Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Commencer à SageMaker HyperPod utiliser le AWS CLI

Le didacticiel suivant explique comment créer un nouveau SageMaker HyperPod cluster avec Slurm à l'aide des AWS CLI commandes pour. SageMaker HyperPod À la fin de ce didacticiel, vous disposerez d'un cluster Slurm fonctionnel avec un nœud contrôleur, un nœud de connexion et un groupe de travail de calcul, prêt à planifier et à exécuter des charges de travail ML. Le didacticiel couvre la configuration de la topologie Slurm, les options de configuration du cycle de vie des nœuds, le stockage partagé FSx en option et la manière de se connecter à votre cluster.

Avant de commencer, assurez-vous d'avoir terminé Conditions préalables à l'utilisation SageMaker HyperPod (VPC, quotas, FSx) et Gestion des identités et des accès AWS pour SageMaker HyperPod (rôles IAM, rôle d'exécution avec). AmazonSageMakerClusterInstanceRolePolicy

Concepts clés

Cette section couvre les concepts de configuration de base pour créer un cluster SageMaker HyperPod Slurm. La compréhension de ces concepts vous aidera à faire des choix éclairés lors de la configuration de votre cluster, mais si vous souhaitez commencer immédiatement, vous pouvez accéder directement à Créer votre cluster cette page et y revenir si nécessaire.

Lors de la création d'un Slurm-orchestrated cluster, vous devez effectuer deux choix de configuration indépendants :

Pour la topologie Slurm, ce didacticiel utilise l'approche de API-driven configuration, dans laquelle vous définissez les rôles des nœuds et les partitions directement dans la CreateCluster demande, SlurmConfig sur chaque groupe d'instances et Orchestrator.Slurm au niveau du cluster. Il s'agit de l'approche recommandée pour les nouveaux clusters. Il fournit une source unique de vérité, une validation intégrée et une détection des dérives de configuration des partitions, sans aucun fichier supplémentaire à gérer. Vous pouvez également utiliser un ancien provisioning_parameters.json fichier stocké dans Amazon S3 à des fins de rétrocompatibilité avec les clusters existants. Pour plus de détails sur l'ancienne approche, voirSageMaker HyperPod Configuration du Slurm.

Pour la configuration du cycle de vie des nœuds SageMaker HyperPod , trois options sont disponibles. Dans le cas le plus simple, vous omettez LifeCycleConfig complètement et HyperPod configurez automatiquement les nœuds en utilisant la AMI-based configuration, en configurant Slurm et des packages essentiels tels que Docker, Enroot et Pyxis pour exécuter des charges de travail ML, sans aucun script ni compartiment Amazon S3 requis. Si vous avez besoin de personnalisations en plus de la AMI-based configuration, vous pouvez fournir un script d'extension OnInitComplete qui s'exécute une fois la configuration terminée. Pour un contrôle total sur l'ensemble de la séquence d'approvisionnement, le OnCreate chemin permet à vos scripts de tout contrôler, y compris au démarrage de Slurm.

Pour les charges de travail ML, vous aurez généralement également besoin d'un système de fichiers partagé à hautes performances pour les données d'entraînement, les points de contrôle et les bibliothèques partagées. SageMaker HyperPod prend en charge Amazon FSx for Lustre et FSx pour OpenZFS, configurés par groupe d'instances via. InstanceStorageConfigs La configuration FSx est facultative pour la création de clusters mais recommandée pour les charges de travail de production.

Configuration de la topologie Slurm via l'API

Tous les exemples présentés dans ce didacticiel utilisent la configuration de la topologie API-driven Slurm, dans laquelle vous définissez la structure du cluster Slurm directement dans la demande d'CreateClusterAPI plutôt que par le biais d'un fichier de configuration distinct.

Un cluster Slurm nécessite au moins un nœud contrôleur (qui exécute le slurmctld démon et coordonne la planification des tâches) et un ou plusieurs nœuds de calcul (qui exécutent les tâches). Vous pouvez éventuellement ajouter un nœud de connexion pour fournir aux utilisateurs un point d'accès dédié pour soumettre et gérer des tâches sans se connecter directement au contrôleur. Dans la demande d'API, vous attribuez à chaque groupe d'instances son rôle Slurm en SlurmConfig spécifiant si le groupe sert de contrôleur, de connexion ou de nœud de calcul. Les groupes de calcul sont également mappés sur une ou plusieurs partitions Slurm, qui agissent comme des files d'attente logiques qui organisent la façon dont les tâches sont planifiées sur différents ensembles de nœuds.

Au niveau du cluster, Orchestrator.Slurm contrôle le mode de HyperPod gestion de la configuration de la partition dansslurm.conf. Vous choisissez une stratégie qui détermine s'il s' HyperPod agit de la seule source fiable pour la topologie des partitions, si elle remplace les modifications manuelles ou si elle fusionne la API-defined configuration avec les modifications manuelles que vous avez apportées. Voici une référence pour les champs utilisés.

SlurmConfig(par groupe d'instances) :

"SlurmConfig": {
    "NodeType": "Controller | Login | Compute",
    "PartitionNames": ["partition-name"]
}

Orchestrator.Slurm(au niveau du cluster) :

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

SlurmConfigStrategydétermine comment HyperPod gère les mappages partition-nœud slurm.conf sur le nœud contrôleur. Lorsque vous créez ou mettez à jour un cluster, HyperPod écrit la configuration de partition en slurm.conf fonction de celle SlurmConfig que vous avez définie pour chaque groupe d'instances, en mappant les groupes d'instances de calcul aux partitions qui leur sont attribuées et en enregistrant les nœuds de contrôleur et de connexion avec les rôles Slurm appropriés.

La stratégie que vous choisissez contrôle ce qui se passe lorsque la configuration de la partition slurm.conf a été modifiée en dehors de l'API, par exemple lorsqu'un administrateur édite le fichier directement sur le nœud du contrôleur. AvecManaged, HyperPod traite l'API comme la seule source fiable et détecte et bloque les mises à jour en cas de dérive slurm.conf sur le disque. AvecOverwrite, HyperPod force la API-defined configuration sur le contrôleur, annulant toute modification manuelle apportée à. slurm.conf Cela est utile pour récupérer après une modification involontaire. AvecMerge, HyperPod préserve les modifications manuelles slurm.conf et les fusionne avec la configuration de l'API, offrant aux utilisateurs avancés la flexibilité de conserver des slurm.conf paramètres personnalisés en même API-managed temps que les partitions.

Options de configuration du cycle de vie des nœuds

Lorsque vous créez un cluster SageMaker HyperPod Slurm, vous choisissez le mode de provisionnement des nœuds de chaque groupe d'instances en configurant le LifeCycleConfig bloc dans la demande. CreateCluster SageMaker HyperPod prend en charge trois options de configuration du cycle de vie des nœuds, chacune offrant un niveau de contrôle différent sur le processus de provisionnement.

Avec AMI-based la configuration uniquement, vous omettez LifeCycleConfig complètement. HyperPod configure automatiquement les nœuds en utilisant AMI-based la configuration, en installant Slurm, en installant les packages essentiels et en démarrant tous les services requis. Il s'agit du chemin le plus simple et ne nécessite aucun compartiment ou script Amazon S3.

Avec l'option Extension, vous spécifiez OnInitComplete et SourceS3Uri pointez vers votre script d'extension dans Amazon S3. LifeCycleConfig HyperPod exécute d'abord la AMI-based configuration complète, puis exécute votre script. Cela vous permet d'ajouter des personnalisations, telles que des agents de surveillance, l'intégration LDAP ou des montages de stockage supplémentaires, sans gérer le provisionnement de base.

Avec l'option Personnalisé, vous spécifiez OnCreate et SourceS3Uri pointez vers votre ensemble de scripts de cycle de vie complet dans Amazon S3. LifeCycleConfig HyperPod n'exécute pas AMI-based la configuration et ne démarre pas Slurm. Vos scripts possèdent l'intégralité de la séquence de provisionnement. Cela vous donne un contrôle total sur les logiciels installés, leur configuration et le moment où Slurm démarre.

Configuration de FSx et de VPC

Pour les charges de travail ML, un système de fichiers partagé à hautes performances est essentiel pour stocker les données d'entraînement, les points de contrôle des modèles et les bibliothèques partagées sur les nœuds du cluster. SageMaker HyperPod prend en charge Amazon FSx for Lustre et FSx pour OpenZFS, configurés par groupe d'instances via. InstanceStorageConfigs Les systèmes de fichiers FSx résident dans votre VPC. Une configuration VPC personnalisée () est donc requise lors de l'utilisation de FSx. VpcConfig

La configuration FSx fonctionne avec les trois options de configuration du cycle de vie des nœuds. Lors de l'utilisation AMI-based de la configuration ouOnInitComplete, HyperPod gère automatiquement le montage FSx. Lors de l'utilisationOnCreate, vos scripts de cycle de vie sont responsables du montage.

FSx for Lustre :

"InstanceStorageConfigs": [
    {
        "FsxLustreConfig": {
            "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com",
            "MountPath": "/fsx",
            "MountName": "abcdefgh"
        }
    }
]

FSx pour OpenZFS :

"InstanceStorageConfigs": [
    {
        "FsxOpenZfsConfig": {
            "DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
            "MountPath": "/shared"
        }
    }
]

Configuration VPC (requise pour FSx) :

Ajoutez VpcConfig au niveau du cluster dans votre CreateCluster demande :

"VpcConfig": {
    "SecurityGroupIds": ["sg-0abc123def456789a"],
    "Subnets": ["subnet-0abc123def456789a"]
}

Pour plus d'informations sur la configuration d'un VPC, consultez. Conditions préalables à l'utilisation SageMaker HyperPod Pour plus d'informations sur la configuration de FSx, consultez. Conditions préalables à l'utilisation SageMaker HyperPod

Créer votre cluster

Cette section explique comment créer un cluster à l'aide de chacune des trois options de configuration du cycle de vie des nœuds décrites dansOptions de configuration du cycle de vie des nœuds. Pour la plupart des utilisateurs, nous recommandons de commencer par l'option A, AMI-based configuration uniquement. Il ne nécessite aucun script ni compartiment Amazon S3 et fournit un cluster entièrement fonctionnel prêt à l'emploi. Choisissez l'option B si vous devez ajouter des personnalisations en plus de la AMI-based configuration, ou l'option C si vous avez besoin d'un contrôle total sur le processus de provisionnement.

ExecutionRoleDans tous les exemples, indiquez l'ARN du rôle IAM que vous avez créé avec le rôle managé AmazonSageMakerClusterInstanceRolePolicy dansConditions préalables à l'utilisation SageMaker HyperPod.

Option A : AMI-based configuration uniquement (sans configuration du cycle de vie)

C'est le chemin le plus simple. Aucun compartiment, script ou fichier de configuration Amazon S3 n'est nécessaire. SageMaker HyperPod configure les nœuds automatiquement à l'aide de AMI-based la configuration, en installant les logiciels essentiels et en appliquant les configurations afin que le cluster soit prêt à exécuter des charges de travail ML prêtes à l'emploi. Tous les packages logiciels étant intégrés à l'AMI, aucun accès à Internet n'est requis lors du provisionnement.

Le tableau suivant répertorie les fonctionnalités incluses dans la AMI-based configuration :

Option B : étendre AMI-based la configuration avec OnInitComplete

Utilisez cette option lorsque vous avez besoin de personnalisations en plus de la AMI-based configuration, telles que des agents de surveillance, une LDAP/SSSD intégration ou des supports de stockage supplémentaires. SageMaker HyperPod exécute d'abord la AMI-based configuration, puis exécute votre script d'extension.

Option C : contrôle personnalisé complet avec OnCreate (avancé)

Utilisez cette option lorsque vous avez besoin d'un contrôle total sur le provisionnement, notamment en installant des logiciels, en apportant des modifications à l'infrastructure et en décidant quand démarrer Slurm. AvecOnCreate, SageMaker HyperPod n'exécute pas AMI-based la configuration et ne démarre pas Slurm automatiquement.

Erreurs de validation courantes

Connectez-vous à votre cluster

Une fois que l'état du cluster est InService passé à (généralement 10 à 15 minutes), connectez-vous et vérifiez.

Pour plus d'informations sur l'exécution de charges de travail ML, consultezOffres d'emploi sur SageMaker HyperPod des clusters.

Suppression du cluster et nettoyage des ressources

Après le test, supprimez le cluster pour éviter des frais continus :

aws sagemaker delete-cluster --cluster-name my-hyperpod-cluster

Si vous avez utilisé des scripts de cycle de vie des nœuds (option B ou option C), nettoyez le compartiment Amazon S3 :

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

Si vous avez utilisé uniquement AMI-based la configuration (option A), aucun nettoyage Amazon S3 n'est nécessaire pour les scripts de cycle de vie des nœuds.

Si vous avez exécuté des charges de travail de formation, vérifiez également la présence de données ou d'artefacts dans Amazon S3, Amazon FSx for Lustre ou Amazon Elastic File System et supprimez-les pour éviter les frais.

Rubriques en relation