SageMaker HyperPod FAQs - Amazon SageMaker KI
Warum kann ich in Amazon keine Protokollgruppen meines SageMaker HyperPod Clusters finden CloudWatch?Welche speziellen Konfigurationen werden in Slurm-Konfigurationsdateien wie slurm.conf und HyperPod gres.conf verwaltet?Wie führe ich Docker auf Slurm-Knoten aus? HyperPodWarum schlägt mein parallel Trainingsjob fehl, wenn ich die NVIDIA Collective Communications Library (NCCL) mit Slurm auf der Plattform verwende? SageMaker HyperPod Wie verwende ich den lokalen NVMe Speicher von P-Instances, um Docker- oder Enroot-Container mit Slurm zu starten?Wie richten Sie EFA-Sicherheitsgruppen ein?Wie überwache ich meine HyperPod Clusterknoten? Gibt es CloudWatch Metriken, aus denen exportiert wurde HyperPod?Kann ich den HyperPod Clusterknoten zusätzlichen Speicher hinzufügen? Die Cluster-Instances haben einen begrenzten lokalen Instance-Speicher.Warum werden meine Rechenknoten nach einem Neustart als „DOWN“ oder „DRAINED“ angezeigt?Warum werden meine Knoten aufgrund von Speicherplatzproblemen (OOM) immer wieder heruntergefahren?Wie kann ich sicherstellen, dass Ressourcen nach Abschluss von Aufträgen ordnungsgemäß bereinigt werden?

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 FAQs

Verwenden Sie die folgenden häufig gestellten Fragen, um Probleme bei der Verwendung von zu beheben SageMaker HyperPod.

Warum kann ich in Amazon keine Protokollgruppen meines SageMaker HyperPod Clusters finden CloudWatch?

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. Um das Problem zu beheben, wählen Sie eine der folgenden Optionen.

  • Option 1: Aktualisieren Sie Ihre Lebenszyklusskripte, um Protokolle in /var/log/provision/provisioning.log zu schreiben.

  • Option 2: Aktualisieren Sie den CloudWatch Agenten so, dass er nach Ihren benutzerdefinierten Pfaden für die Protokollierung der Lebenszyklusbereitstellung sucht.

    1. 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 Feldnamen logs.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 Instanzebene 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
}

    2. Ersetzen Sie den Wert für den "file_path"-Feldnamen durch den benutzerdefinierten Pfad, den Sie in Ihren Lebenszyklusskripten verwenden. Wenn Sie beispielsweise Ihre Lebenszyklusskripte so eingerichtet haben, dass sie in /var/log/custom-provision/custom-provisioning.log schreiben, aktualisieren Sie den Wert wie folgt, sodass er mit ihm übereinstimmt.

      "file_path": "/var/log/custom-provision/custom-provisioning.log"

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

Welche speziellen Konfigurationen werden in Slurm-Konfigurationsdateien wie slurm.conf und HyperPod gres.conf verwaltet?

Wenn Sie einen Slurm-Cluster erstellen HyperPod, richtet der HyperPod Agent die gres.confDateien slurm.confund unter ein, um den Slurm-Cluster auf der Grundlage Ihrer Anfrage /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: ClusterNameSlurmctldHost,PartitionName, undNodeName.

    Um die Automatische Knotenwiederherstellung und automatische Wiederaufnahme Funktionalität zu aktivieren, HyperPod müssen außerdem die SchedulerParameters Parameter TaskPlugin 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.

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 einbeziehen können. Weitere Informationen hierzu finden Sie unter Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod und Docker-Container auf einem Slurm-Rechenknoten ausführen auf HyperPod.

Warum schlägt mein parallel Trainingsjob fehl, wenn ich die NVIDIA Collective Communications Library (NCCL) mit Slurm auf der Plattform verwende? SageMaker HyperPod

Standardmäßig legt das Linux-Betriebssystem die #RemoveIPC=yes-Flag fest. Slurm- und mpirun-Aufträge, die NCCL verwenden, generieren Ressourcen für die Interprozesskommunikation (IPC) unter Nicht-Root-Benutzersitzungen. Diese Benutzersitzungen werden möglicherweise während des Auftragsvorgangs abgemeldet.

Wenn Sie Aufträge mit Slurm oder mpirun ausführen, wenn systemd feststellt, dass der Benutzer nicht angemeldet ist, werden die IPC-Ressourcen bereinigt. Slurm- und mpirun-Aufträge können ausgeführt werden, ohne dass der Benutzer angemeldet ist. Dazu ist es jedoch erforderlich, die Bereinigung auf systemd-Ebene zu deaktivieren und stattdessen auf Slurm-Ebene einzurichten. Weitere Informationen finden Sie unter Systemd in der NCCL-Dokumentation.

Führen Sie die folgenden Schritte aus, um die Bereinigung auf Systemd-Ebene zu deaktivieren.

  1. Legen Sie die Flag #RemoveIPC=no in der Datei /etc/systemd/logind.conf fest, wenn Sie Trainingsjobs ausführen, die Slurm und NCCL verwenden.

  2. Standardmäßig bereinigt Slurm gemeinsam genutzte Ressourcen nicht. Wir empfehlen Ihnen, ein Slurm-Epilog-Skript einzurichten, um gemeinsam genutzte Ressourcen zu bereinigen. Diese Bereinigung ist nützlich, wenn Sie viele gemeinsam genutzte Ressourcen haben und diese nach Trainingsjobs bereinigen möchten. Nachfolgend sehen Sie ein Beispielskript.

    #!/bin/bash
: <<'SUMMARY'
Script: epilog.sh

Use this script with caution, as it can potentially delete unnecessary resources and cause issues if you don't use it correctly.

Note: You must save this script in a shared in a shared location that is accessible to all nodes in the cluster, such as /fsx volume.
Workers must be able to access the script to run the script after jobs.

SUMMARY

# Define the log directory and create it if it doesn't exist
LOG_DIR="/<PLACEHOLDER>/epilogue" #NOTE: Update PLACEHOLDER to be a shared value path, such as /fsx/epilogue.
mkdir -p "$LOG_DIR"

# Name the log file using the Slurm job name and job ID
log_file="$LOG_DIR/epilogue-${SLURM_JOB_NAME}_${SLURM_JOB_ID}.log"

logging() {
    echo "[$(date)] $1" | tee -a "$log_file"
}

# Slurm epilogue script to clean up IPC resources
logging "Starting IPC cleanup for Job $SLURM_JOB_ID"

# Clean up shared memory segments by username
for seg in $(ipcs -m | awk -v owner="$SLURM_JOB_USER" '$3 == owner {print $2}'); do
    if ipcrm -m "$seg"; then
        logging "Removed shared memory segment $seg"
    else
        logging "Failed to remove shared memory segment $seg"
    fi
done

# Clean up semaphores by username
for sem in $(ipcs -s | awk -v user="$SLURM_JOB_USER" '$3 == user {print $2}'); do
    if ipcrm -s "$sem"; then
        logging "Removed semaphore $sem"
    else
        logging "Failed to remove semaphore $sem"
    fi
done

# Clean up NCCL IPC
NCCL_IPC_PATH="/dev/shm/nccl-*"
for file in $NCCL_IPC_PATH; do
    if [ -e "$file" ]; then
        if rm "$file"; then
            logging "Removed NCCL IPC file $file"
        else
            logging "Failed to remove NCCL IPC file $file"
        fi
    fi
done
logging "IPC cleanup completed for Job $SLURM_JOB_ID"
exit 0

    Weitere Informationen zum Epilog-Parameter finden Sie in der Slurm-Dokumentation.

  3. Fügen Sie in der slurm.conf-Datei vom Controller-Knoten eine Zeile hinzu, die auf das von Ihnen erstellte Epilog-Skript verweist.

    Epilog="/path/to/epilog.sh"  #For example: /fsx/epilogue/epilog.sh

  4. Führen Sie die folgenden Befehle aus, um die Berechtigungen des Skripts zu ändern und es ausführbar zu machen.

    chown slurm:slurm /path/to/epilog.sh
chmod +x  /path/to/epilog.sh

  5. Führen Sie den Befehl scontrol reconfigure aus, um alle Ihre Änderungen zu übernehmen.

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 Instance-Speicher verwenden. NVMe Informationen darüber, wie Sie den NVMe Store einrichten und ihn zum Starten von Docker-Containern verwenden, finden Sie unter. Docker-Container auf einem Slurm-Rechenknoten ausführen auf HyperPod

Wie richten Sie 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: Eine EFA-fähige Sicherheitsgruppe vorbereiten im EC2 Amazon-Benutzerhandbuch.

Wie überwache ich meine HyperPod Clusterknoten? Gibt es CloudWatch Metriken, aus 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 der Cluster-Ressourcen Beachten Sie, dass der Export von Systemmetriken nach Amazon SageMaker HyperPod derzeit nicht unterstützt wird. CloudWatch

Kann ich den HyperPod Clusterknoten zusätzlichen Speicher hinzufügen? Die Cluster-Instances haben einen begrenzten lokalen Instance-Speicher.

Wenn der standardmäßige Instance-Speicher für Ihren Workload nicht ausreicht, können Sie zusätzlichen Speicher pro Instance 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.

Warum werden meine Rechenknoten nach einem Neustart als „DOWN“ oder „DRAINED“ angezeigt?

Dies tritt in der Regel auf, wenn Knoten mit sudo reboot statt mit der Slurm-Steuerungsschnittstelle neu gestartet werden. Verwenden Sie den Slurm-Befehl scontrol reboot nextstate=resume <list_of_nodes>, um Knoten ordnungsgemäß neu zu starten. Dadurch wird sichergestellt, dass Slurm die richtige Kontrolle über den Knotenstatus behält und nach dem Neustart den normalen Betrieb wieder aufnimmt.

Bei GPU-Instances (wie NVIDIA P5) kann dies auch passieren, wenn der Knoten seinen Startvorgang nicht innerhalb der Standardzeit von Slurm (60 Sekunden) abschließen kann. Um dieses Problem zu beheben, erhöhen Sie den TimeToResume-Parameter in slurm.conf auf 300 Sekunden. Dadurch haben GPU-Instances ausreichend Zeit, um Treiber zu starten und zu initialisieren.

Warum werden meine Knoten aufgrund von Speicherplatzproblemen (OOM) immer wieder heruntergefahren?

OOM-Probleme treten auf, wenn Aufträge die Speicherkapazität des Knotens überschreiten. Um dies zu verhindern, implementieren Sie cgroups, um das Speicherlimits pro Auftrag zu erzwingen. Dadurch wird verhindert, dass sich ein einzelner Auftrag auf den gesamten Knoten auswirkt, und Isolierung und Stabilität werden verbessert.

Beispieleinrichtung in slurm.conf: 

TaskPlugin=task/cgroup

Beispieleinrichtung in cgroup.conf:

CgroupAutomount=yes
ConstrainCores=yes
CgroupPlugin=autodetect
ConstrainDevices=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
SignalChildrenProcesses=yes
MaxRAMPercent=99
MaxSwapPercent=80
MinRAMSpace=100

Weitere Informationen finden Sie unter Kontrollgruppe in Slurm, Cgroup- und PAM-basierte Anmeldesteuerung für Slurm-Rechenknoten und Konfigurieren von Cgroups für Slurm.

Wie kann ich sicherstellen, dass Ressourcen nach Abschluss von Aufträgen ordnungsgemäß bereinigt werden?

Implementieren Sie Epilog-Skripte, um Ressourcen nach Abschluss von Aufträgen automatisch zu bereinigen. Ressourcen werden möglicherweise nicht ordnungsgemäß gelöscht, wenn Aufträge unerwartet abstürzen, Fehler enthalten, die eine normale Bereinigung verhindern, oder wenn gemeinsam genutzte Speicherpuffer (einschließlich solcher, die zwischen Prozessen und GPU-Treibern gemeinsam genutzt werden) zugewiesen bleiben.

Epilog-Skripte können Aufgaben wie das Löschen des GPU-Speichers, das Entfernen temporärer Dateien und das Aushängen von Dateisystemen ausführen. Diese Skripte weisen Einschränkungen auf, wenn Ressourcen nicht ausschließlich einem einzelnen Auftrag zugewiesen sind. Ausführliche Anweisungen und Beispielskripte finden Sie im zweiten Aufzählungspunkt der Frage Warum schlägt mein parallel Trainingsjob fehl, wenn ich die NVIDIA Collective Communications Library (NCCL) mit Slurm auf der Plattform verwende? SageMaker HyperPod . Weitere Informationen finden Sie unter Aktivieren des Slurm-Epilog-Skripts.