AWS ParallelCluster risoluzione dei problemi - AWS ParallelCluster
Recupero e conservazione dei logRisoluzione dei problemi di distribuzione dello stackRisoluzione dei problemi nei cluster con modalità di coda multiplaRisoluzione dei problemi nei cluster in modalità coda singolaGruppi di collocamento e problemi relativi al lancio delle istanzeDirectory che non possono essere sostituiteRisoluzione dei problemi in Amazon DCVRisoluzione dei problemi nei cluster con integrazione AWS BatchRisoluzione dei problemi quando una risorsa non riesce a creareRisoluzione dei problemi relativi alle dimensioni delle IAM politicheSupporto aggiuntivo

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

AWS ParallelCluster risoluzione dei problemi

La AWS ParallelCluster comunità mantiene una pagina Wiki che fornisce molti suggerimenti per la risoluzione dei problemi sul AWS ParallelCluster GitHub Wiki. Per un elenco dei problemi noti, vedi Problemi noti.

Recupero e conservazione dei log

I log sono una risorsa utile per la risoluzione dei problemi. Prima di poter utilizzare i log per risolvere i problemi relativi alle AWS ParallelCluster risorse, è necessario creare un archivio di log del cluster. Segui i passaggi descritti nell'argomento Creazione di un archivio dei log di un cluster sul AWS ParallelCluster GitHub Wiki per avviare questo processo.

Se uno dei cluster in esecuzione presenta problemi, è necessario collocarlo in uno STOPPED stato eseguendo il pcluster stop <cluster_name> comando prima di iniziare la risoluzione dei problemi. In questo modo si evita di incorrere in costi imprevisti.

Se pcluster smette di funzionare o se desideri eliminare un cluster preservandone i log, esegui il comando. pcluster delete —keep-logs <cluster_name> L'esecuzione di questo comando elimina il cluster ma mantiene il gruppo di log archiviato in Amazon. CloudWatch Per ulteriori informazioni su questo comando, consulta la pcluster delete documentazione.

Risoluzione dei problemi di distribuzione dello stack

Se il cluster non viene creato e ripristina la creazione dello stack, puoi consultare i seguenti file di registro per diagnosticare il problema. Vuoi cercare l'output di ROLLBACK_IN_PROGRESS in questi log. Il messaggio di errore dovrebbe essere simile al seguente:

$ pcluster create mycluster
Creating stack named: parallelcluster-mycluster
Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS                        
Cluster creation failed.  Failed events:
  - AWS::EC2::Instance MasterServer Received FAILURE signal with UniqueId i-07af1cb218dd6a081

Per diagnosticare il problema, crea nuovamente il cluster utilizzandopcluster create, incluso il --norollback flag. Quindi, SSH nel cluster:

$ pcluster create mycluster --norollback
...
$ pcluster ssh mycluster

Dopo aver effettuato l'accesso al nodo principale, dovresti trovare tre file di registro principali che puoi utilizzare per individuare l'errore.

  • /var/log/cfn-init.logè il registro dello script. cfn-init Per prima cosa controlla questo registro. È probabile che venga visualizzato un errore come Command chef failed in questo registro. Guarda le righe immediatamente precedenti a questa riga per ulteriori dettagli relativi al messaggio di errore. Per ulteriori informazioni, vedere cfn-init.

  • /var/log/cloud-init.logè il log per cloud-init. Se non vedi nullacfn-init.log, prova a controllare successivamente questo registro.

  • /var/log/cloud-init-output.logè l'output dei comandi eseguiti da cloud-init. Questo include l'output di. cfn-init Nella maggior parte dei casi, non è necessario consultare questo registro per risolvere questo tipo di problema.

Risoluzione dei problemi nei cluster con modalità di coda multipla

Questa sezione è rilevante per i cluster che sono stati installati utilizzando la AWS ParallelCluster versione 2.9.0 e successive con Slurm pianificatore di lavori. Per ulteriori informazioni sulla modalità a coda multipla, vedere. Modalità coda multipla

Registri delle chiavi

La tabella seguente fornisce una panoramica dei log delle chiavi per il nodo principale:

/var/log/cfn-init.log

Questo è il log di AWS CloudFormation inizializzazione. Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza. È utile per la risoluzione dei problemi di inizializzazione.

/var/log/chef-client.log

Questo è il registro del client Chef. Contiene tutti i comandi che sono stati eseguiti tramite Chef/CINC. È utile per la risoluzione dei problemi di inizializzazione.

/var/log/parallelcluster/slurm_resume.log

Questo è un ResumeProgram registro. Avvia istanze per nodi dinamici ed è utile per la risoluzione dei problemi di avvio dei nodi dinamici.

/var/log/parallelcluster/slurm_suspend.log

Questo è il registro. SuspendProgram Viene chiamato quando le istanze vengono terminate per i nodi dinamici ed è utile per la risoluzione dei problemi di terminazione dei nodi dinamici. Quando si controlla questo registro, è necessario controllare anche il registro. clustermgtd

/var/log/parallelcluster/clustermgtd

Questo è il clustermgtd registro. Funziona come il demone centralizzato che gestisce la maggior parte delle azioni operative del cluster. È utile per risolvere qualsiasi problema di avvio, interruzione o funzionamento del cluster.

/var/log/slurmctld.log

Questa è la Slurm registro del demone di controllo. AWS ParallelCluster non prende decisioni di scalabilità. Piuttosto, tenta solo di lanciare risorse per soddisfare i Slurm requisiti. È utile per problemi di scalabilità e allocazione, problemi relativi al lavoro e qualsiasi problema di avvio e terminazione relativo alla pianificazione.

Queste sono le note chiave per i nodi Compute:

/var/log/cloud-init-output.log

Questo è il log cloud-init. Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza. È utile per la risoluzione dei problemi di inizializzazione.

/var/log/parallelcluster/computemgtd

Questo è il computemgtd registro. Viene eseguito su ogni nodo di elaborazione per monitorare il nodo nel raro caso in cui il clustermgtd demone sul nodo principale sia offline. È utile per la risoluzione di problemi di terminazione imprevisti.

/var/log/slurmd.log

Questa è la Slurm calcola il registro del demone. È utile per la risoluzione dei problemi relativi all'inizializzazione e agli errori di calcolo.

Risoluzione dei problemi di inizializzazione dei nodi

Questa sezione illustra come risolvere i problemi di inizializzazione dei nodi. Ciò include i problemi in cui il nodo non riesce ad avviarsi, accendersi o entrare a far parte di un cluster.

Nodo principale:

Registri applicabili:

  • /var/log/cfn-init.log

  • /var/log/chef-client.log

  • /var/log/parallelcluster/clustermgtd

  • /var/log/parallelcluster/slurm_resume.log

  • /var/log/slurmctld.log

Controlla i /var/log/chef-client.log registri /var/log/cfn-init.log e. Questi registri dovrebbero contenere tutte le azioni eseguite durante la configurazione del nodo principale. La maggior parte degli errori che si verificano durante l'installazione dovrebbe contenere un messaggio di errore nel /var/log/chef-client.log registro. Se nella configurazione del cluster sono specificati script di preinstallazione o post-installazione, ricontrolla che lo script venga eseguito correttamente tramite i messaggi di registro.

Quando viene creato un cluster, il nodo principale deve attendere che i nodi di calcolo si uniscano al cluster prima di poter entrare a far parte del cluster. Pertanto, se i nodi di elaborazione non riescono a unirsi al cluster, anche il nodo principale fallisce. È possibile seguire una di queste serie di procedure, a seconda del tipo di note di calcolo utilizzate, per risolvere questo tipo di problema:

Nodi di calcolo dinamici:

  • Cerca in ResumeProgram log (/var/log/parallelcluster/slurm_resume.log) il nome del tuo nodo di calcolo per vedere se ResumeProgram è mai stato chiamato con il nodo. (Se ResumeProgram non è mai stato chiamato, puoi controllare slurmctld log (/var/log/slurmctld.log) per determinare se Slurm hai mai provato a chiamare ResumeProgram con il nodo.)

  • Tieni presente che autorizzazioni errate per ResumeProgram potrebbero causare ResumeProgram un errore silenzioso. Se stai utilizzando una configurazione personalizzata AMI con modifiche alla ResumeProgram configurazione, verifica che sia di proprietà dell'slurmutente e disponga dell'autorizzazione 744 (rwxr--r--). ResumeProgram

  • Se ResumeProgram viene chiamato, controlla se è stata avviata un'istanza per il nodo. Se non è stata avviata alcuna istanza, dovrebbe essere visualizzato un messaggio di errore che descrive l'errore di avvio.

  • Se l'istanza viene avviata, potrebbe essersi verificato un problema durante il processo di configurazione. Dovresti vedere l'indirizzo IP privato e l'ID dell'istanza corrispondenti dal ResumeProgram registro. Inoltre, puoi consultare i registri di configurazione corrispondenti per l'istanza specifica. Per ulteriori informazioni sulla risoluzione di un errore di configurazione con un nodo di calcolo, consulta la sezione successiva.

Nodi di calcolo statici:

  • Controlla il registro clustermgtd (/var/log/parallelcluster/clustermgtd) per vedere se sono state lanciate istanze per il nodo. Se non sono state avviate, dovrebbe apparire un messaggio di errore chiaro che descrive in dettaglio l'errore di avvio.

  • Se l'istanza viene avviata, c'è qualche problema durante il processo di configurazione. Dovresti vedere l'indirizzo IP privato e l'ID dell'istanza corrispondenti dal ResumeProgram registro. Inoltre, puoi consultare i registri di configurazione corrispondenti per l'istanza specifica.

  • Nodi di calcolo:

    • Registri applicabili:

      • /var/log/cloud-init-output.log

      • /var/log/slurmd.log

    • Se viene avviato il nodo di calcolo/var/log/cloud-init-output.log, verifica innanzitutto che dovrebbe contenere i log di configurazione simili al /var/log/chef-client.log registro sul nodo principale. La maggior parte degli errori che si verificano durante l'installazione dovrebbero contenere messaggi di errore nel registro. /var/log/cloud-init-output.log Se nella configurazione del cluster sono specificati script di preinstallazione o post-installazione, verificate che siano stati eseguiti correttamente.

    • Se stai usando uno personalizzato AMI con modifica a Slurm configurazione, allora potrebbe esserci un Slurm errore correlato che impedisce al nodo di calcolo di entrare a far parte del cluster. Per gli errori relativi allo scheduler, controlla il /var/log/slurmd.log registro.

Risoluzione dei problemi di sostituzioni e terminazioni impreviste dei nodi

Questa sezione continua a esplorare come risolvere i problemi relativi ai nodi, in particolare quando un nodo viene sostituito o terminato in modo imprevisto.

  • Registri applicabili:

    • /var/log/parallelcluster/clustermgtd(nodo principale)

    • /var/log/slurmctld.log(nodo principale)

    • /var/log/parallelcluster/computemgtd(nodo di calcolo)

  • Nodi sostituiti o terminati in modo imprevisto

    • Controlla il clustermgtd log (/var/log/parallelcluster/clustermgtd) per vedere se è clustermgtd stata intrapresa l'azione necessaria per sostituire o terminare un nodo. Nota che clustermgtd gestisce tutte le normali azioni di manutenzione del nodo.

    • Se il nodo clustermgtd viene sostituito o terminato, dovrebbe esserci un messaggio che spiega in dettaglio il motivo per cui è stata intrapresa questa azione sul nodo. Se il motivo è correlato allo scheduler (ad esempio, perché il nodo è attivoDOWN), controlla il slurmctld log in per ulteriori informazioni. Se il motivo è EC2 correlato ad Amazon, dovrebbe esserci un messaggio informativo che descriva in dettaglio il problema EC2 relativo ad Amazon che ha richiesto la sostituzione.

    • Se clustermgtd non hai terminato il nodo, controlla innanzitutto se si trattava di una terminazione prevista da parte di AmazonEC2, in particolare di una terminazione puntuale. computemgtd, in esecuzione su un nodo Compute, può anche intraprendere un'azione per terminare un nodo se clustermgtd viene considerato non integro. Controlla computemgtd log (/var/log/parallelcluster/computemgtd) per vedere se il nodo è computemgtd terminato.

  • Nodi falliti

    • Controlla slurmctld log (/var/log/slurmctld.log) per vedere perché un job o un nodo non sono riusciti. Tieni presente che i lavori vengono automaticamente messi in coda in caso di errore di un nodo.

    • Se slurm_resume segnala che il nodo è stato avviato e dopo alcuni minuti clustermgtd segnala che non esiste un'istanza corrispondente in Amazon EC2 per quel nodo, il nodo potrebbe fallire durante la configurazione. Per recuperare il log da un compute (/var/log/cloud-init-output.log), procedi nel seguente modo:

      • Invia un lavoro a let Slurm avvia un nuovo nodo.

      • Dopo l'avvio del nodo, abilita la protezione dalla terminazione usando questo comando.

        aws ec2 modify-instance-attribute --instance-id i-xyz --disable-api-termination

      • Recupera l'output della console dal nodo con questo comando.

        aws ec2 get-console-output --instance-id i-xyz --output text

Sostituzione, interruzione o spegnimento delle istanze e dei nodi problematici

  • Registri applicabili:

    • /var/log/parallelcluster/clustermgtd(nodo principale)

    • /var/log/parallelcluster/slurm_suspend.log(nodo principale)

  • Nella maggior parte dei casi, clustermgtd gestisce tutte le azioni di terminazione previste dell'istanza. Controlla il clustermgtd registro per vedere perché non è riuscito a sostituire o terminare un nodo.

  • Se i nodi dinamici non funzionano scaledown_idletime correttamente, controlla il SuspendProgram registro per vedere se SuspendProgram è stato chiamato usando slurmctld il nodo specifico come argomento. Nota che in realtà SuspendProgram non esegue alcuna azione. Piuttosto, registra solo quando viene chiamato. La terminazione e il NodeAddr ripristino di tutte le istanze vengono eseguiti da. clustermgtd Slurm riporta SuspendTimeout automaticamente i nodi in uno POWER_SAVING stato.

Risoluzione di altri problemi noti relativi a nodi e processi

Un altro tipo di problema noto è che AWS ParallelCluster potrebbe non riuscire ad allocare i lavori o a prendere decisioni sulla scalabilità. Con questo tipo di problema, avvia, termina o gestisce le risorse AWS ParallelCluster solo in base a Slurm istruzioni. Per questi problemi, consulta il slurmctld registro per risolverli.

Risoluzione dei problemi nei cluster in modalità coda singola

Nota

A partire dalla versione 2.11.5, AWS ParallelCluster non supporta l'uso di SGE oppure Torque pianificatori.

Questa sezione si applica ai cluster che non dispongono di una modalità di coda multipla con una delle due configurazioni seguenti:

  • Avviato utilizzando una AWS ParallelCluster versione precedente alla 2.9.0 e SGE, Torque, oppure Slurm pianificatori di lavori.

  • Lanciato utilizzando AWS ParallelCluster la versione 2.9.0 o successiva e SGE oppure Torque pianificatori di lavori.

Registri chiave

I seguenti file di registro sono i registri delle chiavi per il nodo principale.

Per la AWS ParallelCluster versione 2.9.0 o successiva:

/var/log/chef-client.log

Questo è il registro del client CINC (chef). Contiene tutti i comandi che sono stati eseguitiCINC. È utile per la risoluzione dei problemi di inizializzazione.

Per tutte le AWS ParallelCluster versioni:

/var/log/cfn-init.log

Questo è il cfn-init registro. Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza ed è quindi utile per la risoluzione dei problemi di inizializzazione. Per ulteriori informazioni, vedere cfn-init.

/var/log/clustermgtd.log

Questo è il registro per clustermgtd Slurm pianificatori. clustermgtdviene eseguito come demone centralizzato che gestisce la maggior parte delle azioni operative del cluster. È utile per risolvere qualsiasi problema di avvio, chiusura o funzionamento del cluster.

/var/log/jobwatcher

Questo è il jobwatcher registro per SGE e Torque pianificatori. jobwatchermonitora la coda dello scheduler e aggiorna l'Auto Scaling Group. È utile per la risoluzione di problemi relativi al ridimensionamento dei nodi.

/var/log/sqswatcher

Questo è il sqswatcher registro per SGE e Torque pianificatori. sqswatcherelabora l'evento Instance Ready inviato da un'istanza di calcolo dopo una corretta inizializzazione. Aggiunge inoltre nodi di calcolo alla configurazione dello scheduler. Questo registro è utile per risolvere il motivo per cui uno o più nodi non sono riusciti a entrare a far parte di un cluster.

Di seguito sono riportati i log chiave per i nodi di calcolo.

AWS ParallelCluster versione 2.9.0 o successiva

/var/log/cloud-init-output.log

Questo è il log di avvio di Cloud. Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza. È utile per la risoluzione dei problemi di inizializzazione.

AWS ParallelCluster versioni precedenti alla 2.9.0

/var/log/cfn-init.log

Questo è il registro di inizializzazione CloudFormation . Contiene tutti i comandi che sono stati eseguiti durante la configurazione di un'istanza. È utile per la risoluzione dei problemi di inizializzazione

Tutte le versioni

/var/log/nodewatcher

Questo è il nodewatcher registro. nodewatcherdemoni che vengono eseguiti su ogni nodo di calcolo quando si utilizza SGE e Torque pianificatori. Ridimensionano un nodo se è inattivo. Questo registro è utile per qualsiasi problema relativo al ridimensionamento delle risorse.

Risoluzione dei problemi relativi alle operazioni di avvio e unione non riuscite

  • Registri applicabili:

    • /var/log/cfn-init-cmd.log(nodo principale e nodo di elaborazione)

    • /var/log/sqswatcher(nodo principale)

  • Se i nodi non sono stati avviati, controlla il /var/log/cfn-init-cmd.log registro per visualizzare il messaggio di errore specifico. Nella maggior parte dei casi, gli errori di avvio dei nodi sono dovuti a un errore di configurazione.

  • Se i nodi di calcolo non sono riusciti a partecipare alla configurazione dello scheduler nonostante la corretta configurazione, controlla il /var/log/sqswatcher registro per vedere se l'evento è stato sqswatcher elaborato. Nella maggior parte dei casi questi problemi sono dovuti al fatto che sqswatcher l'evento non è stato elaborato.

Risoluzione dei problemi di scalabilità

  • Registri applicabili:

    • /var/log/jobwatcher(nodo principale)

    • /var/log/nodewatcher(nodo di calcolo)

  • Problemi di scalabilità verso l'alto: per il nodo principale, controlla il /var/log/jobwatcher registro per vedere se il jobwatcher demone ha calcolato il numero corretto di nodi richiesti e ha aggiornato il gruppo Auto Scaling. Si noti che jobwatcher monitora la coda dello scheduler e aggiorna l'Auto Scaling Group.

  • Problemi di ridimensionamento: per i nodi di elaborazione, controlla il /var/log/nodewatcher registro sul nodo problematico per scoprire perché il nodo è stato ridimensionato. Nota che nodewatcher i demoni ridimensionano un nodo di calcolo se è inattivo.

Un problema noto è rappresentato dagli errori casuali delle note di calcolo su cluster di grandi dimensioni, in particolare quelli con 500 o più nodi di elaborazione. Questo problema è correlato a una limitazione dell'architettura di scalabilità del cluster a coda singola. Se desideri utilizzare un cluster su larga scala, stai utilizzando la AWS ParallelCluster versione v2.9.0 o successiva, stai utilizzando Slurme per evitare questo problema, è consigliabile eseguire l'aggiornamento e passare a un cluster supportato dalla modalità di coda multipla. È possibile farlo pcluster-config convert eseguendo.

Per i cluster su larga scala, potrebbe essere necessaria un'ulteriore ottimizzazione del sistema. Per ulteriori informazioni, contattare. AWS Support

Gruppi di collocamento e problemi relativi al lancio delle istanze

Per ottenere la latenza tra i nodi più bassa, utilizzate un gruppo di posizionamento. Un gruppo di posizionamento garantisce che le istanze si trovino sulla stessa dorsale di rete. Se non ci sono abbastanza istanze disponibili quando viene effettuata una richiesta, viene restituito un InsufficientInstanceCapacity errore. Per ridurre la possibilità di ricevere questo errore quando si utilizzano i gruppi di posizionamento dei cluster, imposta il placement_group parametro su DYNAMIC e imposta il placement parametro su. compute

Se avete bisogno di un filesystem condiviso ad alte prestazioni, prendete in considerazione l'utilizzo FSx di for Lustre.

Se il nodo principale deve appartenere al gruppo di posizionamento, utilizzate lo stesso tipo di istanza e la stessa sottorete sia per la testa che per tutti i nodi di calcolo. In questo modo, il compute_instance_type parametro ha lo stesso valore del master_instance_type parametro, il placement parametro viene impostato su e il compute_subnet_id parametro non viene specificato. cluster Con questa configurazione, il valore del master_subnet_id parametro viene utilizzato per i nodi di calcolo.

Per ulteriori informazioni, consulta Risoluzione dei problemi di avvio delle istanze e Gruppi di posizionamento, ruoli e limitazioni nella Amazon EC2 User Guide.

Directory che non possono essere sostituite

Le seguenti directory sono condivise tra i nodi e non possono essere sostituite.

/home

Ciò include la cartella home dell'utente predefinita (/home/ec2_usersu Amazon Linux, /home/centos su CentOSe così /home/ubuntu via Ubuntu).

/opt/intel

Ciò include IntelMPI, Intel Parallel Studio e file correlati.

/opt/sge
Nota

A partire dalla versione 2.11.5, AWS ParallelCluster non supporta l'uso di SGE oppure Torque pianificatori.

Questo include Son of Grid Engine e file correlati. (Condizionale, solo se scheduler = sge.)

/opt/slurm

Ciò include Slurm Workload Manager e file correlati. (Condizionale, solo se scheduler = slurm.)

/opt/torque
Nota

A partire dalla versione 2.11.5, AWS ParallelCluster non supporta l'uso di SGE oppure Torque pianificatori.

Questo include Torque Resource Manager e file correlati. (Condizionale, solo se scheduler = torque.)

Risoluzione dei problemi in Amazon DCV

Registri per Amazon DCV

I log di Amazon DCV vengono scritti nei file della /var/log/dcv/ directory. La revisione di questi registri può aiutare a risolvere i problemi.

Memoria tipo DCV istanza Amazon

Il tipo di istanza deve avere almeno 1,7 gibibyte (GiB) di per eseguire Amazon. RAM DCV Nano e micro i tipi di istanza non dispongono di memoria sufficiente per eseguire AmazonDCV.

DCVProblemi con Ubuntu Amazon

Quando esegui Gnome Terminal su una DCV sessione su Ubuntu, potresti non avere automaticamente accesso all'ambiente utente disponibile AWS ParallelCluster tramite la shell di login. L'ambiente utente fornisce moduli di ambiente come openmpi o intelmpi e altre impostazioni utente.

Le impostazioni predefinite di Gnome Terminal impediscono alla shell di avviarsi come shell di accesso. Ciò significa che i profili della shell non vengono generati automaticamente e l'ambiente AWS ParallelCluster utente non viene caricato.

Per creare correttamente il profilo della shell e accedere all'ambiente AWS ParallelCluster utente, effettuate una delle seguenti operazioni:

  • Modificate le impostazioni predefinite del terminale:

    1. Scegli il menu Modifica nel terminale Gnome.

    2. Seleziona Preferenze, quindi Profili.

    3. Scegli Comando e seleziona Esegui comando come shell di accesso.

    4. Apri un nuovo terminale.

  • Usa la riga di comando per trovare i profili disponibili:

    $ source /etc/profile && source $HOME/.bashrc

Risoluzione dei problemi nei cluster con integrazione AWS Batch

Questa sezione è pertinente ai cluster con integrazione di AWS Batch scheduler.

Problemi relativi al nodo principale

I problemi di configurazione relativi al nodo principale possono essere risolti allo stesso modo del cluster a coda singola. Per ulteriori informazioni su questi problemi, consulta Risoluzione dei problemi nei cluster in modalità coda singola.

AWS Batch problemi di invio di lavori paralleli a più nodi

In caso di problemi nell'invio di lavori paralleli multinodo quando si utilizza AWS Batch come pianificatore di processi, è necessario eseguire l'aggiornamento alla AWS ParallelCluster versione 2.5.0. Se ciò non è possibile, puoi utilizzare la soluzione alternativa descritta in dettaglio nell'argomento: applicare patch automatiche a un cluster utilizzato per inviare lavori paralleli a più nodi tramite. AWS Batch

Problemi di calcolo

AWS Batch gestisce gli aspetti di scalabilità e calcolo dei tuoi servizi. Se riscontri problemi relativi all'elaborazione, consulta la documentazione AWS Batch sulla risoluzione dei problemi per ricevere assistenza.

Job fallimenti

Se un processo fallisce, è possibile eseguire il awsbout comando per recuperare l'output del processo. Puoi anche eseguire il awsbstat -d comando per ottenere un collegamento ai log dei lavori archiviati da Amazon CloudWatch.

Risoluzione dei problemi quando una risorsa non riesce a creare

Questa sezione è rilevante per le risorse del cluster in caso di mancata creazione.

Quando una risorsa non riesce a creare, ParallelCluster restituisce un messaggio di errore come il seguente.

pcluster create -c config my-cluster
Beginning cluster creation for cluster: my-cluster
WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with 
id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the 
Internet (e.g. a NAT Gateway and a valid route table).
WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with
id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet 
(e.g. a NAT Gateway and a valid route table).
Info: There is a newer version 3.0.3 of AWS ParallelCluster available.
Creating stack named: parallelcluster-my-cluster
Status: parallelcluster-my-cluster - ROLLBACK_IN_PROGRESS                   
Cluster creation failed.  Failed events:
- AWS::CloudFormation::Stack MasterServerSubstack Embedded stack 
arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 
was not successfully created: 
The following resource(s) failed to create: [MasterServer]. 
- AWS::CloudFormation::Stack parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL The following resource(s) failed to create: [MasterServer]. 
- AWS::EC2::Instance MasterServer You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the 
specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit.  
(Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null)
}

Ad esempio, se viene visualizzato il messaggio di stato mostrato nella risposta al comando precedente, è necessario utilizzare tipi di istanza che non superino il CPU limite v corrente o richiedano una maggiore CPU capacità v.

Puoi anche utilizzare la CloudFormation console per visualizzare le informazioni sullo "Cluster creation failed" stato.

Visualizza i messaggi di CloudFormation errore dalla console.

  1. Accedi a AWS Management Console e vai a https://console.aws.amazon.com/cloudformazione.

  2. Seleziona lo stack denominato parallelcluster-cluster_name.

  3. Scegli la scheda Eventi.

  4. Controlla lo stato della risorsa che non è stata creata scorrendo l'elenco degli eventi delle risorse per ID logico. Se la creazione di una sottoattività non è riuscita, procedi a ritroso per trovare l'evento relativo alla risorsa non riuscita.

  5. Un esempio di AWS CloudFormation messaggio di errore:

    2022-02-07 11:59:14 UTC-0800	MasterServerSubstack	CREATE_FAILED	Embedded stack 
arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789
was not successfully created: The following resource(s) failed to create: [MasterServer].

Risoluzione dei problemi relativi alle dimensioni delle IAM politiche

Fai riferimento alle IAM AWS STS quote, ai requisiti relativi ai nomi e ai limiti di caratteri per verificare le quote sulle politiche gestite associate ai ruoli. Se la dimensione di una policy gestita supera la quota, suddividi la policy in due o più policy. Se superi la quota del numero di politiche associate a un IAM ruolo, crea ruoli aggiuntivi e distribuisci le politiche tra di loro per soddisfare la quota.

Supporto aggiuntivo

Per un elenco dei problemi noti, consulta la pagina GitHubWiki principale o la pagina dei problemi. Per problemi più urgenti, contatta AWS Support o apri un nuovo GitHub problema.