Risoluzione dei problemi AWS Aggiornamenti della versione del cluster PCS

Questo argomento consente di identificare e risolvere i problemi più comuni che possono verificarsi durante l'aggiornamento della versione dello scheduler su un cluster.

• I nodi di calcolo non riescono a connettersi dopo l'aggiornamento

• Richiesta di aggiornamento rifiutata con ValidationException

• Il cluster rimane in stato DI AGGIORNAMENTO

• Il cluster entra nello stato UPDATE_FAILED dopo l'aggiornamento

• I nodi di calcolo non si avviano a causa di errori di analisi della configurazione

• Cluster non disponibile dopo l'aggiornamento a causa di una configurazione QoS non valida

I nodi di calcolo non riescono a connettersi dopo l'aggiornamento

Cause comuni

Dopo l'aggiornamento del cluster, i nodi di calcolo appena lanciati non riescono a registrarsi con il controller. I nodi si avviano ma non vengono mai visualizzati nell'sinfooutput e il gruppo di nodi di calcolo può scorrere ripetutamente tra le istanze. Ciò si verifica quando l'AMI del gruppo di nodi di calcolo contiene una versione dello scheduler che non rientra nella finestra di compatibilità della nuova versione del controller.

Ad esempio, se aggiorni un cluster dal 24.11 al 25.11 ma il gruppo di nodi di calcolo utilizza ancora un'AMI con Slurm 23.11, le nuove istanze non possono connettersi perché 23.11 non rientra nella finestra di compatibilità del 25.11.

Come diagnosticare

Puoi confermare questo problema controllando i log in due punti:

Registri dello Scheduler

Se hai abilitato la registrazione dello scheduler, controlla i log dello scheduler in CloudWatch Logs per errori simili ai seguenti:

error: unpack_header: protocol_version 10240 not supported
error: slurm_unpack_received_msg: [ip-10-0-1-23] Incompatible versions of client and server code

Questi errori indicano che un nodo di elaborazione con una versione dello scheduler incompatibile sta tentando di connettersi al controller. Per informazioni sulla configurazione della registrazione dello scheduler, vedere. Registri dell'utilità di pianificazione in PCS AWS

Registri delle istanze dei nodi di calcolo

Recuperate l'output della console dell'istanza o connettetevi tramite Systems Manager e controllate nel registro di bootstrap la presenza di errori simili ai seguenti:

error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server
error: _establish_configuration: failed to load configs
error: slurmd initialization failed

Per ulteriori informazioni sul recupero dei log delle istanze, consulta. Recupera i log delle istanze

Risoluzione

Aggiorna il gruppo di nodi di calcolo per utilizzare un'AMI che contenga una versione di pianificazione all'interno della finestra di compatibilità della tua nuova versione del cluster:

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

Per determinare quali versioni dello scheduler sono compatibili con il tuo cluster, vedi. Compatibilità delle versioni

Per informazioni sulla creazione di AMI personalizzate con la versione di pianificazione corretta, consulta. Amazon Machine Images (AMI) per AWS PZ

Richiesta di aggiornamento rifiutata con ValidationException

Cause comuni

La UpdateCluster richiesta viene restituita immediatamente con un ValidationException errore che indica che l'aggiornamento non è supportato. Ciò si verifica quando:

• La versione di destinazione non rientra nella finestra di compatibilità della versione corrente.

• La versione di destinazione è designata come End of Life (EOL) e non è più una destinazione di aggiornamento valida.

• La versione di destinazione è precedente o uguale alla versione corrente (i downgrade non sono supportati).

Risoluzione

Se la versione di destinazione non rientra nella finestra di compatibilità, esegui l'aggiornamento in più passaggi. Ogni passaggio deve avere come target una versione supportata all'interno della finestra di compatibilità. Ad esempio, per passare dal 23.11 al 25.11, aggiorna prima alla 25.05, attendi che il cluster ritorni alla versione 25.11ACTIVE, quindi aggiorna alla 25.11.

Se la versione di destinazione è EOL, scegli invece una versione più recente supportata. Per informazioni sulle versioni supportate, consulta. Versioni Slurm in AWS PZ

Il cluster rimane in stato DI AGGIORNAMENTO

Cause comuni

Il cluster rimane nello UPDATING stato più a lungo del previsto (più di 20 minuti). Ciò può verificarsi a causa di problemi interni transitori durante il processo di aggiornamento.

Risoluzione

AWS PCS ripristina automaticamente i cluster bloccati nello stato. UPDATING Se il cluster non torna ACTIVE o non torna UPDATE_FAILED entro 30 minuti, contatta AWS Support per ricevere assistenza.

Il cluster entra nello stato UPDATE_FAILED dopo l'aggiornamento

Cause comuni

Il cluster passa UPDATE_FAILED allo stato durante l'aggiornamento. Ciò può verificarsi quando errori temporanei del servizio impediscono il corretto completamento dell'aggiornamento.

Risoluzione

Riprova l'aggiornamento inviando nuovamente la stessa richiesta. UpdateCluster I cluster in UPDATE_FAILED stato accettano nuove richieste di aggiornamento. Se l'aggiornamento continua a fallire, contatta l' AWS assistenza.

I nodi di calcolo non si avviano a causa di errori di analisi della configurazione

Cause comuni

Dopo l'aggiornamento del cluster, i nodi di elaborazione non si avviano e non vengono mai visualizzati nell'output. sinfo I registri delle istanze del nodo di calcolo mostrano errori simili ai seguenti:

error: _parse_next_key: Parsing error at unrecognized key: HashPlugin
error: Invalid DebugFlag: AuditRPCs
fatal: Unable to process configuration file

Ciò si verifica quando i nodi di calcolo che eseguono la versione di pianificazione 23.11 ricevono la configurazione da una versione più recente del cluster. Le versioni di Scheduler successive alla 23.11 hanno introdotto nuove direttive di configurazione che la 23.11 non può analizzare. A differenza delle altre versioni incluse nella finestra di compatibilità, i nodi di calcolo 23.11 non possono connettersi a un cluster più recente perché generano errori irreversibili su chiavi di configurazione non riconosciute.

Questo problema può verificarsi anche se l'AMI personalizzata utilizza una versione dell'agente AWS PCS precedente alla v1.4.0. Le versioni precedenti dell'agente non supportano il fallback automatico delle versioni per il demone del nodo di calcolo.

Risoluzione

Ricostruisci la tua AMI personalizzata con i seguenti requisiti:

• Scheduler versione 24.05 o successiva

• AWS Agente PCS versione 1.4.0 o successiva

Quindi aggiorna il gruppo di nodi di calcolo per utilizzare la nuova AMI:

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

Per informazioni sulla creazione di AMI personalizzate, consulta. Amazon Machine Images (AMI) per AWS PZ Per informazioni sulle versioni degli agenti AWS PCS, vedereAWS Versioni dell'agente PCS.

Cluster non disponibile dopo l'aggiornamento a causa di una configurazione QoS non valida

Cause comuni

Dopo l'aggiornamento alla versione 25.11, il cluster entra UPDATE_FAILED nello stato o lo scheduler non è più disponibile. Non è possibile inviare lavori o eseguire comandi di pianificazione. I registri dello scheduler mostrano errori simili ai seguenti:

error: Invalid Allow/DenyQOS value: low
fatal: Partition my-queue has an invalid DenyQOS (low), please check your configuration

Ciò si verifica quando una coda (partizione) fa riferimento a un nome QoS o a QOS impostazioni che non esistono nel database di contabilità Slurm. AllowQOS DenyQOS Slurm 25.11 ha introdotto una convalida più rigorosa dei riferimenti QoS all'avvio dello scheduler. Le versioni precedenti consentivano riferimenti a nomi QoS inesistenti senza errori.

Risoluzione

Prima di eseguire l'aggiornamento alla versione 25.11, verificate che tutti i nomi QoS a cui si fa riferimento nelle configurazioni delle code esistano nel database di contabilità. Connect a un nodo di login ed esegui il seguente comando per verificare se esiste un QoS:

sacctmgr show qos where name=low format=name

Se il QoS non esiste, crealo prima di tentare l'aggiornamento:

sacctmgr add qos low

In alternativa, rimuovi il riferimento QoS dalla configurazione della coda aggiornando le impostazioni personalizzate Slurm della coda per rimuovere il parametro AllowQOSDenyQOS, o QOS prima di aggiornare il cluster.