View a markdown version of this page

Erste Schritte mit der SageMaker HyperPod Verwendung von AWS CLI - Amazon SageMaker KI
Die wichtigsten KonzepteErstellen Ihres -ClustersConnect zu Ihrem Cluster herLöschen des Clusters und Bereinigen der RessourcenVerwandte Themen

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, der bereit ist, ML-Workloads zu planen und auszuführen. Das Tutorial behandelt die Einrichtung der Slurm-Topologie, die Konfigurationsoptionen für den Knotenlebenszyklus, optionalen gemeinsam genutzten FSx-Speicher und wie Sie eine Verbindung zu Ihrem Cluster herstellen.

Stellen Sie vor dem Start sicher, dass Sie die 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 direkt zu dieser Seite springen Erstellen Ihres -Clusters und bei Bedarf 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 zwar für jede Instanzgruppe und SlurmConfig auf Orchestrator.Slurm Clusterebene. Dies ist der empfohlene Ansatz für neue Cluster. Es bietet eine zentrale Informationsquelle, 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 drei Optionen für die Konfiguration des Knotenlebenszyklus. Im einfachsten Fall lassen Sie Knoten LifeCycleConfig komplett weg und konfigurieren sie HyperPod automatisch mithilfe der AMI-based Konfiguration, der Einrichtung von Slurm und wichtigen Paketen wie Docker, Enroot und Pyxis für die Ausführung von ML-Workloads, ohne dass Skripte oder Amazon S3 S3-Bucket erforderlich sind. 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 Damit Sie die volle Kontrolle über die gesamte Bereitstellungssequenz haben, können Ihre Skripte über den OnCreate Pfad alles selbst bestimmen, auch wenn Slurm gestartet wird.

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 for Lustre und FSx for OpenZFS, konfiguriert pro Instanzgruppe über. InstanceStorageConfigs Die FSx-Konfiguration ist für die Clustererstellung optional, wird jedoch für Produktionsworkloads empfohlen.

Konfiguration der Slurm-Topologie über die API

Alle Beispiele in diesem Tutorial verwenden die Konfiguration der API-driven Slurm-Topologie, bei der Sie die Slurm-Cluster-Struktur 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 Login-Knoten hinzufügen, um Benutzern einen dedizierten Zugangspunkt für das Senden und Verwalten von Jobs zur Verfügung zu stellen, ohne sich direkt beim Controller anmelden zu müssen. In der API-Anfrage weisen Sie jeder Instanzgruppe ihre Slurm-Rolle zu und geben dabei anSlurmConfig, ob die Gruppe als Controller-, Anmelde- oder Rechenknoten dient. Rechengruppen werden auch einer oder mehreren Slurm-Partitionen zugeordnet, die als logische Warteschlangen fungieren und die Art und Weise organisieren, wie Jobs über verschiedene Knotengruppen hinweg geplant werden.

Steuert auf Clusterebene, 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 sie manuelle Änderungen überschreibt oder ob die API-defined Konfiguration mit den von Ihnen vorgenommenen manuellen Änderungen zusammengeführt wird. Hier finden Sie 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(Clusterebene):

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

SlurmConfigStrategybestimmt, wie die Zuordnungen von Partitionen zu Knoten 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 Werte, ordnet Recheninstanzgruppen den ihnen zugewiesenen Partitionen zu und registriert Controller- und Login-Knoten mit den entsprechenden Slurm-Rollen.

Die von Ihnen gewählte Strategie steuert, was passiert, wenn die Partitionskonfiguration in außerhalb der API geändert slurm.conf wurde, z. B. indem ein Administrator die Datei direkt auf dem Controller-Knoten bearbeitet. Bei Managed HyperPod behandelt die API als zentrale Informationsquelle und erkennt und blockiert Aktualisierungen, wenn slurm.conf auf der Festplatte etwas verändert wurde. Mit Overwrite HyperPod zwingt die API-defined Konfiguration auf den Controller, wobei alle manuellen Änderungen daran verworfen werden. slurm.conf Dies ist nützlich für die Wiederherstellung nach einer unbeabsichtigten Änderung. Mit Merge HyperPod behält manuelle Änderungen bei slurm.conf und führt sie mit der API-Konfiguration zusammen, sodass fortgeschrittene Benutzer die Flexibilität haben, benutzerdefinierte slurm.conf Einstellungen neben Partitionen beizubehalten. API-managed

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

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

Anmerkung

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

Optionen für die Konfiguration des Knotenlebenszyklus

Bei der Erstellung eines SageMaker HyperPod Slurm-Clusters wählen Sie aus, wie die Knoten jeder Instanzgruppe 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 unterschiedliches Maß an Kontrolle über den Bereitstellungsprozess bietet.

Wenn Sie nur die AMI-based Konfiguration verwenden, verzichten Sie ganz 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 weder Amazon S3 S3-Bucket noch Skripte.

Mit der Option Erweiterung geben OnInitComplete Sie 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 Speichermounts hinzufügen, ohne die Basisbereitstellung verwalten zu müssen.

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

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

Die optionale Konfiguration des Knotenlebenszyklus wird nur für Slurm-orchestrated Cluster unterstützt. EKS-orchestrated Cluster und Slurm-Cluster, die Continuous verwenden, benötigen NodeProvisioningMode weiterhin LifeCycleConfig mit OnCreate und SourceS3Uri auf jeder Instanzgruppe.

Anmerkung

OnCreateund schließen OnInitComplete sich gegenseitig aus. Wenn Sie beide für dieselbe Instanzgruppe angeben, tritt ein Validierungsfehler auf.

FSx- und VPC-Konfiguration

Für ML-Workloads ist ein gemeinsam genutztes Hochleistungsdateisystem für die Speicherung von Trainingsdaten, Modell-Checkpoints und gemeinsam genutzten Bibliotheken auf Clusterknoten unerlässlich. SageMaker HyperPod unterstützt Amazon FSx for Lustre und FSx for OpenZFS, konfiguriert pro Instanzgruppe über. InstanceStorageConfigs FSx-Dateisysteme befinden sich in Ihrer VPC, daher ist eine benutzerdefinierte VPC-Konfiguration (VpcConfig) erforderlich, wenn Sie FSx verwenden.

Die FSx-Konfiguration funktioniert mit allen drei Konfigurationsoptionen für den Knotenlebenszyklus. Wenn Sie AMI-based Configuration oder verwendenOnInitComplete, HyperPod erfolgt die FSx-Montage automatisch. Bei der Verwendung OnCreate sind Ihre Lifecycle-Skripte für das Mounten verantwortlich.

FSx for 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 dies 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 eine FSx for Lustre- und eine FSx für OpenZFS-Konfiguration haben. Verschiedene Instanzgruppen können unterschiedliche Dateisysteme mounten.

VPC-Konfiguration (für FSx erforderlich):

Fügen Sie Ihrer CreateCluster Anfrage VpcConfig auf Clusterebene 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 unterVoraussetzungen für die Verwendung SageMaker HyperPod.

Erstellen Ihres -Clusters

In diesem Abschnitt werden Sie Schritt für Schritt durch die Erstellung eines Clusters mithilfe der drei unter beschriebenen Konfigurationsoptionen für den Knotenlebenszyklus geführt. Optionen für die Konfiguration des Knotenlebenszyklus Für die meisten Benutzer empfehlen wir, mit Option A zu beginnen, also nur mit AMI-based Konfiguration. Es erfordert keine Skripte oder einen Amazon S3 S3-Bucket und bietet einen voll funktionsfähigen Cluster, der sofort einsatzbereit ist. 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 für ExecutionRole alle Beispiele den ARN der IAM-Rolle an, die Sie mit dem Managed AmazonSageMakerClusterInstanceRolePolicy in Voraussetzungen für die Verwendung SageMaker HyperPod erstellt haben.

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

Dies ist der einfachste Weg. Es werden keine Amazon S3 S3-Buckets, 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 für die Ausführung von ML-Workloads bereit ist. 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-Laufzeit zum Erstellen und Ausführen von ML-Containern
EnrootContainer-Ausführung ohne Root für Slurm-Workloads
PyxisSlurm-Plugin für die Container-Integration
Slurm-BuchhaltungKonfiguriert die Slurm-Jobbuchhaltung für die Nachverfolgung des Jobverlaufs und des Ressourcenverbrauchs
MariaDBStellt MariaDB auf dem Controller-Knoten als unterstützende Datenbank für die Slurm-Buchhaltung bereit
Generierung von SSH-SchlüsselnDas Schlüsselpaar wurde für den Standard-Ubuntu-Benutzer generiert
SSH-VerbreitungBenutzeranmeldedaten werden für Jobs mit mehreren Knoten über mehrere Rechenknoten verteilt
Rotation des Slurm-ProtokollsBeugt einem Übermaß an Protokollen und einer vollen Festplatte vor
Einrichtung des Home-VerzeichnissesDas Home-Verzeichnis des Ubuntu-Benutzers, das in das gemeinsam genutzte Dateisystem eingebunden ist

  1. Speichern Sie Folgendes alscreate_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 keine Instanzgruppe angegeben LifeCycleConfig ist.

    Die Slurm-Topologie wird 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, der partition-1 für die Jobplanung zugewiesen ist. SlurmConfig Auf Clusterebene HyperPod ist dies SlurmConfigStrategy: "Managed" die zentrale Informationsquelle für die Partitionskonfiguration. Die Worker-Gruppe umfasst ein FSx for Lustre-Dateisystem, das /fsx für gemeinsam genutzten Speicher eingehängt 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 weglassen InstanceStorageConfigs und FsxLustreConfig VpcConfig aus der Anfrage entfernen. 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. Im Folgenden finden Sie 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 zu wechseltInService, fahren Sie mit fortConnect zu Ihrem Cluster her.

Option B: AMI-based Konfiguration erweitern 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 von Observability. Jede Funktion befindet sich in einem eigenen Verzeichnis mit einem eigenen Einstiegsskript, 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 Ordners Extensions verfügbar ist. Dieses Skript orchestriert alle verfügbaren Erweiterungsskripten und bietet einfache boolesche Schalter, um die einzelnen Funktionen zu aktivieren oder zu deaktivieren. Um es zu verwenden, laden Sie den gesamten Ordner Extensions in Ihren Amazon S3 S3-Bucket hoch und geben Sie run_extensions.sh als OnInitComplete Skript Folgendes an:

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

    Aktivieren oder deaktivieren Sie darin 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 (Bucket-Pfad muss beginnen mits3://sagemaker-):

    aws s3 cp extend-defaults.sh \
    s3://sagemaker-amzn-s3-demo-bucket/scripts/

  3. Speichern Sie Folgendes alscreate_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

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

    Tipp

    Sie können Optionen innerhalb eines Clusters mischen. Verwenden Sie beispielsweise die AMI-based Konfiguration 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 Clusterebene festgelegt. Der einzige Unterschied besteht in der Hinzufügung von LifeCycleConfig withOnInitComplete, die anweist, dass Ihr Erweiterungsskript ausgeführt werden HyperPod soll, nachdem die AMI-based Konfiguration auf jedem Knoten abgeschlossen ist. Um FSx hinzuzufügen, fügen Sie FsxLustreConfig oder FsxOpenZfsConfig in InstanceStorageConfigs die entsprechenden Instanzgruppen ein und fügen Sie es VpcConfig auf Clusterebene 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

    MitOnInitComplete, die Antwort wird OnInitComplete in der angezeigtLifeCycleConfig. Im Folgenden finden Sie 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 zu wechseltInService, fahren Sie mit fortConnect 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 noch keine Erfahrung damit haben 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-Skripts 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 (Bucket-Pfad muss beginnen mits3://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 alscreate_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 liegt LifeCycleConfig bei. 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, fügen Sie FsxLustreConfig oder FsxOpenZfsConfig in InstanceStorageConfigs die entsprechenden Instanzgruppen ein und fügen Sie es VpcConfig auf Clusterebene hinzu, wie unter beschriebenFSx- 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

    MitOnCreate, die Antwort wird OnCreate in der angezeigtLifeCycleConfig. Im Folgenden finden Sie 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 zu wechseltInService, fahren Sie mit fortConnect zu Ihrem Cluster her.

Häufige Validierungsfehler

Fehler Auflösung
„Der Cluster muss genau einen InstanceGroup mit dem Knotentyp Controller 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 Custom VPC unterstützt“ Zu deiner Anfrage VpcConfig hinzufügen, wenn du FSx verwendest
"LifeCycleConfig ist für die Instanzgruppe erforderlich...“ EKS-Cluster oder Slurm ContinuousNodeProvisioningMode. 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...“ Wann OnCreate oder angegeben OnInitComplete ist, SourceS3Uri muss ebenfalls angegeben werden.
„LifeCycleConfig ist optional, erfordert aber ein kompatibles AMI...“ Wird ausgeführtUpdateClusterSoftware, um auf ein AMI zu aktualisieren, das die optionale Konfiguration des Knotenlebenszyklus unterstützt.
„LifeCycleConfig Die Instanzgruppe wird bereitgestellt, enthält aber keine Konfiguration...“ Geben Sie SourceS3Uri mit OnCreate oder OnInitComplete an oder lassen Sie es LifeCycleConfig ganz weg.

Connect zu Ihrem Cluster her

Wenn der Clusterstatus auf InService (normalerweise 10 bis 15 Minuten) wechselt, stellen Sie eine Verbindung her und überprüfen Sie den Vorgang.

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

    aws sagemaker list-cluster-nodes --cluster-name my-hyperpod-cluster

  2. Stellen Sie mit dem AWS Systems Manager Sitzungsmanager 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 (Option B oder Option C) verwendet haben, bereinigen Sie den Amazon S3 S3-Bucket:

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

Wenn Sie nur die AMI-based Konfiguration (Option A) verwendet haben, ist keine Amazon S3 S3-Bereinigung für Knotenlebenszyklus-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.