Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Slurm Workload Manager (slurm
)
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).
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 oderDOWN.
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 Aufträge 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
<Queue/Name>-st-<ComputeResource/Name>-<num>
wo<num> = 1..ComputeResource/MinCount
-
Dynamische Knoten
<Queue/Name>-dy-<ComputeResource/Name>-<num>
wo<num> = 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 handeltMinCount == MaxCount
, sind alle zugehörigen Rechenknoten statisch und alle Instanzen werden zum Zeitpunkt der Clustererstellung/-aktualisierung gestartet und laufen weiter. Beispielsweise:
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 „TERMINATEAus“ QueueUpdateStrategygesetzt werden, bevor ein Cluster-Update durchgeführt werden kann. Es ist nicht erforderlich, die Rechenflotte zu beenden oder festzulegen QueueUpdateStrategy, TERMINATE wann:
-
Neue Warteschlangen zu Scheduling hinzufügen/
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/https://docs.aws.amazon.com/parallelcluster/latest/ug/Scheduling-v3.html#Scheduling-v3-SlurmQueuesSlurmQueues
allen Rechenknoten mit Namen<Queue/Name>-*
, 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/https://docs.aws.amazon.com/parallelcluster/latest/ug/Scheduling-v3.html#Scheduling-v3-SlurmQueues-ComputeResourcesComputeResources
aus einer Warteschlange werden alle Rechenknoten mit Namen<Queue/Name>-*-<ComputeResource/Name>-*
, 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öhenMinCount
(undMaxCount
) der Cluster konfiguriert wird, indem die Anzahl der statischen Knoten auf den neuen Wert von erhöht wirdMinCount
<Queue/Name>-st-<ComputeResource/Name>-<new_MinCount>
und das System weiterhin versucht, EC2 Amazon-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen. -
Wenn
MinCount == MaxCount
beim VerringernMinCount
(undMaxCount
) der Menge N der Cluster konfiguriert wird, indem die letzten N statischen Knoten entfernt werden,<Queue/Name>-st-<ComputeResource/Name>-<old_MinCount - N>...<old_MinCount>]
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
amMinCount
undMaxCount: 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 (vorausgesetztMinCount < 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, <Queue/Name>-st-<ComputeResource/Name>-<old_MinCount +
N>
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. <Queue/Name>-dy-<ComputeResource/Name>-[<MaxCount -
old_MinCount - N>...<MaxCount - old_MinCount>]
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 +30 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, <Queue/Name>-st-<ComputeResource/Name>-<old_MinCount +
N>
und das System versucht weiterhin, EC2 Amazon-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen. Außerdem 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 +30 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 (vorausgesetztMinCount < MaxCount
, dass sie unverändert bleibt), wird der Cluster konfiguriert, indem die letzten N statischen Knoten entfernt werden, <Queue/Name>-st-<ComputeResource/Name>-[<old_MinCount -
N>...<old_MinCount>
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:
<Queue/Name>-dy-<ComputeResource/Name>-[1..<MazCount -
new_MinCount>]
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, <Queue/Name>-st-<ComputeResource/Name>-<old_MinCount -
N>...<oldMinCount>]
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 (vorausgesetztMinCount < MaxCount
, dass sie unverändert bleibt), MinCount
wird der Cluster konfiguriert, indem die letzten N dynamischen Knoten entfernt werden, <Queue/Name>-dy-<ComputeResource/Name>-<old_MaxCount -
N...<oldMaxCount>]
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 letzterem Fall schlägt der Job mit dem Status NODE _ fehl FAIL und verschwindet aus der Warteschlange. In diesem Fall muss er erneut manuell eingereicht werden.
Wenn Sie planen, ein Update zur Änderung der Clustergröße durchzuführen, können Sie verhindern, dass Jobs in 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 werdenqeueu-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 istqeueu-st-computeresource-[9-10]
. Ab dem Zeitpunkt, an dem die Reservierung erstellt wurde, können keine Jobs mehr auf den Knoten ausgeführt werdenqeueu-st-computeresource-[9-10]
. Bitte beachten Sie, dass die Reservierung nicht verhindert, dass Jobs irgendwann auf den Knoten zugewiesen werdenqeueu-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, indem wir den folgenden Befehl verwenden
sudo -i scontrol delete ReservationName=maint_for_update
Weitere Informationen finden Sie unter Slurm Reservierung, das offizielle SchedMD-Dokument finden Sie hier.
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
Für Informationen über Slurm, siehe https://slurm.schedmd.com
AWS ParallelCluster Version (en) | Unterstützt Slurm version |
---|---|
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 |
Themen
- Konfiguration mehrerer Warteschlangen
- Slurm Leitfaden für den Modus mit mehreren Warteschlangen
- Slurmgeschützter Cluster-Modus
- Slurmschneller Cluster-Failover mit unzureichender Kapazität
- Slurmspeicherbasierte Terminplanung
- Zuweisung mehrerer Instanztypen mit Slurm
- Cluster-Skalierung für dynamische Knoten
- Slurm Abrechnung mit AWS ParallelCluster
- SlurmAnpassung der Konfiguration
- Slurmprolog und epilog
- Größe und Aktualisierung der Clusterkapazität