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](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli) 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](sagemaker-hyperpod-prerequisites.md) (VPC, Kontingente, FSx) und [AWS Identity and Access Management für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md) (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](#smcluster-getting-started-slurm-cli-create-cluster) 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? 1. **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 unter[SageMaker HyperPod Slurm-Konfiguration](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration). 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 an`SlurmConfig`, 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" } } ``` `SlurmConfigStrategy`bestimmt, 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](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration). ### 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 darauf`LifeCycleConfig`. 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** `OnCreate`und 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 verwenden`OnInitComplete`, 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 unter[Voraussetzungen für die Verwendung SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md). Weitere Informationen zum FSx-Setup finden Sie unter[Voraussetzungen für die Verwendung SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md). ## 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](#smcluster-getting-started-slurm-cli-lifecycle-options) 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](sagemaker-hyperpod-prerequisites.md) 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-Daemonen | Controller- und Compute-Daemons wurden automatisch gestartet | | Docker | Container-Laufzeit zum Erstellen und Ausführen von ML-Containern | | Enroot | Container-Ausführung ohne Root für Slurm-Workloads | | Pyxis | Slurm-Plugin für die Container-Integration | | Slurm-Buchhaltung | Konfiguriert die Slurm-Jobbuchhaltung für die Nachverfolgung des Jobverlaufs und des Ressourcenverbrauchs | | MariaDB | Stellt MariaDB auf dem Controller-Knoten als unterstützende Datenbank für die Slurm-Buchhaltung bereit | | Generierung von SSH-Schlüsseln | Das Schlüsselpaar wurde für den Standard-Ubuntu-Benutzer generiert | | SSH-Verbreitung | Benutzeranmeldedaten werden für Jobs mit mehreren Knoten über mehrere Rechenknoten verteilt | | Rotation des Slurm-Protokolls | Beugt einem Übermaß an Protokollen und einer vollen Festplatte vor | | Einrichtung des Home-Verzeichnisses | Das Home-Verzeichnis des Ubuntu-Benutzers, das in das gemeinsam genutzte Dateisystem eingebunden ist | 1. Speichern Sie Folgendes als`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 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ührt`slurmctld`), 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. 1. Erstellen Sie den Cluster: ``` aws sagemaker create-cluster \ --cli-input-json {{file://create_cluster.json}} ``` 1. Ü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 wechselt**InService**, fahren Sie mit fort[Connect zu Ihrem Cluster her](#smcluster-getting-started-slurm-cli-connect). ### 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 Beispiel`extend-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](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/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://// |-- 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 Funktion`run_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. 1. Auf Amazon S3 hochladen (Bucket-Pfad muss beginnen mit`s3://sagemaker-`): ``` aws s3 cp extend-defaults.sh \ s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/ ``` 1. Speichern Sie Folgendes als`create_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. `OnCreate`und `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` with`OnInitComplete`, 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 beschrieben[FSx- und VPC-Konfiguration](#smcluster-getting-started-slurm-cli-fsx-vpc). 1. Erstellen Sie den Cluster: ``` aws sagemaker create-cluster \ --cli-input-json {{file://create_cluster.json}} ``` 1. Überprüfen Sie den Status: ``` aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}} ``` Mit`OnInitComplete`, die Antwort wird `OnInitComplete` in der angezeigt`LifeCycleConfig`. 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 wechselt**InService**, fahren Sie mit fort[Connect zu Ihrem Cluster her](#smcluster-getting-started-slurm-cli-connect). ### 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. Mit`OnCreate`, 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](https://github.com/aws-samples/awsome-distributed-training/): ``` 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 mit`s3://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](sagemaker-hyperpod-lifecycle-best-practices-slurm.md). 1. Speichern Sie Folgendes als`create_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 beschrieben[FSx- und VPC-Konfiguration](#smcluster-getting-started-slurm-cli-fsx-vpc). 1. Erstellen Sie den Cluster: ``` aws sagemaker create-cluster \ --cli-input-json {{file://create_cluster.json}} ``` 1. Überprüfen Sie den Status: ``` aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}} ``` Mit`OnCreate`, die Antwort wird `OnCreate` in der angezeigt`LifeCycleConfig`. 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 wechselt**InService**, fahren Sie mit fort[Connect zu Ihrem Cluster her](#smcluster-getting-started-slurm-cli-connect). ### 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}} ``` 1. 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}} ``` 1. 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](sagemaker-hyperpod-run-jobs-slurm.md) ## 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. ## Verwandte Themen + [SageMaker HyperPod Slurm-Konfiguration](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration) + [Anpassen von SageMaker HyperPod Clustern mithilfe von Lebenszyklusskripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md) + [FSx-Konfiguration über InstanceStorageConfigs](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config) + [SageMaker HyperPod Slurm-Cluster-Operationen](sagemaker-hyperpod-operate-slurm.md) + [Erweiterungsskripte für SageMaker HyperPod](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions) + [Anpassen von SageMaker HyperPod Clustern mithilfe von Lebenszyklusskripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)