Présentation de dga-cluster

Caractéristiques du cluster

• Cluster SuperMicro
• 82 nœuds de calcul et un nœud frontal en haute disponibilité (HADR)
• Interconnexion 10 gigabit ethernet + Infiniband 56 Gb/s
• 2 switchs 48 ports 1 Gb/s (pour l'administration)
• 4 switchs 48 ports 10 Gb/s
• 5 switchs Infiniband 36 ports 56 Gb/s

Station d’accueil

• 2 serveurs SuperMicro SYS-6028R-TRT en haute disponibilité (si un serveur s'arrête, le second prend sa place de façon transparente pour l'utilisateur)
• 2 Processeurs Intel Xeon 16 cores E5-2698 v3
• 256 Go de mémoire
• 2 disques internes SAS mirrorés de 1 To, 15000 trs/min

Nœuds de calculs

Marque Type nombre de noeuds Processeurs/noeuds nombre de coeurs/noeuds Mémoire (Go)/noeuds
SuperMicro SYS-6028TP-HTTR 72 2 x E5-2640 v3 @ 2.60GHz 16 128
SuperMicro SYS-6028TP-HTTR 8 2 x E5-2640 v3 @ 2.60GHz 16 256
SuperMicro SYS-6028R-TRT 2 2 x E5-2698 v3 @ 2.30GHz 32 512

• Interconnexion 10 gigabit ethernet (communication entre noeuds) et Infiniband 56 gb/s (accès à /travail)

Connexion au cluster

Demande de compte

L'ouverture d'un compte est nécessaire pour pouvoir accéder au cluster ( voir demande d’ouverture de compte )

Ligne de commande (SSH)

La station d’accueil du cluster se nomme dga-cluster : elle est accessible par l’adresse dga-cluster.jouy.inra.fr ou via son adresse IP 193.54.97.206

Pour se connecter utiliser un client SSH tel que PuTTY sous Windows, ou SSH sous linux.

ssh user@dga-cluster.jouy.inra.fr

Votre mot de passe vous est demandé. Vous arrivez ensuite dans votre répertoire personnel qui est le même que celui présent sur dga20.

La station d'accueil ne propose pas de bureau graphique (Gnome, kde, ...)

Connexion graphique

dga-cluster ne proposant pas de bureau graphique, if faut utiliser un déport de DISPLAY pour pouvoir ouvrir une application graphique

exemple: ouvrir un terminal une fois connecté en ssh

ssh -X user@dga-cluster

puis entrer la commande suivante
gnome-terminal

Compilateur Fortran

IMPORTANT : le compilateur Intel Fortran n'est disponible que sur dga-cluster ou via la classe SGE (ordonnanceur de travaux Batch) ifort

Organisation espace disque

Tous les utilisateurs ont un répertoire personnel sauvegardé situé dans /home qui contient leurs fichiers de configuration. Ce répertoire est partagé avec tous les noeuds du cluster et dga20.

Un /travail est accessible depuis la station de travail, les nœuds du cluster et dga20. Il est situé sur une baie Panasas connectée au serveur via un réseau Infiniband à 56 Gb/s.
Il est ouvert à tous les utilisateurs du cluster. Il n'est pas sauvegardé.

Les fichiers et répertoires présents sous /travail sont supprimés automatiquement après 17 jours de non utilisation.

Attention: Les répertoires Equipes/Projets sont accessibles en lecture seule depuis chaque noeud du cluster à l'exception du noeud hébergeant la file d'attente SGE copyq où ces répertoires sont accessibles en lecture-écriture.

cas particulier: les répertoires /bdir et /bdir_test sont accessibles en lecture-écriture depuis les noeuds hébergeant les files d'attente SGE sas et sasindex

En fin de calcul ne pas oublier de recopier les fichiers de sortie sur vos répertoires habituels en utilisant la file d'attente copyq et de faire le ménage dans les répertoires de travail du cluster.

La commande : df -Ph /travail permet de connaitre la taille et l'occupation des file-systems :

Filesystem                   Size  Used Avail Use% Mounted on
panfs://10.10.10.11/travail   28T  5,3T   23T  19% /travail

L’ordonnanceur SGE

Présentation de SGE

L’ordonnanceur utilisé pour soumettre des jobs de calcul sur le cluster du CTIG est SGE (Son of Grid Engine), c’est un logiciel open source.

Il a été mis en place plusieurs files d'attentes (queues) suivant la durée maximum d'exécution du job : ainsi, plus le job sera court et plus la priorité sera élevée. Actuellement le cluster dispose de 1384 cœurs qui permettent de faire tourner 1384 jobs simultanément. Il n’est possible dans la configuration actuelle que d’utiliser un cœur par job (sauf en lançant des jobs en parallèles).

L’objectif des files est de répondre à la majeure partie des besoins tout en optimisant l’utilisation du cluster.

Attention : tout job lancé hors SGE est supprimé sans préavis

Voici les files d’attentes disponibles, le nombre de cœurs disponible indiqué est pour une utilisation de 4G de mémoire :

Nom de la file Durée maximum du job* Nombre de cœurs disponibles (si les autres files ne sont pas utilisées) Max jobs (6) / utilisateur Max Mémoire (h_vmem) Noeud(s) cible(s)
bigmem Infinie 30 15 500 Go les 2 noeuds à 512 Go de mémoire
copyq(1) Infinie 16 12 125 Go 1 noeud à 128 Go de mémoire
ifort(2) infinie 1 1 125 Go 1 noeud à 128 Go de mémoire
longq 48h 154 110 250 Go tous sauf les 2 noeuds à 512 Go + les 2 noeuds sas + le noeud copyq
qimpute(3) Infinie 154 154 500Go tous sauf les noeuds SAS, le noeud de compilation ifort,le noeud copyq
sas(4) infinie 16 12 250 Go 1 noeud à 256 Go de mémoire
sasindex(5) infinie 16 12 250 Go 1 noeud à 256 Go de mémoire
unlimitq infinie 160 100 250 Go 30 des noeuds à 128 Go de mémoire + 3 noeuds à 256 Go de mémoire
workq 02h 1001 640 250 Go tous sauf les 2 noeuds à 512 Go + les 2 noeuds sas + le noeud copyq

*Durée maximum d’utilisation du processeur
(1) réservée aux copies de fichiers de sortie vers les espaces équipes/projets en fin de traitement
(2) réservée aux compilations Intel Fortran en Batch
(3) réservée à GenEval production
(4) réservée aux programmes utilisant SAS
(5) réservée aux programmes SAS lancés par des utilisateurs inscrits dans le groupe index-sge.
(6) le nombre maximum de jobs actifs pour un utilisateur est de 890 (toutes classes confondues)

Les jobs en trop sont mis en attente.

Limites par noeuds

Ressources utilisables par nœud sur 72 Nœuds à 128 Go de mémoire 8 Nœuds à 256 Go de mémoire 2 Nœuds à 512 Go de mémoire
Mémoire 125 Go 250 Go 500 Go
CPU (nombre de cœurs) 16 16 32

La capacité mémoire de chacun des nœuds allouée à SGE est inférieure à la capacité physique de ces noeuds de façon à réserver quelques Go pour le système. Cependant, il peut arriver que le système d’exploitation prenne plus que la mémoire qui lui est réservée, dans ce cas des jobs peuvent rester bloqués faute de mémoire disponible. il faut alors contacter ou demander moins de mémoire.

Soumettre un job

A noter: les commandes ci-dessous peuvent aussi être lancées depuis dga20

En ligne de commande :

qsub - submit a batch job to Sun Grid Engine.
qsh - submit an interactive X-windows session to Sun Grid Engine.
qlogin - submit an interactive login session to Sun Grid Engine.
qrsh - submit an interactive rsh session to Sun Grid Engine.
qalter - modify a pending batch job of Sun Grid Engine.
qresub - submit a copy of an existing Sun Grid Engine job.

Exemple pour un job simple :
1 - Il faut préparer un fichier (script) contenant la (ou les) ligne(s) de commande
2 - Vos fichiers de sortie doivent être impérativement dirigés vers l'espace disque /travail
3- Il faut impérativement préciser la quantité de mémoire à utiliser avec –l h_vmem= sinon il vous sera alloué 4Go maximum par job.
4 - Soumettre le job avec la commande de soumission (qsub)

Voici un exemple de script de soumission (il est aussi possible de lancer des jobs en interactif):
monscript.sh

#!/bin/sh
#$ -o /travail/.../output.txt
#$ -e /travail/.../error.txt
#$ -q longq
#$ -M mon_email@inra.fr
#$ -m bea
#$ -l h_vmem=3G
# Mon programme commence ici :
blastall -d swissprot -p blastx -i /travail/.../z72882.fa

Toute ligne commençant par #$ indique une option à exécuter par sge.
-l h_vmem=8G : pour spécifier à l'ordonnanceur l'allocation de 8Go de mémoire pour l'exécution
de ce job.
-q queue_name : spécifier le nom de la queue
-o output_filename : redirection de la sortie standard
-e error_filename : redirection de la sortie d'erreur
-M mon_adresse@mail : si un problème survient pendant l'exécution, un mail est envoyé à cette adresse.
-m bae : quand ce mail doit être envoyé (b : begin, a : abort, e : end)
-N job_name : pour donner un nom à son job

Pour soumettre :
qsub monscript.sh

Alternativement, vous pouvez ne faire apparaître que les lignes de commandes dans le script et indiquer les options à l’appel de qsub.
Soit qsub –l h_vmem=3G –q longq –M –m bea Monscript.sh

Avec l’interface graphique ce sont les mêmes commandes. Pour lancer l’interface taper « qmon ».

Suivre l’exécution d’un job

Utiliser la commande qstat dont voici quelques options :
qstat : liste les jobs de tous les utilisateurs en cours
qstat -u user : donne les informations uniquement sur l'utilisateur
qstat -j job_id : détail sur un job en particulier (numéro id attribué par SGE)
qstat -s r : donne uniquement les jobs avec le status r(unning)
qstat -f : visualise les jobs en cours par file et par nœud

La commande qmon permet de donner le même type d'information via une interface graphique.

Suivre l’exécution avec Ganglia :

En se connectant (depuis dga20 ou dga-cluster) sur http://193.54.97.5/ganglia/ à l’aide d’un navigateur, vous pouvez obtenir une vue synthétique de l’état du cluster. Les informations essentielles apparaissant sur cette interface sont le nombre nœuds et le nombre de jobs potentiels présents sur le cluster. Le nombre de jobs en cours d’exécution sont également représenté à l’aide d’une ligne bleu, tandis qu’une aire grisée indique le load average de la plateforme. Note importante lors d’une utilisation normale des ressources la courbe du nombre de processus en cours d’exécution et l’aire tracée par le load average doivent concorder. En cas contraire, le script en cours d’exécution devra être repensé.

Obtenir de l’information sur un job terminé

Utiliser la commande qacct :
qacct -j job_id : donne les informations sur un job en particulier.

Tuer un job

qdel -j job_id : tue un job en particulier
qdel -u user : tue l'ensemble de mes jobs

On ne peut pas tuer les jobs d’un autre utilisateur.

Problèmes connus

Certains programmes fortran peuvent rencontrer des problèmes (type error while loading shared libraries,...) lorsqu'ils s'exécutent sur le node190 (compilation ifort). Pour remédier à ce problème en attendant qu'une solution ne soit trouvée, il faut ajouter -l h=!(node190) dans les paramètres du script sge pour éviter que le job ne tourne sur le node190