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á.
Guia do Slurm para o modo de várias filas
Aqui você pode aprender como AWS ParallelCluster Slurm gerenciar nós de fila (partição) e como monitorar os estados da fila e do nó.
Visão geral
A arquitetura de escalabilidade é baseada no Cloud Scheduling Guide
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~
) emsinfo
. Nesse estado, nenhuma instância do EC2 serve de apoio ao 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#
) emsinfo
. Um nó faz a transição automática para um estadoPOWER_UP
quando Slurm aloca uma tarefa para um nó em um estadoPOWER_SAVING
.Como alternativa, você pode fazer manualmente a transição dos nós para o estado
POWER_UP
como usuário raizsu
com o comando:$
scontrol update nodename=
nodename
state=power_upNesse estágio, o
ResumeProgram
é invocado, as instâncias do EC2 são iniciadas e configuradas, e ocorre a transição do nó para o estadoPOWER_UP
. -
Um nó atualmente disponível para uso aparece sem um sufixo (por exemplo
idle
) emsinfo
. 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 do Amazon EC2 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%
) emsinfo
. Os nós dinâmicos entram automaticamente no estadoPOWER_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 estadoPOWER_DOWN
manualmente como usuário raizsu
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 opção ScaledownIdletime é salva na opção
SuspendTimeout
da configuração Slurm. -
Um nó que está off-line aparece com um sufixo
*
(por exemplo,down*
) emsinfo
. Um nó fica off-line se o controlador Slurm não conseguir entrar em contato com o nó ou se os nós estáticos forem desativados e as instâncias de backup forem encerradas.
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-efacompute1-[1-4] efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 1 idle% gpu-dy-gpucompute1-1 gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10] ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2] ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
Os nós spot-st-spotcompute2-[1-2]
e efa-st-efacompute1-1
já têm instâncias de backup configuradas e estão disponíveis para uso. Os nós ondemand-dy-ondemandcompute1-[1-2]
estão no estado POWER_UP
e devem estar disponíveis em instantes. O nó gpu-dy-gpucompute1-1
está no estado POWER_DOWN
e passa para o estado POWER_SAVING
depois de ScaledownIdletime (o padrão é 10 minutos).
Todos os outros nós estão no estado POWER_SAVING
sem nenhuma instância do EC2 como backup.
Trabalhando com um nó disponível
Um nó disponível é apoiado por uma instância do Amazon EC2. Por padrão, o nome do nó pode ser usado para fazer SSH diretamente na instância (por exemplo, ssh
efa-st-efacompute1-1
). O endereço IP privado da instância pode ser recuperado usando o comando:
$
scontrol show nodes
nodename
Verifique o endereço IP exibido no campo NodeAddr
.
Para nós que não estão disponíveis, o NodeAddr
campo não deve apontar para uma instância do Amazon EC2 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
oustatic
.)
Você pode ver os recursos de um determinado nó usando o comando:
$
scontrol show nodes
nodename
Quando retornar, confira a lista AvailableFeatures
.
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-efacompute1-[1-4] efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10] ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
Observe que a lista padrão é spot
. É indicada pelo sufixo *
.
Envia um trabalho para um nó estático na fila padrão (spot
).
$
sbatch --wrap
"sleep 300"
-N1
-Cstatic
Envia um trabalho para um nó dinâmico na fila EFA
.
$
sbatch --wrap
"sleep 300"
-pefa
-Cdynamic
Envia um trabalho para oito (8) nós c5.2xlarge
e dois (2) nós t2.xlarge
na fila ondemand
.
$
sbatch --wrap
"sleep 300"
-pondemand
-N10
-C "[c5.2xlarge*8&t2.xlarge*2
]"
Envia um trabalho para um nó da GPU na fila gpu
.
$
sbatch --wrap
"sleep 300"
-pgpu
-G1
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-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2] 13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1 7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1 8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-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-efacompute1-[2-4] efa up infinite 1 mix efa-dy-efacompute1-1 efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 1 mix~ gpu-dy-gpucompute1-1 gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10] ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2] ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 1 mix spot-st-spotcompute2-1 spot* up infinite 1 idle spot-st-spotcompute2-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 ter mais informações, consulte clustermgtd.
Estados de partição
AWS ParallelCluster suporta os seguintes estados de partição. Uma partição Slurm é uma fila no 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.
cluster update-compute-fleet
-
Interrompendo 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
\ --regioneu-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 umUP
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 comoUP
não ativa nenhuma capacidade dinâmica.$
pcluster update-compute-fleet --cluster-name
testSlurm
\ --regioneu-west-1
--status START_REQUESTED
Quando update-compute-fleet
executado, você pode verificar o estado do cluster executando o comando pcluster describe-compute-fleet
e verificando Status
. A seguir, listamos estados possíveis:
-
STOP_REQUESTED
: a solicitação de interrupção da frota de computação é enviada ao cluster. -
STOPPING
: no momento, o processopcluster
está interrompendo a frota de computação. -
STOPPED
: o processopcluster
finalizou o processo de interrupção, todas as partições estão em estadoINACTIVE
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 processopcluster
está iniciando o cluster no momento. -
RUNNING
: o processopcluster
finalizou o processo inicial, todas as partições estão no estadoUP
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, executeupdate-compute-fleet
para reativar a frota.
Controle manual de filas
Em alguns casos, talvez você queira ter algum controle manual sobre os nós ou sobre a fila (conhecida como partição em Slurm) em um cluster. Você pode gerenciar nós em um cluster por meio dos seguintes procedimentos comuns usando o comando scontrol
.
-
Ative os nós dinâmicos no estado
POWER_SAVING
Execute o comando como usuário raiz
su
:$
scontrol update nodename=
nodename
state=power_upVocê também pode enviar um trabalho
sleep 1
como espaço reservado, solicitando um determinado número de nós e, em seguida, contar com o Slurm para ativação do 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 raizsu
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 comandoscontrol update nodename=
. Isso porque AWS ParallelCluster gerencia automaticamente o processo de desligamento.nodename
state=power_down -
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 raizsu
com o comando:$
scontrol update partition=
queuename
state=inactiveIsso 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 raizsu
com o comando:$
scontrol update partition=
queuename
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 chamaResumeProgram
com os nomes dos nós (por exemplo,queue1-dy-spotcompute1-[1-2]
). -
ResumeProgram
inicia duas instâncias do Amazon EC2 e atribui os endereços IP e nomes de host privados dequeue1-dy-spotcompute1-[1-2]
, aguardandoResumeTimeout
(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 estadoPOWER_SAVING
. Em seguida, o programador definequeue1-dy-spotcompute1-[1-2]
para o estadoPOWER_DOWN
e chamaSuspendProgram
com os nomes dos nós. -
SuspendProgram
é chamado para dois nós. Os nós permanecem no estadoPOWER_DOWN
, por exemplo, permanecendoidle%
por umSuspendTimeout
(o período padrão é 120 segundos (2 minutos)). Depois declustermgtd
detectar que os nós estão sendo desligados, ele encerra as instâncias de backup. Em seguida, ele passaqueue1-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 chamaResumeProgram
com os nomes dos nós (por exemploqueue1-dy-spotcompute1-[1-2]
). -
ResumeProgram
inicia somente uma (1) instância do Amazon EC2 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 estadoPOWER_UP
. -
queue1-dy-spotcompute1-2
faz a transição para o estadoPOWER_DOWN
e o trabalho é enfileirado automaticamente porque Slurm detecta uma falha no nó. -
queue1-dy-spotcompute1-2
fica disponível apósSuspendTimeout
(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 o tempo que Slurm espera antes da 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
SuspendTimeout
menor significa que os nós são redefinidos mais rapidamente e que Slurm pode tentar executar 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. SeSuspendTimeout
demorar mais do que alguns minutos, Slurm tenta percorrer todos os nós do sistema. UmSuspendTimeout
mais longo pode ser benéfico para sistemas de grande escala (mais de 1.000 nós) para reduzir o estresse em Slurm enquanto ele tenta enfileirar novamente os 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 dePOWER_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 estadoPOWER_DOWN
e não fica disponível para uso do programador.
-
Logs para a arquitetura
A lista a seguir contém os logs chave. O nome do stream de log usado com o Amazon CloudWatch Logs tem o formato
, em que {hostname}
.{instance_id}
.{logIdentifier}
LogiDentifier
segue os nomes dos registros.
-
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 seResumeProgram
foi chamado com o nó. Caso contrário, verifique o logslurmctld
para determinar se Slurm tentou chamarResumeProgram
com o nó. Observe que permissões incorretas emResumeProgram
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ódulos 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ó foiclustermgtd
substituído ou encerrado, verifique o logclustermgtd
. -
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ó forDOWN
), verifique o logslurmctld
para obter mais detalhes. Se o motivo estiver relacionado ao Amazon EC2, use ferramentas como a Amazon CloudWatch ou o console do Amazon EC2, a CLI ou os 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 do status de saúde do Amazon EC2. -
Se
clustermgtd
não encerrou o nó, verifique se o nó foi encerrado porcomputemgtd
ou se a instância foi encerrada pelo EC2 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í.
-
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 logclustermgtd
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 processosslurmctld
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 de instâncias e redefinições deNodeAddr
são concluídos porclustermgtd
. Slurm faz a transição dos nós paraIDLE
apósSuspendTimeout
.
Outros problemas:
-
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 as instruções do Slurm.
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.