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, 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](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 bei Bedarf direkt hierher springen [Erstellen Ihres -Clusters](#smcluster-getting-started-slurm-cli-create-cluster) 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? 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 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 unter[SageMaker HyperPod Slurm-Konfiguration](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration). 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 angeben`SlurmConfig`, 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" } } ``` `SlurmConfigStrategy`bestimmt, 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. Mit`Managed`, HyperPod behandelt die API als zentrale Informationsquelle und erkennt und blockiert Updates, falls `slurm.conf` auf der Festplatte etwas verloren geht. Mit`Overwrite`, 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](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration). ### 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 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 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** `OnCreate`und 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 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 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](#smcluster-getting-started-slurm-cli-lifecycle-options) 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](sagemaker-hyperpod-prerequisites.md) ### 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-Daemonen | Controller- und Compute-Daemons wurden automatisch gestartet | | Docker | Container-Runtime zum Erstellen und Ausführen von ML-Containern | | Enroot | Rootlose Container-Ausführung für Slurm-Workloads | | Pyxis | Slurm-Plugin für die Container-Integration | | Slurm-Buchhaltung | Konfiguriert die Slurm-Jobbuchhaltung für die Verfolgung des Auftragsverlaufs und des Ressourcenverbrauchs | | MariaDB | Stellt MariaDB auf dem Controller-Knoten als Backing-Datenbank für die Slurm-Buchhaltung bereit | | Generierung von SSH-Schlüsseln | Schlüsselpaar, das für den Standard-Ubuntu-Benutzer generiert wurde | | SSH-Ausbreitung | Benutzeranmeldeinformationen werden bei Aufträgen mit mehreren Knoten über Rechenknoten hinweg weitergegeben | | Slurm-Log-Rotation | Beugt Problemen mit dem Aufblähen der Logs und der vollen Festplatte vor | | Einrichtung des Home-Verzeichnisses | Ubuntu-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ührt`slurmctld`), 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. 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. 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 wechselt**InService**, fahren Sie mit fort[Stellen Sie eine Verbindung zu Ihrem Cluster her](#smcluster-getting-started-slurm-cli-connect). ### 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 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 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://// |-- 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 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 (der Bucket-Pfad muss mit beginnen`s3://sagemaker-`): ``` aws s3 cp extend-defaults.sh \ s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/ ``` 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" }, "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. `OnCreate`und `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` with`OnInitComplete`, 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 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}} ``` Bei `OnInitComplete` wird die Antwort `OnInitComplete` in der angezeigt`LifeCycleConfig`. 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 wechselt**InService**, fahren Sie mit fort[Stellen Sie eine Verbindung 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 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](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 (der Bucket-Pfad muss mit beginnen`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 unter`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 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](#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}} ``` Bei `OnCreate` wird die Antwort `OnCreate` in der angezeigt`LifeCycleConfig`. 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 wechselt**InService**, fahren Sie mit fort[Stellen Sie eine Verbindung zu Ihrem Cluster her](#smcluster-getting-started-slurm-cli-connect). ### 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}} ``` 1. 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}} ``` 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 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. ## 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 Betrieb des Slurm-Clusters](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)