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 /opt/wss/<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, um 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 /opt/wss/<cluster_name>
     wso cp deploy -t "10.0.0.x"
     

     Für mehrere Knoten:

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

3. Führen Sie den folgenden Befehl aus, um den Zustand des Clusters zu überprüfen:

   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 keine ausgewählten Dienste 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 /opt/wss/<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 die Konten configuser und root beträgt 60 Tage. Sie müssen das Kennwort auf jedem Knoten des Steuerungsebenen-Clusters ändern, bevor es abläuft.

Das Root-Kennwort und das configuser-Kennwort müssen nicht miteinander übereinstimmen, aber jedes muss auf jedem Knoten im Cluster identisch sein. Beispielsweise muss das Root-Kennwort auf jedem Knoten identisch sein, und das configuser-Kennwort muss auf jedem Knoten identisch sein.

Zurücksetzen des Configuser- oder Root-Kennworts

Einzelner Knoten, als Root oder über Sudo angemeldet:

passwd configuser
passwd root

Auf allen Knoten gleichzeitig, vom Bootstrap-Knoten aus:

export TARGETS='general_compute_linux:general_compute_access_linux'
wso control-plane ansible -- -b -m shell -a "echo 'configuser:NEW_PASSWORD' | chpasswd" "${TARGETS}"
wso control-plane ansible -- -b -m shell -a "echo 'root:NEW_PASSWORD' | chpasswd" "${TARGETS}"

Ersetzen Sie NEW_PASSWORD vor der Ausführung durch das tatsächliche Kennwort und ${TARGETS} durch die Ansible-Bestandslistengruppe oder das Hostmuster für die zu aktualisierenden Knoten – lassen Sie den Platzhalter nicht wörtlich in einem gespeicherten Skript oder Ihrem Shell-Verlauf stehen.

Wichtig: Aktualisieren Sie nach dem Ändern des configuser-Kennworts dasselbe Kennwort in cp-cluster.ini auf dem Bootstrap-Knoten. Andernfalls schlagen wso-CLI-Vorgänge für den Cluster bei der Authentifizierung fehl. Aktive configuser-Sitzungen müssen nach einem Zurücksetzen nicht ungültig gemacht werden.

Kennwortablaufzeit ändern

Die 60-tägige Gültigkeitsdauer wird durch die Felder „password-aging“ für jedes Konto gesteuert.

Hinweis: Wenn Sie den Befehl als configuser ausführen, stellen Sie den Befehlen sudo voran.

Überprüfen Sie die aktuelle Einstellung mit:

chage -l configuser
chage -l root

Ändern Sie diese pro Konto (einzelner Knoten):

chage -M <days> configuser
chage -M <days> root

-M legt die maximale Anzahl an Tagen fest, die ein Kennwort gültig bleibt. -1 deaktiviert den Ablauf (nicht allgemein empfohlen für root- oder -Dienstkonten).

Wiederherstellen eines vollständig vergessenen Root-Kennworts

Hierfür ist Konsolen- (Hypervisor-)Zugriff auf die betroffene VM erforderlich – dies ist nicht über SSH möglich und es kann jeweils nur ein Knoten wiederhergestellt werden.

1. Starten Sie die VM neu und unterbrechen Sie den Vorgang im GRUB-Menü.

2. Markieren Sie den Starteintrag und drücken Sie e, um ihn zu bearbeiten.

3. Suchen Sie die Zeile, die mit linux (oder linux16) beginnt, gehen Sie an deren Ende und hängen Sie Folgendes an:

   rd.break enforcing=0
   

4. Drücken Sie Ctrl+X (oder F10), um mit den geänderten Parametern zu starten. Dies führt Sie zur Dracut-Notfall-Shell.

5. Hängen Sie das Root-Dateisystem mit Lese-/Schreibzugriff neu ein und führen Sie ein „chroot“ darauf aus:

   mount -o remount,rw /sysroot
   chroot /sysroot
   

6. Legen Sie das neue Kennwort fest:

   passwd root
   

7. Markieren Sie das Dateisystem für eine SELinux-Neukennzeichnung beim nächsten Start, da SELinux für diese Sitzung im Permissive-Modus war:

   touch /.autorelabel
   

8. Beenden Sie chroot und starten Sie neu:

   exit
   reboot
   

   Der erste Startvorgang danach dauert aufgrund der SELinux-Neukennzeichnung länger als gewöhnlich.