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 montre 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 travailleurs 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é les tâches Prérequis pour 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 principaux concepts de configuration 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 section et y revenir si nécessaire.

Lors de la création d'un Slurm-orchestrated cluster, vous pouvez 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 et les partitions des nœuds directement dans la CreateCluster demande, en utilisant SlurmConfig 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 de dérive de la configuration des partitions sans aucun fichier supplémentaire à gérer. Vous pouvez également utiliser un ancien provisioning_parameters.json fichier stocké dans Amazon S3 pour assurer la rétrocompatibilité avec les clusters existants. Pour plus de détails sur l'approche héritée, voirSageMaker HyperPod Configuration de Slurm.

Pour la configuration du cycle de vie des nœuds, SageMaker HyperPod prend en charge trois options. Dans le cas le plus simple, vous omettez LifeCycleConfig complètement et configurez HyperPod automatiquement les nœuds à l'aide de la AMI-based configuration, de la configuration de Slurm et de 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 de provisionnement, 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 pour 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 de Slurm via l'API

Tous les exemples de ce didacticiel utilisent la configuration topologique API-driven Slurm, dans laquelle vous définissez la structure du cluster Slurm directement dans la demande d'CreateClusterAPI plutôt que via 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é à la soumission et à la gestion 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 à 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 la manière dont HyperPod la configuration des partitions est gérée dansslurm.conf. Vous choisissez une stratégie qui détermine s'il s' HyperPod agit de la source unique de vérité 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(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 sur la slurm.conf base de ce SlurmConfig que vous avez défini 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 est modifiée en dehors de l'API, par exemple par un administrateur modifiant le fichier directement sur le nœud du contrôleur. AvecManaged, HyperPod traite l'API comme la source unique de vérité 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 Ceci est utile pour récupérer après une modification involontaire. AvecMerge, HyperPod préserve les modifications manuelles apportées à la configuration de l'API slurm.conf et les fusionne avec celle-ci, ce qui permet aux utilisateurs avancés de conserver des slurm.conf paramètres personnalisés en plus API-managed des partitions.

Options de configuration du cycle de vie des nœuds

Lorsque vous créez un cluster SageMaker HyperPod Slurm, vous choisissez la manière dont les nœuds de chaque groupe d'instances sont provisionnés 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 à l'aide de AMI-based la configuration, de la configuration de Slurm, de l'installation des packages essentiels et du démarrage de tous les services requis. Il s'agit du chemin le plus simple qui ne nécessite aucun bucket ou script Amazon S3.

Avec l'option Extension, vous spécifiez « OnInitComplete in LifeCycleConfig » en SourceS3Uri pointant vers votre script d'extension dans Amazon S3. 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, une intégration LDAP ou des montages de stockage supplémentaires, sans gérer le provisionnement de base.

Avec l'option Personnalisé, vous pouvez LifeCycleConfig le spécifier OnCreate en SourceS3Uri pointant vers votre script de cycle de vie complet défini dans Amazon S3. 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 FSx et VPC

Pour les charges de travail de machine learning, un système de fichiers hautes performances partagé 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 pour 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 (VpcConfig) est donc requise lors de l'utilisation de FSx.

La configuration FSx fonctionne avec les trois options de configuration du cycle de vie des nœuds. Lorsque vous utilisez AMI-based 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 pour 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 du 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, consultezPrérequis pour l'utilisation SageMaker HyperPod. Pour plus d'informations sur la configuration de FSx, consultezPrérequis pour 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 gestionnaire AmazonSageMakerClusterInstanceRolePolicy dansPrérequis pour 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 des configurations afin que le cluster soit prêt à exécuter des charges de travail ML prêtes à l'emploi. Tous les packages logiciels sont intégrés à l'AMI, de sorte qu'aucun accès Internet n'est requis lors du provisionnement.

Le tableau suivant répertorie les fonctionnalités incluses dans AMI-based la 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 lance d'abord AMI-based la configuration, puis exécute le script de votre 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 pour installer des logiciels, apporter des modifications à l'infrastructure et décider 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 dans les SageMaker HyperPod 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, recherchez également des données ou des artefacts dans Amazon S3, Amazon FSx for Lustre ou Amazon Elastic File System et supprimez-les pour éviter des frais.

Rubriques associées