Verwalten der Omnissa Access Control Plane-Clusterknoten

In diesem Thema wird beschrieben, wie Sie eine bestehende Bereitstellung der Steuerungsebene durch Hinzufügen von Infrastruktur-/Plattformknoten und Access-Knoten von Omnissa ersetzen können. Außerdem wird erläutert, was geschieht, wenn ein Knoten nicht mehr funktionsfähig ist und aus dem Cluster entfernt wird.

Hinzufügen eines Omnissa Access-Knoten zum Cluster

Sie können einen vorhandenen Steuerungsebenenknoten ersetzen, indem Sie dem Cluster einen Omnissa Access Linux-Knoten hinzufügen. Neue Knoten werden mithilfe des Befehls wso cp deploy vom Bootstrap-Knoten aus integriert.

Voraussetzungen

• IP-Adresse des neuen Knotens wurde vor der Ausführung des Befehls „deploy“ zur entsprechenden Hostgruppe unter cp-cluster.ini hinzugefügt.
• Der neue Knoten ist über SSH vom Bootstrap-Knoten aus erreichbar.

Vorgehensweise:

1. Öffnen Sie die /root/<cluster-name>/cp-cluster/cp-cluster.ini-Datei und fügen Sie die IP-Adresse des neuen Knotens unter der entsprechenden Hostgruppe hinzu. Beispiel:

   Option 1 – Omnissa Access-Knoten: Wenn Sie einen neuen Omnissa Access-Knoten hinzufügen, fügen Sie ihn in den folgenden Abschnitten hinzu:

   [general_compute_access_linux]
   10.0.0.x
   10.0.0.x  # New node
   [vault_server_linux]
   10.0.0.x  # New node
   [consul_server_linux]
   10.0.0.x  # New node
   [nomad_server_linux]
   10.0.0.x  # New node
   [general_compute_nginx_http]
   10.0.0.x  # New node
   

   Option 2 – Infrastruktur-/Plattformknoten¹ Wenn Sie einen neuen Knoten für Infrastruktur-/Plattformknoten hinzufügen, fügen Sie ihn in allen Abschnitten mit Ausnahme der folgenden Abschnitte hinzu:

   [general_compute_access_linux]
   [general_compute_nginx_http]
   [asset_server_linux]
   
   # If the new node is a candidate for asset-server-linux that will replace existing asset-server, you must add a node IP in asset_server_linux, too.
   
   

   Wichtig: Fügen Sie die IP-Adresse des Bootstrap-Knotens nicht zur Bestandsliste hinzu. Die Validierung schlägt fehl, wenn die Bootstrap-IP erkannt wird.

2. Führen Sie auf dem Bootstrap-Knoten wso cp deploy aus, das Onboarding des Knotens durchzuführen.

   • Um das Onboarding eines oder mehrerer bestimmter Knoten durchzuführen, verwenden Sie das Flag -t (--target-hosts):

     # navigate to your cluster working directory
     cd /root/<cluster_name>
     wso cp deploy -t "10.0.0.x"
     

     Für mehrere Knoten:

     cd /root/<cluster_name>
     wso cp deploy -t "10.0.0.x,10.0.0.x"
     

3. Überprüfen Sie, ob der Cluster fehlerfrei ist wso healthcheck

4. Verschieben Sie Arbeitslasten (Dienste) auf den neuen Knoten. Standardmäßig werden auf dem neu hinzugefügten Knoten keine Arbeitslasten ausgeführt. Sie sollten sich mit dem Nomad-Token bei der Nomad-Benutzeroberfläche anmelden und die folgenden Schritte ausführen

   1. Melden Sie sich bei der Nomad-Benutzeroberfläche unter https://10.0.0.x:4646/ui/jobs an
   2. Klicken Sie auf Clients.
   3. Klicken Sie auf die Knoten-ID, aus der Sie die Arbeitslasten verschieben möchten.
   4. Klicken Sie auf Entleeren (Drain), um die Arbeitslasten auf eine neue VM zu verschieben.

   Hinweis: Nach Abschluss des Entleerungsvorgangs werden alle Arbeitslasten auf die neue VM verschoben. Sie können ausgewählte Dienste nicht auf den neuen Knoten verschieben.

5. Entfernen Sie den vorhandenen Knoten aus dem Cluster, indem Sie den folgenden Befehl ausführen.

   # From the bootstrap VM
   source /root/<cluster_name>/cp-cluster/cp-cluster.env
   server_id = <node_ip> # IP of the node being removed
   
   # API to remove peer
   curl -sk \
   -H "X-Vault-Token: $VAULT_TOKEN" \
   -H "Content-Type: application/json" \
   -X POST \
   -d '{"server_id":"$server_id"}' \
   "$VAULT_ADDRESS/v1/sys/storage/raft/remove-peer"
   

6. Überprüfen Sie die Integrität des Clusters und der Dienste.

   wso healthcheck
   wso access check-service-readiness
   

Fehlerbehebung

Entfernen eines Omnissa Access-Knotens aus dem Cluster

Es gibt keinen speziellen CLI-Befehl zum Entfernen eines Knotens aus dem Steuerungsebenen-Cluster. Wenn ein Knoten nicht mehr verfügbar oder fehlerhaft ist, übernimmt der Cluster die Entfernung automatisch:

• Der Knoten empfängt nach etwa zwei verpassten Taktsignalen keine neuen Arbeitslastzuteilungen mehr.
• Vorhandene Arbeitslasten auf dem Knoten werden auf fehlerfreie Knoten umverteilt.
• Es ist kein Manueller Entfernungsbefehl erforderlich.

1. Entfernen Sie die IP-Adresse des alten Knotens aus allen relevanten Abschnitten der cp-cluster.ini-Datei.
2. Schalten Sie den entfernten Knoten aus.

Hinweis: Die Bereinigung der Cluster-Mitgliedschaft erfolgt nach einem anderen Zeitplan als die Fehlererkennung:

• Consul löscht inaktive Knoten automatisch innerhalb von 24 bis 72 Stunden aus seiner Mitgliederliste.
• Nomad entfernt veraltete Knoten während des nächsten Garbage Collection-Zyklus.
• Aus diesem Grund kann ein entfernter Knoten noch einige Zeit in der Nomad- oder Consul-Benutzeroberfläche angezeigt werden, nachdem er keinen Datenverkehr mehr empfängt, obwohl er nicht mehr für die Planung verwendet wird.

Kennwortverwaltung für Steuerungsebenen-Clusterknoten

Die Standardlaufzeit des Kennworts für den Benutzer „configuser“ und den Root-Benutzer beträgt 60 Tage. Sie müssen das Kennwort für alle Steuerungsebenen-Clusterknoten alle 60 Tage ändern.

Sobald Sie das Kennwort geändert haben, müssen Sie dasselbe Kennwort in der Datei „cp-cluster.ini“ aktualisieren, damit Ihre WSO-CLIs funktionieren.

• Zum Ändern des Kennworts: sudo passwd username
• Informationen zum Aktualisieren des Kennworts in der cp-cluster.ini-Datei finden Sie im Abschnitt „Konfigurieren der Cluster-Bestandsliste“ unter Initialisieren des Omnissa Access Control Plane-Clusters.