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.
Provisionnement continu pour des opérations de cluster améliorées sur Amazon EKS
SageMaker HyperPod Les clusters Amazon créés avec l'orchestration Amazon EKS prennent désormais en charge le provisionnement continu, une nouvelle fonctionnalité qui permet une flexibilité et une efficacité accrues lors de l'exécution de charges de travail à grande échelle AI/ML . Le provisionnement continu vous permet de démarrer la formation rapidement, d'évoluer facilement, d'effectuer la maintenance sans perturber les opérations et de bénéficier d'une visibilité granulaire sur les opérations du cluster.
Note
Le provisionnement continu est disponible pour les HyperPod clusters créés avec l'orchestration EKS. Les clusters créés avec l'orchestration de Slurm utilisent un modèle de mise à l'échelle différent.
Comment ça marche
Le provisionnement continu fonctionne grâce à une architecture axée sur les événements qui gère chaque instance de manière indépendante. Lorsque vous créez un HyperPod cluster, vous spécifiez le nombre d'instances souhaité pour chaque groupe d'instances. Le système de provisionnement continu :
-
Accepte la demande : enregistre le nombre d'instances cibles pour chaque groupe d'instances
-
Lance le provisionnement : commence à lancer des instances pour atteindre le nombre cible
Suit la progression : surveille chaque tentative de lancement d'instance et enregistre le statut
-
Gère les échecs : retente automatiquement les lancements ayant échoué
Le provisionnement continu est désactivé par défaut. Pour utiliser cette fonctionnalité, réglez --node-provisioning-mode
surContinuous
.
Lorsque le provisionnement continu est activé, vous pouvez lancer plusieurs opérations de dimensionnement simultanément sans attendre la fin des opérations précédentes. Cela vous permet de dimensionner simultanément différents groupes d'instances dans le même cluster et de soumettre plusieurs demandes de dimensionnement au même groupe d'instances.
Le provisionnement continu vous permet également d'accéder à une DescribeClusterEventsurveillance détaillée ListClusterEventdes événements et à une visibilité opérationnelle.
Mesurage de l'utilisation
HyperPod les clusters dotés d'un provisionnement continu utilisent des mesures au niveau de l'instance pour fournir une facturation précise qui reflète l'utilisation réelle des ressources. Cette approche de mesure diffère de la facturation traditionnelle au niveau du cluster car elle permet de suivre chaque instance indépendamment.
Facturation au niveau de l'instance
Avec le provisionnement continu, la facturation commence et s'arrête au niveau de l'instance individuelle plutôt que d'attendre les changements d'état au niveau du cluster. Cette approche présente les avantages suivants :
-
Exactitude précise de la facturation : la facturation commence lorsque l'exécution du script de cycle de vie commence. Si le script de cycle de vie échoue, le provisionnement de l'instance sera réessayé et vous serez facturé pour la durée d'exécution du script de cycle de vie.
-
Mesure indépendante : le cycle de vie de facturation de chaque instance est géré séparément, ce qui permet d'éviter les erreurs de facturation en cascade
-
Mises à jour de facturation en temps réel : la facturation commence lorsqu'une instance commence à exécuter son script de cycle de vie et s'arrête lorsque l'instance entre dans un état de terminaison
Cycle de vie de facturation
Chaque instance de votre HyperPod cluster suit le cycle de vie de facturation suivant :
-
La facturation commence : lorsque l'instance démarre avec succès et commence à exécuter son script de configuration du cycle de vie
-
La facturation continue : pendant toute la durée de vie opérationnelle de l'instance
-
Arrêt de la facturation : lorsque l'instance entre dans un état de terminaison, quelle que soit la raison de la résiliation
Note
La facturation ne démarre pas pour les instances qui ne démarrent pas. Si le lancement d'une instance échoue en raison d'une capacité insuffisante ou d'autres problèmes, cette tentative infructueuse ne vous est pas facturée. La facturation est calculée au niveau de l'instance et les coûts sont agrégés et déclarés sous le nom de ressource Amazon (ARN) de votre cluster.
Créez un cluster avec le provisionnement continu activé
Note
Vous devez disposer d'un cluster Amazon EKS existant configuré avec un réseau VPC et le graphique Helm requis doit être installé. En outre, préparez un script de configuration du cycle de vie et chargez-le dans un compartiment Amazon S3 auquel votre rôle d'exécution peut accéder.
L' AWS CLI opération suivante crée un HyperPod cluster avec un groupe d'instances et le provisionnement continu activé.
aws sagemaker-dev create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "ig-1", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create_noop.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 1, "TrainingPlanArn": "" }' \ --node-provisioning-mode Continuous // Expected Output: { "ClusterArn": "arn:aws:sagemaker:us-west-2:<account-id>:cluster/<cluster-id>" }
Après avoir créé votre cluster, vous pouvez utiliser ListClusterNodesou DescribeClusterNodepour obtenir plus d'informations sur les nœuds du cluster.
L'appel de ces opérations renverra un ClusterInstanceStatusDetailsobjet avec l'une des valeurs suivantes :
-
En cours d'exécution : le nœud est sain et enregistré auprès de l'orchestrateur de cluster (EKS).
-
Échec : le provisionnement du nœud a échoué, mais le système réessaiera automatiquement de le configurer avec une nouvelle instance. EC2
-
En attente : le nœud est en cours de provisionnement ou de redémarrage.
-
ShuttingDown: La terminaison du nœud est en cours. Le nœud passera au statut d'échec si la résiliation rencontre des problèmes, ou sera supprimé du cluster avec succès.
-
SystemUpdating: le nœud est soumis à un correctif d'AMI, soit déclenché manuellement, soit dans le cadre de l'application de correctifs à des cronjobs.
-
DeepHealthCheckInProgress: Des bilans de santé DHCs approfondis () sont en cours. Cela peut prendre entre quelques minutes et plusieurs heures selon la nature des tests. Les nœuds défectueux sont remplacés et les nœuds sains passent en mode Exécution.
-
NotFound: Utilisé en BatchAddClusterNodesréponse pour indiquer qu'un nœud a été supprimé lors d'une rediffusion idempotente.