Slurm guide pour le mode de file d'attente multiple

• Un nœud dans un POWER_SAVING état apparaît avec un ~ suffixe (par exempleidle~) danssinfo. Dans cet état, aucune EC2 instance ne sauvegarde le nœud. Cependant, Slurm peut toujours allouer 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 lorsque Slurm alloue 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 suivante :

  $ scontrol update nodename=nodename state=power_up

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

• Un nœud actuellement disponible apparaît sans suffixe (par exempleidle) danssinfo. Une fois le nœud configuré et 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' EC2 instances Amazon 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 l'POWER_DOWNétat manuellement en tant qu'utilisateur su root à l'aide de la commande suivante :

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

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

  Le ScaledownIdletimeréglage est enregistré dans Slurm SuspendTimeoutréglage de configuration.

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

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

• Type de nœud (il s'agit de l'un dynamic ou static de l'autre)

• 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 soutiennent les nœuds d'une partition inactive sont arrêtées. Les nouvelles instances ne sont pas lancées 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 maintiennent 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. Cependant, AWS ParallelCluster les processus ne maintiennent pas la partition dans un UP état. Vous devez modifier l'état des partitions manuellement. Tous les nœuds statiques sont disponibles au bout de quelques minutes. Notez que le fait de définir une partition sur UP n'augmente aucune capacité dynamique.

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

• STOP_REQUESTED: La demande d'arrêt du parc informatique 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 démarre actuellement le cluster.

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

• PROTECTED: Cet état indique que certaines partitions présentent des échecs d'amorçage constants. Les partitions concernées sont inactives. Examinez le problème, puis lancez-vous update-compute-fleet pour réactiver le parc.

• Allumez 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 vous fier à Slurm pour alimenter le nombre de nœuds requis.

• Éteignez les nœuds dynamiques 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 tombés en panne.

  En général, il est déconseillé de définir les nœuds sur POWER_DOWN directement à l'aide de la scontrol update nodename=nodename state=power_down commande. Cela est dû au fait que le processus de mise hors tension est AWS ParallelCluster automatiquement géré.

• 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 en INACTIVE tant qu'utilisateur su root à l'aide de la commande :

  $ scontrol update partition=queuename state=inactive

  Cela 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 EC2 instances Amazon et attribue les adresses IP privées et les noms d'hôte 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.

• Une fois la configuration SuspendTime expirée (qui est définie sur ScaledownIdletime), le planificateur définit l'état des instances. 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 en restant 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 de futures tâches.

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 passe :

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

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

• ResumeProgramlance une (1) seule EC2 instance Amazon et la configurequeue1-dy-spotcompute1-1, avec une (1) instancequeue1-dy-spotcompute1-2, en échouant au lancement.

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

• queue1-dy-spotcompute1-2passe à l'POWER_DOWNétat, et le travail est automatiquement mis en attente car 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 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 s'exécuter sur un nœud disponible sans qu'une défaillance se produise.

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

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

  • Il peut être utile d'étendre ResumeTimeout si votre processus de pré-installation ou de post-installation prend presque autant de temps.

  • ResumeTimeoutest également le temps d' AWS ParallelCluster attente maximal 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 interrompue.

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

  • Une valeur plus courte SuspendTimeout signifie que les nœuds sont réinitialisés plus rapidement, et Slurm peut 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 SuspendTimeout c'est plus que quelques minutes, Slurm essaie de parcourir tous les nœuds du système. Un délai plus long SuspendTimeout peut être bénéfique pour les systèmes à grande échelle (plus de 1 000 nœuds) afin de réduire le stress sur Slurm lorsqu'il essaie de remettre fréquemment en file d'attente des 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 résiliées. 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 Slurm J'ai essayé d'appeler ResumeProgram avec le nœud. Notez que des autorisations incorrectes ResumeProgram peuvent entraîner son échec silencieux.

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

  • Si une instance a été lancée, il se peut qu'il y ait eu un problème pendant le processus de démarrage. Trouvez l'adresse IP privée et l'ID d'instance correspondants dans le ResumeProgram journal et consultez les journaux de démarrage 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 apparaître quant à la raison pour laquelle elles n'ont pas pu être lancées.

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

• Nœuds remplacés/interrompus de façon inattendue :

  • 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 résiliation du nœud, un message doit apparaître indiquant le motif 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 EC2 liée à Amazon, utilisez des outils tels qu'Amazon CloudWatch ou la EC2 console Amazon, la CLI SDKs, ou pour vérifier le statut ou les journaux de cette instance. Par exemple, vous pouvez vérifier si l'instance a connu des événements planifiés ou si les vérifications de l'état de EC2 santé d'Amazon ont échoué.

  • Si le nœud clustermgtd n'a pas été résilié, vérifiez s'il computemgtd a été résilié ou si l'instance EC2 a été résiliée pour récupérer une instance Spot.

• Défaillances des 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 fermeture d'instance attendues. Consultez le clustermgtd journal pour savoir pourquoi il n'a pas réussi à remplacer ou à mettre fin à un nœud.

• En cas d'échec 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. Remarque SuspendProgram n'effectue en fait aucune action spécifique. Au contraire, il ne se connecte que lorsqu'il est appelé. Toutes les fermetures et NodeAddr réinitialisations d'instances sont terminées parclustermgtd. Slurm fait passer les nœuds vers les IDLE nœuds suivantsSuspendTimeout.

• AWS ParallelCluster ne prend pas de décisions relatives à l'attribution des tâches ou à la mise à l'échelle. Il essaie uniquement de lancer, de résilier et de maintenir les ressources conformément à Slurminstructions.

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