PowerFlex: descrizione della funzione Run Script on Host (nota anche come OS Patching)

Interfaccia utente - Pre-PFMP (PowerFlex 4.x)

Prerequisiti

Obbligatorio: lo script principale si trova nella directory /opt/emc/scaleio/lia/bin/ con autorizzazioni di esecuzione.

• Il nome dello script deve essere patch_script 

Opzionale: lo script di convalida si trova nella directory /opt/emc/scaleio/lia/bin/ con autorizzazioni di esecuzione.

• Il nome dello script deve essere verification_script

> La funzione è supportata solo su Linux (RHEL e SLES).
> La funzione verifica se il codice di uscita è 0 (zero) al termine dell'esecuzione.
> I codici di uscita e l'esecuzione dello script sono reperibili nei registri LIA.
> È responsabilità del cliente testare patch_script e verification_script prima di eseguire il processo tramite Gateway.
> Posizione della funzione: Maintain → System Logs & Analysis → Run Script on Hosts.

Procedura e flussi

Running script on:
1. Entire System: tutti i nodi PowerFlex.
Per impostazione predefinita, lo script viene eseguito sul primo dominio di protezione (PD) dell'host, quindi passa al secondo e così via.
Opzione In parallel on different Protection Domains disabilitata: per impostazione predefinita, la casella di controllo è deselezionata.
 
Opzione In parallel on different Protection Domains abilitata: selezionando questa opzione, patch_script viene eseguito in parallelo su tutti i PD.
I PD senza MDM sono i primi e i nodi cluster sono gli ultimi.


2. Protection Domain: uno specifico PD
I PD senza MDM sono i primi, i nodi cluster MDM sono gli ultimi.

3. Fault Set: uno specifico FS
I FS senza MDM sono i primi, i nodi cluster MDM sono gli ultimi.

4. SDS: un singolo nodo SDS


Running configuration:
1. Stop process on script failure.
1.1 Opzione Stop process on script failure abilitata: per impostazione predefinita, la casella di controllo è selezionata.
L'intero processo non riesce e si arresta in caso di uscita di patch_script (e verification_script se selezionato) con un codice diverso da 0 (zero).
 
1.2 Opzione Stop process on script failure disabilitata.
Se patch_script non riesce, l'esecuzione del nodo ha esito negativo e il sistema passa al nodo successivo ed esegue patch_script su tale nodo.
 

2. Script timeout: quanto tempo è necessario per il completamento di patch_script?
L'esecuzione dello script ha un timeout configurabile, scelto dall'utente.
Per impostazione predefinita, è configurato su 15 minuti → A causa di un bug, il timeout è hardcoded per 15 minuti nelle versioni precedenti a PowerFlex 3.6.
L'intero processo non riesce e si arresta dopo il timeout di esecuzione dello script.

3. Verification script: eseguire verification_script dopo l'esecuzione di patch_script?
3.1 Run: vengono eseguiti patch_script e, al termine, verification_script, a seconda che l'azione post-script patch_script sia stata riavviata o meno (sezione n. 4).
3.2 Do not Run: viene eseguito patch_script e, al termine, l'intero processo si arresta e viene completato.
 

4. Post script action: riavviare il nodo dopo l'esecuzione di patch_script?
4.1 Reboot: al termine dell'esecuzione di patch_script con codice di uscita 0 (zero), il nodo si riavvia e si arresta o continua a seconda che sia stata scelta o meno l'esecuzione di verification_script (sezione n. 3).
Se Gateway è su un nodo da riavviare, non viene riavviato, l'operazione ha esito positivo e viene visualizzata una finestra pop-up che segnala di riavviarlo manualmente.
4.2 Do not reboot: al termine dell'esecuzione di patch_script con codice di uscita 0 (zero), il nodo non si riavvia e si arresta o continua a seconda che sia stata scelta o meno l'esecuzione di verification_script (sezione n. 3).
 


Run Script on Hosts:
Premere "Run Script on Hosts" --> Viene avviata la fase di convalida.
Questa fase invia una richiesta a ogni LIA del nodo per verificare l'esistenza dei file patch_script e verification_script (se selezionati) in /opt/emc/scaleio/lia/bin/.
La logica del codice seleziona un elenco casuale di nodi per l'esecuzione (in base alle condizioni menzionate).
 


Start execution phase:
Premere il pulsante "Start execution phase".
1. Gateway effettua le seguenti verifiche:

a. Controllare che non vi siano capacità con errori.
b. Controllare la capacità di riserva valida.
c. Controllare lo stato del cluster valido.
d. Controllare che nessun altro SDS sia in modalità di manutenzione.

2. Impostare l'SDS in modalità di manutenzione.
3. Eseguire patch_script. Al termine dell'esecuzione, il file viene eliminato e viene creato un file di backup nella stessa directory
con il nome backup_patch_script
4. Riavviare l'host (se selezionato)
5. Eseguire verification_script (se selezionato). Al termine dell'esecuzione, il file viene eliminato e viene creato un file di backup nella stessa directory con il nome backup_verification_script
6. Rimuovere l'SDS dalla modalità di manutenzione.
7. L'operazione viene completata.


 

RESTAPI - Post-PFMP (PowerFlex 4.x)

• Eseguire uno script di patch su tutti o alcuni nodi di sistema con riavvio e script di verifica opzionali. L'operazione ha un certo livello di parallelismo.
• I file di script devono essere archiviati nella cartella del nodo: /opt/emc/scaleio/lia/bin. In alternativa, possono essere sottoposti a upload da GW sul nodo. Gli script possono essere ricavati da una cartella locale di GW o scaricati dalla condivisione HTTP/HTTPS.
• È possibile fornire un elenco di SdsIds e/o mdmIds per scegliere in modo esplicito i nodi su cui eseguirli.
• I nomi file sono hardcoded e non possono essere modificati: patch_script e verification_script

Comando REST

• /im/types/Configuration/actions/liaRunOsPatching

Parametri obbligatori

• Uno dei seguenti parametri è obbligatorio: pdIds/fsIds/sdsIds/mdmIds / executeOnAllSdss / executeOnAllMdms
  • pdIds  : esecuzione su tutti i nodi che fanno parte dei seguenti domini di protezione (ID PD), in formato decimale
  • fsIds  : esecuzione su tutti i nodi che fanno parte dei seguenti Fault Set (ID FS), in formato decimale
  • sdsIds  : esecuzione su tutti gli SDS elencati per ID, in formato decimale
  • mdmIds  : esecuzione su tutti gli MDM elencati per ID, in formato decimale
  • executeOnAllSdss  : esecuzione su tutti gli SDS (true/false)
  • executeOnAllMdms  : esecuzione su tutti gli MDM (true/false)

Parametri opzionali

• isRebootRequired : in caso di riavvio di ogni nodo dopo l'esecuzione dello script di patch (valori: true/false)
• isVerificationScriptRequired : in caso di esecuzione dello script di verifica su ciascun nodo (valori: true/false)
• isRunningInParallelOnPds : in caso di esecuzione dell'operazione in modo parallelo sui nodi che appartengono a PD diversi (valori: true/false)
• isStopProcessingOnScriptFailure : in caso di arresto dell'intera operazione per un errore dello script (valori: true/false)
• TimeoutMs : timeout per l'esecuzione dello script di patch in millisecondi
• isUploadFileNeeded  : in caso GW esegua l'upload degli script sui nodi (valori: true/false)

I seguenti campi sono pertinenti se il valore di isUploadFileNeeded  è "true":

• patchScriptFilePath  : il nome della cartella locale o un URL HTTP/HTTPS dello script di patch
• verificationScriptFilePath  : il nome della cartella locale o un URL HTTP/HTTPS dello script di verifica
• maintenanceModeType  : tipo di modalità di manutenzione (valori: IMM/PMM)
• verificationScriptTimeoutSec  : timeout dello script di verifica in secondi
• rebootTimeoutSec  : timeout di riavvio dei nodi in secondi

Tenere presente che, prima di eseguire il comando liaRunOsPatching, è necessario effettuare l'accesso e ottenere la configurazione del sistema. Vedere l'esempio riportato di seguito.
 

Esempio di comando

La variabile *token contiene il token Keycloak restituito da /auth/login o da /api/gatewayLogin.
**<ip-address>: indirizzo IP di un server HTTP contenente gli script da eseguire

Ottenere il file JSON di una configurazione di sistema, che costituisce il payload del comando di patch (è necessario sostituire manualmente liaPassword e mdmPassword da null in una stringa).


Inserire l'output di questo comando (con password fisse) nel file config.json:

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

Eseguire il comando di patch:

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

Registri

Gateway:

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

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

Suggerimento: switch speciale per mantenere lo script nel nodo durante la risoluzione dei problemi o i test:

• Modificare il file /opt/emc/scaleio/gateway/webapps/ROOT/WEB-INF/classes/gatewayInternal.properties
• Individuare il campo "ospatching.delete.scripts=false"
• Impostarlo su true per la risoluzione dei problemi (il valore predefinito è false)