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.
-
Avant de créer un SageMaker HyperPod cluster :
-
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.
-
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.
-
-
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
AmazonSageMakerClusterInstanceRolePolicyattachée, votre cluster a accès aux compartiments Amazon S3 avec le préfixe spécifiquesagemaker-.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.shsont 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.sheffectue les actions suivantes.-
aws-node(CNI) : nouveau Daemonsetrig-aws-nodecréé ;aws-nodeexistant 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.
-
-
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 politiqueAmazonSageMakerClusterInstanceRolePolicygé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, ajoutezInstanceStressetInstanceConnectivitypour activer Vérifications de surveillance approfondie de l’état. -
Pour
NodeRecovery, spécifiezAutomaticd'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
Tagsparamè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.Labelseffet, 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.
-
-
Exécutez la commande create-cluster comme suit.
Important
Lorsque vous exécutez la commande
create-clusteravec le paramètre--cli-input-json, vous devez inclure le préfixefile://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éfixefile://entraîne une erreur d’analyse de paramètre.aws sagemaker create-cluster \ --cli-input-jsonfile://complete/path/to/create_cluster.jsonL’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.
OverrideVpcConfigCRITIQUE : Vérifiez
OverrideVpcConfigla configuration avant le déploiement afin d'éviter d'encourir des frais supplémentaires pour l'ODCR et pour la capacité à la demande.