Cluster-Skalierung für dynamische Knoten - AWS ParallelCluster

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.

Cluster-Skalierung für dynamische Knoten

ParallelCluster unterstützt Slurm die Methoden zur dynamischen Skalierung von Clustern mithilfe Slurm des Energiespar-Plugins. Weitere Informationen finden Sie im Cloud Scheduling Guide und im SlurmPower Saving Guide in der Slurm Dokumentation.

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

The available ParallelCluster Strategien einführen that can be set into the ScalingStrategy cluster configuration to be used with Skalierung auf Jobebene are:

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-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, verarbeitet Parellelcluster nacheinander mehrere Batches.

Es stellt sicher, dass am Ende des Skalierungsprozesses keine inaktiven Instanzen übrig bleiben, indem der Durchsatz auf Kosten einer vorübergehenden Überskalierung während des Skalierungsprozesses maximiert wird.

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.

Im Folgenden finden Sie ein Beispiel, das 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.

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 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.

    • Eine ll-or-nothing Skalierung:

      ParallelCluster skaliert den Cluster mithilfe eines Amazon EC2 EC2-Launch-Instance-API-Aufrufs, der nur erfolgreich ist, wenn alle zur Unterstützung der angeforderten Knoten benötigten Instances gestartet 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-nothingEC2-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.

Um einen Job im exklusiven Modus einzureichen:

  • Übergeben Sie die Exklusivkennzeichnung, wenn Sie einen Slurm Job an den Cluster senden. z. B. sbatch ... --exclusive.

    ODER

  • Senden Sie einen Job an eine Cluster-Warteschlange, die mit der JobExclusiveAllocationEinstellung auf konfiguriert wurdetrue.

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-nothingStartanforderung 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-nothingStartanforderung für jeden Satz von 500 Knoten und eine zusätzliche Startanforderung für die restlichen 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-nothingStartanforderung 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-nothingStartstrategie:

  • 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-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-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.

AWS ParallelCluster verwendet nur eine Art von Strategie für die dynamische 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 inaktive Instanzen am Ende des Skalierungsprozesses, für den Fall, dass es nicht möglich ist, alle von den Jobs angeforderten Knoten zuzuweisen.