Beheben Sie Probleme mit dem Bootstrap und der Registrierung von Rechenknoten in PCS AWS - AWS PCS

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

  2. Weist vorhandene Knoten zu, sobald Ressourcen verfügbar sindslurmctld.

  3. slurmdDaemons 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.

  2. Wenn zusätzliche Kapazität benötigt wird, verwendet AWS PCS die Startvorlage für die Compute-Knotengruppe, um neue EC2-Instances zu starten.

  3. Neue Instanzen starten per Bootstrap in den Cluster:

    1. Instanzen registrieren sich bei AWS PCS.

    2. Instanzen treten dem Slurm-Cluster bei.

  4. Wenn die Ressourcen bereit sind, slurmctld weist sie Knoten zu (einschließlich der Knoten, die neu gebootet wurden).

  5. slurmdDaemons 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-1Ersetzen Sie es durch Ihre AWS Region und i-1234567890abcdef0 durch Ihre Instance-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 im Systems Manager 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 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 Compute-Knotengruppeninstanzen in AWS PCS

AWS-Managementkonsole
Um VPC-, Subnetz- und Sicherheitsgruppen abzurufen
  1. Öffnen Sie die Amazon EC2-Konsole.

  2. Wählen Sie Instances.

  3. Wählen Sie in der Tabelle Instances die Instance-ID aus.

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

  5. Wählen Sie in der Instanzübersicht die Registerkarte Sicherheit 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 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 <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 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 unterErstellen Sie ein Instanzprofil für AWS PCS.

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:

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/<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 über einen Schnittstellenendpunkt (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.

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

Probleme beim Beitritt zu 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:

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

ResumeTimeouterreicht

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.

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 istslurmctld, aber Port 6818 fehlt, slurmd um Ping zu ermöglichenslurmctld. slurmd

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