Initialiser le cluster Omnissa Access Control Plane

Suivez les procédures ci-dessous pour initialiser le cluster Omnissa Access Control Plane à partir du nœud de démarrage. Toutes les commandes doivent être exécutées à partir du nœud de démarrage.

Initialisez le cluster du plan de contrôle.

Procédure :

• Suivez les instructions en ligne ci-dessous pour initialiser le cluster du plan de contrôle.

  Remarque : exécutez la commande suivante, en remplaçant <size_of_your_deployment> par small, medium ou large pour correspondre à la taille OVA que vous avez déployée :

  cd /opt/wss/<cluster_name>
  wso access init -n cp-cluster -s <size_of_your_deployment>
  

  Lorsque vous exécutez cette commande, la sortie se présente comme suit :

  cd /opt/wss/<cluster_name>
  wso access init -n cp-cluster -s small
  
  # Output
  <timestamp> Control Plane name: cp-cluster
  <timestamp> Created a sample profile.yml file
  <timestamp> Sample Control Plane inventory file created
  <timestamp> Created a sample telemetry config file: /opt/wss/<cluster_name>/telegraf_plugin/prometheus_remote_write.conf.example
  <timestamp> Successfully initialized
  

Résultats :

Cette commande crée les fichiers suivants :

• Fichier d'inventaire de cluster : /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
• Fichier de configuration de déploiement : /opt/wss/<cluster_name>/profile.yml

Configurer l'inventaire du cluster

Le fichier cp-cluster.ini définit les éléments suivants :

• Nœuds d'infrastructure/de plate-forme
• Nœuds Omnissa Access

Générer un fichier de clé privée SSH :

Si vous prévoyez d'utiliser ansible_ssh_private_key_file pour vous connecter à des nœuds de cluster (au lieu de ansible_password), générez le fichier de clé ci-dessous avant de remplir le fichier cp-cluster.ini.

# On bootstrap node follow below steps
# change to configuser
su configuser

# Generate Public and private keys
ssh-keygen -t <cipher>

# Copy public Key to all other machines (Access+Infra+platform)
ssh-copy-id configuser@10.0.0.X 
# Repeat this for all cluster VMs from bootstrap VM

# Test login work with other machines without password
ssh configuser@10.0.0.X
# You should be able to login to 10.0.0.X from bootstrap without credentials

# Exit from 10.0.0.X by using exit command, so that you are in bootstrap machine. 
exit 
# Exit as configuser; run again to return to root

# create a directory in bootstrap machine
mkdir -p /opt/wss/<cluster_name>/cp-cluster/private-key

# Copy the private key to PATH
cp /home/configuser/.ssh/id_<cipher> /opt/wss/<cluster_name>/cp-cluster/private-key

# change the permission of file
chmod 400 /opt/wss/<cluster_name>/cp-cluster/private-key/id_<cipher>

Procédure de remplissage automatique du fichier cp-cluster.ini :

Exécutez la commande suivante :

update-cluster-ini INI_FILE=/opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini

# Output

[root@bootstrap configuser]# update-cluster-ini INI_FILE=/opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
Enter User (this is the user created at OVA deployment): configuser
Use (1) password or (2) ssh_private_key_file?
Enter 1 or 2: 1
Enter password:
Deployment size: (1) small  (2) medium  (3) large
Enter 1, 2, or 3: 1
Enter Omnissa Access Node IPs (2 IPs required, comma or space separated): 10.0.0.x 10.0.0.x
Enter infra and platform node IPs (3 IPs required, comma or space separated): 10.0.0.x 10.0.0.x 10.0.0.x 
Moved existing /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini to /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini.bkp.20260714_052152
Written /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini (small): access=2, infra=3, asset=2.

Remarque : lorsque vous êtes invité à saisir le mot de passe, entrez le même mot de passe que celui utilisé pour le compte configuser lors du déploiement OVA. Ce mot de passe doit être identique sur tous les nœuds de démarrage, Omnissa Access et d'infrastructure/de plate-forme du cluster.

Procédure manuelle de mise à jour du fichier cp-cluster.ini :

1. Ouvrez le fichier cp-cluster.ini Par exemple :

   vi /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
   

2. Suivez les instructions en ligne ci-dessous pour la mise à jour du fichier.

   Remarque : ansible_user doit toujours être défini sur configuser.

   Choisissez ensuite une méthode d'authentification :

   • ansible_password : vérifiez que le champ est défini sur le mot de passe configuser.
   • ansible_ssh_private_key_file : clé privée SSH générée pour configuser (reportez-vous à la section Générer un fichier de clé privée SSH ci-dessus).

   Utilisez l'un ou l'autre, mais pas les deux.

   [linux:children]
   asset_server_linux
   consul_server_linux
   general_compute_linux
   kafka_controller_linux
   kafka_server_linux
   nomad_server_linux
   opensearch_leader_linux
   opensearch_data_linux
   postgres_linux
   vault_server_linux
   general_compute_nginx_http
   general_compute_access_linux
   
   # This template includes sample IPs. Please update these to match your specific environment settings.
   
   # Provide IPs to asset server nodes
   [asset_server_linux]
   10.0.0.1
   10.0.0.2
   
   # Provide IPs to all Infrastructure/Platform and Omnissa Access nodes
   [consul_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   10.0.0.4
   10.0.0.5
   
   # Provide IPs to all Infrastructure/Platform and Omnissa Access nodes
   [vault_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   10.0.0.4
   10.0.0.5
   
   # Provide IPs to all Infrastructure/Platform and Omnissa Access nodes
   [nomad_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   10.0.0.4
   10.0.0.5
   
   # Provide IPs to kafka controller nodes
   [kafka_controller_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to kafka server nodes
   [kafka_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to postgres server nodes
   [postgres_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to Opensearch leader nodes
   [opensearch_leader_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to Opensearch data nodes
   [opensearch_data_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to General compute nodes
   [general_compute_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs to access compute nodes
   [general_compute_access_linux]
   10.0.0.4
   10.0.0.5
   
   # Provide IPs to Nginx HTTP server nodes
   [general_compute_nginx_http]
   10.0.0.4
   10.0.0.5
   
   [linux:vars]
   # Uncomment ansible_user, ansible_password or ansible_ssh_private_key_file below to provide common credentials to connect to each of the specified nodes
   # Only one of password or ssh private key can be provided
   #ansible_user=
   #ansible_password=
   #ansible_ssh_private_key_file=
   

Mettre à jour le fichier profile.yml

Cette procédure garantit que seuls les services d'infrastructure de base sont déployés initialement.

Le fichier profile.yml (/opt/wss/<cluster_name>/profile.yml) contient des paramètres de configuration au niveau du déploiement pour l'environnement du cluster. Il est principalement utilisé pour configurer les éléments suivants :

• Synchronisation de l'heure (NTP)

• Stockage partagé (NFS)

• Intégration centralisée de la journalisation

  La section journalisation permet aux services de cluster de transférer les journaux vers des plates-formes de journalisation centralisées telles que :

  • Loki
  • OpenSearch
  • Syslog

  Exemple de structure :

  # logging:
  # loki_server:
  #    url:
  #    username:
  #    password:
  # opensearch:
  #    url: https://10.0.0.x:<port>
  #    username: host-logging-writer
  #    password: *******
  #    index_prefix: access_logs
  # syslog_servers:
  #    host:
  #    protocol: udp
  #    port: 514
  #    syslog_cert_passphrase:   # only if your syslog client key in the logging directory is passphrase-protected  
  

Remarques importantes

• La journalisation des modifications de configuration après le déploiement peut nécessiter un redéploiement ou une mise à niveau pour prendre effet.
• Supprimez les commentaires et configurez uniquement les sections requises.
• Assurez-vous que tous les services externes (serveurs NTP, NFS et de journalisation) sont accessibles à partir des nœuds de cluster.
• Cette procédure n'est pas obligatoire, mais si votre organisation dispose d'un serveur NTP, vous pouvez activer et mettre à jour la configuration du serveur NTP avec l'adresse du serveur

Procédure :

1. Ouvrez le fichier profile.yml Par exemple :

   vi /opt/wss/<cluster_name>/profile.yml
   

2. Annulez la mise en commentaire des paramètres utilisés pour configurer le stockage partagé basé sur NFS (si besoin) et le serveur NTP (recommandé) pour le cluster, de la façon suivante :

   # Uncomment and provide NTP server to configure for time synchronization on the cluster nodes
   # ntp_server:
   
   # Uncomment and provide NFS server to configure Network File Share on the cluster nodes
   # nfs_host: 10.0.0.x
   # nfs_path:
   # nfs_version: 4
   

3. Examinez le reste du fichier profile.yml et mettez à jour d'autres sections nécessaires, telles que la journalisation et les mesures.

4. Enregistrez le fichier profile.yml.

5. Exécutez la commande suivante pour valider le fichier profile.yml.

   wso cp precheck
   
   # Output
   Cluster Size is (small)...
   The following errors were found in the cluster configuration:
   logging configuration is not set
   telemetry configuration is not set
   nfs backup server info is not set
   
   Please fix the above errors and validate the cluster configuration again.
   

   Remarque : si wso cp precheck signale que les informations de journalisation, de télémétrie ou de serveur de sauvegarde NFS ne sont pas définies, ces erreurs sont attendues si vous n'avez pas configuré ces paramètres facultatifs. Vous pouvez les ignorer en toute sécurité et passer à wso access validate.

Validez le fichier d'inventaire de cluster

• Après la mise à jour du fichier d'inventaire (.ini), validez-le. Par exemple :

  wso access validate
  
  # OUTPUT
  <timestamp> Inventory file validated successfully.
  

  Remarque : wso access validate peut signaler la réussite, même si wso cp precheck a signalé des erreurs de configuration précédemment. Il s'agit d'un comportement attendu ; poursuivez avec wso access validate, quels que soient les avertissements de vérification préalable.