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 installiert wurden Slurm Job-Scheduler. Weitere Hinweise zur Konfiguration mehrerer Warteschlangen finden Sie unter. Konfiguration mehrerer Warteschlangen
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 Befehl verwenden und mit einem private-dns-name
der ausfallenden Knoten oder dem Hauptknoten filtern:
$
pcluster list-cluster-log-streams --cluster-name
mycluster
--regioneu-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 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
\ --regioneu-west-1
--log-stream-nameip-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 und CloudWatch Amazon-Dashboard.
Themen
- Wichtige Protokolle für das Debuggen
- 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
- Behebung von Problemen bei der Knoteninitialisierung
- Behebung unerwarteter Knotenersetzungen und -beendigungen
- Ersetzen, Beenden oder Herunterfahren problematischer Instanzen und Knoten
- Status der Warteschlange (Partition) Inactive
- Behebung anderer bekannter Knoten- und Jobprobleme
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 AWS CloudFormation Init-Log. 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 CINC Chef/ ausgeführt wurden. Verwenden Sie es, um Initialisierungsprobleme zu beheben. -
/var/log/parallelcluster/slurm_resume.log
- Das ist einResumeProgram
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 dasSuspendProgram
Protokoll. Es wird aufgerufen, wenn Instanzen für dynamische Knoten beendet werden. Verwenden Sie es, um Probleme mit der Terminierung dynamischer Knoten zu beheben. Wenn Sie dieses Protokoll überprüfen, sollten Sie auch dasclustermgtd
Protokoll überprüfen. -
/var/log/parallelcluster/clustermgtd
- Das ist dasclustermgtd
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
- Das ist der Slurm steuere das Daemon-Protokoll. AWS ParallelCluster trifft keine Skalierungsentscheidungen. Vielmehr versucht es nur, Ressourcen bereitzustellen, um die Slurm Anforderungen. Es ist nützlich bei Skalierungs- und Zuweisungsproblemen, auftragsbezogenen Problemen und allen Problemen im Zusammenhang 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. Dercompute_console_output log
Inhalt, den Sie erhalten, ist derselbe, wenn Sie die EC2 Amazon-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. 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 dascomputemgtd
Protokoll. Es läuft auf jedem Rechenknoten und überwacht den Knoten für den seltenen Fall, dass derclustermgtd
Daemon auf dem Hauptknoten offline ist. Verwenden Sie ihn, um unerwartete Terminierungsprobleme zu beheben. -
/var/log/slurmd.log
- Das ist der Slurm berechnet das 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 eine verwendet Slurm Scheduler, Sie haben ein Problem mit unzureichender Kapazität. 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.
-
Reservieren Sie Kapazität für die Instances und starten Sie sie mit ODCR (Kapazitätsreservierungen auf Abruf). Weitere Informationen finden Sie unter Starten Sie Instances mit On-Demand-Kapazitätsreservierungen (ODCR).
-
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.
-
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 und Scheduling/SlurmQueues/ComputeResources/Instances.
-
Verschieben Sie die Warteschlange in eine andere Availability Zone, indem Sie die Subnetz-ID in der Cluster-Konfiguration ändern 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//SlurmQueuesNetworking/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.
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 diese Art von 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 eine benutzerdefinierte Version AMI mit Änderungen an der verwenden Slurm Konfiguration, dann könnte es eine geben Slurmverwandter Fehler, der verhindert, dass der Rechenknoten dem Cluster beitritt. Informationen zu Fehlern im Zusammenhang mit dem Scheduler finden Sie im
/var/log/slurmd.log
Protokoll.
Dynamische Rechenknoten:
-
Suchen Sie in
ResumeProgram
log (/var/log/parallelcluster/slurm_resume.log
) nach dem Namen Ihres Rechenknotens, um zu sehen, ob der Knoten jemals aufgerufenResumeProgram
wurde. (FallsResumeProgram
es noch nie aufgerufen wurde, können Sie anhand desslurmctld
Logs (/var/log/slurmctld.log
) nachsehen, ob Slurm jemals versucht,ResumeProgram
mit dem Knoten anzurufen). -
Beachten Sie, dass falsche Berechtigungen für
ResumeProgram
dazu führenResumeProgram
können, dass der Fehler automatisch fehlschlägt. Wenn Sie ein benutzerdefiniertes Objekt AMI mit Änderungen amResumeProgram
Setup verwenden, überprüfen Sie, ob das demslurm
BenutzerResumeProgram
gehört und über die Berechtigung744
(rwxr--r--
) verfügt. -
Wenn aufgerufen
ResumeProgram
wird, überprüfen Sie, ob eine Instanz 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 im AWS ParallelCluster Benutzerhandbuch und unter Service-verknüpfte Rolle für Spot-Instance-Anfragen im EC2Amazon-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 Knotenclustermgtd
ersetzt oder beendet wurde. Beachten Sie, dass alle normalen Wartungsaktionen für Knotenclustermgtd
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 istDOWN
), schauen Sie imslurmctld
Protokoll nach, um weitere Informationen zu erhalten. Wenn der Grund auf Amazon EC2 zurückzuführen ist, sollte eine informative Nachricht angezeigt werden, in der das Problem EC2 im Zusammenhang mit Amazon beschrieben wird, für das der Ersatz erforderlich war. -
Wenn der Knoten
clustermgtd
nicht beendet wurde, überprüfen Sie zunächst, ob es sich um eine erwartete Kündigung durch Amazon handeltEC2, genauer gesagt um eine Spot-Terminierung.computemgtd
, der auf einem Rechenknoten läuft, kann einen Knoten auch beenden, wenn er als fehlerhaft eingestuftclustermgtd
wird. Prüfen Siecomputemgtd
log (/var/log/parallelcluster/computemgtd
), um zu sehen, ob der Knotencomputemgtd
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 Minutenclustermgtd
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 zur Vermietung ein Slurm einen neuen Knoten einrichten.
-
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 imclustermgtd
Protokoll nach, warum ein Knoten nicht ersetzt oder beendet werden konnte. -
Wenn dynamische Knoten ausfallenSlurmSettingsEigenschaften, schauen Sie im
SuspendProgram
Protokoll nach, ob der spezifische Knoten als Argument aufgerufenSuspendProgram
wurde.slurmctld
Beachten Sie, dass tatsächlichSuspendProgram
keine Aktion ausgeführt wird. Vielmehr protokolliert es nur, wenn es aufgerufen wird. Das Beenden undNodeAddr
Zurücksetzen aller Instanzen erfolgt vonclustermgtd
. Slurm versetzt Knoten danachSuspendTimeout
automatisch wieder in einenPOWER_SAVING
Zustand. -
Wenn Rechenknoten aufgrund von Bootstrap-Fehlern ständig ausfallen, überprüfen Sie, ob sie mit Slurmgeschützter Cluster-Modus 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 werdeninact
, wurde Ihr Cluster möglicherweise Slurmgeschützter Cluster-Modus 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 entsprechend gestartet, beendet oder verwaltet Slurm Anweisungen. Überprüfen Sie bei diesen Problemen das slurmctld
Protokoll, um sie zu beheben.