Slurmgeschützter Cluster-Modus - AWS ParallelCluster
Parameter für den geschützten ModusÜberprüfen Sie den Clusterstatus im geschützten StatusWie deaktiviere ich den geschützten StatusBootstrap-Fehler, die den geschützten Status aktivierenWie debuggt man den geschützten Modus

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.

Slurmgeschützter Cluster-Modus

Wenn ein Cluster mit aktiviertem Schutzmodus ausgeführt wird, AWS ParallelCluster überwacht und verfolgt die Bootstrap-Fehler der Rechenknoten, während die Rechenknoten gestartet werden. Auf diese Weise wird erkannt, ob diese Fehler kontinuierlich auftreten.

Wenn in einer Warteschlange (Partition) Folgendes erkannt wird, wechselt der Cluster in den geschützten Status:

  1. Aufeinanderfolgende Bootstrap-Fehler des Compute-Knotens treten kontinuierlich auf, ohne dass der Compute-Knoten erfolgreich gestartet wurde.

  2. Die Anzahl der Fehler erreicht einen vordefinierten Schwellenwert.

Wenn der Cluster den Schutzstatus erreicht hat, werden Warteschlangen mit Ausfällen am oder über dem vordefinierten Schwellenwert AWS ParallelCluster deaktiviert.

SlurmDer geschützte Clustermodus wurde in AWS ParallelCluster Version 3.0.0 hinzugefügt.

Sie können den geschützten Modus verwenden, um den Zeit- und Ressourcenaufwand für den Bootstrap-Fehlerzyklus von Compute-Knoten zu reduzieren.

Parameter für den geschützten Modus

protected_failure_count

protected_failure_countgibt die Anzahl aufeinanderfolgender Fehler in einer Warteschlange (Partition) an, die den Cluster-Schutzstatus aktivieren.

Die Standardeinstellung protected_failure_count ist 10 und der geschützte Modus ist aktiviert.

Wenn protected_failure_count der Wert größer als Null ist, ist der geschützte Modus aktiviert.

Wenn kleiner oder gleich Null protected_failure_count ist, ist der geschützte Modus deaktiviert.

Sie können den protected_failure_count Wert ändern, indem Sie den Parameter in der clustermgtd Konfigurationsdatei hinzufügen, die sich unter /etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf befindetHeadNode.

Sie können diesen Parameter jederzeit aktualisieren und müssen dafür nicht die Rechenflotte anhalten. Wenn ein Start in einer Warteschlange erfolgreich ist, bevor die Anzahl der Fehler erreicht istprotected_failure_count, wird die Anzahl der Fehler auf Null zurückgesetzt.

Überprüfen Sie den Clusterstatus im geschützten Status

Wenn sich ein Cluster im geschützten Status befindet, können Sie den Status der Rechenflotte und den Knotenstatus überprüfen.

Den Flottenstatus berechnen

Der Status der Rechenflotte befindet sich PROTECTED in einem Cluster, der im geschützten Status ausgeführt wird.

$ pcluster describe-compute-fleet --cluster-name <cluster-name> --region <region-id>
{
   "status": "PROTECTED",
   "lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}

Status des Knotens

Um zu erfahren, in welchen Warteschlangen (Partitionen) Bootstrap-Fehler aufgetreten sind, für die der Schutzstatus aktiviert wurde, melden Sie sich beim Cluster an und führen Sie den sinfo Befehl aus. Partitionen mit Bootstrap-Fehlern auf oder höher protected_failure_count befinden sich im Status. INACTIVE Partitionen ohne Bootstrap-Fehler bei oder höher protected_failure_count befinden sich im UP Status und funktionieren erwartungsgemäß.

PROTECTEDDer Status hat keinen Einfluss auf laufende Jobs. Wenn Jobs auf einer Partition mit Bootstrap-Fehlern bei oder höher ausgeführt werdenprotected_failure_count, wird die Partition INACTIVE nach Abschluss der laufenden Jobs auf den Wert gesetzt.

Betrachten Sie die Knotenstatus, die im folgenden Beispiel gezeigt werden.

$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]

queue1Die Partition liegt INACTIVE daran, dass 10 aufeinanderfolgende Bootstrap-Fehler beim Compute-Knoten-Bootstrap erkannt wurden.

Instanzen hinter den Knoten queue1-dy-c5xlarge-[1-10] wurden gestartet, konnten aber aufgrund eines fehlerhaften Status nicht dem Cluster beitreten.

Der Cluster befindet sich im geschützten Status.

queue2Die Partition ist von den Bootstrap-Fehlern in nicht betroffen. queue1 Sie befindet sich im UP Status und kann weiterhin Jobs ausführen.

Wie deaktiviere ich den geschützten Status

Nachdem der Bootstrap-Fehler behoben wurde, können Sie den folgenden Befehl ausführen, um den Schutzstatus des Clusters zu beenden.

$ pcluster update-compute-fleet --cluster-name <cluster-name> \
  --region <region-id> \
  --status START_REQUESTED

Bootstrap-Fehler, die den geschützten Status aktivieren

Bootstrap-Fehler, die den geschützten Status aktivieren, werden in die folgenden drei Typen unterteilt. Um den Typ und das Problem zu identifizieren, können Sie überprüfen, ob Protokolle AWS ParallelCluster generiert wurden. Wenn Protokolle generiert wurden, können Sie sie auf Fehlerdetails überprüfen. Weitere Informationen finden Sie unter Protokolle abrufen und aufbewahren.

  1. Bootstrap-Fehler, der dazu führt, dass sich eine Instanz selbst beendet.

    Eine Instanz schlägt zu Beginn des Bootstrap-Prozesses fehl, z. B. eine Instanz, die sich aufgrund von Fehlern im\\ | -Skript selbst beendet. SlurmQueuesCustomActionsOnNodeStartOnNodeConfigured

    Suchen Sie bei dynamischen Knoten nach Fehlern, die den folgenden ähneln:

    Node bootstrap error: Node ... is in power up state without valid backing instance

    Suchen Sie bei statischen Knoten im clustermgtd Log (/var/log/parallelcluster/clustermgtd) nach Fehlern, die den folgenden ähneln:

    Node bootstrap error: Node ... is in power up state without valid backing instance

  2. Knoten resume_timeout oder node_replacement_timeout läuft ab.

    Eine Instanz kann dem Cluster nicht innerhalb des resume_timeout (für dynamische Knoten) oder node_replacement_timeout (für statische Knoten) beitreten. Sie beendet sich vor dem Timeout nicht selbst. Beispielsweise ist das Netzwerk für den Cluster nicht korrekt eingerichtet und der Knoten wird Slurm nach Ablauf des Timeouts in den DOWN Status versetzt.

    Suchen Sie bei dynamischen Knoten nach Fehlern, die den folgenden ähneln:

    Node bootstrap error: Resume timeout expires for node

    Suchen Sie bei statischen Knoten im clustermgtd Log (/var/log/parallelcluster/clustermgtd) nach Fehlern, die den folgenden ähneln:

    Node bootstrap error: Replacement timeout expires for node ... in replacement.

  3. Die Zustandsprüfung der Knoten schlägt fehl.

    Eine Instance hinter dem Knoten besteht eine Amazon EC2 EC2-Zustandsprüfung oder eine Zustandsprüfung für geplante Ereignisse nicht, und die Knoten werden als Bootstrap-Fehlerknoten behandelt. In diesem Fall wird die Instance aus einem Grund beendet, auf den sie keinen Einfluss hat. AWS ParallelCluster

    Suchen Sie im clustermgtd Protokoll (/var/log/parallelcluster/clustermgtd) nach Fehlern, die den folgenden ähneln:

    Node bootstrap error: Node %s failed during bootstrap when performing health check.

  4. Die SlurmRegistrierung der Rechenknoten schlägt fehl.

    Die Registrierung des Daemons beim slurmd Slurm Kontroll-Daemon (slurmctld) schlägt fehl und führt dazu, dass der Status des Compute-Knotens in den INVALID_REG Status wechselt. Falsch konfigurierte Slurm Rechenknoten können diesen Fehler verursachen, z. B. wenn bei berechneten Knoten, bei denen Fehler bei der Spezifikation der CustomSlurmSettingsRechenknoten vorliegen.

    Suchen Sie in der slurmctld Protokolldatei (/var/log/slurmctld.log) auf dem Hauptknoten oder in der slurmd Protokolldatei (/var/log/slurmd.log) des ausgefallenen Rechenknotens nach Fehlern, die den folgenden ähneln:

    Setting node %s to INVAL with reason: ...

Wie debuggt man den geschützten Modus

Wenn sich Ihr Cluster im geschützten Status befindet und clustermgtd Protokolle aus den HeadNode und den cloud-init-output Protokollen von problematischen Rechenknoten AWS ParallelCluster generiert wurden, können Sie die Protokolle auf Fehlerdetails überprüfen. Weitere Informationen zum Abrufen von Protokollen finden Sie unterProtokolle abrufen und aufbewahren.

clustermgtdlog (/var/log/parallelcluster/clustermgtd) auf dem Hauptknoten

Protokollmeldungen zeigen, auf welchen Partitionen Bootstrap-Fehler aufgetreten sind und wie viele Bootstrap-Fehler es gibt.

[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions  
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.

Suchen clustermgtd Sie im Protokoll nach, für Found the following bootstrap failure nodes welchen Knoten das Bootstrap fehlgeschlagen ist.

[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING - 
Found the following bootstrap failure nodes: (x2)  ['queue1-st-c5large-1(192.168.110.155)',  'broken-st-c5large-2(192.168.65.215)']

Suchen clustermgtd Sie im Protokoll nach, Node bootstrap error um den Grund für den Fehler zu ermitteln.

[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error: 
Node broken-st-c5large-2(192.168.65.215) is currently in  replacement and no backing instance

cloud-init-outputlog (/var/log/cloud-init-output.log) auf den Rechenknoten

Nachdem Sie die private IP-Adresse des Bootstrap-Fehlerknotens im clustermgtd Protokoll abgerufen haben, können Sie das entsprechende Rechenknotenprotokoll finden, indem Sie sich entweder beim Rechenknoten anmelden oder den Anweisungen unter Logs abrufen folgen. Protokolle abrufen und aufbewahren In den meisten Fällen zeigt das /var/log/cloud-init-output Protokoll des problematischen Knotens den Schritt, der den Bootstrap-Fehler des Compute-Knotens verursacht hat.