UNIVERSITE ABDEL MALEK ESSAADI FACULTE DES

SCIENCES ET TECHNIQUES DE TANGER

PROJET DE FIN DE MODULE :

CALCUL PARALLELE ET APPLICATIONS DISTRIBUEES

Encadré par :
Pr. Chaker EL AMRANI

Réalisé par :
TALBI Ibrahim
Table des matières

1. Introduction : ......................................................................................................................................... 3
2. Prérequis : ............................................................................................................................................. 3
3. Configuration initiale de réseau : .......................................................................................................... 3
4. Installation de HTcondor : ..................................................................................................................... 8
5. Configuration l’authentification SSH : ................................................................................................. 13
6. Configuration de partage NFS : ........................................................................................................... 17
7. Tester l’infrastructure de notre cluster : ............................................................................................. 20
8. Soumission de jobs : ............................................................................................................................ 20
9. Conclusion : ......................................................................................................................................... 25
1. Introduction :

En informatique, le parallélisme consiste à mettre en œuvre des architectures permettant de

traiter des informations de manière simultanée, ainsi que les algorithmes spécialisés pour celles-
ci. Ces techniques ont pour but de réaliser le plus grand nombre d'opérations en un temps le
plus petit possible.

Afin de pouvoir étudier la programmation parallèle, il faut tout d'abord créer un cluster de
machines capable de fonctionner en parallèle. Le but de ce projet est de pouvoir obtenir un tel
cluster et j’utilise Le Framework HTCondor pour lancer un programme sur le cluster composé de
trois machines, une machine Master et deux machines slaves.

2. Prérequis :

• Une machine virtuelle Ubuntu 18.04 (Master) ;

• Deux machines virtuelles, Ubuntu Server 20.04 (Slaves) ;
• Installation de Mpich sur toutes les machines Master et slaves ;
• Installation et configuration d’un serveur NFS entre les machines ;
• Générer une clés Ssh entre les machines ;
• Un réseau NAT commun ;
• Installation et configuration HTcondor.

3. Configuration initiale de réseau :

Avant tous, j’ai créé trois machines virtuelles, une machine Ubuntu 18.04 avec une interface
graphique et deux machines slaves Ubuntu Server 20.04.
Ensuite j’ai créé un réseau NAT nommé « Cluster », les trois machines sont connectés depuis ce réseau.

Réseau Nat nommé « Cluster »

Les machine slaves sont connecté au réseau « Cluster »

La machine master connecté au réseau « Cluster »

Dans notre cas les machines possèdes des adresses IP DHCP, les adresses sont distribué comme suivant :

• Machine Master (Ubuntu 18.04) : 10.0.2.5

• Machine Slave1 (Ubuntu Server) : 10.0.2.4
• Machine Slave 2 (Ubuntu Server) : 10.0.2.15

Maintenant que toutes les machines sont toujours connectés au même réseau, les adresses IP sont fixes.
Il faut assurer que chacun de nom machines connaissent les autres, pour cela on va associer un nom à
chaque adresse via le fichier /etc/hosts et puis on va redémarrer les service de réseau , dans la suite de
ce projet, on pourra connecter juste par le nom associé à l’adresse de machine.

Configuration /etc/hosts pour le Master

Configuration /etc/hosts pour Slave1

 Configuration /etc/hosts pour Slave2

Teste de la connexion entre les machines après la configuration.

Ping depuis la machine Slave2

 Ping depuis la machine Master

4. Installation de HTcondor :

4.1. C’est quoi HTcondor :

HTcondor est un kit de composants logiciels (framework) open source de parallélisation de

traitement pour la parallélisation à distribution grossière de tâches de calcul lourdes1. Il peut être
utilisé pour gérer une charge de travail sur une grappe de serveurs dédiée.

HTcondor tourne sur les systèmes Linux, Unix, Mac OS X, FreeBSD, et sur les systèmes Windows
actuels. Condor peut aisément faire collaborer des ressources dédiées (grappes de calculateurs en
batterie) et des postes de travail non dédiés (grille informatique) en un seul environnement de calcul
intégré.

4.2. L’installation et configuration:

L’installation de HTcondor sous Linux se fait comme suivant :

$ sudo apt update

$ sudo apt-get install htcondor

Pendant l’installation, il faut faire un ensemble de configuration selon notre cluster.

4.3. Installation dans la machine Master :

Voici la configuration finale de la machine Master :

Configuration HTcondor pour Master

 4.4. Installation dans la machine Slave1 :

L’installation finale de la machine Slave1 :

Configuration HTcondor pour Slave1

 4.5. Installation dans la machine Slave2 :

L’installation finale de la machine Slave1 :

Configuration HTcondor pour Slave2

On lance la commande condor_status pour vérifier que la configuration est fait correctement :

On constate que le cluster est composé d’une machine Master et deux machine Slaves.

L’architecture de notre cluster est bien réalisé par la configuration qu’on a fait.

Résultat condor_status

Avant tester le cluster par la soumission des tâches, il reste quelques configuration à faire :

• Générer un clés SSH, pour la communication entre les machines sans demander le mot de passe.
• Configuration de NFS, pour la partage des fichiers.

5. Configuration l’authentification SSH :

Secure Shell, ou SSH, est un protocole réseau normalement utilisé pour connecter un utilisateur à un
système distant sur un réseau non sécurisé

L’authentification des clés SSH commence par la création d’une paire de clés. Comme l’authentification
par SSH est asymétrique, une paire de clés asymétriques est créée dans les deux machines en
communication. Le cryptage asymétrique utilise une paire de clés composée d’une clé publique et d’une
clé privée. La clé publique donne à l’utilisateur (ou bien la machine dans notre cas ) l’accès au système de
fichiers distant.
Pour Cela il faut générer une paire de clés entre toutes les machines à fin rendre la communication plus
sécurisé et pour que les machines fassent confiance entre eux, déjà il faut mettre en place le serveur
OpenSSH sur les trois machines.

Générer les certificats et clés RSA au niveau machine Master, par la commande suivante :

Ensuite, il faut copier les clés générés vers les machines slaves par la commande suivnate :

$ ssh-copy-id ibrahim@slave1

$ ssh-copy-id ibrahim@slave2
 Copier la clé vers Slave1

Copier la clé vers Slave1

Après cette configuration, désormais, la connexion SSH se fait sans mot de passe entre les machines de
cluster.
 Connexion SSH sans mot de passe

Remarque : La configuration précédente se répète pour les deux machine slaves (Slave1, Slaevz2)

La connexion SSH entre les slaves sans mot de passe

 Connexion SSH depuis les slaves vers le Master sans mot de passe

6. Configuration de partage NFS :

Network File System (NFS), ou système de fichiers en réseau, est une application client/serveur qui
permet à un utilisateur de consulter et, éventuellement, de stocker et de mettre à jour des fichiers sur
un ordinateur distant, comme s'ils étaient sur son propre ordinateur.

Dans notre cas, le NFS est important lors de soumission des tâches, pour que les machines puissent
accéder à des fichiers nécessaires pour terminer l’exécution des tâches.

➢ Tout d’abord, il faut mettre en place le serveur NFS sur la machine Master, on lançant la
commande suivante :

$ sudo apt update

$ sudo apt install nfs-kernel-server

➢ Il faut créer le dossier partagé dans le dossier /mnt/ :

$ mkdir /mnt/jobs

➢ Puisque nous voulons que toutes les machines slaves puissent accéder au répertoire partagé, il
faut supprimer toute restriction dans les autorisations du répertoire.

$ sudo chown -R nobody:nogroup /mnt/jobs/

➢ Ici, on va donnles privilèges de lecture, d'écriture et d'exécution à tout le contenu du répertoire.

$sudo chmod 777 /mnt/jobs

➢ Les autorisations d'accès au serveur NFS sont définies dans le fichier /etc/exports :

Configuration /etc/exports

• rw: Signifie "lecture/écriture"..

• sync: Requires changes to be written to the disk before they are applied.
• No_subtree_check: Élimine la vérification des sous-arbres.

➢ Après avoir accordé l'accès aux slaves, il faut exporter le répertoire de partage NFS jobs, puis
redémarrer le serveur NFS kernel pour que les changements prennent effet.

$ sudo exportfs -a

$ sudo systemctl restart nfs-kernel-server

 ➢ La configuration sur les machines slaves est comme suivante :

Configuration dans les machines slaves

➢ Ensuite, il faut créer la dossier lequel on montrera le partage nfs du serveur NFS. Pour ce faire,
exécutez la commande :

$ sudo mkdir -p /mnt/jobs_shared

➢ La dernière étape restante est le montage du partage NFS qui est partagé par le serveur NFS.
Cela permettra au système client d'accéder au répertoire partagé jobs.

$ sudo mount master:/mnt/nfs_share /mnt/jobs_shared

Le partage s’arrêtera au redémarrage de la machine, comme solution permanente il faut modifier la

configuration de la fichier /etc/fstab :
 7. Tester l’infrastructure de notre cluster :

Mais avant, il faut que installer MPICH sur nos machines pour qu’on puisse faire des tests avec les
notions de parallélisme.

$ sudo apt update

$ sudo apt-get install mpich

7.1. Teste d’un code serial :

7.2. Teste d’un code parallèle :

8. Soumission de jobs :

Maintenant qu’on est terminé toutes les configurations nécessaires, on peut tester notre cluster par la
soumission des jobs depuis la machine Master aux machines salves.
 8.1. Création et Configuration d’un job:
8.1.1. Serial :
➢ Tout d’abord, il faut créer un fichier de soumission de Condor :

Fichier de soumission Condor (Serial)

• Uinverse : signifie le mode de soumettre (parallel, valilla, …) ;

• Executable : le nom de programme ;
• Log : c’est le nom d’un fichier où Condor va enregistrer des informations sur
l’exécution du job ;
• Output : où Condor devrait mettre la sortie standard du job ;
• Error : où Condor devrait mettre la sortie d’erreur du job.

Cette fois, on va utiliser un code Serial qui calcule la somme de 1 à 100 :

Le programme Serial
 La soumission du job se fait par la commande suivante :
$ condor_submit serial.jdl

Soumission du job

Depuis le fichier log, on constate que le job est exécuté par la machine d’adresse IP 10.0.2.15 c’est-à-dire
par Slave2, il y a autres informations tels que : Cpu, Mémoire, Disk, le temps d’exécution …
➢ On modifiant la valeur de queue à 2, le programme s’exentéra sur les deux machines slaves :

Fichier de soumission Condor - queue 2 (Serial)

Voici la résultat et le fichier log lors de l’exécution :

Résultat d’exécution (Serial-queue 2)

On constate que la même programme est soumis et exécuté sur les deux machine slave1 et slave2.

8.1.2. Parallèle :

Par la même façon, sauf de quelques modification sur le fichier de soumission du job, :

On fait la soumission par la commande suivante :

$ condor_submit paralleljob.jdl
Depuis le fichier log, on constate que le job est bien distribué (à slave1 : 10.0.2.4), mais output de
programme ne donne rien.

9. Conclusion :

Les mécanismes des travaux parallèles sont plus complexes que les mécanismes nécessaires pour les
travaux séquentiels. La raison en est qu'un certain nombre d'opérations doivent être gérées par
HTCondor : les communications SSH entre les noeuds, les transferts de fichiers, l'exécution du travail
dans les noeuds conçus et plus encore. Par conséquent, le checkpointing ne fonctionnera pas pour les
travaux de l'univers parallèle et la suspension des travaux peut causer des problèmes : c'est pourquoi les
travaux de l'univers parallèle doivent être exécutés dans des ressources dédiées, où les politiques qui
incluent la suspension des travaux doivent être désactivées.