Modo protegido por cluster do Slurm - AWS ParallelCluster
Parâmetro do modo protegidoVerificação de status do cluster no status protegidoComo desativar o status protegidoFalhas de bootstrap que ativam o status protegidoComo depurar o modo protegido

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

Modo protegido por cluster do Slurm

Quando um cluster é executado com o modo protegido ativado, o 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.

  2. A contagem de falhas atinge um limite predefinido.

Depois que o cluster entra no status protegido, o AWS ParallelCluster desativa as filas com falhas no limite predefinido ou acima dele.

O modo protegido por cluster do Slurm foi adicionado no 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 <cluster-name> --region <region-id>
{
   "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 <cluster-name> \
  --region <region-id> \
  --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 o AWS ParallelCluster gerou logs. Se os logs foram gerados, você pode verificá-los para obter detalhes do erro. Para ter mais informações, consulte Recuperando e preservando logs.

  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 \ CustomActions \ OnNodeStart | 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

  2. 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 estado DOWN pelo Slurm após 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.

  3. Os nós falham na verificação de integridade.

    Uma instância atrás do nó falha em uma verificação de integridade do EC2 ou na 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.

  4. Os nós de computação falham no registro do Slurm.

    O registro do daemon slurmd com o daemon de controle do Slurm (slurmctld) falha e faz com que o estado do nó de computação mude para o estado INVALID_REG. Os nós de computação do Slurm configurados incorretamente podem causar esse erro, como nós computados configurados com erros de especificação do nó de computação CustomSlurmSettings.

    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 AWS ParallelCluster gerou logs clustermgtd a partir de HeadNode e dos logs de cloud-init-output dos nós de computação problemáticos, você poderá verificar os logs para ver os detalhes do erro. Para obter mais informações sobre recuperação de logs, consulte Recuperando e preservando logs.

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