Initialisieren des Omnissa Access Control Plane-Clusters

Befolgen Sie die nachstehenden Schritte, um den Omnissa Access Control Plane-Cluster vom Bootstrap-Knoten aus zu initialisieren. Alle Befehle müssen über den Bootstrap-Knoten ausgeführt werden.

Initialisieren des Steuerungsebenen-Clusters

Vorgehensweise:

• Befolgen Sie die Inline-Anweisungen unten, um den Steuerungsebenen-Cluster zu initialisieren.

  Hinweis: Führen Sie den folgenden Befehl aus und ersetzen Sie dabei <size_of_your_deployment> durch small, medium oder large, um ihn an die Größe der von Ihnen bereitgestellten OVA anzupassen:

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

  Wenn Sie diesen Befehl ausführen, sieht die Ausgabe in etwa wie folgt aus:

  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
  

Ergebnisse:

Dieser Befehl erstellt die folgenden Dateien:

• Cluster-Bestandslistendatei: /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
• Bereitstellungskonfigurationsdatei: /opt/wss/<cluster_name>/profile.yml

Konfigurieren der Cluster-Bestandsliste

Die cp-cluster.ini-Datei definiert die folgenden Elemente:

• Infrastruktur-/Plattformknoten
• Omnissa Access-Knoten

Generieren einer Privaten SSH-Schlüsseldatei:

Wenn Sie ansible_ssh_private_key_file für die Verbindung zu Clusterknoten verwenden möchten (anstelle von ansible_password), generieren Sie die unten stehende Schlüsseldatei, bevor Sie die cp-cluster.ini-Datei ausfüllen.

# 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>

Vorgehensweise zum automatischen Auffüllen der cp-cluster.ini-Datei:

Führen Sie den folgenden Befehl aus:

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.

Hinweis: Wenn Sie zur Eingabe des Kennworts aufgefordert werden, geben Sie dasselbe Kennwort ein, das für das configuser-Konto bei der OVA-Bereitstellung verwendet wurde. Dieses Kennwort muss für alle Bootstrap-, Omnissa Access- und Infrastruktur-/Plattformknoten im Cluster identisch sein.

Manuelle Vorgehensweise zum Aktualisieren der cp-cluster.ini-Datei:

1. Öffnen Sie die cp-cluster.ini-Datei. Beispiel:

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

2. Befolgen Sie die unten stehenden Inline-Anweisungen, um die Datei zu aktualisieren.

   Hinweis: ansible_user muss immer auf configuser festgelegt sein.

   Wählen Sie anschließend eine Authentifizierungsmethode aus:

   • ansible_password — Vergewissern Sie sich, dass das Feld auf das configuser-Kennwort gesetzt ist.
   • ansible_ssh_private_key_file — der für configuser generierte private SSH-Schlüssel (siehe Generieren einer privaten SSH-Schlüsseldateioben ).

   Verwenden Sie entweder die eine oder die andere Methode, nicht beide.

   [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=
   

Aktualisieren der profile.yml-Datei

Diese Vorgehensweise stellt sicher, dass zunächst nur die zentralen Infrastrukturdienste bereitgestellt werden.

Die profile.yml-Datei (/opt/wss/<cluster_name>/profile.yml) enthält Konfigurationseinstellungen auf Bereitstellungsebene für die Clusterumgebung. Sie wird in erster Linie zur Konfiguration folgender Funktionen verwendet:

• Zeitsynchronisation (NTP)

• Freigegebener Speicher (NFS)

• Integration der zentralisierten Protokollierung

  Der Abschnitt „Protokollierung“ ermöglicht es Cluster-Diensten, Protokolle an zentralisierte Protokollierungsplattformen weiterzuleiten, wie zum Beispiel:

  • Loki
  • OpenSearch
  • Syslog

  Beispielstruktur:

  # 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  
  

Wichtige Hinweise

• Die Protokollierung von Konfigurationsänderungen nach der Bereitstellung erfordert möglicherweise eine erneute Bereitstellung oder ein Upgrade, um wirksam zu werden.
• Heben Sie die Auskommentierung auf und konfigurieren Sie nur die erforderlichen Abschnitte.
• Stellen Sie sicher, dass alle externen Dienste (NTP, NFS, Protokollierungsserver) von Clusterknoten aus erreichbar sind.
• Dies ist keine obligatorische Vorgehensweise. Wenn Ihre Organisation jedoch über einen NTP-Server verfügt, können Sie die NTP-Serverkonfiguration aktivieren und die Serveradresse aktualisieren.

Vorgehensweise:

1. Öffnen Sie die profile.yml-Datei. Beispiel:

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

2. Heben Sie die Auskommentierung der Einstellungen zur Konfiguration des NFS-basierten freigegebenen Speichers (falls gewünscht) und des NTP-Servers (empfohlen) für den Cluster wie folgt:

   # 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. Überprüfen Sie den Rest der profile.yml-Datei und aktualisieren Sie andere erforderliche Abschnitte, wie z. B. Protokollierung und Metriken.

4. Speichern Sie die Datei profile.yml.

5. Führen Sie den folgenden Befehl aus, um die Datei profile.yml zu validieren:

   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.
   

   Hinweis: Wenn wso cp precheck meldet, dass Informationen zu Protokollierung, Telemetrie oder dem NFS-Backup-Server nicht festgelegt sind, sind diese Fehler zu erwarten, sofern Sie diese optionalen Einstellungen nicht konfiguriert haben. Sie können sie bedenkenlos ignorieren und mit wso access validate fortfahren.

Validieren der Cluster-Bestandslistendatei

• Nachdem Sie die Bestandslistendatei (.ini) aktualisiert haben, validieren Sie diese. Beispiel:

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

  Hinweis: wso access validate meldet möglicherweise auch dann Erfolg, auch wenn wso cp precheck zuvor Konfigurationsfehler gemeldet hat. Dies ist das erwartete Verhalten – fahren Sie mit wso access validate ungeachtet etwaiger Vorabprüfungswarnungen fort.