TP de l'UE Cluster

Il y aura 2 séances de 3 heures de TP pour ``haute disponibilité´´ en 3 séances de 3 heures pour MPI.

Les étudiants suivant l'option Image ont l'obligation de se mettre en binome avec un étudiant d'option réseau.

Sujet haute disponibilité

Je vous demande de faire un script (shell, perl, python, ...) qui réinstalle complètement votre travail à partir de 0 (ce script fera parti de votre compte-rendu). Comme cela, même si le disque dur est effacé vous ne perdrez pas de temps à tout refaire. Vous stockerez donc toute les données nécessaires pour configurer la machine ainsi que le script la configurant dans une disquette ou une clef USB qui vous permettra d'initialiser le maître et l'esclave en lançant le script sur l'une et sur l'autre.

La première séance de TP portera sur DRBD et la seconde sur HeartBeat.

Configuration réseau

On utilisera la deuxième carte réseau pour connecter directement les deux machines (avec un câble croisé). Chacune des deux machines a une adresse IP normale et une adresse privée et l'une des deux à l'adresse publique du service.

• eth0 : 192.168.9.0/23
• eth1 : 192.168.255.0/24
• L'adresse normale de la machine est 192.168.9.XXX ou XXX est le dernier nombre indiqué sur l'étiquette portant le nom de la machine.
• L'adresse publique du service est 192.168.10.XXX ou XXX est le dernier nombre indiqué sur l'étiquette portant le nom de la machine maîtresse.
• Pour les adresses privées vous prenez 192.168.255.1 et 192.168.255.2

Le script déterminera si la machine est maître ou esclave en regardant son nom (commande hostname). En aucun cas vous ne devez changer les noms des machines sur lequel vous êtes. Les paramètres du script sont :

1. "Nom du maître"
2. "XXX du maître" # Pour Heartbeat
3. "Nom de l'esclave"
4. "XXX de l'esclave" # Pour Heartbeat

Configurer les deux cartes réseaux sans utiliser ifconfig mais dans le fichier /etc/network/interfaces Pour tester immédiatement la nouvelle configuration lancez /etc/init.d/networking restart

La première sera connectée au réseau mural afin que toutes les machines puissent communiquer entre elles. La deuxième permettra de faire la synchronisation avec l'autre machine en utilisant un câble croisé.

Vous ne configurez pas l'adresse du service pour l'instant. C'est HeartBeat qui s'en chargera

Branchez les câbles et testez les liaisons en utilisant les 2 adresses IP de la machine distante.

Libérez une partition

On a besoin d'une partition, il n'y en a point de libre... Nous allons donc prendre la partition de swap. Pour ce faire, votre script d'installation doit :

• Exécuter la commande swapoff -a pour ne plus utiliser de swap
• Commenter dans /etc/fstab la ligne indiquant que le swap se trouve dans /dev/hda3

  Filtre pour commenter les lignes contenant le mot swap : sed 's/.*swap/# &'/

Installation DRBD

Récupérez sur le réseau la dernière version de DRBD http://oss.linbit.com/drbd/ que vous mettrez sur votre disquette ou votre clef USB avec votre script de configuration.

Décompressez, détarrez, compilez et installez DRBD. ATTENTION, il est nécessaire d'ajouter la ligne : unsigned int module_refcount(struct module *u) { return 1 ; } dans le fichier drbd_main.c après les include.

Créez le périphérique block nommé /dev/drbd0, il vous permettra d'accéder au disque virtuel fiable. Son major est 147 et son minor 0

Configurez DRBD. Il stockera les données dans /dev/hda3 Et c'est TROIS et pas autre chose.

Prenez 50M comme vitesse de synchronisation

Faites en sorte que DRBD soit lancé au démarrage et arrêté lors du shutdown. Pour cela ajoutez les bons liens dans /etc/rc2.d et /etc/rc0.d Je vous conseille le nombre 19 comme niveau de priorité au lancement des scripts. S'il vous plais : enlevez ces fichiers lorsque votre TP est terminé, par exemple en lançant votre script d'installation sans donner de paramètres.

Lancez DRBD (/etc/init.d/drbd start).

Regardez le status de DRBD (/proc/drbd), de préférence laissez une fenêtre le montrant en permanence (commande watch).

Initialisation disque fiable DRBD

Indiquez à DRBD quel est la machine primaire (commandes drbdsetup ou drbdadm).

Si vous êtes le primaire : faites un mkfs.ext3 sur /dev/drbd0, pas sur la partition physique.

Si vous êtes le primaire : montez la partition, travaillez dessus. Tout en faisant cela, analysez le comportement des 2 systèmes, des disques et du réseau.

Tests du disque fiable DRBD

Tout en continuant à modifier les fichiers, faites un redémarrage du secondaire. Rien ne devrait être perturbé. Combien de temps dure la synchronisation des deux disques ?

Faites un autre test en éteignant le primaire et en demandant au secondaire de devenir le nouveau primaire. Avez-vous accès à tous les fichiers ?

Démarrer l'ancien primaire, que ce passe-t-il ? Que devez-vous faire pour relancer la synchronization ?

Heartbeat

Branchez un câble "null modem" entre les deux machines pour faire passer les batements de cœur.

Configurer HeartBeat pour qu'il mettre l'adresse IP du service sur la carte réseau nommée eth0:0

C'est heartbeat qui fait la configuration réseau du service, NE mettez PAS celle ci dans le fichier /etc/network/interfaces

Le package "heartbeat" est déjà installé. Configurez le (/etc/ha.d/ha.cnf) avec seulement le service DRBD et le montage du disque DRBD (/etc/ha.d/haresources). Remettez le fichier original avant de quitter le TP, (faites comme pour les liens symboliques).

Les logs de heartbeat sont dans /var/log/ha-log

Tester les différents cas de panne (ils sont nombreux). Mesurez les temps de basculements pour chaque cas. Pourquoi ne pas tester la panne consistant à débrancher les 3 cables reliant les 2 machines ?

Exportez le disque DRBD via NFS (/etc/ha.d/haresources) et mesurez le temps pendant lequel les clients n'ont pas eu le service NFS en fonction de la panne. Ne faites pas lancer les services NFS par /etc/rc?.d/... car c'est heartbeat qui s'en charge. Par contre vous modifiez /etc/exports pour dire qui à le droit de monter votre disque.

Rapport

Vous devez expliciter tous les tests que vous avez fait dans votre rapport. Le rapport est à rendre la semaine qui suit le dernier TP.

Sujets parallélisme

Vous trouverez des petits exemples MPI sur mon compte que je vous conseille de tester et de comprendre, n'oubliez pas de prendre le Makefile. Le manuel de référence MPI

Problèmes courants :

• Si la commande rsh vous demande un mot de passe MPI ne fonctionnera pas. Pour réparer cela : Ajouter le nom de la machine qui lance la commande dans .rhosts et faites en sorte que tout le monde puisse lire votre fichier .rhosts (votre compte ne doit pas être protégé en lecture).
• Quelles machines mettre dans nom_des_machines ? Regardez dans la liste des machines par salles de TP Et choisissez QUE les machines vers lesquels la commande rsh fonctionne. Si c'est très lent, alors mettez les adresses IP (problème de configuration local)
• Pour faire des tests de temps d'exécution valides il faut être seul à travailler, il faut donc demander aux autres avant de les lancer si quelqu'un travaille sur les machines. Limitez la durée de vos tests à une minute.

Le sujet : un simulateur de vagues

Les sources d'un simulateur de vagues (vague.c) sont à votre disposition. Vous pouvez l'exécuter pour voir ce que cela fait.

Vous devez paralléliser cette application afin de la faire fonctionner sur plusieurs machines. Pour cela :

• Chaque tache s'occupe d'un bloc de la mer.
• La figure montre quelques-uns des échanges faits entre des blocs d'une grille de blocs 3x2, chacun des blocs comportant 4x4 pixels.
• Le simulateur utilise les pixels du bord mais ne met pas leur valeur à jour.
• Seule la partie jaune est affichable. La mer de cet exemple fait seulement 6x4 pixels.
• Considérez la mer sur un tore. C'est-à-dire qu'à gauche de la colonne de gauche il y a la colonne de droite et inversement. Même chose pour le haut et le bas. Ainsi il n'y a pas de cas particuliers pour les bords.

Remarques :

• Je vous déconseille fortement de modifier les fonctions de vagues.c à part le main et mer_remplir.
• Il n'est pas nécessaire de mettre le source de vague.c dans votre rapport car normalement vous ne les avez pas modifié.
• Aucune des taches ne doit créer la mer totale. Sauf pour debugguer : dans ce cas, la tâche maîtresse fera l'affichage total.
• Les paramètres de votre programme seront :
  • La largeur en pixel d'un bloc, y compris le bord.
  • La hauteur en pixel d'un bloc, y compris le bord.
  • Le nombre de blocs en largeur.
  • Le nombre de blocs en hauteur.
  • Un entier indiquant le nombre de pas de simulation qui sont faits entre chaque affichage. Si ce nombre est très grand, on ne fait aucun affichage.
  • Le nombre de pas de simulation à faire avant de s'arrêter. Afficher le nombre de simulations par secondes si aucun affichage n'a eu lieu.

Vous devrez tester le fonctionnement de votre application parallèle :

• Vérifier qu'elle donne bien exactement le même résultat quand elle est parallélisée ou non.
• Comparer sa vitesse pour diverses tailles de grille (1000x1000, 2000x2000, 4000x4000, 8000x8000, 16000x16000) sur un nombre variable de processeurs (de 1 à 17). Les tests de vitesse sont fait SANS affichage.
• Trouver le goulot d'étranglement de votre algorithme.
• S'il vous reste du temps, imaginez une méthode pour simplifier les grilles et les transmettre vers la tache 0 qui les affichera en OpenGL 25 fois par seconde.

Vous devez rendre un rapport papier d'environ 4 pages :

• Contenant la description de la méthode utilisée pour paralléliser.
• Indiquant les raisons des choix qui ont été faits.
• Contenant les résultats des tests de fonctionnement.
• Indiquant aussi si l'on peut améliorer la parallélisation de l'algorithme que vous avez utilisé.
• Avec le listing en annexe (pas dans les 4 pages).

Le rapport est à rendre la semaine qui suit le dernier TP.