Slurmmode protégé par cluster

Lorsqu'un cluster s'exécute avec le mode protégé activé, il AWS ParallelCluster surveille et suit les défaillances de démarrage des nœuds de calcul lors du lancement des nœuds de calcul. Il le fait pour détecter si ces défaillances se produisent en continu.

Si les éléments suivants sont détectés dans une file d'attente (partition), le cluster passe à l'état protégé :

1. Les défaillances consécutives du bootstrap du nœud de calcul se produisent continuellement en l'absence de lancement réussi du nœud de calcul.

2. Le nombre de défaillances atteint un seuil prédéfini.

Une fois que le cluster est devenu protégé, AWS ParallelCluster désactive les files d'attente présentant des défaillances égales ou supérieures au seuil prédéfini.

Slurmle mode protégé par cluster a été ajouté dans AWS ParallelCluster la version 3.0.0.

Vous pouvez utiliser le mode protégé pour réduire le temps et les ressources consacrés au cycle de défaillance du bootstrap des nœuds de calcul.

Paramètre du mode protégé

protected_failure_count

protected_failure_countindique le nombre de défaillances consécutives dans une file d'attente (partition) qui active le statut de protection du cluster.

La valeur par défaut protected_failure_count est 10 et le mode protégé est activé.

S'il protected_failure_count est supérieur à zéro, le mode protégé est activé.

S'protected_failure_countil est inférieur ou égal à zéro, le mode protégé est désactivé.

Vous pouvez modifier la protected_failure_count valeur en ajoutant le paramètre dans le fichier de clustermgtd configuration situé /etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf dans leHeadNode.

Vous pouvez mettre à jour ce paramètre à tout moment et vous n'avez pas besoin d'arrêter le parc informatique pour le faire. Si un lancement réussit dans une file d'attente avant que le nombre d'échecs n'atteigneprotected_failure_count, le nombre d'échecs est remis à zéro.

Vérifier l'état du cluster dans l'état protégé

Lorsqu'un cluster est protégé, vous pouvez vérifier l'état du parc informatique et l'état des nœuds.

Calculer l'état du parc

L'état du parc informatique est celui PROTECTED d'un cluster fonctionnant en état protégé.

$ pcluster describe-compute-fleet --cluster-name <cluster-name> --region <region-id>
{
   "status": "PROTECTED",
   "lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}

État du nœud

Pour savoir quelles files d'attente (partitions) présentent des défaillances de démarrage ayant activé le statut protégé, connectez-vous au cluster et exécutez la sinfo commande. Les partitions présentant des défaillances de bootstrap égales ou supérieures protected_failure_count sont dans INACTIVE cet état. Les partitions ne présentant pas d'échec du bootstrap égal ou supérieur protected_failure_count sont dans l'UPétat et fonctionnent comme prévu.

PROTECTEDle statut n'a aucun impact sur les tâches en cours d'exécution. Si des tâches sont exécutées sur une partition présentant des échecs de démarrage égaux ou supérieursprotected_failure_count, la partition est définie sur une INACTIVE fois les tâches en cours d'exécution terminées.

Examinez les états des nœuds illustrés dans l'exemple suivant.

$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]

queue1La partition est INACTIVE due au fait que 10 défaillances consécutives du bootstrap du nœud de calcul ont été détectées.

Les instances situées derrière les nœuds ont queue1-dy-c5xlarge-[1-10] été lancées mais n'ont pas réussi à rejoindre le cluster en raison d'un état défectueux.

Le cluster est protégé.

La partition queue2 n'est pas affectée par les échecs de bootstrap dansqueue1. Il est dans l'UPétat et peut toujours exécuter des tâches.

Comment désactiver le statut protégé

Une fois l'erreur de démarrage résolue, vous pouvez exécuter la commande suivante pour sortir le cluster de son statut protégé.

$ pcluster update-compute-fleet --cluster-name <cluster-name> \
  --region <region-id> \
  --status START_REQUESTED

Défaillances du bootstrap qui activent le statut protégé

Les erreurs de démarrage qui activent le statut protégé sont subdivisées en trois types suivants. Pour identifier le type et le problème, vous pouvez vérifier si des journaux AWS ParallelCluster ont été générés. Si des journaux ont été générés, vous pouvez vérifier les détails des erreurs. Pour plus d’informations, consultez Récupération et conservation des journaux.

1. Erreur de démarrage qui provoque l'arrêt automatique d'une instance.

   Une instance échoue au début du processus de démarrage, par exemple une instance qui s'arrête automatiquement en raison d'erreurs dans le script SlurmQueues\ CustomActions\ OnNodeStart|. OnNodeConfigured

   Pour les nœuds dynamiques, recherchez les erreurs similaires aux suivantes :

   Node bootstrap error: Node ... is in power up state without valid backing instance

   Pour les nœuds statiques, recherchez dans le clustermgtd journal (/var/log/parallelcluster/clustermgtd) les erreurs similaires aux suivantes :

   Node bootstrap error: Node ... is in power up state without valid backing instance

2. Nœuds resume_timeout ou node_replacement_timeout expirations.

   Une instance ne peut pas rejoindre le cluster au sein du resume_timeout (pour les nœuds dynamiques) ou node_replacement_timeout (pour les nœuds statiques). Il ne s'arrête pas automatiquement avant le délai imparti. Par exemple, la mise en réseau n'est pas correctement configurée pour le cluster et le nœud est réglé à l'DOWNétat une Slurm fois le délai expiré.

   Pour les nœuds dynamiques, recherchez les erreurs similaires aux suivantes :

   Node bootstrap error: Resume timeout expires for node

   Pour les nœuds statiques, recherchez dans le clustermgtd journal (/var/log/parallelcluster/clustermgtd) les erreurs similaires aux suivantes :

   Node bootstrap error: Replacement timeout expires for node ... in replacement.

3. Le contrôle de santé des nœuds échoue.

   Une instance située derrière le nœud échoue à une vérification de l'état d'Amazon EC2 ou à une vérification de l'état d'un événement planifié, et les nœuds sont traités comme des nœuds de défaillance du bootstrap. Dans ce cas, l'instance se termine pour une raison indépendante de la volonté de AWS ParallelCluster.

   Recherchez dans le clustermgtd journal (/var/log/parallelcluster/clustermgtd) les erreurs similaires aux suivantes :

   Node bootstrap error: Node %s failed during bootstrap when performing health check.

4. L'Slurmenregistrement des nœuds de calcul échoue.

   L'enregistrement du slurmd démon auprès du démon de Slurm contrôle (slurmctld) échoue et fait passer l'état du nœud de calcul à cet état. INVALID_REG Des nœuds de Slurm calcul mal configurés peuvent provoquer cette erreur, par exemple des nœuds calculés configurés avec des erreurs de spécification de nœuds de CustomSlurmSettingscalcul.

   Consultez le fichier slurmctld journal (/var/log/slurmctld.log) du nœud principal ou le fichier slurmd journal (/var/log/slurmd.log) du nœud de calcul défaillant pour détecter des erreurs similaires aux suivantes :

   Setting node %s to INVAL with reason: ...

Comment déboguer le mode protégé

Si votre cluster est protégé et s'il a AWS ParallelCluster généré des clustermgtd journaux à partir des nœuds de calcul problématiques HeadNode et des cloud-init-output journaux à partir de nœuds de calcul, vous pouvez consulter les journaux pour obtenir des informations détaillées sur les erreurs. Pour plus d'informations sur la façon de récupérer les journaux, consultezRécupération et conservation des journaux.

clustermgtdlog (/var/log/parallelcluster/clustermgtd) sur le nœud principal

Les messages du journal indiquent quelles partitions présentent des échecs d'amorçage et le nombre d'échecs d'amorçage correspondant.

[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions  
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.

Dans le clustermgtd journal, recherchez le Found the following bootstrap failure nodes nœud qui n'a pas pu démarrer.

[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING - 
Found the following bootstrap failure nodes: (x2)  ['queue1-st-c5large-1(192.168.110.155)',  'broken-st-c5large-2(192.168.65.215)']

Dans le clustermgtd journal, recherchez Node bootstrap error la raison de l'échec.

[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error: 
Node broken-st-c5large-2(192.168.65.215) is currently in  replacement and no backing instance

cloud-init-outputlog (/var/log/cloud-init-output.log) sur les nœuds de calcul

Après avoir obtenu l'adresse IP privée du nœud de défaillance du bootstrap dans le clustermgtd journal, vous pouvez trouver le journal du nœud de calcul correspondant en vous connectant au nœud de calcul ou en suivant les instructions Récupération et conservation des journaux pour récupérer les journaux. Dans la plupart des cas, le /var/log/cloud-init-output journal du nœud problématique indique l'étape à l'origine de l'échec du bootstrap du nœud de calcul.