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 AWS STCK

Wenn Rechenknoten beim Bootstrap oder bei der Registrierung in Ihrem AWS PCS-Cluster nicht ordnungsgemäß ausgeführt werden, treten möglicherweise die folgenden Symptome auf:

Diese Fehler können durch Probleme beim Start der EC2-Instance oder während des AWS PCS-Rechenknoten-Bootstrap-Vorgangs verursacht werden. In diesem Thema werden Verfahren beschrieben, die Ihnen bei der Behebung von Problemen während des AWS PCS-Knoten-Bootstrap-Vorgangs helfen. Weitere Informationen zur Fehlerbehebung beim Start von EC2-Instances finden Sie unter Problembehandlung bei Startproblemen bei Amazon EC2-Instances im Amazon Elastic Compute Cloud-Benutzerhandbuch.

Bootstrap-Fehler treten auf, wenn eine EC2-Instance erfolgreich gestartet wird, aber während des Beitritts zum PCS-Cluster fehlschlägt. AWS Der Bootstrap-Prozess umfasst zwei Hauptphasen:

Wie funktioniert Slurm auf AWS 2 STCK

Es könnte Ihnen helfen, die Standardfunktion von Slurm mit der Funktionsweise von Slurm auf AWS PCS zu vergleichen.

Standardverarbeitung von Slurm-Aufträgen

Die folgenden Schritte finden bei der Standardverarbeitung von Slurm-Aufträgen statt:

Die Verarbeitung von Slurm-Jobs ist aktiviert AWS 5 STCK

Die folgenden Schritte finden bei der AWS PCS-Auftragsverarbeitung statt:

Rufen Sie Instanzprotokolle ab

Der erste Schritt bei der Behebung von Rechenknoten-Bootstrap-Problemen besteht darin, die Instanzprotokolle abzurufen. Sie können eine der folgenden Methoden verwenden:

AWS CLI

Rufen Sie die Konsolenausgabe mit dem folgenden Befehl vom Rechenknoten ab:

aws ec2 get-console-output --region us-east-1 --instance-id i-1234567890abcdef0 --output text

us-east-1Ersetzen Sie durch Ihre AWS Region und i-1234567890abcdef0 durch Ihre Instanz-ID.

AWS Systems Manager

Wenn Sie mithilfe des 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 Verbindung zur Instanz her. Weitere Informationen finden Sie unter Starten einer Sitzung im Systems Manager-Benutzerhandbuch.

2. 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 zur Instance herstellen können. Systems Manager- und SSH-Dienste werden erst gestartet, nachdem die Initialisierung abgeschlossen ist oder wenn bei der Bootstrap-Ausführung im Falle eines Fehlers ein Timeout erreicht wird.

Ruft 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-IDs nicht kennen, finden Sie weitere Informationen unter. Suchen nach Rechenknotengruppeninstanzen in AWS PCS

AWS-Managementkonsole

So rufen Sie VPC-, Subnetz- und Sicherheitsgruppen ab

1. Öffnen Sie die Amazon EC2-Konsole.

2. Wählen Sie Instances.

3. Wählen Sie in der Instanzentabelle die Instanz-ID aus.

4. Suchen Sie in der angezeigten Instanzübersicht für die Instance nach der VPC-ID und Subnetz-ID.

5. Wählen Sie in der Instanzübersicht den Tab Security aus.

6. 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 Node-Registrierung

Die Knotenregistrierung ist die erste Aktion, die von einem Rechenknoten während des Bootstraps ausgeführt wird. Der Knoten ruft den AWS PCS-API-Endpunkt auf, um sich selbst bei AWS PCS zu registrieren. Bei Registrierungsfehlern werden normalerweise 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 <clusterId>
<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::<accountId>:assumed-role/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> 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 dem Rechenknoten zugeordnete Instanzprofil über die pcs:RegisterComputeNodeGroupInstance entsprechende Berechtigung verfügt. Weitere Informationen zum Erstellen eines gültigen Instanzprofils finden Sie unterErstellen Sie ein Instanzprofil für AWS STCK.

Es kann keine Verbindung hergestellt werden AWS PCS-Endpunkte

Wenn sich Ihre Rechenknoten in einem privaten Subnetz befinden, stellen Sie sicher, dass Sie VPC-Endpunkte für PCS konfiguriert haben. AWS Stellen Sie alternativ sicher, dass Ihr Subnetz eine Route zu einem NAT-Gateway für den Internetzugang hat. Standardmäßig verwendet der AWS PCS-Agent den Dual-Stack-Endpunkt ohne FIPS. pcs.region.api.aws Wenn Sie benutzerdefiniertes DNS verwenden, stellen Sie sicher, dass es pcs.region.api.aws zum Endpunkt aufgelöst werden kann. Weitere Informationen finden Sie hier:

Falsch konfiguriert AWS PCS-Endpunkt

Wenn eine Fehlermeldung ähnlich der folgenden angezeigt wird, ü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/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> 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 mithilfe eines Schnittstellenendpunkts (AWS PrivateLink)

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.

Instances in einem Subnetz mit einem Internet-Gateway müssen eine öffentliche IP-Adresse haben. Um dieses Problem zu beheben, wählen Sie eine der folgenden Optionen:

Multi-NIC Instanz in einem öffentlichen Subnetz

Sie müssen ein privates Subnetz verwenden, wenn Sie einen Instance-Typ verwenden, der über mehrere Netzwerkschnittstellen (NICs) verfügt.

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 Start der Instance im Amazon EC2-Benutzerhandbuch für Linux-Instances.

Multi-NIC Instance-Typen 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 gemeinsame Slurm-Geheimnis im 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 gemeinsames Slurm-Geheimnis im AWS Secrets Manager (mit dem Namensformat:pcs!slurm-secret-<cluster-id>), wenn Sie einen Cluster erstellen. Dieses Geheimnis ist für die sichere Kommunikation im Cluster erforderlich. Weitere Informationen finden Sie unter Arbeiten mit Cluster-Geheimnissen in AWS STCK.

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 undslurmdbd) 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 innerhalb des Wiederherstellungsfensters befindet. Eine ausführliche Anleitung finden Sie unter Wiederherstellen eines AWS Secrets Manager-Geheimnisses.

Wenn das Wiederherstellungsfenster abläuft, kann das Secret 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-Geheimnis.

Probleme beim Verbinden des Slurm-Clusters

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 Slurm-Join-Fehlern werden normalerweise Fehlermeldungen ähnlich den folgenden angezeigt:

<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:

Weitere Informationen zu den Anforderungen von Sicherheitsgruppen finden Sie in den folgenden Themen:

Fehlende NVIDIA-Treiber

Wenn die Instance korrekt bootet, Jobs aber nicht starten und Sie in Ihren Instance-Protokollen Fehlermeldungen ähnlich den 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 zur Instance 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.

ResumeTimeout erreicht

Wenn ein Rechenknoten und seine EC2-Instance beendet werden, weil der Knoten defekt ist, unterstützt AWS PCS das AMI möglicherweise nicht oder es liegen Netzwerkprobleme vor. Die EC2-Instance läuft ungefähr 30 Minuten, bis Slurms erreicht ResumeTimeout ist und den Knoten als markiert. 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-Protokolle 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.

Slurmctld kann den Rechenknoten 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 auf DOWN Nach einiger Zeit gesetzt und dann beendet.

Dies kann durch falsch konfigurierte Sicherheitsgruppen verursacht werden. Zum Beispiel, wenn Port 6817 für die Kommunikation mit Port 6817 aktiviert istslurmctld, Port 6818 jedoch fehlt, um Ping zuzulassenslurmctld. slurmd slurmd

Stellen Sie sicher, dass Ihre Sicherheitsgruppen alle erforderlichen Regeln enthalten, wie unter beschrieben. Anforderungen und Überlegungen zur Sicherheitsgruppe