Créé en 1979, "UNIX with Satellite Processors" fut la première version de ce que nous appelons aujourd'hui MOSIX. Développé à l'origine pour le monde Unix et les ordinateurs spécialisés (comme les VAX 780), MOSIX a su se recentrer sur le monde du PC en 1992. Depuis cette date, les développeurs de MOSIX sont passés d'une plate forme de développement BSD à une plate forme Linux.
Le but premier de l'équipe de développement de MOSIX (basé à l'université hébraïque de Jerusalem) est de fournir un système en clustering, à travers Linux, agissant comme une simple machine vu de l'extérieur (c'est à dire vu des utilisateurs et des processus).
L'idée est fort simple et les initiales de MOSIX permettent de résumer très rapidement le fondement de ce projet de clustering. Ainsi, MOSIX signifie :
Multicomputer Operating System for UnIX
MOSIX va donc permettre de distribuer des tâches et des processus à travers un ensemble de machines en réseaux et spécialisées dans l'éxécution parallèle de processus. Dans la suite, nous allons voir plus en détails comment MOSIX s'y prend pour réaliser cette lourde tâche.
MOSIX est donc un cluster à répartition de charges entre processus. En effet, chaque application pourra être migrée entre les nodes afin de tirer avantage de la meilleure ressource disponible. Son idée principale consiste à répartir sur plusieurs machines, non pas le calcul, mais le multitâche.
En fait, MOSIX peut être divisé en deux modules internes : une partie gérant le mécanisme préemptif de migration de process (PPM), et une autre gérant un ensemble d'algorithmes permettant la migratation et le partage de ressources sur le cluster. Ces deux fonctions permettent ainsi un monitoring régulier des processus, afin de les déplacer pour optimiser les performances du système.
Ainsi, Pour mettre en oeuvre ce cheminement, MOSIX est disponible comme application sous forme d'extension et d'enrichissement du noyau Linux. Il s'agit en fait d'appliquer quelques patchs sur le kernell et d'y ajouter quelques applications pour que votre node se transforme en une entité d'un cluster MOSIX. Cette implémentation en temps que module noyau permet à MOSIX de travailler au même niveau que le kernell et donc d'assurer un maximum de transparence aux applications, qui n'ont alors pas besoin d'être adaptée ou recompilée.
En réalité, MOSIX utilise un algorithme dit de "fork and forget" pour permettre une migration totalement transparente aux yeux d'un utilisateur. Chaque nouveau processus sera alors assigné automatiquement par MOSIX à la ressource la plus apte à répondre le plus rapidement à la requête.
Toutefois, MOSIX utilise un mécanisme de priorité sur ces processus, et ceci afin de ne pas perturber le réseau de manière intempestive. En effet, lors de la création d'un processus, celui ci est en priorité exécuté sur la machine locale. A partir du moment où cette machine commencera à perdre en performance, le système répartira sur la machine la moins chargée le processus en question. Ce point introduit la capacité de MOSIX à pouvoir optimiser de façon constante la répartition des processus au sein du système.
Enfin, en plus d'être performant et surtout peu commun (cluster de tâches système), MOSIX se trouve être l'un des projets de clustering les plus simples à mettre en oeuvre sous Linux. En fait, il vous suffit de posséder au minimum deux PC (l'hétérogénïté des matériels ne perturbent pas le fonctionnement de MOSIX) sous Linux (la distribution que vous voulez), le tout interconnecté par un réseau TCP/IP. Bien entendu, dans la mesure où votre cluster tend à grossir, il serait préférable de posséder des éléments réseaux performants. Il vous faudra compter à peu près une journée de travail complète, lire la documentation, préparer votre architecture, installer et configurer MOSIX sur une dizaine de nodes. Bien entendu, il vous faudra rallonger ce temps, si votre sytème comporte plus de noeuds ou si les nodes se trouvent être trop hétérogènes....
MOSIX s'affiche donc comme étant une solution adaptée au domaine de l'administration système, tout en gardant un certain standard dans sa conception, lui permettant alors de toucher un panel plus large d'applications et de proposer plusieurs solutions de clustering système.
Grâce à ses capacités, MOSIX peut désormais répondre à plusieurs types de clusters. Par types, j'entends les manières différentes de concevoir un cluster MOSIX, en fonction du matériel et de sa disponibilité.
Le premier type de clusters que vous pouvez concevoir est appeler un "single pool". En fait il s'agit d'interconnecter en tant que nodes, des serveurs et des stations de travail. En tant que workstation c'est un avantage car vous pouvez tirer parti de toutes les capacités d'un serveur, mais cela peut aussi être un inconvénient dans la mesure où votre PC servira lui aussi de machine de traitement.
Le deuxième type de clusters est dit "server pool". Là, il s'agit de n'interconnecter que les serveurs au sein du cluster. Ici, vos stations de travail ne font plus partie du cluster et donc ne sont plus utilisées pour éxécuter les tâches réparties sur le système. Toutefois, cette méthode à le désavantage de devoir se connecter sur un des serveurs afin de pouvoir utiliser le cluster.
Le troisième type de cluster est nommé "adaptive pool". Ici, il s'agit de reprendre la technique du single pool et de n'autoriser les workstations à pénétrer sur le système en tant que nodes, qu'à des moments bien précis (par l'intermédiaire la crontab par exemple). En fait le cluster réagira en tant que server pool à des moments, et en tant que single pool à d'autres. Cette technique à l'avantage de pouvoir utiliser les stations de travail au sein du cluster lorsque l'utilisateur ne l'utilise pas (typiquement la nuit, ou lorsqu'il part en pause, par l'intermédiaire de son économiseur d'écran par exemple).
Enfin le dernier type de cluster est appellé "Half-duplex pool". En fait, c'est un single pool "intelligent". Les workstations peuvent envoyer des processus au serveurs du cluster mais celles-ci ne s'occuperont que de leurs propres processus. On dit que les stations de travail ne font partie du cluster que pour exécuter leurs propres processus, et ne se soucient donc guère des processus extérieurs.
Ainsi, MOSIX affiche une grande variété de solutions permettant de l'utiliser dans diverses architectures déjà mises en place. L'arrivée d'un tel produit sur votre système ne devrait pas avoir de conséquences majeures dans la mesure ou vos machines servant de nodes répondent aux caractéristiques minimums.
Renaud Vayssade
dimanche 27 janvier, 2002 22:13
