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.
Slurm stratégies d'allocation dynamique de nœuds dans la version 3.8.0
À partir de ParallelCluster la version 3.8.0, ParallelCluster utilise la reprise au niveau du travail ou le dimensionnement au niveau du travail comme stratégie d'allocation dynamique de nœuds par défaut pour dimensionner le cluster : ParallelCluster augmente le cluster en fonction des exigences de chaque tâche, du nombre de nœuds alloués à la tâche et des nœuds devant être repris. ParallelCluster obtient ces informations à partir de la variable d'environnement SLURM_RESUME_FILE.
Le dimensionnement pour les nœuds dynamiques est un processus en deux étapes, qui implique le lancement des EC2 instances et l'attribution des EC2 instances Amazon lancées au Slurm nœuds. Chacune de ces deux étapes peut être réalisée en utilisant une all-or-nothinglogique basée sur le meilleur effort.
Pour le lancement des EC2 instances Amazon :
-
all-or-nothingappelle l' EC2 API Amazon de lancement avec une cible minimale égale à la capacité cible totale
-
best-effort appelle l' EC2 API Amazon de lancement avec un objectif minimum égal à 1 et une capacité cible totale égale à la capacité demandée
Pour l'attribution des EC2 instances Amazon à Slurm nœuds :
-
all-or-nothingattribue des EC2 instances Amazon à Slurm nœuds uniquement s'il est possible d'attribuer une EC2 instance Amazon à chaque nœud demandé
-
best-effort attribue des instances Amazon EC2 à Slurm nœuds même si tous les nœuds demandés ne sont pas couverts par la capacité d' EC2 instance Amazon
Les combinaisons possibles des stratégies ci-dessus se traduisent par les stratégies de ParallelCluster lancement.
all-or-nothingmise à l'échelle :
Cette stratégie implique de AWS ParallelCluster lancer un appel d'API d'instance de EC2 lancement Amazon pour chaque tâche, qui nécessite toutes les instances nécessaires au lancement réussi des nœuds de calcul demandés. Cela garantit que le cluster évolue uniquement lorsque la capacité requise par tâche est disponible, évitant ainsi de laisser des instances inactives à la fin du processus de dimensionnement.
La stratégie utilise une all-or-nothinglogique pour le lancement des EC2 instances Amazon pour chaque tâche et une all-or-nothinglogique pour l'attribution des EC2 instances Amazon à Slurm nœuds.
Les groupes de stratégie lancent les demandes par lots, un pour chaque ressource de calcul demandée et jusqu'à 500 nœuds chacun. Pour les demandes couvrant plusieurs ressources informatiques ou dépassant 500 nœuds, traite plusieurs lots de ParallelCluster manière séquentielle.
La défaillance du lot d'une ressource unique entraîne l'arrêt de toutes les capacités inutilisées associées, ce qui garantit qu'aucune instance inactive ne sera laissée à la fin du processus de dimensionnement.
Limites
-
Le temps nécessaire à la mise à l'échelle est directement proportionnel au nombre de tâches soumises par exécution du Slurm programme de CV.
-
L'opération de dimensionnement est limitée par la limite du compte de RunInstances ressources, fixée à 1 000 instances par défaut. Cette limitation est conforme aux politiques AWS de limitation des EC2 API d'Amazon. Pour plus de détails, consultez la documentation relative à la limitation des EC2 API Amazon
-
Lorsque vous soumettez une tâche dans une ressource de calcul avec un seul type d'instance, dans une file d'attente qui couvre plusieurs zones de disponibilité, l'appel d'API de all-or-nothing EC2lancement ne réussit que si toute la capacité peut être fournie dans une seule zone de disponibilité.
-
Lorsque vous soumettez une tâche dans une ressource de calcul comportant plusieurs types d'instances, dans une file d'attente avec une seule zone de disponibilité, l'appel d'API de EC2 lancement d'all-or-nothingAmazon ne réussit que si toute la capacité peut être fournie par un seul type d'instance.
-
Lorsque vous soumettez une tâche dans une ressource de calcul comportant plusieurs types d'instances, dans une file d'attente couvrant plusieurs zones de disponibilité, l'appel d'API de EC2 lancement d'all-or-nothingAmazon n'est pas pris en charge et ParallelCluster effectue plutôt un dimensionnement optimal.
greedy-all-or-nothingmise à l'échelle :
Cette variante de la all-or-nothing stratégie garantit toujours que le cluster évolue uniquement lorsque la capacité requise par tâche est disponible, évitant ainsi les instances inactives à la fin du processus de dimensionnement, mais elle implique de ParallelCluster lancer un appel d'API d'instance de EC2 lancement Amazon qui vise une capacité cible minimale de 1, dans le but de maximiser le nombre de nœuds lancés jusqu'à la capacité demandée. La stratégie utilise une logique du meilleur effort pour le lancement des EC2 instances pour toutes les tâches, ainsi que la all-or-nothinglogique d'attribution des EC2 instances Amazon à Slurm des nœuds pour chaque tâche.
Les groupes de stratégie lancent les demandes par lots, un pour chaque ressource de calcul demandée et jusqu'à 500 nœuds chacun. Pour les demandes couvrant plusieurs ressources de calcul ou dépassant 500 nœuds, Parellelcluster traite plusieurs lots de manière séquentielle.
Cela garantit qu'aucune instance inactive ne sera laissée à la fin du processus de dimensionnement, en maximisant le débit au prix d'un surdimensionnement temporaire pendant le processus de dimensionnement.
Limites
-
Un surdimensionnement temporaire est possible, ce qui entraîne des coûts supplémentaires pour les instances qui passent à l'état actif avant la fin du dimensionnement.
-
La même limite d'instance que dans la all-or-nothing stratégie s'applique, sous réserve de AWS la limite du compte de RunInstances ressources.
mise à l'échelle optimale :
Cette stratégie appelle Amazon EC2 Launch instance API en ciblant une capacité minimale de 1 et en visant à atteindre la capacité totale demandée au prix de laisser les instances inactives après l'exécution du processus de dimensionnement si toutes les capacités demandées ne sont pas disponibles. La stratégie utilise une logique du meilleur effort pour le lancement des EC2 instances Amazon pour toutes les tâches, ainsi que la logique du meilleur effort pour l'attribution des EC2 instances Amazon aux nœuds Slurm pour chaque tâche.
Les groupes de stratégie lancent les demandes par lots, un pour chaque ressource de calcul demandée et jusqu'à 500 nœuds chacun. Pour les demandes couvrant plusieurs ressources informatiques ou dépassant 500 nœuds, traite plusieurs lots de ParallelCluster manière séquentielle.
Cette stratégie permet une mise à l'échelle bien au-delà de la limite par défaut de 1 000 instances lors de l'exécution de plusieurs processus de dimensionnement, au prix d'instances inactives au cours des différents processus de dimensionnement.
Limites
-
Possibilité d'exécuter des instances inactives à la fin du processus de dimensionnement, dans le cas où il n'est pas possible d'allouer tous les nœuds demandés par les tâches.
L'exemple suivant montre le comportement de la mise à l'échelle des nœuds dynamiques à l'aide des différentes stratégies de ParallelCluster lancement. Supposons que vous ayez soumis deux jobs demandant 20 nœuds chacun, pour un total de 40 nœuds du même type, mais que seules 30 EC2 instances Amazon soient disponibles pour couvrir la capacité demandée EC2.
all-or-nothingmise à l'échelle :
-
Pour la première tâche, une API d'instance de EC2 lancement all-or-nothingAmazon est appelée, demandant 20 instances. Un appel réussi entraîne le lancement de 20 instances
-
all-or-nothing attribution des 20 instances lancées à Slurm les nœuds de la première tâche sont réussis
-
Une autre API d'instance de EC2 lancement all-or-nothingAmazon est appelée, demandant 20 instances pour la deuxième tâche. L'appel n'aboutit pas, car il n'y a de capacité que pour 10 autres instances. Aucune instance n'est lancée pour le moment
greedy-all-or-nothingmise à l'échelle :
-
Une API d'instance de EC2 lancement Amazon est appelée, demandant 40 instances, ce qui correspond à la capacité totale demandée par toutes les tâches. Cela se traduit par le lancement de 30 instances
-
Une all-or-nothingattribution de 20 des instances lancées à Slurm les nœuds de la première tâche sont réussis
-
Une autre all-or-nothingaffectation des instances lancées restantes à Slurm des nœuds pour la deuxième tâche sont essayés, mais comme il n'y a que 10 instances disponibles sur un total de 20 demandées par la tâche, l'attribution échoue
-
Les 10 instances lancées non attribuées sont résiliées
mise à l'échelle optimale :
-
Une API d'instance de EC2 lancement Amazon est appelée, demandant 40 instances, ce qui correspond à la capacité totale demandée par toutes les tâches. Cela se traduit par le lancement de 30 instances.
-
Une affectation optimale de 20 des instances lancées à Slurm les nœuds de la première tâche sont réussis.
-
Encore une fois, les 10 instances lancées restantes ont été assignées à Slurm les nœuds de la deuxième tâche sont réussis, même si la capacité totale demandée était de 20. Mais comme la tâche demandait les 20 nœuds et qu'il était possible d'attribuer des EC2 instances Amazon à seulement 10 d'entre eux, la tâche ne peut pas démarrer et les instances restent inactives, jusqu'à ce qu'une capacité suffisante soit trouvée pour démarrer les 10 instances manquantes lors d'un appel ultérieur du processus de dimensionnement, ou que le planificateur planifie la tâche sur d'autres nœuds de calcul déjà en cours d'exécution.
