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
| Composants | Adresses IP |
|---|---|
| asset_server | Un ou deux nœuds d'infrastructure/de plate-forme |
| consul, vault, nomad | Tous les nœuds d'infrastructure/plate-forme et les nœuds Omnissa Access |
| kafka, opensearch, opensearch_leader, persistent_redis, postgres, general_compute | Tous les nœuds d'infrastructure/de plate-forme |
| general_compute_access_linux | Tous les nœuds Omnissa Access |
| general_compute_nginx_http | Tous 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 :
-
Ouvrez le fichier
cp-cluster.iniPar exemple :vi /root/<cluster_name>/cp-cluster/cp-cluster.ini -
Suivez les instructions en ligne ci-dessous pour la mise à jour du fichier.
Remarque : vous pouvez utiliser l'option
ansible_passwordouansible_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= -
Suivez les instructions en ligne ci-dessous pour générer le fichier
ansible_ssh_private_key_fileet l'utiliser dans le fichiercp-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 :
-
Ouvrez le fichier
profile.ymlPar exemple :vi /root/<cluster_name>/profile.yml -
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 -
Examinez le reste du fichier
profile.ymlet mettez à jour d'autres sections nécessaires, telles que la journalisation et les mesures. -
Enregistrez le fichier
profile.yml. -
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 ?