As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Slurm 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.