L'environnement I-Cluster

I-Cluster est constitué de ressources extrêmement dynamiques, les machines qui constituent la plate-forme adhèrent et quittent le nuage de façon intempestive, et il n'est pas facile de diagnostiquer les pannes. Toutefois le nombre de machine est potentiellement grand, et il est toujours possible de trouver une station de travail où faire exécuter un calcul. Il n'y a néanmoins pas de garantie que ce calcul se termine normalement.

Une solution de type Mosix ne peut cependant être applicable dans notre cas :

Tout d'abord lorsqu'une machine disparaît du nuage, elle disparaît complètement. La notion de Unique Home Node n'a donc pas de sens.

De plus pour des raisons de portabilité, nous avons choisi d'ajouter des fonctionnalités à un noyau existant, plutôt que de le modifier.

Une solution de type Condor n'est pas non plus envisageable. I-cluster est une plate-forme ouverte, et nous n'avons pas de contrôle sur les applications clientes. On ne saurait donc ni les recompiler, ni même inspecter le code.

La qualité souvent approximative des ressources matérielles disponibles (processeurs, réseaux, périphériques) doit être compensée par les possibilités d'allocation dynamique des processeurs aux processus. L'objectif de pérennité du service est souvent beaucoup plus forte que toute autre considération. Trois points spécifiques ont guidé notre travail : assurer la transparence de la migration, supporter l'hétérogénéité des architectures et privilégier le support efficace d'applications parallèles. Aucun des systèmes connus à ce jour ne permet d'atteindre ces objectifs à la fois, en particulier la prise en compte des communications à la migration, dans un contexte de disparition complète du noeud origine de l'application. Les capacités des modules Linux offrent donc une alternative intéressante, puisqu'on peut ainsi ajouter de nouvelles fonctions au noyau sans le recompiler. Ces capacités étant implémentées au niveau du noyau, on peut surveiller et migrer n'importe quel type d'application.

Nous avons opté pour une solution de sauvegarde/reprise du contexte d'un processus au niveau du noyau Linux en étant le moins intrusif possible au niveau de la configuration, c'est-à-dire sans nécessiter de modification du noyau sous-jacent ni de recompilation/édition du programme à surveiller.