Installation d'Omnissa Access

Pour déployer Omnissa® Access™ sur le plan de contrôle, suivez les instructions fournies dans ce guide.

Cette section Installation d'Omnissa Access du guide Installation et configuration d'Omnissa Access vous guide à travers le processus de bout en bout de déploiement d'Omnissa Access dans votre environnement. Elle inclut une présentation du déploiement, une description des composants de plate-forme qui composent un cluster Omnissa Access, l'architecture de déploiement prise en charge et une séquence d'installation progressive qui vous guide de la préparation initiale de la machine virtuelle jusqu'à la création de locataires, soit au moyen de l'assistant guidé Access Wizard, soit manuellement, si vous préférez garder un contrôle direct sur chacune des étapes.

Le stockage NFS est requis si vous prévoyez de configurer un site de récupération d'urgence (DR) pour votre déploiement. Pour connaître les conditions préalables, reportez-vous à la section Configurer la récupération d'urgence pour Omnissa Access.

Une fois l'installation terminée, le guide continue avec des rubriques de configuration et de gestion qui vous aident à préparer et à exploiter votre déploiement.

Une fois la configuration terminée, vous pouvez utiliser la console Omnissa Access pour gérer les utilisateurs et les groupes, configurer et gérer les stratégies d'authentification et d'accès, et ajouter des ressources au catalogue et gérer les droits d'accès à ces ressources. Vous pouvez également configurer l'intégration de Workspace ONE UEM et lancer Hub Services.

Présentation de l'architecture

Omnissa Access s'exécute sous la forme d'un ensemble de microservices en conteneur gérés par le plan de contrôle. Les services qui composent Omnissa Access sont distribués sur un cluster de machines virtuelles dédiées, exécutant toutes AlmaLinux 9.6, et sont déployés et exploités comme des charges de travail indépendantes. Du fait que chaque service s'exécute indépendamment, les services peuvent être mis à jour, redémarrés, mis à l'échelle et récupérés individuellement.

Plan de contrôle

Le plan de contrôle est la plate-forme qui installe, exécute, met à l'échelle et surveille les services qui constituent un déploiement d'Omnissa Access. Il coordonne chaque service du cluster à l'aide de trois services de plate-forme :

• Nomad planifie et orchestre les charges de travail de service.
• Consul fournit la détection de services et sécurise la communication interne entre les services.
• Vault stocke et gère les clés secrètes, les certificats et les jetons.

Catégories de services

Un déploiement d'Omnissa Access se compose de trois catégories de services :

Types de nœuds

Un cluster Omnissa Access est créé à partir de trois types de machines virtuelles, plus un équilibreur de charge :

• Nœud de démarrage : contrôleur de déploiement. Exécutez l'interface de ligne de commande WSO à partir de ce nœud pour déployer et exploiter le cluster.
• Nœuds d'infrastructure/de plate-forme : hébergez les services de plate-forme et les services d'infrastructure.
• Nœuds Omnissa Access : hébergez les services Omnissa Access. Les services de plate-forme s'exécutent également sur ces nœuds.
• Équilibreur de charge : distribue le trafic entre les nœuds Omnissa Access et fournit une haute disponibilité pour les services Access.

Les services de plate-forme s'exécutent à la fois sur les nœuds d'infrastructure/de plate-forme et sur les nœuds Omnissa Access, de sorte que l'orchestration, la détection de services et la gestion des secrets continuent de fonctionner dans l'ensemble du cluster plutôt que de dépendre d'un seul nœud.

Interface de ligne de commande WSO

La CLI WSO (interface de ligne de commande de Workspace ONE) est l'interface principale pour le déploiement et l'exécution d'Omnissa Access. Vous exécutez les commandes de l'interface de ligne de commande WSO à partir du nœud de démarrage.

Présentation du déploiement

Omnissa Access est déployé sur la plate-forme du plan de contrôle en plusieurs phases. Chaque phase dépend de la réussite de la phase précédente.

Phases de déploiement

1. Préparez les machines virtuelles.
2. Déployez les machines virtuelles.
3. Déployez Omnissa Access, en choisissant l'une des options suivantes :
   • Option 1 : utilisation d'Access Wizard.
   • Option 2 : manuellement, étape par étape.

Architecture de déploiement

Assurez-vous que les détails suivants liés à l'architecture sont respectés, comme requis pour Omnissa Access :

• Machines virtuelles requises

  Type de nœud	Nombre	Objectif
  Nœuds d'infrastructure/de plate-forme	3	Services d'infrastructure
  Nœuds Omnissa Access	2 pour les déploiements petits et moyens 3 pour les déploiements grands	Services applicatifs Access
  Nœud de démarrage	1	Contrôleur de déploiement
  Équilibreur de charge	0	Pour la haute disponibilité (HA) des services Access

  Remarque : les services de plate-forme s'exécutent sur les nœuds d'infrastructure/de plate-forme et les nœuds Omnissa Access.

• Placement des services

  Nœud	Services
  Nœuds d'infrastructure/de plate-forme	Nomad, Consul, Vault, Postgres, Redis, Kafka, OpenSearch
  Nœuds Omnissa Access	Services Nomad, Consul, Vault, Access
  Nœud de démarrage	Déploiement/Opérations administratives

  Assurez-vous que tous les nœuds répondent aux exigences suivantes :

  • Exécuter AlmaLinux 9.6
  • Disposer d'adresses IP statiques
  • Disposer de noms d'hôte uniques
  • Disposer d'un accès au protocole SSH à partir du nœud de démarrage

• Configuration de l'équilibrage de charge

  Configurez votre équilibreur de charge et ajoutez vos nœuds de service d'accès en amont, ce qui permet à l'équilibreur de charge d'effectuer la redirection vers n'importe quel nœud. Reportez-vous à la section Utilisation d'un équilibreur de charge ou d'un proxy inverse pour activer l'accès externe à Omnissa Access pour les exigences de configuration.

• Résolution DNS

  • Entrée DNS : assurez-vous qu'une entrée DNS est résolue en adresse IP du nom de domaine complet (adresse IP de l'équilibreur de charge).

    tenant.example.com

• Conditions requises pour les certificats

  • Nom commun (CN) : nom d'hôte de l'équilibreur de charge (tenant.example.com).

  • Autres noms du sujet (SAN)

    • Exemples :
      • tenant.example.com
      • tenant-cert.example.com
      • tenant-amsso.example.com

    Assurez-vous que la partie domaine de toutes les entrées d'autres noms du sujet correspond au domaine utilisé par l'équilibreur de charge et les nœuds de cluster.

    Remarques :

    • Vous pouvez choisir d'utiliser un certificat générique, tel que *.tenant.example.com pour couvrir tous les autres noms du sujet.
    • Si vous n'utilisez pas l'authentification basée sur un certificat, tenant.example.com est le seul autre nom du sujet requis. Vous pouvez omettre tenant-cert.example.com et tenant-amsso.example.com.

  Référence CSR

  Utilisez l'une des configurations suivantes en fonction de votre type de certificat.

  Certificat générique

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = *.tenant.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = *.tenant.example.com
  

  Certificat non générique (tous les autres noms du sujet requis)

  Si vous n'utilisez pas de certificat générique, répertoriez explicitement chaque autre nom du sujet.

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = tenant.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = tenant.example.com
  DNS.2 = tenant-cert.example.com
  DNS.3 = tenant-amsso.example.com