Cluster Haute Performance - Centre National de … : Principe et Utilisation I Introduction Le CNRM utilise les deux extrêmes du panel informatique qui sont le poste de travail d’un

Aneto : Principe et Utilisation

Cluster Haute Performance

Principe et Utilisation

Document mis à jour le 28/02/2008 1 CNRM/CTI Michel TYTECA


Sommaire

I Introduction ..................................................................................................................................................... 4

II Architecture .................................................................................................................................................... 5

III Les logiciels ................................................................................................................................................... 7

IV Les espaces fichiers ...................................................................................................................................... 9

V Les comptes et autorisations ........................................................................................................................ 11

VI Les Transferts de données .......................................................................................................................... 12

a. Pourquoi réguler les transferts..............................................................................................................12

b. Comment réguler les transferts............................................................................................................12

3. Les commandes « r »..............................................................................................................................13

VII La soumission de travaux .......................................................................................................................... 14

1. qsub..........................................................................................................................................................14

b. nqs2pbs...................................................................................................................................................16

c. xpbs..........................................................................................................................................................17

d. Les Classes de travaux...........................................................................................................................18

e. La synchronisation implicite.................................................................................................................18

VIII MPI ............................................................................................................................................................. 22

1. MPICH2..................................................................................................................................................22

a. Préparation d’un programme.........................................................................................................22

b. mpdboot et mpd..............................................................................................................................22

c. mpiexec.............................................................................................................................................23

d. mpdallexit.........................................................................................................................................23

e. Exemple............................................................................................................................................23

b. OpenMPI ...............................................................................................................................................23

IX Splitcmd ......................................................................................................................................................... 24 3. NOM....................................................................................................................................................................................................................................24

4. SYNOPSIS...........................................................................................................................................................................................................................24

5. DESCRIPTION..................................................................................................................................................................................................................24

6. OPTIONS............................................................................................................................................................................................................................24

7. REMARQUES....................................................................................................................................................................................................................24

8. ENVIRONNEMENT........................................................................................................................................................................................................25

9. BOGUES.............................................................................................................................................................................................................................25

10. VERSION..........................................................................................................................................................................................................................25



11. VOIR AUSSI.....................................................................................................................................................................................................................25

12. AUTEUR...........................................................................................................................................................................................................................25

X Pour en savoir plus ........................................................................................................................................ 26

i. Distributeur de tickets......................................................................................................................26

ii. raid50 raid0 et raid1.........................................................................................................................26

iii. Election d’un job (maui)................................................................................................................26

iv. Améliorations possibles.................................................................................................................27



I Introduction

Le CNRM utilise les deux extrêmes du panel informatique qui sont le poste de travail d’un coté et le supercalculateur vectoriel de l’autre. Le supercalculateur, moyen de travail indispensable, demeure une denrée rare et chère qu’il faut utiliser d’une manière efficace, alors que le PC ne permet que l’exécution de programmes raisonnables. Il existe entre ces deux utilisations un besoin de puissance intermédiaire qu’il faut contenter en évitant d’une part d’encombrer le supercalculateur et d’autre part de saturer le poste de travail.

La solution du cluster HPC est considérée comme une multiplicité de systèmes usuels. Il s’inscrit dans la continuité du poste de travail et conduit à garantir une homogénéité de l’ensemble du parc. Cette compatibilité offre une disponibilité immédiate chez l’utilisateur qui en maîtrise déjà l’outil grâce à l’expérience acquise sur son poste de travail. Le faible coût de ses éléments et sa forte modularité garantissent également une possibilité d’évolution (scalability chez les anglo-saxons) et ajouté au très bon rapport prix/performance, c’est un des arguments qui permet d’envisager de démarrer avec un budget minime sur une configuration modeste.

L’évolution constante du cluster doit être un élément important du choix et pour cela, il suffit de se référer à la loi de Moore qui dit que la puissance double tous les 18 mois. Ainsi, en terme de puissance de calcul, un cluster de 16 machines en 2006 équivaut au PC de 2010.

Le niveau de performance attendu doit permettre de faire tourner sur ce cluster de calcul un programme qui occuperait le poste de travail entre quelques minutes et quelques heures.



II Architecture

Le cluster ANETO du CNRM est constitué de n+1 machines connectées entre elles, visible par l'utilisateur comme une seule entité et répertorié sur le réseau par « aneto.cnrm.meteo.fr » On dit que cette grappe (cluster) de calculateurs est constituée d'un nœud maître (ou frontal) et de n nœuds de calcul. Les différents nœuds qui composent ce cluster sont amenés à évoluer en nombre et en genre.

Dans ce document, nous désignerons par “extérieur”, toute machine connectée au réseau ne faisant pas partie du cluster, qu’elle soit au CNRM ou pas, et par opposition “interne” tout nœud du cluster.

Le paragraphe qui suit est sujet à modification, il décrit la composition du cluster à un

instant donné.

1 nœud frontal:o serveur Dell PowerEdge1950

2 processeurs Xeon dual core 64 bit 3,00Ghz8 Go de mémoire36 Go en RAID1 privés (système) 15000tr/mnEthernet 1Gb/s2 baies de disque 3 To en RAID5+0

8 nœuds de calculo 5 serveurs Dell PowerEdge1950

2 processeurs Xeon quad core 64 bits 3,00Ghz16 Go de mémoire70 Go en RAID0 privés (système) 15000 tr/mnEthernet 1 Gb/s

o 2 serveurs Dell PowerEdge19502 processeurs Xeon dual core 64 bits 3,00Ghz8 Go de mémoire70 Go en RAID0 privés (système) 15000 tr/mnEthernet 1 Gb/s

o 1 serveur Nec Express 5800 RH22 processeurs Xeon dual core 64 bit 3,00Ghz4 Go de mémoire70 Go en RAID0 privés (système) 10000tr/mnEthernet 1Gb/s

Puissance théorique:

Equivalent à 60 processeurs

(BENCHS)





III Les logiciels

Tous les nœuds, sont placés sur le même système d'exploitation linux de la distribution Mandriva dans sa version 2007.0 64 bits. Ils disposent des mêmes logiciels que sur les postes de travail linux du CNRM et sont compatibles avec eux. Tous les exécutables produits sur un poste du CNRM, 32 et 64 bits, peuvent s'exécuter sur le cluster.

Tous les logiciels de base installés sur les postes de travail le sont également sur chaque nœud sauf ceux concernant le conversationnel pur. Aucun Bureau (GNOME ou KDE), aucun navigateur WEB, n’est disponible alors que l’on trouvera les outils suivants :

Les compilateurs gcc, g95, gfortran, pgi …

Les bibliothèques graphiques comme ImageMagick, gmt, grace …

Les langages python, perl, java …

Les applications comme Metview, …

Il est souvent préférable de compiler un programme spécifiquement pour une architecture 64 bits compatible avec un nœud du cluster pour une meilleure efficacité.

Les logiciels de gestion de l’ensemble du cluster (le middleware) sont ceux de la suite OSCAR, largement utilisé dans le communauté. Tous les composants de cette suite, conforme à l’OpenSource, ont été adaptés et recompilés pour tourner sur cette architecture par CTI. Ils représentent l’état de l’art en la matière dans le domaine des logiciels libres et parfois au delà.

Il s'agit de:

o Pbs Torque1 (dérivé de OpenPBS) version 2.1.6 pour le gestionnaire de Batch et le client.

o Maui version 3.2.6 pour le scheduler

o Ganglia version 3.0.3 pour la supervision.

o C3 version 4.0 pour la multi-diffusion interne au cluster

o Systemimager pour l'installation des nœuds et Mandriva mkcd

o OpenMPI version 1.1.2 et MPICH version 2 pour paralleliser

o NFS pour le partage de fichiers

1 Terrascale OpenSource Ressource QueueManager



Le graphique ci-dessus représente un instantané sur l’ état du cluster fourni par le logiciel ganglia. Bien que certaines parties restent à développer, ce site offre une interface agréable, indépendante du poste, permettant de superviser le fonctionnement du cluster et de façon déjà très aboutie.Cette vue d’ensemble du cluster Aneto est accessible à l’aide d’un navigateur et à tout moment depuis le CNRM à l’URL suivante :

http://aneto.cnrm.meteo.fr/ganglia


http://aneto.cnrm.meteo.fr/ganglia


IV Les espaces fichiers

NFS assure le partage des espaces sur l’ensemble des nœuds. Au total, 6To sont accessibles depuis tous les nœuds et plus de 15Go privés par nœud. Les variables d’environnements ainsi que leurs affectations sont fournies par souci de compatibilité avec le système de calcul intensif de Météofrance, TORI.

Bien que sécurisés sur des disques au format RAID50 qui offre une tolérance au panne mais pas une infaillibilité, ces espaces ne sont pas sauvegardés. Leur volume et la recherche de performances expliquent cette prise de risque. La gestion des quotas

n'est pas activée sur l'ensemble des espaces, aussi pour des raisons de performances, mais fera l'objet d'une étude si cela s'avère necessaire, notamment en cas de pénurie de place.

$HOMEDIR

Cette variable d’environnement, synonyme de $HOME, représente comme à son habitude la directory d’accueil de l’utilisateur. Elle est définie à l’annuaire LDAP du CNRM et possède la même valeur que sur les postes de travail. Les données présentes sur la HOME directory sont permanentes mais non sauvegardées. La HOME directory réside sur un espace de 2 To commun à tous les utilisateurs et visible depuis tous les nœuds sous le système de fichier /home. La taille limite d'un fichier sur cet espace est fixée à 256 Go.

$WORKDIR

Cette variable d’environnement désigne un autre espace permanent non sauvegardé. Cet espace est une extension de la HOME directory de l’utilisateur. Il réside sur un autre espace de 2 To commun à tous les utilisateurs et visible depuis tous les nœuds sous le système de fichier /work. Le nom est déduit de $HOMEDIR, soit en général quelque chose comme /work/username. La taille limite d'un fichier sur cet espace est également fixée à 256 Go.

$TMPDIR

Cette variable d’environnement désigne l’espace temporaire de travail accessible depuis tous les nœuds. Il est détruit à la fin du job et réside sur un espace de 1,5 To commun à tous les utilisateurs sous le système de fichier /utmp. Il est calculé au prologue du job, soit en général quelque chose comme /utmp/user_jobid. La taille limite d'un fichier sur cet espace est également fixée à 256 Go.

$TMP_LOC

Cette variable d’environnement désigne l’espace temporaire de travail accessible uniquement depuis le nœud où tourne le job. Les temps d’accès sont en général meilleurs que depuis



$TMPDIR. Les données sont automatiquement détruites en fin de job et l’espace réside sous le système de fichier /tmp. Le nom est calculé de façon dynamique à chaque job. La taille limite d'un fichier sur cet espace est fixée à 16 Go.



V Les comptes et autorisations

La stratégie utilisée pour l’utilisation d’ANETO s’appuie sur l’annuaire LDAP du CNRM. Les comptes et autorisations sont uniques et parfaitement compatibles avec le reste de l’utilisation du parc. Toutefois, pour des raisons de performances, les comptes locaux au cluster sont synchronisés avec l’annuaire uniquement une fois par heure. La modification du mot de passe par la commande passwd invoquée sur son poste par exemple, ne sera effective sur le cluster qu’au début de l’heure suivante.

La validation d’un compte inclut la création des répertoires définis par défaut ($HOMEDIR, $WORKDIR).

L’invalidation d’un compte n’entraîne pas la destruction systématique de l’espace utilisateur. Mais les administrateurs de CTI se réservent le droit de supprimer ces espaces dès qu’ils le jugeront nécessaires. C’est l’utilisateur qui est responsable de la

sauvegarde de ses données avant l’invalidation de son compte.

Il faut disposer d’une autorisation à son compte, fourni par CTI, pour utiliser le cluster ANETO. Cette autorisation donne droit à la soumission de jobs par le protocole PBS alors que le conversationnel n’est pas permis. Le frontal ANETO utilise la commande

rcp pour rapatrier les sorties STDIN et STDERR sur votre poste de travail selon la procédure indiquée dans la commande qsub. Il est indispensable d’autoriser sur son poste de travail, son compte aneto dans son fichier .rhosts par la ligne suivante :

aneto.cnrm.meteo.fr mon_compte

Aucun transfert de fichiers n’est possible depuis l’extérieur vers le cluster. Tous les transferts doivent se faire à l’initiative d’ANETO. Ainsi, un transfert de fichier ne pourra être déclencher que par la soumission d’un job (voir la rubrique transfert de

fichiers pour plus détails).

L’exécution de tâche cronnée est interdite. Il existe d’autres moyens pour faire exécuter un ensemble de taches sur Aneto.



VI Les Transferts de données

a. Pourquoi réguler les transferts.

La configuration proposée est une configuration modeste. Le choix du réseau (Ethernet 1Gb/s) et des logiciels (NFS) est un choix de départ, dicté par des considérations financières, qui devrait pouvoir évoluer vers quelque chose de plus performant dans le futur. Il demeure toutefois acceptable tant que le nombre de nœuds est réduit et à condition de prendre quelques précautions dont une des principales consiste à ne pas trop perturber l’ensemble du cluster de calcul par des transferts trop nombreux qui solliciteraient trop souvent les processeurs. L’optimisation des échanges est donc une grande préoccupation des administrateurs.

b. Comment réguler les transferts.

La première mesure est la suppression des échanges fichiers avec le cluster à l’initiative de l’extérieur. Tous les transferts ne sont possibles qu'à l'initiative du cluster et sont réalisés par le nœud frontal. Même si les commandes sont accessibles depuis chacun des nœuds, elles sont toujours réalisé par le frontal ANETO.

Il est préférable de découper son travail en 3 phases,

TRANSFERTS ► TRAITEMENT ► TRANSFERTS

pour une meilleure efficacité de l'ensemble du cluster même si l'imbrication de plusieurs transferts et traitements n'est pas interdit sur ANETO. Un distributeur de ticket a été écrit et mis en place afin de limiter la simultanéité des échanges avec l'extérieur du cluster. Le distributeur tente de les limiter à N (10) transferts simultanés entre ANETO et INTERNET.

Les transferts avec l’extérieur ne peuvent concerner que les espaces partagés. Il est impossible d’échanger un fichier de ou vers $TMP_LOC avec l’extérieur.

Les commandes de transferts utilisables depuis n’importe quel nœud du cluster sont:

o rcp

o rsync

o cvs

o wget

o ftget et ftput

o lp



o scp (bientôt)

Le système de transfert ftserv, basé sur ftp, écrit et modifié par la DSI, a été porté moyennant quelques ajustements sur le cluster du CNRM. La commande ftp qui a vocation à être une application conversationnelle n’est pas directement accessible depuis les nœuds du cluster ; les accès de type ftp se font à l’aide des commandes ftput et ftget, comme sur le système TORI et avec les mêmes options.

La commande ftmotpasse disponible sur tous les postes du CNRM , permet ainsi de créer et modifier son fichier .ftuas pour utilisation. Lorsqu’elle est utilisée depuis un nœud du cluster elle

a un comportement différent. Elle réalise la recopie du fichier $HOME/.ftuas vers le cluster depuis la machine de soumission, soit l’équivalent de la commande :

rcp $PBS_O_HOST/.ftuas $HOME/.ftuas.

Ce fichier sera obligatoirement protégé avec les tous les droits supprimés pour le groupe et les autres (0600) sous le $HOME de l’utilisateur.

De plus les commandes ftput et ftget sont soumises à régulation comme les autres et sont exécutées par le frontal même si elles sont activées depuis un nœud du cluster.

La re-direction du STDIN pour les commandes ftput et ftget n’est pas possible sur ANETO. Pour pallier à cet inconvénient, l’option –i nom_de_fichier permet d’inscrire la liste des

transferts à effectuer dans un fichier pour une seule session de type ftp.

Il convient d’ajouter aux méthodes indiquées ci-dessus, la méthode de synchronisation implicite expliquée au paragraphe VII.5.

3. Les commandes « r ».

La commande rsh est remplacée par la commande rcmd. Elle prend les mêmes options que la commande d'origine et suit le même comportement (voir man rsh). Attention cependant, la commande rsh est toujouts disponible sur le cluster mais ne produit pas les résultats attendus.

Limites sur la commande RCP. La commande rcp ne permet pas de transférer un fichier de plus de 2 Go depuis (et vers) le cluster. Pour s'affranchir de cette limite, et traiter les fichiers de

taille supérieure ou égale à 2 Go en gardant le même protocole de transfert, il convient dans ce cas d'utiliser la commande rsync avec l'option -e rsh.



VII La soumission de travaux

PBS Torque est installé sur tous les postes clients du CNRM sous la directory /opt/pbs depuis la version MDV2006.

Vérifier que la directory /opt/pbs/bin figure dans votre $PATH sinon ajouter la par la commande : export PATH=$PATH:/opt/pbs/bin. Vous disposerez alors directement des commandes nécessaires dont les principales sont :

qstat, qalter, qdel, qdisable, qhold, qsub, nqs2pbs, xpbs.

La soumission d’une tâche à PBS passe par l’écriture d’un script et l’utilisation de la commande qsub pour soumettre ce job. Les jobs sont placés dans des files d’attente.

1. qsub

Créer un job, c’est soumettre un script exécutable au serveur. Le serveur est celui qui est défini par défaut (aneto) à moins que l’option –q soit précisée. Dans la plupart des cas, le script est un script shell sh ou csh.

Les options de la commande qsub sont des directives soumises au gestionnaire de batch PBS (Torque). L’autre forme pour passer ces directives consiste à les inclure dans le script lui-même. Un script PBS peut donc contenir deux types d’informations ; la première concerne les options fournies à PBS, la seconde au job lui-même. Les lignes débutant par “#PBS” qui sont des commentaires lorsque le script est interprété par un shell, sont des directives PBS quand elles figurent en tête du script. En effet l’analyse par Torque du script concernant les directives stoppe dès qu’une ligne du script rompt la séquence PBS (ne débute plus par “#PBS”).

Les directives ou options les plus couramment utilisées sont :

-S shell Le shell utilisé

-q nom Queue demandée

-m abe Mail requis

-M email Adresses mail

-j oe Joindre STDOUT+STDERR

-N nom Nom du job

-l ressources Ressources demandées

-v variables ENV requises



L’envoi de mail est configuré sur le cluster ANETO. Il utilise l’annuaire du CNRM pour déterminer à quelle adresse email appartient le compte utilisateur. Cette adresse sera utilisée par défaut en l’absence de l’option –M.

La commande qsub transmettra certaines variables d’environnement dans l’attribut Variable_List du job. Ces variables seront disponibles durant l’exécution du job. Les variables suivantes sont extraites de l’environnement de la commande qsub : $HOME, $LANG, $LOGNAME, $PATH, $MAIL, $SHELL et $TZ. Leurs valeurs seront attribuées à des variables qui porteront le même nom préfixée de PBS_O_. Ainsi $PBS_O_HOME aura la valeur de la variable $HOME au moment de la commande qsub. D’autres variables seront disponibles lors du job.

$PBS_O_HOST La machine de soumission du job

$PBS_O_QUEUE La classe de travaux demandée

$PBS_O_WORKDIR La directory d’origine de la soumission

$PBS_JOBID Le numéro du job en cours

$PBS_JOBNAME Le nom du Job

$PBS_NODEFILE Le nom du fichier contenant la liste des nœuds attribués

$PBS_QUEUE La classe de travaux attribuée

Les précisions sur les ressources demandées (option –l) :

cput Sec ou hh:mn :ss Temps CPU demandé

file size Taille maximum de disque requise

host val Host explicite

mem size Taille totale maximum requise en mémoire pour le job

nice val Priorité haute(-20) à priorité basse(19) requise

nodes Spécification sur les nœuds. Nombre de nœuds, Nombre de processeurs par nœud, noms des nœuds…

pcput sec Temps CPU maximum par processus demandé



pmem size Mémoire maximum par processus demandé

pvmem size Mémoire virtuelle maximum par processus requise

software val Licence ou soft (A ETUDIER)

vmem size Taille maximum de mémoire virtuelle demandée

walltime Sec… Durée maximale du Job

La commande qstat permet d’obtenir des informations sur l’état de ses requêtes.

Voir la page de man pour des informations plus complètes.

b. nqs2pbs

Cet utilitaire convertit un script NQS en script conforme à PBS. Il travaille sur une copie et insère les directives PBS déduites avant les directives #QSUB de NQS. Attention certaines directives peuvent ne pas être traduites mais un message avertit l’utilisateur dans ce cas.

Voir le manuel pour de plus amples informations.

Aucun test n’a pu encore être effectué avec cet utilitaire.



c. xpbs

xpbs constitue une interface graphique à l’ensemble des commandes pbs.



d. Les Classes de travaux

Queue Memory CPU Time Walltime Node Run Que Lm State---------------- ------ -------- -------- ---- --- --- -- -----default -- -- -- -- 0 0 10 E RXXL -- 120:00:0 120:00:0 -- 0 0 10 E RXL -- 48:00:00 48:00:00 -- 0 0 10 E RL -- 12:00:00 12:00:00 -- 0 0 10 E RM -- 02:00:00 02:00:00 -- 0 0 10 E RS -- 00:20:00 00:20:00 -- 0 0 10 E R

e. La synchronisation implicite

Lorsque la variable d’environnement $SYNC_SRC est positionnée, elle indique la directory d’origine à « mirorer » sur le cluster. La directory $SYNC_SRC et son contenu sont recopiés sous $SYNC_DEST ($HOME par défaut) avec le même nom. La directory $SYNC_DEST est créée si nécessaire. Les fichiers qui existaient sur la cible, non présents sur la source sont automatiquement détruits.

La variable respecte la syntaxe de la commande rsync. La synchronisation est déclenchée apres initialisation du profil général du système. Elle est réalisée pour le compte de l'utilisateur et proche de la commande suivante:

rsync [...] --delete $SYNC_SRC $SYNC_DEST

Les variables $SYNC_SRC et $SYNC_DEST doivent être fournies avec l'option -v de la commande de soumission de job qsub de PBS comme décrit ci-dessous:

qsub -v SYNC_SRC=machine:quelque_part,SYNC_DEST=autre_part

ou (voir man qsub) au début du script par:

#PBS -v SYNC_SRC=...

Noter que la commande de synchronisation est réalisée avec les droits de l'utilisateur, que sa réalisation est comptabilisée dans le walltime et qu'elle se déroule dans le contexte des « transferts régulés » expliqué ci-dessus. Elle est donc soumise à l'obtention d'un ticket.

Le résultat de la commande de synchronisation est disponible dans le fichier temporaire sous le nom :

$TMPDIR/.JobInSync.log

En fin de job, la synchronisation inverse et automatiquement réalisée afin de disposer en local des fichiers produits sur le cluster. Toutefois, seuls les fichiers nouvellement créés sur le cluster sont copiés en local à l’exclusion des fichiers modifiés ou détruits. Ces derniers demeurent intacts sur la station d’origine afin d’éviter des désagréments.

Il est possible de désactiver cette synchronisation inverse en détruisant avant la fin du job le fichier suivant :

rm –f $TMPDIR/.JobOutSync.args



La formule commentaire dans un script shell “#PBS” est préférable à une commande rsync explicite dans le script. En effet, elle permet de disposer d’un script entièrement

portable, qui peut s'exécuter localement de la même manière que sur le cluster sans aucune modification ou test.

Exemple:

#!/bin/sh#PBS -N MultiNodes#PBS -q S#PBS -l nodes=2:ppn=2#PBS -j oe#PBS -v SYNC_SRC=SXCTI1:/Sauvegarde/Projet1,SYNC_DEST=Projetssuite du job

La directory /Sauvegarde/Projet1 du serveur SXCTI1 sera synchronisée sous la directory Projets/Projet1 sous le $HOME de l’utilisateur avant exécution du job.

o Etape 1 (Soumission du Job)

La figure 1 représente l’état de l’arborescence sur la station SXCTI1 avant la demande d’exécution du job.

Figure 1



o Etape 2 (Activation du Job)

L’étape suivante représente l’arborescence de la $HOMEDIR juste après la synchronisation implicite, avant le démarrage du job. La directory Projets a été créée et Projet1 a été recopié vers la cible.

Figure 2

o Etape 3 (Traitement)

Supposons l’état suivant de l’arborescence de la $HOMEDIR sur le cluster après exécution du job. On notera par exemple que le fichier1 a été modifié, que le fichier5 a été supprimé et que la directory DIR3 et ses fichiers fichier6 et fichier7 ont été créés.

Figure 3



o Etape 4 (Fin du Job)

L’étape finale est représentée sur la figure 4. Le fichier1 et le fichier5 n’ont pas été modifiés en retour. La directory DIR3 et ses fichiers ont été recopiés sur SXCTI1.

Figure 4



VIIIMPI

1. MPICH2

Mpich2 est une implémentation libre et gratuite de la version 2 du standard MPI concernant les bibliothèques de “message passing”. MPI 1 et inclus dans MPI 2.

Le paquetage Mpich2 fait partie de toute installation linux du CNRM depuis la configuration des postes en MDV2006. MPI 1 fournit la commande mpirun pour démarrer un job parallèle MPI. Le MPI forum recommande l’utilisation de la

commande mpiexec. Mpich2 comporte cette commande et fournit également mpirun pour compatibilité alors que les deux commandes ne sont pas synonymes, notamment au niveau des options.

Pour lancer un job parallèle de type MPI vous devez au préalable créer l’univers MPI, puis activer le job et enfin arrêter l’univers comme indiqué ci-dessous :

o mpd ou mpdboot

o activation du programme

o mpdallexit

a. Préparation d’un programme

La meilleure façon d’obtenir un exécutable MPI est d’utiliser les scripts fournis par Mpich2 qui sont mpif77, mpif90, mpicc et mpicxx our respectivement des programmes du langage Fortran77, fortran90, C et C++. Ce sont les variables

d’environnements $MPICH_CC, $MPICH_CXX, $MPICH_F77, $MPICH_F90 qui indiquent quels sont les compilateurs a prendre en compte.

b. mpdboot et mpd

L’univers MPI se lance par la commande mpd lorsque l’on se trouve dans une configuration mono-noeud alors que la commande mpdboot est adaptée à la configuration multi-noeuds. Il faut auparavant fournir un mot de passe pour autoriser l’activation de l’univers par l’utilisateur. Pour cela, vous devez posséder un fichier $HOME/.mpd.conf protégé (0600) contenant :

MPD_SECRETWORD=mon_mot_de_passe

où mot_de_passe sera un code secret, de préférence différent de votre mot de passe de session.

Le serveur de batch Torque/PBS lorsqu’il active un job demandant la réservation de plusieurs nœuds rend à l’utilisateur une variable d’environnement $PBS_NODEFILE indiquant le PATH du fichier contenant les processeurs alloués. Ce fichier est directement utilisable par la commande mpdboot pour activer l’univers MPI. Elle comporte l’option –machinefile permettant



d’indiquer au système où lancer l’anneau MPI.

c. mpiexec

Il s’agit de la commande de base recommandée par le MPI forum pour activer un programme sur l’anneau MPI. Elle prend la forme générale :

mpixexec –n 8 mon_programme

d. mpdallexit

Fermeture de l’univers MPI.

e. Exemple

L’exemple qui suit est un programme simple écrit en C, qui s’exécutera sur 5 nœuds de 4 processeurs chacun. On doit donc trouver 20 instances du programme mpihello qui imprimeront sur STDOUT un message de bienvenue.

#!/bin/sh#PBS -N MultiNodes#PBS -q S#PBS -l nodes=5:ppn=4#PBS -j oe#PBS -v SYNC_SRC=carlit:Projets/Cluster/Tests/Mpicd Mpiechoecho "================================================================"echo "Compilation C de mpihello"echo "================================================================"mpicc -o mpihello mpihello.crm -f $HOME/.mpd.confecho "================================================================"echo "Creation du fichier MPD.CONF"echo "MPD_SECRETWORD=aneto" > $HOME/.mpd.confecho "================================================================"chmod 600 $HOME/.mpd.confecho "Boote l'univers MPI sur les 5 noeuds"mpdboot -n 5 -f $PBS_NODEFILEecho "================================================================"echo "Lancement du programme"echo "================================================================"mpiexec -np 20 ./mpihelloecho "================================================================"echo "Arret de l'anneau"echo "================================================================"mpdallexit

b. OpenMPI A ecrire



IX Splitcmd

3. NOM

splicmd - Paralléliser l'exécution d'une commande qui porte sur plusieurs jeux de données indépendantes sur le cluster ANETO.

4. SYNOPSIS

splitcmd [options] commande MIN MAX [ arg3 [ arg4 ... ]]

Options : [-vhf machinefile]

5. DESCRIPTION

La commande splitcmd distribue sur l'ensemble des noeuds alloués l'exécutable commande passé en paramètre pour une exécution parallélisée. splitcmd tient compte du nombre de noeuds alloués au job par pbs et utilise les deux premiers arguments MIN (arg1) et MAX (arg2) pour recalculer chaque instance de la commande sur les noeuds. Les arguments suivants, s'ils existent, sont reconduits tel quel.

MIN et MAX représente respectivement la borne inférieure et la borne supérieure comprises de l'intervalle d'exécution de commande.

Chaque noeud prend donc en charge l'exécution du programme " commande " sous la forme suivante : commande arg1 arg2 [arg3 [arg4 ...]] où arg1 et arg2 sont recalculés pour tenir compte du rang du noeud et de la demande initiale. Le retour de splitcmd s'effectue après la dernière exécution du programme commande.

Exemple:

splitcmd ma_commande 1950 2011 args active si 3 noeuds sont alloués:

ma_commande 1950 1970 args sur le 1er noeud ma_commande 1971 1990 args sur le 2eme noeud ma_commande 1991 2011 args sur le 3eme noeud

6. OPTIONS

-f machinefile Prendre en compte le fichier machinefile comme fichier donnant la liste des

noeuds plutot que le fichier standard pbs. -v

Passer en mode bavard. -h

Imprimer l'aide sommaire du programme.

7. REMARQUES

splitcmd n'utilise pas MPI. Aucune modification de programme n'est requise pour utiliser splitcmd pourvu que MIN et MAX soient traités convenablement et que les différentes instances travaillent sur des données indépendantes. splitcmd ne rend la main qu'après l'exécution de la dernière instance du programme. Les différentes sorties standards sont concaténées sans entrelacements dans l'ordre d'arrivée. Même si une seule instance du programme ne peut exister par noeud, l'exécutable activé peut être du type OpenMP si plusieurs processeurs sont disponibles. Pour ce faire, la requête de soumission doit être en adéquation avec l'optimisation demandée. Une demande de 4 noeuds de 3 processeurs chacun permettra par



exemple de faire tourner 4 instances d'un même programme compatible OpenMP qui utiliserait 3 coeurs par noeud.

8. ENVIRONNEMENT

Chaque instance du programme dispose de toutes les variables d'environnements définies avant l'appel de splitcmd. L'utilisateur qui désire disposer également des variables locales au script qui est responsable de l'appel de splitcmd doit utiliser l'option set -a du shell afin d'exporter automatiquement ces dernières. Les variables suivantes sont modifiées :

$HOSTNAME $PBS_NODENUM

Attention, $TMP_LOC n'est accessible que depuis le premier noeud.

9. BOGUES

toujours aucune erreur connue (HUMMM).

10. VERSION

1.0

11. VOIR AUSSI

qsub(1)

12. AUTEUR

Michel TYTECA CNRM/GSC/CTI [email protected]


mailto:[email protected]

http://localhost/cgi-bin/man/man2html?1+qsub


X Pour en savoir plus

i. Distributeur de tickets

Le démon ticketd ect activé sur aneto. Il contrôle la gestion de 10 tickets (paramètrable) qu’il délivre pour un temps donné (15 mns maximum paramètrable).

Lorsqu’un client a besoin de faire un transfert, il se présente au guichet et réclame un ticket. Il patiente au maximum 10 mns (paramètrable) que le ticket soit délivré par le démon ticketd.

Le démon lui délivre un ticket s’il en dispose et note l’heure d’attribution.

Le démon boucle sur une attente de libération de ticket ou sur délai d’expiration d’un ticket attribué si aucun ticket n’est libre.

Le client qui recoit un ticket ou qui se libère sur attente trop longue réalise son transfert.

Le client qui a terminé son transfert rend le ticket attribué.

ii. raid50 raid0 et raid1

Les diques privés à chaque nœud sont disposés en volume de type RAID0 (mode entrelacé) par le controleur. Aucune sécurité n’est assurée en cas de panne d’un des disques au profit d’ une augmentation des performances car les échanges se font à 2 fois la vitesse nominale.

Les disques privés au serveur frontal sont disposés en volume de type RAID1 (miroir) par le controleur. Le frontal dispose donc d’une bonne tolrérance aux pannes sur sa partie système.

Les baies de disques, supports des espaces partagés sont disposées en volume de type RAID5+0 (entrelacé+parité), soient 15 disques répartis comme suit :

1 disque de secours a chaud.

2x7 disques pour un RAID5 par groupe.

On dispose donc d’une bonne tolérance aux pannes + une option de performance non négligeable puisque on mesure un taux de transfert de l’ordre de 200Mo/s net.

iii. Election d’un job (maui)

FAIR SHARE SCHEDULING

RESERVATION

BACK FILLING



iv. Améliorations possibles

Le caractère modeste de cette première version d’un cluster au CNRM le prédispose à un large éventail d’améliorations possibles. On peut noter :

L’augmentation du nombre de nœuds.

L’augmentation de puissance de chacun des nœuds.

L’augmentation de la bande passante du réseau existant ( trunking ?).

Une service de partage de fichiers dédié et plus performant (GFS ?).

Un réseau de plus faible latence pour l’utilisation intensive du Message Passing (INFINIBAND ?).


Documents

Cluster Haute Performance - Centre National de … : Principe et Utilisation I Introduction Le CNRM utilise les deux extrêmes du panel informatique qui sont le poste de travail d’un