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' < $1 + $3)\
print "Found" ; next)' < $conf' in Found)
setpe -w -f $conf
exit ;;
esac
done
# no configuration found
setpe -off
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 situations moins favorables
Mise en oeuvre de MOSIX
Contraintes
Configuration
Le fichier /etc/mosix.map définit le cluster MOSIX en attribuant un identifiant à une adresse IP. Chaque ligne contient trois champs :
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 :
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 :
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 :
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