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.
# 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.
```