Création d'un SageMaker HyperPod cluster - Amazon SageMaker AI

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.

Création d'un SageMaker HyperPod cluster

Découvrez comment créer des SageMaker HyperPod clusters orchestrés par Amazon EKS à l'aide duAWS CLI.

  1. Avant de créer un SageMaker HyperPod cluster :

    1. Veillez à disposer d’un cluster Amazon EKS existant et opérationnel. Pour obtenir des instructions détaillées sur la configuration d’un cluster Amazon EKS, consultez Création d’un cluster Amazon EKS dans le Guide de l’utilisateur Amazon EKS.

    2. Installez les Charts de Helm comme indiqué dans Installation de packages sur le cluster Amazon EKS à l’aide de Helm. Si vous effectuez la Création d'un cluster HyperPod EKS avec un groupe d'instances restreint (RIG), vous aurez besoin de Charts de Helm distincts.

  2. Préparez un script de configuration de cycle de vie et chargez-le sur un compartiment Amazon S3, tel que s3://amzn-s3-demo-bucket/Lifecycle-scripts/base-config/.

    Pour démarrer rapidement, téléchargez l'exemple on_create.shde script depuis le GitHub référentiel AWS ome Distributed Training et chargez-le dans le compartiment S3. Vous pouvez également inclure des instructions de configuration supplémentaires, une série de scripts de configuration ou des commandes à exécuter pendant la phase de provisionnement du HyperPod cluster.

    Important

    Si vous créez un Rôle IAM pour SageMaker HyperPod avec la seule politique AmazonSageMakerClusterInstanceRolePolicy attachée, votre cluster a accès aux compartiments Amazon S3 avec le préfixe spécifique sagemaker-.

    Si vous créez un groupe d’instances restreint, vous n’êtes pas tenu de télécharger et d’exécuter le script de cycle de vie. Au lieu de cela, vous devez exécuter install_rig_dependencies.sh.

    Les conditions préalables requises pour exécuter le script install_rig_dependencies.sh sont les suivantes :

    • AWSNode (CNI) et CoreDNS doivent tous deux être activés. Il s'agit de modules complémentaires EKS standard qui ne sont pas gérés par le SageMaker HyperPod Helm standard, mais qui peuvent être facilement activés dans la console EKS sous Extensions.

    • Le graphique SageMaker HyperPod Helm standard doit être installé avant d'exécuter ce script.

    Le script install_rig_dependencies.sh effectue les actions suivantes.

    • aws-node (CNI) : nouveau Daemonset rig-aws-node créé ; aws-node existant corrigé pour éviter les nœuds de RIG.

    • coredns: Converti en Daemonset pour prendre en charge l'utilisation RIGs sur plusieurs plates-formes et éviter les surcharges.

    • training-operators : mise à jour avec les tolérances de rejet de processus de travail RIG et nodeAffinity favorisant les instances n’appartenant pas un RIG.

    • Elastic Fabric Adapter (EFA) : mise à jour pour tolérer le rejet des processus de travail RIG et utiliser des images de conteneur correctes pour chaque région.

  3. Préparez un fichier de demande d'CreateClusterAPI au format JSON. 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.

    Note

    Assurez-vous que votre SageMaker HyperPod cluster est déployé dans le même Virtual Private Cloud (VPC) que votre cluster Amazon EKS. Les sous-réseaux et les groupes de sécurité spécifiés dans la configuration du SageMaker HyperPod cluster doivent permettre la connectivité réseau et la communication avec le point de terminaison du serveur API du cluster Amazon EKS.

    // create_cluster.json { "ClusterName": "string", "InstanceGroups": [{ "InstanceGroupName": "string", "InstanceType": "string", "InstanceCount": number, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "string", "ThreadsPerCore": number, "OnStartDeepHealthChecks": [ "InstanceStress", "InstanceConnectivity" ] }], "RestrictedInstanceGroups": [ { "EnvironmentConfig": { "FSxLustreConfig": { "PerUnitStorageThroughput": number, "SizeInGiB": number } }, "ExecutionRole": "string", "InstanceCount": number, "InstanceGroupName": "string", "InstanceStorageConfigs": [ { ... } ], "InstanceType": "string", "OnStartDeepHealthChecks": [ "string" ], "OverrideVpcConfig": { "SecurityGroupIds": [ "string" ], "Subnets": [ "string" ] }, "ScheduledUpdateConfig": { "DeploymentConfig": { "AutoRollbackConfiguration": [ { "AlarmName": "string" } ], "RollingUpdatePolicy": { "MaximumBatchSize": { "Type": "string", "Value": number }, "RollbackMaximumBatchSize": { "Type": "string", "Value": number } }, "WaitIntervalInSeconds": number }, "ScheduleExpression": "string" }, "ThreadsPerCore": number, "TrainingPlanArn": "string" } ], "VpcConfig": { "SecurityGroupIds": ["string"], "Subnets": ["string"] }, "Tags": [{ "Key": "string", "Value": "string" }], "Orchestrator": { "Eks": { "ClusterArn": "string", "KubernetesConfig": { "Labels": { "nvidia.com/mig.config": "all-3g.40gb" } } } }, "NodeRecovery": "Automatic" }

    Notez les points suivants lors de la configuration pour créer un nouveau SageMaker HyperPod cluster associé à un cluster EKS.

    • Vous pouvez configurer jusqu’à 20 groupes d’instances sous le paramètre InstanceGroups.

    • Pour Orchestator.Eks.ClusterArn, spécifiez l’ARN du cluster EKS que vous souhaitez utiliser comme orchestrateur.

    • Pour OnStartDeepHealthChecks, ajoutez InstanceStress et InstanceConnectivity pour activer Vérifications de surveillance approfondie de l’état.

    • PourNodeRecovery, spécifiez Automatic d'activer la restauration automatique des nœuds. SageMaker HyperPod remplace ou redémarre les instances (nœuds) lorsque des problèmes sont détectés par l'agent de surveillance de l'état.

    • Pour le Tags paramètre, 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 services AWS qui prennent en charge le balisage. Pour en savoir plus sur le balisage des ressources AWS en général, consultez le Guide de l’utilisateur Ressources AWS de balisage.

    • Pour le paramètre VpcConfig, spécifiez les informations du VPC utilisé dans le cluster EKS. Les sous-réseaux doivent être privés.

    • En Orchestrator.Eks.KubernetesConfig.Labels effet, vous pouvez éventuellement spécifier les étiquettes Kubernetes à appliquer aux nœuds. Pour activer le partitionnement du GPU avec le GPU multi-instance (MIG), ajoutez l'nvidia.com/mig.configétiquette avec le profil MIG souhaité. Par exemple, "nvidia.com/mig.config": "all-3g.40gb" configure tout GPUs avec le profil de partition 3g.40 Go. Pour plus d'informations sur le partitionnement du GPU et les profils disponibles, consultezUtilisation de partitions GPU dans Amazon SageMaker HyperPod.

  4. Exécutez la commande create-cluster comme suit.

    Important

    Lorsque vous exécutez la commande create-cluster avec le paramètre --cli-input-json, vous devez inclure le préfixe file:// avant le chemin complet du fichier JSON. Ce préfixe est nécessaire pour s'assurer que l'entrée AWS CLI est reconnue comme un chemin de fichier. L’omission du préfixe file:// entraîne une erreur d’analyse de paramètre.

    aws sagemaker create-cluster \ --cli-input-json file://complete/path/to/create_cluster.json

    L’ARN du nouveau cluster devrait être renvoyé.

    Important

    Vous pouvez utiliser l’opération update-cluster pour supprimer un groupe d’instances restreint (RIG). Lorsqu'un RIG est réduit à 0, le système de fichiers FSx for Lustre n'est pas supprimé. Pour supprimer complètement le système de fichiers FSx for Lustre, vous devez supprimer complètement le RIG.

    La suppression d’un RIG ne supprimera aucun artefact stocké dans le compartiment Amazon S3 géré par le service. Cependant, vous devez vous assurer que tous les artefacts du système de fichiers FSx for Lustre sont entièrement synchronisés avec Amazon S3 avant de les supprimer. Nous vous recommandons d'attendre au moins 30 minutes après la fin du travail pour garantir la synchronisation complète de tous les artefacts du système de fichiers FSx for Lustre avec le compartiment Amazon S3 géré par le service.

    Important

    Lorsque vous utilisez une réservation de capacité à la demande (ODCR) intégrée, vous devez associer votre groupe d'instances au même ID de zone de disponibilité (AZ ID) que l'ODCR en utilisant un sous-réseau dans l'ID AZ correspondant. OverrideVpcConfig

    CRITIQUE : Vérifiez OverrideVpcConfig la configuration avant le déploiement afin d'éviter d'encourir des frais supplémentaires pour l'ODCR et pour la capacité à la demande.