Slurm guia para o modo de fila múltipla - AWS ParallelCluster
Visão geralCiclo de vida do nó da nuvemTrabalhando com um nó disponívelEstados do trabalho e envioRecursos e estado do nóEstados de partiçãoinício e término do pclusterControle manual das filasComportamento e ajustes de escalabilidadeLogs para a nova arquiteturaProblemas comuns e como depurar:

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Slurm guia para o modo de fila múltipla

AWS ParallelCluster a versão 2.9.0 introduziu o modo de fila múltipla e uma nova arquitetura de escalonamento para Slurm Workload Manager (Slurm).

As seções a seguir fornecem uma visão geral sobre o uso de um Slurm cluster com a arquitetura de escalabilidade recém-introduzida.

Visão geral

A nova arquitetura de escalabilidade é baseada em SlurmGuia de agendamento em nuvem e plug-in de economia de energia. Para obter mais informações sobre o plug-in de economia de energia, consulte Slurm Guia de economia de energia. Na nova arquitetura, os recursos que podem ser potencialmente disponibilizados para um cluster são normalmente predefinidos no Slurm configuração como nós de nuvem.

Ciclo de vida do nó da nuvem

Durante todo o ciclo de vida, os nós da nuvem entram em vários, se não em todos, dos seguintes estados: POWER_SAVING, POWER_UP (pow_up), ALLOCATED (alloc) e POWER_DOWN (pow_dn). Em alguns casos, um nó da nuvem pode entrar no estado OFFLINE. A lista a seguir detalha vários aspectos desses estados no ciclo de vida do nó na nuvem.

  • Um nó em um estado POWER_SAVING aparece com um sufixo ~ (por exemplo, idle~) em sinfo. Nesse estado, não há nenhuma EC2 instância 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.

  • Quando Slurm aloca o trabalho para um nó em um POWER_SAVING estado, o nó é automaticamente transferido para um POWER_UP estado. Caso contrário, os nós podem ser colocados no estado POWER_UP manualmente usando o comando scontrol update nodename=nodename state=power_up. Nesse estágio, o ResumeProgram é invocado e as EC2 instâncias são iniciadas e configuradas para apoiar um POWER_UP nó.

  • 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 instâncias em EC2 seja igual ao número de nós disponíveis. Na maioria dos casos, os nós estáticos ficam sempre 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 scaledown_idletime. Por outro lado, os nós estáticos na maioria dos casos não são desligados. Contudo, os nós podem ser colocados no estado POWER_DOWN manualmente usando o comando scontrol update nodename=nodename state=powering_down. Nesse estado, a instância associada a um nó é encerrada e o nó retorna ao estado POWER_SAVING e para uso após o scaledown_idletime. A scaledown-idletime configuração é salva no Slurm configuração como SuspendTimeout configuração.

  • Um nó que está off-line aparece com um sufixo * (por exemplo, down*) em sinfo. Um nó fica off-line se 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.

Agora, considere os estados dos nós mostrados no exemplo sinfo a seguir.

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1  idle% gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite      2   mix# ondemand-dy-c52xlarge-[1-2]
ondemand     up   infinite     18  idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2]

Os nós spot-st-t2large-[1-2] e efa-st-c5n18xlarge-1 já têm instâncias de backup configuradas e estão disponíveis para uso. Os nós ondemand-dy-c52xlarge-[1-2] estão no estado POWER_UP e devem estar disponíveis em instantes. O nó gpu-dy-g38xlarge-1 está no estado POWER_DOWN e passará para o estado POWER_SAVING depois de scaledown_idletime (o padrão é 120 segundos).

Todos os outros nós estão no POWER_SAVING estado sem nenhuma EC2 instância apoiando-os.

Trabalhando com um nó disponível

Um nó disponível é apoiado por uma EC2 instância. Por padrão, o nome do nó pode ser usado para fazer SSH diretamente na instância (por exemplo, ssh efa-st-c5n18xlarge-1). O endereço IP privado da instância pode ser recuperado usando o comando scontrol show nodes nodename e verificando o campo NodeAddr. Para nós que não estão disponíveis, o NodeAddr campo não deve apontar para uma EC2 instância em execução. Em vez disso, deve ser igual ao nome do nó.

Estados do trabalho e envio

Na maioria dos casos, os trabalhos enviados são imediatamente alocados aos nós do sistema ou colocados como pendentes se todos os nós estiverem alocados.

Se os nós alocados para um trabalho incluírem qualquer nó em um estado POWER_SAVING, o trabalho começará com um estado CF ou CONFIGURING. Nesse momento, o trabalho aguarda para que os nós no estado POWER_SAVING façam a transição para o estado POWER_UP e fiquem disponíveis.

Depois que todos os nós alocados para uma trabalho estiverem disponíveis, o trabalho entrará no estado RUNNING (R).

Por padrão, todos os trabalhos são enviados para a fila padrão (conhecida como partição em Slurm). Isso é representado por um * sufixo após o nome da fila. Você pode selecionar uma fila usando a opção de envio de trabalho -p.

Todos os nós são configurados com os seguintes recursos, que podem ser usados nos comandos de envio de tarefas:

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

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

Você pode ver todos os recursos disponíveis para um determinado nó usando o comando scontrol show nodes nodename e verificando a lista AvailableFeatures.

Outra consideração são os trabalhos. Considere o estado inicial do cluster, que você pode ver executando o comando sinfo.

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite     10  idle~ gpu-dy-g38xlarge-[1-10]
ondemand     up   infinite     20  idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2]

Observe que a lista padrão é spot. É indicada pelo sufixo *.

Envia um trabalho para um nó estático para a fila padrão (spot).

$ sbatch --wrap "sleep 300" -N 1 -C static

Envia um trabalho para um nó dinâmico para a fila EFA.

$ sbatch --wrap "sleep 300" -p efa -C dynamic

Envia um trabalho para oito (8) nós c5.2xlarge e dois (2) nós t2.xlarge para a fila ondemand.

$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"

Envia um trabalho para um nó da GPU para a fila gpu.

$ sbatch --wrap "sleep 300" -p gpu -G 1

Agora, considere o estado dos trabalhos usando o comando squeue.

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                12  ondemand     wrap   ubuntu CF       0:36     10 ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
                13       gpu     wrap   ubuntu CF       0:05      1 gpu-dy-g38xlarge-1
                 7      spot     wrap   ubuntu  R       2:48      1 spot-st-t2large-1
                 8       efa     wrap   ubuntu  R       0:39      1 efa-dy-c5n18xlarge-1

Os trabalhos 7 e 8 (nas filas spot e efa) já estão em execução (R). Os trabalhos 12 e 13 ainda estão com configuração em andamento (CF), provavelmente aguardando a disponibilização das instâncias.

# Nodes states corresponds to state of running jobs
$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      3  idle~ efa-dy-c5n18xlarge-[2-4]
efa          up   infinite      1    mix efa-dy-c5n18xlarge-1
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1   mix~ gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite     10   mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
ondemand     up   infinite     10  idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      1    mix spot-st-t2large-1
spot*        up   infinite      1   idle spot-st-t2large-2

Recursos e estado do nó

Na maioria dos casos, os estados dos nós são totalmente gerenciados de AWS ParallelCluster acordo com os processos específicos no ciclo de vida do nó na nuvem descritos anteriormente neste tópico.

No entanto, AWS ParallelCluster também substitui ou encerra nós não íntegros em DRAINED estados DOWN e nós que têm instâncias de backup não íntegras. Para obter mais informações, consulte clustermgtd.

Estados de partição

AWS ParallelCluster suporta os seguintes estados de partição. A Slurm partição é uma fila de entrada. AWS ParallelCluster

  • 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.

início e término do pcluster

Quando pcluster stop é executado, todas as partições são colocadas no INACTIVE estado e os AWS ParallelCluster processos mantêm as partições no INACTIVE estado.

Quando pcluster start é executado, todas as partições são inicialmente colocadas no 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. Se initial_count for maior que max_count, então initial_count talvez não seja satisfeito quando o estado da partição for alterado para o estado UP.

Quando pcluster start e pcluster stop estão em execução, você pode verificar o estado do cluster executando o comando pcluster status e verificando o ComputeFleetStatus. A seguir, listamos estados possíveis:

  • STOP_REQUESTED: a solicitação pcluster stop é enviada ao cluster.

  • STOPPING: o processo pcluster está interrompendo o cluster no momento.

  • 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 pcluster start é 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.

Controle manual das filas

Em alguns casos, talvez você queira ter algum controle manual sobre os nós ou a fila (conhecido como partição em Slurm) em um cluster. Você pode gerenciar nós em um cluster por meio dos seguintes procedimentos comuns.

  • Ative os nós dinâmicos no POWER_SAVING estado: execute o scontrol update nodename=nodename state=power_up comando ou envie um sleep 1 trabalho de espaço reservado solicitando um determinado número de nós e confie em Slurm para alimentar o número necessário de nós.

  • Desligue os nós dinâmicos antesscaledown_idletime: defina os nós dinâmicos para DOWN com o scontrol update nodename=nodename state=down comando. 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. Nenhuma intervenção manual é necessária. Portanto, convém tentar definir nós para DOWN sempre que possível.

  • Desativar uma fila (partição) ou interromper todos os nós estáticos em uma partição específica: defina uma fila específica INACTIVE com o comando scontrol update partition=queue name 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 INACTIVE com o comando scontrol update partition=queue name state=up.

Comportamento e ajustes de escalabilidade

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-c5xlarge-[1-2]).

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

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

  • O trabalho é concluído.

  • Depois de decorrido o SuspendTime configurado (que está definido como scaledown_idletime), as instâncias são colocadas no estado POWER_SAVING pelo programador. O programador coloca queue1-dy-c5xlarge-[1-2] no estado POWER_DOWN e chama o 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 se configura queue1-dy-c5xlarge-[1-2] no estado ocioso e redefine o endereço IP privado e o nome do host para que possam ser ativados novamente para futuros trabalhos.

Agora, 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 coloca 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-c5xlarge-[1-2]).

  • ResumePrograminicia somente uma (1) EC2 instância e configuraqueue1-dy-c5xlarge-1, mas falhou ao iniciar uma instância paraqueue1-dy-c5xlarge-2.

  • queue1-dy-c5xlarge-1 não será afetado e ficará online após atingir o estado POWER_UP.

  • queue1-dy-c5xlarge-2é colocado no POWER_DOWN estado e o trabalho é enfileirado automaticamente porque Slurm detecta uma falha no nó.

  • queue1-dy-c5xlarge-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 é 60 minutos (1 hora)): ResumeTimeout controla a hora Slurm espera antes de colocar o nó no estado inativo.

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

    • Esse também é o tempo máximo de AWS ParallelCluster espera antes de substituir ou redefinir um nó, caso haja algum problema. Os nós de computação terminam automaticamente se ocorrer algum erro durante a inicialização ou a configuração. Em seguida, os processos do AWS ParallelCluster também substituem o nó quando percebem que a instância foi 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 significaria que os nós seriam reinicializados mais rapidamente e Slurm é capaz de tentar executar instâncias com mais frequência.

    • Um SuspendTimeout mais longo faz com que os nós com falha reiniciem mais lentamente. Enquanto isso, Slurm pneus para 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 reenfileirando trabalhos que falharam com frequência.

    • Observe que SuspendTimeout isso não se refere ao tempo AWS ParallelCluster esperado 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 desligado e indisponível para uso no programador.

Logs para a nova arquitetura

A lista a seguir contém os principais logs da arquitetura de várias filas. O nome do stream de log usado com o Amazon CloudWatch Logs tem o formato{hostname}.{instance_id}.{logIdentifier}, que logIdentifier segue os nomes dos registros. Para obter mais informações, consulte Integração com Amazon CloudWatch Logs.

  • 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)

Problemas comuns e como depurar:

Nós que falharam ao iniciar, ativar ou ingressar no cluster:

  • Nós dinâmicos:

    • Verifique o log ResumeProgram para ver se ResumeProgram foi chamado alguma vez com o nó. Caso contrário, verifique o slurmctld registro para determinar se Slurm já 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 puder ser 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ó. Caso negativo, 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 durante 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 ou encerrados inesperadamente e falhas nos nós

  • 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, use ferramentas 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 do status de EC2 saúde.

    • 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 analise a situação a partir daí.

Falha ao substituir ou encerrar instâncias, falha ao desligar os nós

  • 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 scaledown_idletime, consulte o log SuspendProgram para ver se há um programa pelo slurmctld 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 coloca nós em IDLE depoisSuspendTimeout.

Outros problemas

  • AWS ParallelCluster não toma decisões de alocação de tarefas ou escalabilidade. Ele simplesmente 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.