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. # Slurm geschützter Cluster-Modus Wenn ein Cluster mit aktiviertem geschützten Modus ausgeführt wird, AWS ParallelCluster überwacht und verfolgt die Bootstrap-Fehler von Compute-Knoten, während die Compute-Knoten 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. 1. 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. Slurm Der 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_count`gibt 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` befindet`HeadNode`. 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 ist`protected_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 {{}} --region {{}} { "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äß. `PROTECTED`Der Status hat keinen Einfluss auf laufende Jobs. Wenn Jobs auf einer Partition mit Bootstrap-Fehlern bei oder höher ausgeführt werden`protected_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] ``` `queue1`Die 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. `queue2`Die 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 {{}} \ --region {{}} \ --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](troubleshooting-v3-get-logs.md). 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. [`SlurmQueues`[`CustomActions`[`OnNodeStart`[`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured)](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)](Scheduling-v3.md#Scheduling-v3-SlurmQueues) 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 ``` 1. **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 ist auf den `DOWN` Status von gesetzt Slurm nach Ablauf des Timeouts. 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. ``` 1. Die **Zustandsprüfung der Knoten schlägt fehl**. Eine Instance hinter dem Knoten besteht eine EC2 Amazon-Zustandsprüfung oder eine Zustandsprüfung für geplante Ereignisse nicht, und die Knoten werden als Bootstrap-Ausfallknoten 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. ``` 1. **Rechenknoten schlagen fehl Slurm Registrierung**. Die Registrierung des `slurmd` Daemons bei Slurm control daemon (`slurmctld`) schlägt fehl und bewirkt, dass der Status des Compute-Knotens in den `INVALID_REG` Status wechselt. Falsch konfiguriert Slurm Rechenknoten können diesen Fehler verursachen, z. B. berechnete Knoten, bei denen Fehler bei der Spezifikation der [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)Rechenknoten 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 problematischer Rechenknoten AWS ParallelCluster generiert wurden, können Sie die Protokolle auf Fehlerdetails überprüfen. Weitere Informationen zum Abrufen von Protokollen finden Sie unter[Protokolle abrufen und aufbewahren](troubleshooting-v3-get-logs.md). **`clustermgtd`log (`/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-output`log (`/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](troubleshooting-v3-get-logs.md) 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.