Sommaire
Surveiller le cluster
Normalement les administrateurs du cluster (groupe sila) sont alertés par mail lorsque un ou plusieurs nœuds passent dans l'état DOWN (cf. SlurmTrigger). Toutefois, il n'est pas inutile de faire une surveillance active pour prévenir tout problème.
1. Démarche basée 'frontale utilisateur'
L'administrateur peut vérifier le bon fonctionnement du cluster en utilisant la démarche suivante :
connexion en tant que root sur les frontales utilisateurs (summit2, ompfront,...).
lancer la commande Slurm : squeue, pour visualiser les jobs en attente ou en cours d'exécution.
lancer la commande Slurm : sinfo, pour obtenir des informations sur l'état des noeuds.
Ces opérations peuvent être accomplies quotidiennement pour prévenir tout problème. Les détails sont donnés ci-dessous.
2. Détecter un problème en visualisant l'état des jobs
Lancer simplement la commande squeue et vérifier la raison pour laquelle un job est en attente d'exécution (statut PD pour Pending) en regardant la colonne NODELIST(REASON). Les raisons normales sont (Resources) et (Priority) : toute autre raison peut refléter un problème.
Voici un exemple intéressant ou tout paraît normal :
summit2:~ # squeue
JOBID PARTITION NAME USER ST TIME NODES CPUS NODELIST(REASON)
1249 mono_long script_g saub PD 0:00 1 8 (Resources)
1042 mono_long ref ulsc R 3-05:23:30 1 2 n4
1128 mono_long script_g saub R 1-02:44:18 1 8 n2
1150 mono_long nutrho2 ulsc R 2-19:54:49 1 2 n4
1245 mono_long sc_g4_v0 saub R 52:32 1 8 n1
1248 mono_long script_g saub R 1-03:47:04 1 8 n3
1251 mono_long sc_geos5 saub R 1-03:17:42 1 8 n6
1254 mono_long sc_g5_v0 saub R 1-02:55:35 1 8 n7
1315 mono_long run_meso bers R 20:15:18 1 1 n4
956 mpib40_8 job.mpi nguc R 4-15:03:26 2 16 n[33-34]
542 o3pflexlo launch_p boud PD 0:00 1 8 (Resources)
543 o3pflexlo launch_p boud PD 0:00 1 8 (Priority)
544 o3pflexlo launch_p boud PD 0:00 1 8 (Priority)
545 o3pflexlo launch_p boud PD 0:00 1 8 (Priority)
541 o3pflexlo launch_p boud R 2-02:17:09 1 8 n126
538 o3pflexwo launch_p boud PD 0:00 1 8 (Resources)
539 o3pflexwo launch_p boud PD 0:00 1 8 (Priority)
537 o3pflexwo launch_p boud R 1-14:39:35 1 8 n125
1262 o3pgeoslo sc_g4_v3 saub R 1-00:58:42 1 8 n128Pourtant, on peut se demander pourquoi le job 1249 demandant 1 noeud est en attente de ressource alors que la partition mono_long n'est pas saturée comme on peut le voir avec :
summit2:~ # sinfo -p mono_long PARTITION AVAIL TIMELIMIT NODES CPUS(A/I/O/T) STATE NODELIST mono_long up 15-00:00:0 2 0/16/0/16 idle~ n[5,8] mono_long up 15-00:00:0 6 45/3/0/48 alloc n[1-4,6-7]
indiquant que les noeuds 5 et 8 sont libres. Il est alors possible d'extraire plus d'informations sur un job avec la commande :
scontrol show jobs <job-id>
Dans notre cas, la commande précédente appliquée au job 1249 nous révèle que le noeud n3 a été spécifié lors de l'allocation du job (avec l'option -w n3) car ReqNodeList=n3 dans les lignes suivantes :
summit2:~ # scontrol show jobs 1249 JobId=1249 Name=script_geos4.sh UserId=saub(1601) GroupId=O3P(600) Priority=4294899374 Account=(null) QOS=(null) JobState=RUNNING Reason=None Dependency=(null) TimeLimit=15-00:00:00 Requeue=1 Restarts=0 BatchFlag=1 ExitCode=0:0 SubmitTime=2010-07-09T12:29:00 EligibleTime=2010-07-09T12:29:00 StartTime=2010-07-10T16:40:48 EndTime=2010-07-25T16:40:48 SuspendTime=None SecsPreSuspend=0 Partition=mono_long AllocNode:Sid=summit2:8832 ReqNodeList=n3 ExcNodeList=(null) NodeList=n3 NumNodes=1 NumCPUs=8 CPUs/Task=8 ReqS:C:T=65534:65534:65534 MinCPUsNode=8 MinMemoryNode=0 MinTmpDiskNode=0 Features=(null) Reservation=(null) Shared=OK Contiguous=0 Licenses=(null) Network=(null) Command=/home2/saub/GEOS-Chem.v8-02-01.stdrun/runs/v8-02-01/geos4_v1/script_geos4.sh WorkDir=/home2/saub/GEOS-Chem.v8-02-01.stdrun/runs/v8-02-01/geos4_v1
ReqNodeList=(null) lorsqu'aucun numéro de noeud n'est spécifié au cours de l'allocation.
3. Détecter un problème en visualisant l'état des noeuds
Il est très facile de repérer un noeud qui se trouve dans l'état DOWN vis à vis du gestionnaire de ressource et d'en afficher la raison par la commande :
sinfo -R
- Le résultat de la commande "sinfo -R" est recopié automatiquement dans le corps du mail envoyé à sila dans le cas où un trigger est activé pour se déclencher au passage à l'état DOWN d'un nœud (cf. SlurmTrigger).
3.1. Nœud forcé à DOWN par l'administrateur
Dans l'exemple ci-dessous rien n'est anormal puisque la raison est connue de l'administrateur :
summit2:~ # sinfo -R REASON USER TIMESTAMP NODELIST Test sila root 2012-02-15T09:19:10 n140
En effet ce résultat peut apparaître si l'administrateur a inséré dans le fichier de configuration Slurm (/usr/local/slurm/etc/slurm.conf) les lignes suivantes :
# # DownNodes # DownNodes=n140 Reason="Test sila" State="DOWN"
ou bien s'il a lancé en interactif la commande scontrol suivante (cas le plus probable) :
summit2:~ # scontrol update nodename=n140 state=down reason="Test sila"
3.2. Nœud DOWN car 'Not responding'
Il y a un problème qui nécessite une intervention lorsque la raison retournée est Not responding comme dans l'exemple ci-dessous :
REASON USER TIMESTAMP NODELIST Not responding slurm 2012-02-23T09:41:14 n231
La valeur de TIMESTAMP fournit la date et l'heure à laquelle le nœud est déclaré DOWN par Slurm. Généralement ce problème survient à cause d'un mauvais boot du nœud réveillé par Slurm1. Sur Summit2, Slurm est configuré pour marquer Down un nœud qui n'a pas donné signe de vie 20 minutes après la demande de démarrage (variable ResumeTimeout=1200 dans slurm.conf). Par conséquent, le nœud a vraisemblablement reçu une demande de 'power on' vers l'instant : TIMESTAMP-20mn. La procèdure à suivre pour traiter ce problème est détaillée dans RéactiverNoeudDown.
Le script qui se charge de réveiller un nœud est : ResumeProgram=/etc/beowulf_UF/scripts/slurm_ResumeNodes. (1)
3.3. Nœud DOWN dû à un reboot
Il peut arriver qu'un nœud en activité (dans l'état idle ou alloc) redémarre suite à une intervention sur la frontale d'administration (une perte de connexion avec le nœud, un arrêt/redémarrage souhaité par l'administrateur) ou un problème sur le nœud. Dans ce cas, lorsqu'il termine sa phase de boot en démarrant le démon slurmd, le gestionnaire de ressource force l'état du nœud à DOWN et notifie les administrateurs par mail avec un message de la forme :
REASON USER TIMESTAMP NODELIST Node unexpectedly rebooted slurm 2012-07-30T11:28:30 n231
Le nœud en question restera dans l'état DOWN tant que l'administrateur n'aura pas explicitement modifié cet état par la commande scontrol state=resume ci-dessous. Pour remettre le nœud en service vis à vis de Slurm, il faut impérativement que l'administrateur intervienne manuellement sur la frontale Summit2 en exécutant la ligne de commande :
summit2:~ # scontrol update nodename=n231 state=resume
Nous avons choisi ce type de comportement en initialisant ReturnToService=1 dans le fichier de configuration de Slurm /usr/local/slurm/etc/slurm.conf de manière à rester toujours informé d'un reboot intempestif des nœuds.