schéma général

Milojicic résume les schémas classiques de migration de processus à la figure 1. Cela consiste en les phases suivantes: l'enregistrement du contexte d'exécution du processus avant la migration, le transfert de ce contexte sur la machine cible, et enfin la reconstitution exacte du contexte sur la machine cible, suivie de la reprise de l'exécution. Ces services peuvent être implémentés à plusieurs niveaux d'une architecture (comme partie intégrante de l'application, comme bibliothèque utilisateur, ou au niveau du système d'exploitation), avec des performances différentes au niveau de la transparence aux applications, la portabilité sur plusieurs systèmes d'exploitation, la généricité ou la prise en compte de plusieurs types d'applications:

• Une façon naturelle de permettre la migration d'une application est de la prendre en compte dans le codage de l'application. [4] propose un schéma d'auto-sauvegarde du contexte à des instants précis de son exécution tels que les appels de fonctions, les créations d'objets...Cette forme de migration est limitée à l'application elle-même; toutefois l'implémentation peut être simplifiée, et optimisée pour certains cas.
• La migration en mode utilisateur permet de pallier à l'absence de support au niveau système pour la migration de processus. Elle est destinée à des applications sollicitant peu de ressources système. L'exemple émergent dans ce courant est Condor[]. Condor implémente les mécanismes de migration dans une bibliothèque en mode utilisateur. Condor nécessite que le programme à surveiller soit lié avec la bibliothèque de migration. A la réception d'un avis de checkpoint, l'application crée un processus fils qui enregistre son contexte pendant que le processus original (père) continue son exécution. La bibliothèque de checkpoint est réalisée en modifiant (augmentant) certains appels système pour enregistrer les valeurs de retour et maintenir une trace de tous les objets utilisés par l'application. Lorsqu'un processus quitte son environnement d'origine, il y laisse un résidu à qui il fait suivre les requêtes destinées au système.
• La prise en compte de la migration de processus au niveau système requiert de profondes modifications du noyau sous-jacent. Le système le plus connu dans cette catégorie est Mosix[], un système distribué conçu au Hebrew University of Jerusalem. Le partage dynamique de charge est réalisé dans Mosix par la migration de processus. Le noyau Mosix [] consiste en deux parties : un mécanisme de migration préemptive de processus (Preemtive Process Migration PPM), et des mécanismes de partage de ressource. Au moment de la commutation de contexte, le PPM peut choisir de migrer n'importe quel processus sur un tout noeud disponible. Chaque processus possède un noeud domicile unique (Unique Home Node UHN), qui est celui où il a été créé. Les processus ayant migré sur un autre noeud utilisent les ressources locales autant que possible, mais interagissent avec le système uniquement à travers leur UHN. Ainsi , comme dans Condor, les appels système émis par le processus seront routés vers le UHN.
• Crak[6] est un système qui vise à combiner les avantages de Mosix et epckpt. Dérivé de epckpt, il implémente la migration de processus sous la forme d'un module, donc ne nécessite pas de modification du noyau. Les processus sont autorisés à utiliser toutes sortes de ressources (tubes, signaux, fichiers...).