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 Workload Manager (`slurm`)
AWS ParallelCluster Version 2.11.9 verwendet 20.11.9. Slurm Weitere Informationen zu Slurm finden Sie unter [https://slurm.schedmd.com/](https://slurm.schedmd.com/). Downloads finden Sie unter [https://github.com/SchedMD/slurm/tags](https://github.com/SchedMD/slurm/tags). Sie finden den Quellcode unter [https://github.com/SchedMD/slurm](https://github.com/SchedMD/slurm).
**Wichtig**
AWS ParallelCluster wird mit Slurm Konfigurationsparametern getestet, die standardmäßig bereitgestellt werden. Alle Änderungen, die Sie an diesen Slurm Konfigurationsparametern vornehmen, erfolgen auf eigenes Risiko. Sie werden nur nach bestem Wissen und Gewissen unterstützt.
| AWS ParallelCluster Version (en) | Unterstützte Slurm-Version |
| --- | --- |
| 2.11.7, 2.11.8, 2.11.9 | 20,11,9 |
| 2.11.4 bis 2.11.6 | 20.11.8 |
| 2.11.0 bis 2.11.3 | 20.11.7 |
| 2.10.4 | 20,02,7 |
| 2.9.0 bis 2.10.3 | 20.02.4 |
| 2.6 bis 2.8.1 | 19.05.5 |
| 2,5.0, 2,5.1 | 19.05.3-2 |
| 2.3.1 bis 2.4.1 | 18.08.6-2 |
| vor 2.3.1 | 16.05.3-1 |
# Modus mit mehreren Warteschlangen
AWS ParallelCluster Version 2.9.0 führte den Modus mit mehreren Warteschlangen ein. Der Modus mit mehreren Warteschlangen wird unterstützt, wenn [`scheduler`](cluster-definition.md#scheduler) er auf eingestellt `slurm` und die [`queue_settings`](cluster-definition.md#queue-settings) Einstellung definiert ist. Dieser Modus ermöglicht die Koexistenz verschiedener Instanztypen in den Rechenknoten. Die Rechenressourcen, die die verschiedenen Instanztypen enthalten, können nach Bedarf nach oben oder unten skaliert werden. Im Warteschlangenmodus werden bis zu fünf (5) Warteschlangen unterstützt, und jeder [`[queue]`Abschnitt](queue-section.md) kann sich auf bis zu drei (3) [`[compute_resource]`Abschnitte](compute-resource-section.md) beziehen. Jeder dieser [`[queue]`Abschnitte](queue-section.md) ist eine Partition inSlurm Workload Manager. Weitere Informationen erhalten Sie unter [SlurmLeitfaden für den Modus mit mehreren Warteschlangen](multiple-queue-mode-slurm-user-guide.md) und [Tutorial zum Modus mit mehreren Warteschlangen](tutorial-mqm.md).
Jeder [`[compute_resource]`Abschnitt](compute-resource-section.md) in einer Warteschlange muss einen anderen Instanztyp haben, und jeder dieser Abschnitte `[compute_resource]` ist weiter in statische und dynamische Knoten unterteilt. Statische Knoten für jeden Knoten `[compute_resource]` werden von 1 bis zum Wert von nummeriert[`min_count`](compute-resource-section.md#compute-resource-min-count). Dynamische Knoten `[compute_resource]` werden jeweils von eins (1) bis ([`max_count`](compute-resource-section.md#compute-resource-max-count)-`min_count`) nummeriert. Wenn beispielsweise 2 und 10 `min_count` `max_count` ist, `[compute_resource]` werden die dynamischen Knoten für diesen Wert von eins (1) bis acht (8) nummeriert. Der Wert kann jederzeit zwischen Null (0) und der maximalen Anzahl dynamischer Knoten in a liegen`[compute_resource]`.
Die Instances, die in der Rechenflotte gestartet werden, werden dynamisch zugewiesen. Um dies zu verwalten, werden Hostnamen für jeden Knoten generiert. Das Format des Hostnamens lautet wie folgt:
`$HOSTNAME=$QUEUE-$STATDYN-$INSTANCE_TYPE-$NODENUM`
+ `$QUEUE`ist der Name der Warteschlange. Wenn der Abschnitt beispielsweise beginnt, `[queue queue-name]` dann "`$QUEUE`" ist "*queue-name*“.
+ `$STATDYN`ist `st` für statische Knoten oder `dy` für dynamische Knoten.
+ `$INSTANCE_TYPE`ist der Instanztyp für`[compute_resource]`, aus der [`instance_type`](compute-resource-section.md#compute-resource-instance-type) Einstellung.
+ `$NODENUM`ist die Nummer des Knotens. `$NODENUM`liegt zwischen eins (1) und dem Wert von [`min_count`](compute-resource-section.md#compute-resource-min-count) für statische Knoten und zwischen eins (1) und ([`max_count`](compute-resource-section.md#compute-resource-max-count)-`min_count`) für dynamische Knoten.
Sowohl Hostnamen als auch vollqualifizierte Domainnamen (FQDN) werden mithilfe von Amazon Route 53-Hosting-Zonen erstellt. Der FQDN ist`$HOSTNAME.$CLUSTERNAME.pcluster`, wobei der Name des [`[cluster]`Abschnitts `$CLUSTERNAME`](cluster-definition.md) steht, der für den Cluster verwendet wird.
Verwenden Sie den [`pcluster-config convert`](pcluster-config.md#pcluster-config-convert) Befehl, um Ihre Konfiguration in einen Warteschlangenmodus zu konvertieren. Es schreibt eine aktualisierte Konfiguration mit einem einzigen [`[queue]`Abschnitt](queue-section.md) namens`[queue compute]`. Diese Warteschlange enthält einen einzelnen [`[compute_resource]`Abschnitt](compute-resource-section.md), der benannt ist`[compute_resource default]`. Das `[queue compute]` und `[compute_resource default]` hat Einstellungen, die aus dem angegebenen [`[cluster]`Abschnitt](cluster-definition.md) migriert wurden.
# SlurmLeitfaden 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](https://slurm.schedmd.com/elastic_computing.html) und dem Energiespar-Plugin. Weitere Informationen zum Energiespar-Plugin finden Sie im [SlurmPower Saving Guide](https://slurm.schedmd.com/power_save.html). 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 gesamten Lebenszyklus treten Cloud-Knoten in mehrere, wenn nicht sogar 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 wechseln. In der folgenden Liste werden verschiedene Aspekte dieser Zustände im Lebenszyklus eines Cloud-Knotens beschrieben.
+ Ein Knoten in einem `POWER_SAVING` Status wird mit einem `~` Suffix (zum Beispiel`idle~`) in `sinfo` angezeigt. In diesem Status gibt es keine EC2-Instance, die den Knoten unterstützt. SlurmKann dem Knoten jedoch weiterhin Jobs zuweisen.
+ Ein Knoten, der in einen `POWER_UP` Status übergeht, wird mit einem `#` Suffix (zum Beispiel`idle#`) in angezeigt. `sinfo`
+ Wenn Slurm einem Knoten in einem Status eine Aufgabe zugewiesen wird, wechselt der Knoten automatisch in einen `POWER_SAVING` Status. `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 konfiguriert, um einen `POWER_UP` Knoten zu unterstützen.
+ Ein Knoten, der derzeit zur Verwendung verfügbar ist, wird ohne Suffix (z. B.`idle`) in angezeigt. `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. Als allgemeine Regel empfehlen wir, dass die Anzahl der Instanzen 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 automatisch in den `POWER_DOWN` Status danach. [`scaledown_idletime`](scaling-section.md#scaledown-idletime) Im Gegensatz dazu werden statische Knoten in den meisten Fällen nicht ausgeschaltet. 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 mit einem Knoten verknüpfte Instanz beendet und der Knoten wird in den `POWER_SAVING` Zustand zurückgesetzt, in dem er future verwendet werden kann[`scaledown_idletime`](scaling-section.md#scaledown-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 unterstützenden Instanzen beendet werden.
Betrachten Sie nun die im folgenden `sinfo` Beispiel gezeigten Knotenzustände.
```
$ 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-Instances eingerichtet, sodass sie verwendet werden können. 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 wird danach in den `POWER_SAVING` Status [`scaledown_idletime`](scaling-section.md#scaledown-idletime) übergehen (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 per SSH direkt auf die Instanz zuzugreifen (zum Beispiel`ssh efa-st-c5n18xlarge-1`). Die private IP-Adresse der Instanz kann mit dem `scontrol show nodes nodename` Befehl abgerufen und das `NodeAddr` Feld markiert werden. Bei Knoten, die nicht verfügbar sind, sollte das `NodeAddr` Feld nicht auf eine laufende EC2-Instance verweisen. Vielmehr sollte es mit dem Knotennamen identisch sein.
## Status und Einreichung von Job
In den meisten Fällen werden übermittelte Jobs sofort Knoten im System zugewiesen oder als ausstehend eingestuft, wenn alle Knoten zugewiesen sind.
Wenn die für einen Job zugewiesenen Knoten Knoten in einem `POWER_SAVING` Status enthalten, beginnt der Job mit einem `CF` oder`CONFIGURING`. Zu diesem Zeitpunkt wartet der Job darauf, dass die Knoten im `POWER_SAVING` Status in den `POWER_UP` Status wechseln und verfügbar sind.
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 Partition inSlurm) übergeben. Dies wird durch ein `*` Suffix nach dem Warteschlangennamen gekennzeichnet. Sie können mit der Option zum Einreichen von `-p` Jobs 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 Beispiel`c5.xlarge`)
+ Ein Knotentyp (Dies ist entweder `dynamic` oder`static`.)
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.
Ein weiterer Aspekt sind Arbeitsplätze. Betrachten Sie zunächst den Ausgangsstatus des Clusters, den Sie anzeigen können, indem Sie den `sinfo` Befehl ausführen.
```
$ 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.
Sendet einen Job an einen statischen Knoten in der Standardwarteschlange (`spot`).
```
$ sbatch --wrap "sleep 300" -N 1 -C static
```
Sendet einen Job an einen dynamischen Knoten in der `EFA` Warteschlange.
```
$ sbatch --wrap "sleep 300" -p efa -C dynamic
```
Sendet 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 der `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) werden bereits ausgeführt (`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
```
## Status und Funktionen des Knotens
In den meisten Fällen werden Knotenstatus AWS ParallelCluster gemäß den spezifischen Prozessen im Cloud-Knoten-Lebenszyklus, die weiter oben in diesem Thema beschrieben wurden, vollständig verwaltet.
Ersetzt oder beendet jedoch AWS ParallelCluster auch fehlerhafte Knoten in `DRAINED` Zuständen `DOWN` und Knoten, die über fehlerhafte Backing-Instances verfügen. Weitere Informationen finden Sie unter [`clustermgtd`](processes.md#clustermgtd).
## Status der Partition
AWS ParallelCluster unterstützt die folgenden Partitionsstatus. 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. Neue Instanzen werden für Knoten in einer inaktiven Partition nicht gestartet.
## pcluster starten und beenden
Wenn [`pcluster stop`](pcluster.stop.md) es ausgeführt wird, werden alle Partitionen in den `INACTIVE` Status versetzt, und die AWS ParallelCluster Prozesse behalten die Partitionen im `INACTIVE` Status bei.
Wenn ausgeführt [`pcluster start`](pcluster.start.md) wird, werden zunächst alle Partitionen in den `UP` Status versetzt. 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` Wenn größer als [`initial_count`](compute-resource-section.md#compute-resource-initial-count) ist[`max_count`](compute-resource-section.md#compute-resource-max-count), ist [`initial_count`](compute-resource-section.md#compute-resource-initial-count) es möglicherweise nicht erfüllt, wenn der Partitionsstatus in den `UP` Status geändert wird.
Wenn [`pcluster start`](pcluster.start.md) und ausgeführt [`pcluster stop`](pcluster.stop.md) werden, können Sie den Status des Clusters überprüfen, indem Sie den [`pcluster status`](pcluster.status.md) Befehl ausführen und das überprüfen`ComputeFleetStatus`. Im Folgenden werden mögliche Status aufgeführt:
+ `STOP_REQUESTED`: Die [`pcluster stop`](pcluster.stop.md) 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 wurden beendet.
+ `START_REQUESTED`: Die [`pcluster start`](pcluster.start.md) Anfrage 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.
## Manuelle Steuerung von Warteschlangen
In einigen Fällen möchten Sie möglicherweise die Knoten oder die Warteschlange (auch Partition genanntSlurm) in einem Cluster manuell steuern. Sie können Knoten in einem Cluster mithilfe der folgenden gängigen 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` Platzhalter-Job, der eine bestimmte Anzahl von Knoten anfordert, und verlassen Sie sich daraufSlurm, dass die erforderliche Anzahl von Knoten eingeschaltet wird.
+ Dynamische Knoten vorher ausschalten[`scaledown_idletime`](scaling-section.md#scaledown-idletime): Stellen Sie dynamische Knoten `DOWN` mit dem `scontrol update nodename=nodename state=down` Befehl auf ein. AWS ParallelCluster beendet die ausgefallenen dynamischen Knoten automatisch 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 Abschaltvorgang AWS ParallelCluster automatisch abgewickelt wird. Es ist kein manueller Eingriff erforderlich. Daher empfehlen wir, dass Sie versuchen, die Knoten `DOWN` wann immer möglich auf zu setzen.
+ 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 die Warteschlange spezifisch ein. Dadurch werden alle Instanzen beendet, die Knoten in der Partition unterstützen.
+ Eine 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 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 Beispiel`queue1-dy-c5xlarge-[1-2]`).
+ `ResumeProgram`startet zwei EC2-Instances und weist die privaten IP-Adressen und Hostnamen von zu. Warten Sie `ResumeTimeout` (der Standardzeitraum beträgt 60 Minuten (1 Stunde))`queue1-dy-c5xlarge-[1-2]`, bevor die Knoten zurückgesetzt werden.
+ Die Instanzen werden konfiguriert und treten dem Cluster bei. Der Job wird auf Instanzen ausgeführt.
+ Die Job ist erledigt.
+ Nach Ablauf der konfigurierten `SuspendTime` Zeit (die auf gesetzt ist[`scaledown_idletime`](scaling-section.md#scaledown-idletime)), werden die Instanzen vom Scheduler in den `POWER_SAVING` Status versetzt. Der Scheduler `queue1-dy-c5xlarge-[1-2]` versetzt den `POWER_DOWN` Status und ruft `SuspendProgram` mit den Knotennamen auf.
+ `SuspendProgram`wird für zwei Knoten aufgerufen. Knoten bleiben in diesem `POWER_DOWN` Zustand, z. B. indem sie eine Zeit `idle%` lang verbleiben `SuspendTimeout` (der Standardzeitraum beträgt 120 Sekunden (2 Minuten)). Nachdem `clustermgtd` erkannt wurde, dass Knoten heruntergefahren werden, werden die unterstützenden Instances beendet. Anschließend wird die Konfiguration `queue1-dy-c5xlarge-[1-2]` in den Ruhezustand versetzt und die private IP-Adresse und der Hostname zurückgesetzt, sodass sie für future Jobs 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 empfängt einen Job, für den zwei Knoten erforderlich sind.
+ Der Scheduler versetzt zwei Cloud-Bursting-Knoten in den `POWER_UP` Status und ruft sie `ResumeProgram` mit den Knotennamen auf (zum Beispiel). `queue1-dy-c5xlarge-[1-2]`
+ `ResumeProgram`startet nur eine (1) EC2-Instance und konfiguriert sie`queue1-dy-c5xlarge-1`, aber es konnte keine Instance für gestartet werden. `queue1-dy-c5xlarge-2`
+ `queue1-dy-c5xlarge-1`ist nicht betroffen und wird nach Erreichen `POWER_UP` des Status online geschaltet.
+ `queue1-dy-c5xlarge-2`wird in den `POWER_DOWN` Status versetzt, und der Job wird automatisch in die Warteschlange gestellt, da ein Slurm Knotenausfall erkannt wird.
+ `queue1-dy-c5xlarge-2`wird 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 60 Minuten (1 Stunde)): `ResumeTimeout` Steuert die Slurm Wartezeit, bis der Knoten in den Status „Heruntergefahren“ 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, 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. Als Nächstes ersetzt der AWS ParallelCluster Prozess auch den Knoten, wenn er feststellt, dass die Instanz beendet wurde.
+ `SuspendTimeout`(Die Standardeinstellung ist 120 Sekunden (2 Minuten)): `SuspendTimeout` Steuert, wie schnell Knoten wieder im System platziert und wieder einsatzbereit sind.
+ Ein kürzerer Wert `SuspendTimeout` würde bedeuten, dass Knoten schneller zurückgesetzt werden und Slurm häufiger versucht werden kann, Instances zu starten.
+ Bei einer längeren `SuspendTimeout` Einstellung werden ausgefallene Knoten langsamer zurückgesetzt. In der Zwischenzeit versucht erSlurm, andere Knoten zu verwenden. Wenn `SuspendTimeout` es länger als ein paar Minuten dauert, wird 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 indem ausfallende Jobs häufig in die Warteschlange gestellt werden.
+ Beachten Sie, dass sich `SuspendTimeout` dies nicht auf die Wartezeit bezieht, bis AWS ParallelCluster eine Backing-Instance für einen Knoten beendet wurde. Backing-Instances für `power down` Knoten werden sofort beendet. Der Terminierungsvorgang ist in der Regel nach wenigen Minuten abgeschlossen. Während dieser Zeit befindet sich der Knoten jedoch im ausgeschalteten Zustand und kann nicht im Scheduler verwendet werden.
## Protokolle für die neue Architektur
Die folgende Liste enthält die wichtigsten Protokolle für die Architektur mit mehreren Warteschlangen. Der mit Amazon CloudWatch Logs verwendete Protokollstreamname hat das Format`{hostname}.{instance_id}.{logIdentifier}`, in dem die Protokollnamen *logIdentifier* folgen. Weitere Informationen finden Sie unter [Integration mit Amazon CloudWatch Logs](cloudwatch-logs.md).
+ `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 Anleitung zum Debuggen:
**Knoten, die nicht gestartet, hochgefahren oder dem Cluster nicht beigetreten sind:**
+ Dynamische Knoten:
+ Sehen Sie im `ResumeProgram` Protokoll nach, ob jemals mit dem Knoten aufgerufen `ResumeProgram` wurde. Falls 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 Instance nicht gestartet werden kann, 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 nicht, sollte es eindeutige Fehler darüber geben, warum die Instances nicht gestartet werden konnten.
+ Wenn eine Instance gestartet wurde, liegt ein Problem beim Bootstrap-Vorgang 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 Logs an.
**Knoten wurden unerwartet ersetzt oder beendet, Knotenausfälle**
+ Knoten replaced/terminated unerwartet
+ 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, die den Grund für die Aktion angibt. Wenn der Grund mit dem Scheduler zusammenhängt (zum Beispiel der Knoten`DOWN`), suchen Sie im `slurmctld` Protokoll nach weiteren Einzelheiten. 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 die Instance geplante Ereignisse hatte oder ob die EC2-Integritätsprüfungen nicht bestanden haben.
+ Falls 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.
+ 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 analysieren Sie die Situation von dort aus.
**Fehler beim Ersetzen oder Beenden von Instanzen, Fehler beim Herunterfahren von Knoten**
+ `clustermgtd`Behandelt 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[`scaledown_idletime`](scaling-section.md#scaledown-idletime), schauen Sie im `SuspendProgram` Protokoll nach, ob ein Programm `slurmctld` mit dem spezifischen Knoten als Argument gestartet wurde. Note führt eigentlich `SuspendProgram` keine bestimmte Aktion aus. Vielmehr protokolliert es nur, wenn es aufgerufen wird. Alle Instanzbeendigungen und `NodeAddr` Resets sind bis abgeschlossen`clustermgtd`. Slurmfügt Knoten in den Ordner `IDLE` danach ein`SuspendTimeout`.
**Andere Probleme**
+ AWS ParallelCluster trifft keine Entscheidungen zur Stellenzuweisung oder Skalierung. Es versucht einfach, Ressourcen gemäß den Anweisungen zu starten, zu beenden und zu Slurm verwalten.
Bei Problemen mit der Auftragszuweisung, der Knotenzuweisung und der Skalierungsentscheidung suchen Sie im `slurmctld` Protokoll nach Fehlern.