PowerFlex: Erläuterung der Funktion „Skript auf Hosts ausführen“ (BS-Patching)

UI – Nach PFMP (PowerFlex 4.x)

Voraussetzungen

Obligatorisch: Das Hauptskript befindet sich im Verzeichnis /opt/emc/scaleio/lia/bin/ mit Ausführungsberechtigungen.

• Der Skriptname muss patch_script lauten. 

Optional: Das Validierungsskript befindet sich im Verzeichnis /opt/emc/scaleio/lia/bin/ mit Ausführungsberechtigungen.

• Der Skriptname muss verification_script lauten.

> Die Funktion wird nur unter Linux (RHEL und SLES) unterstützt.
> Die Funktion prüft, ob der Exitcode am Ende der Ausführung 0 (Null) lautet.
> Die Exitcodes und das ausgeführte Skript finden Sie in den LIA-Protokollen.
> Es liegt in der Verantwortung von KundInnen, das patch_script und verification_script zu testen, bevor der Vorgang über den Gateway ausgeführt wird.
> Die Funktion befindet sich unter: Wartung → Systemprotokolle und Analysen → Skript auf Hosts ausführen

Schritte und Abläufe

Skript wird ausgeführt auf:
1. Gesamtes System: alle PowerFlex-Nodes
Standardmäßig wird das Skript in der Schutzdomain (PD) des ersten Host ausgeführt, dann auf dem zweiten usw.
„Parallel auf verschiedenen Schutzdomains“ deaktiviert: Das Kontrollkästchen ist standardmäßig deaktiviert.
 
„Parallel auf verschiedenen Schutzdomains“ aktiviert: Wenn Sie diese Option auswählen, wird das patch_script in allen PDs parallel ausgeführt.
PDs ohne MDMs werden zuerst ausgeführt und die Cluster-Nodes zuletzt.


2. Schutzdomain: eine bestimmte PD
PDs ohne MDMs werden zuerst ausgeführt und die MDM-Cluster-Nodes zuletzt.

3. Fehlergruppe: ein bestimmte Fehlergruppe
Fehlergruppen ohne MDMs werden zuerst ausgeführt und die MDM-Cluster-Nodes zuletzt.

4. SDS: ein einzelner SDS-Node


Ausführungskonfiguration:
1. „Prozess bei Skriptfehler anhalten“
1.1 „Prozess bei Skriptfehler anhalten“ aktiviert: Das Kontrollkästchen ist standardmäßig aktiviert.
Die gesamte Ausführung schlägt fehl und wird angehalten, sobald das patch_script (und das verification_script, falls ausgewählt) mit einem anderen Code als 0 (Null) beendet wird.
 
1.2 „Prozess bei Skriptfehler anhalten“ deaktiviert
Wenn das patch_script fehlschlägt, schlägt die Ausführung dieses Node fehl und das System wechselt zum nächsten Node und führt das patch_script auf diesem Node aus.
 

2. Skript-Timeout: Wie lange soll auf den Abschluss des patch_script gewartet werden?
Für die Ausführung des Skripts kann von NutzerInnen ein Timeout-Wert ausgewählt werden.
Standardmäßig ist dieser auf 15 Minuten festgelegt.→ Aufgrund eines Bugs ist der Timeout-Wert in Versionen vor PowerFlex 3.6 auf 15 Minuten hartcodiert.
Die gesamte Ausführung schlägt fehl und wird angehalten, sobald der Timeout-Wert für das Skript erreicht wurde.

3. Verifizierungsskript: Soll das verification_script nach dem patch_script ausgeführt werden?
3.1 Ausführen: Das patch_script wird ausgeführt und sobald es abgeschlossen ist, wird das verification_script ausgeführt, abhängig davon, ob nach der Ausführung des patch_script ein Neustart stattfindet oder nicht (Abschnitt 4).
3.2 Nicht ausführen: Das patch_script wird ausgeführt und sobald es beendet ist, wird die gesamte Ausführung angehalten und als erfolgreich beendet.
 

4. Aktion nach Skriptausführung: Soll der Node nach der Ausführung des patch_script neu gestartet werden?
4.1 Neustart: Nachdem das patch_script fertig ausgeführt und mit Code 0 (Null) beendet wurde, wird der Node neu gestartet und angehalten oder fortgesetzt, je nachdem, ob das verification_script für die Ausführung ausgewählt wurde oder nicht (Abschnitt 3).
Wenn sich der Gateway auf einem Node befindet, der neu gestartet wird, wird der Gateway nicht neu gestartet. Der Vorgang ist erfolgreich und ein Pop-up-Fenster wird angezeigt, mit dem Hinweis, dass der Gateway manuell neu gestartet werden muss.
4.2 Kein Neustart: Nachdem das patch_script fertig ausgeführt und mit Code 0 (Null) beendet wurde, wird der Node nicht neu gestartet und angehalten oder fortgesetzt, abhängig davon, ob das verification_script für die Ausführung ausgewählt wurde oder nicht (Abschnitt 3).
 


Skript auf Hosts ausführen:
Klicken Sie auf „Skript auf Hosts ausführen“ -->Die Validierungsphase startet.
In dieser Phase wird eine Anfrage an alle LIAs des Node gesendet, um das Vorhandensein der patch_script- und verification_script-Dateien (falls ausgewählt) unter /opt/emc/scaleio/lia/bin/zu überprüfen.
Die Codelogik wählt eine zufällige Liste an Nodes für die Ausführung aus (gemäß den genannten Bedingungen).
 


Ausführungsphase starten:
Klicken Sie auf die Schaltfläche „Ausführungsphase starten“.
1. Der Gateway führt die folgenden Überprüfungen durch:

a. Überprüft, dass keine fehlgeschlagene Kapazität vorhanden ist
b. Überprüft die gültige Reservekapazität
c. Überprüft den gültigen Clusterstatus
d. Überprüft, dass sich kein anderer SDS im Wartungsmodus befindet

2. Versetzen Sie den SDS in den Wartungsmodus.
3. Führen Sie das patch_script aus. Nach einer erfolgreichen Ausführung wird die Datei gelöscht und eine Sicherungsdatei davon im selben Verzeichnis erstellt.
Der Name lautet backup_patch_script.
4. Starten Sie den Host neu (falls ausgewählt)
5. Führen Sie das verification_script aus (falls ausgewählt). Nach einer erfolgreichen Ausführung wird die Datei gelöscht und eine Sicherungsdatei davon im selben Verzeichnis mit dem Namen backup_verification_script erstellt.
6. Beenden Sie den Wartungsmodus des SDS.
7. Der Vorgang wurde erfolgreich abgeschlossen.


 

REST API – Nach PFMP (PowerFlex 4.x)

• Führen Sie ein Patchskript auf allen oder einigen System-Nodes mit optionalem Neustart und optionalem Verifizierungsskript aus. Der Vorgang weist ein gewisses Maß an Parallelität auf.
• Die Skriptdateien sollten im Ordner des Node gespeichert werden: /opt/emc/scaleio/lia/bin. Alternativ können sie vom GW auf den Node hochgeladen werden. Die Skripte können entweder aus dem lokalen Ordner des Gateway entnommen oder von einer HTTP- oder HTTPS-Freigabe heruntergeladen werden.
• Es kann eine Liste der „SdsIds“ und/oder „mdmIds“ angegeben werden, um explizit die Nodes auszuwählen, auf denen die Skripte ausgeführt werden sollen.
• Die Dateinamen sind hartcodiert und können nicht geändert werden: patch_script und verification_script.

REST-Befehl

• /im/types/Configuration/actions/liaRunOsPatching

Erforderliche Parameter

• Einer der folgenden Parameter ist obligatorisch: pdIds/fsIds/sdsIds/mdmIds / executeOnAllSdss / executeOnAllMdms
  • pdIds  : Ausführung auf allen Nodes, die Teil der folgenden Schutzdomains (PD-IDs) sind; im Dezimalformat.
  • fsIds  : Ausführung auf allen Nodes, die Teil der folgenden Fehlergruppen (FS-IDs) sind; im Dezimalformat
  • sdsIds  : Ausführung auf allen SDS, die nach IDs aufgelistet sind; im Dezimalformat
  • mdmIds  : Ausführung auf allen MDMs, die nach IDs aufgelistet sind; im Dezimalformat
  • executeOnAllSdss  : Ausführung auf allen SDS (true/false)
  • executeOnAllMdms  : Ausführung auf allen MDMs (true/false)

Optionale Parameter

• isRebootRequired : gibt an, ob nach dem Ausführen des Patchskript jeder Node neu gestartet werden soll (Werte: true/false)
• isVerificationScriptRequired : gibt an, ob das Verifizierungsskript auf jedem Node ausgeführt werden soll (Werte: true/false)
• isRunningInParallelOnPds : gibt an, ob der Vorgang auf Nodes, die zu verschiedenen PDs gehören, parallel ausgeführt werden soll (Werte: true/false)
• isStopProcessingOnScriptFailure : gibt an, ob der gesamte Vorgang im Falle eines Skriptfehlers angehalten werden soll (Werte: true/false)
• TimeoutMs : gibt den Timeout-Wert für die Ausführung des Patchskripts in Millisekunden an
• isUploadFileNeeded  : gibt an, ob der GW Skripte auf die Nodes hochladen soll (Werte: true/false)

Die folgenden Felder sind relevant, wenn isUploadFileNeeded  auf „true“ festgelegt wird:

• patchScriptFilePath  : entweder der Name des lokalen Ordners oder eine http/https-URL des Patchskripts
• verificationScriptFilePath  : entweder der Name des lokalen Ordners oder eine http/https-URL des Verifizierungsskripts
• maintenanceModeType  : Wartungsmodustyp (Werte: IMM/PMM)
• verificationScriptTimeoutSec  : Timeout für das Verifizierungsskript in Sekunden
• rebootTimeoutSec  : Timeout für den Node-Neustart in Sekunden

Beachten Sie, dass Sie sich vor dem Ausführen des Befehls „liaRunOsPatching“ zunächst anmelden und die Systemkonfiguration abrufen sollten, wie im folgenden Beispiel dargestellt.
 

Befehlsbeispiel

*Die Token-Variable enthält das Keycloak-Token, das von /auth/login oder von /api/gatewayLogin zurückgegeben wurde.
**<IP-Adresse>: Die IP-Adresse eines HTTP-Servers, der die auszuführenden Skripte enthält.

Rufen Sie die JSON-Datei einer Systemkonfiguration ab, die als Payload für den Patchbefehl dient („liaPassword“ und „mdmPassword“ müssen manuell von null auf die jeweilige Zeichenfolge geändert werden).


Fügen Sie die Ausgabe dieses Befehls (mit eingegebenen Kennwörtern) in die config.json-Datei ein:

curl -s -X POST -k -H  "Content-Type: application/json" -d '{ "mdmIps":["1.2.3.4","5.6,7,8"], "mdmUser":"<mdm_username>", "mdmPassword":"<mdm_password>", "securityConfiguration":{ "allowNonSecureCommunicationWithMdm":"true", "allowNonSecureCommunicationWithLia":"true", "disableNonMgmtComponentsAuth":"false" } }' -H "Authorization: Bearer ${token}"  https://<m&o-ip-address>/im/types/Configuration/instances

Führen Sie den Patchbefehl aus:

curl -v -k -X -i POST -H "Content-Type:application/json" -H "Authorization: Bearer ${token}" 

 "https:/<m&o-ip-address>/im/types/Configuration/actions/liaRunOsPatching?executeOnAllSdss=true &isRebootRequired=true&isVerificationScriptRequired=true&patchScriptFilePath=https://<ip-address>/patch_script&verificationScriptFilePath=https://<ip-address>/verification_script&maintenanceModeType=IMM&rebootTimeoutSec=30" -d @config.json

Protokolle

Gateway:

• /opt/emc/scaleio/gateway/logs/scaleio.log
• /opt/emc/scaleio/gateway/logs/scaleio-trace.log

LIA:
/opt/emc/scaleio/lia/logs/trc.x

Tipp: Spezieller Switch, um das Skript beim Troubleshooting oder Testen auf dem Node zu behalten:

• Bearbeiten Sie die Datei: /opt/emc/scaleio/gateway/webapps/ROOT/WEB-INF/classes/gatewayInternal.properties
• Suchen Sie das Feld „ospatching.delete.scripts=false“.
• Ändern Sie das Troubleshooting auf „true“ (Standard ist „false“).