MOSIX fait d'un ensemble de machines un cluster de puissance, les solutions retenues pour sa réalisation et sa mise en oeuvre sont originales, terriblement efficaces et offrent des possibilités uniques. La mise en production d'un cluster MOSIX ne nécessite pas de modification des applications, contrairement aux solutions basées sur des appels à des bibliothèques de passage de messages, comme PVM ou MPI.
MOSIX
MOSIX est un outil relativement méconnu dans l'offre des outils de clustering sous Linux. Nous allons tenter dans cet article
de vous présenter ce produit, intéressant sous bien des aspects. Développé par l'université de Jérusalem, MOSIX est un environnement
purement logiciel permettant de transformer un ensemble de machines en une machine de calcul.
Du déjà-vu, direz-vous ... Pas tant que cela. En effet, si MOSIX fait d'un ensemble de machines un cluster de puissance,
les solutions retenues pour sa réalisation et sa mise en oeuvre sont originales, terriblement efficaces et offrent des possibilités
uniques. La mise en production d'un cluster MOSIX ne nécessite pas de modification des applications, contrairement aux solutions
basées sur des appels à des bibliothèques de passage de messages, comme PVM
ou MPI.
MOSIX effectue toutes les opérations de répartition et de synchronisation de façon transparente, comme si l'environnement était celui
d'un système SMP. Ceci permet par exemple de créer autant de processes que l'on veut à partir d'une seule machine, et de laisser
les couches logicielles de MOSIX gérer ces processes sur l'ensemble des machines du cluster, en conservant à partir de la machine
originale la possibilité de voir les processes (avec un simple ps) comme s'ils étaient toujours tous sur cette même machine.
MOSIX est basé sur un ensemble d'algorithmes adaptatifs de gestion des ressources qui supervisent et gèrent en temps réel
la répartition de la charge, même non équilibrée, afin de garantir une performance optimale de l'ensemble des processes.
Pour ce faire, MOSIX utilise la migration préemptive des processes afin d'assurer leur migration entre les noeuds du cluster
et de donner à chaque process les ressources dont il a besoin. Contrairement à des appels à des modules de bibliothèques
qui s'effectuent en contexte utilisateur, puis qui passent éventuellement en mode kernel à traver un coûteux changement de contexte,
MOSIX est implémenté directement dans le noyau Linux.
Cette stratégie garantit de meilleures performances et une totale indépendance des applications avec l'environnement,
exactement comme dans une machine SMP, et au contraire d'une machine Beowulf
classique. Egalement en raison de cette indépendance, MOSIX permet de définir des clusters de différents types, et des clusters composés
de machines différentes, ou interconnectées par des réseaux différents.
Chaque application peut être développée en mode séquentiel ou parallèle, et chaque utilisateur du cluster MOSIX n'a pas à se préoccuper
des autres utilisateurs de la machine, ni même de la machine sur laquelle ses processes s'exécutent. Encore une fois,
on a le comportement d'une machine SMP dans un cluster.
La structure de MOSIX est répartie, c'est-à-dire que chaque noeud du cluster est à la fois maître des processes qui ont été créés
localement d'une part, et serveur de processes distants, c'est-à-dire des processes ayant été migrés d'autre part.
Cette architecture permet donc d'assurer une évolutivité de la configuration cluster, par adjonction ou suppression de systèmes,
en assurant une perturbation minimale pour les applications en cours d'exécution : la haute performance rejoint ici la disponibilité.
De plus, MOSIX utilise pour ses opérations de surveillance continuelle de l'état du cluster, des algorithmes de surveillance
et de paramétrage automatique. Il est ainsi capable de prendre en compte les performances et les paramètres de chaque noeud
et d'utiliser ces informations lors des décisions de migration des processes.
MOSIX a été développé initialement pour BSD, Linux étant le portage le plus récent. A ce jour, seules les distributions Linux
pour machines à architecture processeur IA-32 (Intel, AMD, Cyrix) supportent MOSIX, mais des portages nouveaux, sur Alpha en particulier,
sont à espérer dans un futur proche. Le modèle système de MOSIX est basé sur le modèle UHN (Unique Home Node), dans lequel l'ensemble
des processes d'un utilisateur semblent tourner sur le noeud de login. Chaque nouveau process est créé dans l'environnement
de son process parent et est identique à celui du noeud de login de l'utilisateur. Les processes migrés interagissent
avec l'environnement local à travers l'UHN, mais en utilisant les ressources locales.
Tant que la charge de la machine de login de l'utilisateur reste en dessous d'une valeur définie, les processes restent attachés
à ce noeud, mais au moment où la charge de la machine origine va dépasser le niveau fixé, la migration des processes va s'effectuer
de manière transparente et silencieuse vers les autres noeuds du cluster. MOSIX peut supporter des configurations avec un très grand
nombre de machines, la limite actuelle étant 65535, avec des déperdition de synchronisation minimales.
De la configuration de base, constituée de quelques machines de type PC interconnectées en réseau Ethernet, jusqu'aux grandes
configurations composées de stations de travail performantes et de serveurs, monoprocesseurs ou SMP, avec des réseaux Fast Ethernet
ou Gigabit Ethernet, MOSIX garantit une utilisation optimale des ressources qui lui sont confiées, en déchargeant totalement
l'utilisateur des tâches de gestion d'une telle configuration, permettant à ce dernier de se consacrer totalement à l'utilisation
de son application sans se préoccuper de la machine.
Les types de clusters
MOSIX peut gérer différents types de clusters, de type temps partagé, partitionné, ou machine de batch. Comme nous l'avons vu
précédemment, un cluster est un ensemble de machines de tous types relées en réseau TCP/IP, quelle que soit la technologie Ethernet
supportant TCP/IP.
Les machines orientées partage de temps sont typiquement des machines multi-utilisateurs. Ces machines peuvent travailler
en mode Single Pool, c'est à dire que toutes les machines du réseau vont toutes travailler au sein d'un même cluster MOSIX.
Ces machines peuvent travailler également en mode Serveur Pool, les serveurs sont partagés, tandis que les stations de travail
ne font pas partie du cluster. Le mode Adaptive Pool permet de configurer le cluster dynamiquement en fonction de contraintes
de charge ou de contraintes horaires. Le mode Half Duplex Pool permet aux stations de rester indépendantes tout en gardant
la capacité d'adresser des tâches aux machines constituant le cluster.
Si la première solution est la plus simple, elle a pour inconvénient de venir perturber les stations de travail,
c'est à dire les machines individuelles, avec une charge non contrôlée par l'utilisateur de cette station. En revanche,
cette solution permet à tout utilisateur d'accéder au cluster à partir de sa propre machine. La mise en oeuvre de cette solution
s'effectue en distribuant uniformément sur chaque noeud du cluster un même fichier de configuration, MOSIX.map,
contenant l'adresse de toutes les machines.
La deuxième solution laisse à l'utilisateur toute la puissance de sa machine, mais contraint à se connecter sur un serveur
afin de lancer une tâche cluster wide. Dans ce cas, le fichier MOSIX.map est également uniformément distribué,
mais ne contient que les adresses des serveurs.
La troisième solution, quant à elle, permet de laisser aux utilisateurs la puissance de leur machine pendant les heures ouvrables,
avant les contraintes de la deuxième solution, et de donner toutes les machines au cluster en dehors de ces heures afin de disposer
de toute la puissance de calcul pour les gros travaux. La configuration, dans ce cas, est celle de la première solution,
avec en plus une série de commandes (mosctl expel et mosctl noblock) dans le fichier crontab
de chaque station. On peut également envisager de surveiller l'activité de chaque station et d'intégrer une station au cluster
en cas d'inactivité prolongée.
La dernière solution permet à chacun de garder sa machine pour ses tâches individuelles, et d'utiliser quand même le cluster
sans passer par un login. Cette solution se met en place par la distribution de MOSIX.map comme dans le cas n°2,
mais demande en plus d'intégrer une commande mosctl expel au démarrage de MOSIX sur chaque station, dans /etc/rc.d/init.d/mosix.
Partitionnement dynamique
Le partitionnement est une opération qui consiste à diviser un cluster en sous-clusters. Il existe de nombreuses façons
de réaliser une telle opération : l'exemple suivant est celui donné dans la documentation de MOSIX :
Donner à chaque machine du cluster un identifiant unique, dans le fichier /etc/mospe (MOSIX Processing Element).
Préparer les possibles configurations, en prenant soin à ce qu'une machine ne se trouve que dans un seul cluster
et stocker chaque configuration dans un fichier comme /usr/clusters/combination{n}/. Créer un répertoire par configuration,
partagé et accessible, par exemple /usr/clusters/combination{n}/cluster{m}. Pour passer d'une configuration à une autre,
lancez sur chaque machine la commande mosconf (MOSIX CONFiguration), mosconf étant le script suivant :
me='cat /etc/mospe'
for conf in /usr/clusters/combination$1/*
do
case 'awk '{if('$me' >= $1 && $3 != "ALIAS" && '$me'
Mode batch
Le cluster est configuré comme une machine multi-utilisateurs à temps partagé en mode server pool, mais les requêtes
ne sont effectuées qu'à travers un programme de queuing qui gère leur passage.
Les applications de prédilection
Les caractéristiques les plus remarquables de MOSIX étant ses capacités de répartition de charge et de migration de processes
sans requérir d'intervention de la part des utilisateurs, il est particulièrement conçu pour les environnements partagés dans lequels
une application SMP forkant de multiples processes verra ces mêmes processes répartis automatiquement de la façon la plus judicieuse
et gérés en temps réel de façon à conserver la meilleure répartition possible. Les applications monolithiques multiples,
quant à elles, ne présenteront pas l'inconvénient de saturer une seule machine. Les applications de calcul intensif, avec un faible
pourcentage de communication inter processes en regard de leur temps de calcul seront donc les plus à même de tirer parti
de cet environnement. En revanche, les applications demandant un volume de communication inter processes plus important se verront
plus idéalement exploitées avec PVM ou MPI pour la mise en place initiale des processes :
Les serveurs web, demandant une puissance de calcul significative, par exemple pour des besoins statistiques.
Les clusters utilisant des machines aux performances et aux caractéristiques différentes, où les capacités d'analyse
et d'adaptation de MOSIX seront mis à profit.
Les environnements partagés et fortement sollicités, comme par exemple des environnements de développement dans lesquels
des opérations de compilation initiées par une seule personne peuvent impacter de façon significative les autres utilisateurs.
Les situations moins favorables
Les applications dépendantes de la configuration matérielle d'une machine.
Les applications requérant une communication inter processes intensive, jusqu'à la finalisation du projet de sockets migrables.
Les applications à mémoire partagée, jusqu'à la finalisation du projet network ram, qui permettra de migrer les processes
aux données, tandis qu'actuellement les données sont toujours migrées aux processes.
Mise en oeuvre de MOSIX
Contraintes
Chaque noeud du cluster doit être sur un réseau TCP/IP sous Linux.
Chaque noeud doit posséder un processeur équipé d'une unité de calcul flottante ?
Pour les machines SMP, tous les processeurs de la machine doivent être cadencés à la même fréquence.
Configuration
Le fichier /etc/mosix.map définit le cluster MOSIX en attribuant un identifiant à une adresse IP. Chaque ligne contient
trois champs :
L'identifiant du premier noeud dans le groupe (entier compris entre 1 et 65535).
L'adresse IP du premier noeud dans le groupe.
Le nombre de noeuds dans le groupe.
Si le nombre de noeuds dans le groupe est soit 0, soit le mot clé ALIAS, la ligne définit alors une adresse IP alternative pour le noeud,
ce qui est requis dans le cas où le cluster est composé de machines existant sur des réseaux différents et où la machine doit agir
comme une gateway. Ce fichier peut contenir au maximum 256 entrées, c'est-à-dire définir 256 groupes ou alias. Cette valeur
MAX_MOSNET_ENTS est codée dans /include/linux/mosctl.h.
Exemples
Si vous avez 6 noeuds, dont 3 noeuds de classe C avec l'adresse 200.200.120.xxx, 1 noeud avec l'adresse 200.200.130.xxx et 2 noeuds
avec l'adresse 200.200.140.xxx, alors votre fichier de configuration /etc/mosix.map aura la structure suivante :
1 200.200.120.1 3
4 200.200.130.1 1
5 200.200.140.1 2
Un exemple plus complexe, dans lequel 13 noeuds, 6 en 192.168.0.xxx, 6 en 192.168.1.xxx, et un routeur reliant les deux réseaux
utilisant 192.168.0.100 et 192.168.1.100, amènera un /etc/mosix.map comme suit :
1 192.168.0.1 6
7 192.168.0.100 1
7 192.168.1.100 ALIAS
8 192.168.1.1 6
Généralement, le réseau utilisé par MOSIX est le même que celui utilisé pour les autres communications. L'identifiant MOSIX
pour le noeud local est alors défini par l'adresse IP correspondant au nom du noeud. Si ce n'est pas le cas, l'identifiant MOSIX
doit être défini dans /etc/mospe. Lorsque le réseau du cluster MOSIX est partitionné par des gateways, on doit mettre 1
dans /etc/mosgates, ou 2 s'il y a plus d'une gateway entre tout noeud constituant le cluster MOSIX. MOSIX peut être activé
ou désactivé aux différents niveaux d'init de façon standard, en utilisant le run level editor ou en éditant /etc/inittab.
MOSIX doit être activé seulement après que le réseau ait été démarré (priorité 10), et stoppé avant que le réseau ne soit stoppé
(priorité 97). La migration manuelle des processes est résidente dans le noyau, et le module de gestion de charge automatique est chargé
lors de la configuration de MOSIX. Ce dernier n'est jamais désactivé automatiquement et doit donc être invalidé le cas échéant
par la commande rmmod mosix.
Administration
Le comportement de MOSIX est contrôlé à travers les fichiers présents dans le répertoire /proc/mosix/admin.
Le fichier le plus important est le fichier de configuration /proc/mosix/admin/config. Toutefois, ce fichier étant
un fichier binaire, il n'est manipulable qu'à travers l'utilitaire setpe. De la même façon, le numéro du noeud,
écrit dans /proc/mosix/admin/mospe, ne doit être modifié qu'au travers de cet utilitaire. Le nombre de gateways
entre un noeud et tous les autres noeuds du cluster doit être défini dans /proc/mosix/admin/gateways. Les valeurs possibles
peuvent être uniquement 0, 1 ou 2 et contôlent la valeur de time-out utilisée lors de la collecte d'informations sur les autres noeuds.
Mettre 1 dans /proc/mosix/admin/block permet d'interdire la migration de processes sur le noeud, tandis qu'une valeur de 0
le permet. Afin de renvoyer des processes déjà migrés sur le noeud, mettre 1 dans /proc/mosix/admin/expel.
Afin d'interdire la migration automatique de processes à partir du noeud, mettre 1 dans /proc/mosix/admin/stay, la valeur 0
établit la migration automatique. Afin de prévenir la migration automatique des processes locaux tout en autorisant la migration
des processes étrangers, mettre 1 dans /proc/mosix/admin/lstay. Pour rappeler en local des processes déjà migrés sur d'autres
noeuds, mettre 1 dans /proc/mosix/admin/bring. Mettre 0 dans /proc/mosix/admin/lstay autorise la migration des processes
locaux, sauf si /proc/mosix/admin/stay a été mis à 1.
Si l'on emploie l'utilitaire tune_kernel, il est nécessaire de mettre 1 dans /proc/mosix/admin/quiet afin de garantir
l'exactitude des résultats. Cette configuration n'est utile en aucune autre circonstances. Mettre 0 invalide le mode tune_kernel,
qu'il est conseillé de lancer après l'installation de MOSIX, et après chaque modification de la composition du cluster
Les paramètres de tuning produits par tune_kernel sont inclus dans le noyau à travers le fichier include/mos/dscosts.h.
Si vous désirez conserver ce fichier intact, afin par exemple de partager une même copie du noyau entre différents noeuds,
ou si vous utilisez temporairement un réseau différent précédemment tuné, vous pouvez copier les paramètres existants
dans /tmp/overheads sous forme d'une liste séparée par des espaces dans /proc/mosix/admin/overheads. Si un fichier
/etc/overheads est présent, il est copié dans /proc/mosix/admin/overheads par le script d'initialisation de MOSIX.
MOSIX collecte des informations sur les ressources consommées par les processes qui décroissent au fil du temps. Bien que la règle
d'appréciation du taux de décroissement puisse être spécifique à chaque process, les valeurs par défaut peuvent être modifiées
par l'administrateur. L'intervalle entre deux mesures, exprimé en secondes et initialement à 2, peut être modifié
dans /proc/mosix/admin/decayinterval. Le volume d'informations à conserver à chaque intervalle est défini par un nombre entier,
par défaut 1000. Afin de changer cette valeur, modifiez /proc/mosix/admin/slowdecay ou /proc/mosix/admin/fastdecay.
MOSIX assure qu'à tout instant la valeur donnée à slow-decay doit être supérieure ou égale à celle de fast-decay.
MOSIX mesure la rapidité du processeur au boot, par rapport à celle d'un PII-400, représentant 10000 unités de vitesse.
La performance des processeurs varie cependant en fonction des benchmarks. Si les applications s'exécutent plus ou moins vite
sur un noeud donné, il est alors possible de modifier la valeur de /proc/mosix/admin/speed. Lors de l'obtention des informations
de charge du noyau, particulièrement à travers l'utilitaire mon, 100 points de charge représentent environ une charge d'un process CPU
s'exécutant sur un processeur de référence (PII-400). Si le reste ou la plupart des noeuds fonctionnent à des vitesses différentes,
vous pouvez modifier /proc/mosix/admin/speed de telle sorte que 100 points de charge représentent une charge de un process CPU
s'exécutant sur votre système le plus caractéristique.
La plupart des fichiers dans /proc/mosix/admin peuvent aussi être lus afin de connaître leur valeur courante.
Même l'administrateur ne peut tuer ou perturber les processes migrés, si ce n'est en les ré-exportant en spécifiant le numéro
du noeud vers lequel ils devraient être envoyés, en renseignant, /proc/mosix/remote/{pid}/goto. Sans raison précise,
cette valeur doit être 0, afin de renvoyer le process migré vers son noeud d'origine. Une valeur de 1 entraînera la machine hôte
à envisager une migration avec un placement optimal.
Information
MOSIX donne les informations suivantes pour chaque process :
/proc/{pid}/where indique où le process s'exécute, 0 indiquant son noeud d'origine.
/proc/{pid}/lock/ indique si le process est ou non éligible à la migration hors de son noeud d'origine.
/proc/{pid}/nmigs indique combien de fois le process a été migré.
/proc/{pid}/cantmove contient les raisons pour lesquelles un process ne peut être migré hors de son noeud d'origine.
Les raisons peuvent être les suviantes : utilisation de mémoire partagée, accès direct au bus ou aux périphériques, appels en mode
système, utilisation de priorités temps réel.
Le répertoire /proc/mosix/remote/{pid}/ contient un certain nombre d'informations sur les processes migrés sur le noeud
local à partir d'autres noeuds. Les informations sont, pour des raisons de sécurité, volontairement limitées à l'indication
de la quantité de ressources consommées sur la machine locale.
/proc/mosix/remote/{pid}/from indique de quel noeud du cluster le process est originaire, en précisant l'identifiant
MOSIX et l'adresse IP.
/proc/mosix/remote/{pid}/stat donne les informations relatives à la consommation mémoire par process : total size,
resident size, shared-memory size (toujours à 0 sans quoi le process ne peut migrer), text pages, library pages, data pages, dirty pages.
/proc/mosix/remote/{pid}/stats donne les informations relatives à la consommation CPU :
1.utime=temps consommé en mode user depuis migration sur le noeud.
2.cutime=temps consommé par les processes fils en mode user, s'ils n'ont jamais migré.
3.nice=rang nice (priorité scheduling).
4.state="R" for running, "S" pour tout autre état.
5.vsize=taille de l'espace virtuel du process.
6.rss=nombre de pages résidentes.
7.nswap=nombre d'opérations de swap.
8.cnswap=nombre d'opérations de swap effectuées par les fils, s'ils n'ont jamais migré.
Les informations sur tous les noeuds configurés sont disponibles à travers les répertoires /proc/mosix/nodes/{node-number}.
Cela comprend :
/proc/mosix/nodes/{node-number}/cpus donne le nombre de processeurs par noeud.
/proc/mosix/nodes/{node-number}/load donne la charge courante, 100 étant la charge nominale d'une machine monoprocesseur
standard.
/proc/mosix/nodes/{node-number}/mem donne la mémoire disponible sur le noeud comme pour MOSIX.
/proc/mosix/nodes/{node-number}/rmem donne la mémoire disponible sur le noeud pour Linux.
/proc/mosix/nodes/{node-number}/tmem donne toute la mémoire disponible sur le noeud.
/proc/mosix/nodes/{node-number}/speed donne la vitesse du processeur, 10000 étant la vitesse d'un PII-400.
/proc/mosix/nodes/{node-number}/util donne l'état d'occupation de la machine, la valeur normale étant 100 fois
le nombre de processeurs.
/proc/mosix/nodes/{node-number}/status contient un nombre étant un masque de bits produit par un XOR indiquant :
1 MOSIX est configuré.
2 MOSIX est actif.
4 La migration automatique à partir du noeud est invalidée.
8 La migration automatique des processes du noeud est invalidée.
16 Le noeud n'accepte pas les processes immigrants.
32 Le noeud est en mode 'quiet'
64 Le noeud est en mode 'tune'
La même information est disponible sous forme condensée dans le répertoire /proc/mosix/info.
Contrôle manuel
Un process peut invalider le mode de migration automatique pour lui-même et ses fils en se verrouillant sur le noeud, en mettant à 1
/proc/self/lock. Remettre ensuite cette valeur à 0 n'agit que sur le process père et pas sur ses fils. Toutefois, cette option
n'empêche pas un process d'être migré vers son noeud d'origine en cas de situation extrême, comme par exemple un arrêt du système
ou une requête explicite de l'administrateur. Un process peut seulement agir sur lui-même, à l'exception du super user qui peut
dévérouiller des processes s'éxécutant sur leur noeud d'origine.
Un process peut être migré vers un noeud quelconque en mettant dans /proc/self/migrate l'identifiant MOSIX du noeud.
La valeur 0 représente le noeud d'origine et la valeur - 1 représente une demande de migration avec destination optimale.
Donner une valeur dans /proc/self/migrate prend la main sur les locks. Il n'est pas possible d'écrire
dans le /proc/{pid}/migrate d'un autre process. Afin d'effectuer la migration d'un autre process, il faut avoir le privilège
d'envoyer un signal à ce process. Il faut écrire la valeur désirée dans /proc/{pid}/goto. Un process peut indiquer à MOSIX
la nature des ressources qui vont être demandées dans les fichiers du répertoire /proc/mosix/decay :
/proc/mosix/decay/clear à 1 effectue une remise à zéro des statistiques.
/proc/mosix/decay/cpujob à 1 indique à MOSIX que le process est purement CPU.
/proc/mosix/decay/iojob à 1 indique à MOSIX que le process est purement I/O.
/proc/mosix/decay/slow à 1 indique à MOSIX d'effectuer une régression lente sur ses statistiques afin de travailler
sur un historique long.
/proc/mosix/decay/fast à 1 indique à MOSIX d'effectuer une régression rapide sur ses statistiques afin de travailler
sur un historique court.
/proc/mosix/decay/own permet de définir, sous forme de deux nombres entiers séparés par des espaces, une stratégie
de collecte précise par process. La première valeur (comprise entre 0 et 1000) indique combien de 1000 unités de collecte seront
à conserver à chaque nouvelle opération, opération s'effectuant toutes les n secondes, spécifiées par la deuxième valeur.
Le comportement d'un process étant défini par la primitive execve, non seulement ses statistiques sont remises à 0,
mais la stratégie de collecte est remise à sa valeur par défaut, basée sur le long terme. Un process désireux de préserver
sa stratégie de collecte à travers execve doit mettre /proc/mosix/decay/exec à 1. S'il désire ne préserver cette stratégie
que pour une seule fois, c'est /proc/mosix/decay/execonce qui doit être mis à 1. Un process devant pouvoir donner à ses fils,
sa stratégie de collecte doit mettre /proc/mosix/decay/inherit à 1.
Mettre les valeurs précédemment discutées à 0 annule ces options. Les modes de collecte cpu, io, slow, fast et own, sont mutuellement
exclusifs, le choix d'un mode donné invalidant les autres. Afin de déterminer la stratégie courante, lire les fichiers
/proc/mosix/decay/cpujob, /proc/mosix/decay/iojob, /proc/mosix/decay/slow, /proc/mosix/decay/fast, /proc/mosix/decay/exec,
/proc/mosix/decay/execonce et /proc/mosix/decay/inherit. Un 1 indique un mode validé et 0 un mode invalidé.
/proc/mosix/decay/own donnera les deux paramètres précédemment discutés si ce mode est actif, autrement deux 0.
Sécurité
Tous les noeuds d'un cluster MOSIX doivent être sûrs de chaque super user sur les autres noeuds, car le super user sous Linux
a le pouvoir d'émettre et de recevoir des paquets IP bas niveau. Ceci implique que tous les noeuds d'un réseau MOSIX doivent être
sur un réseau sûr. Sur le réseau utilisé par MOSIX, transitent des informations sensibles relatives à la communication inter noyaux
ne devant pas passer entre des mains mal intentionnées. Il faut donc être sûr que les tentatives de masquerading, visant à faire
passer une machine étrangère pour un des noeuds du cluster, ne puissent pas être effectuées. Cette garantie s'obtient généralement
en mettant en place un routeur ou un firewall.
Installation de Mosix
Les kits rpm existant pour les distributions Red Hat, SuSE et Mandrake. Et bien que MOSIX travail au niveau du kernel,
l'installation s'effectue de façon classique, si ce n'est qu'il est nécessaire de rebooter la machine une fois l'installation effectuée
afin que le nouveau kernel soit chargé. Les deux kits à charger sont :
[root@ecrehous /root]# ls *mos*.rpm
kernel-mosix-0.97.7-2.2.16.i386.rpm
mosix-redhat-0.97.7-1.i386.rpm
Le premier kit (kernel) contient le nouveau noyau et les modules associés. Il va venir non pas remplacer le noyau précédemment existant
sur votre machine, mais en ajouter un nouveau que vous devrez intégrer à votre boot manager afin de garder
le contrôle des événements si les choses devaient poser problème. Le second kit, particulier pour chaque distribution,
contient les binaires des commandes propres à MOSIX, ainsi que les pages man pour chacune de ces commandes. Ces fichiers étant répartis
dans l'arborescence standard, il sera bon de conserver la sortie d'une commande rpm -qlp afin de conserver une liste
de ce qui aura été installé, au moins jusqu'à ce que vous soyez familier avec cet environnement.
Conclusion
MOSIX est un outil fabuleux. Cet article a été réalisé en s'appuyant très largement sur l'excellente documentation disponible
sur le site web de l'université de Jérusalem. Les illustratons sont difficiles à produire, tant ce produit sait se faire discret
et travail en profondeur et en silence. Pour les amateurs d'interfaces d'administration graphiques, sachez cependant
que les environnements produits par Alinka, Orange et Raisin, integrent MOSIX. Le seul regret
est de ne pas disposer de MOSIX à ce jour pour les plates-formes Alpha/Linux, mais l'auteur invite toutes les personnes intéressées
par cette possibilité à le contacter afin de permettre à ce portage de voir le jour bientôt.
Références
http://www.mosix.cs.huji.ac.il
http://www.alinka.com
Christophe Le Cannellier
Linux Magazine France n°20 - Septembre 2000
|
