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á.
# Agendadores suportados por AWS ParallelCluster
AWS ParallelCluster suportes Slurm e AWS Batch agendadores, que são definidos usando a [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)configuração. Os tópicos a seguir descreverão cada agendador e como usá-los.
**Topics**
+ [Slurm Workload Manager (`slurm`)](slurm-workload-manager-v3.md)
+ [Usando o agendador AWS Batch (`awsbatch`) com AWS ParallelCluster](awsbatchcli-v3.md)
# Slurm Workload Manager (`slurm`)
## Tamanho e atualização da capacidade do cluster
A capacidade do cluster é definida pelo número de nós de computação que o cluster pode escalar. Os nós de computação são apoiados por instâncias do Amazon EC2 definidas nos recursos computacionais AWS ParallelCluster da `(Scheduling/SlurmQueues/`ComputeResources`)` configuração e são organizados em `(Scheduling/SlurmQueues)` filas que mapeiam 1:1 para partições. Slurm
[Em um recurso de computação, é possível configurar o número mínimo de nós de computação (instâncias) que sempre devem ser mantidos em execução no cluster (`MinCount`) e o número máximo de instâncias para as quais o recurso computacional pode ser escalado (`MaxCount`3).](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)
No momento da criação do cluster, ou após uma atualização do cluster, AWS ParallelCluster inicia quantas instâncias do Amazon EC2 estiverem configuradas `MinCount` para cada recurso computacional (`Scheduling/SlurmQueues/ ComputeResources`) definido no cluster. As instâncias lançadas para cobrir a quantidade mínima de nós para os recursos computacionais no cluster são chamadas de ***nós estáticos***. Uma vez iniciados, os nós estáticos devem ser persistentes no cluster e não são encerrados pelo sistema, a menos que ocorra um evento ou condição específica. Esses eventos incluem, por exemplo, a falha das verificações de integridade do Slurm ou do Amazon EC2 e a alteração do status do nó do Slurm para DRAIN ou DOWN.
As instâncias do Amazon EC2, no intervalo de `1` a `‘MaxCount - MinCount’` (`MaxCount ` *menos*` MinCount)`, lançadas sob demanda para lidar com o aumento da carga do cluster, são chamadas de ***nós dinâmicos***. Sua natureza é efêmera, elas são lançadas para atender a trabalhos pendentes e são encerradas quando ficam ociosas por um tempo definido por `Scheduling/SlurmSettings/ScaledownIdletime` na configuração do cluster (padrão: 10 minutos).
Os nós estáticos e os nós dinâmicos estão obedecem ao seguinte padrão de nomenclatura:
+ Os nós estáticos são `-st--`, em que ` = 1..ComputeResource/MinCount`
+ Os nós dinâmicos são `-dy--`, em que ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Por exemplo, dada a seguinte AWS ParallelCluster configuração:
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
Os seguintes nós serão definidos no Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Quando um recurso computacional o tiver`MinCount == MaxCount`, todos os nós de computação correspondentes serão estáticos e todas as instâncias serão iniciadas no creation/update momento do cluster e mantidas em funcionamento. Por exemplo:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Atualização da capacidade do cluster
A atualização da capacidade do cluster inclui adicionar ou remover filas, recursos computacionais ou alterar o `MinCount/MaxCount` de um recurso computacional. A partir da AWS ParallelCluster versão 3.9.0, reduzir o tamanho de uma fila exige que a frota de computação seja interrompida ou [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)configurada como TERMINATE antes que uma atualização do cluster ocorra. Não é necessário interromper a frota de computação ou configurar [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)para TERMINATE quando:
+ Adicionar novas filas ao Agendamento/ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Adicionar novos recursos computacionais `Scheduling/SlurmQueues/ComputeResources` a uma fila
+ Aumentar a `MaxCount` de um recurso computacional
+ Aumento MinCount de um recurso computacional e aumento MaxCount do mesmo recurso computacional em pelo menos a mesma quantidade
## Considerações e limitações
Esta seção tem como objetivo descrever fatores, restrições ou limitações importantes que devem ser levados em consideração ao redimensionar a capacidade do cluster.
+ Ao remover uma fila de `Scheduling/SlurmQueues`, todos os nós computacionais com nome `-*`, tanto estáticos quanto dinâmicos, serão removidos da configuração do Slurm, e as instâncias correspondentes do Amazon EC2 serão encerradas.
+ Ao remover um recurso computacional `Scheduling/SlurmQueues/ComputeResources` de uma fila, todos os nós de computação com nome `-*--*`, tanto estáticos quanto dinâmicos, serão removidos da configuração do Slurm, e as instâncias correspondentes do Amazon EC2 serão encerradas.
Ao alterar o parâmetro `MinCount` de um recurso computacional, podemos distinguir dois cenários diferentes: se `MaxCount` for mantido igual a `MinCount` (somente capacidade estática) e se `MaxCount` for maior que `MinCount` (capacidade estática e dinâmica mista).
### Alterações de capacidade somente com nós estáticos
+ Se `MinCount == MaxCount`, ao aumentar `MinCount` (e `MaxCount`), o cluster será configurado estendendo o número de nós estáticos até o novo valor de `MinCount` `-st--` e o sistema continuará tentando iniciar instâncias do Amazon EC2 para atender à nova capacidade estática necessária.
+ Se `MinCount == MaxCount`, ao diminuir `MinCount` (e `MaxCount`) em N, o cluster será configurado removendo os últimos N nós estáticos `-st--...]` e o sistema encerrará as instâncias correspondentes do Amazon EC2.
+ Estado inicial `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualizar `-30` em `MinCount` e `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Alterações de capacidade com nós mistos
Se `MinCount < MaxCount`, ao aumentar `MinCount` em uma quantidade N (supondo que `MaxCount` será mantido inalterado), o cluster será configurado estendendo o número de nós estáticos até o novo valor de `MinCount` (`old_MinCount + N`): `-st--` e o sistema continuará tentando iniciar instâncias do Amazon EC2 para atender à nova capacidade estática necessária. Além disso, para honrar a capacidade `MaxCount` do recurso computacional, a configuração do cluster é atualizada *removendo os últimos N nós dinâmicos*: `-dy--[...]` e o sistema encerrará as instâncias correspondentes do Amazon EC2.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização \$130 para `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Se `MinCount < MaxCount`, ao aumentar `MinCount` e `MaxCount` com a mesma quantidade N, o cluster será configurado estendendo o número de nós estáticos para o novo valor de `MinCount` (`old_MinCount + N`): `-st--` e o sistema continuará tentando iniciar instâncias do Amazon EC2 para atender à nova capacidade estática necessária. Além disso, nenhuma alteração será feita no número de nós dinâmicos para honrar o novo
`MaxCount` value.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização \$130 para `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Se `MinCount < MaxCount`, ao diminuir `MinCount` em N (supondo que `MaxCount` seja mantido inalterado), o cluster será configurado removendo os últimos N nós estáticos `-st--[...` e o sistema encerrará as instâncias correspondentes do Amazon EC2. Além disso, para honrar a capacidade `MaxCount` do recurso computacional, a configuração do cluster é atualizada ampliando o número de nós dinâmicos para preencher a lacuna `MaxCount - new_MinCount: -dy--[1..]`. Nesse caso, como esses são nós dinâmicos, nenhuma nova instância do Amazon EC2 será inicializada, a menos que o agendador tenha trabalhos pendentes nos novos nós.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização -30 no `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Se `MinCount < MaxCount`, ao diminuir `MinCount` e `MaxCount` em N, o cluster será configurado removendo os últimos N nós estáticos `-st--...]` e o sistema encerrará as instâncias correspondentes do Amazon EC2.
Além disso, nenhuma alteração será feita no número de nós dinâmicos para honrar o novo valor `MaxCount`.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização -30 no `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Se `MinCount < MaxCount`, ao diminuir `MaxCount` a quantidade N (supondo que `MinCount` seja mantido inalterado), o cluster será configurado removendo os últimos N nós dinâmicos `-dy--]` e o sistema encerrará as instâncias correspondentes do Amazon EC2 caso elas estejam em execução. Nenhum impacto é esperado nos nós estáticos.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização -30 no `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Impactos nos empregos
Em todos os casos em que os nós são removidos e as instâncias do Amazon EC2 são encerradas, um trabalho em lote em execução nos nós removidos será enfileirado novamente, a menos que não haja outros nós que satisfaçam os requisitos do trabalho. Nesse último caso, o trabalho falha com o status NODE\$1FAIL e desaparece da fila e deve ser reenviado manualmente.
Se você estiver planejando executar uma atualização de redimensionamento de cluster, poderá impedir que os trabalhos sejam executados nos nós que serão removidos durante a atualização planejada. Isso é possível configurando os nós para serem removidos na manutenção. Esteja ciente de que a configuração de um nó em manutenção não afetará os trabalhos que já estiverem em execução no nó.
Suponha que, com a atualização de redimensionamento do cluster planejada, você vai remover o nó `qeueu-st-computeresource-[9-10`]. Você pode criar uma reserva do Slurm com o seguinte comando
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Isso criará uma reserva do Slurm chamada `maint_for_update` nos nós `qeueu-st-computeresource-[9-10]`. Quando a reserva é criada, nenhum outro trabalho pode ser executado nos nós `qeueu-st-computeresource-[9-10]`. Esteja ciente de que a reserva não impedirá que os trabalhos sejam alocados nos nós `qeueu-st-computeresource-[9-10]`.
Após a atualização do redimensionamento do cluster, se a reserva do Slurm tiver sido definida apenas em nós removidos durante esse processo, a reserva de manutenção será excluída automaticamente. Em vez disso, se você tiver criado uma reserva do Slurm em nós que ainda estão presentes após a atualização do redimensionamento do cluster, poderá ser necessário remover a reserva de manutenção desses nós após a execução da atualização de redimensionamento, usando o seguinte comando:
```
sudo -i scontrol delete ReservationName=maint_for_update
```
Para conferir mais detalhes sobre a reserva do Slurm, consulte o documento oficial da SchedMD [aqui](https://slurm.schedmd.com/reservations.html).
## Processo de atualização do cluster em alterações de capacidade
Após uma alteração na configuração do agendador, as seguintes etapas são executadas durante o processo de atualização do cluster:
+ Pare AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Gerar configuração de partições do Slurm atualizada com base na configuração do AWS ParallelCluster
+ Reiniciar `slurmctld` (feito por meio da fórmula do serviço do Chef)
+ Verificar status do `slurmctld` `(systemctl is-active --quiet slurmctld.service)`
+ Recarregar configuração do Slurm `(scontrol reconfigure)`
+ Iniciar `clustermgtd (supervisorctl start clustermgtd)`
Para saber mais sobre o Slurm, consulte [https://slurm.schedmd.com](https://slurm.schedmd.com). Para downloads, consulte [https://github.com/SchedMD/slurm/tags](https://github.com/SchedMD/slurm/tags). Para o código-fonte, consulte [https://github.com/SchedMD/slurm](https://github.com/SchedMD/slurm).
## Versões de cluster e SLURM suportadas
A tabela a seguir lista as Slurm versões AWS ParallelCluster e AWS compatíveis.
| AWS ParallelCluster versão (ões) | Versão do Slurm compatível |
| --- | --- |
| 3.13.0 | 24.05.07 |
| 3.12.0 | 23.11.10 |
| 3.11.0 | 23.11.10 |
| 3.9.2, 3.9.3, 3.10.0 | 23.11.7 |
| 3.9.0, 3.9.1 | 23.11.4 |
| 3.8.0 | 23.02.7 |
| 3.7.2 | 23.02.6 |
| 3.7.1 | 23.02.5 |
| 3.7.0 | 23.02.4 |
| 3.6.0, 3.6.1 | 23.02.2 |
| 3.5.0, 3.5.1 | 22.05.8 |
| 3.4.0, 3.4.1 | 22.05.7 |
| 3.3.0, 3.3.1 | 22.05.5 |
| 3.1.4, 3.1.5, 3.2.0, 3.2.1 | 21.08.8-2 |
| 3.1.2, 3.1.3 | 21.08.6 |
| 3.1.1 | 21.08.5 |
| 3.0.0 | 20.11.8 |
**Topics**
+ [Tamanho e atualização da capacidade do cluster](#cluster-capacity-size-and-update)
+ [Atualização da capacidade do cluster](#cluster-capacity-update)
+ [Considerações e limitações](#considerations-limitations)
+ [Impactos nos empregos](#impacts-on-jobs)
+ [Processo de atualização do cluster em alterações de capacidade](#cluster-update-process)
+ [Versões de cluster e SLURM suportadas](#cluster-slurm-version-table)
+ [Configuração de várias filas](configuration-of-multiple-queues-v3.md)
+ [Guia do Slurm para o modo de várias filas](multiple-queue-mode-slurm-user-guide-v3.md)
+ [Slurm modo protegido por cluster](slurm-protected-mode-v3.md)
+ [Failover rápido de capacidade insuficiente do cluster Slurm](slurm-short-capacity-fail-mode-v3.md)
+ [Slurm agendamento baseado em memória](slurm-mem-based-scheduling-v3.md)
+ [Alocação a vários tipos de instância com o Slurm](slurm-multiple-instance-allocation-v3.md)
+ [Dimensionamento de clusters para nós dinâmicos](scheduler-node-allocation-v3.md)
+ [Slurmcontabilidade com AWS ParallelCluster](slurm-accounting-v3.md)
+ [Slurm personalização de configuração](slurm-configuration-settings-v3.md)
+ [`prolog` e `epilog` da Slurm](slurm-prolog-epilog-v3.md)
+ [Tamanho e atualização da capacidade do cluster](slurm-cluster-capacity-size-and-update.md)
# Configuração de várias filas
Com a AWS ParallelCluster versão 3, você pode configurar várias filas definindo o [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)para `slurm` e especificando mais de uma fila para [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) no arquivo de configuração. Nesse modo, diferentes tipos de instância coexistem nos nós de computação especificados na seção [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) do arquivo de configuração. [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) com diferentes tipos de instância têm a escala aumentada ou reduzida conforme necessário para o [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues).
Geralmente, várias *filas* em um único cluster são preferidas a vários clusters quando as cargas de trabalho compartilham a mesma infraestrutura e os mesmos recursos subjacentes (como armazenamento compartilhado, rede ou nós de login). Se as cargas de trabalho tiverem necessidades semelhantes de computação, armazenamento e rede, usar várias filas em um único cluster é mais eficiente, pois permite o compartilhamento de recursos e evita duplicações desnecessárias. Essa abordagem simplifica o gerenciamento e reduz a sobrecarga, ao mesmo tempo em que permite o agendamento eficiente de trabalhos e a alocação de recursos. Por outro lado, vários *clusters* devem ser usados quando há fortes requisitos de segurança, dados ou isolamento operacional entre cargas de trabalho. Por exemplo, se você precisar gerenciar e operar cargas de trabalho de forma independente, com diferentes cronogramas, ciclos de atualização ou políticas de acesso, vários clusters são mais apropriados.
**Filas de clusters e cotas de recursos de computação**
| Recurso | Quota |
| --- | --- |
| [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | 50 filas por cluster |
| [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 50 recursos de computação por fila 50 recursos de computação por cluster |
**Contagem de nós**
Cada recurso de computação em [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) para uma fila deve ter um [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name), [`InstanceType`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType), [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount), e [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) exclusivos. [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) e [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) têm valores padrão que definem o intervalo de instâncias de um recurso de computação em [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) para uma fila. Você também pode especificar seus próprios valores para [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) e [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount). Cada recurso de computação em [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) é composto por nós estáticos numerados de 1 até o valor de [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) e nós dinâmicos numerados do valor de [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) até o valor de [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount).
**Exemplo de configuração**
A seguir, veja um exemplo de uma seção de [Programação](Scheduling-v3.md) para um arquivo de configuração de cluster. Nessa configuração, há duas filas nomeadas `queue1` e `queue2` e cada uma delas tem uma [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) com uma [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) especificada.
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
- InstanceType: c4.xlarge
MaxCount: 5
Name: c4xlarge
- Name: queue2
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
```
**Hostnames**
As instâncias que são lançadas na frota de computação são atribuídas dinamicamente. Os nomes de host são gerados para cada nó. Por padrão, AWS ParallelCluster usará o seguinte formato do nome do host:
`$HOSTNAME=$QUEUE-$STATDYN-$COMPUTE_RESOURCE-$NODENUM`
+ `$QUEUE` é o nome da fila. Por exemplo, se a seção [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) tiver uma entrada com o [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Name) definido como “`queue-name`”, então “`$QUEUE`” será “`queue-name`”.
+ `$STATDYN` é `st` para nós estáticos ou `dy` para nós dinâmicos.
+ `$COMPUTE_RESOURCE` é o [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name) do recurso de computação [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) correspondente a esse nó.
+ `$NODENUM` é o número do nó. `$NODENUM` fica entre um (1) e o valor de [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) para nós estáticos e entre um (1) e [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)-[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) para nós dinâmicos.
Do arquivo de configuração de exemplo acima, um determinado nó da `queue1` e um recurso de computação `c5xlarge` têm um nome de host: `queue1-dy-c5xlarge-1`.
Tanto os nomes de host quanto os nomes de domínio totalmente qualificados (FQDN) são criados usando zonas hospedadas do Amazon Route 53. O FQDN é `$HOSTNAME.$CLUSTERNAME.pcluster`, sendo `$CLUSTERNAME` o nome do cluster.
Observe que o mesmo formato também será usado para os nomes de nós Slurm.
Os usuários podem escolher usar o EC2 nome de host padrão da Amazon da instância que alimenta o nó de computação em vez do formato de nome de host padrão usado por. AWS ParallelCluster Isso pode ser feito definindo o parâmetro [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) como verdadeiro. No entanto, os nomes dos Slurm nós continuarão usando o AWS ParallelCluster formato padrão.
# 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 do
A 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 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, 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#`) em `sinfo`. Um nó faz a transição automática para um estado `POWER_UP` quando Slurm aloca uma tarefa para um nó em um estado `POWER_SAVING`.
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 instâncias do EC2 são iniciadas e configuradas, e ocorre a transição do nó para o estado `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 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%`) em `sinfo`. Os nós dinâmicos entram automaticamente no estado `POWER_DOWN` depois do [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime).
A opção [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) é salva na opção `SuspendTimeout` da configuração Slurm.
+ **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.
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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 os nós que não estão disponíveis, o campo `NodeAddr` 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` ou `static`.)
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" -N 1 -C static
```
Envia um trabalho para um nó dinâmico na 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` na 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 na fila `gpu`.
```
$ sbatch --wrap "sleep 300" -p gpu -G 1
```
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 obter mais informações, consulte [`clustermgtd`](processes-v3.md#clustermgtd-v3).
## 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 \
--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
```
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 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.
## 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_up
```
Você 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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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
```
## 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-spotcompute1-[1-2]`).
+ `ResumeProgram` inicializa duas instâncias do Amazon EC2 e atribui os endereços IP privados e nomes de host de `queue1-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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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]`).
+ `ResumeProgram` inicia somente 1 (uma) instância do Amazon EC2 e configura `queue1-dy-spotcompute1-1`, com 1 (uma) instância, `queue1-dy-spotcompute1-2`, falhando na inicialização.
+ `queue1-dy-spotcompute1-1` não é afetado e fica on-line depois de chegar ao estado `POWER_UP`.
+ `queue1-dy-spotcompute1-2` faz a transição para o estado `POWER_DOWN` 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 o tempo que Slurm espera antes da transição do nó para o estado inativo.
+ Pode ser útil estender `ResumeTimeout` se o processo de pre/post instalação demorar quase esse tempo.
+ `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. 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 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 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.
## 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`{hostname}.{instance_id}.{logIdentifier}`, que *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 se `ResumeProgram` foi chamado com o nó. Caso contrário, verifique o log `slurmctld` para determinar se Slurm 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 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**
+ 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 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 teve eventos programados ou falhou nas verificações do status de integridade do Amazon 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 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 log `clustermgtd` para ver por que ele não conseguiu substituir ou encerrar um nó.
+ Se os nós dinâmicos falharem por [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 de instâncias e redefinições de `NodeAddr` são concluídos por `clustermgtd`. Slurm faz a transição dos 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.
# Slurm modo protegido por cluster
Quando um cluster é executado com o modo protegido ativado, AWS ParallelCluster monitora e rastreia as falhas de bootstrap do nó de computação à medida que os nós de computação são iniciados. Ele faz isso para detectar se essas falhas estão ocorrendo continuamente.
Se o seguinte for detectado em uma fila (partição), o cluster entrará no status protegido:
1. Falhas consecutivas de bootstrap do nó de computação ocorrem continuamente sem nenhuma inicialização bem-sucedida do nó de computação.
1. A contagem de falhas atinge um limite predefinido.
Depois que o cluster entra no status protegido, AWS ParallelCluster desativa as filas com falhas no limite predefinido ou acima dele.
Slurm o modo protegido por cluster foi adicionado na AWS ParallelCluster versão 3.0.0.
Você pode usar o modo protegido para reduzir o tempo e os recursos gastos no ciclo de falhas de bootstrap do nó de computação.
## Parâmetro do modo protegido
**`protected_failure_count`**
`protected_failure_count` especifica o número de falhas consecutivas em uma fila (partição) que ativam o status de cluster protegido.
O padrão `protected_failure_count` é 10 e o modo protegido está ativado.
Se `protected_failure_count` for maior que zero, o modo protegido será ativado.
Se `protected_failure_count` for menor ou igual a zero, o modo protegido será desativado.
Você pode alterar o valor de `protected_failure_count` adicionando o parâmetro no arquivo de configuração `clustermgtd` localizado em `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` no `HeadNode`.
Você pode atualizar esse parâmetro a qualquer momento e não precisa interromper a frota de computação para fazer isso. Se uma inicialização for bem-sucedida em uma fila antes que a contagem de falhas chegue a `protected_failure_count`, a contagem de falhas será redefinida para zero.
## Verificação de status do cluster no status protegido
Quando um cluster está no status protegido, você pode verificar o status da frota de computação e os estados dos nós.
### Status da frota de computação
O status da frota de computação é `PROTECTED` em um cluster executado em status protegido.
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### Status do nó
Para saber quais filas (partições) têm falhas de bootstrap que ativaram o status protegido, faça login no cluster e execute o comando `sinfo`. Partições com falhas de bootstrap iguais ou superiores a `protected_failure_count` ficam no estado `INACTIVE`. Partições sem falhas de bootstrap iguais ou superiores a `protected_failure_count` ficam no estado `UP` e funcionam conforme esperado.
O status `PROTECTED` não afeta os trabalhos em execução. Se os trabalhos estiverem sendo executados em uma partição com falhas de bootstrap iguais ou superiores a `protected_failure_count`, a partição será definida como `INACTIVE` após a conclusão dos trabalhos em execução.
Considere os estados dos nós mostrados no exemplo a seguir.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
A partição `queue1` é `INACTIVE` porque foram detectadas 10 falhas consecutivas de bootstrap do nó de computação.
As instâncias por trás dos nós `queue1-dy-c5xlarge-[1-10]` foram iniciadas, mas falharam em se juntar ao cluster devido a um status não íntegro.
O cluster está em status protegido.
A partição `queue2` não é afetada pelas falhas de bootstrap em `queue1`. Está no estado `UP` e ainda pode executar trabalhos.
## Como desativar o status protegido
Depois que o erro de bootstrap for resolvido, você poderá executar o comando a seguir para tirar o cluster do status protegido.
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## Falhas de bootstrap que ativam o status protegido
Os erros de bootstrap que ativam o status protegido são subdivididos nos três tipos a seguir. Para identificar o tipo e o problema, você pode verificar se os registros AWS ParallelCluster foram gerados. Se os logs foram gerados, você pode verificá-los para obter detalhes do erro. Para obter mais informações, consulte [Recuperando e preservando logs](troubleshooting-v3-get-logs.md).
1. **Erro de bootstrap que faz com que uma instância seja encerrada automaticamente**.
Uma instância falha no início do processo de bootstrap, como uma instância que se encerra automaticamente devido a erros no script [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) \$1 [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions) \$1 [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart) \$1 [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured).
Para nós dinâmicos, procure erros semelhantes aos seguintes:
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
Para nós estáticos, procure no log `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) por erros semelhantes aos seguintes:
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. **Os nós `resume_timeout` ou `node_replacement_timeout` expiraram**.
Uma instância não pode se juntar ao cluster em `resume_timeout` (para nós dinâmicos) ou `node_replacement_timeout` (para nós estáticos). Ele não encerra automaticamente antes do tempo limite. Por exemplo, a rede não está configurada corretamente para o cluster e o nó é definido para o `DOWN` estado por Slurm depois que o tempo limite expirar.
Para nós dinâmicos, procure erros semelhantes aos seguintes:
```
Node bootstrap error: Resume timeout expires for node
```
Para nós estáticos, procure no log `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) por erros semelhantes aos seguintes:
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. **Os nós falham na verificação de integridade**.
Uma instância atrás do nó falha em uma verificação de EC2 saúde da Amazon ou em uma verificação de integridade de um evento agendado, e os nós são tratados como nós de falha de bootstrap. Nesse caso, a instância é encerrada por um motivo fora do controle do AWS ParallelCluster.
Procure no log `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) por erros semelhantes aos seguintes:
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. **Os nós de computação falham Slurm registro**.
O registro do `slurmd` daemon com o Slurm control daemon (`slurmctld`) falha e faz com que o estado do nó de computação mude para o estado. `INVALID_REG` Configurado incorretamente Slurm nós de computação podem causar esse erro, como nós computados configurados com erros de especificação de nós de [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)computação.
Procure no arquivo de log `slurmctld` (`/var/log/slurmctld.log`) no nó principal ou no arquivo de log `slurmd` (`/var/log/slurmd.log`) do nó de computação com falha em busca de erros semelhantes aos seguintes:
```
Setting node %s to INVAL with reason: ...
```
## Como depurar o modo protegido
Se seu cluster estiver em status protegido e se forem AWS ParallelCluster gerados `clustermgtd` registros dos `HeadNode` e dos `cloud-init-output` nós de computação problemáticos, você poderá verificar os registros para ver os detalhes do erro. Para obter mais informações sobre recuperação de logs, consulte [Recuperando e preservando logs](troubleshooting-v3-get-logs.md).
**Log `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) no nó principal**
As mensagens de log mostram quais partições têm falhas de bootstrap e a contagem de falhas de bootstrap correspondente.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
No log `clustermgtd`, pesquise por `Found the following bootstrap failure nodes` para descobrir qual nó falhou no bootstrap.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
No log `clustermgtd`, pesquise por `Node bootstrap error` para descobrir o motivo da falha.
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
**log `cloud-init-output` (`/var/log/cloud-init-output.log`) nos nós de computação**
Depois de obter o endereço IP privado do nó de falha de bootstrap no log `clustermgtd`, você pode encontrar o log do nó de computação correspondente fazendo login no nó de computação ou seguindo as orientações em [Recuperando e preservando logs](troubleshooting-v3-get-logs.md) para recuperar os logs. Na maioria dos casos, o log `/var/log/cloud-init-output` do nó problemático mostra a etapa que causou a falha de bootstrap do nó de computação.
# Failover rápido de capacidade insuficiente do cluster Slurm
A partir da AWS ParallelCluster versão 3.2.0, os clusters são executados com o modo de failover rápido de capacidade insuficiente ativado por padrão. Isso minimiza o tempo gasto tentando enfileirar um trabalho quando erros de capacidade insuficiente do Amazon EC2 são detectados. Isso é particularmente eficaz quando você configura sua fila com vários recursos computacionais que usam tipos de instância diferentes.
**O Amazon EC2 detectou falhas de capacidade insuficiente:**
+ `InsufficientInstanceCapacity`
+ `InsufficientHostCapacity`
+ `InsufficientReservedInstanceCapacity`
+ `MaxSpotInstanceCountExceeded`
+ `SpotMaxPriceTooLow`: ativado se o seu preço de solicitação spot é inferior ao preço mínimo de atendimento de solicitação spot exigido.
+ `Unsupported`: ativado com o uso de um tipo de instância que não é compatível com uma instância específica Região da AWS.
No modo rápido de failure-over de capacidade insuficiente, se um erro de capacidade insuficiente for detectado quando uma tarefa for atribuída a [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`compute resource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources), AWS ParallelCluster faça o seguinte:
1. Ele define o recurso de computação para um estado desativado (`DOWN`) por um período de tempo predefinido.
1. Ele usa `POWER_DOWN_FORCE` para cancelar as tarefas do nó com falha do recurso de computação e para suspender o nó com falha. Ele define o nó com falha para o estado `IDLE` e `POWER_DOWN (!)` e, em seguida, para `POWERING_DOWN (%)`.
1. Ele enfileira o trabalho em outro recurso de computação.
Os nós estáticos e ativados do recurso de computação desativado não são afetados. Os trabalhos podem ser concluídos nesses nós.
Esse ciclo se repete até que o trabalho seja atribuído com êxito a um ou mais nós de recursos de computação. Para mais informações sobre os estados dos nós, consulte [Guia do Slurm para o modo de várias filas](multiple-queue-mode-slurm-user-guide-v3.md).
Se nenhum recurso de computação for encontrado para executar o trabalho, o trabalho será definido no estado `PENDING` até que o período de tempo predefinido termine. Nesse caso, você pode modificar o período de tempo predefinido conforme descrito na seção a seguir.
## Parâmetro de tempo limite de capacidade insuficiente
**`insufficient_capacity_timeout`**
`insufficient_capacity_timeout` especifica o período de tempo (em segundos) em que o recurso de computação é mantido no estado desativado (`down`) quando um erro de capacidade insuficiente é detectado.
Por padrão, `insufficient_capacity_timeout` é habilitado.
O `insufficient_capacity_timeout` padrão é 600 segundos (10 minutos).
Se o valor `insufficient_capacity_timeout` for menor ou igual a zero, o modo de failover rápido de capacidade insuficiente será desativado.
Você pode alterar o valor de `insufficient_capacity_timeout` adicionando o parâmetro no arquivo de configuração `clustermgtd` localizado em `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` no `HeadNode`.
O parâmetro pode ser atualizado a qualquer momento, sem interromper a frota de computação.
Por exemplo:
+ `insufficient_capacity_timeout=600`:
Se um erro de capacidade insuficiente for detectado, o recurso de computação será definido como desativado (`DOWN`). Após 10 minutos, seu nó com falha é definido para o estado `idle~` (`POWER_SAVING`).
+ `insufficient_capacity_timeout=60`:
Se um erro de capacidade insuficiente for detectado, o recurso de computação será definido como desativado (`DOWN`). Após 1 minuto, seu nó com falha é definido para o estado `idle~`.
+ `insufficient_capacity_timeout=0`:
O modo de failover rápido de capacidade insuficiente é desativado. O recurso de computação não é desativado.
**nota**
Pode haver um atraso de até um minuto entre o momento em que os nós falham com erros de capacidade insuficientes e o momento em que o daemon de gerenciamento de cluster detecta as falhas do nó. Isso ocorre porque o daemon de gerenciamento de cluster verifica falhas de capacidade insuficiente do nó e define os recursos de computação para o `down` estado em intervalos de um minuto.
## Status do modo de failover rápido de capacidade insuficiente
Quando um cluster está no modo de failover rápido e de capacidade insuficiente, você pode verificar seu status e os estados dos nós.
### Estados do nó
Quando uma tarefa é enviada a um nó dinâmico de recursos de computação e um erro de capacidade insuficiente é detectado, o nó é colocado nesse estado `down#` com razão.
```
(Code:InsufficientInstanceCapacity)Failure when resuming nodes.
```
Depois os nós desligados (nós no estado `idle~`) são configurados para `down~` com razão.
```
(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity.
```
O trabalho é enfileirado para outros recursos de computação na fila.
Os nós estáticos do recurso de computação e os nós que são `UP` não são afetados pelo modo de failover rápido de capacidade insuficiente.
Considere os estados dos nós mostrados no exemplo a seguir.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Enviamos um trabalho para a queue1, que requer um nó.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 1 down# queue1-dy-c-1-1
queue1* up infinite 15 idle~ queue1-dy-c-2-[1-15]
queue1* up infinite 14 down~ queue1-dy-c-1-[2-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
O nó `queue1-dy-c-1-1` é iniciado para executar o trabalho. No entanto, a instância falhou ao ser iniciada devido a um erro de capacidade insuficiente. O nó `queue1-dy-c-1-1` está definido como `down`. O nó dinâmico desligado dentro do recurso de computação (`queue2-dy-c-1`) está definido como `down`.
Você pode verificar a razão do nó com `scontrol show nodes`.
```
$ scontrol show nodes queue1-dy-c-1-1
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Failure when resuming nodes [root@2022-03-10T22:17:50]
$ scontrol show nodes queue1-dy-c-1-2
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity [root@2022-03-10T22:17:50]
```
O trabalho é enfileirado em outro tipo de instância dentro dos recursos de computação da fila.
Depois de decorrido o `insufficient_capacity_timeout`, os nós no recurso de computação são redefinidos para o estado `idle~`.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Depois de decorrido o `insufficient_capacity_timeout` e os nós no recurso de computação são redefinidos para o estado `idle~`, o programador Slurm atribui prioridade menor aos nós. O programador continua selecionando nós de outros recursos de computação da fila com pesos maiores, a menos que ocorra uma das seguintes situações:
+ Os requisitos de envio de um trabalho correspondem ao recurso de computação recuperado.
+ Nenhum outro recurso de computação está disponível porque eles estão lotados.
+ `slurmctld` é reiniciado.
+ A frota de AWS ParallelCluster computação é interrompida e começa a desligar e ligar todos os nós.
### Logs relacionados
Os logs relacionados a erros de capacidade insuficiente e ao modo rápido de failover de capacidade insuficiente podem ser encontrados no log `resume` do Slurm e no log `clustermgtd` no nó principal.
**Slurm `resume` (`/var/log/parallelcluster/slurm_resume.log`)**
Mensagens de erro quando um nó falha na inicialização devido à capacidade insuficiente.
```
[slurm_plugin.instance_manager:_launch_ec2_instances] - ERROR - Failed RunInstances request: dcd0c252-90d4-44a7-9c79-ef740f7ecd87
[slurm_plugin.instance_manager:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['queue1-dy-c-1-1']: An error occurred
(InsufficientInstanceCapacity) when calling the RunInstances operation (reached max retries: 1): We currently do not have sufficient p4d.24xlarge capacity in the
Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get p4d.24xlarge capacity by not
specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
```
**Slurm `clustermgtd` (`/var/log/parallelcluster/clustermgtd`)**
O recurso de computação c-1 em queue1 está desativado devido à capacidade insuficiente.
```
[slurm_plugin.clustermgtd:_reset_timeout_expired_compute_resources] - INFO - The following compute resources are in down state
due to insufficient capacity: {'queue1': {'c-1': ComputeResourceFailureEvent(timestamp=datetime.datetime(2022, 4, 14, 23, 0, 4, 769380, tzinfo=datetime.timezone.utc),
error_code='InsufficientInstanceCapacity')}}, compute resources are reset after insufficient capacity timeout (600 seconds) expired
```
Depois que o tempo limite de capacidade insuficiente expirar, o recurso de computação é redefinido e os nós dentro dos recursos de computação são definidos como `idle~`.
```
[root:_reset_insufficient_capacity_timeout_expired_nodes] - INFO - Reset the following compute resources because insufficient capacity
timeout expired: {'queue1': ['c-1']}
```
# Slurm agendamento baseado em memória
A partir da versão 3.2.0, suporta AWS ParallelCluster Slurm agendamento baseado em memória com o parâmetro de configuração [`SlurmSettings`[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/cluster.
**nota**
[A partir da AWS ParallelCluster versão 3.7.0, `EnableMemoryBasedScheduling` pode ser ativado se você configurar vários tipos de instância em Instâncias.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Para AWS ParallelCluster as versões 3.2.0 a 3.6. *x*, não `EnableMemoryBasedScheduling` pode ser ativado se você configurar vários tipos de instância em [Instâncias](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
**Atenção**
Quando você especifica vários tipos de instâncias em um Slurm recurso de computação de fila com `EnableMemoryBasedScheduling` ativado, o `RealMemory` valor é a quantidade mínima de memória disponibilizada para todos os tipos de instância. Isso pode resultar em quantidades significativas de memória não utilizada se você especificar tipos de instância com capacidades de memória muito diferentes.
Com`EnableMemoryBasedScheduling: true`, o Slurm O agendador rastreia a quantidade de memória que cada trabalho exige em cada nó. Então, o Slurm O agendador usa essas informações para agendar vários trabalhos no mesmo nó de computação. A quantidade total de memória que os trabalhos exigem em um nó não pode ser maior do que a memória disponível do nó. O programador impede que um trabalho use mais memória do que a solicitada quando o trabalho foi enviado.
Com `EnableMemoryBasedScheduling: false`, os trabalhos podem competir pela memória em um nó compartilhado e causar falhas no trabalho e eventos `out-of-memory`.
**Atenção**
Slurm usa uma notação de potência de 2 para seus rótulos, como MB ou GB. Leia esses rótulos como MiB e GiB, respectivamente.
## Slurm configuração e agendamento baseado em memória
Com`EnableMemoryBasedScheduling: true`, Slurm define o seguinte Slurm parâmetros de configuração:
+ [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory) no `slurm.conf`. Essa opção configura a memória do nó para ser um recurso consumível no Slurm.
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)no Slurm `cgroup.conf`. Com essa opção, o acesso de um trabalho à memória é limitado à quantidade de memória que o trabalho solicitou quando enviado.
**nota**
Vários outros Slurm os parâmetros de configuração podem afetar o comportamento do Slurm agendador e gerenciador de recursos quando essas duas opções são definidas. Para obter mais informações, consulte o [.Slurm Documentação](https://slurm.schedmd.com/documentation.html).
## Slurm agendador e agendamento baseado em memória
**`EnableMemoryBasedScheduling: false` (padrão)**
Por padrão, `EnableMemoryBasedScheduling` é definido como falso. Quando falso, Slurm não inclui memória como recurso em seu algoritmo de agendamento e não rastreia a memória que os trabalhos usam. Os usuários podem especificar a opção `--mem MEM_PER_NODE` para definir a quantidade mínima de memória por nó que um trabalho exige. Isso força o programador a escolher nós com um valor `RealMemory` de pelo menos `MEM_PER_NODE` ao agendar o trabalho.
Por exemplo, suponha que um usuário envie dois trabalhos com `--mem=5GB`. Se os recursos solicitados, como CPUs ou GPUs estiverem disponíveis, os trabalhos poderão ser executados ao mesmo tempo em um nó com 8 GiB de memória. As duas tarefas não estão programadas em nós de computação com menos de 5 GiB de `RealMemory`.
**Atenção**
Quando o agendamento baseado em memória está desativado, Slurm não rastreia a quantidade de memória que os trabalhos usam. Os trabalhos executados no mesmo nó podem competir por recursos de memória e fazer com que o outro trabalho falhe.
Quando a programação baseada em memória está desativada, recomendamos que os usuários não especifiquem as opções [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu) ou [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu). Essas opções podem causar um comportamento diferente do descrito no [Slurm Documentação](https://slurm.schedmd.com/documentation.html).
**`EnableMemoryBasedScheduling: true`**
Quando `EnableMemoryBasedScheduling` está definido como verdadeiro, Slurm rastreia o uso da memória de cada trabalho e impede que os trabalhos usem mais memória do que a solicitada com as opções de `--mem` envio.
Usando o exemplo anterior, um usuário envia dois trabalhos com `--mem=5GB`. Os trabalhos não podem ser executados ao mesmo tempo em um nó com 8 GiB de memória. Isso ocorre porque a quantidade total de memória necessária é maior do que a memória disponível no nó.
Com o agendamento baseado em memória ativado `--mem-per-cpu` e `--mem-per-gpu` se comporte de forma consistente com o que está descrito no Slurm documentação. Por exemplo, um trabalho é enviado com `--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB`. Nesse caso, Slurm atribui ao trabalho um total de 4 GiB para cada nó.
**Atenção**
Quando a programação baseada em memória está ativada, recomendamos que os usuários incluam uma especificação `--mem` ao enviar um trabalho. Com o padrão Slurm configuração incluída com AWS ParallelCluster, se nenhuma opção de memória estiver incluída (`--mem`,`--mem-per-cpu`, ou`--mem-per-gpu`), Slurm atribui toda a memória dos nós alocados ao trabalho, mesmo que ele solicite somente uma parte dos outros recursos, como CPUs ou. GPUs Isso evita efetivamente o compartilhamento de nós até que o trabalho seja concluído, pois não há memória disponível para outros trabalhos. Isso acontece porque Slurm define a memória por nó da tarefa para [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)quando nenhuma especificação de memória for fornecida no momento do envio da tarefa. O valor padrão para esse parâmetro é 0 e especifica o acesso ilimitado à memória de um nó.
Se vários tipos de recursos de computação com quantidades diferentes de memória estiverem disponíveis na mesma fila, um trabalho enviado sem opções de memória poderá receber quantidades diferentes de memória em nós diferentes. Isso depende de quais nós o programador disponibiliza para o trabalho. Os usuários podem definir um valor personalizado para opções, como `DefMemPerNode` ou [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU), no nível do cluster ou da partição no Slurm arquivos de configuração para evitar esse comportamento.
## Slurm RealMemory and AWS ParallelCluster SchedulableMemory
do Slurm configuração que é fornecida com AWS ParallelCluster, Slurm interpreta como [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)a quantidade de memória por nó disponível para trabalhos. A partir da versão 3.2.0, por padrão, é AWS ParallelCluster definida `RealMemory` como 95% da memória listada nos [tipos de EC2 instância da Amazon](https://aws.amazon.com/ec2/instance-types) e retornada pela EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)da Amazon.
Quando o agendamento baseado em memória é desativado, o Slurm O agendador usa `RealMemory` para filtrar os nós quando os usuários enviam um trabalho com o `--mem` especificado.
Quando o agendamento baseado em memória está ativado, o Slurm O agendador interpreta como `RealMemory` a quantidade máxima de memória disponível para trabalhos em execução no nó de computação.
A configuração padrão pode não ser ideal para todos os tipos de instância:
+ Essa configuração pode ser maior do que a quantidade de memória que os nós podem realmente acessar. Isso pode acontecer quando os nós de computação são tipos de instâncias pequenas.
+ Essa configuração pode ser maior do que a quantidade de memória que os nós podem realmente acessar. Isso pode acontecer quando os nós de computação são tipos de instância grandes e podem levar a uma quantidade significativa de memória não utilizada.
Você pode usar [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)para ajustar o valor de `RealMemory` configure by AWS ParallelCluster para nós de computação. Para substituir o padrão, defina um valor personalizado para `SchedulableMemory` especificamente para sua configuração de cluster.
Para verificar a memória real disponível de um nó de computação, execute o comando `/opt/slurm/sbin/slurmd -C` no nó. Esse comando retorna a configuração de hardware do nó, incluindo o valor [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory). Para obter mais informações, consulte [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C).
Certifique-se de que os processos do sistema operacional do nó de computação tenham memória suficiente. Para fazer isso, limite a memória disponível para trabalhos definindo o valor de `SchedulableMemory` como menor do que o valor de `RealMemory` retornado pelo comando `slurmd -C`.
# Alocação a vários tipos de instância com o Slurm
A partir da AWS ParallelCluster versão 3.3.0, você pode configurar seu cluster para alocar a partir do conjunto de tipos de instância definidos de um recurso computacional. A alocação pode ser baseada em estratégias de baixo custo ou capacidade ideal da EC2 frota da Amazon.
Esse conjunto de tipos de instância definidos deve ter todos o mesmo número de v CPUs ou, se o multithreading estiver desativado, o mesmo número de núcleos. Além disso, esse conjunto de tipos de instância deve ter o mesmo número de aceleradores dos mesmos fabricantes. Se [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa) / [`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa-Enabled) estiver definido como `true`, as instâncias devem ter suporte ao EFA. Para obter mais informações e requisitos, consulte [`Scheduling`](Scheduling-v3.md) / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy) e [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) / [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Você pode [`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)definir como `lowest-price` ou `capacity-optimized` dependendo da sua [CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType)configuração.
Em [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances), você pode configurar um conjunto de tipos de instância.
**nota**
[A partir da AWS ParallelCluster versão 3.7.0, `EnableMemoryBasedScheduling` pode ser ativado se você configurar vários tipos de instância em Instâncias.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Para AWS ParallelCluster as versões 3.2.0 a 3.6. *x*, não `EnableMemoryBasedScheduling` pode ser ativado se você configurar vários tipos de instância em [Instâncias](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Os exemplos a seguir mostram como você pode consultar tipos de instância para vCPUs, suporte ao EFA e arquitetura.
Consulta InstanceTypes com arquitetura 96 v CPUs e x86\$164.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-vcpus,Values=96" "Name=processor-info.supported-architecture,Values=x86_64" \
--query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
Consulta InstanceTypes com 64 núcleos, suporte a EFA e arquitetura arm64.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-cores,Values=64" "Name=processor-info.supported-architecture,Values=arm64" "Name=network-info.efa-supported,Values=true" --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
O próximo exemplo de trecho de configuração de cluster mostra como você pode usá-los. InstanceType and AllocationStrategy propriedades.
```
...
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-1
CapacityType: ONDEMAND
AllocationStrategy: lowest-price
...
ComputeResources:
- Name: computeresource1
Instances:
- InstanceType: r6g.2xlarge
- InstanceType: m6g.2xlarge
- InstanceType: c6g.2xlarge
MinCount: 0
MaxCount: 500
- Name: computeresource2
Instances:
- InstanceType: m6g.12xlarge
- InstanceType: x2gd.12xlarge
MinCount: 0
MaxCount: 500
...
```
# Dimensionamento de clusters para nós dinâmicos
ParallelCluster suporta Slurm métodos para escalar dinamicamente clusters usando o plug-in Slurm de economia de energia. Para obter mais informações, consulte o [Cloud Scheduling Guide](https://slurm.schedmd.com/elastic_computing.html) e o [Power Saving Guide do Slurm](https://slurm.schedmd.com/power_save.html) na documentação do Slurm. Os tópicos a seguir descrevem as estratégias do Slurm de cada versão.
**Topics**
+ [Estratégias de alocação dinâmica de nós do Slurm na versão 3.8.0](scheduler-node-allocation-v3-3.8.0.md)
+ [Estratégias de alocação dinâmica de nós do Slurm na versão 3.7.x](scheduler-dynamic-node-allocation-v3-3.7.x.md)
+ [Estratégias de alocação dinâmica de nós do Slurm na versão 3.6.x e anteriores](scheduler-dynamic-node-allocation-v3-3.6.x.md)
# Estratégias de alocação dinâmica de nós do Slurm na versão 3.8.0
A partir da ParallelCluster versão 3.8.0, ParallelCluster usa o **currículo no nível do trabalho** **ou o escalonamento no nível** do trabalho como a estratégia padrão de alocação dinâmica de nós para ParallelCluster escalar o cluster: expande o cluster com base nos requisitos de cada trabalho, no número de nós alocados para o trabalho e nos nós que precisam ser retomados. ParallelCluster obtém essas informações da variável de ambiente SLURM\$1RESUME\$1FILE.
A escala para nós dinâmicos é um processo de duas etapas, que envolve o lançamento das instâncias do EC2 e a atribuição das instâncias do Amazon EC2 lançadas aos nós do Slurm. Cada uma dessas duas etapas pode ser executada usando uma lógica **all-or-nothing**de **melhor esforço**.
Para o lançamento das instâncias do Amazon EC2:
+ **all-or-nothing**chama a API de lançamento do Amazon EC2 com meta mínima igual à capacidade alvo total
+ **melhor esforço** chama a API Amazon EC2 de lançamento com meta mínima igual a 1 e a capacidade total da meta igual à capacidade solicitada
Para atribuição de instâncias do Amazon EC2 aos nós Slurm:
+ **all-or-nothing**atribui instâncias do Amazon EC2 Slurm aos nós somente se for possível atribuir uma instância do Amazon EC2 a cada nó solicitado
+ **melhor esforço** atribui instâncias do Amazon EC2 aos nós do Slurm, mesmo que todos os nós solicitados não sejam cobertos pela capacidade da instância do Amazon EC2
As combinações possíveis das estratégias acima se traduzem nas estratégias de ParallelCluster lançamento.
**Example** [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)
**all-or-nothing**dimensionamento:
Essa estratégia envolve AWS ParallelCluster iniciar uma chamada de API de instância de lançamento do Amazon EC2 para cada trabalho, o que exige que todas as instâncias necessárias para que os nós de computação solicitados sejam executados com sucesso. Isso garante que o cluster seja escalado somente quando a capacidade necessária por trabalho estiver disponível, evitando instâncias ociosas deixadas no final do processo de escalabilidade.
A estratégia usa uma **all-or-nothing**lógica para o lançamento das instâncias do Amazon EC2 para cada job plus e uma **all-or-nothing**lógica para a atribuição das instâncias do Amazon EC2 aos nós. Slurm
Os grupos de estratégias iniciam solicitações em lotes, uma para cada recurso computacional solicitado e até 500 nós cada. Para solicitações que abrangem vários recursos computacionais ou excedem 500 nós, processa ParallelCluster sequencialmente vários lotes.
A falha do lote de um único recurso resulta no encerramento de toda a capacidade não utilizada associada, garantindo que nenhuma instância ociosa seja deixada no final do processo de escalabilidade.
Limitações
+ O tempo necessário para escalar é diretamente proporcional ao número de trabalhos enviados por execução do programa de currículo do Slurm.
+ A operação de escalabilidade é limitada pelo limite da conta de RunInstances recursos, definido em 1.000 instâncias por padrão. Essa limitação está de acordo com as políticas de limitação de API AWS do EC2. Para obter mais detalhes, consulte a documentação de limitação de API do [Amazon](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html) EC2
+ Quando você envia um trabalho em um recurso computacional com um único tipo de instância, em uma fila que abrange várias zonas de disponibilidade, a chamada da API de inicialização do **all-or-nothing**EC2 só é bem-sucedida se toda a capacidade puder ser fornecida em uma única zona de disponibilidade.
+ Quando você envia um trabalho em um recurso computacional com vários tipos de instância, em uma fila com uma única zona de disponibilidade, a **all-or-nothing**chamada da API de lançamento do Amazon EC2 só é bem-sucedida se toda a capacidade puder ser fornecida por um único tipo de instância.
+ **Quando você envia um trabalho em um recurso computacional com vários tipos de instância, em uma fila que abrange várias zonas de disponibilidade, a chamada da API de lançamento do **all-or-nothing**Amazon EC2 não é suportada e ParallelCluster , em vez disso, executa o melhor esforço de escalabilidade.**
**greedy-all-or-nothing**dimensionamento:
Essa variante da all-or-nothing estratégia ainda garante que o cluster seja escalado somente quando a capacidade necessária por trabalho estiver disponível, evitando instâncias ociosas no final do processo de escalabilidade, mas envolve ParallelCluster iniciar uma chamada de API de instância de lançamento do Amazon EC2 que visa uma capacidade mínima de destino de 1, tentando maximizar o número de nós lançados até a capacidade solicitada. A estratégia usa uma lógica de melhor esforço para o lançamento das instâncias do EC2 para todos os trabalhos, além da **all-or-nothing**lógica para a atribuição das instâncias do Amazon EC2 aos Slurm nós de cada trabalho.
Os grupos de estratégias iniciam solicitações em lotes, uma para cada recurso computacional solicitado e até 500 nós cada. Para solicitações que abrangem vários recursos computacionais ou excedem 500 nós, processa ParellelCluster sequencialmente vários lotes.
Ele garante que nenhuma instância seja deixada ociosa no final do processo de escalabilidade, maximizando o throughput ao custo da escalabilidade excessiva temporária durante o processo.
Limitações
+ A escalabilidade excessiva temporária é possível, gerando custos adicionais para instâncias que fazem a transição para um estado de execução antes da conclusão da escalabilidade.
+ O mesmo limite de instância da all-or-nothing estratégia se aplica, sujeito ao limite AWS da conta de RunInstances recursos da.
Escalabilidade de **melhor esforço**:
Essa estratégia chama a chamada de API de instância de lançamento do Amazon EC2 visando uma capacidade mínima de 1 e buscando atingir a capacidade total solicitada ao custo de deixar instâncias ociosas após a execução do processo de escalabilidade, caso nem toda a capacidade solicitada esteja disponível. A estratégia usa uma lógica de melhor esforço para o lançamento das instâncias do Amazon EC2 para todos os trabalhos, além da lógica de **melhor esforço** para a atribuição das instâncias do Amazon EC2 aos nós do Slurm para cada trabalho.
Os grupos de estratégias iniciam solicitações em lotes, uma para cada recurso computacional solicitado e até 500 nós cada. Para solicitações que abrangem vários recursos computacionais ou excedem 500 nós, processa ParallelCluster sequencialmente vários lotes.
Essa estratégia permite escalar muito além do limite padrão de 1.000 instâncias em várias execuções de processos de escalabilidade, ao custo de ter instâncias ociosas nos diferentes processos de escalabilidade.
Limitações
+ Possíveis instâncias ociosas em execução no final do processo de escalabilidade, caso não seja possível alocar todos os nós solicitados pelos trabalhos.
Veja a seguir um exemplo que mostra como o dimensionamento dos nós dinâmicos se comporta usando as diferentes **estratégias de ParallelCluster lançamento**. Suponha que você tenha enviado dois trabalhos solicitando 20 nós cada, para um total de 40 nós do mesmo tipo, mas há apenas 30 instâncias do Amazon EC2 disponíveis para cobrir a capacidade solicitada no EC2.
**all-or-nothing**dimensionamento:
+ Para o primeiro trabalho, uma API de instância de lançamento do ** all-or-nothing**Amazon EC2 é chamada, solicitando 20 instâncias. Uma chamada bem-sucedida resulta no lançamento de 20 instâncias
+ **all-or-nothing **a atribuição das 20 instâncias lançadas aos Slurm nós para o primeiro trabalho foi bem-sucedida
+ Outra API de instância de lançamento do **all-or-nothing**Amazon EC2 é chamada, solicitando 20 instâncias para o segundo trabalho. A chamada não foi bem-sucedida, pois só há capacidade para outras 10 instâncias. Nenhuma instância foi iniciada no momento
**greedy-all-or-nothing**dimensionamento:
+ Uma API de instância de execução de **melhor esforço** do Amazon EC2 é chamada, solicitando 40 instâncias, que é a capacidade total solicitada por todos os trabalhos. Isso resulta no lançamento de 30 instâncias
+ Uma **all-or-nothing**atribuição de 20 das instâncias lançadas aos Slurm nós para o primeiro trabalho foi bem-sucedida.
+ Outra **all-or-nothing**atribuição das instâncias lançadas restantes aos Slurm nós do segundo trabalho foi tentada, mas como há apenas 10 instâncias disponíveis do total de 20 solicitadas pelo trabalho, a atribuição não foi bem-sucedida
+ As 10 instâncias lançadas não atribuídas são encerradas
Escalabilidade de **melhor esforço**:
+ Uma API de instância de execução de **melhor esforço** do Amazon EC2 é chamada, solicitando 40 instâncias, que é a capacidade total solicitada por todos os trabalhos. Isso resulta no lançamento de 30 instâncias.
+ Uma atribuição de **melhor esforço** de 20 das instâncias lançadas aos nós do Slurm para o primeiro trabalho é bem-sucedida.
+ Outra atribuição de **melhor esforço** das 10 instâncias lançadas restantes aos nós do Slurm para o segundo trabalho é bem-sucedida, mesmo que a capacidade total solicitada seja 20. Mas como o trabalho estava solicitando os 20 nós e só era possível atribuir instâncias do Amazon EC2 a 10 deles, o trabalho não pode ser iniciado e as instâncias ficam ociosas até que capacidade suficiente seja encontrada para iniciar as outras 10 instâncias em uma chamada posterior do processo de escalabilidade ou até o agendador programar o trabalho em outros nós de computação já em execução.
# Estratégias de alocação dinâmica de nós do Slurm na versão 3.7.x
ParallelCluster usa dois tipos de estratégias dinâmicas de alocação de nós para escalar o cluster:
+
**Alocação com base nas informações disponíveis do nó solicitado:**
+ **Retomada de todos os nós** ou escalabilidade da **lista de nós**:
ParallelCluster aumenta o cluster com base somente nos nomes Slurm da lista de nós solicitada quando Slurm ele é `ResumeProgram` executado. Ele aloca recursos computacionais aos nós somente pelo nome do nó. A lista de nomes de nós pode se estender por vários trabalhos.
+ **Continuação em nível de trabalho** ou escalonamento **em nível de trabalho**:
ParallelCluster aumenta o cluster com base nos requisitos de cada trabalho, no número atual de nós alocados para o trabalho e nos nós que precisam ser retomados. ParallelCluster obtém essas informações da variável de `SLURM_RESUME_FILE` ambiente.
+
**Alocação com uma estratégia de execução do Amazon EC2:**
+ Escalabilidade com o **melhor esforço**:
ParallelCluster expande o cluster usando uma chamada de API de instância de execução do Amazon EC2 com a capacidade mínima de destino igual a 1, para iniciar algumas, mas não necessariamente todas, as instâncias necessárias para suportar os nós solicitados.
+ **Uma ll-or-nothing** escala:
ParallelCluster aumenta a escala do cluster usando uma chamada de API de instância de execução do Amazon EC2 que só é bem-sucedida se todas as instâncias necessárias para suportar os nós solicitados forem iniciadas. Nesse caso, ele chama a API de instância de execução do Amazon EC2 com a capacidade mínima de destino igual à capacidade total solicitada.
Por padrão, ParallelCluster usa escalabilidade de **lista** de nós com a melhor estratégia de lançamento do **Amazon** EC2 para lançar algumas, mas não necessariamente todas, as instâncias necessárias para dar suporte aos nós solicitados. Ele tenta provisionar o máximo de capacidade possível para atender ao workload enviado.
**A partir da ParallelCluster versão 3.7.0, ParallelCluster usa escalabilidade em **nível de trabalho** com uma estratégia de lançamento do **all-or-nothing**EC2 para trabalhos enviados no modo exclusivo.** Quando você envia um trabalho em modo exclusivo, o trabalho tem acesso exclusivo aos nós alocados. Para obter mais informações, consulte [EXCLUSIVE](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE) na documentação do Slurm.
Para enviar um trabalho no modo exclusivo:
+ Transmita o sinalizador exclusivo ao enviar um trabalho do Slurm para o cluster. Por exemplo, .`sbatch ... --exclusive`
OU
+ Envie um trabalho para uma fila de cluster que tenha sido configurada com [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation) definido como `true`.
Ao enviar um trabalho no modo exclusivo:
+ ParallelCluster atualmente agrupa solicitações de lançamento em lotes para incluir até 500 nós. Se um trabalho solicitar mais de 500 nós, ParallelCluster faz uma solicitação de **all-or-nothing**inicialização para cada conjunto de 500 nós e uma solicitação de inicialização adicional para o restante dos nós.
+ Se a alocação de nós estiver em um único recurso computacional, ParallelCluster fará uma solicitação de **all-or-nothing**inicialização para cada conjunto de 500 nós e uma solicitação de inicialização adicional para o restante dos nós. Se uma solicitação de execução falhar, ParallelCluster encerrará a capacidade não utilizada que foi criada por todas as solicitações de execução.
+ Se a alocação de nós abranger vários recursos computacionais, será ParallelCluster necessário fazer uma solicitação de **all-or-nothing**lançamento para cada recurso computacional. Essas solicitações também são agrupadas. Se uma solicitação de inicialização falhar para um dos recursos computacionais, ParallelCluster a capacidade não utilizada criada por todas as solicitações de inicialização do recurso computacional será encerrada.
escalabilidade **em nível de trabalho** com limitações conhecidas da estratégia de **all-or-nothing**lançamento:
+ Quando você envia um trabalho em um recurso computacional com um único tipo de instância, em uma fila que abrange várias zonas de disponibilidade, a chamada da API de inicialização do **all-or-nothing**EC2 só é bem-sucedida se toda a capacidade puder ser fornecida em uma única zona de disponibilidade.
+ Quando você envia um trabalho em um recurso computacional com vários tipos de instância, em uma fila com uma única zona de disponibilidade, a **all-or-nothing**chamada da API de lançamento do Amazon EC2 só é bem-sucedida se toda a capacidade puder ser fornecida por um único tipo de instância.
+ **Quando você envia um trabalho em um recurso computacional com vários tipos de instância, em uma fila que abrange várias zonas de disponibilidade, a chamada da API de lançamento do **all-or-nothing**Amazon EC2 não é suportada e ParallelCluster, em vez disso, executa o melhor esforço de escalabilidade.**
# Estratégias de alocação dinâmica de nós do Slurm na versão 3.6.x e anteriores
AWS ParallelCluster usa somente um tipo de estratégia dinâmica de alocação de nós para escalar o cluster:
+ Alocação com base nas informações disponíveis do nó solicitado:
+ Reinício de **todos os nós** ou escalabilidade da **lista** de nós: ParallelCluster expande o cluster com base somente nos nomes Slurm da lista de nós solicitada quando ele é executado. Slurm `ResumeProgram` Ele aloca recursos computacionais aos nós somente pelo nome do nó. A lista de nomes de nós pode se estender por vários trabalhos.
+ Alocação com uma estratégia de execução do Amazon EC2:
+ **Escalabilidade da melhor** maneira: ParallelCluster expande o cluster usando uma chamada de API de instância de lançamento do Amazon EC2 com a capacidade mínima de destino igual a 1, para iniciar algumas, mas não necessariamente todas, as instâncias necessárias para suportar os nós solicitados.
ParallelCluster usa a escalabilidade da **lista** de nós com a melhor estratégia de lançamento do **Amazon** EC2 para lançar algumas, mas não necessariamente todas, as instâncias necessárias para dar suporte aos nós solicitados. Ele tenta provisionar o máximo de capacidade possível para atender ao workload enviado.
Limitações
+ Possíveis instâncias ociosas em execução no final do processo de escalabilidade, caso não seja possível alocar todos os nós solicitados pelos trabalhos.
# Slurmcontabilidade com AWS ParallelCluster
A partir da versão 3.3.0, AWS ParallelCluster oferece suporte à Slurm contabilização com o parâmetro de configuração de cluster [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database).
A partir da versão 3.10.0, AWS ParallelCluster oferece suporte à Slurm contabilidade com um Slurmdbd externo com o parâmetro de configuração do cluster/. [SlurmSettings[ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)](Scheduling-v3.md#Scheduling-v3-SlurmSettings) É recomendado usar um Slurmdbd externo se vários clusters compartilharem o mesmo banco de dados.
Com a contabilização de Slurm, você pode integrar um banco de dados contábil externo para fazer o seguinte:
+ Gerenciar usuários do cluster ou grupos de usuários e outras entidades. Com esse recurso, você pode usar Slurm os recursos mais avançados, como imposição de limite de recursos, compartilhamento justo e. QOSs
+ Coleta e salva dados do trabalho, como o usuário que executou o trabalho, a duração do trabalho e os recursos que ele usa. Você pode visualizar os dados salvos com o utilitário `sacct`.
**nota**
AWS ParallelCluster suporta a Slurm contabilização de [Slurmservidores de banco de dados MySQL compatíveis](https://slurm.schedmd.com/accounting.html#mysql-configuration).
## Trabalhando com Slurm contabilidade usando externo Slurmdbd na AWS ParallelCluster v3.10.0 e posterior
Antes de configurar a contabilidade do Slurm, você deve ter um servidor de banco de dados do Slurmdbd externo, que se conecta a um servidor de banco de dados externo existente.
Para configurar isso, defina o seguinte:
+ O endereço do Slurmdbd servidor externo em [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)/[Host](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ExternalSlurmdbd-Host). O servidor deve existir e estar acessível a partir do nó principal.
+ A chave munge para se comunicar com o Slurmdbd servidor externo em. [MungeKeySecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-MungeKeySecretArn)
Para ver um tutorial, consulte [Criando um cluster com um externo Slurmdbd contabilidade](external-slurmdb-accounting.md).
**nota**
Você é responsável por gerenciar as entidades contábeis do banco de dados do Slurm.
A arquitetura do recurso de SlurmDB suporte AWS ParallelCluster externo permite que vários clusters compartilhem o mesmo SlurmDB e o mesmo banco de dados.
![\[\]](http://docs.aws.amazon.com/pt_br/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png)
**Atenção**
O tráfego entre AWS ParallelCluster e o externo não SlurmDB é criptografado. É recomendável executar o cluster e o SlurmDB externo em uma rede confiável.
## Trabalhando com Slurm contabilidade usando o nó principal Slurmdbd na AWS ParallelCluster v3.3.0 e versões posteriores
Antes de configurar a contabilização de Slurm, você deve ter um servidor de banco de dados externo existente e um banco de dados que use um protocolo `mysql`.
Para configurar a Slurm contabilidade com AWS ParallelCluster, você deve definir o seguinte:
+ O URI do servidor de banco de dados externo em [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri). O servidor deve existir e estar acessível a partir do nó principal.
+ Credenciais para acessar o banco de dados externo que estão definidas em [Database/[PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn)e [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName). AWS ParallelCluster usa essas informações para configurar a contabilidade no Slurm nível e o `slurmdbd` serviço no nó principal. `slurmdbd`é o daemon que gerencia a comunicação entre o cluster e o servidor do banco de dados.
Para ver um tutorial, consulte [Criação de um cluster com Slurm contabilidade](tutorials_07_slurm-accounting-v3.md).
**nota**
AWS ParallelCluster executa um bootstrap básico do banco de dados Slurm contábil definindo o usuário padrão do cluster como administrador do banco de dados no Slurm banco de dados. AWS ParallelCluster não adiciona nenhum outro usuário ao banco de dados contábil. O cliente é responsável por gerenciar as entidades de contabilização no banco de dados Slurm.
AWS ParallelCluster configura [https://slurm.schedmd.com/slurmdbd.html](https://slurm.schedmd.com/slurmdbd.html)para garantir que um cluster tenha seu próprio Slurm banco de dados no servidor de banco de dados. O mesmo servidor de banco de dados pode ser usado em vários clusters, mas cada cluster tem seu próprio banco de dados separado. AWS ParallelCluster usa o nome do cluster para definir o nome do banco de dados no [https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc)parâmetro do arquivo de `slurmdbd` configuração. Considere a situação a seguir. Um banco de dados que está presente no servidor de banco de dados inclui um nome de cluster que não é mapeado para um nome de cluster ativo. Nesse caso, você pode criar um novo cluster com esse nome de cluster para mapear para esse banco de dados. Slurm reutiliza o banco de dados para o novo cluster.
**Atenção**
Não recomendamos configurar mais de um cluster para usar o mesmo banco de dados ao mesmo tempo. Isso pode levar a problemas de desempenho ou até mesmo a situações de impasse no banco de dados.
Se a contabilização de Slurm estiver habilitada no nó principal de um cluster, recomendamos usar um tipo de instância com uma CPU poderosa, mais memória e maior largura de banda da rede. A contabilização de Slurm pode sobrecarregar o nó principal do cluster.
Na arquitetura atual do recurso de AWS ParallelCluster Slurm contabilidade, cada cluster tem sua própria instância do `slurmdbd` daemon, conforme mostrado nos exemplos de configurações do diagrama a seguir.
![\[\]](http://docs.aws.amazon.com/pt_br/parallelcluster/latest/ug/images/slurm-acct-arch.png)
Se você estiver adicionando funcionalidades personalizadas de vários clusters Slurm ou de federação ao seu ambiente de cluster, todos os clusters devem fazer referência à mesma instância `slurmdbd`. Para essa alternativa, recomendamos que você habilite a AWS ParallelCluster Slurm contabilização em um cluster e configure manualmente os outros clusters para se conectarem aos `slurmdbd` que estão hospedados no primeiro cluster.
Se você estiver usando AWS ParallelCluster versões anteriores à versão 3.3.0, consulte o método alternativo para implementar a Slurm contabilidade descrito nesta postagem do [blog sobre HPC](https://aws.amazon.com/blogs/compute/enabling-job-accounting-for-hpc-with-aws-parallelcluster-and-amazon-rds/).
## Considerações sobre contabilização de Slurm
### Banco de dados e cluster em diferentes VPCs
Para habilitar a contabilização de Slurm, é necessário um servidor de banco de dados para servir como back-end para as operações de leitura e gravação que o daemon `slurmdbd` executa. Antes que o cluster seja criado ou atualizado para permitir a contabilização de Slurm, o nó principal deve ser capaz de acessar o servidor do banco de dados.
Se você precisar implantar o servidor de banco de dados em uma VPC diferente da usada pelo cluster, considere o seguinte:
+ Para permitir a comunicação entre o `slurmdbd` lado do cluster e o servidor do banco de dados, você deve configurar a conectividade entre os dois VPCs. Para obter mais informações, consulte [VPC Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) no *Guia do usuário da Amazon Virtual Private Cloud*.
+ Você deve criar o grupo de segurança que deseja anexar ao nó principal na VPC do cluster. Depois que os dois VPCs forem emparelhados, a vinculação cruzada entre os grupos de segurança do lado do banco de dados e do cluster estará disponível. Para obter mais informações, consulte [Regras do Grupo de Segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules) no *Guia do usuário da Amazon Virtual Private Cloud*.
### Configurando a criptografia TLS entre `slurmdbd` e o servidor de banco de dados
Com a configuração de Slurm contabilidade padrão fornecida, AWS ParallelCluster `slurmdbd` estabelece uma conexão criptografada TLS com o servidor de banco de dados, se o servidor oferecer suporte à criptografia TLS. AWS serviços de banco de dados, como o Amazon RDS, Amazon Aurora oferecem suporte à criptografia TLS por padrão.
Você pode exigir conexões seguras no lado do servidor definindo o parâmetro `require_secure_transport` no servidor do banco de dados. Isso é configurado no CloudFormation modelo fornecido.
Seguindo as práticas recomendadas de segurança, recomendamos também habilitar a verificação da identidade do servidor no cliente do `slurmdbd`. Para fazer isso, configure [StorageParameters](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters)o. no`slurmdbd.conf`. Carregue o certificado CA do servidor no nó principal do cluster. Em seguida, defina a opção [SSL\$1CA](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) de `StorageParameters` em `slurmdbd.conf` para o caminho do certificado CA do servidor no nó principal. Isso permite a verificação da identidade do servidor no lado de `slurmdbd`. Depois de fazer essas alterações, reinicie o serviço `slurmdbd` para restabelecer a conectividade com o servidor de banco de dados com a verificação de identidade ativada.
### Atualização das credenciais do banco de dados
Para atualizar os valores [de Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName)ou [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn), você deve primeiro interromper a frota de computação. Suponha que o valor secreto armazenado no AWS Secrets Manager segredo seja alterado e seu ARN não seja alterado. Nessa situação, o cluster não atualiza automaticamente a senha do banco de dados para o novo valor. Para atualizar o cluster para o novo valor secreto, execute o comando a seguir no nó principal.
```
$ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh
```
**Atenção**
Para evitar a perda de dados contábeis, recomendamos que você altere a senha do banco de dados somente quando a frota de computação for interrompida.
### Monitoramento de banco de dados
Recomendamos que você ative os recursos de monitoramento dos serviços de AWS banco de dados. Para obter mais informações, consulte a documentação de [Monitoramento do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) ou de [Monitoramento do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/MonitoringAurora.html).
# Slurm personalização de configuração
A partir da AWS ParallelCluster versão 3.6.0, você pode personalizar o `slurm.conf` Slurm configuração em uma configuração de AWS ParallelCluster cluster.
Na configuração do cluster, você pode personalizar Slurm parâmetros de configuração usando as seguintes configurações de cluster:
+ Personalização Slurm parâmetros para todo o cluster usando o [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings)ou o [`CustomSlurmSettingsIncludeFile`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettingsIncludeFile)parâmetro. AWS ParallelCluster falhará se você especificar ambos.
+ Personalização Slurm parâmetros para uma fila usando [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomSlurmSettings)(mapeado para Slurm partições).
+ Personalização Slurm parâmetros para um recurso computacional usando [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)(mapeado para Slurm nós).
## Slurm limites e considerações de personalização de configuração ao usar AWS ParallelCluster
+ Para `CustomSlurmSettings` e `CustomSlurmSettingsIncludeFile` configurações, você só pode especificar e atualizar `slurm.conf` os parâmetros incluídos no [Slurm versão ](slurm-workload-manager-v3.md) compatível com a AWS ParallelCluster versão que você está usando para configurar um cluster.
+ Se você especificar personalizado Slurm configurações em qualquer um dos `CustomSlurmSettings` parâmetros, AWS ParallelCluster executa verificações de validação e impede a configuração ou atualização Slurm parâmetros de configuração que entram em conflito com a AWS ParallelCluster lógica. A ferramenta Slurm os parâmetros de configuração com os quais se sabe que entram em conflito AWS ParallelCluster são identificados nas listas de negação. As listas de negação podem mudar em AWS ParallelCluster versões futuras se outras Slurm recursos são adicionados. Para obter mais informações, consulte [Listado na lista de negação Slurm parâmetros de configuração para `CustomSlurmSettings`](#slurm-configuration-denylists-v3).
+ AWS ParallelCluster só verifica se um parâmetro está em uma lista de negação. AWS ParallelCluster não valida seu costume Slurm sintaxe ou semântica do parâmetro de configuração. Você é responsável por validar sua personalização Slurm parâmetros de configuração. Personalizado inválido Slurm parâmetros de configuração podem causar Slurm falhas de daemon que podem levar a falhas na criação e atualização do cluster.
+ Se você especificar personalizado Slurm configurações em`CustomSlurmSettingsIncludeFile`, AWS ParallelCluster não realiza nenhuma validação.
+ Você pode atualizar `CustomSlurmSettings` e `CustomSlurmSettingsIncludeFile` sem parar e iniciar a frota de computação. Nesse caso, AWS ParallelCluster reinicia o `slurmctld` daemon e executa o comando. `scontrol reconfigure`
Alguns Slurm os parâmetros de configuração podem exigir operações diferentes antes que uma alteração seja registrada em todo o cluster. Por exemplo, eles podem exigir a reinicialização de todos os daemons no cluster. Você é responsável por verificar se AWS ParallelCluster as operações são suficientes para propagar sua personalização Slurm configurações dos parâmetros de configuração durante as atualizações. Se você achar que AWS ParallelCluster as operações não são suficientes, é sua responsabilidade fornecer as ações adicionais necessárias para propagar as configurações atualizadas, conforme recomendado no [Slurm documentação](https://slurm.schedmd.com/documentation.html).
## Listado na lista de negação Slurm parâmetros de configuração para `CustomSlurmSettings`
As tabelas a seguir listam os parâmetros com as AWS ParallelCluster versões que negam seu uso, começando com a versão 3.6.0. `CustomSlurmSettings`não é compatível com AWS ParallelCluster versões anteriores à versão 3.6.0.
**Parâmetros listados na lista de negação no nível do cluster:**
| Slurm parameter | Listado na lista Deny em versões AWS ParallelCluster |
| --- | --- |
| CommunicationParameters | 3.6.0 |
| Epilog | 3.6.0 |
| GresTypes | 3.6.0 |
| LaunchParameters | 3.6.0 |
| Prolog | 3.6.0 |
| ReconfigFlags | 3.6.0 |
| ResumeFailProgram | 3.6.0 |
| ResumeProgram | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| SlurmctldHost | 3.6.0 |
| SlurmctldLogFile | 3.6.0 |
| SlurmctldParameters | 3.6.0 |
| SlurmdLogfile | 3.6.0 |
| SlurmUser | 3.6.0 |
| SuspendExcNodes | 3.6.0 |
| SuspendProgram | 3.6.0 |
| SuspendTime | 3.6.0 |
| TaskPlugin | 3.6.0 |
| TreeWidth | 3.6.0 |
**Negar parâmetros listados no nível do cluster quando o nativo [Slurm a integração contábil](slurm-accounting-v3.md) é configurada na configuração do cluster:**
| Slurm parameter | Listado na lista Deny em versões AWS ParallelCluster |
| --- | --- |
| AccountingStorageType | 3.6.0 |
| AccountingStorageHost | 3.6.0 |
| AccountingStoragePort | 3.6.0 |
| AccountingStorageUser | 3.6.0 |
| JobAcctGatherType | 3.6.0 |
**Parâmetros listados na lista de negação no nível da fila (partição) para filas gerenciadas por: AWS ParallelCluster**
| Slurm parameter | Listado na lista Deny em versões AWS ParallelCluster |
| --- | --- |
| Nodes | 3.6.0 |
| PartitionName | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| State | 3.6.0 |
| SuspendTime | 3.6.0 |
**Parâmetros listados na lista de negação no nível do recurso computacional (nó) para recursos computacionais gerenciados por: AWS ParallelCluster**
| Slurm parameter | Lista de negação na AWS ParallelCluster versão e em versões posteriores |
| --- | --- |
| CPUs | 3.6.0 |
| Atributos | 3.6.0 |
| Gres | 3.6.0 |
| NodeAddr | 3.6.0 |
| NodeHostname | 3.6.0 |
| NodeName | 3.6.0 |
| Weight | 3.7.0 |
# `prolog` e `epilog` da Slurm
A partir da AWS ParallelCluster versão 3.6.0, a Slurm configuração implantada AWS ParallelCluster inclui os parâmetros de configuração `Prolog` e`Epilog`:
```
# PROLOG AND EPILOG
Prolog=/opt/slurm/etc/scripts/prolog.d/*
Epilog=/opt/slurm/etc/scripts/epilog.d/*
SchedulerParameters=nohold_on_prolog_fail
BatchStartTimeout=180
```
Para obter mais informações, consulte o [Guia do Prolog e do Epilog](https://slurm.schedmd.com/prolog_epilog.html) na documentação do Slurm.
AWS ParallelCluster inclui os seguintes scripts de prólogo e epílogo:
+ `90_plcuster_health_check_manager` (na pasta `Prolog`)
+ `90_pcluster_noop` (na pasta `Epilog`)
**nota**
Tanto a pasta `Prolog` quanto a `Epilog` devem ter pelo menos um arquivo.
Você pode usar seus próprios scripts `prolog` e `epilog` personalizados, adicionando-os às pastas `Prolog` e `Epilog` correspondentes.
**Atenção**
Slurm executa todos os scripts nas pastas, em ordem alfabética inversa.
A duração do tempo de execução dos scripts `prolog` e `epilog` afeta o tempo necessário para executar um trabalho. Atualize a configuração `BatchStartTimeout` ao executar vários scripts ou scripts `prolog` de longa execução. O padrão é 3 minutos.
Se você estiver usando scripts `prolog` e `epilog` personalizados, localize os scripts nas pastas `Prolog` e `Epilog` correspondentes. Recomendamos que você mantenha o script `90_plcuster_health_check_manager` que é executado antes de cada script personalizado. Para obter mais informações, consulte [Slurm personalização de configuração](slurm-configuration-settings-v3.md).
# Tamanho e atualização da capacidade do cluster
A capacidade do cluster é definida pelo número de nós de computação que o cluster pode escalar. Os nós de computação são apoiados por EC2 instâncias da Amazon definidas nos recursos computacionais da AWS ParallelCluster configuração `(Scheduling/SlurmQueues/ ComputeResources)` e são organizados em filas `(Scheduling/SlurmQueues)` que mapeiam 1:1 para Slurm partições.
Em um recurso de computação, é possível configurar o número mínimo de nós de computação (instâncias) que sempre devem ser mantidos em execução no cluster (`MinCount`) e o número máximo de instâncias para as quais o recurso computacional pode ser escalado ([`MaxCount` 3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)).
No momento da criação do cluster, ou após uma atualização do cluster, AWS ParallelCluster inicia quantas EC2 instâncias da Amazon estiverem configuradas `MinCount` para cada recurso computacional (`Scheduling/SlurmQueues/ ComputeResources`) definido no cluster. As instâncias lançadas para cobrir a quantidade mínima de nós para os recursos computacionais no cluster são chamadas de ***nós estáticos***. Uma vez iniciados, os nós estáticos devem ser persistentes no cluster e não são encerrados pelo sistema, a menos que ocorra um evento ou condição específica. Tais eventos incluem, por exemplo, o fracasso do Slurm ou exames EC2 de saúde da Amazon e a mudança do Slurm status do nó para DRAIN ou DOWN.
As EC2 instâncias da Amazon, na faixa de `1` até `‘MaxCount - MinCount’` (`MaxCount `*menos*)` MinCount)`, lançadas sob demanda para lidar com o aumento da carga do cluster, são chamadas de nós ***dinâmicos***. Sua natureza é efêmera, eles são iniciados para atender a trabalhos pendentes e são encerrados quando permanecem ociosos por um período de tempo definido `Scheduling/SlurmSettings/ScaledownIdletime` na configuração do cluster (padrão: 10 minutos).
Os nós estáticos e os nós dinâmicos estão obedecem ao seguinte padrão de nomenclatura:
+ Os nós estáticos são `-st--`, em que ` = 1..ComputeResource/MinCount`
+ Os nós dinâmicos são `-dy--`, em que ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Por exemplo, dada a seguinte AWS ParallelCluster configuração:
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
Os seguintes nós serão definidos em Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Quando um recurso computacional tiver `MinCount == MaxCount`, todos os nós de computação correspondentes serão estáticos e todas as instâncias serão iniciadas no momento da criação/atualização do cluster e mantidas ativas e em execução. Por exemplo:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Atualização da capacidade do cluster
A atualização da capacidade do cluster inclui adicionar ou remover filas, recursos computacionais ou alterar o `MinCount/MaxCount` de um recurso computacional. A partir da AWS ParallelCluster versão 3.9.0, reduzir o tamanho de uma fila exige que a frota de computação seja interrompida ou [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)configurada como TERMINATE antes que uma atualização do cluster ocorra. Não é necessário interromper a frota de computação ou configurar [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)para TERMINATE quando:
+ Adicionar novas filas ao Agendamento/ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Adicionar novos recursos computacionais `Scheduling/SlurmQueues/ComputeResources` a uma fila
+ Aumentar a `MaxCount` de um recurso computacional
+ Aumento MinCount de um recurso computacional e aumento MaxCount do mesmo recurso computacional em pelo menos a mesma quantidade
## Considerações e limitações
Esta seção tem como objetivo descrever fatores, restrições ou limitações importantes que devem ser levados em consideração ao redimensionar a capacidade do cluster.
+ Ao remover uma fila de `Scheduling/SlurmQueues` todos os nós de computação com nome`-*`, tanto estático quanto dinâmico, será removida do Slurm a configuração e as EC2 instâncias correspondentes da Amazon serão encerradas.
+ Ao remover um recurso `Scheduling/SlurmQueues/ComputeResources` de computação de uma fila, todos os nós de computação com nome`-*--*`, estático e dinâmico, serão removidos do Slurm a configuração e as EC2 instâncias correspondentes da Amazon serão encerradas.
Ao alterar o parâmetro `MinCount` de um recurso computacional, podemos distinguir dois cenários diferentes: se `MaxCount` for mantido igual a `MinCount` (somente capacidade estática) e se `MaxCount` for maior que `MinCount` (capacidade estática e dinâmica mista).
### Alterações de capacidade somente com nós estáticos
+ Se`MinCount == MaxCount`, ao aumentar `MinCount` (e`MaxCount`), o cluster for configurado estendendo o número de nós estáticos até o novo valor de, `MinCount` `-st--` e o sistema continuar tentando iniciar EC2 instâncias da Amazon para atender à nova capacidade estática necessária.
+ Se`MinCount == MaxCount`, ao diminuir `MinCount` (e`MaxCount`) da quantidade N, o cluster for configurado removendo os últimos N nós estáticos `-st--...]` e o sistema encerrará as instâncias correspondentes da Amazon EC2 .
+ Estado inicial `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualizar `-30` em `MinCount` e `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Alterações de capacidade com nós mistos
Se`MinCount < MaxCount`, `MinCount` ao aumentar em uma quantidade N (supondo que `MaxCount` será mantido inalterado), o cluster for configurado estendendo o número de nós estáticos até o novo valor de `MinCount` (`old_MinCount + N`): `-st--` e o sistema continuará tentando iniciar EC2 instâncias da Amazon para atender à nova capacidade estática necessária. Além disso, para honrar a `MaxCount` capacidade do recurso computacional, a configuração do cluster é atualizada *removendo os últimos N nós dinâmicos*: `-dy--[...]` e o sistema encerrará as instâncias correspondentes da Amazon EC2 .
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização \$130 para `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Se`MinCount < MaxCount`, ao aumentar `MinCount` e `MaxCount` com a mesma quantidade N, o cluster for configurado estendendo o número de nós estáticos para o novo valor de `MinCount` (`old_MinCount + N`): `-st--` e o sistema continuará tentando iniciar EC2 instâncias da Amazon para atender à nova capacidade estática necessária. Além disso, nenhuma alteração será feita no número de nós dinâmicos para honrar o novo
`MaxCount` value.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização \$130 para `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Se`MinCount < MaxCount`, ao diminuir a quantidade N (`MinCount`supondo que `MaxCount` será mantida inalterada), o cluster será configurado removendo os últimos N nós estáticos de nós estáticos `-st--[...` e o sistema encerrará as instâncias correspondentes da Amazon. EC2 Além disso, para honrar a `MaxCount` capacidade do recurso computacional, a configuração do cluster é atualizada ampliando o número de nós dinâmicos para preencher a lacuna. `MaxCount - new_MinCount: -dy--[1..]` Nesse caso, como esses são nós dinâmicos, nenhuma nova EC2 instância da Amazon será lançada, a menos que o agendador tenha trabalhos pendentes nos novos nós.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização -30 no `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Se`MinCount < MaxCount`, ao diminuir `MinCount` e `MaxCount` com a mesma quantidade N, o cluster for configurado removendo os últimos N nós estáticos `-st--...]` e o sistema encerrará as instâncias correspondentes da Amazon EC2 .
Além disso, nenhuma alteração será feita no número de nós dinâmicos para honrar o novo valor `MaxCount`.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização -30 no `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Se`MinCount < MaxCount`, ao diminuir a quantidade N (`MaxCount``MinCount`supondo que seja mantida inalterada), o cluster for configurado removendo os últimos N nós dinâmicos `-dy--]` e o sistema encerrará as EC2 instâncias correspondentes da Amazon no caso de elas estarem em execução. Nenhum impacto é esperado nos nós estáticos.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Atualização -30 no `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Impactos nos empregos
Em todos os casos em que os nós são removidos e as EC2 instâncias da Amazon encerradas, um trabalho em lote executado nos nós removidos será colocado novamente na fila, a menos que não haja outros nós que satisfaçam os requisitos do trabalho. Nesse último caso, o trabalho falha com o status NODE\$1FAIL e desaparece da fila e deve ser reenviado manualmente.
Se você estiver planejando executar uma atualização de redimensionamento de cluster, poderá impedir que os trabalhos sejam executados nos nós que serão removidos durante a atualização planejada. Isso é possível configurando os nós para serem removidos na manutenção. Esteja ciente de que a configuração de um nó em manutenção não afetará os trabalhos que já estiverem em execução no nó.
Suponha que, com a atualização de redimensionamento do cluster planejada, você vai remover o nó `qeueu-st-computeresource-[9-10`]. Você pode criar um Slurm reserva com o seguinte comando
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Isso criará um Slurm reserva `maint_for_update` nomeada nos nós`qeueu-st-computeresource-[9-10]`. Quando a reserva é criada, nenhum outro trabalho pode ser executado nos nós `qeueu-st-computeresource-[9-10]`. Esteja ciente de que a reserva não impedirá que os trabalhos sejam alocados nos nós `qeueu-st-computeresource-[9-10]`.
Após a atualização do redimensionamento do cluster, se o Slurm A reserva foi definida somente nos nós que foram removidos durante a atualização de redimensionamento. A reserva de manutenção será excluída automaticamente. Se, em vez disso, você tivesse criado um Slurm reserva em nós que ainda estão presentes após a atualização de redimensionamento do cluster. Talvez desejemos remover a reserva de manutenção nos nós após a atualização de redimensionamento ser executada, usando o seguinte comando
```
sudo -i scontrol delete ReservationName=maint_for_update
```
Para obter detalhes adicionais sobre Slurm reserva, veja o documento oficial do SchedMD [aqui.](https://slurm.schedmd.com/reservations.html)
## Processo de atualização do cluster em alterações de capacidade
Após uma alteração na configuração do agendador, as seguintes etapas são executadas durante o processo de atualização do cluster:
+ Pare AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Gerar atualização Slurm configuração de partições a partir da AWS ParallelCluster configuração
+ Reiniciar `slurmctld` (feito por meio da fórmula do serviço do Chef)
+ Verificar status do `slurmctld` `(systemctl is-active --quiet slurmctld.service)`
+ Reload (Recarregar) Slurm configuração `(scontrol reconfigure)`
+ Iniciar `clustermgtd (supervisorctl start clustermgtd)`
# Usando o agendador AWS Batch (`awsbatch`) com AWS ParallelCluster
**Atenção**
AWS CodeBuild não é suportado nas regiões Ásia-Pacífico (Malásia) `ap-southeast-5` () e Ásia-Pacífico (Tailândia) `ap-southeast-7` (). Portanto, a ParallelCluster AWS Batch integração não é suportada nessas regiões.
AWS ParallelCluster também suporta AWS Batch agendadores. Os tópicos a seguir descrevem como usar AWS Batch. Para obter informações sobre AWS Batch, consulte [AWS Batch](https://aws.amazon.com/batch/). Para obter a documentação, consulte o [Guia do usuário do AWS Batch](https://docs.aws.amazon.com/batch/latest/userguide/).
**AWS ParallelCluster Comandos CLI para AWS Batch**
Quando você usa o `awsbatch` agendador, os comandos da AWS ParallelCluster CLI AWS Batch para são instalados automaticamente no nó AWS ParallelCluster principal. A CLI usa operações de AWS Batch API e permite as seguintes operações:
+ Enviar e gerenciar trabalhos.
+ Monitorar trabalhos, filas e hosts.
+ Espelhar comandos do programador tradicional.
**Importante**
AWS ParallelCluster não suporta trabalhos de GPU para AWS Batch. Para obter mais informações, consulte [Trabalhos de GPU](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html).
Esta CLI é distribuída como um pacote separado. Para obter mais informações, consulte [Compatibilidade com agendadores](moving-from-v2-to-v3.md#scheduler_support).
**Topics**
+ [`awsbsub`](awsbatchcli.awsbsub-v3.md)
+ [`awsbstat`](awsbatchcli.awsbstat-v3.md)
+ [`awsbout`](awsbatchcli.awsbout-v3.md)
+ [`awsbkill`](awsbatchcli.awsbkill-v3.md)
+ [`awsbqueues`](awsbatchcli.awsbqueues-v3.md)
+ [`awsbhosts`](awsbatchcli.awsbhosts-v3.md)
# `awsbsub`
Envia trabalhos para a fila de trabalhos do cluster.
```
awsbsub [-h] [-jn JOB_NAME] [-c CLUSTER] [-cf] [-w WORKING_DIR]
[-pw PARENT_WORKING_DIR] [-if INPUT_FILE] [-p VCPUS] [-m MEMORY]
[-e ENV] [-eb ENV_DENYLIST] [-r RETRY_ATTEMPTS] [-t TIMEOUT]
[-n NODES] [-a ARRAY_SIZE] [-d DEPENDS_ON]
[command] [arguments [arguments ...]]
```
**Importante**
AWS ParallelCluster não suporta trabalhos de GPU para AWS Batch. Para obter mais informações, consulte [Trabalhos de GPU](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html).
## Argumentos posicionais
***command***
Envia o trabalho (o comando especificado deve estar disponível nas instâncias de computação) ou o nome do arquivo a ser transferido. Consulte também `--command-file`.
**arguments**
(Opcional) Especifica argumentos para o comando ou arquivo de comando.
## Argumentos nomeados
**-jn *JOB\$1NAME*, --job-name *JOB\$1NAME***
Nomeia a tarefa. O primeiro caractere deve ser uma letra ou um número. O nome do trabalho pode conter letras (minúsculas e maiúsculas), números, hifens e sublinhados, e ter até 128 caracteres de comprimento.
**-c *CLUSTER*, --cluster *CLUSTER***
Especifica o cluster a ser usado.
**-cf, --command-file**
Indica que o comando é um arquivo a ser transferido para as instâncias de computação.
Padrão: False
**-w *WORKING\$1DIR*, --working-dir *WORKING\$1DIR***
Especifica a pasta a ser usada como diretório de trabalho da tarefa. Se um diretório de trabalho não for especificado, o trabalho será executado na subpasta `job-` do diretório inicial do usuário. Você pode usar esse parâmetro ou o parâmetro `--parent-working-dir`.
**-pw *PARENT\$1WORKING\$1DIR*, --parent-working-dir *PARENT\$1WORKING\$1DIR***
Especifica a pasta pai do diretório de trabalho da tarefa. Se um diretório de trabalho pai não for especificado, o padrão será o diretório inicial do usuário. Uma subpasta chamada `job-` será criada no diretório de trabalho pai. Você pode usar esse parâmetro ou o parâmetro `--working-dir`.
**-if *INPUT\$1FILE*, --input-file *INPUT\$1FILE***
Especifica o arquivo a ser transferido para as instâncias de computação, no diretório de trabalho do trabalho. Você pode especificar vários parâmetros de arquivo de entrada.
**-p *VCPUS*, --vcpus *VCPUS***
Especifica o número de v CPUs a ser reservado para o contêiner. Quando usado junto com`–nodes`, ele identifica o número de v CPUs para cada nó.
Padrão: 1
**-m *MEMORY*, --memory *MEMORY***
Especifica o limite rígido de memória (em MiB) a ser fornecido para a tarefa. Se o trabalho tentar exceder o limite de memória especificado aqui, ele será encerrado.
Padrão: 128
**-e *ENV*, --env *ENV***
Especifica uma lista separada por vírgulas dos nomes das variáveis de ambiente a serem exportadas para o ambiente da tarefa. Para exportar todas as variáveis de ambiente, especifique "all". Observe que uma lista de variáveis de ambiente "all" não inclui as listadas no parâmetro `–env-blacklist`, nem variáveis que começam com os prefixos `PCLUSTER_*` e `AWS_*`.
**-eb *ENV\$1DENYLIST*, --env-blacklist *ENV\$1DENYLIST***
Especifica uma lista separada por vírgulas dos nomes das variáveis de ambiente a **não** serem exportadas para o ambiente da tarefa. Por padrão, `HOME`, `PWD`, `USER`, `PATH`, `LD_LIBRARY_PATH`, `TERM` e `TERMCAP` não são exportadas.
**-r *RETRY\$1ATTEMPTS*, --retry-attempts *RETRY\$1ATTEMPTS***
Especifica o número de vezes que um trabalho será movido para o status `RUNNABLE`. Você pode especificar entre 1 e 10 tentativas. Se o valor de tentativas for maior que 1, o trabalho será repetido se falhar, até ser movido para um status `RUNNABLE` esse número especificado de vezes.
Padrão: 1
**-t *TIMEOUT*, --timeout *TIMEOUT***
Especifica a duração em segundos (medida a partir do `startedAt` timestamp da tentativa de trabalho) após a qual AWS Batch encerra seu trabalho se ele não tiver sido concluído. O valor de tempo limite deve ser pelo menos 60 segundos.
**-n *NODES*, --nodes *NODES***
Especifica o número de nós a serem reservados para a tarefa. Especifique um valor para esse parâmetro a fim de habilitar o envio paralelo com vários nós.
Quando o parâmetro [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) / [`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues) / [`CapacityType`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-CapacityType) é definido como `SPOT`, trabalhos paralelos de vários nós *não são* suportados. Além disso, deve haver uma função `AWSServiceRoleForEC2Spot` vinculada ao serviço em sua conta. Você pode criar essa função com o seguinte AWS CLI comando:
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
Para ter mais informações, consulte [Função vinculada ao serviço para solicitações de instâncias spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) no *Guia do usuário do Amazon Elastic Compute Cloud para instâncias do Linux*.
**-a *ARRAY\$1SIZE*, --array-size *ARRAY\$1SIZE***
Indica o tamanho da matriz. Você pode especificar um valor entre 2 e 10.000. Se você especificar propriedades de matriz para uma tarefa, ela se torna uma tarefa de matriz.
**-d *DEPENDS\$1ON*, --depends-on *DEPENDS\$1ON***
Especifica uma lista de dependências separadas por ponto-e-vírgula para uma tarefa. Uma tarefa pode depender de, no máximo, outras 20 tarefas. Você pode especificar um tipo de dependência `SEQUENTIAL` sem especificar um ID de trabalho para trabalhos de matriz. Uma dependência sequencial permite que cada tarefa filho da matriz seja concluída sequencialmente, a partir do índice 0. Você também pode especificar uma dependência do tipo N\$1TO\$1N com um ID de tarefa para tarefas de matriz. Uma dependência N\$1TO\$1N significa que cada índice filho dessa tarefa precisa aguardar que o índice filho correspondente de cada dependência seja concluído antes de poder começar. A sintaxe desse parâmetro é “jobId=**, type=**;...”.
# `awsbstat`
Mostra as tarefas que são enviadas na fila de tarefas do cluster.
```
awsbstat [-h] [-c CLUSTER] [-s STATUS] [-e] [-d] [job_ids [job_ids ...]]
```
## Argumentos posicionais
***job\$1ids***
Especifica a lista de trabalhos separados por espaços IDs a serem mostrados na saída. Se o trabalho for uma matriz de trabalhos, todos os trabalhos filho são exibidos. Se uma única tarefa for solicitada, seus detalhes são exibidos.
## Argumentos nomeados
**-c *CLUSTER*, --cluster *CLUSTER***
Indica o cluster a ser usado.
**-s *STATUS*, --status *STATUS***
Especifica uma lista separada por vírgulas de status de tarefa a ser incluída. O status de tarefa padrão é "ativo". Os valores aceitos são: `SUBMITTED`, `PENDING`, `RUNNABLE`, `STARTING`, `RUNNING`, `SUCCEEDED`, `FAILED` e `ALL`.
Padrão: “`SUBMITTED`,`PENDING`,`RUNNABLE`,`STARTING`,`RUNNING`”
**-e, --expand-children**
Expande tarefas com filhos (matriz e paralelo com vários nós).
Padrão: False
**-d, --details**
Mostra os detalhes da tarefa.
Padrão: False
# `awsbout`
Mostra a saída de uma tarefa específica.
```
awsbout [-h] [-c CLUSTER] [-hd HEAD] [-t TAIL] [-s] [-sp STREAM_PERIOD] job_id
```
## Argumentos posicionais
***job\$1id***
Especifica o ID da tarefa.
## Argumentos nomeados
**-c *CLUSTER*, --cluster *CLUSTER***
Indica o cluster a ser usado.
**-hd *HEAD*, --head *HEAD***
Obtém as primeiras *HEAD* linhas da saída do trabalho.
**-t *TAIL*, --tail *TAIL***
Obtém as últimas linhas da saída da tarefa.
**-s, --stream**
Obtém a saída da tarefa e aguarda a saída adicional que será produzida. Esse argumento pode ser usado em conjunto com –tail para iniciar a partir das últimas linhas da saída da tarefa.
Padrão: False
**-sp *STREAM\$1PERIOD*, --stream-period *STREAM\$1PERIOD***
Define o período de streaming.
Padrão: 5
# `awsbkill`
Cancela ou encerra tarefas enviadas no cluster.
```
awsbkill [-h] [-c CLUSTER] [-r REASON] job_ids [job_ids ... ]
```
## Argumentos posicionais
***job\$1ids***
Especifica a lista de trabalhos separados por espaços a IDs serem cancelados ou encerrados.
## Argumentos nomeados
**-c *CLUSTER*, --cluster *CLUSTER***
Indica o nome do cluster a ser usado.
**-r *REASON*, --reason *REASON***
Indica a mensagem que será anexada a uma tarefa, explicando o motivo do cancelamento.
Padrão:”Terminated by the user”
# `awsbqueues`
Mostra a fila de tarefas associada ao cluster.
```
awsbqueues [-h] [-c CLUSTER] [-d] [job_queues [job_queues ... ]]
```
## Argumentos posicionais
***job\$1queues***
Especifica a lista separada por espaços de nomes de fila a ser exibida. Se uma única fila for solicitada, seus detalhes são exibidos.
## Argumentos nomeados
**-c *CLUSTER*, --cluster *CLUSTER***
Especifica o nome do cluster a ser usado.
**-d, --details**
Indica se deve mostrar os detalhes das filas.
Padrão: False
# `awsbhosts`
Mostra os hosts que pertencem ao ambiente de computação do cluster.
```
awsbhosts [-h] [-c CLUSTER] [-d] [instance_ids [instance_ids ... ]]
```
## Argumentos posicionais
***instance\$1ids***
Especifica uma lista de instâncias separadas por espaços. IDs Se uma única instância for solicitada, seus detalhes são exibidos.
## Argumentos nomeados
**-c *CLUSTER*, --cluster *CLUSTER***
Especifica o nome do cluster a ser usado.
**-d, --details**
Indica se deve mostrar os detalhes dos hosts.
Padrão: False