MacBidouille

Software (suite) :

3.2 Systèmes de gestion
    Il existe des systèmes qui permettent de se libérer des librairies que nous allons présenter plus tard. En effet, ceux-ci autorisent la distribution des processus sur les noeuds d'un cluster. L'application qui peut en bénéficier doit donc être fortement multi-processus.
3.2.1 OpenMosix [2] [3]
    Ammon Barak, professeur à l'université de Jérusalem, commença ses premiers travaux sur Mosix en 1977. Le but de ce projet était de transformer un ensemble d'ordinateur en une seule entité. Les "n" ordinateurs du cluster devant être vus au possible comme une seule et même ressource de calcul.
OpenMosix permet à un ensemble de machines reliées par réseau de coopérer et de travailler ensemble comme si elles ne formaient qu'une seule et même machine multiprocesseur à mémoire partagée (SMP). Il se présente sous forme d'un "patch" à appliquer au noyau Linux.

Fig. 3.2 OpenMosix Linux Clustering
    Au contraire des clusters de type Beowulf, OpenMosix ne nécessite pas d'applications liées à des librairies de parallélisation particulières comme les MPI ou les PVM. Il ne nécessite donc pas de modifications des applications. Le cadre dans lequel il peut être utilisé s'en trouve très élargit. En effet, son principe de base consiste à faire migrer un processus de façon dynamique et préemptive vers le noeud du cluster qui présente les meilleures caractéristiques et performances à un temps "t". Ces opérations de répartition de charge et de synchronisation se font de manière transparente pour l'utilisateur.
    La stratégie sous-jacente consiste à l'exécution sur chaque noeud d'un algorithme de dissémination d'information qui envoie à intervalle régulier des informations sur ses ressources à un ensemble d'autres noeuds choisis au hasard. Un algorithme de répartition de charge réduit en permanence les différences de charge entre les noeuds. Ces différences sont calculées par paires de noeuds tirées au hasard. Un dernier algorithme, de gestion de la mémoire, surveille l'utilisation de la mémoire de manière à éviter la saturation et le swapping des processus. Cet algorithme tend à contrebalancer une migration excessive des processus sur un noeud et trouve un noeud avec un espace mémoire suffisant en cas de saturation.
OpenMosix a donc la capacité de répondre dynamiquement à des besoins et des conditions d'exécution irrégulières et non prédictibles. A tout moment un processus est donc assuré d'obtenir les meilleures conditions d'exécution, il s'ensuit une réduction globale du temps d'exécution de l'ensemble des processus.
OpenMosix concède toutefois quelques désavantages:

1. OpenMosix n'est pas, de par sa conception, portable.
2. On obtiendra aucun gain de performance si on ne lance qu'un seul processus sur le cluster.
3. Les processus à temps d'exécution court ne bénéficient pas d'un meilleur temps d'exécution. Si il y avait migration de ce type de processus on perdrait du temps lors du transfert.
4. Une application basée sur les "threads" ("processus" à mémoire partagée) ne peuvent pas migrer. La communauté de développeurs d'OpenMosix essaie de combler cette lacune.