Département Informatique

Rapport
GRILLE & CLUSTER
Programmation parallèle
Gestion d'image système : SystemImager,
Gestion des ressources : Slurm,
Système de fichier parallèle : Lustre

Réalisé par:
xxxxxx
Samir ABDELLI.

Année académique: 2010

I. Introduction :

Un cluster est une infrastructure qui rassemble un ensemble de machines (ordinateurs)

indépendantes, reliées au réseau et fonctionnant comme un seul système.

Grille est l’interconnexion des clusters :

II. Objectifs:

• Augmentation de la Puissance de calcule et de Stockage.

• Partage de Ressources.
• Optimisations des Performances (Temps d’Exécution).
• Garantie une Haute disponibilité des ressources et une répartition des charges de
traitements.

III. Travaux dirigés :

III.1 TD1 Programmation parallèle :

La programmation parallèle utilise différents techniques pour augmenter la puissance de
calcule et la capacité de stockage de telle sorte à minimiser le temps de traitement et optimiser
l’utilisation de ressources matériel.

La première partie de TD consiste à mètre en place la notion de programmation parallèle

on utilisant trois techniques : les threads Posix de la librairie pthread et l’utilisation d’OPENMP
en mémoire partagée et la programmation par passage de message à l'aide de la librairie MPI en
mémoire distribuée.

L’exemple étudié consiste à comparer la vitesse d’exécution pour un programme parallèle

en utilisant les threads et une exécution séquentiel du programme.

Le programme permet de calculer et d’afficher sur un plan limité par X et Y. Un nombre de

pixels. Le principe est de diviser la ligne des abscisses X à des intervalles bornés par [X0, X1] = [x0,
x1], [x0, x1], …….. [x0, x1] et de lancer pour chaque sous intervalle la fonction de calcule de nombre de
pixel (chaque threads calcule un sous intervalle).
 On remarque que la vitesse d’exécution est divisé en nombre de sous intervalles (thread).
Pour compiler le programme en utilise la commande :
gcc –lm nom.c –o nom : –lm pour inclure la librairie « math » et –o pour spécifier le nom du ficher a
exécuter.

III.1.1 Définition :
La programmation parallèle consiste à exécuter simultanément plusieurs processus,
coopérant entre eux pour réaliser une tache donnée et cela consiste un mayeur utilisation du
processeur.
La programmation parallèle peut se faire de différentes manières :
• Sur la même machine avec un seul processeur partagé (mono processeur).
• Sur une machine ayant plusieurs processeurs (multi processeur).
• Sur des machines différentes interconnectées par un réseau de
communication, la synchronisation s’effectue par l’échange de messages.

III.1.2 Les threads :

Ce sont des processus légers, coopèrent entre eux, partagent la même mémoire pour
réaliser des taches communes.
L’objectif des threads consiste à appliquer le principe de la programmation parallèle dans les
machines pour but d’optimiser la vitesse d’exécution des programmes et un mayeur utilisation
des processeurs.
En outre l’implémentation des threads nécessite des mécanismes de synchronisation et de
gestion de ressources (sémaphores, moniteurs, …).
De la, on peut avoir des situations d’interblocage et une complexité des Programmes.

III.1.3 OPENMP :
C’est est une interface de programmation portable, qui permet de faciliter le
développement des applications parallèles pour machines à mémoire partagée. OpenMP permet
de réaliser une parallélisassions incrémentale d'un code séquentiel en utilisant les primitives
FORK () et JOIN (). OpenMP nous permet de gérer l’ordre ainsi le regroupement des taches
(threads).

III.1.4 MPI  (Message Passing Interface) :

Est un outil de programmation parallèle. Utilise le model de programmation par message,
implémenté sur des architectures à mémoire partagées et distribuées.

Avantage  :
• Tout algorithme parallèle peut être exprimé en termes du paradigme MPI
• On peut l’appliquer en même temps sur des architectures à mémoire distribués et
partagée. La performance est généralement bonne dans les deux environnements
• Permet un contrôle explicite sur la communication, conduisant à un rendement élevé à
cause du chevauchement de communication et de calcul.
• MPI est portable.
• Les implémentations actuelles sont efficaces et optimisés.

III.2 TD2 installation d’un cluster (gestion système) :

 III.2 .1 Installation des machines :

Ici il suffit d’installer le système CentOS 5.3 avec l’image iso fournie dans trois machine
cluster0(serveur) et deux clients cluster1 et cluster2 suivant les indications du TD. Cluster2 sera installé
à partir d’une image de cluster1

III.2 .2 Mise en place d’un environnement minimal d’administration distant :

• Résolution des noms :

Création de la première machine virtuelle (Cluster0)
192.168.0.1 cluster0
192.168.0.2 cluster1
192.168.0.3 cluster2
Dans le fichier /etc/hosts pour la machine cluster0 et cluster1, mettre :

Pour tester la résolution, on peut faire pinguer les autres machines avec leur nom.
ping cluster1
Ex :

Note : Dans ce qui suit, les commandes contiennent parfois les résultats de l’exécution de cette
commande et c’est dans le bit de pouvoir voir les différent paramètres et parfois encore les
options à saisir durant l’exécution de cette commande par l’utilisateur.

• Configuration ssh :
Pour ce faire, sur cluser0, se loguer en tant que « root » et créer une paire de clé via la
commande ssh-keygen -t rsa. Sera demande le dossier dans le quel créer les clés, laisser le dossier
par défaut (ce pendant on peut donner un chemin différent de celui pas défaut) puis une
passephrase ne rien mettre pour permettre la connexion ssh sans demande de mot de passe.

Une fois la paire de clé créée, il faut le synchronisé avec les autres nœuds via la
commande.
# ssh-coppy-id -i ~ /.ssh/id_rsa .pub root@cluster1 ou cluster2

Puis tester la connectivité avec la commande :

# ssh cluster1 ou # ssh cluster2

Nous remarquons maintenant que ni cluster1 ni cluster2 ne demande le mot de passe.

• Installation l’outil « pdsh »:

• pdsh :
Permet à l’administrateur d’exécuter des commandes de Shell en parallèle sur un ensemble de
systèmes. Il peut utiliser remsh ou ssh pour les transferts réseau.
pdcp doit être aussi installer sur les machines cluster1 et cluster2 (paquets pdsh et pdsh-rcmd-exec).

[root@cluster1 ~]# rpm -ivh pdsh-2.18-1.i386.rpm pdsh-rcmd-exec-2.18-1.i386.rpm

Préparation... ########################################### [100%]
1:pdsh-rcmd-exec ########################################### [ 50%]
2:pdsh ########################################### [100%]

Ex:
[root@cluster0 ~]# pdsh -w cluster[1-2] hostname
cluster2: cluster2
cluster1: cluster1

Exécution de la commande hostname sur les nœuds cluster1 et cluster2 en parallèle et affichage des
résultats de la commande (commande lancée à partir de cluster0)

• pdcp :
Permet d’effectuer des copies de fichiers et de répertoires en parallèle sur un ensemble de
systèmes distants.
pdcp –w cluster1, …, clusterx /etc/hosts /etc

Ex  :

Permet de copier le fichier /etc/hosts à partir de server cluster0 vers un autre répertoire (/etc.) sur les
nœuds cluster1, …, clusterx et en parallèle.

[root@cluster0 ~]# pdcp -w cluster[1-2] /root/Desktop/Cluster0.txt / root/Desktop

Cette commande copie en parallèle dans le répertoire distant de cluster1 et cluster2 / root/Desktop le
fichier Cluster0.txt de répertoire /root/Desktop présents sur cluster0.

• dshbak :
Combiné avec pdsh pour formater et de consolider la sortie de plusieurs systèmes pour un
meilleur affichage à l’écran.

root@cluster0 ~]# pdsh -w cluster[1-2] uname|dshbak

----------------
cluster1
----------------
Linux
----------------
cluster2
----------------
Linux
Mais en utilisant la commande dshbak avec l’option « c » on aura :

[root@cluster0 ~]# pdsh -w cluster[1-2] uname|dshbak -c

----------------
cluster[1-2]
----------------
Linux

Ci-dessous il n'y a aucun changement :

[root@cluster0 ~]# pdsh -w cluster[1-2] uptime|dshbak

----------------
cluster1
----------------
01:17:49 up 2:35, 2 users, load average: 0.03, 0.02, 0.00
----------------
cluster2
----------------
23:25:38 up 5:16, 2 users, load average: 0.00, 0.00, 0.00

[root@cluster0 ~]# pdsh -w cluster[1-2] uptime|dshbak -c

----------------
cluster1
----------------
01:17:27 up 2:34, 2 users, load average: 0.04, 0.02, 0.00
----------------
cluster2
----------------
23:25:16 up 5:16, 2 users, load average: 0.00, 0.00, 0.00
 • Montage de CD-ROM et lancement automatique au démarrage

[root@cluster0 dev]# vi /etc/fstab

Ajouter la ligne suivante (le répertoire /mnt/cdrom est créé manuellement)

« /dev/cdrom /mnt/cdrom auto defaults 0 0 »
[root@cluster0 dev]# mount /dev/cdrom /mnt/cdrom/
mount: périphérique de type bloc/dev/cdrom est protégé en écriture, on le monte en lecture seulement

• root@cluster1 rpm_generation]# rpm -ivh elfutils-0.137-3.el5.i386.rpm elfutils-libs-0.137-3.el5.i386.rpm rpm-build-

4.4.2.3-9.el5.i386.rpm
• Préparation... ########################################### [100%]
• 1:elfutils-libs ########################################### [ 33%]
• 2:elfutils ########################################### [ 67%]
• 3:rpm-build ########################################### [100%]
• Serveur Cluster0 :
•
• Les paquets rpm-build elfutils elfutils-libs sont bien installés sur Cluster 1 et Cluster2
•
• root@cluster1 compilation]# rpm -ivh gcc-4.1.2-44.el5.i386.rpm glibc-devel-2.5-34.i386.rpm glibc-headers-2.5-
34.i386.rpm kernel-headers-2.6.18-128.el5.i386.rpm libgomp-4.3.2-7.el5.i386.rpm

• Préparation... ########################################### [100%]

• 1:kernel-headers ########################################### [ 20%]

• 2:libgomp ########################################### [ 40%]

• 3:glibc-headers ########################################### [ 60%]

• 4:glibc-devel ########################################### [ 80%]

• 5:gcc ########################################### [100%]

•
• [root@cluster0 distributed_shell]# rpm –i --rebuild pdsh-2.18-1.src.rpm

• [root@cluster0 SPECS]# rpmbuild -v -bb /usr/src/redhat/SPECS/pdsh.spec

• [root@cluster0 Desktop]# cd /usr/src/redhat/RPMS/

• [root@cluster0 RPMS]# ls

• athlon geode i386 i486 i586 i686 noarch

• [root@cluster0 RPMS]# cd i386/

• [root@cluster0 i386]# ls

• pdsh-2.18-1.i386.rpm pdsh-mod-netgroup-2.18-1.i386.rpm

• pdsh-mod-dshgroup-2.18-1.i386.rpm pdsh-rcmd-exec-2.18-1.i386.rpm

• pdsh-mod-machines-2.18-1.i386.rpm pdsh-rcmd-ssh-2.18-1.i386.rpm

• [root@cluster0 i386]# rpm -i pdsh-rcmd-exec-2.18-1.i386.rpm pdsh-rcmd-ssh-2.18-1.i386.rpm pdsh-2.18-1.i386.rpm

• Configuration d’un export NFS :

On crée un répertoire de montage, situé pour des tests, dans /mnt, par exemple sur la machine
cluster1 :

[root@cluster1 /]# mkdir /mnt/nfs

Puis on effectue le montage, sur le point de montage précédent, de la ressource /cluster/local (qui a
été exportée par cluster0
[root@cluster /]# mount -t nfs cluster0:/cluster/local /mnt/nfs
Le cluster1 pourra alors accéder au partage de cluster0

Syntaxe générale  :
mount -t nfs nom-machine:arborescence point-montage

On peut tester ça on mettant un fichier (ou dossier) dans /cluster/local sur le cluster0 puis de vérifier
la présence de ce fichier(ou dossier) sur le montage local de cluster1(ou cluster2).

• Sur le serveur:
Exporter les partage NFS avec des droits de lecture (ro: read only) pour les nœuds clients
[root@cluster0 ~]# vi /etc/exports
/cluster/local cluster*(ro,no_root_squash,async)
/cluster/local 192.168.0.*/255.255.0.0(ro,no_root_squash,async)
Valider les changements
[root@cluster0 ~]# export -a
[root@cluster0 ~]# touch /cluster/local/helloWorld.txt

• Sur le client:
Ajout de montage automatique de partage NFS de cluster0 dans /mnt/nfs :
Ajouter la ligne « cluster0:/cluster/local /mnt/nfsl nfs defaults 0 0 » dans le fichier /etc/fstab
[root@cluster1 nfs]# vi /etc/fstab
/dev/VolGroup00/LogVol00 / ext3 defaults 11
LABEL=/boot /boot ext3 defaults 12
tmpfs /dev/shm tmpfs defaults 00
devpts /dev/pts devpts gid=5, mode=620 0 0
sysfs /sys sysfs defaults 00
proc /proc proc defaults 00
/dev/VolGroup00/LogVol01 swap swap defaults 00
/dev/cdrom /media/cd udf,iso9660 user,noauto 0 0
cluster0:/cluster/local /mnt/nfsl nfs defaults 0 0

[root@cluster1 mnt]# mount -t nfs cluster0:/cluster/local /mnt/nfs/

[root@cluster1 mnt]# cd nfs/
[root@cluster1 nfs]# ls
[root@cluster1 nfs]# ls
helloWorld.txt
 • Test de sécurité:
Le fichier helloWorld.txt est en réalité sur le serveur Cluster0 et au moment de la configuration de
l'export il y avait un ro: lecture seule (Read only). Les nœuds clients peuvent accéder à ce fichier
dans /mnt/nfs mais ne peuvent pas le supprimer.

[root@cluster1 /]# rm /mnt/nfs/helloWorld.txt

rm: détruire un fichier protégé en écriture fichier régulier `/mnt/nfs/pdsh-mod-machines-2.18-1.i386.rpm'? y

rm: ne peut enlever `/mnt/nfs/helloWorld.txt': Système de fichiers accessible en lecture seulement.

Maintenant, on peut utiliser le partage NFS.

III.2 .3 Outils de déploiements de cluster : SystemImager

• Installation des packages systemeimager :

Installer sytemconfigurator sur cluster1

• [root@cluster1 perl_module]# rpm -i perl-AppConfig-1.66-1.el5.rf.noarch.rpm
• [root@cluster1 systemconfigurator-2.2.11-1]# rpm -i systemconfigurator-2.2.11-1.noarch.rpm

Installer systemimager-common
• [root@cluster1 systemimager-4.1.6-1]# rpm -i systemimager-common-4.1.6-1.noarch.rpm

Installer systemimager-client
• [root@cluster1 systemimager-4.1.6-1]# rpm -i systemimager-client-4.1.6-1.noarch.rpm

• Installer systemimager-i386initrd_template
• [root@cluster1 systemimager-4.1.6-1]# rpm -i systemimager-i386initrd_template-4.1.6-1.noarch.rpm
•
 • Prise d’une image golden :
• Préparation du client à prise d’une image :

Désactiver le FW de Linux et SELinux sur les nœuds.

• Sur Cluster1 :
• [root@cluster1 /]# system-config-securitylevel
• [root@cluster1 systemimager-4.1.6-1]# si_prepareclient --server 192.168.0.1
• ……..
• Continue? (y/[n]): y
• …………
• Continue? (y/[n]): y
• ………
• Your client has been successfully prepared. Boot kernel (copied from
• this Linux distribution) and an initrd.img (generated by the
• initrd_template package) can be found in /etc/systemimager/boot.
• Automatically create configuration file for systemconfigurator:
• >> /etc/systemconfig/systemconfig.conf

• Sur Cluster0:
[root@cluster0 perl_module]# rpm -i perl-AppConfig-1.66-1.el5.rf.noarch.rpm
[root@cluster0 systemconfigurator-2.2.11-1]# rpm -i systemconfigurator-2.2.11-1.noarch.rpm
Installer systemconfigurator:

[root@cluster0 systemimager-4.1.6-1]# rpm -i systemimager-common-4.1.6-1.noarch.rpm

Installer systemimager-common

[root@cluster0 perl_module]# rpm -i perl-XML-Parser-2.34-6.1.2.2.1.i386.rpm

[root@cluster0 perl_module]# rpm -i perl-XML-Simple-2.14-4.fc6.noarch.rpm
[root@cluster0 systemimager-4.1.6-1]# rpm -i systemimager-server-4.1.6-1.noarch.rpm
Arrêt de xinetd :[ OK ]
Démarrage de xinetd :[ OK ]
Installer systemimager-server
Installer systemimager-i386boot-standard
[root@cluster0 systemimager-4.1.6-1]# rpm -i systemimager-i386boot-standard-4.1.6-1.noarch.rpm

• [root@cluster0/]#si_getimage--golden-client 192.168.0.2 --image

centos_golden_client_image -post-install reboot
• This program will get the "centos_golden_client_image" system image from "192.168.0.2"
• ……………
• Continue? ([y]/n): y
• Retrieving /etc/systemimager/mounted_filesystems from 192.168.0.2 to check for
mounted filesystems...
• ------------- 192.168.0.2 mounted_filesystems RETRIEVAL PROGRESS -------------
• receiving file list ... done
• mounted_filesystems
•
• sent 142 bytes received 561 bytes 1406.00 bytes/sec
• total size is 437 speedup is 0.62
• ------------- 192.168.0.2 mounted_filesystems RETRIEVAL FINISHED -------------
• # Automatic exclusions made by SystemImager.
• Retrieving image centos_golden_client_image from 192.168.0.2
• ------------- centos_golden_client_image IMAGE RETRIEVAL PROGRESS -------------
•
• IP Address Assignment
• ---------------------
• There are three ways to assign IP addresses to the client systems on an
• ongoing basis:
•
• 1) DHCP
• 2) STATIC
• 3) REPLICANT
• ----------------------------------------------------------------
• Which method do you prefer? [1]: 1
• You have chosen method 1 for assigning IP addresses.
•
• Are you satisfied? ([y]/n): y
• Would you like to run the "si_clusterconfig" utility now? (y/[n]): n
• Récupération et configuration de l'image sur cluster0 à partir de
client gold :

• Ajouter un groupe :
[root@cluster0 /]# si_clusterconfig -e
.....
<!--
Define your custom groups below (and remember to remove
or comment the previous entries if you don't want to use
them).
...
-->
<group>
<name>TP_HPC</name>
<priority>20</priority>
<image>centos_golden_client_image</image>
 <override>centos_golden_client_image</override>
<node>cluster1,cluster2</node>
</group>

• Préparation du serveur pour déployer :

• Installation tftp, tftp-server et dhcp :
[root@cluster0 dhcp_tftp]# rpm -i tftp-0.49-2.el5.centos.i386.rpm
[root@cluster0 dhcp_tftp]# rpm -i tftp-server-0.42-3.1.el5.centos.i386.rpm
[root@cluster0 dhcp_tftp]# rpm -i dhcp-3.0.5-18.el5.i386.rpm

• Configuration de la chaine de boot pour systemimager (serveur dhcp et tftp):

[root@cluster0 /]# si_mkbootserver

WARNING: this script may modify the following files:
--> /etc/services
--> /etc/inetd.conf
--> /etc/xinetd.d/tftp
And can restart inetd, xinetd or tftp servers.
Do you wish to continue (y/[n])? y
What is the path to the pxelinux bootloader [/usr/lib/syslinux/pxelinux.0]?
Copying /usr/lib/syslinux/pxelinux.0 to /var/lib/tftpboot/X86PC/UNDI/linux-install/linux.0 ... done.

[root@cluster0 /]# si_mkdhcpserver

.............
.........
Type your response or hit <Enter> to accept [defaults]. If you don't
have a response, such as no first or second DNS server, just hit
<Enter> and none will be used.
What is your DHCP daemon major version number (2 or 3)? [3]:
What is the name of your DHCP daemon config file? [/etc/dhcpd.conf]:
What is your domain name? []:
What is your network number? [192.168.1.0]: 192.168.0.0
.............
..........
Here are the values you have chosen:
#######################################################################
ISC DHCP daemon version: 3
ISC DHCP daemon config file: /etc/dhcpd.conf
DNS domain name:
Network number: 192.168.0.0
Netmask: 255.255.255.0
Starting IP address for your DHCP range: 192.168.0.2
Ending IP address for your DHCP range: 192.168.0.254
First DNS server:
Second DNS server:
Third DNS server:
Default gateway: 192.168.0.254
Image server: 192.168.0.1
Boot server: 192.168.0.1
Log server:
Log server port:
Flamethrower directory port:
Use tmpfs staging on client: n
SSH files download URL:
####################################################################
Are you satisfied? (y/[n]): y
 • Retoucher le serveur DHCP :

[root@cluster0 /]# vi /etc/dhcpd.conf

Ajouter des nœuds clients (IP fixe) :

host cluster1{
fixed-address 192.168.0.2;
hardware ethernet 00:0C:29:43:5E:34;
option host-name "cluster1";
}

host cluster2{
fixed-address 192.168.0.3;
hardware ethernet 00:0C:29:22:07:0A;
option host-name "cluster2";
}

Redémarrage de serveur DHCP pour prendre en compte les nouvelles modifications :

[root@cluster0 /]# service dhcpd restart
Arrêt de dhcpd : [ OK ]
Démarrage de dhcpd : [ OK ]

• Déploiement d’un nœud client :

• Démarrage des services de déploiement :
[root@cluster0 /]# /etc/init.d/systemimager-server-rsyncd start
[root@cluster0 /]# vi /etc/systemimager/systemimager.conf
changer NET_BOOT_DEFAULT = net en NET_BOOT_DEFAULT = LOCAL
[root@cluster0 /]# /etc/init.d/systemimager-server-netbootmond start
Starting SystemImager's net boot client monitor: ok.
 • Déploiement du client :

[root@cluster0 /]# si_mkclientnetboot --netboot --clients cluster2

[netboot] using the kernel and initrd.img for architecture: i386
[netboot] using the flavor: standard

Après on lance la machine cluster2 qui va charger l'image de notre serveur (après
installation de l'image au login on saisi les mêmes informations de login que la machine à partir
du quelle on a créé l'image, c'est à dire cluster1).

On peut voir les échanges réseaux entre cluster0 (serveur) et nœud client (cluster2) avec
tcpdump à partir de serveur cluster0

[root@cluster0 /]# tcpdump

..............
.........
04:22:35.733056 IP cluster2.48203 > cluster0.rsync: . ack 36545177 win 45414 <nop,nop,timestamp 4294936565 22917660>
04:22:35.733065 IP cluster0.rsync > cluster2.48203: . 36546625:36548073(1448) ack 0 win 0 <nop,nop,timestamp 22917660
4294936565>
04:22:35.733105 IP cluster0.rsync > cluster2.48203: P 36548073:36549273(1200) ack 0 win 0 <nop,nop,timestamp 22917660
4294936565>
04:22:35.733153 IP cluster0.rsync > cluster2.48203: . 36549273:36550721(1448) ack 0 win 0 <nop,nop,timestamp 22917660
4294936565>
04:22:35.733188 IP cluster0.rsync > cluster2.48203: . 36550721:36552169(1448) ack 0 win 0 <nop,nop,timestamp 22917660
4294936565>
04:22:35.733379 IP cluster2.48203 > cluster0.rsync: . ack 36552169 win 45074 <nop,nop,timestamp 4294936565 22917660>
04:22:35.733391 IP cluster0.rsync > cluster2.48203: P 36552169:36553369(1200) ack 0 win 0 <nop,nop,timestamp 22917660
4294936565>
...............
..........
Capture d'image de cluster2 au moment de déploiement :

III.3 TD3 installation d’un cluster (gestion système) suite

III.3.1 Installation d'un environnement de compilation et de génération de rpm :

• Le package rpm :
Package Manager (Red Hat Package manager ou RPM) est un système de gestion de
paquets de logiciels, permet d'installer, de désinstaller, de vérifier, d'interroger et de mettre à
jour des paquets logiciels.

La compilation et l'installation des éléments suivants a été déjà traité pour le serveur Cluster0
dans la partie ci-dessus et reste à faire la même chose pour les nœuds clients Cluster1 et Cluster2,
on procèdera de la même façon que Cluster0
•
• root@cluster1 rpm_generation]# rpm -ivh elfutils-0.137-3.el5.i386.rpm elfutils-libs-0.137-3.el5.i386.rpm rpm-build-
4.4.2.3-9.el5.i386.rpm
• Préparation... ########################################### [100%]
• 1:elfutils-libs ########################################### [ 33%]
• 2:elfutils ########################################### [ 67%]
• 3:rpm-build ########################################### [100%]
• root@cluster2 rpm_generation]# rpm -ivh elfutils-0.137-3.el5.i386.rpm elfutils-libs-0.137-3.el5.i386.rpm rpm-build-
4.4.2.3-9.el5.i386.rpm
• Préparation... ########################################### [100%]
• 1:elfutils-libs ########################################### [ 33%]
• 2:elfutils ########################################### [ 67%]
• 3:rpm-build ########################################### [100%]
• rpm-build elfutils elfutils-libs sont bien installés sur Cluster 1 et Cluster2
•
• root@cluster1 compilation]# rpm -ivh gcc-4.1.2-44.el5.i386.rpm glibc-devel-2.5-34.i386.rpm glibc-headers-2.5-
34.i386.rpm kernel-headers-2.6.18-128.el5.i386.rpm libgomp-4.3.2-7.el5.i386.rpm
• Préparation... ########################################### [100%]
• 1:kernel-headers ########################################### [ 20%]
• 2:libgomp ########################################### [ 40%]
• 3:glibc-headers ########################################### [ 60%]
• 4:glibc-devel ########################################### [ 80%]
• 5:gcc ########################################### [100%]

Les paquets gcc glibc-devel glibc-headers kernel-header libgomp sont bien installés sur Cluster1 et Cluster2

III.3.2 Génération et Installation d'un outil sécurisé : munge

Munge est un service d'authentification pour la création et la validation des pouvoirs. Il
Permet à un processus d'authentifier l'UID et GID d'un autre processus local ou distant dans un
groupe d'hôtes ayant usagers et des groupes. Ces hôtes forment un domaine de sécurité qui est
défini par une clé partagée cryptographiques.

• III.3.2.1. Génération du produit munge :

a) Installation des pré-requis à la compilation de munge :

Installation des paquets OPENSSL, KRB5, ZLIB, E2FSPROGS, KEYUTILS, LIBSELINUX, et LIBSEPOL
[root@cluster0 crypto_ssl]# rpm -ivh openssl-devel-0.9.8e-7.el5.i386.rpm krb5-devel-1.6.1-31.el5.i386.rpm zlib-devel-1.2.3-
3.i386.rpm e2fsprogs-devel-1.39-20.el5.i386.rpm keyutils-libs-devel-1.2-1.el5.i386.rpm libselinux-devel-1.33.4-5.1.el5.i386.rpm
libsepol-devel-1.15.2-1.el5.i386.rpm
Préparation... ########################################### [100%]
1:libsepol-devel ########################################### [ 14%]
2:libselinux-devel ########################################### [ 29%]
3:keyutils-libs-devel ########################################### [ 43%]
4:e2fsprogs-devel ########################################### [ 57%]
5:zlib-devel ########################################### [ 71%]
:krb5-devel ########################################### [ 86%]
7:openssl-devel ########################################### [100%]

Même chose sur Cluster1 et Cluster2

 b) Compilation de munge :
Compilation et génération des paquets rpms installables à partir du package source (les
rpms installables seront dans le répertoire /usr/src/redhat/RPMS/i386)
[root@cluster0 munge.0.5.8]# rpmbuild --rebuild munge-0.5.8-1.src.rpm
[root@cluster0 munge.0.5.8]# cd /usr/src/redhat/RPMS/i386/
[root@cluster0 i386]# ls
munge-0.5.8-1.i386.rpm pdsh-mod-machines-2.18-1.i386.rpm
munge-devel-0.5.8-1.i386.rpm pdsh-mod-netgroup-2.18-1.i386.rpm
munge-libs-0.5.8-1.i386.rpm dsh-rcmd-exec-2.18-1.i386.rpm
pdsh-2.18-1.i386.rpm pdsh-rcmd-ssh-2.18-1.i386.rpm
pdsh-mod-dshgroup-2.18-1.i386.rpm

III.3.2.2. Installation et configuration de munge

• Installation de munge :
• [root@cluster0 i386]# rpm -ivh munge-0.5.8-1.i386.rpm munge-devel-0.5.8-1.i386.rpm munge-
libs-0.5.8-1.i386.rpm
• Préparation... ########################################### [100%]
• 1:munge-libs ########################################### [ 33%]
• 2:munge ########################################### [ 67%]
• 3:munge-devel ########################################### [100%]
• Le server Cluster 0

Les paquets munge, mung-devel, et mung-libs ont été bien installés

• Les nœuds clients:

[root@cluster1 i386]# rpm -ivh munge-0.5.8-1.i386.rpm munge-devel-0.5.8-1.i386.rpm munge-libs-0.5.8-1.i386.rpm
Préparation... ########################################### [100%]
1:munge-libs ########################################### [ 50%]
2:munge ########################################### [ 100%]

Les paquets munge, et mung-libs ont été bien installés

• Configuration de munge :
Génération de la clé de cryptage avec la commande dd :

[root@cluster0 /]# dd if=/dev/urandom of=/etc/munge/munge.key bs=1 count=1024

1024+0 enregistrements lus
1024+0 enregistrements écrits
1024 octets (1,0 kB) copiés, 0,0207986 seconde, 49,2 kB/s 1:mun$
Synchronisation de la clé créée munge.key sur les nœuds client Cluster1 et Cluster2, pou cela on
utilise la commande pdcp.

[root@cluster0 ~]# pdcp –w cluster[1-2] /etc/munge/munge.key /etc/munge/

A présent la clé munge.key est présentée sur Cluster0(le serveur), Cluster1 et Cluster2 (clients).

Démarrage de nouveau service installé munge, vérification de son statut et vérification de

l'enregistrement de service pour le démarrage automatique à chaque boot.

[root@cluster0 ~]# service munge start

Starting MUNGE:
[root@cluster0 ~]# service munge status
munged (pid 3814) en cours d'exécution...
[root@cluster0 ~]# chkconfig --list munge
munge 0:arrêt 1:arrêt 2:arrêt 3:marche4:marche 5:marche6:arrêt

Donc munge est lancé automatiquement au boot de système avec les niveaux (runlevel)
35
Il existe 5 niveaux importants de runlevel :
- runlevel 0 : appelé lors de l'arrêt du système,
- runlevel 1 : appelé lorsque le système démarre en mono-utilisateur,
- runlevel 2 : correspond au mode de démarrage normal (sans NFS)
- runlevel 3 : appelé lorsque le système démarre en multiutilisateur (en réseau, NFS),
- runlevel 4 : non utilisé,
- runlevel 5 : appelé lorsque le système démarre en multiutilisateur, mode graphique,
- runlevel 6 : appelé lorsque le système reboote.

III.3.3 Génération et Installation du gestionnaire de ressource SLURM :

Slurm : est un gestionnaire de ressource, utilise préférentiellement l'outil « munge » pour
sécuriser ses communications. Il dispose d'un gestionnaire centralisé, slurmctld, pour surveiller les
ressources et le travail. Il peut aussi être un gestionnaire de sauvegarde pour assumer ces
responsabilités en cas d'échec.

III.3.3.1. Génération du produit slurm :

• Installation des pré-requis à la compilation de SLURM :

root@cluster0 slurm_compilation_require]# rpm -ivh libtermcap-devel-2.0.8-46.1.i386.

rpm readline-devel-5.1-1.1.i386.rpm
Préparation... ########################################### [100%]
1:libtermcap-devel ########################################### [ 50%]
2:readline-devel ########################################### [100%]
[root@cluster0 slurm_compilation_require]# rpm -ivh pam-devel-0.99.6.2-4.el5.i386.rpm
Préparation... ########################################### [100%]
1:pam-devel ########################################### [100%]

• Compilation de SLURM :

[root@cluster0 slurm]# ls
slurm-2.0.8.tar.bz2
Copie de slurm-2.0.8.tar.bz2 dans /usr/src/redhat/SOURCES/
[root@cluster0 slurm]# cp slurm-2.0.8.tar.bz2 /usr/src/redhat/SOURCES/

Accès au répertoire :

[root@cluster0 slurm]# cd /usr/src/redhat/SOURCES/

[root@cluster0 SOURCES]# ls
pdsh-2.18 pdsh-2.18.tar.bz2 slurm-2.0.8.tar.bz2

Compilation et génération des paquets rpm installable à partir de l'archive source :

[root@cluster0 SOURCES]# rpmbuild -ta /usr/src/redhat/SOURCES/slurm-2.0.8.tar.bz2

l'option ta est utlisée pour les paquets source compréssés.

La commande ci-dessus génère les paquets installable suivants dans le répertoire

/usr/src/redhat/RPMS/i386/:

slurm-2.0.8-1.i386.rpm, slurm-devel-2.0.8-1.i386.rpm, slurm-munge-2.0.8-1.i386.rpm, slurm-perlapi-2.0.8-1.i386.rpm, slurm-

plugins-2.0.8-1.i386.rpm, slurm-slurmdbd-2.0.8-1.i386.rpm, slurm-slurmdb-direct-2.0.8-1.i386.rpm, et slurm-torque-2.0.8-
1.i386.rpm

III.3.3.2. Installation et configuration de SLURM :

• Installation des packages SLURM :

Les packages slurm, slurm-plugins et slurm-munge seront installés sur l'ensemble des nœuds de cluster
(Cluster0, Cluster1, et Cluster2). Et comme Cluster0 possède les rpms installables on fait:

[root@cluster0 i386]# pdccp –r –w cluster[1-2 /usr/src/redhat/RPMS/i386/slurm-* /usr/src/redhat/RPMS/i386/

slurm-2.0.8-1.i386.rpm 100% 24MB 12.0MB/s 00:02
slurm-devel-2.0.8-1.i386.rpm
slurm-munge-2.0.8-1.i386.rpm
slurm-perlapi-2.0.8-1.i386.rpm
slurm-plugins-2.0.8-1.i386.rpm
slurm-slurmdbd-2.0.8-1.i386.rpm
slurm-slurmdb-direct-2.0.8-1.i386.rpm
slurm-torque-2.0.8-1.i386.rpm
100% 1273KB 1.2MB/s 00:00
100% 16KB 16.3KB/s 00:00
00% 189KB 188.5KB/s 00:00
100% 653KB 652.9KB/s 00:00
100% 918KB 918.2KB/s 00:00
100% 5941 5.8KB/s 00:00
100% 14KB 14.4KB/s 00:00

Sur chaque nœud (ClusterX est Cluster1 et Cluster2)

Installer les rpm slurm sur CLuster0, Cluster1, et Cluster2 :

[root@cluster0 i386]# rpm -ivh slurm-2.0.8-1.i386.rpm slurm-plugins-2.0.8-1.i386.rpm

slurm-munge-2.0.8-1.i386.rpm
Préparation... ########################################### [100%]
1:slurm-plugins ########################################### [ 33%]
2:slurm ########################################### [ 67%]
You need to build and install a slurm.conf file
Edit /etc/slurm/slurm.conf.example and copy it to slurm.conf or
Build a new one using http://www.llnl.gov/linux/slurm/configurator.html
3:slurm-munge ########################################### [100%]

• Configuration de SLURM :
Copier le fichier de l'exemple de configuration de slurm « slurm.conf. exemple » en « slurm.conf » :
•
• [root@cluster0 i386]# cp /etc/slurm/slurm.conf.example /etc/slurm/slurm.conf
•
Modifier le contenu de fichier slurm.conf (que dans les parties signalées):
•
• [root@cluster0 i386]# vi /etc/slurm/slurm.conf
• ControlMachine=cluster0
• #ControlAddr=
• #BackupController=
• #BackupAddr=
• SlurmUser=root
• #SlurmdUser=root
•
•
•
•
•
•
•
•
•

• Et à la fin de fichier on modifie :

•
• # COMPUTE NODES
• NodeName=cluster[1-2]
• PartitionName=compute Nodes=cluster[1-2]
•

Synchronisation de fichier slurm.conf sur l'ensemble des nœuds (Cluster1 et Cluster2), les clusters
doivent avoir le même fichier de configuration slurm.conf
•
• [root@cluster0 i386]# pdcp –w cluster[1-2] /etc/slurm/slurm.conf /etc/slurm/
• slurm.conf 100% 1870 1.8KB/s 00:00
•

Maintenant, le démarrage de service slurm sur l'ensemble des nœuds de l'architecture de cluster :
• [root@cluster0 i386]# service slurm start
• starting slurmctld: [ OK ]
• [root@cluster0 i386]# pdsh –w cluster[1-2] service slurm start
• starting slurmctld: [ OK ]

• III.3.3.3. Utilisation de slurm :

Pour afficher le statut des ressources on utilise la commande sinfo:
•
• [root@cluster0 i386]# sinfo
• PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
• compute up infinite 2 unk* cluster[1-2]
•

Pour la mise à jour de l'état des nœuds on utilise la commande scontrol qui est utilisé pour voir et
modifier l'état et la configuration de Slurm :
•
• [root@cluster0 i386]# scontrol update NodeName=cluster[1-2] state=IDLE
• [root@cluster0 i386]# sinfo
• PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
• compute up infinite 2 idle* cluster[1-2]
•

Changement d'état des nœuds d’unk (UNKNOWN) à IDLE. Autres valeurs possibles de state:
"NoResp", "ALLOC", "ALLOCATED", "DOWN", "DRAIN", "FAIL", "FAILING",
"MAINT", "POWER_DOWN", "POWER_UP", ou "RESUME"
•
La commande srun de slurm permet d'exécutera un job en parallèle sur le cluster géré par
SLURM.
Etant donné que la configuration initiale est opérationnelle, on utilisera quelque service
offrent pas SLURM :
•
• Soumettre une tache avec srun:
Demander le hostname de chaque nœud :

• [root@cluster0 i386]# srun hostname

• srun: Requested partition configuration not available now
• srun: job 25 queued and waiting for resources
• [root@cluster0 i386]# srun -N1 -l --mincpus=1 -t1 hostname
• mincpus =1 spécifie le nombre minimum des cpu par noeud.

E pour voir l’état des jobs dans la file des jobs « scheduler »
• [root@cluster0 i386]# squeue
• JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
• 37 debug hostname root R 0:11 1 cluster1
•
• [root@cluster0 i386]# squeue -v
• -----------------------------
• all = false
• format = (null)
• iterate = 0
• job_flag = 0
• jobs = (null)
• max_procs = 1
• nodes =
• partitions = (null)
• sort = (null)
• states = (null)
• step_flag = 0
• steps = (null)
• users = (null)
• verbose = 1
• -----------------------------
• Wed May 26 18:46:20 2010
• JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
• 37 debug hostname root R 0:08 1 cluster1
 • Voir les informations de la partition debug :
• [root@cluster0 i386]# scontrol show hostnames cluster[1-2]
• cluster1
• cluster2
•
• [root@cluster0 i386]# scontrol
• scontrol: show part debug
• PartitionName=debug TotalNodes=2 TotalCPUs=2 RootOnly=NO
• Default=YES Shared=NO Priority=1 State=UP MaxTime=UNLIMITED Hidden=NO
• MinNodes=1 MaxNodes=UNLIMITED DisableRootJobs=NO AllowGroups=ALL
• AllocNodes=ALL
• Nodes=cluster[1-2] NodeIndices=0-1 DefaultTime=NONE
•

• Mise à jour avec scontrol:

• scontrol: update PartitionName=debug MaxTime=60:00 MaxNodes=4
• scontrol: show part debug
• PartitionName=debug TotalNodes=2 TotalCPUs=2 RootOnly=NO
• Default=YES Shared=NO Priority=1 State=UP MaxTime=01:00:00 Hidden=NO
• MinNodes=1 MaxNodes=4 DisableRootJobs=NO AllowGroups=ALL
• AllocNodes=ALL
• Nodes=cluster[1-2] NodeIndices=0-1 DefaultTime=NONE
•
• scontrol: show hostnames cluster[1-2]
• cluster1
• cluster2
III.4 TD4 installation d’un cluster : Système de fichier parallèle LUSTRE 

Le nœud serveur cluster0 gèrera les métadonnées du système de fichier. Il sera le nœud
MDS (Metadata Server) et MGS (Management Server).

Le nœud cluster1 gèrera les données du système de fichier. Il sera un nœud OSS (Object
Storage Server).

Enfin, le nœud cluster2 sera un client Lustre et montera le système de fichier.

III.4.1 Préparation des nœuds :

III.4.1.1 Installation des paquets nécessaires :

Sur les nœuds serveurs lustre (cluster0 et cluster1), les paquets suivants seront nécessaires :
• kernel-lustre-smp: noyau linux « patché » pour lustre
• lustre-module: module lustre pour un nœud « patché »
• lustre: outils de configuration
• lustre-ldiskfs: système de fichier support (ext3 optimisé pour lustre)
• e2fsprogs: outils de manipulation du système de fichier support optimisé

• Sur cluster0 et cluster1:

[root@cluster0 lustre]# rpm --force -ivh e2fsprogs-1.39-23.el5.i386.

rpm e2fsprogs-libs-1.39- 23.el5.i386.rpm
Préparation... ########################################## [100%]
1:e2fsprogs-libs ########################################### [ 50%]
2:e2fsprogs ########################################### [100%]

[root@cluster0 /]# cd /mnt/cdrom/lustre/

[root@cluster0 /]# rpm -ivh kernel-lustre-smp-2.6.18-8.1.14.el5_lustre.1.6.3.i686.rpm lustre-modules-1.6.3-
2.6.18_8.1.14.el5_lustre.1.6.3smp.i686.rpm lustre-1.6.3-2.6.18_8.1.14.el5_lustre.1.6.3smp.i686.rpm lustre-ldiskfs-3.0.2-
2.6.18_8.1.14.el5_lustre.1.6.3smp.i686.rpm

• Sur le cluster2 :

[root@cluster2 /]# mount /dev/cdrom /mnt/cdrom/

mount:périphérique de type bloc /dev/cdrom est protégé en écriture, on le monte en lecture
seulement.

[root@cluster2 /]# cd /mnt/cdrom/

[root@cluster2 cdrom]# cd lustre/

[root@cluster2 lustre]# ls

e2fsprogs-1.39-23.el5.i386.rpm

e2fsprogs-libs-1.39-23.el5.i386.rpm

kernel-lustre-smp-2.6.18-8.1.14.el5_lustre.1.6.3.i686.rpm

lustre-1.6.3-2.6.18_8.1.14.el5_lustre.1.6.3smp.i686.rpm

lustre-ldiskfs-3.0.2-2.6.18_8.1.14.el5_lustre.1.6.3smp.i686.rpm

lustre-modules-1.6.3-2.6.18_8.1.14.el5_lustre.1.6.3smp.i686.rpm

[root@cluster2 lustre]# rpm -ivh kernel-lustre-smp-2.6.18-8.1.14.el5_lustre.1.6.3.i686.rpm lustre-modules-1.6.3-

2.6.18_8.1.14.el5_lustre.1.6.3smp.i686.rpm lustre-1.6.3-2.6.18_8.1.14.el5_lustre.1.6.3smp.i686.rpm

III.4.1.2 Création des espaces nécessaires :

Sur cluster0 MDS on crée le fichier mds avec plus de 100 Méga dans le répertoire créé /mnt/lustre

[root@cluster0 /]# mkdir /mnt/lustre

[root@cluster0 /]# dd if=/dev/zero of=/mnt/lustre/mds bs=1M count=100
100+0 enregistrements lus
100+0 enregistrements écrits
104857600 octets (105 MB) copiés, 1,46028 seconde, 71,8 MB/s

Même chose pour cluster1 OSS :

[root@cluster1 /]# mkdir /mnt/lustre

[root@cluster1 /]# dd if=/dev/zero of=/mnt/lustre/oss bs=1M count=100
100+0 enregistrements lus
100+0 enregistrements écrits
104857600 octets (105 MB) copiés, 0,839672 seconde, 125 MB/sd
Maintenant avec ces deux fichiers on le simulera avec la commande losetup:
• « losetup -a » pour lister les devices,
• « losetup -f fichier » pour installer un fichier en tant que device,
• « losetup -d loop_device » pour arrêter une device.*
• « losetup loop_device » pour voir plus d'information sur la device
• « losetup -r » lecture seule

• Sur cluster0 MDS on fait:

[root@cluster0 /]# losetup -f /mnt/lustre/mds
[root@cluster0 /]# losetup -a
/dev/loop0: [fd00]:1136243 (/mnt/lustre/mds)

• Sur cluster1 OSS on fait:

[root@cluster1 /]# losetup -f /mnt/lustre/oss
[root@cluster1 lustre]# losetup -a
/dev/loop0: [fd00]:226693 (/mnt/lustre/oss)

III.4.2 Installation de la configuration Lustre :

III.4.2 .1 Installation du serveur de métadonnée et activation :

Au sein de notre configuration simple, cluster0 mutualisera les fonctions de serveur de

métadonnées (MDS) et de serveur de configuration (MGS).
Formater la device de métadonnée ou MDT, MetaData Target sur le nœud serveur MDS,
MetaData Server :
mkfs.lustre --fsname=<fsname> --mgs --mdt <block device name>

Le champ <fsname> : sert tout au long de la configuration à identifier globalement tous les
composants d'un même système de fichier.
mkfs.lustre : formater un disque pour un service Lustre

• Sur cluster0 :

[root@cluster0 ~]# losetup -a

/dev/loop0: [fd00]:1136315 (/mnt/lustre/mds)

On s'assure que ldiskfs est chargé avec la commande.

[root@cluster0 ~]# modprobe ldiskfs :

Et en sortie on doit rien avoir (sinon message d'erreur).
Si il ya erreur vérifier que notre système a été booté avec le kernel de lustre pour vérifier ca on
tape:

[root@cluster0 ~]# uname -a

Linux cluster0 <version kernel>.el5_lustre<version Lustre>smp #1 SMP Sun Oct 7 20:29:00 EDT 2007 i686 i686 i386
GNU/Linux

Si on n’a pas ça donc il faut redémarrer avec le kernel-lustre ou bien modifier le contenu de
fichier de démarrage dans:

[root@cluster0 ~]# vi /boot/grub/menu.lst

Laisser la ligne de kernel-lustre et mettre la ligne de l'ancien kernel en commentaire (précéder avec
#), il faut faire aussi attention à l'option default

[root@cluster0 ~]# mkfs.lustre --fsname=lustre --mgs --mdt /dev/loop0

Permanent disk data:
Target: lustre-MDTffff
Index: unassigned
Lustre FS: lustre
Mount type: ldiskfs
Flags: 0x75 (MDT MGS needs_index first_time update )
Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr
Parameters:
checking for existing Lustre data: not found
device size = 100MB
formatting backing filesystem ldiskfs on /dev/loop0
target name lustre-MDTffff
4k blocks 0
options -i 4096 -I 512 -q -O dir_index -F
mkfs_cmd = mkfs.ext2 -j -b 4096 -L lustre-MDTffff -i 4096 -I 512 -q -O dir_index -F /dev/loop0
Writing CONFIGS/mountdata
On lance maintenant la commande :

Si la device était déjà formaté pour lustre on ajoute à la ligne l'option « --reformat»
Démarrer le MDT sur le nœud MDS :
mount -t lustre <block device name> <mount point>

Pour activer le serveur de métadonnée, on fait :

[root@cluster0 ~]# mount -t lustre /dev/loop0 /mnt/lustre

III.4.2 .2 Installation d'un serveur de donnée et activation :

Au sein de notre configuration, cluster1 remplit le rôle d'un serveur de donnée, OSS Object
Storage Server, hébergeant un OST, Object Storage Target.
Formater la device de donnée OST :
mkfs.lustre --fsname=<fsname> --mgsnode=<nid> --ost <block device name>

Le champ <nid> (Network Identifier) permet d'identifier le serveur de configuration ou MGS.

Ainsi, le composant de donnée OST lorsqu'il est démarré peut intégrer globalement la
configuration Lustre correspondant au nom <fsname> sur le nœud MGS correspondant à ce <nid>.
Lustre est compatible avec beaucoup de technologie réseau différentes. Le champ <nid> est
suffisamment plastique pour correspondre à tous ces nommages. Ici, dans notre cas, il s'agit
simplement de l'adresse IP de notre serveur MGS (cluster0).

On utilise donc la commande suivante:

mkfs.lustre --fsname=lustre --mgsnode=192.168.0.1 --ost /dev/loop0

Pour cela on fait:

[root@cluster1 ~]# losetup -a
/dev/loop0: [fd00]:226693 (/mnt/lustre/oss)
[root@cluster1 ~]# mkfs.lustre --fsname=lustre --mgsnode=192.168.0.1 --ost /dev/loop0

Permanent disk data:

Target: lustre-OSTffff
Index: unassigned
Lustre FS: lustre
Mount type: ldiskfs
Flags: 0x72
(OST needs_index first_time update )

Persistent mount opts: errors=remount-ro,extents,mballoc

Parameters: mgsnode=192.168.0.1@tcp
checking for existing Lustre data: not found
device size = 100MB
formatting backing filesystem ldiskfs on /dev/loop0
target name lustre-OSTffff
4k blocks 0
options -I 256 -q -O dir_index -F
mkfs_cmd = mkfs.ext2 -j -b 4096 -L lustre-OSTffff -I 256 -q -O dir_index -F /dev/loop0
Writing CONFIGS/mountdata

Démarrer la device OST sur le nœud OSS :

mount -t lustre <block device name> <mount point>

On lance la device OST sur le nœud OSS (cluster1) :

[root@cluster1 ~]# mount -t lustre /dev/loop0 /mnt/lustre/

III.4.2 .3 Montage sur le nœud client :

Notre configuration minimaliste lustre est désormais opérationnelle. Elle est prête à être
montée sur le nœud client, cluster2 :
mount -t lustre <mgs node nid>:/<fsname> <mount point>

Pour le montage donc on exécutera la commande suivante (mount) sur le client (nœud cluster2) :
[root@cluster2 ~]# mkdir /mnt/lustre
[root@cluster2 ~]# mount -t lustre 192.168.0.1:/lustre /mnt/lustre/

III.4.3 Exploration des fonctionnalités annexes

• [root@cluster1 mnt]# losetup -a
• /dev/loop0: [fd00]:226693 (/mnt/lustre/oss)
• [root@cluster1 mnt]# mkdir /mnt/lustre2
• [root@cluster1 mnt]# dd if=/dev/zero of=/mnt/lustre2/oss bs=1M count=100
• [root@cluster1 mnt]# losetup -f /mnt/lustre2/oss
• [root@cluster1 mnt]# losetup -a
 • /dev/loop0: [fd00]:226693 (/mnt/lustre/oss)
• /dev/loop1: [fd00]:226695 (/mnt/lustre2/oss)
• [root@cluster1 mnt]# mkfs.lustre --fsname=lustre --mgsnode=192.168.0.1 --ost /dev/loop1
• Permanent disk data:
• Target: lustre-OSTffff
• Index: unassigned
• Lustre FS: lustre
• Mount type: ldiskfs
• Flags: 0x72
• (OST needs_index first_time update )
• Persistent mount opts: errors=remount-ro,extents,mballoc
• Parameters: mgsnode=192.168.0.1@tcp
• checking for existing Lustre data: not found
• device size = 100MB
• formatting backing filesystem ldiskfs on /dev/loop1
• target name lustre-OSTffff
• 4k blocks 0
• options -I 256 -q -O dir_index -F
• mkfs_cmd = mkfs.ext2 -j -b 4096 -L lustre-OSTffff -I 256 -q -O dir_index -F /dev/loop1
• Writing CONFIGS/mountdata
• Créer un deuxième ost sur le nœud cluster1 :

Et puis, activation d’OST:

[root@cluster1 /]# mount -t lustre /dev/loop1 /mnt/lustre2/

• Gérer les politiques de stripping :

• Positionner un quota : « lfs getstripe [...] »:

La commande "lfs getstripe" liste des informations formatées pour un fichier donné ou pour
des fichiers dans un répertoire ou tout simplement les fichiers d'une arborescence.

Sur le client (nœud cluster2) on exécute la commande:

[root@cluster2 ~]# lfs getstripe /mnt/lustre
OBDS:
0: lustre-OST0000_UUID ACTIVE
1: lustre-OST0001_UUID ACTIVE
/mnt/lustre has no stripe info
Et on voit bien qu'on a deux OST

• consulter un quota : « lfs setstripe [...] »  :

[root@cluster2 ~]# lfs setstripe -s 4M /mnt/lustre

[root@cluster2 ~]# lfs getstripe /mnt/lustre
OBDS:
0: lustre-OST0000_UUID ACTIVE
1: lustre-OST0001_UUID ACTIVE
/mnt/lustre
default stripe_count: 0 stripe_size: 4194304 stripe_offset: -1

[root@cluster2 ~]# lfs df -h

UUID bytes Used Available Use% Mounted on
lustre-MDT0000_UUID 87.5M 9.2M 78.3M 10% /mnt/lustre[MDT:0]
lustre-OST0000_UUID 93.7M 9.3M 84.4M 9% /mnt/lustre[OST:0]
lustre-OST0001_UUID 93.7M 9.3M 84.4M 9% /mnt/lustre[OST:1]
filesystem summary: 187.5M 18.6M 168.8M 9% /mnt/lustre

Création d'un fichier sur le client cluster2:

[root@cluster2 ~]# dd if=/dev/zero of=/mnt/lustre/testdb bs=1M count=50

50+0 enregistrements lus
50+0 enregistrements écrits
52428800 octets (52 MB) copiés, 2,48491 seconde, 21,1 MB/s000_UUIJ
Pour avoir des informations sur le fichier créé, on fait :

[root@cluster2 ~]# lfs getstripe /mnt/lustre/testdb

OBDS:
0: lustre-OST0000_UUID ACTIVE
1: lustre-OST0001_UUID ACTIVE
/mnt/lustre/testdb
obdidx objid objid group
1 2 0x2 0

Répartition de la taille de fichier créé par le client sur le nœud cluster2 de 50 mégaoctets sur
l'architecture :
[root@cluster2 ~]# lfs df -h
UUID bytes Used Available Use% Mounted on
lustre-MDT0000_UUID 87.5M 9.2M 78.3M 10% /mnt/lustre[MDT:0]
lustre-OST0000_UUID 93.7M 9.3M 84.4M 9% /mnt/lustre[OST:0]
lustre-OST0001_UUID 93.7M 59.3M 34.4M 63% /mnt/lustre[OST:1]
filesystem summary: 187.5M 68.6M 118.8M 36% /mnt/lustre

• Gérer les quotas :

Lustre possède deux types de fichier quota:

• Administrative quotas (pour MDT), qui contient les limites pour les utilisateurs et les
groupes de cluster.

• Opérationnel quotas (pour MDT et OST), qui contient les informations de quota dédié à
un nœud de cluster.

Configuration :
▪ Au formatage : mkfs.lustre --param mdt.quota_type=ug ug: user/group

• Sur le MDT cluster0 :

[root@cluster0 ~]# umount /mnt/lustre/

[root@cluster0 ~]# mkfs.lustre --reformat --fsname lustre --mdt --mgs --param mdt.quota_type=ug /dev/loop0

Permanent disk data:

Target: lustre-MDTffff
Index: unassigned
Lustre FS: lustre
Mount type: ldiskfs
Flags: 0x75
(MDT MGS needs_index first_time update )
Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr
Parameters: mdt.quota_type=ug
device size = 100MB
formatting backing filesystem ldiskfs on /dev/loop0
target name lustre-MDTffff
4k blocks 0
options -i 4096 -I 512 -q -O dir_index -F
mkfs_cmd = mkfs.ext2 -j -b 4096 -L lustre-MDTffff -i 4096 -I 512 -q -O dir_index -F /dev/loop0
Writing CONFIGS/mountdata

• Sur le OST cluster1 :

[root@cluster1 /]# mkfs.lustre --reformat --fsname=lustre --mgsnode=192.168.0.1 --ost /dev/loop0
Permanent disk data:
Target: lustre-OSTffff
Index: unassigned
Lustre FS: lustre
Mount type: ldiskfs
Flags: 0x72
(OST needs_index first_time update )
Persistent mount opts: errors=remount-ro,extents,mballoc
Parameters: mgsnode=192.168.0.1@tcp
device size = 100MB
formatting backing filesystem ldiskfs on /dev/loop0
target name lustre-OSTffff
4k blocks 0
options -I 256 -q -O dir_index -F
mkfs_cmd = mkfs.ext2 -j -b 4096 -L lustre-OSTffff -I 256 -q -O dir_index -F /dev/loop0
Writing CONFIGS/mountdata
[root@cluster1 /]# umount /mnt/lustre2
[root@cluster1 /]# mkfs.lustre --reformat --fsname=lustre --mgsnode=192.168.0.1 --ost /dev/loop1
Permanent disk data:
Target: lustre-OSTffff
Index: unassigned
Lustre FS: lustre
Mount type: ldiskfs
Flags: 0x72
(OST needs_index first_time update )
Persistent mount opts: errors=remount-ro,extents,mballoc
Parameters: mgsnode=192.168.0.1@tcp
device size = 100MB
formatting backing filesystem ldiskfs on /dev/loop1
target name lustre-OSTffff
4k blocks 0
options -I 256 -q -O dir_index -F
mkfs_cmd = mkfs.ext2 -j -b 4096 -L lustre-OSTffff -I 256 -q -O dir_index -F /dev/loop1
Writing CONFIGS/mountdata
[root@cluster1 /]# mount -t lustre /dev/loop0 /mnt/lustre/
[root@cluster1 /]# mount -t lustre /dev/loop1 /mnt/lustre2/

• Sur le client cluster2 :

[root@cluster2 /]# mount -t lustre 192.168.0.1:/lustre /mnt/lustre/
[root@cluster2 /]# lfs quotacheck -ug /mnt/lustre
[root@cluster2 /]# lfs quotaon -ug /mnt/lustre/
[root@cluster2 /]# lfs setquota -t 30720 30920 /mnt/lustre
Les informations quota pour l'utilisateur root
[root@cluster2 /]# lfs quota -u root /mnt/lustre
Disk quotas for user root (uid 0):
Filesystem kbytes quota limit grace files quota limit grace
/mnt/lustre 604 0 0 21 0 0
lustre-MDT0000_UUID 140 0 0 21 0 0
lustre-OST0000_UUID 232 0 0
lustre-OST0001_UUID 232 0 0

[root@cluster2 /]# lfs quota -t -u /mnt/lustre

Block grace time: 08:32; Inode grace time: 08:35
[root@cluster2 /]# lfs setquota -u bob 307200 309200 10000 11000 /mnt/lustre
error: find id for name bob failed: No such file or directory
Set filesystem quotas.
usage: setquota [ -u | -g ] <name> <block-softlimit> <block-hardlimit> <inode-softlimit> <inode-hardlimit> <filesystem>
setquota -t [ -u | -g ] <block-grace> <inode-grace> <filesystem>
[root@cluster2 /]# lfs setquota -u root 30720 30920 1000 100 /mnt/lustre[root@cluster2 /]# lfs quota -u root /mnt/lustre
Disk quotas for user root (uid 0):
Filesystem kbytes quota limit grace files quota limit grace
/mnt/lustre 608 30720 30920 21 1000 100
lustre-MDT0000_UUID 144* 0 1 21* 0 1
lustre-OST0000_UUID 232* 0 1
lustre-OST0001_UUID 232* 0 1

Arrêt : « lfs quotaoff »

[root@cluster2 /]# lfs quotaoff /mnt/lustre/

IV. Conclusion Générale:

Ces travaux dirrigés nous ont permis de comprendre les techniques utilisés pour
l’implementation de la programmation paralléle; Threads, OPENMP, MPI en utilisant le langage
de programation C. Aussi on a pus aborder la notion de Cluster et de manipuler les outils
necessaire pour l’adminnistration des cluster (pdsh, SystemImager, rpm, munge, Slurm, Lustre).

Les Tps qu’on a fait nous ont été très utiles pour voir et comprendre la façon dont un
système informatique distribué et complexe, est installé, configuré et géré et de tirer profit de
toutes formes de ressource existante sur le matériel, logiciel, dans desi réseaux afin d’augmenter
la puissance de calcul et capacie de stockage. Notre réalisation est surtout basée sur des éléments
de cours et des ressources internet, cela ne nous a pas empêché à vouloir savoir plus sur un
domaine à la pointe, qui nécessite beaucoup de qualité de rigueur, et nous espérons que nous
avons développés certaines qualités en gestion et administration système.

La réalisation des projets nous a donnée une idée sur l’informatique de nuage (Cloud
Computing) qui est actuellement un concept de plus en plus répondu, où les données sont
distribuées, la puissance de calcul et l’espace de stockage sont offerts selon la demande. On
cherche plus où sont nos données physiquement ou quel processeurs utilise-t-on, l’essentiel c’est
de pouvoir y accéder à tout moment.

Bibliographie :

• Les brochures de TP
• Cours « Grille et Cluster » de Patrice Lucas
• Outils pdsh http://sourceforge.net/projects/pdsh/
• Site officiel de SystemImager http://wiki.systemimager.org
• Slurm https://www.scorec.rpi.edu/wiki/SLURM
• Site officiel de Lustre http://wiki.lustre.org/index.php
• Manuel Lustre http://wiki.lustre.org/manual/
• Site « Oracle-Sun » pour Lustre https://cds.sun.com
• Manuel Linux pour les commandes système