Systèmes tolérant les fautes à base de support d exécution réflexifs Capture en ligne de l état d applications

Transcription

1 Systèmes tolérant les fautes à base de support d exécution réflexifs Capture en ligne de l état d applications Ludovic Courtès <ludovic.courtes@laas.fr> Stage de DEA - Université de Franche-Comté Stage de fin d études - Université de Technologie de Belfort-Montbéliard Printemps 2003 Suiveur UTBM : Vincent Hilaire Tuteur LAAS-CNRS : Jean-Charles Fabre

2

3 Avant-propos Ce rapport présente le travail effectué lors d un stage au sein du groupe Tolérance aux fautes et Sûreté de Fonctionnement (TSF) du Laboratoire d Analyse et d Architecture des Systèmes du CNRS (LAAS-CNRS), à Toulouse. Ce stage marque la fin de mes études d ingénieur à l Université de Technologie de Belfort-Montbéliard (UTBM), ainsi que la fin du Diplôme d Études Approfondies (DEA) Informatique, Automatique et Productique préparé en parallèle à l Université de Franche-Comté. Je tiens à remercier Jean Arlat, responsable du groupe TSF, pour m avoir accueilli dans le groupe, et Jean-Charles Fabre pour m avoir intégré à son équipe, pour m avoir guidé pendant ce stage, et pour m avoir aidé à surmonter les difficultés que j ai rencontrées. Je remercie François Taïani, futur docteur, pour son suivi, ses nombreuses relectures de ce rapport, ses conseils, ses métaphores et ses périphrases éclairantes, ainsi que Marc-Olivier Killijian, chargé de recherche «alternatif», pour son soutien, ses encouragements, et pour m avoir aidé à ne pas m égarer dans le méta-espace. Un grand merci à mes collègues de bureau, Marc Lecointe, Amine Filali et Carlos Aguilar pour leur bonne humeur quotidienne et pour leur capacité à créer une ambiance de travail agréable et sympathique. Enfin, je remercie tous mes autres collègues, stagiaires et thésards, qui ont contribué à faire de ce stage un bon moment. Ce rapport et les figures qu il contient ont été réalisés avec le système de mise en page libre Lout, <

4

5 Table des Matières Avant-propos iii Introduction Chapitre 1. Introduction à la tolérance aux fautes Concepts de base Définitions Tolérance aux fautes Utilisation de la réflexivité Motivations Concepts Protocoles à méta-objets Chapitre 2. Capture d état, état de l art Introduction à la capture d état Langages persistants Langages réflexifs Systèmes d exploitation persistants Bibliothèques de capture d état Compilation source-à-source et compilation ouverte Utilisation des informations du compilateur Chapitre 3. Capture de l état d applications écrites en langage C ou C Besoins pour une sauvegarde portable de programmes C Mise-en-œuvre de mécanismes d introspection et de sauvegarde portable Aperçu de l architecture Définitiond un méta-modèle du langage C Mise-à-plat des données à sauvegarder Processus de sauvegarde et de restauration Modules de stockage hiérarchiques Utilisation de Pego Limitations Performances Sauvegarde de la pile Problématique Fonctionnement de la pile et difficultés Mise-en-œuvre Conclusion

6 Chapitre 4. Mécanismes de tolérance aux fautes pour les systèmes d exploitation Objectifs Besoins pour l intégration de mécanismes de tolérance aux fautes Vue réflexive des besoins Techniques et architectures de système Architectures de systèmes d exploitation Réification Introspection Conclusion et perspectives Chapitre 5. Conclusion Références Glossaire vi

7 Liste des figures 1.1. Réification,introspection et intercession dans un système réflexif Relations d instanciation dans un programme GOOPS Exemple montrant les capacités réflexives (de réification) de GOOPS Mécanisme de gestion de la mémoire virtuelle Principe de shadowing dans un support de stockage stable Processus d instrumentation de code à l aide d un compilateur source-à-source Architecture de l outil de sauvegarde portable Pego, basé sur la bibliothèque d introspection Ego Relation entre les données de l application (niveau de base) et le «méta-niveau» proposé par Ego Représentations de types de données C par des méta-types dans Ego (objets ctype_t) Définitionsde type et hiérarchie des fichierssources et fichiersd entête Capture d état de variables en XML Diagramme de syntaxe pour la mise-à-plat des pointeurs (pointer swizzling) par Pego au format XML Exemple de mise-à-plat d un pointeur par Pego Lien entre le modèle de l application (les méta-objets) et la vue correspondante du support de stockage (nœuds de l arbre de capture d état) Exemple de configurationutilisant le module de stockage réseau Exemple d utilisation de Pego dans une application où les ressources «externes» sont clairement séparées des ressources «locales» Capture d écran de trois répliques du jeu xgalaga instrumenté avec Pego Exemple d interface permettant de rendre persistante de l information relative à un fichier Durée de la réalisation d une capture d état pour la multiplication de matrices Taille du fichierde capture d état pour la multiplication de matrices Temps de capture d état et restauration sur différentes architectures Disposition de la pile d appel (standard System V) Architecture d un système d exploitation multi-serveur Mécanisme d appel de procédures distantes (RPC) Architecture à composants Interface d import/export de l états d objets distants (UML)

8

9 Introduction Ce rapport présente le travail effectué lors d un stage de DEA effectué au sein du groupe Tolérance aux fautes et Sûreté de Fonctionnement informatique (TSF) du LAAS-CNRS, à Toulouse. Ce stage s inscrit dans le cadre de recherches portant sur la mise en œuvre de systèmes tolérants les fautes adaptatifs. Ces travaux sont fondés sur la notion de support d exécution réflexif qui offre l observabilité et la commandabilité nécessaires à la manipulation en ligne de l état d un système. Le travail effectué durant ce stage est axé autour de deux thèmes principaux : d une part la capture en ligne de l état d applications (écrites en langage C ou C++) qui a fait l objet d une réalisation pratique, et d autre part une partie prospective relative aux architectures ouvertes de système d exploitation et à l utilisation de capacités réflexives pour mettre en œuvre des mécanismes de tolérance aux fautes. Après une présentation des principaux concepts en tolérance aux fautes et des applications de la réflexivité aux systèmes sûrs de fonctionnement (chapitre 1), nous aborderons aux chapitres 2 et 3 la mise en œuvre de la capture d état en ligne d applications, un mécanisme essentiel pour un système tolérant aux fautes. Le chapitre 2 donne un aperçu des moyens permettant la capture d état, et le chapitre 3 décrit ensuite la mise en œuvre d une bibliothèque de capture d état pour applications C et C++ réalisée durant ce stage. Enfin,nous verrons au chapitre 4, de manière plus générale, l ensemble des propriétés ainsi que les architectures de systèmes d exploitation permettant la mise en œuvre de mécanismes de tolérance aux faute. 1

10

11 Chapitre 1. Introduction à la tolérance aux fautes «Spécifier, concevoir, réaliser et exploiter des systèmes où la faute est naturelle, prévue, et tolérable.» [32]. Ce chapitre expose les principaux concepts liés à la sûreté de fonctionnement et plus particulièrement à la tolérance aux fautes, ainsi que différentes techniques. La section 1.2 présente ensuite les concepts liés à la réflexivité et leur application à l architecture de systèmes tolérants aux fautes. L intérêt de systèmes réflexifs est davantage détaillé dans les chapitres suivants, dans le cas de la mise en œuvre d un mécanisme de capture d état portable puis dans le cas de l architecture de systèmes d exploitation Concepts de base Définitions Les systèmes informatiques étant de plus en plus répandus, une défaillance de l un d entre eux peut avoir un impact catastrophique sur la société. En même temps, les systèmes informatiques étant de plus en plus complexes, il devient de plus en plus difficilede les maîtriser et un soin accru doit leur être apporté. La sûreté de fonctionnement d un système informatique est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu il leur délivre [32]. Selon les applications les besoins en sûreté de fonctionnement diffèrent. Plusieurs attributs ou facettes de la sûreté de fonctionnement peuvent être dégagés [32] : la disponibilité évalue le fait d être prêt à rendre le service; la fiabilité évalue la continuité du service; la sécurité-innocuité est définie par la non-occurrence de conséquences catastrophiques pour l environnement; la confidentialité s intéresse à la non-divulgation non-autorisée d information; l intégrité caractérise la non-occurrence d altérations de l information; enfin,la maintenabilité caractérise l aptitude aux réparations et aux évolutions du système. La défaillance d un système survient lorsque le service délivré dévie de l accomplissement de la fonction du système. Une erreur est la partie de l état du système susceptible d entraîner une défaillance. Enfin,une faute est la cause adjugée au supposée d une erreur. Fautes, erreurs et défaillances peuvent donc s enchaîner comme suit : faute erreur défaillance faute 3

12 4 Chapitre 1. Introduction à la tolérance aux fautes Plus précisément, la défaillance d un composant peut être vue comme une faute pour le système qui l englobe, et elle peut à son tour être source d une erreur dans ledit système, etc. À leur tour, les défaillances peuvent être rangées dans plusieurs classes. Le service rendu par un système peut défaillir suivant deux axes, l axe des valeurs (la valeur rendue en réponse à une requête n est pas correcte) et l axe temporel (la réponse ne se fait pas dans l intervalle de temps spécifié).dans le cas de défaillances par arrêt, l activité du système n est plus perceptible aux utilisateurs, ce qui peut se traduire soit par un figementde l état des sorties du système, soit par un silence (e.g. pas d envoi de messages dans un système réparti). De plus, la perception des défaillances conduit à distinguer les défaillances cohérentes (tous les utilisateurs en ont la même perception) et les défaillances incohérentes (les utilisateurs peuvent avoir des perceptions différentes des défaillances). Les fautes peuvent être caractérisées selon plusieurs critères [32] : selon leur cause phénoménologique, il peut s agir de fautes physiques ou de fautes dues à l homme; selon leur nature, elles peuvent être accidentelles ou intentionnelles; selon la phase du cycle de vie du système où elles ont été introduites, il peut s agir de fautes de développement (ce que l on appelle souvent des «bugs») ou de fautes opérationnelles apparaissant durant l exploitation du système; en fonction de la situation des fautes, on parlera de fautes internes lorsqu elles font partie du système, et de fautes externes lorsqu elles sont le résultat de l interaction du système avec son environnement; enfin,selon la durée de vie des fautes, on parlera de fautes permanentes ou de fautes temporaires (liées à des conditions ponctuelles et donc présentes pour une durée limitée). Plusieurs moyens permettent d assurer la sûreté de fonctionnement d un système. L élimination des fautes cherche à réduire le nombre et la sévérité des fautes.la prévision des fautes cherche à estimer la présence et la conséquence des fautes. Enfin,la tolérance aux fautes, dont il est question dans la section suivante, est un moyen qui cherche à permettre au système de remplir sa fonction en dépit de la présence de fautes Tolérance aux fautes La tolérance aux fautes est un moyen d assurer la sûreté de fonctionnement d un système en présence de fautes, qu il s agisse de fautes physiques, de fautes de conception, d erreurs de l opérateur, ou encore d intrusions. Dans ce document, nous nous intéressons principalement aux deux premières classes de fautes. La première étape dans la conception d un système tolérant aux fautes est la mise en œuvre de mécanismes de détection d erreurs. Les formes les plus courantes de détection d erreurs sont les suivantes [32] : le contrôle par codes détecteurs d erreur, qui utilise la redondance de la représentation de l information (e.g. le Code à Redondance Cyclique ou CRC est un code détecteur et même correcteur d erreur); la duplication et comparaison qui consiste à comparer les résultats fournis par deux unités indépendantes fournissant le même service;

13 1.1. Concepts de base 5 le contrôle de données structurées qui consiste à vérifier soit la cohérence des données d un point de vue sémantique, soit la cohérence de la structure des données (e.g. cohérence d une liste chaînée). Des exemples de ce type de contrôle au niveau du système d exploitation sont donnés dans [46] et au chapitre 4. La deuxième étape de la mise en œuvre d un système tolérant aux fautes concerne le traitement des erreurs détectées. Une première technique consiste à masquer les fautes en utilisant des codes correcteurs d erreurs [32] : c est ce que permet l utilisation de codes tels que SEC («Single-Error Correction») ou CRC (Code à Redondance Cyclique), et c est aussi l objectif des systèmes de sauvegarde redondante des données tels que RAID («Redundant Array of Inexpensive or Independent Disks»). Une autre méthode répandue pour tolérer les fautes, une fois détectées, est le recouvrement d erreur. On distingue essentiellement trois techniques de recouvrement d erreur : le recouvrement d erreur par poursuite qui consiste, après avoir détecté une erreur, à rechercher un nouvel état acceptable du système; le recouvrement d erreur par compensation qui nécessite que l état du système comporte suffisamment de redondance pour permettre de le faire passer dans un état exempt d erreur; enfin, le recouvrement d erreur par reprise, le plus utilisé dans la tolérance aux fautes logicielles, et qui consiste à capturer régulièrement l état du système, créant un ensemble de «points de reprise» (ou «checkpoints») possibles, de manière à pouvoir ramener le système» dans un état antérieur après détection d une erreur. Ce dernier point fait l objet des chapitres 2 et 3. Ces modes de recouvrement d erreur ont donné lieu à des techniques réparties de réplication de processus [32, p. 98]. La réplication de processus consiste en l exécution coordonnée d un groupe de processus installés sur des processeurs distincts. On distingue alors trois types de réplication différents : la réplication active est une technique de détection et compensation par laquelle toutes les répliques d un même processus traitent tous les messages d entrée; la réplication passive est une technique de recouvrement par reprise dans laquelle seule la réplique primaire traite les données d entrée et fournit les résultats; en l absence de fautes, les autres répliques (dites répliques de secours) ne traitent pas les données d entrée mais leur état est mis à jour au moyen de points de reprise envoyés par la réplique primaire; la réplication semi-active est une technique de recouvrement par laquelle les messages d entrée sont diffusés à toutes les répliques mais une seule réplique (la réplique meneuse) traite tous les messages d entrée et fournit les messages de sortie; par contre, contrairement à la réplication active, la réplique meneuse communique avec les suiveuse pour leur indiquer toutes les décisions non-déterministes qu elle prend. La technique de réplication passive sera illustrée par la présentation de l implantation proposée en chapitre 3 (voir notamment la figure3.9, page 28) Utilisation de la réflexivité Cette section introduit dans un premier temps les apports des concepts liés à la réflexivité dans la conception et l architecture de systèmes tolérants aux fautes. La section définitensuite certains concepts de base en réflexivité. L utilité des architectures réflexives pour la mise en œuvre de méca-

14 6 Chapitre 1. Introduction à la tolérance aux fautes nismes de tolérance aux fautes est illustrée par la suite aussi bien dans le cas de l implémentation de mécanismes de capture d état portable (chapitre 2), que dans le cas de l introduction de mécanismes divers au niveau du système d exploitation (chapitre 4) Motivations La mise en œuvre de mécanismes de tolérance aux fautes pour une application donnée est une problématique orthogonale au développement des parties fonctionnelles de l application. La mise en œuvre de ces mécanismes peut par ailleurs s avérer assez complexe, et elle requiert une bonne connaissance du développeur. Pour ces raisons, et aussi pour simplifierla maintenabilité de l application, l idéal est que le développeur de l application puisse s affranchir des préoccupations liées à la tolérance aux fautes. Les mécanismes de tolérance aux fautes peuvent alors être développés par un spécialiste dans ce domaine, sans avoir cette fois-ci à se préoccuper de l application elle-même. On parle alors de séparation des préoccupations(ou «separation of concerns») entre le développeur de l application et le développeur des mécanismes de tolérance aux fautes [45]. De cette façon, la tolérance aux fautes devient transparente pour le programmeur de l application. Pour que cette séparation puisse être respectée, l application doit fournir des moyens de contrôle et d observabilité répondant aux besoins des mécanismes de tolérance aux fautes [53]. En effet, les mécanismes de détection et de recouvrement d erreurs nécessitent tous d avoir accès à certaines données de l application mais aussi d avoir un contrôle sur l application et sur son déroulement. Ces besoins sont formalisés par la définitionde la réflexivité calculatoire (ou «computational reflection») donnée par Pattie Maes [38]. La section suivante présente les principaux concepts liés à la réflexivité et leur utilisation Concepts La réflexivité est la capacité d un système à raisonner à propos de lui-même et à agir sur lui-même [38]. Cette définition élémentaire introduit la notion de moyens d observation et de modification ou d extension a posteriori du comportement initial du système. Un système réflexif est définicomme un système qui intègre des structures de données représentant certains aspects de lui-même et qui constituent sont auto-représentation. Cette auto-représentation ou méta-modèle doit pouvoir lui permettre de se poser des questions sur lui-même mais aussi d être capable d agir sur lui-même. De cette façon, un tel système a la capacité de s auto-modifier. Dans un système réflexif, le méta-modèle est relié de manière causale aux aspects qu il représente, de telle sorte que : (i) (ii) le système dispose toujours d une représentation exacte de lui-même; l état du système est toujours cohérent avec sa représentation. On appelle niveau de base le système lui-même. Le méta-niveau est la partie du système qui observe et modifie le niveau de base en interprétant et en agissant sur le méta-modèle. Ces deux niveaux sont liés par des processus d interaction illustrés par la figure 1.1 : la réificationest une information envoyée par le niveau de base au méta-niveau pour indiquer un changement lorsqu il a subit une modification, l intercession est initiée par le méta-niveau pour communiquer un changement au niveau de base, et l introspection est une demande d information sur le niveau de base initiée par le méta-niveau. Pour être plus précis, le mécanisme d intercession peut être divisé en intercession comportementale qui vise à modifierle comportement du niveau de base, et en intercession structurelle qui vise à modifierl état du niveau de base [53]. Les langages de programmation ont été l un des premiers champs d expérimentation des concepts de réflexivité, même si la réflexivité a depuis été appliqué à bien d autres champs (voir section 4). Un langage de programmation interprété est dit réflexif si son interpréteur donne accès à des structures de données représentant certains aspects du système, et si cet interpréteur garantie le lien de

15 1.2. Utilisation de la réflexivité 7 MÉTA-NIVEAU Composants mettant en œuvre les besoins non-fonctionnels Réification Introspection, intercession NIVEAU DE BASE L application elle-même Réification Introspection, intercession Figure 1.1. Réification,introspection et intercession dans un système réflexif. causalité entre ces structures de données et le système lui-même [38]. Le fait d être réflexif rend le langage ouvert, dans le sens où une fonctionnalité qui n est pas présente dans le langage peut toujours être ajoutée. À titre d exemple, le langage orienté-object 3-KRS présenté par Pattie Maes dans [38] et [37] ne prend pas en charge l héritage multiple mais permet de rajouter cette fonctionnalité en spécialisant les méthodes d interprétation des objets. Plus simplement, la primitive defined? du langage Scheme (ou son équivalent boundp en Common Lisp) qui renvoie un booléen indiquant si une variable est définie ou non est un bon exemple de réificationd informations maintenues par l interpréteur. En résumé, le méta-niveau d un langage interprété peut être vu comme l ensemble des structures et données qui contrôlent l interprétation du programme. Dans le cas des langages compilés tels que C++, des compilateurs ouverts tels que OpenC++ [5] permettent d obtenir une représentation du programme à la compilation. Un méta-programme peut utiliser cette représentation et la modifier pour intervenir dans le processus de compilation. Une utilisation de ce type d outil pour obtenir une représentation d un programme C++ est discutée plus loin en section 2, page 11. La section suivante décrit plus spécifiquementcomment peuvent être introduits les mécanismes de réflexivité dans un langage orienté-objet Protocoles à méta-objets Dans un modèle objet, la réflexivité est généralement réalisée à travers un protocole à méta-objets. Un méta-objet correspond au méta-niveau d un objet : un méta-objet peut donc observer l objet correspondant par le biais d introspection et le contrôler par le biais d intercession. Le protocole à métaobjets définitles interactions possibles entre objets et méta-objets, c est-à-dire l ensemble des méthodes et réificationet d intercession. Dans un langage réflexif orienté-objet tel que CLOS (Common Lisp Object System) [27], GOOPS [19]ou 3-KRS [37, 38], chaque élément du langage est représenté par un métaobjet accessible à l utilisateur, et chacun de ces méta-objets encapsule une représentation ainsi que le comportement de la notion qu il représente. Par exemple, dans CLOS et GOOPS, chaque classe est représentée par un objet de type classe. Les objets de type classe contiennent des informations décrivant la classe qu ils représentent, telles que son nom, ses attributs, leur valeur par défaut, etc. Ils définissentaussi des méthodes telles que la méthode d initialisation et la méthode d allocation des instances (similaire à l opérateur new () du langage C++) de cette classe. Lorsqu une instance d une classe est créée, les méthodes d allocation puis d initialisation d instance de cet objet classe sont appellées. Pour une classe donnée, il est possible de personnaliser le comportement de ces méthodes. L objet de type classe lui-même est une instance d un objet représentant la notion de classe et appellé méta-classe (en d autres termes, une méta-classe est la classe d une classe). La figure1.2 illustre les relations d instanciation entre objets et méta-objets en GOOPS (chaque flèche représente une instanciation). Une méta-classe contient des attributs tels que la liste des classes dont hérite la classe qu elle représente (la «class precedence list» ou CPL), un attribut représentant la liste des attributs (en termes CLOS ou GOOPS, on parle de «slots») de la classe qu elle représente, etc. S agissant d un objet

16 8 Chapitre 1. Introduction à la tolérance aux fautes ; Définition d une classe et d une méthode (define-class <myclass> (<object>) (value #:init-value 0)) (define-method (get-value (object <myclass>)) (slot-ref object value)) <class> <my-metaclass> ; Définition d une méta-classe sans attributs (define-class <my-metaclass> (<class>)) ; Rajoute l attribut new-slot aux classes qui ; utilisent la métaclasse <my-metaclass> (definemethod (compute-slots (class <my-metaclass>)) (let ((slots (next-method))) (cons (new-slot #:init-value 0) slots))) ; Création d une classe (define-class <myclass2> (<object>) (chbouib #:init-value 2) (shbweeb #:init-value "bonjour") #:metaclass <my-metaclass>) <myclass> <method> <myclass2> est une instance de object1 get-value object2 est une instance de ; Instanciation d objets (define object1 (make <myclass>)) (define object2 (make <myclass2>)) Figure 1.2. Relations d instanciation dans un programme GOOPS. comme un autre, une méta-classe dispose aussi de méthodes d allocation et d initialisation d instances. Une méta-classe dispose entre autres d une méthode effectuant le calcul des classes dont hérite une classe, d une méthode calculant la liste des attributs d une classe, de méthodes pour la prise en charge d erreurs telles qu une tentative d accès à un attribut inexistant, etc. Lorsqu une classe est définie, il est possible de spécifier une méta-classe particulière avec le mot-clef #:metaclass suivi de la méta-classe choisie. Ainsi, dans la figure 1.2, on a les relations suivantes : object1 est une instance de <myclass> qui hérite de <object> ; <myclass> est une instance de <class> ; <class> est la méta-classe de object1 ; <myclass2> est une instance de <my-metaclass> ; <my-metaclass> est la méta-classe de object2 ; <class> et <my-metaclass> sont toutes les deux des instances de <class> (c est le point de départ de la méta-hiérarchie). La méta-classe <my-metaclass> (qui hérite de <class>) redéfinitla méthode compute-slots qui est appelée lors de la création d une classe de manière à rajouter automatiquement l attribut new-slot à toutes les classes qui l utilisent comme méta-classe. Ainsi, la classe <myclass2> a automatiquement l attribut new-slot en plus de ceux qu elle définit. Bien sûr, beaucoup d autres aspects pourraient être modifiés de la même façon. Notons que dans CLOS comme dans GOOPS, les méthodes sont elles-aussi des objets. La notion de méta-espace («metaspace») introduite notamment dans [56] désigne l ensemble des méta-objets directs ou indirects d un objet donné. Dans l exemple précédent, le méta-espace d object2 est constitué des objets <myclass2>, <my-metaclass> et <class>. La section 2.3 donne par la suite des exemples d utilisation de ces possibilités pour la capture d état.

17 1.2. Utilisation de la réflexivité 9 La richesse du protocole à méta-objets de ces langages leur procure une puissance et une flexi - bilité inégalée. C est pour cette raison que l utilisation de protocoles à méta-objets tend à s étendre à d autres domaines que les langages de programmation, et notamment au domaine des systèmes d exploitation comme nous le verrons au chapitre 4. Ces expérimentations tendent à montrer que la réflexivité est un concept transversal qui peut être appliqué à d autres domaines que les langages de programmation en offrant des propriétés tout aussi intéressantes.

18

19 Chapitre 2. Capture d état, état de l art Pour prévenir les défaillances logicielles ou matérielles d un système informatique, il est intéressant de pouvoir sauvegarder l état de l application critique qui nous intéresse à intervalles réguliers. De nombreux travaux se sont déjà intéressés à la capture d état d applications dans des contextes particuliers. Certains de ces travaux s intéressent à la conception de langages appropriés à la capture de l état, alors que d autres cherchent à mettre en œuvre des mécanismes de bas niveau permettant de réaliser des captures binaires de l état de programmes écrits dans des langages compilés indépendamment du langage. La section 2.1 présente les motivations ainsi que certains principes de base de la capture d état. Les sections suivantes détaillent différentes techniques de capture d état ainsi que les avantages et inconvénients de chacune d entre elles Introduction à la capture d état La mémoire de travail physique des ordinateurs, la «mémoire vive», étant volatile, un programme informatique qui s arrête perd toutes les informations relatives à son état. La mémoire nonvolatile d un ordinateur, c est-à-dire les supports de stockage tels que les disques durs, est généralement accessible par la notion de fichier, dont la manipulation est clairement distincte de l utilisation de la mémoire volatile 1. Une application peut créer des fichierspour y sauvegarder explicitement tout ou partie de son état, de manière à éventuellement pouvoir restaurer cet état de manière explicite lors d une prochaine exécution. Toutefois, pour sauvegarder des structures de données complexes dans un fichier,l auteur d applications devra lui-même définirun format de fichierpermettant de décrire aussi fidèlement que possible les données que son programme manipule, et il devra écrire des modules permettant de «mettre à plat» les données dans le fichier(on parle de «serialization») puis de les extraire pour les restaurer («deserialization»). Même si ce travail est facilité par les formats de fichier génériques tel que XML et les outils permettant facilement de les manipuler, il s avère rapidement fastidieux et représente souvent une partie importante du programme (de l ordre de 30% du code source d après Atkinson [2]). Dans le cadre d un système sûr de fonctionnement ou à haute disponibilité, il est important qu une défaillance du système n entraîne pas la perte des données sur lesquelles travaille l application. Capturer l état d une application critique permet, en cas de faute, de redémarrer rapidement l application en restaurant son état, de sorte que peu ou pas d informations auront été perdues. Le simple fait de disposer d une capture de l état de l application permet ensuite de mettre en œuvre différentes stratégies de tolérance aux fautes : réplication passive, réplication semi-active, réplication active (chapitre 1). La possibilité de réaliser régulièrement des captures de l état d une application (on parle de «checkpointing») est un point crucial pour un système tolérant aux fautes. Ce mécanisme a donc deux objectifs. D une part, il donne l impression au programmeur que les données manipulées par son programme ne sont pas volatiles mais persistantes : toutes les données du programme ont une durée de vie illimitée, qu il s agisse ou non de fichiers.d autre part, selon les applications, il peut être nécessaire que le ou les flux d exécution des brins de l application soient eux-aussi persistants : dans ce cas, chaque brin d exécution («thread») de l application a la possibilité de reprendre son exécution après une défaillance là où elle en était avant. La section 3.6 revient sur cet aspect plus en détail. 1 Notons toutefois que la possibilité d associer le contenu d un fichier à une zone mémoire avec mmap () tend à effacer partiellement cet aspect. 11

20 12 Chapitre 2. Capture d état, état de l art Les sections suivantes présentent différents outils logiciels qui permettent de mettre en œuvre, de façon plus ou moins générique, des mécanismes de capture de l état d application. Certains d entre eux sont transparents, c est-à-dire que leur mise en œuvre ne demande que peu, voire pas, de modifications de l application que l on souhaite rendre persistante.on parle de persistance orthogonale lorsque les mécanismes de persistance sont clairement séparés de la partie fonctionnelle de l application, respectant ainsi le principe de «séparation des préoccupations» évoqué en section 1.2 [45]. Certains de ces mécanismes ne permettent de réaliser que des sauvegardes des données de l application, alors que d autres sont capables d en sauvegarder également le flux d exécution. Enfin, alors que certains de ces systèmes ne permettent que de faire une sauvegarde binaire de l état de l application, c est-àdire une sauvegarde qui n a de sens que sur une plate-forme donnée (architecture matérielle, système d exploitation, compilateur 1 ), d autres permettent de réaliser des captures d état portables d une plateforme à l autre. En tolérance aux fautes, les captures d état portables, c est-à-dire indépendantes de la plate-forme sur laquelle a été réalisée la capture, sont intéressantes car elles permettent de diversifierles plateformes sur lesquelles fonctionne l application critique. La redondance de l application sur des plateformes différentes permet d éliminer certaines fautes qui ne peuvent avoir lieu que pour une configuration bien précise [32, p. 100]. C est pour cette raison que l outil développé durant le stage qui sera présenté en section 3.2 se donne pour objectif de permettre de façon générique de créer des captures d état portables dans le cadre d applications écrites en langage C ou C Langages persistants Pour permettre l écriture d applications persistantes, une approche consiste à doter les langages de programmation de facilités permettant au programmeur de manipuler de manière transparente des données qui sont en fait persistantes. Le premier langage persistant, PS-Algol [2], était conçu comme une extension d un langage existant, S-Algol. S-Algol est un langage fortement typé : des vérificationsde type peuvent être effectuées à l exécution, par exemple 2. Cette fonctionnalité permet aux mécanismes de capture d état d être génériques car fournis par le système de prise en charge de l exécution («run-time support system»). De ce fait, peu de modificationsont dû être apportées au langage et au compilateur. Toutefois, PS-Algol ne fournit pas la persistance de manière transparente : le programmeur doit lui-même explicitement appeler une fonction pour demander l écriture d une capture d état sur disque. Le successeur de PS-Algol, Napier 88 [40], est un langage qui a été spécialement créé dans le but de servir à la création d un système persistant. Il nécessite donc un apprentissage particulier de la part du programmeur. Tout comme PS-Algol mais contrairement à Napier 88, le projet Persistent Java [3] (ou PJava) a pour objectif la mise en œuvre de mécanismes permettant la persistance des données manipulées par le programme avec peu ou pas de modificationsà un langage existant, en l occurrence Java. Un autre objectif de PJava est de pouvoir être utilisé avec des programmes existants en Java sans engendrer de perte de performance. L essentiel des mécanismes requis sont implémentés par la machine virtuelle Java. Le «ramasse-miettes» (ou «garbage collector») de celle-ci est responsable de l écriture des objets «récoltés» vers un support de stockage à long terme. Le standard CORBA propose une approche permettant la réalisation de captures d état portables d applications CORBA grâce à son Persistent State Service (PSS) [7]. Le mécanisme proposé n est pas transparent et repose sur une description faite par le programmeur de l état qu il est nécessaire de 1 Un certain nombre de caractéristiques varient d une plate-forme à l autre et notamment la taille des types de bases (e.g. selon la plate-forme, un int peut être codé sur 32 ou 64 bits), l ordre des octets ou «endianness», les contraintes d alignement des données, les conventions d appel de fonctions, etc. 2 Cette fonctionnalité existe aussi en C++ pour les classes contenant des méthodes virtuelles et est connue sous le nom de RTTI (Run-Time Type Identification).