Behebung von Skalierungsproblemen

• /var/log/cfn-init.log- Dies ist das CloudFormation Init-Log. Es enthält alle Befehle, die beim Einrichten 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 ausgeführt wurden Chef/CINC. 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 Starten 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 wird als zentralisierter Daemon ausgeführt, der die meisten Cluster-Betriebsaktionen verwaltet. Verwenden Sie ihn, um Probleme beim Starten, Beenden oder Clusterbetrieb zu beheben.

• /var/log/slurmctld.log- Dies ist das Slurm Control Daemon-Protokoll. AWS ParallelCluster trifft keine Skalierungsentscheidungen. Vielmehr versucht es nur, Ressourcen bereitzustellen, um die Slurm Anforderungen zu erfüllen. Es ist nützlich bei Skalierungs- und Zuweisungsproblemen, auftragsbezogenen Problemen und allen Problemen im Zusammenhang mit dem Start und der Beendigung des Terminplans.

• /var/log/parallelcluster/compute_console_output- Dieses Protokoll zeichnet die Konsolenausgabe einer Beispielteilmenge statischer Rechenknoten auf, 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 Amazon EC2-Konsole verwenden oder AWS CLI die Ausgabe der Instance-Konsole abrufen.

• /var/log/cloud-init-output.log- Das ist das Cloud-Init-Log. Es enthält alle Befehle, die beim Einrichten einer Instanz ausgeführt wurden. Verwenden Sie es, um Initialisierungsprobleme zu beheben.

• /var/log/parallelcluster/computemgtd- Das ist das computemgtd Protokoll. Es wird auf jedem Rechenknoten ausgeführt, um den Knoten in dem seltenen Fall zu überwachen, dass der clustermgtd Daemon auf dem Hauptknoten offline ist. Verwenden Sie es, um unerwartete Abschlussprobleme zu beheben.

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

Je nach Anwendungsfall sollten Sie erwägen, eine der folgenden Methoden zu verwenden, um diese Art von Fehlermeldungen zu vermeiden:

• Deaktivieren Sie die Platzierungsgruppe, falls sie aktiviert ist. Weitere Informationen finden Sie unter Probleme beim Start von Placement-Gruppen und Instances.

• Reservieren Sie Kapazität für die Instances und starten Sie sie mit ODCR (On-Demand Capacity Reservations). Weitere Informationen finden Sie unter Instances mit On-Demand Kapazitätsreservierungen (ODCR) starten.

• Konfigurieren Sie mehrere Rechenressourcen mit unterschiedlichen Instanztypen. Wenn für Ihre Arbeitslast kein bestimmter Instanztyp erforderlich ist, können Sie das schnelle Failover bei 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 Clusterkonfiguration Scheduling//SlurmQueuesNetworking/SubnetIdsändern.

• 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, welcher 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 Log befinden. Wenn in der Clusterkonfiguration Skripts für die Vor- oder Nachinstallation angegeben sind, überprüfen Sie, ob sie erfolgreich ausgeführt wurden.

• Wenn Sie ein benutzerdefiniertes AMI mit Änderungen an der Slurm Konfiguration verwenden, liegt möglicherweise ein Slurm entsprechender Fehler vor, der verhindert, dass der Rechenknoten dem Cluster beitritt. Überprüfen Sie das Protokoll auf Fehler im Zusammenhang mit dem /var/log/slurmd.log Scheduler.

• Suchen ResumeProgram Sie im Log (/var/log/parallelcluster/slurm_resume.log) nach dem Namen Ihres Rechenknotens, um festzustellen, ob der Knoten jemals aufgerufen ResumeProgram wurde. (Falls ResumeProgram es noch nie aufgerufen wurde, können Sie anhand von slurmctld log (/var/log/slurmctld.log) überprüfen, ob Sie Slurm jemals versucht haben, ResumeProgram mit dem Knoten aufzurufen).

• Beachten Sie, dass falsche Berechtigungen für dazu führen ResumeProgram können, dass ResumeProgram unbeaufsichtigte Fehler auftreten. 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 Berechtigung 744 (rwxr--r--) 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 während des Einrichtungsvorgangs ein Problem 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 Rechenknoten finden Sie im nächsten Abschnitt.

• Prüfen Sie im clustermgtd (/var/log/parallelcluster/clustermgtd) -Protokoll, 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, gibt es während des Einrichtungsvorgangs ein Problem. 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 weiterhin einen PD-Status (ausstehend) hat, ü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-linked Rolle für Spot-Instance-Anfragen im Amazon EC2-Benutzerhandbuch.

• Anwendbare Protokolle:

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

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

  • /var/log/parallelcluster/computemgtd(Knoten berechnen)

• Prüfen Sie im clustermgtd Protokoll (/var/log/parallelcluster/clustermgtd), ob ein Knoten clustermgtd ersetzt oder beendet wurde. Beachten Sie, dass clustermgtd damit alle normalen Wartungsarbeiten am Knoten durchgeführt werden.

• Wenn der Knoten clustermgtd ersetzt oder beendet wurde, sollte eine Meldung angezeigt werden, 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 aktiviert istDOWN), finden Sie weitere Informationen im slurmctld Log-In. Wenn der Grund mit Amazon EC2 zusammenhängt, sollte es eine informative Meldung geben, in der das Amazon EC2-Problem beschrieben wird, das den Austausch erforderlich machte.

• Wenn der Knoten clustermgtd nicht beendet wurde, überprüfen Sie zunächst, ob es sich um eine erwartete Kündigung durch Amazon EC2 handelte, genauer gesagt um eine Spot-Kündigung. computemgtd, das auf einem Rechenknoten läuft, kann auch einen Knoten beenden, wenn dieser als clustermgtd fehlerhaft eingestuft wird. Prüfen Sie computemgtd log (/var/log/parallelcluster/computemgtd), um zu sehen, ob der Knoten computemgtd beendet wurde.

• Checken Sie in slurmctld log (/var/log/slurmctld.log) ein, um zu sehen, warum ein Job oder ein Knoten ausgefallen ist. Beachten Sie, dass Jobs automatisch erneut in die Warteschlange gestellt werden, wenn ein Knoten ausfällt.

• Wenn gemeldet slurm_resume wird, dass der Knoten gestartet wurde, und nach einigen Minuten clustermgtd meldet, dass es in Amazon EC2 für diesen Knoten keine entsprechende Instance 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 der Instanz so, dass ein ausgefallener 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

  • Markieren 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)

• In den meisten Fällen werden alle erwarteten Aktionen zum Beenden der Instanz clustermgtd verarbeitet. Schauen Sie im clustermgtd Protokoll nach, warum ein Knoten nicht ersetzt oder beendet werden konnte.

• Wenn dynamische Knoten ausfallenSlurmSettingsEigenschaften, überprüfen Sie im SuspendProgram Protokoll, ob der Aufruf von slurmctld mit dem spezifischen Knoten als Argument ausgeführt SuspendProgram wurde. Beachten Sie, dass damit eigentlich SuspendProgram keine Aktion ausgeführt wird. Vielmehr protokolliert es nur, wenn es aufgerufen wird. Das Beenden und NodeAddr Zurücksetzen aller Instanzen erfolgt durchclustermgtd. Slurmversetzt Knoten SuspendTimeout automatisch wieder in einen POWER_SAVING Zustand nach dem Ende.

• 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. Führen Sie eine Problembehandlung durch und korrigieren Sie das Bootstrap-Skript.