Slurmmodalità protetta dal cluster - AWS ParallelCluster

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Slurmmodalità protetta dal cluster

Quando un cluster viene eseguito con la modalità protetta abilitata, AWS ParallelCluster monitora e tiene traccia degli errori di avvio dei nodi di elaborazione durante l'avvio dei nodi di elaborazione. Lo fa per rilevare se questi guasti si verificano continuamente.

Se viene rilevato quanto segue in una coda (partizione), il cluster entra nello stato protetto:

  1. Gli errori consecutivi di avvio dei nodi di calcolo si verificano continuamente senza che il lancio del nodo di elaborazione abbia esito positivo.

  2. Il numero di errori raggiunge una soglia predefinita.

Dopo che il cluster è entrato nello stato protetto, AWS ParallelCluster disattiva le code con errori pari o superiori alla soglia predefinita.

Slurmla modalità protetta dal cluster è stata aggiunta nella AWS ParallelCluster versione 3.0.0.

È possibile utilizzare la modalità protetta per ridurre il tempo e le risorse impiegati per il ciclo di errore di avvio dei nodi di calcolo.

Parametro della modalità protetta

protected_failure_count

protected_failure_countspecifica il numero di errori consecutivi in una coda (partizione) che attivano lo stato di protezione del cluster.

L'impostazione predefinita protected_failure_count è 10 e la modalità protetta è abilitata.

Se protected_failure_count è maggiore di zero, la modalità protetta è abilitata.

Se protected_failure_count è minore o uguale a zero, la modalità protetta è disattivata.

È possibile modificare il protected_failure_count valore aggiungendo il parametro nel file di clustermgtd configurazione che si trova /etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf in. HeadNode

Puoi aggiornare questo parametro in qualsiasi momento e non è necessario interrompere il parco di elaborazione per farlo. Se un avvio riesce in coda prima del raggiungimento del numero di erroriprotected_failure_count, il conteggio degli errori viene azzerato.

Verifica lo stato del cluster in stato protetto

Quando un cluster è protetto, puoi controllare lo stato della flotta di elaborazione e gli stati dei nodi.

Calcola lo stato della flotta

Lo stato della flotta di elaborazione si trova PROTECTED in un cluster in esecuzione in stato protetto.

$ pcluster describe-compute-fleet --cluster-name <cluster-name> --region <region-id> { "status": "PROTECTED", "lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z" }

Stato del nodo

Per sapere quali code (partizioni) presentano errori di bootstrap che hanno attivato lo stato protetto, accedi al cluster ed esegui il comando. sinfo Le partizioni con errori di bootstrap pari o superiori protected_failure_count sono nello stato. INACTIVE Le partizioni senza errori di bootstrap pari o superiori protected_failure_count sono nello UP stato e funzionano come previsto.

PROTECTEDlo stato non influisce sui lavori in esecuzione. Se i processi sono in esecuzione su una partizione con errori di bootstrap pari o superioriprotected_failure_count, la partizione viene impostata su INACTIVE dopo il completamento dei processi in esecuzione.

Considerate i parametri di nodo, consulta l'esempio seguente.

$ 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]

queue1La partizione è INACTIVE dovuta al rilevamento di 10 errori di bootstrap consecutivi del nodo di calcolo.

Le istanze dietro i nodi sono queue1-dy-c5xlarge-[1-10] state avviate ma non sono riuscite a unirsi al cluster a causa di uno stato non integro.

Lo stato del cluster è protetto.

La partizione queue2 non è influenzata dagli errori di bootstrap in. queue1 È nello UP stato e può ancora eseguire lavori.

Come disattivare lo stato protetto

Dopo che l'errore di bootstrap è stato risolto, puoi eseguire il seguente comando per disattivare lo stato protetto del cluster.

$ pcluster update-compute-fleet --cluster-name <cluster-name> \ --region <region-id> \ --status START_REQUESTED

Errori di bootstrap che attivano lo stato protetto

Gli errori di bootstrap che attivano lo stato protetto sono suddivisi nei tre tipi seguenti. Per identificare il tipo e il problema, puoi verificare se sono stati AWS ParallelCluster generati registri. Se i log sono stati generati, puoi controllarli per i dettagli degli errori. Per ulteriori informazioni, consulta Recupero e conservazione dei registri.

  1. Errore di bootstrap che causa la chiusura automatica di un'istanza.

    Un'istanza fallisce all'inizio del processo di bootstrap, ad esempio un'istanza che si chiude automaticamente a causa di errori nello script SlurmQueues\ CustomActions\ OnNodeStart|. OnNodeConfigured

    Per i nodi dinamici, consulta i parametri di, consulta i parametri di, consulta:

    Node bootstrap error: Node ... is in power up state without valid backing instance

    Per i nodi statici, cerca nel clustermgtd log (/var/log/parallelcluster/clustermgtd) errori simili ai seguenti:

    Node bootstrap error: Node ... is in power up state without valid backing instance
  2. Nodi resume_timeout o node_replacement_timeout scadenze.

    Un'istanza non può unirsi al cluster all'interno del resume_timeout (per i nodi dinamici) o node_replacement_timeout (per i nodi statici). Non si interrompe automaticamente prima del timeout. Ad esempio, la rete non è configurata correttamente per il cluster e il nodo è impostato DOWN sullo stato Slurm entro la scadenza del timeout.

    Per i nodi dinamici, consulta i parametri di, consulta i parametri di, consulta:

    Node bootstrap error: Resume timeout expires for node

    Per i nodi statici, cerca nel clustermgtd log (/var/log/parallelcluster/clustermgtd) errori simili ai seguenti:

    Node bootstrap error: Replacement timeout expires for node ... in replacement.
  3. I nodi non superano il controllo dello stato.

    Un'istanza dietro il nodo non supera il controllo dello stato di EC2 o il controllo dello stato di un evento pianificato e i nodi vengono trattati come nodi di errore bootstrap. In questo caso, l'istanza termina per un motivo che sfugge al controllo diAWS ParallelCluster.

    Cerca nel clustermgtd log (/var/log/parallelcluster/clustermgtd) errori simili ai seguenti:

    Node bootstrap error: Node %s failed during bootstrap when performing health check.
  4. La Slurmregistrazione dei nodi di elaborazione non va a buon fine.

    La registrazione del demone con il slurmd daemon di Slurm controllo (slurmctld) ha esito negativo e fa sì che lo stato del nodo di calcolo passi allo stato. INVALID_REG I nodi di Slurm elaborazione configurati in modo errato possono causare questo errore, come i nodi calcolati configurati con CustomSlurmSettingserrori di specifica dei nodi di calcolo.

    Cerca nel file di slurmctld registro (/var/log/slurmctld.log) sul nodo principale o nel file di slurmd registro (/var/log/slurmd.log) del nodo di elaborazione fallito per errori simili ai seguenti:

    Setting node %s to INVAL with reason: ...

Come eseguire il debug della modalità protetta

Se il tuo cluster è in stato protetto e se clustermgtd i log sono stati AWS ParallelCluster generati dai HeadNode nodi di elaborazione problematici, puoi controllare i log per i dettagli degli errori. cloud-init-output Per ulteriori informazioni su come recuperare i parametri di, consulta. Recupero e conservazione dei registri

clustermgtdlog (/var/log/parallelcluster/clustermgtd) sul nodo principale

I messaggi di registro mostrano quali partizioni presentano errori di bootstrap e il corrispondente numero di errori di bootstrap.

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

Nel clustermgtd registro, cerca per Found the following bootstrap failure nodes trovare quale nodo non è riuscito a eseguire il 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)']

Nel clustermgtd registro, cerca Node bootstrap error per trovare il motivo dell'errore.

[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

cloud-init-outputlog (/var/log/cloud-init-output.log) sui nodi di calcolo

Dopo aver ottenuto l'indirizzo IP privato del nodo di errore bootstrap nel clustermgtd registro, è possibile trovare il registro del nodo di calcolo corrispondente accedendo al nodo di elaborazione o seguendo le istruzioni per recuperare i log. Recupero e conservazione dei registri Nella maggior parte dei casi, il /var/log/cloud-init-output registro del nodo problematico mostra il passaggio che ha causato l'errore di avvio del nodo di calcolo.