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. # AWS ParallelCluster Problembehandlung Die AWS ParallelCluster Community unterhält eine Wiki-Seite, die viele Tipps zur Fehlerbehebung im [AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/) enthält. Eine Liste der bekannten Probleme finden Sie unter [Bekannte Probleme](https://github.com/aws/aws-parallelcluster/wiki#known-issues-). **Topics** + [Protokolle abrufen und aufbewahren](#retrieving-and-preserve-logs) + [Behebung von Problemen bei der Stack-Bereitstellung](#troubleshooting-stack-creation-failures) + [Behebung von Problemen in Clustern mit mehreren Warteschlangenmodi](#multiple-queue-mode) + [Behebung von Problemen in Clustern im Single-Queue-Modus](#troubleshooting-issues-in-single-queue-clusters) + [Probleme bei der Platzierung von Gruppen und beim Starten von Instances](#placement-groups-and-instance-launch-issues) + [Verzeichnisse, die nicht ersetzt werden können](#directories-cannot-be-replaced) + [Behebung von Problemen in Amazon DCV](#nice-dcv-troubleshooting) + [Behebung von Problemen in Clustern mit AWS Batch Integration](#clusters-with-aws-batch-integration) + [Fehlerbehebung, wenn eine Ressource nicht erstellt werden kann](#troubleshooting-resource-fails-to-create) + [Behebung von Problemen mit der Größe der IAM-Richtlinie](#troubleshooting-policy-size-issues) + [Zusätzlicher Support](#getting-support) ## Protokolle abrufen und aufbewahren Protokolle sind eine nützliche Ressource zur Behebung von Problemen. Bevor Sie Protokolle zur Behebung von Problemen mit Ihren AWS ParallelCluster Ressourcen verwenden können, sollten Sie zunächst ein Archiv mit Clusterprotokollen erstellen. Folgen Sie den Schritten, die im [AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/) im Thema [Erstellen eines Clusterprotokollarchivs](https://github.com/aws/aws-parallelcluster/wiki/Creating-an-Archive-of-a-Cluster's-Logs) beschrieben sind, um diesen Vorgang zu starten. Wenn bei einem Ihrer laufenden Cluster Probleme auftreten, sollten Sie den Cluster in einen `STOPPED` Zustand versetzen, indem Sie den ``pcluster stop` ` Befehl ausführen, bevor Sie mit der Fehlerbehebung beginnen. Dadurch werden unerwartete Kosten vermieden. Wenn der `pcluster` Cluster nicht mehr funktioniert oder wenn Sie einen Cluster löschen und gleichzeitig seine Protokolle beibehalten möchten, führen Sie den ``pcluster delete` —keep-logs ` Befehl aus. Durch die Ausführung dieses Befehls wird der Cluster gelöscht, die in Amazon CloudWatch gespeicherte Protokollgruppe wird jedoch beibehalten. Weitere Informationen zu diesem Befehl finden Sie in der [`pcluster delete`](pcluster.delete.md) Dokumentation. ## Behebung von Problemen bei der Stack-Bereitstellung Wenn Ihr Cluster nicht erstellt werden kann und die Stack-Erstellung rückgängig gemacht wird, können Sie die folgenden Protokolldateien durchsuchen, um das Problem zu diagnostizieren. Sie möchten `ROLLBACK_IN_PROGRESS` in diesen Protokollen nach der Ausgabe von suchen. Die Fehlermeldung sollte wie folgt aussehen: ``` $ pcluster create mycluster Creating stack named: parallelcluster-mycluster Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::EC2::Instance MasterServer Received FAILURE signal with UniqueId i-07af1cb218dd6a081 ``` Um das Problem zu diagnostizieren, erstellen Sie den Cluster erneut[`pcluster create`](pluster.create.md), einschließlich des `--norollback` Flags. Stellen Sie dann per SSH eine Verbindung zum Cluster her: ``` $ pcluster create mycluster --norollback ... $ pcluster ssh mycluster ``` Nachdem Sie beim Hauptknoten angemeldet sind, sollten Sie drei primäre Protokolldateien finden, anhand derer Sie den Fehler lokalisieren können. + `/var/log/cfn-init.log`ist das Protokoll für das `cfn-init` Skript. Überprüfen Sie zuerst dieses Protokoll. Sie werden wahrscheinlich einen Fehler wie `Command chef failed` in diesem Protokoll sehen. Sehen Sie sich die Zeilen unmittelbar vor dieser Zeile an, um weitere Einzelheiten zu der Fehlermeldung zu erfahren. Weitere Informationen finden Sie unter [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html). + `/var/log/cloud-init.log`[ist das Protokoll für Cloud-Init.](https://cloudinit.readthedocs.io/) Wenn Sie nichts darin sehen, versuchen Sie als `cfn-init.log` Nächstes, in diesem Protokoll nachzuschauen. + `/var/log/cloud-init-output.log`ist die Ausgabe von Befehlen, die von [cloud-init](https://cloudinit.readthedocs.io/) ausgeführt wurden. Dies beinhaltet die Ausgabe von. `cfn-init` In den meisten Fällen müssen Sie sich dieses Protokoll nicht ansehen, um diese Art von Problem zu beheben. ## Behebung von Problemen in Clustern mit mehreren Warteschlangenmodi Dieser Abschnitt ist relevant für Cluster, die mit AWS ParallelCluster Version 2.9.0 und höher mit dem Slurm Job Scheduler installiert wurden. Weitere Informationen zum Modus mit mehreren Warteschlangen finden Sie unter. [Modus mit mehreren Warteschlangen](queue-mode.md) **Topics** + [Wichtige Protokolle](#key-logs) + [**Behebung von Problemen mit der Knoteninitialisierung**](#troubleshooting-node-initialization-issues) + [**Behebung unerwarteter Knotenersetzungen und -beendigungen**](#troubleshooting-unexpected-node-replacements-and-terminations) + [**Probleminstanzen und Knoten ersetzen, beenden oder herunterfahren**](#replacing-terminating-or-powering-down-problematic-instances-and-nodes) + [**Behebung anderer bekannter Knoten- und Jobprobleme**](#troubleshooting-other-known-node-and-job-issues) ### Wichtige Protokolle Die folgende Tabelle bietet einen Überblick über die Schlüsselprotokolle für den Hauptknoten: `/var/log/cfn-init.log` Dies ist das CloudFormation Init-Protokoll. Es enthält alle Befehle, die beim Einrichten einer Instanz ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen. `/var/log/chef-client.log` Dies ist das Chef-Client-Protokoll. Es enthält alle Befehle, die über Chef/Cinc ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen. `/var/log/parallelcluster/slurm_resume.log` Das ist ein `ResumeProgram` Protokoll. Es startet Instances für dynamische Knoten und ist nützlich für die Behebung von Problemen beim Starten dynamischer Knoten. `/var/log/parallelcluster/slurm_suspend.log` Dies ist das `SuspendProgram` Protokoll. Es wird aufgerufen, wenn Instanzen für dynamische Knoten beendet werden, und ist nützlich, 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. Er ist nützlich für die Behebung von Problemen beim Starten, Beenden oder Clusterbetrieb. `/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. Dies sind die wichtigsten Hinweise für die Compute-Knoten: `/var/log/cloud-init-output.log` Dies ist das [Cloud-Init-Protokoll](https://cloudinit.readthedocs.io/). Es enthält alle Befehle, die bei der Einrichtung einer Instanz ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen. `/var/log/parallelcluster/computemgtd` Dies 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. Es ist nützlich bei der Behebung unerwarteter Kündigungsprobleme. `/var/log/slurmd.log` Dies ist das Slurm Compute-Daemon-Protokoll. Es ist nützlich, um Probleme mit der Initialisierung und Rechenfehlern zu beheben. ### **Behebung von Problemen mit 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` und `/var/log/chef-client.log` -Protokolle. Diese Protokolle sollten alle Aktionen enthalten, die bei der Einrichtung des Hauptknotens ausgeführt wurden. Bei den meisten Fehlern, die während der Installation auftreten, sollte eine Fehlermeldung im `/var/log/chef-client.log` Protokoll stehen. Wenn in der Konfiguration des Clusters Skripts vor oder nach der Installation 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. Wenn also die Rechenknoten dem Cluster nicht beitreten können, schlägt auch der Hauptknoten fehl. Je nachdem, welche Art von Compute Notes Sie verwenden, können Sie eines der folgenden Verfahren anwenden, um diese Art von Problem zu beheben: **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 der Node noch nie aufgerufen `ResumeProgram` wurde, können Sie anhand von `slurmctld` log (`/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, sollte Ihnen eine Fehlermeldung angezeigt werden, 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 Rechenknoten 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. + **Knoten berechnen:** + **Anwendbare Protokolle:** + `/var/log/cloud-init-output.log` + `/var/log/slurmd.log` + Wenn der 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. Suchen Sie im `/var/log/slurmd.log` Protokoll nach Fehlern im Zusammenhang mit dem Scheduler. ### **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 Sie die Aktion zum Ersetzen oder Beenden eines Knotens ergriffen `clustermgtd` haben. 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 ist`DOWN`), schauen Sie im `slurmctld` Protokoll nach, um weitere Informationen zu erhalten. Wenn der Grund mit Amazon EC2 zusammenhängt, sollte es eine informative Nachricht geben, in der das Problem im Zusammenhang mit Amazon EC2 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 handelt, genauer gesagt um eine Spot-Terminierung. `computemgtd`, der auf einem Rechenknoten ausgeführt wird, kann auch Maßnahmen ergreifen, um einen Knoten zu 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. + **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 ein, um einen neuen Knoten hochfahren zu lassenSlurm. + Nachdem der Knoten gestartet wurde, aktivieren Sie den Kündigungsschutz mit diesem Befehl. ``` aws ec2 modify-instance-attribute --instance-id i-xyz --disable-api-termination ``` + Rufen Sie mit diesem Befehl die Konsolenausgabe vom Knoten ab. ``` aws ec2 get-console-output --instance-id i-xyz --output text ``` ### **Probleminstanzen und Knoten ersetzen, beenden oder herunterfahren** + **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 ausfallen[`scaledown_idletime`](scaling-section.md#scaledown-idletime), 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 von`clustermgtd`. Slurmversetzt Knoten danach `SuspendTimeout` automatisch wieder in einen `POWER_SAVING` Zustand. ### **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 gemäß den Anweisungen gestartet, beendet oder verwaltet. Slurm Überprüfen Sie bei diesen Problemen das `slurmctld` Protokoll, um diese Probleme zu beheben. ## Behebung von Problemen in Clustern im Single-Queue-Modus **Anmerkung** Ab Version 2.11.5 wird die Verwendung von SGE oder Torque Schedulern AWS ParallelCluster nicht unterstützt. Dieser Abschnitt bezieht sich auf Cluster, die nicht über einen Modus mit mehreren Warteschlangen mit einer der folgenden beiden Konfigurationen verfügen: + Wurde mit einer AWS ParallelCluster Version vor 2.9.0 und SGETorque, oder Slurm Job-Schedulern gestartet. + Mit AWS ParallelCluster Version 2.9.0 oder höher und/oder Job-Schedulern SGE gestartet. Torque **Topics** + [Wichtige Protokolle](#key-logs-1) + [**Fehlerbehebung bei fehlgeschlagenen Start- und Verbindungsvorgängen**](#troubleshooting-failed-launch-and-join-operations) + [Behebung von Skalierungsproblemen](#troubleshooting-scaling-issues) + [Behebung anderer Probleme im Zusammenhang mit Clustern](#troubleshooting-other-cluster-related-issues) ### Wichtige Protokolle Die folgenden Protokolldateien sind die Schlüsselprotokolle für den Hauptknoten. Für AWS ParallelCluster Version 2.9.0 oder höher: `/var/log/chef-client.log` Dies ist das CINC (Chef) -Client-Protokoll. Es enthält alle Befehle, die über CINC ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen. Für alle AWS ParallelCluster Versionen: `/var/log/cfn-init.log` Das ist das `cfn-init` Protokoll. Es enthält alle Befehle, die beim Einrichten einer Instanz ausgeführt wurden, und ist daher nützlich für die Behebung von Initialisierungsproblemen. Weitere Informationen finden Sie unter [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html). `/var/log/clustermgtd.log` Dies ist das `clustermgtd` Protokoll für Scheduler. Slurm `clustermgtd`wird als zentraler Daemon ausgeführt, der die meisten Clusteroperationen verwaltet. Er ist nützlich, um Probleme beim Starten, Beenden oder Clusterbetrieb zu beheben. `/var/log/jobwatcher` Dies ist das `jobwatcher` Protokoll für SGE und Torque Scheduler. `jobwatcher`überwacht die Scheduler-Warteschlange und aktualisiert die Auto Scaling Group. Dies ist nützlich bei der Behebung von Problemen im Zusammenhang mit der Skalierung von Knoten. `/var/log/sqswatcher` Dies ist das `sqswatcher` Protokoll für SGE und Torque Scheduler. `sqswatcher`verarbeitet das Instance-Ready-Ereignis, das von einer Recheninstanz nach erfolgreicher Initialisierung gesendet wird. Außerdem werden Rechenknoten zur Scheduler-Konfiguration hinzugefügt. Dieses Protokoll ist nützlich, um zu beheben, warum ein oder mehrere Knoten einem Cluster nicht beitreten konnten. Im Folgenden sind die wichtigsten Protokolle für die Rechenknoten aufgeführt. AWS ParallelCluster Version 2.9.0 oder höher `/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. Es ist nützlich bei der Behebung von Initialisierungsproblemen. AWS ParallelCluster Versionen vor 2.9.0 `/var/log/cfn-init.log` Dies ist das CloudFormation Init-Protokoll. Es enthält alle Befehle, die beim Einrichten einer Instanz ausgeführt wurden. Es ist nützlich bei der Behebung von Initialisierungsproblemen Alle Versionen `/var/log/nodewatcher` Das ist das `nodewatcher` Protokoll. `nodewatcher`Daemons, die auf jedem Compute-Knoten laufen, wenn Scheduler verwendet werdenSGE. Torque Sie skalieren einen Knoten herunter, wenn er inaktiv ist. Dieses Protokoll ist nützlich für alle Probleme im Zusammenhang mit der Reduzierung von Ressourcen. ### **Fehlerbehebung bei fehlgeschlagenen Start- und Verbindungsvorgängen** + **Anwendbare Protokolle:** + `/var/log/cfn-init-cmd.log`(Hauptknoten und Rechenknoten) + `/var/log/sqswatcher`(Hauptknoten) + Wenn Knoten nicht gestartet werden konnten, schauen Sie im `/var/log/cfn-init-cmd.log` Protokoll nach, um die entsprechende Fehlermeldung zu finden. In den meisten Fällen sind Fehler beim Starten von Knoten auf einen Einrichtungsfehler zurückzuführen. + Wenn Compute-Knoten trotz erfolgreicher Einrichtung nicht an der Scheduler-Konfiguration teilnehmen konnten, überprüfen Sie im `/var/log/sqswatcher` Protokoll, ob das Ereignis `sqswatcher` verarbeitet wurde. Diese Probleme sind in den meisten Fällen darauf zurückzuführen, `sqswatcher` dass das Ereignis nicht verarbeitet wurde. ### Behebung von Skalierungsproblemen + **Anwendbare Protokolle:** + `/var/log/jobwatcher`(Kopfknoten) + `/var/log/nodewatcher`(Rechenknoten) + **Probleme mit der Skalierung:** Überprüfen Sie für den Hauptknoten im `/var/log/jobwatcher` Protokoll, ob der `jobwatcher` Daemon die richtige Anzahl der erforderlichen Knoten berechnet und die Auto Scaling Scaling-Gruppe aktualisiert hat. Beachten Sie, dass die Scheduler-Warteschlange `jobwatcher` überwacht und die Auto Scaling Group aktualisiert wird. + **Probleme beim Herunterskalieren:** Überprüfen Sie bei Rechenknoten das `/var/log/nodewatcher` Protokoll auf dem problematischen Knoten, um zu sehen, warum der Knoten herunterskaliert wurde. Beachten Sie, dass `nodewatcher` Daemons einen Rechenknoten herunterskalieren, wenn er inaktiv ist. ### Behebung anderer Probleme im Zusammenhang mit Clustern Ein bekanntes Problem sind zufällige Fehler bei Rechennotizen auf großen Clustern, insbesondere solchen mit 500 oder mehr Rechenknoten. Dieses Problem steht im Zusammenhang mit einer Einschränkung der Skalierungsarchitektur eines Clusters mit einer Warteschlange. Wenn Sie einen großen Cluster verwenden möchten, AWS ParallelCluster Version v2.9.0 oder höher verwenden, dieses Problem verwenden und dieses Problem vermeiden möchtenSlurm, sollten Sie ein Upgrade durchführen und zu einem Cluster wechseln, der den Modus mehrerer Warteschlangen unterstützt. Sie können dies tun, indem Sie Folgendes ausführen. [`pcluster-config convert`](pcluster-config.md#pcluster-config-convert) Bei ultra-large-scale Clustern ist möglicherweise eine zusätzliche Optimierung Ihres Systems erforderlich. Für weitere Informationen wenden Sie sich bitte an Support. ## Probleme bei der Platzierung von Gruppen und beim Starten von Instances Verwenden Sie eine *Platzierungsgruppe*, um die niedrigste Latenz zwischen den Knoten zu erzielen. Eine Platzierungsgruppe garantiert, dass sich Ihre Instances auf demselben Netzwerk-Backbone befinden. Wenn bei einer Anfrage nicht genügend Instances verfügbar sind, wird ein `InsufficientInstanceCapacity` Fehler zurückgegeben. Um die Wahrscheinlichkeit zu verringern, dass dieser Fehler bei der Verwendung von Cluster-Placement-Gruppen auftritt, setzen Sie den [`placement_group`](cluster-definition.md#placement-group) Parameter auf `DYNAMIC` und setzen Sie den [`placement`](cluster-definition.md#placement) Parameter auf`compute`. Wenn Sie ein leistungsstarkes gemeinsam genutztes Dateisystem benötigen, sollten Sie es [FSx für Lustre](https://aws.amazon.com/fsx/lustre/) verwenden. Wenn sich der Hauptknoten in der Platzierungsgruppe befinden muss, verwenden Sie denselben Instanztyp und dasselbe Subnetz sowohl für den Kopf als auch für alle Rechenknoten. Dadurch hat der [`compute_instance_type`](cluster-definition.md#compute-instance-type) Parameter denselben Wert wie der [`master_instance_type`](cluster-definition.md#master-instance-type) Parameter, der [`placement`](cluster-definition.md#placement) Parameter wird auf `cluster` gesetzt und der [`compute_subnet_id`](vpc-section.md#compute-subnet-id) Parameter ist nicht angegeben. Bei dieser Konfiguration wird der Wert des [`master_subnet_id`](vpc-section.md#master-subnet-id) Parameters für die Rechenknoten verwendet. Weitere Informationen finden Sie unter [Problembehandlung beim Starten von Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) und [Placement-Gruppen, Rollen und Einschränkungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups) im *Amazon EC2 EC2-Benutzerhandbuch*. ## Verzeichnisse, die nicht ersetzt werden können Die folgenden Verzeichnisse werden von den Knoten gemeinsam genutzt und können nicht ersetzt werden. `/home` Dazu gehört der Standard-Home-Ordner des Benutzers (`/home/ec2_user`auf Amazon LinuxCentOS, `/home/centos` on und `/home/ubuntu` onUbuntu). `/opt/intel` Dazu gehören Intel MPI, Intel Parallel Studio und zugehörige Dateien. `/opt/sge` Ab Version 2.11.5 wird die Verwendung von SGE oder Torque -Schedulern AWS ParallelCluster nicht unterstützt. Dazu gehören Son of Grid Engine und zugehörige Dateien. (Bedingt, nur wenn [`scheduler`](cluster-definition.md#scheduler)` = sge`.) `/opt/slurm` Dazu gehören Slurm Workload Manager und zugehörige Dateien. (Bedingt, nur wenn [`scheduler`](cluster-definition.md#scheduler)` = slurm`.) `/opt/torque` Ab Version 2.11.5 wird die Verwendung von AWS ParallelCluster OR-Schedulern nicht unterstützt. SGE Torque Dazu gehören Torque Resource Manager und zugehörige Dateien. (Bedingt, nur wenn [`scheduler`](cluster-definition.md#scheduler)` = torque`.) ## Behebung von Problemen in Amazon DCV **Topics** + [Protokolle für Amazon DCV](#nice-dcv-troubleshooting-logs) + [Speicher vom Typ Amazon DCV Instance](#nice-dcv-troubleshooting-memory) + [Probleme mit Ubuntu Amazon DCV](#nice-dcv-troubleshooting-modules) ### Protokolle für Amazon DCV Die Protokolle für Amazon DCV werden in Dateien im `/var/log/dcv/` Verzeichnis geschrieben. Die Überprüfung dieser Protokolle kann bei der Behebung von Problemen hilfreich sein. ### Speicher vom Typ Amazon DCV Instance Der Instance-Typ sollte mindestens 1,7 Gibibyte (GiB) RAM haben, um Amazon DCV ausführen zu können. Nanound micro Instance-Typen haben nicht genug Speicher, um Amazon DCV auszuführen. ### Probleme mit Ubuntu Amazon DCV Wenn Sie Gnome Terminal über eine DCV-Sitzung auf Ubuntu ausführen, haben Sie möglicherweise nicht automatisch Zugriff auf die Benutzerumgebung, die über die AWS ParallelCluster Login-Shell verfügbar ist. Die Benutzerumgebung bietet Umgebungsmodule wie openmpi oder intelmpi und andere Benutzereinstellungen. Die Standardeinstellungen von Gnome Terminal verhindern, dass die Shell als Login-Shell gestartet wird. Das bedeutet, dass Shell-Profile nicht automatisch bezogen werden und die AWS ParallelCluster Benutzerumgebung nicht geladen wird. Gehen Sie wie folgt vor, um das Shell-Profil korrekt zu beziehen und auf die AWS ParallelCluster Benutzerumgebung zuzugreifen: + **Ändern Sie die Standard-Terminaleinstellungen:** 1. Wählen Sie im Gnome-Terminal das Menü **Bearbeiten**. 1. Wählen Sie **Einstellungen** und dann **Profile** aus. 1. Wählen Sie „**Befehl**“ und anschließend „**Befehl als Login-Shell ausführen**“. 1. Öffnen Sie ein neues Terminal. + **Verwenden Sie die Befehlszeile, um die verfügbaren Profile abzurufen:** ``` $ source /etc/profile && source $HOME/.bashrc ``` ## Behebung von Problemen in Clustern mit AWS Batch Integration Dieser Abschnitt ist relevant für Cluster mit AWS Batch Scheduler-Integration. ### Probleme mit dem Hauptknoten Einrichtungsprobleme im Zusammenhang mit dem Hauptknoten können auf die gleiche Weise wie bei Clustern mit einzelnen Warteschlangen behoben werden. Weitere Informationen zu diesen Problemen finden Sie unter [Behebung von Problemen in Clustern im Single-Queue-Modus](#troubleshooting-issues-in-single-queue-clusters). ### AWS Batch Probleme bei der Einreichung parallel Jobs mit mehreren Knoten Wenn Sie bei der Verwendung AWS Batch als Job-Scheduler Probleme beim Senden von parallel Jobs mit mehreren Knoten haben, sollten Sie ein Upgrade auf AWS ParallelCluster Version 2.5.0 durchführen. Falls das nicht möglich ist, können Sie die Problemumgehung verwenden, die im Thema beschrieben wird: [Selbstpatchen eines Clusters, über das parallel Aufträge mit mehreren Knoten gesendet werden](https://github.com/aws/aws-parallelcluster/wiki/Self-patch-a-Cluster-Used-for-Submitting-Multi-node-Parallel-Jobs-through-AWS-Batch). AWS Batch ### Probleme mit der Datenverarbeitung AWS Batch verwaltet die Skalierungs- und Rechenaspekte Ihrer Dienste. Wenn Sie auf Probleme im Zusammenhang mit der Datenverarbeitung stoßen, finden Sie in der Dokumentation AWS Batch [zur Fehlerbehebung](https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html) Hilfe. ### Auftragsfehler Wenn ein Job fehlschlägt, können Sie den ``awsbout`` Befehl ausführen, um die Jobausgabe abzurufen. Sie können den ``awsbstat` -d` Befehl auch ausführen, um einen Link zu den von Amazon gespeicherten Jobprotokollen zu erhalten CloudWatch. ## Fehlerbehebung, wenn eine Ressource nicht erstellt werden kann Dieser Abschnitt ist relevant für Clusterressourcen, wenn sie nicht erstellt werden können. Wenn eine Ressource nicht erstellt werden kann, wird eine Fehlermeldung wie die folgende ParallelCluster zurückgegeben. ``` pcluster create -c config my-cluster Beginning cluster creation for cluster: my-cluster WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). Info: There is a newer version 3.0.3 of AWS ParallelCluster available. Creating stack named: parallelcluster-my-cluster Status: parallelcluster-my-cluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::CloudFormation::Stack MasterServerSubstack Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer]. - AWS::CloudFormation::Stack parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL The following resource(s) failed to create: [MasterServer]. - AWS::EC2::Instance MasterServer You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit. (Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null) } ``` Wenn Sie beispielsweise die in der vorherigen Befehlsantwort angezeigte Statusmeldung sehen, müssen Sie Instanztypen verwenden, die Ihr aktuelles vCPU-Limit nicht überschreiten oder mehr vCPU-Kapazität anfordern. Sie können die CloudFormation Konsole auch verwenden, um Informationen zum Status abzurufen. `"Cluster creation failed"` CloudFormation Fehlermeldungen von der Konsole aus anzeigen. 1. Melden Sie sich bei der an AWS-Managementkonsole und navigieren Sie zu [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. Wählen Sie den Stack mit dem Namen parallelcluster- aus. *cluster\$1name* 1. Wählen Sie die Registerkarte **Ereignisse** . 1. **Überprüfen Sie den **Status** der Ressource, die nicht erstellt werden konnte, indem Sie die Liste der Ressourcenereignisse nach der logischen ID durchsuchen.** Wenn eine Unteraufgabe nicht erstellt werden konnte, gehen Sie rückwärts vor, um das fehlgeschlagene Ressourcenereignis zu finden. 1. Ein Beispiel für eine AWS CloudFormation Fehlermeldung: ``` 2022-02-07 11:59:14 UTC-0800 MasterServerSubstack CREATE_FAILED Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer]. ``` ## Behebung von Problemen mit der Größe der IAM-Richtlinie Informationen zur Überprüfung der [AWS STS Kontingente für verwaltete Richtlinien, die Rollen zugeordnet sind, finden Sie unter IAM und Kontingente, Namensanforderungen und Zeichenbeschränkungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). Wenn die Größe einer verwalteten Richtlinie das Kontingent überschreitet, teilen Sie die Richtlinie in zwei oder mehr Richtlinien auf. Wenn Sie das Kontingent für die Anzahl der einer IAM-Rolle zugewiesenen Richtlinien überschreiten, erstellen Sie zusätzliche Rollen und verteilen Sie die Richtlinien auf diese, um das Kontingent zu erreichen. ## Zusätzlicher Support Eine Liste der bekannten Probleme finden Sie auf der [GitHubWiki-Hauptseite](https://github.com/aws/aws-parallelcluster/wiki) oder auf der [Problemseite](https://github.com/aws/aws-parallelcluster/issues). Bei dringenderen Problemen wenden Sie sich an Support oder öffnen Sie ein [neues GitHub Problem](https://github.com/aws/aws-parallelcluster/issues).