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. # Gestion des SageMaker HyperPod clusters orchestrés par Amazon EKS Cette section fournit des conseils sur la gestion SageMaker HyperPod via l'interface utilisateur ou la AWS Command Line Interface (CLI) de la console SageMaker AI. Il explique comment effectuer diverses tâches connexes SageMaker HyperPod, que vous préfériez une interface visuelle ou que vous utilisiez des commandes. **Topics** + [Commencer à utiliser le support Amazon EKS dans SageMaker HyperPod](sagemaker-hyperpod-eks-prerequisites.md) + [Installation de packages sur le cluster Amazon EKS à l’aide de Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md) + [Configuration du contrôle d’accès basé sur les rôles Kubernetes](sagemaker-hyperpod-eks-setup-rbac.md) + [Amazon Machine Images personnalisées (AMIs) pour les SageMaker HyperPod clusters](hyperpod-custom-ami-support.md) + [Gestion des clusters SageMaker HyperPod EKS à l'aide de la SageMaker console](sagemaker-hyperpod-eks-operate-console-ui.md) + [Création de SageMaker HyperPod clusters à l'aide CloudFormation de modèles](smcluster-getting-started-eks-console-create-cluster-cfn.md) + [Gestion des clusters SageMaker HyperPod EKS à l'aide du AWS CLI](sagemaker-hyperpod-eks-operate-cli-command.md) + [HyperPod point de contrôle hiérarchisé géré](managed-tier-checkpointing.md) + [SageMaker HyperPod gouvernance des tâches](sagemaker-hyperpod-eks-operate-console-ui-governance.md) + [Rapports d'utilisation pour l'attribution des coûts dans SageMaker HyperPod](sagemaker-hyperpod-usage-reporting.md) + [Configuration du stockage pour les SageMaker HyperPod clusters orchestrés par Amazon EKS](sagemaker-hyperpod-eks-setup-storage.md) + [Utilisation du pilote Amazon EBS CSI sur SageMaker HyperPod les clusters EKS](sagemaker-hyperpod-eks-ebs.md) + [Configuration d'étiquettes et de teintures Kubernetes personnalisées sur Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-custom-labels-and-taints.md) # Commencer à utiliser le support Amazon EKS dans SageMaker HyperPod Outre les informations générales SageMaker HyperPod, consultez les exigences et considérations suivantes [Conditions préalables à l'utilisation SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) pour orchestrer des SageMaker HyperPod clusters à l'aide d'Amazon EKS. **Important** Vous pouvez configurer la configuration des ressources pour créer des SageMaker HyperPod clusters à l'aide du AWS Management Console et CloudFormation. Pour plus d’informations, consultez [Création d'un SageMaker HyperPod cluster avec l'orchestration Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md) et [Création de SageMaker HyperPod clusters à l'aide CloudFormation de modèles](smcluster-getting-started-eks-console-create-cluster-cfn.md). **Exigences** **Note** Avant de créer un HyperPod cluster, vous avez besoin d'un cluster Amazon EKS en cours d'exécution configuré avec VPC et installé à l'aide de Helm. + Si vous utilisez la console SageMaker AI, vous pouvez créer un cluster Amazon EKS sur la page de console du HyperPod cluster. Pour de plus amples informations, veuillez consulter [Création d'un SageMaker HyperPod cluster avec l'orchestration Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md). + Si vous utilisez une AWS CLI, vous devez créer un cluster Amazon EKS avant de créer un HyperPod cluster auquel vous pouvez vous associer. Pour plus d’informations, 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. Lorsque vous provisionnez votre cluster Amazon EKS, tenez compte des points suivants : 1. **Prise en charge des versions de Kubernetes** + SageMaker HyperPod prend en charge les versions 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 et 1.34 de Kubernetes. 1. **Mode d’authentification du cluster Amazon EKS** + Le mode d'authentification d'un cluster Amazon EKS pris en charge par SageMaker HyperPod are `API` and`API_AND_CONFIG_MAP`. 1. **Réseaux** + SageMaker HyperPod nécessite le plug-in Amazon VPC Container Network Interface (CNI) version 1.18.3 ou ultérieure. **Note** AWS Le [plugin VPC CNI pour Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) est le seul CNI pris en charge par. SageMaker HyperPod + Le [type de sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types) de votre VPC doit être privé HyperPod pour les clusters. 1. **Rôles IAM** + Assurez-vous que les rôles IAM nécessaires pour HyperPod sont configurés comme indiqué dans la [Gestion des identités et des accès AWS pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md) section. 1. **Modules complémentaires du cluster Amazon EKS** + Vous pouvez continuer à utiliser les différents modules complémentaires fournis par Amazon EKS, tels que [Kube-proxy](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-kube-proxy.html), CoreDNS[,](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-coredns.html) le plug-in [Amazon VPC Container Network Interface (CNI), l'identité du pod Amazon EKS, l' GuardDutyagent, le pilote Amazon Container Storage Interface (CSI](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-vpc-cni.html)), le pilote Mountpoint pour FSx Amazon S3 CSI, le Distro pour et l'agent Observability. AWS OpenTelemetry CloudWatch **Considérations relatives à la configuration de SageMaker HyperPod clusters avec Amazon EKS** + Vous devez utiliser des rôles IAM distincts en fonction du type de vos nœuds. Pour HyperPod les nœuds, utilisez un rôle basé sur[Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod). Pour les nœuds Amazon EKS, consultez [Rôle IAM de nœud Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html). + Vous pouvez provisionner et monter des volumes Amazon EBS supplémentaires sur des SageMaker HyperPod nœuds en utilisant deux approches : utiliser [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html#sagemaker-Type-ClusterInstanceGroupSpecification-InstanceStorageConfigs](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html#sagemaker-Type-ClusterInstanceGroupSpecification-InstanceStorageConfigs)pour le provisionnement de volumes au niveau du cluster (disponible lors de la création ou de la mise à jour de groupes d'instances) ou utiliser le pilote Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) pour une gestion dynamique des volumes au niveau des pods. Avec [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html#sagemaker-Type-ClusterInstanceGroupSpecification-InstanceStorageConfigs](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html#sagemaker-Type-ClusterInstanceGroupSpecification-InstanceStorageConfigs), définissez le [chemin local sur](https://kubernetes.io/docs/concepts/storage/volumes/#local) `/opt/sagemaker` pour monter correctement les volumes sur vos pods Amazon EKS. Pour plus d'informations sur le déploiement du contrôleur [Amazon EBS CSI](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) sur des HyperPod nœuds, consultez. [Utilisation du pilote Amazon EBS CSI sur SageMaker HyperPod les clusters EKS](sagemaker-hyperpod-eks-ebs.md) + Si vous utilisez des étiquettes de type d'instance pour définir des contraintes de planification, veillez à utiliser les types d'instance SageMaker AI ML préfixés par. `ml.` Par exemple, pour les instances P5, utilisez `ml.p5.48xlarge` à la place de `p5.48xlarge`. **Considérations relatives à la configuration du réseau pour les SageMaker HyperPod clusters avec Amazon EKS** + Chaque instance de HyperPod cluster prend en charge une interface réseau élastique (ENI). Pour connaître le nombre maximal de pods par type d’instance, reportez-vous au tableau suivant. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html) + Par défaut, seuls les pods avec `hostNetwork = true` ont accès au service de métadonnées d’instance (IMDS) d’Amazon EC2. Utilisez l'identité Amazon EKS Pod ou les [rôles IAM pour les comptes de service (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) pour gérer l'accès aux AWS informations d'identification des Pods. + HyperPod Les clusters orchestrés par EKS prennent en charge les deux modes d'adressage IP, ce qui permet de les configurer avec ou IPv4 pour des clusters IPv6 IPv6 Amazon EKS dans des environnements IPv6 VPC et de sous-réseau compatibles. Pour de plus amples informations, veuillez consulter [Configuration SageMaker HyperPod avec un Amazon VPC personnalisé](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc). **Considérations relatives à l'utilisation des HyperPod fonctionnalités de résilience du cluster** + Le remplacement automatique des nœuds n’est pas pris en charge pour les instances CPU. + L'agent HyperPod de surveillance de l'état de santé doit être installé pour que la restauration automatique des nœuds fonctionne. L’agent peut être installé à l’aide de Helm. Pour de plus amples informations, veuillez consulter [Installation de packages sur le cluster Amazon EKS à l’aide de Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md). + L'agent de vérification HyperPod approfondie de l'état et de surveillance de l'état prend en charge les instances GPU et Trn. + SageMaker L'IA inflige la coloration suivante aux nœuds lorsqu'ils sont soumis à des contrôles de santé approfondis : ``` effect: NoSchedule key: sagemaker.amazonaws.com/node-health-status value: Unschedulable ``` **Note** Vous ne pouvez pas ajouter de rejets personnalisés aux nœuds des groupes d’instances lorsque `DeepHealthChecks` est activé. Une fois que votre cluster Amazon EKS est en cours d'exécution, configurez-le à l'aide du gestionnaire de packages Helm comme indiqué [Installation de packages sur le cluster Amazon EKS à l’aide de Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md) avant de créer votre HyperPod cluster. # Installation de packages sur le cluster Amazon EKS à l’aide de Helm Avant de créer un SageMaker HyperPod cluster et de l'associer à un cluster Amazon EKS, vous devez installer des packages à l'aide de [Helm](https://helm.sh/), un gestionnaire de packages pour Kubernetes. Helm est un outil open source permettant de configurer un processus d’installation pour les clusters Kubernetes. Il permet l'automatisation et la rationalisation des installations de dépendances et simplifie les différentes configurations nécessaires pour préparer le cluster Amazon EKS en tant qu'orchestrateur (plan de contrôle) d'un cluster. SageMaker HyperPod L'équipe SageMaker HyperPod de service fournit un package de diagrammes Helm, qui regroupe les principales dépendances telles que les plug-ins, les device/EFA plug-ins, [Kubeflow Training Operator](https://www.kubeflow.org/docs/components/training/) et les configurations d'autorisation associées. **Important** Cette étape d’installation de Helm est requise. Si vous configurez votre cluster Amazon EKS à l’aide de la [AWS Management Console](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md) ou d’[CloudFormation](smcluster-getting-started-eks-console-create-cluster-cfn.md), vous pouvez ignorer cette étape, car l’installation est gérée automatiquement pendant le processus de configuration. Si vous configurez le cluster directement à l'aide du APIs, utilisez le graphique Helm fourni pour configurer votre cluster Amazon EKS. Si vous ne configurez pas votre cluster Amazon EKS à l'aide du graphique Helm fourni, le SageMaker HyperPod cluster risque de ne pas fonctionner correctement ou d'échouer complètement le processus de création. Le nom de l’espace de noms `aws-hyperpod` ne peut pas être modifié. 1. [Installez Helm](https://helm.sh/docs/intro/install/) sur votre ordinateur local. 1. Téléchargez les graphiques Helm SageMaker HyperPod fournis `helm_chart/HyperPodHelmChart` dans le [référentiel SageMaker HyperPod CLI](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart). ``` git clone https://github.com/aws/sagemaker-hyperpod-cli.git cd sagemaker-hyperpod-cli/helm_chart ``` 1. Mettez à jour les dépendances des Charts de Helm, prévisualisez les modifications qui seront apportées à votre cluster Kubernetes et installez les Charts de Helm. ``` helm dependencies update HyperPodHelmChart ``` ``` helm install hyperpod-dependencies HyperPodHelmChart --namespace kube-system --dry-run ``` ``` helm install hyperpod-dependencies HyperPodHelmChart --namespace kube-system ``` En résumé, l'installation de Helm configure différents composants pour votre cluster Amazon EKS, notamment la planification des tâches et la mise en file d'attente (Kueue), la gestion du stockage, MLflow l'intégration et Kubeflow. En outre, les graphiques installent les composants suivants pour les intégrer aux fonctionnalités de résilience du SageMaker HyperPod cluster, qui sont des composants obligatoires. + **Agent de surveillance de l'état** — Ceci installe l'agent de surveillance de l'état fourni par. SageMaker HyperPod Cela est nécessaire si vous souhaitez que votre HyperPod cluster soit surveillé. Les agents de surveillance de l’état sont fournis sous forme d’images Docker comme suit. Dans les Charts de Helm fournis, dans `values.yaml`, l’image est prédéfinie. L'agent prend en charge les instances basées sur le GPU et les Trainium-accelerator-based instances (`trn1`,`trn1n`,`inf2`). Il est installé dans l’espace de noms `aws-hyperpod`. Pour trouver votre URI compatible, consultez la section [Régions prises en charge et leur ECR URIs dans le sagemaker-hyperpod-cli référentiel sur GitHub](https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/readme.md#6-notes). + **Contrôle de santé approfondi** : cela permet de configurer a`ClusterRole`, a ServiceAccount (`deep-health-check-service-account`) dans l'espace de `aws-hyperpod` noms et a `ClusterRoleBinding` pour activer la fonctionnalité de contrôle de santé SageMaker HyperPod approfondi. Pour plus d'informations sur le fichier RBAC Kubernetes pour un contrôle de santé approfondi, consultez le fichier de configuration dans [https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/HyperPodHelmChart/charts/deep-health-check/templates/deep-health-check-rbac.yaml](https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/HyperPodHelmChart/charts/deep-health-check/templates/deep-health-check-rbac.yaml)le référentiel CLI. SageMaker HyperPod GitHub + **`job-auto-restart`**- Cela permet de configurer a`ClusterRole`, a ServiceAccount (`job-auto-restart`) dans l'espace de `aws-hyperpod` noms et a`ClusterRoleBinding`, pour activer la fonctionnalité de redémarrage automatique pour les tâches de PyTorch formation dans. SageMaker HyperPod Pour plus d'informations sur le fichier RBAC Kubernetes pour`job-auto-restart`, consultez le fichier de configuration dans [https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/HyperPodHelmChart/charts/job-auto-restart/templates/job-auto-restart-rbac.yaml](https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/HyperPodHelmChart/charts/job-auto-restart/templates/job-auto-restart-rbac.yaml)le référentiel CLI. SageMaker HyperPod GitHub + **Opérateur MPI Kubeflow** : l’[opérateur MPI](https://github.com/kubeflow/mpi-operator) est un opérateur Kubernetes qui simplifie l’exécution des charges de travail distribuées de Machine Learning (ML) et de calcul haute performance (HPC) à l’aide de l’interface MPI (Message Passing Interface) sur les clusters Kubernetes. Il installe MPI Operator v0.5. Il est installé dans l’espace de noms `mpi-operator`. + **`nvidia-device-plugin`**— Il s'agit d'un plug-in pour appareil Kubernetes qui vous permet d'exposer automatiquement NVIDIA à la consommation par GPUs les conteneurs de votre cluster Amazon EKS. Cela permet à Kubernetes d'allouer et de fournir un accès au conteneur demandé GPUs pour ce conteneur. Obligatoire lors de l’utilisation d’un type d’instance avec GPU. + **`neuron-device-plugin`** : il s’agit d’un plug-in d’appareil Kubernetes qui vous permet d’exposer automatiquement les puces AWS Inferentia pour qu’elles soient consommées par les conteneurs dans votre cluster Amazon EKS. Il permet à Kubernetes d'accéder aux puces AWS Inferentia sur les nœuds du cluster et de les utiliser. Obligatoire lors de l’utilisation d’un type d’instance Neuron. + **`aws-efa-k8s-device-plugin`**— Il s'agit d'un plug-in pour appareil Kubernetes qui permet d'utiliser AWS Elastic Fabric Adapter (EFA) sur les clusters Amazon EKS. EFA est un périphérique réseau qui fournit une communication à faible latence et à haut débit entre les instances d’un cluster. Obligatoire lors de l’utilisation d’un type d’instance compatible EFA. Pour plus d'informations sur la procédure d'installation à l'aide des diagrammes Helm fournis, consultez le [fichier README dans le référentiel SageMaker HyperPod CLI](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart). # Configuration du contrôle d’accès basé sur les rôles Kubernetes Les administrateurs de clusters doivent également configurer le [contrôle d'accès basé sur les rôles (RBAC) Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) pour que les utilisateurs de data scientists puissent utiliser la [SageMaker HyperPod CLI](https://github.com/aws/sagemaker-hyperpod-cli) pour exécuter des charges de travail sur HyperPod des clusters orchestrés avec Amazon EKS. ## Option 1 : Configuration de RBAC à l’aide des Charts de Helm L'équipe SageMaker HyperPod de service fournit un sous-graphique Helm pour configurer le RBAC. Pour en savoir plus, veuillez consulter la section [Installation de packages sur le cluster Amazon EKS à l’aide de Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md). ## Option 2 : Configuration manuelle de RBAC Créez `ClusterRole` et `ClusterRoleBinding` avec le privilège minimum, et créez `Role` et `RoleBinding` avec des autorisations de mutation. **Pour créer `ClusterRole` et `ClusterRoleBinding` pour le rôle IAM de scientifique des données** Créez un fichier de configuration `cluster_level_config.yaml` au niveau du cluster comme suit. ``` kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: hyperpod-scientist-user-cluster-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"] - apiGroups: [""] resources: ["nodes"] verbs: ["list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: hyperpod-scientist-user-cluster-role-binding subjects: - kind: Group name: hyperpod-scientist-user-cluster-level apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: hyperpod-scientist-user-cluster-role # this must match the name of the Role or ClusterRole you wish to bind to apiGroup: rbac.authorization.k8s.io ``` Appliquez la configuration au cluster EKS. ``` kubectl apply -f cluster_level_config.yaml ``` **Pour créer un rôle et RoleBinding dans un espace de noms** Il s’agit des opérateurs d’entraînement de l’espace de noms qui exécutent les tâches d’entraînement et Resiliency surveillera par défaut. La reprise automatique des tâches peut être prise en charge uniquement dans l’espace de noms `kubeflow` ou dans l’espace de noms préfixé par `aws-hyperpod`. Créez un fichier de configuration de rôle `namespace_level_role.yaml` comme suit. Cet exemple crée un rôle dans l’espace de noms `kubeflow`. ``` kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: kubeflow name: hyperpod-scientist-user-namespace-level-role ### # 1) add/list/describe/delete pods # 2) get/list/watch/create/patch/update/delete/describe kubeflow pytroch job # 3) get pod log ### rules: - apiGroups: [""] resources: ["pods"] verbs: ["create", "get"] - apiGroups: [""] resources: ["nodes"] verbs: ["get", "list"] - apiGroups: [""] resources: ["pods/log"] verbs: ["get", "list"] - apiGroups: [""] resources: ["pods/exec"] verbs: ["get", "create"] - apiGroups: ["kubeflow.org"] resources: ["pytorchjobs", "pytorchjobs/status"] verbs: ["get", "list", "create", "delete", "update", "describe"] - apiGroups: [""] resources: ["configmaps"] verbs: ["create", "update", "get", "list", "delete"] - apiGroups: [""] resources: ["secrets"] verbs: ["create", "get", "list", "delete"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: kubeflow name: hyperpod-scientist-user-namespace-level-role-binding subjects: - kind: Group name: hyperpod-scientist-user-namespace-level apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: hyperpod-scientist-user-namespace-level-role # this must match the name of the Role or ClusterRole you wish to bind to apiGroup: rbac.authorization.k8s.io ``` Appliquez la configuration au cluster EKS. ``` kubectl apply -f namespace_level_role.yaml ``` ## Création d’une entrée d’accès pour les groupes Kubernetes Après avoir configuré RBAC à l’aide de l’une des deux options ci-dessus, utilisez l’exemple de commande suivant pour remplacer les informations nécessaires. ``` aws eks create-access-entry \ --cluster-name \ --principal-arn arn:aws:iam:::role/ScientistUserRole \ --kubernetes-groups '["hyperpod-scientist-user-namespace-level","hyperpod-scientist-user-cluster-level"]' ``` Pour le paramètre `principal-arn`, vous devez utiliser les [Utilisateurs IAM pour les scientifiques](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-user). # Amazon Machine Images personnalisées (AMIs) pour les SageMaker HyperPod clusters À l'aide d'Amazon Machine Images (AMIs) de base fournies et rendues publiques par Amazon SageMaker HyperPod, vous pouvez créer des produits personnalisés AMIs. Avec une AMI personnalisée, vous pouvez créer des environnements spécialisés pour les charges de travail d’IA avec des piles de logiciels préconfigurées, des personnalisations de pilotes, des dépendances propriétaires et des agents de sécurité. Cette fonctionnalité élimine le besoin d’amorçage complexe après lancement à l’aide de scripts de configuration de cycle de vie. Grâce à la personnalisation AMIs, vous pouvez standardiser les environnements à différentes étapes, accélérer les temps de démarrage et avoir un contrôle total sur votre environnement d'exécution tout en tirant parti des capacités SageMaker HyperPod de l'infrastructure et des avantages de l'évolutivité. Cela vous permet de garder le contrôle de votre infrastructure d'IA tout en bénéficiant SageMaker HyperPod du temps d'exécution de base optimisé. Vous pouvez tirer parti des images de base SageMaker HyperPod optimisées pour les performances en ajoutant des agents de sécurité, des outils de conformité et des bibliothèques spécialisées, tout en préservant tous les avantages de la formation distribuée. Cette fonctionnalité supprime le choix auparavant requis entre l’optimisation de l’infrastructure et les politiques de sécurité organisationnelles. L’expérience AMI personnalisée s’intègre parfaitement avec les flux de travail de sécurité d’entreprise établis. Les équipes de sécurité créent des images renforcées en utilisant SageMaker HyperPod le public AMIs comme base, et les équipes de la plateforme d'IA peuvent les personnaliser AMIs lors de la création ou de la mise à jour de clusters via le SageMaker HyperPod APIs. Ils APIs valident la compatibilité des images, gèrent les autorisations nécessaires et assurent la rétrocompatibilité afin que les flux de travail existants continuent de fonctionner. Les organisations dotées de protocoles de sécurité stricts peuvent éliminer l’alternative sujette aux erreurs consistant à installer des agents de sécurité au moment de l’exécution par le biais de scripts de cycle de vie. En s'alignant sur les pratiques de sécurité des entreprises plutôt que d'obliger les organisations à adapter leurs protocoles aux limites de l'entreprise, SageMaker HyperPod la personnalisation AMIs élimine un obstacle courant à l'adoption par les organisations soucieuses de la sécurité qui exécutent des charges de travail critiques liées à l'IA. Pour les notes de publication sur les mises à jour destinées au public AMIs, voir[Publications d’AMI publiques](sagemaker-hyperpod-release-public-ami.md). Pour savoir comment créer une AMI personnalisée et comment l'utiliser dans vos HyperPod clusters, consultez les rubriques suivantes. **Topics** + [Création d’une AMI personnalisée](hyperpod-custom-ami-how-to.md) + [Gestion de clusters avec personnalisation AMIs](hyperpod-custom-ami-cluster-management.md) # Création d’une AMI personnalisée La page suivante explique comment créer une Amazon Machine Image (AMI) personnalisée à l'aide d'Amazon SageMaker HyperPod base AMIs. Vous commencez par sélectionner une AMI de base, puis vous créez votre propre AMI personnalisée en utilisant l’une des méthodes courantes de création de nouvelles images, telles que l’ AWS CLI. ## Sélectionnez une AMI SageMaker HyperPod de base Vous pouvez sélectionner une AMI SageMaker HyperPod de base à l'aide de l'une des méthodes suivantes. ### AWS sélection de la console Vous pouvez sélectionner public SageMaker HyperPod AMIs via la AWS console ou à l'aide de l'appel `DescribeImages` d'API. SageMaker HyperPod AMIs sont publics et visibles partout Compte AWS. Vous pouvez les trouver dans le catalogue des AMI Amazon EC2 en appliquant un filtre pour rechercher des entités publiques AMIs détenues par Amazon. À rechercher SageMaker HyperPod AMIs dans la console : 1. Connectez-vous à la console Amazon EC2. 1. Dans le panneau de navigation de gauche, choisissez **AMIs**. 1. Dans le menu déroulant **Type d’image**, sélectionnez **Images publiques**. 1. Dans les filtres de la barre de recherche, définissez le filtre **Alias du propriétaire** sur **amazon**. 1. Recherchez le AMIs préfixé **HyperPodEKS** et sélectionnez l'AMI (de préférence la plus récente) adaptée à votre cas d'utilisation. Par exemple, vous pouvez choisir une AMI entre Kubernetes 1.31 et Kubernetes 1.30. ### Récupérez le dernier ID d'AMI public via le AWS CLI Si vous souhaitez toujours utiliser la dernière version de l'AMI publique, il est plus efficace d'utiliser le paramètre SageMaker HyperPod SSM public qui contient la valeur du dernier ID d'AMI publié par SageMaker HyperPod. L’exemple suivant montre comment extraire l’ID de la dernière AMI à l’aide de l’ AWS CLI : ``` aws ssm get-parameter \ --name "/aws/service/sagemaker-hyperpod/ami/x86_64/eks-1.31-amazon-linux-2/latest/ami-id" \ --region us-east-1 \ --query "Parameter.Value" \ --output text ``` **Note** Remplacez le nom du paramètre par la version de Kubernetes correspondante selon les besoins. Par exemple, si vous souhaitez utiliser Kubernetes 1.30, utilisez le paramètre suivant : `/aws/service/hyperpod/ami/x86_64/eks-1.30-amazon-linux-2/latest/ami-id`. ## Génération de votre AMI personnalisée Après avoir sélectionné une AMI SageMaker HyperPod publique, utilisez-la comme AMI de base pour créer votre propre AMI personnalisée à l'aide de l'une des méthodes suivantes. Notez qu'il ne s'agit pas d'une liste exhaustive pour la construction AMIs. Vous pouvez utiliser n'importe quelle méthode de votre choix pour construire AMIs. SageMaker HyperPod n'a aucune recommandation spécifique. + **AWS Console de gestion** : vous pouvez lancer une instance Amazon EC2 à l'aide de l' SageMaker HyperPod AMI, effectuer les personnalisations souhaitées, puis créer une AMI à partir de cette instance. + **AWS CLI** : vous pouvez également utiliser la commande `aws ec2 create-image` pour créer une AMI à partir d’une instance Amazon EC2 existante après avoir effectué la personnalisation. + **HashiCorp Packer** : Packer est un outil open source HashiCorp qui vous permet de créer des images de machine identiques pour plusieurs plateformes à partir d'une configuration source unique. Il prend en charge AMIs la création AWS, ainsi que la création d'images pour d'autres fournisseurs de cloud et plateformes de virtualisation. + **Image Builder** : EC2 Image Builder est un service AWS entièrement géré qui facilite l’automatisation de la création, de la maintenance, de la validation, du partage et du déploiement d’images Linux ou Windows Server. Pour plus d’informations, consultez le [Guide de l’utilisateur EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html). ### Créez une AMI personnalisée avec un AWS KMS chiffrement géré par le client Les sections suivantes décrivent comment créer une AMI personnalisée à l'aide d'une AWS KMS clé gérée par le client pour chiffrer les volumes de votre HyperPod cluster. Pour plus d'informations sur les clés gérées par le client HyperPod et sur l'octroi des autorisations requises en matière de politique des clés IAM et KMS, consultez[AWS KMS key Chiffrement géré par le client pour SageMaker HyperPod](smcluster-cmk.md). Si vous envisagez d'utiliser une AMI personnalisée chiffrée à l'aide d'une clé gérée par le client, assurez-vous de chiffrer également le volume racine Amazon EBS de votre HyperPod cluster avec la même clé. #### AWS CLI exemple : créer une nouvelle AMI à l'aide d'EC2 Image Builder et d' HyperPod une image de base L’exemple suivant montre comment créer une AMI à l’aide d’Image Builder avec le chiffrement AWS KMS  : ``` aws imagebuilder create-image-recipe \ name "hyperpod-custom-recipe" \ version "1.0.0" \ parent-image "" \ block-device-mappings DeviceName="/dev/xvda",Ebs={VolumeSize=100,VolumeType=gp3,Encrypted=true,KmsKeyId=arn:aws:kms:us-east-1:111122223333:key/key-id,DeleteOnTermination=true} ``` #### Console Amazon EC2 : création d’une nouvelle AMI à partir d’une instance Amazon EC2 Pour créer une AMI à partir d’une instance Amazon EC2 en utilisant la console Amazon EC2 : 1. Cliquez avec le bouton droit sur votre instance Amazon EC2 personnalisée et choisissez **Créer l’image**. 1. Dans la section **Chiffrement**, sélectionnez **Chiffrer les instantanés**. 1. Sélectionnez votre clé KMS dans le menu déroulant. Par exemple : `arn:aws:kms:us-east-2:111122223333:key/` ou utilisez l’alias de clé : `alias/`. #### AWS CLI exemple : créer une nouvelle AMI à partir d'une instance Amazon EC2 Utilisez la commande `aws ec2 create-image` avec le chiffrement AWS KMS  : ``` aws ec2 create-image \ instance-id "" \ name "MyCustomHyperPodAMI" \ description "Custom HyperPod AMI" \ block-device-mappings '[ { "DeviceName": "/dev/xvda", "Ebs": { "Encrypted": true, "KmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id", "VolumeType": "gp2" } } ]' ``` # Gestion de clusters avec personnalisation AMIs Une fois l'AMI personnalisée créée, vous pouvez l'utiliser pour créer ou mettre à jour un SageMaker HyperPod cluster Amazon. Vous pouvez également augmenter verticalement ou ajouter des groupes d’instances qui utilisent la nouvelle AMI. ## Autorisations requises pour les opérations du cluster Ajoutez les autorisations suivantes à l'utilisateur administrateur du cluster qui gère et configure les SageMaker HyperPod clusters. L'exemple de politique suivant inclut l'ensemble minimal d'autorisations permettant aux administrateurs de clusters d'exécuter le SageMaker HyperPod noyau APIs et de gérer les SageMaker HyperPod clusters avec une AMI personnalisée. Notez que les autorisations de partage d’instantanés d’AMI et EBS d’AMI sont incluses par le biais des autorisations d’API `ModifyImageAttribute` et `ModifySnapshotAttribute` dans le cadre de la politique suivante. Pour réduire la portée des autorisations de partage, procédez comme suit : + Ajoutez des balises pour contrôler les autorisations de partage d’AMI sur l’AMI et l’instantané d’AMI. Par exemple, vous pouvez baliser l’AMI avec `AllowSharing` défini sur `true`. + Ajoutez la clé de contexte dans la politique pour autoriser le partage d'AMI uniquement pour les AMIs balises associées à certaines balises. La politique suivante est une politique limitée visant à garantir que seuls les AMIs `AllowSharing` tags `true` sont autorisés. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/your-execution-role-name" }, { "Effect": "Allow", "Action": [ "sagemaker:CreateCluster", "sagemaker:DeleteCluster", "sagemaker:DescribeCluster", "sagemaker:DescribeClusterNode", "sagemaker:ListClusterNodes", "sagemaker:ListClusters", "sagemaker:UpdateCluster", "sagemaker:UpdateClusterSoftware", "sagemaker:BatchDeleteClusterNodes", "eks:DescribeCluster", "eks:CreateAccessEntry", "eks:DescribeAccessEntry", "eks:DeleteAccessEntry", "eks:AssociateAccessPolicy", "iam:CreateServiceLinkedRole", "ec2:DescribeImages", "ec2:DescribeSnapshots" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:ModifyImageAttribute", "ec2:ModifySnapshotAttribute" ], "Resource": "*", "Condition": { "StringEquals": { "ec2:ResourceTag/AllowSharing": "true" } } } ] } ``` ------ **Important** Si vous prévoyez d’utiliser une AMI personnalisée chiffrée, veillez à ce que votre clé KMS réponde aux autorisations décrites dans [AWS KMS key Chiffrement géré par le client pour SageMaker HyperPod](smcluster-cmk.md). En outre, assurez-vous que la clé KMS de votre AMI personnalisée est également utilisée pour chiffrer le volume racine Amazon EBS de votre cluster. ## Créer un cluster Vous pouvez spécifier votre AMI personnalisée dans le champ `ImageId` pour l’opération `CreateCluster`. Les exemples suivants montrent comment créer un cluster avec une AMI personnalisée, avec ou sans clé gérée par AWS KMS le client pour chiffrer les volumes du cluster. ------ #### [ Standard example ] L’exemple suivant montre comment créer un cluster avec une AMI personnalisée. ``` aws sagemaker create-cluster \ --cluster-name \ --orchestrator 'Eks={ClusterArn=''}' \ --node-provisioning-mode Continuous \ --instance-groups '{ "InstanceGroupName": "", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "", "OnCreate": "on_create_noop.sh" }, "ImageId": "", "ExecutionRole": "", "ThreadsPerCore": 1, "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 200 } } ] }' --vpc-config '{ "SecurityGroupIds": [""], "Subnets": [""] }' ``` ------ #### [ Customer managed key example ] L'exemple suivant montre comment créer un cluster avec une AMI personnalisée tout en spécifiant votre propre clé gérée par le AWS KMS client pour chiffrer les volumes Amazon EBS du cluster. Il est possible de spécifier différentes clés gérées par le client pour le volume racine et le volume de stockage de l'instance. Si vous n'utilisez pas de clés gérées par le client `InstanceStorageConfigs` sur le terrain, une clé KMS AWS détenue est utilisée pour chiffrer les volumes. Si vous utilisez des clés différentes pour le volume racine et les volumes de stockage de l'instance secondaire, définissez les politiques de clés KMS requises sur vos deux clés. ``` aws sagemaker create-cluster \ --cluster-name \ --orchestrator 'Eks={ClusterArn=''}' \ --node-provisioning-mode Continuous \ --instance-groups '{ "InstanceGroupName": "", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "", "OnCreate": "on_create_noop.sh" }, "ImageId": "", "ExecutionRole": "", "ThreadsPerCore": 1, "InstanceStorageConfigs": [ # Root volume configuration { "EbsVolumeConfig": { "RootVolume": True, "VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id" } }, # Instance storage volume configuration { "EbsVolumeConfig": { "VolumeSizeInGB": 100, "VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id" } } ] }' --vpc-config '{ "SecurityGroupIds": [""], "Subnets": [""] }' ``` ------ ## Mise à jour du logiciel du cluster Si vous souhaitez mettre à jour un groupe d’instances existant sur votre cluster avec votre AMI personnalisée, vous pouvez utiliser l’opération `UpdateClusterSoftware` et spécifier votre AMI personnalisée dans le champ `ImageId`. Notez que la nouvelle image est appliquée à tous les groupes d’instances de votre cluster, à moins que vous spécifiiez le nom d’un groupe d’instances spécifique dans votre demande. L’exemple suivant montre comment mettre à jour le logiciel de plateforme d’un cluster avec une AMI personnalisée : ``` aws sagemaker update-cluster-software \ --cluster-name \ --instance-groups \ --image-id ``` ## Augmentation verticale d’un groupe d’instances Les exemples suivants montrent comment augmenter la taille d'un groupe d'instances pour un cluster à l'aide d'une AMI personnalisée, avec ou sans clé gérée par le AWS KMS client pour le chiffrement. ------ #### [ Standard example ] L’exemple suivant montre comment augmenter verticalement un groupe d’instances à l’aide d’une AMI personnalisée. ``` aws sagemaker update-cluster \ --cluster-name --instance-groups '[{ "InstanceGroupName": "", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "", "OnCreate": "on_create_noop.sh" }, "ExecutionRole": "", "ThreadsPerCore": 1, "ImageId": "" }]' ``` ------ #### [ Customer managed key example ] L'exemple suivant montre comment mettre à jour et étendre votre cluster avec une AMI personnalisée tout en spécifiant votre propre clé gérée par le AWS KMS client pour chiffrer les volumes Amazon EBS du cluster. Il est possible de spécifier différentes clés gérées par le client pour le volume racine et le volume de stockage de l'instance. Si vous n'utilisez pas de clés gérées par le client `InstanceStorageConfigs` sur le terrain, une clé KMS AWS détenue est utilisée pour chiffrer les volumes. Si vous utilisez des clés différentes pour le volume racine et les volumes de stockage de l'instance secondaire, définissez les politiques de clés KMS requises sur vos deux clés. ``` aws sagemaker update-cluster \ --cluster-name --instance-groups '[{ "InstanceGroupName": "", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "", "OnCreate": "on_create_noop.sh" }, "ExecutionRole": "", "ThreadsPerCore": 1, "ImageId": "", "InstanceStorageConfigs": [ # Root volume configuration { "EbsVolumeConfig": { "RootVolume": True, "VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id" } }, # Instance storage volume configuration { "EbsVolumeConfig": { "VolumeSizeInGB": 100, "VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id" } } ] }]' ``` ------ ## Ajout d’un groupe d’instances L’exemple suivant montre comment ajouter un groupe d’instances à un cluster à l’aide d’une AMI personnalisée : ``` aws sagemaker update-cluster \ --cluster-name "" \ --instance-groups '{ "InstanceGroupName": "", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "", "OnCreate": "on_create_noop.sh" }, "ExecutionRole": "", "ThreadsPerCore": 1, "ImageId": "" }' '{ "InstanceGroupName": "", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 1, "LifeCycleConfig": { "SourceS3Uri": "", "OnCreate": "on_create_noop.sh" }, "ExecutionRole": "", "ThreadsPerCore": 1, "ImageId": "" }' ``` # Gestion des clusters SageMaker HyperPod EKS à l'aide de la SageMaker console Les rubriques suivantes fournissent des conseils sur la manière de gérer SageMaker HyperPod dans la console SageMaker AI. **Topics** + [Création d'un SageMaker HyperPod cluster avec l'orchestration Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md) + [Navigation, affichage et modification de SageMaker HyperPod clusters](sagemaker-hyperpod-eks-operate-console-ui-browse-view-edit.md) + [Supprimer un SageMaker HyperPod cluster](sagemaker-hyperpod-eks-operate-console-ui-delete-cluster.md) # Création d'un SageMaker HyperPod cluster avec l'orchestration Amazon EKS Le didacticiel suivant explique comment créer un nouveau SageMaker HyperPod cluster et le configurer avec l'orchestration Amazon EKS via l'interface utilisateur de la console SageMaker AI. **Topics** + [Créer un cluster](#smcluster-getting-started-eks-console-create-cluster-page) + [déployer des ressources ;](#smcluster-getting-started-eks-console-create-cluster-deploy) ## Créer un cluster Pour accéder à la page **SageMaker HyperPod Clusters** et choisir l'orchestration Amazon EKS, procédez comme suit. 1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/). 1. Choisissez **HyperPod Clusters** dans le volet de navigation de gauche, puis **Gestion des clusters**. 1. Sur la page **SageMaker HyperPod Clusters**, choisissez **Create HyperPod cluster**. 1. Dans le menu déroulant **Créer un HyperPod cluster**, sélectionnez **Orchestrated by Amazon EKS**. 1. Sur la page de création du cluster EKS, vous verrez deux options. Choisissez celle qui correspond le mieux à vos besoins. 1. **Configuration rapide** : pour commencer immédiatement avec les paramètres par défaut, choisissez **Configuration rapide**. Grâce à cette option, l' SageMaker IA créera de nouvelles ressources telles que le VPC, les sous-réseaux, les groupes de sécurité, le compartiment Amazon S3, le rôle IAM et FSx pour Lustre lors de la création de votre cluster. 1. **Configuration personnalisée** : pour intégrer des ressources AWS existantes ou pour respecter des exigences spécifiques de mise en réseau, de sécurité ou de stockage, choisissez **Configuration personnalisée**. Avec cette option, vous pouvez choisir d’utiliser les ressources existantes ou d’en créer de nouvelles, et vous pouvez personnaliser la configuration qui répond le mieux à vos besoins. ## Configuration rapide Dans la section **Configuration rapide**, suivez ces étapes pour créer votre HyperPod cluster avec l'orchestration Amazon EKS. ### Paramètres généraux Attribuez un nom au nouveau cluster. Vous ne pourrez pas modifier le nom après la création du cluster. ### Groupes d’instances Pour ajouter un groupe d’instances, choisissez **Ajouter un groupe**. Chaque groupe d’instances peut être configuré différemment et vous pouvez créer un cluster hétérogène composé de plusieurs groupes d’instances avec divers types d’instances. Pour déployer un cluster, vous devez ajouter au moins un groupe d’instances. Procédez comme suit pour ajouter un groupe d’instances. 1. Pour **Type de groupe d’instances**, choisissez **Standard** ou **Groupe d’instances restreint (RIG)**. Généralement, vous choisissez **Standard**, qui fournit un environnement informatique à usage général sans restrictions de sécurité supplémentaires. **Groupe d’instances restreint (RIG)** est un environnement spécialisé pour la personnalisation de modèles de fondation tels qu’Amazon Nova. Pour plus d'informations sur la configuration de RIG pour la personnalisation des modèles Amazon Nova, consultez la section Personnalisation d'Amazon Nova SageMaker HyperPod dans le guide de l'[utilisateur d'Amazon Nova 1.0 ou dans le guide](https://docs.aws.amazon.com//nova/latest/userguide/nova-hp.html) de l'[utilisateur d'Amazon Nova 2.0](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp.html). 1. Pour **Nom**, spécifiez le nom du groupe d’instances. 1. Pour **Capacité de l’instance**, choisissez une capacité à la demande ou un plan d’entraînement pour réserver vos ressources de calcul. 1. Pour **Type d’instance**, choisissez l’instance pour le groupe d’instances. **Important** Veillez à choisir un type d’instance doté de quotas suffisants et suffisamment d’adresses IP non attribuées pour votre compte. Pour consulter ou demander des quotas supplémentaires, consultez [SageMaker HyperPod quotas](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas). 1. Pour **Quantité d’instances**, spécifiez un entier ne dépassant pas le quota d’instances pour l’utilisation du cluster. Pour ce didacticiel, entrez **1** pour les trois groupes. 1. Pour **Zone de disponibilité cible**, choisissez la zone de disponibilité dans laquelle vos instances seront provisionnées. La zone de disponibilité doit correspondre à l’emplacement de votre capacité de calcul accélérée. 1. Pour **Autre volume de stockage par instance (Go) – facultatif**, spécifiez un entier compris entre 1 et 16 384 pour définir la taille d’un volume Elastic Block Store (EBS) supplémentaire en gigaoctets (Go). Le volume EBS est attaché à chaque instance du groupe d’instances. Le chemin de montage par défaut pour le volume EBS supplémentaire est `/opt/sagemaker`. Une fois le cluster créé avec succès, vous pouvez accéder par SSH aux instances du cluster (nœuds) et vérifier si le volume EBS est correctement monté en exécutant la commande `df -h`. L’attachement d’un volume EBS supplémentaire fournit un stockage stable, hors instance et persistant de manière indépendante, comme décrit dans la section [Volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) du *Guide de l’utilisateur Amazon Elastic Block Store*. 1. Pour **Vérifications de surveillance approfondie de l’état des instances**, choisissez votre option. Des vérifications de surveillance approfondie de l’état surveillent l’état des instances lors de leur création et après les mises à jour logicielles. Elles permettent de récupérer automatiquement les instances défectueuses par le biais de redémarrages ou de remplacements lorsqu’elles sont activées. 1. Si votre type d'instance prend en charge le partitionnement GPU avec un GPU multi-instance (MIG), vous pouvez activer la configuration de partition GPU pour le groupe d'instances. Le partitionnement du GPU vous permet de le GPUs diviser en partitions isolées plus petites pour une meilleure utilisation des ressources. Pour de plus amples informations, veuillez consulter [Utilisation de partitions GPU dans Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md). 1. Activez **l'option Utiliser la partition GPU** pour activer le partitionnement GPU pour ce groupe d'instances. 1. Sélectionnez un **profil de partition GPU** parmi les options disponibles pour votre type d'instance. Chaque profil définit la configuration de la tranche GPU et l'allocation de mémoire. 1. Choisissez **Ajouter un groupe d’instances**. ### Paramètres par défaut de configuration rapide Cette section répertorie tous les paramètres par défaut pour la création de votre cluster, y compris toutes les nouvelles AWS ressources qui seront créées au cours du processus de création du cluster. Passez en revue les paramètres par défaut. ## Configuration personnalisée Dans la section **Configuration personnalisée**, suivez ces étapes pour créer votre premier HyperPod cluster avec l'orchestration Amazon EKS. ### Paramètres généraux Attribuez un nom au nouveau cluster. Vous ne pourrez pas modifier le nom après la création du cluster. Pour **Restauration d’instance**, choisissez **Automatique – *recommandé*** ou **Aucun**. ### Réseaux Configurez les paramètres réseau au sein in-and-out du cluster et du cluster. Pour l'orchestration du SageMaker HyperPod cluster avec Amazon EKS, le VPC est automatiquement défini sur celui configuré avec le cluster EKS que vous avez sélectionné. 1. Pour le **VPC**, choisissez votre propre VPC si vous en avez déjà un qui permet à l' SageMaker IA d'accéder à votre VPC. Pour créer un nouveau VPC, suivez les instructions de la section [Création d’un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*. Vous pouvez le laisser sur **Aucun** pour utiliser le VPC SageMaker AI par défaut. 1. Pour le **bloc d'adresse IPv4 CIDR VPC**, entrez l'adresse IP de départ de votre VPC. 1. Pour les **zones de disponibilité**, choisissez les zones de disponibilité (AZ) dans lesquelles HyperPod vous créerez des sous-réseaux pour votre cluster. Choisissez AZs celui qui correspond à l'emplacement de votre capacité de calcul accélérée. 1. Pour **Groupe(s) de sécurité**, choisissez les groupes de sécurité attachés au cluster Amazon EKS ou dont le trafic entrant est autorisé par le groupe de sécurité associé au cluster Amazon EKS. Pour créer de nouveaux groupes de sécurité, accédez à la console Amazon VPC. ### Orchestration Suivez ces étapes pour créer ou sélectionner un cluster Amazon EKS à utiliser comme orchestrateur. 1. Pour **Cluster EKS**, choisissez de créer un nouveau cluster Amazon EKS ou d’utiliser un cluster existant. Si vous devez créer un nouveau cluster EKS, vous pouvez le créer à partir de la section Cluster EKS sans avoir à ouvrir la console Amazon EKS. **Note** Le sous-réseau VPC que vous choisissez HyperPod doit être privé. Après avoir soumis une nouvelle demande de création de cluster EKS, attendez que le cluster EKS devienne `Active`. 1. Pour **Version de Kubernetes**, choisissez une version dans le menu déroulant. Pour plus d’informations sur les versions de Kubernetes, consultez [Comprendre le cycle de vie des versions de Kubernetes sur EKS](https://docs.aws.amazon.com//eks/latest/userguide/kubernetes-versions.html) dans le *Guide de l’utilisateur Amazon EKS*. 1. Pour **Opérateurs**, choisissez **Utiliser les graphiques Helm et les modules complémentaires par défaut** ou **N’installez pas d’opérateurs**. L’option par défaut est **Utiliser les graphiques Helm et les modules complémentaires par défaut**, qui sera utilisée pour installer les opérateurs sur le cluster EKS. Pour plus d'informations sur les graphiques Helm par défaut et les modules complémentaires, consultez [https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart/HyperPodHelmChart](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart/HyperPodHelmChart)le GitHub référentiel. Pour de plus amples informations, veuillez consulter [Installation de packages sur le cluster Amazon EKS à l’aide de Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md). 1. Pour **Opérateurs activés**, consultez la liste des opérateurs activés. Pour modifier les opérateurs, décochez la case en haut et choisissez les opérateurs à activer pour le cluster EKS. **Note** Pour l'utiliser HyperPod avec EKS, vous devez installer des cartes Helm et des modules complémentaires qui activent les opérateurs sur le cluster EKS. Ces composants configurent EKS en tant que plan de contrôle HyperPod et fournissent la configuration nécessaire à la gestion et à l'orchestration de la charge de travail. ### Groupes d’instances Pour ajouter un groupe d’instances, choisissez **Ajouter un groupe**. Chaque groupe d’instances peut être configuré différemment et vous pouvez créer un cluster hétérogène composé de plusieurs groupes d’instances avec divers types d’instances. Pour déployer un cluster, vous devez ajouter au moins un groupe d’instances. Procédez comme suit pour ajouter un groupe d’instances. 1. Pour **Type de groupe d’instances**, choisissez **Standard** ou **Groupe d’instances restreint (RIG)**. Généralement, vous choisissez **Standard**, qui fournit un environnement informatique à usage général sans restrictions de sécurité supplémentaires. **Groupe d’instances restreint (RIG)** est un environnement spécialisé pour la personnalisation de modèles de fondation tels qu’Amazon Nova. Pour plus d'informations sur la configuration de RIG pour la personnalisation des modèles Amazon Nova, consultez la section Personnalisation d'Amazon Nova SageMaker HyperPod dans le guide de l'[utilisateur d'Amazon Nova 1.0 ou dans le guide](https://docs.aws.amazon.com//nova/latest/userguide/nova-hp.html) de l'[utilisateur d'Amazon Nova 2.0](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp.html). 1. Pour **Nom**, spécifiez le nom du groupe d’instances. 1. Pour **Capacité de l’instance**, choisissez une capacité à la demande ou un plan d’entraînement pour réserver vos ressources de calcul. 1. Pour **Type d’instance**, choisissez l’instance pour le groupe d’instances. **Important** Veillez à choisir un type d’instance doté de quotas suffisants et suffisamment d’adresses IP non attribuées pour votre compte. Pour consulter ou demander des quotas supplémentaires, consultez [SageMaker HyperPod quotas](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas). 1. Pour **Quantité d’instances**, spécifiez un entier ne dépassant pas le quota d’instances pour l’utilisation du cluster. Pour ce didacticiel, entrez **1** pour les trois groupes. 1. Pour **Zone de disponibilité cible**, choisissez la zone de disponibilité dans laquelle vos instances seront provisionnées. La zone de disponibilité doit correspondre à l’emplacement de votre capacité de calcul accélérée. 1. Pour **Autre volume de stockage par instance (Go) – facultatif**, spécifiez un entier compris entre 1 et 16 384 pour définir la taille d’un volume Elastic Block Store (EBS) supplémentaire en gigaoctets (Go). Le volume EBS est attaché à chaque instance du groupe d’instances. Le chemin de montage par défaut pour le volume EBS supplémentaire est `/opt/sagemaker`. Une fois le cluster créé avec succès, vous pouvez accéder par SSH aux instances du cluster (nœuds) et vérifier si le volume EBS est correctement monté en exécutant la commande `df -h`. L’attachement d’un volume EBS supplémentaire fournit un stockage stable, hors instance et persistant de manière indépendante, comme décrit dans la section [Volumes Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) du *Guide de l’utilisateur Amazon Elastic Block Store*. 1. Pour **Vérifications de surveillance approfondie de l’état des instances**, choisissez votre option. Des vérifications de surveillance approfondie de l’état surveillent l’état des instances lors de leur création et après les mises à jour logicielles. Elles permettent de récupérer automatiquement les instances défectueuses par le biais de redémarrages ou de remplacements lorsqu’elles sont activées. Pour en savoir plus, consultez [Vérifications de surveillance approfondie de l’état](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md) 1. Pour **Utiliser une partition GPU : facultatif**, si votre type d'instance prend en charge le partitionnement GPU avec un GPU multi-instance (MIG), vous pouvez activer cette option pour configurer le profil de partition GPU pour le groupe d'instances. Le partitionnement du GPU vous permet de le GPUs diviser en partitions isolées plus petites pour une meilleure utilisation des ressources. Pour de plus amples informations, veuillez consulter [Utilisation de partitions GPU dans Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md). 1. Activez **l'option Utiliser la partition GPU** pour activer le partitionnement GPU pour ce groupe d'instances. 1. Sélectionnez un **profil de partition GPU** parmi les options disponibles pour votre type d'instance. Chaque profil définit la configuration de la tranche GPU et l'allocation de mémoire. 1. Choisissez **Ajouter un groupe d’instances**. ### Scripts de cycle de vie Vous pouvez choisir d’utiliser les scripts de cycle de vie par défaut ou les scripts de cycle de vie personnalisés, qui seront stockés dans votre compartiment Amazon S3. Vous pouvez consulter les scripts de cycle de vie par défaut dans le [ GitHub référentiel Awesome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts). Pour en savoir plus sur les scripts de cycle de vie, consultez [Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie](sagemaker-hyperpod-lifecycle-best-practices-slurm.md). 1. Pour **Scripts de cycle de vie**, choisissez d’utiliser des scripts de cycle de vie par défaut ou personnalisés. 1. Pour **Compartiment S3 pour les scripts de cycle de vie**, choisissez de créer un nouveau compartiment ou d’utiliser un compartiment existant pour stocker les scripts de cycle de vie. ### Permissions Choisissez ou créez un rôle IAM qui permet d'exécuter et HyperPod d'accéder aux AWS ressources nécessaires en votre nom. Pour de plus amples informations, veuillez consulter [Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod). ### Stockage Configurez le système de fichiers FSx for Lustre à provisionner sur le HyperPod cluster. 1. Pour **Système de fichiers**, choisissez un système de fichiers existant FSx pour Lustre, pour créer un nouveau système de fichiers FSx pour Lustre, ou n'en FSx configurez aucun pour Lustre. 1. Pour **Débit par unité de stockage**, choisissez le débit qui sera disponible par Tio de stockage provisionné. 1. Pour **Capacité de stockage**, entrez une valeur de capacité en To. 1. Pour le **type de compression des données**, choisissez **LZ4**d'activer la compression des données. 1. Pour **Version Lustre**, consultez la valeur recommandée pour les nouveaux systèmes de fichiers. ### Balises - facultatif Pour les **balises *(facultatif)***, ajoutez des paires clé/valeur au nouveau cluster et gérez le cluster en tant que AWS ressource. Pour en savoir plus, consultez [Balisage de vos ressources AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). ## déployer des ressources ; Après avoir terminé la configuration du cluster à l’aide de la **configuration rapide** ou de la **configuration personnalisée**, choisissez l’option suivante pour démarrer le provisionnement des ressources et la création du cluster. + **Soumettre** : SageMaker AI commencera à approvisionner les ressources de configuration par défaut et à créer le cluster. + **Télécharger les paramètres du CloudFormation modèle** : vous allez télécharger le fichier JSON des paramètres de configuration et exécuter la AWS CLI commande pour déployer la CloudFormation pile afin de provisionner les ressources de configuration et de créer le cluster. Vous pouvez modifier le fichier JSON de paramètres téléchargés si nécessaire. Si vous choisissez cette option, consultez des instructions supplémentaires dans [Création de SageMaker HyperPod clusters à l'aide CloudFormation de modèles](smcluster-getting-started-eks-console-create-cluster-cfn.md). # Navigation, affichage et modification de SageMaker HyperPod clusters Suivez les instructions suivantes pour parcourir, afficher et modifier les SageMaker HyperPod clusters orchestrés par Amazon EKS dans la console SageMaker AI. **Topics** + [Pour parcourir vos SageMaker HyperPod clusters](#sagemaker-hyperpod-eks-operate-console-ui-browse-clusters) + [Pour afficher les détails de chaque SageMaker HyperPod cluster](#sagemaker-hyperpod-eks-operate-console-ui-view-details-of-clusters) + [Pour modifier un SageMaker HyperPod cluster](#sagemaker-hyperpod-eks-operate-console-ui-edit-clusters) ## Pour parcourir vos SageMaker HyperPod clusters Sous **Clusters** sur la SageMaker HyperPod page de la console SageMaker AI, tous les clusters créés doivent être répertoriés dans la section **Clusters**, qui fournit une vue récapitulative des clusters, de leur ARNs statut et de leur heure de création. ## Pour afficher les détails de chaque SageMaker HyperPod cluster Sous **Clusters** sur la SageMaker HyperPod page de la console SageMaker AI, les noms des clusters sont activés sous forme de liens. Cliquez sur le lien du nom du cluster pour voir les détails de chaque cluster. ## Pour modifier un SageMaker HyperPod cluster 1. Sous **Clusters** dans le volet principal de la SageMaker HyperPod console, choisissez le cluster que vous souhaitez mettre à jour. 1. Sélectionnez votre cluster, puis choisissez **Modifier**. 1. Sur la page **Modifier **, vous pouvez modifier les configurations des groupes d’instances existants, ajouter d’autres groupes d’instances, supprimer des groupes d’instances et modifier les balises du cluster. Après avoir apporté des modifications, choisissez **Soumettre**. 1. Dans la section **Configurer les groupes d’instances**, vous pouvez ajouter d’autres groupes d’instances en choisissant **Créer un groupe d’instances**. 1. Dans la section **Configurer les groupes d’instances**, vous pouvez choisir **Modifier** pour modifier sa configuration ou **Supprimer** pour supprimer définitivement le groupe d’instances. **Important** Lorsque vous supprimez un groupe d’instance, tenez compte des points suivants : Votre SageMaker HyperPod cluster doit toujours gérer au moins un groupe d'instances. Assurez-vous que toutes les données critiques sont sauvegardées avant leur suppression. Le processus de suppression ne peut pas être annulé. **Note** La suppression d’un groupe d’instances résilie toutes les ressources de calcul associées à ce groupe. 1. Dans la section **Balises**, vous pouvez mettre à jour les balises du cluster. # Supprimer un SageMaker HyperPod cluster Suivez les instructions suivantes pour supprimer les SageMaker HyperPod clusters orchestrés par Amazon EKS dans la console SageMaker AI. 1. Sous **Clusters** dans le volet principal de la SageMaker HyperPod console, choisissez le cluster que vous souhaitez supprimer. 1. Sélectionnez votre cluster, puis choisissez **Supprimer**. 1. Dans la fenêtre contextuelle de suppression du cluster, examinez attentivement les informations du cluster pour confirmer que vous avez choisi le bon cluster à supprimer. 1. Après avoir examiné les informations du cluster, choisissez **Oui, supprimer le cluster**. 1. Dans le champ textuel pour confirmer la suppression, saisissez **delete**. 1. Choisissez **Supprimer** dans le coin inférieur droit de la fenêtre contextuelle pour terminer l’envoi de la demande de suppression du cluster. **Note** Lorsque la suppression du cluster échoue en raison des politiques de gouvernance des SageMaker HyperPod tâches associées, vous devez le faire[Suppression de politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md). # Création de SageMaker HyperPod clusters à l'aide CloudFormation de modèles Vous pouvez créer des SageMaker HyperPod clusters à l'aide CloudFormation des modèles pour HyperPod. Vous devez procéder AWS CLI à l'installation pour continuer. **Topics** + [Configurez les ressources dans la console et déployez-les à l'aide de CloudFormation](#smcluster-getting-started-eks-console-create-cluster-deploy-console) + [Configurer et déployer des ressources à l'aide de CloudFormation](#smcluster-getting-started-eks-console-create-cluster-deploy-cfn) ## Configurez les ressources dans la console et déployez-les à l'aide de CloudFormation Vous pouvez configurer les ressources à l'aide des modèles AWS Management Console et les déployer à l'aide CloudFormation des modèles. Procédez comme suit : 1. *Au lieu de choisir **Soumettre***, choisissez **Télécharger les paramètres du CloudFormation modèle** à la fin du didacticiel dans[Commencer à SageMaker HyperPod utiliser la console SageMaker AI](smcluster-getting-started-slurm-console.md). Le didacticiel contient des informations de configuration importantes dont vous aurez besoin pour créer votre cluster avec succès. **Important** Si vous choisissez **Soumettre**, vous ne pourrez pas déployer un cluster portant le même nom tant que vous ne l’aurez pas supprimé. Après avoir sélectionné **Télécharger les paramètres du CloudFormation modèle**, la fenêtre **Utiliser le fichier de configuration pour créer le cluster à l'aide** de la AWS CLI fenêtre apparaît sur le côté droit de la page. 1. Dans la fenêtre **Utilisation du fichier de configuration pour créer le cluster à l’aide de l’ AWS CLI**, choisissez **Télécharger le fichier de paramètres de configuration**. Ce fichier sera téléchargé sur votre ordinateur. Vous pouvez modifier le fichier JSON de configuration en fonction de vos besoins ou le laisser tel quel, si aucune modification n’est requise. 1. Dans un terminal, accédez à l’emplacement du fichier de paramètres `file://params.json`. 1. Exécutez la AWS CLI commande [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) pour déployer la CloudFormation pile qui fournira les ressources configurées et créera le HyperPod cluster. ``` aws cloudformation create-stack --stack-name my-stack --template-url https://aws-sagemaker-hyperpod-cluster-setup.amazonaws.com/templates-slurm/main-stack-slurm-based-template.yaml --parameters file://params.json --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM ``` 1. Pour consulter l'état du provisionnement des ressources, accédez à la [CloudFormation console.](https://console.aws.amazon.com/cloudformation) Une fois la création du cluster terminée, affichez le nouveau cluster sous **Clusters** dans le volet principal de la SageMaker HyperPod console. Vous pouvez vérifier son statut dans la colonne **Statut**. 1. Une fois que le statut du cluster est passé à `InService`, vous pouvez commencer à vous connecter aux nœuds du cluster. Pour accéder aux nœuds du cluster et commencer à exécuter des charges de travail ML, consultez [Offres d'emploi sur SageMaker HyperPod des clusters](sagemaker-hyperpod-run-jobs-slurm.md). ## Configurer et déployer des ressources à l'aide de CloudFormation Vous pouvez configurer et déployer des ressources à l'aide CloudFormation des modèles pour SageMaker HyperPod. Procédez comme suit : 1. Téléchargez un CloudFormation modèle SageMaker HyperPod depuis le [sagemaker-hyperpod-cluster-setup](https://github.com/aws/sagemaker-hyperpod-cluster-setup) GitHub référentiel. 1. Exécutez la AWS CLI commande [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) pour déployer la CloudFormation pile qui fournira les ressources configurées et créera le HyperPod cluster. ``` aws cloudformation create-stack --stack-name my-stack --template-url URL_of_the_file_that_contains_the_template_body --parameters file://params.json --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM ``` 1. Pour consulter le statut de provisionnement des ressources, accédez à la console CloudFormation . Une fois la création du cluster terminée, affichez le nouveau cluster sous **Clusters** dans le volet principal de la SageMaker HyperPod console. Vous pouvez vérifier son statut dans la colonne **Statut**. 1. Une fois que le statut du cluster est passé à `InService`, vous pouvez commencer à vous connecter aux nœuds du cluster. # Gestion des clusters SageMaker HyperPod EKS à l'aide du AWS CLI Les rubriques suivantes fournissent des conseils sur l'écriture de fichiers de requêtes d' SageMaker HyperPod API au format JSON et leur exécution à l'aide des AWS CLI commandes. **Topics** + [Création d'un SageMaker HyperPod cluster](sagemaker-hyperpod-eks-operate-cli-command-create-cluster.md) + [Récupération des détails SageMaker HyperPod du cluster](sagemaker-hyperpod-eks-operate-cli-command-cluster-details.md) + [Mettre à jour la configuration SageMaker HyperPod du cluster](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md) + [Mise à jour du logiciel SageMaker HyperPod de la plateforme](sagemaker-hyperpod-eks-operate-cli-command-update-cluster-software.md) + [Accès aux nœuds SageMaker HyperPod du cluster](sagemaker-hyperpod-eks-operate-access-through-terminal.md) + [Réduction de la taille d'un SageMaker HyperPod cluster](smcluster-scale-down.md) + [Supprimer un SageMaker HyperPod cluster](sagemaker-hyperpod-eks-operate-cli-command-delete-cluster.md) # 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" } ``` 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. # Récupération des détails SageMaker HyperPod du cluster Découvrez comment récupérer les détails d' SageMaker HyperPod un cluster à l'aide du AWS CLI. ## Description d’un cluster Exécutez [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster.html) pour vérifier le statut du cluster. Vous pouvez spécifier le nom ou l’ARN du cluster. ``` aws sagemaker describe-cluster --cluster-name your-hyperpod-cluster ``` Une fois que le statut du cluster passe à **InService**, passez à l’étape suivante. À l'aide de cette API, vous pouvez également récupérer les messages d'échec liés à l'exécution d'autres opérations d' HyperPod API. ## Liste des détails des nœuds du cluster Exécutez [list-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html)pour vérifier les informations clés des nœuds du cluster. ``` aws sagemaker list-cluster-nodes --cluster-name your-hyperpod-cluster ``` Cela renvoie une réponse et `InstanceId` correspond à ce dont vous avez besoin pour vous y connecter (en utilisant `aws ssm`). ## Description des détails d’un nœud de cluster Exécutez [describe-cluster-node](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster-node.html)pour récupérer les détails d'un nœud de cluster. Vous pouvez obtenir l'ID du nœud du cluster à partir de la list-cluster-nodes sortie. Vous pouvez spécifier le nom ou l’ARN du cluster. ``` aws sagemaker describe-cluster-node \ --cluster-name your-hyperpod-cluster \ --node-id i-111222333444555aa ``` ## Liste des clusters Exécutez [list-clusters](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-clusters.html) pour répertorier tous les clusters figurant dans votre compte. ``` aws sagemaker list-clusters ``` Vous pouvez également ajouter des indicateurs supplémentaires pour filtrer la liste des clusters. Pour en savoir plus sur le fonctionnement de cette commande à bas niveau et sur les indicateurs supplémentaires pour le filtrage, consultez la référence de l'[ListClusters](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusters.html)API. # Mettre à jour la configuration SageMaker HyperPod du cluster Exécutez [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) pour mettre à jour la configuration d’un cluster. **Note** Considérations importantes : Vous ne pouvez pas modifier les informations du cluster EKS auxquelles votre HyperPod cluster est associé une fois celui-ci créé. Si des vérifications de surveillance approfondie de l’état sont exécutées sur le cluster, cette API ne fonctionnera pas comme prévu. Vous pouvez rencontrer un message d’erreur indiquant que des vérifications de surveillance approfondie de l’état sont en cours. Pour mettre à jour le cluster, vous devez attendre que les vérifications de surveillance approfondie de l’état soient terminées. 1. Créez un fichier de demande d’API [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) au format JSON. Assurez-vous de spécifier le nom du cluster et le nom du groupe d’instances appropriés à mettre à jour. Pour chaque groupe d’instances, vous pouvez modifier le type d’instance, le nombre d’instances, le script de point d’entrée de configuration de cycle de vie et le chemin vers ce script. **Note** Vous pouvez utiliser le `UpdateCluster` pour réduire ou supprimer des groupes d'instances entiers de votre SageMaker HyperPod cluster. Pour obtenir des instructions supplémentaires sur la manière de réduire verticalement ou de supprimer les groupes d’instances, consultez [Réduction de la taille d'un SageMaker HyperPod cluster](smcluster-scale-down.md). 1. Pour `ClusterName`, spécifiez le nom du cluster que vous voulez mettre à jour. 1. Pour `InstanceGroupName` 1. Pour mettre à jour un groupe d’instances existant, spécifiez le nom du groupe d’instances que vous souhaitez mettre à jour. 1. Pour ajouter un nouveau groupe d’instances, spécifiez un nouveau nom qui n’existe pas dans votre cluster. 1. Pour `InstanceType` 1. Pour mettre à jour un groupe d’instances existant, vous devez mettre en correspondance le type d’instance que vous avez initialement spécifié avec ce groupe. 1. Pour ajouter un nouveau groupe d’instances, spécifiez un type d’instance avec lequel vous souhaitez configurer le groupe. 1. Pour `InstanceCount` 1. Pour mettre à jour un groupe d’instances existant, spécifiez un entier correspondant au nombre d’instances que vous souhaitez. Vous pouvez fournir une valeur supérieure ou inférieure (jusqu’à 0) pour augmenter ou réduire verticalement le groupe d’instances. 1. Pour ajouter un nouveau groupe d’instances, spécifiez un entier supérieur ou égal à 1. 1. Pour `LifeCycleConfig`, vous pouvez modifier à la fois les valeurs `SourceS3Uri` et `OnCreate` comme vous le souhaitez pour mettre à jour le groupe d’instances. 1. Pour `ExecutionRole` 1. Pour mettre à jour un groupe d’instances existant, continuez à utiliser le même rôle IAM que celui que vous avez attaché lors de la création du cluster. 1. Pour ajouter un nouveau groupe d’instances, spécifiez un rôle IAM que vous souhaitez attacher. 1. Pour `ThreadsPerCore` 1. Pour mettre à jour un groupe d’instances existant, continuez à utiliser la même valeur que vous avez spécifiée lors de la création du cluster. 1. Pour ajouter un nouveau groupe d’instances, vous pouvez choisir n’importe quelle valeur parmi les options autorisées par type d’instance. Pour plus d’informations, recherchez le type d’instance et consultez la colonne **Threads valides par cœur** dans le tableau de référence dans [Cœurs de CPU et threads par cœur de CPU par type d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html) dans le *Guide de l’utilisateur Amazon EC2*. 1. Pour `OnStartDeepHealthChecks`, ajoutez `InstanceStress` et `InstanceConnectivity` pour activer [Vérifications de surveillance approfondie de l’état](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md). 1. 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. L’extrait de code suivant est un modèle de fichier de demande JSON que vous pouvez utiliser. Pour plus d'informations sur la syntaxe des demandes et les paramètres de cette API, consultez la référence de l'[UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API. ``` // update_cluster.json { // Required "ClusterName": "name-of-cluster-to-update", // Required "InstanceGroups": [{ "InstanceGroupName": "string", "InstanceType": "string", "InstanceCount": number, "LifeCycleConfig": { "SourceS3Uri": "string", "OnCreate": "string" }, "ExecutionRole": "string", "ThreadsPerCore": number, "OnStartDeepHealthChecks": [ "InstanceStress", "InstanceConnectivity" ] }], "NodeRecovery": "Automatic" } ``` 1. Exécutez la commande `update-cluster` suivante pour soumettre la demande. ``` aws sagemaker update-cluster \ --cli-input-json file://complete/path/to/update_cluster.json ``` # Mise à jour du logiciel SageMaker HyperPod de la plateforme Lorsque vous créez votre SageMaker HyperPod cluster, sélectionnez SageMaker HyperPod une Amazon Machine Image (AMI) correspondant à la version Kubernetes de votre cluster Amazon EKS. Exécutez [update-cluster-software](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster-software.html)pour mettre à jour les clusters existants avec les logiciels et les correctifs de sécurité fournis par le SageMaker HyperPod service. Pour `--cluster-name`, spécifiez le nom ou l’ARN du cluster à mettre à jour. **Important** Lorsque cette API est appelée, SageMaker HyperPod elle ne vide ni ne redistribue les tâches (Pods) exécutées sur les nœuds. Assurez-vous de vérifier si des tâches sont en cours d’exécution sur les nœuds avant d’appeler cette API. Le processus d’application de correctifs remplace le volume racine par l’AMI mise à jour, ce qui signifie que les données précédemment stockées dans le volume racine de l’instance seront perdues. Assurez-vous de sauvegarder vos données depuis le volume racine de l'instance vers Amazon S3 ou Amazon FSx for Lustre. Tous les nœuds du cluster subissent une durée d’indisponibilité (les nœuds apparaissent comme `` dans la sortie de `kubectl get node`) alors que l’application des correctifs est en cours. Nous vous recommandons de résilier toutes les charges de travail avant d’appliquer le correctif et de les reprendre une fois l’application du correctif terminée. Si l’application du correctif de sécurité échoue, vous pouvez extraire les messages d’échec en exécutant l’API [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html) comme indiqué dans [Description d’un cluster](sagemaker-hyperpod-eks-operate-cli-command-cluster-details.md#sagemaker-hyperpod-eks-operate-cli-command-describe-cluster). ``` aws sagemaker update-cluster-software --cluster-name your-hyperpod-cluster ``` Lorsque vous appelez l'`UpdateClusterSoftware`API, mettez SageMaker HyperPod à jour la version Kubernetes des nœuds en sélectionnant la dernière version en [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) fonction de la version Kubernetes de votre cluster Amazon EKS. Il exécute ensuite les scripts de cycle de vie dans le compartiment Amazon S3 que vous avez spécifié lors de la création ou de la mise à jour du cluster. Vous pouvez vérifier la version de kubelet d’un nœud en exécutant la commande `kubectl describe node`. La version Kubernetes des nœuds de SageMaker HyperPod cluster n'est pas automatiquement mise à jour lorsque vous mettez à jour la version de votre cluster Amazon EKS. Après avoir mis à jour la version de Kubernetes pour votre cluster Amazon EKS, vous devez utiliser l'`UpdateClusterSoftware`API pour mettre à jour les nœuds de votre SageMaker HyperPod cluster vers la même version de Kubernetes. Il est recommandé de mettre à jour votre SageMaker HyperPod cluster après avoir mis à jour vos nœuds Amazon EKS, et d'éviter qu'il y ait plus d'une différence de version entre la version du cluster Amazon EKS et la version des nœuds du SageMaker HyperPod cluster. L'équipe SageMaker HyperPod de service déploie régulièrement de nouvelles [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) solutions pour renforcer la sécurité et améliorer l'expérience utilisateur. Nous vous recommandons de toujours mettre à jour le DLAMI le plus récent SageMaker HyperPod . Pour les futures SageMaker HyperPod mises à jour du DLAMI relatives aux correctifs de sécurité, contactez. [Notes de SageMaker HyperPod publication d'Amazon](sagemaker-hyperpod-release-notes.md) **Note** Vous pouvez exécuter cette API uniquement par programmation. La fonctionnalité d'application de correctifs n'est pas implémentée dans l'interface utilisateur de la SageMaker HyperPod console. # Accès aux nœuds SageMaker HyperPod du cluster Vous pouvez accéder directement aux nœuds d'un SageMaker HyperPod cluster en service à l'aide des AWS CLI commandes pour AWS Systems Manager (SSM). Exécutez `aws ssm start-session` avec le nom d’hôte du nœud au format `sagemaker-cluster:[cluster-id]_[instance-group-name]-[instance-id]`. Vous pouvez récupérer l'ID du cluster, l'ID de l'instance et le nom du groupe d'instances depuis la [SageMaker HyperPod console](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters) ou en exécutant `describe-cluster` et `list-cluster-nodes` depuis les [AWS CLI commandes pour SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes). Par exemple, si votre ID de cluster est `aa11bbbbb222`, le nom du nœud de cluster `controller-group` et l’ID du nœud de cluster `i-111222333444555aa`, la commande SSM `start-session` doit être la suivante. **Note** Si vous ne l'avez pas encore configuré AWS Systems Manager, suivez les instructions fournies à l'adresse[Configuration AWS Systems Manager et exécution en tant que pour le contrôle d'accès des utilisateurs du cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm). ``` $ aws ssm start-session \ --target sagemaker-cluster:aa11bbbbb222_controller-group-i-111222333444555aa \ --region us-west-2 Starting session with SessionId: s0011223344aabbccdd root@ip-111-22-333-444:/usr/bin# ``` # Réduction de la taille d'un SageMaker HyperPod cluster Vous pouvez réduire le nombre d'instances exécutées sur votre SageMaker HyperPod cluster Amazon. Vous souhaiterez peut-être réduire verticalement un cluster pour diverses raisons, telles qu’une réduction de l’utilisation des ressources ou l’optimisation des coûts. La page suivante décrit deux approches principales en matière de réduction verticale : + **Réduction verticale au niveau du groupe d’instances :** cette approche utilise l’API `UpdateCluster`, avec laquelle vous pouvez : + Réduire verticalement le nombre d’instances indépendamment pour des groupes d’instances spécifiques. SageMaker L'IA gère la terminaison des nœuds de manière à atteindre le nouveau nombre d'instances cibles que vous avez défini pour chaque groupe. Consultez [Réduction verticale d’un groupe d’instances](#smcluster-scale-down-updatecluster). + Supprimer complètement les groupes d’instances de votre cluster. Consultez [Suppression de groupes d’instances](#smcluster-remove-instancegroup). + **Réduction verticale au niveau des instances :** cette approche utilise l’API `BatchDeleteClusterNodes`, avec laquelle vous pouvez spécifier les nœuds individuels que vous souhaitez résilier. Consultez [Réduction verticale au niveau des instances](#smcluster-scale-down-batchdelete). **Note** Lorsque vous utilisez la réduction verticale au niveau des instances avec `BatchDeleteCusterNodes`, vous pouvez résilier un maximum de 99 instances à la fois. `UpdateCluster` prend en charge la résiliation d’un nombre quelconque d’instances. ## Considérations importantes + Lorsque vous réduisez verticalement un cluster, vous devez vous assurer que les ressources restantes sont suffisantes pour gérer votre charge de travail et que toute migration ou rééquilibrage nécessaire des données est correctement géré(e) afin d’éviter les interruptions. + Assurez-vous de sauvegarder vos données sur Amazon S3 ou sur un système de fichiers FSx pour Lustre avant d'appeler l'API sur un groupe de nœuds de travail. Cela permet d’éviter toute perte de données potentielle à partir du volume racine de l’instance. Pour plus d’informations sur la sauvegarde, consultez [Utilisez le script de sauvegarde fourni par SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software-backup). + Pour appeler cette API sur un cluster existant, vous devez d'abord appliquer un correctif au cluster en exécutant l'[ UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API. Pour plus d’informations sur l’application de correctifs à un cluster, consultez [Mettre à jour le logiciel de SageMaker HyperPod plate-forme d'un cluster](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software). + Les mesures et la facturation pour les instances à la demande seront automatiquement arrêtées après une réduction verticale. Pour arrêter de mesurer les instances réservées dont la taille est réduite, vous devez contacter l'équipe chargée de votre AWS compte pour obtenir de l'aide. + Vous pouvez utiliser la capacité libérée par les instances réservées réduites pour augmenter le volume d'un autre SageMaker HyperPod cluster. ## Réduction verticale au niveau du groupe d’instances L'[https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)opération vous permet d'apporter des modifications à la configuration de votre SageMaker HyperPod cluster, par exemple en réduisant le nombre d'instances d'un groupe d'instances ou en supprimant des groupes d'instances entiers. Cela peut être utile lorsque vous souhaitez ajuster les ressources allouées à votre cluster en fonction de l’évolution de votre charge de travail, optimiser les coûts ou modifier le type d’instance d’un groupe d’instances. ### Réduction verticale d’un groupe d’instances Utilisez cette approche lorsqu’un groupe d’instances est inactif et qu’il est possible de résilier l’une quelconque des instances en toute sécurité pour effectuer une réduction verticale. Lorsque vous soumettez une `UpdateCluster` demande de réduction, choisit de HyperPod manière aléatoire les instances à résilier et réduit la taille jusqu'au nombre de nœuds spécifié pour le groupe d'instances. **Note** Lorsque vous réduisez verticalement le nombre d’instances d’un groupe d’instances à 0, toutes les instances de ce groupe sont résiliées. Cependant, le groupe d'instances lui-même existera toujours dans le SageMaker HyperPod cluster. Vous pourrez augmenter verticalement le groupe d’instances ultérieurement, en utilisant la même configuration de groupe d’instances. Vous pouvez également choisir de supprimer définitivement un groupe d’instances. Pour de plus amples informations, veuillez consulter [Suppression de groupes d’instances](#smcluster-remove-instancegroup). **Pour effectuer une réduction verticale avec `UpdateCluster`** 1. Suivez les étapes décrites dans [Mettre à jour la configuration SageMaker HyperPod du cluster](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md). Lorsque vous atteignez l'étape **1.d** où vous spécifiez le **InstanceCount**champ, entrez un nombre inférieur au nombre actuel d'instances pour réduire le cluster. 1. Exécutez la AWS CLI commande [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) pour soumettre votre demande. Vous trouverez ci-dessous un exemple d’objet JSON `UpdateCluster`. Imaginons le cas où votre groupe d’instances possède actuellement 2 instances en cours d’exécution. Si vous définissez le **InstanceCount**champ sur 1, comme indiqué dans l'exemple, sélectionnez de HyperPod manière aléatoire l'une des instances et y mettez fin. ``` { "ClusterName": "name-of-cluster-to-update", "InstanceGroups": [ { "InstanceGroupName": "training-instances", "InstanceType": "instance-type", "InstanceCount": 1, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket/training-script.py", "OnCreate": "s3://amzn-s3-demo-bucket/setup-script.sh" }, "ExecutionRole": "arn:aws:iam::123456789012:role/SageMakerRole", "ThreadsPerCore": number-of-threads, "OnStartDeepHealthChecks": [ "InstanceStress", "InstanceConnectivity" ] } ], "NodeRecovery": "Automatic" } ``` ### Suppression de groupes d’instances Vous pouvez utiliser cette [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)opération pour supprimer des groupes d'instances entiers de votre SageMaker HyperPod cluster lorsqu'ils ne sont plus nécessaires. Cela va au-delà d’une simple réduction verticale et vous permet d’éliminer complètement des groupes d’instances spécifiques de la configuration de votre cluster. **Note** Lors de la suppression d’un groupe d’instances : Toutes les instances du groupe ciblé sont résiliées. L’intégralité de la configuration du groupe est supprimée du cluster. Toutes les charges de travail exécutées sur ce groupe d’instances sont arrêtées. **Pour supprimer des groupes d’instances avec `UpdateCluster`** 1. Lorsque vous suivez les étapes décrites dans [Mettre à jour la configuration SageMaker HyperPod du cluster](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md) : 1. Définissez le paramètre `InstanceGroupsToDelete` facultatif dans votre code JSON `UpdateCluster` et transmettez la liste séparée par des virgules des noms de groupes d’instances que vous souhaitez supprimer. 1. Lorsque vous spécifiez la liste `InstanceGroups`, assurez-vous que les spécifications des groupes d’instances que vous supprimez ne figurent plus dans la liste `InstanceGroups`. 1. Exécutez la AWS CLI commande [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) pour soumettre votre demande. **Important** Votre SageMaker HyperPod cluster doit toujours gérer au moins un groupe d'instances. Assurez-vous que toutes les données critiques sont sauvegardées avant leur suppression. Le processus de suppression ne peut pas être annulé. Vous trouverez ci-dessous un exemple d’objet JSON `UpdateCluster`. Prenons le cas où un cluster possède actuellement 3 groupes d’instances, un groupe *d’entraînement*, un groupe *d’entraînement de prototype* et un groupe *d’inférence*. Vous souhaitez supprimer le groupe *d’entraînement de prototype*. ``` { "ClusterName": "name-of-cluster-to-update", "InstanceGroups": [ { "InstanceGroupName": "training", "InstanceType": "instance-type", "InstanceCount": , "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket/training-script.py", "OnCreate": "s3://amzn-s3-demo-bucket/setup-script.sh" }, "ExecutionRole": "arn:aws:iam::123456789012:role/SageMakerRole", "ThreadsPerCore": number-of-threads, "OnStartDeepHealthChecks": [ "InstanceStress", "InstanceConnectivity" ] }, { "InstanceGroupName": "inference-serving", "InstanceType": "instance-type", "InstanceCount": 2, [...] }, ], "InstanceGroupsToDelete": [ "prototype-training" ], "NodeRecovery": "Automatic" } ``` ## Réduction verticale au niveau des instances L'`BatchDeleteClusterNodes`opération vous permet de réduire la taille d'un SageMaker HyperPod cluster en spécifiant les nœuds individuels que vous souhaitez terminer. `BatchDeleteClusterNodes`fournit un contrôle plus granulaire pour la suppression ciblée des nœuds et l'optimisation des clusters. Par exemple, vous pouvez utiliser `BatchDeleteClusterNodes` pour supprimer des nœuds ciblés à des fins de maintenance, de mises à niveau continues ou de rééquilibrage géographique des ressources. **Demande et réponse d’API** Lorsque vous soumettez une `BatchDeleteClusterNodes` demande, SageMaker HyperPod supprime les nœuds en fonction de leur instance IDs. L'API accepte une demande avec le nom du cluster et une liste de nœuds IDs à supprimer. La réponse contient deux sections : + `Failed` : liste des erreurs de type `[ BatchDeleteClusterNodesError ](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchDeleteClusterNodesError.html)` : une par ID d’instance. + `Successful`: La liste des instances IDs a été interrompue avec succès. **Validation et gestion des erreurs** L’API effectue diverses validations, telles que : + Vérification du format de l’ID de nœud (préfixe `i-` et structure des ID d’instances Amazon EC2). + Vérification de la longueur de la liste de nœuds, avec une limite de 99 nœuds IDs ou moins par `BatchDeleteClusterNodes` demande. + Assurez-vous qu'un SageMaker HyperPod cluster valide portant le nom de cluster en entrée est présent et qu'aucune opération au niveau du cluster (mise à jour, mise à jour du système, application de correctifs ou suppression) n'est en cours. + Gestion des cas où les instances sont introuvables, ont un statut non valide ou sont en cours d’utilisation. **Codes de réponse d’API** + L’API renvoie un code de statut `200` en cas de réussite (p. ex., tous les nœuds d’entrée ont réussi la validation) ou des demandes partiellement réussies (p. ex., certains nœuds d’entrée échouent à la validation). + Si toutes ces validations échouent (p. ex., tous les nœuds d’entrée échouent à la validation), l’API renverra une réponse `400` Bad Request avec les messages d’erreur et les codes d’erreur appropriés. **Exemple** Voici un exemple de **réduction verticale d’un cluster au niveau des instances** à l’aide de l’ AWS CLI : ``` aws sagemaker batch-delete-cluster-nodes --cluster-name "cluster-name" --node-ids '["i-111112222233333", "i-111112222233333"]' ``` # Supprimer un SageMaker HyperPod cluster Exécutez [delete-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-cluster.html) pour supprimer un cluster. Vous pouvez spécifier le nom ou l’ARN du cluster. ``` aws sagemaker delete-cluster --cluster-name your-hyperpod-cluster ``` Cette API nettoie uniquement les SageMaker HyperPod ressources et ne supprime aucune ressource du cluster EKS associé. Cela inclut le cluster Amazon EKS, les identités EKS Pod, les FSx volumes Amazon et les modules complémentaires EKS. Cela inclut également la configuration initiale que vous avez ajoutée à votre cluster EKS. Si vous souhaitez nettoyer toutes les ressources, assurez-vous de nettoyer également les ressources EKS séparément. Assurez-vous de supprimer d'abord les SageMaker HyperPod ressources, puis les ressources EKS. L’exécution de la suppression dans l’ordre inverse peut entraîner le maintien de certaines ressources. **Important** Lorsque cette API est appelée, SageMaker HyperPod elle ne vide ni ne redistribue les tâches (Pods) exécutées sur les nœuds. Assurez-vous de vérifier si des tâches sont en cours d’exécution sur les nœuds avant d’appeler cette API. # HyperPod point de contrôle hiérarchisé géré Cette section explique le fonctionnement du point de contrôle hiérarchisé géré et les avantages qu'il apporte pour la formation de modèles à grande échelle. Le point de contrôle hiérarchisé SageMaker HyperPod géré par Amazon vous permet de former plus efficacement des modèles d'IA générative à grande échelle. Il utilise plusieurs niveaux de stockage, y compris la mémoire CPU de votre cluster. Cette approche réduit votre temps de récupération et minimise les pertes de progression de l’entraînement. Elle utilise également des ressources de mémoire sous-utilisées dans votre infrastructure d’entraînement. Le point de contrôle hiérarchisé géré permet d'enregistrer les points de contrôle à une fréquence plus élevée dans la mémoire. Il les conserve périodiquement dans un stockage durable. Cela permet de maintenir à la fois les performances et la fiabilité au cours de votre processus d’entraînement. Ce guide explique comment configurer, configurer et utiliser le point de contrôle hiérarchisé géré avec des PyTorch frameworks sur des clusters Amazon EKS HyperPod . ## Comment fonctionne le point de contrôle hiérarchisé géré Le point de contrôle hiérarchisé géré utilise une approche de stockage multiniveau. La mémoire CPU sert de niveau principal pour stocker les points de contrôle du modèle. Les niveaux secondaires incluent des options de stockage permanent telles qu’Amazon S3. Lorsque vous enregistrez un point de contrôle, le système le stocke dans l’espace mémoire alloué sur les nœuds de votre cluster. Il réplique automatiquement les données sur les nœuds de calcul adjacents pour renforcer la fiabilité. Cette stratégie de réplication protège contre les défaillances d’un ou de plusieurs nœuds tout en fournissant un accès rapide pour les opérations de récupération. Le système enregistre également régulièrement les points de contrôle dans le stockage permanent en fonction de votre configuration. Cela garantit la durabilité à long terme de votre progression d’entraînement. Les composants clés sont les suivants : + **Système de gestion de la mémoire** : démon de gestion de mémoire qui fournit de la mémoire désagrégée en tant que service pour le stockage des points de contrôle. + **HyperPod Bibliothèque Python** : interface avec le stockage désagrégé APIs et fournit des utilitaires pour enregistrer, charger et gérer les points de contrôle à tous les niveaux + **Réplication des points de contrôle** : réplique automatiquement les points de contrôle sur plusieurs nœuds pour garantir la tolérance aux pannes. Le système s'intègre parfaitement aux boucles d' PyTorch entraînement par le biais de simples appels d'API. Cela nécessite des modifications minimales de votre code existant. ## Avantages Le point de contrôle hiérarchisé géré offre plusieurs avantages pour la formation de modèles à grande échelle : + **Facilité d’utilisation améliorée** : gère l’enregistrement, la réplication, la persistance et la récupération des points de contrôle. + **Opérations de point de contrôle plus rapides** : le stockage basé sur la mémoire permet des temps d’enregistrement et de chargement plus rapides que les points de contrôle sur disque, ce qui permet une récupération plus rapide. + **Tolérance aux pannes** : la réplication automatique des points de contrôle entre les nœuds protège contre les défaillances matérielles des nœuds. + **Changements de code minimaux** : l’intégration simple des API ne nécessite que des modifications mineures aux scripts d’entraînement existants. + **Débit d’entraînement amélioré** : la réduction des frais liés aux points de contrôle signifie plus de temps consacré à l’entraînement proprement dit. **Topics** + [Comment fonctionne le point de contrôle hiérarchisé géré](#managed-tier-checkpointing-works) + [Avantages](#managed-tier-checkpointing-benefits) + [Configurer des points de contrôle hiérarchisés gérés](managed-tier-checkpointing-setup.md) + [Supprimer le point de contrôle hiérarchisé géré](managed-tier-checkpointing-remove.md) + [Considérations relatives à la sécurité pour le point de contrôle hiérarchisé géré](managed-tier-security-considerations.md) # Configurer des points de contrôle hiérarchisés gérés Cette section décrit le processus de configuration du point de contrôle hiérarchisé géré pour Amazon. SageMaker HyperPod Vous allez apprendre à activer cette fonctionnalité sur votre cluster et à implémenter les points de contrôle dans votre code d’entraînement. **Topics** + [Conditions préalables](#managed-tier-checkpointing-setup-prerequisites) + [Étape 1 : activer le point de contrôle hiérarchisé géré pour votre cluster](#managed-tier-checkpointing-setup-step-enable-for-cluster) + [Étape 2 : Installation de la bibliothèque Python dans votre image d’entraînement](#managed-tier-checkpointing-setup-step-install-library) + [Étape 3 : Enregistrez les points de contrôle dans votre boucle d'entraînement](#managed-tier-checkpointing-setup-step-save-checkpoint-in-loop) + [Étape 4 : Charger les points de contrôle pour la récupération](#managed-tier-checkpointing-setup-step-load-checkpoint) + [Validez vos opérations de point de contrôle hiérarchisé gérées](#managed-tier-checkpointing-setup-validation) ## Conditions préalables Avant de configurer le point de contrôle hiérarchisé géré, assurez-vous d'avoir : + Un HyperPod cluster Amazon EKS avec suffisamment de mémoire CPU disponible pour l'allocation des points de contrôle + PyTorch charges de travail de formation et emplois de DCP (les deux sont pris en charge) + Autorisations IAM appropriées pour la gestion des clusters, notamment : + Amazon CloudWatch et Amazon S3 rédigent des autorisations pour le module de formation afin de lire/écrire des points de contrôle et de transmettre des métriques + Ces autorisations peuvent être configurées via la [configuration EKS OIDC](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). ## Étape 1 : activer le point de contrôle hiérarchisé géré pour votre cluster **Important** Vous devez choisir d'utiliser le point de contrôle hiérarchisé géré. Activez le point de contrôle hiérarchisé géré HyperPod APIs lors de la création ou de la mise à jour de votre cluster. Le service installe automatiquement le système de gestion de la mémoire lorsque vous spécifiez le paramètre `TieredStorageConfig`. Pour les nouveaux clusters, vous pouvez utiliser [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) AWS CLI. ``` aws sagemaker create-cluster \ --cluster-name cluster-name \ --orchestrator "Eks={ClusterArn=eks-cluster-arn}" \ --instance-groups '{ "InstanceGroupName": "instance-group-name", "InstanceType": "instance-type", "InstanceCount": instance-count, "LifeCycleConfig": { "SourceS3Uri": "s3-path-to-lifecycle-scripts", "OnCreate": "lifecycle-script-name" }, "ExecutionRole": "instance-group-iam-role", "ThreadsPerCore": threads-per-core, "InstanceStorageConfigs": [ { "EbsVolumeConfig": {"VolumeSizeInGB": volume-size} } ] }' \ --vpc-config '{ "SecurityGroupIds": ["security-group-ids"], "Subnets": ["subnets"] }' \ --tiered-storage-config '{ "Mode": "Enable" }' ``` Le paramètre `InstanceMemoryAllocationPercentage` spécifie le `percentage` (int) de mémoire du cluster à allouer pour les points de contrôle. La plage est comprise entre 20 et 100. ## Étape 2 : Installation de la bibliothèque Python dans votre image d’entraînement Installez la [bibliothèque de points de SageMaker contrôle Amazon](https://pypi.org/project/amzn-sagemaker-checkpointing/) et ses dépendances dans votre image d'entraînement en l'ajoutant à votre Dockerfile : ``` # Add this line to your training image Dockerfile RUN pip install amzn-sagemaker-checkpointing s3torchconnector tenacity torch boto3 s3torchconnector ``` ## Étape 3 : Enregistrez les points de contrôle dans votre boucle d'entraînement Dans votre boucle d'entraînement, vous pouvez enregistrer des points de contrôle de manière asynchrone à l'aide du DCP. PyTorch Voici un exemple sur la façon de procéder. ``` import torch import torch.distributed as dist from torch.distributed.checkpoint import async_save, load from amzn_sagemaker_checkpointing.checkpointing.filesystem.filesystem import ( SageMakerTieredStorageWriter, SageMakerTieredStorageReader ) # Initialize distributed training dist.init_process_group(backend="nccl") # Configure checkpointing checkpoint_config = SageMakerCheckpointConfig( # Unique ID for your training job # Allowed characters in ID include: alphanumeric, hyphens, and underscores namespace=os.environ.get('TRAINING_JOB_NAME', f'job-{int(time.time())}'), # Number of distributed processes/available GPUs world_size=dist.get_world_size(), # S3 storage location, required for SageMakerTieredStorageReader for read fallbacks # Required for SageMakerTieredStorageWriter when save_to_s3 is True s3_tier_base_path="s3://my-bucket/checkpoints" ) # Your model and optimizer model = MyModel() optimizer = torch.optim.AdamW(model.parameters()) # Training loop future = None in_memory_ckpt_freq = 10 s3_ckpt_freq = 50 for training_step in range(1000): # ... training code ... # Save checkpoint if (training_step % in_memory_ckpt_freq == 0 or training_step % s3_ckpt_freq == 0): # Create state dictionary state_dict = { "model": model.state_dict(), "optimizer": optimizer.state_dict(), "step": training_step, "epoch": epoch } # Create storage writer for current step checkpoint_config.save_to_s3 = training_step % s3_ckpt_freq == 0 storage_writer = SageMakerTieredStorageWriter( checkpoint_config=checkpoint_config, step=training_step ) # wait for previous checkpoint to get completed if future is not None: exc = future.exception() if exc: print(f"Failure in saving previous checkpoint:{str(exc)}") # Handle failures as required else: result = future.result() # Process results from save, if required # Async save checkpoint using PyTorch DCP future = async_save(state_dict=state_dict, storage_writer=storage_writer) # Continue training while checkpoint saves in background ``` ## Étape 4 : Charger les points de contrôle pour la récupération Voici un exemple de chargement d'un point de contrôle. ``` # Create state dictionary template state_dict = { "model": model.state_dict(), "optimizer": optimizer.state_dict(), "step": 0, "epoch": 0 } # Load latest checkpoint storage_reader = SageMakerTieredStorageReader(checkpoint_config=checkpoint_config) load(state_dict, storage_reader=storage_reader) # Load specific checkpoint step storage_reader = SageMakerTieredStorageReader( checkpoint_config=checkpoint_config, step=500 # Or don't pass step if you have to load the latest available step. ) try: load(state_dict, storage_reader=storage_reader) except BaseException as e: print(f"Checkpoint load failed: {str(e)}") # Add additional exception handling ``` ## Validez vos opérations de point de contrôle hiérarchisé gérées Vous pouvez valider vos opérations de point de contrôle hiérarchisé gérées à l'aide de journaux. **Journalisation personnalisée (facultatif)** Vous pouvez intégrer les journaux de points de contrôle à d’autres journaux en transmettant un enregistreur personnalisé à la bibliothèque. Par exemple, vous pouvez ajouter un enregistreur personnalisé à votre code d’entraînement afin que tous les journaux de la bibliothèque soient également collectés dans l’enregistreur d’entraînement. **Journalisation des services améliorée (facultatif)** Pour améliorer le débogage et la visibilité des services, vous pouvez monter le chemin du journal de points de contrôle `/var/log/sagemaker_checkpointing` depuis votre pod vers un chemin `/var/logs/sagemaker_checkpointing` sur votre hôte. Cela garantit que seuls les journaux spécifiques à la bibliothèque sont collectés séparément. Cela fournit à l’équipe de service une meilleure visibilité pour le débogage et le support. # Supprimer le point de contrôle hiérarchisé géré Cette section explique comment désactiver le point de contrôle hiérarchisé géré lorsque vous n'en avez plus besoin. Pour désactiver le point de contrôle hiérarchisé géré, utilisez le [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) AWS CLI pour mettre à jour la configuration de votre cluster : ``` aws sagemaker update-cluster \ --cluster-name cluster-name \ --tiered-storage-config '{ "Mode": "Disable" }' ``` Cela supprime le démon de gestion de mémoire de votre cluster. Le daemon est implémenté en tant que Kubernetes standard DaemonSet et suit la gestion du cycle de vie standard de Kubernetes. # Considérations relatives à la sécurité pour le point de contrôle hiérarchisé géré Cette section couvre les considérations de sécurité importantes lors de l'utilisation du point de contrôle hiérarchisé géré. Cela inclut l’utilisation du module pickle Python, le chiffrement Amazon S3 et la sécurité des points de terminaison réseau. **Utilisation du module pickle Python** Le point de contrôle hiérarchisé géré utilise le module pickle de Python pour désérialiser les données de point de contrôle stockées dans Amazon S3. Cette mise en œuvre a d’importantes implications en matière de sécurité : + **Limite de confiance étendue** : lorsque vous utilisez le point de contrôle hiérarchisé géré avec Amazon S3, le compartiment Amazon S3 fait partie de la limite de confiance de votre cluster. + **Risque d’exécution du code** : le module pickle de Python peut exécuter du code arbitraire lors de la désérialisation. Si un utilisateur non autorisé obtient un accès en écriture à votre compartiment Amazon S3 de point de contrôle, il est susceptible de créer des données de pickle malveillantes qui s'exécutent lorsqu'elles sont chargées par un point de contrôle hiérarchisé géré. **Bonnes pratiques pour le stockage Amazon S3** Lorsque vous utilisez le point de contrôle hiérarchisé géré avec le stockage Amazon S3 : + **Restreindre l’accès au compartiment Amazon S3** : veillez à ce que seuls les utilisateurs autorisés et les rôles associés à votre cluster d’entraînement aient accès au compartiment Amazon S3 utilisé pour les points de contrôle. + **Mettre en œuvre des stratégies de compartiment** : configurez des stratégies de compartiment appropriées pour empêcher les accès ou les modifications non autorisés. + **Valider les modèles d'accès** : implémentez la journalisation pour valider les modèles d'accès à vos compartiments Amazon S3 de point de contrôle. + **Valider les noms des compartiments** : faites preuve de prudence lors de la sélection des noms de compartiments afin d’éviter tout détournement potentiel des compartiments. **Points de terminaison réseau** Le point de contrôle hiérarchisé géré active les points de terminaison réseau de chacun de vos nœuds de calcul sur les ports suivants : 9200/TCP, 9209/UDP, 9210/UDP, 9219/UDP, 9220/UDP, 9229/UDP, 9230/UDP, 9240/UDP. Ces ports sont nécessaires au fonctionnement du service de points de contrôle et au maintien de la synchronisation des données. Par défaut, SageMaker la configuration réseau restreint l'accès à ces points de terminaison pour des raisons de sécurité. Nous vous recommandons de conserver ces restrictions par défaut. Lorsque vous configurez les paramètres réseau de vos nœuds et de votre VPC, suivez les AWS meilleures pratiques pour les VPCs groupes de sécurité et. ACLs Pour plus d’informations, consultez les ressources suivantes : + [ SageMaker HyperPod Conditions préalables d'Amazon](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-prerequisites.html#sagemaker-hyperpod-prerequisites-optional-vpcCluster) + [Bonnes pratiques de sécurité de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html) # SageMaker HyperPod gouvernance des tâches SageMaker HyperPod la gouvernance des tâches est un système de gestion robuste conçu pour rationaliser l'allocation des ressources et garantir une utilisation efficace des ressources informatiques au sein des équipes et des projets pour vos clusters Amazon EKS. Cela permet aux administrateurs de définir : + des niveaux de priorité pour différentes tâches ; + l’allocation de ressources de calcul pour chaque équipe ; + comment chaque équipe prête et emprunte des ressources de calcul inactives ; + si une équipe préempte ses propres tâches. HyperPod la gouvernance des tâches fournit également l'observabilité du cluster Amazon EKS, offrant une visibilité en temps réel sur la capacité du cluster. Cela inclut la disponibilité et l’utilisation des ressources de calcul, l’allocation et l’utilisation des équipes, ainsi que les informations sur l’exécution des tâches et les temps d’attente, vous permettant de prendre des décisions éclairées et de gérer vos ressources de manière proactive. Les sections suivantes expliquent comment configurer, comprendre les concepts clés et utiliser la gouvernance des HyperPod tâches pour vos clusters Amazon EKS. **Topics** + [Configuration pour la gouvernance des SageMaker HyperPod tâches](sagemaker-hyperpod-eks-operate-console-ui-governance-setup.md) + [Tableau de bord](sagemaker-hyperpod-eks-operate-console-ui-governance-metrics.md) + [Tâches](sagemaker-hyperpod-eks-operate-console-ui-governance-tasks.md) + [Stratégies](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md) + [Exemples de AWS CLI commandes de gouvernance des HyperPod tâches](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md) + [Dépannage](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md) + [Document d'attribution pour la gouvernance des SageMaker HyperPod tâches Amazon](sagemaker-hyperpod-eks-operate-console-ui-governance-attributions.md) # Configuration pour la gouvernance des SageMaker HyperPod tâches La section suivante fournit des informations sur la configuration d'Amazon CloudWatch Observability EKS et des modules complémentaires de gouvernance des SageMaker HyperPod tâches. Assurez-vous que vous disposez de la politique d'autorisation minimale pour les administrateurs de HyperPod clusters avec Amazon EKS, dans[Utilisateurs IAM pour l’administrateur de cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). Cela inclut les autorisations nécessaires pour exécuter le SageMaker HyperPod noyau APIs et gérer les SageMaker HyperPod clusters au sein de votre Compte AWS entreprise, en effectuant les tâches dans[Gestion des SageMaker HyperPod clusters orchestrés par Amazon EKS](sagemaker-hyperpod-eks-operate.md). **Topics** + [Configuration du tableau de bord](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.md) + [Configuration de la gouvernance des tâches](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-task-governance.md) # Configuration du tableau de bord Utilisez les informations suivantes pour configurer le module complémentaire Amazon SageMaker HyperPod Amazon CloudWatch Observability EKS. Cela vous permet de disposer d’un tableau de bord visuel détaillé qui fournit une vue des métriques relatives au matériel de votre cluster EKS, à l’allocation des équipes et aux tâches. Si vous rencontrez des problèmes lors de la configuration, consultez [Dépannage](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md) pour découvrir les solutions de dépannage connues. **Topics** + [HyperPod Conditions préalables requises pour le module complémentaire Amazon CloudWatch Observability EKS](#hp-eks-dashboard-prerequisites) + [HyperPod Configuration du module complémentaire Amazon CloudWatch Observability EKS](#hp-eks-dashboard-setup) ## HyperPod Conditions préalables requises pour le module complémentaire Amazon CloudWatch Observability EKS La section suivante décrit les conditions préalables requises avant d’installer le module complémentaire d’observabilité Amazon EKS. + Assurez-vous que vous disposez de la politique d'autorisation minimale pour les administrateurs de HyperPod cluster, dans[Utilisateurs IAM pour l’administrateur de cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). + Attachez la politique IAM `CloudWatchAgentServerPolicy` à vos composants master. Pour ce faire, entrez la commande suivante. Remplacez `my-worker-node-role` par le rôle IAM utilisé par vos composants master Kubernetes. ``` aws iam attach-role-policy \ --role-name my-worker-node-role \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy ``` ## HyperPod Configuration du module complémentaire Amazon CloudWatch Observability EKS Utilisez les options suivantes pour configurer le module complémentaire Amazon SageMaker HyperPod Amazon CloudWatch Observability EKS. ------ #### [ Setup using the SageMaker AI console ] Les autorisations suivantes sont requises pour configurer et visualiser le tableau de bord de gouvernance des HyperPod tâches. Cette section développe les autorisations répertoriées dans [Utilisateurs IAM pour l’administrateur de cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). Pour gérer la gouvernance des tâches, utilisez l’exemple de politique : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sagemaker:ListClusters", "sagemaker:DescribeCluster", "sagemaker:ListComputeQuotas", "sagemaker:CreateComputeQuota", "sagemaker:UpdateComputeQuota", "sagemaker:DescribeComputeQuota", "sagemaker:DeleteComputeQuota", "sagemaker:ListClusterSchedulerConfigs", "sagemaker:DescribeClusterSchedulerConfig", "sagemaker:CreateClusterSchedulerConfig", "sagemaker:UpdateClusterSchedulerConfig", "sagemaker:DeleteClusterSchedulerConfig", "eks:ListAddons", "eks:CreateAddon", "eks:DescribeAddon", "eks:DescribeCluster", "eks:DescribeAccessEntry", "eks:ListAssociatedAccessPolicies", "eks:AssociateAccessPolicy", "eks:DisassociateAccessPolicy" ], "Resource": "*" } ] } ``` ------ Pour accorder des autorisations permettant de gérer Amazon CloudWatch Observability Amazon EKS et de consulter le tableau de bord du HyperPod cluster via la console SageMaker AI, utilisez l'exemple de politique ci-dessous : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:ListAddons", "eks:CreateAddon", "eks:UpdateAddon", "eks:DescribeAddon", "eks:DescribeAddonVersions", "sagemaker:DescribeCluster", "sagemaker:DescribeClusterNode", "sagemaker:ListClusterNodes", "sagemaker:ListClusters", "sagemaker:ListComputeQuotas", "sagemaker:DescribeComputeQuota", "sagemaker:ListClusterSchedulerConfigs", "sagemaker:DescribeClusterSchedulerConfig", "eks:DescribeCluster", "cloudwatch:GetMetricData", "eks:AccessKubernetesApi" ], "Resource": "*" } ] } ``` ------ Accédez à l'onglet **Tableau de bord** de la SageMaker HyperPod console pour installer Amazon CloudWatch Observability EKS. Pour vous assurer que les métriques liées à la gouvernance des tâches sont incluses dans le **tableau de bord**, cochez la case des métriques Kueue. L'activation des métriques Kueue permet d'augmenter CloudWatch **les coûts des métriques**, une fois la limite du niveau gratuit atteinte. Pour plus d'informations, consultez la section **Mesures** dans [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). ------ #### [ Setup using the EKS AWS CLI ] Utilisez la AWS CLI commande EKS suivante pour installer le module complémentaire : ``` aws eks create-addon --cluster-name cluster-name --addon-name amazon-cloudwatch-observability --configuration-values "configuration json" ``` Voici un exemple du code JSON des valeurs de configuration : ``` { "agent": { "config": { "logs": { "metrics_collected": { "kubernetes": { "kueue_container_insights": true, "enhanced_container_insights": true }, "application_signals": { } } }, "traces": { "traces_collected": { "application_signals": { } } } }, }, } ``` ------ #### [ Setup using the EKS Console UI ] 1. Accédez à la [console EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez votre cluster. 1. Choisissez **Modules complémentaires**. 1. Trouvez le module complémentaire **Amazon CloudWatch Observability** et installez-le. Installez la version >= 2.4.0 pour le module complémentaire. 1. Incluez les valeurs de configuration JSON suivantes : ``` { "agent": { "config": { "logs": { "metrics_collected": { "kubernetes": { "kueue_container_insights": true, "enhanced_container_insights": true }, "application_signals": { } }, }, "traces": { "traces_collected": { "application_signals": { } } } }, }, } ``` ------ Une fois le module complémentaire EKS Observability installé avec succès, vous pouvez consulter les métriques de votre cluster EKS sous l'onglet **Tableau de bord de** la HyperPod console. # Configuration de la gouvernance des tâches Cette section contient des informations sur la configuration du module complémentaire Amazon SageMaker HyperPod Task Governance EKS. Cela inclut l’octroi d’autorisations qui vous permettent de définir la priorité des tâches, l’allocation de calcul pour les équipes, la manière dont les ressources de calcul inactives sont partagées et la préemption des tâches pour les équipes. Si vous rencontrez des problèmes lors de la configuration, consultez [Dépannage](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md) pour découvrir les solutions de dépannage connues. **Topics** + [Paramètres Kueue](#hp-eks-task-governance-kueue-settings) + [HyperPod Conditions préalables à la gouvernance des tâches](#hp-eks-task-governance-prerequisites) + [HyperPod configuration de la gouvernance des tâches](#hp-eks-task-governance-setup) ## Paramètres Kueue HyperPod Le module complémentaire EKS de gouvernance des tâches installe [Kueue](https://github.com/kubernetes-sigs/kueue/tree/main/apis/kueue) pour vos clusters HyperPod EKS. Kueue est un système natif de Kubernetes qui gère les quotas et la façon dont les tâches les consomment. | Version complémentaire de gouvernance des HyperPod tâches EKS | Version de Kueue qui est installée dans le cadre de l’extension | | --- | --- | | v1.1.3 | v0.12.0 | **Note** Kueue v.012.0 et versions ultérieures ne sont pas inclus dans kueue-rbac-proxy l'installation. Les versions précédentes étaient peut-être kueue-rbac-proxy installées. Par exemple, si vous utilisez Kueue v0.8.1, vous pourriez avoir la v0.18.1. kueue-rbac-proxy HyperPod la gouvernance des tâches exploite Kueue pour la mise en file d'attente des tâches, la planification et la gestion des quotas natifs de Kubernetes, et est installée avec le module complémentaire EKS de gouvernance des tâches. HyperPod Une fois installé, il HyperPod crée et modifie des ressources Kubernetes SageMaker gérées par l'IA telles que`KueueManagerConfig`,,,, et`ClusterQueues`. `LocalQueues` `WorkloadPriorityClasses` `ResourceFlavors` `ValidatingAdmissionPolicies` Bien que les administrateurs Kubernetes aient la possibilité de modifier l'état de ces ressources, il est possible que toute modification apportée à une ressource SageMaker gérée par l'IA soit mise à jour et remplacée par le service. Les informations suivantes décrivent les paramètres de configuration utilisés par le module complémentaire de gouvernance des HyperPod tâches pour configurer Kueue. ``` apiVersion: config.kueue.x-k8s.io/v1beta1 kind: Configuration health: healthProbeBindAddress: :8081 metrics: bindAddress: :8443 enableClusterQueueResources: true webhook: port: 9443 manageJobsWithoutQueueName: false leaderElection: leaderElect: true resourceName: c1f6bfd2.kueue.x-k8s.io controller: groupKindConcurrency: Job.batch: 5 Pod: 5 Workload.kueue.x-k8s.io: 5 LocalQueue.kueue.x-k8s.io: 1 ClusterQueue.kueue.x-k8s.io: 1 ResourceFlavor.kueue.x-k8s.io: 1 clientConnection: qps: 50 burst: 100 integrations: frameworks: - "batch/job" - "kubeflow.org/mpijob" - "ray.io/rayjob" - "ray.io/raycluster" - "jobset.x-k8s.io/jobset" - "kubeflow.org/mxjob" - "kubeflow.org/paddlejob" - "kubeflow.org/pytorchjob" - "kubeflow.org/tfjob" - "kubeflow.org/xgboostjob" - "pod" - "deployment" - "statefulset" - "leaderworkerset.x-k8s.io/leaderworkerset" podOptions: namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: NotIn values: [ kube-system, kueue-system ] fairSharing: enable: true preemptionStrategies: [LessThanOrEqualToFinalShare, LessThanInitialShare] resources: excludeResourcePrefixes: [] ``` Pour plus d’informations sur chaque entrée de configuration, consultez [Configuration](https://kueue.sigs.k8s.io/docs/reference/kueue-config.v1beta1/#Configuration) dans la documentation de Kueue. ## HyperPod Conditions préalables à la gouvernance des tâches + Assurez-vous que vous disposez de la politique d'autorisation minimale pour les administrateurs de HyperPod cluster, dans[Utilisateurs IAM pour l’administrateur de cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). Cela inclut les autorisations nécessaires pour exécuter le SageMaker HyperPod noyau APIs, gérer les SageMaker HyperPod clusters au sein de votre Compte AWS entreprise et effectuer les tâches dans[Gestion des SageMaker HyperPod clusters orchestrés par Amazon EKS](sagemaker-hyperpod-eks-operate.md). + Vous aurez besoin d’une version de Kubernetes >= 1.30. Pour obtenir des instructions, consultez [Mise à jour des clusters existants vers la nouvelle version de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html). + Si Kueue est déjà installé dans leurs clusters, désinstallez Kueue avant d’installer le module complémentaire EKS. + Un HyperPod nœud doit déjà exister dans le cluster EKS avant d'installer le module complémentaire de gouvernance des HyperPod tâches. ## HyperPod configuration de la gouvernance des tâches Vous trouverez ci-dessous des informations sur la manière de configurer la gouvernance des HyperPod tâches. ------ #### [ Setup using the SageMaker AI console ] Vous trouverez ci-dessous des informations sur la configuration de la gouvernance des HyperPod tâches à l'aide de la SageMaker HyperPod console. Vous disposez déjà de toutes les autorisations suivantes si vous avez déjà accordé des autorisations pour gérer Amazon CloudWatch Observability EKS et consulter le tableau de bord du HyperPod cluster via la console SageMaker AI du[HyperPod Configuration du module complémentaire Amazon CloudWatch Observability EKS](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.md#hp-eks-dashboard-setup). Si vous ne l'avez pas configuré, utilisez l'exemple de politique ci-dessous pour accorder les autorisations nécessaires à la gestion du module complémentaire de gouvernance des HyperPod tâches et à l'affichage du tableau de bord du HyperPod cluster via la console d' SageMaker intelligence artificielle. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:ListAddons", "eks:CreateAddon", "eks:UpdateAddon", "eks:DescribeAddon", "eks:DescribeAddonVersions", "sagemaker:DescribeCluster", "sagemaker:DescribeClusterNode", "sagemaker:ListClusterNodes", "sagemaker:ListClusters", "eks:DescribeCluster", "eks:AccessKubernetesApi" ], "Resource": "*" } ] } ``` ------ Accédez à l'onglet **Tableau de bord** de la SageMaker HyperPod console pour installer le module complémentaire Amazon SageMaker HyperPod Task Governance. ------ #### [ Setup using the Amazon EKS AWS CLI ] Utilisez l'exemple de AWS CLI commande [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/create-addon.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/create-addon.html)EKS pour configurer l'API Amazon EKS de gouvernance des HyperPod tâches et l'interface utilisateur de la console à l'aide de AWS CLI : ``` aws eks create-addon --region region --cluster-name cluster-name --addon-name amazon-sagemaker-hyperpod-taskgovernance ``` ------ Vous pouvez consulter l'onglet **Politiques** de la console HyperPod SageMaker AI si l'installation a réussi. Vous pouvez également utiliser l'exemple de AWS CLI commande [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/describe-addon.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/describe-addon.html)EKS suivant pour vérifier l'état. ``` aws eks describe-addon --region region --cluster-name cluster-name --addon-name amazon-sagemaker-hyperpod-taskgovernance ``` # Tableau de bord Amazon SageMaker HyperPod Task Governance fournit un tableau de bord complet des indicateurs d'utilisation de votre cluster Amazon EKS, y compris les indicateurs relatifs au matériel, aux équipes et aux tâches. Vous trouverez ci-dessous des informations sur le tableau de bord de votre cluster HyperPod EKS. Le tableau de bord fournit une vue complète des métriques d’utilisation du cluster, y compris des métriques relatives au matériel, aux équipes et aux tâches. Vous devez installer le module complémentaire EKS pour visualiser le tableau de bord. Pour de plus amples informations, veuillez consulter [Configuration du tableau de bord](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.md). Dans la [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/), sous **HyperPod Clusters**, vous pouvez accéder à la HyperPod console et consulter la liste des HyperPod clusters de votre région. Choisissez votre cluster et accédez à l’onglet **Tableau de bord**. Le tableau de bord contient les métriques suivantes. Vous pouvez télécharger les données d’une section en choisissant l’option **Exporter** correspondante. **Utilisation** Fournit l'état du cluster EKS point-in-time et des mesures basées sur les tendances pour les ressources informatiques critiques. Par défaut, **tous les groupes d’instances** sont affichés. Utilisez le menu déroulant pour filtrer vos groupes d’instances. Les métriques incluses dans cette section sont les suivantes : + Nombre total d’instances de récupération, en cours d’exécution et en attente. Le nombre d’instances de récupération en attente correspond au nombre d’instances qui nécessitent une attention particulière pour être récupérées. + GPUs, mémoire GPU, CPUs mémoire v et v. CPUs + Utilisation GPU, utilisation de la mémoire GPU, utilisation vCPU et utilisation de la mémoire vCPU. + Graphique interactif de l’utilisation de votre GPU et de votre vCPU. **Équipes** Fournit des informations sur la gestion des ressources spécifiques aux équipes. Cela inclut notamment les éléments suivants : + Allocation d’instances et de GPU. + Taux d’utilisation de GPU. + Statistiques de GPU emprunté. + Statut de la tâche (en cours ou en attente). + Graphique à barres de l’utilisation GPU par rapport à l’allocation des ressources de calcul entre les équipes. + Informations détaillées GPU et vCPU des équipes. Par défaut, les informations affichées incluent **Toutes les équipes**. Vous pouvez filtrer par équipe et par instance en choisissant les menus déroulants. Dans le graphique interactif, vous pouvez filtrer en fonction du temps. **Tâches** **Note** Pour afficher les tâches de votre cluster HyperPod EKS dans le tableau de bord : Configurez le contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour les utilisateurs de data scientists dans l'espace de HyperPod noms désigné afin d'autoriser l'exécution de tâches sur les clusters orchestrés par Amazon EKS. Les espaces de noms suivent le format `hyperpod-ns-team-name`. Pour établir les autorisations RBAC, reportez-vous aux [instructions de création d’un rôle d’équipe](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role). Assurez-vous que votre tâche est soumise avec l’espace de noms et les étiquettes de classe de priorité appropriés. Pour visualiser un exemple complet, consultez [Soumettre une tâche à une file d'attente et à un SageMaker espace de noms gérés par l'IA](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job). Fournit des informations sur les métriques liées aux tâches. Cela inclut le nombre de tâches en cours, en attente et préemptées, ainsi que les statistiques d’exécution et de temps d’attente. Par défaut, les informations affichées incluent **Toutes les équipes**. Vous pouvez filtrer par équipe en choisissant le menu déroulant. Dans le graphique interactif, vous pouvez filtrer en fonction du temps. # Tâches Vous trouverez ci-dessous des informations sur les tâches du cluster Amazon SageMaker HyperPod EKS. Les tâches sont des opérations ou des tâches envoyées au cluster. Il peut s’agir d’opérations de machine learning, telles que l’entraînement, l’exécution d’expériences ou l’inférence. La liste des détails des tâches consultables inclut le statut, la durée d’exécution et la quantité de ressources de calcul utilisée par tâche. Dans la [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/), sous **HyperPod Clusters**, vous pouvez accéder à la HyperPod console et consulter la liste des HyperPod clusters de votre région. Choisissez votre cluster et accédez à l’onglet **Tâches**. Pour que l’onglet **Tâches** soit visible par toute personne autre que l’administrateur, celui-ci doit [ajouter une entrée d’accès au cluster EKS pour le rôle IAM](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html). **Note** Pour afficher les tâches de votre cluster HyperPod EKS dans le tableau de bord : Configurez le contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour les utilisateurs de data scientists dans l'espace de HyperPod noms désigné afin d'autoriser l'exécution de tâches sur les clusters orchestrés par Amazon EKS. Les espaces de noms suivent le format `hyperpod-ns-team-name`. Pour établir les autorisations RBAC, reportez-vous aux [instructions de création d’un rôle d’équipe](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role). Assurez-vous que votre tâche est soumise avec l’espace de noms et les étiquettes de classe de priorité appropriés. Pour visualiser un exemple complet, consultez [Soumettre une tâche à une file d'attente et à un SageMaker espace de noms gérés par l'IA](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job). Pour les clusters EKS, les tâches kubeflow (PyTorch, MPI, TensorFlow) sont affichées. Par défaut, PyTorch les tâches sont affichées. Vous pouvez filtrer les PyTorch TensorFlow tâches MPI en choisissant le menu déroulant ou en utilisant le champ de recherche. Les informations affichées pour chaque tâche incluent le nom, le statut, l’espace de noms, la classe de priorité et l’heure de création de la tâche. # Utilisation de la planification basée sur la topologie dans la gouvernance des tâches Amazon SageMaker HyperPod La planification basée sur la topologie dans Amazon SageMaker HyperPod Task Governance optimise l'efficacité de la formation des charges de travail d'apprentissage automatique distribuées en plaçant des pods en fonction de la topologie du réseau physique de vos instances Amazon EC2. En tenant compte de la structure hiérarchique de l' AWS infrastructure, y compris les zones de disponibilité, les blocs réseau et les racks physiques, la planification basée sur la topologie garantit que les pods nécessitant des communications fréquentes sont planifiés à proximité afin de minimiser la latence du réseau. Ce placement intelligent est particulièrement utile pour les tâches de formation à l'apprentissage automatique à grande échelle qui impliquent une pod-to-pod communication intensive, ce qui se traduit par une réduction des temps de formation et une utilisation plus efficace des ressources au sein de votre cluster. **Note** Pour utiliser la planification tenant compte de la topologie, assurez-vous que votre version de la gouvernance des HyperPod tâches est v1.2.2-eksbuild.1 ou supérieure. L’ordonnancement topologique prend en charge les types d’instances suivants : + ml.p3dn.24xlarge + ml.p4d.24xlarge + ml.p4de.24xlarge + ml.p5.48xlarge + ml.p5e.48xlarge + ml.p5en.48xlarge + ml.p6e-gb200.36xlarge + ml.trn1.2xlarge + ml.trn1.32xlarge + ml.trn1n.32xlarge + ml.trn2.48xlarge + ml.trn2u.48xlarge La planification basée sur la topologie s'intègre à vos HyperPod flux de travail existants tout en fournissant des préférences topologiques flexibles via les fichiers KUBECTL YAML et la CLI. HyperPod HyperPod la gouvernance des tâches configure automatiquement les nœuds du cluster avec des étiquettes topologiques et fonctionne avec des politiques de gouvernance des HyperPod tâches et des mécanismes d'emprunt de ressources, garantissant ainsi que la planification tenant compte de la topologie ne perturbe pas vos processus opérationnels actuels. Grâce à la prise en charge intégrée des spécifications topologiques préférées et requises, vous pouvez optimiser le placement des charges de travail en fonction de vos exigences de performances spécifiques tout en conservant la flexibilité nécessaire pour revenir à une planification standard lorsque les contraintes topologiques ne peuvent pas être satisfaites. En intégrant des étiquettes adaptées à la topologie HyperPod, vous pouvez améliorer leurs charges de travail d'apprentissage automatique grâce à un placement intelligent des modules qui tient compte de l'infrastructure réseau physique. HyperPod la gouvernance des tâches optimise automatiquement la planification des pods en fonction de la topologie hiérarchique du centre de données, ce qui se traduit directement par une réduction de la latence du réseau et une amélioration des performances de formation pour les tâches de machine learning distribuées. Cette prise en compte de la topologie est particulièrement utile pour les charges de travail de machine learning à grande échelle, car elle minimise les frais de communication en rapprochant stratégiquement les pods associés dans la hiérarchie du réseau. Il en résulte une latence du réseau de communication optimisée entre les pods, une utilisation plus efficace des ressources et de meilleures performances globales pour les AI/ML applications gourmandes en calcul, le tout sans que vous ayez à gérer manuellement des configurations de topologie réseau complexes. Les étiquettes suivantes indiquent les couches réseau topologiques disponibles dans lesquelles la gouvernance des HyperPod tâches peut planifier des pods : + topologie.k8s.aws/ -1 network-node-layer + topologie.k8s.aws/ -2 network-node-layer + topologie.k8s.aws/ -3 network-node-layer + topology.k8s.aws/ultraserver-id Pour utiliser l’ordonnancement topologique, incluez les étiquettes suivantes dans votre fichier YAML : + kueue.x-k8s.io/ podset-required-topology - indique que cette tâche doit disposer des pods requis et que tous les pods des nœuds doivent être planifiés au sein de la même couche topologique. + kueue.x-k8s.io/ podset-preferred-topology - indique que cette tâche doit comporter les pods, mais que la planification des pods au sein de la même couche topologique est préférable mais pas obligatoire. HyperPod la gouvernance des tâches essaiera de planifier les pods au sein d'une couche avant d'essayer la couche topologique suivante. Si les ressources ne partagent pas la même étiquette topologique, la tâche sera suspendue. La tâche figurera sur la liste d’attente. Une fois que Kueue aura constaté qu’il y a suffisamment de ressources, il admettra et exécutera la tâche. L’exemple suivant montre comment utiliser les étiquettes dans vos fichiers YAML : ``` apiVersion: batch/v1 kind: Job metadata: name: test-tas-job namespace: hyperpod-ns-team-name labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue kueue.x-k8s.io/priority-class: PRIORITY_CLASS-priority spec: parallelism: 10 completions: 10 suspend: true template: metadata: labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue annotations: kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3" or kueue.x-k8s.io/podset-preferred-topology: "topology.k8s.aws/network-node-layer-3" spec: nodeSelector: topology.k8s.aws/network-node-layer-3: TOPOLOGY_LABEL_VALUE containers: - name: dummy-job image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0 args: ["3600s"] resources: requests: cpu: "100" restartPolicy: Never ``` Le tableau suivant explique les nouveaux paramètres que vous pouvez utiliser dans le fichier YAML kubectl. | Paramètre | Description | | --- | --- | | kueue.x-k8s.io/queue-name | Nom de la file d’attente à utiliser pour exécuter la tâche. Le format de ce nom de file d’attente doit être hyperpod-ns-team-name-localqueue. | | kueue.x-k8s.io/priority-class | Permet de spécifier une priorité pour la planification des pods. Cette spécification est facultative. | | annotations | Contient l’annotation topologique que vous attachez à la tâche. Les topologies disponibles sont kueue.x-k8s.io/ et podset-required-topology kueue.x-k8s.io/. podset-preferred-topology Vous pouvez utiliser une annotation ou nodeSelector, mais pas les deux en même temps. | | nodeSelector | Spécifie la couche réseau qui représente la couche de placement des instances Amazon EC2. Utilisez ce champ ou une annotation, mais pas les deux en même temps. Dans votre fichier YAML, vous pouvez également utiliser le paramètre nodeSelector pour choisir la couche exacte pour vos pods. Pour obtenir la valeur de votre étiquette, utilisez l'opération [ DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html)API. | Vous pouvez également utiliser la HyperPod CLI pour exécuter votre tâche et utiliser une planification adaptée à la topologie. Pour plus d'informations sur la HyperPod CLI, consultez[SageMaker HyperPod Commandes CLI](sagemaker-hyperpod-eks-hyperpod-cli-reference.md). ``` hyp create hyp-pytorch-job \ --version 1.1 \ --job-name sample-pytorch-job \ --image 123456789012.dkr.ecr.us-west-2.amazonaws.com/ptjob:latest \ --pull-policy "Always" \ --tasks-per-node 1 \ --max-retry 1 \ --priority high-priority \ --namespace hyperpod-ns-team-name \ --queue-name hyperpod-ns-team-name-localqueue \ --preferred-topology-label topology.k8s.aws/network-node-layer-1 ``` Voici un exemple de fichier de configuration que vous pouvez utiliser pour exécuter un PytorchJob avec des étiquettes topologiques. Le fichier est largement similaire si vous souhaitez exécuter des tâches MPI et Tensorflow. Si vous souhaitez plutôt exécuter ces tâches, n'oubliez pas de modifier le fichier de configuration en conséquence, par exemple en utilisant la bonne image au lieu de PyTorchJob. Si vous exécutez un PyTorchJob, vous pouvez attribuer différentes topologies aux nœuds maître et secondaire. PyTorchJob possède toujours un nœud principal. Nous vous recommandons donc d'utiliser plutôt la topologie pour prendre en charge les modules de travail. ``` apiVersion: kubeflow.org/v1 kind: PyTorchJob metadata: annotations: {} labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue name: tas-test-pytorch-job namespace: hyperpod-ns-team-name spec: pytorchReplicaSpecs: Master: replicas: 1 restartPolicy: OnFailure template: metadata: labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue spec: containers: - command: - python3 - /opt/pytorch-mnist/mnist.py - --epochs=1 image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727 imagePullPolicy: Always name: pytorch Worker: replicas: 10 restartPolicy: OnFailure template: metadata: # annotations: # kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3" labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue spec: containers: - command: - python3 - /opt/pytorch-mnist/mnist.py - --epochs=1 image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727 imagePullPolicy: Always name: pytorch resources: limits: cpu: 1 requests: memory: 200Mi cpu: 1 #nodeSelector: # topology.k8s.aws/network-node-layer-3: xxxxxxxxxxx ``` Pour voir les topologies de votre cluster, utilisez l'opération [ DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html)API. Par défaut, les topologies sont masquées dans AWS Management Console Amazon SageMaker Studio. Suivez ces étapes pour les afficher dans l’interface que vous utilisez. **SageMaker Studio** 1. Dans SageMaker Studio, accédez à votre cluster. 1. Dans la vue Tâches, choisissez le menu des options dans la colonne Nom, puis choisissez **Gérer les colonnes**. 1. Sélectionnez **Topologie demandée** et **Contrainte topologique** pour ajouter les colonnes permettant d’afficher les informations topologiques dans la liste des pods Kubernetes. **AWS Management Console** 1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/). 1. Sous **HyperPod clusters**, choisissez **Cluster management**. 1. Choisissez l’onglet **Tâches**, puis l’icône représentant un engrenage. 1. Sous les attributs de l’instance, activez **Topologie demandée** et **Contrainte topologique**. 1. Choisissez **Confirmer** pour voir les informations topologiques dans le tableau. # Stratégies SageMaker HyperPod La gouvernance des tâches Amazon simplifie l'allocation des ressources de votre cluster Amazon EKS et la hiérarchisation des tâches. Vous trouverez ci-dessous des informations sur les politiques de cluster HyperPod EKS. Pour obtenir des informations sur la configuration de la gouvernance des tâches, consultez [Configuration de la gouvernance des tâches](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-task-governance.md). Les politiques sont divisées en **Définition des priorités des ressources de calcul** et **Allocation des ressources de calcul**. Les concepts de politique ci-dessous seront organisés dans le contexte de ces politiques. La **définition des priorités des ressources de calcul**, ou politique de cluster, détermine la manière dont les ressources de calcul inactives sont empruntées et la manière dont les tâches sont priorisées par les équipes. + L’**allocation des ressources de calcul inactives** définit la manière dont les ressources de calcul inactives sont allouées entre les équipes. C’est-à-dire comment les ressources de calcul inactives peuvent être empruntées aux équipes. Lorsque vous choisissez une **allocation de ressources de calcul inactives**, vous pouvez choisir entre : + **Premier arrivé, premier servi** : lorsque cette option est appliquée, les équipes ne sont pas priorisées les unes par rapport aux autres et chaque tâche entrante a des chances égales d’obtenir des ressources au-delà du quota. Les tâches sont priorisées dans l’ordre de leur soumission. Cela signifie qu’un utilisateur peut être en mesure d’utiliser 100 % des ressources de calcul inactives s’il en fait la demande en premier. + **Partage équitable** : lorsque cette option est appliquée, les équipes empruntent les ressources de calcul inactives en fonction du **Partage équitable de la pondération** qui leur a été attribué. Ces pondérations sont définies dans **Allocation de calcul**. Pour plus d’informations sur la façon d’utiliser cela, consultez [Exemples de partage de ressources de calcul inactives](#hp-eks-task-governance-policies-examples). + La **priorisation des tâches** définit la manière dont les tâches sont mises en file d’attente à mesure que le calcul devient disponible. Lorsque vous choisissez une **priorisation des tâches**, vous pouvez choisir entre : + **Premier arrivé, premier servi** : lorsqu’elles sont appliquées, les tâches sont mises en file d’attente dans l’ordre dans lequel elles sont demandées. + **Classement des tâches** : lorsqu’elles sont appliquées, les tâches sont mises en file d’attente dans l’ordre défini par leur ordre de priorité. Si cette option est choisie, vous devez ajouter des classes de priorité aux pondérations pour définir leur ordre de priorité. Les tâches de même classe de priorité seront exécutées selon le principe du premier arrivé, premier servi. Lorsque cette option est activée dans Allocation de calcul, les tâches sont préemptées des tâches les moins prioritaires par des tâches plus prioritaires au sein de l’équipe. Lorsque les scientifiques des données soumettent des tâches au cluster, ils utilisent le nom de la classe de priorité dans le fichier YAML. La classe de priorité est au format `priority-class-name-priority`. Pour obtenir un exemple, consultez [Soumettre une tâche à une file d'attente et à un SageMaker espace de noms gérés par l'IA](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job). + **Classes de priorité** : ces classes établissent une priorité relative pour les tâches lors de l’emprunt d’une capacité. Lorsqu’une tâche est exécutée avec un quota emprunté, elle peut être préemptée par une autre tâche plus prioritaire, si aucune capacité supplémentaire n’est disponible pour la tâche entrante. Si la **préemption** est activée dans **Allocation de calcul**, une tâche plus prioritaire peut également préempter des tâches au sein de sa propre équipe. + **Le partage de ressources non allouées** permet aux équipes d'emprunter des ressources de calcul qui ne sont allouées à aucune équipe par le biais de quotas de calcul. Lorsque cette option est activée, la capacité de cluster non allouée devient disponible pour que les équipes puissent l'emprunter automatiquement. Pour de plus amples informations, veuillez consulter [Comment fonctionne le partage des ressources non allouées](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works). L’**allocation de calcul**, ou le quota de calcul, définit l’allocation de calcul d’une équipe et le poids (ou niveau de priorité) attribué à une équipe pour une allocation de ressources de calcul inactives équitable. + **Nom de l’équipe** : le nom de l’équipe. Un **espace de noms** correspondant sera créé, du type `hyperpod-ns-team-name`. + **Membres** : membres de l’espace de noms de l’équipe. Vous devrez configurer un contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour les utilisateurs de data scientists que vous souhaitez intégrer à cette équipe, afin d'exécuter des tâches sur des clusters HyperPod orchestrés avec Amazon EKS. Pour configurer un RBAC Kubernetes, utilisez les instructions fournies dans [create team role](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role). + **Partage équitable de la pondération** : il s’agit du niveau de priorité attribué à l’équipe lorsque l’option **Partage équitable** est appliquée pour **Allocation de calcul inactif**. La priorité la plus élevée a une pondération de 100 et la priorité la plus basse une pondération de 0. Une pondération plus élevée permet à une équipe d’accéder plus tôt aux ressources inutilisées dans le cadre d’une capacité partagée. Une pondération nulle correspond à la priorité la plus basse, ce qui signifie que cette équipe sera toujours désavantagée par rapport aux autres équipes. La pondération équitable donne un avantage comparatif à cette équipe lorsqu’elle est en concurrence avec d’autres pour les ressources disponibles. L’admission donne la priorité aux tâches planifiées par les équipes ayant les pondérations les plus élevées et l’emprunt le plus faible. Par exemple, si l’équipe A a une pondération de 10 et l’équipe B une pondération de 5, l’équipe A aura la priorité pour accéder aux ressources inutilisées (ses tâches seront planifiées avant celles de l’équipe B). + **Préemption des tâches** : le calcul est pris en charge par une tâche en fonction de sa priorité. Par défaut, l’équipe qui prête des ressources de calcul inactives préemptera les tâches des autres équipes. + **Prêt et emprunt** : comment l’équipe prête ses ressources de calcul inactives et si l’équipe peut emprunter à d’autres équipes. + Limite d'**emprunt basée sur le pourcentage : limite** de calcul inutilisée qu'une équipe est autorisée à emprunter, exprimée en pourcentage de son quota garanti. Une équipe peut emprunter jusqu'à 10 000 % du calcul alloué. La valeur que vous indiquez ici est interprétée comme un pourcentage. Par exemple, une valeur de 500 sera interprétée comme 500 %. Ce pourcentage s'applique uniformément à tous les types de ressources (CPU, GPU, mémoire) et à tous les types d'instances inclus dans le quota de l'équipe. + Limite d'**emprunt absolue : limite** de calcul inactif qu'une équipe est autorisée à emprunter, définie comme des valeurs de ressources absolues par type d'instance. Cela permet de contrôler de manière granulaire le comportement d'emprunt pour des types d'instances spécifiques. Vous devez spécifier des limites absolues en utilisant le même schéma que le **quota de calcul**, y compris le nombre d'instances, les accélérateurs, les vCPU, la mémoire ou les partitions d'accélérateur. Vous pouvez définir des limites absolues pour un ou plusieurs types d'instances dans le quota de votre équipe. Pour en savoir plus sur la manière dont ces concepts sont utilisés, tels que les classes de priorité et les espaces de noms, consultez [Exemples de AWS CLI commandes de gouvernance des HyperPod tâches](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md). ## Exemples de partage de ressources de calcul inactives Le quota réservé total ne doit pas dépasser la capacité disponible du cluster pour cette ressource, afin de garantir une gestion appropriée des quotas. Par exemple, si un cluster comprend 20 instances `ml.c5.2xlarge`, le quota cumulé attribué aux équipes doit rester inférieur à 20. Si les politiques d’**allocation de calcul** pour les équipes autorisent l’action **Prêter et emprunter** ou **Prêter**, la capacité inutilisée est partagée entre ces équipes. Par exemple, l’option **Prêter et emprunter** est activée pour les équipes A et B. L’équipe A a un quota de 6 mais n’en utilise que 2 pour ses tâches, et l’équipe B a un quota de 5 et en utilise 4 pour ses tâches. Une tâche soumise à l’équipe B nécessite 4 ressources. 3 seront empruntées à l’équipe A. Si la politique d’**allocation de calcul** d’une équipe est définie sur **Ne pas prêter**, l’équipe ne sera pas en mesure d’emprunter de capacité supplémentaire au-delà de ses propres allocations. ## Comment fonctionne le partage des ressources non allouées Le partage des ressources non allouées gère automatiquement le pool de ressources qui ne sont allouées à aucun quota de calcul dans votre cluster. Cela signifie qu'il surveille HyperPod en permanence l'état de votre cluster et qu'il met automatiquement à jour la configuration appropriée au fil du temps. **Configuration initiale** + Lorsque vous définissez `IdleResourceSharing` la valeur `Enabled` dans votre ClusterSchedulerConfig (par défaut, c'est le cas`Disabled`), la gouvernance des HyperPod tâches commence à surveiller votre cluster et calcule les ressources inactives disponibles en soustrayant les quotas d'équipe de la capacité totale des nœuds. + Le partage des ressources non allouées ClusterQueues est créé pour représenter le pool de ressources empruntables. + Lorsque vous activez pour la première fois le partage de ressources non allouées, la configuration de l'infrastructure prend plusieurs minutes. Vous pouvez suivre les progrès par le biais de la politique `Status` et `DetailedStatus` dans ClusterSchedulerConfig. **Réconciliation continue** + HyperPod la gouvernance des tâches surveille en permanence les modifications telles que les ajouts ou suppressions de nœuds et les mises à jour des quotas de files d'attente des clusters. + Lorsque des modifications se produisent, le partage des ressources non allouées recalcule le quota et les met à jour. ClusterQueues La réconciliation s'effectue généralement en quelques secondes. **Surveillance** Vous pouvez vérifier que le partage des ressources non allouées est entièrement configuré en vérifiant le partage des ressources non allouées : ClusterQueues ``` kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing ``` Lorsque vous voyez ClusterQueues des noms tels que`hyperpod-ns-idle-resource-sharing-cq-1`, le partage de ressources non allouées est actif. Notez que plusieurs partages de ressources non allouées ClusterQueues peuvent exister en fonction du nombre de types de ressources dans votre cluster. ## Éligibilité des nœuds pour le partage de ressources non allouées Le partage de ressources non allouées inclut uniquement les nœuds qui répondent aux exigences suivantes : 1. **État de prêt pour les nœuds** + Les nœuds doivent être en `Ready` état pour contribuer au pool de ressources non allouées. + Les nœuds en `NotReady` état ou non prêts sont exclus des calculs de capacité. + Lorsqu'un nœud le devient`Ready`, il est automatiquement inclus dans le cycle de réconciliation suivant. 1. **État planifiable du nœud** + Les nœuds avec `spec.unschedulable: true` sont exclus du partage des ressources non allouées. + Lorsqu'un nœud redevient planifiable, il est automatiquement inclus dans le cycle de réconciliation suivant. 1. **Configuration MIG (nœuds GPU uniquement)** + Pour les nœuds GPU dotés d'un partitionnement MIG (GPU multi-instance), l'`nvidia.com/mig.config.state`étiquette doit apparaître `success` pour que le nœud contribue aux profils MIG au partage de ressources non allouées. + Ces nœuds seront réessayés automatiquement une fois la configuration MIG terminée avec succès. 1. **Types d'instances pris en charge** + L'instance doit être un type d' SageMaker HyperPod instance pris en charge. + Consultez la liste des types d'instances pris en charge dans le SageMaker HyperPod cluster. **Topics** + [Exemples de partage de ressources de calcul inactives](#hp-eks-task-governance-policies-examples) + [Comment fonctionne le partage des ressources non allouées](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works) + [Éligibilité des nœuds pour le partage de ressources non allouées](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-node-eligibility) + [Création de politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-create.md) + [Modification des politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-edit.md) + [Suppression de politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md) + [Allocation d'un quota de calcul dans le cadre de la gouvernance des SageMaker HyperPod tâches Amazon](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-compute-allocation.md) # Création de politiques Vous pouvez créer votre **politique de cluster** et vos configurations d’**allocation de calcul** dans l’onglet **Politiques**. Vous trouverez ci-dessous des instructions sur la création des configurations suivantes. + Créez votre **politique de cluster** pour mettre à jour la façon dont les tâches sont priorisées et les ressources de calcul inactives allouées. + Créez une **allocation de calcul** pour créer une nouvelle politique d’allocation de ressources de calcul pour une équipe. **Note** Lorsque vous créez une **allocation de calcul**, vous devez configurer un contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour les utilisateurs de data scientists dans l'espace de noms correspondant afin d'exécuter des tâches sur des clusters orchestrés avec Amazon EKS. HyperPod Les espaces de noms ont le format `hyperpod-ns-team-name`. Pour configurer un RBAC Kubernetes, utilisez les instructions fournies dans [create team role](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role). Pour plus d'informations sur les concepts de politique du cluster EKS en matière de gouvernance des HyperPod tâches, consultez[Stratégies](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md). **Création de politiques de gouvernance des HyperPod tâches** Cette procédure suppose que vous avez déjà créé un cluster Amazon EKS configuré avec HyperPod. Si vous ne l’avez pas déjà fait, consultez [Création d'un SageMaker HyperPod cluster avec l'orchestration Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md). 1. Accédez à la [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/). 1. Dans le volet de navigation de gauche, sous **HyperPodClusters**, choisissez **Cluster Management**. 1. Choisissez votre cluster Amazon EKS dans la liste **SageMaker HyperPoddes clusters**. 1. Choisissez l’onglet **Politiques**. 1. Pour créer votre **politique de cluster** : 1. Choisissez le bouton **Modifier** correspondant pour mettre à jour la façon dont les tâches sont priorisées et les ressources de calcul inactives allouées. 1. Une fois que vous avez apporté vos modifications, choisissez **Soumettre**. 1. Pour créer une **allocation de calcul** : 1. 1. Choisissez le bouton **Créer** correspondant. Vous accédez alors à la page de création de l’allocation de calcul. 1. Une fois que vous avez apporté vos modifications, choisissez **Soumettre**. # Modification des politiques Vous pouvez modifier votre **politique de cluster** et vos configurations d’**allocation de calcul** dans l’onglet **Politiques**. Vous trouverez ci-dessous des instructions sur la modification des configurations suivantes. + Modifiez votre **politique de cluster** pour mettre à jour la façon dont les tâches sont priorisées et les ressources de calcul inactives allouées. + Modifiez l’**allocation de calcul** pour créer une nouvelle politique d’allocation de ressources de calcul pour une équipe. **Note** Lorsque vous créez une **allocation de calcul**, vous devez configurer un contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour les utilisateurs de data scientists dans l'espace de noms correspondant afin d'exécuter des tâches sur des clusters orchestrés avec Amazon EKS. HyperPod Les espaces de noms ont le format `hyperpod-ns-team-name`. Pour configurer un RBAC Kubernetes, utilisez les instructions fournies dans [create team role](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role). Pour plus d'informations sur les concepts de politique du cluster EKS en matière de gouvernance des HyperPod tâches, consultez[Stratégies](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md). **Modifier les politiques de gouvernance des HyperPod tâches** Cette procédure suppose que vous avez déjà créé un cluster Amazon EKS configuré avec HyperPod. Si vous ne l’avez pas déjà fait, consultez [Création d'un SageMaker HyperPod cluster avec l'orchestration Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md). 1. Accédez à la [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/). 1. Dans le volet de navigation de gauche, sous **HyperPodClusters**, choisissez **Cluster Management**. 1. Choisissez votre cluster Amazon EKS dans la liste **SageMaker HyperPoddes clusters**. 1. Choisissez l’onglet **Politiques**. 1. Pour modifier votre **politique de cluster** : 1. Choisissez le bouton **Modifier** correspondant pour mettre à jour la façon dont les tâches sont priorisées et les ressources de calcul inactives allouées. 1. Une fois que vous avez apporté vos modifications, choisissez **Soumettre**. 1. Pour modifier votre **allocation de calcul** : 1. 1. Choisissez la configuration que vous souhaitez modifier sous **Allocation de calcul**. Vous accédez alors à la page des détails de configuration. 1. Si vous souhaitez modifier ces configurations, choisissez **Modifier**. 1. Une fois que vous avez apporté vos modifications, choisissez **Soumettre**. # Suppression de politiques Vous pouvez supprimer votre **politique de cluster** et vos configurations d'**allocation de calcul** à l'aide de la console SageMaker AI ou AWS CLI. La page suivante fournit des instructions sur la façon de supprimer vos politiques et configurations de gouvernance des SageMaker HyperPod tâches. Pour plus d'informations sur les concepts de politique du cluster EKS en matière de gouvernance des HyperPod tâches, consultez[Stratégies](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md). **Note** Si vous rencontrez des problèmes pour répertorier ou supprimer les politiques de gouvernance des tâches, vous devrez peut-être mettre à jour votre ensemble minimal d’autorisations d’administrateur de cluster. Consultez l’onglet **Amazon EKS** dans la section [Utilisateurs IAM pour l’administrateur de cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). Pour plus d’informations, consultez [Suppression de clusters](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md#hp-eks-troubleshoot-delete-policies). ## Supprimer les politiques de gouvernance des HyperPod tâches (console) Ce qui suit utilise la console SageMaker AI pour supprimer vos politiques de gouvernance des HyperPod tâches. **Note** Vous ne pouvez pas supprimer votre **politique de cluster** (`ClusterSchedulerConfig`) à l'aide de la console SageMaker AI. Pour savoir comment procéder à l'aide du AWS CLI, voir[Supprimer les politiques de gouvernance des HyperPod tâches (AWS CLI)](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete-cli). **Pour supprimer des politiques de gouvernance des tâches (console)** 1. Accédez à la [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/). 1. Dans le volet de navigation de gauche, sous **HyperPodClusters**, choisissez **Cluster Management**. 1. Choisissez votre cluster Amazon EKS dans la liste **SageMaker HyperPoddes clusters**. 1. Choisissez l’onglet **Politiques**. 1. Pour supprimer votre **allocation de calcul** (`ComputeQuota`) : 1. Dans la section **Allocation de calcul**, sélectionnez la configuration que vous souhaitez supprimer. 1. Dans le menu déroulant **Actions**, choisissez **Supprimer**. 1. Suivez les instructions fournies dans l’interface utilisateur pour réaliser la tâche. ## Supprimer les politiques de gouvernance des HyperPod tâches (AWS CLI) Ce qui suit utilise le AWS CLI pour supprimer vos politiques de gouvernance des HyperPod tâches. **Note** Si vous rencontrez des problèmes lors de l'utilisation des commandes suivantes, vous devrez peut-être mettre à jour votre AWS CLI. Pour plus d’informations, consultez [Installation ou mise à jour de la version la plus récente de l’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **Pour supprimer des politiques de gouvernance des tâches (AWS CLI)** Définissez d'abord vos variables pour les AWS CLI commandes qui suivent. ``` REGION=aws-region ``` 1. Obtenez le *cluster-arn* code associé aux politiques que vous souhaitez supprimer. Vous pouvez utiliser la AWS CLI commande suivante pour répertorier les clusters de votre Région AWS. ``` aws sagemaker list-clusters \ --region ${REGION} ``` 1. Pour supprimer vos allocations de calcul (`ComputeQuota`) : 1. Répertoriez tous les quotas de calcul associés au HyperPod cluster. ``` aws sagemaker list-compute-quotas \ --cluster-arn cluster-arn \ --region ${REGION} ``` 1. Pour chaque `compute-quota-id` que vous souhaitez supprimer, exécutez la commande suivante pour supprimer le quota de calcul. ``` aws sagemaker delete-compute-quota \ --compute-quota-id compute-quota-id \ --region ${REGION} ``` 1. Pour supprimer vos politiques de cluster (`ClusterSchedulerConfig`) : 1. Répertoriez toutes les politiques de cluster associées au HyperPod cluster. ``` aws sagemaker list-cluster-scheduler-configs \ --cluster-arn cluster-arn \ --region ${REGION} ``` 1. Pour chaque `cluster-scheduler-config-id` que vous souhaitez supprimer, exécutez la commande suivante pour supprimer le quota de calcul. ``` aws sagemaker delete-cluster-scheduler-config --cluster-scheduler-config-id scheduler-config-id \ --region ${REGION} ``` # Allocation d'un quota de calcul dans le cadre de la gouvernance des SageMaker HyperPod tâches Amazon Les administrateurs de clusters peuvent décider de la manière dont l’entreprise utilise le calcul acheté. Cela permet de réduire le gaspillage et les ressources inactives. Vous pouvez allouer un quota de calcul afin que les équipes puissent emprunter les ressources inutilisées les unes des autres. L'allocation de quotas de calcul dans le cadre de la gouvernance des HyperPod tâches permet aux administrateurs d'allouer des ressources au niveau de l'instance et à un niveau de ressources plus granulaire. Cette fonctionnalité permet une gestion flexible et efficace des ressources par les équipes en permettant un contrôle granulaire des ressources de calcul individuelles au lieu d’exiger des allocations d’instances complètes. L’allocation à un niveau granulaire élimine les inefficacités de l’allocation traditionnelle au niveau de l’instance. Grâce à cette approche, vous pouvez optimiser l’utilisation des ressources et réduire les ressources de calcul inactives. L’allocation de quotas de calcul prend en charge trois types d’allocation de ressources : accélérateurs, vCPU et mémoire. Les accélérateurs sont des composants d’instances de calcul accéléré qui exécutent des fonctions telles que les calculs en virgule flottante, le traitement graphique ou la mise en correspondance de modèles de données. Les accélérateurs incluent les GPUs accélérateurs Trainium et les cœurs de neurones. Pour le partage de GPU entre plusieurs équipes, différentes équipes peuvent recevoir des allocations de GPU spécifiques à partir du même type d’instance, maximisant ainsi l’utilisation du matériel des accélérateurs. Pour les charges de travail gourmandes en mémoire qui nécessitent de la RAM supplémentaire pour le prétraitement des données ou les scénarios de mise en cache des modèles, vous pouvez allouer un quota de mémoire supérieur au ratio par défaut. GPU-to-memory Pour les tâches de prétraitement gourmandes en ressources CPU qui nécessitent des ressources CPU importantes en plus de l’entraînement GPU, vous pouvez allouer une allocation de ressources CPU indépendante. Une fois que vous avez fourni une valeur, la gouvernance des HyperPod tâches calcule le ratio à l'aide de la formule **ressource allouée divisée par la quantité totale de ressources disponibles dans l'instance**. HyperPod la gouvernance des tâches utilise ensuite ce ratio pour appliquer des allocations par défaut à d'autres ressources, mais vous pouvez remplacer ces valeurs par défaut et les personnaliser en fonction de votre cas d'utilisation. Voici des exemples de scénarios illustrant la manière dont la gouvernance des HyperPod tâches alloue les ressources en fonction de vos valeurs : + **Seul l'accélérateur est spécifié** : la gouvernance des HyperPod tâches applique le ratio par défaut au vCPU et à la mémoire en fonction des valeurs de l'accélérateur. + **Seul le vCPU est spécifié** : la gouvernance des HyperPod tâches calcule le ratio et l'applique à la mémoire. Les accélérateurs sont définis sur 0. + **Seule la mémoire est spécifiée** : la gouvernance des HyperPod tâches calcule le ratio et l'applique au vCPU car le calcul est nécessaire pour exécuter les charges de travail spécifiées par la mémoire. Les accélérateurs sont définis sur 0. Pour contrôler l'allocation de quotas par programme, vous pouvez utiliser l'[ ComputeQuotaResourceConfig](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ComputeQuotaResourceConfig.html)objet et spécifier vos allocations en nombres entiers. ``` { "ComputeQuotaConfig": { "ComputeQuotaResources": [{ "InstanceType": "ml.g5.24xlarge", "Accelerators": "16", "vCpu": "200.0", "MemoryInGiB": "2.0" }] } } ``` Pour voir toutes les allocations allouées, y compris les valeurs par défaut, utilisez l'[ DescribeComputeQuota](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeComputeQuota.html)opération. Pour mettre à jour vos allocations, utilisez l'[ UpdateComputeQuota](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateComputeQuota.html)opération. Vous pouvez également utiliser la HyperPod CLI pour allouer des quotas de calcul. Pour plus d'informations sur la HyperPod CLI, consultez[Exécution de tâches sur SageMaker HyperPod des clusters orchestrés par Amazon EKS](sagemaker-hyperpod-eks-run-jobs.md). L'exemple suivant montre comment définir des quotas de calcul à l'aide de la HyperPod CLI. ``` hyp create hyp-pytorch-job --version 1.1 --job-name sample-job \ --image 123456789012.dkr.ecr.us-west-2.amazonaws.com/ptjob:latest \ --pull-policy "Always" \ --tasks-per-node 1 \ --max-retry 1 \ --priority high-priority \ --namespace hyperpod-ns-team-name \ --queue-name hyperpod-ns-team-name-localqueue \ --instance-type sample-instance-type \ --accelerators 1 \ --vcpu 3 \ --memory 1 \ --accelerators-limit 1 \ --vcpu-limit 4 \ --memory-limit 2 ``` Pour allouer des quotas à l'aide de la AWS console, procédez comme suit. 1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/). 1. Sous HyperPod clusters, choisissez **Cluster management**. 1. Sous **Allocations de calcul**, choisissez **Créer**. 1. Si vous n’avez pas encore d’instances, choisissez **Ajouter une allocation** pour ajouter une instance. 1. Sous **Allocations**, choisissez d’allouer par instances ou par ressources individuelles. Si vous allouez par ressources individuelles, l' SageMaker IA affecte automatiquement des allocations aux autres ressources selon le ratio que vous avez choisi. Pour annuler cette allocation basée sur le ratio, utilisez le bouton correspondant pour annuler ce calcul. 1. Répétez les étapes 4 e 5 pour configurer des instances supplémentaires. Après avoir alloué le quota de calcul, vous pouvez ensuite soumettre des tâches via la HyperPod CLI ou`kubectl`. HyperPodplanifie efficacement les charges de travail en fonction du quota disponible. # Allocation d'un quota de partition GPU Vous pouvez étendre l'allocation de quotas de calcul pour prendre en charge le partitionnement du GPU, permettant ainsi un partage précis des ressources au niveau de la partition du GPU. Lorsque le partitionnement du GPU est activé ou pris GPUs en charge dans le cluster, chaque GPU physique peut être partitionné en plusieurs processeurs isolés GPUs avec des allocations multiprocesseurs définies pour le calcul, la mémoire et le streaming. Pour plus d'informations sur le partitionnement du GPU, consultez[Utilisation de partitions GPU dans Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md). Vous pouvez attribuer des partitions GPU spécifiques à des équipes, ce qui permet à plusieurs équipes de partager un seul GPU tout en maintenant une isolation matérielle et des performances prévisibles. Par exemple, une instance ml.p5.48xlarge avec 8 H100 GPUs peut être partitionnée en partitions GPU, et vous pouvez allouer des partitions individuelles à différentes équipes en fonction de leurs exigences en matière de tâches. Lorsque vous spécifiez les allocations de partition GPU, la gouvernance des HyperPod tâches calcule les quotas de vCPU et de mémoire proportionnels en fonction de la partition GPU, de la même manière que l'allocation au niveau du GPU. Cette approche maximise l'utilisation du GPU en éliminant les capacités inutilisées et en permettant un partage rentable des ressources entre plusieurs tâches simultanées sur le même GPU physique. ## Création de quotas de calcul ``` aws sagemaker create-compute-quota \ --name "fractional-gpu-quota" \ --compute-quota-config '{ "ComputeQuotaResources": [ { "InstanceType": "ml.p4d.24xlarge", "AcceleratorPartition": { "Count": 4, "Type": "mig-1g.5gb" } } ], "ResourceSharingConfig": { "Strategy": "LendAndBorrow", "BorrowLimit": 100 } }' ``` ## Vérification des ressources de quota ``` # Check ClusterQueue kubectl get clusterqueues kubectl describe clusterqueue QUEUE_NAME # Check ResourceFlavors kubectl get resourceflavor kubectl describe resourceflavor FLAVOR_NAME ``` # Exemples de AWS CLI commandes de gouvernance des HyperPod tâches Vous pouvez l'utiliser HyperPod avec EKS via Kubectl ou via une HyperPod CLI personnalisée. Vous pouvez utiliser ces commandes via Studio ou AWS CLI. Vous trouverez ci-dessous des exemples de gouvernance des SageMaker HyperPod tâches, expliquant comment afficher les détails du cluster à l'aide des HyperPod AWS CLI commandes. Pour plus d'informations, notamment sur la procédure d'installation, consultez le [référentiel HyperPod CLI Github](https://github.com/aws/sagemaker-hyperpod-cli). **Topics** + [Obtention d’informations sur les quotas d’appareil accélérateur de cluster](#hp-eks-cli-get-clusters) + [Soumettre une tâche à une file d'attente et à un SageMaker espace de noms gérés par l'IA](#hp-eks-cli-start-job) + [Affichage des tâches](#hp-eks-cli-list-jobs) + [Obtention des informations détaillées sur une tâche](#hp-eks-cli-get-job) + [Suspension et annulation de la suspension de tâches](#hp-eks-cli-patch-job) + [Débogage de tâches](#hp-eks-cli-other) ## Obtention d’informations sur les quotas d’appareil accélérateur de cluster L’exemple de commande suivant permet d’obtenir des informations sur le quota d’appareil accélérateur de cluster. ``` hyperpod get-clusters -n hyperpod-ns-test-team ``` L’espace de noms de cet exemple, `hyperpod-ns-test-team`, est créé dans Kubernetes en fonction du nom d’équipe fourni, `test-team`, lors de la création de l’allocation de calcul. Pour de plus amples informations, veuillez consulter [Modification des politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-edit.md). Exemple de réponse : ``` [ { "Cluster": "hyperpod-eks-test-cluster-id", "InstanceType": "ml.g5.xlarge", "TotalNodes": 2, "AcceleratorDevicesAvailable": 1, "NodeHealthStatus=Schedulable": 2, "DeepHealthCheckStatus=Passed": "N/A", "Namespaces": { "hyperpod-ns-test-team": { "TotalAcceleratorDevices": 1, "AvailableAcceleratorDevices": 1 } } } ] ``` ## Soumettre une tâche à une file d'attente et à un SageMaker espace de noms gérés par l'IA L'exemple de commande suivant soumet une tâche à votre HyperPod cluster. Si vous n'avez accès qu'à une seule équipe, la file d'attente vous HyperPod AWS CLI sera automatiquement attribuée dans ce cas. Sinon, si plusieurs files d’attente sont découvertes, nous vous proposerons toutes les options viables que vous pourrez sélectionner. ``` hyperpod start-job --job-name hyperpod-cli-test --job-kind kubeflow/PyTorchJob --image docker.io/kubeflowkatib/pytorch-mnist-cpu:v1beta1-bc09cfd --entry-script /opt/pytorch-mnist/mnist.py --pull-policy IfNotPresent --instance-type ml.g5.xlarge --node-count 1 --tasks-per-node 1 --results-dir ./result --priority training-priority ``` Les classes de priorité sont définies dans la **politique du cluster**, qui définit la manière dont les tâches sont priorisées et les ressources de calcul inactives allouées. Lorsqu’un scientifique des données soumet une tâche, il utilise l’un des noms de classe de priorité avec le format `priority-class-name-priority`. Dans cet exemple, `training-priority` fait référence à la classe de priorité nommée « entraînement ». Pour plus d’informations sur les concepts de la politique, consultez [Stratégies](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md). Si aucune classe de priorité n’est spécifiée, la tâche est traitée comme une tâche de faible priorité, avec une valeur de classement des tâches de 0. Si une classe de priorité est spécifiée, mais qu’elle ne correspond pas à l’une des classes de priorité définies dans la **politique de cluster**, la soumission échoue et un message d’erreur fournit l’ensemble défini de classes de priorité. Vous pouvez également soumettre la tâche à l’aide d’un fichier de configuration YAML en utilisant la commande suivante : ``` hyperpod start-job --config-file ./yaml-configuration-file-name.yaml ``` Voici un exemple de fichier de configuration YAML équivalent à la soumission d’une tâche, comme indiqué ci-dessus. ``` defaults: - override hydra/job_logging: stdout hydra: run: dir: . output_subdir: null training_cfg: entry_script: /opt/pytorch-mnist/mnist.py script_args: [] run: name: hyperpod-cli-test nodes: 1 ntasks_per_node: 1 cluster: cluster_type: k8s instance_type: ml.g5.xlarge custom_labels: kueue.x-k8s.io/priority-class: training-priority cluster_config: label_selector: required: sagemaker.amazonaws.com/node-health-status: - Schedulable preferred: sagemaker.amazonaws.com/deep-health-check-status: - Passed weights: - 100 pullPolicy: IfNotPresent base_results_dir: ./result container: docker.io/kubeflowkatib/pytorch-mnist-cpu:v1beta1-bc09cfd env_vars: NCCL_DEBUG: INFO ``` Vous pouvez également soumettre une tâche en utilisant `kubectl` pour vous assurer que la tâche apparaît dans l’onglet **Tableau de bord**. Voici un exemple de commande kubectl. ``` kubectl apply -f ./yaml-configuration-file-name.yaml ``` Lorsque vous soumettez la tâche, assurez-vous d’inclure le nom de votre file d’attente et les étiquettes de classe de priorité. Par exemple, avec le nom de la file d’attente `hyperpod-ns-team-name-localqueue` et la classe de priorité `priority-class-name-priority`, vous devez inclure les étiquettes suivantes : + `kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue` + `kueue.x-k8s.io/priority-class: priority-class-name-priority` L’extrait de configuration YAML suivant montre comment ajouter des étiquettes à votre fichier de configuration d’origine pour vous assurer que votre tâche apparaîtra dans l’onglet **Tableau de bord** : ``` metadata: name: job-name namespace: hyperpod-ns-team-name labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue kueue.x-k8s.io/priority-class: priority-class-name-priority ``` ## Affichage des tâches La commande suivante répertorie les tâches et leurs détails. ``` hyperpod list-jobs ``` Exemple de réponse : ``` { "jobs": [ { "Name": "hyperpod-cli-test", "Namespace": "hyperpod-ns-test-team", "CreationTime": "2024-11-18T21:21:15Z", "Priority": "training", "State": "Succeeded" } ] } ``` ## Obtention des informations détaillées sur une tâche La commande suivante fournit les détails d’une tâche. Si aucun espace de noms n'est spécifié, HyperPod AWS CLI récupérera un espace de noms géré par l' SageMaker IA auquel vous avez accès. ``` hyperpod get-job --job-name hyperpod-cli-test ``` Exemple de réponse : ``` { "Name": "hyperpod-cli-test", "Namespace": "hyperpod-ns-test-team", "Label": { "app": "hyperpod-cli-test", "app.kubernetes.io/managed-by": "Helm", "kueue.x-k8s.io/priority-class": "training" }, "CreationTimestamp": "2024-11-18T21:21:15Z", "Status": { "completionTime": "2024-11-18T21:25:24Z", "conditions": [ { "lastTransitionTime": "2024-11-18T21:21:15Z", "lastUpdateTime": "2024-11-18T21:21:15Z", "message": "PyTorchJob hyperpod-cli-test is created.", "reason": "PyTorchJobCreated", "status": "True", "type": "Created" }, { "lastTransitionTime": "2024-11-18T21:21:17Z", "lastUpdateTime": "2024-11-18T21:21:17Z", "message": "PyTorchJob hyperpod-ns-test-team/hyperpod-cli-test is running.", "reason": "PyTorchJobRunning", "status": "False", "type": "Running" }, { "lastTransitionTime": "2024-11-18T21:25:24Z", "lastUpdateTime": "2024-11-18T21:25:24Z", "message": "PyTorchJob hyperpod-ns-test-team/hyperpod-cli-test successfully completed.", "reason": "PyTorchJobSucceeded", "status": "True", "type": "Succeeded" } ], "replicaStatuses": { "Worker": { "selector": "training.kubeflow.org/job-name=hyperpod-cli-test,training.kubeflow.org/operator-name=pytorchjob-controller,training.kubeflow.org/replica-type=worker", "succeeded": 1 } }, "startTime": "2024-11-18T21:21:15Z" }, "ConsoleURL": "https://us-west-2.console.aws.amazon.com/sagemaker/home?region=us-west-2#/cluster-management/hyperpod-eks-test-cluster-id“ } ``` ## Suspension et annulation de la suspension de tâches Si vous souhaitez supprimer une tâche soumise du planificateur, HyperPod AWS CLI fournit une `suspend` commande permettant de supprimer temporairement la tâche de l'orchestration. La tâche suspendue ne sera plus planifiée à moins que la suspension de la tâche soit annulée manuellement par la commande `unsuspend`. Pour suspendre temporairement une tâche : ``` hyperpod patch-job suspend --job-name hyperpod-cli-test ``` Pour replacer une tâche dans la file d’attente : ``` hyperpod patch-job unsuspend --job-name hyperpod-cli-test ``` ## Débogage de tâches HyperPod AWS CLI Il fournit également d'autres commandes vous permettant de résoudre les problèmes de soumission de tâches. Par exemple `list-pods` et `get-logs` dans le référentiel HyperPod AWS CLI Github. # Dépannage La page suivante contient des solutions connues pour le dépannage de vos clusters HyperPod EKS. **Topics** + [Onglet Dashboard (Tableau de bord)](#hp-eks-troubleshoot-dashboard) + [Onglet Tâches](#hp-eks-troubleshoot-tasks) + [Stratégies](#hp-eks-troubleshoot-policies) + [Suppression de clusters](#hp-eks-troubleshoot-delete-policies) + [Partage de ressources non allouées](#hp-eks-troubleshoot-unallocated-resource-sharing) ## Onglet Dashboard (Tableau de bord) **Échec de l’installation du module complémentaire EKS** Pour que l’installation du module complémentaire EKS réussisse, vous devez disposer d’une version de Kubernetes >= 1.30. Pour effectuer une mise à jour, consultez [Mise à jour de la version de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html). Pour que l’installation du module complémentaire EKS réussisse, tous les nœuds doivent présenter le statut **Prêt** et tous les pods doivent présenter le statut **En cours d’exécution**. Pour vérifier l'état de vos nœuds, utilisez la [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html) AWS CLI commande ou accédez à votre cluster EKS dans la [console EKS](https://console.aws.amazon.com/eks/home#/clusters) et consultez l'état de vos nœuds. Résolvez le problème pour chaque nœud ou contactez votre administrateur. Si le statut du nœud est **Inconnu**, supprimez le nœud. Une fois que le statut de tous les nœuds **est prêt**, réessayez d'installer le module complémentaire EKS HyperPod depuis la console [Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/). Pour vérifier le statut de vos pods, utilisez la commande [CLI Kubernetes](https://kubernetes.io/docs/reference/kubectl/) `kubectl get pods -n cloudwatch-agent` ou accédez à votre cluster EKS dans la [console EKS](https://console.aws.amazon.com/eks/home#/clusters) et consultez le statut de vos pods avec l’espace de noms `cloudwatch-agent`. Résolvez le problème relatif aux pods ou contactez votre administrateur pour le résoudre. Une fois que tous les statuts des pods sont **actifs**, réessayez d'installer le module complémentaire EKS HyperPod depuis la console [Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/). Pour plus de résolution des problèmes, consultez la section [Résolution des problèmes liés au module complémentaire Amazon CloudWatch Observability EKS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html#Container-Insights-setup-EKS-addon-troubleshoot). ## Onglet Tâches Si le message d’erreur indiquant que la **définition de ressource personnalisée (CRD) n’est pas configurée sur le cluster** s’affiche, accordez les politiques `EKSAdminViewPolicy` et `ClusterAccessRole` à votre rôle d’exécution de domaine. + Pour en savoir plus sur la façon d’obtenir votre rôle d’exécution, consultez [Obtention de votre rôle d’exécution](sagemaker-roles.md#sagemaker-roles-get-execution-role). + Pour découvrir comment attacher des politiques à un utilisateur ou à un groupe IAM, consultez [Ajout et suppression d’autorisations basées sur l’identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html). ## Stratégies La liste suivante répertorie les solutions aux erreurs liées aux politiques utilisant la console HyperPod APIs or. + Si la politique présente le statut `CreateFailed` ou `CreateRollbackFailed`, vous devez supprimer la politique qui a échoué, puis en créer une nouvelle. + Si la politique présente le statut `UpdateFailed`, réessayez la mise à jour avec le même ARN de politique. + Si la politique présente le statut `UpdateRollbackFailed`, vous devez supprimer la politique qui a échoué, puis en créer une nouvelle. + Si la politique présente le statut `DeleteFailed` ou `DeleteRollbackFailed`, réessayez la suppression avec le même ARN de politique. + Si vous avez rencontré une erreur en essayant de supprimer la **priorisation de calcul**, ou la politique de cluster, à l'aide de la HyperPod console, essayez de la supprimer à l'`cluster-scheduler-config`aide de l'API. Pour vérifier le statut de la ressource, accédez à la page de détails d’une allocation de calcul. Pour en savoir plus sur l’échec, utilisez l’API de description. ## Suppression de clusters Les solutions connues aux erreurs liées à la suppression de clusters sont répertoriées ci-dessous. + Lorsque la suppression du cluster échoue en raison des politiques de gouvernance des SageMaker HyperPod tâches associées, vous devez le faire[Suppression de politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md). + Lorsque la suppression du cluster échoue en raison de l’absence des autorisations suivantes, vous devez mettre à jour votre ensemble minimal d’autorisations d’administrateur de cluster. Consultez l’onglet **Amazon EKS** dans la section [Utilisateurs IAM pour l’administrateur de cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). + `sagemaker:ListComputeQuotas` + `sagemaker:ListClusterSchedulerConfig` + `sagemaker:DeleteComputeQuota` + `sagemaker:DeleteClusterSchedulerConfig` ## Partage de ressources non allouées Si la capacité de votre pool de ressources non allouées est inférieure à celle prévue : 1. **Vérifier l'état de préparation du nœud** ``` kubectl get nodes ``` Vérifiez que tous les nœuds affichent `Ready` leur statut dans la colonne STATUS. 1. **Vérifier l'état planifiable du nœud** ``` kubectl get nodes -o custom-columns=NAME:.metadata.name,UNSCHEDULABLE:.spec.unschedulable ``` Vérifiez que les nœuds s'affichent `` ou `false` non`true`. 1. **Répertorier le partage ClusterQueues de ressources non allouées :** ``` kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing ``` Cela montre tous les partages ClusterQueues de ressources non alloués. S'ils ne s' ClusterQueues affichent pas, vérifiez la ClusterSchedulerConfig politique `FailureReason` ci-dessous pour voir s'il existe des messages d'échec pour poursuivre le débogage. 1. **Vérifiez le quota de partage des ressources non allouées :** ``` kubectl describe clusterqueue hyperpod-ns-idle-resource-sharing- ``` Consultez la `spec.resourceGroups[].flavors[].resources` section pour voir le quota alloué à chaque type de ressource. Plusieurs partages de ressources non allouées ClusterQueues peuvent exister en fonction du nombre de types de ressources dans votre cluster. 1. **Vérifiez l'état de la configuration MIG (nœuds GPU) :** ``` kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.nvidia\.com/mig\.config\.state}{"\n"}{end}' ``` Vérifiez que les nœuds compatibles MiG affichent `success` leur état. # Document d'attribution pour la gouvernance des SageMaker HyperPod tâches Amazon Vous trouverez ci-dessous des informations sur les attributions et les licences tierces pour le matériel utilisé dans le cadre de la gouvernance des SageMaker HyperPod tâches Amazon. **Topics** + [[fichiers de base](https://packages.debian.org/bookworm/base-files)](#hp-eks-task-governance-attributions-base-files) + [[netbase](https://packages.debian.org/source/stable/netbase)](#hp-eks-task-governance-attributions-netbase) + [[golang-lru](https://github.com/hashicorp/golang-lru)](#hp-eks-task-governance-attributions-golang-lru) ## [fichiers de base](https://packages.debian.org/bookworm/base-files) ``` This is the Debian prepackaged version of the Debian Base System Miscellaneous files. These files were written by Ian Murdock and Bruce Perens . This package was first put together by Bruce Perens , from his own sources. The GNU Public Licenses in /usr/share/common-licenses were taken from ftp.gnu.org and are copyrighted by the Free Software Foundation, Inc. The Artistic License in /usr/share/common-licenses is the one coming from Perl and its SPDX name is "Artistic License 1.0 (Perl)". Copyright © 1995-2011 Software in the Public Interest. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. On Debian systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. ``` ## [netbase](https://packages.debian.org/source/stable/netbase) ``` Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Comment: This package was created by Peter Tobias tobias@et-inf.fho-emden.de on Wed, 24 Aug 1994 21:33:28 +0200 and maintained by Anthony Towns until 2001. It is currently maintained by Marco d'Itri . Files: * Copyright: Copyright © 1994-1998 Peter Tobias Copyright © 1998-2001 Anthony Towns Copyright © 2002-2022 Marco d'Itri License: GPL-2 This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2, as published by the Free Software Foundation. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. . On Debian systems, the complete text of the GNU General Public License version 2 can be found in '/usr/share/common-licenses/GPL-2'. ``` ## [golang-lru](https://github.com/hashicorp/golang-lru) ``` Copyright © 2014 HashiCorp, Inc. Mozilla Public License, version 2.0 1. Definitions 1.1. "Contributor" means each individual or legal entity that creates, contributes to the creation of, or owns Covered Software. 1.2. "Contributor Version" means the combination of the Contributions of others (if any) used by a Contributor and that particular Contributor's Contribution. 1.3. "Contribution" means Covered Software of a particular Contributor. 1.4. "Covered Software" means Source Code Form to which the initial Contributor has attached the notice in Exhibit A, the Executable Form of such Source Code Form, and Modifications of such Source Code Form, in each case including portions thereof. 1.5. "Incompatible With Secondary Licenses" means a. that the initial Contributor has attached the notice described in Exhibit B to the Covered Software; or b. that the Covered Software was made available under the terms of version 1.1 or earlier of the License, but not also under the terms of a Secondary License. 1.6. "Executable Form" means any form of the work other than Source Code Form. 1.7. "Larger Work" means a work that combines Covered Software with other material, in a separate file or files, that is not Covered Software. 1.8. "License" means this document. 1.9. "Licensable" means having the right to grant, to the maximum extent possible, whether at the time of the initial grant or subsequently, any and all of the rights conveyed by this License. 1.10. "Modifications" means any of the following: a. any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or b. any new file in Source Code Form that contains any Covered Software. 1.11. "Patent Claims" of a Contributor means any patent claim(s), including without limitation, method, process, and apparatus claims, in any patent Licensable by such Contributor that would be infringed, but for the grant of the License, by the making, using, selling, offering for sale, having made, import, or transfer of either its Contributions or its Contributor Version. 1.12. "Secondary License" means either the GNU General Public License, Version 2.0, the GNU Lesser General Public License, Version 2.1, the GNU Affero General Public License, Version 3.0, or any later versions of those licenses. 1.13. "Source Code Form" means the form of the work preferred for making modifications. 1.14. "You" (or "Your") means an individual or a legal entity exercising rights under this License. For legal entities, "You" includes any entity that controls, is controlled by, or is under common control with You. For purposes of this definition, "control" means (a) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (b) ownership of more than fifty percent (50%) of the outstanding shares or beneficial ownership of such entity. 2. License Grants and Conditions 2.1. Grants Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license: a. under intellectual property rights (other than patent or trademark) Licensable by such Contributor to use, reproduce, make available, modify, display, perform, distribute, and otherwise exploit its Contributions, either on an unmodified basis, with Modifications, or as part of a Larger Work; and b. under Patent Claims of such Contributor to make, use, sell, offer for sale, have made, import, and otherwise transfer either its Contributions or its Contributor Version. 2.2. Effective Date The licenses granted in Section 2.1 with respect to any Contribution become effective for each Contribution on the date the Contributor first distributes such Contribution. 2.3. Limitations on Grant Scope The licenses granted in this Section 2 are the only rights granted under this License. No additional rights or licenses will be implied from the distribution or licensing of Covered Software under this License. Notwithstanding Section 2.1(b) above, no patent license is granted by a Contributor: a. for any code that a Contributor has removed from Covered Software; or b. for infringements caused by: (i) Your and any other third party's modifications of Covered Software, or (ii) the combination of its Contributions with other software (except as part of its Contributor Version); or c. under Patent Claims infringed by Covered Software in the absence of its Contributions. This License does not grant any rights in the trademarks, service marks, or logos of any Contributor (except as may be necessary to comply with the notice requirements in Section 3.4). 2.4. Subsequent Licenses No Contributor makes additional grants as a result of Your choice to distribute the Covered Software under a subsequent version of this License (see Section 10.2) or under the terms of a Secondary License (if permitted under the terms of Section 3.3). 2.5. Representation Each Contributor represents that the Contributor believes its Contributions are its original creation(s) or it has sufficient rights to grant the rights to its Contributions conveyed by this License. 2.6. Fair Use This License is not intended to limit any rights You have under applicable copyright doctrines of fair use, fair dealing, or other equivalents. 2.7. Conditions Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted in Section 2.1. 3. Responsibilities 3.1. Distribution of Source Form All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License. You must inform recipients that the Source Code Form of the Covered Software is governed by the terms of this License, and how they can obtain a copy of this License. You may not attempt to alter or restrict the recipients' rights in the Source Code Form. 3.2. Distribution of Executable Form If You distribute Covered Software in Executable Form then: a. such Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient; and b. You may distribute such Executable Form under the terms of this License, or sublicense it under different terms, provided that the license for the Executable Form does not attempt to limit or alter the recipients' rights in the Source Code Form under this License. 3.3. Distribution of a Larger Work You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s). 3.4. Notices You may not remove or alter the substance of any license notices (including copyright notices, patent notices, disclaimers of warranty, or limitations of liability) contained within the Source Code Form of the Covered Software, except that You may alter any license notices to the extent required to remedy known factual inaccuracies. 3.5. Application of Additional Terms You may choose to offer, and to charge a fee for, warranty, support, indemnity or liability obligations to one or more recipients of Covered Software. However, You may do so only on Your own behalf, and not on behalf of any Contributor. You must make it absolutely clear that any such warranty, support, indemnity, or liability obligation is offered by You alone, and You hereby agree to indemnify every Contributor for any liability incurred by such Contributor as a result of warranty, support, indemnity or liability terms You offer. You may include additional disclaimers of warranty and limitations of liability specific to any jurisdiction. 4. Inability to Comply Due to Statute or Regulation If it is impossible for You to comply with any of the terms of this License with respect to some or all of the Covered Software due to statute, judicial order, or regulation then You must: (a) comply with the terms of this License to the maximum extent possible; and (b) describe the limitations and the code they affect. Such description must be placed in a text file included with all distributions of the Covered Software under this License. Except to the extent prohibited by statute or regulation, such description must be sufficiently detailed for a recipient of ordinary skill to be able to understand it. 5. Termination 5.1. The rights granted under this License will terminate automatically if You fail to comply with any of its terms. However, if You become compliant, then the rights granted under this License from a particular Contributor are reinstated (a) provisionally, unless and until such Contributor explicitly and finally terminates Your grants, and (b) on an ongoing basis, if such Contributor fails to notify You of the non-compliance by some reasonable means prior to 60 days after You have come back into compliance. Moreover, Your grants from a particular Contributor are reinstated on an ongoing basis if such Contributor notifies You of the non-compliance by some reasonable means, this is the first time You have received notice of non-compliance with this License from such Contributor, and You become compliant prior to 30 days after Your receipt of the notice. 5.2. If You initiate litigation against any entity by asserting a patent infringement claim (excluding declaratory judgment actions, counter-claims, and cross-claims) alleging that a Contributor Version directly or indirectly infringes any patent, then the rights granted to You by any and all Contributors for the Covered Software under Section 2.1 of this License shall terminate. 5.3. In the event of termination under Sections 5.1 or 5.2 above, all end user license agreements (excluding distributors and resellers) which have been validly granted by You or Your distributors under this License prior to termination shall survive termination. 6. Disclaimer of Warranty Covered Software is provided under this License on an "as is" basis, without warranty of any kind, either expressed, implied, or statutory, including, without limitation, warranties that the Covered Software is free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the Covered Software is with You. Should any Covered Software prove defective in any respect, You (not any Contributor) assume the cost of any necessary servicing, repair, or correction. This disclaimer of warranty constitutes an essential part of this License. No use of any Covered Software is authorized under this License except under this disclaimer. 7. Limitation of Liability Under no circumstances and under no legal theory, whether tort (including negligence), contract, or otherwise, shall any Contributor, or anyone who distributes Covered Software as permitted above, be liable to You for any direct, indirect, special, incidental, or consequential damages of any character including, without limitation, damages for lost profits, loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses, even if such party shall have been informed of the possibility of such damages. This limitation of liability shall not apply to liability for death or personal injury resulting from such party's negligence to the extent applicable law prohibits such limitation. Some jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so this exclusion and limitation may not apply to You. 8. Litigation Any litigation relating to this License may be brought only in the courts of a jurisdiction where the defendant maintains its principal place of business and such litigation shall be governed by laws of that jurisdiction, without reference to its conflict-of-law provisions. Nothing in this Section shall prevent a party's ability to bring cross-claims or counter-claims. 9. Miscellaneous This License represents the complete agreement concerning the subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not be used to construe this License against a Contributor. 10. Versions of the License 10.1. New Versions Mozilla Foundation is the license steward. Except as provided in Section 10.3, no one other than the license steward has the right to modify or publish new versions of this License. Each version will be given a distinguishing version number. 10.2. Effect of New Versions You may distribute the Covered Software under the terms of the version of the License under which You originally received the Covered Software, or under the terms of any subsequent version published by the license steward. 10.3. Modified Versions If you create software not governed by this License, and you want to create a new license for such software, you may create and use a modified version of this License if you rename the license and remove any references to the name of the license steward (except to note that such modified license differs from this License). 10.4. Distributing Source Code Form that is Incompatible With Secondary Licenses If You choose to distribute Source Code Form that is Incompatible With Secondary Licenses under the terms of this version of the License, the notice described in Exhibit B of this License must be attached. Exhibit A - Source Code Form License Notice This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/. If it is not possible or desirable to put the notice in a particular file, then You may include the notice in a location (such as a LICENSE file in a relevant directory) where a recipient would be likely to look for such a notice. You may add additional accurate notices of copyright ownership. Exhibit B - "Incompatible With Secondary Licenses" Notice This Source Code Form is "Incompatible With Secondary Licenses", as defined by the Mozilla Public License, v. 2.0. ``` # Rapports d'utilisation pour l'attribution des coûts dans SageMaker HyperPod Les rapports d'utilisation dans les clusters SageMaker HyperPod orchestrés par EKS fournissent une visibilité précise de la consommation des ressources informatiques. Cette fonctionnalité permet aux entreprises de mettre en œuvre une attribution transparente des coûts, en allouant les coûts du cluster aux équipes, aux projets ou aux départements en fonction de leur utilisation réelle. En suivant des indicateurs tels que les GPU/CPU heures et l'utilisation de Neuron Core, capturés à la *fois dans des agrégats au niveau de l'équipe et dans des ventilations spécifiques aux tâches, les rapports d'utilisation complètent HyperPod la fonctionnalité de [gouvernance des tâches](sagemaker-hyperpod-eks-operate-console-ui-governance.md) de la société, garantissant ainsi une répartition* équitable des coûts dans les clusters mutualisés partagés en : + éliminant les incertitudes dans l’allocation des coûts ; + liant directement les dépenses à une consommation de ressources mesurable ; + renforçant la responsabilité basée sur l’utilisation dans les environnements d’infrastructure partagée. ## Conditions préalables Pour afficher cette fonctionnalité : + Il vous faut : + Un **SageMaker HyperPod environnement** actif avec un cluster orchestré par EKS en cours d'exécution. + (Fortement recommandé) **Avoir configuré la gouvernance des tâches** avec des quotas de calcul et des règles de priorité. Pour les instructions de configuration, consultez [Configuration de la gouvernance des tâches](sagemaker-hyperpod-eks-operate-console-ui-governance-setup.md). + Familiarisez-vous avec les concepts fondamentaux suivants : + **Quota de calcul alloué :** ressources réservées pour une équipe sur la base de quotas prédéfinis dans ses politiques de gouvernance des tâches. Il s’agit d’une *fonctionnalité garantie* pour leurs charges de travail. + **Calcul emprunté :** ressources inactives du groupe de clusters partagé que les équipes peuvent utiliser temporairement *au-delà du quota qui leur est alloué*. Le calcul emprunté est attribué dynamiquement en fonction des règles de priorité définies dans les politiques de gouvernance des tâches et de la disponibilité des ressources non utilisées. + **Utilisation du calcul :** mesure des ressources (GPU, CPU, heures de cœurs neuronaux) consommées par une équipe, suivie comme suit : + **Utilisation allouée** : utilisation dans les limites du quota de l’équipe. + **Utilisation empruntée** : utilisation au-delà du quota, puisée dans le groupe partagé. + **Attribution des coûts :** processus d’allocation des coûts de cluster aux équipes en fonction de leur *utilisation réelle du calcul*, y compris les ressources consommées dans les limites de leur quota prédéfini et les ressources utilisées temporairement à partir du pool de clusters partagé au-delà de leur quota. ## Types de rapports HyperPodles rapports d'utilisation fournissent une granularité opérationnelle variable : + **Les rapports récapitulatifs** fournissent une visibilité à l'échelle de l'organisation sur l'utilisation du calcul, en agrégeant le nombre total d'heures de GPU/CPU/Neuron base par équipe (espace de noms) tout en faisant la distinction entre *l'utilisation normale* (ressources provenant du quota alloué à une équipe) et le *calcul emprunté* (capacité excédentaire provenant de pools partagés). + Les **rapports détaillés** fournissent la répartition des tâches par équipe et permettent de suivre les heures de calcul exactes consacrées à l’exécution de tâches spécifiques, y compris de tâches préemptées, de modèles d’utilisation horaire et d’allocations spécifiques à l’espace de noms. **Important** HyperPod les rapports d'utilisation suivent l'utilisation du calcul dans *tous les espaces de noms Kubernetes* d'un cluster, y compris ceux gérés par Task Governance, les espaces de noms par défaut et les espaces de noms créés en **dehors de Task Governance (par exemple, via des appels d'API** Kubernetes directs ou des outils externes). Cette surveillance au niveau de l’infrastructure garantit une responsabilisation complète basée sur l’utilisation, évitant les écarts dans l’attribution des coûts pour les clusters partagés, quelle que soit la manière dont les espaces de noms sont gérés. ## Formats de rapports et plage de temps En utilisant le script Python fourni dans [Génération de rapports](sagemaker-hyperpod-usage-reporting-generate.md), les administrateurs peuvent générer des rapports d’utilisation à la demande au format CSV ou PDF, en sélectionnant des plages de temps allant d’instantanés quotidiens à des fenêtres d’historique de 180 jours (6 mois). **Note** Vous pouvez configurer la fenêtre d’historique pour qu’elle s’étende au-delà du maximum de 180 jours par défaut lors de la configuration de l’infrastructure de rapports. Pour plus d'informations sur la configuration de la période de conservation des données, voir [Installer l'infrastructure de rapports d'utilisation à l'aide](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#install-usage-report-infrastructure-using-cloudformation) de CloudFormation. ## Cas d’utilisation illustratifs Cette fonctionnalité répond aux scénarios critiques dans les AI/ML environnements à locataires multiples tels que : 1. **Répartition des coûts pour les clusters partagés** : un administrateur gère un HyperPod cluster partagé par 20 équipes qui forment des modèles d'IA génératifs. À l’aide d’un *rapport d’utilisation récapitulatif*, il analyse l’utilisation GPU quotidienne sur 180 jours et découvre que l’équipe A a consommé 200 heures de GPU d’un type d’instance spécifique, à savoir 170 heures de son quota alloué et 30 de calcul emprunté. L’administrateur facture à l’équipe A le montant correspondant à ce rapport d’utilisation. 1. **Audit et résolution des litiges** : une équipe financière met en doute l’exactitude de l’attribution des coûts, invoquant des incohérences. L’administrateur peut exporter un *rapport détaillé au niveau des tâches* pour effectuer un audit des incohérences. En recoupant les horodatages, les types d’instances et les tâches préemptées au sein de l’espace de noms de l’équipe, le rapport réconcilie de manière transparente les données d’utilisation contestées. # Détails des rapports et ventilation des données SageMaker HyperPodles rapports d'utilisation fournissent deux objectifs distincts pour analyser la consommation de ressources informatiques : des **rapports de synthèse** pour la répartition des coûts et **des rapports détaillés** pour l'audit granulaire. Les rapports récapitulatifs regroupent l’utilisation à l’échelle du cluster par équipe ou par espace de noms, en mettant en évidence les tendances de calcul alloué par rapport au calcul emprunté entre les ressources de GPU, de CPU et de cœurs neuronaux. Des rapports détaillés explorent les tâches individuelles et présentent des métriques telles que les fenêtres d’exécution, le statut des tâches et l’utilisation par classe de priorité. Dans cette section, nous décomposons la structure de ces rapports, comprenons leurs métriques clés et montrons comment les administrateurs et les équipes financières peuvent croiser les tendances récapitulatives avec les données au niveau des tâches afin de valider l’exactitude de la répartition des coûts, de résoudre les incohérences et d’optimiser l’infrastructure partagée. ## En-têtes de rapports communs Les rapports récapitulatifs et détaillés incluent tous les métadonnées suivantes permettant de contextualiser les données d’utilisation : + **ClusterName:** nom du cluster Hyperpod orchestré par EKS dans lequel les ressources ont été consommées. + **Type :** catégorie du rapport (`Summary Utilization Report` ou `Detailed Utilization Report`). + **Date de génération :** date de création du rapport (p. ex., `2025-04-18`). + **Plage de dates (UTC) :** période couverte (p. ex., `2025-04-16 to 2025-04-18`). + **Périodes de données manquantes :** lacunes dans la collection de données dues à des durées d’indisponibilité du cluster ou à des problèmes de surveillance (p. ex., `2025-04-16 00:00:00 to 2025-04-19 00:00:00`). ## Rapports récapitulatifs Les rapports récapitulatifs fournissent une vue d’ensemble quotidienne de la consommation des ressources de calcul par équipe/espace de noms et par type d’instance, en distinguant l’utilisation allouée (quota réservé) et l’utilisation empruntée (groupe prêté). Ces rapports sont parfaits pour la génération de factures, les déclarations d’attribution des coûts ou les prévisions de capacité. *Exemple : un rapport récapitulatif peut indiquer que l’équipe A a utilisé 200 heures de GPU, à savoir 170 heures sur le quota alloué et 30 heures empruntées.* Voici une ventilation structurée des colonnes clés d’un rapport récapitulatif : + **Date :** date de l’utilisation faisant l’objet du rapport (p. ex., `2025-04-18`). + **Espace de noms :** espace de noms Kubernetes associé à l’équipe (p. ex., `hyperpod-ns-ml-team`). + **Équipe : The** Owning team/department (par exemple,`ml-team`). + **Type d’instance :** instance de calcul utilisée (p. ex., ml.g5.4xlarge). + **Total/Allocated/BorrowedUtilisation (heures) :** répartition de l'utilisation du GPU, du processeur ou du Neuron Core par catégorie. Où : + **Utilisation totale = Utilisation allouée \$1 Utilisation empruntée** + L’**utilisation allouée** correspond au nombre réel d’heures de GPU, de CPU ou de cœurs neuronaux utilisées par une équipe, plafonné à 100 % du quota qui lui est alloué. + L’**utilisation empruntée** correspond au nombre réel d’heures de GPU, de CPU ou de cœurs neuronaux utilisées par une équipe *au-delà du quota qui lui a été alloué*, puisées dans le pool de clusters partagé en fonction des règles de priorité de gouvernance des tâches et de la disponibilité des ressources. Exemple : 72 heures de GPU au total (48 allouées, 24 empruntées). **Note** Seule l’utilisation totale est affichée pour les espaces de noms non gérés par la gouvernance des tâches. ## Rapports détaillés Des rapports détaillés fournissent une visibilité chirurgicale sur l’utilisation des ressources de calcul, en décomposant la consommation des ressources par tâche, en présentant des métriques granulaires telles que les fenêtres d’exécution des tâches, leur statut (p. ex., Succès, Échec) et leur utilisation par classe de priorité. Ces rapports sont parfaitement adaptés pour valider des écarts de facturation ou pour garantir le respect des politiques de gouvernance. Voici une ventilation structurée des colonnes clés d’un rapport détaillé : + **Date :** date de l’utilisation faisant l’objet du rapport (p. ex., `2025-04-18`). + **Début/fin de période :** fenêtre d’exécution exacte (UTC) pour la tâche (p. ex., `19:54:34`). + **Espace de noms :** espace de noms Kubernetes associé à l’équipe (p. ex., `hyperpod-ns-ml-team`). + **Équipe : The** Owning team/department (par exemple,`ml-team`). + **Tâche :** identifiant de la tâche/du pod (p. ex., `pytorchjob-ml-pytorch-job-2p5zt-db686`). + **Instance :** instance de calcul utilisée (p. ex., `ml.g5.4xlarge`). + **Statut :** résultat de la tâche (réussite, échec, préemption). + **Utilisation totale :** consommation totale (heures et nombre d’instances) des ressources de GPU, de CPU ou de cœurs neuronaux. + **Classe de priorité :** niveau de priorité attribué (p. ex., priorité d’entraînement). # Génération de rapports Ce guide fournit des step-by-step instructions pour configurer et gérer les rapports d'utilisation pour vos SageMaker HyperPod clusters. Suivez ces procédures pour déployer l’infrastructure, générer des rapports personnalisés et supprimer des ressources lorsqu’elles ne sont plus nécessaires. ## Configuration de rapports d’utilisation **Note** Avant de configurer l'infrastructure des rapports SageMaker HyperPod d'utilisation dans votre SageMaker HyperPod cluster, assurez-vous de respecter toutes les conditions requises détaillées dans ce [https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#prerequisites](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#prerequisites)document. Les rapports d'utilisation dans HyperPod nécessitent : + Déploiement SageMaker HyperPod des AWS ressources des rapports d'utilisation à l'aide d'une CloudFormation pile + Installation du rapport SageMaker HyperPod d'utilisation de l'opérateur Kubernetes via un graphique Helm Vous trouverez des instructions d'installation complètes dans le [ GitHub référentiel SageMaker HyperPod des rapports d'utilisation](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md). Plus précisément, suivez les étapes de la section [Configuration](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#set-up-usage-reporting). ## Génération de rapports d’utilisation à la demande Une fois l'infrastructure de rapports d'utilisation et l'opérateur Kubernetes installés, les données de travail de votre SageMaker HyperPod cluster sont automatiquement collectées et stockées dans le compartiment S3 que vous avez configuré lors de l'installation. L’opérateur capture de façon continue des métriques d’utilisation détaillées en arrière-plan, créant des fichiers de données bruts dans le répertoire `raw` du compartiment S3 que vous avez désigné. Pour générer un rapport d'utilisation à la demande, vous pouvez utiliser le `run.py` script fourni dans le [ GitHub référentiel de rapports SageMaker HyperPod d'utilisation](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md) pour extraire et exporter les mesures d'utilisation. Plus précisément, vous trouverez le script et les instructions complètes pour générer un rapport dans la section [Generate Reports](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#generate-reports). Le script vous permet de : + spécifier des plages de dates personnalisées pour la génération de rapports ; + choisir entre le type de rapport détaillé et le type de rapport récapitulatif ; + exporter les rapports au format CSV ou PDF ; + diriger les rapports vers un emplacement S3 spécifique. ## Nettoyage des ressources des rapports d’utilisation Lorsque vous n'avez plus besoin de votre infrastructure de reporting SageMaker HyperPod d'utilisation, suivez les étapes décrites dans [Nettoyer les ressources](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#clean-up-resources) pour nettoyer l'opérateur et les AWS ressources Kubernetes (dans cet ordre). La suppression appropriée des ressources permet d’éviter des coûts inutiles. # Configuration du stockage pour les SageMaker HyperPod clusters orchestrés par Amazon EKS L'administrateur du cluster doit configurer le stockage pour que les utilisateurs de data scientists puissent gérer les données d'entrée et de sortie et stocker les points de contrôle lors de la formation sur les SageMaker HyperPod clusters. **Gestion de grands jeux de données (données d’entrée/sortie)** + **Accès et gestion des données** : les scientifiques des données travaillent souvent avec de grands jeux de données nécessaires à l’entraînement des modèles de machine learning. La spécification des paramètres de stockage dans la soumission de la tâche leur permet de définir où se trouvent ces jeux de données (p. ex., dans des compartiments Amazon S3, des volumes persistants dans Kubernetes) et comment y accéder pendant l’exécution de la tâche. + **Optimisation des performances** : l’efficacité de l’accès aux données d’entrée peut avoir un impact significatif sur les performances de la tâche d’entraînement. En optimisant les paramètres de stockage, les data scientists peuvent s'assurer que les données sont lues et écrites efficacement, réduisant ainsi les goulots d' I/O étranglement. **Stockage des points de contrôle** + **Enregistrement de points de contrôle pendant l’entraînement** : au cours des tâches d’entraînement de longue durée, il est courant d’enregistrer des points de contrôle, c’est-à-dire des états intermédiaires du modèle. Cela permet aux scientifiques des données de reprendre l’entraînement à partir d’un point précis en cas de défaillance, plutôt que de repartir de zéro. + **Récupération des données et expérimentation** : en spécifiant l’emplacement de stockage des points de contrôle, les scientifiques des données peuvent s’assurer que ces points de contrôle sont stockés de manière sécurisée, potentiellement dans un système de stockage distribué offrant redondance et haute disponibilité. Cela est crucial pour récupérer après une interruption et pour expérimenter différentes stratégies d’entraînement. **Astuce** Pour une expérience pratique et des conseils sur la façon de configurer le stockage pour un SageMaker HyperPod cluster orchestré avec Amazon EKS, consultez les sections suivantes de l'[ SageMaker HyperPod atelier Amazon EKS Support in](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e). [Configurez Amazon FSx pour Lustre sur SageMaker HyperPod](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e/en-US/01-cluster/06-fsx-for-lustre) [Configurer un point de montage pour Amazon S3 à l'aide de [Mountpoint](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mountpoint.html) pour Amazon S3](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e/en-US/01-cluster/09-s3-mountpoint) # Utilisation du pilote Amazon EBS CSI sur SageMaker HyperPod les clusters EKS SageMaker HyperPod prend en charge le pilote Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI), qui gère le cycle de vie des volumes Amazon EBS en tant que stockage pour les volumes Kubernetes que vous créez. Avec le pilote Amazon EBS CSI, vous pouvez créer, associer et gérer vos volumes Amazon EBS pour vos charges de travail d'apprentissage automatique exécutées sur des clusters SageMaker HyperPod avec l'orchestration Amazon EKS. **Topics** + [Fonctionnalités de stockage clés](#sagemaker-hyperpod-eks-ebs-features) + [Cas d’utilisation](#sagemaker-hyperpod-eks-ebs-use) + [Configuration du pilote Amazon EBS CSI sur SageMaker HyperPod les clusters EKS](#sagemaker-hyperpod-eks-ebs-setup) + [En utilisant le APIs](#sagemaker-hyperpod-eks-ebs-setup-apis) ## Fonctionnalités de stockage clés Le pilote Amazon EBS CSI activé SageMaker HyperPod prend en charge les fonctionnalités de stockage suivantes. + Provisionnement statique : associe des volumes Amazon EBS précréés à des [volumes persistants](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) Kubernetes à utiliser dans vos pods. + Provisionnement dynamique : crée automatiquement des volumes Amazon EBS et des volumes persistants associés à partir de [https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). Les paramètres peuvent être transmis via [https://kubernetes.io/docs/concepts/storage/storage-classes/](https://kubernetes.io/docs/concepts/storage/storage-classes/) pour un contrôle précis de la création de volumes. + Redimensionnement des volumes : étend les volumes existants en mettant à jour la spécification de taille [https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) sans interrompre les charges de travail en cours d’exécution. Cela peut être essentiel pour gérer des référentiels de modèles en pleine croissance ou pour s’adapter à des nœuds plus importants sans interruption de service. + Instantanés de volumes : crée des point-in-time instantanés de volumes à des fins de sauvegarde, de restauration et de gestion des versions des données. + Volumes de blocs : fournit un accès brut aux périphériques de stockage en mode bloc pour les applications hautes performances nécessitant un accès direct au stockage. + Modification du volume : modifie les propriétés du volume telles que le type, les opérations d’entrée ou de sortie par seconde (IOPS) ou le débit à l’aide de [classes d’attributs de volume](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/). Pour plus d’informations sur le pilote CSI Amazon EBS, consultez [Utilisation du stockage en volume Kubernetes avec Amazon EBS](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) dans le *Guide de l’utilisateur Amazon EKS*. Pour plus d’informations sur le stockage dans les pods de votre cluster, consultez [Stockage](https://kubernetes.io/docs/concepts/storage/) dans la *documentation Kubernetes*. ## Cas d’utilisation L'intégration du pilote Amazon EBS CSI permet plusieurs cas d'utilisation clés pour les charges de travail de formation et d'inférence sur les clusters EKS. SageMaker HyperPod **Charges de travail d’entraînement** + Stockage de jeux de données : provisionnez des volumes pour les jeux de données d’entraînement qui persistent après le redémarrage du pod + Stockage des points de contrôle : enregistrez les points de contrôle du modèle et les résultats d’entraînement intermédiaires + Artefacts partagés : accédez aux jeux de données et aux artefacts de modèles communs dans le cadre de plusieurs tâches d’entraînement **Charges de travail d’inférence** + Stockage de modèles : provisionnez dynamiquement des volumes de taille appropriée en fonction des exigences du modèle + Mise en cache des conteneurs : créez un stockage éphémère pour améliorer les performances d’inférence + Enregistrement des événements : stockez les résultats d’inférence et les journaux grâce à un stockage persistant ## Configuration du pilote Amazon EBS CSI sur SageMaker HyperPod les clusters EKS Le pilote Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) vous permet de provisionner et de gérer dynamiquement des volumes Amazon EBS pour vos charges de travail conteneurisées exécutées sur des clusters avec une orchestration EKS. SageMaker HyperPod Cette section vous guide pour installer et configurer le pilote CSI Amazon EBS afin d’activer le stockage persistant pour vos charges de travail de machine learning. ### Conditions préalables Avant de commencer, vous devez exécuter les actions suivantes : + [Installez et configurez le AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) + [Création d'un SageMaker HyperPod cluster avec l'orchestration Amazon EKS](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-create-cluster.html) + Installation du pilote CSI Amazon EBS avec la version [v1.47.0](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/CHANGELOG.md#v1470) ### Autorisations supplémentaires Pour configurer le module complémentaire du pilote CSI Amazon EBS, suivez les instructions fournies dans [Utilisation du stockage de volumes Kubernetes avec Amazon EBS](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) dans le *Guide de l’utilisateur Amazon EKS*. Vous devez également ajouter les autorisations supplémentaires suivantes au rôle IAM utilisé pour exécuter le module complémentaire de pilote. Notez qu'il s'agit du rôle IAM spécifié dans la configuration de votre compte de service pour le module complémentaire de pilote, et non du rôle d'exécution du HyperPod cluster. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sagemaker:AttachClusterNodeVolume", "sagemaker:DetachClusterNodeVolume" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/*" }, { "Effect": "Allow", "Action": [ "eks:DescribeCluster" ], "Resource": "arn:aws:eks:us-east-1:111122223333:cluster/my-cluster-name" } ] } ``` ------ ## En utilisant le APIs Vous pouvez également utiliser les opérations [AttachClusterNodeVolume](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AttachClusterNodeVolume.html)et [DetachClusterNodeVolume](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DetachClusterNodeVolume.html)API pour associer et détacher vos volumes Amazon EBS aux instances de cluster SageMaker HyperPod EKS. **Les principales exigences relatives à leur utilisation APIs sont les suivantes.** + Le volume Amazon EBS et le cluster SageMaker HyperPod EKS doivent appartenir à la même Compte AWS entité. + Le principal appelant a besoin d’autorisations minimales spécifiques pour effectuer correctement l’opération d’attachement ou de détachement. Pour plus d’informations sur les autorisations minimales, consultez les sections suivantes. + Après avoir attaché un volume à votre HyperPod nœud, suivez les instructions des [sections SageMaker HyperPod Accès aux nœuds](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-access-through-terminal.html) de cluster pour accéder au nœud de cluster et [Rendre un volume disponible pour](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-using-volumes.html) le montage du volume attaché. ### Autorisations nécessaires pour les `sagemaker:AttachClusterNodeVolume` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sagemaker:AttachClusterNodeVolume" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/*" }, { "Effect": "Allow", "Action": [ "eks:DescribeCluster" ], "Resource": "arn:aws:eks:us-east-1:111122223333:cluster/my-cluster-name" }, { "Effect": "Allow", "Action": [ "ec2:AttachVolume", "ec2:DescribeVolumes" ], "Resource": "arn:aws:ec2:us-east-1:111122223333:volume/*" } ] } ``` ------ ### Autorisations nécessaires pour les `sagemaker:DetachClusterNodeVolume` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sagemaker:DetachClusterNodeVolume" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/*" }, { "Effect": "Allow", "Action": [ "eks:DescribeCluster" ], "Resource": "arn:aws:eks:us-east-1:111122223333:cluster/my-cluster-name" }, { "Effect": "Allow", "Action": [ "ec2:DetachVolume", "ec2:DescribeVolumes" ], "Resource": "arn:aws:ec2:us-east-1:111122223333:volume/*" } ] } ``` ------ ### Autorisations requises pour les AWS KMS clés Ajoutez les AWS KMS autorisations suivantes uniquement si vous utilisez des clés KMS gérées par le client pour chiffrer vos volumes Amazon EBS attachés à des nœuds de HyperPod cluster. Ces autorisations ne sont pas requises si vous utilisez des clés KMS gérées par AWS(option de chiffrement par défaut). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "key-default-1", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/caller-role" }, "Action": "kms:DescribeKey", "Resource": "*" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/caller-role" }, "Action": "kms:CreateGrant", "Resource": "*", "Condition": { "StringEquals": { "kms:CallerAccount": "111122223333", "kms:ViaService": "ec2.us-east-1.amazonaws.com" }, "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:ebs:id" }, "Bool": { "kms:GrantIsForAWSResource": true }, "ForAllValues:StringEquals": { "kms:GrantOperations": [ "Decrypt" ] } } } ] } ``` ------ **Note** Ces AWS KMS autorisations ne sont pas requises `sagemaker:DetachClusterNodeVolume` lors du détachement d'un volume CAVA (Cluster Auto Volume Attachment) chiffré à l'aide de clés KMS gérées par le client. # Configuration d'étiquettes et de teintures Kubernetes personnalisées sur Amazon SageMaker HyperPod SageMaker HyperPod Les clusters Amazon dotés de l'orchestrateur Amazon Elastic Kubernetes Service (Amazon EKS) prennent en charge les étiquettes et les teintes Kubernetes personnalisées pour les nœuds au sein de groupes d'instances. Les étiquettes et les annotations sont des mécanismes fondamentaux de planification et d'organisation dans Kubernetes qui vous permettent de contrôler avec précision le placement des pods et l'utilisation des ressources. Les étiquettes sont des paires clé-valeur qui peuvent être associées à des objets Kubernetes, ce qui vous permet d'organiser et de sélectionner des ressources en fonction d'attributs. Les taches, associées aux tolérances, sont des propriétés spécifiques aux nœuds qui influencent la planification des capsules en repoussant les gousses dont les tolérances ne sont pas identiques. Ensemble, ces mécanismes vous permettent d'isoler les charges de travail, de les attribuer en fonction des spécifications matérielles et de garantir une utilisation optimale des ressources. ## Cas d’utilisation courants Voici les scénarios courants dans lesquels les étiquettes et les teintures personnalisées sont bénéfiques : + **Prévention des modules système sur des instances coûteuses** : appliquez des modifications aux instances GPU pour empêcher les modules système et autres charges de travail non critiques de consommer des ressources de calcul coûteuses + **Intégration à l'outillage existant** : appliquez des étiquettes qui correspondent aux modèles d'infrastructure établis et aux configurations d'affinité des nœuds de votre organisation ## Configuration des étiquettes et des teintures Vous pouvez configurer des étiquettes et des nuances Kubernetes personnalisées au niveau du groupe d'instances à l'aide du `KubernetesConfig` paramètre de configuration de votre cluster. Les étiquettes et les marques sont appliquées à tous les nœuds du groupe d'instances et persistent tout au long du cycle de vie du cluster. Le `KubernetesConfig` paramètre est déclaratif, ce qui signifie que vous spécifiez l'état complet souhaité des étiquettes et des nuances pour un groupe d'instances. SageMaker HyperPod réconcilie ensuite l'état réel des nœuds pour qu'il corresponde à l'état souhaité. + **Ajouter des étiquettes ou des teintures** - Incluez les nouvelles étiquettes ou teintures `KubernetesConfig` ainsi que celles que vous souhaitez conserver + **Mise à jour des étiquettes ou des teintures** : modifiez les valeurs `KubernetesConfig` des étiquettes ou des teintures que vous souhaitez modifier, et incluez toutes les autres que vous souhaitez conserver + **Supprimer les étiquettes ou les taches** : omettez les étiquettes ou les taches que vous souhaitez supprimer`KubernetesConfig`, en ne conservant que celles que vous souhaitez conserver ### Création d'un cluster avec des étiquettes et des teintures Lorsque vous créez un nouveau SageMaker HyperPod cluster, incluez le `KubernetesConfig` paramètre dans la configuration de votre groupe d'instances. L'exemple suivant montre comment créer un cluster avec des étiquettes et des teintes personnalisées : ``` { "ClusterName": "my-cluster", "InstanceGroups": [{ "InstanceGroupName": "worker-group-1", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 4, "LifeCycleConfig": { "SourceS3Uri": "s3://my-bucket/lifecycle-config.sh", "OnCreate": "on-create.sh" }, "ExecutionRole": "arn:aws:iam::123456789012:role/HyperPodExecutionRole", "ThreadsPerCore": 1, "KubernetesConfig": { "Labels": { "env": "prod", "team": "ml-training", "gpu-type": "a100" }, "Taints": [{ "key": "gpu", "value": "true", "effect": "NoSchedule" }, { "key": "dedicated", "value": "ml-workloads", "effect": "NoExecute" }] } }], "VpcConfig": { "SecurityGroupIds": ["sg-0123456789abcdef0"], "Subnets": ["subnet-0123456789abcdef0", "subnet-0123456789abcdef1"] }, "Orchestrator": { "Eks": { "ClusterArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-eks-cluster" } } } ``` Dans cet exemple : + **Étiquettes** : trois étiquettes personnalisées sont appliquées : `env=prod``team=ml-training`, et `gpu-type=a100` + **Teintes :** deux taches sont configurées pour empêcher la planification indésirable des pods ### Mise à jour des étiquettes et des altérations sur un cluster existant Vous pouvez modifier les étiquettes et les teintes d'un cluster existant à l'aide de l'`UpdateCluster`API. L'exemple suivant montre comment mettre à jour le `KubernetesConfig` pour un groupe d'instances : ``` { "ClusterName": "my-cluster", "InstanceGroups": [{ "InstanceGroupName": "worker-group-1", "KubernetesConfig": { "Labels": { "env": "prod", "team": "ml-training", "gpu-type": "a100", "cost-center": "ml-ops" }, "Taints": [{ "key": "gpu", "value": "true", "effect": "NoSchedule" }] } }] } ``` Lorsque vous mettez à jour les étiquettes et les nuances, SageMaker HyperPod applique les modifications à tous les nœuds du groupe d'instances. Le service gère la transition entre l'état actuel et l'état souhaité, que vous pouvez surveiller à l'aide de l'`DescribeCluster`API. ## Surveillance de l'étiquette et de l'application de taches SageMaker HyperPod permet APIs de surveiller l'état des étiquettes et des taches lorsqu'elles sont appliquées aux nœuds de votre cluster. ### Vérification de l'état au niveau du cluster Utilisez l'`DescribeCluster`API pour afficher l'état actuel et souhaité des étiquettes et des taches au niveau du groupe d'instances. L'exemple suivant montre la structure de réponse : ``` { "ClusterName": "my-cluster", "ClusterStatus": "InService", "InstanceGroups": [{ "InstanceGroupName": "worker-group-1", "InstanceType": "ml.p4d.24xlarge", "CurrentInstanceCount": 4, "TargetInstanceCount": 4, "KubernetesConfig": { "CurrentLabels": { "env": "prod", "team": "ml-training", "gpu-type": "a100" }, "DesiredLabels": { "env": "prod", "team": "ml-training", "gpu-type": "a100" }, "CurrentTaints": [{ "key": "gpu", "value": "true", "effect": "NoSchedule" }], "DesiredTaints": [{ "key": "gpu", "value": "true", "effect": "NoSchedule" }] } }] } ``` En cas `DesiredLabels` de `CurrentLabels` `CurrentTaints` correspondance`DesiredTaints`, la configuration spécifiée est appliquée à tous les nœuds du groupe d'instances. S'ils diffèrent, le cluster est toujours en train d'appliquer les modifications. ### Vérification de l'état de chaque nœud Pour plus de détails au niveau des nœuds, utilisez l'`DescribeClusterNode`API pour vérifier l'étiquette et altérer la configuration des nœuds individuels. L'exemple suivant montre la structure de réponse : ``` { "NodeDetails": { "InstanceId": "i-0123456789abcdef0", "InstanceGroupName": "worker-group-1", "InstanceType": "ml.p4d.24xlarge", "InstanceStatus": { "Status": "Running", "Message": "Node is healthy" }, "LifeCycleConfig": { "SourceS3Uri": "s3://my-bucket/lifecycle-config.sh", "OnCreate": "on-create.sh" }, "LaunchTime": 1699564800.0, "KubernetesConfig": { "CurrentLabels": { "env": "prod", "team": "ml-training", "gpu-type": "a100" }, "DesiredLabels": { "env": "prod", "team": "ml-training", "gpu-type": "a100" }, "CurrentTaints": [{ "key": "gpu", "value": "true", "effect": "NoSchedule" }], "DesiredTaints": [{ "key": "gpu", "value": "true", "effect": "NoSchedule" }] } } } ``` La surveillance au niveau des nœuds est utile pour résoudre les problèmes lorsque les étiquettes ou les taches ne s'appliquent pas correctement à des nœuds spécifiques, ou lorsque vous devez vérifier la configuration d'une instance particulière. ## Préfixes réservés Certains préfixes sont réservés à l'utilisation du système et ne doivent pas être utilisés pour des étiquettes ou des teintures personnalisées. Les préfixes suivants sont réservés : + `kubernetes.io/`- Réservé aux composants principaux de Kubernetes + `k8s.io/`- Réservé aux composants principaux de Kubernetes + `sagemaker.amazonaws.com/`- Réservé pour SageMaker HyperPod + `eks.amazonaws.com/`- Réservé à Amazon EKS + `k8s.aws/`- Réservé à Amazon EKS + `karpenter.sh/`- Réservé à la mise à l'échelle automatique de Karpenter Les étiquettes et les marques comportant ces préfixes sont gérées par les composants du système et ne doivent pas être remplacées par des valeurs personnalisées.