AWS ParallelCluster Problembehandlung - 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 in Amazon DCVBehebung von Problemen in Clustern mit AWS Batch IntegrationFehlerbehebung, wenn eine Ressource nicht erstellt werden kannBehebung von Problemen mit der Größe der IAM-RichtlinieZusätzlicher Support

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 Problembehandlung

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 zur 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. Durch die Ausführung dieses Befehls wird der Cluster gelöscht, die in Amazon CloudWatch gespeicherte Protokollgruppe wird 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 Kennzeichens. Stellen Sie dann per SSH eine Verbindung zum Cluster her:

$ 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 im Zusammenhang mit 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 Slurm Job Scheduler installiert wurden. Weitere Informationen zum Modus mit mehreren Warteschlangen finden Sie unter. Modus 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 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 Chef/Cinc 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, um Probleme beim Starten, Beenden oder Clusterbetrieb zu beheben.

/var/log/slurmctld.log

Dies ist das Protokoll des Slurm Kontroll-Daemons. AWS ParallelCluster trifft keine Skalierungsentscheidungen. Vielmehr versucht es nur, Ressourcen bereitzustellen, um die Slurm Anforderungen zu erfüllen. Dies ist nützlich bei Problemen mit der Skalierung und Zuweisung, bei Problemen im Zusammenhang mit Aufträgen sowie bei Problemen mit dem Start und der Kündigung im Zusammenhang mit dem Terminplaner.

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 beim Einrichten 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

Dies ist das Slurm Compute-Daemon-Protokoll. Es ist nützlich, um Probleme mit der Initialisierung und Rechenfehlern zu beheben.

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 Ihrem Compute-Knotennamen, um zu sehen, ob der Node jemals mit dem Node aufgerufen ResumeProgram wurde. (Falls der Node noch nie aufgerufen ResumeProgram wurde, können Sie anhand von slurmctld log (/var/log/slurmctld.log) nachsehen, ob Slurm jemals versucht wurde, ResumeProgram mit dem Node aufzurufen.)

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

  • Wenn aufgerufen ResumeProgram wird, überprüfen Sie, ob eine Instance 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 Compute-Knoten 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 AMI mit Änderung der Slurm Konfiguration verwenden, liegt möglicherweise ein Slurm verwandter Fehler vor, 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 handelt EC2, 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

    • Schauen Sie in slurmctld log (/var/log/slurmctld.log) nach, 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 ein, um einen neuen Knoten hochfahren zu lassenSlurm.

      • 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. Slurmversetzt 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 gemäß den Anweisungen gestartet, beendet oder verwaltet. Slurm Ü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 Verwendung von SGE oder Torque -Schedulern AWS ParallelCluster nicht unterstützt.

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

  • Wurde mit einer AWS ParallelCluster Version vor 2.9.0 und SGETorque, oder Slurm Job-Schedulern gestartet.

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

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 über CINC ausgeführt wurden. 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 clustermgtd Protokoll für Scheduler. Slurm 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 und Torque Scheduler. jobwatcherüberwacht die Scheduler-Warteschlange und aktualisiert die Amazon EC2 Auto Scaling Scaling-Gruppe. 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 und Torque Scheduler. sqswatcherverarbeitet das Ereignis „Instance Ready“, 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 Scheduler verwendet werdenSGE. Torque 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.

  • Wenn 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 Amazon EC2 Auto Scaling Scaling-Gruppe aktualisiert hat. Beachten Sie, dass die Scheduler-Warteschlange jobwatcher überwacht und die Amazon EC2 Auto Scaling Scaling-Gruppe 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 bei Clustern 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, AWS ParallelCluster Version v2.9.0 oder höher verwenden, dieses Problem verwenden und dieses Problem vermeiden möchtenSlurm, 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ühren. pcluster-config convert

Bei ultra-large-scale Clustern ist möglicherweise eine zusätzliche Optimierung Ihres Systems erforderlich. Für weitere Informationen wenden Sie sich an 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 FSx fü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 EC2 Amazon-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 LinuxCentOS, /home/centos on und /home/ubuntu onUbuntu).

/opt/intel

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

/opt/sge
Anmerkung

Ab Version 2.11.5 wird die Verwendung von SGE oder Torque -Schedulern AWS ParallelCluster nicht unterstützt.

Dazu gehören Son of Grid Engine und zugehörige Dateien. (Bedingt, nur wenn scheduler = sge.)

/opt/slurm

Dazu gehören Slurm Workload Manager und zugehörige Dateien. (Bedingt, nur wenn scheduler = slurm.)

/opt/torque
Anmerkung

Ab Version 2.11.5 wird die Verwendung von AWS ParallelCluster OR-Schedulern nicht unterstützt. SGE Torque

Dazu gehören Torque Resource Manager und zugehörige Dateien. (Bedingt, nur wenn scheduler = torque.)

Behebung von Problemen in Amazon DCV

Protokolle 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 Typ Amazon DCV Instance

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

Probleme mit Ubuntu Amazon DCV

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.

Auftragsfehler

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 Instanztypen verwenden, die Ihr aktuelles vCPU-Limit nicht überschreiten oder mehr vCPU-Kapazität anfordern.

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

CloudFormation Fehlermeldungen von der Konsole aus anzeigen.

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

  2. Wählen Sie den Stack mit dem Namen parallelcluster- aus. 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 Größe der IAM-Richtlinie

Informationen zur Überprüfung der AWS STS Kontingente für verwaltete Richtlinien, die Rollen zugeordnet sind, finden Sie unter IAM und 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 Richtlinien, die einer IAM-Rolle zugeordnet sind, überschreiten, erstellen Sie zusätzliche Rollen und verteilen Sie die Richtlinien auf diese, um das Kontingent zu erreichen.

Zusätzlicher Support

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