Behebung von Skalierungsproblemen

• /var/log/cfn-init.log- Dies ist das CloudFormation 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/chef-client.log- Dies ist das Chef-Client-Protokoll. Es enthält alle Befehle, die über Chef/Cinc ausgeführt wurden. Verwenden Sie es, um Initialisierungsprobleme zu beheben.

• /var/log/parallelcluster/slurm_resume.log- Das ist ein ResumeProgram 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 das SuspendProgram 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 das clustermgtd Protokoll überprüfen.

• /var/log/parallelcluster/clustermgtd- Das ist das clustermgtd 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- Dies ist das Protokoll des Slurm Kontroll-Daemons. AWS ParallelCluster trifft keine Skalierungsentscheidungen. Vielmehr versucht es nur, Ressourcen bereitzustellen, um die Slurm Anforderungen zu erfüllen. Dies ist nützlich bei Problemen mit der Skalierung und Zuweisung, bei Problemen im Zusammenhang mit Aufträgen sowie bei Problemen 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. Der compute_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.

• /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 das computemgtd Protokoll. Es läuft auf jedem Rechenknoten und überwacht den Knoten für den seltenen Fall, dass der clustermgtd Daemon auf dem Hauptknoten offline ist. Verwenden Sie ihn, um unerwartete Terminierungsprobleme zu beheben.

• /var/log/slurmd.log- Dies ist das Slurm Compute-Daemon-Protokoll. Verwenden Sie es, um Probleme mit der Initialisierung und Rechenfehlern zu beheben.

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 (On-Demand-Kapazitätsreservierungen). 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.

• /var/log/cfn-init.log

• /var/log/chef-client.log

• /var/log/parallelcluster/clustermgtd

• /var/log/parallelcluster/slurm_resume.log

• /var/log/slurmctld.log

• 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 ein benutzerdefiniertes AMI mit Änderung der Slurm Konfiguration verwenden, liegt möglicherweise ein Slurm verwandter Fehler vor, der verhindert, dass der Compute-Knoten dem Cluster beitritt. Informationen zu Fehlern im Zusammenhang mit dem Scheduler finden Sie im /var/log/slurmd.log Protokoll.

• Suchen Sie in ResumeProgram log (/var/log/parallelcluster/slurm_resume.log) nach Ihrem Compute-Knotennamen, um zu sehen, ob der Node jemals mit dem Node aufgerufen ResumeProgram wurde. (Falls der Node noch nie aufgerufen ResumeProgram wurde, können Sie anhand des slurmctld Logs (/var/log/slurmctld.log) nachsehen, ob Slurm jemals versucht wurde, ResumeProgram mit dem Node aufzurufen.)

• Beachten Sie, dass falsche Berechtigungen für ResumeProgram dazu führen ResumeProgram können, dass der Fehler automatisch fehlschlägt. Wenn Sie ein benutzerdefiniertes AMI mit Änderungen am ResumeProgram Setup verwenden, überprüfen Sie, ob das dem slurm Benutzer ResumeProgram gehört und über die 744 (rwxr--r--) -Berechtigung verfügt.

• Wenn aufgerufen ResumeProgram wird, überprüfen Sie, ob eine Instance 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.

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

• 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 EC2 Amazon-Benutzerhandbuch.

• Anwendbare Protokolle:

  • /var/log/parallelcluster/clustermgtd(Kopfknoten)

  • /var/log/slurmctld.log(Kopfknoten)

  • /var/log/parallelcluster/computemgtd(Rechenknoten)

• Prüfen Sie im clustermgtd Protokoll (/var/log/parallelcluster/clustermgtd), ob ein Knoten clustermgtd ersetzt oder beendet wurde. Beachten Sie, dass alle normalen Wartungsaktionen für Knoten clustermgtd 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 im slurmctld 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 handelt EC2 , genauer gesagt um eine Spot-Terminierung. computemgtd, der auf einem Rechenknoten läuft, kann einen Knoten auch beenden, wenn er als fehlerhaft eingestuft clustermgtd wird. Prüfen Sie computemgtd log (/var/log/parallelcluster/computemgtd), um zu sehen, ob der Knoten computemgtd beendet wurde.

• 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 Minuten clustermgtd 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 ein, um einen neuen Knoten hochfahren zu lassenSlurm.

  • 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

• 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 im clustermgtd 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 aufgerufen SuspendProgram wurde. slurmctld Beachten Sie, dass tatsächlich SuspendProgram keine Aktion ausgeführt wird. Vielmehr protokolliert es nur, wenn es aufgerufen wird. Das Beenden und NodeAddr Zurücksetzen aller Instanzen erfolgt vonclustermgtd. Slurmversetzt Knoten danach SuspendTimeout automatisch wieder in einen POWER_SAVING Zustand.

• Wenn Rechenknoten aufgrund von Bootstrap-Fehlern ständig ausfallen, überprüfen Sie, ob sie mit Slurm geschü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.