Ministere de l’enseignement superieur et de la recherche scientifique

5.1.1 Le degré de tolérance aux fautes

Le degré de tolérance aux fautes est le nombre maximum de fautes simultanées tolérées. Les fautes comprennent aussi bien les fautes de l’application que celles des mécanismes de recouvrement arrière. C’est l’objectif le plus important. Une politique est efficace si les mécanismes choisis tolèrent la faute globale du système réparti sans effet domino.

5.1.2 Les surcoûts pendant l’exécution

Les surcoûts pendant l’exécution sont de trois ordres [36] :

5.1.2.1 La charge du réseau 

Toute application telle qu’elle soit, génère un trafic de messages sur le réseau de communication.

5.1.2.2 Le stockage 

La procédure de recouvrement arrière commence par une capture d’un état de l’application et, est automatiquement suivie de la sauvegarde des informations en mémoire stable.

5.1.2.3 Temps d’exécution

 Cette perte de temps est due à la fois aux accès à la mémoire stable, pour le stockage, et au mécanisme de capture de l’état lui-même.

Donc, l’objectif serait, de capturer des états de l’application, qui soient utiles, de taille la plus minimale possible et échelonner les sauvegardes et d’espacer leur fréquence.

5.1.3 L’inhibition pendant l’exécution

Toutes les applications possèdent un temps d’exécution propre. Les stratégies de recouvrement arrière, seront d’autant plus performantes si elles s’interfèrent moins avec l’application. En d’autres termes, l’objectif est qu’elles utilisent les ressources aux moments ou elles sont disponibles.

Par ailleurs, les mécanismes respectant la cohérence forte d’un système, inhibent l’exécution de l’application.

5.1.4 La quantité de travail à défaire ou à refaire

La performance des stratégies de recouvrement arrière peut également être évaluée en terme de quantité de travail à défaire ou à refaire. Elle se décline selon deux métriques :

5.1.4.1 La distance de recouvrement arrière

La distance de recouvrement arrière mesure l’effet domino ou quantité de travail à défaire.

5.1.4.2 Le nombre de processus impliqués par la stratégie

Le nombre de processus devant se ré exécuter (c’est le premier paramètre de la quantité de travail à refaire) varie selon les applications et les politiques de recouvrement arrière.

5.2 Mécanismes de base pour la mise en œuvre d’une stratégie de recouvrement arrière 

Pour mettre en œuvre une stratégie de recouvrement arrière, il faut en dégager les ingrédients essentiaux. Alors, en l’absence de fautes nous devons capturer un ou plusieurs états, que doit il contenir ? Ensuite nous devons nous assurer de leur stockage dans un endroit stable : pourquoi pas la mémoire vive ? …s’il y’a une faute qui surgit, nous devons la déceler, et essayer de la tolérer.

Toutes ces questions serviront de fondement pour cette mise en œuvre.

5.2.1 La détection des défaillances

C’est l’événement déclencheur du recouvrement, de ce fait la première étape d’une stratégie de recouvrement arrière est la détection de la défaillance d’un processus. Cette procédure est expliquée dans le précédent, section 4.3.2.1.

5.2.2 la sauvegarde d’état du processus

Un programme informatique qui s’arrête perd toutes les informations relatives à son état. La mémoire de travail physique des ordinateurs, la « mémoire vive », étant volatile.

5.2.2.1 Que faut il sauvegarder

Si nous devons sauvegarder l’état d’un processus, nous devons nous assurer que cet état doit être suffisamment complet pour qu’un arrêt du processus suivi d’un recouvrement préserve toutes les caractéristiques du processus et permettent notamment le rétablissement des communications et des entrées/sorties.

Il faut donc conserver le tas, la pile, le code et l’état des registres dans le système d’exploitation. Il est également nécessaire de sauvegarder le répertoire courant, les comptes à rebours, l’identité de l’utilisateur, celle du processus, l’arborescence du processus, les librairies partagées liées à l’application, les fichiers ouverts surtout en écriture et puisque nous nous trouvons dans un environnement réparti, nous devons parfois sauvegardé l’histoire répartie du processus (voire chapitre 4 section 4.5.1).

5.2.2.2 Oŭ faut il sauvegarder

La mémorisation des états, doit se faire sur un support qui résiste aux défaillances des machines (sûreté) et n’altère pas l’information conservée (sécurité). Aussi, ce support doit être accessible en lecture et en écriture.

En fonction du nombre de fautes à tolérer, des performances et des moyens disponibles, plusieurs solutions sont possibles pour réaliser une mémoire stable.

La solution la plus simple, est l’utilisation de la mémoire vive d’un serveur considéré comme fiable [37]. Le passage à l’échelle est rendu difficile et il est parfois nécessaire de dupliquer le serveur, le système perdant alors une bonne partie de sa simplicité. Une autre solution est la sauvegarde du point de reprise dans la mémoire vive d’un nœud distant Ceci ne permet de résister qu’à une seule faute mais évite la saturation d’un serveur et augmente considérablement l’utilisation mémoire. Pour éviter ce surplus d’utilisation mémoire, une variante consiste à sauvegarder le point de reprise sur un disque local d’un nœud distant. Le défaut est alors le coût en latence dû aux accès en écriture sur disque. De nos jour, les méthodes utilisées utilise la philosophie de dupliquer la sauvegarde sur un deux sites distants.

5.2.2.3 Qui doit faire la sauvegarde

On peut lancer la sauvegarde de trois manières : par l’application elle-même par l’insertion, au sein de l’application, des codes permettant la réalisation de la sauvegarde, par une librairie liée à l’application qui initiera les sauvegarde .ou encore par le système d’exploitation. La dernière solution, est l’intégration dans le système d’exploitation de la génération des points de reprise. Le système d’exploitation peut fournir une primitive d’initiation des points de reprise ou les initier de manière transparente. Dans ce dernier cas, aucune modification des applications ou librairies

5.2.2.4 Libérer l’espace de stockage (le ramasse miette)

A un certain moment, l’état sauvegardé perdra sa cohérence, il ne sera plus d’actualité vu la progression de l’application. Ces mises à jour au niveau de l’exécution du processus imposeront une nouvelle sauvegarde, donc une nouvelle occupation d’espace en mémoire. Faut-il mettre à jour ces sauvegardes, les supprimer parce qu’elles sont devenues inutiles ou tout simplement les garder pour usage ultérieur. La libération de l’espace occupé par les sauvegardes d’état, est décidée par protocole de recouvrement arrière adopté.