PowerFlex: Explicação do recurso Executar script no host (também conhecido como Aplicação de patch do sistema operacional)
Summary: O recurso é usado para executar scripts fornecidos pelo usuário em servidores que hospedam componentes MDM ou SDS. O recurso pode ser usado para qualquer finalidade externa ao sistema PowerFlex, como executar um conjunto de comandos do shell do Linux, aplicar patches em um sistema operacional e muito mais. ...
Instructions
Interface do usuário — Pré-PFMP (PowerFlex 4.x)
Pré-requisitos
Obrigatório — o script principal está localizado no diretório /opt/emc/scaleio/lia/bin/ com permissões de execução.
- O nome do script deve ser patch_script
Opcional — o script de validação está localizado no diretório /opt/emc/scaleio/lia/bin/ com permissões de execução.
- O nome do script deve ser verification_script
> O recurso é compatível apenas com Linux (RHEL e SLES).
> O recurso verifica se o código de saída é 0 (zero) no final da execução.
> Os códigos de saída e a execução do script podem ser encontrados nos logs do LIA.
> É responsabilidade do cliente testar o patch_script e o verification_script antes de executar o processo usando o Gateway.
> Localização do recurso: Maintain → System Logs and Analysis → Run Script on Hosts.
Etapas e fluxos
Executar script em:
1. Todo o sistema — Todos os nós do PowerFlex
Por padrão, o script é executado no Domínio de Proteção (PD) do primeiro host, depois passa para o segundo e assim por diante.
In parallel on different Protection Domains desabilitado — por padrão, a caixa de seleção é desmarcada.
In parallel on different Protection Domains habilitado: ao selecionar essa opção, o patch_script será executado em paralelo em todos os PDs.
PDs que não têm MDMs são os primeiros e os nós de cluster são os últimos.
2. Domínio de proteção — um PD específico
O PD que não tem MDMs é o primeiro e os nós de cluster MDM são os últimos.
3. Conjunto de falhas — um FS específico.
Os FSs que não têm MDMs são os primeiros e os nós de cluster MDM são os últimos.
4. SDS — um único nó SDS
Configuração da execução:
1. Parar o processo em caso de falha do script.
1.1 Stop process on script failure habilitado — por padrão, a caixa de seleção é marcada.
Toda a execução falhará e parará assim que o patch_script (e o verification_script, se selecionado) sair com qualquer outro código que não seja 0 (Zero).
1.2 Stop process on script failure desabilitado.
Se o patch_script falhar, a execução desse nó falhará e o sistema passará para o próximo nó e executará o patch_script nesse nó.
2. Tempo de espera excedido do script — Quanto tempo esperar até a conclusão do patch_script?
A execução do script tem um tempo de espera excedido configurável, escolhido pelo usuário.
Por padrão, é configurado como 15 minutos → devido a um bug, o tempo de espera excedido é codificado como 15 minutos nas versões anteriores ao PowerFlex 3.6.
Toda a execução falhará e parará assim que a execução do script atingir o tempo de espera excedido.
3. Verification script - Do you want to run the verification_script after the patch_script was run?
3.1 Run — o patch_script será executado, seguido pela execução do verification_script, dependendo se a pós-ação do patch_script foi reiniciar ou não (seção nº 4).
3.2 Do not Run — o patch_script será executado e, em seguida, toda a execução parará e concluirá como bem-sucedida.
4. Post script action - Do you want to reboot the node after the patch_script is ran?
4.1 Reboot — depois que o patch_script terminar de ser executado e sair com o código 0 (Zero), o nó reinicializará e parará ou continuará, dependendo se o verification_script foi escolhido para executar ou não (seção nº 3).
Se o gateway estiver em um nó a ser reinicializado, ele não será reinicializado, a operação será bem-sucedida e um pop-up que nos lembra de reinicializá-lo manualmente será exibido.
4.2 Do not reboot - depois que o patch_script terminar de ser executado e sair com o código 0 (Zero), o nó não reinicializará e parará ou continuará, dependendo se o verification_script foi escolhido para executar ou não (seção nº 3).
Executar script nos hosts:
Pressione “Run Script on Hosts” —> A fase Validar começa.
Essa fase envia uma solicitação a cada LIA do nó para verificar a existência dos arquivos patch_script e verification_script (se selecionado) em /opt/emc/scaleio/lia/bin/.
A lógica de código seleciona uma lista aleatória de nós para executar (de acordo com as condições mencionadas).
Iniciar fase de execução:
Pressione o botão “Start execution phase”.
1. O gateway faz as seguintes verificações:
a. Verifique se não há nenhuma capacidade com falha.
b. Verifique a capacidade sobressalente válida.
c. Verifique o estado válido do cluster.
d. Verifique se nenhum outro SDS está no modo de manutenção.
2. Coloque o SDS no modo de manutenção.
3. Execute o patch_script — após uma execução bem-sucedida, o arquivo é excluído e um arquivo de backup dele é criado no mesmo diretório.
Com o nome backup_patch_script
4. Reinicialize o host (se selecionado)
5. Execute o verification_script (se selecionado) — após uma execução bem-sucedida, o arquivo é excluído e um arquivo de backup dele é criado no mesmo diretório com o nome backup_verification_script.
6. Retire o SDS do modo de manutenção.
7. Operação concluída com sucesso.
RESTAPI — Pós-PFMP (PowerFlex 4.x)
- Execute um script de patch em todos ou em alguns nós do sistema, com uma reinicialização opcional e um script de verificação opcional. A operação tem um certo nível de paralelismo.
- Os arquivos de script devem ser armazenados na pasta do nó: /opt/emc/scaleio/lia/bin Como alternativa, podem ser carregados pelo GW no nó. Os scripts podem ser obtidos de uma pasta local do GW ou baixados do compartilhamento HTTP/HTTPS.
- Uma lista de SdsIds e/ou mdmIds pode ser fornecida para escolher explicitamente os nós a serem executados.
- Os nomes dos arquivos são codificados e não podem ser alterados: patch_script e verification_script
Comando REST
- /im/types/Configuration/actions/liaRunOsPatching
Parâmetros obrigatórios
- Um dos seguintes parâmetros é obrigatório: pdIds/fsIds/sdsIds/mdmIds / executeOnAllSdss / executeOnAllMdms
pdIds- execute em todos os nós que fazem parte dos seguintes domínios de proteção (Ids de PD), em formato decimalfsIds- execute em todos os nós que fazem parte dos seguintes conjuntos de falhas (Ids de FS), em formato decimalsdsIds- execute em todos os SDSs listados por Ids, em formato decimalmdmIds- execute em todos os MDMs listados por Ids, em formato decimalexecuteOnAllSdss- execute em todos os SDSs (true/false)executeOnAllMdms- execute em todos os MDMs (true/false)
Parâmetros opcionais
isRebootRequired- se cada nó deve ser reinicializado após a execução do script de patch (valores: true/false)isVerificationScriptRequired- se o script de verificação deve ser executado em cada nó (valores: true/false)isRunningInParallelOnPds- se a operação deve ser executada de forma paralela nos nós que pertencem a PDs diferentes (valores: true/false)isStopProcessingOnScriptFailure- se toda a operação deve parar em caso de falha de script (valores: true/false)TimeoutMs- tempo de espera excedido para executar o script de patch em milissegundosisUploadFileNeeded- se o GW deve carregar scripts para os nós (valores: true/false)
Os campos a seguir são relevantes quando isUploadFileNeeded for 'true':
patchScriptFilePath- o nome da pasta local ou uma URL http/https do script de patchverificationScriptFilePath- o nome da pasta local ou uma URL http/https do script de verificaçãomaintenanceModeType- Tipo de Modo de manutenção (valores: IMM/PMM)verificationScriptTimeoutSec- tempo de espera excedido do script de verificação em segundosrebootTimeoutSec- tempo de espera excedido da reinicialização do nó em segundos
Observe que antes de executar o comando liaRunOsPatching, você deve primeiro fazer login e obter a configuração do sistema. Consulte o exemplo abaixo.
Exemplo de comando
*variável de token contém o token Keycloak que foi retornado de /auth/login ou de /api/gatewayLogin.
**<ip-address> — Endereço IP de um servidor http que contém os scripts a serem executados
Obtenha o json de uma configuração do sistema, que será o payload do comando de patch (deve substituir liaPassword e mdmPassword manualmente de null para alguma string).
Insira a saída desse comando (com senhas fixas) no arquivo config.json file:
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
Execute o comando de 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
Additional Information
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
Dica — Opção especial para manter o script no nó durante a solução de problemas ou o teste:
- Edite o arquivo /opt/emc/scaleio/gateway/webapps/ROOT/WEB-INF/classes/gatewayInternal.properties
- Localize o campo “ospatching.delete.scripts=false”
- Altere para true para a solução de problemas (o padrão é false)