Skip to main content

18 août 2026

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 : selon la taille du fichier OVA que vous avez déployé, vous devez exécuter l'une des commandes suivantes. Exemple :

  • Si vous avez déployé un fichier OVA de petite taille  : wso access init -n cp-cluster -s small

  • Si vous avez déployé un fichier OVA de taille moyenne wso access init -n cp-cluster -s medium

  • Si vous avez déployé un fichier OVA de grande taille wso access init -n cp-cluster -s large

Lorsque vous exécutez l'une de ces commandes, la sortie se présente comme suit :

cd /root/<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: /root/<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 (cp-cluster.ini)
  • Fichier 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
ComposantsAdresses IP
asset_serverUn ou deux nœuds d'infrastructure/de plate-forme
consul, vault, nomadTous les nœuds d'infrastructure/plate-forme et les nœuds Omnissa Access
kafka, opensearch, opensearch_leader, persistent_redis, postgres, general_computeTous les nœuds d'infrastructure/de plate-forme
general_compute_access_linuxTous les nœuds Omnissa Access
general_compute_nginx_httpTous les nœuds Omnissa Access

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

Exécutez la commande suivante :

update-cluster-ini.sh INI_FILE=/root/<cluster_name>/cp-cluster/cp-cluster.ini

# Output

[root@bootstrap configuser]# ./update-cluster-ini.sh INI_FILE=/root/<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 /root/<cluster_name>/cp-cluster/cp-cluster.ini to /root/<cluster_name>/cp-cluster/cp-cluster.ini.bkp.20260714_052152
Written /root/<cluster_name>/cp-cluster/cp-cluster.ini (small): access=2, infra=3, asset=2.

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

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

    vi /root/<cluster_name>/cp-cluster/cp-cluster.ini
    
  2. Suivez les instructions en ligne ci-dessous pour la mise à jour du fichier.

    Remarque : vous pouvez utiliser l'option ansible_password ou ansible_ssh_private_key_file.

    Si vous utilisez ansible_ssh_private_key_file, l'étape 3 est requise.

    Si vous utilisez ansible_password, assurez-vous qu'il s'agit bien de celui que vous avez utilisé lors du déploiement OVA.

    [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 management server 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 management server 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 management server 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=
    
    
  3. Suivez les instructions en ligne ci-dessous pour générer le fichier ansible_ssh_private_key_file et l'utiliser dans 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 /root/<cluster_name>/cp-cluster/private-key
    
    # Copy the private key to PATH
    cp /home/configuser/.ssh/id_<cipher> /root/<cluster_name>/cp-cluster/private-key
    
    # change the permission of file
    chmod 400 /root/<cluster_name>/cp-cluster/private-key/id_<cipher>
    

Mise à jour du fichier /root/<cluster_name>/profile.yml

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

Le fichier 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 /root/<cluster_name>/profile.yml
    
  2. Si vous le souhaitez, annulez la mise en commentaire des paramètres utilisés pour configurer le stockage partagé basé sur NFS et le serveur NTP pour le cluster, de la façon suivante :

    # Uncomment and provide NTP server to configure for time synchronization on the cluster nodes
    # ntp_server:
    # 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

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.
    

Cette page vous a-t-elle été utile ?

Envoyer un commentaire sur cette rubrique

Cette rubrique vous a-t-elle été utile ?

N'indiquez aucune information personnelle ou confidentielle.

Génération du lien…