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.
# Behebung von Skalierungsproblemen
Dieser Abschnitt ist relevant für Cluster, die mit AWS ParallelCluster Version 3.0.0 und höher mit dem Slurm Job Scheduler installiert wurden. Weitere Informationen zur Konfiguration mehrerer Warteschlangen finden Sie unter. [Konfiguration mehrerer Warteschlangen](configuration-of-multiple-queues-v3.md)
Wenn bei einem Ihrer laufenden Cluster Probleme auftreten, versetzen Sie den Cluster in einen `STOPPED` Zustand, indem Sie den folgenden Befehl ausführen, bevor Sie mit der Problembehandlung beginnen. Dadurch werden unerwartete Kosten vermieden.
```
$ pcluster update-compute-fleet --cluster-name mycluster \
--status STOP_REQUESTED
```
Sie können die auf den Clusterknoten verfügbaren Protokolldatenströme auflisten, indem Sie den [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md) Befehl verwenden und mit einem `private-dns-name` der ausfallenden Knoten oder dem Hauptknoten filtern:
```
$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \
--filters 'Name=private-dns-name,Values=ip-10-0-0-101'
```
Anschließend können Sie den Inhalt des Log-Streams abrufen, um ihn zu analysieren, indem Sie den [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md) Befehl verwenden und die `--log-stream-name` entsprechenden Logs an eines der im folgenden Abschnitt genannten Schlüsselprotokolle übergeben:
```
$ pcluster get-cluster-log-events --cluster-name mycluster \
--region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init
```
AWS ParallelCluster erstellt CloudWatch Cluster-Protokollstreams in Protokollgruppen. Sie können diese Protokolle in der CloudWatch Konsole „**Benutzerdefinierte Dashboards**“ oder „**Protokollgruppen**“ anzeigen. Weitere Informationen erhalten Sie unter [Integration mit Amazon CloudWatch Logs](cloudwatch-logs-v3.md) und [CloudWatch Amazon-Dashboard](cloudwatch-dashboard-v3.md).
**Topics**
+ [
## Wichtige Protokolle für das Debuggen
](#troubleshooting-v3-key-logs)
+ [
## Es `InsufficientInstanceCapacity` wird ein Fehler angezeigt, `slurm_resume.log` wenn ich einen Job nicht ausführen kann oder `clustermgtd.log` wenn ich keinen Cluster erstellen kann
](#compute-node-initialization-ice-failure-v3-c2)
+ [
## Behebung von Problemen bei der Knoteninitialisierung
](#troubleshooting-v3-node-init)
+ [
## **Behebung unerwarteter Knotenersetzungen und -beendigungen**
](#troubleshooting-v3-unexpected-node-replacements-and-terminations)
+ [
## **Ersetzen, Beenden oder Herunterfahren problematischer Instanzen und Knoten**
](#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3)
+ [
## Status der Warteschlange (Partition) `Inactive`
](#troubleshooting-v3-queues)
+ [
## Behebung anderer bekannter Knoten- und Jobprobleme
](#troubleshooting-v3-other-node-job-issues)
## Wichtige Protokolle für das Debuggen
Die folgende Tabelle bietet einen Überblick über die Schlüsselprotokolle für den Hauptknoten:
+ `/var/log/cfn-init.log`- Dies ist das CloudFormation Init-Protokoll. Es enthält alle Befehle, die bei der Einrichtung einer Instanz ausgeführt wurden. Verwenden Sie es, um Initialisierungsprobleme zu beheben.
+ `/var/log/chef-client.log`- Dies ist das Chef-Client-Protokoll. Es enthält alle Befehle, die über Chef/Cinc ausgeführt wurden. Verwenden Sie es, um Initialisierungsprobleme zu beheben.
+ `/var/log/parallelcluster/slurm_resume.log`- Das ist ein `ResumeProgram` Protokoll. Es startet Instanzen für dynamische Knoten. Verwenden Sie es, um Probleme beim Start dynamischer Knoten zu beheben.
+ `/var/log/parallelcluster/slurm_suspend.log`- Das ist das `SuspendProgram` Protokoll. Es wird aufgerufen, wenn Instanzen für dynamische Knoten beendet werden. Verwenden Sie es, um Probleme mit der Kündigung dynamischer Knoten zu beheben. Wenn Sie dieses Protokoll überprüfen, sollten Sie auch das `clustermgtd` Protokoll überprüfen.
+ `/var/log/parallelcluster/clustermgtd`- Das ist das `clustermgtd` Protokoll. Es läuft als zentraler Daemon, der die meisten Clusteroperationen verwaltet. Verwenden Sie ihn, um Probleme beim Starten, Beenden oder Clusterbetrieb zu beheben.
+ `/var/log/slurmctld.log`- Dies ist das Protokoll des Slurm Kontroll-Daemons. AWS ParallelCluster trifft keine Skalierungsentscheidungen. Vielmehr versucht es nur, Ressourcen bereitzustellen, um die Slurm Anforderungen zu erfüllen. Dies ist nützlich bei Problemen mit der Skalierung und Zuweisung, bei Problemen im Zusammenhang mit Aufträgen sowie bei Problemen mit dem Start und der Kündigung im Zusammenhang mit dem Terminplaner.
+ `/var/log/parallelcluster/compute_console_output`- In diesem Protokoll wird die Konsolenausgabe einer Stichprobe von statischen Rechenknoten aufgezeichnet, die unerwartet beendet wurden. Verwenden Sie dieses Protokoll, wenn statische Rechenknoten beendet werden und die Rechenknotenprotokolle in CloudWatch nicht verfügbar sind. Der `compute_console_output log` Inhalt, den Sie erhalten, ist derselbe, wenn Sie die Amazon EC2 EC2-Konsole verwenden oder AWS CLI die Ausgabe der Instance-Konsole abrufen.
Dies sind die wichtigsten Protokolle für die Rechenknoten:
+ `/var/log/cloud-init-output.log`- Dies ist das [Cloud-Init-Protokoll](https://cloudinit.readthedocs.io/). Es enthält alle Befehle, die bei der Einrichtung einer Instanz ausgeführt wurden. Verwenden Sie es, um Initialisierungsprobleme zu beheben.
+ `/var/log/parallelcluster/computemgtd`- Das ist das `computemgtd` Protokoll. Es läuft auf jedem Rechenknoten und überwacht den Knoten für den seltenen Fall, dass der `clustermgtd` Daemon auf dem Hauptknoten offline ist. Verwenden Sie ihn, um unerwartete Terminierungsprobleme zu beheben.
+ `/var/log/slurmd.log`- Dies ist das Slurm Compute-Daemon-Protokoll. Verwenden Sie es, um Probleme mit der Initialisierung und Rechenfehlern zu beheben.
## Es `InsufficientInstanceCapacity` wird ein Fehler angezeigt, `slurm_resume.log` wenn ich einen Job nicht ausführen kann oder `clustermgtd.log` wenn ich keinen Cluster erstellen kann
Wenn der Cluster einen Slurm Scheduler verwendet, liegt ein Problem mit unzureichender Kapazität vor. Wenn bei einer Anfrage zum Starten einer Instanz nicht genügend Instances verfügbar sind, wird ein `InsufficientInstanceCapacity` Fehler zurückgegeben.
Bei der statischen Instance-Kapazität finden Sie den Fehler im `clustermgtd` Protokoll unter`/var/log/parallelcluster/clustermgtd`.
Für die dynamische Instanzkapazität finden Sie den Fehler im `ResumeProgram` Protokoll unter`/var/log/parallelcluster/slurm_resume.log`.
Die Meldung sieht dem folgenden Beispiel ähnlich:
```
An error occurred (InsufficientInstanceCapacity) when calling the RunInstances/CreateFleet operation...
```
Je nach Anwendungsfall sollten Sie eine der folgenden Methoden in Betracht ziehen, um diese Art von Fehlermeldungen zu vermeiden:
+ Deaktivieren Sie die Platzierungsgruppe, falls sie aktiviert ist. Weitere Informationen finden Sie unter [Probleme beim Platzieren von Gruppen und beim Starten von Instances](troubleshooting-v3-placemment-groups.md).
+ Reservieren Sie Kapazität für die Instances und starten Sie sie mit ODCR (On-Demand-Kapazitätsreservierungen). Weitere Informationen finden Sie unter [Starten Sie Instances mit On-Demand-Kapazitätsreservierungen (ODCR)](launch-instances-odcr-v3.md).
+ Konfigurieren Sie mehrere Rechenressourcen mit unterschiedlichen Instanztypen. Wenn für Ihren Workload kein bestimmter Instance-Typ erforderlich ist, können Sie ein schnelles Failover mit unzureichender Kapazität mit mehreren Rechenressourcen nutzen. Weitere Informationen finden Sie unter [Slurmschneller Cluster-Failover mit unzureichender Kapazität](slurm-short-capacity-fail-mode-v3.md).
+ Konfigurieren Sie mehrere Instanztypen in derselben Rechenressource und nutzen Sie die Zuweisung mehrerer Instanztypen. Weitere Informationen zur Konfiguration mehrerer Instanzen finden Sie unter [Zuweisung mehrerer Instanztypen mit Slurm](slurm-multiple-instance-allocation-v3.md) und [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
+ Verschieben Sie die Warteschlange in eine andere Availability Zone, indem Sie die Subnetz-ID in der Cluster-Konfiguration ändern [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds).
+ Wenn Ihre Arbeitslast nicht eng miteinander verknüpft ist, verteilen Sie die Warteschlange auf verschiedene Availability Zones. Weitere Informationen zur Konfiguration mehrerer Subnetze finden Sie unter [`Scheduling`](Scheduling-v3.md)//[`SlurmQueues`[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds).
## Behebung von Problemen bei der Knoteninitialisierung
In diesem Abschnitt wird beschrieben, wie Sie Probleme mit der Knoteninitialisierung beheben können. Dazu gehören Probleme, bei denen der Knoten nicht gestartet, eingeschaltet oder einem Cluster nicht beitreten kann.
**Topics**
+ [
### Hauptknoten
](#troubleshooting-v3-node-init.head-node)
+ [
### Datenverarbeitungsknoten
](#troubleshooting-v3-node-init.compute-node)
### Hauptknoten
Anwendbare Protokolle:
+ `/var/log/cfn-init.log`
+ `/var/log/chef-client.log`
+ `/var/log/parallelcluster/clustermgtd`
+ `/var/log/parallelcluster/slurm_resume.log`
+ `/var/log/slurmctld.log`
Überprüfen Sie die `/var/log/cfn-init.log` `/var/log/chef-client.log` AND-Protokolle oder die entsprechenden Protokolldatenströme. Diese Protokolle enthalten alle Aktionen, die bei der Einrichtung des Hauptknotens ausgeführt wurden. Bei den meisten Fehlern, die während der Installation auftreten, sollten sich Fehlermeldungen im `/var/log/chef-client.log` Protokoll befinden. Wenn in der Konfiguration des Clusters `OnNodeStart` oder `OnNodeConfigured` -Skripts angegeben sind, überprüfen Sie anhand der Protokollmeldungen, ob das Skript erfolgreich ausgeführt wird.
Wenn ein Cluster erstellt wird, muss der Hauptknoten warten, bis die Rechenknoten dem Cluster beitreten, bevor er dem Cluster beitreten kann. Aus diesem Grund schlägt auch der Hauptknoten fehl, wenn die Rechenknoten dem Cluster nicht beitreten können. Je nachdem, welche Art von Compute Notes Sie verwenden, können Sie eines der folgenden Verfahren anwenden, um dieses Problem zu beheben:
### Datenverarbeitungsknoten
+ Anwendbare Protokolle:
+ `/var/log/cloud-init-output.log`
+ `/var/log/slurmd.log`
+ Wenn ein Rechenknoten gestartet wird, überprüfen Sie zunächst`/var/log/cloud-init-output.log`, ob dieser die Setup-Protokolle enthalten sollte, die dem `/var/log/chef-client.log` Protokoll auf dem Hauptknoten ähneln. Bei den meisten Fehlern, die während des Setups auftreten, sollten sich Fehlermeldungen im `/var/log/cloud-init-output.log` Protokoll befinden. Wenn in der Clusterkonfiguration Skripts vor oder nach der Installation angegeben sind, überprüfen Sie, ob sie erfolgreich ausgeführt wurden.
+ Wenn Sie ein benutzerdefiniertes AMI mit Änderung der Slurm Konfiguration verwenden, liegt möglicherweise ein Slurm verwandter Fehler vor, der verhindert, dass der Compute-Knoten dem Cluster beitritt. Suchen Sie im Protokoll nach Fehlern im Zusammenhang mit dem `/var/log/slurmd.log` Scheduler.
**Dynamische Rechenknoten:**
+ Suchen Sie in `ResumeProgram` log (`/var/log/parallelcluster/slurm_resume.log`) nach Ihrem Compute-Knotennamen, um zu sehen, ob der Node jemals mit dem Node aufgerufen `ResumeProgram` wurde. (Falls der Node noch nie aufgerufen `ResumeProgram` wurde, können Sie anhand des `slurmctld` Logs (`/var/log/slurmctld.log`) nachsehen, ob Slurm jemals versucht wurde, `ResumeProgram` mit dem Node aufzurufen.)
+ Beachten Sie, dass falsche Berechtigungen für `ResumeProgram` dazu führen `ResumeProgram` können, dass der Fehler automatisch fehlschlägt. Wenn Sie ein benutzerdefiniertes AMI mit Änderungen am `ResumeProgram` Setup verwenden, überprüfen Sie, ob das dem `slurm` Benutzer `ResumeProgram` gehört und über die `744` (`rwxr--r--`) -Berechtigung verfügt.
+ Wenn aufgerufen `ResumeProgram` wird, überprüfen Sie, ob eine Instance für den Knoten gestartet wurde. Wenn keine Instance gestartet wurde, wird eine Fehlermeldung angezeigt, die den Startfehler beschreibt.
+ Wenn die Instance gestartet wird, ist möglicherweise ein Problem während des Einrichtungsvorgangs aufgetreten. Sie sollten die entsprechende private IP-Adresse und Instanz-ID aus dem `ResumeProgram` Protokoll sehen. Darüber hinaus können Sie sich die entsprechenden Setup-Protokolle für die jeweilige Instanz ansehen. Weitere Informationen zur Behebung eines Setup-Fehlers mit einem Compute-Knoten finden Sie im nächsten Abschnitt.
**Statische Rechenknoten:**
+ Prüfen Sie im Protokoll `clustermgtd` (`/var/log/parallelcluster/clustermgtd`), ob Instanzen für den Knoten gestartet wurden. Wenn sie nicht gestartet wurden, sollte eine klare Fehlermeldung angezeigt werden, in der der Startfehler detailliert beschrieben wird.
+ Wenn die Instanz gestartet wird, liegt während des Einrichtungsvorgangs ein Problem vor. Sie sollten die entsprechende private IP-Adresse und Instanz-ID aus dem `ResumeProgram` Protokoll sehen. Darüber hinaus können Sie sich die entsprechenden Setup-Protokolle für die jeweilige Instanz ansehen.
**Rechenknoten, die von Spot-Instances unterstützt werden:**
+ Wenn Sie Spot-Instances zum ersten Mal verwenden und der Job im Status PD (ausstehend) verbleibt, überprüfen Sie die `/var/log/parallelcluster/slurm_resume.log` Datei noch einmal. Sie werden wahrscheinlich einen Fehler wie den folgenden finden:
```
2022-05-20 13:06:24,796 - [slurm_plugin.common:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['spot-dy-t2micro-2']: An error occurred (AuthFailure.ServiceLinkedRoleCreationNotPermitted) when calling the RunInstances operation: The provided credentials do not have permission to create the service-linked role for Amazon EC2 Spot Instances.
```
Wenn Sie Spot-Instances verwenden, muss in Ihrem Konto eine `AWSServiceRoleForEC2Spot` serviceverknüpfte Rolle vorhanden sein. Führen Sie den folgenden Befehl aus AWS CLI, um diese Rolle in Ihrem Konto mithilfe von zu erstellen:
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
Weitere Informationen finden Sie [Arbeiten mit Spot-Instances](spot-v3.md) im AWS ParallelCluster Benutzerhandbuch und unter [Service-verknüpfte Rolle für Spot-Instance-Anfragen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) im *Amazon EC2 EC2-Benutzerhandbuch*.
## **Behebung unerwarteter Knotenersetzungen und -beendigungen**
In diesem Abschnitt wird weiter untersucht, wie Sie Probleme im Zusammenhang mit Knoten beheben können, insbesondere wenn ein Knoten ersetzt oder unerwartet beendet wird.
+ **Anwendbare Protokolle:**
+ `/var/log/parallelcluster/clustermgtd`(Kopfknoten)
+ `/var/log/slurmctld.log`(Kopfknoten)
+ `/var/log/parallelcluster/computemgtd`(Rechenknoten)
**Knoten wurden unerwartet ersetzt oder beendet**
+ Prüfen Sie im `clustermgtd` Protokoll (`/var/log/parallelcluster/clustermgtd`), ob ein Knoten `clustermgtd` ersetzt oder beendet wurde. Beachten Sie, dass alle normalen Wartungsaktionen für Knoten `clustermgtd` behandelt werden.
+ Wenn der Knoten `clustermgtd` ersetzt oder beendet wurde, sollte eine Meldung erscheinen, in der detailliert beschrieben wird, warum diese Aktion auf dem Knoten ausgeführt wurde. Wenn der Grund mit dem Scheduler zusammenhängt (z. B. weil der Knoten aktiv ist`DOWN`), schauen Sie im `slurmctld` Protokoll nach, um weitere Informationen zu erhalten. Wenn der Grund mit Amazon EC2 zusammenhängt, sollte es eine informative Nachricht geben, in der das Problem im Zusammenhang mit Amazon EC2 beschrieben wird, das den Austausch erforderlich machte.
+ Wenn der Knoten `clustermgtd` nicht beendet wurde, überprüfen Sie zunächst, ob es sich um eine erwartete Kündigung durch Amazon EC2 handelt, genauer gesagt um eine Spot-Terminierung. `computemgtd`, der auf einem Rechenknoten ausgeführt wird, kann einen Knoten auch beenden, wenn er als `clustermgtd` fehlerhaft eingestuft wird. Prüfen Sie `computemgtd` log (`/var/log/parallelcluster/computemgtd`), um zu sehen, ob der Knoten `computemgtd` beendet wurde.
**Knoten sind ausgefallen**
+ Schauen Sie in `slurmctld` log (`/var/log/slurmctld.log`) nach, warum ein Job oder ein Knoten fehlgeschlagen ist. Beachten Sie, dass Jobs automatisch in die Warteschlange gestellt werden, wenn ein Knoten ausfällt.
+ Wenn `slurm_resume` gemeldet wird, dass der Knoten gestartet wurde, und nach einigen Minuten `clustermgtd` meldet, dass es keine entsprechende Instance in Amazon EC2 für diesen Knoten gibt, schlägt der Knoten möglicherweise während der Einrichtung fehl. Gehen Sie wie folgt vor, um das Protokoll von einem Compute (`/var/log/cloud-init-output.log`) abzurufen:
+ Reichen Sie einen Job ein, um einen neuen Knoten hochfahren zu lassenSlurm.
+ Warten Sie, bis der Rechenknoten gestartet ist.
+ Ändern Sie das Verhalten beim Herunterfahren, das von der Instanz initiiert wurde, sodass ein ausfallender Rechenknoten gestoppt und nicht beendet wird.
```
$ aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--instance-initiated-shutdown-behavior "{\"Value\": \"stop\"}"
```
+ Beendigungsschutz aktivieren.
```
$ aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--disable-api-termination
```
+ Kennzeichnen Sie den Knoten so, dass er leicht identifizierbar ist.
```
$ aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=Name,Value=QUARANTINED-Compute
```
+ Trennen Sie den Knoten vom Cluster, indem Sie das `parallelcluster:cluster-name` Tag ändern.
```
$ aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=parallelcluster:clustername,Value=QUARANTINED-ClusterName
```
+ Rufen Sie mit diesem Befehl die Konsolenausgabe vom Knoten ab.
```
$ aws ec2 get-console-output --instance-id i-1234567890abcdef0 --output text
```
## **Ersetzen, Beenden oder Herunterfahren problematischer Instanzen und Knoten**
+ **Anwendbare Protokolle:**
+ `/var/log/parallelcluster/clustermgtd`(Kopfknoten)
+ `/var/log/parallelcluster/slurm_suspend.log`(Kopfknoten)
+ Bearbeitet in den meisten Fällen `clustermgtd` alle erwarteten Aktionen zur Instanzbeendigung. Sehen Sie im `clustermgtd` Protokoll nach, warum ein Knoten nicht ersetzt oder beendet werden konnte.
+ Wenn dynamische Knoten ausfallen[`SlurmSettings`Eigenschaften](Scheduling-v3.md#Scheduling-v3-SlurmSettings.properties), schauen Sie im `SuspendProgram` Protokoll nach, ob der spezifische Knoten als Argument aufgerufen `SuspendProgram` wurde. `slurmctld` Beachten Sie, dass tatsächlich `SuspendProgram` keine Aktion ausgeführt wird. Vielmehr protokolliert es nur, wenn es aufgerufen wird. Das Beenden und `NodeAddr` Zurücksetzen aller Instanzen erfolgt von`clustermgtd`. Slurmversetzt Knoten danach `SuspendTimeout` automatisch wieder in einen `POWER_SAVING` Zustand.
+ Wenn Rechenknoten aufgrund von Bootstrap-Fehlern ständig ausfallen, überprüfen Sie, ob sie mit [Slurm geschützter Cluster-Modus](slurm-protected-mode-v3.md) aktivierter Option gestartet werden. Wenn der geschützte Modus nicht aktiviert ist, ändern Sie die Einstellungen für den geschützten Modus, um den geschützten Modus zu aktivieren. Beheben Sie Fehler und korrigieren Sie das Bootstrap-Skript.
## Status der Warteschlange (Partition) `Inactive`
Wenn Sie das Programm ausführen `sinfo` und in der Ausgabe Warteschlangen mit dem `AVAIL` Status von angezeigt werden`inact`, wurde Ihr Cluster möglicherweise [Slurm geschützter Cluster-Modus](slurm-protected-mode-v3.md) aktiviert und die Warteschlange wurde für einen vordefinierten Zeitraum auf den `INACTIVE` Status gesetzt.
## Behebung anderer bekannter Knoten- und Jobprobleme
Ein anderes bekanntes Problem besteht darin, dass AWS ParallelCluster möglicherweise keine Jobs zugewiesen oder Skalierungsentscheidungen getroffen werden können. Bei dieser Art von Problem werden Ressourcen AWS ParallelCluster nur gemäß den Anweisungen gestartet, beendet oder verwaltet. Slurm Überprüfen Sie bei diesen Problemen das `slurmctld` Protokoll, um sie zu beheben.