Mémoire stable, ressources et localisation

En plus du protocole de création d’états globaux et du protocole de reprise, nous avons intégré dans l’implémentation les différents services nécessaires au fonctionnement en pratique de la tolérance aux pannes :

− un service de stockage des points de reprise, − un service de détection de pannes,

4.2 Implémentation 81

− un fournisseur de ressources qui peuvent être utilisées pour redémarrer la ou les activités défaillantes si le nœud dans lequel elles s’exécutaient n’est plus disponible,

− un service de localisation pour activités qui ont été redémarrées sur un autre nœud suite à une panne.

L’implémentation robuste de ces services n’étant pas un objectif de cette thèse, nous proposons une implémentation centralisée. Nous avons implémenté un ser-veur de tolérance aux pannes unique capable de rendre ces différents services, et basé sur le protocole de communication RMI. L’accès à ce serveur unique peut être spécifié en une seule fois dans la définition d’un technical service de tolérance aux pannes en utilisant l’argumentglobalServer:

<arg name="globalServer" value="rmi://host1/globalServer"/>

Cependant, chacun de ces services correspond à une interface spécifique et peut donc être implémenté de manière indépendante simplement en étendant le code existant.

4.2.2.1 Détection de pannes

Nous considérons ici qu’une activité est en panne si la connexion vers cette activité est impossible, c’est-à-dire si une exception est levée par la couche de communication. Même si l’activité soupçonnée n’est pas réellement en panne mais que le chemin réseau pour y accéder est coupé, le redémarrage de l’application est quand même possible. L’utilisation de numéros d’incarnations sur les messages permettra aux autres activités d’identifier une telle activité “zombie”, d’ignorer ses messages et de terminer l’exécution de cette activité.

La détection de panne peut être réalisée par les activités entre elles. En effet, l’envoi de message étant soumis dans ProActive à un rendez-vous, une activité qui en contacte une autre doit attendre la fin de la connexion. Elle peut donc détecter d’éventuelles erreurs de connexion, et déclencher le processus de recouvrement si nécessaire.

Pourtant, cette solution pour la détection de pannes n’est pas suffisante. En ef-fet, si l’activité tombée en panne n’est contactée par aucune autre, la panne n’est jamais détectée. Le serveur de tolérance aux pannes propose donc un service de détection de pannes, basé sur un mécanisme de heartbeat messages, ou messages de vie. Ce service est chargé de contacter régulièrement chacune des activités de l’application en appelant de manière synchrone une méthode dédiée sur l’activité. L’activité est considérée comme en panne si la connexion pour réaliser cet appel est impossible. Dans ce cas, une activité est choisie par le service pour déclencher le recouvrement de l’application.

4.2.2.2 Ressources

Ce serveur propose aussi un service de fourniture de ressources. L’activité chargée du recouvrement contacte ce service pour obtenir un nœud d’exécution

qui peut accueillir l’activité en panne. Les ressources peuvent être collectées par le service de deux manières :

− l’utilisateur peut au moment du déploiement spécifier à l’aide des

techni-cal services les nœuds qui peuvent recevoir des activités qui doivent être

redémarrées. Si le technical service associé à un nœud définit la propriété

resourceNodedans le descripteur de déploiement :

<arg name="resourceNode" value="rmi://host1/ressourceServer"/>

alors le nœud s’enregistre automatiquement comme ressource disponible en cas de panne auprès du service de ressource démarré sur la machinehost1. − le serveur peut aussi utiliser une infrastructure pair-à-pair sous-jacente pour récupérer des nœuds sur lesquels les activités pourront être redémar-rées. Dans ce cas, le serveur doit être démarré avec l’option

-p2p rmi ://url1/entry1 rmi ://url2/entry2 ..., où les URLs passées en paramètre sont des points d’entrée possibles du réseau pair-à-pair. Ce service de ressource ne tient pas compte des problèmes de placement des activités ; le choix du nœud utilisé comme ressource pour redémarrer une activité ne suit pas de politique précise (ordre FIFO dans le cas de ressources enregistrées au déploiement, et indéterministe pour les ressources obtenues par le réseau pair-à-pair). Cependant, ProActive fournit un service de balance de charge qui pourrait être utilisé pour optimiser le placement des activités après un recouvrement.

Certaines solutions de tolérance aux pannes comme la plate-forme GatoS-tar [FOL 94] proposent une unification de la tolérance aux pannes et du place-ment des processus, en fonction de critères physiques tels que la charge des ma-chines, mais aussi en fonction des caractéristiques de l’application, telles que le taux global de communication ou le temps processeur consommé.

4.2.2.3 Localisation

Enfin, le serveur de tolérance aux pannes implémente aussi un service de lo-calisation. Lorsqu’une activité en panne est détectée par le service de détection ou par une autre activité, le service de localisation est prévenu et l’activité est signalée en panne. Dès qu’une activité redémarre, elle contacte le service de loca-lisation pour préciser sa nouvelle localoca-lisation en lui envoyant une référence sur elle-même.

Si une activité i constate qu’une référence vers une activité j n’est plus valable, c’est-à-dire que la connexion est impossible, elle contacte le service de localisation et lui envoie cette référence invalide vers j. Plusieurs cas sont possibles :

− si l’activité j n’est pas signalée en panne, et que la référence invalide reçue est la même que la référence actuellement associée à j, alors j est potentiel-lement en panne,

− si l’activité j n’est pas signalée en panne, et que la référence invalide re-çue n’est pas la même que la référence actuellement associée à j, alors la référence actuellement associée à j est renvoyée à l’appelant i,

− si l’activité j est signalée en panne, alors l’appel de i est temporisé jusqu’à ce que j ait contacté le serveur pour préciser sa nouvelle localisation.

4.2 Implémentation 83

Il faut noter que ce service de localisation ne repose pas sur l’existence d’un

processus stable, mais seulement sur l’existence d’une mémoire stable. En effet,

toutes les données sont mises à jour par les activités elles-mêmes : il existe sur la mémoire stable une table qui recense toutes les activités du système, ainsi que leur état supposé et leur localisation.