Cette phase de préparation garantit que toutes les machines virtuelles, la mise en réseau, les certificats et les conditions préalables de l'infrastructure sont préparés avant de démarrer un déploiement basé sur le plan de contrôle d'Omnissa Access.
Dans ce modèle de déploiement, les services de plate-forme et d'application sont déployés sur des machines virtuelles dédiées et orchestrés via l'infrastructure du plan de contrôle. Toutes les machines virtuelles requises et l'infrastructure de prise en charge nécessaires doivent être provisionnées et validées avant de commencer le workflow de déploiement.
Configuration requise de la topologie de déploiement
Le modèle de déploiement utilise des machines virtuelles dédiées pour le démarrage, les services d'infrastructure/de plate-forme et les services Omnissa Access.
Un déploiement de production standard se compose des nœuds suivants :
| Type de nœud | Quantité | Objectif |
|---|---|---|
| Nœud de démarrage | 1 | Initialise et orchestre le déploiement du plan de contrôle. |
| Nœuds Omnissa Access | 2 ou 3 | Héberge les services applicatifs Omnissa Access derrière l'équilibreur de charge. |
| Nœuds d'infrastructure/de plate-forme | 3 | Héberge des services de plate-forme et d'infrastructure partagée. |
Nombre total de nœuds requis : 6 si vous utilisez petit ou grand, 7 si vous utilisez grand.
Important :
- Toutes les machines virtuelles doivent être déployées et accessibles avant de démarrer le workflow d'installation.
- Les adresses IP statiques, les enregistrements DNS et les noms d'hôte doivent être configurés pour tous les nœuds.
- Le mot de passe
configuserdoit être configuré de manière cohérente sur tous les nœuds. - L'expiration du mot de passe par défaut de
configuserest de 60 jours à partir de la date du déploiement OVA. Vous devez réinitialiser le même mot de passe sur tous les nœuds du cluster. - Une fois le démarrage du plan de contrôle et l'initialisation du cluster terminés, la modification des rôles de nœud ou de la topologie de déploiement n'est pas prise en charge.
- Tous les nœuds doivent pouvoir communiquer entre eux sur les ports réseau requis.
- Un équilibreur de charge doit être configuré devant les nœuds Omnissa Access avant le déploiement.
Directives de configuration de l'infrastructure pour la haute disponibilité
Pour vous assurer que le système reste en cours d'exécution même si un problème se produit, suivez ces règles lors de la création de machines virtuelles (VM) pour l'infrastructure et la plate-forme.
Exécutez chaque nœud sur une machine physique différente (hôtes ESX) Par exemple, si vous avez besoin de trois nœuds d'infrastructure/de plate-forme et de deux nœuds Omnissa Access, placez-les comme suit :
- Nœud d'infrastructure/de plate-forme 1 → Hôte physique 1
- Nœud d'infrastructure/de plate-forme 2 → Hôte physique 2
- Nœud d'infrastructure/de plate-forme 3 → Hôte physique 3
- Nœud Omnissa Access 1 → hôte physique 1
- Nœud Omnissa Access 2 → hôte physique 2
Avec cette approche, si un hôte physique tombe en panne, le service peut toujours s'exécuter en utilisant les deux autres, ce qui maintient votre système disponible et stable.
Exigences de dimensionnement de matériel
Le dimensionnement suivant s'applique uniquement aux déploiements basés sur le plan de contrôle d'Omnissa Access.
Choisissez une taille de déploiement en fonction du nombre d'utilisateurs, de groupes et d'applications dans votre environnement.
Le tableau suivant montre la configuration matérielle minimale requise pour chaque taille de déploiement.
Configuration matérielle minimale par taille de déploiement :
| Taille du déploiement | Nœud de démarrage | Nœuds Omnissa Access | Nœuds d'infrastructure/de plate-forme¹ | Échelle prise en charge |
|---|---|---|---|---|
| Petite | 1 nœud 8 vCPU RAM de 32 Go 200 Go de disque | 2 nœuds équilibrés en charge 24 vCPU 48 Go de RAM 200 Go de disque chacun | 3 nœuds 16 vCPU 48 Go de RAM 200 Go de disque chacun | Jusqu'à : 300 000 utilisateurs 3 000 groupes 50 applications |
| Moyenne | 1 nœud 8 vCPU RAM de 32 Go 200 Go de disque | 2 nœuds équilibrés en charge 48 vCPU 64 Go RAM 200 Go de disque chacun | 3 nœuds 24 vCPU 96 Go de RAM 300 Go de disque chacun | Jusqu'à : 1 000 000 utilisateurs 10 000 groupes 150 applications |
| Grande | 1 nœud 8 vCPU RAM de 32 Go 200 Go de disque | 3 nœuds équilibrés en charge 64 vCPU 96 Go de RAM 200 Go de disque chacun | 3 nœuds 24 vCPU 96 Go de RAM 400 Go de disque chacun | Jusqu'à : 1 000 000 utilisateurs 20 000 groupes 500 applications |
¹ Les nœuds d'infrastructure/de plate-forme hébergent des services de plate-forme internes, notamment la base de données, la messagerie, la mise en cache et la recherche (PostgreSQL, Redis, Kafka et OpenSearch).
*Le nœud de démarrage nécessite exactement 8 vCPU, quelle que soit la taille du déploiement.
Important :
- Le dimensionnement des ressources peut varier en fonction de la charge d'authentification, des services activés et des exigences d'intégration.
- Une allocation de stockage supplémentaire peut être requise en fonction de la journalisation, de la rétention d'audit et des exigences opérationnelles.
Conditions requises pour tous les nœuds
Téléchargez le fichier OVA d'Omnissa Access sur la page Omnissa Customer Connect et sélectionnez Omnissa Access. Après avoir téléchargé le fichier, déployez toutes les machines virtuelles.
Assurez-vous que les exigences suivantes sont remplies pour tous les nœuds avant le déploiement :
- Adresse IP statique attribuée.
- Nom d'hôte configuré correctement.
- Résolution DNS configurée et validée si vous utilisez des noms d'hôte dans le fichier
cp-cluster.ini. - Accès SSH activé.
- Tous les nœuds accessibles entre eux sur le réseau.
- Équilibreur de charge configuré et accessible.
- Mot de passe
configuserconfiguré ou réinitialisé sur le même mot de passe sur tous les nœuds.
L'objectif est de s'assurer que le système d'exploitation et l'infrastructure de base sont entièrement préparés et n'interfèrent pas avec les services du plan de contrôle pendant le déploiement.
Conditions requises pour les certificats
Préparez les certificats TLS requis avant le déploiement.
Certificat de nom de domaine complet d'Omnissa Access
Un certificat TLS est requis pour le nom de domaine complet du déploiement d'Omnissa Access.
Conditions requises pour les certificats :
- Format PEM (
.pem). - Le CN doit correspondre au nom de domaine complet du locataire principal.
- Le certificat doit inclure les noms alternatifs du sujet (SAN, Subject Alternative Names) suivants :
tenant.example.comtenant-cert.example.comtenant-amsso.example.com
Les certificats génériques sont pris en charge s'ils répondent aux entrées de noms alternatifs du sujet requises.
Exemple :
Si le domaine de déploiement est example.com, les entrées de noms alternatifs du sujet du certificat peuvent être les suivantes :
- tenant.example.com
- tenant-cert.example.com
- tenant-amsso.example.com
Les fichiers de certificat et de clé privée sont requis lors de la configuration du déploiement.
Exigences de configuration réseau
| Composant | Description |
|---|---|
| Enregistrement DNS et adresse IP | Adresse IP et enregistrement DNS. Collectez les informations requises pour déployer le modèle OVF, telles que : nom d'hôte, adresse IPv4 de la carte réseau 1 (eth0), adresses du serveur DNS, domaine de recherche DNS, masque de réseau IPv4 de la carte réseau 1, passerelle par défaut IPv4, CIDR IPv4 du pont Docker0. |
| Port du pare-feu | Assurez-vous que les ports de pare-feu entrants sont ouverts pour les utilisateurs extérieurs au réseau, pour l'instance Omnissa Access ou l'équilibreur de charge. Consultez les conditions requises de port suivantes. |
| Proxy inverse | Déployez un proxy inverse, tel que F5 Access Policy Manager, dans la zone DMZ pour permettre aux utilisateurs d'accéder en toute sécurité au portail de l'utilisateur d'Omnissa Access à distance. |
Unified Access Gateway 2.8 et versions ultérieures prennent en charge la fonctionnalité de proxy inverse pour autoriser les utilisateurs à accéder en toute sécurité au catalogue unifié d'Omnissa Access à distance. Vous pouvez déployer Unified Access Gateway dans la zone DMZ derrière les équilibrages de charge se trouvant devant le dispositif Omnissa Access.
Exigences du port
Les conditions requises de port suivantes concernent les communications interne et externe.
| Service | Destiné au public | Port | Protocole | Direction | Type de nœud de source | Type de nœud de destination |
|---|---|---|---|---|---|---|
| Consul LAN Gossip | Non | 8301 | TCP/UDP | Bidirectionnel | tous les | tous les |
| Consul RPC | Non | 8300 | TCP | Bidirectionnel | tous les | tous les |
| Port Consul Mesh gRPC | Non | 8302 | gRPC | Bidirectionnel | Charge de travail d'application/de cluster | Charge de travail d'application/de cluster |
| Consul HTTP(s) | Non | 8501 | HTTPS | Entrant | CLI | Cluster de gestion |
| Ports de service dynamiques | Non | 20 000–32 000 | TCP/HTTPS | Bidirectionnel | Charge de travail d'application/de cluster | Charge de travail d'application/de cluster |
| UI/API Nomad | Non | 4646 | HTTPS | Entrant | CLI | Cluster de gestion |
| UI/API Nomad | Non | 4647 | TCP | Bidirectionnel | tous les | tous les |
| Nomad LAN Gossip | Non | 4648 | TCP/UDP | Bidirectionnel | tous les | tous les |
| Vault | Non | 8201 | TCP | Bidirectionnel | Cluster de gestion | Cluster de gestion |
| Vault API | Non | 8202 | HTTPS | Entrant | CLI | Cluster de gestion |
| Télémétrie sortante | Non | 8125 | UDP | Sortant | tous les | Cluster de gestion |
| Télémétrie sortante | Non | 2878 | TCP | Entrant | Charge de travail d'application/de cluster | Charge de travail d'application/de cluster |
| Télémétrie sortante | Non | 9411 | TCP | Sortant | tous les | Charge de travail d'application/de cluster |
| Journalisation Syslog sortante | Non | 5044 | TCP | Entrant | Charge de travail d'application/de cluster | Charge de travail d'application/de cluster |
| Connexion Redis | Non | 6379 | TCP | Bidirectionnel | Charge de travail d'application/de cluster | Charge de travail d'application/de cluster |
| Connexion Redis TLS | Non | 16380 | TCP | Bidirectionnel | Charge de travail d'application/de cluster | Charge de travail d'application/de cluster |
| Connexion Redis Sentinel | Non | 26379 | TCP | Bidirectionnel | Charge de travail d'application/de cluster | Charge de travail d'application/de cluster |
| Connexion Redis Sentinel TLS | Non | 36379 | TCP | Bidirectionnel | Charge de travail d'application/de cluster | Charge de travail d'application/de cluster |
| Connexion Postgres | Non | 5432 | TCP | Entrant | Charge de travail d'application/de cluster | Core Services |
| Connexion Postgres | Non | 5432 | TCP | Bidirectionnel | Core Services | Core Services |
| Connexions client | Non | 9092 | TCP | Entrant | Charge de travail d'application/de cluster | Core Services |
| Connexions client | Non | 9096 | TCP | Entrant | Charge de travail d'application/de cluster | Core Services |
| Kafka | Non | 9094 | TCP | Entrant | Core Services | Core Services |
| Kafka | Non | 9093 | TCP | Entrant | Core Services | Core Services |
| Kafka | Non | 2181 | TCP | Entrant | Core Services | Core Services |
| Kafka | Non | 2888 | TCP | Entrant | Core Services | Core Services |
| Kafka | Non | 3888 | TCP | Entrant | Core Services | Core Services |
| Passerelle d'entrée | Non | 8080 | HTTPS | Entrant | tous les | Charge de travail d'application/de cluster |
| Images/modules/ressources binaires de Docker | Non | 443 | HTTPS | Entrant | tous les | Serveur de ressources |
| Connexion client OpenSearch | Non | 29200 | TCP | Bidirectionnel | Charge de travail d'application/de cluster | Core Services |
| Communication interne OpenSearch | Non | 29300 | TCP | Bidirectionnel | Charge de travail d'application/de cluster | Core Services |
| Postgres | Non | 28008 | HTTPS | Bidirectionnel | Charge de travail d'application/de cluster | Core Services |
| NGINX | Oui | 80 | HTTP | Entrant | tous les | Nœuds Omnissa Access |
| NGINX | Oui | 443 | HTTPS | Entrant | tous les | Nœuds Omnissa Access |
| Flux NGINX | Oui | 27443 | TCP | Entrant | tous les | Nœuds Omnissa Access |
| Flux NGINX | Oui | 25262 | TCP | Entrant | tous les | Nœuds Omnissa Access |
| CAS | Non | 28443 | TCP | Entrant | tous les | Nœuds Omnissa Access |
| CERTPROXY | Non | 25261 | TCP | Entrant | tous les | Nœuds Omnissa Access |
Important :
- Assurez-vous que les règles de pare-feu requises sont configurées avant le déploiement.
- Les ports de plate-forme interne doivent être accessibles entre l'infrastructure et les nœuds d'Omnissa Access.
- Les ports publics doivent être exposés uniquement via l'équilibreur de charge ou le proxy inverse.
- L'exposition des ports peut varier en fonction de l'architecture de déploiement et des exigences de sécurité.
Cette page vous a-t-elle été utile ?