Slurm guia para o modo de fila múltipla

• Um nó em um estado POWER_SAVING aparece com um sufixo ~ (por exemplo, idle~) em sinfo. Nesse estado, nenhuma EC2 instância está apoiando o nó. No entanto, Slurm ainda pode alocar trabalhos para o nó.

• Um nó em transição para um estado POWER_UP aparece com um sufixo # (por exemplo, idle#) em sinfo. Um nó faz a transição automática para um POWER_UP estado, quando Slurm aloca um trabalho para um nó em um POWER_SAVING estado.

  Como alternativa, você pode fazer manualmente a transição dos nós para o estado POWER_UP como usuário raiz su com o comando:

  $ scontrol update nodename=nodename state=power_up

  Nesse estágio, o ResumeProgram é invocado, as EC2 instâncias são iniciadas e configuradas e o nó faz a transição para o POWER_UP estado.

• Um nó atualmente disponível para uso aparece sem um sufixo (por exemplo idle) em sinfo. Depois que o nó é configurado e se une ao cluster, ele fica disponível para executar trabalhos. Nesse estágio, o nó está configurado corretamente e pronto para uso.

  Como regra geral, recomendamos que o número de EC2 instâncias da Amazon seja igual ao número de nós disponíveis. Na maioria dos casos, os nós estáticos ficam disponíveis após a criação do cluster.

• Um nó em transição para um estado POWER_DOWN aparece com um sufixo % (por exemplo, idle%) em sinfo. Os nós dinâmicos entram automaticamente no estado POWER_DOWN depois do ScaledownIdletime. Por outro lado, os nós estáticos na maioria dos casos não são desligados. No entanto, você pode colocar os nós no estado POWER_DOWN manualmente como usuário raiz su com o comando:

  $ scontrol update nodename=nodename state=down reason="manual draining"

  Nesse estado, as instâncias associadas a um nó são encerradas e o nó volta ao estado POWER_SAVING e fica disponível para uso após o ScaledownIdletime.

  A ScaledownIdletimeconfiguração é salva no Slurm SuspendTimeoutdefinição de configuração.

• Um nó que está off-line aparece com um sufixo * (por exemplo, down*) em sinfo. Um nó fica off-line se o Slurm o controlador não pode entrar em contato com o nó ou se os nós estáticos estiverem desativados e as instâncias de apoio forem encerradas.

• Um tipo de instância (por exemplo, c5.xlarge)

• Um tipo de nó (que pode ser dynamic ou static.)

• UP: indica que a partição está em um estado ativo. Esse é o valor padrão de uma partição. Nesse estado, todos os nós da partição ficam ativos e disponíveis para uso.

• INACTIVE: indica que a partição está em um estado inativo. Nesse estado, todas as instâncias de backup dos nós de uma partição inativa são encerradas. Novas instâncias não são iniciadas para nós em uma partição inativa.

• Interromper a frota de computação - Quando o comando a seguir é executado, todas as partições passam para o INACTIVE estado e AWS ParallelCluster os processos mantêm as partições no estado. INACTIVE

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status STOP_REQUESTED

• Iniciando a frota de computação - Quando o comando a seguir é executado, todas as partições inicialmente passam para o estado UP. No entanto, AWS ParallelCluster os processos não mantêm a partição em um UP estado. Você precisa alterar os estados das partições manualmente. Todos os nós estáticos ficam disponíveis após alguns minutos. Observe que definir uma partição como UP não ativa nenhuma capacidade dinâmica.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status START_REQUESTED

• STOP_REQUESTED: a solicitação de interrupção da frota de computação é enviada ao cluster.

• STOPPING: no momento, o processo pcluster está interrompendo a frota de computação.

• STOPPED: o processo pcluster finalizou o processo de interrupção, todas as partições estão em estado INACTIVE e todas as instâncias de computação foram encerradas.

• START_REQUESTED: a solicitação de inicialização da frota de computação é enviada ao cluster.

• STARTING: o processo pcluster está iniciando o cluster no momento.

• RUNNING: o processo pcluster finalizou o processo inicial, todas as partições estão no estado UP e os nós estáticos ficam disponíveis após alguns minutos.

• PROTECTED: esse status indica que algumas partições têm falhas de bootstrap consistentes. As partições afetadas estão inativas. Investigue o problema e, em seguida, execute update-compute-fleet para reativar a frota.

• Ative os nós dinâmicos no estado POWER_SAVING

  Execute o comando como usuário raiz su:

  $ scontrol update nodename=nodename state=power_up

  Você também pode enviar um sleep 1 trabalho de espaço reservado solicitando um certo número de nós e, em seguida, confiar em Slurm para alimentar o número necessário de nós.

• Desligue os nós dinâmicos antes de ScaledownIdletime

  Recomendamos que você defina nós dinâmicos para DOWN como usuário raiz su com o comando:

  $ scontrol update nodename=nodename state=down reason="manually draining"

  AWS ParallelCluster encerra e redefine automaticamente os nós dinâmicos abatidos.

  Em geral, não recomendamos definir os nós para POWER_DOWN diretamente com o comando scontrol update nodename=nodename state=power_down. Isso porque AWS ParallelCluster gerencia automaticamente o processo de desligamento.

• Desativar uma fila (partição) ou interromper todos os nós estáticos em uma partição específica

  Defina uma fila específica para INACTIVE como usuário raiz su com o comando:

  $ scontrol update partition=queuename state=inactive

  Isso encerra todas as instâncias de backup de nós na partição.

• Ativar uma fila (partição)

  Defina uma fila específica para UP como usuário raiz su com o comando:

  $ scontrol update partition=queuename state=up

Veja a seguir o exemplo do fluxo de trabalho de escalabilidade normal:

• O programador recebe um trabalho que requer dois nós.

• O programador faz a transição de dois nós para um estado POWER_UP e chama ResumeProgram com os nomes dos nós (por exemplo, queue1-dy-spotcompute1-[1-2]).

• ResumePrograminicia duas EC2 instâncias da Amazon e atribui os endereços IP e nomes de host privados dequeue1-dy-spotcompute1-[1-2], aguardando ResumeTimeout (o período padrão é de 30 minutos) antes de redefinir os nós.

• As instâncias são configuradas e se unem ao cluster. Um trabalho começa a ser executado nas instâncias.

• O trabalho é concluído e para de ser executado.

• Depois de decorrido o SuspendTime configurado (que está definido como ScaledownIdletime), o programador define as instâncias para o estado POWER_SAVING. Em seguida, o programador define queue1-dy-spotcompute1-[1-2] para o estado POWER_DOWN e chama SuspendProgram com os nomes dos nós.

• SuspendProgram é chamado para dois nós. Os nós permanecem no estado POWER_DOWN, por exemplo, permanecendo idle% por um SuspendTimeout (o período padrão é 120 segundos (2 minutos)). Depois de clustermgtd detectar que os nós estão sendo desligados, ele encerra as instâncias de backup. Em seguida, ele passa queue1-dy-spotcompute1-[1-2] para o estado ocioso e redefine o endereço IP privado e o nome do host para que esteja pronto para ser ativado em trabalhos futuros.

Se algo der errado e uma instância de um determinado nó não puder ser iniciada por algum motivo, acontece o seguinte:

• O programador recebe um trabalho que requer dois nós.

• O programador faz a transição de dois nós de expansão na nuvem para o estado POWER_UP e chama ResumeProgram com os nomes dos nós (por exemplo queue1-dy-spotcompute1-[1-2]).

• ResumePrograminicia somente uma (1) EC2 instância da Amazon e configuraqueue1-dy-spotcompute1-1, com uma (1) instânciaqueue1-dy-spotcompute1-2, falhando ao iniciar.

• queue1-dy-spotcompute1-1 não é afetado e fica on-line depois de chegar ao estado POWER_UP.

• queue1-dy-spotcompute1-2faz a transição para o POWER_DOWN estado, e o trabalho é enfileirado automaticamente porque Slurm detecta uma falha no nó.

• queue1-dy-spotcompute1-2 fica disponível após SuspendTimeout (o padrão é 120 segundos (2 minutos)). Enquanto isso, o trabalho é recolocado na fila e pode começar a ser executado em outro nó.

• O processo acima se repete até que o trabalho possa ser executado em um nó disponível sem que ocorra uma falha.

Há dois parâmetros de temporização que podem ser ajustados, se necessário:

• ResumeTimeout(o padrão é 30 minutos): ResumeTimeout controla a hora Slurm espera antes de fazer a transição do nó para o estado inativo.

  • Pode ser útil estender ResumeTimeout se o processo de pré/pós-instalação demorar tanto assim.

  • ResumeTimeout também é o tempo máximo que AWS ParallelCluster espera antes de substituir ou redefinir um nó se houver algum problema. Os nós de computação terminam automaticamente se ocorrer algum erro durante a inicialização ou a configuração. AWS ParallelCluster os processos substituem um nó após a detecção de uma instância encerrada.

• SuspendTimeout (o padrão é 120 segundos (2 minutos)): SuspendTimeout controla a rapidez com que os nós são colocados de volta no sistema e que ficam prontos para uso novamente.

  • Um menor SuspendTimeout significa que os nós são redefinidos mais rapidamente e Slurm pode tentar iniciar instâncias com mais frequência.

  • Um SuspendTimeout mais longo significa que os nós com falha são reinicializados mais lentamente. Enquanto isso, Slurm tenta usar outros nós. Se SuspendTimeout for mais do que alguns minutos, Slurm tenta percorrer todos os nós do sistema. Um mais longo SuspendTimeout pode ser benéfico para sistemas de grande escala (mais de 1.000 nós) para reduzir o estresse em Slurm quando tenta reenfileirar trabalhos que falham com frequência.

  • Observe que SuspendTimeout isso não se refere ao tempo de AWS ParallelCluster espera para encerrar uma instância de apoio para um nó. As instâncias de backup para nós de POWER_DOWN são encerradas imediatamente. O processo de encerramento geralmente é concluído em alguns minutos. No entanto, durante esse período, o nó permanece no estado POWER_DOWN e não fica disponível para uso do programador.

• ResumeProgram: /var/log/parallelcluster/slurm_resume.log (slurm_resume)

• SuspendProgram: /var/log/parallelcluster/slurm_suspend.log (slurm_suspend)

• clustermgtd: /var/log/parallelcluster/clustermgtd.log (clustermgtd)

• computemgtd: /var/log/parallelcluster/computemgtd.log (computemgtd)

• slurmctld: /var/log/slurmctld.log (slurmctld)

• slurmd: /var/log/slurmd.log (slurmd)

• Nós dinâmicos:

  • Verifique o log ResumeProgram para ver se ResumeProgram foi chamado com o nó. Caso contrário, verifique o slurmctld registro para determinar se Slurm tentei ligar ResumeProgram com o nó. Observe que permissões incorretas em ResumeProgram podem fazer com que ele falhe silenciosamente.

  • Se ResumeProgram for chamado, verifique se uma instância foi executada para o nó. Se a instância não foi iniciada, deve haver uma mensagem de erro clara sobre o motivo da falha na inicialização da instância.

  • Se uma instância foi iniciada, pode ter havido algum problema durante o processo de bootstrap. Encontre o endereço IP privado e o ID da instância correspondentes no ResumeProgram registro e veja os registros de bootstrap correspondentes para a instância específica em CloudWatch Logs.

• Nós estáticos:

  • Verifique o log clustermgtd para ver se foram iniciadas instâncias para o nó. Se as instâncias não iniciarem, deve haver mensagens de erro claras sobre o motivo da falha na inicialização da instância.

  • Se uma instância foi iniciada, houve algum problema com o processo de bootstrap. Encontre o IP privado e o ID da instância correspondentes no clustermgtd registro e veja os registros de bootstrap correspondentes para a instância específica em CloudWatch Logs.

• Nós substituídos/encerrados inesperadamente:

  • Na maioria dos casos, clustermgtd lida com todas as ações de manutenção do nó. Para verificar se um nó foi clustermgtd substituído ou encerrado, verifique o log clustermgtd.

  • Se clustermgtd tiver substituído ou encerrado o nó, deverá haver uma mensagem indicando o motivo da ação. Se o motivo estiver relacionado com o programador (por exemplo, o nó for DOWN), verifique o log slurmctld para obter mais detalhes. Se o motivo estiver EC2 relacionado à Amazon, use ferramentas como a Amazon CloudWatch ou o EC2 console da Amazon, a CLI ou SDKs, para verificar o status ou os registros dessa instância. Por exemplo, você pode verificar se a instância tinha eventos programados ou falhou nas verificações de status de EC2 saúde da Amazon.

  • Se clustermgtd não encerrou o nó, verifique se o nó computemgtd foi encerrado ou se a instância EC2 foi encerrada para recuperar uma instância spot.

• Falhas do nó:

  • Na maioria dos casos, os trabalhos são automaticamente enfileirados se um nó falhar. Examine o log slurmctld para ver por que um trabalho ou um nó falhou e avalie a situação a partir daí.

• Em geral, clustermgtd lida com todas as ações esperadas de encerramento da instância. Examine o log clustermgtd para ver por que ele não conseguiu substituir ou encerrar um nó.

• Se os nós dinâmicos falharem por ScaledownIdletime, consulte o log SuspendProgram para ver se os processos slurmctld fizeram chamadas com o nó específico como argumento. Na verdade, SuspendProgram não executa nenhuma ação específica. Em vez disso, ele só cria logs quando é chamado. Todos os encerramentos e NodeAddr redefinições de instâncias são concluídos porclustermgtd. Slurm faz a transição dos nós para IDLE depoisSuspendTimeout.

• AWS ParallelCluster não toma decisões de alocação de tarefas ou escalabilidade. Ele só tenta iniciar, encerrar e manter os recursos de acordo com Slurmdas instruções.

  Para problemas relacionados à alocação de trabalhos, alocação de nós e decisão de escalabilidade, consulte o log slurmctld em busca de erros.