Cluster Linux Openmosix

Cluster Linux Openmosix Tony Bernard bernard.tony@free.fr Décembre 2004 UFR Sciences de Toulon - 1-2004/2005

INTRODUCTION 1 Présentation des clusters Linux 1.1 Définition 1.2 Utilisation des clusters 1.3 Différents types de cluster 1.4 Logiciels de clustering PC 2 Openmosix 2.1 Définition 2.2 Installation 2.3 Configuration 2.4 Commandes et outils et d'openmosix 2.5 Exemples de tests 3 Avantages et inconvénients d Openmosix 3.1 Avantages 3.2 Inconvénients CONCLUSIONS REMERCIEMENTS : je tiens à remercier les deux enseignants du module d administration système Emmanuel Bruno et Pascal Ritter, pour la qualité des cours dispensés ainsi que leur disponibilité tout le long du semestre pour répondre aux diverses questions sur ce projet. Merci à Christophe Jaubert pour sa relecture et les corrections apportées. UFR Sciences de Toulon - 2-2004/2005

INTRODUCTION Dans le domaine scientifique ainsi que dans le monde de l entreprise, le gain de temps ainsi que la disponibilité sont des notions primordiales. C'est pour cela qu'une forte puissance de calcul et de stockage est recherchée depuis de nombreuses années. Déjà plusieurs solutions sont apparues, telles que l'utilisation de super calculateurs (ILLIAC IV en 1965 et le Cray-I de Seymour Cray en 1976) ou par l'utilisation de plusieurs ordinateurs en parallèle. Ce rapport est consacré à cette deuxième catégorie que l'on appel cluster. Après une présentation sommaire des différentes utilités et catégories de clusters, un tour d horizon des différents clusters sera proposé. Les principales solutions de clustering Linux seront énoncées, et le cluster Openmosix sera présenté plus en détail. Un bilan sur les avantages et inconvénients de celui ci clôturera ce rapport. 1 Présentation des clusters 1.1 Définition Un cluster (ou grappe en français) représente un groupe d'ordinateurs. La différence avec un simple réseau d'ordinateur est qu'ils se partagent leurs ressources (CPU, mémoire et disque). Les clusters PC présentent en général une architecture avec une machine serveur (node serveur) qui constitue le point d'entrée et sera chargée de répartir le travail à effectuer par les noeuds (node), euxmêmes connectés par un switch. Le tout forme ce que l'on appel un cluster PC. Tâches à exécuter Noeud serveur Noeuds Figure 1-1 : exemple d'architecture d'un cluster. 1.2 Utilisation des clusters Clusters de calculs Ils permettent le cumul des puissances de calcul des processeurs. Deux catégories de clusters de calculs sont disponibles, ceux dit à calculs parallèles et ceux dit à calculs distribués. Dans le cas des clusters de calculs parallèles, les différents processeurs ont accès aux mêmes données et effectuent les mêmes traitements. Alors que, dans le cas des clusters de calculs distribués, les données, mais également les traitements, peuvent être répartis sur différentes machines. Dans ce deuxième cas les connexions entre les nœuds sont importantes et influencent les performances du calcul. Ces types de cluster sont utilisés dans certains domaines comme la recherche ou les mathématiques afin de résoudre des problèmes complexes, ils ont aussi été très utilisés pour décoder le génome humain. Le rapport prix / performance d une grappe de PC est de trois à dix fois inférieurs à celui des supercalculateurs traditionnels. En janvier 2005, le plus grand supercalculateur d Europe sera opérationnel en Espagne, son coût est estimé à 70 millions d euros. Cette somme reste tout de même au dessous des 300 millions de dollars de Earth simulator du supercalculateur Japonais. UFR Sciences de Toulon - 3-2004/2005

Clusters de stockage Le principe est le même que précédemment mais appliqué au stockage. On peut disposer d une taille de stockage gigantesque due au cumul des disques durs. Un cluster de stockage permet surtout d'obtenir de meilleures performances. L'absence du goulot d'étranglement que représente un lien réseau unique permet un taux de transfert plus élevé. Le fichier est découpé en bloc et stocké par morceau sur plusieurs disques. Virtuellement, l'espace de stockage semble ne faire qu'un et notre fichier semble stocké sur un seul disque. Le cluster distribue les données par l'intermédiaire de plusieurs disques répartis sur les différents noeuds du cluster. Ainsi, tout utilisateur aura le loisir de travailler avec des fichiers de très grandes tailles, tout en minimisant les transferts. Clusters à haute disponibilité Les clusters dits à haute disponibilité ont été créés pour prévenir les failles matérielles et logicielles d'une machine, ceci afin de garantir la disponibilité de l'ensemble des services d'un système. La redondance, le fonctionnement du cluster et l'assurance contre les pertes peuvent ainsi être garanties à 99,9%. Son utilisation est courante dans le domaine des serveurs Web, ftp, fichiers, La figure 1-2-1 montre un exemple simple de cluster à haute disponibilité. Son fonctionnement est le suivant : lorsque le serveur principal (nœud 1) fonctionne normalement, il envoi un signal heartbeat au nœud 2. Lorsque le nœud 2 ne reçoit plus le signal provenant du nœud principal, il prend l identité complète de celui ci, ainsi, c'est le second serveur qui prend le relais. L utilisateur ne sera quasiment par perturbé, il ressentira juste un temps de réponse plus long. Figure 1-2-1 : Exemple de cluster à haute disponibilité Clusters avec répartition de charge (Load-Balanced) Le noeud serveur, en fonction de la charge des machines, alloue à telle ou telle machine le processus à effectuer. Dans le domaine des serveurs ftp et web, le clustering à répartition de charge est en général couplé à un cluster à haute disponibilité. La répartition de charge permet par exemple de migrer un processus Apache d'une machine surchargée vers une autre machine. Ce type de cluster peut aussi être utilisé dans le cas des serveurs d'applications où de multiples utilisateurs effectuent diverses opérations. Ces clusters se rapprochent des clusters de calculs. Ces clusters reposent sur des algorithmes dont voici quatre exemples (extrait de chez Microsoft) : Round-robin (répartition de charge équitable). L algorithme répartit de façon identique la charge entre chaque noeud, quels que soient le nombre actuel de connexions ou les temps de réponse. Cet algorithme est adapté si les serveurs du cluster disposent des mêmes capacités de traitement. Dans le cas contraire, certains serveurs risquent de recevoir plus de requêtes qu'ils UFR Sciences de Toulon - 4-2004/2005

ne peuvent en traiter tandis que d'autres n'utiliseront qu'une partie de leurs capacités. Weighted Round-robin (répartition de charge pondérée). Cet algorithme prend en compte la capacité de traitement de chaque serveur. Des coefficients de performance sont affectés aux noeuds et un ordre est généré automatiquement en fonction de ces valeurs. Les demandes sont ensuite affectées aux différents noeuds selon une séquence faisant intervenir ces pondérations. Least-connection (répartition de charge selon la moindre connexion). L'algorithme Leastconnection envoie les demandes au noeud qui sert actuellement le moins de connexions. Load-based (répartition basée sur la charge). L algorithme Load-based envoie les demandes au noeud dont la charge actuelle est la plus faible. 1.3 Différents types de cluster Clusters propriétaires IBM, SUN, Packard Bell, Compaq, Fujitsu et Microsoft possèdent leur propre système de clustering. L'inconvénient majeur de ces systèmes est qu'ils ne sont pas compatibles entre eux. De plus l'installation de tel système oblige des prestations de maintenance auprès du fournisseur. Le coût pour un cluster scientifique est d'environ 100 000. Bien entendu, ce chiffre ne représente rien au regard des architectures ultra-puissantes (supercalculateur) coûtant quant à elles plusieurs millions d'euros. Clusters commerciaux Il s'agit ici de systèmes proposés par des sociétés de services en informatique. Ils utilisent majoritairement des distributions Linux pour appuyer leur développement. Cette forte utilisation des distribution Linux est du au fait que les fournisseurs souhaitent garder une certaine"généricité" sur les systèmes proposés. Un tel système coûte environ 50 000. Clusters Linux Le caractère pseudo gratuit de ce type de clustering réside dans le fait que ces systèmes ne sont pas livrés prêts à l emploi. Un investissement humain est nécessaire pour mettre en place le cluster. Cette solution reste la moins onéreuse en termes d installation mais surtout de maintenance, à condition qu'une personne qualifiée puisse assurer ces tâches. 1.4 Principaux clusters Linux Distributed.net Ce cluster est le plus grand au monde, en nombre de machines, mais aussi parce qu il est reparti sur toute la planète. Le client est disponible quelque soit l architecture de la machine, mais aussi quelque soit le système d'exploitation : Windows, Linux, BSD, FreeBSD, Solaris, AIX, etc. Grâce à ce client, tout ordinateur devient un nœud connecté à Internet. Le but de ce cluster gigantesque est de trouver (challenge) des clefs d algorithmes de cryptage. En 1998, Distributed.net a cassé un code DES- II 56 bits en 40 jours. De même la clef du code RC5-32/12/7 56 bits fut cassée en 250 jours. D autres challenges sont en cours sur www.distributed.net. LVS LVS est un projet clustering à répartition de charge. Il permet de gérer la répartition de charge du réseau TCP/IP entre ces noeuds. Le procédé qu'utilise le serveur LVS est assez simple : il se charge de connaître automatiquement les serveurs disponibles et d'en attribuer la charge à ceux qui en sont le plus capables. Si un serveur devient indisponible, le noeud serveur LVS renvoie les différentes requêtes vers un autre serveur disponible. Ce cluster peut être utilisé pour des applications à haute disponibilité. UFR Sciences de Toulon - 5-2004/2005

Beowulf Beowulf est un cluster à répartition de charge. Les appels effectués vers la machine virtuelle seront en réalité exécutés en fonction de la puissance et de la disponibilité de chaque noeud. Le système va constamment vérifier l'occupation des noeuds et y répartir tous les processus en cours. Cependant, il est nécessaire de souligner qu un même processus ne pourra pas être fragmenté sur plusieurs nodes. Ce système comporte habituellement un noeud serveur, et un ou plusieurs noeuds clients. Beowulf utilise les éléments suivants : Parallel VirtualMachine (PVM) et Message Passing Interface (MPI). De grandes machines Beowulf peuvent avoir plus d'un noeud serveur. Un des principaux avantages de ce cluster est la possibilité d installation des nœuds sans disque (diskless). C est le nœud serveur qui les paramètres après qu ils aient démarré en réseau. Alinka Raisin Raisin est un outil propriétaire, permettant le clustering à haute disponibilité. Alinka Raisin est installé une seule fois sur un poste maître, utilisé ou non pour le calcul. Une simple disquette de boot est suffisante pour ajouter de nouveaux nœuds. Chaque nouveau nœud demande son adresse IP par requête bootp et monte son système de fichiers par NFS. Le poste maître gère ensuite le partitionnement et le formatage des disques durs pour un fonctionnement autonome des nœuds. Oscar (Open Source Cluster Application Ressources) Oscar est un projet GPL soutenu par Dell, IBM et Intel fournissant du cluster de calculs. Oscar est en ensemble de programme qui permettent l utilisation et l administration d un cluster. Il se rajoute sur une distribution de manière générale sur une station de travail déjà installée. Il est prévu pour fonctionner avec les distributions basées sur le système de paquets RPM. Clic (Cluster Linux Calcul) Il s agit d un cluster de calcul soutenu par MandrakeSoft, Bull et l'id-imag. La politique de Mandrake apparaît dans ce cluster : automatiser au maximum la procédure d installation. Ce qui en fait son avantage principal, mais ce projet ne semble plus en développement, car depuis Octobre 2003 aucune mise à jour n a été effectuée. La suite du document sera consacrée au cluster Mosix, dans sa déclinaison Open Source Openmosix. 2 Openmosix 2.1 Définition Openmosix est un cluster à répartition de charge entre processus. En effet, chaque application pourra être migrée entre les nodes afin de tirer avantage de la meilleure ressource disponible. L idée principale consiste à répartir sur plusieurs machines - non pas le calcul - mais les tâches elles-mêmes. En effet, un processus ne sera pas découpé sur les différents noeuds. Openmosix offre du clustering proche du load-balancing, où un serveur noeud gère la répartition. Ici, il n'y a pas l'obligation d'avoir un noeud serveur. Si un noeud doit exécuter plusieurs tâches qui requièrent un temps CPU important, alors que ses voisins sont moins actifs : Openmosix va alors prendre la décision de migrer ces processus sur les noeuds les plus puissants et les moins actifs du cluster. Cette opération équilibre donc la charge totale sur le maximum de noeuds. Ainsi, la migration est totalement transparente. Ceci permet de disposer d une machine multiprocesseur (SMP), à la différence que les échanges de données sont plus lents en raison du passage obligatoire par le réseau. UFR Sciences de Toulon - 6-2004/2005

2.2 Installation La première solution d'installation consiste à patcher le noyau (http://openmosix.sourceforge.net) et à installer Openmosix avec les codes sources ou directement à l'aide de binaires disponibles sous forme de paquets (.rpm ou.deb). Dans ce cas il est nécessaire de démarrer l installation sur la base d une version 2.4.26 ou inférieur du noyau et de recompiler celui-ci après avoir appliquer le patch Openmosix. En effet à ce jour, il n'existe pas de patch officiel pour Openmosix avec des noyaux plus récents. Voici en détail la procédure d installation sous Debian : Récupérer les sources du noyau : # apt-get install kernel-source-2.4.24 Après cela, vous trouverez un fichier compressé dans /usr/src : /usr/src/kernel-source-2.4.24.tar.bz2 Il faut décompresser ce fichier : # cd /usr/src tar vxjf kernel-source-2.4.24 Récupérez le patch du noyau : Soit avec apt-get : # apt-get install kernel-patch-openmosix Celui si ne semble pas toujours bien s appliquer, il est préférable de télécharger le patch directement sur le site d Openmosix : http://www.openmosix.org. Voici, un lien direct : http://belnet.dl.sourceforge.net/sourceforge/openmosix/openmosix-2.4.24-2.bz2 Il faut ensuite le mettre dans copier dans /usr/src et le décompresser : # cp openmosix-2.4.22-1.bz2 /usr/src # tar vxjf openmosix-2.4.22-1.bz2 Patchez le noyau : Créer un lien symbolique. Cette étape vous permettra de vous rappeler le dernier noyau utilisé : # ln s /usr/src/ kernel-source-2.4.24 /usr/src/linux Patcher le noyau: # patch p0 < openmosix-2.4.22-1 Configurez le noyau : Récupérer la dernière version de votre configuration du noyau (optionnel). # cp /boot/config-votre_noyau_actuel /usr/src/linux Configurer votre noyau : # cd /usr/src/linux # make oldconfig La commande make oldconfig détecte les nouvelles modifications apportées. Répondez affirmativement à toutes les questions qui concernent Openmosix. UFR Sciences de Toulon - 7-2004/2005

Compilez le noyau et mettez le en place : Lancez la compilation : # make dep # make bzimage Copiez le noyau compilé dans le répertoire /boot en le renommant en vmlinuz (standard) : # cp /usr/src/linux/arch/i386/boot/bzimage /boot/vmlinux-2.4.22-omosix Copiez la nouvelle configuration dans le même répertoire : # cp /usr/src/linux/.config /boot/config-2.4.22-omosix Copiez le fichier System.map toujours dans /boot : # cp /usr/src/linux/system.map /boot/system.map-2.4.22-omosix Modifiez votre secteur de boot en éditant le fichier de configuration de Lilo : /etc/lilo.conf Ajouter les lignes suivantes : image=/boot/vmlinux-2.4.22-omosix label=linux-2.4.22-omosix read-only Et modifiez éventuellement la ligne default : default=linux-2.4.22-omosix Modifiez le secteur de boot : # lilo -v Si aucune erreur n a été commise vous devriez avoir la ligne : Add Linux-2.4.22-Omosix * Il faut alors redémarrer la machine et sélectionner le noyau Linux-2.4.22-Omosix. Installez Openmosix # apt-get install openmosix Lancez Openmosix # /etc/init.d/openmosix start Si tout à fonctionné correctement vous devriez obtenir un message finissant par : «openmosix configuration was successful :)» La seconde solution consiste à récupérer le noyau patché, qui est disponible pour la distribution Debian sur http://public.planetmirror.com/pub/clusterknoppix. Installer le noyau : kernel-image-2.4.24-openmosix-1_10.00.custom_i386.deb # dpkg i kernel-image-2.4.24-openmosix-1_10.00.custom_i386.deb Une troisième solution consiste dans l'utilisation d un LiveCD, tel que ClusterKnoppix (http://bofh.be/clusterknoppix/). C'est à partir de cette distribution installée sur disque dur que tous les tests suivants ont été effectués, cette version possède un noyau récent, pacthé Openmosix, qui reconnaît les disques durs S-ATA. UFR Sciences de Toulon - 8-2004/2005

2.3 Configuration Le fichier de configuration permettant d'ajouter différents noeuds au cluster est /etc/openmosix.map. La syntaxe est la suivante : ID_noeud Host Nombre_de_noeud # Ici est définie une machine 192.168.0.211 1 192.168.0.211 1 # Ici sont définies les 15 machines de 192.168.0.1O1 à 192.168.0.115 2 192.168.0.1O1 15 Note : dans les dernières versions de Openmosix (0.3.4) il n'est plus nécessaire de renseigner ce fichier, un démon d'openmosix (omdisc) découvre automatiquement par broadcast, les nœuds présents sur le réseau. Les autres fichiers de configuration se situent dans /proc/hpc/, /proc/mosix pour les anciennes versions. Les valeurs des fichiers du répertoire /proc/hpc/admin représentent la configuration actuelle. La configuration peut se faire soit en éditant les fichiers, soit en utilisant la commande mosctl. Par exemple si l'on souhaite bloquer l'arrivée de processus : # mosctl block Et inversement: # mostctl noblock Options principales : block bring expel lstay mospe nomfs stay Interdit l'arrivée de processus. Renvoie tous les processus locaux sur leur noeud d'origine. Renvoie tous les processus locaux sur leur noeud d'origine et interdit d'en recevoir de nouveau. Utile lorsque l'on souhaite arrêter la machine. Interdit aus processus locaux de migrer mais autorise les processus étrangers à être migré. Contient l'id du nœud. Interdit l'utilisation de MFS («partage du systèmes de fichiers»). Interdit la migration des processus sur d'autre noeud. Informations sur les autres noeuds /proc/hpc/nodes/[id_du_noeud]/cpus Nombre de CPU du nœud. /proc/hpc/nodes/[id_du_noeud]]/load Charge CPU. /proc/hpc/nodes/[id_du_noeud]]/mem Mémoire de la machine utilisée. /proc/hpc/nodes/[id_du_noeud]]/rmem Mémoire libre de la machine. /proc/hpc/nodes/[id_du_noeud]]/speed Vitesse du noeud. /proc/hpc/nodes/[id_du_noeud]]/status Statut du noeud. /proc/hpc/nodes/[id_du_noeud]]/tmem Mémoire totale. /proc/hpc/nodes/[id_du_noeud]]/util Utilisation du noeud (%). UFR Sciences de Toulon - 9-2004/2005

Informations sur les processus /proc/[pid]/cantmove Raison pour laquelle le processus n'a pas été migré. /proc/[pid]/lock Si le processus est bloqué sur le noeud. /proc/[pid]/nmigs Temps depuis lequel le processus a été migré. /proc/[pid]/where Nœud sur lequel le processus est traité. /proc/[pid]/goto Nœud sur lequel le processus sera migré. /proc/hpc/remote/from Noeud d'origine du processus. /proc/hpc/remote/identity Informations sur le processus. /proc/hpc/remote/statm Taille mémoire du processus /proc/hpc/remote/stats Taux CPU du processus 2.4 Commandes et outils d'openmosix Les commandes suivantes sont disponibles : mosmon - moniteur Openmosix. Il affiche au sein d une console l'état des nœuds : charge CPU, mémoire installée, utilisée, etc mtop - version améliorée de la commande top qui affiche sur quel nœud les processus sont exécutés. mps - version améliorée de ps qui affiche les numéros de nœud des processus. mosctl whois ''ID_noeud'' - affiche l'adresse IP ou le nom d'hôte du nœud. "mosctl'' est la commande d'administration de Openmosix (voir man mostcl). migrate PID [noeud] - permet de forcer la migration d'un processus [sur un noeud]. mosrun - Permet de définir des options sur le lancement du programme. mosrun -h/-l prog -h : interdit la migration. -l : force la migration. openmosixcollector: démon d enregistrement des traces. Il permet de collecter en temps réel les informations de charge sur les noeuds du cluster et de les stocker dans /tmp où elles pourront être exploitées graphiquement par le programme openmosixanalyser. Pour démarrer le démons de collecte d information : # /etc/init.d/openmosixcollector start ou # openmosixcollector -d UFR Sciences de Toulon - 10-2004/2005

Les outils graphiques: openmosixview : C'est le programme principal d'administration graphique et de monitoring. Cette fenêtre principale permet de visualiser les informations de chaque noeud du cluster : adresse IP, numéro de noeud, nombre de processeurs, charge CPU, taux d'occupation mémoire, efficacité de la répartition de charge sur l'ensemble des noeuds, et un poids relatif à la puissance CPU de chaque noeud. Ce poids est calculé sur la base de plusieurs paramètres tels que la puissance du processeur. Cependant, l'utilisateur peut modifier cette valeur par l'interface graphique (ou mosctl setspeed) afin de forcer l'utilisation d'un nœud ou, à l inverse, forcer l'inactivité d'un noeud que l'on souhaite laisser libre. Figure 2-3-1 openmosixview. openmosixprocs : Tableau des processus dont les informations fournies sont semblables à celle de mtop. Cette utilitaire offre, en outre, la possibilité de gérer la migration des ces processus. Ces derniers sont identifiables aisément grâce à leur couleur verte). Figure 2-3-2 openmosixprocs. UFR Sciences de Toulon - 11-2004/2005

openmosixanalyzer : analyseur des traces du démon penmosixcollector (évolution de la charge CPU et mémoire). Dans la figure 2-3-3, deux augmentations de charge apparaissent. Figure 2-3-3 : openmosixanalyzer. openmosixmigmon : Graphique qui représente différents noeuds avec les liens des processus migré. Chaque noeud est représenté sous la forme d'un cercle autour desquels gravitent les processus qui s y exécutent. Cette fenêtre offre à l'utilisateur des possibilités d'interaction. Il est possible de glisser/déposer un processus sur un noeud à l aide de la souris. Dans l exemple de la figure 2-3-3 la machine 111 a migré 4 processus (en vert) sur la machine 112. En sélectionnant une de ces quatre tâches, il est possible de la faire glisser sur la machine 111 (et vice versa). Cette action aura pour conséquence de migrer le processus correspondant sur le nœud 111. Figure 2-3-3 openmosixmigmon UFR Sciences de Toulon - 12-2004/2005

openmosixhistory : historique des processus. Le programme fournit dans le temps les processus lancés. On obtient les mêmes informations qu openmosixprocs mais à différents moments. 2.5 Exemples de tests Pour commencer, vérifiez que la migration des processus fonctionne. Lancez la commande suivante plusieurs fois et vérifiez que des processus ont été migrée à l'aide de la commande mtop. # awk 'BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}' & # mtop PID USER PRI NI SIZE RSS SHARE STAT N# MGS %CPU %MEM TIME COMMAND 3457 root 14 0 588 584 516 R 0 0 96.6 0.1 0:06 awk 3461 root 14 0 588 584 516 R 0 0 95.0 0.1 0:05 awk 3454 root 17 0 112 112 36 S 103 1 72.4 0.0 0:07 awk 3451 root 17 0 108 108 36 S 112 1 70.9 0.0 0:06 awk 3453 root 14 0 108 108 36 S 112 1 66.4 0.0 0:08 awk 3456 root 19 0 108 108 36 S 103 1 66.4 0.0 0:07 awk 3455 root 20 0 112 112 36 S 112 1 63.3 0.0 0:07 awk 3459 root 14 0 108 108 36 S 103 1 63.3 0.0 0:05 awk Les processus sont bien exécutés sur les différents noeuds. L'exemple suivant consistera à encoder 6 chansons*. L'encodage, qui transformera des fichiers wav en ogg, est lancé sur le seul ordinateur 192.168.0.111. Rappel : mosrun -h force l'exécution local du processus. # time $(for i in *.wav; do mosrun -h oggenc "$i" & done) real 3m11.317s user 0m55.420s sys 0m21.130s L'encodage dure 3m11s. Un seul nœud, le 111, sur lequel la commande a été lancée, est utilisé comme le montre le graphe suivant : Figure 2-4-1 Utilisation d une seule machine 111 du cluster (openmosixview) * : la création de mp3 (ou autre format) à partir de cd audio est interdite en France, de plus le piratage nuit à la création artistique. UFR Sciences de Toulon - 13-2004/2005

La commande est ensuite lancée normalement, sans forcer le processus à s'exécuter localement: # time $(for i in *.wav; do oggenc "$i" & done) real 1m9.305s user 0m37.630s sys 0m2.880s Maintenant l'encodage dure au total 1m9.305s. Les graphiques suivants sont obtenus : Figure 2-4-2 : utilisation de toutes les machines du cluster. La colonne overall load de la figure 2-4-2 montre la répartition équitable entre les neouds. Figure 2-4-3 : tableau des processus et détail d'un processus migré. La fenêtre de droite (openmosixprocs) affiche les processus lancés. Les processus migrés apparaissent en vert, lorsqu un double clic est effectué sur l un d eux la fenêtre de droite apparaît. Il est alors possible d interagir sur le processus. Il peut alors, être renvoyé sur son nœud d origine, envoyé vers un nœud plus rapide, bloqué sur ce nœud ou encore être détruit. UFR Sciences de Toulon - 14-2004/2005

Figure 2-4-5 : topologie des noeuds et des processus. Ici lors de la capture d écran, deux processus avaient migré vers le nœud 112 et 3 vers le 103. Comme expliqué dans la présentation d openmosixmigmon (chapitre 2-3), il est possible de faire glisser un processus du nœud 103 vers la nœud 112. Bilan des tests Le temps d encodage est donc passé de 3mn10s à 1mn09s, soit quasiment trois fois moins de temps. Les résultats sont en accord avec nos espérances car l on disposait de trois fois plus de ressources. Si nous effectuons le calcul, nous nous s apercevons que théoriquement le temps total avec les trois machines aurait du être de 1m03s. Cette différence est due au fait que le transfert des processus, mais surtout le transfert des données traitées sur une autre machine du réseau prend du temps. Ici, les fichiers wav occupaient près de 50 Mo, ce qui correspond précisément aux six secondes perdues lors du transfert sur le réseau. En effectuant un test avec des processus de petite taille, et en faisant des calculs, le temps a précisément été divisé par trois. 3 Avantages et inconvénients de Openmosix 3.1 Avantages Openmosix peut fonctionner avec une architecture matérielle hétérogène. Son utilisation est transparente. L'utilisateur croit avoir à faire à une seule machine et aucune action supplémentaire n est nécessaire de sa part. Le coût d'un cluster Openmosix est beaucoup plus faible que celui d'un supercalculateur. UFR Sciences de Toulon - 15-2004/2005

Le système est autonome, il régule sa charge automatiquement, les interventions de l'administrateur sont extrêmement réduites. L'utilisateur peut contrôler et agir sur les processus depuis un seul noeud. La configuration de cluster Openmosix est automatique grâce à la découverte automatique des noeuds présents sur le réseau (omdiscd). Son utilisation et son administration à travers Openmosixview est très simple. Un autre atout important est que le projet est en constante évolution. De nombreuses amélioration yont récemment été apportées : La migration des threads et des programmes à mémoire partagé, comme Apache, est supportée à l'aide du patch ''Migshm''. Un masque logique permet de spécifier un ensemble de noeuds vers lesquels on autorise les processus à migrer. Une reprise à chaud des processus (checkpoint) dans le cas ou un noeud aurait dû être arrêté subitement. 3.2 Inconvénients Openmosix ne fonctionne pas sous Windows, la cause est qu il dépend du noyau Linux. Openmosix est un cluster à répartition de charge par processus : Lancer un seul processus gourmand sur une machine du cluster n apporte pas de gain de performance. Le processus ne sera pas fragmenté sur les différents nœuds. Les processus s'exécutant très rapidement et qui ne durent pas suffisamment longtemps en mémoire, ne bénéficient pas des algorithmes de migration d Openmosix. La version Migshm manque de stabilité. En effet plusieurs crashs système ont eu lieu lors de différents tests. La migration de processus Apache entraîne quelque fois un plantage système. Il est important de noter, qu à la date d aujourd hui, les différentes études sur Migshm confirment que le patch n est pas prêt à passer en production du fait de son instabilité. Si aucune librairie de programmation n'est requise pour tirer parti d Openmosix, il est préférable en revanche, de bien concevoir son application et d'écrire des programmes très modulaires qui lancent des processus par fork() et exec(). CONCLUSION Aucun cluster n'est parfait, c'est pour cela que les différentes solutions sont complémentaires entre elles. Pour les serveurs Web, une combinaison de clusters à répartition de charge et à haute disponibilité est nécessaire. Openmosix est une solution simple et peu onéreuse pour des besoins de cluster à répartition de charge. Openmosix s'affiche donc comme une solution idéale dans le cadre d'un serveur d'applications : grâce à lui, tous les utilisateurs connectés à distance disposent de performances constantes. D'autres questions peuvent alors se poser sur l'utilisation d'un tel procédé, du point de vue de la sécurité. Un point a déjà été résolu avec la possibilité d'utiliser une connexion SSH entre les nœuds. Mais ne serait-il pas possible pour un utilisateur malveillant et averti, d analyser en mémoire les processus qui ont été migrés sur sa machine? C est pour cela qu à mon avis les nœuds d un cluster ne devraient pas être des stations de travail comme dans le projet de clustering Oscar. UFR Sciences de Toulon - 16-2004/2005