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.
# Scheduler unterstützt von AWS ParallelCluster
AWS ParallelCluster Unterstützungen Slurm und AWS Batch Scheduler, die mithilfe der Einstellung festgelegt werden. [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) In den folgenden Themen werden die einzelnen Scheduler und ihre Verwendung beschrieben.
**Topics**
+ [Slurm Workload Manager (`slurm`)](slurm-workload-manager-v3.md)
+ [Verwenden des AWS Batch (`awsbatch`) -Schedulers mit AWS ParallelCluster](awsbatchcli-v3.md)
# Slurm Workload Manager (`slurm`)
## Größe und Aktualisierung der Clusterkapazität
Die Kapazität des Clusters wird durch die Anzahl der Rechenknoten definiert, die der Cluster skalieren kann. Rechenknoten werden von Amazon EC2 EC2-Instances unterstützt, die in der AWS ParallelCluster Konfiguration innerhalb von Rechenressourcen definiert sind`(Scheduling/SlurmQueues/`ComputeResources`)`, und sind in Warteschlangen organisiert, `(Scheduling/SlurmQueues)` die Partitionen 1:1 zugeordnet Slurm sind.
Innerhalb einer Rechenressource ist es möglich, die Mindestanzahl von Rechenknoten (Instances), die immer im Cluster laufen müssen (`MinCount`), und die maximale Anzahl von Instances, auf die die Rechenressource skaliert werden kann, zu konfigurieren ([`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)).
AWS ParallelCluster Startet bei der Clustererstellung oder bei einem Cluster-Update so viele Amazon EC2 EC2-Instances, wie `MinCount` für jede im Cluster definierte Rechenressource (`Scheduling/SlurmQueues/ ComputeResources`) konfiguriert sind. Die Instances, die gestartet werden, um die minimale Anzahl von Knoten für Rechenressourcen im Cluster abzudecken, werden als ***statische Knoten*** bezeichnet. Einmal gestartet, sollen statische Knoten im Cluster persistent sein und werden nicht vom System beendet, es sei denn, ein bestimmtes Ereignis oder eine bestimmte Bedingung tritt ein. Zu diesen Ereignissen gehören beispielsweise der Ausfall von Slurm Amazon EC2 EC2-Zustandsprüfungen und die Änderung des Slurm Knotenstatus auf DRAIN oder DOWN.
Die Amazon EC2 EC2-Instances im Bereich von `1` bis `‘MaxCount - MinCount’` (`MaxCount `*minus*)` MinCount)`, die bei Bedarf gestartet werden, um die erhöhte Last des Clusters zu bewältigen, werden als ***dynamische Knoten*** bezeichnet. Sie sind kurzlebig, sie werden gestartet, um ausstehende Jobs zu bearbeiten, und werden beendet, sobald sie für einen `Scheduling/SlurmSettings/ScaledownIdletime` in der Cluster-Konfiguration definierten Zeitraum inaktiv bleiben (Standard: 10 Minuten).
Statische Knoten und dynamische Knoten entsprechen dem folgenden Benennungsschema:
+ Statische Knoten `-st--` wo ` = 1..ComputeResource/MinCount`
+ Dynamische Knoten `-dy--` wo ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Zum Beispiel bei der folgenden AWS ParallelCluster Konfiguration:
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
Die folgenden Knoten werden definiert in Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Wenn es sich bei einer Rechenressource um statische Rechenknoten handelt`MinCount == MaxCount`, sind alle zugehörigen Rechenknoten statisch und alle Instanzen werden zur creation/update Clusterzeit gestartet und am Laufen gehalten. Beispiel:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Aktualisierung der Clusterkapazität
Die Aktualisierung der Clusterkapazität umfasst das Hinzufügen oder Entfernen von Warteschlangen, Rechenressourcen oder das Ändern `MinCount/MaxCount` einer Rechenressource. Ab AWS ParallelCluster Version 3.9.0 muss zur Reduzierung der Größe einer Warteschlange die Rechenflotte gestoppt oder auf TERMINATE [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)gesetzt werden, bevor ein Cluster-Update stattfinden kann. In folgenden Fällen ist es nicht erforderlich, die Rechenflotte zu beenden oder auf [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)TERMINATE zu setzen:
+ Neue Warteschlangen zu Scheduling hinzufügen/ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Neue Rechenressourcen `Scheduling/SlurmQueues/ComputeResources` zu einer Warteschlange hinzufügen
+ Erhöhung der `MaxCount` Anzahl einer Rechenressource
+ Erhöhung MinCount einer Rechenressource und Erhöhung MaxCount derselben Rechenressource um mindestens die gleiche Menge
## Überlegungen und Einschränkungen
In diesem Abschnitt sollen alle wichtigen Faktoren, Einschränkungen oder Einschränkungen beschrieben werden, die bei der Größenänderung der Clusterkapazität berücksichtigt werden sollten.
+ Beim Entfernen einer Warteschlange aus `Scheduling/SlurmQueues` allen Rechenknoten mit Namen`-*`, sowohl statische als auch dynamische, werden sie aus der Slurm Konfiguration entfernt und die entsprechenden Amazon EC2 EC2-Instances werden beendet.
+ Beim Entfernen einer Rechenressource `Scheduling/SlurmQueues/ComputeResources` aus einer Warteschlange werden alle Rechenknoten mit Namen`-*--*`, sowohl statisch als auch dynamisch, aus der Slurm Konfiguration entfernt und die entsprechenden Amazon EC2 EC2-Instances werden beendet.
Wenn wir den `MinCount` Parameter einer Rechenressource ändern, können wir zwei verschiedene Szenarien unterscheiden: ob gleich gehalten `MaxCount` wird `MinCount` (nur statische Kapazität) und ob größer als `MinCount` (gemischte statische und dynamische Kapazität) `MaxCount` ist.
### Die Kapazität ändert sich nur bei statischen Knoten
+ Wenn `MinCount == MaxCount` beim Erhöhen `MinCount` (und`MaxCount`) der Cluster konfiguriert wird, indem die Anzahl der statischen Knoten auf den neuen Wert von erhöht wird `MinCount` `-st--` und das System weiterhin versucht, Amazon EC2 EC2-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen.
+ Wenn `MinCount == MaxCount` beim Verringern `MinCount` (und`MaxCount`) der Menge N der Cluster konfiguriert wird, indem die letzten N statischen Knoten entfernt werden, `-st--...]` und das System beendet die entsprechenden Amazon EC2 EC2-Instances.
+ Ursprünglicher Zustand `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Update `-30` am `MinCount` und `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Kapazitätsänderungen bei gemischten Knoten
Wenn der Cluster um einen Betrag N erhöht `MinCount` `MaxCount` wird (vorausgesetzt`MinCount < MaxCount`, dass er unverändert bleibt), wird der Cluster konfiguriert, indem die Anzahl der statischen Knoten auf den neuen Wert von `MinCount` (`old_MinCount + N`): erweitert wird, `-st--` und das System versucht weiterhin, Amazon EC2 EC2-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen. Um der `MaxCount` Kapazität der Rechenressource Rechnung zu tragen, wird die Cluster-Konfiguration außerdem aktualisiert, *indem die letzten N dynamischen Knoten* entfernt werden. Das System beendet dann die entsprechenden Amazon EC2 EC2-Instances. `-dy--[...]`
+ Ausgangszustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aktualisieren Sie \$130 auf `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Wenn `MinCount < MaxCount` bei Erhöhung `MinCount` und gleichem Wert N `MaxCount` der Cluster konfiguriert wird, indem die Anzahl der statischen Knoten auf den neuen Wert von `MinCount` (`old_MinCount + N`): erweitert wird, `-st--` und das System versucht weiterhin, Amazon EC2 EC2-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen. Darüber hinaus werden keine Änderungen an der Anzahl der dynamischen Knoten vorgenommen, um den neuen Anforderungen gerecht zu werden
`MaxCount` Wert.
+ Ausgangszustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aktualisieren Sie \$130 auf `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Wenn die `MinCount` Anzahl N verringert `MaxCount` wird (vorausgesetzt`MinCount < MaxCount`, dass sie unverändert bleibt), wird der Cluster konfiguriert, indem die letzten N statischen Knoten entfernt werden, `-st--[...` und das System beendet die entsprechenden Amazon EC2 EC2-Instances. Um der `MaxCount` Kapazität der Rechenressource Rechnung zu tragen, wird außerdem die Cluster-Konfiguration aktualisiert, indem die Anzahl der dynamischen Knoten erhöht wird, um die Lücke zu schließen. `MaxCount - new_MinCount: -dy--[1..]` In diesem Fall, da es sich um dynamische Knoten handelt, werden keine neuen Amazon EC2 EC2-Instances gestartet, es sei denn, der Scheduler hat Jobs auf den neuen Knoten ausstehend.
+ Ausgangszustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Update -30 am `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Wenn `MinCount < MaxCount` `MaxCount` der Wert abnimmt `MinCount` und die gleiche Menge N beträgt, wird der Cluster konfiguriert, indem die letzten N statischen Knoten entfernt werden, `-st--...]` und das System beendet die entsprechenden Amazon EC2 EC2-Instances.
Darüber hinaus werden keine Änderungen an der Anzahl der dynamischen Knoten vorgenommen, um dem neuen `MaxCount` Wert Rechnung zu tragen.
+ Ausgangszustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Update -30 am `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Wenn die `MaxCount` Anzahl N verringert wird (vorausgesetzt`MinCount < MaxCount`, dass sie unverändert bleibt), `MinCount` wird der Cluster konfiguriert, indem die letzten N dynamischen Knoten entfernt werden, `-dy--]` und das System beendet die entsprechenden Amazon EC2 EC2-Instances, falls sie ausgeführt wurden. Es werden keine Auswirkungen auf die statischen Knoten erwartet.
+ Ursprünglicher Zustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Update -30 am `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Auswirkungen auf die Arbeitsplätze
In allen Fällen, in denen Knoten entfernt und Amazon EC2 EC2-Instances beendet werden, wird ein Sbatch-Job, der auf den entfernten Knoten ausgeführt wird, erneut in die Warteschlange gestellt, es sei denn, es gibt keine anderen Knoten, die die Auftragsanforderungen erfüllen. Im letzten Fall schlägt der Job mit dem Status NODE\$1FAIL fehl und verschwindet aus der Warteschlange. Er muss manuell erneut eingereicht werden.
Wenn Sie planen, ein Update zur Änderung der Clustergröße durchzuführen, können Sie verhindern, dass Jobs auf den Knoten ausgeführt werden, die während des geplanten Updates entfernt werden. Dies ist möglich, indem Sie festlegen, dass die Knoten im Rahmen der Wartung entfernt werden. Bitte beachten Sie, dass die Einstellung eines Knotens zur Wartung keine Auswirkungen auf Jobs hat, die eventuell bereits auf dem Knoten ausgeführt werden.
Nehmen wir an, dass Sie mit dem geplanten Update zur Änderung der Clustergröße den Knoten entfernen werden`qeueu-st-computeresource-[9-10`]. Sie können eine Slurm Reservierung mit dem folgenden Befehl erstellen
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Dadurch wird eine Slurm Reservierung erstellt, die `maint_for_update` auf den Knoten benannt ist`qeueu-st-computeresource-[9-10]`. Ab dem Zeitpunkt, an dem die Reservierung erstellt wird, können keine Jobs mehr auf den Knoten ausgeführt werden`qeueu-st-computeresource-[9-10]`. Bitte beachten Sie, dass die Reservierung nicht verhindert, dass Jobs irgendwann auf den Knoten zugewiesen werden`qeueu-st-computeresource-[9-10]`.
Wenn die Slurm Reservierung nach der Aktualisierung der Clustergröße nur für Knoten festgelegt wurde, die während der Aktualisierung der Clustergröße entfernt wurden, wird die Wartungsreservierung automatisch gelöscht. Wenn Sie stattdessen eine Slurm Reservierung für Knoten erstellt haben, die nach der Aktualisierung der Clustergröße noch vorhanden sind, möchten wir möglicherweise die Wartungsreservierung auf den Knoten nach der Aktualisierung der Größe entfernen. Verwenden Sie dazu den folgenden Befehl
```
sudo -i scontrol delete ReservationName=maint_for_update
```
[Weitere Informationen zur Slurm Reservierung finden Sie im offiziellen SchedMD-Dokument hier.](https://slurm.schedmd.com/reservations.html)
## Cluster-Aktualisierung bei Kapazitätsänderungen
Bei einer Änderung der Scheduler-Konfiguration werden während des Cluster-Aktualisierungsvorgangs die folgenden Schritte ausgeführt:
+ Stoppen AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Generieren Sie die aktualisierte Slurm Partitionskonfiguration anhand der AWS ParallelCluster Konfiguration
+ Neustart `slurmctld` (erfolgt über das Chef-Dienstrezept)
+ `slurmctld`Status überprüfen `(systemctl is-active --quiet slurmctld.service)`
+ Konfiguration neu laden Slurm `(scontrol reconfigure)`
+ `clustermgtd (supervisorctl start clustermgtd)` starten
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). [Den Quellcode finden Sie unter slurm. https://github.com/SchedMD/](https://github.com/SchedMD/slurm)
## Unterstützte Cluster- und SLURM-Versionen
In der folgenden Tabelle sind die AWS ParallelCluster Slurm Versionen aufgeführt, die AWS unterstützt werden.
| AWS ParallelCluster Version (en) | Unterstützte Slurm-Version |
| --- | --- |
| 3.13.0 | 24.05.07 |
| 3.12.0 | 23.11.10 |
| 3.11.0 | 23.11.10 |
| 3.9.2, 3.9.3, 3.10.0 | 23,11,7 |
| 3,9,0, 3,9,1 | 23,11,4 |
| 3.8.0 | 23.02,7 |
| 3.7.2 | 23.02,6 |
| 3.7.1 | 23,02,5 |
| 3.7.0 | 23,02,4 |
| 3.6.0, 3.6.1 | 23,02,2 |
| 3,5.0, 3,5.1 | 22.05.8 |
| 3,4,0, 3,4,1 | 22.05.7 |
| 3.3.0, 3.3.1 | 22.05.5 |
| 3.1.4, 3.1.5, 3.2.0, 3.2.1 | 21.08.8-2 |
| 3.1.2, 3.1.3 | 21,08,6 |
| 3.1.1 | 21,08,5 |
| 3.0.0 | 20,11,8 |
**Topics**
+ [Größe und Aktualisierung der Clusterkapazität](#cluster-capacity-size-and-update)
+ [Aktualisierung der Clusterkapazität](#cluster-capacity-update)
+ [Überlegungen und Einschränkungen](#considerations-limitations)
+ [Auswirkungen auf die Arbeitsplätze](#impacts-on-jobs)
+ [Cluster-Aktualisierung bei Kapazitätsänderungen](#cluster-update-process)
+ [Unterstützte Cluster- und SLURM-Versionen](#cluster-slurm-version-table)
+ [Konfiguration mehrerer Warteschlangen](configuration-of-multiple-queues-v3.md)
+ [SlurmLeitfaden für den Modus mit mehreren Warteschlangen](multiple-queue-mode-slurm-user-guide-v3.md)
+ [Slurm geschützter Cluster-Modus](slurm-protected-mode-v3.md)
+ [Slurmschneller Cluster-Failover mit unzureichender Kapazität](slurm-short-capacity-fail-mode-v3.md)
+ [Slurm speicherbasierte Terminplanung](slurm-mem-based-scheduling-v3.md)
+ [Zuweisung mehrerer Instanztypen mit Slurm](slurm-multiple-instance-allocation-v3.md)
+ [Cluster-Skalierung für dynamische Knoten](scheduler-node-allocation-v3.md)
+ [SlurmAbrechnung mit AWS ParallelCluster](slurm-accounting-v3.md)
+ [Slurm Anpassung der Konfiguration](slurm-configuration-settings-v3.md)
+ [Slurm und `prolog` `epilog`](slurm-prolog-epilog-v3.md)
+ [Größe und Aktualisierung der Clusterkapazität](slurm-cluster-capacity-size-and-update.md)
# Konfiguration mehrerer Warteschlangen
Mit AWS ParallelCluster Version 3 können Sie mehrere Warteschlangen konfigurieren, indem Sie den Wert [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)auf setzen `slurm` und [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) in der Konfigurationsdatei mehrere Warteschlangen für angeben. In diesem Modus existieren verschiedene Instanztypen gleichzeitig in den Rechenknoten, die im [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) Abschnitt der Konfigurationsdatei angegeben sind. [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)mit unterschiedlichen Instanztypen werden je nach Bedarf für die nach oben oder unten skaliert. [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
Mehrere *Warteschlangen* innerhalb eines einzelnen Clusters werden im Allgemeinen mehreren Clustern vorgezogen, wenn sich die Workloads dieselbe zugrunde liegende Infrastruktur und dieselben Ressourcen (wie gemeinsam genutzter Speicher, Netzwerk oder Anmeldeknoten) teilen. Wenn Workloads ähnliche Rechen-, Speicher- und Netzwerkanforderungen haben, ist die Verwendung mehrerer Warteschlangen innerhalb eines einzelnen Clusters effizienter, da sie die gemeinsame Nutzung von Ressourcen ermöglicht und unnötige Doppelarbeit vermeidet. Dieser Ansatz vereinfacht die Verwaltung und reduziert den Overhead, während er gleichzeitig eine effiziente Auftragsplanung und Ressourcenzuweisung ermöglicht. Andererseits sollten mehrere *Cluster* verwendet werden, wenn zwischen den Workloads strenge Sicherheits-, Daten- oder betriebliche Isolationsanforderungen bestehen. Wenn Sie beispielsweise Workloads unabhängig voneinander mit unterschiedlichen Zeitplänen, Aktualisierungszyklen oder Zugriffsrichtlinien verwalten und betreiben müssen, sind mehrere Cluster besser geeignet.
**Kontingente für Clusterwarteschlangen und Rechenressourcen**
| Ressource | Kontingent |
| --- | --- |
| [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | 50 Warteschlangen pro Cluster |
| [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 50 Rechenressourcen pro Warteschlange 50 Rechenressourcen pro Cluster |
**Anzahl der Knoten**
Jede Rechenressource in [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)einer Warteschlange muss ein eindeutiges [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name), [`InstanceType`[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType), und haben [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount). [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)und [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)verfügen über Standardwerte, die den Instanzbereich für eine Rechenressource in [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)einer Warteschlange definieren. Sie können auch Ihre eigenen Werte für [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)und angeben [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount). Jede Rechenressource in [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)besteht aus statischen Knoten, die von 1 bis zum Wert von nummeriert sind, [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)und dynamischen Knoten, die vom Wert [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)bis zum Wert von nummeriert sind [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount).
**Beispiel für eine Konfiguration**
Im Folgenden finden Sie ein Beispiel für einen [Scheduling-Abschnitt](Scheduling-v3.md) für eine Cluster-Konfigurationsdatei. In dieser Konfiguration gibt es zwei Warteschlangen [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)mit dem Namen `queue1` und, `queue2` und jede der Warteschlangen hat einen bestimmten Wert. [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
- InstanceType: c4.xlarge
MaxCount: 5
Name: c4xlarge
- Name: queue2
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
```
**Hostnamen**
Die Instances, die in die Compute-Flotte aufgenommen werden, werden dynamisch zugewiesen. Hostnamen werden für jeden Knoten generiert. Standardmäßig AWS ParallelCluster wird das folgende Format des Hostnamens verwendet:
`$HOSTNAME=$QUEUE-$STATDYN-$COMPUTE_RESOURCE-$NODENUM`
+ `$QUEUE`ist der Name der Warteschlange. Wenn der [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)Abschnitt beispielsweise einen Eintrag hat, dessen Wert auf „`queue-name`“ [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Name)gesetzt ist, dann ist „`$QUEUE`“ der Wert „`queue-name`“.
+ `$STATDYN`ist `st` für statische Knoten oder `dy` für dynamische Knoten.
+ `$COMPUTE_RESOURCE`ist der [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)Wert der [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)Rechenressource, die diesem Knoten entspricht.
+ `$NODENUM`ist die Nummer des Knotens. `$NODENUM`liegt zwischen eins (1) und dem Wert von [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)für statische Knoten und zwischen eins (1) und [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)- [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)für dynamische Knoten.
Aus der obigen Beispielkonfigurationsdatei geht hervor, dass ein bestimmter Knoten aus `queue1` einer Rechenressource einen Hostnamen `c5xlarge` hat:`queue1-dy-c5xlarge-1`.
Sowohl Hostnamen als auch vollqualifizierte Domainnamen (FQDN) werden mithilfe von Amazon Route 53-Hosting-Zonen erstellt. Der FQDN ist`$HOSTNAME.$CLUSTERNAME.pcluster`, wo der Name des `$CLUSTERNAME` Clusters steht.
Beachten Sie, dass dasselbe Format auch für die Slurm Knotennamen verwendet wird.
Benutzer können wählen, ob sie den EC2 Amazon-Standardhostnamen der Instance verwenden möchten, die den Rechenknoten antreibt, anstatt das standardmäßige Hostnamenformat, das von verwendet wird. AWS ParallelCluster Dies kann erreicht werden, indem der [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames)Parameter auf true gesetzt wird. Für Slurm Knotennamen wird jedoch weiterhin das AWS ParallelCluster Standardformat verwendet.
# SlurmLeitfaden für den Modus mit mehreren Warteschlangen
Hier erfahren Sie, wie AWS ParallelCluster und wie Sie Warteschlangenknoten (Partitionsknoten) Slurm verwalten und wie Sie die Warteschlangen- und Knotenstatus überwachen können.
## -Übersicht
Die 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 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 unterstützen keine EC2-Instances den Knoten. 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` Ein Knoten wechselt automatisch in einen `POWER_UP` Status, wenn er einem Knoten in einem Status einen Job Slurm zuweist. `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-Instances werden gestartet und konfiguriert und der Knoten wechselt in den Status. `POWER_UP`
+ **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.
Als allgemeine Regel empfehlen wir, dass die Anzahl der Amazon EC2 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` Status danach. [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) Im Gegensatz dazu werden statische Knoten in den meisten Fällen nicht ausgeschaltet. 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 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)werden.
Die [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 unterstützenden Instanzen beendet werden.
Betrachten Sie die Knotenstatus, die im folgenden `sinfo` Beispiel gezeigt werden.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 idle% gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2]
ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
Für die `efa-st-efacompute1-1` Knoten `spot-st-spotcompute2-[1-2]` und sind bereits Backing-Instances eingerichtet, sodass sie verwendet werden können. Die `ondemand-dy-ondemandcompute1-[1-2]` Knoten befinden sich im `POWER_UP` Status und sollten innerhalb weniger Minuten verfügbar sein. Der `gpu-dy-gpucompute1-1` Knoten befindet sich im `POWER_DOWN` Status und geht danach in den `POWER_SAVING` Status über [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)(standardmäßig 10 Minuten).
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 Amazon EC2 EC2-Instance unterstützt. Standardmäßig kann der Knotenname verwendet werden, um per SSH direkt auf die Instance zuzugreifen (zum Beispiel`ssh efa-st-efacompute1-1`). Die private IP-Adresse der Instanz kann mit dem folgenden Befehl abgerufen werden:
```
$ scontrol show nodes nodename
```
Suchen Sie im zurückgegebenen `NodeAddr` Feld nach der IP-Adresse.
Bei Knoten, die nicht verfügbar sind, sollte das `NodeAddr` Feld nicht auf eine laufende Amazon EC2 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 auch 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 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 Partition in bezeichnetSlurm) weitergeleitet. 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 die Funktionen für einen bestimmten Knoten mit dem folgenden Befehl anzeigen:
```
$ scontrol show nodes nodename
```
Überprüfen Sie im Gegenzug die `AvailableFeatures` Liste.
Betrachten Sie den Anfangsstatus 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-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10]
ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[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 in der `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
```
Berücksichtigen Sie 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-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1
7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1
8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-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 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-efacompute1-[2-4]
efa up infinite 1 mix efa-dy-efacompute1-1
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 mix~ gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 1 mix spot-st-spotcompute2-1
spot* up infinite 1 idle spot-st-spotcompute2-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-v3.md#clustermgtd-v3).
## 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 update-compute-fleet
+ **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
```
Wenn `update-compute-fleet` es ausgeführt wird, können Sie den Status des Clusters überprüfen, indem Sie den `pcluster describe-compute-fleet` Befehl ausführen und das überprüfen`Status`. Im Folgenden werden mögliche Status aufgeführt:
+ `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 Vorgang`update-compute-fleet`, um die Flotte erneut zu aktivieren.
## 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. Mithilfe des `scontrol` Befehls können Sie Knoten in einem Cluster mithilfe der folgenden gängigen Verfahren verwalten.
+ **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 Slurm darauf verlassen, dass die erforderliche Anzahl von Knoten eingeschaltet wird.
+ **Schalten Sie dynamische Knoten vorher aus [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 wird davon abgeraten, Knoten `POWER_DOWN` direkt mithilfe des Befehls so einzustellen, dass sie aktiviert werden. `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
```
## 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-spotcompute1-[1-2]`).
+ `ResumeProgram`startet zwei Amazon EC2 EC2-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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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.
+ `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 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]`
+ `ResumeProgram`startet nur eine (1) Amazon EC2 EC2-Instance und konfiguriert`queue1-dy-spotcompute1-1`, bei der eine (1) Instance nicht gestartet werden kann. `queue1-dy-spotcompute1-2`
+ `queue1-dy-spotcompute1-1`ist nicht betroffen und geht online, nachdem der Status erreicht wurde. `POWER_UP`
+ `queue1-dy-spotcompute1-2`wechselt in den `POWER_DOWN` Status, und der Job wird automatisch in die Warteschlange gestellt, da ein Knotenausfall Slurm erkannt wird.
+ `queue1-dy-spotcompute1-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 30 Minuten)**: `ResumeTimeout` Steuert die Slurm Wartezeit, bis der Knoten in den ausgefallenen Zustand versetzt wird.
+ Eine Verlängerung kann nützlich sein, `ResumeTimeout` wenn der pre/post Installationsvorgang fast so lange dauert.
+ `ResumeTimeout`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. 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 häufiger versuchen Slurm können, Instances zu starten.
+ Länger `SuspendTimeout` bedeutet, dass ausgefallene Knoten langsamer zurückgesetzt werden. SlurmVersucht in der Zwischenzeit, 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 wenn sie versuchen, häufig fehlgeschlagene Jobs 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.
## Protokolle für die Architektur
Die folgende Liste enthält die wichtigsten Protokolle. Der mit Amazon CloudWatch Logs verwendete Protokollstreamname hat das Format`{hostname}.{instance_id}.{logIdentifier}`, in dem die Protokollnamen *logIdentifier* folgen.
+ `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:
+ 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 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 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, die unerwartet ersetzt oder beendet wurden, und 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, in der der Grund für die Aktion angegeben ist. 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 Amazon EC2 zusammenhängt, verwenden Sie Tools wie Amazon CloudWatch oder die Amazon EC2 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 die Instance geplante Ereignisse hatte oder die Amazon EC2 EC2-Integritätsprüfungen nicht bestanden hat.
+ 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 beurteilen 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 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 abgeschlossen`clustermgtd`. Slurmübergibt Knoten nach `IDLE` danach`SuspendTimeout`.
**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 Skalierungsentscheidung suchen Sie im `slurmctld` Protokoll nach Fehlern.
# Slurm geschützter Cluster-Modus
Wenn ein Cluster mit aktiviertem geschützten Modus ausgeführt wird, AWS ParallelCluster überwacht und verfolgt die Bootstrap-Fehler von Compute-Knoten, während die Compute-Knoten gestartet werden. Auf diese Weise wird erkannt, ob diese Fehler kontinuierlich auftreten.
Wenn in einer Warteschlange (Partition) Folgendes erkannt wird, wechselt der Cluster in den geschützten Status:
1. Aufeinanderfolgende Bootstrap-Fehler des Compute-Knotens treten kontinuierlich auf, ohne dass der Compute-Knoten erfolgreich gestartet wurde.
1. Die Anzahl der Fehler erreicht einen vordefinierten Schwellenwert.
Wenn der Cluster den Schutzstatus erreicht hat, werden Warteschlangen mit Ausfällen am oder über dem vordefinierten Schwellenwert AWS ParallelCluster deaktiviert.
Slurm Der geschützte Clustermodus wurde in AWS ParallelCluster Version 3.0.0 hinzugefügt.
Sie können den geschützten Modus verwenden, um den Zeit- und Ressourcenaufwand für den Bootstrap-Fehlerzyklus von Compute-Knoten zu reduzieren.
## Parameter für den geschützten Modus
**`protected_failure_count`**
`protected_failure_count`gibt die Anzahl aufeinanderfolgender Fehler in einer Warteschlange (Partition) an, die den Cluster-Schutzstatus aktivieren.
Die Standardeinstellung `protected_failure_count` ist 10 und der geschützte Modus ist aktiviert.
Wenn `protected_failure_count` der Wert größer als Null ist, ist der geschützte Modus aktiviert.
Wenn kleiner oder gleich Null `protected_failure_count` ist, ist der geschützte Modus deaktiviert.
Sie können den `protected_failure_count` Wert ändern, indem Sie den Parameter in der `clustermgtd` Konfigurationsdatei hinzufügen, die sich unter `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` befindet`HeadNode`.
Sie können diesen Parameter jederzeit aktualisieren und müssen dafür nicht die Rechenflotte anhalten. Wenn ein Start in einer Warteschlange erfolgreich ist, bevor die Anzahl der Fehler erreicht ist`protected_failure_count`, wird die Anzahl der Fehler auf Null zurückgesetzt.
## Überprüfen Sie den Clusterstatus im geschützten Status
Wenn sich ein Cluster im geschützten Status befindet, können Sie den Status der Rechenflotte und den Knotenstatus überprüfen.
### Den Flottenstatus berechnen
Der Status der Rechenflotte befindet sich `PROTECTED` in einem Cluster, der im geschützten Status ausgeführt wird.
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### Status des Knotens
Um zu erfahren, in welchen Warteschlangen (Partitionen) Bootstrap-Fehler aufgetreten sind, für die der Schutzstatus aktiviert wurde, melden Sie sich beim Cluster an und führen Sie den `sinfo` Befehl aus. Partitionen mit Bootstrap-Fehlern auf oder höher `protected_failure_count` befinden sich im Status. `INACTIVE` Partitionen ohne Bootstrap-Fehler bei oder höher `protected_failure_count` befinden sich im `UP` Status und funktionieren erwartungsgemäß.
`PROTECTED`Der Status hat keinen Einfluss auf laufende Jobs. Wenn Jobs auf einer Partition mit Bootstrap-Fehlern bei oder höher ausgeführt werden`protected_failure_count`, wird die Partition `INACTIVE` nach Abschluss der laufenden Jobs auf den Wert gesetzt.
Betrachten Sie die Knotenstatus, die im folgenden Beispiel gezeigt werden.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
`queue1`Die Partition liegt `INACTIVE` daran, dass 10 aufeinanderfolgende Bootstrap-Fehler beim Compute-Knoten-Bootstrap erkannt wurden.
Instanzen hinter den Knoten `queue1-dy-c5xlarge-[1-10]` wurden gestartet, konnten aber aufgrund eines fehlerhaften Status nicht dem Cluster beitreten.
Der Cluster befindet sich im geschützten Status.
`queue2`Die Partition ist von den Bootstrap-Fehlern in nicht betroffen. `queue1` Sie befindet sich im `UP` Status und kann weiterhin Jobs ausführen.
## Wie deaktiviere ich den geschützten Status
Nachdem der Bootstrap-Fehler behoben wurde, können Sie den folgenden Befehl ausführen, um den Schutzstatus des Clusters zu beenden.
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## Bootstrap-Fehler, die den geschützten Status aktivieren
Bootstrap-Fehler, die den geschützten Status aktivieren, werden in die folgenden drei Typen unterteilt. Um den Typ und das Problem zu identifizieren, können Sie überprüfen, ob Protokolle AWS ParallelCluster generiert wurden. Wenn Protokolle generiert wurden, können Sie sie auf Fehlerdetails überprüfen. Weitere Informationen finden Sie unter [Protokolle abrufen und aufbewahren](troubleshooting-v3-get-logs.md).
1. **Bootstrap-Fehler, der dazu führt, dass sich eine Instanz selbst beendet**.
Eine Instanz schlägt zu Beginn des Bootstrap-Prozesses fehl, z. B. eine Instanz, die sich aufgrund von Fehlern im\$1\$1 \$1 -Skript selbst beendet. [`SlurmQueues`[`CustomActions`[`OnNodeStart`[`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured)](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
Suchen Sie bei dynamischen Knoten nach Fehlern, die den folgenden ähneln:
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
Suchen Sie bei statischen Knoten im `clustermgtd` Log (`/var/log/parallelcluster/clustermgtd`) nach Fehlern, die den folgenden ähneln:
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. **Knoten `resume_timeout` oder `node_replacement_timeout` läuft ab**.
Eine Instanz kann dem Cluster nicht innerhalb des `resume_timeout` (für dynamische Knoten) oder `node_replacement_timeout` (für statische Knoten) beitreten. Sie beendet sich vor dem Timeout nicht selbst. Beispielsweise ist das Netzwerk für den Cluster nicht korrekt eingerichtet und der Knoten ist auf den `DOWN` Status von gesetzt Slurm nach Ablauf des Timeouts.
Suchen Sie bei dynamischen Knoten nach Fehlern, die den folgenden ähneln:
```
Node bootstrap error: Resume timeout expires for node
```
Suchen Sie bei statischen Knoten im `clustermgtd` Log (`/var/log/parallelcluster/clustermgtd`) nach Fehlern, die den folgenden ähneln:
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. Die **Zustandsprüfung der Knoten schlägt fehl**.
Eine Instance hinter dem Knoten besteht eine EC2 Amazon-Zustandsprüfung oder eine Zustandsprüfung für geplante Ereignisse nicht, und die Knoten werden als Bootstrap-Ausfallknoten behandelt. In diesem Fall wird die Instance aus einem Grund beendet, auf den sie keinen Einfluss hat. AWS ParallelCluster
Suchen Sie im `clustermgtd` Protokoll (`/var/log/parallelcluster/clustermgtd`) nach Fehlern, die den folgenden ähneln:
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. **Rechenknoten schlagen fehl Slurm Registrierung**.
Die Registrierung des `slurmd` Daemons bei Slurm control daemon (`slurmctld`) schlägt fehl und bewirkt, dass der Status des Compute-Knotens in den `INVALID_REG` Status wechselt. Falsch konfiguriert Slurm Rechenknoten können diesen Fehler verursachen, z. B. berechnete Knoten, bei denen Fehler bei der Spezifikation der [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)Rechenknoten vorliegen.
Suchen Sie in der `slurmctld` Protokolldatei (`/var/log/slurmctld.log`) auf dem Hauptknoten oder in der `slurmd` Protokolldatei (`/var/log/slurmd.log`) des ausgefallenen Rechenknotens nach Fehlern, die den folgenden ähneln:
```
Setting node %s to INVAL with reason: ...
```
## Wie debuggt man den geschützten Modus
Wenn sich Ihr Cluster im geschützten Status befindet und `clustermgtd` Protokolle aus den `HeadNode` und den `cloud-init-output` Protokollen problematischer Rechenknoten AWS ParallelCluster generiert wurden, können Sie die Protokolle auf Fehlerdetails überprüfen. Weitere Informationen zum Abrufen von Protokollen finden Sie unter[Protokolle abrufen und aufbewahren](troubleshooting-v3-get-logs.md).
**`clustermgtd`log (`/var/log/parallelcluster/clustermgtd`) auf dem Hauptknoten**
Protokollmeldungen zeigen, auf welchen Partitionen Bootstrap-Fehler aufgetreten sind und wie viele Bootstrap-Fehler es gibt.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
Suchen `clustermgtd` Sie im Protokoll nach, für `Found the following bootstrap failure nodes` welchen Knoten das Bootstrap fehlgeschlagen ist.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
Suchen `clustermgtd` Sie im Protokoll nach, `Node bootstrap error` um den Grund für den Fehler zu ermitteln.
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
**`cloud-init-output`log (`/var/log/cloud-init-output.log`) auf den Rechenknoten**
Nachdem Sie die private IP-Adresse des Bootstrap-Fehlerknotens im `clustermgtd` Protokoll abgerufen haben, können Sie das entsprechende Rechenknotenprotokoll finden, indem Sie sich entweder beim Rechenknoten anmelden oder den Anweisungen unter Logs abrufen folgen. [Protokolle abrufen und aufbewahren](troubleshooting-v3-get-logs.md) In den meisten Fällen zeigt das `/var/log/cloud-init-output` Protokoll des problematischen Knotens den Schritt, der den Bootstrap-Fehler des Compute-Knotens verursacht hat.
# Slurmschneller Cluster-Failover mit unzureichender Kapazität
Ab AWS ParallelCluster Version 3.2.0 werden Cluster standardmäßig mit aktiviertem Failover-Modus für schnelle unzureichende Kapazität ausgeführt. Dadurch wird der Zeitaufwand für den erneuten Versuch, einen Job in die Warteschlange zu stellen, minimiert, wenn Amazon EC2 EC2-Fehler mit unzureichender Kapazität erkannt werden. Dies ist besonders effektiv, wenn Sie Ihre Warteschlange mit mehreren Rechenressourcen konfigurieren, die unterschiedliche Instance-Typen verwenden.
**Amazon EC2 hat unzureichende Kapazitätsausfälle festgestellt:**
+ `InsufficientInstanceCapacity`
+ `InsufficientHostCapacity`
+ `InsufficientReservedInstanceCapacity`
+ `MaxSpotInstanceCountExceeded`
+ `SpotMaxPriceTooLow`: Aktiviert, wenn der Preis für Spot-Anfragen unter dem erforderlichen Mindestpreis für die Erfüllung von Spot-Anfragen liegt.
+ `Unsupported`: Wird bei Verwendung eines Instance-Typs aktiviert, der in einem bestimmten Fall nicht unterstützt wird AWS-Region.
Wenn im schnellen Failure-Over-Modus für unzureichende Kapazität ein Fehler mit unzureichender Kapazität erkannt wird, wenn ein Job einem [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/zugewiesen wird [`compute resource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources), wird Folgendes AWS ParallelCluster ausgeführt:
1. Dadurch wird die Rechenressource für einen vordefinierten Zeitraum in den Status „Deaktiviert“ (`DOWN`) versetzt.
1. Es wird verwendet`POWER_DOWN_FORCE`, um die fehlerhaften Knotenaufträge der Rechenressource abzubrechen und den fehlerhaften Knoten anzuhalten. Es setzt den fehlerhaften Knoten auf den `POWER_DOWN (!)` Status `IDLE` und dann auf`POWERING_DOWN (%)`.
1. Der Job wird an eine andere Rechenressource weitergeleitet.
Die statischen und eingeschalteten Knoten der deaktivierten Rechenressource sind nicht betroffen. Jobs können auf diesen Knoten abgeschlossen werden.
Dieser Zyklus wiederholt sich, bis der Job erfolgreich einem oder mehreren Rechenressourcenknoten zugewiesen wurde. Informationen zu den Knotenstatus finden Sie unter[SlurmLeitfaden für den Modus mit mehreren Warteschlangen](multiple-queue-mode-slurm-user-guide-v3.md).
Wenn keine Rechenressourcen für die Ausführung des Jobs gefunden werden, wird der Job so lange auf den `PENDING` Status gesetzt, bis der vordefinierte Zeitraum abgelaufen ist. In diesem Fall können Sie den vordefinierten Zeitraum wie im folgenden Abschnitt beschrieben ändern.
## Timeout-Parameter für unzureichende Kapazität
**`insufficient_capacity_timeout`**
`insufficient_capacity_timeout`gibt den Zeitraum (in Sekunden) an, für den die Rechenressource im Status Deaktiviert (`down`) gehalten wird, wenn ein Fehler mit unzureichender Kapazität erkannt wird.
`insufficient_capacity_timeout`Ist standardmäßig aktiviert.
Die Standardeinstellung `insufficient_capacity_timeout` ist 600 Sekunden (10 Minuten).
Wenn der `insufficient_capacity_timeout` Wert kleiner oder gleich Null ist, ist der Failover-Modus für schnelle unzureichende Kapazität deaktiviert.
Sie können den `insufficient_capacity_timeout` Wert ändern, indem Sie den Parameter in der `clustermgtd` Konfigurationsdatei unter `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` hinzufügen. `HeadNode`
Der Parameter kann jederzeit aktualisiert werden, ohne dass die Rechenflotte angehalten wird.
Beispiel:
+ `insufficient_capacity_timeout=600`:
Wenn ein Fehler mit unzureichender Kapazität festgestellt wird, wird die Rechenressource auf deaktiviert (`DOWN`) gesetzt. Nach 10 Minuten wird der ausgefallene Knoten auf den Status `idle~` (`POWER_SAVING`) gesetzt.
+ `insufficient_capacity_timeout=60`:
Wenn ein Fehler mit unzureichender Kapazität erkannt wird, ist die Rechenressource deaktiviert (`DOWN`). Nach einer Minute wird der ausgefallene Knoten in den `idle~` Status versetzt.
+ `insufficient_capacity_timeout=0`:
Der Failover-Modus für schnelle unzureichende Kapazität ist deaktiviert. Die Rechenressource ist nicht deaktiviert.
**Anmerkung**
Zwischen dem Zeitpunkt, an dem Knoten aufgrund unzureichender Kapazität ausfallen, und dem Zeitpunkt, an dem der Clusterverwaltungs-Daemon die Knotenausfälle erkennt, kann es zu einer Verzögerung von bis zu einer Minute kommen. Dies liegt daran, dass der Clusterverwaltungs-Daemon nach Ausfällen mit unzureichender Knotenkapazität sucht und die Rechenressourcen in Abständen von einer Minute auf den `down` Status zurücksetzt.
## Status des Failover-Modus „Schnell“ bei unzureichender Kapazität
Wenn sich ein Cluster im Failover-Modus für schnelle unzureichende Kapazität befindet, können Sie seinen Status und seinen Knotenstatus überprüfen.
### Knotenstatus
Wenn ein Job an einen dynamischen Knoten für Rechenressourcen gesendet wird und ein Fehler mit unzureichender Kapazität festgestellt wird, wird der Knoten in den `down#` Status mit begründetem Status versetzt.
```
(Code:InsufficientInstanceCapacity)Failure when resuming nodes.
```
Dann werden die ausgeschalteten Knoten (Knoten im `idle~` Status) `down~` mit gutem Grund auf ausgeschaltet gesetzt.
```
(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity.
```
Der Job wird für andere Rechenressourcen in der Warteschlange in die Warteschlange eingereiht.
Statische Knoten der Rechenressource und Knoten, die `UP` nicht vom Failover-Modus mit schneller unzureichender Kapazität betroffen sind.
Betrachten Sie die im folgenden Beispiel gezeigten Knotenzustände.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Wir senden einen Job an Queue1, für den ein Knoten erforderlich ist.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 1 down# queue1-dy-c-1-1
queue1* up infinite 15 idle~ queue1-dy-c-2-[1-15]
queue1* up infinite 14 down~ queue1-dy-c-1-[2-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
`queue1-dy-c-1-1`Der Knoten wird gestartet, um den Job auszuführen. Die Instance konnte jedoch aufgrund eines Fehlers mit unzureichender Kapazität nicht gestartet werden. `queue1-dy-c-1-1`Der Knoten ist auf eingestellt`down`. Der ausgeschaltete dynamische Knoten innerhalb der Rechenressource (`queue2-dy-c-1`) ist auf gesetzt`down`.
Sie können den Grund für den Knoten mit überprüfen`scontrol show nodes`.
```
$ scontrol show nodes queue1-dy-c-1-1
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Failure when resuming nodes [root@2022-03-10T22:17:50]
$ scontrol show nodes queue1-dy-c-1-2
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity [root@2022-03-10T22:17:50]
```
Der Job wird innerhalb der Rechenressourcen der Warteschlange für einen anderen Instanztyp in die Warteschlange gestellt.
Nach `insufficient_capacity_timeout` Ablauf dieser Frist werden die Knoten in der Rechenressource auf den Status zurückgesetzt. `idle~`
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Nach `insufficient_capacity_timeout` Ablauf der Fristen und dem Zurücksetzen der Knoten in der Rechenressource auf den `idle~` Status weist der Slurm Scheduler den Knoten eine niedrigere Priorität zu. Der Scheduler wählt weiterhin Knoten aus anderen Queue-Rechenressourcen mit höherer Gewichtung aus, sofern nicht einer der folgenden Fälle eintritt:
+ Die Einreichungsanforderungen eines Jobs stimmen mit der wiederhergestellten Rechenressource überein.
+ Es sind keine anderen Rechenressourcen verfügbar, da sie voll ausgelastet sind.
+ `slurmctld`wird neu gestartet.
+ Die AWS ParallelCluster Rechenflotte wird gestoppt und gestartet, um alle Knoten herunterzufahren und hochzufahren.
### Verwandte Protokolle
Protokolle zu Fehlern bei unzureichender Kapazität und zum schnellen Failover-Modus für unzureichende Kapazität finden Sie im Slurm `resume` Protokoll und im `clustermgtd` Protokoll im Hauptknoten.
**Slurm `resume` (`/var/log/parallelcluster/slurm_resume.log`)**
Fehlermeldungen, wenn ein Knoten aufgrund unzureichender Kapazität nicht gestartet werden kann.
```
[slurm_plugin.instance_manager:_launch_ec2_instances] - ERROR - Failed RunInstances request: dcd0c252-90d4-44a7-9c79-ef740f7ecd87
[slurm_plugin.instance_manager:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['queue1-dy-c-1-1']: An error occurred
(InsufficientInstanceCapacity) when calling the RunInstances operation (reached max retries: 1): We currently do not have sufficient p4d.24xlarge capacity in the
Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get p4d.24xlarge capacity by not
specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
```
**Slurm `clustermgtd` (`/var/log/parallelcluster/clustermgtd`)**
Die Rechenressource c-1 in Warteschlange 1 ist aufgrund unzureichender Kapazität deaktiviert.
```
[slurm_plugin.clustermgtd:_reset_timeout_expired_compute_resources] - INFO - The following compute resources are in down state
due to insufficient capacity: {'queue1': {'c-1': ComputeResourceFailureEvent(timestamp=datetime.datetime(2022, 4, 14, 23, 0, 4, 769380, tzinfo=datetime.timezone.utc),
error_code='InsufficientInstanceCapacity')}}, compute resources are reset after insufficient capacity timeout (600 seconds) expired
```
Nach Ablauf des Timeouts für unzureichende Kapazität wird die Rechenressource zurückgesetzt und die Knoten innerhalb der Rechenressourcen werden auf eingestellt. `idle~`
```
[root:_reset_insufficient_capacity_timeout_expired_nodes] - INFO - Reset the following compute resources because insufficient capacity
timeout expired: {'queue1': ['c-1']}
```
# Slurm speicherbasierte Terminplanung
Ab Version 3.2.0 unterstützt AWS ParallelCluster Slurm speicherbasiertes Scheduling mit dem [`SlurmSettings`[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)](Scheduling-v3.md#Scheduling-v3-SlurmSettings)Cluster-Konfigurationsparameter/.
**Anmerkung**
`EnableMemoryBasedScheduling`[Kann ab AWS ParallelCluster Version 3.7.0 aktiviert werden, wenn Sie mehrere Instanztypen in Instances konfigurieren.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Für die AWS ParallelCluster Versionen 3.2.0 bis 3.6. *x*, `EnableMemoryBasedScheduling` kann nicht aktiviert werden, wenn Sie mehrere Instanztypen in [Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) konfigurieren.
**Warnung**
Wenn Sie mehrere Instanztypen in einem angeben Slurm Wenn die Rechenressource in der Warteschlange `EnableMemoryBasedScheduling` aktiviert ist, entspricht der `RealMemory` Wert der Mindestmenge an Arbeitsspeicher, die allen Instance-Typen zur Verfügung steht. Dies kann zu erheblichen Mengen an ungenutztem Speicher führen, wenn Sie Instance-Typen mit sehr unterschiedlichen Speicherkapazitäten angeben.
Mit`EnableMemoryBasedScheduling: true`, dem Slurm Der Scheduler verfolgt die Menge an Speicher, die jeder Job auf jedem Knoten benötigt. Dann ist der Slurm Der Scheduler verwendet diese Informationen, um mehrere Jobs auf demselben Rechenknoten zu planen. Die Gesamtmenge an Speicher, die Jobs auf einem Knoten benötigen, darf nicht größer sein als der verfügbare Knotenspeicher. Der Scheduler verhindert, dass ein Job mehr Speicher beansprucht, als beim Absenden des Jobs angefordert wurde.
Mit `EnableMemoryBasedScheduling: false` können Jobs auf einem gemeinsam genutzten Knoten um Arbeitsspeicher konkurrieren und zu Auftragsfehlern und `out-of-memory` Ereignissen führen.
**Warnung**
Slurm verwendet für seine Bezeichnungen eine Zweierpotenz, z. B. MB oder GB. Lesen Sie diese Labels als MiB bzw. GiB.
## Slurm Konfiguration und speicherbasierte Planung
Mit `EnableMemoryBasedScheduling: true` Slurm legt Folgendes fest Slurm Konfigurationsparameter:
+ [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory) im `slurm.conf`. Diese Option konfiguriert den Knotenspeicher als verbrauchbare Ressource in Slurm.
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)in der Slurm `cgroup.conf`. Mit dieser Option ist der Speicherzugriff eines Jobs auf die Speichermenge beschränkt, die der Job bei der Übermittlung angefordert hat.
**Anmerkung**
Mehrere andere Slurm Konfigurationsparameter können sich auf das Verhalten des auswirken Slurm Scheduler und Ressourcenmanager, wenn diese beiden Optionen festgelegt sind. Weitere Informationen finden Sie hier: [Slurm Dokumentation](https://slurm.schedmd.com/documentation.html).
## Slurm Scheduler und speicherbasierte Planung
**`EnableMemoryBasedScheduling: false`(Standard)**
`EnableMemoryBasedScheduling`ist standardmäßig auf „Falsch“ gesetzt. Wenn falsch, Slurm nimmt Speicher nicht als Ressource in seinen Planungsalgorithmus auf und verfolgt nicht den Speicher, den Jobs verwenden. Benutzer können die `--mem MEM_PER_NODE` Option angeben, um die Mindestmenge an Speicher pro Knoten festzulegen, die ein Job benötigt. Dadurch wird der Scheduler gezwungen, `MEM_PER_NODE` bei der Planung des Jobs Knoten mit einem `RealMemory` Wert von mindestens auszuwählen.
Nehmen wir zum Beispiel an, dass ein Benutzer zwei Jobs mit einreicht. `--mem=5GB` Wenn angeforderte Ressourcen wie CPUs oder verfügbar GPUs sind, können die Jobs gleichzeitig auf einem Knoten mit 8 GiB Arbeitsspeicher ausgeführt werden. Die beiden Jobs sind nicht auf Rechenknoten mit weniger als 5 GiB geplant`RealMemory`.
**Warnung**
Wenn die speicherbasierte Planung deaktiviert ist, Slurm verfolgt nicht die Menge an Speicher, die Jobs verwenden. Jobs, die auf demselben Knoten ausgeführt werden, konkurrieren möglicherweise um Speicherressourcen und führen dazu, dass der andere Job fehlschlägt.
Wenn die speicherbasierte Planung deaktiviert ist, empfehlen wir Benutzern, die Optionen [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu)oder [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu)nicht anzugeben. Diese Optionen können zu einem Verhalten führen, das sich von dem unterscheidet, was in der [Slurm Dokumentation](https://slurm.schedmd.com/documentation.html).
**`EnableMemoryBasedScheduling: true`**
Wann `EnableMemoryBasedScheduling` ist auf true gesetzt, Slurm verfolgt die Speichernutzung der einzelnen Jobs und verhindert, dass Jobs mehr Speicher verwenden, als mit den `--mem` Übermittlungsoptionen angefordert wurde.
Im vorherigen Beispiel sendet ein Benutzer zwei Jobs mit`--mem=5GB`. Die Jobs können nicht gleichzeitig auf einem Knoten mit 8 GiB Arbeitsspeicher ausgeführt werden. Das liegt daran, dass die insgesamt benötigte Speichermenge größer ist als der auf dem Knoten verfügbare Speicher.
Wenn die speicherbasierte Planung aktiviert ist, `--mem-per-cpu` `--mem-per-gpu` verhalten Sie sich konsistent mit den Anweisungen in Slurm -Dokumentation. Zum Beispiel wird ein Job mit eingereicht. `--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB` In diesem Fall Slurm weist dem Job insgesamt 4 GiB für jeden Knoten zu.
**Warnung**
Wenn die speicherbasierte Planung aktiviert ist, empfehlen wir Benutzern, bei der Einreichung eines Jobs eine `--mem` Spezifikation anzugeben. Mit der Standardeinstellung Slurm Konfiguration, die in enthalten ist AWS ParallelCluster, falls keine Speicheroption enthalten ist (`--mem`,`--mem-per-cpu`, oder`--mem-per-gpu`), Slurm weist dem Job den gesamten Speicher der zugewiesenen Knoten zu, auch wenn er nur einen Teil der anderen Ressourcen anfordert, z. B. CPUs oder GPUs. Dadurch wird die gemeinsame Nutzung von Knoten effektiv verhindert, bis der Job abgeschlossen ist, da kein Speicher für andere Jobs verfügbar ist. Das passiert, weil Slurm legt den Speicher pro Knoten für den Job auf den Wert fest, [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)wenn zum Zeitpunkt der Auftragsübergabe keine Speicherspezifikationen angegeben wurden. Der Standardwert für diesen Parameter ist 0 und gibt unbegrenzten Zugriff auf den Speicher eines Knotens an.
Wenn mehrere Typen von Rechenressourcen mit unterschiedlichen Speichermengen in derselben Warteschlange verfügbar sind, werden einem ohne Speicheroptionen eingereichten Job möglicherweise unterschiedliche Speichermengen auf verschiedenen Knoten zugewiesen. Das hängt davon ab, welche Knoten der Scheduler für den Job zur Verfügung stellt. Benutzer können einen benutzerdefinierten Wert für Optionen wie `DefMemPerNode` oder auf Cluster [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU)- oder Partitionsebene in der Slurm Konfigurationsdateien, um dieses Verhalten zu verhindern.
## Slurm RealMemory und AWS ParallelCluster SchedulableMemory
Mit dem Slurm Konfiguration, die mitgeliefert wird AWS ParallelCluster, Slurm wird als die Menge an Speicher pro Knoten interpretiert [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory), die für Jobs verfügbar ist. Ab Version 3.2.0 sind standardmäßig 95 Prozent des Speichers AWS ParallelCluster festgelegt`RealMemory`, der in [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types) aufgeführt und von der EC2 Amazon-API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)zurückgegeben wird.
Wenn die speicherbasierte Planung deaktiviert ist, Slurm Scheduler filtert Knoten`RealMemory`, wenn Benutzer einen Job mit den angegebenen Werten einreichen. `--mem`
Wenn die speicherbasierte Planung aktiviert ist, Slurm Der Scheduler interpretiert dies als `RealMemory` die maximale Speichermenge, die für Jobs verfügbar ist, die auf dem Rechenknoten ausgeführt werden.
Die Standardeinstellung ist möglicherweise nicht für alle Instance-Typen optimal:
+ Diese Einstellung ist möglicherweise höher als die Speichermenge, auf die Knoten tatsächlich zugreifen können. Dies kann passieren, wenn es sich bei den Rechenknoten um kleine Instance-Typen handelt.
+ Diese Einstellung ist möglicherweise niedriger als die Speichermenge, auf die Knoten tatsächlich zugreifen können. Dies kann passieren, wenn es sich bei Rechenknoten um große Instance-Typen handelt, und kann zu einer erheblichen Menge an ungenutztem Speicher führen.
Sie können [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/verwenden [`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory), um den Wert von `RealMemory` configured by AWS ParallelCluster für Compute-Knoten zu optimieren. Um den Standardwert zu überschreiben, definieren Sie einen benutzerdefinierten Wert `SchedulableMemory` speziell für Ihre Clusterkonfiguration.
Um den tatsächlich verfügbaren Speicher eines Rechenknotens zu überprüfen, führen Sie den `/opt/slurm/sbin/slurmd -C` Befehl auf dem Knoten aus. Dieser Befehl gibt die Hardwarekonfiguration des Knotens einschließlich des [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)Werts zurück. Weitere Informationen finden Sie unter [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C).
Stellen Sie sicher, dass die Betriebssystemprozesse des Rechenknotens über ausreichend Arbeitsspeicher verfügen. Beschränken Sie dazu den für Jobs verfügbaren Speicher, indem Sie den `SchedulableMemory` Wert auf einen niedrigeren Wert als den vom `slurmd -C` Befehl zurückgegebenen `RealMemory` Wert setzen.
# Zuweisung mehrerer Instanztypen mit Slurm
Ab AWS ParallelCluster Version 3.3.0 können Sie Ihren Cluster so konfigurieren, dass er aus dem Satz definierter Instanztypen einer Rechenressource zuweist. Die Zuteilung kann auf der Grundlage kostengünstiger oder optimaler Kapazitätsstrategien für EC2 Amazon-Flotten erfolgen.
Dieser Satz definierter Instance-Typen muss entweder alle dieselbe Anzahl von v CPUs oder, falls Multithreading deaktiviert ist, dieselbe Anzahl von Kernen haben. Darüber hinaus muss dieser Satz von Instance-Typen dieselbe Anzahl von Beschleunigern derselben Hersteller haben. Wenn [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa)/auf gesetzt [`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa-Enabled)ist`true`, muss EFA für die Instances unterstützt werden. Weitere Informationen und Anforderungen finden Sie unter [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)und [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Sie können `capacity-optimized` je nach [CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType)Konfiguration auf `lowest-price` oder einstellen [`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy).
[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)In können Sie eine Reihe von Instanztypen konfigurieren.
**Anmerkung**
Ab AWS ParallelCluster Version 3.7.0 `EnableMemoryBasedScheduling` kann aktiviert werden, wenn Sie mehrere Instanztypen in [Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) konfigurieren.
Für die AWS ParallelCluster Versionen 3.2.0 bis 3.6. *x*, `EnableMemoryBasedScheduling` kann nicht aktiviert werden, wenn Sie mehrere Instanztypen in [Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) konfigurieren.
Die folgenden Beispiele zeigen, wie Sie Instance-Typen nach VCPUs, EFA-Unterstützung und Architektur abfragen können.
Abfrage InstanceTypes mit 96 v CPUs - und x86\$164-Architektur.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-vcpus,Values=96" "Name=processor-info.supported-architecture,Values=x86_64" \
--query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
Abfrage InstanceTypes mit 64 Kernen, EFA-Unterstützung und arm64-Architektur.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-cores,Values=64" "Name=processor-info.supported-architecture,Values=arm64" "Name=network-info.efa-supported,Values=true" --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
Das nächste Beispiel für eine Cluster-Konfiguration zeigt, wie Sie diese verwenden können InstanceType and AllocationStrategy Eigenschaften.
```
...
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-1
CapacityType: ONDEMAND
AllocationStrategy: lowest-price
...
ComputeResources:
- Name: computeresource1
Instances:
- InstanceType: r6g.2xlarge
- InstanceType: m6g.2xlarge
- InstanceType: c6g.2xlarge
MinCount: 0
MaxCount: 500
- Name: computeresource2
Instances:
- InstanceType: m6g.12xlarge
- InstanceType: x2gd.12xlarge
MinCount: 0
MaxCount: 500
...
```
# Cluster-Skalierung für dynamische Knoten
ParallelCluster unterstützt Slurm die Methoden zur dynamischen Skalierung von Clustern mithilfe Slurm des Power Saver-Plugins. Weitere Informationen finden Sie im [Cloud Scheduling Guide](https://slurm.schedmd.com/elastic_computing.html) und im [SlurmPower Saving Guide](https://slurm.schedmd.com/power_save.html) in der Slurm Dokumentation. In den folgenden Themen werden die Slurm Strategien für die einzelnen Versionen beschrieben.
**Topics**
+ [SlurmStrategien zur dynamischen Knotenzuweisung in Version 3.8.0](scheduler-node-allocation-v3-3.8.0.md)
+ [SlurmStrategien zur dynamischen Knotenzuweisung in Version 3.7.x](scheduler-dynamic-node-allocation-v3-3.7.x.md)
+ [SlurmStrategien zur dynamischen Knotenzuweisung in Version 3.6.x und früheren Versionen](scheduler-dynamic-node-allocation-v3-3.6.x.md)
# SlurmStrategien zur dynamischen Knotenzuweisung in Version 3.8.0
Ab ParallelCluster Version 3.8.0 wird die **Wiederaufnahme auf Jobebene** oder die **Skalierung auf Jobebene** als Standardstrategie für die dynamische Knotenzuweisung ParallelCluster verwendet, um den Cluster zu skalieren: ParallelCluster skaliert den Cluster auf der Grundlage der Anforderungen jedes Jobs, der Anzahl der dem Job zugewiesenen Knoten und der Knoten, die wieder aufgenommen werden müssen. ParallelCluster ruft diese Informationen aus der Umgebungsvariablen SLURM\$1RESUME\$1FILE ab.
Die Skalierung für dynamische Knoten ist ein zweistufiger Prozess, der den Start der EC2-Instances und die Zuweisung der gestarteten Amazon EC2 EC2-Instances zu den Slurm Knoten beinhaltet. Jeder dieser beiden Schritte kann mithilfe einer Logik **all-or-nothing**oder einer **Best-Effort-Logik** ausgeführt werden.
Für den Start der Amazon EC2 EC2-Instances:
+ **all-or-nothing**ruft die Amazon EC2 EC2-Launch-API auf, wobei das Mindestziel der Gesamtzielkapazität entspricht
+ **Best-Effort** ruft die Amazon EC2 EC2-API zum Starten auf, wobei das Mindestziel 1 und die Gesamtzielkapazität der angeforderten Kapazität entspricht
Für die Zuweisung der Amazon EC2 EC2-Instances zu Slurm Knoten:
+ **all-or-nothing**weist Amazon EC2 EC2-Instances Slurm Knoten nur zu, wenn es möglich ist, jedem angeforderten Knoten eine Amazon EC2 EC2-Instance zuzuweisen
+ **Best-Effort** weist Amazon EC2 EC2-Instances Slurm Knoten zu, auch wenn nicht alle angeforderten Knoten durch die Amazon EC2 EC2-Instance-Kapazität abgedeckt sind
Die möglichen Kombinationen der oben genannten Strategien spiegeln sich in den Startstrategien wider. ParallelCluster
**Example** [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)
**all-or-nothing**Skalierung:
Diese Strategie beinhaltet das AWS ParallelCluster Initiieren eines Amazon EC2 EC2-Launch-Instance-API-Aufrufs für jeden Job, der alle Instances erfordert, die für den erfolgreichen Start der angeforderten Rechenknoten erforderlich sind. Dadurch wird sichergestellt, dass der Cluster nur skaliert wird, wenn die erforderliche Kapazität pro Job verfügbar ist. Dadurch wird vermieden, dass Instances am Ende des Skalierungsprozesses im Leerlauf verbleiben.
Die Strategie verwendet eine **all-or-nothing**Logik für den Start der Amazon EC2 EC2-Instances für jeden Job sowie eine **all-or-nothing**Logik für die Zuweisung der Amazon EC2 EC2-Instances zu Slurm Knoten.
Die Strategiegruppen starten Anfragen in Batches, eine für jede angeforderte Rechenressource und jeweils bis zu 500 Knoten. Bei Anfragen, die sich über mehrere Rechenressourcen oder mehr als 500 Knoten erstrecken, werden mehrere ParallelCluster Batches nacheinander verarbeitet.
Der Ausfall eines Batches einer einzelnen Ressource führt zur Kündigung der gesamten zugehörigen ungenutzten Kapazität, wodurch sichergestellt wird, dass am Ende des Skalierungsprozesses keine inaktiven Instanzen übrig bleiben.
Einschränkungen
+ Die für die Skalierung benötigte Zeit ist direkt proportional zur Anzahl der Jobs, die pro Ausführung des Slurm Resume-Programms eingereicht wurden.
+ Der Skalierungsvorgang ist durch das RunInstances Ressourcenkontolimit begrenzt, das standardmäßig auf 1000 Instanzen festgelegt ist. Diese Einschränkung entspricht den AWS EC2-API-Drosselungsrichtlinien. Weitere Informationen finden Sie in der [Amazon EC2 EC2-API-Drosselungsdokumentation](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html)
+ Wenn Sie einen Job in einer Rechenressource mit einem einzigen Instance-Typ in einer Warteschlange einreichen, die sich über mehrere Availability Zones erstreckt, ist der **all-or-nothing**EC2-Launch-API-Aufruf nur erfolgreich, wenn die gesamte Kapazität in einer einzigen Availability Zone bereitgestellt werden kann.
+ Wenn Sie einen Job in einer Rechenressource mit mehreren Instance-Typen in einer Warteschlange mit einer einzigen Availability Zone einreichen, ist der **all-or-nothing**Amazon EC2 EC2-Launch-API-Aufruf nur erfolgreich, wenn die gesamte Kapazität von einem einzigen Instance-Typ bereitgestellt werden kann.
+ Wenn Sie einen Job in einer Rechenressource mit mehreren Instance-Typen in einer Warteschlange einreichen, die sich über mehrere Availability Zones erstreckt, wird der **all-or-nothing**Amazon EC2 EC2-Launch-API-Aufruf nicht unterstützt und ParallelCluster führt stattdessen eine Skalierung nach **bestem Wissen durch.**
**greedy-all-or-nothing**Skalierung:
Diese Variante der all-or-nothing Strategie stellt weiterhin sicher, dass der Cluster nur skaliert wird, wenn die erforderliche Kapazität pro Job verfügbar ist, wodurch inaktive Instances am Ende des Skalierungsprozesses vermieden werden. Sie beinhaltet jedoch die ParallelCluster Initiierung eines Amazon EC2 EC2-Launch-Instance-API-Aufrufs, der auf eine Mindestzielkapazität von 1 abzielt und versucht, die Anzahl der gestarteten Knoten bis zur angeforderten Kapazität zu maximieren. Die Strategie verwendet eine Best-Effort-Logik für den Start der EC2-Instances für alle Jobs sowie die **all-or-nothing**Logik für die Zuweisung der Amazon EC2 EC2-Instances zu Slurm Knoten für jeden Job.
Die Strategiegruppen starten Anfragen stapelweise, eine für jede angeforderte Rechenressource und jeweils bis zu 500 Knoten. Bei Anfragen, die sich über mehrere Rechenressourcen oder mehr als 500 Knoten erstrecken, werden mehrere ParellelCluster Batches nacheinander verarbeitet.
Es stellt sicher, dass am Ende des Skalierungsprozesses keine inaktiven Instanzen übrig bleiben, indem der Durchsatz maximiert wird, allerdings auf Kosten einer vorübergehenden Überskalierung während des Skalierungsprozesses.
Einschränkungen
+ Eine vorübergehende Überskalierung ist möglich, was zu zusätzlichen Kosten für Instances führt, die vor Abschluss der Skalierung in den Betriebszustand übergehen.
+ Es gilt das gleiche Instance-Limit wie in der all-or-nothing Strategie, abhängig vom Limit für AWS das RunInstances Ressourcenkonto.
Skalierung nach **bestem Aufwand**:
Diese Strategie ruft den Amazon EC2 EC2-Launch-Instance-API-Aufruf auf, wobei eine Mindestkapazität von 1 angestrebt wird und versucht wird, die angeforderte Gesamtkapazität zu erreichen, wobei inaktive Instances nach der Ausführung des Skalierungsprozesses belassen werden müssen, falls nicht die gesamte angeforderte Kapazität verfügbar ist. Die Strategie verwendet eine Best-Effort-Logik für den Start der Amazon EC2 EC2-Instances für alle Jobs sowie die **Best-Effort-Logik** für die Zuweisung der Amazon EC2 EC2-Instances zu Slurm-Knoten für jeden Job.
Die Strategie gruppiert Anfragen in Batches, eine für jede angeforderte Rechenressource und jeweils bis zu 500 Knoten. Bei Anfragen, die sich über mehrere Rechenressourcen oder mehr als 500 Knoten erstrecken, werden mehrere ParallelCluster Batches nacheinander verarbeitet.
Diese Strategie ermöglicht eine Skalierung weit über das Standardlimit von 1000 Instanzen bei mehreren Ausführungen von Skalierungsprozessen hinaus, allerdings auf Kosten inaktiver Instanzen für die verschiedenen Skalierungsprozesse.
Einschränkungen
+ Mögliche Instances, die am Ende des Skalierungsprozesses im Leerlauf laufen, für den Fall, dass es nicht möglich ist, alle von den Jobs angeforderten Knoten zuzuweisen.
Das folgende Beispiel zeigt, wie sich die Skalierung dynamischer Knoten unter Verwendung der verschiedenen **ParallelCluster Startstrategien** verhält. Angenommen, Sie haben zwei Jobs eingereicht, bei denen jeweils 20 Knoten angefordert wurden, also insgesamt 40 Knoten desselben Typs, aber es sind nur 30 Amazon EC2 EC2-Instances verfügbar, um die angeforderte Kapazität auf EC2 abzudecken.
**all-or-nothing**Skalierung:
+ Für den ersten Job wird eine ** all-or-nothing**Amazon EC2 EC2-Launch-Instance-API aufgerufen, die 20 Instances anfordert. Ein erfolgreicher Aufruf hat zum Start von 20 Instances geführt
+ **all-or-nothing **Die Zuweisung der 20 gestarteten Instances zu Slurm Knoten für den ersten Job ist erfolgreich
+ Eine weitere **all-or-nothing**Amazon EC2 EC2-Launch-Instance-API wird aufgerufen und fordert 20 Instances für den zweiten Job an. Der Aufruf ist nicht erfolgreich, da nur Kapazität für weitere 10 Instances vorhanden ist. Derzeit werden keine Instances gestartet
**greedy-all-or-nothing**Skalierung:
+ Es wird **eine Amazon** EC2 EC2-Launch-Instance-API aufgerufen, die 40 Instances anfordert, was der Gesamtkapazität entspricht, die von allen Jobs angefordert wird. Dies führt zum Start von 30 Instances
+ Eine **all-or-nothing**Zuweisung von 20 der gestarteten Instances zu Slurm Knoten für den ersten Job ist erfolgreich
+ Eine weitere **all-or-nothing**Zuweisung der verbleibenden gestarteten Instances zu Slurm Knoten für den zweiten Job wird versucht, aber da von den insgesamt 20 vom Job angeforderten Instanzen nur 10 verfügbar sind, ist die Zuweisung nicht erfolgreich
+ Die 10 nicht zugewiesenen gestarteten Instances werden beendet
Skalierung nach **bestem Aufwand**:
+ Es wird **eine Amazon** EC2 EC2-Launch-Instance-API aufgerufen, die 40 Instances anfordert, was der Gesamtkapazität entspricht, die von allen Jobs angefordert wird. Dies führt zum Start von 30 Instances.
+ Eine **Best-Effort-Zuweisung** von 20 der gestarteten Instances zu Slurm Knoten für den ersten Job ist erfolgreich.
+ Eine weitere **Best-Effort-Zuweisung** der verbleibenden 10 gestarteten Instances zu Slurm Knoten für den zweiten Job ist erfolgreich, auch wenn die angeforderte Gesamtkapazität 20 betrug. Da der Job jedoch die 20 Knoten anforderte und es möglich war, Amazon EC2 EC2-Instances nur 10 davon zuzuweisen, kann der Job nicht gestartet werden und die Instances laufen im Leerlauf, bis genügend Kapazität gefunden wurde, um die fehlenden 10 Instances bei einem späteren Aufruf des Skalierungsprozesses zu starten, oder der Scheduler plant den Job auf anderen, bereits laufenden Rechenknoten.
# SlurmStrategien zur dynamischen Knotenzuweisung in Version 3.7.x
ParallelCluster verwendet zwei Arten von Strategien zur dynamischen Knotenzuweisung, um den Cluster zu skalieren:
+
**Zuweisung auf der Grundlage verfügbarer angeforderter Knoteninformationen:**
+ **Wiederaufnahme der Skalierung aller Knoten** oder Skalierung der **Knotenliste**:
ParallelCluster skaliert den Cluster nur auf Slurm der Grundlage der angeforderten Knotenlistennamen, wenn er ausgeführt wirdSlurm. `ResumeProgram` Es weist den Knoten Rechenressourcen nur anhand des Knotennamens zu. Die Liste der Knotennamen kann mehrere Jobs umfassen.
+ **Lebenslauf auf Jobebene** oder Skalierung auf **Jobebene**:
ParallelCluster skaliert den Cluster auf der Grundlage der Anforderungen der einzelnen Jobs, der aktuellen Anzahl der Knoten, die dem Job zugewiesen sind, und der Knoten, die wieder aufgenommen werden müssen. ParallelCluster ruft diese Informationen aus der `SLURM_RESUME_FILE` Umgebungsvariablen ab.
+
**Allokation mit einer Amazon EC2 EC2-Startstrategie:**
+ Skalierung nach **bestem Wissen und Gewissen**:
ParallelCluster skaliert den Cluster mithilfe eines Amazon EC2 EC2-Launch-Instance-API-Aufrufs mit einer Mindestzielkapazität von 1, um einige, aber nicht unbedingt alle Instances zu starten, die zur Unterstützung der angeforderten Knoten benötigt werden.
+ **Eine ll-or-nothing** Skalierung:
ParallelCluster skaliert den Cluster mithilfe eines Amazon EC2 EC2-Launch-Instance-API-Aufrufs, der nur erfolgreich ist, wenn alle Instances gestartet werden, die zur Unterstützung der angeforderten Knoten benötigt werden. In diesem Fall ruft es die Amazon EC2 EC2-Launch-Instance-API auf, wobei die minimale Zielkapazität der angeforderten Gesamtkapazität entspricht.
Standardmäßig ParallelCluster verwendet die Skalierung der **Knotenliste** mit einer **Best-Effort-Amazon** EC2-Startstrategie, um einige, aber nicht unbedingt alle Instances zu starten, die zur Unterstützung der angeforderten Knoten benötigt werden. Es versucht, so viel Kapazität wie möglich bereitzustellen, um die eingereichte Arbeitslast zu bedienen.
**Ab ParallelCluster Version 3.7.0 wird die Skalierung **auf Jobebene** mit einer **all-or-nothing**EC2-Startstrategie für Jobs ParallelCluster verwendet, die im exklusiven Modus eingereicht wurden.** Wenn Sie einen Job im exklusiven Modus einreichen, hat der Job exklusiven Zugriff auf die ihm zugewiesenen Knoten. Weitere Informationen finden Sie in der Slurm Dokumentation unter [EXCLUSIVE](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE).
So reichen Sie einen Job im exklusiven Modus ein:
+ Übergeben Sie die Exklusivkennzeichnung, wenn Sie einen Slurm Job an den Cluster senden. Beispiel, `sbatch ... --exclusive`.
ODER
+ Senden Sie einen Job an eine Cluster-Warteschlange, die mit der [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation)Einstellung auf konfiguriert wurde`true`.
Wenn Sie einen Job im exklusiven Modus einreichen:
+ ParallelCluster führt derzeit Batches von Startanfragen mit bis zu 500 Knoten durch. Wenn ein Job mehr als 500 Knoten anfordert, ParallelCluster stellt er eine **all-or-nothing**Startanforderung für jeden Satz von 500 Knoten und eine zusätzliche Startanforderung für die restlichen Knoten.
+ Wenn sich die Knotenzuweisung auf eine einzelne Rechenressource ParallelCluster bezieht, wird eine **all-or-nothing**Startanforderung für jeden Satz von 500 Knoten und eine zusätzliche Startanforderung für die übrigen Knoten gestellt. Schlägt eine Startanfrage fehl, ParallelCluster wird die ungenutzte Kapazität, die durch alle Startanfragen geschaffen wurde, beendet.
+ Wenn sich die Knotenzuweisung über mehrere Rechenressourcen erstreckt, ParallelCluster muss für jede Rechenressource eine **all-or-nothing**Startanforderung gestellt werden. Diese Anfragen werden ebenfalls gebündelt. Wenn eine Startanfrage für eine der Rechenressourcen fehlschlägt, wird die ungenutzte Kapazität ParallelCluster beendet, die durch alle Startanfragen für Rechenressourcen geschaffen wurde.
Skalierung **auf Jobebene** mit bekannten Einschränkungen der **all-or-nothing**Startstrategie:
+ Wenn Sie einen Job in einer Rechenressource mit einem einzigen Instance-Typ in einer Warteschlange einreichen, die sich über mehrere Availability Zones erstreckt, ist der **all-or-nothing**EC2-Start-API-Aufruf nur erfolgreich, wenn die gesamte Kapazität in einer einzigen Availability Zone bereitgestellt werden kann.
+ Wenn Sie einen Job in einer Rechenressource mit mehreren Instance-Typen in einer Warteschlange mit einer einzigen Availability Zone einreichen, ist der **all-or-nothing**Amazon EC2 EC2-Launch-API-Aufruf nur erfolgreich, wenn die gesamte Kapazität von einem einzigen Instance-Typ bereitgestellt werden kann.
+ Wenn Sie einen Job in einer Rechenressource mit mehreren Instance-Typen in einer Warteschlange einreichen, die sich über mehrere Availability Zones erstreckt, wird der **all-or-nothing**Amazon EC2 EC2-Launch-API-Aufruf nicht unterstützt und ParallelCluster führt stattdessen eine Skalierung nach **bestem Wissen durch.**
# SlurmStrategien zur dynamischen Knotenzuweisung in Version 3.6.x und früheren Versionen
AWS ParallelCluster verwendet nur eine Art von Strategie zur dynamischen Knotenzuweisung, um den Cluster zu skalieren:
+ Zuweisung auf der Grundlage verfügbarer angeforderter Knoteninformationen:
+ **Wiederaufnahme aller Knoten** oder Skalierung der **Knotenliste**: ParallelCluster Skaliert den Cluster nur auf Slurm der Grundlage der angeforderten Knotenlistennamen, wenn er ausgeführt wirdSlurm. `ResumeProgram` Rechenressourcen werden Knoten nur anhand des Knotennamens zugewiesen. Die Liste der Knotennamen kann mehrere Jobs umfassen.
+ Allokation mit einer Amazon EC2 EC2-Startstrategie:
+ Skalierung nach **bestem Aufwand**: ParallelCluster Skaliert den Cluster mithilfe eines Amazon EC2 EC2-Launch-Instance-API-Aufrufs mit einer Mindestzielkapazität von 1, um einige, aber nicht unbedingt alle Instances zu starten, die zur Unterstützung der angeforderten Knoten benötigt werden.
ParallelCluster verwendet die Skalierung **der Knotenliste** mit einer **Best-Effort-Amazon** EC2-Startstrategie, um einige, aber nicht unbedingt alle Instances zu starten, die zur Unterstützung der angeforderten Knoten benötigt werden. Es versucht, so viel Kapazität wie möglich bereitzustellen, um die eingereichte Arbeitslast zu bedienen.
Einschränkungen
+ Mögliche Instances, die am Ende des Skalierungsprozesses im Leerlauf laufen, für den Fall, dass es nicht möglich ist, alle von den Jobs angeforderten Knoten zuzuweisen.
# SlurmAbrechnung mit AWS ParallelCluster
AWS ParallelCluster Unterstützt ab Version 3.3.0 die Slurm Abrechnung mit dem Cluster-Konfigurationsparameter [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database).
AWS ParallelCluster Unterstützt ab Version 3.10.0 die Slurm Abrechnung mit einer externen Slurmdbd mit dem Cluster-Konfigurationsparameter/. [SlurmSettings[ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)](Scheduling-v3.md#Scheduling-v3-SlurmSettings) Die Verwendung einer externen Slurmdbd wird empfohlen, wenn sich mehrere Cluster dieselbe Datenbank teilen.
Mit Slurm Accounting können Sie eine externe Buchhaltungsdatenbank integrieren, um Folgendes zu tun:
+ Verwalten Sie Cluster-Benutzer oder Benutzergruppen und andere Entitäten. Mit dieser Funktion können Sie erweiterte Funktionen wie die Durchsetzung Slurm von Ressourcenbeschränkungen, Fair-Share und nutzen. QOSs
+ Erfassen und speichern Sie Auftragsdaten, z. B. den Benutzer, der den Job ausgeführt hat, die Dauer des Jobs und die verwendeten Ressourcen. Sie können die gespeicherten Daten mit dem `sacct` Hilfsprogramm anzeigen.
**Anmerkung**
AWS ParallelCluster unterstützt die Slurm Abrechnung [Slurmunterstützter MySQL-Datenbankserver](https://slurm.schedmd.com/accounting.html#mysql-configuration).
## Arbeiten mit der Slurm Buchhaltung unter Verwendung von External Slurmdbd in AWS ParallelCluster Version 3.10.0 und höher
Bevor Sie die Slurm Kontoführung konfigurieren, müssen Sie über einen vorhandenen externen Slurmdbd Datenbankserver verfügen, der eine Verbindung zu einem vorhandenen externen Datenbankserver herstellt.
Um dies zu konfigurieren, definieren Sie Folgendes:
+ Die Adresse des externen Slurmdbd Servers in [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)/[Host](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ExternalSlurmdbd-Host). Der Server muss existieren und vom Hauptknoten aus erreichbar sein.
+ Der Munge-Schlüssel für die Kommunikation mit dem externen Slurmdbd Server in [MungeKeySecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-MungeKeySecretArn).
Eine schrittweise Anleitung finden Sie unter[Erstellen eines Clusters mit einem externen Slurmdbd Buchhaltung](external-slurmdb-accounting.md).
**Anmerkung**
Sie sind für die Verwaltung der Slurm Datenbank-Buchhaltungseinheiten verantwortlich.
Die Architektur der AWS ParallelCluster externen SlurmDB Unterstützungsfunktion ermöglicht es, dass mehrere Cluster dieselbe SlurmDB Datenbank gemeinsam nutzen.
![\[\]](http://docs.aws.amazon.com/de_de/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png)
**Warnung**
Der Datenverkehr zwischen AWS ParallelCluster und dem SlurmDB Externen ist nicht verschlüsselt. Es wird empfohlen, den Cluster und den externen Cluster SlurmDB in einem vertrauenswürdigen Netzwerk auszuführen.
## Arbeiten mit Slurm Accounting unter Verwendung von Head Node Slurmdbd in AWS ParallelCluster Version 3.3.0 und höher
Bevor Sie die Slurm Kontoführung konfigurieren, müssen Sie über einen vorhandenen externen Datenbankserver und eine Datenbank verfügen, die das Protokoll verwendet`mysql`.
Um die Slurm Kontoführung mit zu konfigurieren AWS ParallelCluster, müssen Sie Folgendes definieren:
+ Der URI für den externen Datenbankserver in [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)//[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri). Der Server muss existieren und vom Hauptknoten aus erreichbar sein.
+ Anmeldeinformationen für den Zugriff auf die externe Datenbank, die in [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn)und [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/definiert sind [UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName). AWS ParallelCluster verwendet diese Informationen, um die Kontoführung auf der Slurm Ebene und den `slurmdbd` Dienst auf dem Hauptknoten zu konfigurieren. `slurmdbd`ist der Daemon, der die Kommunikation zwischen dem Cluster und dem Datenbankserver verwaltet.
Eine schrittweise Anleitung finden Sie unter[Einen Cluster erstellen mit Slurm Buchhaltung](tutorials_07_slurm-accounting-v3.md).
**Anmerkung**
AWS ParallelCluster führt einen grundlegenden Bootstrap der Slurm Accounting-Datenbank durch, indem der Standard-Clusterbenutzer in der Slurm Datenbank als Datenbankadministrator festgelegt wird. AWS ParallelCluster fügt der Accounting-Datenbank keinen weiteren Benutzer hinzu. Der Kunde ist für die Verwaltung der Buchhaltungseinheiten in der Slurm Datenbank verantwortlich.
AWS ParallelCluster konfiguriert [https://slurm.schedmd.com/slurmdbd.html](https://slurm.schedmd.com/slurmdbd.html), um sicherzustellen, dass ein Cluster über eine eigene Slurm Datenbank auf dem Datenbankserver verfügt. Derselbe Datenbankserver kann in mehreren Clustern verwendet werden, aber jeder Cluster hat seine eigene separate Datenbank. AWS ParallelCluster verwendet den Clusternamen, um den Namen für die Datenbank im [https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc)Parameter der `slurmdbd` Konfigurationsdatei zu definieren. Stellen Sie sich die folgende Situation vor. Eine Datenbank, die auf dem Datenbankserver vorhanden ist, enthält einen Clusternamen, der keinem aktiven Clusternamen zugeordnet ist. In diesem Fall können Sie einen neuen Cluster mit diesem Clusternamen erstellen, der dieser Datenbank zugeordnet werden soll. Slurmverwendet die Datenbank für den neuen Cluster erneut.
**Warnung**
Es wird nicht empfohlen, mehr als einen Cluster einzurichten, um dieselbe Datenbank gleichzeitig zu verwenden. Dies kann zu Leistungsproblemen oder sogar zu Datenbank-Deadlock-Situationen führen.
Wenn Slurm Accounting auf dem Hauptknoten eines Clusters aktiviert ist, empfehlen wir die Verwendung eines Instance-Typs mit einer leistungsstarken CPU, mehr Arbeitsspeicher und höherer Netzwerkbandbreite. SlurmDie Kontoführung kann den Hauptknoten des Clusters zusätzlich belasten.
In der aktuellen Architektur der AWS ParallelCluster Slurm Accounting-Funktion hat jeder Cluster seine eigene Instanz des `slurmdbd` Daemons, wie in der folgenden Abbildung mit Beispielkonfigurationen dargestellt.
![\[\]](http://docs.aws.amazon.com/de_de/parallelcluster/latest/ug/images/slurm-acct-arch.png)
Wenn Sie Ihrer Slurm Cluster-Umgebung benutzerdefinierte Multi-Cluster- oder Verbundfunktionen hinzufügen, müssen alle Cluster auf dieselbe `slurmdbd` Instanz verweisen. Für diese Alternative empfehlen wir, dass Sie die AWS ParallelCluster Slurm Kontoführung auf einem Cluster aktivieren und die anderen Cluster manuell so konfigurieren, `slurmdbd` dass sie eine Verbindung zu den Clustern herstellen, die auf dem ersten Cluster gehostet werden.
Wenn Sie AWS ParallelCluster Versionen vor Version 3.3.0 verwenden, lesen Sie die alternative Methode zur Implementierung der Slurm Buchhaltung, die in diesem [HPC-Blogbeitrag](https://aws.amazon.com/blogs/compute/enabling-job-accounting-for-hpc-with-aws-parallelcluster-and-amazon-rds/) beschrieben wird.
## SlurmÜberlegungen zur Rechnungslegung
### Datenbank und Cluster auf verschiedenen VPCs
Um die Slurm Buchhaltung zu aktivieren, wird ein Datenbankserver benötigt, der als Backend für die Lese- und Schreiboperationen dient, die der `slurmdbd` Daemon ausführt. Bevor der Cluster erstellt oder aktualisiert wird, um die Slurm Kontoführung zu aktivieren, muss der Hauptknoten in der Lage sein, den Datenbankserver zu erreichen.
Wenn Sie den Datenbankserver auf einer anderen VPC als der, die der Cluster verwendet, bereitstellen müssen, sollten Sie Folgendes berücksichtigen:
+ Um die Kommunikation zwischen dem `slurmdbd` auf der Clusterseite und dem Datenbankserver zu ermöglichen, müssen Sie die Konnektivität zwischen den beiden VPCs einrichten. Weitere Informationen finden Sie unter [VPC Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) im *Amazon Virtual Private Cloud Cloud-Benutzerhandbuch*.
+ Sie müssen die Sicherheitsgruppe erstellen, die Sie dem Hauptknoten auf der VPC des Clusters zuordnen möchten. Nachdem die beiden miteinander verbunden VPCs wurden, ist eine Querverknüpfung zwischen den Sicherheitsgruppen auf der Datenbankseite und der Clusterseite verfügbar. Weitere Informationen finden Sie unter [Sicherheitsgruppenregeln](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules) im *Amazon Virtual Private Cloud Cloud-Benutzerhandbuch*.
### Konfiguration der TLS-Verschlüsselung zwischen `slurmdbd` und dem Datenbankserver
`slurmdbd`Stellt mit der standardmäßigen Slurm Kontoführungskonfiguration, die dies AWS ParallelCluster vorsieht, eine TLS-verschlüsselte Verbindung zum Datenbankserver her, sofern der Server die TLS-Verschlüsselung unterstützt. AWS Datenbankdienste wie Amazon RDS Amazon Aurora unterstützen standardmäßig TLS-Verschlüsselung.
Sie können sichere Verbindungen auf der Serverseite verlangen, indem Sie den `require_secure_transport` Parameter auf dem Datenbankserver festlegen. Dies ist in der bereitgestellten CloudFormation Vorlage konfiguriert.
Gemäß den bewährten Sicherheitsmethoden empfehlen wir, dass Sie auch die Überprüfung der Serveridentität auf dem `slurmdbd` Client aktivieren. Um dies zu tun, konfigurieren Sie den [StorageParameters](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters)in der`slurmdbd.conf`. Laden Sie das CA-Zertifikat des Servers auf den Hauptknoten des Clusters hoch. Stellen Sie als Nächstes die [SSL\$1CA-Option](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) `StorageParameters` in `slurmdbd.conf` auf den Pfad des Server-CA-Zertifikats auf dem Hauptknoten ein. Dadurch wird nebenbei die Überprüfung der Serveridentität aktiviert. `slurmdbd` Nachdem Sie diese Änderungen vorgenommen haben, starten Sie den `slurmdbd` Dienst neu, um die Verbindung zum Datenbankserver mit aktivierter Identitätsprüfung wiederherzustellen.
### Aktualisierung der Datenbankanmeldedaten
Um die Werte für [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName)oder zu aktualisieren [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn), müssen Sie zuerst die Rechenflotte beenden. Angenommen, der geheime Wert, der im AWS Secrets Manager Secret gespeichert ist, wird geändert und sein ARN wird nicht geändert. In diesem Fall aktualisiert der Cluster das Datenbankkennwort nicht automatisch auf den neuen Wert. Um den Cluster für den neuen geheimen Wert zu aktualisieren, führen Sie den folgenden Befehl vom Hauptknoten aus aus.
```
$ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh
```
**Warnung**
Um den Verlust von Buchhaltungsdaten zu vermeiden, empfehlen wir, das Datenbankkennwort nur zu ändern, wenn die Rechenflotte gestoppt ist.
### Datenbank-Überwachung
Wir empfehlen, dass Sie die Überwachungsfunktionen der AWS Datenbankdienste aktivieren. Weitere Informationen finden Sie in der Dokumentation zur [Amazon RDS-Überwachung](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) oder [Amazon Aurora Aurora-Überwachung](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/MonitoringAurora.html).
# Slurm Anpassung der Konfiguration
Ab AWS ParallelCluster Version 3.6.0 können Sie das anpassen `slurm.conf` Slurm Konfiguration in einer AWS ParallelCluster Clusterkonfiguration.
In der Clusterkonfiguration können Sie anpassen Slurm Konfigurationsparameter mithilfe der folgenden Cluster-Konfigurationseinstellungen:
+ Anpassen Slurm Parameter für den gesamten Cluster, indem Sie entweder den Parameter [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings)oder den [`CustomSlurmSettingsIncludeFile`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettingsIncludeFile)Parameter verwenden. AWS ParallelCluster schlägt fehl, wenn Sie beide angeben.
+ Anpassen Slurm Parameter für eine Warteschlange mithilfe von [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomSlurmSettings)(zugeordnet auf Slurm Partitionen).
+ Anpassen Slurm Parameter für eine Rechenressource mithilfe von [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)(zugeordnet zu Slurm Knoten).
## Slurm Einschränkungen bei der Anpassung der Konfiguration und Überlegungen bei der Verwendung AWS ParallelCluster
+ Für `CustomSlurmSettings` und `CustomSlurmSettingsIncludeFile` Einstellungen können Sie nur `slurm.conf` Parameter angeben und aktualisieren, die in der [Slurm Version](slurm-workload-manager-v3.md), die von der AWS ParallelCluster Version unterstützt wird, die Sie zur Konfiguration eines Clusters verwenden.
+ Wenn Sie benutzerdefiniert angeben Slurm Konfigurationen in einem der `CustomSlurmSettings` Parameter, AWS ParallelCluster führt Validierungsprüfungen durch und verhindert die Einstellung oder Aktualisierung Slurm Konfigurationsparameter, die mit der AWS ParallelCluster Logik in Konflikt stehen. Das Tool Slurm Konfigurationsparameter, mit denen bekanntermaßen Konflikte auftreten, AWS ParallelCluster werden in Verweigerungslisten identifiziert. Die Ablehnungslisten können sich in future AWS ParallelCluster Versionen ändern, falls andere Slurm Funktionen wurden hinzugefügt. Weitere Informationen finden Sie unter [Auf der Denim-Liste Slurm Konfigurationsparameter für `CustomSlurmSettings`](#slurm-configuration-denylists-v3).
+ AWS ParallelCluster prüft nur, ob ein Parameter in einer Sperrliste enthalten ist. AWS ParallelCluster validiert Ihre benutzerdefinierte Einstellung nicht Slurm Syntax oder Semantik von Konfigurationsparametern. Sie sind dafür verantwortlich, Ihren Benutzerdefiniert zu validieren Slurm Konfigurationsparameter. Ungültiger Benutzerdefiniert Slurm Konfigurationsparameter können folgende Ursachen haben Slurm Daemon-Fehler, die zu Fehlern bei der Clustererstellung und -aktualisierung führen können.
+ Wenn Sie Benutzerdefiniert angeben Slurm Konfigurationen in`CustomSlurmSettingsIncludeFile`, führt AWS ParallelCluster keine Überprüfung durch.
+ Sie können die Rechenflotte aktualisieren`CustomSlurmSettings`, `CustomSlurmSettingsIncludeFile` ohne sie zu stoppen und zu starten. In diesem Fall AWS ParallelCluster startet der `slurmctld` Daemon neu und führt den `scontrol reconfigure` Befehl aus.
Etwas Slurm Konfigurationsparameter erfordern möglicherweise unterschiedliche Operationen, bevor eine Änderung im gesamten Cluster registriert wird. Beispielsweise können sie einen Neustart aller Daemons im Cluster erfordern. Sie sind dafür verantwortlich, zu überprüfen, ob die AWS ParallelCluster Operationen für die Weitergabe Ihrer benutzerdefinierten Daten ausreichen Slurm Einstellungen der Konfigurationsparameter bei Updates. Wenn Sie der Meinung sind, dass die AWS ParallelCluster Operationen nicht ausreichen, liegt es in Ihrer Verantwortung, die zusätzlichen Maßnahmen zu ergreifen, die zur Weitergabe der aktualisierten Einstellungen erforderlich sind, wie in der [Slurm Dokumentation](https://slurm.schedmd.com/documentation.html).
## Auf der Denim-Liste Slurm Konfigurationsparameter für `CustomSlurmSettings`
In den folgenden Tabellen sind die Parameter mit den AWS ParallelCluster Versionen aufgeführt, die ihre Verwendung verweigern, beginnend mit Version 3.6.0. `CustomSlurmSettings`wird für AWS ParallelCluster Versionen vor Version 3.6.0 nicht unterstützt.
**Parameter auf Clusterebene, die auf der Verweigerliste stehen:**
| Slurm Parameter | In Versionen, die auf der Denim-Liste stehen AWS ParallelCluster |
| --- | --- |
| CommunicationParameters | 3.6.0 |
| Epilog | 3.6.0 |
| GresTypes | 3.6.0 |
| LaunchParameters | 3.6.0 |
| Prolog | 3.6.0 |
| ReconfigFlags | 3.6.0 |
| ResumeFailProgram | 3.6.0 |
| ResumeProgram | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| SlurmctldHost | 3.6.0 |
| SlurmctldLogFile | 3.6.0 |
| SlurmctldParameters | 3.6.0 |
| SlurmdLogfile | 3.6.0 |
| SlurmUser | 3.6.0 |
| SuspendExcNodes | 3.6.0 |
| SuspendProgram | 3.6.0 |
| SuspendTime | 3.6.0 |
| TaskPlugin | 3.6.0 |
| TreeWidth | 3.6.0 |
**Parameter auf Clusterebene, die auf der Negativliste stehen [Slurm Die Accounting-Integration](slurm-accounting-v3.md) ist in der Cluster-Konfiguration konfiguriert:**
| Slurm Parameter | In Versionen auf der Deni-List-Liste AWS ParallelCluster |
| --- | --- |
| AccountingStorageType | 3.6.0 |
| AccountingStorageHost | 3.6.0 |
| AccountingStoragePort | 3.6.0 |
| AccountingStorageUser | 3.6.0 |
| JobAcctGatherType | 3.6.0 |
**Auf der Sperrliste stehende Parameter auf Warteschlangenebene (Partitionsebene) für Warteschlangen, die verwaltet werden von: AWS ParallelCluster**
| Slurm Parameter | In Versionen auf der Negativliste AWS ParallelCluster |
| --- | --- |
| Knoten | 3.6.0 |
| PartitionName | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| Status | 3.6.0 |
| SuspendTime | 3.6.0 |
**Auf der Denim-List-Liste stehende Parameter auf Rechenressourcenebene (Knoten) für Rechenressourcen, die verwaltet werden von: AWS ParallelCluster**
| Slurm Parameter | In AWS ParallelCluster Version und späteren Versionen auf der Negativliste |
| --- | --- |
| CPUs | 3.6.0 |
| Features | 3.6.0 |
| Gres | 3.6.0 |
| NodeAddr | 3.6.0 |
| NodeHostname | 3.6.0 |
| NodeName | 3.6.0 |
| Gewicht | 3.7.0 |
# Slurm und `prolog` `epilog`
Ab AWS ParallelCluster Version 3.6.0 AWS ParallelCluster umfasst die Slurm Konfiguration, die mit bereitgestellt wird, die folgenden `Prolog` `Epilog` Konfigurationsparameter:
```
# PROLOG AND EPILOG
Prolog=/opt/slurm/etc/scripts/prolog.d/*
Epilog=/opt/slurm/etc/scripts/epilog.d/*
SchedulerParameters=nohold_on_prolog_fail
BatchStartTimeout=180
```
Weitere Informationen finden Sie im [Prolog and Epilog Guide](https://slurm.schedmd.com/prolog_epilog.html) in der Dokumentation. Slurm
AWS ParallelCluster beinhaltet die folgenden Prolog- und Epilog-Skripte:
+ `90_plcuster_health_check_manager`(im Ordner) `Prolog`
+ `90_pcluster_noop`(im `Epilog` Ordner)
**Anmerkung**
`Prolog`Sowohl der `Epilog` Ordner als auch müssen mindestens eine Datei enthalten.
Sie können Ihre eigenen benutzerdefinierten `epilog` Skripts `prolog` oder Skripts verwenden, indem Sie sie den entsprechenden `Epilog` Ordnern `Prolog` und hinzufügen.
**Warnung**
Slurmführt jedes Skript in den Ordnern in umgekehrter alphabetischer Reihenfolge aus.
Die Laufzeit der `prolog` und `epilog` -Skripts wirkt sich auf die Zeit aus, die für die Ausführung eines Jobs benötigt wird. Aktualisieren Sie die `BatchStartTimeout` Konfigurationseinstellung, wenn Sie mehrere oder lang andauernde `prolog` Skripts ausführen. Die Standardeinstellung ist 3 Minuten.
Wenn Sie benutzerdefinierte `epilog` Skripts `prolog` und Skripts verwenden, suchen Sie die Skripts in den entsprechenden `Epilog` Ordnern `Prolog` und. Wir empfehlen, dass Sie das `90_plcuster_health_check_manager` Skript behalten, das vor jedem benutzerdefinierten Skript ausgeführt wird. Weitere Informationen finden Sie unter [Slurm Anpassung der Konfiguration](slurm-configuration-settings-v3.md).
# Größe und Aktualisierung der Clusterkapazität
Die Kapazität des Clusters wird durch die Anzahl der Rechenknoten definiert, die der Cluster skalieren kann. Rechenknoten werden von EC2 Amazon-Instances unterstützt, die in der AWS ParallelCluster Konfiguration innerhalb von Rechenressourcen definiert sind`(Scheduling/SlurmQueues/ ComputeResources)`, und sind in Warteschlangen organisiert`(Scheduling/SlurmQueues)`, die 1:1 zugeordnet sind Slurm Partitionen.
Innerhalb einer Rechenressource ist es möglich, die Mindestanzahl von Rechenknoten (Instanzen) zu konfigurieren, die immer im Cluster laufen müssen (`MinCount`), und die maximale Anzahl von Instanzen, auf die die Rechenressource skaliert werden kann ([`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)).
AWS ParallelCluster Startet bei der Clustererstellung oder bei einem Cluster-Update so viele EC2 Amazon-Instances, wie `MinCount` für jede im Cluster definierte Rechenressource (`Scheduling/SlurmQueues/ ComputeResources`) konfiguriert sind. Die Instances, die gestartet werden, um die minimale Anzahl von Knoten für Rechenressourcen im Cluster abzudecken, werden als ***statische Knoten** bezeichnet.* Einmal gestartet, sollen statische Knoten im Cluster persistent sein und werden nicht vom System beendet, es sei denn, ein bestimmtes Ereignis oder eine bestimmte Bedingung tritt ein. Zu diesen Ereignissen gehört beispielsweise der Ausfall von Slurm oder Amazon EC2 Health Checks und die Änderung der Slurm Knotenstatus auf DRAIN oder DOWN.
Die EC2 Amazon-Instances im Bereich von `1` bis `‘MaxCount - MinCount’` (`MaxCount `*minus*)` MinCount)`, die bei Bedarf gestartet wurden, um die erhöhte Belastung des Clusters zu bewältigen, werden als ***dynamische Knoten*** bezeichnet. Sie sind kurzlebig. Sie werden gestartet, um ausstehende Jobs zu bearbeiten, und werden beendet, sobald sie für einen `Scheduling/SlurmSettings/ScaledownIdletime` in der Cluster-Konfiguration festgelegten Zeitraum inaktiv bleiben (Standard: 10 Minuten).
Statische Knoten und dynamische Knoten entsprechen dem folgenden Benennungsschema:
+ Statische Knoten `-st--` wo ` = 1..ComputeResource/MinCount`
+ Dynamische Knoten `-dy--` wo ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Zum Beispiel bei der folgenden AWS ParallelCluster Konfiguration:
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
Die folgenden Knoten werden definiert in Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Wenn es sich bei einer Rechenressource um statische Rechenknoten handelt`MinCount == MaxCount`, sind alle zugehörigen Rechenknoten statisch und alle Instanzen werden bei der Clustererstellung/Aktualisierung gestartet und laufen weiter. Zum Beispiel:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Aktualisierung der Cluster-Kapazität
Die Aktualisierung der Clusterkapazität umfasst das Hinzufügen oder Entfernen von Warteschlangen, Rechenressourcen oder das Ändern `MinCount/MaxCount` einer Rechenressource. Ab AWS ParallelCluster Version 3.9.0 muss zur Reduzierung der Größe einer Warteschlange die Rechenflotte gestoppt oder auf TERMINATE [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)gesetzt werden, bevor ein Cluster-Update stattfinden kann. Es ist nicht erforderlich, die Rechenflotte zu beenden oder auf TERMINATE [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)zu setzen, wenn:
+ Neue Warteschlangen zu Scheduling hinzufügen/ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Neue Rechenressourcen `Scheduling/SlurmQueues/ComputeResources` zu einer Warteschlange hinzufügen
+ Erhöhung der `MaxCount` Anzahl einer Rechenressource
+ Erhöhung MinCount einer Rechenressource und Erhöhung MaxCount derselben Rechenressource um mindestens die gleiche Menge
## Überlegungen und Einschränkungen
In diesem Abschnitt sollen alle wichtigen Faktoren, Einschränkungen oder Einschränkungen beschrieben werden, die bei der Größenänderung der Clusterkapazität berücksichtigt werden sollten.
+ Beim Entfernen einer Warteschlange aus `Scheduling/SlurmQueues` allen Rechenknoten mit Namen`-*`, sowohl statische als auch dynamische, werden sie aus der Slurm Konfiguration und die entsprechenden EC2 Amazon-Instances werden beendet.
+ Beim Entfernen einer Rechenressource `Scheduling/SlurmQueues/ComputeResources` aus einer Warteschlange werden alle Rechenknoten mit Namen`-*--*`, sowohl statische als auch dynamische, aus der Slurm Konfiguration und die entsprechenden EC2 Amazon-Instances werden beendet.
Wenn wir den `MinCount` Parameter einer Rechenressource ändern, können wir zwei verschiedene Szenarien unterscheiden: ob gleich gehalten `MaxCount` wird `MinCount` (nur statische Kapazität) und ob sie größer `MaxCount` ist als `MinCount` (gemischte statische und dynamische Kapazität).
### Die Kapazität ändert sich nur bei statischen Knoten
+ Wenn `MinCount == MaxCount` beim Erhöhen `MinCount` (und`MaxCount`) der Cluster konfiguriert wird, indem die Anzahl der statischen Knoten auf den neuen Wert von erhöht wird `MinCount` `-st--` und das System weiterhin versucht, EC2 Amazon-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen.
+ Wenn `MinCount == MaxCount` beim Verringern `MinCount` (und`MaxCount`) der Menge N der Cluster konfiguriert wird, indem die letzten N statischen Knoten entfernt werden, `-st--...]` und das System beendet die entsprechenden EC2 Amazon-Instances.
+ Ausgangszustand `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Update `-30` am `MinCount` und `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Kapazitätsänderungen bei gemischten Knoten
Wenn der Cluster um einen Betrag N erhöht `MinCount` `MaxCount` wird (vorausgesetzt`MinCount < MaxCount`, dass er unverändert bleibt), wird der Cluster konfiguriert, indem die Anzahl der statischen Knoten auf den neuen Wert von `MinCount` (`old_MinCount + N`): erweitert wird, `-st--` und das System versucht weiterhin, EC2 Amazon-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen. Um der `MaxCount` Kapazität der Rechenressource Rechnung zu tragen, wird die Cluster-Konfiguration außerdem aktualisiert, *indem die letzten N dynamischen Knoten* entfernt werden. `-dy--[...]` Das System beendet dann die entsprechenden EC2 Amazon-Instances.
+ Ausgangszustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aktualisieren Sie \$130 auf `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Wenn `MinCount < MaxCount` bei Erhöhung `MinCount` und gleichem Wert N `MaxCount` der Cluster konfiguriert wird, indem die Anzahl der statischen Knoten auf den neuen Wert von `MinCount` (`old_MinCount + N`): erweitert wird, `-st--` und das System versucht weiterhin, EC2 Amazon-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen. Darüber hinaus werden keine Änderungen an der Anzahl der dynamischen Knoten vorgenommen, um den neuen Anforderungen gerecht zu werden
`MaxCount` Wert.
+ Ausgangszustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Aktualisieren Sie \$130 auf `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Wenn die `MinCount` Anzahl N verringert `MaxCount` wird (vorausgesetzt`MinCount < MaxCount`, dass sie unverändert bleibt), wird der Cluster konfiguriert, indem die letzten N statischen Knoten entfernt werden, `-st--[...` und das System beendet die entsprechenden EC2 Amazon-Instances. Um der `MaxCount` Kapazität der Rechenressource Rechnung zu tragen, wird außerdem die Cluster-Konfiguration aktualisiert, indem die Anzahl der dynamischen Knoten erhöht wird, um die Lücke zu schließen. `MaxCount - new_MinCount: -dy--[1..]` In diesem Fall, da es sich um dynamische Knoten handelt, werden keine neuen EC2 Amazon-Instances gestartet, es sei denn, der Scheduler hat Jobs auf den neuen Knoten ausstehend.
+ Ausgangszustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Update -30 am `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Wenn `MinCount < MaxCount` `MaxCount` der Wert abnimmt `MinCount` und die gleiche Menge N beträgt, wird der Cluster konfiguriert, indem die letzten N statischen Knoten entfernt werden, `-st--...]` und das System beendet die entsprechenden EC2 Amazon-Instances.
Außerdem werden keine Änderungen an der Anzahl der dynamischen Knoten vorgenommen, um dem neuen `MaxCount` Wert Rechnung zu tragen.
+ Ausgangszustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Update -30 am `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Wenn die `MaxCount` Anzahl N verringert wird (vorausgesetzt`MinCount < MaxCount`, dass sie unverändert bleibt), `MinCount` wird der Cluster konfiguriert, indem die letzten N dynamischen Knoten entfernt werden, `-dy--]` und das System beendet die entsprechenden EC2 Amazon-Instances, falls sie ausgeführt wurden. Es sind keine Auswirkungen auf die statischen Knoten zu erwarten.
+ Ausgangszustand: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Update -30 am `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Auswirkungen auf die Arbeitsplätze
In allen Fällen, in denen Knoten entfernt und EC2 Amazon-Instances beendet werden, wird ein Sbatch-Job, der auf den entfernten Knoten ausgeführt wird, erneut in die Warteschlange gestellt, es sei denn, es gibt keine anderen Knoten, die die Job-Anforderungen erfüllen. In diesem letzten Fall schlägt der Job mit dem Status NODE\$1FAIL fehl und verschwindet aus der Warteschlange. Er muss manuell erneut eingereicht werden.
Wenn Sie planen, ein Update zur Änderung der Clustergröße durchzuführen, können Sie verhindern, dass Jobs auf den Knoten ausgeführt werden, die während des geplanten Updates entfernt werden. Dies ist möglich, indem Sie festlegen, dass die Knoten im Rahmen der Wartung entfernt werden. Bitte beachten Sie, dass die Einstellung eines Knotens zur Wartung keine Auswirkungen auf Jobs hat, die eventuell bereits auf dem Knoten ausgeführt werden.
Nehmen wir an, dass Sie mit dem geplanten Update zur Änderung der Clustergröße den Knoten entfernen werden`qeueu-st-computeresource-[9-10`]. Sie können eine erstellen Slurm Reservierung mit dem folgenden Befehl
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Dadurch wird ein erstellt Slurm Reservierung, die `maint_for_update` auf den Knoten benannt ist`qeueu-st-computeresource-[9-10]`. Ab dem Zeitpunkt, an dem die Reservierung erstellt wurde, können keine Jobs mehr auf den Knoten ausgeführt werden`qeueu-st-computeresource-[9-10]`. Bitte beachten Sie, dass die Reservierung nicht verhindert, dass Jobs irgendwann auf den Knoten zugewiesen werden`qeueu-st-computeresource-[9-10]`.
Nach dem Update zur Änderung der Clustergröße, wenn Slurm Die Reservierung wurde nur für Knoten eingerichtet, die während der Aktualisierung der Größenänderung entfernt wurden. Die Wartungsreservierung wird automatisch gelöscht. Wenn Sie stattdessen eine erstellt hätten Slurm Reservierung auf Knoten, die nach dem Update zur Cluster-Größenänderung noch vorhanden sind, möchten wir möglicherweise die Wartungsreservierung auf den Knoten nach der Aktualisierung der Größenänderung entfernen. Verwenden Sie dazu den folgenden Befehl
```
sudo -i scontrol delete ReservationName=maint_for_update
```
Weitere Informationen finden Sie unter Slurm [Reservierung, das offizielle SchedMD-Dokument finden Sie hier.](https://slurm.schedmd.com/reservations.html)
## Cluster-Aktualisierungsprozess bei Kapazitätsänderungen
Bei einer Änderung der Scheduler-Konfiguration werden während des Cluster-Aktualisierungsvorgangs die folgenden Schritte ausgeführt:
+ Stoppen AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Aktualisiert generieren Slurm Konfiguration von Partitionen aus der AWS ParallelCluster Konfiguration
+ Neustart `slurmctld` (erfolgt über das Chef-Dienstrezept)
+ Überprüfen Sie `slurmctld` den Status `(systemctl is-active --quiet slurmctld.service)`
+ Reload Slurm Konfiguration `(scontrol reconfigure)`
+ `clustermgtd (supervisorctl start clustermgtd)` starten
# Verwenden des AWS Batch (`awsbatch`) -Schedulers mit AWS ParallelCluster
**Warnung**
AWS CodeBuild wird in den Regionen Asien-Pazifik (Malaysia) (`ap-southeast-5`) und Asien-Pazifik (Thailand) (`ap-southeast-7`) nicht unterstützt. Daher wird ParallelCluster AWS Batch die Integration in diesen Regionen nicht unterstützt.
AWS ParallelCluster unterstützt auch AWS Batch Scheduler. In den folgenden Themen wird die Verwendung AWS Batch beschrieben. Informationen zu finden AWS Batch Sie unter [AWS Batch](https://aws.amazon.com/batch/). Die Dokumentation finden Sie im [AWS Batch Benutzerhandbuch](https://docs.aws.amazon.com/batch/latest/userguide/).
**AWS ParallelCluster CLI-Befehle für AWS Batch**
Wenn Sie den `awsbatch` Scheduler verwenden, AWS Batch werden die AWS ParallelCluster CLI-Befehle für automatisch im AWS ParallelCluster Hauptknoten installiert. Die CLI verwendet AWS Batch API-Operationen und ermöglicht die folgenden Operationen:
+ Übermitteln und Verwalten von Aufgaben.
+ Überwachen von Aufgaben, Warteschlangen und Hosts.
+ Spiegeln herkömmlicher Scheduler-Befehle.
**Wichtig**
AWS ParallelCluster unterstützt keine GPU-Jobs für AWS Batch. Weitere Informationen finden Sie unter [GPU-Jobs](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html).
Diese CLI wird als separates Paket verteilt. Weitere Informationen finden Sie unter [Scheduler-Unterstützung](moving-from-v2-to-v3.md#scheduler_support).
**Topics**
+ [`awsbsub`](awsbatchcli.awsbsub-v3.md)
+ [`awsbstat`](awsbatchcli.awsbstat-v3.md)
+ [`awsbout`](awsbatchcli.awsbout-v3.md)
+ [`awsbkill`](awsbatchcli.awsbkill-v3.md)
+ [`awsbqueues`](awsbatchcli.awsbqueues-v3.md)
+ [`awsbhosts`](awsbatchcli.awsbhosts-v3.md)
# `awsbsub`
Sendet Jobs an die Job-Warteschlange des Clusters.
```
awsbsub [-h] [-jn JOB_NAME] [-c CLUSTER] [-cf] [-w WORKING_DIR]
[-pw PARENT_WORKING_DIR] [-if INPUT_FILE] [-p VCPUS] [-m MEMORY]
[-e ENV] [-eb ENV_DENYLIST] [-r RETRY_ATTEMPTS] [-t TIMEOUT]
[-n NODES] [-a ARRAY_SIZE] [-d DEPENDS_ON]
[command] [arguments [arguments ...]]
```
**Wichtig**
AWS ParallelCluster unterstützt keine GPU-Jobs für AWS Batch. Weitere Informationen finden Sie unter [GPU-Jobs](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html).
## Positionale Argumente
***command***
Sendet den Job (der angegebene Befehl muss auf den Recheninstanzen verfügbar sein) oder den Namen der zu übertragenden Datei. Siehe auch `--command-file`.
**arguments**
(Optional) Gibt Argumente für den Befehl oder die Befehlsdatei an.
## Benannte Argumente
**-jn *JOB\$1NAME*, --job-name *JOB\$1NAME***
Benennt die Aufgabe. Das erste Zeichen muss entweder ein Buchstabe oder eine Zahl sein. Der Jobname kann Buchstaben (sowohl Groß- als auch Kleinbuchstaben), Zahlen, Bindestriche und Unterstriche enthalten und bis zu 128 Zeichen lang sein.
**-c *CLUSTER*, --cluster *CLUSTER***
Gibt den zu verwendenden Cluster an.
**-cf, --command-file**
Zeigt an, dass der Befehl eine Datei ist, die an Datenverarbeitungs-Instances übertragen werden soll.
Standard: False
**-w *WORKING\$1DIR*, --working-dir *WORKING\$1DIR***
Gibt den Ordner an, der als Arbeitsverzeichnis der Aufgabe verwendet werden soll. Wenn kein Arbeitsverzeichnis angegeben ist, wird der Job im `job-` Unterordner des Home-Verzeichnisses des Benutzers ausgeführt. Sie können entweder diesen Parameter oder den Parameter `--parent-working-dir` verwenden.
**-pw *PARENT\$1WORKING\$1DIR*, --parent-working-dir *PARENT\$1WORKING\$1DIR***
Gibt den übergeordneten Ordner des Arbeitsverzeichnisses des Jobs an. Wenn kein übergeordnetes Arbeitsverzeichnis angegeben ist, wird standardmäßig das Basisverzeichnis des Benutzers verwendet. Ein Unterordner mit dem Namen `job-` wird im übergeordneten Arbeitsverzeichnis erstellt. Sie können entweder diesen Parameter oder den Parameter `--working-dir` verwenden.
**-if *INPUT\$1FILE*, --input-file *INPUT\$1FILE***
Gibt die an die Datenverarbeitungs-Instances zu übertragende Datei im Arbeitsverzeichnis der Aufgabe an. Sie können mehrere Eingabedateiparameter angeben.
**-p *VCPUS*, --vcpus *VCPUS***
Gibt die Anzahl von v anCPUs , die für den Container reserviert werden sollen. Wenn es zusammen mit verwendet wird`–nodes`, identifiziert es die Anzahl von v CPUs für jeden Knoten.
Standard: 1
**-m *MEMORY*, --memory *MEMORY***
Gibt die harte Grenze des Arbeitsspeichers (in MiB) für die Aufgabe an. Wenn Ihr Job versucht, das hier angegebene Speicherlimit zu überschreiten, wird der Job beendet.
Standard: 128
**-e *ENV*, --env *ENV***
Gibt eine durch Komma getrennte Liste von Umgebungsvariablennamen zum Exportieren in die Aufgabenumgebung an. Zum Exportieren aller Umgebungsvariablen geben Sie „all“ an. Beachten Sie, dass eine Liste mit 'allen' Umgebungsvariablen nicht die im `–env-blacklist` Parameter aufgeführten Variablen oder Variablen enthält, die mit dem `AWS_*` Präfix `PCLUSTER_*` oder beginnen.
**-eb *ENV\$1DENYLIST*, --env-blacklist *ENV\$1DENYLIST***
Gibt eine durch Komma getrennte Liste von Umgebungsvariablennamen an, die **nicht** in die Aufgabenumgebung exportiert werden sollen. Standardmäßig werden `HOME`, `PWD`, `USER`, `PATH`, `LD_LIBRARY_PATH`, `TERM` und `TERMCAP` nicht exportiert.
**-r *RETRY\$1ATTEMPTS*, --retry-attempts *RETRY\$1ATTEMPTS***
Gibt an, wie oft ein Job in den `RUNNABLE` Status versetzt werden soll. Sie können zwischen einem und zehn Versuche angeben. Wenn der Wert der Versuche größer als 1 ist, wird der Auftrag wiederholt, falls er fehlschlägt, bis er den angegebenen `RUNNABLE` Status erreicht hat.
Standard: 1
**-t *TIMEOUT*, --timeout *TIMEOUT***
Gibt die Zeitdauer in Sekunden (gemessen anhand des `startedAt` Zeitstempels des Auftragsversuchs) an, nach deren Ablauf Ihr Job AWS Batch beendet wird, falls er noch nicht abgeschlossen ist. Der Timeout-Wert muss mindestens 60 Sekunden betragen.
**-n *NODES*, --nodes *NODES***
Gibt die Anzahl der Knoten an, die für die Aufgabe zu reservieren sind. Geben Sie einen Wert für diesen Parameter an, um die parallel Übertragung mit mehreren Knoten zu ermöglichen.
Wenn der [`CapacityType`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-CapacityType)Parameter [`Scheduler`[`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues)](Scheduling-v3.md#yaml-Scheduling-Scheduler)//auf gesetzt ist`SPOT`, werden parallel Jobs mit mehreren Knoten *nicht* unterstützt. Darüber hinaus muss es in Ihrem Konto eine `AWSServiceRoleForEC2Spot` dienstbezogene Rolle geben. Sie können diese Rolle mit dem folgenden AWS CLI Befehl erstellen:
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
Weitere Informationen finden Sie unter [Service-verknüpfte Rolle für Spot-Instance-Anfragen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) im *Amazon Elastic Compute Cloud-Benutzerhandbuch für Linux-Instances*.
**-a *ARRAY\$1SIZE*, --array-size *ARRAY\$1SIZE***
Zeigt die Größe des Arrays an. Sie können einen Wert zwischen 2 und 10.000 auswählen. Wenn Sie Array-Eigenschaften für eine Aufgabe angeben, wird sie zu einer Array-Aufgabe.
**-d *DEPENDS\$1ON*, --depends-on *DEPENDS\$1ON***
Gibt eine durch Strichpunkte getrennte Liste von Abhängigkeiten für eine Aufgabe an. Eine Aufgabe kann von maximal 20 Aufgaben abhängen. Sie können eine `SEQUENTIAL` Typabhängigkeit angeben, ohne eine Job-ID für Array-Jobs anzugeben. Eine sequenzielle Abhängigkeit ermöglicht jeder untergeordneten Array-Aufgabe, sequentiell abgeschlossen zu werden (beginnend mit Index 0). Sie können auch eine Abhängigkeit vom Typ „N\$1TO\$1N“ mit einer Aufgaben-ID für Array-Aufgaben angeben. Eine Abhängigkeit vom Typ N\$1TO\$1N bedeutet, dass jeder untergeordnete Index dieser Aufgabe warten muss, bis der entsprechende untergeordnete Index jeder Abhängigkeit abgeschlossen ist. Die Syntax für diesen Parameter lautet „jobID=**, type=**;...“.
# `awsbstat`
Zeigt die Aufgaben in der Aufgabenwarteschlange des Clusters.
```
awsbstat [-h] [-c CLUSTER] [-s STATUS] [-e] [-d] [job_ids [job_ids ...]]
```
## Positionale Argumente
***job\$1ids***
Gibt die durch Leerzeichen getrennte Liste von Jobs IDs an, die in der Ausgabe angezeigt werden sollen. Wenn die Aufgabe ein Aufgaben-Array ist, werden alle untergeordneten Aufgaben angezeigt. Wenn eine einzelne Aufgabe angefordert wird, wird sie in einer detaillierten Version angezeigt.
## Benannte Argumente
**-c *CLUSTER*, --cluster *CLUSTER***
Gibt den Cluster an, der verwendet werden soll.
**-s *STATUS*, --status *STATUS***
Gibt eine durch Komma getrennte Liste der Job-Status an, die berücksichtigt werden sollen. Der standardmäßige Aufgabenstatus lautet „active“. Akzeptierte Werte sind: `SUBMITTED`, `PENDING`, `RUNNABLE`, `STARTING`, `RUNNING`, `SUCCEEDED`, `FAILED` und `ALL`.
Standard: „`SUBMITTED`,`PENDING`,`RUNNABLE`,`STARTING`,`RUNNING`“
**-e, --expand-children**
Erweitert Aufgaben mit untergeordneten Elementen (Array und Multi-Knoten parallel).
Standard: False
**-d, --details**
Zeigt Aufgabendetails.
Standard: False
# `awsbout`
Zeigt die Ausgabe einer bestimmten Aufgabe an.
```
awsbout [-h] [-c CLUSTER] [-hd HEAD] [-t TAIL] [-s] [-sp STREAM_PERIOD] job_id
```
## Positionale Argumente
***job\$1id***
Gibt die Aufgaben-ID an.
## Benannte Argumente
**-c *CLUSTER*, --cluster *CLUSTER***
Gibt den Cluster an, der verwendet werden soll.
**-hd *HEAD*, --head *HEAD***
Ruft die ersten *HEAD* Zeilen der Jobausgabe ab.
**-t *TAIL*, --tail *TAIL***
Ruft die letzten -Zeilen der Aufgabenausgabe ab.
**-s, --stream**
Ruft die Aufgabenausgabe ab und wartet dann darauf, dass weitere Ausgaben erstellt werden. Dieses Argument kann zusammen mit „–tail“ verwendet werden, um von den aktuellen -Zeilen der Aufgabenausgabe zu beginnen.
Standard: False
**-sp *STREAM\$1PERIOD*, --stream-period *STREAM\$1PERIOD***
Legt den Streaming-Zeitraum fest.
Standard: 5
# `awsbkill`
Bricht im Cluster übermittelte Aufgaben ab oder beendet sie.
```
awsbkill [-h] [-c CLUSTER] [-r REASON] job_ids [job_ids ... ]
```
## Positionale Argumente
***job\$1ids***
Gibt die durch Leerzeichen getrennte Liste der Jobs IDs an, die abgebrochen oder beendet werden sollen.
## Benannte Argumente
**-c *CLUSTER*, --cluster *CLUSTER***
Gibt den Namen des Clusters an, der verwendet werden soll.
**-r *REASON*, --reason *REASON***
Gibt die Nachricht an, die einer Aufgabe angefügt werden soll und den Grund für ihren Abbruch angibt.
Standard:“Terminated by the user”
# `awsbqueues`
Zeigt die Aufgabenwarteschlange an, die mit dem Cluster verknüpft ist.
```
awsbqueues [-h] [-c CLUSTER] [-d] [job_queues [job_queues ... ]]
```
## Positionale Argumente
***job\$1queues***
Gibt die durch Leerzeichen getrennte Liste von Warteschlangennamen an, die angezeigt werden sollen. Wenn eine einzelne Warteschlange angefordert wird, wird sie in einer detaillierten Version angezeigt.
## Benannte Argumente
**-c *CLUSTER*, --cluster *CLUSTER***
Gibt den Namen des Clusters an, der verwendet werden soll.
**-d, --details**
Gibt an, ob die Details der Warteschlangen angezeigt werden sollen.
Standard: False
# `awsbhosts`
Zeigt die Hosts, die zur Datenverarbeitungsumgebung des Clusters gehören.
```
awsbhosts [-h] [-c CLUSTER] [-d] [instance_ids [instance_ids ... ]]
```
## Positionale Argumente
***instance\$1ids***
Gibt eine durch Leerzeichen getrennte Liste von Instanzen IDs an. Wenn eine einzelne Instance angefordert wird, wird sie in einer detaillierten Version angezeigt.
## Benannte Argumente
**-c *CLUSTER*, --cluster *CLUSTER***
Gibt den Namen des Clusters an, der verwendet werden soll.
**-d, --details**
Gibt an, ob die Details des Hosts angezeigt werden sollen.
Standard: False