Cluster Omega


L'IMAG dispose d'un cluster nommé Omega dont chacun peut se servir pour effectuer de lourds calculs numériques. Pour lancer vos programmes ou "jobs" au cluster, on utilise PBS qui aura en charge de répartir les différents jobs aux ressources disponibles. Sur cette page vous trouverez les bases de l'utilisation de PBS. Cela sera suffisant pour la plupart d'entre nous ; néanmoins il est possible de faire nettement plus.

Vocabulaire

Avant de commencer il paraît nécessaire d'introduire un peu de vocabulaire histoire de fixer un peu les choses.

On appelle cluster un ensemble d'ordinateurs ou serveurs reliés en réseau. Il est ainsi possible de répartir la charge de travail d'un code de calcul sur plusieurs machines.

Les processeurs modernes sont équipés de plusieurs coeurs et sont ainsi capables d'effectuer simultanément autant de tâches que de coeurs présents.

Enfin on appelle noeud un serveur du cluster.

Pour remettre ces définitions dans leur contexte, le cluster Omega dispose actuellement de 12 noeuds et chacun des processeurs dispose de 12 coeurs.

Avertissement

Avec les définitions précédentes, on voit que l'on peut se représenter un cluster comme un groupe de plusieurs ordinateurs. Il ne faut cependant pas oublier que ces ordinateurs sont liés entre eux et forment donc une grappe. Cela implique en particulier que votre répertoire personnel, là où vous stockerez vos résultats, est commun à tous les noeuds. Il faut donc prendre garde à ce que plusieurs noeuds n'écrivent pas dans le même fichier de sortie sous peine d'obtenir un fichier corrompu !

Pré-requis

Bien entendu l'accès à Omega est sécurisé, ce qui signifie avant toutes choses qu'il vous faut disposer d'un compte utilisateur sur le cluster. Si ce n'est pas le cas, il faudra faire votre demande d'ouverture de compte auprès de Baptiste.

Une fois votre compte créé, vous pouvez alors vous connecter au cluster via ssh. Pour être plus précis, dans un terminal les commandes

ssh nom_utilisateur@omega

à partir du réseau local ou

ssh nom_utilisateur@omega.math.univ-montp2.fr

à partir d'un accès extérieur à l'UM2 vous permettent de vous connecter à Omega, après avoir saisi votre mot de passe - et pour la toute première connexion avoir accepté la clé du serveur.

Vous pouvez alors déposer vos fichiers, créer des répertoires, etc. de manière classique via le terminal ou via un utilitaire graphique tel que FileZilla. Par exemple, à partir d'un terminal (non logué sur Omega), la commande

scp mon_fichier_local nom_utilisateur@omega:~/nom_dossier

placera une copie du fichier "mon_fichier_local" dans le dossier "~/nom_dossier" présent sur le cluster.

L'intérêt d'un cluster est de faire tourner rapidement vos codes tout en ne saturant pas votre machine personnelle. Cela sous entend donc que, malgré tous vos efforts (optimisation du code, appels à des langages compilés comme C ou Fortran pour les parties les plus coûteuses, parallélisation, etc.) votre code de calcul reste trop lourd :-( Si vous avez du code compilé, ce que je vous conseille vivement, il faudra donc préalablement le compiler sur le cluster. Par exemple, pour compiler le code C suivant, on fera une fois logué sur omega

gcc helloworld.c -o monCode

ce qui produira un exécutable nommé "monCode" que l'on pourrait (je dis "pourrait" car ce n'est pas ce qu'on fera pour utiliser le cluster proprement) lancer en faisant

./monCode

Pour ceux qui utilisent du C, C++ ou Fortran avec du R, on compilera comme d'habitude par

R CMD SHLIB mon_code.c

ce qui nous produira une librairie statique nommée "mon_code.so" que l'on n'oubliera pas de charger dans l'appel à notre code R via

dyn.load("mon_code.so")

Voilà vous savez tout sur les pré-requis et nous allons donc pouvoir lancer nos premiers jobs sur Omega !!!

Lancer et gérer des jobs: PBS

Dans la partie précédente, je vous ai dit qu'il ne fallait pas lancer un exécutable par

./mon_executable

En fait tout job doit être lancé via PBS (Portable Batch System) qui aura la charge d'organiser au mieux la répartition de tous les jobs, dont le votre, sur le cluster.

Ne vous inquiétez pas, PBS n'a rien de bien compliqué mais nécessite quelques informations supplémentaires. En effet, afin de gérer correctement les nombreux jobs soumis au cluster, PBS à besoin par exemple de savoir le temps total d'exécution de votre code. Typiquement ces informations sont renseignées dans un fichier "script shell" que nous nommerons par exemple job.sh. Voici à quoi ressemble ce fichier

#!/bin/bash
#PBS -l walltime=1:30:00

cd ~/toto
sleep 20
./monCode

La première ligne de "job.sh" sert à dire que nous avons un script bash, la deuxième nous dit que la durée du job sera de 1h30. Attention toutefois, si votre calcul dépasse 1h30, le job est tout simplement arrêté et vos calculs s'arrêteront nets sans aucune sauvegarde ! Il convient donc de bien réfléchir lorsque l'on renseigne ce champs. Les deux dernières lignes sont des commandes shell classiques, mais ça vous l'aviez déjà remarqué.

Il ne nous reste plus qu'à soumettre le job via PBS au cluster, ce qui se fait par la commande

qsub job.sh

Votre job vient d'être soumis au cluster. Pour vérifier que votre demande a bien été prise en compte, si votre code est en cours d'exécution, a été placé en file d'attente, etc., c'est la commande "qstat" qu'il faut utiliser

> qstat
Job id              Name             User            Time Use S Queue
------------------- ---------------- --------------- -------- - -----
2818.omega          job.sh           nom_utilisateur        0 R batch

Cette sortie contient plusieurs informations utiles. La première colonne donne le numéro d'identification de votre job, ici c'est le job 2818.

La deuxième colonne correspond au nom de votre job ; par défaut c'est le nom du fichier .sh mais on verra plus tard comment affecter un nom plus parlant !

La troisième colonne donne le nom de l'utilisateur pour chacun des jobs listés --- hé oui vous n'êtes pas le seul à utiliser le cluster !!!

Remarque : Actuellement la commande qstat n'affiche que les jobs dont vous êtes le propriétaire. Cela devrait être réglé bientôt.

La quatrième colonne donne la durée en heures, minutes et secondes depuis laquelle votre code a été lancé. Pour notre exemple c'est tellement rapide que forcément le temps fait 0.

La cinquième colonne nommée "S" donne le statut de votre job. Ce statut peut être

Enfin la dernière colonne indique dans quelle file d'attente votre job a été soumis.

Une fois votre code terminé, vous noterez qu'il y a (au moins) deux fichiers qui ont été créés : job.sh.e2818 et job.sh.o2818, le 2818 correspond bien entendu au numéro d'identification de votre job. Ces fichiers correspondent respectivement aux messages éventuels d'erreurs et aux messages envoyés à la sortie standard durant l'exécution de votre code. Pour notre exemple, job.sh.e2818 est vide alors que job.sh.o2818 contient

Hello World!

Typiquement votre code de calcul sauvegardera des données/résultats importants durant son appel, et ces sauvegardes seront tout naturellement placées dans votre répertoire de travail.

Pour des raisons personnelles, il est parfois nécessaire d'arrêter un job en cours d'exécution ; ceci se fait à l'aide de la commande qdel. Cette commande prend un (ou plusieurs) arguments correspondant au numéro d'identification du job que vous souhaitez interrompre. Par exemple, en supposant que notre job affichant "Hello World!" soit encore en cours d'exécution, pour le stopper il suffira de faire

qdel 2818

A ce stade vous êtes maintenant capable de lancer/stopper vos jobs sur Omega. C'était facile non ?

Utilisation "avancée" de PBS

Dans cette section nous allons voir comment utiliser PBS de manière un peu plus poussée. Toutefois ce dont je vais parler reste encore dans le domaine de base mais est largement suffisant pour l'utilisation que j'en ai.

Nommer ses jobs

Tout enseignant chercheur qui se respecte, travaille sur de nombreux projets en même temps ;-) Il est donc pratique, voire indispensable, d'associer des noms plus parlant à chacun de nos jobs. Comme vous vous en doutez certainement, cette opération s'effectue à l'aide du script shell - vous vous souvenez notre fameux fichier job.sh. Par exemple,

#!/bin/bash
#PBS -l walltime=1:30:00
#PBS -N helloWorld

cd ~/toto
sleep 20
./monCode

affectera le nom helloWorld à mon job soumis.

Être averti du début, de la fin, ou de l'interruption d'un job

Il est souvent pratique d'être averti lorsqu'un job commence ou qu'il vient de se terminer. Cela est possible avec PBS en ajoutant à votre script shell les lignes suivantes

#PBS -M adresse_mail_valide
#PBS -m abe

Les lettres a, b et e sont là pour dire que vous souhaitez être informé lorsque votre code s'est anormalement terminé, commence ou se termine. Bien sûr il est possible d'être averti seulement d'un ou deux de ces événements.

Remarque : Cette option ne semble pas avoir été configurée sur le cluster Omega.

Lancer le même code plusieurs fois

Il est souvent utile de lancer le même code plusieurs fois ; par exemple lors de simulations Monte Carlo. Ceci peut-être fait lors de l'appel à la fonction qsub. Par exemple

qsub -t 1-5 job.sh

lancera le même job 5 fois. Notez également qu'en passant cette option à qsub, cela définit une variable d'environnement nommée PBS_ARRAYID qui peut-être par exemple utile afin de régler la graine aléatoire lors de simulations Monte Carlo. L'exemple suivant illustre bien cette variable.

#!/bin/bash
#PBS -l walltime=0:05:00

echo "Hello World from array " $PBS_ARRAYID

Pour les utilisateurs de R

Pour ceux qui veulent utiliser R sur le cluster voici un script shell que j'utilise souvent

#!/bin/bash
#PBS -l nodes=omega01,walltime=20:00:00
#PBS -N nom_du_job

cd ~/repertoire_de_travail
R CMD BATCH --vanilla code_R fichier_de_sortie.Rout

Pour finir...

Voilà c'est fini et j'espère que ce tutoriel vous a été utile. Pour ceux qui veulent aller plus loin (nous avons juste survolé les possibilités de PBS), vous trouverez des liens utiles en haut à droite de cette page.