Slurm Leitfaden für den Modus mit mehreren Warteschlangen

• Ein Knoten in einem POWER_SAVING Status wird mit einem ~ Suffix (zum Beispielidle~) in sinfo angezeigt. In diesem Status unterstützen keine EC2 Instanzen den Knoten. Jedoch Slurm kann dem Knoten immer noch Jobs zuweisen.

• Ein Knoten, der in einen POWER_UP Status übergeht, wird mit einem # Suffix (zum Beispielidle#) in angezeigt. sinfo Ein Knoten wechselt automatisch in einen POWER_UP Zustand, wenn Slurm weist einem Knoten in einem Status einen Job zu. POWER_SAVING

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

  $ scontrol update nodename=nodename state=power_up

  In dieser Phase ResumeProgram wird der aufgerufen, EC2 Instanzen werden gestartet und konfiguriert und der Knoten wechselt in den POWER_UP Status.

• Ein Knoten, der derzeit zur Verwendung verfügbar ist, wird ohne Suffix angezeigt (z. B.idle) in. sinfo Nachdem der Knoten eingerichtet wurde und dem Cluster beigetreten ist, steht er für die Ausführung von Jobs zur Verfügung. In dieser Phase ist der Knoten ordnungsgemäß konfiguriert und einsatzbereit.

  In der Regel empfehlen wir, dass die Anzahl der EC2 Amazon-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 Status 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 Status zurückversetzt und kann danach wieder verwendet ScaledownIdletimewerden.

  Die ScaledownIdletimeEinstellung wird gespeichert im Slurm SuspendTimeoutKonfigurationseinstellung.

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

• 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. Neue Instanzen werden für Knoten in einer inaktiven Partition nicht gestartet.

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

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

• Starten der Compute-Flotte — Wenn der folgende Befehl ausgeführt wird, wechseln zunächst alle Partitionen in den UP Status. AWS ParallelCluster Prozesse halten die Partition jedoch nicht in einem 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 keine dynamische Kapazität erhöht. UP

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

• STOP_REQUESTED: Die Flottenanforderung „Stop Compute“ wird an den Cluster gesendet.

• STOPPING: Der pcluster Prozess stoppt derzeit die Compute-Flotte.

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

• START_REQUESTED: Die Anfrage zum Starten der Compute-Flotte wird an den Cluster gesendet.

• STARTING: Der pcluster Prozess startet derzeit 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 konsistente Bootstrap-Fehler auftreten. Die betroffenen Partitionen sind inaktiv. Bitte untersuchen Sie das Problem und starten Sie dann den Vorgangupdate-compute-fleet, um die Flotte erneut zu aktivieren.

• Dynamische Knoten im POWER_SAVING Status einschalten

  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, der eine bestimmte Anzahl von Knoten anfordert, und sich dann darauf verlassen Slurm um die erforderliche Anzahl von Knoten hochzufahren.

• Schalten Sie zuvor dynamische Knoten aus ScaledownIdletime

  Wir empfehlen, dynamische Knoten mit dem DOWN folgenden Befehl auf su Root-Benutzer einzustellen:

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

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

  Im Allgemeinen empfehlen wir nicht, Knoten POWER_DOWN direkt mithilfe des Befehls so einzustellen. scontrol update nodename=nodename state=power_down Das liegt daran, dass der Abschaltvorgang 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.

• Aktiviert 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 empfängt einen Job, für den zwei Knoten erforderlich sind.

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

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

• Die Instances werden konfiguriert und treten dem Cluster bei. Ein Job wird auf Instanzen ausgeführt.

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

• Nach Ablauf der konfigurierten SuspendTime Zeit (die auf gesetzt ist ScaledownIdletime), setzt der Scheduler die Instanzen auf den Status. POWER_SAVING Der Scheduler wechselt dann queue1-dy-spotcompute1-[1-2] auf den POWER_DOWN Status und ruft SuspendProgram mit den Knotennamen auf.

• SuspendProgramwird für zwei Knoten aufgerufen. Knoten bleiben in diesem POWER_DOWN Zustand, z. B. indem sie eine Zeit idle% lang verbleiben SuspendTimeout (der Standardzeitraum ist 120 Sekunden (2 Minuten)). Nachdem clustermgtd erkannt wurde, dass Knoten heruntergefahren werden, werden die unterstützenden Instances beendet. Anschließend 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 future Aufgaben 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 ResumeProgram mit den Knotennamen auf (zum Beispiel). queue1-dy-spotcompute1-[1-2]

• ResumeProgramstartet nur eine (1) EC2 Amazon-Instance und konfiguriertqueue1-dy-spotcompute1-1, bei der eine (1) Instance nicht gestartet werden kann. queue1-dy-spotcompute1-2

• queue1-dy-spotcompute1-1ist nicht betroffen und wird nach Erreichen des POWER_UP Bundesstaats online geschaltet.

• queue1-dy-spotcompute1-2wechselt in den POWER_DOWN Status, und der Job wird automatisch in die Warteschlange gestellt, weil Slurm erkennt einen Knotenausfall.

• queue1-dy-spotcompute1-2wird danach verfügbar SuspendTimeout (die Standardeinstellung ist 120 Sekunden (2 Minuten)). In der Zwischenzeit wird der Job 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 Timing-Parameter, die bei Bedarf angepasst werden können:

• ResumeTimeout(Die Standardeinstellung ist 30 Minuten): ResumeTimeout steuert die Zeit Slurm wartet, bevor der Knoten in den ausgefallenen Zustand versetzt wird.

  • Eine Erweiterung könnte nützlich sein, ResumeTimeout wenn der Prozess vor und nach der Installation fast genauso lange dauert.

  • ResumeTimeoutist auch die maximale AWS ParallelCluster Wartezeit, bis ein Knoten ersetzt oder zurückgesetzt wird, falls ein Problem auftritt. Rechenknoten beenden sich selbst, wenn während des Starts oder 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 Knoten schneller zurückgesetzt werden, und Slurm kann versuchen, Instances häufiger zu starten.

  • Länger SuspendTimeout bedeutet, dass ausgefallene Knoten langsamer zurückgesetzt werden. In der Zwischenzeit Slurm versucht, andere Knoten zu verwenden. Wenn SuspendTimeout es mehr als ein paar Minuten sind, Slurm versucht, alle Knoten im System zu durchlaufen. Eine längere Laufzeit SuspendTimeout könnte für große Systeme (über 1.000 Knoten) von Vorteil sein, um die stress zu verringern Slurm wenn versucht wird, fehlgeschlagene Jobs häufig in die Warteschlange zu stellen.

  • Beachten Sie, dass sich SuspendTimeout dies nicht auf die AWS ParallelCluster Wartezeit bezieht, bis eine Backing-Instance für einen Knoten beendet wird. Backing-Instances für POWER_DOWN Knoten werden sofort beendet. Der Terminierungsvorgang 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 mit dem Knoten aufgerufen ResumeProgram wurde. Falls nicht, überprüfen Sie das slurmctld Protokoll, um festzustellen, ob Slurm hat versucht, ResumeProgram mit dem Knoten anzurufen. Beachten Sie, dass falsche Berechtigungen dazu führen ResumeProgram können, dass der Vorgang im Hintergrund 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 es eine klare Fehlermeldung geben, 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 Logs an.

• Statische Knoten:

  • Prüfen Sie im clustermgtd Protokoll, ob Instanzen für den Knoten gestartet wurden. Wenn Instances nicht gestartet wurden, sollte es eindeutige Fehler darüber 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 unter Logs an CloudWatch .

• Knoten wurden unerwartet ersetzt/beendet:

  • In den meisten Fällen clustermgtd erledigt es alle Wartungsaktionen für Knoten. 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, in der der Grund für die Aktion angegeben ist. Wenn der Grund mit dem Scheduler zusammenhängt (zum Beispiel der KnotenDOWN), suchen Sie im slurmctld Protokoll nach weiteren Einzelheiten. Wenn der Grund EC2 mit Amazon zusammenhängt, verwenden Sie Tools wie Amazon CloudWatch oder die EC2 Amazon-Konsole, oder CLISDKs, um den Status oder die Protokolle für diese Instanz zu überprüfen. Sie können beispielsweise überprüfen, ob für die Instance Ereignisse geplant waren oder ob die EC2 Amazon-Integritätsprüfungen nicht bestanden haben.

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

• Knotenausfälle:

  • In den meisten Fällen werden Jobs automatisch in die Warteschlange gestellt, wenn ein Knoten ausfällt. Schauen 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 ausgeführt haben. Note führt eigentlich SuspendProgram keine bestimmte Aktion aus. Vielmehr protokolliert es nur, wenn es aufgerufen wird. Alle Instanzbeendigungen und NodeAddr Resets sind bis abgeschlossenclustermgtd. Slurm wechselt von Knoten zu den nachfolgenden KnotenIDLE. SuspendTimeout

• AWS ParallelCluster trifft keine Entscheidungen zur Stellenzuweisung oder Skalierung. Es versucht lediglich, Ressourcen entsprechend zu starten, zu beenden und zu verwalten Slurmseine Anweisungen.

  Bei Problemen mit der Auftragszuweisung, der Knotenzuweisung und der Skalierungsentscheidung suchen Sie im slurmctld Protokoll nach Fehlern.