Slurmstratégies d'allocation dynamique de nœuds dans la version 3.8.0 - AWS ParallelCluster

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.

Slurmstraté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 instances EC2 et l'attribution des instances Amazon EC2 lancées aux 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 instances Amazon EC2 :

  • all-or-nothingappelle l'API de lancement Amazon EC2 avec une cible minimale égale à la capacité cible totale

  • best-effort appelle le lancement de l'API Amazon EC2 avec une cible minimale égale à 1 et une capacité cible totale égale à la capacité demandée

Pour l'attribution des instances Amazon EC2 aux Slurm nœuds :

  • all-or-nothingattribue des instances Amazon EC2 Slurm à des nœuds uniquement s'il est possible d'attribuer une instance Amazon EC2 à chaque nœud demandé

  • tout est fait pour attribuer les instances Amazon EC2 Slurm aux nœuds, même si tous les nœuds demandés ne sont pas couverts par la capacité des instances Amazon EC2

    Les combinaisons possibles des stratégies ci-dessus se traduisent par les stratégies de ParallelCluster lancement.

Exemple
The available ParallelCluster stratégies de lancement that can be set into the ScalingStrategy cluster configuration to be used with mise à l'échelle au niveau des tâches are:

all-or-nothingmise à l'échelle :

Cette stratégie implique de AWS ParallelCluster lancer un appel d'API d'instance de lancement Amazon EC2 pour chaque tâche, ce qui nécessite le lancement réussi de toutes les instances nécessaires au lancement 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 instances Amazon EC2 pour chaque tâche et une all-or-nothinglogique pour l'attribution des instances Amazon EC2 aux nœuds. Slurm

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, garantissant ainsi qu'aucune instance inactive ne sera laissée à la fin du processus de dimensionnement.

Limitations

  • Le temps nécessaire à la mise à l'échelle est directement proportionnel au nombre de tâches soumises par exécution du programme de Slurm 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 API EC2. Pour plus de détails, consultez la documentation relative à la limitation des API Amazon EC2

  • 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 lancement all-or-nothingEC2 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 lancement all-or-nothingAmazon EC2 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 lancement all-or-nothingAmazon EC2 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 lancement Amazon EC2 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 basée sur le meilleur effort pour le lancement des instances EC2 pour toutes les tâches, ainsi que la all-or-nothinglogique d'attribution des instances Amazon EC2 Slurm aux 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 informatiques ou dépassant 500 nœuds, traite plusieurs lots de ParellelCluster 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.

Limitations

  • 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 l'API de l'instance de lancement Amazon EC2 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 instances Amazon EC2 pour toutes les tâches, ainsi que la logique du meilleur effort pour l'attribution des instances Amazon EC2 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.

Limitations

  • Instances inactives possibles à 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 tâches demandant 20 nœuds chacune, pour un total de 40 nœuds du même type, mais que seules 30 instances Amazon EC2 soient disponibles pour couvrir la capacité demandée sur EC2.

all-or-nothingmise à l'échelle :

  • Pour la première tâche, une API d'instance de lancement all-or-nothingAmazon EC2 est appelée, demandant 20 instances. Un appel réussi entraîne le lancement de 20 instances

  • all-or-nothing l'attribution des 20 instances lancées aux Slurm nœuds pour la première tâche est réussie

  • Une autre API d'instance de lancement all-or-nothingAmazon EC2 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 lancement Amazon EC2 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-nothingaffectation de 20 des instances lancées aux Slurm nœuds pour la première tâche est réussie

  • Une autre all-or-nothingattribution des instances lancées restantes aux Slurm nœuds pour la deuxième tâche est tentée, 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 assignées sont résiliées

mise à l'échelle optimale :

  • Une API d'instance de lancement Amazon EC2 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 à des Slurm nœuds pour la première tâche est réussie.

  • Une autre affectation optimale des 10 instances lancées restantes aux Slurm nœuds pour la deuxième tâche est couronnée de succès, 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 instances Amazon EC2 à seulement 10 d'entre eux, la tâche ne peut pas démarrer et les instances restent inactives, jusqu'à ce que la capacité soit trouvée suffisante 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.