View a markdown version of this page

Slurm Anleitung für den Modus mit mehreren Warteschlangen - AWS ParallelCluster
-ÜbersichtLebenszyklus eines Cloud-KnotensMit einem verfügbaren Knoten arbeitenStatus des Jobs und EinreichungZustand und Funktionen des KnotensStatus der Partitionpcluster starten und stoppenManuelle Steuerung der WarteschlangenSkalierungsverhalten und AnpassungenProtokolle für neue ArchitekturenHäufige Probleme und wie man sie debuggt:

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.

Slurm Anleitung für den Modus mit mehreren Warteschlangen

AWS ParallelCluster Version 2.9.0 führte den Modus mit mehreren Warteschlangen und eine neue Skalierungsarchitektur für Slurm Workload Manager (Slurm) ein.

Die folgenden Abschnitte bieten einen allgemeinen Überblick über die Verwendung eines Slurm Clusters mit der neu eingeführten Skalierungsarchitektur.

-Übersicht

Die neue Skalierungsarchitektur basiert auf dem Cloud Slurm Scheduling Guide und dem Energiespar-Plugin. Weitere Informationen zum Energiespar-Plugin finden Sie in der Anleitung zum Slurm Energiesparen. In der neuen Architektur sind Ressourcen, die potenziell für einen Cluster verfügbar gemacht werden können, in der Slurm Konfiguration in der Regel als Cloud-Knoten vordefiniert.

Lebenszyklus eines Cloud-Knotens

Während ihres Lebenszyklus treten Cloud-Knoten in mehrere, wenn nicht alle der folgenden Zustände ein:POWER_SAVING, POWER_UP (pow_up), ALLOCATED (alloc) und POWER_DOWN (pow_dn). In einigen Fällen kann ein Cloud-Knoten in den OFFLINE Status übergehen. In der folgenden Liste werden verschiedene Aspekte dieser Zustände im Lebenszyklus eines Cloud-Knotens detailliert beschrieben.

  • Ein Knoten in einem POWER_SAVING Bundesstaat wird mit einem ~ Suffix (z. B.idle~) in sinfo angezeigt. In diesem Zustand gibt es keine EC2-Instanz, die den Knoten unterstützt. SlurmSie können dem Knoten jedoch weiterhin Jobs zuweisen.

  • Ein Knoten, der in einen POWER_UP Bundesstaat übergeht, wird mit einem # Suffix (z. B.idle#) in angezeigt. sinfo

  • Wenn Slurm einem Knoten in einem Bundesstaat eine Aufgabe zugewiesen wird, wechselt der Knoten automatisch in einen POWER_SAVING Bundesstaat. POWER_UP Andernfalls können Knoten mithilfe des Befehls manuell in den POWER_UP Status versetzt werden. scontrol update nodename=nodename state=power_up In dieser Phase ResumeProgram wird der aufgerufen, und EC2-Instances werden gestartet und so konfiguriert, dass sie einen POWER_UP Knoten unterstützen.

  • Ein Knoten, der derzeit verwendet werden kann, wird ohne Suffix (z. B.idle) in angezeigt. sinfo Nachdem der Knoten eingerichtet und dem Cluster beigetreten ist, ist er für die Ausführung von Aufträgen verfügbar. In dieser Phase ist der Knoten ordnungsgemäß konfiguriert und einsatzbereit. Als allgemeine Regel empfehlen wir, dass die Anzahl der Instances in EC2 der Anzahl der verfügbaren Knoten entspricht. In den meisten Fällen sind statische Knoten immer verfügbar, nachdem der Cluster erstellt wurde.

  • Ein Knoten, der in einen POWER_DOWN Status übergeht, wird mit einem % Suffix (z. B.idle%) in angezeigt. sinfo Dynamische Knoten wechseln danach automatisch in den POWER_DOWN Status. scaledown_idletime Im Gegensatz dazu werden statische Knoten in den meisten Fällen nicht abgeschaltet. Knoten können jedoch mithilfe des scontrol update nodename=nodename state=powering_down Befehls manuell in den POWER_DOWN Status versetzt werden. In diesem Zustand wird die einem Knoten zugeordnete Instanz beendet und der Knoten wird in den POWER_SAVING Zustand zurückgesetzt, in dem er später verwendet werden kannscaledown_idletime. Die scaledown-idletime Einstellung wird in der Slurm Konfiguration als SuspendTimeout Einstellung gespeichert.

  • Ein Knoten, der offline ist, wird mit einem * Suffix (z. B.down*) in sinfo angezeigt. Ein Knoten geht offline, wenn der Slurm Controller den Knoten nicht kontaktieren kann oder wenn die statischen Knoten deaktiviert sind und die Back-Instances beendet werden.

Betrachten Sie nun die Knotenzustände, die im folgenden sinfo Beispiel gezeigt werden.

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1  idle% gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite      2   mix# ondemand-dy-c52xlarge-[1-2]
ondemand     up   infinite     18  idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2]

Für die efa-st-c5n18xlarge-1 Knoten spot-st-t2large-[1-2] und sind bereits Backing-Instanzen eingerichtet und sie können verwendet werden. Die ondemand-dy-c52xlarge-[1-2] Knoten befinden sich im POWER_UP Status und sollten innerhalb weniger Minuten verfügbar sein. Der gpu-dy-g38xlarge-1 Knoten befindet sich im POWER_DOWN Status und wechselt danach in den POWER_SAVING Status scaledown_idletime (standardmäßig 120 Sekunden).

Alle anderen Knoten befinden sich im POWER_SAVING Status, ohne dass sie von EC2-Instances unterstützt werden.

Mit einem verfügbaren Knoten arbeiten

Ein verfügbarer Knoten wird von einer EC2-Instance unterstützt. Standardmäßig kann der Knotenname verwendet werden, um eine direkte SSH-Verbindung zur Instance herzustellen (z. B.ssh efa-st-c5n18xlarge-1). Die private IP-Adresse der Instanz kann mit dem scontrol show nodes nodename Befehl abgerufen und das NodeAddr Feld überprüft werden. Bei Knoten, die nicht verfügbar sind, sollte das NodeAddr Feld nicht auf eine laufende EC2-Instance verweisen. Es sollte vielmehr mit dem Knotennamen identisch sein.

Status des Jobs und Einreichung

Eingereichte Jobs werden in den meisten Fällen sofort den Knoten im System zugewiesen oder als ausstehend eingestuft, wenn alle Knoten zugewiesen sind.

Wenn die für einen Job zugewiesenen Knoten Knoten enthalten, die sich in einem POWER_SAVING Bundesstaat befinden, beginnt der Job mit einem CF oder CONFIGURING -Status. Zu diesem Zeitpunkt wartet der Job darauf, dass die Knoten im POWER_SAVING Bundesstaat in den Status übergehen POWER_UP und verfügbar werden.

Nachdem alle für einen Job zugewiesenen Knoten verfügbar sind, wechselt der Job in den Status RUNNING (R).

Standardmäßig werden alle Jobs an die Standardwarteschlange (auch als Partitionseingang bezeichnetSlurm) weitergeleitet. Dies wird durch ein * Suffix nach dem Warteschlangennamen gekennzeichnet. Mithilfe der Option zur -p Auftragsübermittlung können Sie eine Warteschlange auswählen.

Alle Knoten sind mit den folgenden Funktionen konfiguriert, die in Befehlen zur Auftragsübermittlung verwendet werden können:

  • Ein Instanztyp (zum Beispielc5.xlarge)

  • Ein Knotentyp (Dies ist entweder dynamic oderstatic.)

Sie können alle für einen bestimmten Knoten verfügbaren Funktionen anzeigen, indem Sie den scontrol show nodes nodename Befehl verwenden und die AvailableFeatures Liste überprüfen.

Eine weitere Überlegung sind Arbeitsplätze. Betrachten Sie zunächst den Anfangszustand des Clusters, den Sie durch Ausführen des sinfo Befehls anzeigen können.

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite     10  idle~ gpu-dy-g38xlarge-[1-10]
ondemand     up   infinite     20  idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2]

Beachten Sie, dass spot dies die Standardwarteschlange ist. Sie wird durch das * Suffix angezeigt.

Senden Sie einen Job an einen statischen Knoten in die Standardwarteschlange (spot).

$ sbatch --wrap "sleep 300" -N 1 -C static

Sendet einen Job an einen dynamischen Knoten der EFA Warteschlange.

$ sbatch --wrap "sleep 300" -p efa -C dynamic

Senden Sie einen Job an acht (8) c5.2xlarge Knoten und zwei (2) t2.xlarge Knoten an die ondemand Warteschlange.

$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"

Senden Sie einen Job an einen GPU-Knoten in die gpu Warteschlange.

$ sbatch --wrap "sleep 300" -p gpu -G 1

Betrachten Sie nun den Status der Jobs mithilfe des squeue Befehls.

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                12  ondemand     wrap   ubuntu CF       0:36     10 ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
                13       gpu     wrap   ubuntu CF       0:05      1 gpu-dy-g38xlarge-1
                 7      spot     wrap   ubuntu  R       2:48      1 spot-st-t2large-1
                 8       efa     wrap   ubuntu  R       0:39      1 efa-dy-c5n18xlarge-1

Die Jobs 7 und 8 (in den efa Warteschlangen spot und) laufen bereits (R). Die Jobs 12 und 13 werden noch konfiguriert (CF) und warten wahrscheinlich darauf, dass die Instanzen verfügbar werden.

# Nodes states corresponds to state of running jobs
$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      3  idle~ efa-dy-c5n18xlarge-[2-4]
efa          up   infinite      1    mix efa-dy-c5n18xlarge-1
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1   mix~ gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite     10   mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
ondemand     up   infinite     10  idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      1    mix spot-st-t2large-1
spot*        up   infinite      1   idle spot-st-t2large-2

Zustand und Funktionen des Knotens

In den meisten Fällen werden die Knotenstatus vollständig AWS ParallelCluster gemäß den spezifischen Prozessen im Cloud-Node-Lebenszyklus verwaltet, die weiter oben in diesem Thema beschrieben wurden.

Ersetzt oder beendet jedoch AWS ParallelCluster auch fehlerhafte Knoten in DOWN und DRAINED Zuständen und Knoten, die über fehlerhafte Back-Instances verfügen. Weitere Informationen finden Sie unter clustermgtd.

Status der Partition

AWS ParallelCluster unterstützt die folgenden Partitionszustände. Eine Slurm Partition ist eine Warteschlange in AWS ParallelCluster.

  • UP: Zeigt an, dass sich die Partition in einem aktiven Zustand befindet. Dies ist der Standardstatus einer Partition. In diesem Zustand sind alle Knoten in der Partition aktiv und können verwendet werden.

  • INACTIVE: Zeigt an, dass sich die Partition im inaktiven Zustand befindet. In diesem Zustand werden alle Instanzen, die Knoten einer inaktiven Partition unterstützen, beendet. Für Knoten in einer inaktiven Partition werden keine neuen Instanzen gestartet.

pcluster starten und stoppen

Wenn ausgeführt pcluster stop wird, werden alle Partitionen in den INACTIVE Status versetzt, und die AWS ParallelCluster Prozesse behalten den INACTIVE Status der Partitionen bei.

Wenn ausgeführt pcluster start wird, werden zunächst alle Partitionen in den UP Status versetzt. AWS ParallelCluster Prozesse halten die Partition jedoch nicht in einem bestimmten UP Zustand. Sie müssen den Partitionsstatus manuell ändern. Alle statischen Knoten sind nach einigen Minuten verfügbar. Beachten Sie, dass das Einstellen einer Partition auf UP keine dynamische Kapazität aktiviert. Wenn größer als initial_count istmax_count, wird initial_count möglicherweise nicht erfüllt, wenn der Partitionsstatus in den UP Status geändert wird.

Wenn pcluster start und ausgeführt pcluster stop werden, können Sie den Status des Clusters überprüfen, indem Sie den pcluster status Befehl ausführen und das überprüfenComputeFleetStatus. In der folgenden Liste sind mögliche Zustände aufgeführt:

  • STOP_REQUESTED: Die pcluster stop Anfrage wird an den Cluster gesendet.

  • STOPPING: Der pcluster Prozess stoppt derzeit den Cluster.

  • STOPPED: Der pcluster Prozess hat den Stoppvorgang abgeschlossen, alle Partitionen befinden sich im INACTIVE Status und alle Recheninstanzen sind beendet.

  • START_REQUESTED: Die pcluster start Anfrage wird an den Cluster gesendet.

  • STARTING: Der pcluster Prozess startet gerade den Cluster

  • RUNNING: Der pcluster Prozess hat den Startvorgang abgeschlossen, alle Partitionen sind im UP Status und statische Knoten werden nach einigen Minuten verfügbar sein.

Manuelle Steuerung der Warteschlangen

In einigen Fällen möchten Sie möglicherweise eine gewisse manuelle Kontrolle über die Knoten oder Warteschlangen (auch als Partitionseingang bezeichnetSlurm) in einem Cluster haben. Sie können Knoten in einem Cluster mithilfe der folgenden allgemeinen Verfahren verwalten.

  • Dynamische Knoten im POWER_SAVING Status einschalten: Führen Sie den scontrol update nodename=nodename state=power_up Befehl aus oder senden Sie einen sleep 1 Platzhalterauftrag, in dem Sie eine bestimmte Anzahl von Knoten anfordern, und verlassen Sie sich daraufSlurm, die erforderliche Anzahl von Knoten hochzufahren.

  • Vorher dynamische Knoten ausschaltenscaledown_idletime: Stellen Sie dynamische Knoten DOWN mit dem scontrol update nodename=nodename state=down Befehl auf ein. AWS ParallelCluster beendet automatisch die ausgefallenen dynamischen Knoten und setzt sie zurück. Im Allgemeinen empfehlen wir nicht, Knoten so einzustellen, dass sie den Befehl POWER_DOWN direkt verwenden. scontrol update nodename=nodename state=power_down Das liegt daran, dass der Ausschaltvorgang AWS ParallelCluster automatisch abgewickelt wird. Es ist kein manueller Eingriff erforderlich. Daher empfehlen wir, dass Sie versuchen, die Knoten so einzustellen, DOWN wann immer dies möglich ist.

  • Deaktivieren Sie eine Warteschlange (Partition) oder stoppen Sie alle statischen Knoten in einer bestimmten Partition: Stellen Sie INACTIVE mit dem scontrol update partition=queue name state=inactive Befehl eine bestimmte Warteschlange ein. Dadurch werden alle Instanzen beendet, die Knoten in der Partition unterstützen.

  • Warteschlange (Partition) aktivieren: Stellen Sie INACTIVE mit dem scontrol update partition=queue name state=up Befehl eine bestimmte Warteschlange ein.

Skalierungsverhalten und Anpassungen

Hier ist ein Beispiel für den normalen Skalierungsablauf:

  • Der Scheduler erhält einen Job, für den zwei Knoten erforderlich sind.

  • Der Scheduler versetzt zwei Knoten in einen POWER_UP Zustand und ruft (zum Beispielqueue1-dy-c5xlarge-[1-2]) ResumeProgram mit den Knotennamen auf.

  • ResumeProgramstartet zwei EC2-Instances und weist die privaten IP-Adressen und Hostnamen von zu. Er wartet darauf ResumeTimeout (der Standardzeitraum ist 60 Minuten (1 Stunde))queue1-dy-c5xlarge-[1-2], bevor die Knoten zurückgesetzt werden.

  • Die Instanzen sind konfiguriert und treten dem Cluster bei. Der Job beginnt, auf Instanzen ausgeführt zu werden.

  • Die Arbeit ist erledigt.

  • Nach Ablauf der Konfiguration SuspendTime (die auf gesetzt istscaledown_idletime), werden die Instanzen vom Scheduler in den POWER_SAVING Status versetzt. Der Scheduler wechselt queue1-dy-c5xlarge-[1-2] in den POWER_DOWN Status und ruft SuspendProgram mit den Knotennamen auf.

  • SuspendProgramwird für zwei Knoten aufgerufen. Knoten bleiben im POWER_DOWN Status, indem sie beispielsweise eine Zeit idle% lang verweilen SuspendTimeout (der Standardzeitraum ist 120 Sekunden (2 Minuten)). Nachdem clustermgtd festgestellt wurde, dass die Knoten heruntergefahren werden, werden die Backing-Instances beendet. Anschließend wechselt es queue1-dy-c5xlarge-[1-2] in den Ruhezustand und setzt die private IP-Adresse und den Hostnamen zurück, sodass sie für zukünftige Aufgaben wieder eingeschaltet werden können.

Wenn nun etwas schief geht und eine Instanz für einen bestimmten Knoten aus irgendeinem Grund nicht gestartet werden kann, passiert Folgendes.

  • Der Scheduler erhält einen Job, für den zwei Knoten erforderlich sind.

  • Der Scheduler versetzt zwei Cloud-Bursting-Knoten in den POWER_UP Status und ruft ResumeProgram mit den Knotennamen auf (zum Beispiel). queue1-dy-c5xlarge-[1-2]

  • ResumeProgramstartet nur eine (1) EC2-Instance und konfiguriertqueue1-dy-c5xlarge-1, aber es konnte keine Instance für gestartet werden. queue1-dy-c5xlarge-2

  • queue1-dy-c5xlarge-1ist nicht betroffen und geht online, sobald der Status erreicht POWER_UP ist.

  • queue1-dy-c5xlarge-2wird in den POWER_DOWN Status versetzt, und der Job wird automatisch erneut in die Warteschlange gestellt, da ein Slurm Knotenausfall erkannt wird.

  • queue1-dy-c5xlarge-2wird danach verfügbar SuspendTimeout (die Standardeinstellung ist 120 Sekunden (2 Minuten)). In der Zwischenzeit wird der Job erneut in die Warteschlange gestellt und kann auf einem anderen Knoten ausgeführt werden.

  • Der obige Vorgang wird wiederholt, bis der Job auf einem verfügbaren Knoten ausgeführt werden kann, ohne dass ein Fehler auftritt.

Es gibt zwei Zeitparameter, die bei Bedarf angepasst werden können.

  • ResumeTimeout(Die Standardeinstellung ist 60 Minuten (1 Stunde)): ResumeTimeout Steuert die Slurm Wartezeit, bis der Knoten in den Ausfallzustand versetzt wird.

    • Es kann nützlich sein, dies zu verlängern, wenn Ihr pre/post Installationsvorgang fast so lange dauert.

    • Dies ist auch die maximale AWS ParallelCluster Wartezeit, bevor ein Knoten ausgetauscht oder zurückgesetzt wird, falls ein Problem auftritt. Rechenknoten beenden sich selbst, wenn beim Start oder bei der Einrichtung ein Fehler auftritt. Als Nächstes ersetzt der AWS ParallelCluster Prozess auch den Knoten, wenn er feststellt, dass die Instanz beendet ist.

  • SuspendTimeout(Die Standardeinstellung ist 120 Sekunden (2 Minuten)): SuspendTimeout Steuert, wie schnell Knoten wieder im System platziert werden und wieder einsatzbereit sind.

    • Ein kürzerer Wert SuspendTimeout würde bedeuten, dass die Knoten schneller zurückgesetzt werden und Slurm dass versucht werden kann, Instances häufiger zu starten.

    • Je länger, SuspendTimeout desto langsamer werden ausgefallene Knoten zurückgesetzt. In der Zwischenzeit versucht erSlurm, andere Knoten zu verwenden. Wenn SuspendTimeout es länger als ein paar Minuten dauert, Slurm versucht, alle Knoten im System zu durchlaufen. Ein längerer SuspendTimeout Zeitraum kann bei großen Systemen (über 1.000 Knoten) von Vorteil sein, um die Belastung Slurm durch häufiges Umstellen fehlerhafter Jobs in die Warteschlange zu reduzieren.

    • Beachten Sie, dass sich SuspendTimeout dies nicht auf die Wartezeit bezieht, um AWS ParallelCluster eine Backing-Instance für einen Knoten zu beenden. Backing-Instanzen für power down Knoten werden sofort beendet. Der Kündigungsvorgang ist in der Regel nach ein paar Minuten abgeschlossen. Während dieser Zeit bleibt der Knoten jedoch im ausgeschalteten Zustand und kann nicht im Scheduler verwendet werden.

Protokolle für neue Architekturen

Die folgende Liste enthält die wichtigsten Protokolle für die Architektur mit mehreren Warteschlangen. Der Name des Log-Streams, der mit Amazon CloudWatch Logs verwendet wird, hat das Format{hostname}.{instance_id}.{logIdentifier}, in dem die Protokollnamen logIdentifier folgen. Weitere Informationen finden Sie unter Integration mit Amazon CloudWatch Logs.

  • ResumeProgram:

    /var/log/parallelcluster/slurm_resume.log (slurm_resume)

  • SuspendProgram:

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

  • clustermgtd:

    /var/log/parallelcluster/clustermgtd.log (clustermgtd)

  • computemgtd:

    /var/log/parallelcluster/computemgtd.log (computemgtd)

  • slurmctld:

    /var/log/slurmctld.log (slurmctld)

  • slurmd:

    /var/log/slurmd.log (slurmd)

Häufige Probleme und wie man sie debuggt:

Knoten, die nicht gestartet, hochgefahren oder dem Cluster nicht beigetreten sind:

  • Dynamische Knoten:

    • Überprüfen Sie das ResumeProgram Protokoll, um festzustellen, ob jemals mit dem Knoten aufgerufen ResumeProgram wurde. Wenn nicht, überprüfen Sie das slurmctld Protokoll, um festzustellen, ob Slurm jemals versucht wurde, ResumeProgram mit dem Knoten anzurufen. Beachten Sie, dass falsche Berechtigungen dazu führen ResumeProgram können, dass der Vorgang unbemerkt fehlschlägt.

    • Wenn aufgerufen ResumeProgram wird, überprüfen Sie, ob eine Instanz für den Knoten gestartet wurde. Wenn die Instanz nicht gestartet werden kann, sollte eine klare Fehlermeldung angezeigt werden, aus der hervorgeht, warum die Instanz nicht gestartet werden konnte.

    • Wenn eine Instance gestartet wurde, ist möglicherweise während des Bootstrap-Vorgangs ein Problem aufgetreten. Suchen Sie die entsprechende private IP-Adresse und Instanz-ID aus dem ResumeProgram Protokoll und sehen Sie sich die entsprechenden Bootstrap-Protokolle für die jeweilige Instanz in CloudWatch den Protokollen an.

  • Statische Knoten:

    • Überprüfen Sie das clustermgtd Protokoll, um festzustellen, ob Instanzen für den Knoten gestartet wurden. Wenn nicht, sollte es klare Fehler geben, warum die Instances nicht gestartet werden konnten.

    • Wenn eine Instance gestartet wurde, gibt es während des Bootstrap-Vorgangs ein Problem. Suchen Sie die entsprechende private IP und Instanz-ID aus dem clustermgtd Protokoll und sehen Sie sich die entsprechenden Bootstrap-Protokolle für die jeweilige Instanz in CloudWatch den Protokollen an.

Knoten wurden unerwartet ersetzt oder beendet, Knotenfehler

  • Knoten replaced/terminated unerwartet

    • In den meisten Fällen werden clustermgtd alle Wartungsaktionen für Knoten ausgeführt. Um zu überprüfen, ob ein Knoten clustermgtd ersetzt oder beendet wurde, überprüfen Sie das clustermgtd Protokoll.

    • Wenn der Knoten clustermgtd ersetzt oder beendet wurde, sollte eine Meldung erscheinen, die den Grund für die Aktion angibt. Wenn der Grund mit dem Scheduler zusammenhängt (z. B. der KnotenDOWN), finden Sie im slurmctld Protokoll weitere Informationen. Wenn der Grund mit EC2 zusammenhängt, verwenden Sie Tools, um den Status oder die Protokolle für diese Instance zu überprüfen. Sie können beispielsweise überprüfen, ob für die Instance Ereignisse geplant waren oder ob die EC2-Integritätsprüfungen nicht bestanden haben.

    • Wenn der Knoten clustermgtd nicht beendet wurde, überprüfen Sie, ob der Knoten computemgtd beendet wurde oder ob EC2 die Instance beendet hat, um eine Spot-Instance zurückzufordern.

  • Ausfälle des Knotens

    • In den meisten Fällen werden Jobs automatisch erneut in die Warteschlange gestellt, wenn ein Knoten ausfällt. Sehen Sie im slurmctld Protokoll nach, warum ein Job oder ein Knoten ausgefallen ist, und analysieren Sie die Situation von dort aus.

Fehler beim Ersetzen oder Beenden von Instanzen, Fehler beim Ausschalten von Knoten

  • clustermgtdBehandelt im Allgemeinen alle erwarteten Aktionen zum Beenden von Instanzen. 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 ein Programm slurmctld den spezifischen Knoten als Argument verwendet hat. Note führt eigentlich SuspendProgram keine bestimmte Aktion aus. Vielmehr protokolliert es nur, wenn es aufgerufen wird. Das Beenden und NodeAddr Zurücksetzen aller Instanzen ist bis abgeschlossenclustermgtd. Slurmfügt Knoten IDLE danach einSuspendTimeout.

Andere Probleme

  • AWS ParallelCluster trifft keine Entscheidungen zur Stellenzuweisung oder Skalierung. Es versucht lediglich, Ressourcen gemäß den Anweisungen zu starten, zu beenden und zu Slurm verwalten.

    Bei Problemen mit der Auftragszuweisung, der Knotenzuweisung und der Entscheidung zur Skalierung sehen Sie im slurmctld Protokoll nach, ob Fehler aufgetreten sind.