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
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 cluster Slurm com a arquitetura de escalabilidade recém-introduzida.
## Visão geral do
A nova arquitetura de escalabilidade é baseada no [Cloud Scheduling Guide](https://slurm.schedmd.com/elastic_computing.html) do Slurm e no plug-in de economia de energia. Para obter mais informações sobre o plug-in de economia de energia, consulte o [Guia de economia de energia do Slurm](https://slurm.schedmd.com/power_save.html). Na nova arquitetura, os recursos com potencial para serem disponibilizados em um cluster geralmente são predefinidos na configuração do Slurm 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á instância do EC2 que 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#`) em `sinfo`.
+ Quando Slurm aloca um trabalho para um nó em um estado `POWER_SAVING`, o nó faz transferência automática para um estado `POWER_UP`. 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, as instâncias do EC2 são iniciadas e configuradas para servir de backup para o nó `POWER_UP`.
+ 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 no 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`](scaling-section.md#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`](scaling-section.md#scaledown-idletime). A opção `scaledown-idletime` é salva na configuração Slurm como opção `SuspendTimeout`.
+ Um nó que está off-line aparece com um sufixo `*` (por exemplo, `down*`) em `sinfo`. 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.
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`](scaling-section.md#scaledown-idletime) (o padrão é 120 segundos).
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 EC2. 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 os nós que não estão disponíveis, o campo `NodeAddr` não deve apontar para uma instância do 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` 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`](processes.md#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.
## início e término do pcluster
Quando [`pcluster stop`](pcluster.stop.md) é 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`](pcluster.start.md) é 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`](compute-resource-section.md#compute-resource-initial-count) for maior que [`max_count`](compute-resource-section.md#compute-resource-max-count), então [`initial_count`](compute-resource-section.md#compute-resource-initial-count) talvez não seja satisfeito quando o estado da partição for alterado para o estado `UP`.
Quando [`pcluster start`](pcluster.start.md) e [`pcluster stop`](pcluster.stop.md) estão em execução, você pode verificar o estado do cluster executando o comando [`pcluster status`](pcluster.status.md) e verificando o `ComputeFleetStatus`. A seguir, listamos estados possíveis:
+ `STOP_REQUESTED`: a solicitação [`pcluster stop`](pcluster.stop.md) é 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`](pcluster.start.md) é 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 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.
+ Ative os nós dinâmicos no estado `POWER_SAVING`: execute o comando `scontrol update nodename=nodename state=power_up` ou envie um trabalho de espaço reservado `sleep 1` solicitando um determinado número de nós e dependa do Slurm para ativar o número necessário de nós.
+ Desligue os nós dinâmicos antes[`scaledown_idletime`](scaling-section.md#scaledown-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]`).
+ `ResumeProgram` inicia duas instâncias do EC2 e atribui os endereços IP e nomes de host privados de `queue1-dy-c5xlarge-[1-2]`, aguardando `ResumeTimeout` (o período padrão é de 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`](scaling-section.md#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]`).
+ `ResumeProgram` inicia somente uma (1) instância do EC2 e configura `queue1-dy-c5xlarge-1`, mas falhou ao iniciar uma instância para `queue1-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 estado `POWER_DOWN` e o trabalho é reenfileirado 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 o tempo que Slurm espera antes de colocar o nó para o estado inativo.
+ Pode ser útil estender isso se o processo de pre/post instalação demorar quase esse tempo.
+ 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 `SuspendTimeout` menor significaria que os nós serão redefinidos mais rapidamente, e que Slurm pode 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 tenta usar outros nós. Se `SuspendTimeout` demorar mais do que alguns minutos, Slurm tenta percorrer todos os nós do sistema. Um `SuspendTimeout` mais longo pode ser benéfico para sistemas de grande escala (mais de 1.000 nós) para reduzir o estresse em Slurm ao tentar enfileirar novamente os trabalhos que falham 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](cloudwatch-logs.md).
+ `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 log `slurmctld` para determinar se Slurm alguma vez tentou chamar `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**
+ Nodos replaced/terminated 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 relacionado ao EC2, use ferramentas para verificar o status ou os logs dessa instância. Por exemplo, você pode verificar se a instância tinha eventos programados ou falhou nas verificações do status de integridade do EC2.
+ Se `clustermgtd` não encerrou o nó, verifique se o nó foi encerrado por `computemgtd` 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 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`](scaling-section.md#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 de instâncias e redefinições de `NodeAddr` são concluídos por `clustermgtd`. Slurm coloca os nós para `IDLE` após `SuspendTimeout`.
**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.