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 du AWS 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](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) dans le *Guide de l’utilisateur Amazon EKS*. 1. Installez les Charts de Helm comme indiqué dans [Installation de packages sur le cluster Amazon EKS à l’aide de Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md). Si vous créez un [ SageMaker HyperPod cluster Amazon Nova](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp-cluster.html), vous aurez besoin d'un graphique Helm distinct. 1. 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 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts/base-config/on_create.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts/base-config/on_create.sh)de 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](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) avec la seule 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) 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 : + AWS Node (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. 1. Préparez un fichier de demande d'[CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)API 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](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-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" } ``` **Groupes d'instances flexibles** Au lieu d'en spécifier un seul`InstanceType`, vous pouvez utiliser le `InstanceRequirements` paramètre pour spécifier plusieurs types d'instances pour un groupe d'instances. Notez ce qui suit : `InstanceType`et s'`InstanceRequirements`excluent mutuellement. Vous devez spécifier l'un ou l'autre, mais pas les deux. `InstanceRequirements.InstanceTypes`est une liste ordonnée qui détermine la priorité d'approvisionnement. SageMaker HyperPodtente de provisionner le premier type d'instance de la liste et revient aux types suivants si la capacité n'est pas disponible. Vous pouvez spécifier jusqu'à 20 types d'instances, et la liste ne doit pas contenir de doublons. Les groupes d'instances flexibles nécessitent un mode de provisionnement continu des nœuds. L'exemple suivant montre un groupe d'instances utilisant `InstanceRequirements` : ``` { "InstanceGroupName": "flexible-ig", "InstanceRequirements": { "InstanceTypes": ["ml.p5.48xlarge", "ml.p4d.24xlarge", "ml.g6.48xlarge"] }, "InstanceCount": 10, "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" } ``` 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](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md). + Pour`NodeRecovery`, 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](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). + 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, consultez[Utilisation de partitions GPU dans Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md). 1. Exécutez la commande [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) 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](https://docs.aws.amazon.com//cli/latest/reference/ecs/update-cluster.html) 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.