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.

Gestionnaire de charge de travail Slurm (boue)

Taille et mise à jour de la capacité du cluster

La capacité du cluster est définie par le nombre de nœuds de calcul que le cluster peut dimensionner. Les nœuds de calcul sont soutenus par des instances Amazon EC2 définies dans les ressources de calcul de la AWS ParallelCluster configuration (Scheduling/SlurmQueues/ComputeResources) et sont organisés en files d'attente (Scheduling/SlurmQueues) qui mappent 1:1 aux Slurm partitions.

Au sein d'une ressource de calcul, il est possible de configurer le nombre minimum de nœuds de calcul (instances) qui doivent toujours fonctionner dans le cluster (MinCount), et le nombre maximum d'instances que la ressource de calcul peut atteindre (MaxCount3).

Au moment de la création du cluster, ou lors d'une mise à jour du cluster, AWS ParallelCluster lance autant d'instances Amazon EC2 que celles configurées MinCount pour chaque ressource de calcul (Scheduling/SlurmQueues/ ComputeResources) définie dans le cluster. Les instances lancées pour couvrir la quantité minimale de nœuds pour les ressources de calcul d'un cluster sont appelées nœuds statiques. Une fois démarrés, les nœuds statiques sont censés être persistants dans le cluster et le système ne les arrête pas, sauf en cas d'événement ou de condition particulier. Ces événements incluent, par exemple, l'échec des contrôles de Slurm santé Amazon EC2 et le changement de l'état du Slurm nœud en DRAIN ou DOWN.

Les instances Amazon EC2, comprises entre et ‘MaxCount - MinCount’ (MaxCount moins) MinCount), lancées à la demande pour faire face à la charge accrue du cluster, sont appelées nœuds dynamiques. 1 Leur nature est éphémère, ils sont lancés pour traiter les tâches en attente et sont interrompus lorsqu'ils restent inactifs pendant une période définie Scheduling/SlurmSettings/ScaledownIdletime dans la configuration du cluster (par défaut : 10 minutes).

Les nœuds statiques et dynamiques sont conformes au schéma de dénomination suivant :

Par exemple, étant donné la AWS ParallelCluster configuration suivante :

Scheduling:  
    Scheduler: Slurm  
    SlurmQueues:    
        - Name: queue1      
            ComputeResources:        
                - Name: c5xlarge          
                    Instances:            
                        - InstanceType: c5.xlarge          
                        MinCount: 100          
                        MaxCount: 150        

Les nœuds suivants seront définis dans Slurm

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
queue1*      up   infinite     50  idle~ queue1-dy-c5xlarge-[1-50]
queue1*      up   infinite    100   idle queue1-st-c5xlarge-[1-100]                
            

Lorsqu'une ressource de calcul en disposeMinCount == MaxCount, tous les nœuds de calcul correspondants sont statiques et toutes les instances sont lancées au creation/update moment du cluster et maintenues opérationnelles. Par exemple :

Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: queue1
      ComputeResources:
        - Name: c5xlarge
          Instances:
            - InstanceType: c5.xlarge
          MinCount: 100
          MaxCount: 100
            

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
queue1*      up   infinite    100   idle queue1-st-c5xlarge-[1-100]               
            

Mise à jour des capacités du cluster

La mise à jour de la capacité du cluster inclut l'ajout ou la suppression de files d'attente, de ressources de calcul ou la modification MinCount/MaxCount d'une ressource de calcul. À partir de AWS ParallelCluster la version 3.9.0, la réduction de la taille d'une file d'attente nécessite que la flotte de calcul soit arrêtée ou QueueUpdateStrategy réglée sur TERMINATE avant qu'une mise à jour du cluster n'ait lieu. Il n'est pas nécessaire d'arrêter le parc informatique ou de QueueUpdateStrategy régler sur TERMINATE lorsque :

Considérations et restrictions

Cette section a pour but de décrire tous les facteurs, contraintes ou limites importants à prendre en compte lors du redimensionnement de la capacité du cluster.

Lorsque vous modifiez le MinCount paramètre d'une ressource de calcul, nous pouvons distinguer deux scénarios différents : si elle MaxCount est maintenue égale à MinCount (capacité statique uniquement) et si elle MaxCount est supérieure à MinCount (capacité statique et dynamique mixte).

Changements de capacité avec les nœuds statiques uniquement

Changements de capacité avec des nœuds mixtes

SiMinCount < MaxCount, MinCount en augmentant d'un montant N (en supposant qu'il MaxCount restera inchangé), le cluster sera configuré en étendant le nombre de nœuds statiques à la nouvelle valeur de MinCount (old_MinCount + N) : <Queue/Name>-st-<ComputeResource/Name>-<old_MinCount + N> et le système continuera d'essayer de lancer des instances Amazon EC2 pour répondre à la nouvelle capacité statique requise. De plus, pour respecter la MaxCount capacité de la ressource de calcul, la configuration du cluster est mise à jour en supprimant les N derniers nœuds dynamiques  : <Queue/Name>-dy-<ComputeResource/Name>-[<MaxCount - old_MinCount - N>...<MaxCount - old_MinCount>] et le système mettra fin aux instances Amazon EC2 correspondantes.

SiMinCount < MaxCount, lors de l'augmentation MinCount et MaxCount de la même quantité N, le cluster sera configuré en étendant le nombre de nœuds statiques à la nouvelle valeur MinCount (old_MinCount + N) : <Queue/Name>-st-<ComputeResource/Name>-<old_MinCount + N> et que le système continuera à essayer de lancer des instances Amazon EC2 pour répondre à la nouvelle capacité statique requise. De plus, aucune modification ne sera apportée au nombre de nœuds dynamiques pour honorer la nouvelle

Valeur MaxCount.

SiMinCount < MaxCount, lors MinCount de la diminution de la quantité N (en supposant qu'il MaxCount restera inchangé), le cluster sera configuré en supprimant les N derniers nœuds statiques <Queue/Name>-st-<ComputeResource/Name>-[<old_MinCount - N>...<old_MinCount> et le système mettra fin aux instances Amazon EC2 correspondantes. De plus, pour respecter la MaxCount capacité de la ressource de calcul, la configuration du cluster est mise à jour en augmentant le nombre de nœuds dynamiques pour combler le vide. MaxCount - new_MinCount: <Queue/Name>-dy-<ComputeResource/Name>-[1..<MazCount - new_MinCount>] Dans ce cas, comme il s'agit de nœuds dynamiques, aucune nouvelle instance Amazon EC2 ne sera lancée à moins que le planificateur n'ait des tâches en attente sur les nouveaux nœuds.

SiMinCount < MaxCount, lorsqu'il est décroissant MinCount et MaxCount de même quantité N, le cluster sera configuré en supprimant les N derniers nœuds statiques <Queue/Name>-st-<ComputeResource/Name>-<old_MinCount - N>...<oldMinCount>] et le système mettra fin aux instances Amazon EC2 correspondantes.

De plus, aucune modification ne sera apportée au nombre de nœuds dynamiques pour respecter la nouvelle MaxCount valeur.

SiMinCount < MaxCount, lors de la diminution MaxCount de la quantité N (en supposant qu'il MinCount restera inchangé), le cluster sera configuré en supprimant les N derniers nœuds dynamiques <Queue/Name>-dy-<ComputeResource/Name>-<old_MaxCount - N...<oldMaxCount>] et le système mettra fin aux instances Amazon EC2 correspondantes au cas où elles étaient en cours d'exécution. Aucun impact n'est attendu sur les nœuds statiques.

Impacts sur les emplois

Dans tous les cas où des nœuds sont supprimés et des instances Amazon EC2 mises hors service, une tâche sbatch exécutée sur les nœuds supprimés sera remise en file d'attente, à moins qu'aucun autre nœud ne réponde aux exigences de la tâche. Dans ce dernier cas, la tâche échoue avec le statut NODE_FAIL et disparaît de la file d'attente. Elle doit être soumise à nouveau manuellement.

Si vous envisagez d'effectuer une mise à jour du redimensionnement du cluster, vous pouvez empêcher l'exécution des tâches dans les nœuds qui seront supprimés lors de la mise à jour planifiée. Cela est possible en configurant les nœuds à supprimer lors de la maintenance. Sachez que la configuration d'un nœud en maintenance n'aura aucun impact sur les tâches qui sont déjà en cours d'exécution sur le nœud.

Supposons qu'avec la mise à jour planifiée du redimensionnement du cluster, vous allez supprimer le nœudqeueu-st-computeresource-[9-10]. Vous pouvez créer une Slurm réservation à l'aide de la commande suivante

sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]

Cela créera une Slurm réservation nommée maint_for_update sur les nœudsqeueu-st-computeresource-[9-10]. À partir du moment où la réservation est créée, aucune tâche ne peut être exécutée sur les nœudsqeueu-st-computeresource-[9-10]. Sachez que la réservation n'empêchera pas l'attribution éventuelle de tâches sur les nœudsqeueu-st-computeresource-[9-10].

Après la mise à jour du redimensionnement du cluster, si la Slurm réservation a été définie uniquement sur les nœuds supprimés lors de la mise à jour du redimensionnement, la réservation de maintenance sera automatiquement supprimée. Si, au contraire, vous aviez créé une Slurm réservation sur les nœuds qui sont toujours présents après la mise à jour du redimensionnement du cluster, il se peut que nous souhaitions supprimer la réservation de maintenance sur les nœuds une fois la mise à jour du redimensionnement effectuée, en utilisant la commande suivante

sudo -i scontrol delete ReservationName=maint_for_update

Pour plus de détails sur la Slurm réservation, consultez le document officiel de SchedMD ici.

Processus de mise à jour du cluster en cas de modification de capacité

Lors d'une modification de la configuration du planificateur, les étapes suivantes sont exécutées pendant le processus de mise à jour du cluster :

Pour plus d’informations sur Slurm, consultez https://slurm.schedmd.com. Pour les téléchargements, veuillez consulter https://github.com/SchedMD/slurm/tags. Pour le code source, consultez https://github.com/SchedMD/slurm.

Versions de cluster et de SLURM prises en charge

Le tableau suivant répertorie AWS ParallelCluster les Slurm versions prises en AWS charge.