SlurmStrategien zur dynamischen Knotenzuweisung in Version 3.7.x - 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.

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

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