Behebung von Skalierungsproblemen - AWS ParallelCluster

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 --region eu-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 \ --region eu-west-1 --log-stream-name ip-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.

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

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

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 aufgerufen ResumeProgram wurde. (Falls ResumeProgram es noch nie aufgerufen wurde, können Sie anhand des slurmctld 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ühren ResumeProgram können, dass der Fehler automatisch fehlschlägt. Wenn Sie ein benutzerdefiniertes Objekt 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 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 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 handeltEC2, 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.

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