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.
SageMaker HyperPod Häufig gestellte Fragen
Verwenden Sie die folgenden häufig gestellten Fragen, um Probleme bei der Verwendung von zu beheben SageMaker HyperPod.
F: Warum kann ich in Amazon CloudWatch keine Protokollgruppen meines SageMaker HyperPod Clusters finden?
Standardmäßig werden Agentenprotokolle und Instance-Startprotokolle an die Konten der HyperPod Plattform gesendet. CloudWatch Im Fall von Benutzerlebenszyklus-Skripten werden die Lebenszykluskonfigurationsprotokolle an Ihr Konto gesendet CloudWatch.
Wenn Sie die vom HyperPod Serviceteam bereitgestellten Beispiel-Lebenszyklusskripte verwenden, können Sie davon ausgehen, dass die Lebenszyklus-Konfigurationsprotokolle in die geschrieben wurden/var/log/provision/provisioning.log
, und dieses Problem würde nicht auftreten.
Wenn Sie jedoch benutzerdefinierte Pfade für das Sammeln von Protokollen aus der Lebenszyklusbereitstellung verwenden und die Protokollgruppen in Ihren Konten nicht finden können, kann dies daran liegen CloudWatch, dass die in Ihren Lifecycle-Skripten angegebenen Protokolldateipfade nicht mit dem übereinstimmen, wonach der auf den HyperPod Cluster-Instances ausgeführte CloudWatch Agent sucht. In diesem Fall bedeutet dies, dass Sie Ihre Lifecycle-Skripts ordnungsgemäß einrichten müssen, um Protokolle an den CloudWatch Agenten zu senden, und auch die CloudWatch Agentenkonfiguration entsprechend einrichten müssen. Wählen Sie eine der folgenden Optionen, um das Problem zu lösen.
-
Option 1: Aktualisieren Sie Ihre Lebenszyklusskripts, in die Protokolle geschrieben werden sollen
/var/log/provision/provisioning.log
. -
Option 2: Aktualisieren Sie den CloudWatch Agenten so, dass er nach Ihren benutzerdefinierten Pfaden für die Protokollierung der Lebenszyklusbereitstellung sucht.
-
Jede HyperPod Clusterinstanz enthält eine CloudWatch Agentenkonfigurationsdatei im JSON-Format unter
/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json
. Suchen Sie in der Konfigurationsdatei nach dem Feldnamenlogs.logs_collected.files.collect_list.file_path
. Bei der Standardeinstellung von sollte HyperPod das Schlüssel-Wert-Paar"file_path": "/var/log/provision/provisioning.log"
wie unter dokumentiert sein. Protokollierung SageMaker HyperPod auf Instance-Ebene Der folgende Codeausschnitt zeigt, wie die JSON-Datei mit der Standardkonfiguration aussieht. HyperPod"logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/provision/provisioning.log", "log_group_name": "/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]", "log_stream_name": "LifecycleConfig/[InstanceGroupName]/{instance_id}", "retention_in_days": -1 } ] } }, "force_flush_interval": 3 }
-
Ersetzen Sie den Wert für den
"file_path"
Feldnamen durch den benutzerdefinierten Pfad, den Sie in Ihren Lebenszyklusskripten verwenden. Wenn Sie beispielsweise Ihre Lebenszyklus-Skripten so eingerichtet haben, dass sie in sie schreiben/var/log/custom-provision/custom-provisioning.log
, aktualisieren Sie den Wert wie folgt, sodass er mit ihm übereinstimmt."file_path": "
/var/log/custom-provision/custom-provisioning.log
" -
Starten Sie den CloudWatch Agenten mit der Konfigurationsdatei neu, um die Anwendung des benutzerdefinierten Pfads abzuschließen. Der folgende CloudWatch Befehl zeigt beispielsweise, wie der CloudWatch Agent mit der CloudWatch Agent-Konfigurationsdatei aus Schritt 1 neu gestartet wird. Weitere Informationen finden Sie unter Problembehandlung beim CloudWatch Agenten.
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \ -a fetch-config -m ec2 -s -c \ file:/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json
-
F: Welche speziellen Konfigurationen werden in Slurm-Konfigurationsdateien wie slurm.conf
und HyperPod verwaltet? gres.conf
Wenn Sie einen Slurm-Cluster erstellen HyperPod, richtet der HyperPod Agent die gres.conf
slurm.conf
/opt/slurm/etc/
zur Clustererstellung und der HyperPod Lebenszyklusskripte zu verwalten. Die folgende Liste zeigt, welche spezifischen Parameter der HyperPod Agent verarbeitet und überschreibt.
Wichtig
Wir empfehlen dringend, diese von HyperPod verwalteten Parameter NICHT zu ändern.
-
In
slurm.conf
, HyperPod richtet die folgenden grundlegenden Parameter ein: ClusterName
SlurmctldHost
,PartitionName
, undNodeName
.Um die Automatische Wiederaufnahme Funktionalität zu aktivieren, HyperPod müssen außerdem die
SchedulerParameters
ParameterTaskPlugin
und wie folgt festgelegt werden. Der HyperPod Agent richtet diese beiden Parameter standardmäßig mit den erforderlichen Werten ein.TaskPlugin=task/none SchedulerParameters=permit_job_expansion
-
In
gres.conf
, HyperPod verwaltet NodeName
für GPU-Knoten.
F: Wie führe ich Docker auf Slurm-Knoten aus? HyperPod
Um Sie bei der Ausführung von Docker auf Ihren Slurm-Knoten zu unterstützen HyperPod, stellt das HyperPod Service-Team Setup-Skripte zur Verfügung, die Sie als Teil der Lebenszykluskonfiguration für die Clustererstellung einbinden können. Weitere Informationen hierzu finden Sie unter Beginnen Sie mit den grundlegenden Lebenszyklusskripten von HyperPod und Führen Sie Docker-Container auf einem Slurm-Rechenknoten aus auf HyperPod.
F: Wie verwende ich den lokalen NVMe-Speicher von P-Instances, um Docker- oder Enroot-Container mit Slurm zu starten?
Da das Standard-Root-Volume Ihres Hauptknotens normalerweise auf ein EBS-Volume von 100 GB begrenzt ist, müssen Sie Docker und Enroot so einrichten, dass sie den lokalen NVMe-Instance-Speicher verwenden. Informationen zum Einrichten des NVMe-Speichers und dessen Verwendung zum Starten von Docker-Containern finden Sie unter. Führen Sie Docker-Container auf einem Slurm-Rechenknoten aus auf HyperPod
F: Wie richte ich EFA-Sicherheitsgruppen ein?
Wenn Sie einen HyperPod Cluster mit EFA-fähigen Instances erstellen möchten, stellen Sie sicher, dass Sie eine Sicherheitsgruppe einrichten, die den gesamten eingehenden und ausgehenden Datenverkehr zur und von der Sicherheitsgruppe selbst zulässt. Weitere Informationen finden Sie unter Schritt 1: Vorbereiten einer EFA-fähigen Sicherheitsgruppe im Amazon EC2 EC2-Benutzerhandbuch.
F: Wie überwache ich meine Clusterknoten? HyperPod Gibt es CloudWatch Metriken, von denen exportiert wurde? HyperPod
Um einen Überblick über die Ressourcennutzung Ihres HyperPod Clusters zu erhalten, empfehlen wir Ihnen, den HyperPod Cluster in Amazon Managed Grafana und Amazon Managed Service for Prometheus zu integrieren. Mit verschiedenen Open-Source-Grafana-Dashboards und Exportpaketen können Sie Metriken zu den Cluster-Ressourcen exportieren und visualisieren. HyperPod Weitere Informationen zur Einrichtung SageMaker HyperPod mit Amazon Managed Grafana und Amazon Managed Service für Prometheus finden Sie unter. SageMaker HyperPod Überwachung von Cluster-Ressourcen Beachten Sie, dass der Export von Systemmetriken nach Amazon SageMaker HyperPod derzeit nicht unterstützt wird. CloudWatch
F: Kann ich den Clusterknoten zusätzlichen Speicher hinzufügen? HyperPod Die Cluster-Instances verfügen über einen begrenzten lokalen Instanzspeicher.
Wenn der standardmäßige Instanzspeicher für Ihre Arbeitslast nicht ausreicht, können Sie zusätzlichen Speicher pro Instanz konfigurieren. Ab der Veröffentlichung am 20. Juni 2024 können Sie jeder Instance in Ihrem SageMaker HyperPod Cluster ein zusätzliches Amazon Elastic Block Store (EBS) -Volume hinzufügen. Beachten Sie, dass diese Funktion nicht auf bestehende Instanzgruppen von SageMaker HyperPod Clustern angewendet werden kann, die vor dem 20. Juni 2024 erstellt wurden. Sie können diese Funktion nutzen, indem Sie bestehende SageMaker HyperPod Cluster, die vor dem 20. Juni 2024 erstellt wurden, patchen und ihnen neue Instanzgruppen hinzufügen. Diese Funktion ist für alle SageMaker HyperPod Cluster, die nach dem 20. Juni 2024 erstellt wurden, voll wirksam.