AWS ParallelCluster Problembehebung - AWS ParallelCluster
Protokolle abrufen und aufbewahrenBehebung von Problemen bei der Stack-BereitstellungBehebung von Problemen in Clustern mit mehreren WarteschlangenmodiBehebung von Problemen in Clustern im Single-Queue-ModusProbleme bei der Platzierung von Gruppen und beim Starten von InstancesVerzeichnisse, die nicht ersetzt werden könnenBehebung von Problemen bei Amazon DCVBehebung von Problemen in Clustern mit AWS Batch IntegrationFehlerbehebung, wenn eine Ressource nicht erstellt werden kannBehebung von Problemen mit der IAM RichtliniengrößeZusätzliche Unterstützung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

AWS ParallelCluster Problembehebung

Die AWS ParallelCluster Community unterhält eine Wiki-Seite, die viele Tipps zur Fehlerbehebung im AWS ParallelCluster GitHub Wiki enthält. Eine Liste der bekannten Probleme finden Sie unter Bekannte Probleme.

Protokolle abrufen und aufbewahren

Protokolle sind eine nützliche Ressource für die Behebung von Problemen. Bevor Sie Protokolle zur Behebung von Problemen mit Ihren AWS ParallelCluster Ressourcen verwenden können, sollten Sie zunächst ein Archiv mit Clusterprotokollen erstellen. Folgen Sie den Schritten, die im AWS ParallelCluster GitHub Wiki im Thema Erstellen eines Clusterprotokollarchivs beschrieben sind, um diesen Vorgang zu starten.

Wenn bei einem Ihrer laufenden Cluster Probleme auftreten, sollten Sie den Cluster in einen STOPPED Zustand versetzen, indem Sie den pcluster stop <cluster_name> Befehl ausführen, bevor Sie mit der Fehlerbehebung beginnen. Dadurch werden unerwartete Kosten vermieden.

Wenn der pcluster Cluster nicht mehr funktioniert oder wenn Sie einen Cluster löschen und gleichzeitig seine Protokolle beibehalten möchten, führen Sie den pcluster delete —keep-logs <cluster_name> Befehl aus. Wenn Sie diesen Befehl ausführen, wird der Cluster gelöscht, die Protokollgruppe, die in Amazon CloudWatch gespeichert ist, jedoch beibehalten. Weitere Informationen zu diesem Befehl finden Sie in der pcluster delete Dokumentation.

Behebung von Problemen bei der Stack-Bereitstellung

Wenn Ihr Cluster nicht erstellt werden kann und die Stack-Erstellung rückgängig gemacht wird, können Sie die folgenden Protokolldateien durchsuchen, um das Problem zu diagnostizieren. Sie möchten ROLLBACK_IN_PROGRESS in diesen Protokollen nach der Ausgabe von suchen. Die Fehlermeldung sollte wie folgt aussehen:

$ 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

Um das Problem zu diagnostizieren, erstellen Sie den Cluster erneutpcluster create, einschließlich des --norollback Flags. Dann SSH in den Cluster:

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

Nachdem Sie beim Hauptknoten angemeldet sind, sollten Sie drei primäre Protokolldateien finden, anhand derer Sie den Fehler lokalisieren können.

  • /var/log/cfn-init.logist das Protokoll für das cfn-init Skript. Überprüfen Sie zuerst dieses Protokoll. Sie werden wahrscheinlich einen Fehler wie Command chef failed in diesem Protokoll sehen. Sehen Sie sich die Zeilen unmittelbar vor dieser Zeile an, um weitere Einzelheiten zu der Fehlermeldung zu erfahren. Weitere Informationen finden Sie unter cfn-init.

  • /var/log/cloud-init.logist das Protokoll für Cloud-Init. Wenn Sie nichts darin sehen, versuchen Sie als cfn-init.log Nächstes, in diesem Protokoll nachzuschauen.

  • /var/log/cloud-init-output.logist die Ausgabe von Befehlen, die von cloud-init ausgeführt wurden. Dies beinhaltet die Ausgabe von. cfn-init In den meisten Fällen müssen Sie sich dieses Protokoll nicht ansehen, um diese Art von Problem zu beheben.

Behebung von Problemen in Clustern mit mehreren Warteschlangenmodi

Dieser Abschnitt ist relevant für Cluster, die mit AWS ParallelCluster Version 2.9.0 und höher mit dem installiert wurden Slurm Job-Scheduler. Weitere Hinweise zum Modus mit mehreren Warteschlangen finden Sie unterModus mit mehreren Warteschlangen.

Wichtige Protokolle

Die folgende Tabelle bietet einen Überblick über die Schlüsselprotokolle für den Hauptknoten:

/var/log/cfn-init.log

Dies ist das AWS CloudFormation Init-Protokoll. Es enthält alle Befehle, die beim Einrichten einer Instanz ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen.

/var/log/chef-client.log

Dies ist das Chef-Client-Protokoll. Es enthält alle Befehle, die über CINC Chef/ ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen.

/var/log/parallelcluster/slurm_resume.log

Das ist ein ResumeProgram Protokoll. Es startet Instances für dynamische Knoten und ist nützlich für die Behebung von Problemen beim Starten dynamischer Knoten.

/var/log/parallelcluster/slurm_suspend.log

Dies ist das SuspendProgram Protokoll. Es wird aufgerufen, wenn Instanzen für dynamische Knoten beendet werden, und ist nützlich, um Probleme mit der Terminierung dynamischer Knoten zu beheben. Wenn Sie dieses Protokoll überprüfen, sollten Sie auch das clustermgtd Protokoll überprüfen.

/var/log/parallelcluster/clustermgtd

Das ist das clustermgtd Protokoll. Es läuft als zentraler Daemon, der die meisten Clusteroperationen verwaltet. Er ist nützlich für die Behebung von Problemen beim Starten, Beenden oder Clusterbetrieb.

/var/log/slurmctld.log

Das ist Slurm steuere das Daemon-Protokoll. AWS ParallelCluster trifft keine Skalierungsentscheidungen. Vielmehr versucht es nur, Ressourcen bereitzustellen, um die Slurm Anforderungen. Dies ist nützlich bei Problemen mit der Skalierung und Zuweisung, bei Problemen mit dem Job und bei Problemen mit der Terminplanung.

Dies sind die wichtigsten Hinweise für die Compute-Knoten:

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

Dies ist das Cloud-Init-Protokoll. Es enthält alle Befehle, die bei der Einrichtung einer Instanz ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen.

/var/log/parallelcluster/computemgtd

Dies ist das computemgtd Protokoll. Es wird auf jedem Rechenknoten ausgeführt, um den Knoten in dem seltenen Fall zu überwachen, dass der clustermgtd Daemon auf dem Hauptknoten offline ist. Es ist nützlich bei der Behebung unerwarteter Kündigungsprobleme.

/var/log/slurmd.log

Das ist der Slurm Daemon-Protokoll berechnen. Es ist nützlich bei der Behebung von Problemen mit der Initialisierung und bei Rechenfehlern.

Behebung von Problemen mit der Knoteninitialisierung

In diesem Abschnitt wird beschrieben, wie Sie Probleme mit der Knoteninitialisierung beheben können. Dazu gehören Probleme, bei denen der Knoten nicht gestartet, eingeschaltet oder einem Cluster nicht beitreten kann.

Hauptknoten:

Anwendbare Protokolle:

  • /var/log/cfn-init.log

  • /var/log/chef-client.log

  • /var/log/parallelcluster/clustermgtd

  • /var/log/parallelcluster/slurm_resume.log

  • /var/log/slurmctld.log

Überprüfen Sie die /var/log/cfn-init.log und /var/log/chef-client.log -Protokolle. Diese Protokolle sollten alle Aktionen enthalten, die bei der Einrichtung des Hauptknotens ausgeführt wurden. Bei den meisten Fehlern, die während der Installation auftreten, sollte eine Fehlermeldung im /var/log/chef-client.log Protokoll stehen. Wenn in der Konfiguration des Clusters Skripts vor oder nach der Installation angegeben sind, überprüfen Sie anhand der Protokollmeldungen, ob das Skript erfolgreich ausgeführt wird.

Wenn ein Cluster erstellt wird, muss der Hauptknoten warten, bis die Rechenknoten dem Cluster beitreten, bevor er dem Cluster beitreten kann. Wenn also die Rechenknoten dem Cluster nicht beitreten können, schlägt auch der Hauptknoten fehl. Je nachdem, welche Art von Compute Notes Sie verwenden, können Sie eines der folgenden Verfahren anwenden, um diese Art von Problem zu beheben:

Dynamische Rechenknoten:

  • Suchen Sie in ResumeProgram log (/var/log/parallelcluster/slurm_resume.log) nach dem Namen Ihres Rechenknotens, um zu sehen, ob der Knoten jemals aufgerufen ResumeProgram wurde. (Falls ResumeProgram es noch nie aufgerufen wurde, können Sie anhand von slurmctld log (/var/log/slurmctld.log) überprüfen, ob Slurm hat schon einmal versucht, ResumeProgram mit dem Knoten anzurufen.)

  • Beachten Sie, dass falsche Berechtigungen für ResumeProgram dazu führen ResumeProgram können, dass der Fehler automatisch fehlschlägt. Wenn Sie ein benutzerdefiniertes Objekt AMI mit Änderungen am ResumeProgram Setup verwenden, überprüfen Sie, ob das dem slurm Benutzer ResumeProgram gehört und über die Berechtigung 744 (rwxr--r--) verfügt.

  • Wenn aufgerufen ResumeProgram wird, überprüfen Sie, ob eine Instanz für den Knoten gestartet wurde. Wenn keine Instance gestartet wurde, sollte Ihnen eine Fehlermeldung angezeigt werden, die den Startfehler beschreibt.

  • Wenn die Instance gestartet wird, ist möglicherweise ein Problem während des Einrichtungsvorgangs aufgetreten. Sie sollten die entsprechende private IP-Adresse und Instanz-ID aus dem ResumeProgram Protokoll sehen. Darüber hinaus können Sie sich die entsprechenden Setup-Protokolle für die jeweilige Instanz ansehen. Weitere Informationen zur Behebung eines Setup-Fehlers mit einem Rechenknoten finden Sie im nächsten Abschnitt.

Statische Rechenknoten:

  • Prüfen Sie im Protokoll clustermgtd (/var/log/parallelcluster/clustermgtd), ob Instanzen für den Knoten gestartet wurden. Wenn sie nicht gestartet wurden, sollte eine klare Fehlermeldung angezeigt werden, in der der Startfehler detailliert beschrieben wird.

  • Wenn die Instanz gestartet wird, liegt während des Einrichtungsvorgangs ein Problem vor. Sie sollten die entsprechende private IP-Adresse und Instanz-ID aus dem ResumeProgram Protokoll sehen. Darüber hinaus können Sie sich die entsprechenden Setup-Protokolle für die jeweilige Instanz ansehen.

  • Knoten berechnen:

    • Anwendbare Protokolle:

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

      • /var/log/slurmd.log

    • Wenn der Rechenknoten gestartet wird, überprüfen Sie zunächst/var/log/cloud-init-output.log, ob dieser die Setup-Protokolle enthalten sollte, die dem /var/log/chef-client.log Protokoll auf dem Hauptknoten ähneln. Bei den meisten Fehlern, die während des Setups auftreten, sollten sich Fehlermeldungen im /var/log/cloud-init-output.log Protokoll befinden. Wenn in der Clusterkonfiguration Skripts vor oder nach der Installation angegeben sind, überprüfen Sie, ob sie erfolgreich ausgeführt wurden.

    • Wenn Sie ein benutzerdefiniertes System mit einer Änderung AMI von verwenden Slurm Konfiguration, dann könnte es eine geben Slurm verwandter Fehler, der verhindert, dass der Compute-Knoten dem Cluster beitritt. Informationen zu Fehlern im Zusammenhang mit dem Scheduler finden Sie im /var/log/slurmd.log Protokoll.

Behebung unerwarteter Knotenersetzungen und -beendigungen

In diesem Abschnitt wird weiter untersucht, wie Sie Probleme im Zusammenhang mit Knoten beheben können, insbesondere wenn ein Knoten ersetzt oder unerwartet beendet wird.

  • Anwendbare Protokolle:

    • /var/log/parallelcluster/clustermgtd(Kopfknoten)

    • /var/log/slurmctld.log(Kopfknoten)

    • /var/log/parallelcluster/computemgtd(Rechenknoten)

  • Knoten wurden unerwartet ersetzt oder beendet

    • Prüfen Sie im clustermgtd Protokoll (/var/log/parallelcluster/clustermgtd), ob Sie die Aktion zum Ersetzen oder Beenden eines Knotens ergriffen clustermgtd haben. Beachten Sie, dass alle normalen Wartungsaktionen für Knoten clustermgtd behandelt werden.

    • Wenn der Knoten clustermgtd ersetzt oder beendet wurde, sollte eine Meldung erscheinen, in der detailliert beschrieben wird, warum diese Aktion auf dem Knoten ausgeführt wurde. Wenn der Grund mit dem Scheduler zusammenhängt (z. B. weil der Knoten aktiv istDOWN), schauen Sie im slurmctld Protokoll nach, um weitere Informationen zu erhalten. Wenn der Grund auf Amazon EC2 zurückzuführen ist, sollte eine informative Nachricht angezeigt werden, in der das Problem EC2 im Zusammenhang mit Amazon beschrieben wird, für das der Ersatz erforderlich war.

    • Wenn der Knoten clustermgtd nicht beendet wurde, überprüfen Sie zunächst, ob es sich um eine erwartete Kündigung durch Amazon handeltEC2, genauer gesagt um eine Spot-Terminierung. computemgtd, der auf einem Compute-Knoten ausgeführt wird, kann auch Maßnahmen ergreifen, um einen Knoten zu beenden, wenn clustermgtd dieser als fehlerhaft eingestuft wird. Prüfen Sie computemgtd log (/var/log/parallelcluster/computemgtd), um zu sehen, ob der Knoten computemgtd beendet wurde.

  • Knoten sind ausgefallen

    • Checken Sie in slurmctld log (/var/log/slurmctld.log) ein, um zu sehen, warum ein Job oder ein Knoten fehlgeschlagen ist. Beachten Sie, dass Jobs automatisch in die Warteschlange gestellt werden, wenn ein Knoten ausfällt.

    • Wenn slurm_resume gemeldet wird, dass der Knoten gestartet wurde, und nach einigen Minuten clustermgtd meldet, dass es keine entsprechende Instance in Amazon EC2 für diesen Knoten gibt, schlägt der Knoten möglicherweise während der Einrichtung fehl. Gehen Sie wie folgt vor, um das Protokoll von einem Compute (/var/log/cloud-init-output.log) abzurufen:

      • Reichen Sie einen Job zur Vermietung ein Slurm einen neuen Knoten einrichten.

      • Nachdem der Knoten gestartet wurde, aktivieren Sie den Kündigungsschutz mit diesem Befehl.

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

      • Rufen Sie mit diesem Befehl die Konsolenausgabe vom Knoten ab.

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

Probleminstanzen und Knoten ersetzen, beenden oder herunterfahren

  • Anwendbare Protokolle:

    • /var/log/parallelcluster/clustermgtd(Kopfknoten)

    • /var/log/parallelcluster/slurm_suspend.log(Kopfknoten)

  • Bearbeitet in den meisten Fällen clustermgtd alle erwarteten Aktionen zur Instanzbeendigung. Sehen Sie im clustermgtd Protokoll nach, warum ein Knoten nicht ersetzt oder beendet werden konnte.

  • Wenn dynamische Knoten ausfallenscaledown_idletime, schauen Sie im SuspendProgram Protokoll nach, ob der spezifische Knoten als Argument aufgerufen SuspendProgram wurde. slurmctld Beachten Sie, dass tatsächlich SuspendProgram keine Aktion ausgeführt wird. Vielmehr protokolliert es nur, wenn es aufgerufen wird. Das Beenden und NodeAddr Zurücksetzen aller Instanzen erfolgt vonclustermgtd. Slurm versetzt Knoten danach SuspendTimeout automatisch wieder in einen POWER_SAVING Zustand.

Behebung anderer bekannter Knoten- und Jobprobleme

Ein anderes bekanntes Problem besteht darin, dass AWS ParallelCluster möglicherweise keine Jobs zugewiesen oder Skalierungsentscheidungen getroffen werden können. Bei dieser Art von Problem werden Ressourcen AWS ParallelCluster nur entsprechend gestartet, beendet oder verwaltet Slurm Anweisungen. Überprüfen Sie bei diesen Problemen das slurmctld Protokoll, um diese Probleme zu beheben.

Behebung von Problemen in Clustern im Single-Queue-Modus

Anmerkung

Ab Version 2.11.5 wird die AWS ParallelCluster Verwendung von nicht unterstützt SGE or Torque Scheduler.

Dieser Abschnitt bezieht sich auf Cluster, die nicht über einen Modus mit mehreren Warteschlangen mit einer der folgenden beiden Konfigurationen verfügen:

  • Mit einer AWS ParallelCluster Version vor 2.9.0 gestartet und SGE, Torque, oder Slurm Jobplaner.

  • Mit AWS ParallelCluster Version 2.9.0 oder höher gestartet und SGE or Torque Job-Scheduler.

Wichtige Protokolle

Die folgenden Protokolldateien sind die Schlüsselprotokolle für den Hauptknoten.

Für AWS ParallelCluster Version 2.9.0 oder höher:

/var/log/chef-client.log

Dies ist das CINC (Chef-) Client-Protokoll. Es enthält alle Befehle, die ausgeführt wurdenCINC. Es ist nützlich bei der Behebung von Initialisierungsproblemen.

Für alle AWS ParallelCluster Versionen:

/var/log/cfn-init.log

Das ist das cfn-init Protokoll. Es enthält alle Befehle, die beim Einrichten einer Instanz ausgeführt wurden, und ist daher nützlich für die Behebung von Initialisierungsproblemen. Weitere Informationen finden Sie unter cfn-init.

/var/log/clustermgtd.log

Dies ist das Protokoll für clustermgtd Slurm Scheduler. clustermgtdwird als zentraler Daemon ausgeführt, der die meisten Clusteroperationen verwaltet. Er ist nützlich, um Probleme beim Starten, Beenden oder Clusterbetrieb zu beheben.

/var/log/jobwatcher

Dies ist das jobwatcher Protokoll für SGE and Torque Scheduler. jobwatcherüberwacht die Scheduler-Warteschlange und aktualisiert die Auto Scaling Group. Dies ist nützlich bei der Behebung von Problemen im Zusammenhang mit der Skalierung von Knoten.

/var/log/sqswatcher

Dies ist das sqswatcher Protokoll für SGE and Torque Scheduler. sqswatcherverarbeitet das Instance-Ready-Ereignis, das von einer Recheninstanz nach erfolgreicher Initialisierung gesendet wird. Außerdem werden Rechenknoten zur Scheduler-Konfiguration hinzugefügt. Dieses Protokoll ist nützlich, um zu beheben, warum ein oder mehrere Knoten einem Cluster nicht beitreten konnten.

Im Folgenden sind die wichtigsten Protokolle für die Rechenknoten aufgeführt.

AWS ParallelCluster Version 2.9.0 oder höher

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

Dies ist das Cloud-Init-Protokoll. Es enthält alle Befehle, die bei der Einrichtung einer Instanz ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen.

AWS ParallelCluster Versionen vor 2.9.0

/var/log/cfn-init.log

Dies ist das CloudFormation Init-Protokoll. Es enthält alle Befehle, die beim Einrichten einer Instanz ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen

Alle Versionen

/var/log/nodewatcher

Das ist das nodewatcher Protokoll. nodewatcherDaemons, die auf jedem Compute-Knoten laufen, wenn SGE and Torque Scheduler. Sie skalieren einen Knoten herunter, wenn er inaktiv ist. Dieses Protokoll ist nützlich für alle Probleme im Zusammenhang mit der Reduzierung von Ressourcen.

Fehlerbehebung bei fehlgeschlagenen Start- und Verbindungsvorgängen

  • Anwendbare Protokolle:

    • /var/log/cfn-init-cmd.log(Hauptknoten und Rechenknoten)

    • /var/log/sqswatcher(Hauptknoten)

  • Wenn Knoten nicht gestartet werden konnten, schauen Sie im /var/log/cfn-init-cmd.log Protokoll nach, um die entsprechende Fehlermeldung zu finden. In den meisten Fällen sind Fehler beim Starten von Knoten auf einen Einrichtungsfehler zurückzuführen.

  • Falls Compute-Knoten trotz erfolgreicher Einrichtung nicht an der Scheduler-Konfiguration teilnehmen konnten, überprüfen Sie im /var/log/sqswatcher Protokoll, ob das Ereignis sqswatcher verarbeitet wurde. Diese Probleme sind in den meisten Fällen darauf zurückzuführen, sqswatcher dass das Ereignis nicht verarbeitet wurde.

Behebung von Skalierungsproblemen

  • Anwendbare Protokolle:

    • /var/log/jobwatcher(Kopfknoten)

    • /var/log/nodewatcher(Rechenknoten)

  • Probleme mit der Skalierung: Überprüfen Sie für den Hauptknoten im /var/log/jobwatcher Protokoll, ob der jobwatcher Daemon die richtige Anzahl der erforderlichen Knoten berechnet und die Auto Scaling Scaling-Gruppe aktualisiert hat. Beachten Sie, dass die Scheduler-Warteschlange jobwatcher überwacht und die Auto Scaling Group aktualisiert wird.

  • Probleme beim Herunterskalieren: Überprüfen Sie bei Rechenknoten das /var/log/nodewatcher Protokoll auf dem Problemknoten, um zu sehen, warum der Knoten herunterskaliert wurde. Beachten Sie, dass nodewatcher Daemons einen Rechenknoten herunterskalieren, wenn er inaktiv ist.

Ein bekanntes Problem sind zufällige Fehler bei Rechennotizen auf großen Clustern, insbesondere solchen mit 500 oder mehr Rechenknoten. Dieses Problem steht im Zusammenhang mit einer Einschränkung der Skalierungsarchitektur eines Clusters mit einer Warteschlange. Wenn Sie einen großen Cluster verwenden möchten, verwenden Sie AWS ParallelCluster Version v2.9.0 oder höher Slurm, und dieses Problem vermeiden möchten, sollten Sie ein Upgrade durchführen und zu einem Cluster wechseln, der den Modus mehrerer Warteschlangen unterstützt. Sie können dies tun, indem Sie Folgendes ausführenpcluster-config convert.

Bei extrem großen Clustern ist möglicherweise eine zusätzliche Optimierung Ihres Systems erforderlich. Für weitere Informationen wenden Sie sich an AWS Support.

Probleme bei der Platzierung von Gruppen und beim Starten von Instances

Verwenden Sie eine Platzierungsgruppe, um die niedrigste Latenz zwischen den Knoten zu erzielen. Eine Platzierungsgruppe garantiert, dass sich Ihre Instances auf demselben Netzwerk-Backbone befinden. Wenn bei einer Anfrage nicht genügend Instances verfügbar sind, wird ein InsufficientInstanceCapacity Fehler zurückgegeben. Um die Wahrscheinlichkeit zu verringern, dass dieser Fehler bei der Verwendung von Cluster-Placement-Gruppen auftritt, setzen Sie den placement_group Parameter auf DYNAMIC und setzen Sie den placement Parameter aufcompute.

Wenn Sie ein leistungsstarkes gemeinsam genutztes Dateisystem benötigen, sollten Sie es FSxfür Lustre verwenden.

Wenn sich der Hauptknoten in der Platzierungsgruppe befinden muss, verwenden Sie denselben Instanztyp und dasselbe Subnetz sowohl für den Kopf als auch für alle Rechenknoten. Dadurch hat der compute_instance_type Parameter denselben Wert wie der master_instance_type Parameter, der placement Parameter wird auf cluster gesetzt und der compute_subnet_id Parameter ist nicht angegeben. Bei dieser Konfiguration wird der Wert des master_subnet_id Parameters für die Rechenknoten verwendet.

Weitere Informationen finden Sie unter Problembehandlung bei Instance-Starts und Placement-Gruppen, Rollen und Einschränkungen im EC2Amazon-Benutzerhandbuch.

Verzeichnisse, die nicht ersetzt werden können

Die folgenden Verzeichnisse werden von den Knoten gemeinsam genutzt und können nicht ersetzt werden.

/home

Dazu gehört der Standard-Home-Ordner des Benutzers (/home/ec2_userauf Amazon Linux, /home/centos auf CentOS, und /home/ubuntu auf Ubuntu).

/opt/intel

Dazu gehören IntelMPI, Intel Parallel Studio und zugehörige Dateien.

/opt/sge
Anmerkung

Ab Version 2.11.5 wird die AWS ParallelCluster Verwendung von nicht unterstützt SGE or Torque Scheduler.

Das beinhaltet Son of Grid Engine und zugehörige Dateien. (Bedingt, nur wenn scheduler = sge.)

/opt/slurm

Das beinhaltet Slurm Workload Manager und zugehörige Dateien. (Bedingt, nur wenn scheduler = slurm.)

/opt/torque
Anmerkung

Ab Version 2.11.5 wird die AWS ParallelCluster Verwendung von nicht unterstützt SGE or Torque Scheduler.

Das beinhaltet Torque Resource Manager und zugehörige Dateien. (Bedingt, nur wenn scheduler = torque.)

Behebung von Problemen bei Amazon DCV

Logs für Amazon DCV

Die Protokolle für Amazon DCV werden in Dateien im /var/log/dcv/ Verzeichnis geschrieben. Die Überprüfung dieser Protokolle kann bei der Behebung von Problemen hilfreich sein.

Speicher vom DCV Amazon-Instanztyp

Der Instance-Typ sollte mindestens 1,7 Gibibyte (GiB) haben, um Amazon ausführen RAM zu können. DCV Nano and micro Instance-Typen haben nicht genug Speicher, um Amazon auszuführenDCV.

DCVProbleme mit Ubuntu Amazon

Wenn Sie Gnome Terminal über eine DCV Sitzung auf Ubuntu ausführen, haben Sie möglicherweise nicht automatisch Zugriff auf die Benutzerumgebung, die über die AWS ParallelCluster Login-Shell verfügbar ist. Die Benutzerumgebung bietet Umgebungsmodule wie openmpi oder intelmpi und andere Benutzereinstellungen.

Die Standardeinstellungen von Gnome Terminal verhindern, dass die Shell als Login-Shell gestartet wird. Das bedeutet, dass Shell-Profile nicht automatisch bezogen werden und die AWS ParallelCluster Benutzerumgebung nicht geladen wird.

Gehen Sie wie folgt vor, um das Shell-Profil korrekt zu beziehen und auf die AWS ParallelCluster Benutzerumgebung zuzugreifen:

  • Ändern Sie die standardmäßigen Terminaleinstellungen:

    1. Wählen Sie im Gnome-Terminal das Menü Bearbeiten.

    2. Wählen Sie Einstellungen und dann Profile aus.

    3. Wählen Sie „Befehl“ und anschließend „Befehl als Login-Shell ausführen“.

    4. Öffnen Sie ein neues Terminal.

  • Verwenden Sie die Befehlszeile, um die verfügbaren Profile abzurufen:

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

Behebung von Problemen in Clustern mit AWS Batch Integration

Dieser Abschnitt ist relevant für Cluster mit AWS Batch Scheduler-Integration.

Probleme mit dem Hauptknoten

Einrichtungsprobleme im Zusammenhang mit dem Hauptknoten können auf die gleiche Weise wie bei Clustern mit einzelnen Warteschlangen behoben werden. Weitere Informationen zu diesen Problemen finden Sie unter Behebung von Problemen in Clustern im Single-Queue-Modus.

AWS Batch Probleme bei der Einreichung parallel Jobs mit mehreren Knoten

Wenn Sie bei der Verwendung AWS Batch als Job-Scheduler Probleme beim Senden von parallel Jobs mit mehreren Knoten haben, sollten Sie ein Upgrade auf AWS ParallelCluster Version 2.5.0 durchführen. Falls das nicht möglich ist, können Sie die Problemumgehung verwenden, die im Thema beschrieben wird: Selbstpatchen eines Clusters, über das parallel Aufträge mit mehreren Knoten gesendet werden. AWS Batch

Probleme mit der Datenverarbeitung

AWS Batch verwaltet die Skalierungs- und Rechenaspekte Ihrer Dienste. Wenn Sie auf Probleme im Zusammenhang mit der Datenverarbeitung stoßen, finden Sie in der Dokumentation AWS Batch zur Fehlerbehebung Hilfe.

Fehlschläge Job

Wenn ein Job fehlschlägt, können Sie den awsbout Befehl ausführen, um die Jobausgabe abzurufen. Sie können den awsbstat -d Befehl auch ausführen, um einen Link zu den von Amazon gespeicherten Jobprotokollen zu erhalten CloudWatch.

Fehlerbehebung, wenn eine Ressource nicht erstellt werden kann

Dieser Abschnitt ist relevant für Clusterressourcen, wenn sie nicht erstellt werden können.

Wenn eine Ressource nicht erstellt werden kann, wird eine Fehlermeldung wie die folgende ParallelCluster zurückgegeben.

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)
}

Wenn Sie beispielsweise die in der vorherigen Befehlsantwort angezeigte Statusmeldung sehen, müssen Sie Instance-Typen verwenden, die Ihr aktuelles CPU V-Limit nicht überschreiten, oder mehr CPU V-Kapazität anfordern.

Sie können die CloudFormation Konsole auch verwenden, um Informationen zum "Cluster creation failed" Status abzurufen.

CloudFormation Fehlermeldungen von der Konsole aus anzeigen.

  1. Melden Sie sich bei der an AWS Management Console und navigieren Sie zu https://console.aws.amazon.com/cloudformation.

  2. Wählen Sie den Stack mit dem Namen parallelcluster-cluster_name.

  3. Wählen Sie die Registerkarte Ereignisse.

  4. Überprüfen Sie den Status der Ressource, die nicht erstellt werden konnte, indem Sie die Liste der Ressourcenereignisse nach der logischen ID durchsuchen. Wenn eine Unteraufgabe nicht erstellt werden konnte, gehen Sie rückwärts vor, um das fehlgeschlagene Ressourcenereignis zu finden.

  5. Ein Beispiel für eine AWS CloudFormation Fehlermeldung:

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

Behebung von Problemen mit der IAM Richtliniengröße

Informationen zur IAM Überprüfung der AWS STS Kontingente für verwaltete Richtlinien, die Rollen zugeordnet sind, finden Sie unter Kontingente, Namensanforderungen und Zeichenbeschränkungen. Wenn die Größe einer verwalteten Richtlinie das Kontingent überschreitet, teilen Sie die Richtlinie in zwei oder mehr Richtlinien auf. Wenn Sie das Kontingent für die Anzahl der einer IAM Rolle zugewiesenen Richtlinien überschreiten, erstellen Sie zusätzliche Rollen und verteilen Sie die Richtlinien auf diese, um das Kontingent zu erreichen.

Zusätzliche Unterstützung

Eine Liste der bekannten Probleme finden Sie auf der GitHubWiki-Hauptseite oder auf der Problemseite. Bei dringenderen Problemen wenden Sie sich an AWS Support oder öffnen Sie ein neues GitHub Problem.