Exemples de partage de ressources de calcul inactives Comment fonctionne le partage des ressources non allouées Éligibilité des nœuds pour le partage de ressources non allouées

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.

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

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

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.

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 casDisabled), 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 quehyperpod-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.

Le partage de ressources non allouées inclut uniquement les nœuds qui répondent aux exigences suivantes :

État de prêt pour les nœuds
- Les nœuds doivent avoir le Ready statut requis 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 devientReady, il est automatiquement inclus dans le cycle de réconciliation suivant.
É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.
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.
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.

Rubriques

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Planification

Création de politiques