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.
Politiques
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 plus d'informations sur la façon de configurer la gouvernance des tâches, consultezConfiguration de la gouvernance des tâches.
Les politiques sont divisées en priorités de calcul et allocation de calcul. Les concepts politiques ci-dessous seront organisés dans le contexte de ces politiques.
La priorisation du calcul, ou politique de cluster, détermine comment le calcul inactif est emprunté et comment les tâches sont hiérarchisées par les équipes.
-
L'allocation du calcul inactif définit la manière dont le calcul inactif est réparti entre les équipes. C'est-à-dire comment le calcul inutilisé peut être emprunté aux équipes. Lorsque vous choisissez une allocation de calcul inactive, vous pouvez choisir entre :
-
Premier arrivé, premier servi : lorsqu'elles sont appliquées, les équipes ne sont pas hiérarchisées les unes par rapport aux autres et chaque tâche entrante est également susceptible d'obtenir des ressources dépassant le quota. Les tâches sont classées par ordre de priorité en fonction de l'ordre de soumission. Cela signifie qu'un utilisateur peut être en mesure d'utiliser 100 % du calcul inactif s'il en fait la demande au préalable.
-
Partage équitable : une fois appliqué, les équipes empruntent du calcul inactif en fonction de la pondération équitable qui leur a été attribuée. Ces poids sont définis dans Calculer l'allocation. Pour plus d'informations sur la manière dont cela peut être utilisé, consultezExemples de partage de ressources informatiques inutilisées.
-
-
La hiérarchisation 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 ont été 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é ainsi que les poids auxquels elles doivent être hiérarchisées. 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 l'allocation de calcul, les tâches sont préemptées des tâches moins prioritaires par des tâches plus prioritaires au sein de l'équipe.
Lorsque les data scientists soumettent des tâches au cluster, ils utilisent le nom de classe de priorité dans le fichier YAML. La classe de priorité est au format
priority-class-name-priority -
Classes de priorité : Ces classes établissent une priorité relative pour les tâches liées à la capacité d'emprunt. 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 que celle-ci, si aucune capacité supplémentaire n'est disponible pour la tâche entrante. Si la préemption est activée dans l'allocation de calcul, une tâche plus prioritaire peut également préempter des tâches au sein de sa propre équipe.
-
L'allocation de calcul, ou 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 calcul inutilisée équitable.
-
Nom de l'équipe : nom de l'équipe. Un espace de noms correspondant sera créé, de 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, suivez les instructions de la section Créer un rôle d'équipe.
-
Poids de partage équitable : il s'agit du niveau de priorité attribué à l'équipe lorsque le partage équitable est appliqué pour l'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. Un poids plus élevé permet à une équipe d'accéder plus rapidement aux ressources inutilisées dans le cadre d'une capacité partagée. Une pondération nulle signifie 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 se bat pour les ressources disponibles par rapport aux autres. Admission donne la priorité à la planification des tâches des équipes ayant les poids les plus élevés et les emprunts les plus faibles. 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, car elle aura des tâches planifiées plus tôt que 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 ordinateurs inactifs préemptera les tâches des autres équipes.
-
Prêts et emprunts : comment l'équipe prête des ressources informatiques inutilisées et si l'équipe peut emprunter à d'autres équipes.
-
Limite d'emprunt : limite de calcul inutilisée qu'une équipe est autorisée à emprunter. Une équipe peut emprunter jusqu'à 500 % 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 %.
-
Pour plus d'informations sur la manière dont ces concepts sont utilisés, tels que les classes de priorité et les espaces de nom, consultezExemples de AWS CLI commandes de gouvernance des HyperPod tâches.
Exemples de partage de ressources informatiques inutilisées
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 ml.c5.2xlarge instances, le quota cumulé attribué aux équipes doit rester inférieur à 20.
Si les politiques d'allocation de calcul pour les équipes autorisent le prêt et l'emprunt ou le prêt, la capacité inutilisée est partagée entre ces équipes. Par exemple, Lend and Borrow est activé 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. Un travail soumis à l'équipe B nécessitant 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.
Pour gérer un pool ou un ensemble de ressources que toutes les équipes peuvent emprunter, vous pouvez créer une équipe dédiée dotée de ressources qui comblent l'écart entre les allocations des autres équipes et la capacité totale du cluster. Assurez-vous que cette allocation de ressources cumulée inclut les types d'instances appropriés et ne dépasse pas la capacité totale du cluster. Pour garantir le partage de ces ressources entre les équipes, autorisez les équipes participantes à définir leurs allocations de calcul sur Prêt et Emprunter ou sur Prêt pour ce pool de ressources commun. Chaque fois que de nouvelles équipes sont introduites, que les allocations de quotas sont modifiées ou que la capacité du cluster est modifiée, revoyez les allocations de quotas de toutes les équipes et assurez-vous que le quota cumulé reste égal ou inférieur à la capacité du cluster.
