Slurmschneller Cluster-Failover mit unzureichender Kapazität - 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.

Slurmschneller Cluster-Failover mit unzureichender Kapazität

Ab AWS ParallelCluster Version 3.2.0 werden Cluster mit dem Failover-Modus „Schnelles Failover mit unzureichender Kapazität“ ausgeführt, das standardmäßig aktiviert ist. 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 Ihren Cluster mit mehreren Arten von Instance-Typen konfigurieren.

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/zugewiesen wird compute resource, wird Folgendes AWS ParallelCluster ausgeführt:

  1. Dadurch wird die Rechenressource für einen vordefinierten Zeitraum in den Status „Deaktiviert“ (DOWN) versetzt.

  2. Es wird verwendetPOWER_DOWN_FORCE, um die fehlerhaften Knotenaufträge der Rechenressource abzubrechen und den fehlerhaften Knoten zu unterbrechen. Es setzt den fehlerhaften Knoten auf den POWER_DOWN (!) Status IDLE und dann aufPOWERING_DOWN (%).

  3. 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 unterSlurm Leitfaden für den Modus mit mehreren Warteschlangen.

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

Beispielsweise:

  • 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. Das liegt daran, dass der Clusterverwaltungs-Daemon nach Ausfällen mit unzureichender Knotenkapazität sucht und die Rechenressourcen in Intervallen 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-1Der 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-1Der Knoten ist auf eingestelltdown. Der ausgeschaltete dynamische Knoten innerhalb der Rechenressource (queue2-dy-c-1) ist auf gesetztdown.

Sie können den Grund für den Knoten mit überprüfenscontrol 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, es sei denn, einer der folgenden Fälle tritt ein:

  • Die Einreichungsanforderungen eines Jobs stimmen mit der wiederhergestellten Rechenressource überein.

  • Es sind keine anderen Rechenressourcen verfügbar, da sie voll ausgelastet sind.

  • slurmctldwird 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']}