View a markdown version of this page

Erste Schritte mit der SageMaker HyperPod Verwendung von AWS CLI - Amazon SageMaker KI

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.

Erste Schritte mit der SageMaker HyperPod Verwendung von AWS CLI

Das folgende Tutorial zeigt, wie Sie mit Slurm mithilfe der AWS CLI Befehle für SageMaker HyperPod einen neuen SageMaker HyperPod Cluster erstellen. Am Ende dieses Tutorials haben Sie einen funktionierenden Slurm-Cluster mit einem Controller-Knoten, einem Login-Knoten und einer Compute-Worker-Gruppe, bereit, ML-Workloads zu planen und auszuführen. Das Tutorial behandelt die Einrichtung der Slurm-Topologie, Konfigurationsoptionen für den Knotenlebenszyklus, optionalen gemeinsamen FSx-Speicher und wie Sie eine Verbindung zu Ihrem Cluster herstellen.

Bevor Sie beginnen, stellen Sie sicher, dass Sie die Rollen Voraussetzungen für die Verwendung SageMaker HyperPod (VPC, Kontingente, FSx) und AWS Identity and Access Management für SageMaker HyperPod (IAM-Rollen, Ausführungsrolle mit) abgeschlossen haben. AmazonSageMakerClusterInstanceRolePolicy

Die wichtigsten Konzepte

In diesem Abschnitt werden die wichtigsten Konfigurationskonzepte für die Erstellung eines SageMaker HyperPod Slurm-Clusters behandelt. Wenn Sie diese Konzepte verstehen, können Sie bei der Konfiguration Ihres Clusters fundierte Entscheidungen treffen. Wenn Sie jedoch sofort loslegen möchten, können Sie bei Bedarf direkt hierher springen Erstellen Ihres -Clusters und darauf zurückgreifen.

Beim Erstellen eines Slurm-orchestrated Clusters treffen Sie zwei unabhängige Konfigurationsentscheidungen:

  1. Konfiguration der Slurm-Topologie — Wie ist die Slurm-Cluster-Topologie (Knotenrollen, Partitionen) definiert?

  2. Konfiguration des Knotenlebenszyklus — Wie werden Knoten bereitgestellt und angepasst?

Für die Slurm-Topologie verwendet dieses Tutorial den API-driven Konfigurationsansatz, bei dem Sie Knotenrollen und Partitionen direkt in der CreateCluster Anfrage definieren und dies für jede Instanzgruppe und SlurmConfig auf Orchestrator.Slurm Cluster-Ebene verwenden. Dies ist der empfohlene Ansatz für neue Cluster. Es bietet eine zentrale Informationsquelle, eine integrierte Validierung und Erkennung von Abweichungen bei der Partitionskonfiguration, ohne dass zusätzliche Dateien verwaltet werden müssen. Alternativ können Sie eine in Amazon S3 gespeicherte provisioning_parameters.json Legacy-Datei verwenden, um die Abwärtskompatibilität mit vorhandenen Clustern zu gewährleisten. Einzelheiten zum Legacy-Ansatz finden Sie unterSageMaker HyperPod Slurm-Konfiguration.

SageMaker HyperPod Unterstützt für die Konfiguration des Knotenlebenszyklus drei Optionen. Im einfachsten Fall lassen Sie alles weg und konfigurieren Knoten HyperPod automatisch mithilfe der AMI-based Konfiguration. Sie richten Slurm und wichtige Pakete wie Docker, Enroot und Pyxis für die Ausführung von ML-Workloads ein, ohne dass Skripte oder ein Amazon S3-Bucket erforderlich sind. LifeCycleConfig Wenn Sie zusätzlich zur Konfiguration Anpassungen benötigen, können Sie ein Erweiterungsskript bereitstellen, das nach Abschluss der AMI-based Konfiguration ausgeführt wird. OnInitComplete Um die volle Kontrolle über die gesamte Bereitstellungssequenz zu haben, überlässt der OnCreate Pfad Ihren Skripten alles, auch wenn Slurm startet.

Für ML-Workloads benötigen Sie in der Regel auch ein gemeinsam genutztes Hochleistungsdateisystem für Trainingsdaten, Checkpoints und gemeinsam genutzte Bibliotheken. SageMaker HyperPod unterstützt Amazon FSx für Lustre und FSx für OpenZFS, konfiguriert pro Instanzgruppe über. InstanceStorageConfigs Die FSx-Konfiguration ist für die Cluster-Erstellung optional, wird jedoch für Produktions-Workloads empfohlen.

Konfiguration der Slurm-Topologie über die API

Alle Beispiele in diesem Tutorial verwenden die API-driven Slurm-Topologiekonfiguration, bei der Sie die Slurm-Clusterstruktur direkt in der CreateCluster API-Anfrage definieren und nicht über eine separate Konfigurationsdatei.

Ein Slurm-Cluster benötigt mindestens einen Controller-Knoten (der den slurmctld Daemon ausführt und die Jobplanung koordiniert) und einen oder mehrere Rechenknoten (die Jobs ausführen). Optional können Sie einen Anmeldeknoten hinzufügen, um Benutzern einen dedizierten Zugangspunkt zum Senden und Verwalten von Jobs zu bieten, ohne sich direkt am Controller anmelden zu müssen. In der API-Anfrage weisen Sie jeder Instanzgruppe ihre Slurm-Rolle zu, indem Sie angebenSlurmConfig, ob die Gruppe als Controller-, Anmelde- oder Rechenknoten dient. Rechengruppen werden außerdem einer oder mehreren Slurm-Partitionen zugeordnet. Diese dienen als logische Warteschlangen, die organisieren, wie Jobs auf verschiedenen Knotengruppen geplant werden.

Steuert auf Cluster-Ebene, wie die Orchestrator.Slurm Partitionskonfiguration in HyperPod verwaltet wird. slurm.conf Sie wählen eine Strategie, die bestimmt, ob HyperPod es sich um die zentrale Informationsquelle für die Partitionstopologie handelt, ob manuelle Änderungen überschrieben werden oder ob die API-defined Konfiguration mit allen von Ihnen vorgenommenen manuellen Änderungen zusammengeführt wird. Hier ist eine Referenz für die verwendeten Felder.

SlurmConfig(pro Instanzgruppe):

"SlurmConfig": { "NodeType": "Controller | Login | Compute", "PartitionNames": ["partition-name"] }
Feld Description
NodeType Erforderlich Die Slurm-Rolle für diese Instanzgruppe. Zulässige Werte: Controller, Login, Compute. Es muss genau eine Instanzgruppe sein. Controller
PartitionNames Bedingt. Slurm-Partitionsnamen. Erforderlich für den Compute Knotentyp; nicht zulässig für Controller oderLogin.

Orchestrator.Slurm(Cluster-Ebene):

"Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed | Overwrite | Merge" } }

SlurmConfigStrategybestimmt, wie die Partitions-zu-Knoten-Zuordnungen auf dem Controller-Knoten HyperPod verwaltet werden. slurm.conf Wenn Sie einen Cluster erstellen oder aktualisieren, HyperPod schreibt die Partitionskonfiguration auf der slurm.conf Grundlage der von SlurmConfig Ihnen für jede Instanzgruppe definierten Partitionen, ordnet Recheninstanzgruppen den ihnen zugewiesenen Partitionen zu und registriert Controller- und Anmeldeknoten mit den entsprechenden Slurm-Rollen.

Die von Ihnen gewählte Strategie steuert, was passiert, wenn die Partitionskonfiguration außerhalb der API slurm.conf geändert wird, beispielsweise indem ein Administrator die Datei direkt auf dem Controller-Knoten bearbeitet. MitManaged, HyperPod behandelt die API als zentrale Informationsquelle und erkennt und blockiert Updates, falls slurm.conf auf der Festplatte etwas verloren geht. MitOverwrite, HyperPod überträgt die API-defined Konfiguration auf den Controller und verwirft alle manuellen Änderungen an. slurm.conf Dies ist nützlich, um eine unbeabsichtigte Änderung zu beheben. Mit Merge HyperPod behält manuelle Änderungen an der API-Konfiguration bei slurm.conf und führt sie mit der API-Konfiguration zusammen, sodass fortgeschrittene Benutzer die Flexibilität haben, benutzerdefinierte slurm.conf Einstellungen zusammen mit Partitionen zu verwalten. API-managed

Strategie Erkennung von Partitionsabweichungen Manuelle Änderungen Anwendungsfall
Managed (Standard) Aktiviert; blockiert Aktualisierungen, wenn eine Abweichung festgestellt wird Nicht unterstützt Eine einzige Quelle der Wahrheit
Overwrite Disabled Beim Update überschrieben Erholung nach einer Drift
Merge Disabled Konserviert und zusammengeführt Maßgeschneiderte slurm.conf Bedürfnisse
Wichtig

Die Drift-Erkennung gilt nur für die Slurm-Partitionskonfiguration in slurm.conf (Partitions-zu-Knoten-Zuordnungen, die über die API definiert werden). Änderungen an anderen slurm.conf Einstellungen, wie z. B. Planungsparametern, Ressourcenbeschränkungen oder der Kontokonfiguration, werden nicht überwacht und von uns nicht erkannt oder gemeldet. HyperPod

Anmerkung

Wenn Sie es vorziehen, die Slurm-Topologie mithilfe einer provisioning_parameters.json Datei statt der API zu definieren, lassen Sie sie SlurmConfig bei Instanzgruppen und der Cluster-Anfrage Orchestrator.Slurm aus und laden Sie die Datei zusammen mit Ihren Node-Lifecycle-Skripten auf Amazon S3 hoch. Details hierzu finden Sie unter SageMaker HyperPod Slurm-Konfiguration.

Konfigurationsoptionen für den Knotenlebenszyklus

Wenn Sie einen SageMaker HyperPod Slurm-Cluster erstellen, wählen Sie aus, wie die Knoten der einzelnen Instanzgruppen bereitgestellt werden, indem Sie den LifeCycleConfig Block in der CreateCluster Anfrage konfigurieren. SageMaker HyperPod unterstützt drei Konfigurationsoptionen für den Knotenlebenszyklus, von denen jede ein anderes Maß an Kontrolle über den Bereitstellungsprozess bietet.

Wenn Sie nur die AMI-based Konfiguration verwenden, verzichten Sie vollständig daraufLifeCycleConfig. HyperPod konfiguriert Knoten automatisch mithilfe der AMI-based Konfiguration, richtet Slurm ein, installiert wichtige Pakete und startet alle erforderlichen Dienste. Dies ist der einfachste Pfad und erfordert keinen Amazon S3-Bucket oder -Skripte.

Bei der Erweiterungsoption geben OnInitComplete Sie dies LifeCycleConfig zusammen mit einem SourceS3Uri Verweis auf Ihr Erweiterungsskript in Amazon S3 an. HyperPod führt zuerst die vollständige AMI-based Konfiguration aus und führt dann Ihr Skript aus. Auf diese Weise können Sie Anpassungen wie Monitoring-Agents, LDAP-Integration oder zusätzliche Speicherzuweisungen hinzufügen, ohne die grundlegende Bereitstellung verwalten zu müssen.

Bei der Option Benutzerdefiniert geben Sie dies LifeCycleConfig zusammen mit einem OnCreate SourceS3Uri Verweis auf Ihr vollständiges Lifecycle-Skript in Amazon S3 an. HyperPod führt die AMI-based Konfiguration nicht aus und startet Slurm nicht. Ihre Skripte besitzen die gesamte Bereitstellungssequenz. Dadurch haben Sie die vollständige Kontrolle darüber, welche Software installiert ist, wie sie konfiguriert wird und wann Slurm gestartet wird.

Option für den Lebenszyklus eines Knotens Wird ein Amazon S3-Bucket benötigt? Skripte zum Hochladen? LifeCycleConfig in der API?
AMI-based nur Konfiguration (am einfachsten) Nein Nein Ganz weglassen
Erweiterung () OnInitComplete Ja Nur dein Erweiterungsskript OnInitComplete + SourceS3Uri
Benutzerdefiniert (OnCreate) Ja Vollständiger Lebenszyklus-Skriptsatz OnCreate + SourceS3Uri
Anmerkung

Die optionale Konfiguration des Knotenlebenszyklus wird nur für Slurm-orchestrated Cluster unterstützt. EKS-orchestrated Amazon-Cluster sind weiterhin LifeCycleConfig mit OnCreate und SourceS3Uri für jede Instanzgruppe erforderlich.

Anmerkung

OnCreateund schließen OnInitComplete sich gegenseitig aus. Die Angabe von beiden für dieselbe Instanzgruppe führt zu einem Validierungsfehler.

FSx- und VPC-Konfiguration

Für ML-Workloads ist ein gemeinsames Hochleistungsdateisystem unerlässlich, um Trainingsdaten, Modellprüfpunkte und gemeinsam genutzte Bibliotheken über Clusterknoten hinweg zu speichern. SageMaker HyperPod unterstützt Amazon FSx für Lustre und FSx für OpenZFS, konfiguriert pro Instanzgruppe über. InstanceStorageConfigs FSx-Dateisysteme befinden sich in Ihrer VPC, daher ist eine benutzerdefinierte VPC-Konfiguration () erforderlich, wenn Sie FSx verwenden. VpcConfig

Die FSx-Konfiguration funktioniert mit allen drei Konfigurationsoptionen für den Knotenlebenszyklus. Bei Verwendung von AMI-based configuration or wird OnInitComplete das HyperPod FSx-Mounten automatisch ausgeführt. Bei Verwendung OnCreate sind Ihre Lifecycle-Skripte für das Mounten verantwortlich.

FSx für Lustre:

"InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } } ]
Feld Description
DnsName Erforderlich Der DNS-Name des FSx for Lustre-Dateisystems.
MountPath Optional. Der lokale Mount-Pfad auf der Instanz. Standard: /fsx
MountName Erforderlich Der Mount-Name des FSx for Lustre-Dateisystems. Finden Sie ihn in der FSx for Lustre-Konsole oder über. aws fsx describe-file-systems

FSx für OpenZFS:

"InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com", "MountPath": "/shared" } } ]
Feld Description
DnsName Erforderlich Der DNS-Name des FSX for OpenZFS-Dateisystems.
MountPath Optional. Der lokale Mount-Pfad auf der Instanz. Standard: /home
Anmerkung

Jede Instanzgruppe kann höchstens einen FSx für Lustre und einen FSx für die OpenZFS-Konfiguration haben. Verschiedene Instanzgruppen können verschiedene Dateisysteme mounten.

VPC-Konfiguration (für FSx erforderlich):

Fügen Sie Ihrer CreateCluster Anfrage VpcConfig auf Cluster-Ebene hinzu:

"VpcConfig": { "SecurityGroupIds": ["sg-0abc123def456789a"], "Subnets": ["subnet-0abc123def456789a"] }

Weitere Informationen zum Einrichten einer VPC finden Sie unterVoraussetzungen für die Verwendung SageMaker HyperPod. Weitere Informationen zum FSx-Setup finden Sie unter. Voraussetzungen für die Verwendung SageMaker HyperPod

Erstellen Ihres -Clusters

Dieser Abschnitt führt Sie Schritt für Schritt durch die Erstellung eines Clusters mithilfe der drei Konfigurationsoptionen für den Knotenlebenszyklus, die unter beschrieben werden. Konfigurationsoptionen für den Knotenlebenszyklus Für die meisten Benutzer empfehlen wir, mit Option A, nur AMI-based Konfiguration, zu beginnen. Sie erfordert keine Skripte oder einen Amazon S3-Bucket und bietet sofort einen voll funktionsfähigen Cluster. Wählen Sie Option B, wenn Sie zusätzlich zur AMI-based Konfiguration Anpassungen hinzufügen müssen, oder Option C, wenn Sie die volle Kontrolle über den Bereitstellungsprozess benötigen.

Geben Sie ExecutionRole in allen Beispielen den ARN der IAM-Rolle an, die Sie mit dem Managed In erstellt haben. AmazonSageMakerClusterInstanceRolePolicy Voraussetzungen für die Verwendung SageMaker HyperPod

Option A: Nur AMI-based Konfiguration (ohne Lebenszykluskonfiguration)

Dies ist der einfachste Weg. Es werden kein Amazon S3-Bucket, keine Skripte oder Konfigurationsdateien benötigt. SageMaker HyperPod konfiguriert Knoten automatisch mithilfe der AMI-based Konfiguration, installiert wichtige Software und wendet Konfigurationen an, sodass der Cluster sofort bereit ist, ML-Workloads auszuführen. Alle Softwarepakete sind in das AMI eingebettet, sodass während der Bereitstellung kein Internetzugang erforderlich ist.

In der folgenden Tabelle sind die in der AMI-based Konfiguration enthaltenen Funktionen aufgeführt:

Funktion Description
Slurm-DaemonenController- und Compute-Daemons wurden automatisch gestartet
DockerContainer-Runtime zum Erstellen und Ausführen von ML-Containern
EnrootRootlose Container-Ausführung für Slurm-Workloads
PyxisSlurm-Plugin für die Container-Integration
Slurm-BuchhaltungKonfiguriert die Slurm-Jobbuchhaltung für die Verfolgung des Auftragsverlaufs und des Ressourcenverbrauchs
MariaDBStellt MariaDB auf dem Controller-Knoten als Backing-Datenbank für die Slurm-Buchhaltung bereit
Generierung von SSH-SchlüsselnSchlüsselpaar, das für den Standard-Ubuntu-Benutzer generiert wurde
SSH-AusbreitungBenutzeranmeldeinformationen werden bei Aufträgen mit mehreren Knoten über Rechenknoten hinweg weitergegeben
Slurm-Log-RotationBeugt Problemen mit dem Aufblähen der Logs und der vollen Festplatte vor
Einrichtung des Home-VerzeichnissesUbuntu-Benutzerstartverzeichnis, das in das gemeinsam genutzte Dateisystem eingebunden ist
  1. Speichern Sie Folgendes unter: create_cluster.json

    { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } } ] } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } }, "VpcConfig": { "SecurityGroupIds": ["sg-0abc123def456789a"], "Subnets": ["subnet-0abc123def456789a"] } }

    Beachten Sie, dass für jede Instanzgruppe kein angegeben LifeCycleConfig ist.

    Die Slurm-Topologie ist für jede Instanzgruppe definiert: Ihr my-controller-group wird die Controller Rolle zugewiesen (wird ausgeführtslurmctld), sie my-login-group dient als Login Knoten für den Benutzerzugriff und worker-group-1 ist ein Compute Knoten, dem die Jobplanung partition-1 zugewiesen wird. SlurmConfig Auf Cluster-Ebene HyperPod ist es SlurmConfigStrategy: "Managed" die zentrale Informationsquelle für die Partitionskonfiguration. Die Worker-Gruppe umfasst ein FSx for Lustre-Dateisystem, das /fsx für gemeinsamen Speicher gemountet VpcConfig ist, und wird auf Cluster-Ebene spezifiziert, wie es für FSx erforderlich ist.

    Tipp

    Wenn Sie ohne FSx testen, können Sie die Anfrage auslassen und FsxLustreConfig aus InstanceStorageConfigs der Anfrage entfernen. VpcConfig FSx ist für die Clustererstellung nicht erforderlich, wird jedoch für ML-Produktionsworkloads empfohlen.

  2. Erstellen Sie den Cluster:

    aws sagemaker create-cluster \ --cli-input-json file://create_cluster.json
  3. Überprüfen Sie den Status:

    aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster

    Nur bei AMI-based Konfiguration enthalten Instanzgruppen in der Antwort keinen LifeCycleConfig Block. Das Folgende ist ein gekürztes Beispiel, das die Controller-Instanzgruppe zeigt:

    { "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "InService", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "SlurmConfig": { "NodeType": "Controller" } } ] }

    Wenn der Status in wechseltInService, fahren Sie mit fortStellen Sie eine Verbindung zu Ihrem Cluster her.

Option B: Erweitern Sie die AMI-based Konfiguration mit OnInitComplete

Verwenden Sie diese Option, wenn Sie zusätzlich zur AMI-based Konfiguration Anpassungen benötigen, z. B. Monitoring-Agents, LDAP/SSSD Integration oder zusätzliche Speichermounts. SageMaker HyperPod führt zuerst die AMI-based Konfiguration aus und führt dann Ihr Erweiterungsskript aus.

  1. Schreiben Sie Ihr Erweiterungsskript. Zum Beispielextend-defaults.sh:

    #!/bin/bash set -e echo "Running post-initialization customizations..." # Example: Install a monitoring agent # apt-get install -y my-monitoring-agent # Example: Configure LDAP integration # /opt/custom/setup-ldap.sh # Example: Mount an additional S3 bucket # mount-s3 my-data-bucket /mnt/s3-data echo "Custom extensions complete."
    Verwenden von Erweiterungsskripten aus dem Awsome Distributed Training Repository

    Der Ordner Extensions im Awsome Distributed Training Repository bietet gebrauchsfertige Erweiterungsskripte für allgemeine Aufgaben wie das Hinzufügen von Benutzern und das Aktivieren der Beobachtbarkeit. Jede Funktion befindet sich in einem eigenen Verzeichnis und verfügt über ein eigenes Einstiegspunkt-Skript, das direkt als Skript bereitgestellt werden kann. OnInitComplete

    Für Cluster, die mehrere Funktionen benötigen, empfehlen wir, das run_extensions.sh Skript zu verwenden, das auf der obersten Ebene des Erweiterungsordners verfügbar ist. Dieses Skript orchestriert alle verfügbaren Erweiterungsskripts und bietet einfache boolesche Schalter, um die einzelnen Funktionen zu aktivieren oder zu deaktivieren. Um es zu verwenden, laden Sie den gesamten Erweiterungsordner in Ihren Amazon S3-Bucket hoch und geben Sie run_extensions.sh als Skript Folgendes an: OnInitComplete

    s3://<bucket>/<prefix>/ |-- run_extensions.sh (OnInitComplete target) |-- detect-node/ (node type detection utility) |-- add-users/ (user management scripts + config) |-- observability/ (observability scripts + config)

    Im Inneren aktivieren oder deaktivieren Sie jede Funktionrun_extensions.sh, indem Sie das entsprechende Flag setzen:

    ENABLE_ADD_USERS="true" ENABLE_OBSERVABILITY="true"

    Die Konfigurationsdatei jeder aktivierten Funktion muss vor dem Hochladen auf Amazon S3 gefüllt werden. Einzelheiten zur Konfiguration finden Sie in der README-Datei im Verzeichnis der einzelnen Funktionen.

  2. Auf Amazon S3 hochladen (der Bucket-Pfad muss mit beginnens3://sagemaker-):

    aws s3 cp extend-defaults.sh \ s3://sagemaker-amzn-s3-demo-bucket/scripts/
  3. Speichern Sie Folgendes untercreate_cluster.json:

    { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "OnInitComplete": "extend-defaults.sh", "SourceS3Uri": "s3://sagemaker-amzn-s3-demo-bucket/scripts/" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "OnInitComplete": "extend-defaults.sh", "SourceS3Uri": "s3://sagemaker-amzn-s3-demo-bucket/scripts/" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "LifeCycleConfig": { "OnInitComplete": "extend-defaults.sh", "SourceS3Uri": "s3://sagemaker-amzn-s3-demo-bucket/scripts/" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole" } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } } }
    Wichtig

    Wenn angegeben OnInitComplete ist, SourceS3Uri ist erforderlich. OnCreateund OnInitComplete können nicht zusammen in derselben Instanzgruppe verwendet werden.

    Tipp

    Sie können Optionen innerhalb eines Clusters kombinieren. Verwenden Sie die AMI-based Konfiguration beispielsweise nur auf dem Controller und OnInitComplete auf den Workern.

    Die Slurm-Topologie ist dieselbe wie in Option A. Jede Instanzgruppe hat eine SlurmConfig Definition ihrer Knotenrolle und Partitionszuweisung und SlurmConfigStrategy: "Managed" wird auf Cluster-Ebene festgelegt. Der einzige Unterschied besteht in der Hinzufügung von LifeCycleConfig withOnInitComplete, die besagt, dass das Erweiterungsskript ausgeführt werden HyperPod soll, nachdem die AMI-based Konfiguration auf jedem Knoten abgeschlossen ist. Um FSx hinzuzufügen, schließen Sie die entsprechenden Instanzgruppen ein FsxLustreConfig oder FsxOpenZfsConfig in InstanceStorageConfigs sie ein und fügen Sie sie VpcConfig auf Cluster-Ebene hinzu, wie unter beschriebenFSx- und VPC-Konfiguration.

  4. Erstellen Sie den Cluster:

    aws sagemaker create-cluster \ --cli-input-json file://create_cluster.json
  5. Überprüfen Sie den Status:

    aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster

    Bei OnInitComplete wird die Antwort OnInitComplete in der angezeigtLifeCycleConfig. Das Folgende ist ein gekürztes Beispiel, das die Controller-Instanzgruppe zeigt:

    { "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "InService", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-amzn-s3-demo-bucket/scripts/", "OnInitComplete": "extend-defaults.sh" } } ] }

    Wenn der Status in wechseltInService, fahren Sie mit fortStellen Sie eine Verbindung zu Ihrem Cluster her.

Option C: Vollständige benutzerdefinierte Steuerung mit OnCreate (erweitert)

Verwenden Sie diese Option, wenn Sie die vollständige Kontrolle über die Bereitstellung benötigen, einschließlich der Installation von Software, der Durchführung von Infrastrukturänderungen und der Entscheidung, wann Slurm gestartet werden soll. MitOnCreate, SageMaker HyperPod führt die AMI-based Konfiguration nicht aus und startet Slurm nicht automatisch.

Anmerkung

Wenn Sie neu in diesem Bereich sind SageMaker HyperPod und keine spezifischen Anpassungsanforderungen haben, empfehlen wir, mit Option A oder Option B zu beginnen. Sie können später jederzeit in den benutzerdefinierten Modus migrieren.

  1. Bereiten Sie Lebenszyklus-Skripte vor und laden Sie sie auf Amazon S3 hoch. Wenn Sie bei Null anfangen, verwenden Sie die Beispielskripte aus dem Awsome Distributed Training GitHub Repository:

    git clone https://github.com/aws-samples/awsome-distributed-training/ cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config

    Auf Amazon S3 hochladen (der Bucket-Pfad muss mit beginnens3://sagemaker-):

    aws s3 sync . \ s3://sagemaker-amzn-s3-demo-bucket/lifecycle/src

    Weitere Informationen zu den Lebenszyklusskripten finden Sie unter Anpassen von SageMaker HyperPod Clustern mithilfe von Lebenszyklusskripten.

  2. Speichern Sie Folgendes untercreate_cluster.json:

    { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-amzn-s3-demo-bucket/lifecycle/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-amzn-s3-demo-bucket/lifecycle/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-amzn-s3-demo-bucket/lifecycle/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole" } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } } }

    Die Slurm-Topologie folgt demselben SlurmConfig Muster wie die anderen Optionen. Der Hauptunterschied besteht LifeCycleConfig in. OnCreate Dies weist darauf HyperPod hin, dass Sie die AMI-based Konfiguration vollständig überspringen und stattdessen Ihr on_create.sh Skript ausführen sollen. Ihre Skripte sind für die gesamte Bereitstellungssequenz verantwortlich, einschließlich der Installation von Software, der Konfiguration von Slurm und dem Starten der Slurm-Daemons. Um FSx hinzuzufügen, schließen Sie die entsprechenden Instanzgruppen ein FsxLustreConfig oder FsxOpenZfsConfig in sie ein und fügen Sie sie InstanceStorageConfigs auf Cluster-Ebene hinzu, wie VpcConfig unter beschrieben. FSx- und VPC-Konfiguration

  3. Erstellen Sie den Cluster:

    aws sagemaker create-cluster \ --cli-input-json file://create_cluster.json
  4. Überprüfen Sie den Status:

    aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster

    Bei OnCreate wird die Antwort OnCreate in der angezeigtLifeCycleConfig. Das Folgende ist ein gekürztes Beispiel, das die Controller-Instanzgruppe zeigt:

    { "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "InService", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-amzn-s3-demo-bucket/lifecycle/src", "OnCreate": "on_create.sh" } } ] }

    Wenn der Status in wechseltInService, fahren Sie mit fortStellen Sie eine Verbindung zu Ihrem Cluster her.

Häufige Validierungsfehler

Fehler Auflösung
„Cluster muss genau einen InstanceGroup mit Controller-Knotentyp haben“ Stellen Sie sicher, dass genau eine Instanzgruppe über Folgendes verfügtSlurmConfig.NodeType: "Controller"
„Partitionen können nur Compute-Knotentypen zugewiesen werden“ PartitionNamesAus unseren Controller Login Instanzgruppen entfernen
„FSx-Konfigurationen werden nur für benutzerdefinierte VPC unterstützt“ Fügen Sie Ihrer Anfrage hinzuVpcConfig, wenn Sie FSx verwenden
„LifeCycleConfig ist für die Instanzgruppe erforderlich...“ EKS-Cluster. Die optionale Konfiguration des Knotenlebenszyklus wird nicht unterstützt.
„OnCreate und OnInitComplete in schließen LifeCycleConfig sich gegenseitig aus...“ Entferne entweder OnCreate oderOnInitComplete. Sie können nicht beides angeben.
„LifeCycleConfig zum Beispiel ist die Gruppe unvollständig...“ Wenn OnCreate oder angegeben OnInitComplete ist, SourceS3Uri muss ebenfalls angegeben werden.
„LifeCycleConfig ist optional, erfordert aber ein kompatibles AMI...“ AusführenUpdateClusterSoftware, um auf ein AMI zu aktualisieren, das die optionale Konfiguration des Knotenlebenszyklus unterstützt.
„LifeCycleConfig zum Beispiel wird eine Instanzgruppe bereitgestellt, enthält aber keine Konfiguration...“ Geben Sie SourceS3Uri mit OnCreate oder OnInitComplete an oder lassen Sie es LifeCycleConfig ganz weg.

Stellen Sie eine Verbindung zu Ihrem Cluster her

Stellen Sie eine Verbindung her und überprüfen Sie, nachdem der Cluster-Status wieder erreicht ist InService (in der Regel 10 bis 15 Minuten).

  1. Listet Clusterknoten auf, um Instanz-IDs abzurufen:

    aws sagemaker list-cluster-nodes --cluster-name my-hyperpod-cluster
  2. Stellen Sie mit dem AWS Systems Manager Session Manager eine Verbindung her:

    aws ssm start-session \ --target sagemaker-cluster:my-hyperpod-cluster_my-login-group-i-0abc123def456789b \ --region us-west-2
  3. Stellen Sie sicher, dass Slurm richtig konfiguriert ist:

    # Check Slurm nodes sinfo # Check Slurm partitions sinfo -p partition-1 # Submit a test job srun -p partition-1 --nodes=1 hostname

Weitere Informationen zum Ausführen von ML-Workloads finden Sie unter. Jobs auf SageMaker HyperPod Clustern

Löschen des Clusters und Bereinigen der Ressourcen

Löschen Sie den Cluster nach dem Testen, um weitere Gebühren zu vermeiden:

aws sagemaker delete-cluster --cluster-name my-hyperpod-cluster

Wenn Sie Node-Lifecycle-Skripts verwendet haben (Option B oder Option C), bereinigen Sie den Amazon S3-Bucket:

aws s3 rm s3://sagemaker-amzn-s3-demo-bucket/lifecycle/src --recursive

Wenn Sie nur die AMI-based Konfiguration verwendet haben (Option A), ist keine Amazon S3-Bereinigung für Node-Lifecycle-Skripts erforderlich.

Wenn Sie Trainingsworkloads ausgeführt haben, suchen Sie auch in Amazon S3, Amazon FSx for Lustre oder Amazon Elastic File System nach Daten oder Artefakten und löschen Sie diese, um Gebühren zu vermeiden.