Slurm Anleitung für den Modus mit mehreren Warteschlangen

• Ein Knoten in einem POWER_SAVING Bundesstaat wird mit einem ~ Suffix (z. B.idle~) in sinfo angezeigt. In diesem Zustand unterstützen keine EC2-Instances den Knoten. 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 Ein Knoten wechselt automatisch in einen POWER_UP Status, wenn er einem Knoten in einem Bundesstaat einen Job Slurm zuweist. POWER_SAVING

  Alternativ können Sie als su Root-Benutzer die Knoten mit dem POWER_UP folgenden Befehl manuell in den Status überführen:

  $ scontrol update nodename=nodename state=power_up

  In dieser Phase ResumeProgram wird der aufgerufen, EC2-Instances werden gestartet und konfiguriert, und der Knoten geht in den POWER_UP Status über.

• 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 Amazon EC2-Instances der Anzahl der verfügbaren Knoten entspricht. In den meisten Fällen sind statische Knoten 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 automatisch in den POWER_DOWN Zustand danach. ScaledownIdletime Im Gegensatz dazu werden statische Knoten in den meisten Fällen nicht abgeschaltet. Sie können die Knoten jedoch manuell als su Root-Benutzer mit dem folgenden Befehl in den POWER_DOWN Status versetzen:

  $ scontrol update nodename=nodename state=down reason="manual draining"

  In diesem Zustand werden die mit einem Knoten verknüpften Instanzen beendet, und der Knoten wird in den POWER_SAVING Zustand zurückversetzt und kann danach verwendet ScaledownIdletime werden.

  Die ScaledownIdletime Einstellung wird in der Slurm SuspendTimeout Konfigurationseinstellung 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.

• Ein Instanztyp (zum Beispielc5.xlarge)

• Ein Knotentyp (Dies ist entweder dynamic oderstatic.)

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

• Stoppen der Rechenflotte — Wenn der folgende Befehl ausgeführt wird, gehen alle Partitionen in den Status über, und die AWS ParallelCluster Prozesse behalten den INACTIVE Status der Partitionen bei. INACTIVE

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status STOP_REQUESTED

• Starten der Rechenflotte — Wenn der folgende Befehl ausgeführt wird, gehen zunächst alle Partitionen in den UP Status über. 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.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status START_REQUESTED

• STOP_REQUESTED: Die Stopp-Compute-Flottenanforderung wird an den Cluster gesendet.

• STOPPING: Der pcluster Prozess stoppt derzeit die Rechenflotte.

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

• START_REQUESTED: Die Startanfrage für die Computerflotte wird an den Cluster gesendet.

• STARTING: Der pcluster Prozess startet gerade den Cluster.

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

• PROTECTED: Dieser Status weist darauf hin, dass bei einigen Partitionen immer wieder Bootstrap-Fehler auftreten. Die betroffenen Partitionen sind inaktiv. Bitte untersuchen Sie das Problem und starten Sie dannupdate-compute-fleet, um die Flotte wieder zu aktivieren.

• Schalten Sie dynamische Knoten im POWER_SAVING Status ein

  Führen Sie den Befehl als su Root-Benutzer aus:

  $ scontrol update nodename=nodename state=power_up

  Sie können auch einen sleep 1 Platzhalter-Job einreichen, bei dem eine bestimmte Anzahl von Knoten angefordert wird, und sich dann Slurm darauf verlassen, dass die erforderliche Anzahl von Knoten eingeschaltet wird.

• Schalten Sie zuvor dynamische Knoten aus ScaledownIdletime

  Wir empfehlen, dynamische Knoten mit dem folgenden Befehl DOWN als su Root-Benutzer einzurichten:

  $ scontrol update nodename=nodename state=down reason="manually draining"

  AWS ParallelCluster beendet automatisch die ausgefallenen dynamischen Knoten und setzt sie zurück.

  Im Allgemeinen empfehlen wir nicht, Knoten POWER_DOWN direkt mithilfe des Befehls auf Knoten zu setzen. scontrol update nodename=nodename state=power_down Das liegt daran, dass der Ausschaltvorgang AWS ParallelCluster automatisch abgewickelt wird.

• Deaktivieren Sie eine Warteschlange (Partition) oder stoppen Sie alle statischen Knoten in einer bestimmten Partition

  Stellen Sie eine bestimmte Warteschlange mit dem folgenden Befehl INACTIVE als su Root-Benutzer ein:

  $ scontrol update partition=queuename state=inactive

  Dadurch werden alle Instanzen beendet, die Knoten in der Partition unterstützen.

• Aktiviere eine Warteschlange (Partition)

  Stellen Sie mit dem folgenden Befehl UP eine bestimmte Warteschlange für einen su Root-Benutzer ein:

  $ scontrol update partition=queuename state=up

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-spotcompute1-[1-2]) ResumeProgram mit den Knotennamen auf.

• ResumeProgramstartet zwei Amazon EC2-Instances und weist die privaten IP-Adressen und Hostnamen von zu. Wartet auf ResumeTimeout (der Standardzeitraum ist 30 Minuten)queue1-dy-spotcompute1-[1-2], bevor die Knoten zurückgesetzt werden.

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

• Der Job wird abgeschlossen und wird nicht mehr ausgeführt.

• Nach Ablauf der Konfiguration SuspendTime (die auf gesetzt ist ScaledownIdletime) setzt der Scheduler die Instanzen auf den Status. POWER_SAVING Der Scheduler wechselt dann in queue1-dy-spotcompute1-[1-2] 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. Dann wechselt es in queue1-dy-spotcompute1-[1-2] den Ruhezustand und setzt die private IP-Adresse und den Hostnamen zurück, sodass es für zukünftige Aufgaben wieder einsatzbereit ist.

Wenn 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 (zum Beispiel) ResumeProgram mit den Knotennamen auf. queue1-dy-spotcompute1-[1-2]

• ResumeProgramstartet nur eine (1) Amazon EC2-Instance und konfiguriert die Konfiguration mit einer (1) Instancequeue1-dy-spotcompute1-1, wobei der Start fehlschlägt. queue1-dy-spotcompute1-2

• queue1-dy-spotcompute1-1ist nicht betroffen und geht online, nachdem der Bundesstaat erreicht wurde. POWER_UP

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

• queue1-dy-spotcompute1-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 30 Minuten): ResumeTimeout steuert die Slurm Wartezeit, bis der Knoten in den Zustand „Heruntergefahren“ übergeht.

  • Eine Verlängerung kann nützlich sein, ResumeTimeout wenn der pre/post Installationsvorgang fast so lange dauert.

  • ResumeTimeoutist auch die maximale AWS ParallelCluster Wartezeit, nach der 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. AWS ParallelCluster Prozesse ersetzen einen Knoten, wenn eine beendete Instanz erkannt wird.

• 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 bedeutet, dass die Knoten schneller zurückgesetzt werden und sie versuchen Slurm können, Instances häufiger zu starten.

  • Je länger, SuspendTimeout desto langsamer werden ausgefallene Knoten zurückgesetzt. SlurmVersucht in der Zwischenzeit, 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 den Stress zu reduzieren, Slurm wenn versucht wird, fehlerhafte Jobs häufig erneut in die Warteschlange zu stellen.

  • Beachten Sie, dass sich SuspendTimeout dies nicht auf die AWS ParallelCluster Wartezeit bezieht, um 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 in wenigen Minuten abgeschlossen. Während dieser Zeit verbleibt der Knoten jedoch im POWER_DOWN Status und steht dem Scheduler nicht zur Verfügung.

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

• Dynamische Knoten:

  • Prüfen Sie im ResumeProgram Protokoll, ob der Aufruf mit dem Knoten ResumeProgram erfolgte. Wenn nicht, überprüfen Sie das slurmctld Protokoll, um festzustellen, ob Slurm 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 Instance nicht gestartet wurde, sollte eine klare Fehlermeldung angezeigt werden, warum die Instance 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 Instances nicht gestartet wurden, sollte es klare Fehler geben, warum die Instances nicht gestartet werden konnten.

  • Wenn eine Instance gestartet wurde, liegt ein Problem mit dem Bootstrap-Prozess vor. 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 replaced/terminated unerwartet:

  • Übernimmt in den meisten clustermgtd Fällen alle Wartungsaktionen des Knotens. 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 Amazon EC2 zusammenhängt, verwenden Sie Tools wie Amazon CloudWatch oder die Amazon EC2-Konsole, CLI oder SDKs, 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 Amazon 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ückzugewinnen.

• Knotenfehler:

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

• 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 ausfallen ScaledownIdletime, schauen Sie im SuspendProgram Protokoll nach, ob slurmctld Prozesse Aufrufe mit dem spezifischen Knoten als Argument getätigt haben. 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. Slurmübergeht Knoten zu Knoten IDLE danachSuspendTimeout.

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

  Bei Problemen mit der Jobzuweisung, der Knotenzuweisung und der Skalierungsentscheidung überprüfen Sie das slurmctld Protokoll auf Fehler.