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à. # 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](#update-troubleshooting-nodes-fail) + [Richiesta di aggiornamento rifiutata con ValidationException](#update-troubleshooting-validation-error) + [Il cluster rimane in stato DI AGGIORNAMENTO](#update-troubleshooting-stuck-updating) + [Il cluster entra nello stato UPDATE\_FAILED dopo l'aggiornamento](#update-troubleshooting-update-failed) + [I nodi di calcolo non si avviano a causa di errori di analisi della configurazione](#update-troubleshooting-config-parse) + [Cluster non disponibile dopo l'aggiornamento a causa di una configurazione QoS non valida](#update-troubleshooting-qos-bootloop) ## 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'`sinfo`output 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](monitoring_scheduler-logs.md) **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](troubleshooting-compute-node-bootstrap.md#troubleshooting-compute-node-bootstrap-retrieve-logs) ### 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](working-with_clusters_version_update.md#version_update-cluster-compatibility) Per informazioni sulla creazione di AMI personalizzate con la versione di pianificazione corretta, consulta. [Amazon Machine Images (AMI) per AWS PZ](working-with_ami.md) ## 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à](https://slurm.schedmd.com/upgrades.html#compatibility_window) 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.11`ACTIVE`, 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](slurm-versions.md) ## 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à](https://slurm.schedmd.com/upgrades.html#compatibility_window), 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](working-with_ami.md) Per informazioni sulle versioni degli agenti AWS PCS, vedere[AWS Versioni dell'agente PCS](pcs-agent-versions.md). ## 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 `AllowQOS``DenyQOS`, o `QOS` prima di aggiornare il cluster.