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.

Fehlerbehebung AWS Aktualisierungen der PCS-Cluster-Versionen

Dieses Thema hilft Ihnen dabei, häufig auftretende Probleme zu identifizieren und zu lösen, die bei der Aktualisierung der Scheduler-Version auf einem Cluster auftreten können.

Rechenknoten können nach dem Update keine Verbindung herstellen

Häufige Ursache

Nach der Aktualisierung des Clusters können sich neu gestartete Rechenknoten nicht beim Controller registrieren. Die Knoten werden gestartet, erscheinen aber nie in der sinfo Ausgabe, und die Compute-Knotengruppe durchläuft möglicherweise wiederholt Instanzen. Dies tritt auf, wenn das AMI der Compute-Knotengruppe eine Scheduler-Version enthält, die außerhalb des Kompatibilitätsfensters der neuen Controller-Version liegt.

Wenn Sie beispielsweise einen Cluster von 24.11 auf 25.11 aktualisieren, die Compute-Knotengruppe aber immer noch ein AMI mit Slurm 23.11 verwendet, können neue Instances keine Verbindung herstellen, da 23.11 außerhalb des Kompatibilitätsfensters von 25.11 liegt.

Wie diagnostiziert man

Sie können dieses Problem anhand der Logs an zwei Stellen überprüfen:

Scheduler-Protokolle

Wenn Sie die Scheduler-Protokollierung aktiviert haben, überprüfen Sie die Scheduler-Protokolle unter Logs auf CloudWatch Fehler, die den folgenden ähneln:

error: unpack_header: protocol_version 10240 not supported
error: slurm_unpack_received_msg: [ip-10-0-1-23] Incompatible versions of client and server code

Diese Fehler deuten darauf hin, dass ein Rechenknoten mit einer inkompatiblen Scheduler-Version versucht, eine Verbindung zum Controller herzustellen. Hinweise zum Einrichten der Scheduler-Protokollierung finden Sie unter. Scheduler loggt sich in AWS PCS ein

Logs für Knoteninstanzen berechnen

Rufen Sie die Ausgabe der Instanzkonsole ab oder stellen Sie eine Verbindung über Systems Manager her und überprüfen Sie das Bootstrap-Protokoll auf Fehler, die den folgenden ähneln:

error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server
error: _establish_configuration: failed to load configs
error: slurmd initialization failed

Weitere Informationen zum Abrufen von Instanzprotokollen finden Sie unter. Instanzprotokolle abrufen

Auflösung

Aktualisieren Sie die Compute-Knotengruppe, um ein AMI zu verwenden, das eine Scheduler-Version im Kompatibilitätsfenster Ihrer neuen Cluster-Version enthält:

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

Informationen darüber, welche Scheduler-Versionen mit Ihrem Cluster kompatibel sind, finden Sie unter. Versionskompatibilität

Informationen zum Erstellen benutzerdefinierter AMIs mit der richtigen Scheduler-Version finden Sie unter. Amazon Machine Images (AMIs) für AWS STK.

Aktualisierungsanfrage abgelehnt mit ValidationException

Häufige Ursache

Die UpdateCluster Anfrage kehrt sofort mit einem ValidationException Fehler zurück, der darauf hinweist, dass das Update nicht unterstützt wird. Dies tritt auf, wenn:

Auflösung

Wenn sich die Zielversion außerhalb des Kompatibilitätsfensters befindet, führen Sie das Update in mehreren Schritten durch. Jeder Schritt muss auf eine unterstützte Version innerhalb des Kompatibilitätsfensters abzielen. Um beispielsweise von 23.11 auf 25.11 zu wechseln, aktualisieren Sie zuerst auf 25.05, warten Sie, bis der Cluster wieder auf 25.11 zurückkehrt, und aktualisieren Sie dann auf ACTIVE 25.11.

Wenn die Zielversion EOL ist, wählen Sie stattdessen eine neuere unterstützte Version. Informationen zu unterstützten Versionen finden Sie unterSlurm-Versionen in AWS STK..

Der Cluster befindet sich weiterhin im Status UPDATE

Häufige Ursache

Der Cluster bleibt länger als erwartet im UPDATING Status (mehr als 20 Minuten). Dies kann aufgrund vorübergehender interner Probleme während des Aktualisierungsvorgangs auftreten.

Auflösung

AWS PCS stellt automatisch Cluster wieder her, die im UPDATING Status feststecken. Wenn der Cluster nicht zu ACTIVE oder UPDATE_FAILED innerhalb von 30 Minuten zurückkehrt, wenden Sie sich an den AWS Support, um Unterstützung zu erhalten.

Nach dem Update wechselt der Cluster in den Status UPDATE_FAILED

Häufige Ursache

Der Cluster wechselt während des Updates in den UPDATE_FAILED Status. Dies kann der Fall sein, wenn vorübergehende Dienstfehler verhindern, dass das Update erfolgreich abgeschlossen wird.

Auflösung

Versuchen Sie das Update erneut, indem Sie dieselbe UpdateCluster Anfrage erneut senden. Cluster im UPDATE_FAILED Status akzeptieren neue Aktualisierungsanfragen. Wenn das Update weiterhin fehlschlägt, wenden Sie sich an den AWS Support.

Rechenknoten können aufgrund von Fehlern bei der Konfigurationsanalyse nicht gestartet werden

Häufige Ursache

Nach der Aktualisierung des Clusters können die Rechenknoten nicht gestartet werden und erscheinen nie in der sinfo Ausgabe. In den Protokollen der Compute-Knoteninstanz werden Fehler angezeigt, die den folgenden ähneln:

error: _parse_next_key: Parsing error at unrecognized key: HashPlugin
error: Invalid DebugFlag: AuditRPCs
fatal: Unable to process configuration file

Dies tritt auf, wenn Compute-Knoten, auf denen die Scheduler-Version 23.11 ausgeführt wird, eine Konfiguration von einer neueren Cluster-Version erhalten. In Scheduler-Versionen nach 23.11 wurden neue Konfigurationsdirektiven eingeführt, die 23.11 nicht analysieren kann. Im Gegensatz zu anderen Versionen innerhalb des Kompatibilitätsfensters können 23.11-Compute-Knoten keine Verbindung zu einem neueren Cluster herstellen, da sie bei unbekannten Konfigurationsschlüsseln fatale Fehler machen.

Dieses Problem kann auch auftreten, wenn Ihr benutzerdefiniertes AMI eine AWS PCS-Agent-Version verwendet, die älter als v1.4.0 ist. Ältere Agentenversionen unterstützen keinen automatischen Versions-Fallback für den Compute Node Daemon.

Auflösung

Erstellen Sie Ihr benutzerdefiniertes AMI mit den folgenden Anforderungen neu:

Aktualisieren Sie dann die Compute-Knotengruppe, um das neue AMI zu verwenden:

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

Informationen zum Erstellen benutzerdefinierter AMIs finden Sie unterAmazon Machine Images (AMIs) für AWS STK.. Informationen zu den Versionen von AWS PCS-Agenten finden Sie unterAWS Versionen von PCS-Agenten.

Cluster nach dem Update aufgrund einer ungültigen QoS-Konfiguration nicht verfügbar

Häufige Ursache

Nach dem Update auf Version 25.11 wechselt der Cluster in den UPDATE_FAILED Status oder der Scheduler ist nicht mehr verfügbar. Sie können keine Jobs einreichen oder Scheduler-Befehle ausführen. Die Scheduler-Protokolle zeigen Fehler, die den folgenden ähneln:

error: Invalid Allow/DenyQOS value: low
fatal: Partition my-queue has an invalid DenyQOS (low), please check your configuration

Dies tritt auf, wenn eine Warteschlange (Partition) überAllowQOS,, oder QOS Einstellungen auf einen QoS-Namen verweistDenyQOS, die in der Slurm-Accounting-Datenbank nicht vorhanden sind. Slurm 25.11 führte eine strengere Validierung von QoS-Referenzen beim Start des Schedulers ein. Frühere Versionen erlaubten Verweise auf nicht existierende QoS-Namen ohne Fehler.

Auflösung

Stellen Sie vor dem Update auf Version 25.11 sicher, dass alle QoS-Namen, auf die in Ihren Warteschlangenkonfigurationen verwiesen wird, in der Accounting-Datenbank vorhanden sind. Stellen Sie eine Connect zu einem Anmeldeknoten her und führen Sie den folgenden Befehl aus, um zu überprüfen, ob eine QoS vorhanden ist:

sacctmgr show qos where name=low format=name

Wenn die QoS nicht existiert, erstellen Sie sie, bevor Sie das Update versuchen:

sacctmgr add qos low

Alternativ können Sie die QoS-Referenz aus Ihrer Warteschlangenkonfiguration entfernen, indem Sie die benutzerdefinierten Slurm-Einstellungen der Warteschlange aktualisieren, um den QOS ParameterAllowQOS, oder zu entfernenDenyQOS, bevor Sie den Cluster aktualisieren.