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.
# Beheben Sie Probleme mit dem Bootstrap und der Registrierung von Rechenknoten in PCS AWS
Wenn Compute-Knoten beim Bootstrap oder bei der Registrierung nicht ordnungsgemäß bei Ihrem AWS PCS-Cluster funktionieren, können die folgenden Symptome auftreten:
+ Jobs werden nicht gestartet
+ Sie können keine Verbindung zu Instanzen herstellen in AWS Systems Manager
+ Instanzen werden unerwartet heruntergefahren
+ Instanzen werden kontinuierlich ersetzt
Diese Fehler können durch Probleme beim Start der EC2-Instance oder beim Bootstrap-Prozess des AWS PCS-Compute-Knotens verursacht werden. In diesem Thema werden Verfahren beschrieben, die Ihnen bei der Behebung von Problemen beim Bootstrap-Prozess des AWS PCS-Knotens helfen. Weitere Informationen zur Behebung von [Problemen beim Starten von EC2-Instances finden Sie unter Problembehandlung beim Starten von Amazon EC2 EC2-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) im *Amazon Elastic Compute Cloud-Benutzerhandbuch*.
Bootstrap-Fehler treten auf, wenn eine EC2-Instance erfolgreich gestartet wird, aber beim Beitritt zum PCS-Cluster fehlschlägt. AWS Der Bootstrap-Prozess umfasst zwei Hauptphasen:
+ **Knotenregistrierung** — Die EC2-Instance ruft die [RegisterComputeNodeGroupInstance](https://docs.aws.amazon.com/pcs/latest/APIReference/API_RegisterComputeNodeGroupInstance.html) AWS PCS-API-Aktion auf, um sich beim AWS PCS-Service zu registrieren. Fehler können aufgrund von Problemen in den folgenden Bereichen auftreten:
+ Berechtigungen
+ [Falsches Instanzprofil](#troubleshooting-compute-node-bootstrap-wrong-instance-profile)
+ Netzwerk
+ [Es kann keine Verbindung zu AWS PCS-Endpunkten hergestellt werden](#troubleshooting-compute-node-bootstrap-connect-to-endpoints)
+ [Falsch konfigurierter PCS-Endpunkt AWS](#troubleshooting-compute-node-bootstrap-misconfigured-pcs-endpoint)
+ [Instanz in einem öffentlichen Subnetz ohne öffentliche IP](#troubleshooting-compute-node-bootstrap-public-subnet-no-public-ip)
+ [Multi-NIC-Instanz in einem öffentlichen Subnetz](#troubleshooting-compute-node-bootstrap-multi-nic-public-subnet)
+ Geheimer Cluster
+ [Der geheime Clusterschlüssel wurde gelöscht oder zum Löschen markiert](#troubleshooting-compute-node-bootstrap-cluster-secret-deleted)
+ **Slurm-Integration** — Die Instanz läuft `slurmd` und tritt dem Slurm-Cluster bei. Fehler können aufgrund von Problemen in den folgenden Bereichen auftreten:
+ Berechtigungen
+ [Sicherheitsgruppenkonfiguration](#troubleshooting-compute-node-bootstrap-security-groups)
+ [Slurmctld kann den Computerknoten nicht pingen](#troubleshooting-compute-node-bootstrap-slurmctld-ping-issue)
+ Benutzerdefiniertes AMI-Setup
+ [Fehlende NVIDIA-Treiber](#troubleshooting-compute-node-bootstrap-missing-nvidia-drivers)
+ [ResumeTimeout erreicht](#troubleshooting-compute-node-bootstrap-resume-timeout)
## Wie funktioniert Slurm auf AWS PCS
Es könnte Ihnen helfen, die Standardfunktion von Slurm mit der Funktionsweise von Slurm auf PCS zu vergleichen. AWS
**Standardverarbeitung von Slurm-Jobs**
Die folgenden Schritte finden bei der Standardverarbeitung von Slurm-Jobs statt:
1. Wenn Sie einen Job einreichen, `slurmctld` validiert er den Job und stellt ihn in eine Warteschlange.
1. Weist vorhandene Knoten zu, sobald Ressourcen verfügbar sind`slurmctld`.
1. `slurmd`Daemons führen Jobs auf zugewiesenen Knoten aus.
**Verarbeitung von Slurm-Jobs auf PCs AWS**
Bei der Verarbeitung von AWS PCS-Jobs werden die folgenden Schritte ausgeführt:
1. Wenn Sie einen Job einreichen, `slurmctld` validiert er den Job und stellt ihn in eine Warteschlange.
1. **Wenn zusätzliche Kapazität benötigt wird, verwendet AWS PCS die Startvorlage für die Compute-Knotengruppe, um neue EC2-Instances zu starten.**
1. **Neue Instanzen starten per Bootstrap in den Cluster:**
1. **Instanzen registrieren sich bei AWS PCS.**
1. **Instanzen treten dem Slurm-Cluster bei.**
1. Wenn die Ressourcen bereit sind, `slurmctld` weist sie Knoten zu (einschließlich der Knoten, die neu gebootet wurden).
1. `slurmd`Daemons führen Jobs auf zugewiesenen Knoten aus.
## Instanzprotokolle abrufen
Der erste Schritt bei der Behebung von Bootstrap-Problemen mit Rechenknoten besteht darin, die Instanzprotokolle abzurufen. Sie können eine der folgenden Methoden verwenden:
------
#### [ AWS CLI ]
Rufen Sie mit dem folgenden Befehl die Konsolenausgabe vom Rechenknoten ab:
```
aws ec2 get-console-output --region us-east-1 --instance-id i-1234567890abcdef0 --output text
```
*us-east-1*Ersetzen Sie es durch Ihre AWS Region und *i-1234567890abcdef0* durch Ihre Instanz-ID.
------
#### [ AWS Systems Manager ]
Wenn Sie mit Systems Manager eine Verbindung zur Instanz herstellen können, können Sie die Bootstrap-Protokolldatei direkt anzeigen:
1. Stellen Sie mithilfe von Systems Manager eine Connect zur Instanz her. Weitere Informationen finden Sie unter [Starten einer Sitzung](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console) im *Systems Manager Manager-Benutzerhandbuch*.
1. Sehen Sie sich die Bootstrap-Protokolldatei an:
```
sudo cat /var/log/amazon/pcs/bootstrap.log
```
**Anmerkung**
Wenn während der Initialisierungsphase ein Problem auftritt, müssen Sie möglicherweise etwa 20 Minuten warten, bevor Sie eine Verbindung mit der Instanz herstellen können. Systems Manager- und SSH-Dienste werden erst gestartet, nachdem die Initialisierung abgeschlossen ist oder wenn die Bootstrap-Ausführung im Fehlerfall ein Timeout erreicht.
------
## Rufen Sie VPC/Subnet/Security Gruppen aus einer Instanz-ID ab
Um Probleme mit Ihren Rechenknoten zu beheben, müssen Sie möglicherweise Informationen über die VPC, das Subnetz und die Sicherheitsgruppen abrufen, die Ihren Instances zugeordnet sind. Wenn Sie Ihre Instance nicht kennen, finden Sie weitere Informationen IDs unter. [Suchen nach Rechenknotengruppeninstanzen in AWS PCS](working-with_compute-instances.md)
------
#### [ AWS-Managementkonsole ]
**Um VPC-, Subnetz- und Sicherheitsgruppen abzurufen**
1. Öffnen Sie die [Amazon EC2-Konsole](https://console.aws.amazon.com/ec2).
1. Wählen Sie **Instances**.
1. Wählen Sie in der Tabelle **Instances** die Instance-ID aus.
1. Suchen Sie die **VPC-ID** und die **Subnetz-ID** in der angezeigten Instanzübersicht für die Instance.
1. Wählen Sie in der Instanzübersicht die Registerkarte **Sicherheit** aus.
1. Suchen Sie die **Sicherheitsgruppen** auf der Registerkarte **Sicherheit**.
------
#### [ AWS CLI ]
Verwenden Sie den folgenden Befehl, um VPC-, Subnetz- und Sicherheitsgruppeninformationen für Ihre Instance abzurufen:
```
aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query 'Reservations[*].Instances[*].{InstanceId:InstanceId,VpcId:VpcId,SubnetId:SubnetId,SecurityGroups:SecurityGroups[*].GroupId}' --output table
```
------
## Probleme bei der Knotenregistrierung
Die Knotenregistrierung ist die erste Aktion, die von einem Rechenknoten beim Bootstrap ausgeführt wird. Der Knoten ruft den AWS PCS-API-Endpunkt auf, um sich bei AWS PCS zu registrieren. Bei fehlgeschlagenen Registrierungen werden in der Regel Fehlermeldungen angezeigt, die den folgenden ähneln:
```
<13>Nov 13 16:23:50 user-data: [2025-11-13T16:23:50.510+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registering node to cluster
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.193+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is [specific error message]
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.194+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retrying in 31 seconds...
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
...
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.195+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registration timeout (600 seconds) reached. Exiting.
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.200+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: ERROR: Error: (2) occurred on line 1 when running /opt/aws/pcs/bin/pcs_bootstrap_init.sh. Shutting down instance.
```
### Falsches Instanzprofil
Wenn sich der Knoten aufgrund eines falschen Instanzprofils nicht registrieren kann, wird der folgende Fehler angezeigt:
```
<13>Nov 13 18:43:08 user-data: [2025-11-13T18:43:08.268+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is {
<13>Nov 13 18:43:08 user-data: "__type": "com.amazon.coral.service#AccessDeniedException",
<13>Nov 13 18:43:08 user-data: "Message": "User: arn:aws:sts:::assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ as either the resource does not exist, some policy explicitly denies access, or no policy grants access",
<13>Nov 13 18:43:08 user-data: "nodeID": null
<13>Nov 13 18:43:08 user-data: }
```
Stellen Sie sicher, dass das mit dem Compute-Knoten verknüpfte Instanzprofil über die `pcs:RegisterComputeNodeGroupInstance` entsprechende Berechtigung verfügt. Weitere Informationen zum Erstellen eines gültigen Instanzprofils finden Sie unter[Erstellen Sie ein Instanzprofil für AWS PCS](getting-started_create-cng_instance-profile.md).
### Es kann keine Verbindung zu AWS PCS-Endpunkten hergestellt werden
Wenn sich Ihre Rechenknoten in einem privaten Subnetz befinden, stellen Sie sicher, dass Sie VPC-Endpunkte für AWS PCS konfiguriert haben oder dass Ihr Subnetz über eine Route zu einem NAT-Gateway für den Internetzugang verfügt. Weitere Informationen finden Sie hier:
+ [Greifen Sie über einen Schnittstellen-VPC-Endpunkt im *Amazon Virtual Private Cloud AWS PrivateLink Cloud-Handbuch* auf einen AWS Service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) zu.
+ [Endpunkte und Servicekontingenten für AWS PCS](service-endpoints-quotas.md).
+ [Connect Sie Ihre VPC mit anderen Netzwerken](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) im *Amazon Virtual Private Cloud Cloud-Benutzerhandbuch*
+ [AWS PCS-Netzwerke](working-with_networking.md)
### Falsch konfigurierter PCS-Endpunkt AWS
Wenn Sie eine Fehlermeldung ähnlich der folgenden sehen, überprüfen Sie die mit Ihrem AWS PCS-VPC-Endpunkt verknüpfte Richtlinie:
```
com.amazon.coral.security.AccessDeniedException: User: arn:aws:sts::xxx:assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ as either the resource does not exist, some policy explicitly denies access, or no policy grants access
```
Weitere Informationen zur Konfiguration von VPC-Schnittstellenendpunkten für AWS PCS finden Sie unter. [Zugriff AWS Parallel Computing Service über einen Schnittstellenendpunkt (AWS PrivateLink)](vpc-interface-endpoints.md)
### Instanz in einem öffentlichen Subnetz ohne öffentliche IP
Wenn in Ihrem Subnetz die **automatische Zuweisung öffentlicher IP-Adressen** nicht aktiviert ist und Ihre Routenkonfiguration ein Internet-Gateway verwendet, können Instances nicht mit der AWS PCS-API kommunizieren.
Instanzen in einem Subnetz mit einem Internet-Gateway müssen eine öffentliche IP-Adresse haben. Wählen Sie eine der folgenden Optionen, um dieses Problem zu beheben:
+ Fügen Sie Ihrer Cluster-VPC einen VPC-Endpunkt für AWS PCS hinzu. Dadurch können Instances mit AWS PCS kommunizieren, ohne dass eine öffentliche IP-Adresse das Internet-Gateway passieren muss.
+ Verwenden Sie ein privates Subnetz mit einem NAT-Gateway, sodass keine öffentliche IP-Adresse erforderlich ist.
+ Aktivieren Sie die automatische Zuweisung von öffentlichen IP-Adressen über Ihr Subnetz oder Ihre Startvorlage, sodass Instances die API über das Internet-Gateway kontaktieren können. Beachten Sie, dass diese Option nicht für Instances mit mehreren Netzwerkschnittstellen gilt.
### Multi-NIC-Instanz in einem öffentlichen Subnetz
Sie müssen ein privates Subnetz verwenden, wenn Sie einen Instanztyp mit mehreren Netzwerkschnittstellen () verwenden. NICs
AWS Öffentliche IP-Adressen können nur Instances zugewiesen werden, die mit einer einzigen Netzwerkschnittstelle gestartet wurden. Weitere Informationen zu IP-Adressen finden Sie unter [Zuweisen einer öffentlichen IPv4 Adresse beim Instance-Start](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses) im *Amazon EC2 EC2-Benutzerhandbuch für Linux-Instances*.
Instance-Typen mit mehreren NICs benötigen ein NAT-Gateway oder einen internen Proxy im Subnetz, um auf den AWS PCS-Endpunkt zuzugreifen. Alternativ können Sie Ihrer Cluster-VPC einen VPC-Endpunkt für AWS PCS hinzufügen.
### Der geheime Clusterschlüssel wurde gelöscht oder zum Löschen markiert
Wenn das Shared Secret von Slurm in AWS Secrets Manager gelöscht oder zum Löschen markiert wurde, können sich die Rechenknoten nicht registrieren und Ihr Cluster wird beeinträchtigt.
AWS PCS erstellt automatisch ein Shared Secret von Slurm in AWS Secrets Manager (mit dem Namensformat:`pcs!slurm-secret-`), wenn Sie einen Cluster erstellen. Dieses Geheimnis ist für die sichere Kommunikation im Cluster erforderlich. Weitere Informationen finden Sie unter [Arbeiten mit Clustergeheimnissen in AWS PCS](working-with_clusters_secrets.md).
Wenn dieses Geheimnis gelöscht oder zum Löschen markiert wird, können neue Knoten dem Cluster nicht beitreten, und der Controller oder andere Cluster-Daemons (wie `slurmd` und`slurmdbd`) können dem Cluster möglicherweise nicht wieder beitreten, wenn sie neu gestartet werden.
Um dieses Problem zu beheben, können Sie das gelöschte Geheimnis wiederherstellen, sofern es sich noch im Wiederherstellungsfenster befindet. Eine ausführliche Anleitung finden Sie unter [Wiederherstellen eines AWS Secrets Manager Manager-Geheimnisses](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_restore-secret.html).
Wenn das Wiederherstellungsfenster abläuft, kann das Geheimnis nicht wiederhergestellt werden und der betroffene AWS PCS-Cluster kann nicht wiederhergestellt werden. Sie müssen einen neuen Cluster mit derselben Konfiguration erstellen. AWS PCS erstellt automatisch ein neues Scheduler-Secret.
## Probleme beim Zusammenschluss mit Slurm-Clustern
Nach erfolgreicher Knotenregistrierung versucht der Rechenknoten, dem Slurm-Cluster beizutreten. Der `slurmd` Daemon auf dem Knoten kontaktiert den Slurm-Controller, um sich beim Cluster zu registrieren. Bei Fehlern beim Slurm-Join werden normalerweise Fehlermeldungen angezeigt, die den folgenden ähneln:
```
<13>Nov 5 17:20:29 user-data: [2024-11-05T17:20:28+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: service[slurmd] (aws-pcs-slurm::finalize_slurm line 18) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
<13>Nov 5 17:20:29 user-data: ---- Begin output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----
<13>Nov 5 17:20:29 user-data: STDOUT:
<13>Nov 5 17:20:29 user-data: STDERR: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.
<13>Nov 5 17:20:29 user-data: ---- End output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----
```
### Sicherheitsgruppenkonfiguration
Stellen Sie sicher, dass Ihre Sicherheitsgruppen korrekt konfiguriert sind, um die Kommunikation zwischen Rechenknoten und dem Slurm-Controller zu ermöglichen. Die Sicherheitsgruppen müssen den folgenden Verkehr zulassen:
+ Port 6817 für `slurmd` die Kommunikation mit `slurmctld`
+ Port 6818 zum Pingen `slurmctld` `slurmd`
Weitere Informationen zu den Anforderungen an Sicherheitsgruppen finden Sie in den folgenden Themen:
+ [Sicherheitsgruppen für AWS PCS erstellen](getting-started_create-sg.md)
+ [Startvorlagen für AWS PCS erstellen](getting-started_create-cng_launch-templates.md)
+ [Anforderungen und Überlegungen zur Sicherheitsgruppe](working-with_networking_sg.md#working-with_networking_sg-requirements)
**Wichtig**
Die Cluster-Sicherheitsgruppe, die Sie Ihrem Cluster bei der Clustererstellung zugeordnet haben, muss auch in den Sicherheitsgruppen Ihrer Compute-Knotengruppe konfiguriert werden, damit Rechenknoten mit dem Controller kommunizieren können.
### Fehlende NVIDIA-Treiber
Wenn die Instanz korrekt bootet, Jobs aber nicht gestartet werden und Sie in Ihren Instanzprotokollen Fehlermeldungen wie die folgenden sehen, fehlen Ihnen möglicherweise NVIDIA-Treiber:
```
<13>Dec 2 13:52:00 user-data: [2024-12-02T13:52:00.094+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_config_always.sh: INFO: nvidia-smi not found!
...
<13>Dec 2 13:54:10 user-data: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.
<13>Dec 2 13:54:12 user-data: [2024-12-02T13:54:12.718+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_finalize.sh: INFO: systemctl could not start slurmd!
```
Wenn Sie eine Verbindung mit der Instanz herstellen und den `slurmd` Daemon-Status überprüfen, wird möglicherweise ein Fehler ähnlich dem folgenden angezeigt:
```
$ systemctl status slurmd
...
fatal: can't stat gres.conf file /dev/nvidia0: No such file or directory
```
Um dieses Problem zu beheben, installieren Sie NVIDIA-Treiber auf Ihrem benutzerdefinierten AMI. Weitere Informationen finden Sie unter [Schritt 4 — (Optional) Zusätzliche Treiber, Bibliotheken und Anwendungssoftware installieren](working-with_ami_custom_install-software.md).
### ResumeTimeout erreicht
Wenn ein Rechenknoten und seine EC2-Instance beendet werden, weil der Knoten fehlerhaft ist, unterstützt AWS PCS das AMI möglicherweise nicht, oder es liegen Netzwerkprobleme vor. Die EC2-Instance läuft ungefähr 30 Minuten lang, bis der Slurm-Wert erreicht ResumeTimeout ist, und markiert den Knoten als. `DOWN`
Wenn die Instance nicht korrekt bootet und nicht bei AWS PCS registriert ist (kein `RegisterComputeNodeGroupInstance` Aufruf für die EC2-Instance), überprüfen Sie Ihre Instance-Logs auf Fehlermeldungen, die den folgenden ähneln:
```
/opt/aws/pcs/bin/pcs_bootstrap_init.sh: No such file or directory
```
Dieser Fehler weist darauf hin, dass die AWS PCS-Bootstrap-Software nicht Teil des AMI ist. Um dieses Problem zu beheben, stellen Sie sicher, dass Ihr benutzerdefiniertes AMI die AWS PCS-Bootstrap-Software enthält. Weitere Informationen finden Sie unter [Benutzerdefinierte Amazon Machine Images (AMIs) für AWS PCS](working-with_ami_custom.md).
### Slurmctld kann den Computerknoten nicht pingen
Wenn die Instanz die Bootstrap-Prozedur korrekt ausführt und bei AWS PCS registriert ist, sie aber `slurmctld` nicht sehen und keine Jobs an sie senden kann, wird die Instanz `DOWN` nach einiger Zeit auf eingestellt und dann beendet.
Dies kann durch falsch konfigurierte Sicherheitsgruppen verursacht werden. Zum Beispiel, wenn Port 6817 für die Kommunikation mit aktiviert ist`slurmctld`, aber Port 6818 fehlt, `slurmd` um Ping zu ermöglichen`slurmctld`. `slurmd`
Stellen Sie sicher, dass Ihre Sicherheitsgruppen alle erforderlichen Regeln enthalten, wie unter beschrieben. [Anforderungen und Überlegungen zur Sicherheitsgruppe](working-with_networking_sg.md#working-with_networking_sg-requirements)