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 l’entraînement rapidement, de procéder facilement à une mise à l’échelle, d’effectuer la maintenance sans interrompre les opérations et de bénéficier d’une visibilité granulaire sur les opérations du cluster. **Note** Le provisionnement continu est disponible en tant que configuration optionnelle pour les HyperPod clusters créés avec l'orchestration EKS. HyperPod les clusters créés avec l'orchestration de Slurm prennent également en charge le provisionnement continu. Pour en savoir plus, consultez [Provisionnement continu pour des opérations de cluster améliorées avec Slurm](sagemaker-hyperpod-scaling-slurm.md). ## Comment ça marche Le système de provisionnement continu introduit une architecture à état souhaité qui remplace le modèle traditionnel basé sur les demandes. Cette nouvelle architecture permet des opérations parallèles et non bloquantes sur différents niveaux de ressources tout en préservant la stabilité et les performances du système. 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é, définissez `--node-provisioning-mode` sur `Continuous`. Lorsque le provisionnement continu est activé, vous pouvez lancer plusieurs opérations de mise à l’échelle simultanément sans attendre la fin des opérations précédentes. Cela vous permet de mettre à l’échelle simultanément différents groupes d’instances dans le même cluster et de soumettre plusieurs demandes de mise à l’échelle au même groupe d’instances. Le provisionnement continu vous permet également d'accéder à une [DescribeClusterEvent](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeClusterEvent.html)surveillance détaillée [ListClusterEvent](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html)des événements et à une visibilité opérationnelle. ## Comptage d’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 des mesures diffère de la facturation traditionnelle au niveau du cluster, car elle permet de suivre chaque instance indépendamment. **Instance-level facturation** Avec le provisionnement continu, la facturation commence et s’arrête au niveau de l’instance individuelle au lieu 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 la durée d’exécution du script de cycle de vie vous sera facturée. + **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. + **Real-time mises à jour** de facturation : 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 facturation suivant : + **La facturation commence** : lorsque l’instance démarre avec succès et commence à exécuter son script de configuration de cycle de vie. + **La facturation continue** : pendant toute la durée de vie opérationnelle de l’instance. + **La facturation s’arrête** : lorsque l’instance entre en phase de résiliation, 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 signalés sous l’Amazon Resource Name (ARN) de votre cluster. ## Création d’un cluster avec le provisionnement continu activé **Note** Vous devez disposer d’un cluster Amazon EKS configuré avec la mise en réseau de VPC et les Charts de Helm requis installés. En outre, préparez un script de configuration de cycle de vie et chargez-le dans un compartiment Amazon S3 auquel votre rôle d’exécution peut accéder. Pour de plus amples informations, veuillez consulter [Gestion des SageMaker HyperPod clusters orchestrés par Amazon EKS](sagemaker-hyperpod-eks-operate.md). L' AWS CLI opération suivante crée un HyperPod cluster avec un groupe d'instances et le provisionnement continu activé. ``` aws sagemaker 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::cluster/" } ``` Après avoir créé votre cluster, vous pouvez utiliser [ListClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterNodes.html)ou [DescribeClusterNode](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeClusterNode.html)pour obtenir plus d'informations sur les nœuds du cluster. L'appel de ces opérations renverra un [ClusterInstanceStatusDetails](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceStatusDetails.html)objet avec l'une des valeurs suivantes : + **Running** : le nœud est sain et enregistré auprès de l’orchestrateur de cluster (EKS). + **Failure** : le provisionnement du nœud a échoué, mais le système réessaiera automatiquement le provisionnement avec une nouvelle instance EC2. + **Pending** : le nœud est en cours de provisionnement ou de redémarrage. + **ShuttingDown**: La terminaison du nœud est en cours. Le nœud prendra le 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é approfondis (DHC)](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md) sont en cours. Cela peut prendre de quelques minutes à plusieurs heures selon la nature des tests. Les nœuds défaillants sont remplacés et les nœuds sains passent en mode d’exécution. + **NotFound**: Utilisé en [BatchAddClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchAddClusterNodes.html)réponse pour indiquer qu'un nœud a été supprimé lors d'une rediffusion idempotente. ## Exigences de capacité minimale (MinCount) MinCount Cette fonctionnalité vous permet de spécifier le nombre minimum d'instances qui doivent être correctement provisionnées avant qu'un groupe d'instances ne passe au `InService` statut. Cette fonctionnalité permet de mieux contrôler les opérations de dimensionnement et d'éviter les scénarios dans lesquels des groupes d'instances partiellement provisionnés ne peuvent pas être utilisés efficacement pour les charges de travail de formation. **Important** MinCount n'est pas une garantie permanente de capacité minimale. Cela garantit uniquement que le nombre minimum d'instances spécifié est disponible lorsque le groupe d'instances devient disponible pour la première fois`InService`. De brèves baisses du niveau inférieur MinCount peuvent survenir pendant le fonctionnement normal, par exemple lors de remplacements d'instances défectueux ou lors d'activités de maintenance. ### Comment MinCount fonctionne Lorsque vous créez ou mettez à jour un groupe d'instances avec MinCount cette option activée, le comportement suivant se produit : + **Nouveaux groupes d'instances** : le groupe d'instances conserve `Creating` son statut jusqu'à ce qu'au moins les MinCount instances soient correctement provisionnées et prêtes. Une fois ce seuil atteint, le groupe d'instances passe à`InService`. + **Groupes d'instances existants** : lors de MinCount la mise à jour d'un groupe d'instances existant, le statut passe à `Updating` jusqu'à ce que la nouvelle MinCount exigence soit satisfaite. + **Mise à l'échelle continue** : si TargetCount cette valeur est supérieure à MinCount, le système de mise à l'échelle continue de tenter de lancer des instances supplémentaires jusqu'à ce qu'elle TargetCount soit atteinte. + **Délai d'expiration et annulation** : s'il MinCount ne peut pas être satisfait dans les 3 heures, le système rétablit automatiquement le dernier bon état connu du groupe d'instances. Pour plus d'informations sur le comportement de restauration, consultez la section Comportement de [restauration automatique.](#sagemaker-hyperpod-scaling-eks-mincount-rollback) ### État du groupe d'instances pendant MinCount les opérations Les groupes d'instances MinCount configurés présentent le comportement d'état suivant : Création Pour les nouveaux groupes d'instances lorsque CurrentCount < MinCount. Le groupe d'instances conserve ce statut jusqu'à ce que la capacité minimale requise soit atteinte. Mise à jour Pour les groupes d'instances existants, quand MinCount est modifié et CurrentCount < MinCount. Le groupe d'instances conserve ce statut jusqu'à ce que la nouvelle exigence de capacité minimale soit satisfaite. InService Lorsque MinCount ≤ CurrentCount ≤ TargetCount. Le groupe d'instances est prêt à être utilisé et toutes les opérations de mutation sont débloquées. Pendant `Creating` notre `Updating` statut, les restrictions suivantes s'appliquent : + Opérations de mutation telles que `BatchAddClusterNodes``BatchDeleteClusterNodes`, ou `UpdateClusterSoftware` bloquées + Vous pouvez toujours modifier MinCount les TargetCount valeurs pour corriger les erreurs de configuration + La suppression de clusters et de groupes d'instances est toujours autorisée ### Comportement de restauration automatique Si un groupe d'instances ne peut pas l'atteindre MinCount dans les 3 heures, le système lance automatiquement une restauration pour éviter une attente indéfinie : + **Nouveaux groupes d'instances** : MinCount et TargetCount réinitialisés à (0, 0) + **Groupes d'instances existants** : MinCount et leurs valeurs par rapport au dernier `InService` état TargetCount sont restaurées + **Sélection des instances pour la résiliation** : si les instances doivent être résiliées lors de la restauration, le système sélectionne d'abord les instances défectueuses, puis celles qui ont été provisionnées le plus récemment. + **Transition de statut** : le groupe d'instances passe immédiatement à l'`InService`état après le lancement de la restauration, ce qui permet au système de dimensionnement continu de gérer la capacité en fonction des paramètres de restauration Le délai d'expiration de 3 heures est réinitialisé chaque fois MinCount qu'il est mis à jour. Par exemple, si vous effectuez MinCount plusieurs mises à jour, le délai d'expiration commence à courir à compter de la dernière mise à jour. ### MinCount événements Le système émet des événements spécifiques pour vous aider à suivre les MinCount opérations : + **Capacité minimale atteinte** : émise lorsqu'un groupe d'instances atteint avec succès le sien MinCount et passe à `InService` + **Annulation initiée : émise lorsque le délai de 3 heures expire et que la restauration** automatique commence Vous pouvez surveiller ces événements [ListClusterEvents](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html)pour suivre la progression de vos MinCount opérations. ### Utilisation de l'API MinCount est spécifié à l'aide du `MinInstanceCount` paramètre dans les configurations de groupes d'instances : ``` aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "worker-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 64, "MinInstanceCount": 50, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'" }' \ --node-provisioning-mode Continuous ``` Principales considérations relatives à MinCount l'utilisation : + `MinInstanceCount`doit être comprise entre 0 et la valeur `InstanceCount` (incluse) du groupe d'instances spécifié dans [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)ou dans la [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)demande + Le réglage `MinInstanceCount` sur 0 (par défaut) préserve le comportement standard de mise à l'échelle continue + La définition de la `MinInstanceCount` valeur égale à `InstanceCount` fournit un comportement de mise à l'échelle du tout ou rien + MinCount n'est disponible que pour les clusters dont la valeur `NodeProvisioningMode` est définie sur `Continuous` ## Groupes d'instances flexibles Les groupes d'instances flexibles vous permettent de spécifier plusieurs types d'instances au sein d'un même groupe d'instances. Cela simplifie la gestion des clusters en réduisant le nombre de groupes d'instances à créer et à gérer, en particulier pour les charges de travail d'inférence qui utilisent l'autoscaling. Avec des groupes d'instances flexibles, vous pouvez HyperPod : + Tentatives de mise en service d'instances à l'aide du premier type d'instance de votre liste + Retourne aux types d'instances suivants si la capacité n'est pas disponible + Met fin d'abord aux instances du type d'instance le moins prioritaire lors de la réduction **Note** Les groupes d'instances flexibles ne sont disponibles que pour les clusters dont la valeur `NodeProvisioningMode` est définie sur`Continuous`. Les `InstanceRequirements` propriétés `InstanceType` et s'excluent mutuellement : vous pouvez spécifier l'une ou l'autre, mais pas les deux. ### Création d'un cluster avec un groupe d'instances flexible À utiliser `InstanceRequirements` plutôt `InstanceType` que pour créer un groupe d'instances flexible. L'ordre des types d'instances dans la liste détermine la priorité du provisionnement. ``` aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET_AZ1'", "'$SUBNET_AZ2'"] }' \ --instance-groups '[{ "InstanceGroupName": "flexible-ig", "InstanceRequirements": { "InstanceTypes": ["ml.p5.48xlarge", "ml.p4d.24xlarge", "ml.g6.48xlarge"] }, "InstanceCount": 10, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'" }]' \ --node-provisioning-mode Continuous ``` ### Mise à l'échelle ciblée avec BatchAddClusterNodes Lorsque vous utilisez des groupes d'instances flexibles, vous pouvez [BatchAddClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchAddClusterNodes.html)ajouter des nœuds avec des types d'instances et des zones de disponibilité spécifiques. Cela est particulièrement utile lorsque le scalage automatique de Karpenter détermine le type d'instance et la zone de disponibilité optimaux pour votre charge de travail. ``` aws sagemaker batch-add-cluster-nodes \ --cluster-name $HP_CLUSTER_NAME \ --nodes-to-add '[ { "InstanceGroupName": "flexible-ig", "IncrementTargetCountBy": 1, "InstanceTypes": ["ml.p5.48xlarge"], "AvailabilityZones": ["us-west-2a"] } ]' ``` ### Afficher les détails des groupes d'instances flexibles [DescribeCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html)À utiliser pour afficher les types d'instances et la répartition par type de votre groupe d'instances flexible. La réponse inclut : + `InstanceRequirements`— Les types d'instance actuels et souhaités pour le groupe d'instances + `InstanceTypeDetails`— Une ventilation par type d'instance indiquant le nombre et la configuration de chaque type d'instance du groupe ### Utilisation de groupes d'instances flexibles avec la mise à l'échelle automatique de Karpenter Les groupes d'instances flexibles s'intègrent à HyperPod l'autoscaling géré par Karpenter. Pour plus d'informations sur la configuration de Karpenter, consultez[Autoscaling sur EKS SageMaker HyperPod](sagemaker-hyperpod-eks-autoscaling.md). Lorsque vous faites référence à un groupe d'instances flexible dans une `HyperPodNodeClass` configuration, Karpenter : + Détecte les types d'instances pris en charge à partir du groupe d'instances flexible + Sélectionne le type d'instance et la zone de disponibilité optimaux en fonction des exigences et des prix du pod + Adapte le groupe d'instances flexible à l'aide d'`BatchAddClusterNodes`appels ciblés avec le type d'instance et la zone de disponibilité sélectionnés **Note** Lorsque Karpenter gère le dimensionnement, il utilise sa propre logique de sélection basée sur les exigences et les prix des pods pour déterminer le type d'instance à provisionner. Cela diffère de la priorité d'ordre de liste utilisée par HyperPod le provisionnement natif (tel que `CreateCluster` et`UpdateCluster`), où le premier type d'instance de la liste est toujours tenté en premier. Il n'est donc plus nécessaire de créer des groupes d'instances distincts pour chaque type d'instance et de configurer manuellement Karpenter pour référencer plusieurs groupes.