PowerFlex: Explicación de la característica “Ejecutar script en el host” (también conocido como aplicación de parche del SO)

IU: anterior a PFMP (PowerFlex 4.x)

Requisitos previos

Obligatorio: el script principal se encuentra en el directorio /opt/emc/scaleio/lia/bin/ con permisos de ejecución.

• El nombre del script debe ser patch_script 

Opcional: el script de validación se encuentra en el directorio /opt/emc/scaleio/lia/bin/ con permisos de ejecución.

• El nombre del script debe ser verification_script

> La función solo es compatible con Linux (RHEL y SLES).
> La función comprueba si el código de salida es 0 (cero) al final de la ejecución.
> Los códigos de salida y la ejecución del script se pueden encontrar en los registros de LIA.
> Es responsabilidad del cliente probar los scripts patch_script y verification_script antes de ejecutar el proceso mediante el gateway.
> Ubicación de la función: Maintain → System Logs and Analysis → Run Script on Hosts.

Pasos y flujos

Ejecución del script en:
1. Todo el sistema: todos los nodos PowerFlex
De manera predeterminada, el script se ejecuta en el dominio de protección (PD) del primer host y, luego, pasa al segundo, y así sucesivamente.
Opción “In parallel on different Protection Domains” deshabilitada: la casilla de verificación está desmarcada de manera predeterminada.
 
Opción “In parallel on different Protection Domains” habilitada: tras seleccionar esta opción, el script patch_script se ejecutará en paralelo en todos los PD.
Los PD que no tienen MDM son los primeros y los nodos de clúster son los últimos.


2. Dominio de protección: un PD específico
Los PD que no tienen MDM son los primeros y los nodos del clúster de MDM son los últimos.

3. Conjunto de fallas: un FS específico.
Los FS que no tienen MDM son los primeros y los nodos de clúster de MDM son los últimos.

4. SDS: un nodo de SDS único


Ejecución de configuración:
1. Detenga el proceso en caso de falla del script.
1.1 Opción “Stop process on script failure” habilitada: de manera predeterminada, la casilla de verificación está marcada.
Toda la ejecución fallará y se detendrá una vez que patch_script (y verification_script si se selecciona) finalice con cualquier código que no sea 0 (cero).
 
1.2 Opción “Stop process on script failure” deshabilitada.
En caso de que patch_script falle, la ejecución de ese nodo fallará, y el sistema pasará al nodo siguiente y ejecutará patch_script en ese nodo.
 

2. Se agota el tiempo de espera del script: ¿cuánto tiempo hay que esperar para que finalice patch_script?
La ejecución del script tiene un tiempo de espera configurable, el cual es elegido por el usuario.
De manera predeterminada, está configurado en 15 minutos → Debido a un error, el tiempo de espera está codificado de forma fija en 15 minutos en versiones anteriores a PowerFlex 3.6.
Toda la ejecución fallará y se detendrá una vez que se agote el tiempo de espera de la ejecución del script.

3. Script de verificación: ¿desea ejecutar verification_script después de ejecutar patch_script?
3.1 Ejecutar: patch_script se ejecutará y una vez que haya terminado, verification_script se ejecutará, dependiendo de si la acción posterior a patch_script fue reiniciar o no (sección 4).
3.2 No ejecutar: patch_script se ejecutará y, una vez que haya terminado, toda la ejecución se detendrá y finalizará con éxito.
 

4. Acción posterior al script: ¿desea reiniciar el nodo después de ejecutar patch_script?
4.1 Reiniciar: después de que patch_script termine de ejecutarse y finalice con el código 0 (cero), el nodo se reiniciará y se detendrá o continuará dependiendo de si se eligió ejecutar verification_script o no (sección 3).
Si el gateway está en un nodo que se a reiniciar, este no se reiniciará, la operación se realiza correctamente y se mostrará una ventana emergente que nos recuerda que debemos reiniciarla de forma manual.
4.2 No reiniciar: después de que patch_script termine de ejecutarse y finalice con el código 0 (cero), el nodo no se reiniciará y se detendrá o continuará dependiendo de si se eligió ejecutar verification_script o no (sección 3).
 


Ejecute el script en los hosts:
Presione “Run Script on Hosts” --> Se inicia la fase de validación.
En esta fase, se envía una solicitud a cada uno de los LIA del nodo para verificar la existencia de los archivos patch_script y verification_script (si se seleccionan) en /opt/emc/scaleio/lia/bin/.
La lógica del código selecciona una lista aleatoria de nodos en los que se ejecutará (de acuerdo con las condiciones mencionadas).
 


Inicie la fase de ejecución:
Presione el botón “Start execution phase”.
1. El gateway realiza las siguientes verificaciones:

a. Verificar que no haya capacidad con fallas.
b. Verificar la capacidad restante válida.
c. Verificar el estado válido del clúster.
d. Verificar que ningún otro SDS esté en modo de mantenimiento.

2. Coloque el SDS en modo de mantenimiento.
3. Ejecute patch_script: después de una ejecución correcta, el archivo se elimina y se crea un archivo de respaldo en el mismo directorio
con el nombre backup_patch_script
4. Reinicie el host (si está seleccionado)
5. Ejecute verification_script (si se selecciona): después de una ejecución correcta, el archivo se elimina y se crea un archivo de respaldo en el mismo directorio con el nombre backup_verification_script.
6. Saque el SDS del modo de mantenimiento.
7. Operación completada con éxito.


 

API REST: después de PFMP (PowerFlex 4.x)

• Ejecute un script de parche en todos o algunos de los nodos del sistema, con un reinicio opcional y un script de verificación opcional. La operación tiene cierto nivel de paralelismo.
• Los archivos de script se deben almacenar en la carpeta del nodo: /opt/emc/scaleio/lia/bin. Como alternativa, el gateway puede cargarlos en el nodo. Los scripts se pueden tomar desde una carpeta local del gateway o descargarse desde un recurso compartido HTTP/HTTPS.
• Se puede proporcionar una lista de SdsIds o mdmIds para elegir explícitamente los nodos en los cuales ejecutar.
• Los nombres de archivo están codificados de forma fija y no se pueden cambiar: patch_script y verification_script

Comando REST

• /im/types/Configuration/actions/liaRunOsPatching

Parámetros obligatorios

• Cualquiera de los siguientes parámetros es obligatorio: pdIds/fsIds/sdsIds/mdmIds / executeOnAllSdss / executeOnAllMdms
  • pdIds  - ejecutar en todos los nodos que forman parte de los siguientes dominios de protección (ID de PD), en formato decimal
  • fsIds  - ejecutar en todos los nodos que forman parte de los siguientes conjuntos de fallas (ID de FS), en formato decimal
  • sdsIds  - ejecutar en todos los SDS enumerados por ID, en formato decimal
  • mdmIds  - ejecutar en todos los MDM enumerados por ID, en formato decimal
  • executeOnAllSdss  - ejecutar en todos los SDS (verdadero/falso)
  • executeOnAllMdms  - ejecutar en todos los MDM (verdadero/falso)

Parámetros opcionales

• isRebootRequired - ¿Debería reiniciarse cada nodo después de ejecutar el script de parches? (valores: true/false)
• isVerificationScriptRequired - ¿Debería ejecutarse el script de verificación en cada nodo? (valores: true/false)
• isRunningInParallelOnPds - ¿Debería ejecutarse la operación de forma paralela en nodos que pertenecen a diferentes PD? (valores: true/false)
• isStopProcessingOnScriptFailure - ¿Debería detenerse toda la operación en caso de una falla del script? (valores: true/false)
• TimeoutMs - Tiempo de espera agotado para ejecutar el script de parche en milisegundos
• isUploadFileNeeded  - ¿Debería el gateway cargar scripts en los nodos? (valores: true/false)

Los siguientes campos son relevantes cuando isUploadFileNeeded  es “true”:

• patchScriptFilePath  - Ya sea el nombre de la carpeta local o una URL http/https del script del parche
• verificationScriptFilePath  - Ya sea el nombre de la carpeta local o una URL http/https del script de verificación
• maintenanceModeType  - Tipo de modo de mantenimiento (valores: IMM/PMM)
• verificationScriptTimeoutSec  - Tiempo de espera agotado del script de verificación en segundos
• rebootTimeoutSec  - Tiempo de espera agotado de reinicio del nodo en segundos

Tenga en cuenta que, antes de ejecutar el comando liaRunOsPatching, primero debe iniciar sesión y obtener la configuración del sistema; consulte el siguiente ejemplo.
 

Ejemplo de comando

* El token contiene el token Keycloak que se devolvió de /auth/login o de /api/gatewayLogin.
**<ip-address>: dirección IP de un servidor http que contiene los scripts que se ejecutarán

Obtenga el json de una configuración del sistema, el cual será la carga útil del comando de parche (debe reemplazar liaPassword y mdmPassword manualmente de null a alguna cadena).


Inserte la salida de este comando (con contraseñas fijas) en el archivo 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

Ejecute el comando de parche:

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

Registros

Gateway:

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

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

Consejo: realiza una conmutación especial para mantener el script en el nodo cuando se realiza una solución de problemas o se realizan pruebas:

• Edite el archivo /opt/emc/scaleio/gateway/webapps/ROOT/WEB-INF/classes/gatewayInternal.properties
• Busque el campo “ospatching.delete.scripts=false”
• Cambie a true para la solución de problemas (el valor predeterminado es false)