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.
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_RESUME_FILE 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-nothingoder einer Best-Effort-Logik ausgeführt werden.
Für den Start der Amazon EC2 EC2-Instances:
-
all-or-nothingruft 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-nothingweist 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
Beispiel
all-or-nothingSkalierung:
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-nothingLogik für den Start der Amazon EC2 EC2-Instances für jeden Job sowie eine all-or-nothingLogik 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
-
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-nothingEC2-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-nothingAmazon 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-nothingAmazon EC2 EC2-Launch-API-Aufruf nicht unterstützt und ParallelCluster führt stattdessen eine Skalierung nach bestem Wissen durch.
greedy-all-or-nothingSkalierung:
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-nothingLogik 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-nothingSkalierung:
-
Für den ersten Job wird eine all-or-nothingAmazon 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-nothingAmazon 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-nothingSkalierung:
-
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-nothingZuweisung von 20 der gestarteten Instances zu Slurm Knoten für den ersten Job ist erfolgreich
-
Eine weitere all-or-nothingZuweisung 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.
