Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Commencer à SageMaker HyperPod utiliser le AWS CLI
Le didacticiel suivant explique comment créer un nouveau SageMaker HyperPod cluster avec Slurm à l'aide des [AWS CLI commandes](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli) pour. SageMaker HyperPod À la fin de ce didacticiel, vous disposerez d'un cluster Slurm fonctionnel avec un nœud contrôleur, un nœud de connexion et un groupe de travail de calcul, prêt à planifier et à exécuter des charges de travail ML. Le didacticiel couvre la configuration de la topologie Slurm, les options de configuration du cycle de vie des nœuds, le stockage partagé FSx en option et la manière de se connecter à votre cluster.
Avant de commencer, assurez-vous d'avoir terminé [Conditions préalables à l'utilisation SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) (VPC, quotas, FSx) et [Gestion des identités et des accès AWS pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md) (rôles IAM, rôle d'exécution avec). `AmazonSageMakerClusterInstanceRolePolicy`
## Concepts clés
Cette section couvre les concepts de configuration de base pour créer un cluster SageMaker HyperPod Slurm. La compréhension de ces concepts vous aidera à faire des choix éclairés lors de la configuration de votre cluster, mais si vous souhaitez commencer immédiatement, vous pouvez accéder directement à [Créer votre cluster](#smcluster-getting-started-slurm-cli-create-cluster) cette page et y revenir si nécessaire.
Lors de la création d'un Slurm-orchestrated cluster, vous devez effectuer deux choix de configuration indépendants :
1. **Configuration de la topologie Slurm** — Comment est définie la topologie du cluster Slurm (rôles des nœuds, partitions) ?
1. **Configuration du cycle de vie des nœuds** : comment les nœuds sont-ils provisionnés et personnalisés ?
Pour la topologie Slurm, ce didacticiel utilise l'approche de API-driven configuration, dans laquelle vous définissez les rôles des nœuds et les partitions directement dans la `CreateCluster` demande, `SlurmConfig` sur chaque groupe d'instances et `Orchestrator.Slurm` au niveau du cluster. Il s'agit de l'approche recommandée pour les nouveaux clusters. Il fournit une source unique de vérité, une validation intégrée et une détection des dérives de configuration des partitions, sans aucun fichier supplémentaire à gérer. Vous pouvez également utiliser un ancien `provisioning_parameters.json` fichier stocké dans Amazon S3 à des fins de rétrocompatibilité avec les clusters existants. Pour plus de détails sur l'ancienne approche, voir[SageMaker HyperPod Configuration du Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration).
Pour la configuration du cycle de vie des nœuds SageMaker HyperPod , trois options sont disponibles. Dans le cas le plus simple, vous omettez `LifeCycleConfig` complètement et HyperPod configurez automatiquement les nœuds en utilisant la AMI-based configuration, en configurant Slurm et des packages essentiels tels que Docker, Enroot et Pyxis pour exécuter des charges de travail ML, sans aucun script ni compartiment Amazon S3 requis. Si vous avez besoin de personnalisations en plus de la AMI-based configuration, vous pouvez fournir un script d'extension `OnInitComplete` qui s'exécute une fois la configuration terminée. Pour un contrôle total sur l'ensemble de la séquence d'approvisionnement, le `OnCreate` chemin permet à vos scripts de tout contrôler, y compris au démarrage de Slurm.
Pour les charges de travail ML, vous aurez généralement également besoin d'un système de fichiers partagé à hautes performances pour les données d'entraînement, les points de contrôle et les bibliothèques partagées. SageMaker HyperPod prend en charge Amazon FSx for Lustre et FSx pour OpenZFS, configurés par groupe d'instances via. `InstanceStorageConfigs` La configuration FSx est facultative pour la création de clusters mais recommandée pour les charges de travail de production.
### Configuration de la topologie Slurm via l'API
Tous les exemples présentés dans ce didacticiel utilisent la configuration de la topologie API-driven Slurm, dans laquelle vous définissez la structure du cluster Slurm directement dans la demande d'`CreateCluster`API plutôt que par le biais d'un fichier de configuration distinct.
Un cluster Slurm nécessite au moins un nœud contrôleur (qui exécute le `slurmctld` démon et coordonne la planification des tâches) et un ou plusieurs nœuds de calcul (qui exécutent les tâches). Vous pouvez éventuellement ajouter un nœud de connexion pour fournir aux utilisateurs un point d'accès dédié pour soumettre et gérer des tâches sans se connecter directement au contrôleur. Dans la demande d'API, vous attribuez à chaque groupe d'instances son rôle Slurm en `SlurmConfig` spécifiant si le groupe sert de contrôleur, de connexion ou de nœud de calcul. Les groupes de calcul sont également mappés sur une ou plusieurs partitions Slurm, qui agissent comme des files d'attente logiques qui organisent la façon dont les tâches sont planifiées sur différents ensembles de nœuds.
Au niveau du cluster, `Orchestrator.Slurm` contrôle le mode de HyperPod gestion de la configuration de la partition dans`slurm.conf`. Vous choisissez une stratégie qui détermine s'il s' HyperPod agit de la seule source fiable pour la topologie des partitions, si elle remplace les modifications manuelles ou si elle fusionne la API-defined configuration avec les modifications manuelles que vous avez apportées. Voici une référence pour les champs utilisés.
**SlurmConfig**(par groupe d'instances) :
```
"SlurmConfig": {
"NodeType": "Controller | Login | Compute",
"PartitionNames": ["partition-name"]
}
```
| Champ | Description |
| --- | --- |
| NodeType | Obligatoire. Le rôle Slurm pour ce groupe d'instances. Valeurs valides : Controller, Login, Compute. Il doit y avoir exactement un groupe d'instancesController. |
| PartitionNames | Conditionnelle. Noms des partitions Slurm. Obligatoire pour Compute le type de nœud ; non autorisé pour Controller ouLogin. |
**Orchestrator.Slurm**(au niveau du cluster) :
```
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed | Overwrite | Merge"
}
}
```
`SlurmConfigStrategy`détermine comment HyperPod gère les mappages partition-nœud `slurm.conf` sur le nœud contrôleur. Lorsque vous créez ou mettez à jour un cluster, HyperPod écrit la configuration de partition en `slurm.conf` fonction de celle `SlurmConfig` que vous avez définie pour chaque groupe d'instances, en mappant les groupes d'instances de calcul aux partitions qui leur sont attribuées et en enregistrant les nœuds de contrôleur et de connexion avec les rôles Slurm appropriés.
La stratégie que vous choisissez contrôle ce qui se passe lorsque la configuration de la partition `slurm.conf` a été modifiée en dehors de l'API, par exemple lorsqu'un administrateur édite le fichier directement sur le nœud du contrôleur. Avec`Managed`, HyperPod traite l'API comme la seule source fiable et détecte et bloque les mises à jour en cas de dérive `slurm.conf` sur le disque. Avec`Overwrite`, HyperPod force la API-defined configuration sur le contrôleur, annulant toute modification manuelle apportée à. `slurm.conf` Cela est utile pour récupérer après une modification involontaire. Avec`Merge`, HyperPod préserve les modifications manuelles `slurm.conf` et les fusionne avec la configuration de l'API, offrant aux utilisateurs avancés la flexibilité de conserver des `slurm.conf` paramètres personnalisés en même API-managed temps que les partitions.
| Stratégie | Détection de la dérive des partitions | Modifications manuelles | Cas d’utilisation |
| --- | --- | --- | --- |
| Managed (par défaut) | Activé ; bloque les mises à jour en cas de dérive | Non pris en charge | Source unique de vérité |
| Overwrite | Désactivé | Remplacé lors de la mise à jour | Récupération après une dérive |
| Merge | Désactivé | Préservé et fusionné | slurm.confBesoins personnalisés |
**Important**
La détection de dérive s'applique uniquement à la configuration des partitions Slurm dans `slurm.conf` (mappages partition-nœud définis via l'API). Les modifications apportées à d'autres `slurm.conf` paramètres, tels que les paramètres de planification, les limites de ressources ou la configuration comptable, ne sont pas surveillées et ne seront ni détectées ni signalées par HyperPod.
**Note**
Si vous préférez définir la topologie Slurm à l'aide d'un `provisioning_parameters.json` fichier plutôt que de l'API, omettez-le dans les groupes d'instances et dans la demande `SlurmConfig` de cluster, et `Orchestrator.Slurm` téléchargez le fichier sur Amazon S3 en même temps que les scripts de cycle de vie de vos nœuds. Pour en savoir plus, consultez [SageMaker HyperPod Configuration du Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration).
### Options de configuration du cycle de vie des nœuds
Lorsque vous créez un cluster SageMaker HyperPod Slurm, vous choisissez le mode de provisionnement des nœuds de chaque groupe d'instances en configurant le `LifeCycleConfig` bloc dans la demande. `CreateCluster` SageMaker HyperPod prend en charge trois options de configuration du cycle de vie des nœuds, chacune offrant un niveau de contrôle différent sur le processus de provisionnement.
Avec **AMI-based la configuration** uniquement, vous omettez `LifeCycleConfig` complètement. HyperPod configure automatiquement les nœuds en utilisant AMI-based la configuration, en installant Slurm, en installant les packages essentiels et en démarrant tous les services requis. Il s'agit du chemin le plus simple et ne nécessite aucun compartiment ou script Amazon S3.
Avec l'option **Extension**, vous spécifiez `OnInitComplete` et `SourceS3Uri` pointez vers votre script d'extension dans Amazon S3. `LifeCycleConfig` HyperPod exécute d'abord la AMI-based configuration complète, puis exécute votre script. Cela vous permet d'ajouter des personnalisations, telles que des agents de surveillance, l'intégration LDAP ou des montages de stockage supplémentaires, sans gérer le provisionnement de base.
Avec l'option **Personnalisé**, vous spécifiez `OnCreate` et `SourceS3Uri` pointez vers votre ensemble de scripts de cycle de vie complet dans Amazon S3. `LifeCycleConfig` HyperPod n'exécute pas AMI-based la configuration et ne démarre pas Slurm. Vos scripts possèdent l'intégralité de la séquence de provisionnement. Cela vous donne un contrôle total sur les logiciels installés, leur configuration et le moment où Slurm démarre.
| Option de cycle de vie des nœuds | Vous avez besoin d'un compartiment Amazon S3 ? | Des scripts à télécharger ? | LifeCycleConfig dans l'API ? |
| --- | --- | --- | --- |
| AMI-based configuration uniquement (la plus simple) | Non | Non | Omettre complètement |
| Prolongation (OnInitComplete) | Oui | Seul votre script d'extension | OnInitComplete \+ SourceS3Uri |
| Personnalisé (OnCreate) | Oui | Ensemble de scripts de cycle de vie complet | OnCreate \+ SourceS3Uri |
**Note**
La configuration facultative du cycle de vie des nœuds n'est prise en charge que pour les Slurm-orchestrated clusters. EKS-orchestrated les clusters et les clusters Slurm utilisant Continuous `NodeProvisioningMode` continuent d'être nécessaires `LifeCycleConfig` avec `OnCreate` et `SourceS3Uri` sur chaque groupe d'instances.
**Note**
`OnCreate`et s'`OnInitComplete`excluent mutuellement. La spécification des deux sur le même groupe d'instances entraîne une erreur de validation.
### Configuration de FSx et de VPC
Pour les charges de travail ML, un système de fichiers partagé à hautes performances est essentiel pour stocker les données d'entraînement, les points de contrôle des modèles et les bibliothèques partagées sur les nœuds du cluster. SageMaker HyperPod prend en charge Amazon FSx for Lustre et FSx pour OpenZFS, configurés par groupe d'instances via. `InstanceStorageConfigs` Les systèmes de fichiers FSx résident dans votre VPC. Une configuration VPC personnalisée () est donc requise lors de l'utilisation de FSx. `VpcConfig`
La configuration FSx fonctionne avec les trois options de configuration du cycle de vie des nœuds. Lors de l'utilisation AMI-based de la configuration ou`OnInitComplete`, HyperPod gère automatiquement le montage FSx. Lors de l'utilisation`OnCreate`, vos scripts de cycle de vie sont responsables du montage.
**FSx for Lustre :**
```
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "abcdefgh"
}
}
]
```
| Champ | Description |
| --- | --- |
| DnsName | Obligatoire. Nom DNS du système de fichiers FSx for Lustre. |
| MountPath | Facultatif. Le chemin de montage local sur l'instance. Valeur par défaut : /fsx |
| MountName | Obligatoire. Nom de montage du système de fichiers FSx for Lustre. Vous pouvez le trouver dans la console FSx for Lustre ou aws fsx describe-file-systems via. |
**FSx pour OpenZFS :**
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
"MountPath": "/shared"
}
}
]
```
| Champ | Description |
| --- | --- |
| DnsName | Obligatoire. Nom DNS du système de fichiers FSx pour OpenZFS. |
| MountPath | Facultatif. Le chemin de montage local sur l'instance. Valeur par défaut : /home |
**Note**
Chaque groupe d'instances peut avoir au maximum une configuration FSx for Lustre et une configuration FSx pour OpenZFS. Différents groupes d'instances peuvent monter différents systèmes de fichiers.
**Configuration VPC** (requise pour FSx) :
Ajoutez `VpcConfig` au niveau du cluster dans votre `CreateCluster` demande :
```
"VpcConfig": {
"SecurityGroupIds": ["sg-0abc123def456789a"],
"Subnets": ["subnet-0abc123def456789a"]
}
```
Pour plus d'informations sur la configuration d'un VPC, consultez. [Conditions préalables à l'utilisation SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) Pour plus d'informations sur la configuration de FSx, consultez. [Conditions préalables à l'utilisation SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md)
## Créer votre cluster
Cette section explique comment créer un cluster à l'aide de chacune des trois options de configuration du cycle de vie des nœuds décrites dans[Options de configuration du cycle de vie des nœuds](#smcluster-getting-started-slurm-cli-lifecycle-options). Pour la plupart des utilisateurs, nous recommandons de commencer par **l'option A**, AMI-based configuration uniquement. Il ne nécessite aucun script ni compartiment Amazon S3 et fournit un cluster entièrement fonctionnel prêt à l'emploi. Choisissez l'option B si vous devez ajouter des personnalisations en plus de la AMI-based configuration, ou l'option C si vous avez besoin d'un contrôle total sur le processus de provisionnement.
`ExecutionRole`Dans tous les exemples, indiquez l'ARN du rôle IAM que vous avez créé avec le rôle managé `AmazonSageMakerClusterInstanceRolePolicy` dans[Conditions préalables à l'utilisation SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md).
### Option A : AMI-based configuration uniquement (sans configuration du cycle de vie)
C'est le chemin le plus simple. Aucun compartiment, script ou fichier de configuration Amazon S3 n'est nécessaire. SageMaker HyperPod configure les nœuds automatiquement à l'aide de AMI-based la configuration, en installant les logiciels essentiels et en appliquant les configurations afin que le cluster soit prêt à exécuter des charges de travail ML prêtes à l'emploi. Tous les packages logiciels étant intégrés à l'AMI, aucun accès à Internet n'est requis lors du provisionnement.
Le tableau suivant répertorie les fonctionnalités incluses dans la AMI-based configuration :
| Capacité | Description |
| --- | --- |
| Démons Slurm | Le contrôleur et les démons de calcul démarrent automatiquement |
| Docker | Runtime de conteneur pour créer et exécuter des conteneurs ML |
| S'inscrire | Exécution de conteneurs sans racine pour les charges de travail Slurm |
| Pyxis | Plugin Slurm pour l'intégration de conteneurs |
| Comptabilité Slurm | Configure la comptabilité des tâches dans Slurm pour suivre l'historique des tâches et la consommation de ressources |
| MariaDB | Déploie MariaDB sur le nœud contrôleur en tant que base de données de sauvegarde pour la comptabilité Slurm |
| Génération de clés SSH | Paire de clés générée pour l'utilisateur Ubuntu par défaut |
| Propagation SSH | Informations d'identification utilisateur propagées entre les nœuds de calcul pour les tâches multi-nœuds |
| Rotation des bûches de boue | Prévient le surchargement des journaux et les problèmes de saturation du disque |
| Configuration du répertoire de base | Répertoire personnel de l'utilisateur Ubuntu monté sur un système de fichiers partagé |
1. Enregistrez ce qui suit sous le nom `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}}"]
}
}
```
Notez que non n'`LifeCycleConfig`est spécifié pour aucun groupe d'instances.
La topologie Slurm est définie `SlurmConfig` sur chaque groupe d'instances : elle `my-controller-group` se voit attribuer le `Controller` rôle (exécute`slurmctld`), `my-login-group` sert de `Login` nœud pour l'accès des utilisateurs et `worker-group-1` est un `Compute` nœud assigné à la planification `partition-1` des tâches. Au niveau du cluster, `SlurmConfigStrategy: "Managed"` assure HyperPod est la seule source fiable pour la configuration des partitions. Le groupe de travail inclut un système de fichiers FSx for Lustre monté `/fsx` pour le stockage partagé, `VpcConfig` et est spécifié au niveau du cluster selon les besoins de FSx.
**Astuce**
Si vous testez sans FSx, vous pouvez omettre ou supprimer `FsxLustreConfig` `VpcConfig` de `InstanceStorageConfigs` la demande. FSx n'est pas requis pour la création de clusters, mais il est recommandé pour les charges de travail ML de production.
1. Créez le cluster :
```
aws sagemaker create-cluster \
--cli-input-json {{file://create_cluster.json}}
```
1. Vérifiez le statut :
```
aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}}
```
Dans le cas de la AMI-based configuration uniquement, les groupes d'instances de la réponse n'incluent aucun `LifeCycleConfig` bloc. Voici un exemple tronqué illustrant le groupe d'instances du contrôleur :
```
{
"ClusterName": "my-hyperpod-cluster",
"ClusterStatus": "InService",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"SlurmConfig": { "NodeType": "Controller" }
}
]
}
```
Une fois que le statut est passé à**InService**, passez à[Connectez-vous à votre cluster](#smcluster-getting-started-slurm-cli-connect).
### Option B : étendre AMI-based la configuration avec OnInitComplete
Utilisez cette option lorsque vous avez besoin de personnalisations en plus de la AMI-based configuration, telles que des agents de surveillance, une LDAP/SSSD intégration ou des supports de stockage supplémentaires. SageMaker HyperPod exécute d'abord la AMI-based configuration, puis exécute votre script d'extension.
1. Rédigez votre script d'extension. Par exemple `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."
```
**Utilisation de scripts d'extension issus du référentiel Awsome Distributed Training**
Le [dossier Extensions](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions) du référentiel Awsome Distributed Training fournit des scripts d'extension prêts à l'emploi pour les tâches courantes telles que l'ajout d'utilisateurs et l'activation de l'observabilité. Chaque fonctionnalité est autonome dans son propre répertoire avec son propre script de point d'entrée qui peut être fourni directement en tant que `OnInitComplete` script.
Pour les clusters nécessitant plusieurs fonctionnalités, nous vous recommandons d'utiliser le `run_extensions.sh` script disponible au niveau supérieur du dossier Extensions. Ce script orchestre tous les scripts d'extension disponibles et fournit de simples bascules booléens pour activer ou désactiver chaque fonctionnalité. Pour l'utiliser, téléchargez l'intégralité du dossier Extensions dans votre compartiment Amazon S3 et spécifiez `run_extensions.sh` comme `OnInitComplete` script :
```
s3:////
|-- run_extensions.sh (OnInitComplete target)
|-- detect-node/ (node type detection utility)
|-- add-users/ (user management scripts + config)
|-- observability/ (observability scripts + config)
```
À l'intérieur`run_extensions.sh`, activez ou désactivez chaque fonctionnalité en définissant le drapeau correspondant :
```
ENABLE_ADD_USERS="true"
ENABLE_OBSERVABILITY="true"
```
Le fichier de configuration de chaque fonctionnalité activée doit être renseigné avant le téléchargement vers Amazon S3. Reportez-vous au fichier README dans le répertoire de chaque fonctionnalité pour les détails de configuration.
1. Chargement vers Amazon S3 (le chemin du compartiment doit commencer par`s3://sagemaker-`) :
```
aws s3 cp extend-defaults.sh \
s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/
```
1. Enregistrez ce qui suit sous le nom `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"
}
}
}
```
**Important**
Quand `OnInitComplete` est spécifié, `SourceS3Uri` c'est obligatoire. `OnCreate`et `OnInitComplete` ne peuvent pas être utilisés ensemble sur le même groupe d'instances.
**Astuce**
Vous pouvez combiner les options au sein d'un cluster. Par exemple, utilisez AMI-based la configuration uniquement sur le contrôleur et `OnInitComplete` sur les travailleurs.
La topologie Slurm est la même que dans l'option A. Chaque groupe d'instances `SlurmConfig` définit son rôle de nœud et son attribution de partition, et `SlurmConfigStrategy: "Managed"` est défini au niveau du cluster. La seule différence est l'ajout de `LifeCycleConfig` with`OnInitComplete`, qui indique HyperPod d'exécuter votre script d'extension une fois AMI-based la configuration terminée sur chaque nœud. Pour ajouter FSx, incluez `FsxLustreConfig` ou `FsxOpenZfsConfig` intégrez `InstanceStorageConfigs` les groupes d'instances appropriés et ajoutez-les `VpcConfig` au niveau du cluster, comme décrit dans. [Configuration de FSx et de VPC](#smcluster-getting-started-slurm-cli-fsx-vpc)
1. Créez le cluster :
```
aws sagemaker create-cluster \
--cli-input-json {{file://create_cluster.json}}
```
1. Vérifiez le statut :
```
aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}}
```
Avec`OnInitComplete`, la réponse apparaît `OnInitComplete` dans le`LifeCycleConfig`. Voici un exemple tronqué illustrant le groupe d'instances du contrôleur :
```
{
"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"
}
}
]
}
```
Une fois que le statut est passé à**InService**, passez à[Connectez-vous à votre cluster](#smcluster-getting-started-slurm-cli-connect).
### Option C : contrôle personnalisé complet avec OnCreate (avancé)
Utilisez cette option lorsque vous avez besoin d'un contrôle total sur le provisionnement, notamment en installant des logiciels, en apportant des modifications à l'infrastructure et en décidant quand démarrer Slurm. Avec`OnCreate`, SageMaker HyperPod n'exécute **pas** AMI-based la configuration et ne démarre **pas** Slurm automatiquement.
**Note**
Si vous débutez dans ce domaine SageMaker HyperPod et que vous n'avez pas d'exigences de personnalisation spécifiques, nous vous recommandons de commencer par l'option A ou l'option B. Vous pourrez toujours passer au mode personnalisé ultérieurement.
1. Préparez et téléchargez des scripts de cycle de vie sur Amazon S3. Si vous partez de zéro, utilisez les exemples de scripts du [ GitHub référentiel Awsome Distributed Training](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
```
Chargement vers Amazon S3 (le chemin du compartiment doit commencer par`s3://sagemaker-`) :
```
aws s3 sync . \
s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src
```
Pour en savoir plus sur les scripts de cycle de vie, consultez [Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
1. Enregistrez ce qui suit sous le nom `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"
}
}
}
```
La topologie Slurm suit le même `SlurmConfig` schéma que les autres options. La principale différence réside `LifeCycleConfig` dans`OnCreate`. Cela indique HyperPod d'ignorer complètement AMI-based la configuration et d'exécuter votre `on_create.sh` script à la place. Vos scripts sont responsables de la séquence d'approvisionnement complète, y compris l'installation du logiciel, la configuration de Slurm et le démarrage des démons Slurm. Pour ajouter FSx, incluez `FsxLustreConfig` ou `FsxOpenZfsConfig` intégrez `InstanceStorageConfigs` les groupes d'instances appropriés et ajoutez-les `VpcConfig` au niveau du cluster, comme décrit dans. [Configuration de FSx et de VPC](#smcluster-getting-started-slurm-cli-fsx-vpc)
1. Créez le cluster :
```
aws sagemaker create-cluster \
--cli-input-json {{file://create_cluster.json}}
```
1. Vérifiez le statut :
```
aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}}
```
Avec`OnCreate`, la réponse apparaît `OnCreate` dans le`LifeCycleConfig`. Voici un exemple tronqué illustrant le groupe d'instances du contrôleur :
```
{
"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"
}
}
]
}
```
Une fois que le statut est passé à**InService**, passez à[Connectez-vous à votre cluster](#smcluster-getting-started-slurm-cli-connect).
### Erreurs de validation courantes
| Erreur | Résolution |
| --- | --- |
| « Le cluster doit en avoir exactement un InstanceGroup avec le type de nœud Controller » | Assurez-vous qu'un seul groupe d'instances possède les éléments SlurmConfig.NodeType suivants : "Controller" |
| « Les partitions ne peuvent être attribuées qu'aux types de nœuds de calcul » | Supprimer PartitionNames des groupes d'Logininstances Controller ou des groupes d'instances |
| « Les configurations FSx ne sont prises en charge que pour les VPC personnalisés » | Ajoutez VpcConfig à votre demande lorsque vous utilisez FSx |
| « LifeCycleConfig est requis pour le groupe d'instances... » | Clusters EKS ou Slurm Continuous. NodeProvisioningMode La configuration facultative du cycle de vie des nœuds n'est pas prise en charge. |
| « OnCreate et OnInitComplete elles s' LifeCycleConfig excluent mutuellement... » | Supprimez l'un OnCreate ou l'autreOnInitComplete. Vous ne pouvez pas spécifier les deux. |
| « par LifeCycleConfig exemple, le groupe est incomplet... » | Lorsque OnCreate ou OnInitComplete est spécifié, SourceS3Uri il doit également être fourni. |
| « LifeCycleConfig est facultatif mais nécessite une AMI compatible... » | Exécutez UpdateClusterSoftware pour effectuer la mise à jour vers une AMI qui prend en charge la configuration facultative du cycle de vie des nœuds. |
| « par LifeCycleConfig exemple, le groupe d'instances est fourni mais ne contient aucune configuration... » | Spécifiez SourceS3Uri avec OnCreate ouOnInitComplete, ou omettez LifeCycleConfig complètement. |
## Connectez-vous à votre cluster
Une fois que l'état du cluster est **InService** passé à (généralement 10 à 15 minutes), connectez-vous et vérifiez.
1. Répertoriez les nœuds du cluster pour obtenir les ID d'instance :
```
aws sagemaker list-cluster-nodes --cluster-name {{my-hyperpod-cluster}}
```
1. Connectez-vous à l'aide AWS Systems Manager du gestionnaire de session :
```
aws ssm start-session \
--target sagemaker-cluster:{{my-hyperpod-cluster}}_{{my-login-group}}-{{i-0abc123def456789b}} \
--region {{us-west-2}}
```
1. Vérifiez que Slurm est correctement configuré :
```
# Check Slurm nodes
sinfo
# Check Slurm partitions
sinfo -p partition-1
# Submit a test job
srun -p partition-1 --nodes=1 hostname
```
Pour plus d'informations sur l'exécution de charges de travail ML, consultez[Offres d'emploi sur SageMaker HyperPod des clusters](sagemaker-hyperpod-run-jobs-slurm.md).
## Suppression du cluster et nettoyage des ressources
Après le test, supprimez le cluster pour éviter des frais continus :
```
aws sagemaker delete-cluster --cluster-name {{my-hyperpod-cluster}}
```
Si vous avez utilisé des scripts de cycle de vie des nœuds (option B ou option C), nettoyez le compartiment Amazon S3 :
```
aws s3 rm s3://sagemaker-{{amzn-s3-demo-bucket}}/{{lifecycle/src}} --recursive
```
Si vous avez utilisé uniquement AMI-based la configuration (option A), aucun nettoyage Amazon S3 n'est nécessaire pour les scripts de cycle de vie des nœuds.
Si vous avez exécuté des charges de travail de formation, vérifiez également la présence de données ou d'artefacts dans Amazon S3, Amazon FSx for Lustre ou Amazon Elastic File System et supprimez-les pour éviter les frais.
## Rubriques en relation
+ [SageMaker HyperPod Configuration du Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration)
+ [Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [Configuration de FSx via InstanceStorageConfigs](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config)
+ [SageMaker HyperPod Opérations du cluster Slurm](sagemaker-hyperpod-operate-slurm.md)
+ [Scripts d'extension pour SageMaker HyperPod](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions)
+ [Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)