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.
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é :
-
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.
-
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_count
indique 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_count
il 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.
PROTECTED
le 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]
queue1
La 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.
-
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
-
Nœuds
resume_timeout
ounode_replacement_timeout
expirations.Une instance ne peut pas rejoindre le cluster au sein du
resume_timeout
(pour les nœuds dynamiques) ounode_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.
-
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.
-
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 fichierslurmd
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.
clustermgtd
log (/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-output
log (/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.