Le clustering

Tout utilisateur de Linux a déjà rêvé de posséder un jour une machine surpuissante capable d'égaler les supercalculateurs des universités. Le principal problème est le prix de revient d'un tel ordinateur. Peut-on contourner cet état de chose ? Et si oui, comment ? La réponse est simple et tient en un seul mot : CLUSTERING !

CONCEPT
Le principe utilisé dans le clustering consiste à diminuer le temps d'exécution d'une tâche en la fractionnant sur plusieurs machines. En clair, une tâche répartie sur N machine arrivera N fois plus vite à terme que sur une seule. Si vous possédez dans votre cave une vingtaines de PC i486DX33, il y a fort à parier qu'ensemble ils travailleraient plus vite qu'un Pentium 233 ! De cette manière, tous les réseaux peuvent être transformés en cluster. Il serait même envisageable de créer le plus puissant cluster du monde grâce au plus grand réseau interconnecté du monde : InterNet !

Ce concept est fort simple mais il faut faire le distingo entre un système complet en clustering et un logiciel en clustering. Dans le premier cas, ce sont les tâches qui seront réparties sur plusieurs PC et dans le second, c'est une tâche qui sera divisée sur plusieurs PC.

Pourquoi tout le monde n'utilise-t-il pas un cluster puisque c'est performant et peu cher ? Le problème principal provient des connexions entre les différentes machines. Pour créer un cluster performant, les machines doivent pouvoir communiquer très rapidement et le coût s'en trouve augmenté (voir plus bas).

TERMINOLOGIE
Un ensemble de machines en réseau destiné à un fonctionnement en parallèle constitue un cluster. Dans ce cluster, chaque machine sera un Node. Tous les nodes sont des stations de travail dans le sens où elles possèdent un ou plusieurs processeurs en opposition aux terminaux. Le réseau ainsi formé est un NOW, un Network Of Workstation (réseau de station de travail).

CHOIX DU MATERIEL
Le domaine du réseau était encore peu connu et rarement utiliser avant l'arrivé des jeux multi-joueur. En effet, de nos jours, il n'est plus rare de trouver chez un particulier deux, trois ou quatre ordinateurs en réseau. Malheureusement, ces réseaux destinés aux jeux sont souvent lents (ethernet 10 Mb/s) et font cruellement baisser les capacités d'un cluster.

Le matériel performant (cartes, câbles, hub, etc.) coûte excessivement cher. Voyons quelques exemples de matériels supportés par Linux :
  • Ethernet
    Voici le matériel le plus courant. Son prix de revient avoisine les 300 francs mais avec un débit de seulement 10 Mb par seconde. Il s'agit le plus souvent d'une carte ISA ou PCI.
  • Fast Ethernet
    Possédant un débit plus important (100Mb/s), ces cartes sont également plus chères (environ 900 francs). De plus, la connectique impose l'achat d'un Hub dont le coût est proportionnel aux performances.
  • Gigabit Ethernet
    comme son nom l'indique, le débit offert est de 1000Mb/s mais le coût rend une telle carte hors de portée du particulier : environ 10000 francs !
  • PLIP
    Il ne s'agit pas vraiment d'une technologie sérieuse pour le réseau, mais le coût en est très intéressant : moins de 15 francs. PLIP signifie Parallèle Line Interface Protocol. En clair, c'est le port parallèle du PC qui sera utilisé pour interconnecter les machines. Le débit est de 1,2Mb/s.
LOGICIELS
Il existe une grande quantité de logiciels sous Linux afin de transformer un NOW en cluster. Leur tâche est principalement de transformer l'ensemble des nodes en une seule fausse machine : une machine virtuelle dont l'existence est purement imagée et qui n'existe pas physiquement. Voyons ensemble les deux principaux utilitaires et leurs fonctions.

PVM
PVM est l'acronyme de Parallèle Virtual Machine. Il permet de créer un cluster à partir de nodes de types différents (PC/Linux, PC/Windows, Mac, HP, CRAY, etc.). Il supporte tous les réseaux capables d'une connexion par socket comme par exemple SLIP, PLIP, Ethernet et ATM. PVM se présente sous la forme d'un deamon et de bibliothèques C et FORTRAN. Les applications qui utilisent PVM doivent être compilées avec les bibliothèques PVM. Ceci implique une modification du code dans le cas d'une application déjà existante. L'un des plus bel exemple d'application modifiée et recompilée pour PVM est PovRay. C'est un logiciel de Ray Tracing dont le portage pour PVM se nomme PvmPov, mais nous y reviendrons plus loin.

MPI
MPI (pour Message Passing Interface) est souvent considéré comme le concurrent principal de PVM. Pour expliquer cette " guerre de religion " entre PVM et MPI, voyons leurs différences.

 

  • PVM possède un environnement de contrôle. En somme, le lancement d'une application PVM est identique sur tous les environnement. Ceci permet de mettre en oeuvre un utilitaire pour contrôler les exécutions des diverses applications dans la machine virtuelle.
  • MPI considère la machine virtuelle comme un processeur massivement parallèle ou encore comme un réseau de nodes identiques. PVM est d'avantage orienté vers les réseaux hétérogènes (composés de machines différentes).
  • MPI permet un accès distant à la mémoire (RMA, Remote memory Access) et un système d'entrée/sortie en parallèle. Ces deux fonctionnalités sont utiles mais nécessites d'apprendre MPI de la même manière qu'un nouveau langage.
  • o MPI a été crée après PVM et s'en est inspiré. MPI est donc plus performant au niveau de la gestion de buffers, des structures de données, etc.
Voici donc les principales caractéristiques qui existent entre les deux standards. Notre tâche n'est pas de vous inciter à utiliser l'un ou l'autre. Nous ne donnerons donc pas notre avis, à vous de voir en PVM ou MPI le programme qu'il vous faut.

LES PROJETS DE CLUSTERS
Il existe beaucoup de méthodes différentes pour créer un cluster. Il est donc utile de pouvoir se référer à des clusters ou des projets de cluster déjà en place.

  • Beowulf
    Ce projet parrainé par la N.A.S.A. concerne l'architecture classique PC et le système Linux.  Débuté en 1994, il est dirigé par Thomas Sterling et Don Becker. Le système Beowulf permet à un ensemble de nodes de fonctionner tel un seul PC. Les programmes en fonctionnement sur le PC virtuel seront exécutés en fonction de la puissance et de la disponibilité de chaque node. Mais un seul programme ne sera pas réparti sur plusieurs nodes. En clair, le système va vérifier l'occupation de chaque node et y répartir tous les process en cours. Le premier cluster construit dans le cadre de ce projet était constitué de 16 DX4 connecté en ethernet.
  • Linux/AP+
    Ce projet ne traite pas exactement de clustering. Il s'agit du portage de Linux sur l'architecture Fujitsu AP1000+. Cet ordinateur est une machine parallèle basée sur SPARC qui utilise une topologie réseau propriétaire à 25Mo par seconde. En résumé, ce portage ressemble fort à un cluster de SPARC sous Linux.
  • U-NET
    Basé à l'université de Cornell, ce projet a pour but de créer une interface basée sur un réseau classique afin d'optimiser les temps de réponse des machines. Le principe consiste à envoyer et recevoir des messages sans l'intervention du système. U-Net  tourne sur PC sous Linux et des cartes DECchip Fast Ethernet.
  • distributed.net
    Le plus grand cluster connu au monde. En vous connectant à www.distributed.net, vous pourrez télécharger un client (programme) pour votre ordinateur. Et ce, quelqu'il soit et quelque soit son système d'exploitation. Grâce à ce client, vous pourrez transformer votre ordinateur en node connecté à InterNet. Le but de ce cluster gigantesque est, entre autre, de démontrer que la taille des clefs de cryptage actuellement utilisée est obsolète. Pour preuve, distributed.net a cassé un code DES-II 56 bits en 40 jours. La clef du code RC5-32/12/7 56 bits fut cassée en 250 jours.
  • Extreme Linux
    Dérivée du projet Beowulf et en collaboration avec Red Hat, la Nasa et plusieurs centres de recherche, Extreme Linux est la première distribution de Linux en cluster. Celle-ci est directement issue de la distribution Red Hat modifiée pour le cluster de 160 stations Alpha utilisées pour certains effets spéciaux du film Titanic.

EN PRATIQUE
Dans les prochains chapitres, nous considérerons que votre réseau est correctement configuré et fonctionne parfaitement. Nous nous baserons sur un cluster de test composé de seulement trois PC. Ceci est suffisant dans le sens où l'ajout de nouveaux nodes au cluster existant n'est qu'une question de configuration réseau. Le cluster sera donc constitué de trois nodes respectivement nommés case, molly et gentry. Les trois PC fonctionnent avec un kernel 2.0.30 reconnu pour sa stabilité.

PVM
Une fois l'archive de PVM récupérée, il convient de la compiler. La version utilisée pour cet exemple est la 3.3.11. Pour compiler cette version, il a été nécessaire de déclarer deux variables PVM_ROOT et PVM_DPATH. PVM_ROOT pointe vers le répertoire où a été décompacté PVM et PVM_DPATH pointe sur le daemon lui-même. La commande utilisée pour déclarer ces variables est la suivante : 

PVM_ROOT=/pvm3
PVM_DPATH=$PVM_ROOT/lib/pvmd
export PVM_ROOT PVM_DPATH
Cette syntaxe peut différée en fonction de votre environnement et de votre distribution.
Attention : Il est fortement conseillé de placer ces commandes dans l'un des fichiers exécutés au démarrage car elles sont également nécessaires au fonctionnement de PVM. Dans notre cas précis (avec notre distribution Kheops 3.3), nous avons ajouté ces lignes dans le fichier /etc/profile. Les sources de PVM sont fournies pour être compilées sous plusieurs systèmes d'exploitation différents. Il peut arriver qu'au moment de la compilation un message vous informe que l'architecture UNKNOWN est introuvable. Ne paniquez pas, éditez simplement le fichier /lib/pvm3getarch du répertoire de PVM et remplacez ARCH=UNKNOWN par ARCH=LINUX.

Dans un cluster PVM, l'un des nodes est utilisé presque exclusivement pour la gestion du cluster. Il utilise l'utilitaire rsh pour exécuter des commandes sur les autres nodes comme le lancement du daemon par exemple. Il est donc impératif que l'utilisateur qui lance PVM bénéficie des droits suffisants sur rsh. Il faut, sur chaque node, créer un fichier .rhosts dans le répertoire privé de l'utilisateur choisi. Ce fichier devra contenir le nom des autres nodes ainsi que celui des utilisateurs. La syntaxe du fichier dépendra du nom d'identification des autres nodes. Exemple : 

#Fichier .rhosts de case
molly.dixieland.fr root
case.dixieland.fr root
gentry.dixieland.fr root
Dans cet exemple, la première ligne autorise l'utilisateur root en provenance de molly à utiliser les services de rsh. Cette ligne débute avec molly.dixieland.fr et non molly car lorsque l'utilisateur root se log sur case depuis molly et qu'il exécute la commande w il obtient ceci : 
USER TTY   FROM               LOGIN@ IDLE  JCPU  PCPU  WHAT
root ttyp1 molly.dixieland.fr 10:40p 0.00s 0.16s 0.05s w
Donc case voit la machine sous le nom molly.dixielande.fr.

Le plus facile est donc d'être root. Ceci permet d'avoir accès à tout sans restriction. Il est donc naturel que cela fonctionne du premier coup. C'est en pensant cela que nous avons rencontré un problème. L'utilitaire rsh est controlé par inetd. Vous trouverez dans votre fichier /etc/inetd.conf une ligne concernant in.rshd. ATTENTION, certaines versions ont besoin du paramètre -h sur cette ligne. En cas d'absence de ce paramètre, rsh refusera d'exécuter directement une commande émise par l'utilisateur root. Ceci pour des raisons évidentes de sécurité (mais il faut le savoir).
Une fois tous les nodes configurés selon ce principe, vous pouvez procéder au premier test en tapant par exemple (depuis molly): 

rsh case ls
Ceci devrait vous retourner la liste des fichiers présents sur case. Si vous obtenez un message du type access denied, c'est que les fichiers de configuration .rhosts ou inetd.conf ont une erreur. Vous pourrez en savoir plus en consultant le journal du système (/var/log/messages).

Pour lancer PVM, placez vous dans son sous répertoire lib et tapez pvm. Vous vous retrouverez dans l'utilitaire de gestion du daemon pvmd. Celui-ci vous accueille amicalement par le symbole pvm>. Vous pourrez alors taper les commandes destinées à modeler et contrôler votre cluster. Par exemple, vous pourrez taper la commande conf qui vous informera sur la configuration actuelle de PVM. Dans notre cas, immédiatement après le lancement de la commande pvm, conf nous retourne : 

HOST DTID  ARCH  SPEED 
case 40000 LINUX 1000
Après avoir tapé la commande add molly destinée, comme son nom l'indique, à ajouter le node molly dans le cluster, conf nous retourne : 
HOST  DTID  ARCH  SPEED 
case  40000 LINUX  1000 
molly 80000 LINUX  1000
Notre cluster est à ce moment constitué de deux nodes. Un coup d'oeil dans le journal confirme le bon déroulement de l'opération : Jul 15 00:12:48 molly rshd[110]: root@case.dixieland.fr as root: cmd='/pvm3/lib/pvmd -s -d0 -nmolly 1 ac100101:04a5 4096 2 ac100102:0000'. Le daemon pvmd a donc été parfaitement bien lancé sur molly depuis case.
Si en revanche, vous obtenez de PVM, un message comme 0 successful molly Can't start pvmd, vous devrez à nouveau vérifier toute votre configuration.

Pour quitter PVM sans arrêter le cluster, tapez la commande quit. PVM confirmera par pvmd still running et vous pourrez à tout moment reprendre le contrôle en relançant pvm. Pour arrêter le pvmd et la gestion du cluster, utilisez la commande halt.

PVMPOV
PVMPOV est une version modifiée de Pov-Ray 3.01. Celle-ci inclut les bibliothèques de PVM et permet une utilisation de POV en clustering via pvmd. PVMPOV est distribué sous la forme d'un patch non officiel pour Pov-Ray. Vous devrez donc déjà être en possession des sources de POV pour les systèmes Unix.
Après application du patch par la commande patch -s -p1 < pvmpov-3.1.patch et recompilation de POV, vous obtiendrez selon vos choix pvmpov pour la version non graphique, s-pvmpov pour la version svgalib et enfin x-pvmpov pour la version Xwindow.
Ce ou ces exécutables devront être placés dans les sous répertoires /bin/LINUX de PVM sur chaque node. PVMPOV pourra être utilisé de manière classique comme POV mais il se voit gratifié de paramètres supplémentaires. Les deux nouveaux paramètres les plus importants sont :
+N activera le fonctionnement avec PVM
+NW et +NH permettent de définir respectivement une largeur et une hauteur pour les cases de rendering à distribuer

Pour lancer un calcul sur le cluster, il faut tout d'abord lancer PVM et ajouter tous les nodes. Puis lancez le rendering par : 

	
s-pvmpov +Iscript.pov +Oimage.tga +N +H480 +W640 +L/usr/lib/povray3/include +D
Cette ligne provoque un calcul de script.pov en 640*480 par le cluster. Les fichiers includes de POV se trouve dans /usr/lib/povray3/include. Le résultat sera stocké dans image.tga et +D nous permettra de voir le rendering en svgalib.

Nous n'avons pas pu faire de capture de ce qui se passe sur l'écran, mais le spectacle est de taille. L'écran se trouve divisé en cellules de 32*32 qui sont calculées individuellement par les nodes.

Les résultats du cluster sont satisfaisants. Case (Cyrix P200+) seul calcule l'image en 17 minutes. Molly (Intel 133) met 14 minutes. Le cluster piloté par gentry (Amd DX4/100) met avec les nodes case et molly, seulement 7 minutes. Ce rendement pourrait encore être amélioré en utilisant des cartes réseaux plus performantes et non de simples compatibles NE2000 en BNC.