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.
# Orchestration de SageMaker HyperPod clusters avec Slurm
Le support de Slurm vous SageMaker HyperPod aide à mettre en place des clusters résilients pour exécuter des charges de travail d'apprentissage automatique (ML) et développer des state-of-the-art modèles tels que de grands modèles linguistiques (LLMs), des modèles de diffusion et des modèles de base (). FMs Il accélère le développement FMs en supprimant les tâches indifférenciées liées à la création et à la maintenance de clusters de calcul à grande échelle alimentés par des milliers d'accélérateurs tels que AWS Trainium et les unités de traitement graphique NVIDIA A100 et H100 (). GPUs Lorsque les accélérateurs tombent en panne, les fonctionnalités de résilience des instances de SageMaker HyperPod monitoring du cluster détectent et remplacent automatiquement le matériel défectueux à la volée afin que vous puissiez vous concentrer sur l'exécution des charges de travail ML. En outre, grâce à la prise en charge de la configuration du cycle de vie SageMaker HyperPod, vous pouvez personnaliser votre environnement informatique en fonction de vos besoins et le configurer avec les bibliothèques de formation distribuées d'Amazon SageMaker AI pour obtenir des performances optimales sur AWS.
**Exploitation des clusters**
Vous pouvez créer, configurer et gérer des SageMaker HyperPod clusters graphiquement via l'interface utilisateur (UI) de la console et par programmation via l'interface de ligne de AWS commande (CLI) ou. AWS SDK pour Python (Boto3) Avec Amazon VPC, vous pouvez sécuriser le réseau du cluster et tirer parti de la configuration de votre cluster avec les ressources de votre VPC, comme Amazon FSx for Lustre, qui offre le débit le plus rapide. Vous pouvez également attribuer différents rôles IAM aux groupes d’instances du cluster et limiter les actions que les ressources et les utilisateurs de votre cluster peuvent effectuer. Pour en savoir plus, consultez [SageMaker HyperPod Opérations du cluster Slurm](sagemaker-hyperpod-operate-slurm.md).
**Configuration de votre environnement ML**
SageMaker HyperPod runs[SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami), qui met en place un environnement ML sur les HyperPod clusters. Vous pouvez configurer des personnalisations supplémentaires pour la DLAMI en fournissant des scripts de cycle de vie adaptés à votre cas d’utilisation. Pour en savoir plus sur la configuration des scripts de cycle de vie, consultez [Commencer avec SageMaker HyperPod](smcluster-getting-started-slurm.md) et [Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
**Planification de tâches**
Une fois que vous avez créé un HyperPod cluster avec succès, les utilisateurs du cluster peuvent se connecter aux nœuds du cluster (tels que le nœud principal ou contrôleur, le nœud de connexion et le nœud de travail) et planifier des tâches pour exécuter des charges de travail d'apprentissage automatique. Pour en savoir plus, veuillez consulter la section [Offres d'emploi sur SageMaker HyperPod des clusters](sagemaker-hyperpod-run-jobs-slurm.md).
**Résilience face aux défaillances matérielles**
SageMaker HyperPod exécute des contrôles de santé sur les nœuds du cluster et fournit une fonctionnalité de reprise automatique de la charge de travail. Grâce aux fonctionnalités de résilience des clusters de HyperPod, vous pouvez reprendre votre charge de travail à partir du dernier point de contrôle enregistré, une fois que les nœuds défectueux ont été remplacés par des nœuds sains dans les clusters de plus de 16 nœuds. Pour en savoir plus, veuillez consulter la section [SageMaker HyperPod résilience du cluster](sagemaker-hyperpod-resiliency-slurm.md).
**Journalisation et gestion des clusters**
Vous pouvez trouver SageMaker HyperPod des indicateurs d'utilisation des ressources et des journaux de cycle de vie sur Amazon CloudWatch, et gérer les SageMaker HyperPod ressources en les balisant. Chaque exécution de l’API `CreateCluster` crée un flux de journaux distinct, nommé selon le format `-`. Dans le flux de journaux, vous pouvez vérifier les noms d’hôtes, le nom des scripts de cycle de vie ayant échoué et les résultats des scripts ayant échoué, tels que `stdout` et `stderr`. Pour de plus amples informations, veuillez consulter [SageMaker HyperPod gestion des clusters](sagemaker-hyperpod-cluster-management-slurm.md).
**Compatible avec les outils d' SageMaker IA**
Vous pouvez ainsi configurer des clusters avec des bibliothèques de communications collectives AWS optimisées proposées par l' SageMaker IA, telles que la bibliothèque de [parallélisme distribué des données (SMDDP) de l'SageMaker IA](data-parallel.md). SageMaker HyperPod La bibliothèque SMDDP implémente le `AllGather` fonctionnement optimisé pour l'infrastructure AWS informatique et réseau pour les instances d'apprentissage automatique basées sur l' SageMaker IA les plus performantes alimentées par NVIDIA A100. GPUs Pour en savoir plus, veuillez consulter la section [Exécution de charges de travail de formation distribuées avec Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md).
**Placement d'instance avec UltraServers**
SageMaker L'IA alloue automatiquement les tâches aux instances qui vous appartiennent sur la base d'une stratégie UltraServer basée sur le meilleur effort qui consiste à utiliser toutes les instances d'une instance UltraServer avant d'en utiliser une autre. Par exemple, si vous demandez 14 instances et que vous en avez 2 UltraServers dans votre plan de formation, SageMaker AI utilise toutes les instances de la première UltraServer. Si vous avez demandé 20 instances et que vous UltraServers en avez 2 dans votre plan de formation, SageMaker AI utilisera les 17 instances dans la première, UltraServer puis en utilisera 3 dans la seconde UltraServer.
**Topics**
+ [Commencer avec SageMaker HyperPod](smcluster-getting-started-slurm.md)
+ [SageMaker HyperPod Opérations du cluster Slurm](sagemaker-hyperpod-operate-slurm.md)
+ [Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [SageMaker HyperPod support de nœuds à plusieurs têtes](sagemaker-hyperpod-multihead-slurm.md)
+ [Offres d'emploi sur SageMaker HyperPod des clusters](sagemaker-hyperpod-run-jobs-slurm.md)
+ [SageMaker HyperPod surveillance des ressources du cluster](sagemaker-hyperpod-cluster-observability-slurm.md)
+ [SageMaker HyperPod résilience du cluster](sagemaker-hyperpod-resiliency-slurm.md)
+ [Provisionnement continu pour des opérations de cluster améliorées avec Slurm](sagemaker-hyperpod-scaling-slurm.md)
+ [SageMaker HyperPod gestion des clusters](sagemaker-hyperpod-cluster-management-slurm.md)
+ [SageMaker HyperPod FAQs](sagemaker-hyperpod-faq-slurm.md)
# Commencer avec SageMaker HyperPod
Commencez par créer votre premier SageMaker HyperPod cluster et découvrez les fonctionnalités de fonctionnement du cluster de SageMaker HyperPod. Vous pouvez créer un SageMaker HyperPod cluster via l'interface utilisateur de la console SageMaker AI ou les AWS CLI commandes. Ce didacticiel explique comment créer un nouveau SageMaker HyperPod cluster avec Slurm, un logiciel de planification de charge de travail populaire. Après avoir suivi ce didacticiel, vous saurez comment vous connecter aux nœuds du cluster à l'aide des AWS Systems Manager commandes (`aws ssm`). Une fois ce didacticiel terminé, consultez également la section [SageMaker HyperPod Opérations du cluster Slurm](sagemaker-hyperpod-operate-slurm.md) pour en savoir plus sur les parations de SageMaker HyperPod base et [Offres d'emploi sur SageMaker HyperPod des clusters](sagemaker-hyperpod-run-jobs-slurm.md) pour savoir comment planifier des tâches sur le cluster provisionné.
**Astuce**
Pour trouver des exemples pratiques et des solutions, consultez également l'[SageMaker HyperPodatelier](https://catalog.workshops.aws/sagemaker-hyperpod).
**Topics**
+ [Commencer à SageMaker HyperPod utiliser la console SageMaker AI](smcluster-getting-started-slurm-console.md)
+ [Création de SageMaker HyperPod clusters à l'aide CloudFormation de modèles](smcluster-getting-started-slurm-console-create-cluster-cfn.md)
+ [Commencer à SageMaker HyperPod utiliser le AWS CLI](smcluster-getting-started-slurm-cli.md)
# Commencer à SageMaker HyperPod utiliser la console SageMaker AI
Le didacticiel suivant explique comment créer un nouveau SageMaker HyperPod cluster et le configurer avec Slurm via l'interface utilisateur de la console SageMaker AI. À la suite du didacticiel, vous allez créer un HyperPod cluster avec trois nœuds Slurm, `my-controller-group``my-login-group`, et. `worker-group-1`
**Topics**
+ [Créer un cluster](#smcluster-getting-started-slurm-console-create-cluster-page)
+ [déployer des ressources ;](#smcluster-getting-started-slurm-console-create-cluster-deploy)
+ [Suppression du cluster et nettoyage des ressources](#smcluster-getting-started-slurm-console-delete-cluster-and-clean)
## Créer un cluster
Pour accéder à la page **SageMaker HyperPod Clusters** et choisir **Slurm** Orchestration, procédez comme suit.
1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Choisissez **HyperPod Clusters** dans le volet de navigation de gauche, puis **Gestion des clusters**.
1. Sur la page **SageMaker HyperPod Clusters**, choisissez **Create HyperPod cluster**.
1. Dans le menu déroulant **Créer un HyperPod cluster**, choisissez **Orchestrated by Slurm**.
1. Sur la page de création du cluster Slurm, vous verrez deux options. Choisissez celle qui correspond le mieux à vos besoins.
1. **Configuration rapide** : pour commencer immédiatement avec les paramètres par défaut, choisissez **Configuration rapide**. Grâce à cette option, l' SageMaker IA créera de nouvelles ressources telles que le VPC, les sous-réseaux, les groupes de sécurité, le compartiment Amazon S3, le rôle IAM et FSx pour Lustre lors de la création de votre cluster.
1. **Configuration personnalisée** : pour intégrer des ressources AWS existantes ou pour respecter des exigences spécifiques de mise en réseau, de sécurité ou de stockage, choisissez **Configuration personnalisée**. Avec cette option, vous pouvez choisir d’utiliser les ressources existantes ou d’en créer de nouvelles, et vous pouvez personnaliser la configuration qui répond le mieux à vos besoins.
## Configuration rapide
Dans la section **Configuration rapide**, suivez ces étapes pour créer votre HyperPod cluster avec l'orchestration Slurm.
### Paramètres généraux
Attribuez un nom au nouveau cluster. Vous ne pourrez pas modifier le nom après la création du cluster.
### Groupes d’instances
Pour ajouter un groupe d’instances, choisissez **Ajouter un groupe**. Chaque groupe d’instances peut être configuré différemment et vous pouvez créer un cluster hétérogène composé de plusieurs groupes d’instances avec divers types d’instances. Pour déployer un cluster, vous devez ajouter au moins un groupe d’instances pour les types de groupe Contrôleur et Calcul.
**Important**
Vous pouvez ajouter un seul groupe d’instances à la fois. Pour créer plusieurs groupes d’instances, répétez le processus pour chaque groupe d’instances.
Procédez comme suit pour ajouter un groupe d’instances.
1. Pour **Type de groupe d’instances**, choisissez un type pour votre groupe d’instances. Pour ce didacticiel, choisissez **Contrôleur (principal)** pour `my-controller-group`, **Connexion** pour `my-login-group` et **Calcul (travail)** pour `worker-group-1`.
1. Pour **Nom**, spécifiez le nom du groupe d’instances. Pour ce didacticiel, créez trois groupes d’instances nommés `my-controller-group`, `my-login-group` et `worker-group-1`.
1. Pour **Capacité de l’instance**, choisissez une capacité à la demande ou un plan d’entraînement pour réserver vos ressources de calcul.
1. Pour **Type d’instance**, choisissez l’instance pour le groupe d’instances. Pour ce didacticiel, sélectionnez `ml.c5.xlarge` pour `my-controller-group`, `ml.m5.4xlarge` pour `my-login-group` et `ml.trn1.32xlarge` pour `worker-group-1`.
**Important**
Veillez à choisir un type d’instance doté de quotas suffisants et suffisamment d’adresses IP non attribuées pour votre compte. Pour consulter ou demander des quotas supplémentaires, consultez [SageMaker HyperPod quotas](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. Pour **Quantité d’instances**, spécifiez un entier ne dépassant pas le quota d’instances pour l’utilisation du cluster. Pour ce didacticiel, entrez **1** pour les trois groupes.
1. Pour **Zone de disponibilité cible**, choisissez la zone de disponibilité dans laquelle vos instances seront provisionnées. La zone de disponibilité doit correspondre à l’emplacement de votre capacité de calcul accélérée.
1. Pour **Autre volume de stockage par instance (Go) – facultatif**, spécifiez un entier compris entre 1 et 16 384 pour définir la taille d’un volume Elastic Block Store (EBS) supplémentaire en gigaoctets (Go). Le volume EBS est attaché à chaque instance du groupe d’instances. Le chemin de montage par défaut pour le volume EBS supplémentaire est `/opt/sagemaker`. Une fois le cluster créé avec succès, vous pouvez accéder par SSH aux instances du cluster (nœuds) et vérifier si le volume EBS est correctement monté en exécutant la commande `df -h`. L’attachement d’un volume EBS supplémentaire fournit un stockage stable, hors instance et persistant de manière indépendante, comme décrit dans la section [Volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) du *Guide de l’utilisateur Amazon Elastic Block Store*.
1. Choisissez **Ajouter un groupe d’instances**.
### Paramètres par défaut de configuration rapide
Cette section répertorie tous les paramètres par défaut pour la création de votre cluster, y compris toutes les nouvelles AWS ressources qui seront créées au cours du processus de création du cluster. Passez en revue les paramètres par défaut.
## Configuration personnalisée
Dans la section **Configuration personnalisée**, suivez ces étapes pour créer votre HyperPod cluster avec l'orchestration Slurm.
### Paramètres généraux
Attribuez un nom au nouveau cluster. Vous ne pourrez pas modifier le nom après la création du cluster.
Pour **Restauration d’instance**, choisissez **Automatique – *recommandé*** ou **Aucun**.
### Réseaux
Configurez vos paramètres réseau pour la création du cluster. Ces paramètres ne pourront pas être modifiés après la création du cluster.
1. Pour le **VPC**, choisissez votre propre VPC si vous en avez déjà un qui permet à l' SageMaker IA d'accéder à votre VPC. Pour créer un nouveau VPC, suivez les instructions de la section [Création d’un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*. Vous pouvez le laisser sur **Aucun** pour utiliser le VPC SageMaker AI par défaut.
1. Pour le **bloc d'adresse IPv4 CIDR VPC**, entrez l'adresse IP de départ de votre VPC.
1. Pour les **zones de disponibilité**, choisissez les zones de disponibilité (AZ) dans lesquelles HyperPod vous créerez des sous-réseaux pour votre cluster. Choisissez AZs celui qui correspond à l'emplacement de votre capacité de calcul accélérée.
1. Pour **Groupes de sécurité**, créez un groupe de sécurité ou choisissez jusqu’à cinq groupes de sécurité configurés avec des règles permettant la communication entre les ressources au sein du VPC.
### Groupes d’instances
Pour ajouter un groupe d’instances, choisissez **Ajouter un groupe**. Chaque groupe d’instances peut être configuré différemment et vous pouvez créer un cluster hétérogène composé de plusieurs groupes d’instances avec divers types d’instances. Pour déployer un cluster, vous devez ajouter au moins un groupe d’instances.
**Important**
Vous pouvez ajouter un seul groupe d’instances à la fois. Pour créer plusieurs groupes d’instances, répétez le processus pour chaque groupe d’instances.
Procédez comme suit pour ajouter un groupe d’instances.
1. Pour **Type de groupe d’instances**, choisissez un type pour votre groupe d’instances. Pour ce didacticiel, choisissez **Contrôleur (principal)** pour `my-controller-group`, **Connexion** pour `my-login-group` et **Calcul (travail)** pour `worker-group-1`.
1. Pour **Nom**, spécifiez le nom du groupe d’instances. Pour ce didacticiel, créez trois groupes d’instances nommés `my-controller-group`, `my-login-group` et `worker-group-1`.
1. Pour **Capacité de l’instance**, choisissez une capacité à la demande ou un plan d’entraînement pour réserver vos ressources de calcul.
1. Pour **Type d’instance**, choisissez l’instance pour le groupe d’instances. Pour ce didacticiel, sélectionnez `ml.c5.xlarge` pour `my-controller-group`, `ml.m5.4xlarge` pour `my-login-group` et `ml.trn1.32xlarge` pour `worker-group-1`.
**Important**
Veillez à choisir un type d’instance doté de quotas suffisants et suffisamment d’adresses IP non attribuées pour votre compte. Pour consulter ou demander des quotas supplémentaires, consultez [SageMaker HyperPod quotas](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. Pour **Quantité d’instances**, spécifiez un entier ne dépassant pas le quota d’instances pour l’utilisation du cluster. Pour ce didacticiel, entrez **1** pour les trois groupes.
1. Pour **Zone de disponibilité cible**, choisissez la zone de disponibilité dans laquelle vos instances seront provisionnées. La zone de disponibilité doit correspondre à l’emplacement de votre capacité de calcul accélérée.
1. Pour **Autre volume de stockage par instance (Go) – facultatif**, spécifiez un entier compris entre 1 et 16 384 pour définir la taille d’un volume Elastic Block Store (EBS) supplémentaire en gigaoctets (Go). Le volume EBS est attaché à chaque instance du groupe d’instances. Le chemin de montage par défaut pour le volume EBS supplémentaire est `/opt/sagemaker`. Une fois le cluster créé avec succès, vous pouvez accéder par SSH aux instances du cluster (nœuds) et vérifier si le volume EBS est correctement monté en exécutant la commande `df -h`. L’attachement d’un volume EBS supplémentaire fournit un stockage stable, hors instance et persistant de manière indépendante, comme décrit dans la section [Volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) du *Guide de l’utilisateur Amazon Elastic Block Store*.
1. Choisissez **Ajouter un groupe d’instances**.
### Scripts de cycle de vie
Vous pouvez choisir d’utiliser les scripts de cycle de vie par défaut ou les scripts de cycle de vie personnalisés, qui seront stockés dans votre compartiment Amazon S3. Vous pouvez consulter les scripts de cycle de vie par défaut dans le [ GitHub référentiel Awesome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts). 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. Pour **Scripts de cycle de vie**, choisissez d’utiliser des scripts de cycle de vie par défaut ou personnalisés.
1. Pour **Compartiment S3 pour les scripts de cycle de vie**, choisissez de créer un nouveau compartiment ou d’utiliser un compartiment existant pour stocker les scripts de cycle de vie.
### Permissions
Choisissez ou créez un rôle IAM qui permet d'exécuter et HyperPod d'accéder aux AWS ressources nécessaires en votre nom.
### Stockage
Configurez le système de fichiers FSx for Lustre à provisionner sur le HyperPod cluster.
1. Pour **Système de fichiers**, choisissez un système de fichiers existant FSx pour Lustre, pour créer un nouveau système de fichiers FSx pour Lustre, ou n'en FSx configurez aucun pour Lustre.
1. Pour **Débit par unité de stockage**, choisissez le débit qui sera disponible par Tio de stockage provisionné.
1. Pour **Capacité de stockage**, entrez une valeur de capacité en To.
1. Pour le **type de compression des données**, choisissez **LZ4**d'activer la compression des données.
1. Pour **Version Lustre**, consultez la valeur recommandée pour les nouveaux systèmes de fichiers.
### Balises - facultatif
Pour les **balises *(facultatif)***, ajoutez des paires clé/valeur au nouveau cluster et gérez le cluster en tant que AWS ressource. Pour en savoir plus, consultez [Balisage de vos ressources AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
## déployer des ressources ;
Après avoir terminé la configuration du cluster à l’aide de la **configuration rapide** ou de la **configuration personnalisée**, choisissez l’option suivante pour démarrer le provisionnement des ressources et la création du cluster.
+ **Soumettre** : SageMaker AI commencera à approvisionner les ressources de configuration par défaut et à créer le cluster.
+ **Télécharger les paramètres du CloudFormation modèle** : vous allez télécharger le fichier JSON des paramètres de configuration et exécuter la AWS CLI commande pour déployer la CloudFormation pile afin de provisionner les ressources de configuration et de créer le cluster. Vous pouvez modifier le fichier JSON de paramètres téléchargés si nécessaire. Si vous choisissez cette option, consultez des instructions supplémentaires dans [Création de SageMaker HyperPod clusters à l'aide CloudFormation de modèles](smcluster-getting-started-slurm-console-create-cluster-cfn.md).
## Suppression du cluster et nettoyage des ressources
Une fois que vous avez testé avec succès la création d'un SageMaker HyperPod cluster, celui-ci continue de fonctionner tel quel `InService` jusqu'à ce que vous le supprimiez. Nous vous recommandons de supprimer tous les clusters créés à l'aide d'instances d' SageMaker IA à la demande lorsqu'ils ne sont pas utilisés afin d'éviter de devoir payer des frais de service continus basés sur la tarification à la demande. Dans ce didacticiel, vous avez créé un cluster composé de deux groupes d’instances. L’un d’eux utilise une instance C5. Veillez donc à supprimer le cluster en suivant les instructions dans [Supprimer un SageMaker HyperPod cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-delete-cluster).
Toutefois, si vous avez créé un cluster avec une capacité de calcul réservée, le statut des clusters n’a aucune incidence sur la facturation des services.
Pour nettoyer les scripts de cycle de vie du compartiment S3 utilisé pour ce didacticiel, accédez au compartiment S3 que vous avez utilisé lors de la création du cluster et supprimez complètement les fichiers.
Si vous avez testé l'exécution de charges de travail sur le cluster, vérifiez si vous avez téléchargé des données ou si votre tâche a enregistré des artefacts dans différents compartiments S3 ou services de système de fichiers tels qu'Amazon FSx for Lustre et Amazon Elastic File System. Pour éviter d’encourir des frais, supprimez tous les artefacts et toutes les données du stockage ou du système de fichiers.
# Création de SageMaker HyperPod clusters à l'aide CloudFormation de modèles
Vous pouvez créer des SageMaker HyperPod clusters à l'aide CloudFormation des modèles pour HyperPod. Vous devez procéder AWS CLI à l'installation pour continuer.
**Topics**
+ [Configurez les ressources dans la console et déployez-les à l'aide de CloudFormation](#smcluster-getting-started-slurm-console-create-cluster-deploy-console)
+ [Configuration des ressources et déploiement à l'aide de CloudFormation](#smcluster-getting-started-slurm-console-create-cluster-deploy-cfn)
## Configurez les ressources dans la console et déployez-les à l'aide de CloudFormation
Vous pouvez configurer les ressources à l'aide des modèles AWS Management Console et les déployer à l'aide CloudFormation des modèles.
Procédez comme suit :
1. *Au lieu de choisir **Soumettre***, choisissez **Télécharger les paramètres du CloudFormation modèle** à la fin du didacticiel dans[Commencer à SageMaker HyperPod utiliser la console SageMaker AI](smcluster-getting-started-slurm-console.md). Le didacticiel contient des informations de configuration importantes dont vous aurez besoin pour créer votre cluster avec succès.
**Important**
Si vous choisissez **Soumettre**, vous ne pourrez pas déployer un cluster portant le même nom tant que vous ne l’aurez pas supprimé.
Après avoir sélectionné **Télécharger les paramètres du CloudFormation modèle**, la fenêtre **Utiliser le fichier de configuration pour créer le cluster à l'aide** de la AWS CLI fenêtre apparaît sur le côté droit de la page.
1. Dans la fenêtre **Utilisation du fichier de configuration pour créer le cluster à l’aide de l’ AWS CLI**, choisissez **Télécharger le fichier de paramètres de configuration**. Ce fichier sera téléchargé sur votre ordinateur. Vous pouvez modifier le fichier JSON de configuration en fonction de vos besoins ou le laisser tel quel, si aucune modification n’est requise.
1. Dans un terminal, accédez à l’emplacement du fichier de paramètres `file://params.json`.
1. Exécutez la AWS CLI commande [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) pour déployer la CloudFormation pile qui fournira les ressources configurées et créera le HyperPod cluster.
```
aws cloudformation create-stack
--stack-name my-stack
--template-url https://aws-sagemaker-hyperpod-cluster-setup.amazonaws.com/templates-slurm/main-stack-slurm-based-template.yaml
--parameters file://params.json
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
```
1. Pour consulter l'état du provisionnement des ressources, accédez à la [CloudFormation console.](https://console.aws.amazon.com/cloudformation)
Une fois la création du cluster terminée, affichez le nouveau cluster sous **Clusters** dans le volet principal de la SageMaker HyperPod console. Vous pouvez vérifier son statut dans la colonne **Statut**.
1. Une fois que le statut du cluster est passé à `InService`, vous pouvez commencer à vous connecter aux nœuds du cluster. Pour accéder aux nœuds du cluster et commencer à exécuter des charges de travail ML, consultez [Offres d'emploi sur SageMaker HyperPod des clusters](sagemaker-hyperpod-run-jobs-slurm.md).
## Configuration des ressources et déploiement à l'aide de CloudFormation
Vous pouvez configurer les ressources et les déployer à l'aide CloudFormation des modèles pour SageMaker HyperPod.
Procédez comme suit :
1. Téléchargez un CloudFormation modèle SageMaker HyperPod depuis le [sagemaker-hyperpod-cluster-setup](https://github.com/aws/sagemaker-hyperpod-cluster-setup) GitHub référentiel.
1. Exécutez la AWS CLI commande [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) pour déployer la CloudFormation pile qui fournira les ressources configurées et créera le HyperPod cluster.
```
aws cloudformation create-stack
--stack-name my-stack
--template-url URL_of_the_file_that_contains_the_template_body
--parameters file://params.json
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
```
1. Pour consulter le statut de provisionnement des ressources, accédez à la console CloudFormation .
Une fois la création du cluster terminée, affichez le nouveau cluster sous **Clusters** dans le volet principal de la SageMaker HyperPod console. Vous pouvez vérifier son statut dans la colonne **Statut**.
1. Une fois que le statut du cluster est passé à `InService`, vous pouvez commencer à vous connecter aux nœuds du cluster. Pour accéder aux nœuds du cluster et commencer à exécuter des charges de travail ML, consultez [Offres d'emploi sur SageMaker HyperPod des clusters](sagemaker-hyperpod-run-jobs-slurm.md).
# Commencer à SageMaker HyperPod utiliser le AWS CLI
Créez votre premier SageMaker HyperPod cluster à l'aide des AWS CLI commandes pour HyperPod.
## Créez votre premier SageMaker HyperPod cluster avec Slurm
Le didacticiel suivant explique comment créer un nouveau SageMaker HyperPod cluster et le configurer avec Slurm à l'aide des [AWS CLI commandes](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli) pour. SageMaker HyperPod À la suite du didacticiel, vous allez créer un HyperPod cluster avec trois nœuds Slurm : `my-controller-group``my-login-group`, et. `worker-group-1`
Avec l'approche de configuration pilotée par API, vous définissez les types de nœuds Slurm et les assignations de partitions directement dans la demande d'API à l' CreateCluster aide de. `SlurmConfig` Cela élimine le besoin d'un `provisioning_parameters.json` fichier distinct et fournit une validation, une détection de dérive et une per-instance-group FSx configuration intégrées.
1. Tout d’abord, préparez et chargez des scripts de cycle de vie dans un compartiment Amazon S3. Lors de la création du cluster, HyperPod exécutez-les dans chaque groupe d'instances. Chargez des scripts de cycle de vie sur Amazon S3 à l’aide de la commande suivante.
```
aws s3 sync \
~/local-dir-to-lifecycle-scripts/* \
s3://sagemaker-//src
```
**Note**
Le chemin du compartiment S3 doit commencer par un préfixe`sagemaker-`, car le [rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) with autorise `AmazonSageMakerClusterInstanceRolePolicy` uniquement l'accès aux compartiments Amazon S3 commençant par le préfixe spécifique.
Si vous partez de zéro, utilisez des exemples de scripts de cycle de vie fournis dans le [ GitHub référentiel Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/). Les sous-étapes suivantes montrent comment télécharger et charger les exemples de scripts de cycle de vie dans un compartiment Amazon S3.
1. Téléchargez une copie des exemples de scripts de cycle de vie dans un répertoire de votre ordinateur local.
```
git clone https://github.com/aws-samples/awsome-distributed-training/
```
1. Accédez au répertoire [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config), où vous trouverez un ensemble de scripts de cycle de vie.
```
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
```
Pour en savoir plus sur les exemples de 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. Chargez les scripts dans `s3://sagemaker-//src`. Vous pouvez le faire en utilisant la console Amazon S3 ou en exécutant la commande de l’ AWS CLI Amazon S3 suivante.
```
aws s3 sync \
~/local-dir-to-lifecycle-scripts/* \
s3://sagemaker-//src
```
**Note**
Avec la configuration pilotée par API, il n'est pas nécessaire de créer ou de télécharger un `provisioning_parameters.json` fichier. La configuration de Slurm est définie directement dans la demande CreateCluster d'API à l'étape suivante.
1. Préparez un fichier de [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)demande au format JSON et enregistrez-le sous`create_cluster.json`.
Avec la configuration pilotée par API, vous spécifiez le type de nœud Slurm et l'attribution de partition pour chaque groupe d'instances à l'aide du champ. `SlurmConfig` Vous configurez également les paramètres Slurm au niveau du cluster à l'aide de. `Orchestrator.Slurm`
Pour `ExecutionRole`, fournissez l’ARN du rôle IAM que vous avez créé avec la politique `AmazonSageMakerClusterInstanceRolePolicy` gérée dans [Conditions préalables à l'utilisation SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md).
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 500
}
}
]
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
}
}
```
**SlurmConfig champs** :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
**Champs Orchestrator.Slurm :**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
**SlurmConfigStrategy options :**
+ `Managed`(recommandé) : gère `slurm.conf` et détecte HyperPod entièrement les modifications non autorisées (détection de dérive). Les mises à jour échouent si une dérive est détectée.
+ `Overwrite`: HyperPod remplace `slurm.conf` lors des mises à jour, en ignorant les modifications manuelles.
+ `Merge`: HyperPod préserve les modifications manuelles et les fusionne avec la configuration de l'API.
**Ajout FSx pour Lustre (facultatif) :**
Pour monter un système de fichiers FSx for Lustre sur vos nœuds de calcul, ajoutez-le `FsxLustreConfig` au groupe d'instances `InstanceStorageConfigs` for the. Cela nécessite une configuration VPC personnalisée.
```
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "abcdefgh"
}
}
],
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
}
```
**Ajout FSx pour OpenZFS (facultatif) :**
Vous pouvez également effectuer un montage FSx pour les systèmes de fichiers OpenZFS :
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
"MountPath": "/shared"
}
}
]
```
**Note**
Chaque groupe d'instances peut en avoir au maximum un FSx pour la configuration Lustre et un FSx pour la configuration OpenZFS. Différents groupes d'instances peuvent monter différents systèmes de fichiers.
**Ajout d'une configuration VPC (obligatoire pour FSx) :**
Si vous l'utilisez FSx, vous devez spécifier une configuration VPC personnalisée :
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
},
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
},
"VpcConfig": {
"SecurityGroupIds": ["sg-0abc123def456789a"],
"Subnets": ["subnet-0abc123def456789a"]
}
}
```
1. Exécutez la commande suivante pour créer le cluster.
```
aws sagemaker create-cluster --cli-input-json file://complete/path/to/create_cluster.json
```
Elle devrait renvoyer l’ARN du cluster créé.
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster"
}
```
Si vous recevez un message d’erreur dû à des limites de ressources, assurez-vous de remplacer le type d’instance par un type avec des quotas suffisants sur votre compte, ou demandez des quotas supplémentaires en suivant la section [SageMaker HyperPod quotas](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
**Erreurs de validation courantes :**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
1. Exécutez `describe-cluster` pour vérifier le statut du cluster.
```
aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster
```
Exemple de réponse :
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster",
"ClusterName": "my-hyperpod-cluster",
"ClusterStatus": "Creating",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
},
"CreationTime": "2024-01-15T10:30:00Z"
}
```
Une fois que le statut du cluster passe à **InService**, passez à l’étape suivante. La création d'un cluster prend généralement 10 à 15 minutes.
1. Exécutez `list-cluster-nodes` pour vérifier les détails des nœuds du cluster.
```
aws sagemaker list-cluster-nodes --cluster-name my-hyperpod-cluster
```
Exemple de réponse :
```
{
"ClusterNodeSummaries": [
{
"InstanceGroupName": "my-controller-group",
"InstanceId": "i-0abc123def456789a",
"InstanceType": "ml.c5.xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:35:00Z"
},
{
"InstanceGroupName": "my-login-group",
"InstanceId": "i-0abc123def456789b",
"InstanceType": "ml.m5.4xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:35:00Z"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceId": "i-0abc123def456789c",
"InstanceType": "ml.trn1.32xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:36:00Z"
}
]
}
```
`InstanceId`C'est ce dont les utilisateurs de votre cluster ont besoin pour s'y connecter (`aws ssm`). Pour plus d’informations sur la connexion aux nœuds du cluster et l’exécution de charges de travail ML, consultez [Offres d'emploi sur SageMaker HyperPod des clusters](sagemaker-hyperpod-run-jobs-slurm.md).
1. Connectez-vous à votre cluster à l'aide du gestionnaire de AWS Systems Manager session.
```
aws ssm start-session \
--target sagemaker-cluster:my-hyperpod-cluster_my-login-group-i-0abc123def456789b \
--region us-west-2
```
Une fois connecté, 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
```
## Suppression du cluster et nettoyage des ressources
Une fois que vous avez testé avec succès la création d'un SageMaker HyperPod cluster, celui-ci continue de fonctionner tel quel `InService` jusqu'à ce que vous le supprimiez. Nous vous recommandons de supprimer tous les clusters créés à l'aide de capacités d' SageMaker IA à la demande lorsqu'ils ne sont pas utilisés afin d'éviter de devoir payer des frais de service continus basés sur la tarification à la demande. Dans ce didacticiel, vous avez créé un cluster composé de trois groupes d'instances. Assurez-vous de supprimer le cluster en exécutant la commande suivante.
```
aws sagemaker delete-cluster --cluster-name my-hyperpod-cluster
```
Pour nettoyer les scripts de cycle de vie du compartiment Amazon S3 utilisé pour ce didacticiel, accédez au compartiment Amazon S3 que vous avez utilisé lors de la création du cluster et supprimez complètement les fichiers.
```
aws s3 rm s3://sagemaker-//src --recursive
```
Si vous avez testé l'exécution de charges de travail de formation de modèles sur le cluster, vérifiez également si vous avez téléchargé des données ou si votre tâche a enregistré des artefacts dans différents buckets Amazon S3 ou services de système de fichiers tels qu'Amazon FSx for Lustre et Amazon Elastic File System. Pour éviter d’encourir des frais, supprimez tous les artefacts et toutes les données du stockage ou du système de fichiers.
## 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)
+ [FSx configuration via InstanceStorageConfigs](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config)
+ [SageMaker HyperPod Opérations du cluster Slurm](sagemaker-hyperpod-operate-slurm.md)
# SageMaker HyperPod Opérations du cluster Slurm
Cette section fournit des conseils sur la gestion SageMaker HyperPod via l'interface utilisateur ou la AWS Command Line Interface (CLI) de la console SageMaker AI. Vous apprendrez à effectuer diverses tâches connexes SageMaker HyperPod, que vous préfériez une interface visuelle ou que vous utilisiez des commandes.
**Topics**
+ [Gestion des clusters SageMaker HyperPod Slurm à l'aide de la console SageMaker](sagemaker-hyperpod-operate-slurm-console-ui.md)
+ [Gestion des clusters SageMaker HyperPod Slurm à l'aide du AWS CLI](sagemaker-hyperpod-operate-slurm-cli-command.md)
# Gestion des clusters SageMaker HyperPod Slurm à l'aide de la console SageMaker
Les rubriques suivantes fournissent des conseils sur la manière de gérer SageMaker HyperPod via l'interface utilisateur de la console.
**Topics**
+ [Création d'un SageMaker HyperPod cluster](#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster)
+ [Parcourez vos SageMaker HyperPod clusters](#sagemaker-hyperpod-operate-slurm-console-ui-browse-clusters)
+ [Afficher les détails de chaque SageMaker HyperPod cluster](#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters)
+ [Modifier un SageMaker HyperPod cluster](#sagemaker-hyperpod-operate-slurm-console-ui-edit-clusters)
+ [Supprimer un SageMaker HyperPod cluster](#sagemaker-hyperpod-operate-slurm-console-ui-delete-cluster)
## Création d'un SageMaker HyperPod cluster
Consultez les instructions ci-dessous [Commencer à SageMaker HyperPod utiliser la console SageMaker AI](smcluster-getting-started-slurm-console.md) pour créer un nouveau SageMaker HyperPod cluster via l'interface utilisateur de la SageMaker HyperPod console.
## Parcourez vos SageMaker HyperPod clusters
Sous **Clusters** dans le volet principal de la SageMaker HyperPod console sur la page principale de la SageMaker HyperPod console, tous les clusters créés doivent apparaître dans la section **Clusters**, qui fournit une vue récapitulative des clusters, de leur ARNs statut et de leur date de création.
## Afficher les détails de chaque SageMaker HyperPod cluster
Sous **Clusters** sur la page principale de la console, les **noms** des clusters sont activés sous forme de liens. Cliquez sur le lien du nom du cluster pour voir les détails de chaque cluster.
## Modifier un SageMaker HyperPod cluster
1. Sous **Clusters** dans le volet principal de la SageMaker HyperPod console, choisissez le cluster que vous souhaitez mettre à jour.
1. Sélectionnez votre cluster, puis choisissez **Modifier**.
1. Sur la page **Modifier **, vous pouvez modifier les configurations des groupes d’instances existants, ajouter d’autres groupes d’instances, supprimer des groupes d’instances et modifier les balises du cluster. Après avoir apporté des modifications, choisissez **Soumettre**.
1. Dans la section **Configurer les groupes d’instances**, vous pouvez ajouter d’autres groupes d’instances en choisissant **Créer un groupe d’instances**.
1. Dans la section **Configurer les groupes d’instances**, vous pouvez choisir **Modifier** pour modifier sa configuration ou **Supprimer** pour supprimer définitivement le groupe d’instances.
**Important**
Lorsque vous supprimez un groupe d’instance, tenez compte des points suivants :
Votre SageMaker HyperPod cluster doit toujours gérer au moins un groupe d'instances.
Assurez-vous que toutes les données critiques sont sauvegardées avant leur suppression.
Le processus de suppression ne peut pas être annulé.
**Note**
La suppression d’un groupe d’instances résilie toutes les ressources de calcul associées à ce groupe.
1. Dans la section **Balises**, vous pouvez mettre à jour les balises du cluster.
## Supprimer un SageMaker HyperPod cluster
1. Sous **Clusters** dans le volet principal de la SageMaker HyperPod console, choisissez le cluster que vous souhaitez supprimer.
1. Sélectionnez votre cluster, puis choisissez **Supprimer**.
1. Dans la fenêtre contextuelle de suppression du cluster, examinez attentivement les informations du cluster pour confirmer que vous avez choisi le bon cluster à supprimer.
1. Après avoir examiné les informations du cluster, choisissez **Oui, supprimer le cluster**.
1. Dans le champ textuel pour confirmer la suppression, saisissez **delete**.
1. Choisissez **Supprimer** dans le coin inférieur droit de la fenêtre contextuelle pour terminer l’envoi de la demande de suppression du cluster.
# Gestion des clusters SageMaker HyperPod Slurm à l'aide du AWS CLI
Les rubriques suivantes fournissent des conseils sur l'écriture de fichiers de requêtes d' SageMaker HyperPod API au format JSON et leur exécution à l'aide des AWS CLI commandes.
**Topics**
+ [Création d’un nouveau cluster](#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster)
+ [Description d’un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster)
+ [Liste des détails des nœuds du cluster](#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes)
+ [Description des détails d’un nœud de cluster](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster-node)
+ [Liste des clusters](#sagemaker-hyperpod-operate-slurm-cli-command-list-clusters)
+ [Mise à jour de la configuration du cluster](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster)
+ [Mettre à jour le logiciel de SageMaker HyperPod plate-forme d'un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software)
+ [Réduction verticale d’un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-scale-down)
+ [Supprimer un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-delete-cluster)
## Création d’un nouveau cluster
1. Préparez des scripts de configuration de cycle de vie et chargez-les sur un compartiment S3, tel que `s3://sagemaker-amzn-s3-demo-bucket/lifecycle-script-directory/src/`. L’étape 2 suivante suppose qu’il existe un script de point d’entrée nommé `on_create.sh` dans le compartiment S3 spécifié.
**Important**
Vérifiez que vous avez défini le chemin S3 pour qu’il commence par `s3://sagemaker-`. Le [Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) dispose de la politique [https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-cluster.html](https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-cluster.html) gérée attachée, qui permet d’accéder aux compartiments S3 avec le préfixe `sagemaker-` spécifique.
1. Préparez un fichier de demande d'[CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)API au format JSON. Vous devez configurer les groupes d’instances pour qu’ils correspondent au cluster Slurm que vous concevez dans le fichier `provisioning_parameters.json`, qui sera utilisé lors de la création du cluster dans le cadre de l’exécution d’un ensemble de scripts de cycle de vie. Pour en savoir plus, consultez [Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm.md). Le modèle suivant comporte deux groupes d’instances répondant aux exigences minimales d’un cluster Slurm : un nœud de contrôleur (principal) et un nœud de calcul (composant master). Pour `ExecutionRole`, fournissez l’ARN du rôle IAM que vous avez créé avec la politique `AmazonSageMakerClusterInstanceRolePolicy` gérée à partir de la section [Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod).
```
// create_cluster.json
{
"ClusterName": "your-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
// Optional: Configure an additional storage per instance group.
"InstanceStorageConfigs": [
{
// Attach an additional EBS volume to each instance within the instance group.
// The default mount path for the additional EBS volume is /opt/sagemaker.
"EbsVolumeConfig":{
// Specify an integer between 1 and 16384 in gigabytes (GB).
"VolumeSizeInGB": integer,
}
}
]
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.p4d.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster"
}
],
// Optional
"Tags": [
{
"Key": "string",
"Value": "string"
}
],
// Optional
"VpcConfig": {
"SecurityGroupIds": [ "string" ],
"Subnets": [ "string" ]
}
}
```
Selon la façon dont vous concevez la structure du cluster par le biais de vos scripts de cycle de vie, vous pouvez configurer jusqu’à 20 groupes d’instances sous le paramètre `InstanceGroups`.
Pour le paramètre de `Tags` requête, vous pouvez ajouter des balises personnalisées pour gérer le SageMaker HyperPod cluster en tant que AWS ressource. Vous pouvez ajouter des balises à votre cluster de la même manière que vous les ajoutez dans d'autres AWS services qui prennent en charge le balisage. Pour en savoir plus sur le balisage AWS des ressources en général, consultez le Guide de l'[utilisateur AWS des ressources de balisage](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
Pour le paramètre de demande `VpcConfig`, spécifiez les informations d’un VPC que vous souhaitez utiliser. Pour de plus amples informations, veuillez consulter [Configuration SageMaker HyperPod avec un Amazon VPC personnalisé](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc).
1. Exécutez la commande [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) comme suit.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
L’ARN du nouveau cluster devrait être renvoyé.
## Description d’un cluster
Exécutez [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster.html) pour vérifier le statut du cluster. Vous pouvez spécifier le nom ou l’ARN du cluster.
```
aws sagemaker describe-cluster --cluster-name your-hyperpod-cluster
```
Une fois que le statut du cluster passe à **InService**, passez à l’étape suivante. À l'aide de cette API, vous pouvez également récupérer les messages d'échec liés à l'exécution d'autres opérations d' HyperPod API.
## Liste des détails des nœuds du cluster
Exécutez [list-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html)pour vérifier les informations clés des nœuds du cluster.
```
aws sagemaker list-cluster-nodes --cluster-name your-hyperpod-cluster
```
Cela renvoie une réponse et `InstanceId` correspond à ce dont vous avez besoin pour vous y connecter (en utilisant `aws ssm`).
## Description des détails d’un nœud de cluster
Exécutez [describe-cluster-node](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster-node.html)pour récupérer les détails d'un nœud de cluster. Vous pouvez obtenir l'ID du nœud du cluster à partir de la list-cluster-nodes sortie. Vous pouvez spécifier le nom ou l’ARN du cluster.
```
aws sagemaker describe-cluster-node \
--cluster-name your-hyperpod-cluster \
--node-id i-111222333444555aa
```
## Liste des clusters
Exécutez [list-clusters](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-clusters.html) pour répertorier tous les clusters figurant dans votre compte.
```
aws sagemaker list-clusters
```
Vous pouvez également ajouter des indicateurs supplémentaires pour filtrer la liste des clusters. Pour en savoir plus sur le fonctionnement de cette commande à bas niveau et sur les indicateurs supplémentaires pour le filtrage, consultez la référence de l'[ListClusters](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusters.html)API.
## Mise à jour de la configuration du cluster
Exécutez [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) pour mettre à jour la configuration d’un cluster.
**Note**
Vous pouvez utiliser l'`UpdateCluster`API pour réduire ou supprimer des groupes d'instances entiers de votre SageMaker HyperPod cluster. Pour obtenir des instructions supplémentaires sur la manière de réduire verticalement ou de supprimer les groupes d’instances, consultez [Réduction verticale d’un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-scale-down).
1. Créez un fichier de demande `UpdateCluster` au format JSON. Assurez-vous de spécifier le nom du cluster et le nom du groupe d’instances appropriés à mettre à jour. Vous pouvez modifier le type d’instance, le nombre d’instances, le script de point d’entrée de configuration de cycle de vie et le chemin vers ce script.
1. Pour `ClusterName`, spécifiez le nom du cluster que vous voulez mettre à jour.
1. Pour `InstanceGroupName`
1. Pour mettre à jour un groupe d’instances existant, spécifiez le nom du groupe d’instances que vous souhaitez mettre à jour.
1. Pour ajouter un nouveau groupe d’instances, spécifiez un nouveau nom qui n’existe pas dans votre cluster.
1. Pour `InstanceType`
1. Pour mettre à jour un groupe d’instances existant, vous devez mettre en correspondance le type d’instance que vous avez initialement spécifié avec ce groupe.
1. Pour ajouter un nouveau groupe d’instances, spécifiez un type d’instance avec lequel vous souhaitez configurer le groupe.
1. Pour `InstanceCount`
1. Pour mettre à jour un groupe d’instances existant, spécifiez un entier correspondant au nombre d’instances que vous souhaitez. Vous pouvez fournir une valeur supérieure ou inférieure (jusqu’à 0) pour augmenter ou réduire verticalement le groupe d’instances.
1. Pour ajouter un nouveau groupe d’instances, spécifiez un entier supérieur ou égal à 1.
1. Pour `LifeCycleConfig`, vous pouvez modifier à la fois les valeurs `SourceS3Uri` et `OnCreate` comme vous le souhaitez pour mettre à jour le groupe d’instances.
1. Pour `ExecutionRole`
1. Pour mettre à jour un groupe d’instances existant, continuez à utiliser le même rôle IAM que celui que vous avez attaché lors de la création du cluster.
1. Pour ajouter un nouveau groupe d’instances, spécifiez un rôle IAM que vous souhaitez attacher.
1. Pour `ThreadsPerCore`
1. Pour mettre à jour un groupe d’instances existant, continuez à utiliser la même valeur que vous avez spécifiée lors de la création du cluster.
1. Pour ajouter un nouveau groupe d’instances, vous pouvez choisir n’importe quelle valeur parmi les options autorisées par type d’instance. Pour plus d’informations, recherchez le type d’instance et consultez la colonne **Threads valides par cœur** dans le tableau de référence dans [Cœurs de CPU et threads par cœur de CPU par type d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html) dans le *Guide de l’utilisateur Amazon EC2*.
L’extrait de code suivant est un modèle de fichier de demande JSON que vous pouvez utiliser. Pour plus d'informations sur la syntaxe des demandes et les paramètres de cette API, consultez la référence de l'[UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API.
```
// update_cluster.json
{
// Required
"ClusterName": "name-of-cluster-to-update",
// Required
"InstanceGroups": [
{
"InstanceGroupName": "name-of-instance-group-to-update",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
// Optional: Configure an additional storage per instance group.
"InstanceStorageConfigs": [
{
// Attach an additional EBS volume to each instance within the instance group.
// The default mount path for the additional EBS volume is /opt/sagemaker.
"EbsVolumeConfig":{
// Specify an integer between 1 and 16384 in gigabytes (GB).
"VolumeSizeInGB": integer,
}
}
]
},
// add more blocks of instance groups as needed
{ ... }
]
}
```
1. Exécutez la commande `update-cluster` suivante pour soumettre la demande.
```
aws sagemaker update-cluster \
--cli-input-json file://complete/path/to/update_cluster.json
```
## Mettre à jour le logiciel de SageMaker HyperPod plate-forme d'un cluster
Exécutez [update-cluster-software](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster-software.html)pour mettre à jour les clusters existants avec les logiciels et les correctifs de sécurité fournis par le SageMaker HyperPod service. Pour `--cluster-name`, spécifiez le nom ou l’ARN du cluster à mettre à jour.
**Important**
Notez que vous devez sauvegarder votre travail avant d’exécuter cette API. Le processus d’application de correctifs remplace le volume racine par l’AMI mise à jour, ce qui signifie que les données précédemment stockées dans le volume racine de l’instance seront perdues. Assurez-vous de sauvegarder vos données depuis le volume racine de l'instance vers Amazon S3 ou Amazon FSx for Lustre. Pour de plus amples informations, veuillez consulter [Utilisez le script de sauvegarde fourni par SageMaker HyperPod](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software-backup).
```
aws sagemaker update-cluster-software --cluster-name your-hyperpod-cluster
```
Cette commande appelle l'[UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API. Après l'appel d'API, SageMaker HyperPod vérifie si un DLAMI plus récent est disponible pour les instances du cluster. Si une mise à jour du DLAMI est requise SageMaker HyperPod , les instances de cluster seront mises à jour pour utiliser les [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) dernières versions et exécuteront vos scripts de cycle de vie dans le compartiment Amazon S3 que vous avez spécifié lors de la création ou de la mise à jour du cluster. Si le cluster utilise déjà le DLAMI le plus récent SageMaker HyperPod , il n'apportera aucune modification au cluster et ne réexécutera pas les scripts de cycle de vie. L'équipe SageMaker HyperPod de service déploie régulièrement de nouvelles [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) solutions pour renforcer la sécurité et améliorer l'expérience utilisateur. Nous vous recommandons de toujours mettre à jour le DLAMI le plus récent SageMaker HyperPod . Pour les futures SageMaker HyperPod mises à jour du DLAMI relatives aux correctifs de sécurité, contactez. [Notes de SageMaker HyperPod publication d'Amazon](sagemaker-hyperpod-release-notes.md)
**Astuce**
Si l’application du correctif de sécurité échoue, vous pouvez extraire les messages d’échec en exécutant l’API [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html) comme indiqué dans [Description d’un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster).
**Note**
Vous pouvez exécuter cette API uniquement par programmation. La fonctionnalité d'application de correctifs n'est pas implémentée dans l'interface utilisateur de la SageMaker HyperPod console.
### Utilisez le script de sauvegarde fourni par SageMaker HyperPod
SageMaker HyperPod fournit un script pour sauvegarder et restaurer vos données [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/patching-backup.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/patching-backup.sh)dans le * GitHub référentiel Awsome Distributed Training*. Le script fournit les deux fonctions suivantes.
**Pour sauvegarder les données dans un compartiment S3 avant d’appliquer des correctifs**
```
sudo bash patching-backup.sh --create
```
Après avoir exécuté la commande, le script vérifie `squeue` s’il existe des tâches en file d’attente, arrête Slurm s’il n’y a aucune tâche dans la file d’attente, sauvegarde `mariadb` et copie les éléments locaux sur le disque défini sous `LOCAL_ITEMS`. Vous pouvez ajouter d’autres fichiers et répertoires dans `LOCAL_ITEMS`.
```
# Define files and directories to back up.
LOCAL_ITEMS=(
"/var/spool/slurmd"
"/var/spool/slurmctld"
"/etc/systemd/system/slurmctld.service"
"/home/ubuntu/backup_slurm_acct_db.sql"
# ... Add more items as needed
)
```
Vous pouvez également ajouter du code personnalisé au script fourni pour sauvegarder toutes les applications adaptées à votre cas d’utilisation.
**Pour restaurer des données à partir d’un compartiment S3 après avoir appliqué des correctifs**
```
sudo bash patching-backup.sh --restore
```
## Réduction verticale d’un cluster
Vous pouvez réduire le nombre d'instances ou supprimer des groupes d'instances dans votre SageMaker HyperPod cluster afin d'optimiser l'allocation des ressources ou de réduire les coûts.
Pour réduire verticalement, vous pouvez utiliser l’opération d’API `UpdateCluster` pour résilier de manière aléatoire des instances de votre groupe d’instances jusqu’à un nombre spécifié, ou résilier des instances spécifiques à l’aide de l’opération d’API `BatchDeleteClusterNodes`. Vous pouvez également supprimer complètement des groupes d’instances entiers à l’aide de l’API `UpdateCluster`. Pour plus d’informations sur la réduction verticale à l’aide de ces méthodes, consultez [Réduction de la taille d'un SageMaker HyperPod cluster](smcluster-scale-down.md).
**Note**
Vous ne pouvez pas supprimer des instances configurées en tant que nœuds de contrôleur Slurm. Toute tentative de suppression d’un nœud de contrôleur Slurm entraîne une erreur de validation avec le code d’erreur `NODE_ID_IN_USE`.
## Supprimer un cluster
Exécutez [delete-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-cluster.html) pour supprimer un cluster. Vous pouvez spécifier le nom ou l’ARN du cluster.
```
aws sagemaker delete-cluster --cluster-name your-hyperpod-cluster
```
# Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie
SageMaker HyperPod propose toujours des clusters de up-and-running calcul, qui sont hautement personnalisables car vous pouvez écrire des scripts de cycle de vie pour indiquer SageMaker HyperPod comment configurer les ressources du cluster. Les rubriques suivantes présentent les meilleures pratiques pour préparer des scripts de cycle de vie afin de configurer des SageMaker HyperPod clusters avec des outils de gestion de charge de travail open source.
Les rubriques suivantes présentent en détail les meilleures pratiques pour préparer des scripts de cycle de vie sur lesquels configurer les configurations Slurm. SageMaker HyperPod
## Présentation générale
La procédure suivante est le flux principal du provisionnement d'un HyperPod cluster et de sa configuration avec Slurm. Les étapes sont classées selon une approche ***ascendante***.
1. Planifiez la manière dont vous souhaitez créer des nœuds Slurm sur un HyperPod cluster. Par exemple, si vous souhaitez configurer deux nœuds Slurm, vous devez configurer deux groupes d'instances dans un HyperPod cluster.
1. Préparez la configuration de Slurm. Choisissez l'une des approches suivantes :
+ **Option A : Configuration pilotée par API (recommandée)** — Définissez les types de nœuds et les partitions Slurm directement dans la charge utile de l'`CreateCluster`API au sein de chaque groupe d'`SlurmConfig`instances. Avec cette approche :
+ Aucun `provisioning_parameters.json` fichier n'est nécessaire
+ La topologie Slurm est définie dans la charge utile de l'API avec les définitions des groupes d'instances
+ FSx les systèmes de fichiers sont configurés via per-instance-group `InstanceStorageConfigs`
+ La stratégie de configuration est contrôlée via `Orchestrator.Slurm.SlurmConfigStrategy`
Exemple `SlurmConfig` dans un groupe d'instances :
```
{
"InstanceGroupName": "gpu-compute",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 8,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["gpu-training"]
}
}
```
+ **Option B : Configuration héritée** — Préparez un `provisioning_parameters.json` fichier, qui est un[Formulaire de configuration pour provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). `provisioning_parameters.json`doit contenir les informations de configuration du nœud Slurm à provisionner sur le cluster. HyperPod Cela doit refléter la conception des nœuds Slurm à partir de l’étape 1.
1. Préparez un ensemble de scripts de cycle de vie pour configurer Slurm HyperPod afin d'installer des packages logiciels et de configurer un environnement dans le cluster adapté à votre cas d'utilisation. Vous devez structurer les scripts de cycle de vie de manière à ce qu’ils s’exécutent collectivement dans un script Python central (`lifecycle_script.py`), et écrire un script shell de point d’entrée (`on_create.sh`) pour exécuter le script Python. Le script shell entrypoint est ce que vous devez fournir à une demande de création de HyperPod cluster ultérieurement à l'étape 5.
Notez également que vous devez écrire les scripts dans lesquels vous vous attendez à ce `resource_config.json` qu'ils soient générés HyperPod lors de la création du cluster. `resource_config.json`contient des informations sur les ressources du HyperPod cluster telles que les adresses IP, les types d'instances et ARNs, et c'est ce que vous devez utiliser pour configurer Slurm.
1. Rassemblez tous les fichiers des étapes précédentes dans un dossier. La structure des dossiers dépend de l'approche de configuration que vous avez sélectionnée à l'étape 2.
Si vous avez sélectionné l'option A (configuration pilotée par API) :
Votre dossier a uniquement besoin de scripts de cycle de vie pour les tâches de configuration personnalisées. La configuration et le FSx montage du Slurm sont gérés automatiquement en HyperPod fonction de la charge utile de l'API.
```
└── lifecycle_files // your local folder
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scripts to be fed into lifecycle_script.py
```
**Note**
Le `provisioning_parameters.json` fichier n'est pas obligatoire lors de l'utilisation d'une configuration pilotée par API.
Si vous avez sélectionné l'option B (ancienne configuration) :
Votre dossier doit inclure `provisioning_parameters.json` l'ensemble complet des scripts de cycle de vie.
```
└── lifecycle_files // your local folder
├── provisioning_parameters.json
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scrips to be fed into lifecycle_script.py
```
1. Chargez tous les fichiers dans un compartiment S3. Copiez et conservez le chemin de ce compartiment S3. Notez que vous devez créer un chemin de compartiment S3 commençant par `sagemaker-`, car vous devez choisir un [Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) attaché avec [`AmazonSageMakerClusterInstanceRolePolicy`](security-iam-awsmanpol-AmazonSageMakerClusterInstanceRolePolicy.md), qui autorise uniquement les chemins de compartiment S3 commençant par le préfixe `sagemaker-`. La commande suivante est un exemple de commande pour charger tous les fichiers dans un compartiment S3.
```
aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src
```
1. Préparez une demande HyperPod de création de cluster.
+ Option 1 : Si vous utilisez le AWS CLI, rédigez une demande de création de cluster au format JSON (`create_cluster.json`) en suivant les instructions sur[Création d’un nouveau cluster](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster).
+ Option 2 : Si vous utilisez l'interface utilisateur de la console SageMaker AI, remplissez le formulaire de demande de **création d'un cluster** dans l'interface utilisateur de la HyperPod console en suivant les instructions sur[Création d'un SageMaker HyperPod cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster).
À ce stade, assurez-vous de créer des groupes d’instances dans la même structure que celle que vous avez planifiée aux étapes 1 et 2. Assurez-vous également de spécifier le compartiment S3 à l’étape 5 dans les formulaires de demande.
1. Soumettez la demande de création de cluster. HyperPod approvisionne un cluster en fonction de la demande, puis crée un `resource_config.json` fichier dans les instances du HyperPod cluster et configure Slurm sur le cluster exécutant les scripts de cycle de vie.
Les rubriques suivantes vous expliquent en détail comment organiser les fichiers de configuration et les scripts de cycle de vie pour qu'ils fonctionnent correctement lors de la création de HyperPod clusters.
**Topics**
+ [Présentation générale](#sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-highlevel-overview)
+ [Scripts de cycle de vie de base fournis par HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)
+ [Quelles configurations particulières sont HyperPod gérées dans les fichiers de configuration de Slurm](sagemaker-hyperpod-lifecycle-best-practices-slurm-what-hyperpod-overrides-in-slurm-conf.md)
+ [Rotations des journaux de boue](sagemaker-hyperpod-slurm-log-rotation.md)
+ [Montage d'Amazon FSx for Lustre et d'Amazon FSx pour OpenZFS sur un cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-setup-with-fsx.md)
+ [Validation des fichiers de configuration JSON avant de créer un cluster Slurm sur HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md)
+ [Validation du temps d'exécution avant d'exécuter des charges de production sur un HyperPod cluster Slurm](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-runtime.md)
+ [Développement interactif de scripts de cycle de vie sur un nœud de HyperPod cluster](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-develop-lifecycle-scripts.md)
# Scripts de cycle de vie de base fournis par HyperPod
Cette section vous présente tous les composants du processus de base de la configuration de Slurm selon HyperPod une approche ***descendante***. Il commence par la préparation d'une demande de création de HyperPod cluster pour exécuter l'`CreateCluster`API, puis explore en profondeur la structure hiérarchique jusqu'aux scripts de cycle de vie. Utilisez les exemples de scripts de cycle de vie fournis dans le [ GitHub référentiel Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/). Clonez le référentiel en exécutant la commande suivante.
```
git clone https://github.com/aws-samples/awsome-distributed-training/
```
Les scripts de cycle de vie de base pour la configuration d'un cluster Slurm SageMaker HyperPod sont disponibles sur. [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)
```
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
```
L’organigramme suivant présente un aperçu détaillé de la manière dont vous devez concevoir les scripts de cycle de vie de base. Les descriptions situées sous le schéma et le guide de procédure expliquent leur fonctionnement lors de l'appel HyperPod `CreateCluster` d'API.
![\[Un organigramme détaillé de la création de HyperPod clusters et de la structure des scripts de cycle de vie.\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/images/hyperpod-lifecycle-structure.png)
***Figure :** organigramme détaillé de la création de HyperPod clusters et de la structure des scripts de cycle de vie. (1) Les flèches en pointillés sont dirigées vers l’emplacement où les cases sont « appelées » et indiquent le flux des fichiers de configuration et la préparation des scripts de cycle de vie. Cela commence par la préparation de `provisioning_parameters.json` et des scripts de cycle de vie. Ils sont ensuite codés dans `lifecycle_script.py` pour une exécution collective dans l’ordre. Et l'exécution du `lifecycle_script.py` script est effectuée par le script `on_create.sh` shell, qui doit être exécuté dans le terminal de l' HyperPodinstance. (2) Les flèches continues indiquent le flux principal de création du HyperPod cluster et la manière dont les cases sont « appelées » ou « soumises à ». `on_create.sh`est obligatoire pour la demande de création de cluster, `create_cluster.json` soit dans le formulaire de demande **de cluster**, soit dans l'interface utilisateur de la console. Après avoir soumis la demande, HyperPod exécute l'`CreateCluster`API en fonction des informations de configuration fournies par la demande et des scripts de cycle de vie. (3) La flèche en pointillés indique que la HyperPod plateforme crée des instances `resource_config.json` dans le cluster lors du provisionnement des ressources du cluster. `resource_config.json`contient des informations sur les ressources du HyperPod cluster, telles que l'ARN du cluster, les types d'instances et les adresses IP. Il est important de noter que vous devez préparer les scripts de cycle de vie pour attendre le fichier `resource_config.json` lors de la création du cluster. Pour plus d’informations, consultez le guide de procédure ci-dessous.*
Le guide de procédure suivant explique ce qui se passe lors de la création d'un HyperPod cluster et explique comment les scripts de cycle de vie de base sont conçus.
1. `create_cluster.json`— Pour soumettre une demande de création de HyperPod cluster, vous devez préparer un fichier de `CreateCluster` demande au format JSON. Dans cet exemple de bonnes pratiques, nous supposons que le fichier de demande est nommé `create_cluster.json`. Écrivez `create_cluster.json` pour approvisionner un HyperPod cluster avec des groupes d'instances. La meilleure pratique consiste à ajouter le même nombre de groupes d'instances que le nombre de nœuds Slurm que vous prévoyez de configurer sur le HyperPod cluster. Assurez-vous de donner des noms distinctifs aux groupes d’instances que vous attribuerez aux nœuds Slurm que vous prévoyez de configurer.
Vous devez également spécifier un chemin de compartiment S3 pour stocker l’ensemble de vos fichiers de configuration et de scripts de cycle de vie dans le champ nommé `InstanceGroups.LifeCycleConfig.SourceS3Uri` dans le formulaire de demande `CreateCluster`, et spécifier le nom de fichier d’un script shell de point d’entrée (supposons qu’il est nommé `on_create.sh`) sur `InstanceGroups.LifeCycleConfig.OnCreate`.
**Note**
Si vous utilisez le formulaire de **soumission de cluster** dans l'interface utilisateur de la HyperPod console, celle-ci gère le remplissage et l'envoi de la `CreateCluster` demande en votre nom, et exécute l'`CreateCluster`API dans le backend. Dans ce cas, vous n’avez pas besoin de créer `create_cluster.json` ; assurez-vous plutôt de spécifier les informations de configuration de cluster correctes dans le formulaire de soumission **Créer un cluster**.
1. `on_create.sh`— Pour chaque groupe d'instances, vous devez fournir un script shell point d'entrée, pour exécuter des commandes`on_create.sh`, exécuter des scripts pour installer des packages logiciels et configurer l'environnement du HyperPod cluster avec Slurm. Les deux éléments que vous devez préparer sont un élément `provisioning_parameters.json` requis HyperPod pour configurer Slurm et un ensemble de scripts de cycle de vie pour l'installation de progiciels. Ce script doit être écrit pour rechercher et exécuter les fichiers suivants, comme indiqué dans l’exemple de script dans [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh).
**Note**
Assurez-vous de charger l’ensemble complet des scripts de cycle de vie dans l’emplacement S3 que vous spécifiez dans `create_cluster.json`. Vous devez également placer votre `provisioning_parameters.json` au même emplacement.
1. `provisioning_parameters.json` : il s’agit d’un [Formulaire de configuration pour provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). Le script `on_create.sh` trouve ce fichier JSON et définit une variable d’environnement pour identifier le chemin d’accès à celui-ci. Grâce à ce fichier JSON, vous pouvez configurer les nœuds Slurm et les options de stockage telles qu'Amazon FSx pour que Lustre for Slurm communique avec. Dans`provisioning_parameters.json`, assurez-vous d'attribuer les groupes d'instances de HyperPod cluster en utilisant les noms que vous avez spécifiés `create_cluster.json` aux nœuds Slurm de manière appropriée en fonction de la façon dont vous prévoyez de les configurer.
Le schéma suivant montre un exemple de la façon dont les deux fichiers `create_cluster.json` de configuration JSON `provisioning_parameters.json` doivent être écrits pour attribuer des groupes d' HyperPod instances aux nœuds Slurm. Dans cet exemple, nous supposons la configuration de trois nœuds Slurm : le nœud de contrôleur (gestion), le nœud de connexion (facultatif) et le nœud de calcul (composant master).
**Astuce**
Pour vous aider à valider ces deux fichiers JSON, l'équipe du HyperPod service fournit un script de validation, [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py). Pour en savoir plus, veuillez consulter la section [Validation des fichiers de configuration JSON avant de créer un cluster Slurm sur HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md).
![\[Comparaison directe entre les fichiers .json.\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/images/hyperpod-lifecycle-slurm-config.png)
***Figure :** Comparaison directe entre la création `create_cluster.json` de HyperPod clusters et la configuration `provisiong_params.json` de Slurm. Le nombre de groupes d’instances dans `create_cluster.json` doit correspondre au nombre de nœuds que vous souhaitez configurer en tant que nœuds Slurm. Dans le cas de l'exemple de la figure, trois nœuds Slurm seront configurés sur un HyperPod cluster de trois groupes d'instances. Vous devez attribuer les groupes d'instances du HyperPod cluster aux nœuds Slurm en spécifiant les noms des groupes d'instances en conséquence.*
1. `resource_config.json`— Lors de la création du cluster, le `lifecycle_script.py` script est écrit pour s'attendre à ce qu'un `resource_config.json` fichier soit fourni HyperPod. Ce fichier contient des informations sur le cluster, telles que les types d’instances et les adresses IP.
Lorsque vous exécutez l'`CreateCluster`API, HyperPod crée un fichier de configuration des ressources sur la `/opt/ml/config/resource_config.json` base du `create_cluster.json` fichier. Le chemin du fichier est enregistré dans la variable d’environnement nommée `SAGEMAKER_RESOURCE_CONFIG_PATH`.
**Important**
Le `resource_config.json` fichier est généré automatiquement par la HyperPod plateforme, et vous n'avez PAS besoin de le créer. Le code suivant a pour but de montrer un exemple de `resource_config.json` ce qui serait créé à partir de la création du cluster basée sur `create_cluster.json` dans l’étape précédente, et pour vous aider à comprendre ce qui se passe dans le système dorsal et à quoi ressemblerait un fichier `resource_config.json` généré automatiquement.
```
{
"ClusterConfig": {
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz",
"ClusterName": "your-hyperpod-cluster"
},
"InstanceGroups": [
{
"Name": "controller-machine",
"InstanceType": "ml.c5.xlarge",
"Instances": [
{
"InstanceName": "controller-machine-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
},
{
"Name": "login-group",
"InstanceType": "ml.m5.xlarge",
"Instances": [
{
"InstanceName": "login-group-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
},
{
"Name": "compute-nodes",
"InstanceType": "ml.trn1.32xlarge",
"Instances": [
{
"InstanceName": "compute-nodes-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-2",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-3",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-4",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
}
]
}
```
1. `lifecycle_script.py`— Il s'agit du script Python principal qui exécute collectivement les scripts de cycle de vie configurant Slurm sur le HyperPod cluster pendant le provisionnement. Ce script lit `provisioning_parameters.json` et `resource_config.json` à partir des chemins spécifiés ou identifiés dans `on_create.sh`, transmet les informations pertinentes à chaque script de cycle de vie, puis exécute les scripts de cycle de vie dans l’ordre.
Les scripts de cycle de vie sont un ensemble de scripts que vous pouvez personnaliser en toute flexibilité pour installer des packages logiciels et configurer les configurations nécessaires ou personnalisées lors de la création du cluster, telles que la configuration de Slurm, la création d’utilisateurs, l’installation de Conda ou de Docker. L'exemple de [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py)script est préparé pour exécuter d'autres scripts de cycle de vie de base dans le référentiel, tels que le lancement de Slurm deamons () [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh), le montage d'Amazon FSx pour Lustre ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh)) et la configuration de la comptabilité MariaDB () et de la comptabilité RDS (). [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh) Vous pouvez également ajouter d'autres scripts, les regrouper dans le même répertoire et ajouter des lignes de code pour `lifecycle_script.py` permettre l' HyperPod exécution des scripts. Pour plus d'informations sur les scripts de cycle de vie de base, voir également [3.1 Scripts de cycle](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#31-lifecycle-scripts) de vie dans le * GitHub référentiel Awsome Distributed Training*.
**Note**
HyperPod s'exécute [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) sur chaque instance d'un cluster, et l'AMI dispose de progiciels préinstallés conformes aux compatibilités entre eux et HyperPod aux fonctionnalités. Notez que si vous réinstallez l'un des packages préinstallés, vous êtes responsable de l'installation des packages compatibles et notez que certaines HyperPod fonctionnalités risquent de ne pas fonctionner comme prévu.
Outre les configurations par défaut, d’autres scripts permettant d’installer les logiciels suivants sont disponibles dans le dossier [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils). Le fichier `lifecycle_script.py` est déjà prêt à inclure des lignes de code pour exécuter les scripts d’installation. Par conséquent, consultez les éléments suivants pour rechercher ces lignes et les activer en supprimant les marques de commentaires.
1. Les lignes de code suivantes concernent l’installation de [Docker](https://www.docker.com/), d’[Enroot](https://github.com/NVIDIA/enroot) et de [Pyxis](https://github.com/NVIDIA/pyxis). Ces packages sont nécessaires pour exécuter des conteneurs Docker sur un cluster Slurm.
Pour activer cette étape d’installation, définissez le paramètre `enable_docker_enroot_pyxis` sur `True` dans le fichier [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py).
```
# Install Docker/Enroot/Pyxis
if Config.enable_docker_enroot_pyxis:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type)
```
1. Vous pouvez intégrer votre HyperPod cluster à [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) et à [Amazon Managed Grafana pour exporter les mesures relatives au cluster et](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) aux nœuds du cluster vers les tableaux de HyperPod bord Amazon Managed Grafana. Pour exporter les métriques et utiliser le [tableau de bord Slurm](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/), le [tableau de bord de l’Exportateur NVIDIA DCGM](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/) et le [tableau de bord des métriques EFA](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/) sur Amazon Managed Grafana, vous devez installer l’[Exportateur Slurm pour Prometheus](https://github.com/vpenso/prometheus-slurm-exporter), l’[Exportateur NVIDIA DCGM](https://github.com/NVIDIA/dcgm-exporter) et l’[Exportateur de nœuds EFA](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md). Pour plus d’informations sur l’installation des packages d’exportateur et l’utilisation des tableaux de bord Grafana dans un espace de travail Amazon Managed Grafana, consultez [SageMaker HyperPod surveillance des ressources du cluster](sagemaker-hyperpod-cluster-observability-slurm.md).
Pour activer cette étape d’installation, définissez le paramètre `enable_observability` sur `True` dans le fichier [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py).
```
# Install metric exporting software and Prometheus for observability
if Config.enable_observability:
if node_type == SlurmNodeType.COMPUTE_NODE:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()
if node_type == SlurmNodeType.HEAD_NODE:
wait_for_scontrol()
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
ExecuteBashScript("./utils/install_prometheus.sh").run()
```
1. Assurez-vous de charger tous les fichiers de configuration et les scripts de configuration de l’**étape 2** vers le compartiment S3 que vous fournissez dans la demande `CreateCluster` de l’**étape 1**. Par exemple, supposons que votre fichier `create_cluster.json` contienne ce qui suit.
```
"LifeCycleConfig": {
"SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src",
"OnCreate": "on_create.sh"
}
```
Votre `"s3://sagemaker-hyperpod-lifecycle/src"` doit alors contenir `on_create.sh`, `lifecycle_script.py`, `provisioning_parameters.json` et tous les autres scripts de configuration. Supposons que vous ayez préparé les fichiers dans un dossier local comme suit.
```
└── lifecycle_files // your local folder
├── provisioning_parameters.json
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scrips to be fed into lifecycle_script.py
```
Pour charger les fichiers, utilisez la commande S3 comme suit.
```
aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src
```
# Quelles configurations particulières sont HyperPod gérées dans les fichiers de configuration de Slurm
Lorsque vous créez un cluster Slurm sur HyperPod, l' HyperPod agent configure les [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)fichiers [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)et `/opt/slurm/etc/` pour gérer le cluster Slurm en fonction de votre demande de création de cluster et de vos scripts de HyperPod cycle de vie. La liste suivante indique les paramètres spécifiques que l' HyperPod agent gère et remplace.
**Important**
Nous vous recommandons vivement de **ne pas** modifier ces paramètres gérés par HyperPod.
+ Dans [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod définit les paramètres de base suivants : `ClusterName``SlurmctldHost`,`PartitionName`, et`NodeName`.
En outre, pour activer la [Restauration automatique des nœuds et reprise automatique](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) fonctionnalité, HyperPod les `SchedulerParameters` paramètres `TaskPlugin` et doivent être définis comme suit. L' HyperPod agent définit ces deux paramètres avec les valeurs requises par défaut.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ Dans [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod gère `NodeName` les nœuds GPU.
# Rotations des journaux de boue
SageMaker HyperPod fournit une rotation automatique des journaux des démons Slurm afin de gérer l'utilisation de l'espace disque et de maintenir les performances du système. La rotation des journaux est essentielle pour empêcher les journaux de consommer trop d'espace disque et garantir un fonctionnement optimal du système en archivant et en supprimant automatiquement les anciens fichiers journaux tout en conservant les informations de journalisation récentes. Les rotations des journaux Slurm sont activées par défaut lorsque vous créez un cluster.
## Comment fonctionne la rotation des bûches
Lorsque cette option est activée, la configuration de rotation des journaux :
+ Surveille tous les fichiers journaux Slurm dont l'extension `.log` se trouve dans le `/var/log/slurm/` dossier du contrôleur, des nœuds de connexion et de calcul.
+ Fait pivoter les journaux lorsqu'ils atteignent 50 Mo.
+ Conserve jusqu'à deux fichiers journaux pivotés avant de les supprimer.
+ Envoie SIGUSR2 un signal aux démons Slurm (`slurmctld`,`slurmd`, et`slurmdbd`) après la rotation.
## Liste des fichiers journaux soumis à une rotation
Les journaux de Slurm se trouvent dans le `/var/log/slurm/` répertoire. La rotation des journaux est activée pour tous les fichiers correspondants`/var/log/slurm/*.log`. En cas de rotation, les fichiers pivotés ont des suffixes numériques (tels que). `slurmd.log.1` La liste suivante n'est pas exhaustive mais présente certains des fichiers journaux critiques qui pivotent automatiquement :
+ `/var/log/slurm/slurmctld.log`
+ `/var/log/slurm/slurmd.log`
+ `/var/log/slurm/slurmdb.log`
+ `/var/log/slurm/slurmrestd.log`
## Activer ou désactiver la rotation des journaux
Vous pouvez contrôler la fonctionnalité de rotation des journaux à l'aide du `enable_slurm_log_rotation` paramètre figurant dans le `config.py` script des scripts de cycle de vie de votre cluster, comme illustré dans l'exemple suivant :
```
class Config:
# Set false if you want to disable log rotation of Slurm daemon logs
enable_slurm_log_rotation = True # Default value
```
Pour désactiver la rotation des journaux, définissez le paramètre sur`False`, comme indiqué dans l'exemple suivant :
```
enable_slurm_log_rotation = False
```
**Note**
Les scripts de cycle de vie s'exécutent sur tous les nœuds Slurm (nœuds de contrôleur, de connexion et de calcul) lors de la création du cluster. Ils s'exécutent également sur de nouveaux nœuds lorsqu'ils sont ajoutés au cluster. La mise à jour des configurations de rotation des journaux doit être effectuée manuellement après la création du cluster. La configuration de rotation du journal est stockée dans`/etc/logrotate.d/sagemaker-hyperpod-slurm`. Nous vous recommandons de laisser la rotation des journaux activée pour éviter que les fichiers journaux ne consomment trop d'espace disque. Pour désactiver la rotation du journal, supprimez le `sagemaker-hyperpod-slurm` fichier ou commentez son contenu en ajoutant `#` au début de chaque ligne du `sagemaker-hyperpod-slurm` fichier.
## Paramètres de rotation des journaux par défaut
Les paramètres suivants sont configurés automatiquement pour chaque fichier journal pivoté :
| Paramètre | Value | Description |
| --- | --- | --- |
| rotate | 2 | Nombre de fichiers journaux pivotés à conserver |
| size | 50 Mo | Taille maximale avant rotation |
| copytruncate | activé | Copie et tronque le fichier journal d'origine |
| compress | désactivées | Les journaux pivotés ne sont pas compressés |
| missingok | activé | Aucune erreur si le fichier journal est manquant |
| notifempty | activé | Ne fait pas pivoter les fichiers vides |
| noolddir | activé | Les fichiers pivotés restent dans le même répertoire |
# Montage d'Amazon FSx for Lustre et d'Amazon FSx pour OpenZFS sur un cluster HyperPod
Pour monter un système de fichiers partagé Amazon FSx for Lustre sur votre HyperPod cluster, configurez ce qui suit.
1. Utilisez votre réseau Amazon VPC.
1. Pour que les instances de HyperPod cluster communiquent au sein de votre VPC, assurez-vous de les associer [Configuration SageMaker HyperPod avec un Amazon VPC personnalisé](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc) au rôle IAM pour. SageMaker HyperPod
1. Dans `create_cluster.json`, incluez les informations de VPC suivantes.
```
"VpcConfig": {
"SecurityGroupIds": [ "string" ],
"Subnets": [ "string" ]
}
```
Pour plus de conseils sur la configuration d’Amazon VPC, consultez [Conditions préalables à l'utilisation SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md).
1. Pour terminer la configuration de Slurm avec Amazon FSx for Lustre, vous pouvez utiliser l'une des approches suivantes. Vous pouvez trouver les FSx informations Amazon depuis la console Amazon FSx for Lustre de votre compte ou en exécutant la AWS CLI commande suivante,`aws fsx describe-file-systems`.
**Option A : Configuration pilotée par API (recommandée)**
Spécifiez la FSx configuration Amazon directement dans la charge utile de l' CreateCluster API `InstanceStorageConfigs` au sein de chaque groupe d'instances. Cette approche prend en charge à FSx la fois Lustre et FSx OpenZFS, et permet per-instance-group FSx la configuration.
```
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "1abcdefg"
}
}
]
```
FSx Pour OpenZFS, utilisez `FsxOpenZfsConfig` plutôt :
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx-openzfs"
}
}
]
```
Pour plus de détails, consultez [Commencer à SageMaker HyperPod utiliser la AWS CLI](sagemaker-hyperpod-quickstart.md).
**Option B : ancienne configuration**
Spécifiez le nom FSx DNS Amazon et FSx le nom de montage Amazon `provisioning_parameters.json` comme indiqué dans la figure de la [Scripts de cycle de vie de base fournis par HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) section.
```
"fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"fsx_mountname": "1abcdefg"
```
# Validation des fichiers de configuration JSON avant de créer un cluster Slurm sur HyperPod
Pour valider les fichiers de configuration JSON avant de soumettre une demande de création de cluster, utilisez le script de validation de configuration [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py). Ce script analyse et compare le fichier JSON de configuration de HyperPod cluster et le fichier JSON de configuration Slurm, et identifie toute erreur de configuration des ressources entre les deux fichiers et également entre Amazon EC2, Amazon VPC et Amazon Resources. FSx Par exemple, pour valider les fichiers `create_cluster.json` et `provisioning_parameters.json` de la section [Scripts de cycle de vie de base fournis par HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md), exécutez le script de validation comme suit.
```
python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json
```
Vous trouverez ci-après un exemple de sortie d’une validation réussie.
```
✔️ Validated instance group name worker-group-1 is correct ...
✔️ Validated subnet subnet-012345abcdef67890 ...
✔️ Validated security group sg-012345abcdef67890 ingress rules ...
✔️ Validated security group sg-012345abcdef67890 egress rules ...
✔️ Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com
✔️ Validated FSx Lustre mount name abcdefgh
✅ Cluster Validation succeeded
```
# Validation du temps d'exécution avant d'exécuter des charges de production sur un HyperPod cluster Slurm
Pour vérifier le temps d'exécution avant d'exécuter des charges de travail de production sur un cluster Slurm HyperPod, utilisez le script de validation de l'exécution. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py) Ce script vérifie si tous les packages nécessaires à l'exécution de Docker sont installés sur le cluster, si le cluster possède un système de fichiers Lustre correctement monté FSx et un répertoire utilisateur partageant le système de fichiers, et si le démon Slurm est exécuté sur tous les nœuds de calcul.
Pour exécuter le script sur plusieurs nœuds à la fois, utilisez `srun` comme indiqué dans l’exemple de commande suivant pour exécuter le script sur un cluster Slurm de 8 nœuds.
```
# The following command runs on 8 nodes
srun -N 8 python3 hyperpod-precheck.py
```
**Note**
Pour en savoir plus sur le script de validation, notamment les fonctions de validation d'exécution qu'il fournit et les instructions pour résoudre les problèmes qui ne passent pas les validations, consultez la section [Validation de l'exécution avant d'exécuter des charges de travail](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#35-runtime-validation-before-running-workloads) dans le référentiel *Awsome Distributed Training*. GitHub
# Développement interactif de scripts de cycle de vie sur un nœud de HyperPod cluster
Cette section explique comment développer des scripts de cycle de vie de manière interactive sans créer et supprimer un HyperPod cluster à plusieurs reprises.
1. Créez un HyperPod cluster avec les scripts de cycle de vie de base.
1. Connectez-vous à un nœud de cluster.
1. Développez un script (`configure_xyz.sh`) en le modifiant et en l’exécutant à plusieurs reprises sur le nœud.
1. HyperPod exécute les scripts de cycle de vie en tant qu'utilisateur root. Nous vous recommandons donc de les exécuter en `configure_xyz.sh` tant qu'utilisateur root pendant le développement afin de vous assurer que le script est testé dans les mêmes conditions lorsqu'il est exécuté par HyperPod.
1. Intégrez le script dans `lifecycle_script.py` en ajoutant une ligne de code similaire à la suivante.
```
ExecuteBashScript("./utils/configure_xyz.sh").run()
```
1. Chargez les scripts de cycle de vie mis à jour dans le compartiment S3 que vous avez initialement utilisé pour charger les scripts de cycle de vie de base.
1. Testez la version intégrée de `lifecycle_script.py` en créant un nouveau HyperPod cluster. Vous pouvez également utiliser le remplacement manuel des instances pour tester les scripts de cycle de vie mis à jour en créant de nouvelles instances. Pour des instructions détaillées, voir [Remplacer manuellement un nœud](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.html#sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace). Notez que seuls les nœuds de travail sont remplaçables.
# SageMaker HyperPod support de nœuds à plusieurs têtes
Vous pouvez créer plusieurs nœuds de contrôleur (principaux) dans un seul cluster SageMaker HyperPod Slurm, l'un servant de nœud de contrôleur principal et les autres de nœuds de contrôleur de secours. Le nœud de contrôleur principal est chargé de contrôler les nœuds de calcul (composants master) et de gérer les opérations Slurm. Les nœuds de contrôleur de secours surveillent en permanence le nœud de contrôleur principal. Si le nœud de contrôleur principal tombe en panne ou ne répond plus, l’un des nœuds de contrôleur de secours prend automatiquement le relais en tant que nouveau nœud de contrôleur principal.
La configuration de plusieurs nœuds de contrôleur dans les clusters SageMaker HyperPod Slurm offre plusieurs avantages clés. Elle élimine le risque de défaillance d’un nœud de contrôleur individuel en fournissant des nœuds principaux de contrôleur, elle permet le basculement automatique vers les nœuds de contrôleur de secours et accélère la récupération et elle vous permet de gérer vos propres bases de données comptables et la configuration de Slurm de manière indépendante.
## Concepts clés
Ce qui suit fournit des détails sur les concepts liés à la prise en charge de SageMaker HyperPod plusieurs nœuds de contrôleur (tête) pour les clusters Slurm.
**Nœud de contrôleur**
Un nœud de contrôleur est une instance Amazon EC2 au sein d’un cluster qui exécute des services Slurm essentiels pour gérer et coordonner les opérations du cluster. Plus précisément, il héberge le [démon de contrôleur Slurm (slurmctld)](https://slurm.schedmd.com/slurmctld.html) et le [démon de base de données Slurm (slurmdbd)](https://slurm.schedmd.com/slurmdbd.html). Un nœud de contrôleur est également appelé nœud principal.
**Nœud de contrôleur principal**
Un nœud de contrôleur principal est le nœud de contrôleur actif et actuellement en charge du contrôle dans un cluster Slurm. Il est identifié par Slurm comme étant le nœud de contrôleur principal responsable de la gestion du cluster. Le nœud de contrôleur principal reçoit et exécute les commandes des utilisateurs pour contrôler et allouer des ressources sur les nœuds de calcul afin d’exécuter des tâches.
**Nœud de contrôleur de secours**
Un nœud de contrôleur de secours est un nœud de contrôleur inactif et en veille dans un cluster Slurm. Il est identifié par Slurm comme étant un nœud de contrôleur de secours qui ne gère pas actuellement le cluster. Le nœud de contrôleur de secours exécute le [démon de contrôleur Slurm (slurmctld)](https://slurm.schedmd.com/slurmctld.html) en mode veille. Toutes les commandes de contrôleur exécutées sur les nœuds de contrôleur de secours seront propagées au nœud de contrôleur principal pour exécution. Son objectif principal est de surveiller en permanence le nœud de contrôleur principal et d’assumer ses responsabilités si le nœud de contrôleur principal tombe en panne ou cesse de répondre.
**Nœud de calcul**
Un nœud de calcul est une instance Amazon EC2 au sein d’un cluster qui héberge le [démon de travail Slurm (slurmd)](https://slurm.schedmd.com/slurmd.html). La fonction principale du nœud de calcul est d’exécuter les tâches qui luis sont affectées par le [démon de contrôleur Slurm (slurmctld)](https://slurm.schedmd.com/slurmctld.html) qui s’exécute sur le nœud de contrôleur principal. Lorsqu’une tâche est planifiée, le nœud de calcul reçoit des instructions du [démon de contrôleur Slurm (slurmctld)](https://slurm.schedmd.com/slurmctld.html) pour effectuer les tâches et les calculs nécessaires à cette tâche au sein du nœud lui-même. Un nœud de calcul est également appelé composant master.
## Comment ça marche
Le schéma suivant illustre la façon dont les différents AWS services fonctionnent ensemble pour prendre en charge l'architecture à plusieurs nœuds de contrôleur (têtes) pour les clusters SageMaker HyperPod Slurm.
![\[SageMaker HyperPod schéma d'architecture des nœuds à plusieurs têtes\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/images/hyperpod/hyperpod-multihead-architecture.png)
Les AWS services qui fonctionnent ensemble pour prendre en charge l'architecture à SageMaker HyperPod plusieurs nœuds de contrôleur (têtes) sont les suivants.
**AWS des services qui fonctionnent ensemble pour prendre en charge l'architecture à SageMaker HyperPod plusieurs nœuds de contrôleur**
| Service | Description |
| --- | --- |
| JE SUIS ()Gestion des identités et des accès AWS | Définit deux rôles IAM pour contrôler les autorisations d’accès : un rôle pour le groupe d’instances de nœuds de calcul et l’autre pour le groupe d’instances de nœuds de contrôleur. |
| Amazon RDS for MariaDB | Stocke les données comptables de Slurm, qui contiennent les enregistrements de tâches et les données de mesure. |
| AWS Secrets Manager | Stocke et gère les informations d'identification auxquelles Amazon FSx pour Lustre peut accéder. |
| Amazon FSx pour Lustre | Stocke les configurations et l’état de l’environnement d’exécution de Slurm. |
| Amazon VPC | Fournit un environnement réseau isolé dans lequel le HyperPod cluster et ses ressources sont déployés. |
| Amazon SNS | Envoie des notifications aux administrateurs en cas de changement de statut (le contrôleur Slurm est ON ou OFF) lié au nœud de contrôleur principal. |
Le HyperPod cluster lui-même se compose de nœuds de contrôleur (principaux et de secours) et de nœuds de calcul. Les nœuds du contrôleur exécutent les composants du contrôleur Slurm (SlurmCtld) et de la base de données (SlurmDBd), qui gèrent et surveillent la charge de travail sur les nœuds de calcul.
Les nœuds du contrôleur accèdent aux configurations et à l'état d'exécution de Slurm stockés dans le système de fichiers Amazon FSx for Lustre. Les données comptables de Slurm sont stockées dans la base de données Amazon RDS for MariaDB. AWS Secrets Manager fournit un accès sécurisé aux informations d'identification de base de données pour les nœuds du contrôleur.
En cas de changement de statut (le contrôleur Slurm est `ON` ou `OFF`) dans les nœuds de contrôleur Slurm, Amazon SNS envoie des notifications à l’administrateur pour qu’il prenne les mesures nécessaires.
Cette architecture à plusieurs nœuds de contrôleur élimine le point de défaillance unique d’un nœud de contrôleur (principal) individuel, permet une récupération avec basculement rapide et automatique et vous permet de contrôler la base de données comptable et les configurations de Slurm.
# Configuration de plusieurs nœuds de contrôleur pour un cluster SageMaker HyperPod Slurm
Cette rubrique explique comment configurer plusieurs nœuds de contrôleur (têtes) dans un cluster SageMaker HyperPod Slurm à l'aide de scripts de cycle de vie. Avant de commencer, passez en revue les conditions requises répertoriées dans [Conditions préalables à l'utilisation SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) et familiarisez-vous avec les scripts de cycle de vie dans [Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm.md). Les instructions de cette rubrique utilisent des AWS CLI commandes dans l'environnement Amazon Linux. Notez que les variables d’environnement utilisées dans ces commandes sont disponibles dans la session en cours, sauf si elles sont explicitement préservées.
**Topics**
+ [Approvisionnement de ressources à l'aide de piles CloudFormation](sagemaker-hyperpod-multihead-slurm-cfn.md)
+ [Création et attachement d’une politique IAM](sagemaker-hyperpod-multihead-slurm-iam.md)
+ [Préparation et chargement des scripts de cycle de vie](sagemaker-hyperpod-multihead-slurm-scripts.md)
+ [Création d'un SageMaker HyperPod cluster](sagemaker-hyperpod-multihead-slurm-create.md)
+ [Prise en compte des remarques importantes](sagemaker-hyperpod-multihead-slurm-notes.md)
+ [Révision de la référence des variables d’environnement](sagemaker-hyperpod-multihead-slurm-variables-reference.md)
# Approvisionnement de ressources à l'aide de piles CloudFormation
Pour configurer plusieurs nœuds de contrôleur dans un cluster HyperPod Slurm, provisionnez les AWS ressources via deux CloudFormation piles : et. [Provisionnement des ressources de base](#sagemaker-hyperpod-multihead-slurm-cfn-basic) [Provisionnement de ressources supplémentaires pour prendre en charge plusieurs nœuds de contrôleur](#sagemaker-hyperpod-multihead-slurm-cfn-multihead)
## Provisionnement des ressources de base
Suivez ces étapes pour provisionner des ressources de base pour votre cluster Amazon SageMaker HyperPod Slurm.
1. Téléchargez le fichier de modèle [sagemaker-hyperpod.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod.yaml) sur votre ordinateur. Ce fichier YAML est un CloudFormation modèle qui définit les ressources suivantes à créer pour votre cluster Slurm.
+ Un rôle IAM d’exécution pour le groupe d’instances de nœuds de calcul
+ Un compartiment Amazon S3 pour stocker les scripts du cycle de vie
+ Des sous-réseaux publics et privés (les sous-réseaux privés ont accès à Internet via des passerelles NAT)
+ Gateway/NAT Passerelles Internet
+ Deux groupes de sécurité Amazon EC2
+ Un FSx volume Amazon pour stocker les fichiers de configuration
1. Exécutez la commande CLI suivante pour créer une CloudFormation pile nommée`sagemaker-hyperpod`. Définissez la zone de disponibilité (AZ) IDs de votre cluster dans `PrimarySubnetAZ` et`BackupSubnetAZ`. Par exemple, *use1-az4* il s'agit d'un ID AZ pour une zone de disponibilité de la `us-east-1` région. Pour plus d'informations, consultez les [sections Zone de disponibilité IDs](https://docs.aws.amazon.com//ram/latest/userguide/working-with-az-ids.html) et[Configuration de SageMaker HyperPod clusters sur plusieurs AZs](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-multiple-availability-zones).
```
aws cloudformation deploy \
--template-file /path_to_template/sagemaker-hyperpod.yaml \
--stack-name sagemaker-hyperpod \
--parameter-overrides PrimarySubnetAZ=use1-az4 BackupSubnetAZ=use1-az1 \
--capabilities CAPABILITY_IAM
```
Pour plus d'informations, consultez la section [Déployer](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/deploy/) à partir de la AWS Command Line Interface référence. La création de la pile peut prendre quelques minutes. Une fois l’opération terminée, vous verrez ce qui suit dans votre interface de ligne de commande.
```
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - sagemaker-hyperpod
```
1. (Facultatif) Vérifiez la pile dans la [console CloudFormation](https://console.aws.amazon.com/cloudformation/home).
+ Dans le volet de navigation de gauche, choisissez **Pile**.
+ Sur la page **Pile**, recherchez et choisissez **sagemaker-hyperpod**.
+ Choisissez les onglets tels que **Ressources** et **Sorties** pour passer en revue les ressources et les sorties.
1. Créez des variables d’environnement à partir des sorties de la pile (`sagemaker-hyperpod`). Vous utiliserez les valeurs de ces variables pour effectuer le [Provisionnement de ressources supplémentaires pour prendre en charge plusieurs nœuds de contrôleur](#sagemaker-hyperpod-multihead-slurm-cfn-multihead).
```
source .env
PRIMARY_SUBNET=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`PrimaryPrivateSubnet`].OutputValue' --output text)
BACKUP_SUBNET=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`BackupPrivateSubnet`].OutputValue' --output text)
EMAIL=$(bash -c 'read -p "INPUT YOUR SNSSubEmailAddress HERE: " && echo $REPLY')
DB_USER_NAME=$(bash -c 'read -p "INPUT YOUR DB_USER_NAME HERE: " && echo $REPLY')
SECURITY_GROUP=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`SecurityGroup`].OutputValue' --output text)
ROOT_BUCKET_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`AmazonS3BucketName`].OutputValue' --output text)
SLURM_FSX_DNS_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`FSxLustreFilesystemDNSname`].OutputValue' --output text)
SLURM_FSX_MOUNT_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`FSxLustreFilesystemMountname`].OutputValue' --output text)
COMPUTE_NODE_ROLE=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`AmazonSagemakerClusterExecutionRoleArn`].OutputValue' --output text)
```
Lorsque vous voyez des invites vous demandant votre adresse e-mail et votre nom d’utilisateur de la base de données, entrez des valeurs telles que les suivantes.
```
INPUT YOUR SNSSubEmailAddress HERE: Email_address_to_receive_SNS_notifications
INPUT YOUR DB_USER_NAME HERE: Database_user_name_you_define
```
Pour vérifier les valeurs des variables, utilisez la commande `print $variable`.
```
print $REGION
us-east-1
```
## Provisionnement de ressources supplémentaires pour prendre en charge plusieurs nœuds de contrôleur
Suivez ces étapes pour fournir des ressources supplémentaires à votre cluster Amazon SageMaker HyperPod Slurm avec plusieurs nœuds de contrôleur.
1. Téléchargez le fichier modèle [sagemaker-hyperpod-slurm-multi-headnode.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod-slurm-multi-headnode.yaml) sur votre machine. Ce deuxième fichier YAML est un CloudFormation modèle qui définit les ressources supplémentaires à créer pour le support de plusieurs nœuds de contrôleur dans votre cluster Slurm.
+ Un rôle IAM d’exécution pour le groupe d’instances de nœuds de contrôleur
+ Une instance Amazon RDS for MariaDB
+ Une rubrique et un abonnement Amazon SNS
+ AWS Secrets Manager informations d'identification pour Amazon RDS for MariaDB
1. Exécutez la commande CLI suivante pour créer une CloudFormation pile nommée`sagemaker-hyperpod-mh`. Cette deuxième pile utilise le CloudFormation modèle pour créer des AWS ressources supplémentaires afin de prendre en charge l'architecture à plusieurs nœuds de contrôleur.
```
aws cloudformation deploy \
--template-file /path_to_template/slurm-multi-headnode.yaml \
--stack-name sagemaker-hyperpod-mh \
--parameter-overrides \
SlurmDBSecurityGroupId=$SECURITY_GROUP \
SlurmDBSubnetGroupId1=$PRIMARY_SUBNET \
SlurmDBSubnetGroupId2=$BACKUP_SUBNET \
SNSSubEmailAddress=$EMAIL \
SlurmDBUsername=$DB_USER_NAME \
--capabilities CAPABILITY_NAMED_IAM
```
Pour plus d'informations, consultez la section [Déployer](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/deploy/) à partir de la AWS Command Line Interface référence. La création de la pile peut prendre quelques minutes. Une fois l’opération terminée, vous verrez ce qui suit dans votre interface de ligne de commande.
```
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - sagemaker-hyperpod-mh
```
1. (Facultatif) Vérifiez la pile dans la [console AWS Cloud Formation](https://console.aws.amazon.com/cloudformation/home).
+ Dans le volet de navigation de gauche, choisissez **Pile**.
+ Sur la page **Stack**, recherchez et choisissez **sagemaker-hyperpod-mh**.
+ Choisissez les onglets tels que **Ressources** et **Sorties** pour passer en revue les ressources et les sorties.
1. Créez des variables d’environnement à partir des sorties de la pile (`sagemaker-hyperpod-mh`). Vous utiliserez les valeurs de ces variables pour mettre à jour le fichier de configuration (`provisioning_parameters.json`) dans [Préparation et chargement des scripts de cycle de vie](sagemaker-hyperpod-multihead-slurm-scripts.md).
```
source .env
SLURM_DB_ENDPOINT_ADDRESS=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmDBEndpointAddress`].OutputValue' --output text)
SLURM_DB_SECRET_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmDBSecretArn`].OutputValue' --output text)
SLURM_EXECUTION_ROLE_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmExecutionRoleArn`].OutputValue' --output text)
SLURM_SNS_FAILOVER_TOPIC_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmFailOverSNSTopicArn`].OutputValue' --output text)
```
# Création et attachement d’une politique IAM
Cette section explique comment créer une politique IAM et l’attacher au rôle d’exécution que vous avez créé dans [Provisionnement de ressources supplémentaires pour prendre en charge plusieurs nœuds de contrôleur](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-multihead).
1. Téléchargez l'[exemple de politique IAM](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/1.AmazonSageMakerClustersExecutionRolePolicy.json) sur votre machine depuis le GitHub référentiel.
1. Créez une politique IAM avec l’exemple téléchargé, à l’aide de la commande CLI [create-policy](https://docs.aws.amazon.com//cli/latest/reference/iam/create-policy.html).
```
aws --region us-east-1 iam create-policy \
--policy-name AmazonSagemakerExecutionPolicy \
--policy-document file://1.AmazonSageMakerClustersExecutionRolePolicy.json
```
Exemple de sortie de la commande.
```
{
"Policy": {
"PolicyName": "AmazonSagemakerExecutionPolicy",
"PolicyId": "ANPAXISIWY5UYZM7WJR4W",
"Arn": "arn:aws:iam::111122223333:policy/AmazonSagemakerExecutionPolicy",
"Path": "/",
"DefaultVersionId": "v1",
"AttachmentCount": 0,
"PermissionsBoundaryUsageCount": 0,
"IsAttachable": true,
"CreateDate": "2025-01-22T20:01:21+00:00",
"UpdateDate": "2025-01-22T20:01:21+00:00"
}
}
```
1. Attachez la politique `AmazonSagemakerExecutionPolicy` au rôle d'exécution Slurm que vous avez créé à [Provisionnement de ressources supplémentaires pour prendre en charge plusieurs nœuds de contrôleur](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-multihead) l'aide de la commande [attach-role-policy](https://docs.aws.amazon.com//cli/latest/reference/iam/attach-role-policy.html)CLI.
```
aws --region us-east-1 iam attach-role-policy \
--role-name AmazonSagemakerExecutionRole \
--policy-arn arn:aws:iam::111122223333:policy/AmazonSagemakerExecutionPolicy
```
Cette commande ne produit aucune sortie.
(Facultatif) Si vous utilisez des variables d’environnement, voici des exemples de la commande.
+ Pour obtenir le nom du rôle et le nom de la politique
```
POLICY=$(aws --region $REGION iam list-policies --query 'Policies[?PolicyName==AmazonSagemakerExecutionPolicy].Arn' --output text)
ROLENAME=$(aws --region $REGION iam list-roles --query "Roles[?Arn=='${SLURM_EXECUTION_ROLE_ARN}'].RoleName" —output text)
```
+ Pour attacher la politique
```
aws --region us-east-1 iam attach-role-policy \
--role-name $ROLENAME --policy-arn $POLICY
```
Pour de plus amples informations, veuillez consulter [Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod).
# Préparation et chargement des scripts de cycle de vie
Après avoir créé toutes les ressources requises, vous devez configurer des [scripts de cycle](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) de vie pour votre SageMaker HyperPod cluster. Ces [scripts de cycle](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) de vie fournissent une [configuration de base](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) que vous pouvez utiliser pour créer un cluster HyperPod Slurm de base.
## Préparation des scripts de cycle de vie
Suivez ces étapes pour obtenir les scripts de cycle de vie.
1. Téléchargez les [scripts de cycle](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) de vie depuis le GitHub référentiel sur votre machine.
1. Chargez les [scripts de cycle de vie](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) dans le compartiment Amazon S3 que vous avez créé dans [Provisionnement des ressources de base](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-basic), à l’aide de la commande CLI [cp](https://docs.aws.amazon.com//cli/latest/reference/s3/cp.html).
```
aws s3 cp --recursive LifeCycleScripts/base-config s3://${ROOT_BUCKET_NAME}/LifeCycleScripts/base-config
```
## Création du fichier de configuration
Suivez ces étapes pour créer le fichier de configuration et le charger dans le même compartiment Amazon S3 où vous stockez les scripts de cycle de vie.
1. Créez un fichier de configuration nommé `provisioning_parameters.json` avec la configuration suivante. Notez que la liste `slurm_sns_arn` est facultative. Si ce n'est pas le cas, les notifications Amazon SNS ne HyperPod seront pas configurées.
```
cat < /tmp/provisioning_parameters.json
{
"version": "1.0.0",
"workload_manager": "slurm",
"controller_group": "$CONTOLLER_IG_NAME",
"login_group": "my-login-group",
"worker_groups": [
{
"instance_group_name": "$COMPUTE_IG_NAME",
"partition_name": "dev"
}
],
"fsx_dns_name": "$SLURM_FSX_DNS_NAME",
"fsx_mountname": "$SLURM_FSX_MOUNT_NAME",
"slurm_configurations": {
"slurm_database_secret_arn": "$SLURM_DB_SECRET_ARN",
"slurm_database_endpoint": "$SLURM_DB_ENDPOINT_ADDRESS",
"slurm_shared_directory": "/fsx",
"slurm_database_user": "$DB_USER_NAME",
"slurm_sns_arn": "$SLURM_SNS_FAILOVER_TOPIC_ARN"
}
}
EOF
```
1. Chargez le fichier `provisioning_parameters.json` dans le compartiment Amazon S3 où vous stockez les scripts de cycle de vie.
```
aws s3 cp /tmp/provisioning_parameters.json s3://${ROOT_BUCKET_NAME}/LifeCycleScripts/base-config/provisioning_parameters.json
```
**Note**
Si vous utilisez une configuration pilotée par API, le `provisioning_parameters.json` fichier n'est pas obligatoire. Avec la configuration pilotée par API, vous définissez les types de nœuds Slurm, les partitions et le FSx montage directement dans la charge utile de l'API. CreateCluster Pour plus de détails, voir [Commencer SageMaker HyperPod à utiliser le AWS CLI](smcluster-getting-started-slurm-cli.md).
## Vérification des fichiers dans le compartiment Amazon S3
Une fois que vous avez chargé tous les scripts de cycle de vie et le fichier `provisioning_parameters.json`, votre compartiment Amazon S3 devrait ressembler à ce qui suit.
![\[Image montrant tous les scripts de cycle de vie chargés dans le compartiment Amazon S3 dans la console Amazon Simple Storage Service.\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-scripts-s3.png)
Pour plus d'informations, voir [Commencer avec les scripts de cycle de vie de base fournis par HyperPod](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.html).
# Création d'un SageMaker HyperPod cluster
Après avoir configuré toutes les ressources requises et chargé les scripts dans le compartiment Amazon S3, vous pouvez créer un cluster.
1. Pour créer un cluster, exécutez la [https://docs.aws.amazon.com//cli/latest/reference/sagemaker/create-cluster.html](https://docs.aws.amazon.com//cli/latest/reference/sagemaker/create-cluster.html) AWS CLI commande. Le processus de création peut prendre jusqu’à 15 minutes.
```
aws --region $REGION sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--vpc-config '{
"SecurityGroupIds":["'$SECURITY_GROUP'"],
"Subnets":["'$PRIMARY_SUBNET'", "'$BACKUP_SUBNET'"]
}' \
--instance-groups '[{
"InstanceGroupName": "'$CONTOLLER_IG_NAME'",
"InstanceType": "ml.t3.medium",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$SLURM_EXECUTION_ROLE_ARN'",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "'$COMPUTE_IG_NAME'",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$COMPUTE_NODE_ROLE'",
"ThreadsPerCore": 1
}]'
```
Une fois l’exécution réussie, la commande renvoie l’ARN du cluster comme suit.
```
{
"ClusterArn": "arn:aws:sagemaker:us-east-1:111122223333:cluster/cluster_id"
}
```
1. (Facultatif) Pour vérifier l'état de votre cluster, vous pouvez utiliser la console SageMaker AI ([https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/)). Dans le menu de navigation de gauche, choisissez **HyperPod Clusters**, puis sélectionnez **Cluster Management**. Choisissez le nom d’un cluster pour ouvrir la page de détails du cluster. Si votre cluster est créé avec succès, vous verrez que l'état du cluster est **InService**.
![\[Image montrant un cluster HyperPod Slurm avec plusieurs nœuds de contrôleur dans la console Amazon SageMaker AI.\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-multihead-cluster.png)
# Prise en compte des remarques importantes
Cette section contient plusieurs remarques importantes qui pourraient vous être utiles.
1. Pour migrer vers un cluster Slurm à plusieurs contrôleurs, procédez comme suit.
1. Suivez les instructions dans [Approvisionnement de ressources à l'aide de piles CloudFormation](sagemaker-hyperpod-multihead-slurm-cfn.md) pour provisionner toutes les ressources nécessaires.
1. Suivez les instructions dans [Préparation et chargement des scripts de cycle de vie](sagemaker-hyperpod-multihead-slurm-scripts.md) pour charger les scripts de cycle de vie mis à jour. Lors de la mise à jour du fichier `provisioning_parameters.json`, déplacez votre groupe de contrôleurs existant vers la section `worker_groups` et ajoutez un nouveau nom de groupe de contrôleurs dans la section `controller_group`.
1. Exécutez l’appel d’API [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) pour créer un nouveau groupe de contrôleurs et conserver les groupes d’instances de calcul et le groupe de contrôleurs d’origine.
1. Pour réduire verticalement le nombre de nœuds de contrôleur, utilisez la commande CLI [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html). Pour chaque groupe d’instances de contrôleur, le nombre minimum de nœuds de contrôleur que vous pouvez réduire verticalement est de 1. Cela signifie que vous ne pouvez pas réduire verticalement le nombre de nœuds de contrôleur à 0.
**Important**
Pour les clusters créés avant le 24 janvier 2025, vous devez d'abord mettre à jour le logiciel de votre cluster à l'aide de l'[UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API avant d'exécuter la commande [update-cluster CLI](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html).
Voici un exemple de commande CLI permettant de réduire verticalement le nombre de nœuds de contrôleur.
```
aws sagemaker update-cluster \
--cluster-name my_cluster \
--instance-groups '[{
"InstanceGroupName": "controller_ig_name",
"InstanceType": "ml.t3.medium",
"InstanceCount": 3,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket1",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "slurm_execution_role_arn",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "compute-ig_name",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket1",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "compute_node_role_arn",
"ThreadsPerCore": 1
}]'
```
1. Pour supprimer par lots les nœuds du contrôleur, utilisez la commande [batch-delete-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/batch-delete-cluster-nodes.html)CLI. Pour chaque groupe d’instances de contrôleur, vous devez conserver au moins un nœud de contrôleur. Si vous souhaitez supprimer par lots tous les nœuds de contrôleur, l’opération d’API ne fonctionnera pas.
**Important**
Pour les clusters créés avant le 24 janvier 2025, vous devez d'abord mettre à jour le logiciel de votre cluster à l'aide de l'[UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API avant d'exécuter la commande [batch-delete-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/batch-delete-cluster-nodes.html)CLI.
Voici un exemple de commande CLI permettant de supprimer par lots les nœuds de contrôleur.
```
aws sagemaker batch-delete-cluster-nodes --cluster-name my_cluster --node-ids instance_ids_to_delete
```
1. Pour résoudre les problèmes liés à la création de votre cluster, consultez le message d'échec affiché sur la page des détails du cluster de votre console SageMaker AI. Vous pouvez également utiliser CloudWatch les journaux pour résoudre les problèmes de création de clusters. Dans la CloudWatch console, choisissez **Log groups**. Ensuite, recherchez `clusters` pour afficher la liste des groupes de journaux liés à la création de votre cluster.
![\[Image montrant les groupes de journaux du SageMaker HyperPod cluster Amazon dans la CloudWatch console.\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-multihead-logs.png)
# Révision de la référence des variables d’environnement
Les variables d’environnement suivantes sont définies et utilisées dans le didacticiel [Configuration de plusieurs nœuds de contrôleur pour un cluster SageMaker HyperPod Slurm](sagemaker-hyperpod-multihead-slurm-setup.md). Ces variables d’environnement sont disponibles uniquement dans la session en cours, sauf si elles sont explicitement préservées. Elles sont définies à l’aide de la syntaxe `$variable_name`. Les variables avec des key/value paires représentent les ressources AWS créées, tandis que les variables sans clés sont définies par l'utilisateur.
**Référence des variables d’environnement**
| Variable | Description |
| --- | --- |
| \$1BACKUP\$1SUBNET | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1COMPUTE\$1IG\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1COMPUTE\$1NODE\$1ROLE | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1CONTOLLER\$1IG\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1DB\$1USER\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1EMAIL | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1PRIMARY\$1SUBNET | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1POLICY | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1REGION | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1ROOT\$1BUCKET\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SECURITY\$1GROUP | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1DB\$1ENDPOINT\$1ADDRESS | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1DB\$1SECRET\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1EXECUTION\$1ROLE\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1FSX\$1DNS\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1FSX\$1MOUNT\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1SNS\$1FAILOVER\$1TOPIC\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
# Offres d'emploi sur SageMaker HyperPod des clusters
Les rubriques suivantes fournissent des procédures et des exemples d'accès aux nœuds de calcul et d'exécution de charges de travail ML sur des clusters provisionnés SageMaker HyperPod . Selon la façon dont vous avez configuré l'environnement sur votre HyperPod cluster, il existe de nombreuses manières d'exécuter des charges de travail ML sur des HyperPod clusters. Des exemples d'exécution de charges de travail ML sur des HyperPod clusters sont également fournis dans le référentiel [Awsome Distributed Training GitHub ](https://github.com/aws-samples/awsome-distributed-training/). Les rubriques suivantes vous expliquent comment vous connecter aux HyperPod clusters provisionnés et vous aident à exécuter des exemples de charges de travail ML.
**Astuce**
Pour trouver des exemples pratiques et des solutions, consultez également l'[SageMaker HyperPodatelier](https://catalog.workshops.aws/sagemaker-hyperpod).
**Topics**
+ [Accès aux nœuds SageMaker HyperPod de votre cluster](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md)
+ [Planification d'une tâche Slurm sur un cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm-schedule-slurm-job.md)
+ [Exécution de conteneurs Docker sur un nœud de calcul Slurm sur HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md)
+ [Exécution de charges de travail de formation distribuées avec Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)
# Accès aux nœuds SageMaker HyperPod de votre cluster
Vous pouvez accéder à votre **InService**cluster via AWS Systems Manager (SSM) en exécutant la AWS CLI commande `aws ssm start-session` avec le nom d'hôte du SageMaker HyperPod cluster au format de`sagemaker-cluster:[cluster-id]_[instance-group-name]-[instance-id]`. Vous pouvez récupérer l'ID du cluster, l'ID de l'instance et le nom du groupe d'instances depuis la [SageMaker HyperPod console](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters) ou en exécutant `describe-cluster` et `list-cluster-nodes` depuis les [AWS CLI commandes pour SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes). Par exemple, si votre ID de cluster est `aa11bbbbb222`, le nom du nœud de cluster `controller-group` et l’ID du nœud de cluster `i-111222333444555aa`, la commande SSM `start-session` doit être la suivante.
**Note**
Le fait d'accorder aux utilisateurs l'accès aux nœuds HyperPod du cluster leur permet d'installer et d'utiliser des logiciels gérés par les utilisateurs sur les nœuds. Assurez-vous de respecter le principe des autorisations de moindre privilège pour les utilisateurs.
Si vous ne l'avez pas encore configuré AWS Systems Manager, suivez les instructions fournies à l'adresse[Configuration AWS Systems Manager et exécution en tant que pour le contrôle d'accès des utilisateurs du cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm).
```
$ aws ssm start-session \
--target sagemaker-cluster:aa11bbbbb222_controller-group-i-111222333444555aa \
--region us-west-2
Starting session with SessionId: s0011223344aabbccdd
root@ip-111-22-333-444:/usr/bin#
```
Notez que cela vous connecte initialement en tant qu’utilisateur racine. Avant d’exécuter des tâches, basculez vers l’utilisateur `ubuntu` en exécutant la commande suivante.
```
root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
Pour les paramètres avancés permettant une utilisation pratique des HyperPod clusters, consultez les rubriques suivantes.
**Topics**
+ [Conseils supplémentaires pour accéder aux nœuds de votre SageMaker HyperPod cluster](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-tips)
+ [Configurez un environnement multi-utilisateurs via l'espace FSx partagé Amazon](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-fxs-shared-space)
+ [Configuration d'un environnement multi-utilisateurs en intégrant des HyperPod clusters à Active Directory](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-active-directory)
## Conseils supplémentaires pour accéder aux nœuds de votre SageMaker HyperPod cluster
**Utilisez le `easy-ssh.sh` script fourni par HyperPod pour simplifier le processus de connexion**
Pour transformer le processus précédent en une seule ligne de commande, l' HyperPod équipe fournit le [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh)script qui récupère les informations de votre cluster, les agrège dans la commande SSM et se connecte au nœud de calcul. Il n'est pas nécessaire de rechercher manuellement les informations de HyperPod cluster requises car ce script s'exécute `describe-cluster` et `list-cluster-nodes` commande et analyse les informations nécessaires pour exécuter la commande SSM. Les exemples de commandes suivants montrent comment exécuter le script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh). S’il s’exécute correctement, vous serez connecté au cluster en tant qu’utilisateur racine. Il imprime également un extrait de code pour configurer SSH en ajoutant le HyperPod cluster en tant qu'hôte distant via un proxy SSM. En configurant SSH, vous pouvez connecter votre environnement de développement local tel que Visual Studio Code au HyperPod cluster.
```
$ chmod +x easy-ssh.sh
$ ./easy-ssh.sh -c
Cluster id:
Instance id:
Node Group:
Add the following to your ~/.ssh/config to easily connect:
$ cat <> ~/.ssh/config
Host
User ubuntu
ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
EOF
Add your ssh keypair and then you can do:
$ ssh
aws ssm start-session --target sagemaker-cluster:_-
Starting session with SessionId: s0011223344aabbccdd
root@ip-111-22-333-444:/usr/bin#
```
Notez que cela vous connecte initialement en tant qu’utilisateur racine. Avant d’exécuter des tâches, basculez vers l’utilisateur `ubuntu` en exécutant la commande suivante.
```
root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
**Configuration pour un accès facile avec SSH en utilisant le nœud de HyperPod calcul comme hôte distant**
Pour simplifier davantage l'accès au nœud de calcul via SSH depuis une machine locale, le `easy-ssh.sh` script génère un extrait de code expliquant comment configurer le HyperPod cluster en tant qu'hôte distant, comme indiqué dans la section précédente. L’extrait de code est généré automatiquement pour vous aider à l’ajouter directement au fichier `~/.ssh/config` sur votre appareil local. La procédure suivante explique comment configurer un accès facile à l'aide de SSH via le proxy SSM, afin que vous ou les utilisateurs de votre cluster puissiez directement vous connecter `ssh ` au nœud du HyperPod cluster.
1. Sur votre appareil local, ajoutez le nœud de HyperPod calcul avec un nom d'utilisateur en tant qu'hôte distant au `~/.ssh/config` fichier. La commande suivante indique comment ajouter au fichier `~/.ssh/config` l’extrait de code généré automatiquement à partir du script `easy-ssh.sh`. Assurez-vous de le copier à partir de la sortie générée automatiquement du script `easy-ssh.sh` contenant les informations de cluster correctes.
```
$ cat <> ~/.ssh/config
Host
User ubuntu
ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
EOF
```
1. Sur le nœud de HyperPod cluster, ajoutez la clé publique de votre appareil local au `~/.ssh/authorized_keys` fichier sur le nœud de HyperPod cluster.
1. Imprimez le fichier de clé publique sur votre ordinateur local.
```
$ cat ~/.ssh/id_rsa.pub
```
Cela devrait renvoyer votre clé. Copiez la sortie de cette commande.
(Facultatif) Si vous n’avez pas de clé publique, créez-en une en exécutant la commande suivante.
```
$ ssh-keygen -t rsa -q -f "$HOME/.ssh/id_rsa" -N ""
```
1. Connectez-vous au nœud du cluster et basculez vers l’utilisateur pour ajouter la clé. La commande suivante est un exemple d’accès en tant qu’utilisateur `ubuntu`. Remplacez `ubuntu` par le nom de l’utilisateur pour lequel vous souhaitez configurer l’accès facile avec SSH.
```
$ ./easy-ssh.sh -c
$ sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
1. Ouvrez le fichier `~/.ssh/authorized_keys` et ajoutez la clé publique à la fin du fichier.
```
ubuntu@ip-111-22-333-444:/usr/bin# vim ~/.ssh/authorized_keys
```
Une fois la configuration terminée, vous pouvez vous connecter au nœud du HyperPod cluster en tant qu'utilisateur en exécutant une commande SSH simplifiée comme suit.
```
$ ssh
ubuntu@ip-111-22-333-444:/usr/bin#
```
Vous pouvez également utiliser l’hôte pour le développement à distance à partir d’un environnement IDE sur votre appareil local, tel que [Visual Studio Code Remote - SSH](https://code.visualstudio.com/docs/remote/ssh).
## Configurez un environnement multi-utilisateurs via l'espace FSx partagé Amazon
Vous pouvez utiliser l'espace FSx partagé Amazon pour gérer un environnement multi-utilisateurs dans un cluster Slurm sur. SageMaker HyperPod Si vous avez configuré votre cluster Slurm avec Amazon FSx lors de la création du HyperPod cluster, c'est une bonne option pour configurer un espace de travail pour les utilisateurs de votre cluster. Créez un nouvel utilisateur et configurez le répertoire personnel de l'utilisateur sur le système de fichiers FSx partagé Amazon.
**Astuce**
Pour permettre aux utilisateurs d’accéder à votre cluster par le biais de leur nom d’utilisateur et de répertoires dédiés, vous devez également les associer à des rôles ou à des utilisateurs IAM en les balisant comme indiqué dans l’**option 2** de l’étape 5 de la procédure **Pour activer la prise en charge de l’option Exécuter en tant que pour les nœuds gérés sous Linux et macOS** fournie dans [Activation de la prise en charge de l’option Exécuter en tant que pour les nœuds gérés sous Linux et macOS](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html) dans le Guide de l’utilisateur AWS Systems Manager . Consultez également [Configuration AWS Systems Manager et exécution en tant que pour le contrôle d'accès des utilisateurs du cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm).
**Pour configurer un environnement multi-utilisateurs lors de la création d'un cluster Slurm sur SageMaker HyperPod**
L'équipe SageMaker HyperPod de service fournit un script dans le [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)cadre des exemples de script de cycle de vie de base.
1. Préparez un fichier texte nommé `shared_users.txt` que vous devez créer au format suivant. La première colonne est destinée aux noms d'utilisateur, la deuxième colonne aux utilisateurs IDs uniques et la troisième aux annuaires des utilisateurs de l'espace FSx partagé Amazon.
```
username1,uid1,/fsx/username1
username2,uid2,/fsx/username2
...
```
1. Assurez-vous de télécharger les [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)fichiers `shared_users.txt` et dans le compartiment S3 pour les scripts de HyperPod cycle de vie. Lorsque la création du cluster, la mise à jour du cluster ou la mise à jour logicielle du cluster est en cours, [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh) lit dans `shared_users.txt` et configure correctement les répertoires des utilisateurs.
**Pour créer de nouveaux utilisateurs et les ajouter à un cluster Slurm existant exécuté sur SageMaker HyperPod **
1. Sur le nœud principal, exécutez la commande suivante pour enregistrer un script qui aide à créer un utilisateur. Assurez-vous de l’exécuter avec les autorisations sudo.
```
$ cat > create-user.sh << EOL
#!/bin/bash
set -x
# Prompt user to get the new user name.
read -p "Enter the new user name, i.e. 'sean':
" USER
# create home directory as /fsx/
# Create the new user on the head node
sudo useradd \$USER -m -d /fsx/\$USER --shell /bin/bash;
user_id=\$(id -u \$USER)
# add user to docker group
sudo usermod -aG docker \${USER}
# setup SSH Keypair
sudo -u \$USER ssh-keygen -t rsa -q -f "/fsx/\$USER/.ssh/id_rsa" -N ""
sudo -u \$USER cat /fsx/\$USER/.ssh/id_rsa.pub | sudo -u \$USER tee /fsx/\$USER/.ssh/authorized_keys
# add user to compute nodes
read -p "Number of compute nodes in your cluster, i.e. 8:
" NUM_NODES
srun -N \$NUM_NODES sudo useradd -u \$user_id \$USER -d /fsx/\$USER --shell /bin/bash;
# add them as a sudoer
read -p "Do you want this user to be a sudoer? (y/N):
" SUDO
if [ "\$SUDO" = "y" ]; then
sudo usermod -aG sudo \$USER
sudo srun -N \$NUM_NODES sudo usermod -aG sudo \$USER
echo -e "If you haven't already you'll need to run:\n\nsudo visudo /etc/sudoers\n\nChange the line:\n\n%sudo ALL=(ALL:ALL) ALL\n\nTo\n\n%sudo ALL=(ALL:ALL) NOPASSWD: ALL\n\nOn each node."
fi
EOL
```
1. Exécutez le script avec la commande suivante. Il vous sera demandé d’ajouter le nom d’un utilisateur et le nombre de nœuds de calcul auxquels vous souhaitez autoriser l’utilisateur à accéder.
```
$ bash create-user.sh
```
1. Testez l’utilisateur en exécutant les commandes suivantes.
```
$ sudo su - && ssh $(srun hostname)
```
1. Ajoutez les informations utilisateur au fichier `shared_users.txt`, afin que l’utilisateur soit créé sur tout nouveau nœud de calcul ou nouveau cluster.
## Configuration d'un environnement multi-utilisateurs en intégrant des HyperPod clusters à Active Directory
Dans les cas pratiques, les HyperPod clusters sont généralement utilisés par plusieurs utilisateurs : chercheurs en apprentissage automatique (ML), ingénieurs logiciels, scientifiques des données et administrateurs de clusters. Ils modifient leurs propres fichiers et exécutent leurs propres tâches sans affecter le travail des autres. Pour configurer un environnement multi-utilisateur, utilisez le mécanisme des utilisateurs et des groupes Linux pour créer de manière statique plusieurs utilisateurs sur chaque instance via les scripts de cycle de vie. Toutefois, l’inconvénient de cette approche est que vous devez dupliquer les paramètres des utilisateurs et des groupes sur plusieurs instances du cluster afin de conserver une configuration cohérente dans toutes les instances lorsque vous effectuez des mises à jour, telles que l’ajout, la modification et la suppression d’utilisateurs.
Pour résoudre ce problème, vous pouvez utiliser le [protocole LDAP (Lightweight Directory Access Protocol)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) et le protocole [LDAP over TLS/SSL (LDAPS)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) pour intégrer un service d'annuaire tel que [AWS Directory Service pour Microsoft](https://aws.amazon.com/directoryservice/) Active Directory. Pour en savoir plus sur la configuration d'Active Directory et d'un environnement multi-utilisateurs dans un HyperPod cluster, consultez le billet de blog [Intégrer les HyperPod clusters à Active Directory pour une connexion multi-utilisateurs fluide](https://aws.amazon.com/blogs/machine-learning/integrate-hyperpod-clusters-with-active-directory-for-seamless-multi-user-login/).
# Planification d'une tâche Slurm sur un cluster SageMaker HyperPod
Vous pouvez lancer des tâches d’entraînement à l’aide des commandes Slurm `sbatch` ou `srun` standard. Par exemple, pour lancer une tâche de formation à 8 nœuds, vous pouvez exécuter une formation de `srun -N 8 --exclusive train.sh` SageMaker HyperPod support dans différents environnements, notamment`conda`, `venv``docker`, et`enroot`. Vous pouvez configurer un environnement ML en exécutant des scripts de cycle de vie sur vos SageMaker HyperPod clusters. Vous avez également la possibilité de joindre un système de fichiers partagé tel qu'Amazon FSx, qui peut également être utilisé comme environnement virtuel.
L'exemple suivant montre comment exécuter une tâche pour former Llama-2 à l'aide de la technique FSDP (Fully Sharded Data Parallelism) sur un cluster SageMaker HyperPod doté d'un système de fichiers partagé Amazon. FSx Vous pouvez également trouver d'autres exemples dans le [ GitHub référentiel Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/).
**Astuce**
Tous les SageMaker HyperPod exemples sont disponibles dans le `3.test_cases` dossier du [ GitHub référentiel Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/).
1. Clonez le [ GitHub référentiel Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/) et copiez les exemples de tâches de formation dans votre système de FSx fichiers Amazon.
```
$ TRAINING_DIR=/fsx/users/my-user/fsdp
$ git clone https://github.com/aws-samples/awsome-distributed-training/
```
1. Exécutez le script [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh). Cela crée un `conda` environnement sur votre système de FSx fichiers Amazon. Assurez-vous que le système de fichiers est accessible à tous les nœuds du cluster.
1. Créez l’environnement Conda virtuel en lançant une tâche Slurm à nœud unique comme suit.
```
$ srun -N 1 /path_to/create_conda_env.sh
```
1. Une fois l’environnement généré, vous pouvez lancer une tâche d’entraînement en pointant sur le chemin de l’environnement sur le volume partagé. Vous pouvez lancer des tâches d’entraînement à nœud unique ou à nœuds multiples avec la même configuration. Pour lancer une tâche, créez un script de lancement de tâches (également appelé script de point d’entrée), comme suit.
```
#!/usr/bin/env bash
set -ex
ENV_PATH=/fsx/users/my_user/pytorch_env
TORCHRUN=$ENV_PATH/bin/torchrun
TRAINING_SCRIPT=/fsx/users/my_user/pt_train.py
WORLD_SIZE_JOB=$SLURM_NTASKS
RANK_NODE=$SLURM_NODEID
PROC_PER_NODE=8
MASTER_ADDR=(`scontrol show hostnames \$SLURM_JOB_NODELIST | head -n 1`)
MASTER_PORT=$(expr 10000 + $(echo -n $SLURM_JOBID | tail -c 4))
DIST_ARGS="--nproc_per_node=$PROC_PER_NODE \
--nnodes=$WORLD_SIZE_JOB \
--node_rank=$RANK_NODE \
--master_addr=$MASTER_ADDR \
--master_port=$MASTER_PORT \
"
$TORCHRUN $DIST_ARGS $TRAINING_SCRIPT
```
**Astuce**
Si vous souhaitez améliorer la résilience de votre formation face aux pannes matérielles en utilisant la fonctionnalité de reprise automatique de SageMaker HyperPod, vous devez configurer correctement la variable d'environnement `MASTER_ADDR` dans le script du point d'entrée. Pour en savoir plus, veuillez consulter la section [Restauration automatique des nœuds et reprise automatique](sagemaker-hyperpod-resiliency-slurm-auto-resume.md).
Ce didacticiel suppose que ce script est enregistré sous `/fsx/users/my_user/train.sh`.
1. Avec ce script dans le volume partagé à l’adresse `/fsx/users/my_user/train.sh`, exécutez la commande `srun` suivante pour planifier la tâche Slurm.
```
$ cd /fsx/users/my_user/
$ srun -N 8 train.sh
```
# Exécution de conteneurs Docker sur un nœud de calcul Slurm sur HyperPod
[Pour exécuter des conteneurs Docker avec Slurm activé SageMaker HyperPod, vous devez utiliser [Enroot](https://github.com/NVIDIA/enroot) et Pyxis.](https://github.com/NVIDIA/pyxis) Le package Enroot permet de convertir les images Docker en un environnement d’exécution compréhensible par Slurm, tandis que Pyxis permet de planifier l’exécution en tant que tâche Slurm via une commande `srun` `srun --container-image=docker/image:tag`.
**Astuce**
Les packages Docker, Enroot et Pyxis doivent être installés lors de la création du cluster dans le cadre de l’exécution des scripts de cycle de vie, comme indiqué dans [Scripts de cycle de vie de base fournis par HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md). Utilisez les [scripts de cycle de vie de base](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) fournis par l'équipe HyperPod de service lors de la création d'un HyperPod cluster. Ces scripts de base sont configurés pour installer les packages par défaut. Dans le script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py), il y a la classe `Config` avec le paramètre de type booléen pour installer les packages définis sur `True` (`enable_docker_enroot_pyxis=True`). Ceci est appelé et analysé dans le script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py), qui appelle les scripts `install_docker.sh` et `install_enroot_pyxis.sh` depuis le dossier [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils). Les scripts d’installation sont l’emplacement où les installations réelles des packages ont lieu. En outre, les scripts d'installation déterminent s'ils peuvent détecter les chemins de NVMe stockage à partir des instances sur lesquelles ils sont exécutés et définissent les chemins racines vers lesquels Docker et Enroot doivent accéder. `/opt/dlami/nvme` Le volume racine par défaut de toute nouvelle instance est monté `/tmp` uniquement sur un volume EBS de 100 Go, qui s'épuise si la charge de travail que vous prévoyez d'exécuter implique un entraînement LLMs et donc des conteneurs Docker de grande taille. Si vous utilisez des familles d'instances telles que P et G avec un NVMe stockage local, vous devez vous assurer que vous utilisez le NVMe stockage rattaché à`/opt/dlami/nvme`, et les scripts d'installation prennent en charge les processus de configuration.
**Pour vérifier si les chemins racines sont correctement configurés**
Sur un nœud de calcul de votre cluster Slurm activé SageMaker HyperPod, exécutez les commandes suivantes pour vous assurer que le script de cycle de vie fonctionne correctement et que le volume racine de chaque nœud est défini sur. `/opt/dlami/nvme/*` Les commandes suivantes montrent des exemples de vérification du chemin d’exécution Enroot et du chemin racine des données pour 8 nœuds de calcul d’un cluster Slurm.
```
$ srun -N 8 cat /etc/enroot/enroot.conf | grep "ENROOT_RUNTIME_PATH"
ENROOT_RUNTIME_PATH /opt/dlami/nvme/tmp/enroot/user-$(id -u)
... // The same or similar lines repeat 7 times
```
```
$ srun -N 8 cat /etc/docker/daemon.json
{
"data-root": "/opt/dlami/nvme/docker/data-root"
}
... // The same or similar lines repeat 7 times
```
Après avoir confirmé que les chemins d’exécution sont correctement définis sur `/opt/dlami/nvme/*`, vous êtes prêt à générer et à exécuter des conteneurs Docker avec Enroot et Pyxis.
**Pour tester Docker avec Slurm**
1. Sur votre nœud de calcul, essayez les commandes suivantes pour vérifier si Docker et Enroot sont correctement installés.
```
$ docker --help
$ enroot --help
```
1. Testez si Pyxis et Enroot sont correctement installés en exécutant l’une des images [NVIDIA CUDA Ubuntu](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda).
```
$ srun --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY nvidia-smi
pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
DAY MMM DD HH:MM:SS YYYY
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 |
| N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
```
Vous pouvez également le tester en créant un script et en exécutant une commande `sbatch` comme suit.
```
$ cat <> container-test.sh
#!/bin/bash
#SBATCH --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
nvidia-smi
EOF
$ sbatch container-test.sh
pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
DAY MMM DD HH:MM:SS YYYY
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 |
| N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
```
**Pour exécuter une tâche Slurm de test avec Docker**
Une fois que vous avez terminé de configurer Slurm avec Docker, vous pouvez apporter toutes les images Docker prédéfinies et exécuter avec Slurm on. SageMaker HyperPod Voici un exemple de cas d'utilisation qui explique comment exécuter une tâche de formation à l'aide de Docker et de Slurm on. SageMaker HyperPod Il montre un exemple de travail d'apprentissage parallèle du modèle Llama 2 avec la bibliothèque de parallélisme des modèles SageMaker AI (SMP).
1. Si vous souhaitez utiliser l'une des images ECR prédéfinies distribuées par SageMaker AI ou DLC, assurez-vous d'autoriser votre HyperPod cluster à extraire des images ECR via le. [Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) Si vous utilisez votre propre image Docker ou une image Docker open source, vous pouvez ignorer cette étape. Ajoutez les autorisations suivantes au [Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod). Dans ce didacticiel, nous utilisons l’[image Docker SMP](distributed-model-parallel-support-v2.md#distributed-model-parallel-supported-frameworks-v2) prépackagée avec la bibliothèque SMP.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr-public:*",
"ecr:GetDownloadUrlForLayer",
"ecr:GetAuthorizationToken",
"sts:*"
],
"Resource": "*"
}
]
}
```
------
1. Sur le nœud de calcul, clonez le référentiel et accédez au dossier contenant les exemples de scripts d’entraînement avec SMP.
```
$ git clone https://github.com/aws-samples/awsome-distributed-training/
$ cd awsome-distributed-training/3.test_cases/17.SM-modelparallelv2
```
1. Dans ce didacticiel, exécutez l’exemple de script [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh) qui extrait l’image Docker SMP, crée le conteneur Docker et l’exécute en tant qu’environnement d’exécution Enroot. Vous pouvez modifier cela comme vous le souhaitez.
```
$ cat docker_build.sh
#!/usr/bin/env bash
region=us-west-2
dlc_account_id=658645717510
aws ecr get-login-password --region $region | docker login --username AWS --password-stdin $dlc_account_id.dkr.ecr.$region.amazonaws.com
docker build -t smpv2 .
enroot import -o smpv2.sqsh dockerd://smpv2:latest
```
```
$ bash docker_build.sh
```
1. Créez un script de commandes pour lancer une tâche d’entraînement à l’aide de `sbatch`. Dans ce didacticiel, l’exemple de script fourni [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh) lance une tâche d’entraînement parallèle du modèle Llama 2 de 70 milliards de paramètres avec un jeu de données synthétique sur 8 nœuds de calcul. Un ensemble de scripts d’entraînement sont fournis dans [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts), et `launch_training_enroot.sh` prend `train_external.py` comme script de point d’entrée.
**Important**
Pour utiliser un conteneur Docker sur SageMaker HyperPod, vous devez monter le `/var/log` répertoire depuis la machine hôte, qui est le nœud de HyperPod calcul dans ce cas, sur le `/var/log` répertoire du conteneur. Vous pouvez le configurer en ajoutant la variable suivante pour Enroot.
```
"${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}"
```
```
$ cat launch_training_enroot.sh
#!/bin/bash
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0
#SBATCH --nodes=8 # number of nodes to use, 2 p4d(e) = 16 A100 GPUs
#SBATCH --job-name=smpv2_llama # name of your job
#SBATCH --exclusive # job has exclusive use of the resource, no sharing
#SBATCH --wait-all-nodes=1
set -ex;
###########################
###### User Variables #####
###########################
#########################
model_type=llama_v2
model_size=70b
# Toggle this to use synthetic data
use_synthetic_data=1
# To run training on your own data set Training/Test Data path -> Change this to the tokenized dataset path in Fsx. Acceptable formats are huggingface (arrow) and Jsonlines.
# Also change the use_synthetic_data to 0
export TRAINING_DIR=/fsx/path_to_data
export TEST_DIR=/fsx/path_to_data
export CHECKPOINT_DIR=$(pwd)/checkpoints
# Variables for Enroot
: "${IMAGE:=$(pwd)/smpv2.sqsh}"
: "${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}" # This is needed for validating its hyperpod cluster
: "${TRAIN_DATA_PATH:=$TRAINING_DIR:$TRAINING_DIR}"
: "${TEST_DATA_PATH:=$TEST_DIR:$TEST_DIR}"
: "${CHECKPOINT_PATH:=$CHECKPOINT_DIR:$CHECKPOINT_DIR}"
###########################
## Environment Variables ##
###########################
#export NCCL_SOCKET_IFNAME=en
export NCCL_ASYNC_ERROR_HANDLING=1
export NCCL_PROTO="simple"
export NCCL_SOCKET_IFNAME="^lo,docker"
export RDMAV_FORK_SAFE=1
export FI_EFA_USE_DEVICE_RDMA=1
export NCCL_DEBUG_SUBSYS=off
export NCCL_DEBUG="INFO"
export SM_NUM_GPUS=8
export GPU_NUM_DEVICES=8
export FI_EFA_SET_CUDA_SYNC_MEMOPS=0
# async runtime error ...
export CUDA_DEVICE_MAX_CONNECTIONS=1
#########################
## Command and Options ##
#########################
if [ "$model_size" == "7b" ]; then
HIDDEN_WIDTH=4096
NUM_LAYERS=32
NUM_HEADS=32
LLAMA_INTERMEDIATE_SIZE=11008
DEFAULT_SHARD_DEGREE=8
# More Llama model size options
elif [ "$model_size" == "70b" ]; then
HIDDEN_WIDTH=8192
NUM_LAYERS=80
NUM_HEADS=64
LLAMA_INTERMEDIATE_SIZE=28672
# Reduce for better perf on p4de
DEFAULT_SHARD_DEGREE=64
fi
if [ -z "$shard_degree" ]; then
SHARD_DEGREE=$DEFAULT_SHARD_DEGREE
else
SHARD_DEGREE=$shard_degree
fi
if [ -z "$LLAMA_INTERMEDIATE_SIZE" ]; then
LLAMA_ARGS=""
else
LLAMA_ARGS="--llama_intermediate_size $LLAMA_INTERMEDIATE_SIZE "
fi
if [ $use_synthetic_data == 1 ]; then
echo "using synthetic data"
declare -a ARGS=(
--container-image $IMAGE
--container-mounts $HYPERPOD_PATH,$CHECKPOINT_PATH
)
else
echo "using real data...."
declare -a ARGS=(
--container-image $IMAGE
--container-mounts $HYPERPOD_PATH,$TRAIN_DATA_PATH,$TEST_DATA_PATH,$CHECKPOINT_PATH
)
fi
declare -a TORCHRUN_ARGS=(
# change this to match the number of gpus per node:
--nproc_per_node=8 \
--nnodes=$SLURM_JOB_NUM_NODES \
--rdzv_id=$SLURM_JOB_ID \
--rdzv_backend=c10d \
--rdzv_endpoint=$(hostname) \
)
srun -l "${ARGS[@]}" torchrun "${TORCHRUN_ARGS[@]}" /path_to/train_external.py \
--train_batch_size 4 \
--max_steps 100 \
--hidden_width $HIDDEN_WIDTH \
--num_layers $NUM_LAYERS \
--num_heads $NUM_HEADS \
${LLAMA_ARGS} \
--shard_degree $SHARD_DEGREE \
--model_type $model_type \
--profile_nsys 1 \
--use_smp_implementation 1 \
--max_context_width 4096 \
--tensor_parallel_degree 1 \
--use_synthetic_data $use_synthetic_data \
--training_dir $TRAINING_DIR \
--test_dir $TEST_DIR \
--dataset_type hf \
--checkpoint_dir $CHECKPOINT_DIR \
--checkpoint_freq 100 \
$ sbatch launch_training_enroot.sh
```
*Pour trouver les exemples de code téléchargeables, voir [Exécuter une tâche d'entraînement parallèle à un modèle à l'aide de la bibliothèque de parallélisme de modèles SageMaker AI, Docker et Enroot with Slurm](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2#option-2----run-training-using-docker-and-enroot) dans le référentiel Awsome Distributed Training. GitHub * Pour plus d'informations sur l'entraînement distribué avec un cluster Slurm activé SageMaker HyperPod, passez à la rubrique suivante à l'adresse. [Exécution de charges de travail de formation distribuées avec Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)
# Exécution de charges de travail de formation distribuées avec Slurm on HyperPod
SageMaker HyperPod est spécialisé pour les charges de travail liées à la formation de grands modèles linguistiques (LLMs) et de modèles de base (FMs). Ces charges de travail nécessitent souvent l’utilisation de plusieurs techniques de parallélisme et d’opérations optimisées pour l’infrastructure et les ressources ML. En utilisant SageMaker HyperPod, vous pouvez utiliser les frameworks de formation distribués SageMaker basés sur l'IA suivants :
+ La [bibliothèque de parallélisme distribué des données (SMDDP) basée sur l'SageMaker IA](data-parallel.md) qui propose des opérations de communication collective optimisées pour. AWS
+ La [bibliothèque de parallélisme des modèles SageMaker AI (SMP)](model-parallel-v2.md) qui implémente diverses techniques de parallélisme des modèles.
**Topics**
+ [Utilisation de SMDDP sur un SageMaker HyperPod](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smddp)
+ [Utilisation du protocole SMP sur un cluster SageMaker HyperPod](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smp)
## Utilisation de SMDDP sur un SageMaker HyperPod
La [bibliothèque SMDDP](data-parallel.md) est une bibliothèque de communication collective qui améliore les performances de calcul lors de l’entraînement parallèle des données distribuées. La bibliothèque SMDDP fonctionne avec les cadres d’entraînement distribué open source suivants :
+ [PyTorchDistributed Data Parallel (DDP)](https://pytorch.org/docs/stable/notes/ddp.html)
+ [PyTorch parallélisme de données entièrement segmenté (FSDP)](https://pytorch.org/docs/stable/fsdp.html)
+ [DeepSpeed](https://github.com/microsoft/DeepSpeed)
+ [Mégatron- DeepSpeed](https://github.com/microsoft/Megatron-DeepSpeed)
La bibliothèque SMDDP prend en charge la surcharge de communication liée aux principales opérations de communication collective en proposant ce qui suit pour. SageMaker HyperPod
+ La bibliothèque propose des offres `AllGather` optimisées pour AWS. `AllGather`est une opération clé utilisée dans le cadre du sharded data parallel training, une technique de parallélisme de données économe en mémoire proposée par des bibliothèques populaires. Il s'agit notamment de la bibliothèque de parallélisme des modèles d' SageMaker IA (SMP), de DeepSpeed Zero Redundancy Optimizer (Zero) et de PyTorch Fully Sharded Data Parallelism (FSDP).
+ La bibliothèque optimise la node-to-node communication en utilisant pleinement l'infrastructure AWS réseau et la topologie d'instance SageMaker AI ML.
**Pour exécuter des exemples de tâches d’entraînement de parallélisme des données**
Explorez les exemples d’entraînement distribué suivants mettant en œuvre des techniques de parallélisme des données à l’aide de la bibliothèque SMDDP.
+ [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP)
+ [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed)
**Pour configurer un environnement d'utilisation de la bibliothèque SMDDP sur SageMaker HyperPod**
Vous trouverez ci-dessous les exigences relatives à l'environnement de formation pour utiliser la bibliothèque SMDDP sur. SageMaker HyperPod
+ PyTorch v2.0.1 et versions ultérieures
+ CUDA v11.8 et versions ultérieures
+ Version de l’environnement d’exécution `libstdc++` supérieure à 3
+ Python v3.10.x et versions ultérieures
+ `ml.p4d.24xlarge` et `ml.p4de.24xlarge`, qui sont des types d’instances pris en charge par la bibliothèque SMDDP
+ `imdsv2` activé sur l’hôte d’entraînement
Selon la manière dont vous souhaitez exécuter la tâche d’entraînement distribuée, deux options s’offrent à vous pour installer la bibliothèque SMDDP :
+ Installation directe à l’aide du fichier binaire SMDDP.
+ Utilisation des SageMaker AI Deep Learning Containers (DLCs) préinstallés avec la bibliothèque SMDDP.
Les images Docker préinstallées avec la bibliothèque SMDDP ou dans les fichiers binaires SMDDP sont répertoriées dans la section [Frameworks pris en charge](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks) dans la documentation de la bibliothèque SMDDP. URLs
**Pour installer la bibliothèque SMDDP sur le DLAMI SageMaker HyperPod**
+ `pip install --no-cache-dir https://smdataparallel.s3.amazonaws.com/binary/pytorch//cuXYZ/YYYY-MM-DD/smdistributed_dataparallel-X.Y.Z-cp310-cp310-linux_x86_64.whl`
**Note**
Si vous travaillez dans un environnement Conda, veillez à installer PyTorch en utilisant `conda install` plutôt que. `pip`
```
conda install pytorch==X.Y.Z torchvision==X.Y.Z torchaudio==X.Y.Z pytorch-cuda=X.Y.Z -c pytorch -c nvidia
```
**Pour utiliser la bibliothèque SMDDP sur un conteneur Docker**
+ La bibliothèque SMDDP est préinstallée sur les SageMaker AI Deep Learning Containers (). DLCs Pour trouver la liste des frameworks d' SageMaker IA compatibles PyTorch avec la bibliothèque SMDDP, consultez la section DLCs [Frameworks pris en charge](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks) dans la documentation de la bibliothèque SMDDP. Vous pouvez également apporter votre propre conteneur Docker avec les dépendances requises installées pour utiliser la bibliothèque SMDDP. Pour en savoir plus sur la configuration d’un conteneur Docker personnalisé pour utiliser la bibliothèque SMDDP, consultez également [Créez votre propre conteneur Docker avec la bibliothèque SageMaker AI distributed data parallel library](data-parallel-bring-your-own-container.md).
**Important**
Pour utiliser la bibliothèque SMDDP dans un conteneur Docker, montez le répertoire `/var/log` depuis la machine hôte sur `/var/log` dans le conteneur. Cela peut être fait en ajoutant l’option suivante lors de l’exécution de votre conteneur.
```
docker run -v /var/log:/var/log ...
```
Pour savoir comment exécuter des tâches d’entraînement de parallélisme des données avec SMDDP en général, consultez [Formation distribuée avec la bibliothèque de parallélisme de données distribué basée sur l' SageMaker IA](data-parallel-modify-sdp.md).
## Utilisation du protocole SMP sur un cluster SageMaker HyperPod
La [bibliothèque de parallélisme des modèles SageMaker AI (SMP)](model-parallel-v2.md) propose différentes techniques de [parallélisme des state-of-the-art modèles](model-parallel-core-features-v2.md), notamment :
+ parallélisme des données pleinement partitionnées
+ parallélisme expert
+ entraînement de précision mixte avec les types FP16/BF16 et de FP8 données
+ parallélisme de tenseur
La bibliothèque SMP est également compatible avec les frameworks open source tels que PyTorch FSDP, NVIDIA Megatron et NVIDIA Transformer Engine.
**Pour exécuter un exemple de charge de travail d’entraînement de parallélisme des modèles**
Les équipes du service d' SageMaker intelligence artificielle proposent des exemples de tâches de formation mettant en œuvre le parallélisme des modèles avec la bibliothèque SMP à l'adresse. [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2)
# SageMaker HyperPod surveillance des ressources du cluster
Pour obtenir une observabilité complète des ressources et des composants logiciels de votre SageMaker HyperPod cluster, intégrez le cluster à [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) et à [Amazon](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) Managed Grafana. L'intégration avec Amazon Managed Service for Prometheus permet d'exporter les métriques relatives aux ressources de HyperPod votre cluster, fournissant ainsi des informations sur leurs performances, leur utilisation et leur état de santé. L’intégration avec Amazon Managed Grafana permet de visualiser ces métriques via différents tableaux de bord Grafana, qui offrent une interface intuitive pour surveiller et analyser le comportement du cluster. En tirant parti de ces services, vous bénéficiez d'une vue centralisée et unifiée de votre HyperPod cluster, ce qui facilite la surveillance proactive, le dépannage et l'optimisation de vos charges de travail de formation distribuées.
**Astuce**
Pour trouver des exemples pratiques et des solutions, consultez également l'[SageMaker HyperPodatelier](https://catalog.workshops.aws/sagemaker-hyperpod).
![\[Présentation de la configuration SageMaker HyperPod avec Amazon Managed Service pour Prometheus et Amazon Managed Grafana.\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/images/hyperpod-observability-architecture.png)
Figure : Ce schéma d'architecture présente une vue d'ensemble de la configuration SageMaker HyperPod avec Amazon Managed Service for Prometheus et Amazon Managed Grafana.
Passez aux rubriques suivantes pour configurer l'observabilité SageMaker HyperPod du cluster.
**Topics**
+ [Conditions préalables à l'observabilité des SageMaker HyperPod clusters](sagemaker-hyperpod-cluster-observability-slurm-prerequisites.md)
+ [Installation de packages d'exportation de métriques sur votre HyperPod cluster](sagemaker-hyperpod-cluster-observability-slurm-install-exporters.md)
+ [Validation de la configuration de Prometheus sur le nœud principal d'un cluster HyperPod](sagemaker-hyperpod-cluster-observability-slurm-validate-prometheus-setup.md)
+ [Configuration d’un espace de travail Amazon Managed Grafana](sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws.md)
+ [Référence des métriques exportées](sagemaker-hyperpod-cluster-observability-slurm-exported-metrics-reference.md)
+ [Statistiques Amazon SageMaker HyperPod Slurm](smcluster-slurm-metrics.md)
# Conditions préalables à l'observabilité des SageMaker HyperPod clusters
Avant de passer aux étapes d’[Installation de packages d'exportation de métriques sur votre HyperPod cluster](sagemaker-hyperpod-cluster-observability-slurm-install-exporters.md), assurez-vous de respecter les conditions préalables suivantes.
## Activer IAM Identity Center
Pour activer l'observabilité de votre SageMaker HyperPod cluster, vous devez d'abord activer IAM Identity Center. Il s'agit d'une condition préalable au déploiement d'une CloudFormation pile qui configure l'espace de travail Amazon Managed Grafana et Amazon Managed Service pour Prometheus. Ces deux services nécessitent également IAM Identity Center pour l’authentification et l’autorisation, afin de garantir un accès utilisateur sécurisé et la gestion de l’infrastructure de surveillance.
Pour obtenir des instructions détaillées sur l’activation d’IAM Identity Center, consultez la section [Activation d’IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html) dans le *Guide de l’utilisateur AWS IAM Identity Center*.
Après avoir activé IAM Identity Center avec succès, configurez un compte d’utilisateur qui servira d’utilisateur administratif dans toutes les procédures de configuration suivantes.
## Créez et déployez une CloudFormation pile pour l' SageMaker HyperPod observabilité
Créez et déployez une CloudFormation pile d' SageMaker HyperPod observabilité afin de surveiller les métriques du HyperPod cluster en temps réel à l'aide d'Amazon Managed Service pour Prometheus et d'Amazon Managed Grafana. Pour déployer la pile, notez que vous devez également activer [IAM Identity Center](https://console.aws.amazon.com/singlesignon) au préalable.
Utilisez l'exemple de CloudFormation script [https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/4.prometheus-grafana/cluster-observability.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/4.prometheus-grafana/cluster-observability.yaml)qui vous aide à configurer les sous-réseaux Amazon VPC, les systèmes de fichiers Amazon FSx for Lustre, les compartiments Amazon S3 et les rôles IAM nécessaires à la création d'une pile d'observabilité de cluster. HyperPod
# Installation de packages d'exportation de métriques sur votre HyperPod cluster
Dans la [configuration de base, les scripts de cycle](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) de vie fournis par l' SageMaker HyperPod équipe incluent également l'installation de divers packages d'exportation de métriques. Pour activer l’étape d’installation, il vous suffit de définir le paramètre `enable_observability=True` dans le fichier [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py). Les scripts de cycle de vie sont conçus pour amorcer votre cluster avec les packages de l’exportateur de métriques open source suivants.
| | | |
| --- |--- |--- |
| Nom | Nœud cible de déploiement des scripts | Description de l’exportateur |
| [Exportateur Slurm pour Prometheus](https://github.com/vpenso/prometheus-slurm-exporter) | Nœud principal (contrôleur) | Exporte les métriques de comptabilité Slurm. |
| [Exportateur de nœuds Elastic Fabric Adapter (EFA)](https://github.com/aws-samples/awsome-distributed-training/tree/main/4.validation_and_observability/3.efa-node-exporter) | Nœud de calcul | Exporte les métriques à partir des nœuds du cluster et EFA. Le package est une duplication de l’[exportateur de nœuds Prometheus](https://github.com/prometheus/node_exporter). |
| [Exportateur NVIDIA Data Center GPU Management (DCGM)](https://github.com/NVIDIA/dcgm-exporter) | Nœud de calcul | Exporte les métriques NVIDIA DCGM relatives à l'état de santé et aux performances de NVIDIA GPUs. |
Avec `enable_observability=True` dans le fichier [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py), l’étape d’installation suivante est activée dans le script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py).
```
# Install metric exporting software and Prometheus for observability
if Config.enable_observability:
if node_type == SlurmNodeType.COMPUTE_NODE:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()
if node_type == SlurmNodeType.HEAD_NODE:
wait_for_scontrol()
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
ExecuteBashScript("./utils/install_prometheus.sh").run()
```
Sur les nœuds de calcul, le script installe l’exportateur NVIDIA Data Center GPU Management (DCGM) et l’exportateur de nœuds Elastic Fabric Adapter (EFA). L'exportateur DCGM est un exportateur pour Prometheus qui collecte des métriques auprès de GPUs NVIDIA, permettant de surveiller l'utilisation, les performances et l'état du GPU. L’exportateur de nœuds EFA, quant à lui, collecte les métriques relatives à l’interface réseau EFA, essentielles pour les communications à faible latence et à bande passante élevée dans les clusters HPC.
Sur le nœud principal, le script installe l’exportateur Slurm pour Prometheus et le [logiciel open source Prometheus](https://prometheus.io/docs/introduction/overview/). L’exportateur Slurm fournit à Prometheus les métriques relatives aux tâches, aux partitions et à l’état des nœuds de Slurm.
Notez que les scripts de cycle de vie sont conçus pour installer tous les packages de l’exportateur en tant que conteneurs Docker, de sorte que le package Docker doit également être installé à la fois sur le nœud principal et sur les nœuds de calcul. Les scripts de ces composants sont facilement fournis dans le [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils)dossier du * GitHub référentiel Awsome Distributed Training*.
Une fois que vous avez correctement configuré votre HyperPod cluster installé avec les packages d'exportation, passez à la rubrique suivante pour terminer la configuration d'Amazon Managed Service pour Prometheus et Amazon Managed Grafana.
# Validation de la configuration de Prometheus sur le nœud principal d'un cluster HyperPod
Après avoir correctement configuré votre HyperPod cluster installé avec les packages d'exportation, vérifiez si Prometheus est correctement configuré sur le nœud principal de votre cluster. HyperPod
1. Connectez-vous au nœud principal de votre cluster. Pour obtenir des instructions sur la façon d’accéder à un nœud, consultez [Accès aux nœuds SageMaker HyperPod de votre cluster](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md).
1. Exécutez la commande suivante pour vérifier que le fichier de configuration et de service de Prometheus, créé par le script de cycle de vie `install_prometheus.sh`, est exécuté sur le nœud de contrôleur. La sortie doit afficher le statut Actif sous la forme **active (running)**.
```
$ sudo systemctl status prometheus
• prometheus service - Prometheus Exporter
Loaded: loaded (/etc/systemd/system/prometheus.service; enabled; preset:disabled)
Active: active (running) since DAY YYYY-MM-DD HH:MM:SS UTC; Ss ago
Main PID: 12345 (prometheus)
Tasks: 7 (limit: 9281)
Memory: 35M
CPU: 234ms
CGroup: /system.slice/prometheus.service
-12345 /usr/bin/prometheus--config.file=/etc/prometheus/prometheus.yml
```
1. Validez le fichier de configuration de Prometheus comme suit. La sortie doit être similaire à la suivante, avec trois exportateurs configurés avec les bonnes adresses IP des nœuds de calcul.
```
$ cat /etc/prometheus/prometheus.yml
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_timeout: 15s
scrape_configs:
- job_name: 'slurm_exporter'
static_configs:
- targets:
- 'localhost:8080'
- job_name: 'dcgm_exporter'
static_configs:
- targets:
- ':9400'
- ':9400'
- job_name: 'efa_node_exporter'
static_configs:
- targets:
- ':9100'
- ':9100'
remote_write:
- url:
queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500
sigv4:
region:
```
1. Pour vérifier si Prometheus exporte correctement les métriques Slurm, DCGM et EFA, exécutez la commande `curl` suivante pour Prometheus sur le port `:9090` du nœud principal.
```
$ curl -s http://localhost:9090/metrics | grep -E 'slurm|dcgm|efa'
```
Les métriques étant exportées vers l’espace de travail Service géré Amazon pour Prometheus via la configuration d’écriture à distance de Prometheus depuis le nœud de contrôleur, vous pouvez passer à la rubrique suivante pour configurer les tableaux de bord Amazon Managed Grafana afin d’afficher ces métriques.
# Configuration d’un espace de travail Amazon Managed Grafana
Créez un nouvel espace de travail Amazon Managed Grafana ou mettez à jour un espace de travail Amazon Managed Grafana existant avec le service géré Amazon pour Prometheus comme source de données.
**Topics**
+ [Création d’un espace de travail Grafana et définition du service géré Amazon pour Prometheus en tant que source de données.](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-create)
+ [Ouverture de l’espace de travail Grafana et achèvement de la configuration de la source de données](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-connect-data-source)
+ [Importation de tableaux de bord Grafana open source](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-import-dashboards)
## Création d’un espace de travail Grafana et définition du service géré Amazon pour Prometheus en tant que source de données.
Pour visualiser les métriques provenant du service géré Amazon pour Prometheus, créez un espace de travail Amazon Managed Grafana et configurez-le pour utiliser le service géré Amazon pour Prometheus comme source de données.
1. Pour créer un espace de travail Grafana, suivez les instructions fournies dans [Création d’un espace de travail](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-create-workspace.html#creating-workspace), dans le *Guide de l’utilisateur du service géré Amazon pour Prometheus*.
1. À l’étape 13, sélectionnez le service géré Amazon pour Prometheus comme source de données.
1. À l’étape 17, vous pouvez ajouter l’utilisateur administrateur ainsi que d’autres utilisateurs dans IAM Identity Center.
Pour plus d’informations, consultez également les ressources suivantes.
+ [Configuration d’Amazon Managed Grafana pour une utilisation avec le service géré Amazon pour Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-amg.html) dans le *Guide de l’utilisateur du service géré Amazon pour Prometheus*
+ [Utilisez la configuration de la source de AWS données pour ajouter Amazon Managed Service for Prometheus en tant que source de données dans le guide de l'utilisateur d'](https://docs.aws.amazon.com/grafana/latest/userguide/AMP-adding-AWS-config.html)*Amazon Managed Grafana*
## Ouverture de l’espace de travail Grafana et achèvement de la configuration de la source de données
Après avoir créé ou mis à jour avec succès un espace de travail Amazon Managed Grafana, sélectionnez l’URL de l’espace de travail pour ouvrir l’espace de travail. Vous êtes alors invité à saisir un nom d’utilisateur et le mot de passe de l’utilisateur que vous avez configuré dans IAM Identity Center. Vous devez vous connecter en utilisant l’utilisateur administrateur pour finir de configurer l’espace de travail.
1. Sur la page d’**accueil** de l’espace de travail, choisissez **Applications**, **Sources de données AWS ** et **Sources de données**.
1. Sur la page **Sources de données**, choisissez l’onglet **Sources de données**.
1. Pour **Service**, choisissez Service géré Amazon pour Prometheus.
1. Dans la section **Parcourir et approvisionner les sources de données**, choisissez la AWS région dans laquelle vous avez fourni un espace de travail Amazon Managed Service pour Prometheus.
1. Dans la liste des sources de données de la région sélectionnée, choisissez celle correspondant au service géré Amazon pour Prometheus. Assurez-vous de vérifier l'ID de ressource et l'alias de ressource de l'espace de travail Amazon Managed Service for Prometheus que vous avez configuré HyperPod pour la pile d'observabilité.
## Importation de tableaux de bord Grafana open source
Après avoir configuré avec succès votre espace de travail Amazon Managed Grafana avec le service géré Amazon pour Prometheus comme source de données, vous commencerez à collecter les métriques relatives à Prometheus, puis vous devriez commencer à voir les différents tableaux de bord contenant des graphiques, des informations, etc. Le logiciel open source Grafana fournit différents tableaux de bord, que vous pouvez importer dans Amazon Managed Grafana.
**Pour importer des tableaux de bord Grafana open source dans Amazon Managed Grafana**
1. Sur la page d’**accueil** de votre espace de travail Amazon Managed Grafana, choisissez **Tableaux de bord**.
1. Cliquez sur le bouton du menu déroulant avec le texte d’interface utilisateur **Nouveau** et sélectionnez **Importer**.
1. Collez l’URL dans le [tableau de bord Slurm](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/).
```
https://grafana.com/grafana/dashboards/4323-slurm-dashboard/
```
1. Sélectionnez **Charger**.
1. Répétez les étapes précédentes pour importer les tableaux de bord suivants.
1. [Tableau de bord Node Exporter Full](https://grafana.com/grafana/dashboards/1860-node-exporter-full/)
```
https://grafana.com/grafana/dashboards/1860-node-exporter-full/
```
1. [Tableau de bord de l’exportateur NVIDIA DCGM](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/)
```
https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/
```
1. [Tableau de bord des métriques EFA](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/)
```
https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/
```
1. [FSx pour le tableau de bord Lustre Metrics](https://grafana.com/grafana/dashboards/20906-fsx-lustre/)
```
https://grafana.com/grafana/dashboards/20906-fsx-lustre/
```
# Référence des métriques exportées
Les sections suivantes présentent des listes complètes de métriques exportées depuis SageMaker HyperPod Amazon Managed Service for Prometheus après la configuration réussie de la pile à des fins d'observabilité CloudFormation . SageMaker HyperPod Vous pouvez commencer à surveiller ces métriques visualisées dans les tableaux de bord d’Amazon Managed Grafana.
## Tableau de bord de l’exportateur Slurm
Fournit des informations visualisées sur les clusters Slurm sur. SageMaker HyperPod
**Types de métriques**
+ **Vue d’ensemble du cluster :** affichage du nombre total de nœuds, des tâches et de leurs états.
+ **Métriques relatives aux tâches :** visualisation du nombre de tâches et de leurs états au fil du temps.
+ **Métriques des nœuds :** affichage de l’état des nœuds, de leur allocation et des ressources disponibles.
+ **Métriques de partition :** surveillance des métriques spécifiques aux partitions, telles que l’utilisation du processeur, de la mémoire et du GPU.
+ **Efficacité du travail :** calcul de l’efficacité des tâches en fonction des ressources utilisées.
**Liste des métriques**
| Nom des métriques | Description |
| --- | --- |
| slurm\$1job\$1count | Nombre total de tâches dans le cluster Slurm |
| slurm\$1job\$1state\$1count | Nombre de tâches dans chaque état (p. ex., en cours, en attente, terminées) |
| slurm\$1node\$1count | Nombre total de nœuds dans le cluster Slurm |
| slurm\$1node\$1state\$1count | Nombre de nœuds dans chaque état (p. ex., inactif, alloc, mix) |
| slurm\$1partition\$1node\$1count | Nombre de nœuds dans chaque partition |
| slurm\$1partition\$1job\$1count | Nombre de tâches dans chaque partition |
| slurm\$1partition\$1alloc\$1cpus | Nombre total de personnes allouées CPUs dans chaque partition |
| slurm\$1partition\$1free\$1cpus | Nombre total de disques disponibles CPUs dans chaque partition |
| slurm\$1partition\$1alloc\$1memory | Mémoire allouée totale dans chaque partition |
| slurm\$1partition\$1free\$1memory | Mémoire disponible totale dans chaque partition |
| slurm\$1partition\$1alloc\$1gpus | Total alloué GPUs dans chaque partition |
| slurm\$1partition\$1free\$1gpus | Total disponible GPUs dans chaque partition |
## Tableau de bord de l’exportateur de nœuds
Fournit des informations visualisées sur les métriques du système collectées par l'exportateur de nœuds [Prometheus à partir des nœuds du cluster](https://github.com/prometheus/node_exporter). HyperPod
**Types de métriques**
+ **Vue d’ensemble du système :** affichage des moyennes de charge du processeur et de l’utilisation de la mémoire.
+ **Métriques de la mémoire :** visualisation de l’utilisation de la mémoire, notamment de la mémoire totale, de la mémoire disponible et de l’espace d’échange.
+ **Utilisation du disque :** surveillance de l’utilisation et de la disponibilité de l’espace disque.
+ **Trafic réseau :** affichage des octets réseau reçus et transmis au fil du temps.
+ **Métriques du système de fichiers :** analyse de l’utilisation et de la disponibilité du système de fichiers.
+ ** I/O Métriques du disque :** visualisation de l'activité de lecture et d'écriture sur le disque.
**Liste des métriques**
Pour une liste complète des métriques exportées, consultez les GitHub référentiels [Node Exporter](https://github.com/prometheus/node_exporter?tab=readme-ov-file#enabled-by-default) et [procfs](https://github.com/prometheus/procfs?tab=readme-ov-file). Le tableau suivant présente un sous-ensemble des métriques qui fournit des informations sur l’utilisation des ressources du système, telles que la charge du processeur, l’utilisation de la mémoire, l’espace disque et l’activité réseau.
| Nom des métriques | Description |
| --- | --- |
| node\$1load1 | Moyenne de charge sur 1 minute |
| node\$1load5 | Moyenne de charge sur 5 minutes |
| node\$1load15 | Moyenne de charge sur 15 minutes |
| node\$1memory\$1MemTotal | Mémoire système totale |
| node\$1memory\$1MemFree | Mémoire système disponible |
| node\$1memory\$1MemAvailable | Mémoire disponible à allouer aux processus |
| node\$1memory\$1Buffers | Mémoire utilisée par le noyau pour la mise en mémoire tampon |
| node\$1memory\$1Cached | Mémoire utilisée par le noyau pour la mise en cache des données du système de fichiers |
| node\$1memory\$1SwapTotal | Espace d’échange total disponible |
| node\$1memory\$1SwapFree | Espace d’échange disponible |
| node\$1memory\$1SwapCached | Mémoire qui, une fois échangée, est rééchangée mais toujours en échange |
| node\$1filesystem\$1avail\$1bytes | Espace disque disponible en octets |
| node\$1filesystem\$1size\$1bytes | Espace disque total en octets |
| node\$1filesystem\$1free\$1bytes | Espace disque disponible en octets |
| node\$1network\$1receive\$1bytes | Octets réseau reçus |
| node\$1network\$1transmit\$1bytes | Octets réseau transmis |
| node\$1disk\$1read\$1bytes | Octets de disque lus |
| node\$1disk\$1written\$1bytes | Octets de disque écrits |
## Tableau de bord de l’exportateur NVIDIA DCGM
Fournit des informations visualisées sur les métriques des GPU NVIDIA, collectées par l’[exportateur NVIDIA DCGM](https://github.com/NVIDIA/dcgm-exporter).
**Types de métriques**
+ **Vue d’ensemble des GPU :** affichage de l’utilisation, des températures, de la consommation d’énergie et de l’utilisation de la mémoire des GPU.
+ **Métriques de température :** visualisation des températures des GPU au fil du temps.
+ **Consommation d’énergie :** surveillance de la consommation d’énergie des GPU et des tendances en matière de consommation d’énergie.
+ **Utilisation de la mémoire :** analyse de l’utilisation de la mémoire des GPU, y compris la mémoire utilisée, la mémoire disponible et la mémoire totale.
+ **Vitesse des ventilateurs :** affichage des vitesses et des variations des ventilateurs des GPU.
+ **Erreurs ECC :** suivi des erreurs ECC de la mémoire des GPU et des erreurs en attente.
**Liste des métriques**
Le tableau suivant présente la liste des métriques qui fournissent des informations sur l’intégrité et les performances des GPU NVIDIA, notamment les fréquences d’horloge, les températures, la consommation d’énergie, l’utilisation de la mémoire, les vitesses des ventilateurs et les métriques d’erreur.
| Nom des métriques | Description |
| --- | --- |
| DCGM\$1FI\$1DEV\$1SM\$1CLOCK | Fréquence d'horloge SM (in MHz) |
| DCGM\$1FI\$1DEV\$1MEM\$1CLOCK | Fréquence de l'horloge de la mémoire (in MHz) |
| DCGM\$1FI\$1DEV\$1MEMORY\$1TEMP | Température de la mémoire (en °C) |
| DCGM\$1FI\$1DEV\$1GPU\$1TEMP | Température du GPU (en °C) |
| DCGM\$1FI\$1DEV\$1POWER\$1USAGE | Consommation électrique (en W) |
| DCGM\$1FI\$1DEV\$1TOTAL\$1ENERGY\$1CONSUMPTION | Consommation d’énergie totale depuis le démarrage (en mJ) |
| DCGM\$1FI\$1DEV\$1PCIE\$1REPLAY\$1COUNTER | Nombre total de PCIe tentatives |
| DCGM\$1FI\$1DEV\$1MEM\$1COPY\$1UTIL | Utilisation de la mémoire (en %) |
| DCGM\$1FI\$1DEV\$1ENC\$1UTIL | Utilisation de l’encodeur (en %) |
| DCGM\$1FI\$1DEV\$1DEC\$1UTIL | Utilisation du décodeur (en %) |
| DCGM\$1FI\$1DEV\$1XID\$1ERRORS | Valeur de la dernière erreur XID rencontrée |
| DCGM\$1FI\$1DEV\$1FB\$1FREE | Mémoire tampon d’images disponible (en Mio) |
| DCGM\$1FI\$1DEV\$1FB\$1USED | Mémoire tampon d’images utilisée (en Mio) |
| DCGM\$1FI\$1DEV\$1NVLINK\$1BANDWIDTH\$1TOTAL | Nombre total de compteurs de NVLink bande passante pour toutes les voies |
| DCGM\$1FI\$1DEV\$1VGPU\$1LICENSE\$1STATUS | Statut de la licence vGPU |
| DCGM\$1FI\$1DEV\$1UNCORRECTABLE\$1REMAPPED\$1ROWS | Nombre de lignes remappées pour les erreurs non corrigeables |
| DCGM\$1FI\$1DEV\$1CORRECTABLE\$1REMAPPED\$1ROWS | Nombre de lignes remappées pour les erreurs corrigeables |
| DCGM\$1FI\$1DEV\$1ROW\$1REMAP\$1FAILURE | Si le remappage des lignes a échoué |
## Tableau de bord des métriques EFA
Fournit des informations visualisées sur les métriques provenant d’[Amazon Elastic Fabric Adapter (EFA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) équipé d’instances P collectées par l’[exportateur de nœuds EFA](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md).
**Types de métriques**
+ **Métriques d’erreur EFA :** visualisation des erreurs telles que les erreurs d’allocation, les erreurs de commande et les erreurs de mappage mémoire.
+ **Trafic réseau EFA :** surveillance des octets, des paquets et des demandes de travail reçus et transmis.
+ **Performances EFA RDMA :** analyse des opérations de lecture et d’écriture RDMA, y compris des octets transférés et des taux d’erreur.
+ **Durée de vie des ports EFA :** affichage de la durée de vie des ports EFA au fil du temps.
+ **Paquets EFA keep-alive :** suivi du nombre de paquets keep-alive reçus.
**Liste des métriques**
Le tableau suivant présente la liste des métriques qui fournissent des informations sur divers aspects du fonctionnement de l’EFA, notamment les erreurs, les commandes terminées, le trafic réseau et l’utilisation des ressources.
| Nom des métriques | Description |
| --- | --- |
| node\$1amazonefa\$1info | Données non numériques provenant de/sys/class/infiniband/, la valeur est toujours 1. |
| node\$1amazonefa\$1lifespan | Durée de vie du port |
| node\$1amazonefa\$1rdma\$1read\$1bytes | Nombre d’octets lus avec RDMA |
| node\$1amazonefa\$1rdma\$1read\$1resp\$1bytes | Nombre d’octets de réponse de lecture avec RDMA |
| node\$1amazonefa\$1rdma\$1read\$1wr\$1err | Nombre d’erreurs de lecture et d’écriture avec RDMA |
| node\$1amazonefa\$1rdma\$1read\$1wrs | Nombre de rs lus avec RDMA |
| node\$1amazonefa\$1rdma\$1write\$1bytes | Nombre d’octets écrits avec RDMA |
| node\$1amazonefa\$1rdma\$1write\$1recv\$1bytes | Nombre d’octets écrits et reçus avec RDMA |
| node\$1amazonefa\$1rdma\$1write\$1wr\$1err | Nombre d’octets écrits avec une erreur RDMA |
| node\$1amazonefa\$1rdma\$1write\$1wrs | Nombre d’octets écrits wrs RDMA |
| node\$1amazonefa\$1recv\$1bytes | Nombre d’octets reçus |
| node\$1amazonefa\$1recv\$1wrs | Nombre d’octets reçus wrs |
| node\$1amazonefa\$1rx\$1bytes | Nombre d’octets reçus |
| node\$1amazonefa\$1rx\$1drops | Nombre de paquets abandonnés |
| node\$1amazonefa\$1rx\$1pkts | Nombre de paquets reçus |
| node\$1amazonefa\$1send\$1bytes | Nombre d’octets envoyés |
| node\$1amazonefa\$1send\$1wrs | Nombre de wrs envoyés |
| node\$1amazonefa\$1tx\$1bytes | Nombre d’octets transmis |
| node\$1amazonefa\$1tx\$1pkts | Nombre de paquets transmis |
## FSx pour le tableau de bord des métriques Lustre
Fournit des informations visualisées sur les [métriques du système de fichiers Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/monitoring-cloudwatch.html) collectées par [Amazon CloudWatch](https://docs.aws.amazon.com/fsx/latest/LustreGuide/monitoring-cloudwatch.html).
**Note**
Le tableau de bord Grafana FSx for Lustre utilise CloudWatch Amazon comme source de données, ce qui est différent des autres tableaux de bord que vous avez configurés pour utiliser Amazon Managed Service for Prometheus. Pour garantir une surveillance et une visualisation précises des métriques relatives à votre système de fichiers FSx for Lustre, configurez le tableau de bord FSx for Lustre pour utiliser Amazon CloudWatch comme source de données, en spécifiant le même Région AWS endroit où votre système de fichiers FSx for Lustre est déployé.
**Types de métriques**
+ **DataReadBytes:** nombre d'octets pour les opérations de lecture du système de fichiers.
+ **DataWriteBytes:** nombre d'octets pour les opérations d'écriture dans le système de fichiers.
+ **DataReadOperations:** le nombre d'opérations de lecture.
+ **DataWriteOperations:** le nombre d'opérations d'écriture.
+ **MetadataOperations:** le nombre d'opérations sur les métadonnées.
+ **FreeDataStorageCapacity:** quantité de capacité de stockage disponible.
# Statistiques Amazon SageMaker HyperPod Slurm
Amazon SageMaker HyperPod fournit un ensemble de CloudWatch métriques Amazon que vous pouvez utiliser pour surveiller l'état et les performances de vos HyperPod clusters. Ces métriques sont collectées à partir du gestionnaire de charge de travail Slurm exécuté sur vos HyperPod clusters et sont disponibles dans l'`/aws/sagemaker/Clusters` CloudWatch espace de noms.
## Métriques de niveau cluster
Les métriques suivantes au niveau du cluster sont disponibles pour. HyperPod Ces métriques utilisent la `ClusterId` dimension pour identifier le HyperPod cluster spécifique.
| CloudWatch nom de la métrique | Remarques | Nom de la métrique Container Insights pour Amazon EKS |
| --- | --- | --- |
| cluster\$1node\$1count | Nombre total de nœuds dans le cluster | cluster\$1node\$1count |
| cluster\$1idle\$1node\$1count | Nombre de nœuds inactifs dans le cluster | N/A |
| cluster\$1failed\$1node\$1count | Nombre de nœuds défaillants dans le cluster | cluster\$1failed\$1node\$1count |
| cluster\$1cpu\$1count | Nombre total de cœurs de processeur dans le cluster | node\$1cpu\$1limit |
| cluster\$1idle\$1cpu\$1count | Nombre de cœurs de processeur inactifs dans le cluster | N/A |
| cluster\$1gpu\$1count | Total GPUs dans le cluster | node\$1gpu\$1limit |
| cluster\$1idle\$1gpu\$1count | Nombre de périodes inactives GPUs dans le cluster | N/A |
| cluster\$1running\$1task\$1count | Nombre de tâches Slurm en cours d’exécution dans le cluster | N/A |
| cluster\$1pending\$1task\$1count | Nombre de tâches Slurm en attente dans le cluster | N/A |
| cluster\$1preempted\$1task\$1count | Nombre de tâches Slurm préemptées dans le cluster | N/A |
| cluster\$1avg\$1task\$1wait\$1time | Temps d’attente moyen pour les tâches Slurm dans le cluster | N/A |
| cluster\$1max\$1task\$1wait\$1time | Temps d’attente maximal pour les tâches Slurm dans le cluster | N/A |
## Métriques de niveau instance
Les métriques suivantes au niveau de l'instance sont disponibles pour. HyperPod Ces métriques utilisent également la `ClusterId` dimension pour identifier le HyperPod cluster spécifique.
| CloudWatch nom de la métrique | Remarques | Nom de la métrique Container Insights pour Amazon EKS |
| --- | --- | --- |
| node\$1gpu\$1utilization | Utilisation moyenne des GPU sur toutes les instances | node\$1gpu\$1utilization |
| node\$1gpu\$1memory\$1utilization | Utilisation moyenne de la mémoire par les GPU sur toutes les instances | node\$1gpu\$1memory\$1utilization |
| node\$1cpu\$1utilization | Utilisation moyenne du processeur sur toutes les instances | node\$1cpu\$1utilization |
| node\$1memory\$1utilization | Utilisation moyenne de la mémoire sur toutes les instances | node\$1memory\$1utilization |
# SageMaker HyperPod résilience du cluster
SageMaker HyperPod via Slurm Orchestration fournit les fonctionnalités de résilience des clusters suivantes.
**Topics**
+ [Agent de surveillance de la santé](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md)
+ [Restauration automatique des nœuds et reprise automatique](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)
+ [Remplacez ou redémarrez manuellement un nœud à l'aide de Slurm](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md)
# Agent de surveillance de la santé
Cette section décrit l'ensemble des contrôles de santé SageMaker HyperPod utilisés pour surveiller régulièrement l'état des instances de cluster afin de détecter des problèmes liés à des appareils tels que les accélérateurs (GPU et cœurs Trainium) et le réseau (EFA). SageMaker HyperPod un agent de surveillance de l'état de santé (HMA) surveille en permanence l'état de santé de chaque instance basée sur un GPU ou Trainium. Lorsqu’il détecte une défaillance d’instance ou de GPU, l’agent marque l’instance comme étant défectueuse.
SageMaker HyperPod HMA effectue les mêmes contrôles de santé pour les orchestrateurs EKS et Slurm. Pour plus d'informations sur le HMA, consultez[Système de surveillance de la santé](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md).
# Restauration automatique des nœuds et reprise automatique
**Note**
Depuis le 11 septembre 2025, HyperPod avec Slurm, l'orchestration prend désormais en charge les agents de surveillance de la santé. Exécutez [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)et mettez à jour la dernière version de l'AMI afin d'utiliser cette fonctionnalité.
Cette section décrit les deux fonctionnalités SageMaker HyperPod de résilience complémentaires d'Amazon : la restauration automatique des nœuds qui remplace l'infrastructure défectueuse sans intervention manuelle, et la fonctionnalité de reprise automatique qui redémarre les tâches de formation depuis le dernier point de contrôle après une panne matérielle.
## Comment fonctionne la restauration automatique des nœuds
Lors de la création ou de la mise à jour du cluster, les utilisateurs administrateurs du cluster peuvent sélectionner l’option de récupération des nœuds (instances) entre `Automatic` (recommandé) et `None` au niveau du cluster. S'il est défini sur`Automatic`, SageMaker HyperPod redémarre ou remplace automatiquement les nœuds défectueux.
**Important**
Nous vous recommandons de définir l’option `Automatic`. Par défaut, les clusters sont configurés avec la restauration automatique des nœuds.
La récupération automatique des nœuds s’exécute lorsque des problèmes sont détectés via un agent de surveillance de l’état, des vérifications de surveillance de l’état de base et des vérifications de surveillance approfondie de l’état. Si elle est définie sur `None`, l’agent de surveillance de l’état étiquette les instances lorsqu’une défaillance est détectée, mais il ne lance aucune action de réparation ou de récupération automatique sur les nœuds affectés. Nous ne recommandons pas cette option.
## Exécution d'une tâche de formation avec la fonctionnalité de SageMaker HyperPod reprise automatique d'Amazon
Cette section décrit comment exécuter une tâche de formation à l'aide de la fonctionnalité de SageMaker HyperPod reprise automatique, qui fournit une infrastructure de résilience sans intervention permettant de récupérer automatiquement une tâche de formation depuis le dernier point de contrôle enregistré en cas de panne matérielle.
Grâce à la fonctionnalité de reprise automatique, si une tâche échoue en raison d'une panne matérielle ou d'un problème temporaire entre les sessions de formation, la SageMaker HyperPod reprise automatique lance le flux de travail de remplacement des nœuds et redémarre la tâche une fois les nœuds défectueux remplacés. Les vérifications matérielles suivantes sont exécutées chaque fois qu'une tâche échoue lors de l'utilisation de la reprise automatique :
| Catégorie | Nom de l’utilitaire | Compatibilité des types d’instance | Description |
| --- | --- | --- | --- |
| Accélérateur | NVIDIA SMI | GPU | [L'utilitaire nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) est une CLI bien connue pour gérer et surveiller. GPUs L’outil intégré de surveillance de l’état analyse la sortie de nvidia-smi pour déterminer l’intégrité de l’instance. |
| Accélérateur | Neuron sysfs | Trainium | Pour les instances alimentées par Trainium, l’état des appareils Neuron est déterminé en lisant les compteurs de [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) propagés directement par le pilote Neuron. |
| Réseau | EFA | GPU et Trainium | Pour faciliter le diagnostic des appareils Elastic Fabric Adaptor (EFA), l’outil de surveillance de l’état EFA exécute une série de tests de connectivité en utilisant toutes les cartes EFA disponibles au sein de l’instance. |
**Note**
Lorsque des [ressources génériques (GRES)](https://slurm.schedmd.com/gres.html) sont attachées à un nœud Slurm, Slurm n’autorise généralement pas les modifications de l’allocation des nœuds, telles que le remplacement de nœuds, et n’autorise donc pas la reprise d’une tâche ayant échoué. Sauf interdiction explicite, la fonctionnalité de HyperPod reprise automatique met automatiquement en file d'attente toute tâche défectueuse associée aux nœuds compatibles GRES. Ce processus implique d’arrêter la tâche, de la replacer dans la file d’attente des tâches, puis de la redémarrer au début.
**Utilisation de la fonctionnalité de SageMaker HyperPod reprise automatique avec Slurm**
Lorsque vous utilisez la SageMaker HyperPod reprise automatique avec Slurm, vous devez exécuter le travail dans le cadre d'une allocation exclusive acquise soit en utilisant soit. `salloc` `sbatch` Dans tous les cas, vous devez modifier le script de point d’entrée pour vous assurer que toutes les étapes de configuration s’exécutent dans une seule commande `srun` lors de la reprise de la tâche. À l’aide du script de point d’entrée, il est important de configurer l’environnement sur le nœud remplacé de manière à ce qu’il soit cohérent avec l’environnement dans lequel l’étape de la tâche s’exécutait avant d’être arrêtée. La procédure suivante montre comment préparer un script de point d'entrée pour garantir la cohérence de l'environnement et l'exécuter en tant que commande unique`srun`.
**Astuce**
Si vous utilisez `sbatch`, vous pouvez simplifier le script de commande en créant un script distinct pour configurer l’environnement et en utilisant une seule commande `srun`.
1. Créez un script à l’aide de l’exemple de code suivant et enregistrez-le sous `train_auto_resume.sh`. Ce script déploie les configurations de l’environnement d’entraînement en supposant qu’aucune configuration manuelle n’a été précédemment effectuée sur le nœud remplacé. Cela garantit que l’environnement est ignorant du nœud, de sorte que lorsqu’un nœud est remplacé, le même environnement est provisionné sur le nœud avant de reprendre la tâche.
**Note**
L’exemple de code suivant montre comment découvrir la liste des nœuds Slurm associée à la tâche. N'utilisez pas la variable d'`$SLURM_JOB_NODELIST`environnement fournie par Slurm, car sa valeur risque d'être obsolète après la SageMaker HyperPod reprise automatique du travail. L’exemple de code suivant montre comment définir une nouvelle variable `NODE_LIST` pour remplacer `SLURM_JOB_NODELIST`, puis configurer les variables `MASTER_NODE` et `MASTER_ADDR` hors de la variable `NODE_LIST`.
```
#!/bin/bash
# Filename: train_auto_resume.sh
# Sample containerized script to launch a training job with a single srun which can be auto-resumed.
# Place your training environment setup here.
# Example: Install conda, docker, activate virtual env, etc.
# Get the list of nodes for a given job
NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job
awk -F= '/NodeList=/{print $2}' | \ # Extract NodeList field
grep -v Exc) # Exclude nodes marked as excluded
# Determine the master node from the node list
MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames
head -n 1) # Select the first hostname as master node
# Get the master node address
MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information
awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr
awk '{print $1}') # Print the first part of NodeAddr
# Torchrun command to launch the training job
torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \
--nproc_per_node=1 \
--node_rank=$SLURM_NODE \
--master-addr=$MASTER_ADDR \
--master_port=1234 \
"
# Execute the torchrun command in the 'pytorch' Conda environment,
# streaming output live
/opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd
```
**Astuce**
Vous pouvez utiliser le script précédent pour ajouter des commandes supplémentaires afin d’installer des dépendances supplémentaires pour votre tâche. Toutefois, nous vous recommandons de limiter les scripts d’installation des dépendances à l’[ensemble des scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) utilisés lors de la création du cluster. Si vous utilisez un environnement virtuel hébergé sur un répertoire partagé, vous pouvez également utiliser ce script pour activer l’environnement virtuel.
1. Lancez la tâche avec la SageMaker HyperPod reprise automatique activée en ajoutant l'indicateur `--auto-resume=1` indiquant que la `srun` commande doit être réessayée automatiquement en cas de panne matérielle.
**Note**
Si vous avez configuré une allocation de ressources en utilisant `sbatch` ou `salloc`, vous pouvez exécuter plusieurs commandes `srun` dans le cadre de l’allocation. En cas d'échec, la fonctionnalité de SageMaker HyperPod reprise automatique ne fonctionne que dans l'[étape de travail](https://slurm.schedmd.com/job_launch.html#step_allocation) en cours de la `srun` commande avec l'indicateur`--auto-resume=1`. En d’autres termes, l’activation de la reprise automatique dans une commande `srun` ne s’applique pas aux autres commandes `srun` lancées au cours d’une session d’allocation de ressources.
Voici des exemples de commande `srun` avec `auto-resume` activé.
**Utilisation de sbatch**
Comme la plus grande partie de la logique de configuration de l’environnement existe déjà dans `train_auto_resume.sh`, le script de commande doit être simple et similaire à l’exemple de code suivant. Supposons que le script de commande suivant soit enregistré sous `batch.sh`.
```
#!/bin/bash
#SBATCH --nodes 2
#SBATCH --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
Exécutez le script de commande précédent à l’aide de la commande suivante.
```
sbatch batch.sh
```
**Utilisation de salloc**
Commencez par acquérir une allocation exclusive et exécutez la commande `srun` avec l’indicateur `--auto-resume` et le script de point d’entrée.
```
salloc -N 2 --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
## Comment la restauration automatique des nœuds et la reprise automatique des nœuds fonctionnent ensemble
Lorsque les systèmes de restauration automatique des nœuds et de reprise automatique sont actifs, ils suivent une approche coordonnée pour gérer les défaillances. Si le HMA détecte une défaillance matérielle, le nœud est marqué comme étant épuisé quel que soit l'état de la tâche. Lorsque la restauration automatique des nœuds est activée, les nœuds sont automatiquement remplacés une fois que toutes les tâches exécutées sur les nœuds sont terminées. Dans ce scénario, pour les tâches pour lesquelles la reprise automatique est activée, si le statut de sortie de l'étape est différent de zéro, la reprise automatique démarre (les tâches reprennent une fois les nœuds remplacés). Les tâches pour lesquelles la reprise automatique n'est pas activée seront simplement abandonnées, ce qui nécessitera une nouvelle soumission manuelle par les administrateurs ou les utilisateurs.
**Note**
Si vous utilisez la reprise automatique, les nœuds sont toujours remplacés (aucun redémarrage) lorsque des défaillances matérielles sont détectées.
# Remplacez ou redémarrez manuellement un nœud à l'aide de Slurm
Cette section explique à quel moment vous devez redémarrer ou remplacer manuellement un nœud, avec des instructions sur la façon de procéder dans les deux cas.
## Quand redémarrer ou remplacer manuellement un nœud
La fonctionnalité de HyperPod reprise automatique surveille si l'état de vos nœuds Slurm passe à ou. `fail` `down` Vous pouvez vérifier l’état des nœuds Slurm en exécutant `sinfo`.
Si un nœud reste bloqué ou ne répond pas et que le processus de reprise automatique ne le rétablit pas, vous pouvez lancer la restauration manuellement. Le choix entre le redémarrage et le remplacement d'un nœud dépend de la nature du problème. Envisagez de redémarrer en cas de problèmes temporaires ou liés au logiciel, tels que des blocages du système, des fuites de mémoire, des problèmes liés au pilote du processeur graphique, des mises à jour du noyau ou des processus bloqués. Toutefois, si vous rencontrez des problèmes persistants ou liés au matériel, tels que des défaillances GPUs, des défaillances de mémoire ou de réseau, des échecs répétés liés aux tests de santé ou des nœuds qui ne répondent toujours pas après plusieurs tentatives de redémarrage, le remplacement des nœuds est la solution la plus appropriée.
## Méthodes de redémarrage ou de remplacement manuel des nœuds
SageMaker HyperPod propose deux méthodes pour la restauration manuelle des nœuds. L'approche préférée consiste à utiliser le SageMaker HyperPod redémarrage et le remplacement APIs, qui fournissent un processus de restauration plus rapide et plus transparent qui fonctionne sur tous les orchestrateurs. Vous pouvez également utiliser des commandes Slurm traditionnelles`scontrol update`, bien que cette ancienne méthode nécessite un accès direct au nœud de contrôleur du Slurm. Les deux méthodes activent les mêmes processus SageMaker HyperPod de restauration.
## Redémarrer manuellement un nœud à l'aide de l'API de redémarrage
Vous pouvez utiliser le **BatchRebootClusterNodes**pour redémarrer manuellement un nœud défectueux de votre SageMaker HyperPod cluster.
Voici un exemple d'exécution de l'opération de redémarrage sur deux instances d'un cluster à l'aide de AWS Command Line Interface :
```
aws sagemaker batch-reboot-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Remplacer manuellement un nœud à l'aide de l'API de remplacement
Vous pouvez utiliser le **BatchReplaceClusterNodes**pour remplacer manuellement un nœud défectueux dans votre SageMaker HyperPod cluster.
Voici un exemple d'exécution de l'opération de remplacement sur deux instances d'un cluster à l'aide de AWS Command Line Interface :
```
aws sagemaker batch-replace-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Redémarrer manuellement un nœud à l'aide de Slurm
Vous pouvez également utiliser les commandes scontrol Slurm pour déclencher la restauration des nœuds. Ces commandes interagissent directement avec le plan de contrôle Slurm et invoquent les mêmes mécanismes de SageMaker HyperPod restauration sous-jacents.
Dans la commande suivante, remplacez-le par le nom du nœud Slurm (nom d'hôte) de l'instance défectueuse que vous souhaitez redémarrer.
```
scontrol update node= state=fail reason="Action:Reboot"
```
Cela marque le nœud comme FAIL avec la raison spécifiée. SageMaker HyperPod détecte cela et redémarre l'instance. Évitez de modifier l'état du nœud ou de redémarrer le contrôleur Slurm pendant l'opération.
## Remplacer manuellement un nœud à l'aide de Slurm
Vous pouvez utiliser la commande scontrol update comme suit pour remplacer un nœud.
Dans la commande suivante, remplacez `` par le nom du nœud Slurm (nom d'hôte) de l'instance défectueuse que vous souhaitez remplacer.
```
scontrol update node= state=fail reason="Action:Replace"
```
Après avoir exécuté cette commande, le nœud passe à l'`fail`état, attend la fin des tâches en cours d'exécution, est remplacé par une instance saine et est restauré avec le même nom d'hôte. Ce processus prend du temps en fonction des instances disponibles dans votre zone de disponibilité et du temps nécessaire pour exécuter vos scripts de cycle de vie. Pendant les processus de mise à jour et de remplacement, évitez de modifier à nouveau l’état du nœud manuellement ou de redémarrer le contrôleur Slurm. Cela peut entraîner un échec de remplacement. Si le nœud n’est pas rétabli ou ne revient pas à l’état `idle` après une longue période, contactez [AWS Support](https://console.aws.amazon.com/support/).
## Forcer le changement manuel d'un nœud
Si le nœud défaillant est constamment bloqué dans l’état `fail`, le dernier recours que vous pouvez essayer est de forcer manuellement le remplacement de l’état du nœud par `down`. Cela nécessite des privilèges d’administrateur (autorisations sudo).
**Avertissement**
Procédez avec prudence avant d’exécuter la commande suivante, car elle force l’arrêt de toutes les tâches et vous risquez de perdre tout votre travail non enregistré.
```
scontrol update node= state=down reason="Action:Replace"
```
# Provisionnement continu pour des opérations de cluster améliorées avec Slurm
SageMaker HyperPod Les clusters Amazon créés avec l'orchestration de Slurm prennent désormais en charge le provisionnement continu, une fonctionnalité qui permet une flexibilité et une efficacité accrues lors de l'exécution de charges de travail à grande échelle. AI/ML Le provisionnement continu vous permet de démarrer l’entraînement rapidement, de procéder facilement à une mise à l’échelle, d’effectuer la maintenance sans interrompre les opérations et de bénéficier d’une visibilité granulaire sur les opérations du cluster.
**Note**
Le provisionnement continu est disponible en tant que configuration optionnelle pour les nouveaux HyperPod clusters créés avec l'orchestration de Slurm. Les clusters existants utilisant le modèle de dimensionnement précédent ne peuvent pas être migrés vers le provisionnement continu pour le moment.
## Comment ça marche
Le système de provisionnement continu introduit une architecture à l'état souhaité qui remplace le modèle de dimensionnement traditionnel all-or-nothing. Dans le modèle précédent, si un groupe d'instances ne pouvait pas être entièrement provisionné, l'opération complète de création ou de mise à jour du cluster échouait et était annulée. Avec le provisionnement continu, le système accepte une capacité partielle et continue de provisionner les instances restantes de manière asynchrone.
Le système de provisionnement continu :
+ **Accepte la demande** : enregistre le nombre d'instances cibles pour chaque groupe d'instances.
+ **Lance le provisionnement** : commence à lancer des instances pour tous les groupes d'instances en parallèle.
+ Provisionne d'**abord les nœuds prioritaires** : le cluster `InService` passe à un nœud contrôleur (et un nœud de connexion, si un groupe d'instances de connexion est spécifié) a été correctement provisionné.
+ **Suit la progression** : surveille chaque tentative de lancement d'instance et enregistre le statut.
+ **Gère les échecs** : retente automatiquement les lancements échoués pour les nœuds de travail de manière asynchrone.
Le provisionnement continu est désactivé par défaut. Pour utiliser cette fonctionnalité, définissez ce `NodeProvisioningMode` paramètre `Continuous` dans votre `CreateCluster` demande.
Lorsque le provisionnement continu est activé, vous pouvez lancer plusieurs opérations de mise à l’échelle simultanément sans attendre la fin des opérations précédentes. Cela vous permet de mettre à l’échelle simultanément différents groupes d’instances dans le même cluster et de soumettre plusieurs demandes de mise à l’échelle au même groupe d’instances.
## Provisionnement basé sur les priorités
Les clusters Slurm nécessitent un nœud contrôleur pour être opérationnel avant que les nœuds de travail puissent enregistrer et accepter des tâches. Le provisionnement continu gère cela automatiquement grâce à un provisionnement basé sur les priorités :
1. Le groupe d'instances du contrôleur est approvisionné en premier.
1. Une fois qu'un nœud de contrôleur est sain, les nœuds de connexion et les nœuds de travail commencent à s'approvisionner en parallèle.
1. Le cluster passe `InService` lorsqu'un nœud de contrôleur est actif et qu'un nœud de connexion est actif (si un groupe d'instances de connexion est spécifié). Si aucun groupe d'instances de connexion n'est spécifié, le cluster passe `InService` en cluster dès que le nœud contrôleur est provisionné.
1. Les nœuds de travail qui ne peuvent pas être approvisionnés immédiatement en raison de contraintes de capacité entrent dans une boucle de réessai asynchrone et sont automatiquement ajoutés au cluster Slurm dès qu'ils sont disponibles.
## Gestion des défaillances du contrôleur
Lors de la création du cluster, si le nœud du contrôleur ne parvient pas à se provisionner, le comportement dépend du fait que l'erreur est réessayable ou non réessayable.
**Erreurs réessayables** (par exemple, instance défectueuse ou défaillances transitoires) :
+ HyperPod remplace en permanence l'instance et tente à nouveau de le provisionner jusqu'à ce que le contrôleur apparaisse.
+ Les nœuds de travail et de connexion qui ont déjà été provisionnés restent disponibles, mais le cluster n'est pas transféré `InService` tant que le contrôleur n'est pas sain.
**Erreurs non réessayables** (par exemple, absence de capacité disponible pour le type d'instance du contrôleur ou échec du script de cycle de vie) :
+ Le cluster est marqué comme`Failed`.
+ Vous êtes informé de la raison de l'échec et devez prendre des mesures correctives, telles que le choix d'un autre type d'instance, la correction des scripts de cycle de vie ou une nouvelle tentative dans une autre zone de disponibilité.
## Conditions préalables
Le provisionnement continu nécessite que les paramètres de provisionnement de Slurm (types de nœuds, noms de partitions) soient fournis via la charge utile de l'API dans le champ de chaque groupe d'instances. `SlurmConfig` Les clusters qui s'appuient sur l'ancien `provisioning_parameters.json` fichier d'Amazon S3 ne sont pas compatibles avec le provisionnement continu.
**Note**
Les fonctionnalités suivantes ne sont actuellement pas prises en charge avec le provisionnement continu sur les clusters Slurm : migration des clusters existants, configuration de nœuds à plusieurs têtes via la topologie Slurm basée sur l'API, et. `SlurmConfigStrategy` Le provisionnement continu fonctionne exclusivement en mode fusion pour la `slurm.conf` gestion.
## Comptage d’utilisation
HyperPod les clusters dotés d'un provisionnement continu utilisent des mesures au niveau de l'instance pour fournir une facturation précise qui reflète l'utilisation réelle des ressources. Cette approche des mesures diffère de la facturation traditionnelle au niveau du cluster, car elle permet de suivre chaque instance indépendamment.
**Facturation au niveau de l’instance**
Avec le provisionnement continu, la facturation commence et s’arrête au niveau de l’instance individuelle au lieu d’attendre les changements d’état au niveau du cluster. Cette approche présente les avantages suivants :
+ **Exactitude précise de la facturation** : la facturation commence lorsque l’exécution du script de cycle de vie commence. Si le script de cycle de vie échoue, le provisionnement de l'instance sera réessayé et vous serez facturé pour la durée d'exécution du script de cycle de vie.
+ **Mesure indépendante** : le cycle de vie de facturation de chaque instance est géré séparément, ce qui permet d'éviter les erreurs de facturation en cascade.
+ **Mises à jour de facturation en temps réel** : la facturation commence lorsqu'une instance commence à exécuter son script de configuration du cycle de vie et s'arrête lorsque l'instance entre dans un état de terminaison.
**Cycle de vie de facturation**
Chaque instance de votre HyperPod cluster suit le cycle de facturation suivant :
+ La **facturation commence** : lorsque l'instance démarre avec succès et commence à exécuter son script de configuration du cycle de vie.
+ **La facturation continue** : pendant toute la durée de vie opérationnelle de l'instance.
+ **Arrêt de la facturation** : lorsque l'instance entre dans un état de terminaison, quelle que soit la raison de la résiliation.
**Note**
La facturation ne démarre pas pour les instances qui ne démarrent pas. Si le lancement d’une instance échoue en raison d’une capacité insuffisante ou d’autres problèmes, cette tentative infructueuse ne vous est pas facturée. La facturation est calculée au niveau de l’instance et les coûts sont agrégés et signalés sous l’Amazon Resource Name (ARN) de votre cluster.
## Création d’un cluster avec le provisionnement continu activé
**Note**
Préparez un script de configuration du cycle de vie et chargez-le dans un compartiment Amazon S3 auquel votre rôle d'exécution peut accéder. Pour de plus amples informations, veuillez consulter [SageMaker HyperPod Opérations du cluster Slurm](sagemaker-hyperpod-operate-slurm.md).
Préparez un fichier de demande d'`CreateCluster`API au format JSON. Définissez `Continuous` et fournissez `NodeProvisioningMode` les informations topologiques de Slurm dans le champ de chaque groupe d'instances. `SlurmConfig`
```
// create_cluster.json
{
"ClusterName": "my-training-cluster",
"NodeProvisioningMode": "Continuous",
"Orchestrator": {
"Slurm": {}
},
"InstanceGroups": [
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Controller"
}
},
{
"InstanceGroupName": "login-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Login"
}
},
{
"InstanceGroupName": "worker-gpu-a",
"InstanceType": "ml.p5.48xlarge",
"InstanceCount": 16,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["gpu-training"]
}
}
],
"VpcConfig": {
"SecurityGroupIds": ["sg-12345678"],
"Subnets": ["subnet-12345678"]
}
}
```
Exécutez la `create-cluster` commande pour envoyer la demande.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
Cela renvoie l'ARN du nouveau cluster.
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}
```
## Gestion de la configuration de Slurm
Le provisionnement continu fonctionne exclusivement en mode fusion pour la gestion des `slurm.conf` partitions. En mode fusion, HyperPod applique les modifications de configuration de sa partition de manière additive à celles que vous avez modifiées. `slurm.conf` HyperPod met uniquement à jour les sections relatives à la partition de `slurm.conf` (telles que les entrées de nom de partition et de nom de nœud) ; les autres paramètres de configuration de Slurm ne sont pas modifiés. Autrement dit :
+ Vos modifications manuelles `slurm.conf` sont conservées.
+ Il n'y a pas de détection automatique de la dérive ni de résolution des conflits entre vos modifications et HyperPod l'état attendu.
Le `SlurmConfigStrategy` paramètre (`Managed`,`Merge`,`Overwrite`) n'est pas pris en charge avec le provisionnement continu. La transmission d'une `SlurmConfigStrategy` valeur entraîne une erreur d'API.
# SageMaker HyperPod gestion des clusters
Les rubriques suivantes traitent de la journalisation et de la gestion des SageMaker HyperPod clusters.
## Journalisation SageMaker HyperPod des événements
Tous les événements et journaux SageMaker HyperPod sont enregistrés sur Amazon CloudWatch sous le nom du groupe de journaux`/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]`. Chaque appel à l’API `CreateCluster` crée un nouveau groupe de journaux. La liste suivante contient tous les flux de journaux disponibles collectés dans chaque groupe de journaux.
| | |
| --- |--- |
| Nom du groupe de journaux | Nom du flux de journaux |
| /aws/sagemaker/Clusters/[ClusterName]/[ClusterID] | LifecycleConfig/[instance-group-name]/[instance-id] |
## Journalisation SageMaker HyperPod au niveau de l'instance
Vous pouvez accéder aux LifecycleScript journaux publiés CloudWatch lors de la configuration de l'instance de cluster. Chaque instance de cluster créée génère un flux de journaux distinct, qui se distingue par son format `LifecycleConfig/[instance-group-name]/[instance-id]`.
Tous les journaux écrits `/var/log/provision/provisioning.log` sont téléchargés dans le CloudWatch flux précédent. LifecycleScripts Échantillonnez lors de la [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)redirection de leur `stdout` et `stderr` vers cet emplacement. Si vous utilisez vos scripts personnalisés, rédigez vos journaux à l'`/var/log/provision/provisioning.log`endroit où ils seront disponibles CloudWatch.
**Marqueurs du journal des scripts de cycle de**
CloudWatch les journaux des scripts de cycle de vie incluent des marqueurs spécifiques pour vous aider à suivre la progression de l'exécution et à identifier les problèmes :
| | |
| --- |--- |
| Marker | Description |
| START | Indicates the beginning of lifecycle script logs for the instance |
| [SageMaker] Lifecycle scripts were provided, with S3 uri: [s3://bucket-name/] and entrypoint script: [script-name.sh] | Indicates the S3 location and entrypoint script that will be used |
| [SageMaker] Downloading lifecycle scripts | Indicates scripts are being downloaded from the specified S3 location |
| [SageMaker] Lifecycle scripts have been downloaded | Indicates scripts have been successfully downloaded from S3 |
| [SageMaker] The lifecycle scripts succeeded | Indicates successful completion of all lifecycle scripts |
| [SageMaker] The lifecycle scripts failed | Indicates failed execution of lifecycle scripts |
Ces marqueurs vous aident à identifier rapidement l'endroit où un problème s'est produit au cours du processus d'exécution du script du cycle de vie. Lorsque vous résolvez des problèmes, passez en revue les entrées du journal pour identifier l'endroit où le processus s'est arrêté ou a échoué.
**Messages d'échec du script Lifecycle**
Si le script de cycle de vie existe mais échoue lors de son exécution, vous recevrez un message d'erreur contenant le nom du groupe de CloudWatch journaux et le nom du flux de journaux. En cas d'échec du script de cycle de vie sur plusieurs instances, le message d'erreur indiquera qu'une seule instance a échoué, mais le groupe de journaux doit contenir des flux pour toutes les instances.
Vous pouvez afficher le message d'erreur en exécutant l'[DescribeCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html)API ou en consultant la page des détails du cluster dans la SageMaker console. Dans la console, un bouton **Afficher les journaux des scripts de cycle** de vie est fourni pour accéder directement au flux de CloudWatch journaux. Le message d'erreur est au format suivant :
```
Instance [instance-id] failed to provision with the following error: "Lifecycle scripts did not run successfully. To view lifecycle script logs,
visit log group ‘/aws/sagemaker/Clusters/[cluster-name]/[cluster-id]' and log stream ‘LifecycleConfig/[instance-group-name]/[instance-id]’.
If you cannot find corresponding lifecycle script logs in CloudWatch, please make sure you follow one of the options here:
https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-faq-slurm.html#hyperpod-faqs-q1.” Note that multiple instances may be impacted.
```
## Balisage de ressources
AWS Le système de balisage permet de gérer, d'identifier, d'organiser, de rechercher et de filtrer les ressources. SageMaker HyperPod prend en charge le balisage, afin que vous puissiez gérer les clusters en tant que AWS ressource. Lors de la création ou de la modification d’un cluster existant, vous pouvez ajouter ou modifier des balises pour le cluster. Pour en savoir plus sur le balisage en général, consultez [Balisage de vos ressources AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
### Utilisation de l'interface utilisateur SageMaker HyperPod de la console
Lorsque vous [créez un nouveau cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster) et [modifiez un cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-edit-clusters), vous pouvez ajouter, supprimer ou modifier des balises.
### En utilisant le SageMaker HyperPod APIs
Lorsque vous rédigez un fichier de requête [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)ou d'[UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API au format JSON, modifiez la `Tags` section.
### Utilisation des commandes de AWS CLI balisage pour l'IA SageMaker
**Pour baliser un cluster**
Utilisez [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html) comme suit.
```
aws sagemaker add-tags --resource-arn cluster_ARN --tags Key=string,Value=string
```
**Pour supprimer les balises d’un cluster**
Utilisez [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-tags.html) comme suit.
```
aws sagemaker delete-tags --resource-arn cluster_ARN --tag-keys "tag_key"
```
**Pour répertorier les balises d’une ressource**
Utilisez [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-tags.html) comme suit.
```
aws sagemaker list-tags --resource-arn cluster_ARN
```
# SageMaker HyperPod FAQs
Consultez les questions fréquemment posées ci-dessous pour résoudre les problèmes liés à l'utilisation SageMaker HyperPod.
**Topics**
+ [Pourquoi ne puis-je pas trouver les groupes de journaux de mon SageMaker HyperPod cluster sur Amazon CloudWatch ?](#hyperpod-faqs-q1)
+ [Quelles configurations particulières sont HyperPod gérées dans les fichiers de configuration de Slurm tels `slurm.conf` que et ? `gres.conf`](#hyperpod-faqs-q2)
+ [Comment exécuter Docker sur les nœuds Slurm ? HyperPod](#hyperpod-faqs-q3)
+ [Pourquoi ma tâche de formation parallèle échoue-t-elle lorsque j'utilise la bibliothèque de communications collectives NVIDIA (NCCL) avec Slurm sur plateforme ? SageMaker HyperPod](#hyperpod-faqs-q4)
+ [Comment utiliser le NVMe magasin local d'instances P pour lancer des conteneurs Docker ou Enroot avec Slurm ?](#hyperpod-faqs-q5)
+ [Comment configurer des groupes de sécurité EFA ?](#hyperpod-faqs-q6)
+ [Comment surveiller les nœuds de mon HyperPod cluster ? Des CloudWatch métriques sont-elles exportées depuis HyperPod ?](#hyperpod-faqs-q7)
+ [Puis-je ajouter un espace de stockage supplémentaire aux nœuds du HyperPod cluster ? Les instances de cluster disposent d’un espace de stockage d’instances local limité.](#hyperpod-faqs-q8)
+ [Pourquoi mes nœuds de calcul affichent-ils la mention « DOWN » ou « DRAINED » après un redémarrage ?](#hyperpod-faqs-q9)
+ [Pourquoi mes nœuds continuent-ils à être vidés en raison de problèmes de mémoire insuffisante (OOM) ?](#hyperpod-faqs-q10)
+ [Comment puis-je m’assurer que les ressources sont correctement nettoyées une fois les tâches terminées ?](#hyperpod-faqs-q11)
## Pourquoi ne puis-je pas trouver les groupes de journaux de mon SageMaker HyperPod cluster sur Amazon CloudWatch ?
Par défaut, les journaux des agents et les journaux de démarrage des instances sont envoyés au compte de la HyperPod plateforme CloudWatch. Dans le cas de scripts de cycle de vie utilisateur, les journaux de configuration du cycle de vie sont envoyés à celui de votre compte CloudWatch.
Si vous utilisez les [exemples de scripts de cycle](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) de vie fournis par l'équipe de HyperPod service, vous pouvez vous attendre à trouver les journaux de configuration du cycle de vie écrits`/var/log/provision/provisioning.log`, et vous ne rencontrerez pas ce problème.
Toutefois, si vous utilisez des chemins personnalisés pour collecter les journaux issus du provisionnement du cycle de vie et que vous ne trouvez pas les groupes de journaux figurant dans ceux de votre compte CloudWatch, cela peut être dû à des incohérences entre les chemins des fichiers journaux spécifiés dans vos scripts de cycle de vie et ceux recherchés par l' CloudWatch agent exécuté sur les instances de HyperPod cluster. Dans ce cas, cela signifie que vous devez configurer correctement vos scripts de cycle de vie pour envoyer les journaux à l' CloudWatch agent, ainsi que configurer la configuration de l' CloudWatch agent en conséquence. Pour résoudre le problème, choisissez l’une des options suivantes.
+ **Option 1 :** mettez à jour vos scripts de cycle de vie pour écrire les journaux dans `/var/log/provision/provisioning.log`.
+ **Option 2 :** mettez à jour l' CloudWatch agent pour qu'il recherche vos chemins personnalisés pour la journalisation du provisionnement du cycle de vie.
1. Chaque instance de HyperPod cluster contient un fichier de configuration d' CloudWatch agent au format JSON à l'adresse`/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json`. Dans le fichier de configuration, recherchez le nom du champ `logs.logs_collected.files.collect_list.file_path`. Avec la configuration par défaut par HyperPod, la paire clé-valeur doit être `"file_path": "/var/log/provision/provisioning.log"` telle que documentée sur. [Journalisation SageMaker HyperPod au niveau de l'instance](sagemaker-hyperpod-cluster-management-slurm.md#sagemaker-hyperpod-cluster-management-slurm-logging-at-instance-level) L'extrait de code suivant montre à quoi ressemble le fichier JSON avec la configuration HyperPod par défaut.
```
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/provision/provisioning.log",
"log_group_name": "/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]",
"log_stream_name": "LifecycleConfig/[InstanceGroupName]/{instance_id}",
"retention_in_days": -1
}
]
}
},
"force_flush_interval": 3
}
```
1. Remplacez la valeur du nom du champ `"file_path"` par le chemin personnalisé que vous utilisez dans vos scripts de cycle de vie. Par exemple, si vous avez configuré vos scripts de cycle de vie pour écrire dans `/var/log/custom-provision/custom-provisioning.log`, mettez à jour la valeur pour qu’elle corresponde à ce qui suit.
```
"file_path": "/var/log/custom-provision/custom-provisioning.log"
```
1. Redémarrez l' CloudWatch agent avec le fichier de configuration pour terminer l'application du chemin personnalisé. Par exemple, la CloudWatch commande suivante montre comment redémarrer l' CloudWatch agent avec le fichier de configuration de l' CloudWatch agent de l'étape 1. Pour plus d'informations, voir également [Résolution des problèmes liés à l' CloudWatch agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html).
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -m ec2 -s -c \
file:/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json
```
## Quelles configurations particulières sont HyperPod gérées dans les fichiers de configuration de Slurm tels `slurm.conf` que et ? `gres.conf`
Lorsque vous créez un cluster Slurm sur HyperPod, l' HyperPod agent configure les [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)fichiers [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)et `/opt/slurm/etc/` pour gérer le cluster Slurm en fonction de votre demande de création de cluster et de vos scripts de HyperPod cycle de vie. La liste suivante indique les paramètres spécifiques que l' HyperPod agent gère et remplace.
**Important**
Nous vous recommandons vivement de NE PAS modifier ces paramètres gérés par HyperPod.
+ Dans [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod définit les paramètres de base suivants : `ClusterName``SlurmctldHost`,`PartitionName`, et`NodeName`.
En outre, pour activer la [Restauration automatique des nœuds et reprise automatique](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) fonctionnalité, HyperPod les `SchedulerParameters` paramètres `TaskPlugin` et doivent être définis comme suit. L' HyperPod agent définit ces deux paramètres avec les valeurs requises par défaut.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ Dans [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod gère `NodeName` les nœuds GPU.
## Comment exécuter Docker sur les nœuds Slurm ? HyperPod
Pour vous aider à exécuter Docker sur vos nœuds Slurm HyperPod, l'équipe de HyperPod service fournit des scripts de configuration que vous pouvez inclure dans le cadre de la configuration du cycle de vie pour la création de clusters. Pour en savoir plus, consultez [Scripts de cycle de vie de base fournis par HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) et [Exécution de conteneurs Docker sur un nœud de calcul Slurm sur HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md).
## Pourquoi ma tâche de formation parallèle échoue-t-elle lorsque j'utilise la bibliothèque de communications collectives NVIDIA (NCCL) avec Slurm sur plateforme ? SageMaker HyperPod
Par défaut, le système d’exploitation Linux définit l’indicateur `#RemoveIPC=yes`. Les tâches Slurm et mpirun qui utilisent NCCL génèrent des ressources de communication inter-processus (IPC) dans le cadre de sessions d’utilisateur non racine. Ces sessions utilisateur peuvent se déconnecter pendant le processus de tâche.
Lorsque vous exécutez des tâches avec Slurm ou mpirun, si `systemd` détecte que l’utilisateur n’est pas connecté, il nettoie les ressources IPC. Les tâches Slurm et mpirun peuvent être exécutées sans que l’utilisateur soit connecté, mais cela nécessite que vous désactiviez le nettoyage au niveau de systemd et que vous le configuriez au niveau Slurm. Pour plus d’informations, consultez [Systemd dans la documentation NCCL](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html#systemd).
Pour désactiver le nettoyage au niveau de systemd, effectuez les opérations suivantes.
1. Définissez l’indicateur `#RemoveIPC=no` dans le fichier `/etc/systemd/logind.conf` si vous exécutez des tâches d’entraînement utilisant Slurm et NCCL.
1. Par défaut, Slurm ne nettoie pas les ressources partagées. Nous vous recommandons de configurer un script d’épilogue Slurm afin de nettoyer les ressources partagées. Ce nettoyage est utile lorsque vous avez de nombreuses ressources partagées et que vous souhaitez les nettoyer après des tâches d’entraînement. Voici un exemple de script.
```
#!/bin/bash
: <<'SUMMARY'
Script: epilog.sh
Use this script with caution, as it can potentially delete unnecessary resources and cause issues if you don't use it correctly.
Note: You must save this script in a shared in a shared location that is accessible to all nodes in the cluster, such as /fsx volume.
Workers must be able to access the script to run the script after jobs.
SUMMARY
# Define the log directory and create it if it doesn't exist
LOG_DIR="//epilogue" #NOTE: Update PLACEHOLDER to be a shared value path, such as /fsx/epilogue.
mkdir -p "$LOG_DIR"
# Name the log file using the Slurm job name and job ID
log_file="$LOG_DIR/epilogue-${SLURM_JOB_NAME}_${SLURM_JOB_ID}.log"
logging() {
echo "[$(date)] $1" | tee -a "$log_file"
}
# Slurm epilogue script to clean up IPC resources
logging "Starting IPC cleanup for Job $SLURM_JOB_ID"
# Clean up shared memory segments by username
for seg in $(ipcs -m | awk -v owner="$SLURM_JOB_USER" '$3 == owner {print $2}'); do
if ipcrm -m "$seg"; then
logging "Removed shared memory segment $seg"
else
logging "Failed to remove shared memory segment $seg"
fi
done
# Clean up semaphores by username
for sem in $(ipcs -s | awk -v user="$SLURM_JOB_USER" '$3 == user {print $2}'); do
if ipcrm -s "$sem"; then
logging "Removed semaphore $sem"
else
logging "Failed to remove semaphore $sem"
fi
done
# Clean up NCCL IPC
NCCL_IPC_PATH="/dev/shm/nccl-*"
for file in $NCCL_IPC_PATH; do
if [ -e "$file" ]; then
if rm "$file"; then
logging "Removed NCCL IPC file $file"
else
logging "Failed to remove NCCL IPC file $file"
fi
fi
done
logging "IPC cleanup completed for Job $SLURM_JOB_ID"
exit 0
```
Pour plus d’informations sur le paramètre Epilog, consultez la [documentation Slurm](https://slurm.schedmd.com/slurm.conf.html#OPT_Epilog).
1. Dans le fichier `slurm.conf` provenant du nœud du contrôleur, ajoutez une ligne pour pointer vers le script d’épilogue que vous avez créé.
```
Epilog="/path/to/epilog.sh" #For example: /fsx/epilogue/epilog.sh
```
1. Exécutez les commandes suivantes pour modifier les autorisations du script et le rendre exécutable.
```
chown slurm:slurm /path/to/epilog.sh
chmod +x /path/to/epilog.sh
```
1. Pour appliquer toutes vos modifications, exécutez `scontrol reconfigure`.
## Comment utiliser le NVMe magasin local d'instances P pour lancer des conteneurs Docker ou Enroot avec Slurm ?
Le volume racine par défaut de votre nœud principal étant généralement limité à 100 Go de volume EBS, vous devez configurer Docker et Enroot pour utiliser le stockage d'instance local. NVMe Pour savoir comment configurer le NVMe magasin et l'utiliser pour lancer des conteneurs Docker, consultez[Exécution de conteneurs Docker sur un nœud de calcul Slurm sur HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md).
## Comment configurer des groupes de sécurité EFA ?
Si vous souhaitez créer un HyperPod cluster avec des instances compatibles EFA, assurez-vous de configurer un groupe de sécurité pour autoriser tout le trafic entrant et sortant à destination et en provenance du groupe de sécurité lui-même. Pour en savoir plus, consultez [Étape 1 : Préparation d’un groupe de sécurité compatible EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) dans le *Guide de l’utilisateur Amazon EC2*.
## Comment surveiller les nœuds de mon HyperPod cluster ? Des CloudWatch métriques sont-elles exportées depuis HyperPod ?
Pour améliorer l'observabilité de l'utilisation des ressources de votre HyperPod cluster, nous vous recommandons d'intégrer le HyperPod cluster à Amazon Managed Grafana et à Amazon Managed Service for Prometheus. Grâce à divers tableaux de bord Grafana et packages d'exportation open source, vous pouvez exporter et visualiser les métriques liées aux HyperPod ressources du cluster. Pour en savoir plus sur la configuration SageMaker HyperPod avec Amazon Managed Grafana et Amazon Managed Service for Prometheus, consultez. [SageMaker HyperPod surveillance des ressources du cluster](sagemaker-hyperpod-cluster-observability-slurm.md) Notez que l'exportation des métriques du système vers Amazon n'est SageMaker HyperPod actuellement pas prise en charge CloudWatch.
## Puis-je ajouter un espace de stockage supplémentaire aux nœuds du HyperPod cluster ? Les instances de cluster disposent d’un espace de stockage d’instances local limité.
Si le stockage d’instances par défaut est insuffisant pour votre charge de travail, vous pouvez configurer un stockage supplémentaire par instance. À compter de la [sortie du 20 juin 2024,](sagemaker-hyperpod-release-notes.md#sagemaker-hyperpod-release-notes-20240620) vous pouvez ajouter un volume Amazon Elastic Block Store (EBS) supplémentaire à chaque instance de votre cluster. SageMaker HyperPod Notez que cette fonctionnalité ne peut pas être appliquée aux groupes d'instances de SageMaker HyperPod clusters existants créés avant le 20 juin 2024. Vous pouvez utiliser cette fonctionnalité en appliquant des correctifs aux SageMaker HyperPod clusters existants créés avant le 20 juin 2024 et en y ajoutant de nouveaux groupes d'instances. Cette fonctionnalité est pleinement efficace pour tous les SageMaker HyperPod clusters créés après le 20 juin 2024.
## Pourquoi mes nœuds de calcul affichent-ils la mention « DOWN » ou « DRAINED » après un redémarrage ?
Cela se produit généralement lorsque les nœuds sont redémarrés en utilisant `sudo reboot` plutôt que l’interface de contrôle de Slurm. Pour redémarrer correctement les nœuds, utilisez la commande Slurm `scontrol reboot nextstate=resume `. Cela garantit que Slurm conservera un contrôle correct de l’état des nœuds et reprendra son fonctionnement normal après le redémarrage.
Pour les instances GPU (comme NVIDIA P5), cela peut également se produire si le nœud ne parvient pas à terminer son processus de démarrage dans le délai par défaut de Slurm (60 secondes). Pour résoudre ce problème, augmentez le paramètre `TimeToResume` dans `slurm.conf` à 300 secondes. Cela donne aux instances du GPU suffisamment de temps pour démarrer et initialiser les pilotes.
## Pourquoi mes nœuds continuent-ils à être vidés en raison de problèmes de mémoire insuffisante (OOM) ?
Des problèmes OOM se produisent lorsque les tâches dépassent la capacité de mémoire du nœud. Pour éviter cela, implémentez `cgroups` pour appliquer des limites de mémoire par tâche. Cela empêche qu’une seule tâche n’affecte l’ensemble du nœud, et cela améliore l’isolation et la stabilité.
Exemple de configuration dans `slurm.conf` :
```
TaskPlugin=task/cgroup
```
Exemple de configuration dans `cgroup.conf` :
```
CgroupAutomount=yes
ConstrainCores=yes
CgroupPlugin=autodetect
ConstrainDevices=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
SignalChildrenProcesses=yes
MaxRAMPercent=99
MaxSwapPercent=80
MinRAMSpace=100
```
Pour plus d’informations, consultez [Control Group in Slurm](https://slurm.schedmd.com/cgroups.html), [Cgroup and PAM-based login control for Slurm compute nodes](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils/pam_adopt_cgroup_wheel.sh#L197) et [Configure Cgroups for Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/16-enable-cgroups).
## Comment puis-je m’assurer que les ressources sont correctement nettoyées une fois les tâches terminées ?
Implémentez des scripts d’épilogue pour nettoyer automatiquement les ressources une fois les tâches terminées. Les ressources peuvent ne pas être correctement effacées lorsque les tâches se bloquent de manière inattendue, contiennent des bogues empêchant le nettoyage normal ou lorsque des tampons de mémoire partagés (y compris ceux partagés entre les processus et les pilotes GPU) restent alloués.
Les scripts d’épilogue peuvent effectuer des tâches telles que l’effacement de la mémoire GPU, la suppression des fichiers temporaires et le démontage des systèmes de fichiers. Ces scripts présentent des limites lorsque les ressources ne sont pas allouées exclusivement à une tâche unique. Pour des instructions détaillées et des exemples de scripts, reportez-vous au deuxième point de la question [Pourquoi ma tâche de formation parallèle échoue-t-elle lorsque j'utilise la bibliothèque de communications collectives NVIDIA (NCCL) avec Slurm sur plateforme ? SageMaker HyperPod](#hyperpod-faqs-q4). Pour plus d’informations, consultez [Activation d’un script d’épilogue Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/18-slurm-epilogue).