Slurm guide pour le mode file d'attente multiple

• Un nœud dans un POWER_SAVING état apparaît avec un ~ suffixe (par exempleidle~) danssinfo. Dans cet état, aucune instance EC2 ne sauvegarde le nœud. Cependant, il est toujours Slurm possible d'attribuer des tâches au nœud.

• Un nœud en transition vers un POWER_UP état apparaît avec un # suffixe (par exempleidle#) dans. sinfo Un nœud passe automatiquement à un POWER_UP état lorsqu'il Slurm attribue une tâche à un nœud dans un POWER_SAVING état.

  Vous pouvez également faire passer les nœuds à l'POWER_UPétat manuellement en tant qu'utilisateur su root à l'aide de la commande :

  $ scontrol update nodename=nodename state=power_up

  À ce stade, le ResumeProgram est invoqué, les instances EC2 sont lancées et configurées, et le nœud passe à POWER_UP cet état.

• Un nœud actuellement disponible apparaît sans suffixe (par exempleidle) danssinfo. Une fois que le nœud est configuré et a rejoint le cluster, il devient disponible pour exécuter des tâches. À ce stade, le nœud est correctement configuré et prêt à être utilisé.

  En règle générale, nous recommandons que le nombre d'instances Amazon EC2 soit le même que le nombre de nœuds disponibles. Dans la plupart des cas, les nœuds statiques sont disponibles après la création du cluster.

• Un nœud en transition vers un POWER_DOWN état apparaît avec un % suffixe (par exempleidle%) dans. sinfo Les nœuds dynamiques entrent automatiquement dans l'POWER_DOWNétat suivant ScaledownIdletime. En revanche, dans la plupart des cas, les nœuds statiques ne sont pas hors tension. Cependant, vous pouvez placer les nœuds dans POWER_DOWN cet état manuellement en tant qu'utilisateur su root à l'aide de la commande :

  $ scontrol update nodename=nodename state=down reason="manual draining"

  Dans cet état, les instances associées à un nœud sont interrompues et le nœud est remis dans POWER_SAVING cet état et peut être utilisé ultérieurement ScaledownIdletime.

  Le ScaledownIdletime réglage est enregistré dans le SuspendTimeout paramètre Slurm de configuration.

• Un nœud hors ligne apparaît avec un * suffixe (par exempledown*) danssinfo. Un nœud est mis hors ligne si le Slurm contrôleur ne peut pas le contacter ou si les nœuds statiques sont désactivés et que les instances de sauvegarde sont fermées.

• Un type d'instance (par exemplec5.xlarge)

• Un type de nœud (il s'agit de l'un dynamic ou de l'autrestatic.)

• UP: indique que la partition est dans un état actif. Il s'agit de l'état par défaut d'une partition. Dans cet état, tous les nœuds de la partition sont actifs et peuvent être utilisés.

• INACTIVE: indique que la partition est inactive. Dans cet état, toutes les instances qui sauvegardent les nœuds d'une partition inactive sont fermées. Aucune nouvelle instance n'est lancée pour les nœuds d'une partition inactive.

• Arrêt du parc informatique - Lorsque la commande suivante est exécutée, toutes les partitions passent à l'INACTIVEétat et AWS ParallelCluster les processus les conservent dans INACTIVE cet état.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status STOP_REQUESTED

• Démarrage du parc informatique - Lorsque la commande suivante est exécutée, toutes les partitions passent initialement à l'UPétat en question. Cependant, AWS ParallelCluster les processus ne permettent pas de conserver la partition dans un UP état. Vous devez modifier l'état des partitions manuellement. Tous les nœuds statiques deviennent disponibles au bout de quelques minutes. Notez que la définition d'une partition sur UP n'active aucune capacité dynamique.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status START_REQUESTED

• STOP_REQUESTED: La demande d'arrêt de la flotte de calcul est envoyée au cluster.

• STOPPING: Le pcluster processus arrête actuellement le parc informatique.

• STOPPED: le pcluster processus a terminé le processus d'arrêt, toutes les partitions sont en INACTIVE état et toutes les instances de calcul sont terminées.

• START_REQUESTED: La demande de démarrage de la flotte de calcul est envoyée au cluster.

• STARTING: le pcluster processus est en train de démarrer le cluster.

• RUNNING: le pcluster processus a terminé le processus de démarrage, toutes les partitions sont en UP état et les nœuds statiques sont disponibles au bout de quelques minutes.

• PROTECTED: Ce statut indique que certaines partitions présentent des échecs d'amorçage constants. Les partitions concernées sont inactives. Examinez le problème, puis courez update-compute-fleet pour réactiver la flotte.

• Mettez sous tension les nœuds dynamiques en POWER_SAVING état

  Exécutez la commande en tant qu'utilisateur su root :

  $ scontrol update nodename=nodename state=power_up

  Vous pouvez également soumettre une sleep 1 tâche fictive demandant un certain nombre de nœuds, puis compter sur celle-ci Slurm pour alimenter le nombre de nœuds requis.

• Mettez les nœuds dynamiques hors tension avant ScaledownIdletime

  Nous vous recommandons de définir les nœuds dynamiques en DOWN tant qu'utilisateur su root à l'aide de la commande suivante :

  $ scontrol update nodename=nodename state=down reason="manually draining"

  AWS ParallelCluster arrête et réinitialise automatiquement les nœuds dynamiques mis hors service.

  En général, nous vous déconseillons de configurer les nœuds POWER_DOWN directement à l'aide de la scontrol update nodename=nodename state=power_down commande. En effet, le processus de mise hors tension est géré AWS ParallelCluster automatiquement.

• Désactiver une file d'attente (partition) ou arrêter tous les nœuds statiques d'une partition spécifique

  Définissez une file d'attente spécifique INACTIVE en tant qu'utilisateur su root avec la commande :

  $ scontrol update partition=queuename state=inactive

  Cette opération met fin à toutes les instances qui soutiennent les nœuds de la partition.

• Activer une file d'attente (partition)

  Définissez une file d'attente spécifique pour UP un utilisateur su root à l'aide de la commande :

  $ scontrol update partition=queuename state=up

Voici un exemple du flux de travail de dimensionnement normal :

• Le planificateur reçoit une tâche qui nécessite deux nœuds.

• Le planificateur fait passer deux nœuds à un POWER_UP état et appelle ResumeProgram avec les noms des nœuds (par exemplequeue1-dy-spotcompute1-[1-2]).

• ResumeProgramlance deux instances Amazon EC2 et attribue les adresses IP privées et les noms d'hôtes dequeue1-dy-spotcompute1-[1-2], en attendant ResumeTimeout (la période par défaut est de 30 minutes) avant de réinitialiser les nœuds.

• Les instances sont configurées et rejoignent le cluster. Une tâche commence à s'exécuter sur des instances.

• La tâche se termine et s'arrête de fonctionner.

• Une fois la configuration SuspendTime écoulée (qui est définie sur ScaledownIdletime), le planificateur définit les instances sur cet état. POWER_SAVING Le planificateur passe ensuite queue1-dy-spotcompute1-[1-2] à l'POWER_DOWNétat et appelle SuspendProgram avec les noms des nœuds.

• SuspendProgramest appelé pour deux nœuds. Les nœuds restent dans POWER_DOWN cet état, par exemple idle% pendant un SuspendTimeout (la période par défaut est de 120 secondes (2 minutes)). Après avoir clustermgtd détecté que les nœuds sont hors tension, il met fin aux instances de sauvegarde. Ensuite, il passe queue1-dy-spotcompute1-[1-2] à l'état inactif et réinitialise l'adresse IP privée et le nom d'hôte afin qu'il soit prêt à fonctionner pour les tâches futures.

Si les choses tournent mal et qu'une instance pour un nœud particulier ne peut pas être lancée pour une raison quelconque, voici ce qui se produit :

• Le planificateur reçoit une tâche qui nécessite deux nœuds.

• Le planificateur fait passer deux nœuds cloud bursting à l'POWER_UPétat et appelle ResumeProgram avec les noms des nœuds (par exemple). queue1-dy-spotcompute1-[1-2]

• ResumeProgramlance une (1) seule instance Amazon EC2 et configurequeue1-dy-spotcompute1-1, une (1) instance ne parvenant pas à démarrer. queue1-dy-spotcompute1-2

• queue1-dy-spotcompute1-1n'est pas concerné et se met en ligne après avoir atteint l'POWER_UPÉtat.

• queue1-dy-spotcompute1-2passe à l'POWER_DOWNétat et la tâche est automatiquement mise en file d'attente car elle Slurm détecte une défaillance d'un nœud.

• queue1-dy-spotcompute1-2devient disponible après SuspendTimeout (la valeur par défaut est de 120 secondes (2 minutes)). Entre-temps, la tâche est mise en file d'attente et peut commencer à s'exécuter sur un autre nœud.

• Le processus ci-dessus se répète jusqu'à ce que la tâche puisse être exécutée sur un nœud disponible sans échec.

Deux paramètres de synchronisation peuvent être ajustés si nécessaire :

• ResumeTimeout(la valeur par défaut est de 30 minutes)  : ResumeTimeout contrôle le temps d'Slurmattente avant de faire passer le nœud à l'état inactif.

  • Il peut être utile de prolonger ResumeTimeout si votre processus pre/post d'installation prend presque autant de temps.

  • ResumeTimeoutest également le temps d' AWS ParallelCluster attente maximum avant de remplacer ou de réinitialiser un nœud en cas de problème. Les nœuds de calcul s'arrêtent automatiquement en cas d'erreur lors du lancement ou de la configuration. AWS ParallelCluster les processus remplacent un nœud lors de la détection d'une instance terminée.

• SuspendTimeout(la valeur par défaut est de 120 secondes (2 minutes))  : SuspendTimeout contrôle la rapidité avec laquelle les nœuds sont replacés dans le système et prêts à être réutilisés.

  • Une valeur plus courte SuspendTimeout signifie que les nœuds sont réinitialisés plus rapidement et Slurm peuvent essayer de lancer des instances plus fréquemment.

  • Une valeur plus longue SuspendTimeout signifie que les nœuds défaillants sont réinitialisés plus lentement. En attendant, Slurm essaie d'utiliser d'autres nœuds. Si cela SuspendTimeout prend plus de quelques minutes, Slurm essaie de parcourir tous les nœuds du système. Une durée plus longue SuspendTimeout peut être bénéfique pour les systèmes à grande échelle (plus de 1 000 nœuds) afin de réduire le stress Slurm lorsqu'ils essaient fréquemment de remettre en file d'attente les tâches défaillantes.

  • Notez que SuspendTimeout cela ne fait pas référence au temps d' AWS ParallelCluster attente pour mettre fin à une instance de sauvegarde pour un nœud. Les instances de sauvegarde pour POWER_DOWN les nœuds sont immédiatement interrompues. Le processus de terminaison est généralement terminé en quelques minutes. Cependant, pendant ce temps, le nœud reste dans cet POWER_DOWN état et n'est pas disponible pour l'utilisation du planificateur.

• ResumeProgram: /var/log/parallelcluster/slurm_resume.log (slurm_resume)

• SuspendProgram: /var/log/parallelcluster/slurm_suspend.log (slurm_suspend)

• clustermgtd: /var/log/parallelcluster/clustermgtd.log (clustermgtd)

• computemgtd: /var/log/parallelcluster/computemgtd.log (computemgtd)

• slurmctld: /var/log/slurmctld.log (slurmctld)

• slurmd: /var/log/slurmd.log (slurmd)

• Nœuds dynamiques :

  • Consultez le ResumeProgram journal pour voir s'il ResumeProgram a été appelé avec le nœud. Si ce n'est pas le cas, consultez le slurmctld journal pour déterminer si vous avez Slurm essayé d'appeler ResumeProgram avec le nœud. Notez que des autorisations incorrectes ResumeProgram peuvent entraîner un échec silencieux.

  • S'ResumeProgramil est appelé, vérifiez si une instance a été lancée pour le nœud. Si l'instance ne s'est pas lancée, un message d'erreur clair devrait s'afficher pour expliquer pourquoi elle n'a pas pu être lancée.

  • Si une instance a été lancée, il se peut qu'un problème soit survenu pendant le processus d'initialisation. Recherchez l'adresse IP privée et l'ID d'instance correspondants dans le ResumeProgram journal et consultez les journaux d'amorçage correspondants pour l'instance spécifique dans CloudWatch Logs.

• Nœuds statiques :

  • Consultez le clustermgtd journal pour voir si des instances ont été lancées pour le nœud. Si les instances ne se sont pas lancées, des erreurs claires devraient indiquer pourquoi elles n'ont pas pu être lancées.

  • Si une instance a été lancée, il y a un problème avec le processus d'amorçage. Recherchez l'adresse IP privée et l'ID d'instance correspondants dans le clustermgtd journal et consultez les journaux d'amorçage correspondants pour l'instance spécifique dans CloudWatch Logs.

• Nœuds replaced/terminated inattendus :

  • Dans la plupart des cas, clustermgtd gère toutes les actions de maintenance des nœuds. Pour vérifier si un nœud a été clustermgtd remplacé ou résilié, consultez le clustermgtd journal.

  • En cas de clustermgtd remplacement ou de fermeture du nœud, un message devrait indiquer la raison de l'action. Si la raison est liée au planificateur (par exemple, le nœud l'étaitDOWN), consultez le slurmctld journal pour plus de détails. Si la raison est liée à Amazon EC2, utilisez des outils tels qu'Amazon CloudWatch ou la console Amazon EC2, l'interface de ligne de commande ou les kits SDK pour vérifier l'état ou les journaux de cette instance. Par exemple, vous pouvez vérifier si l'instance avait des événements planifiés ou si les contrôles de l'état de santé d'Amazon EC2 ont échoué.

  • Si vous clustermgtd n'avez pas mis fin au nœud, vérifiez s'il computemgtd a mis fin au nœud ou si EC2 a mis fin à l'instance pour récupérer une instance Spot.

• Défaillances de nœuds :

  • Dans la plupart des cas, les tâches sont automatiquement mises en file d'attente en cas de défaillance d'un nœud. Consultez le slurmctld journal pour savoir pourquoi une tâche ou un nœud a échoué et évaluez la situation à partir de là.

• En général, clustermgtd gère toutes les actions de terminaison d'instance attendues. Consultez le clustermgtd journal pour savoir pourquoi il n'a pas réussi à remplacer ou à arrêter un nœud.

• En cas de défaillance de nœuds dynamiques ScaledownIdletime, consultez le SuspendProgram journal pour voir si slurmctld les processus ont effectué des appels avec le nœud spécifique comme argument. Note SuspendProgram n'effectue aucune action spécifique. Au contraire, il ne se connecte que lorsqu'il est appelé. Toutes les terminaisons et NodeAddr réinitialisations des instances sont effectuées au plus tard. clustermgtd Slurmfait passer les nœuds à l'IDLEaprèsSuspendTimeout.

• AWS ParallelCluster ne prend pas de décisions en matière de répartition des tâches ou de dimensionnement. Il essaie uniquement de lancer, de terminer et de gérer les ressources conformément Slurm aux instructions.

  Pour les problèmes liés à l'attribution des tâches, à l'allocation des nœuds et à la décision de dimensionnement, consultez le slurmctld journal pour détecter les erreurs.