DEPARTEMENT D'INFORMATIQUE MEMOIRE. Présenté par. L I M AM S aïd. Pour obtenir LE DIPLOME DE MAGISTER. Spécialité Informatique

Transcription

1 DEPARTEMENT D'INFORMATIQUE MEMOIRE Présenté par L I M AM S aïd Pour obtenir LE DIPLOME DE MAGISTER Spécialité Informatique Option : Systèmes Informatiques Répartis Intitulé : GESTION DE TOLERANCE AUX FAUTES DANS LES CLOUD COMPUTING AVEC CLOUDSIM Soutenu le : 01 /07 /2012 Devant les membres du jury : Président M elle BOURENANE Malika M.C-A Université d Oran Examinateur M r KADDOUR Mejdi M.C-A Université d Oran Examinateur M r LOUKIL Lakhdar M.C-A Université d Oran Encadreur M r BELALEM Ghalem M.C-A Université d Oran

2 REMERCIEMENTS J e tiens, tout particulièrement à exprimer mes vifs remerciements à mon encadreur Dr BELALEM Ghalem maître de conférences à l Université d Oran, pour m avoir donner l opportunité de réaliser ce sujet sous sa direction, la confiance et l aide qu il m a accordé ainsi que ses conseils précieux et son temps consacré tout au long du travail. Je remercie aussi Dr BOURENANE Malika maître de conférences à l Université d Oran, pour m avoir fait l honneur de présider mon jury. Toutes mes reconnaissances vont également aux membres du jury : Dr KADDOUR Mejdi maître de conférences à l Université d Oran Dr LOUKIL Lakhdar maître de conférences à l Université d Oran Pour avoir accepté d évaluer ce travail. Je voudrai aussi exprimer ma grande affection à toute ma famille, en particulier, mes parents, mes sœurs pour leur présence continue et leur soutien indéfectible. Enfin, ma dernière pensée et mon dernier merci vont à ma fiancée, pour la motivation et le courage qu elle m a insufflé au début de cette aventure.

3 Table des matières Introduction i 1 Informatique dans le nuage Description du cloud computing Historique La virtualisation Composants du Cloud L informatique en tant que service Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Software as a Service (SaaS) Avantages et Inconvénients des services Modèles de déploiement Le nuage privé Le nuage public Le nuage hybride La di érence entre le cloud privé et le cloud public Vers la fédération de nuages ou «Intercloud» Avantages et inconvénients du Cloud Computing Avantages Inconvénients La sécurité Conclusion La tolérance aux pannes Notion de sûreté de fonctionnement Attributs de la sûreté de fonctionnement Entraves à la sureté de fonctionnement Moyens d assurer la sûreté de fonctionnement Classi cation des pannes

4 TABLE DES MATIÈRES Détection des pannes Méthodes de tolérance aux pannes Techniques de tolérance aux pannes dans les systèmes répartis Tolérance aux pannes par duplication Tolérance aux pannes par sauvegarde (checkpointing) Analyse comparative des di érentes méthodes de point de reprise Tolérance aux pannes par journalisation Comparaison de di érentes protocoles de tolérance aux pannes par reprise La tolérance aux pannes dans les Cloud Migration Live migration, pourquoi? Conclusion Nos contributions Objectifs du travail Description de la 1 ère approche proposée Les éléments fonctionnels Les di érentes phases Phase de sauvegarde Phase de surveillance La phase d analyse La phase de traitement d erreur La description de la 2 eme approche Quand utiliser le mécanisme de migration? Scénarios de la migration Paramètres fonctionnels utilisés dans les deux approches Conclusion Implémentation de CloudSim-FT Langage et environnement de développement Langage de programmation Java Environnements de développement Architecture de CloudSim Description du fonctionnement de notre application Diagramme d utilisation Diagramme de classes Diagramme de séquence Interface principale Con guration des paramètres de simulation Lancement de la simulation Résultats expérimentaux Expérience 1 : Nombre de cloudlet echouées Expérience 2 : In uence de la période de sauvegarde (intervalle de checkpoint)

5 TABLE DES MATIÈRES Expérience 3 : Impact de la fréquence des pannes sur le comportement de notre première approche Expérience 4 : Comportement de la deuxième approche Synthèse des expériences Conclusion Conclusion générale et perspectives 87

6 Table des gures 1.1 Cloud Computing Interet pour le terme "cloud computing" sur Internet Composants du cloud Les di érents types de services dans le Cloud Modèle de distribution de l infrastructure en tant que service Type de cloud comuting Intercloud : le nuage des nuages La chaîne fondamentale des entraves à la sureté de fonctionnement [5] L arbre de la sûreté de fonctionnement [45] Exemple de protocole de duplication active Exemple de protocole de réplication passive Exemple de protocole de duplication semi-active Migration de processus Les principales phases de notre proposition Architecture globale de l approche de tolérance aux pannes proposée Modèle d exécution sans pannes Modèle d exécution sans mécanisme de sauvegarde Algorithme de Checkpoint Mécanismes de heartbeat et watchdog Transitions d états de la charge d un Datacenter Procédure de rétablissement Architecture globale de l approche basée sur la migration et la sauvegarde Migration au prochain checkpoint Checkpoint avant migration Architecture de CloudSim Diagramme d utilisation du simulateur Diagramme de classe de la conception de simulateur CloudSim Diagramme de séquence sans utiliser la tolérance aux pannes

7 TABLE DES FIGURES Diagramme de séquence de l approche basée sur le mécanisme de checkpoint Digramme de séquence de l approche basée sur la combinaison des mécanismes de checkpoint et de migration Interface principale du CloudSim-FT Con guration du Datacenter Con guration des machines virtuelles Con guration des Cloudlets con guration de mécanisme de tolérance aux pannes Interface de lancement de la simulation et de la visualisation des résultats Nombre de cloudlets échouées sans tolérance aux pannes Nombre de cloudlets échouées avec tolérance aux pannes In uence des pannes sur le nombre de Cloudlets Impact de l intervalle de checkpoint sur le surcoût de sauvegarde Impact de l intervalle de checkpoint sur le temps d exécution Impact des pannes sur le temps d exécution Impact des pannes sur Le temps perdu Impact des pannes sur le surcoût de checkpoint Temps d exécution pour les trois approches In uence des pannes sur le nombre de migration E et de la migration sur le taux d utilisation des Datacenter Le temps d exécution globale et le temps gagné des trois approches.. 85

8 Liste des tableaux 1.1 Les avantages et les inconvénients des di erents services Comparaison entre les trois approches de redondance Comparaison des di érentes méthodes de tolérance aux pannes par reprise Les di érentes phases et leurs activités Rôle de chaque agent dans les di érentes phases de tolérance aux pannes E et de la fréquence des pannes sur le temps d exécution E et de la fréquence des pannes sur le temps perdu E et de la fréquence des pannes sur sur le surcoût de checkpoint E et de la fréquence des pannes sur le surcoût de checkpoint Le pourcentage d utilisation des Datacenter Le temps d exécution global et le temps gagné des trois approches

9 Introduction Lannée 2008 a vu l émergence du terme «Cloud Computing» (ou L informatique dans les nuages) dans les journaux spécialisés, et les annonces des nouvelles solutions chez tous les grands acteurs de l informatique : Microsoft, Google, Amazon, IBM, Dell, Oracle,... Dans l e ervescence qui accompagne toute grande nouveauté dans le monde de l informatique, le Cloud Computing est apparu pour certains comme une révolution et pour d autres comme un simple terme de Marketing qui ne fait que rassembler des services et des technologies qui existent depuis longtemps. L approche du cloud computing s appuie principalement sur le concept de virtualisation. Ce concept est un ensemble de techniques permettant de faire fonctionner sur une seule machine plusieurs systèmes d exploitation et/ou plusieurs applications, isolés les uns des autres. Un cloud est constitué d un ensemble de machines virtuelles qui utilisent la même infrastructure physique. Les techniques de virtualisation permettent notamment la migration de machines virtuelles d un nœud physique à un autre. En fait, les objectifs recherchés à travers la migration de machines virtuelles sont multiples : la répartition de charge, l accès aux ressources, la tolérance aux pannes ou encore pour accomplir certaines activités de maintenance. À l instar des autres services informatiques, les services de Cloud ne sont pas à l abri d une défaillance. En plus dans des tels systèmes le taux de pannes croit avec la taille du système lui-même. Dans un tel contexte, la sûreté de fonctionnement des applications est un élément de première importance, c est pourquoi un mécanisme de tolérance aux pannes devient nécessaire pour en assurer certains aspects. La tolérance aux pannes dans les systèmes répartis est un domaine qui a été très largement étudié depuis une trentaine d années. La littérature propose aujourd hui un grand nombre de protocoles de tolérance aux pannes par recouvrement arrière, que l on peut diviser en deux catégories : les protocoles par points de reprise [42] [53] et les protocoles par journalisation [18] [62]. Chacune de ces catégories présente des propriétés di érentes en termes de performance, et n est parfois pas applicable selon le système ou selon l application considérée. Notre contribution consiste à proposer une approche de tolérance aux pannes permettant de masquer la défaillance d un composant. Dans la première partie nous nous focalisons sur le mécanisme de sauvegarde / reprise (checkpoint), qui est un des mécanismes les plus utilisés dans les systèmes répartis. Dans la seconde partie nous étudions la combinaison de mécanisme de sauvegarde avec la migration. i

10 0. Introduction ii * Pour l essentiel, notre mémoire est structuré autour de quatres chapitres : * Le premier chapitre présente un état de l art sur le Cloud Computing. * Dans le deuxième chapitre, le concept de la tolérance aux fautes est abordé ainsi que les travaux réalisés dans ce domaine. * Le troisième chapitre est destiné à l étape de conception de nos contribution qui prendra en compte la gestion de tolérance aux pannes. * Le quatrième chapitre s appesantit en premier lieu à la concrétisation de la conception présentée en chapitre 3, et en second lieu à l a chage de quelques résultats et leurs interprétations. * En n pour terminer ce manuscrit, nous présentons une conclusion pour synthétiser notre travail ainsi qu un ensemble de perspectives pour des travaux futurs.

11 CHAPITRE 1 Informatique dans le nuage Sommaire 1.1 Description du cloud computing Historique La virtualisation Composants du Cloud L informatique en tant que service Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Software as a Service (SaaS) Avantages et Inconvénients des services Modèles de déploiement Le nuage privé Le nuage public Le nuage hybride La di érence entre le cloud privé et le cloud public Vers la fédération de nuages ou «Intercloud» Avantages et inconvénients du Cloud Computing Avantages Inconvénients La sécurité Conclusion

12 1. Informatique dans le nuage 2 Linformatique dans le nuage est plus connue sous sa forme anglo-saxonne : «Cloud Computing», mais il existe de nombreux synonymes francophones tels que : «informatique dans les nuages», «infonuagique» (Québec) ou encore «informatique dématérialisée». C est un domaine qui regroupe les technologies de distribution, à la demande et via Internet, de services informatiques logiciels et matériels. L idée principale de ces technologies est de distribuer des ressources informatiques comme un service d utilité publique, conformément à ce qui avait été imaginé par les pionniers de l informatique moderne, il y a plus de 40 ans [51]. Ce principe de distribution publique de ressources informatiques anime également la communauté de la grille informatique, si bien qu il est parfois di cile de distinguer la frontière entre «Grille» et «informatique dans le nuage». Cette di culté est d autant plus réelle que l informatique dans les nuages est un concept jeune, dont les premières implantations datent de 2006, et dont le développement s est accéléré durant ces dernières années [35]. 1.1 Description du cloud computing Le «cloud computing» est un néologisme utilisé pour décrire l association d Internet («cloud», le nuage) et l utilisation de l informatique («computing» ). C est une manière d utiliser l informatique dans laquelle tout est dynamiquement couplé et évolutif et dans laquelle les ressources sont fournies sous la forme de services au travers d Internet. Les utilisateurs n ont ainsi besoin d aucune connaissance ni expérience en rapport avec la technologie derrière les services proposés [40]. Fig. 1.1 Cloud Computing Le Cloud Computing est un nuage de services et de données. Plus précisément,

13 1. Informatique dans le nuage 3 c est un paradigme, et à ce titre, il est di cile de lui donner une dé nition exacte et de dire avec certitude s il s agit ou non de Cloud. Il faut donc être vigilant, car de nombreux fournisseurs de services utilisent le mot «Cloud» à des ns marketings. Sur Internet, il n y a pas de dé nition exacte du Cloud Computing et donc pas de certi cation pour dire si nous avons à faire à un «vrai Cloud». Nous tenterons toutefois, au travers de ce mémoire, de donner les principales clés pour comprendre le Cloud Computing. Pour Wikipédia, il s agit d «un concept de déportation sur des serveurs distants et traitements informatiques traditionnellement localisés sur le poste client» [22]. Pour le Syntec, cela consiste en «une interconnexion et une coopération de ressources informatiques, situées au sein d une même entité ou dans diverses structures internes, externes ou mixtes, et dont le mode d accès est basé sur les protocoles et standards Internet» [63]. Pour vulgariser, L informatique dans le nuage s appuie sur une infrastructure (le nuage) composée d un grand nombre de ressources virtualisées (par exemple : réseaux, serveurs, stockage, applications ou services), distribuées dans le monde entier. Ces ressources peuvent être allouées, puis relâchées rapidement, avec des e orts de gestion minimaux et avec peu d interactions entre le client et le fournisseur. Aussi, cette infrastructure peut être dynamiquement recon gurée pour s ajuster à une charge de travail variable (passage à l échelle). Finalement, les garanties de prestation o ertes par l informatique dans le nuage prennent typiquement la forme de contrats de niveau de service [35]. Le Cloud Computing n impose aucune dépense en immobilisation puisque les services sont payés en fonction de l utilisation. Cela permet aux entreprises de ne plus se focaliser sur la gestion, la maintenance et l exploitation de l infrastructure ou des services applicatifs. Les fortes avancées dans le domaine de la virtualisation ont rendu possible le Cloud Computing. Cette virtualisation permet d optimiser les ressources matérielles en les partageants entre plusieurs environnements («time-sharing» ). De même, il est possible de coupler l application (et son système d exploitation) et le matériel (encapsulé dans la machine virtuelle), cela assure également un «provisionning», c est-à-dire la capacité de déploiement d environnement, de manière automatique. Le Cloud Computing couplé, aux technologies de virtualisation, permet la mise à disposition d infrastructures et de plate-forme à la demande. Mais le Cloud Computing ne concerne pas seulement l infrastructure, il bouleverse la plate-forme d exécution et les applications [35]. Le cloud computing correspond au développement et à l utilisation d applications

14 1. Informatique dans le nuage 4 accessibles uniquement via Internet. Les utilisateurs dépendent ainsi uniquement d Internet pour utiliser leurs logiciels, ils ont la possibilité d accéder à des services sans installer quoique ce soit d autre qu un simple navigateur Internet. Aujourd hui, le cloud computing est exploité par la quasi-totalité des grandes entreprises car il fournit une analyse sophistiquée des données de la manière la plus rapide possible [40] Historique Techniquement, le concept de cloud computing est loin d être nouveau, il est même présent depuis des décennies. On en trouve les premières traces dans les années 1960, quand John McCarty 1 a rmait que cette puissance de traitement informatique serait accessible au public dans le futur. Le terme en lui-même est apparu plus couramment aux alentours de la n du XXe siècle et il semblerait que Amazon.com soit l un des premiers à avoir assemblé des data centers et fournit des accès à des clients. Les entreprises comme IBM et Google ainsi que plusieurs universités ont seulement commencé à s y intéresser sérieusement aux alentours de 2008, quand le cloud computing est devenu un concept "à la mode" [40]. Réalisant ce qu ils pourraient faire de toute cette puissance, de nombreuses compagnies ont ensuite commencé à montrer un certain intérêt à échanger leurs anciennes infrastructures et applications internes contre ce que l on appelle les "pay per-use service" (services payés à l utilisation) [40]. Auparavant, seuls les super-ordinateurs permettaient de fournir cette puissance et étaient principalement utilisés par des gouvernements, des militaires, des laboratoires et des universités pour réaliser des calculs aussi complexes que prédire le comportement d un avion en vol, les changements climatiques ou la simulation d explosions nucléaires. Désormais, des entreprises comme Google fournissent des applications qui exploitent le même type de puissance et sont accessibles à tout moment, de n importe où et par tout via Internet. Quelques universités prestigieuses ont également lancé leurs propres programmes de cloud computing en fournissant des accès à des maillages de centaines ou milliers de processeurs et des entreprises comme IBM ont récemment annoncé leur intention d utiliser massivement le cloud computing a l avenir. Ces derniers ont récemment dévoilé un système ultra-performant connu sous le nom de "Blue Cloud" qui permettra d aider les banques et diverses entreprises à distribuer leurs calculs sur un très grand nombre de machines sans posséder d infrastructure interne. Le 24 mars 2008, Yahoo! a même annoncé avoir débuté un partenariat avec la Carnegie Mellon University de 1 John McCarthy (né le 4 septembre 1927, à Boston, Massachusetts - mort le 24 octobre 2011) est le principal pionnier de l intelligence arti cielle avec Marvin Minsky ; il incarne le courant mettant l accent sur la logique symbolique.

15 1. Informatique dans le nuage 5 Fig. 1.2 Interet pour le terme "cloud computing" sur Internet Pittsburgh a n de leur mettre à disposition, à des ns de recherche, un ordinateur doté de processeurs situe dans les locaux de la rme [69]. Actuellement les experts sont convaincu que bientôt, nous utiliserons le cloud computing de la même manière que nous utilisons l électricité, c est à dire en payant uniquement ce que nous consommons sans même nous soucier des aspects techniques nécessaires au bon fonctionnement du système. Le principal facteur de développement restant le fait que toute cette puissance est à tout moment partagée par plusieurs utilisateurs et évite ainsi de perdre du "temps machine" à ne rien faire. Cela devrait également drastiquement réduire les couts de développements et donc les prix [40] La virtualisation La virtualisation a été la première pierre vers l ère du Cloud Computing. En e et, cette notion permet une gestion optimisée des ressources matérielles dans le but de pouvoir y exécuter plusieurs systèmes «virtuels» sur une seule ressource physique et fournir une couche supplémentaire d abstraction du matériel. Les premiers travaux peuvent être attribués à IBM, qui dans les années 60, travaillait déjà sur les mécanismes de virtualisation en développant dans les centres de recherche de Cambridge et de Grenoble, CMS (Conversation Monitor System), le tout premier hyperviseur. C est donc depuis presque 50 ans que l idée d une informatique à la demande est présente dans les esprits même si les technologies n étaient jusqu alors pas au rendezvous pour pouvoir concrétiser cette idée. Avec les di érents progrès technologiques réalisés durant ces 50 dernières années, tant sur le plan matériel, logiciel et conceptuel, aux avancées des mécanismes de sécurité, à l élaboration de réseaux complexes mais standardisés comme Internet, et à l expérience dans l édition et la gestion de logiciels, services, infrastructures et stockage de données, nous sommes maintenant prêts à entrer

16 1. Informatique dans le nuage 6 dans l ère du Cloud Computing, telle que rêvait par John McCarthy en 1961 [66]. 1.2 Composants du Cloud La Figure 1.3 illustre les composants communs de cloud computing [57]. Fig. 1.3 Composants du cloud a. Applications virtualisées : Les applications virtualisées rendent compatible les applications de l utilisateur avec les hardwares, les systèmes d exploitations, le réseau et le stockage pour permettra la exibilité du déploiement. b. Infrastructure virtualisée : L infrastructure virtualisée fournit l abstraction nécessaire pour s assurer qu une application ou un service ne soit pas directement attachée à l infrastructure matérielle (serveurs, stockage ou réseaux). Ceci permet au service de se déplacer dynamiquement à travers les ressources virtualisées d infrastructure.

17 1. Informatique dans le nuage 7 c. Gestion de sécurité et d identité : Le système de gestion de sécurité fournie les commandes nécessaire pour assurer les informations sensibles (les protéger ) et rependre au exigence de conformité. d. Développement : Les infrastructures de développement facilitent non seulement l orchestration de service mais permettent également aux processus d être développés. C est les outils de développement comme le compilateur, SDK (Software Development Kit) et l environnement de développement. e. Gestion d entreprise : La couche de gestion d entreprise manipule le cycle de vie des ressources virtualisées et fournit les éléments additionnels d infrastructure commune pour la gestion de taux de disponibilité, utilisation dosée, gestion de politique, gestion de permis, et recouvrement des pertes. 1.3 L informatique en tant que service On distingue trois sous-ensembles de services (Figure 1.4) au sein de l informatique dans le nuage : le logiciel en tant que service (SaaS), la plateforme en tant que service (PaaS) et l infrastructure en tant que service (IaaS). Chacun de ces types de service correspond à un niveau d abstraction logiciel précis par rapport aux ressources informatiques matérielles accessibles via Internet, et donc hébergées au sein du nuage du point de vue de l utilisateur [51]. Fig. 1.4 Les di érents types de services dans le Cloud

18 1. Informatique dans le nuage 8 C est l infrastructure en tant que service qui correspond au plus faible niveau d abstraction que l on peut obtenir par rapport aux ressources informatiques partagées via le nuage. En utilisant ce type de service, les utilisateurs peuvent directement administrer les ressources informatiques qu ils consomment. Un exemple de service appartenant à cette catégorie est la location de serveurs virtuels proposée par Amazon EC2 [2]. Avec cette solution, les clients peuvent installer le système d exploitation et les composants logiciels de leur choix au sein des espaces d exécution virtualisés distribués par Amazon, comme ils le feraient sur une grappe de machines privées. A un niveau d abstraction supérieur, on trouve la plateforme en tant que service qui étend la gamme de services proposés par l infrastructure en tant que service avec des outils de développement d applications Web qui sont totalement hébergés chez le fournisseur. Finalement, au plus haut niveau d abstraction, on trouve les logiciels en tant que services, qui correspondent à des services logiciels classiques (bureautique, gestion de base de données simpli ée, etc.), dont la particularité est d être hébergé au sein du nuage et non sur une infrastructure privée Infrastructure as a Service (IaaS) L infrastructure en tant que service est plus connue sous le nom d IaaS pour «Infrastructure as a Service». Ce type de service consiste à distribuer des ressources informatiques telles que de la capacité de calcul, des moyens de stockage et de communication, de façon publique via Internet et sous une forme de paiement à l utilisation. Les clients de l infrastructure en tant que service peuvent donc exécuter et héberger leurs applications informatiques dans le nuage et ne paient que les ressources qu ils consomment. Ces services d approvisionnement en infrastructure peuvent servir, d une part à héberger des logiciels ou plateformes en tant que services et, d autre part, à être utilisés de façon plus générique en tant que ressources informatiques pour des applications très variées, allant de la sauvegarde de données jusqu au calcul haute performance, en passant par l analyse statistique de données. La variété d utilisation des services proposés par l infrastructure en tant que service en fait la technologie de l informatique dans le nuage la plus populaire. Aussi lorsque l on parle d informatique dans le nuage, on fait souvent référence à l infrastructure en tant que service. La particularité de l infrastructure en tant que service est de fournir un approvisionnement en ressources informatiques de qualité, qui soit extensible sur commande et dont la capacité dépasse généralement la demande. Le nuage est alors vu par ses utilisateurs comme une source in nie de capacité de calcul, de stockage et de communication. Internet devient alors une place de marché où l infrastructure informatique est distribuée, et consommée en tant que marchandise, selon le modèle illustré sur la

19 1. Informatique dans le nuage 9 Figure 1.5. Fig. 1.5 Modèle de distribution de l infrastructure en tant que service Ce modèle de distribution d infrastructure assouplit le mode d investissement en ressources matérielles et logicielles des industries, ouvrant des perspectives jusqu alors inconnues pour les sociétés et organismes ayant besoin de disposer d un accès direct à une infrastructure informatique. En e et, d après les chercheurs de l Université de Berkeley [6], les trois raisons majeures du succès de l infrastructure en tant que service sont les suivantes : 1. L illusion d une capacité de calcul in nie de la part des utilisateurs du nuage, permettant aux clients de l informatique dans les nuages de se reposer sur un unique service pour l approvisionnement de ressources de calcul à long terme. 2. L assouplissement du mode d investissement des utilisateurs du nuage, permettant aux entreprises de commencer petit, puis d augmenter les ressources informatiques matérielles seulement si le besoin s en fait sentir. 3. La possibilité de payer pour l utilisation de ressources de calcul sur une base à court terme (c.-à-d. accès aux serveurs virtuels à l heure), permettant une utilisation économe des capacités informatiques, en relâchant les ressources de calcul dès qu elles deviennent inutilisées.

20 1. Informatique dans le nuage Platform as a Service (PaaS) La plateforme en tant que service, plus connue sous l appellation anglophone «Platform as a Service» (PaaS) se trouve à mi-chemin entre le logiciel en tant que service et l infrastructure en tant que service. Aussi, il est di cile de dé nir les frontières entre plateforme et infrastructure, aussi bien qu entre plateforme et logiciel en tant que service [6]. Cependant, nous proposons de caractériser ce type de service comme suit : la plateforme en tant que service o re un environnement de développement et de déploiement pour les logiciels en tant que service, qui est accessible et hébergé au sein du nuage. Les services o erts par cette technologie facilitent le déploiement des applications (souvent déployées comme logiciels en tant que service), en abstrayant à ses utilisateurs les coûts et la complexité de maintenance de l infrastructure sous-jacente, et ce, pendant l intégralité du cycle de vie des applications. Ainsi, ces services sont généralement adressés à des développeurs de logiciels souhaitant utiliser une même plateforme pour les cycles de développement et de déploiement de leurs applications. Les plateformes en tant que services incluent généralement des services d aide au développement tels que des applications de conceptions, de versionnement, de test, d intégration de service Web ou de base de données, etc. Elles incluent également des services d aide au déploiement tels que l hébergement d application, la surveillance des applications, le stockage de données, l allocation dynamique de ressources, la gestion de la persistance des données, etc. En n, les services proposés par une plateforme en tant que service sont généralement délivrés sous la forme d une solution intégrée accessible via des interfaces Web publiques. On peut distinguer deux types principaux de plateformes en tant que services : les plateformes de développement d extension et les plateformes de développement d applications autonomes. Les plateformes de développement d extension sont généralement mises à disposition par les grands éditeurs de logiciels en tant que services, dans le but de permettre à leurs utilisateurs d ajouter des fonctions personnalisées aux services classiques. Les plateformes de développement d extension les plus connues sont proposées par de grands éditeurs de logiciels en tant que services tels que Salesforce [61] et Netsuite [56]. Par exemple, Salesforce propose des outils de création assistée de base de données ou encore de personnalisation d interface graphique qui sont conçus pour que les utilisateurs puissent personnaliser leur environnement de travail au sein de la plateforme en tant que service. Les plateformes de développement d applications autonomes sont, dans leur principe, plus proches de l infrastructure en tant que service. Elles proposent généralement, en plus de la distribution d infrastructure, des services de développement permettant de se reposer sur le Nuage pour l intégralité du cycle de vie des applications clientes. C est le cas, par exemple, du service Google Code

21 1. Informatique dans le nuage 11 [38] qui prend en charge l hébergement du code d une application ainsi que son versionnement. Les plateformes en tant que service favorisent généralement l utilisation d une technologie propriétaire ou de services ciblés, comme c est le cas pour les o res Windows Azure [68] ou Google App Engine [39]. Par exemple, la plateforme Google App Engine met à disposition de ses clients des interfaces de programmation qui facilitent l intégration des services logiciels distribués par Google, comme la gestion des comptes utilisateurs ou encore la gestion de partage des documents. La plateforme Windows Azure, elle favorise l utilisation des technologies et services appartenant à Microsoft, comme l environnement de développement «.Net» ou la gamme de services «Live» Software as a Service (SaaS) Le logiciel en tant que service est un logiciel accessible à la demande, via Internet. Il est également connu sous l appellation «SaaS», dérivée de l expression anglophone «Software as a Service». Le logiciel en tant que service est un concept apparu au début du siècle. Les logiciels en tant que service sont les services du nuage qui visent le plus grand nombre d utilisateurs, car contrairement à l infrastructure et à la plateforme en tant que service, leur utilisation ne demande aucune connaissance particulière en technologie de l information et des télécommunications. Ces services sont accessibles via Internet, c est-à-dire hébergés dans le nuage du point de vue de l utilisateur, et sont généralement utilisables via un simple navigateur web. Une autre particularité est d être facturé par abonnement plutôt que par licence logicielle. Ils ont été initialement déployés pour automatiser les forces de ventes des entreprises, ainsi que la gestion de leur clientèle, comme ce fut le cas avec la solution Salesforce [61], considérée comme pionnier du logiciel en tant que service. Aujourd hui, les logiciels en tant que services sont largement utilisés par les entreprises pour di érentes tâches telles que la comptabilité, la facturation en ligne, la gestion de ressources humaines et les suites bureautiques de gestion de documents. L avantage des logiciels en tant que services est multiple pour les utilisateurs. En premier lieu, ils béné cient d un accès nomade et multiplateforme à leurs applications, grâce à l hébergement dans le nuage et grâce à l utilisation d accès standardisés (accès via interface Web). Ensuite, la distribution de logiciel à la demande et le mode de facturation par abonnement permettent aux entreprises clientes d assouplir leur mode d investissement dans les technologies informatiques : ils peuvent dynamiquement adapter leur consommation logicielle en fonction de leur besoin. Finalement, ils jouissent d une utilisation plus simple des services logiciels, sans avoir à se soucier de leur installation ou de leur mise à jour. Il existe une catégorie particulière de service logiciel distribué via Internet qui n est

22 1. Informatique dans le nuage 12 pas systématiquement considérée comme faisant partie du logiciel en tant que service, il s agit des services gratuits à l utilisation. Ces services sont indirectement nancés par la publicité, ou par des produits dérivés de l analyse statistique à grande échelle. La distribution du logiciel en tant que service est principalement freinée par deux problématiques : la dépendance technologique vis-à-vis du fournisseur et la con dentialité des données produites par les clients. Ces deux problèmes se généralisent à tous les types de services accessibles via le nuage. Cependant, il est important de comprendre que la con ance accordée au prestataire qui fournit le service logiciel est une composante importante du marché de la distribution logiciel, en particulier lorsque celle-ci est réalisée via le Nuage. Cette notion de con ance explique, en partie, la polarisation du marché vers un faible nombre de grands distributeurs tels que Salesforce [61] ou encore NetSuite [56]. En résumé, le logiciel en tant que service peut être gratuit ou payant, intégrer des notions de réseautage social ou encore de di usion de média. Les services ainsi proposés, en particulier lorsqu ils sont payants, sont régis par des contrats de niveau de service. Ces contrats dé nissent typiquement le dédommagement prévu pour les clients en cas d indisponibilité du service vendu. Par exemple, les contrats de niveau de service fournis par Salesforce [61] prévoient de dédommager les clients sous forme de remise forfaitaire en cas d indisponibilité du service. Le mode de facturation de ce service étant mensuel, lorsque l abonnement d un client arrive à échéance, les deux partis (le client et le prestataire) établissent un bilan au sein duquel le taux d indisponibilité du service durant le mois écoulé est mesuré. Des remises forfaitaires, inscrites au contrat de niveau de service, sont alors appliquées en fonction de cette mesure Avantages et Inconvénients des services Le tableau 1.1 illustre les services de Cloud Computing qui ont été décrites dans la section précédente tout en montrant les avantages et les inconvénients de chaque service [47].

23 1. Informatique dans le nuage 13 Avantage inconvenient -pas d installation -logiciel limité Saas -plus de licence -sécurité -migration -dépendance des prestataires -pas d infrastructure nécessaire -limitation des langages PaaS -pas d installation -pas de personnalisation dans la -environnement hétérogène con guration des machines virtuelles -administration -sécurité IaaS -personnalisation -besoin d un administrateur système - exibilité d utilisation Tab. 1.1 Les avantages et les inconvénients des di erents services 1.4 Modèles de déploiement Un nuage correspond à une infrastructure distante, dont on ne connaît pas les détails architecturaux, et qui est connue pour les services informatiques qu elle o re. Aussi, il est courant d utiliser le terme un nuage pour désigner l infrastructure gérée par un prestataire donné. On peut distinguer trois types principaux de modèles de déploiement pour ces nuages : le nuage privé, le nuage public et le nuage hybride, (Voir Figure 1.6). Fig. 1.6 Type de cloud comuting Le nuage privé L infrastructure d un nuage privé n est utilisée que par un unique client. Elle peut être gérée par ce client ou par un prestataire de service et peut être située dans les lo-

24 1. Informatique dans le nuage 14 caux de l entreprise cliente ou bien chez le prestataire, le cas échéant. L utilisation d un nuage privé permet de garantir, par exemple, que les ressources matérielles allouées ne seront jamais partagées par deux clients di érents Le nuage public L infrastructure d un nuage public est accessible publiquement ou pour un large groupe industriel. Son propriétaire est une entreprise qui vend de l informatique en tant que service Le nuage hybride L infrastructure d un nuage hybride est une composition de deux types de nuages précédemment cités. Les di érents nuages qui la composent restent des entités indépendantes à part entière, mais sont reliés par des standards ou par des technologies propriétaires qui permettent la portabilité des applications déployées sur les di érents nuages. Une utilisation type de nuage hybride est la répartition de charge entre plusieurs nuages pendant les pics du taux d utilisation [3] La di érence entre le cloud privé et le cloud public Dans le cas du cloud public, votre cloud ne vous appartient pas entièrement. Un grand nombre de ressources informatiques sont partagées avec de nombreuses entreprises à travers l ensemble du réseau Internet. Si ce modèle possède de nombreux avantages en termes de réduction des coûts, de collaboration et d agilité, pour certaines entreprises, en revanche, il soulève, parfois à juste titre et parfois tort, certaines questions sur la sécurité et la con dentialité des données. De son côté, le cloud privé propose des ressources informatiques dont l usage est uniquement réservé à votre entreprise. Vous pouvez héberger votre cloud privé soit sur site, dans votre centre de données (en utilisant une virtualisation et une automatisation à grande échelle), soit hors site chez un fournisseur de services de cloud. Le cloud privé possède la plupart des avantages du cloud public (options de libre-service, relative capacité de montée en charge et facturation interne, par exemple) mais permet davantage de contrôle et de personnalisation du fait que des ressources dédiées sont à votre disposition. Il peut o rir encore plus de exibilité, ce qui peut rendre son coût prohibitif et amoindrir les économies d échelle pour certaines entreprises [3].

25 1. Informatique dans le nuage Vers la fédération de nuages ou «Intercloud» Un nuage correspond à une infrastructure et à son domaine d administration. De façon plus simple, il est courant d associer un nuage à l entreprise qui est responsable de la gestion de l infrastructure associée. On parlera alors du nuage d Amazon, de celui de Google, du nuage de Microsoft,... Cependant, du point de vue d un utilisateur, cet ensemble de nuages accessibles publiquement via Internet peut être vu comme un métanuage, au sein duquel un certain nombre de services et de ressources informatiques sont disponibles. De la même façon qu Internet est le réseau des réseaux. Ce méta-nuage est le nuage des nuages et on l appelle «Intercloud», son principe est illustré sur la Figure 1.7. Fig. 1.7 Intercloud : le nuage des nuages Intercloud est un ensemble de services et de ressources informatiques qui sont publiquement disponibles via Internet. Comme décrit au précédent, on retrouve trois grandes catégories de services : le logiciel, la plateforme et l infrastructure en tant que service. Le modèle de déploiement des applications distribuées sur une fédération de nuages correspond au nuage hybride. Il a pour particularité d utiliser plusieurs nuages au sein d un même environnement de déploiement.

26 1. Informatique dans le nuage Avantages et inconvénients du Cloud Computing Les principaux avantages et inconvénients associés au cloud computing sont les suivants [47] : Avantages Un démarrage rapide : Le cloud computing permet de tester le business plan rapidement, à coûts réduits et avec facilité. L agilité pour l entreprise : Résolution des problèmes de gestion informatique simplement sans avoir à vous engager à long terme. Un développement plus rapide des produits : Réduisons le temps de recherche pour les développeurs sur le paramétrage des applications. Pas de dépenses de capital : Plus besoin des locaux pour élargir vos infrastructures informatiques Inconvénients La bande passante peut faire exploser votre budget : La bande passante qui serait nécessaire pour mettre cela dans le Cloud est gigantesque, et les coûts seraient tellement importants qu il est plus avantageux d acheter le stockage nous-mêmes plutôt que de payer quelqu un d autre pour s en charger. Les performances des applications peuvent être amoindries : Un Cloud public n améliorera dé nitivement pas les performances des applications. La abilité du Cloud : Un grand risque lorsqu on met une application qui donne des avantages compétitifs ou qui contient des informations clients dans le Cloud. Taille de l entreprise : Si votre entreprise est grande alors vos ressources sont grandes, ce qui inclut une grande consommation du cloud. vous trouverez peutêtre plus d intérêt à mettre au point votre propre Cloud plutôt que d en utiliser un externalisé. Les gains sont bien plus importants quand on passe d une petite consommation de ressources à une consommation plus importante. 1.7 La sécurité Les exigences de sécurité constituent souvent un problème majeur avec des solutions de Software ou de Platform as a Service. Une étude menée par l Université de Darmstadt révèle que 22 % des personnes interrogées perçoivent les exigences de sécurité comme le principal obstacle à la mise en œuvre du cloud computing [46]. Les exigences juridiques, de con dentialité et de conformité arrivent en deuxième et troi-

27 1. Informatique dans le nuage 17 sième positions avec 19,8 % et 11,9 % respectivement. Étonnamment, les problèmes techniques sont bien moins perçus comme des obstacles : seulement 7,9 % de personnes expriment des doutes quant à la abilité de la solution et un pourcentage très bas (3,4 %) fait référence à des coûts potentiels de performances comme argument contre le cloud computing. Certains s inquiètent principalement que les données ou l identité tombent entre de mauvaises mains. Cela a été con rmé dans une étude menée par IBM [46] concluant que 80 % des entreprises craignent pour leur sécurité avec l introduction du cloud computing. En dépit des problèmes de sécurité existants, le triomphe du cloud computing sera à peine perturbé. L aspect nancier joue toujours un rôle central dans le processus de prise de décision lorsqu il s agit de sélectionner la bonne solution. Mais le cloud le devance : vous ne payez que pour les services que vous utilisez vraiment. Si le nombre d utilisateurs augmente, il su t simplement d ajouter de la capacité pour satisfaire cet accroissement des demandes ; si le nombre d utilisateurs en ligne diminue, il su t simplement de réduire la capacité a n de ne pas laisser une infrastructure informatique inutilisée. Au lieu de faire face à de forts investissements initiaux, les entreprises choisissent des coûts opérationnels exibles et déductibles d impôt. L étude menée par l université de Darmstadt stipule que 22,4 % des répondants considèrent la réduction des coûts comme argument principal dans le choix d une solution de cloud. L évolutivité (20,4 %) et la exibilité accrue (19,9 %) sont les deuxième et troisième raisons [46]. Peu importe que vous pensiez qu il soit bon ou mauvais, et malgré toutes les préoccupations liées à la sécurité, le cloud computing est la tendance informatique des années à venir. Vu cette tendance, il convient d accorder une grande importance aujourd hui et à l avenir pour gagner la con ance des entreprises et de s y tenir. 1.8 Conclusion L informatique dans les nuages est un paradigme qui o re un nouveau modèle de distribution et de consommation de ressources informatiques à grande échelle. Les technologies associées à cette discipline permettent aux propriétaires de grands centres de traitement de données de louer les ressources inutilisées dont ils disposent, et de ce fait d augmenter la rentabilité de leur investissement matériel. Les clients de l informatique dans le nuage béné cient également de ce modèle de distribution de ressources, car il leur permet d assouplir leur mode d investissement en ressources informatiques, par exemple en ajustant la capacité de traitement de leur infrastructure informatique au fur et à mesure que leurs besoins évoluent. L informatique dans le nuage est un concept jeune et en constante évolution. Une

28 1. Informatique dans le nuage 18 des évolutions les plus prometteuses d après la communauté scienti que est le déploiement d applications distribuées sur une fédération de nuages. En e et, ce mode de déploiement permet, entre autres, d atténuer le risque de verrouillage propriétaire, de stimuler la concurrence des di érents fournisseurs d infrastructure dans le nuage, et de contrôler une partie de la con dentialité des données utilisées par les applications déployées dans le nuage. Néanmoins, la gestion des ressources informatiques provenant de plusieurs nuages est un dé technologique et scienti que d actualité. En e et, la grande taille des fédérations de nuages et l hétérogénéité des ressources qui les composent sont des aspects di cilement pris en compte par les solutions de l informatique dans le nuage d aujourd hui.

29 CHAPITRE 2 La tolérance aux pannes Sommaire 2.1 Notion de sûreté de fonctionnement Attributs de la sûreté de fonctionnement Entraves à la sureté de fonctionnement Moyens d assurer la sûreté de fonctionnement Classi cation des pannes Détection des pannes Méthodes de tolérance aux pannes Techniques de tolérance aux pannes dans les systèmes répartis Tolérance aux pannes par duplication Tolérance aux pannes par sauvegarde (checkpointing) Analyse comparative des di érentes méthodes de point de reprise Tolérance aux pannes par journalisation Comparaison de di érentes protocoles de tolérance aux pannes par reprise La tolérance aux pannes dans les Cloud Migration Live migration, pourquoi? Conclusion

30 2. La tolérance aux pannes 20 La capacité d un système à fonctionner malgré une défaillance d une de ses composantes est appelée tolérance aux pannes (parfois nommée tolérance aux fautes, en anglais fault tolerance). Puisqu il est impossible d empêcher totalement les pannes, une solution consiste à mettre en place des mécanismes de redondance, en dupliquant les ressources critiques, ou des techniques de sauvegarde et de retour en arrière. Lorsqu une des ressources tombe en panne, les autres ressources prennent le relais a n de laisser le temps aux administrateurs du système de remédier à l avarie. Idéalement, dans le cas d une panne matérielle, les éléments matériels fautifs devront pouvoir être «extractibles à chaud» (en anglais «hot swappable» ), c est-à-dire pouvoir être extraits puis remplacés, sans interruption de service [64]. Néanmoins, la mise en place d une architecture redondante ne permet que de s assurer de la disponibilité des données d un système mais ne permet pas de protéger les données contre les erreurs de manipulation des utilisateurs ou contre des catastrophes naturelles telles qu un incendie, une inondation ou encore un tremblement de terre. Il est donc nécessaire de prévoir des mécanismes de sauvegarde (en anglais backup), idéalement sur des sites distants, a n de garantir la pérennité des données. Par ailleurs, un mécanisme de sauvegarde permet d assurer une fonction d archivage, c est-à-dire de conserver les données dans un état correspondant à une date donnée [64]. 2.1 Notion de sûreté de fonctionnement La sûreté de fonctionnement d un système (éventuellement distribué) o re une vision plus générale à la problématique de sécurité abordée dans ce travail. Elle intègre également les problèmes de abilité et de maintenabilité. Plus spéci quement, une défaillance du système surviendra lorsque le service délivré di ère du service spéci é, soit par valeur, soit parce qu il n a pas été dispensé dans l intervalle de temps demandé. Elle est causée par une faute qui, elle-même, génère une erreur. La sureté de fonctionnement peut-être présentée autour de trois notions : ses attributs, ses entraves et ses moyens [5] Attributs de la sûreté de fonctionnement Les attributs de la sûreté de fonctionnement d un système mettent plus ou moins l accent sur les propriétés que doivent véri er la sûreté de fonctionnement du système.

31 2. La tolérance aux pannes 21 Ces attributs permettent d évaluer la qualité du service fourni par un système. Dans [45], six attributs de la sûreté de fonctionnement sont dé nis : Disponibilité : c est la propriété requise par la plupart des systèmes sûrs de fonctionnement. Il s agit de la fraction de temps durant laquelle le système est disponible pour des ns utiles (en excluant les temps de défaillance et de réparation). C est la probabilité que le système soit opérationnel à l instant t ; Fiabilité : cet attribut évalue la continuité du service, c est à dire. le taux en temps de fonctionnement pendant lequel le système ne subit aucune faute. C est la probabilité conditionnelle qu un système fonctionne sans défaillance pendant l intervalle de temps [0, t] sachant qu il était opérationnel à l instant 0 ; Sécurité-innocuité : Evalue la continuité du service avant l arrivée d une défaillance catastrophique. Elle utilise donc la même expression mathématique que la abilité appliquée uniquement aux défaillances catastrophiques ; Con dentialité : cet attribut évalue la capacité du système à fonctionner en dépit de fautes intentionnelles et d intrusions illégales ; Intégrité : l intégrité d un système dé nit son aptitude à assurer des altérations approuvées des données ; Maintenabilité : cette propriété décrit la souplesse du système vis-à-vis des modi cations apportées en vue de sa maintenance. C est le temps d interruption de fonctionnement due à des opérations de maintenance préventive (avant qu une défaillance ne survienne), corrective (à la suite d une défaillance), et perfective (pour faire évoluer le système). L importance des attributs de la sûreté de fonctionnement présentés ci-dessus est principalement liée aux applications et à leurs besoins. Par exemple, pour les applications critiques comme le pilotage de fusées, une grande importance doit être donnée à tous les attributs de la sûreté de fonctionnement. Les applications parallèles à longue durée d exécution font prévaloir la maintenabilité et la abilité Entraves à la sureté de fonctionnement Les entraves à la sureté de fonctionnement sont de trois types [5] : les fautes, les erreurs et les défaillances. Fautes, erreurs et défaillances sont liées par des relations de causalité illustrées sur la Figure 2.1. Fig. 2.1 La chaîne fondamentale des entraves à la sureté de fonctionnement [5]

32 2. La tolérance aux pannes 22 Fautes : Une faute ou panne est caractérisée par sa nature, son origine et son étendue temporelle [45]. La nature d une faute donne le caractère intentionnel ou accidentel d une faute, les fautes intentionnelles sont créées délibérément dans le dessein de nuire tandis que les fautes accidentelles apparaissent de manière fortuite. La durée d une faute exprime la dépendance vis-à-vis de conditions ponctuelles, Une faute temporaire est présentée pendant une durée limitée et disparaît si telle ou telle condition interne ou externe ne peut l éliminer. L origine d une faute est la source d une faute. Une faute est due à des phénomènes soit physiques soit humains. Elle est provoquée soit par une partie de l état du système soit par l environnement. Elle appartient soit à la phase de conception soit à la phase d exploitation du système. L étendue d une faute précise la portion du système a ectée. Une faute locale a ecte une partie du système alors qu une faute globale en a ecte plusieurs. Erreurs : Une erreur est une partie fausse de l état du système. Tant que le service n utilise pas la partie fausse, l erreur est dite latente. Activée ; l erreur est dite e ective est une défaillance apparaît si le service rendu n est plus correcte. une erreur est la conséquence d une faute. Une défaillance survient dès que le système utilise un état erroné [23]. Powell propose une classi cation des erreurs selon leurs types (valeur ou temps) [59]. Premièrement, le service ne correspond pas en valeur à celui spéci é. Si la valeur rendue n est pas interprétable alors l erreur est dite non-codée, sinon elle est dite arbitraire. Deuxièmement, le service n est pas délivré dans l intervalle de temps spéci é. L auteur distingue six catégories. Le service rendu est toujours en avance ou toujours en retard ou encore arbitrairement en avance ou en retard. Le fait que le système omette de rendre le service est considéré également comme un type d erreur. Un arrêt (crash) est dé ni par le fait que le système omet dé nitivement de délivrer des services. Défaillances : une défaillance dénote l incapacité d un élément du système à assurer le service spéci é par l utilisateur. La défaillance est caractérisée par son domaine, sa perception par les utilisateurs et ses conséquences sur l environnement [45]. Le domaine de défaillance est le domaine des erreurs actives. Une défaillance est cohérente si tous les utilisateurs en ont la même perception. Sinon, c est une défaillance incohérente ou byzantine. Les conséquences sur l environnement sont appréciées de mineures ou bénignes à majeures ou catastrophiques suivant les dommages subis.

33 2. La tolérance aux pannes Moyens d assurer la sûreté de fonctionnement Il existe toute une panoplie de moyens pour assurer ou évaluer la sûreté de fonctionnement d un système. Ces moyens sont dé nis par les méthodes et les approches utilisées pour assurer cette propriété. Une classi cation usuelle de ces moyens conduit à quatre catégories [41] : La prévention des fautes : vise à empêcher l apparition ou l introduction des fautes dans le système. Elle repose sur des règles de développement (modularisation, utilisation de langage fortement typé, preuve formelle, etc.). Ce sont généralement les approches de véri cation des modèles conceptuels ; L élimination des fautes : qui se focalise sur les techniques permettant de réduire la présence de fautes ou leurs impacts. L élimination de faute se fait pendant les phases de validation ou lors des premières utilisations du système. Cela est réalisé par des méthodes statiques de preuve de la validité du système (simulation, preuves analytiques, tests,...) ; La prévision des fautes : anticipe ces dernières pour ensuite pouvoir appliquer des moyens de l élimination ou de la tolérance aux fautes. Il s agit d une estimation et évaluation de la présence des fautes (temps, nombre, impact) et de leurs conséquences. Ceci est réalisé généralement par des méthodes d injection de fautes a n de valider le système relativement à ces fautes ; La tolérance aux pannes ou aux fautes : qui essaye de fonctionner en dépit des fautes. Le degré de tolérance aux pannes se mesure par la capacité du système à continuer à délivrer son service en présence de fautes. La Figure 2.2 résume les notions associées à la sûreté de fonctionnement présentées ci-dessus Classi cation des pannes La capacité d identi cation du modèle de pannes joue un rôle très important si l on veut réaliser la tolérance aux pannes. En e et, les conséquences et le traitement d une panne di érent selon son modèle. Les pannes peuvent être classées selon leur degré de gravité, leur degré de permanence et leur nature. Une première classi cation des pannes selon le degré de gravité des défaillances est proposée dans [7] et permet de di érencier : Les pannes franches (crash faults) : soit le système fonctionne normalement (les résultats sont corrects), soit il ne fait rien. Il s agit du modèle de panne le plus simple auquel on essaie de se ramener aussi souvent que possible ; Les pannes par omission : le système perd des messages entrant ou sortant d un processus. On retrouve généralement ce modèle de pannes dans les réseaux ;

34 2. La tolérance aux pannes 24 Fig. 2.2 L arbre de la sûreté de fonctionnement [45] Les pannes de temporisation : les déviations par rapport aux spéci cations concernent uniquement le temps (typiquement le temps de réaction à un événement) ; Les pannes par valeurs : les résultats produits par un composant défaillant sont incorrects. Ce type de panne est typiquement détecté par les mécanismes de certi cation des résultats proposés ; Les pannes byzantines : le système peut faire n importe quoi, y compris avoir un comportement malveillant. Une seconde classi cation des pannes selon leur degré de permanence est également possible. On distingue ainsi les pannes transitoires qui se produisent de manière isolée, les pannes intermittentes qui se déclenchent aléatoirement plusieurs fois et les pannes permanentes qui persistent dès qu elles apparaissent jusqu à réparation.

35 2. La tolérance aux pannes 25 Il existe un troisième classement qui distingue la nature des pannes selon qu elles soient accidentelles ou intentionnelles Détection des pannes Le problème de la détection des pannes est résolu di éremment selon le modèle de communication du système. Considérons d abord le cas des modèles synchrones, dans lesquels le temps de transmission d un message est borné. Supposons qu un envoi de message provoque la mise en attente de l émetteur d une con rmation de réception de la part du récepteur. La détection des pannes franches et de temporisation peut alors être réalisée à l aide de délais de garde "watchdog" lors des communications : lorsqu un processus communique avec un autre et ne reçoit pas de con rmation après ce délai de garde, il peut considérer que le processus cible est défaillant. Le problème devient plus complexe dans le cas des modèles asynchrones : le temps de transmission d un message n est pas borné. Les communications entre les nœuds ne peuvent donc plus être utilisées pour détecter les pannes car il est impossible de prédire le moment où le message est e ectivement reçu par le récepteur. On a alors recours à un détecteur (ou suspecteur) de pannes [21], qui informe les processus sur l état du système. Ces détecteurs utilisent eux aussi des délais de garde. On distingue deux modèles di érents : Le modèle push, dans lequel chaque processus du système doit régulièrement informer les détecteurs de pannes de son état. Si ce détecteur n a pas reçu de message de type je suis vivant de la part d un processus depuis un temps donné, ce processus est suspecté d être défaillant. Le modèle pull, dans lequel ce sont les détecteurs de pannes qui envoient régulièrement des requêtes de type es-tu vivant? aux processus du système. Un processus qui ne répond pas dans un temps donné est suspecté d être défaillant. On note que l on parle de soupçons parce que le processus incriminé n est pas forcement en panne : le message peut être encore en transit dans le système à la n du délai. Chandra et al. ont dé ni dans [21] les notions de justesse, qui indique si un détecteur de pannes peut considérer comme défaillant un processus correct, et de complétude, qui indique s il est possible qu un processus en panne ne soit jamais détecté. 2.2 Méthodes de tolérance aux pannes La tolérance aux fautes est une des méthodes permettant le développement de systèmes sûrs de fonctionnement. Elle vise à éviter les défaillances et est mise en

36 2. La tolérance aux pannes 26 œuvre par la détection des erreurs et le rétablissement du système. La détection permet d identi er la présence d une erreur. Elle peut être e ectuée soit pendant l exécution normale du service, soit pendant une suspension du service (ce qui permet de révéler l éventuelle présence d erreurs latentes ou de fautes dormantes). Le rétablissement du système vise à transformer l état erroné en un état exempt d erreur et de faute. Le traitement de fautes fait appel à des techniques de diagnostic, de passivation, de recon guration ou de réinitialisation. Le traitement de l erreur peut se faire par trois techniques : la reprise, la poursuite et la compensation [5]. Reprise : est la technique la plus couramment utilisée. L état du système est sauvegardé régulièrement. Le système est ramené dans un état sauvegardé (point de reprise) survenu avant l occurrence d erreur. Poursuite : consiste à rechercher un nouvel état exempt d erreur. Ceci peut par exemple être réalisé en associant un traitement exceptionnel lorsqu une erreur est détectée. Le système est amené dans un nouvel état exempt d erreur. Compensation : nécessite que l état du système comporte su samment de redondance pour permettre sa transformation en un état exempt d erreur. Elle est transparente vis-à-vis de l application car elle ne nécessite pas de ré-exécuter une partie de l application (reprise), ni d exécuter une procédure dédiée (poursuite) [14]. Reprise et poursuite sont invoquées à la demande, après qu une ou plusieurs erreurs aient été détectées. Contrairement à la reprise, la poursuite ne garantie pas que le service soit fournie (exemple : saut d un pas de calcul sans résultat). La compensation peut, quant à elle, être appliquée à la demande ou systématiquement, indépendamment de la présence ou de l absence d erreur. Le traitement d erreur est, si besoin est, suivi du traitement de faute. Ils constituent le rétablissement du système, d où le quali catif de la stratégie de tolérance aux fautes correspondante : détection et rétablissement. Le masquage de fautes résulte de l application systématique de la compensation. Un tel masquage pouvant entraîner une diminution non perçue des redondances disponibles, sa mise en œuvre pratique comporte généralement une détection d erreur, conduisant au masquage et détection [65]. 2.3 Techniques de tolérance aux pannes dans les systèmes répartis La tolérance aux pannes dans les systèmes répartis et parallèles est le plus souvent réalisée par l emploi d un mécanisme de redondance. Cette redondance peut être spatiale (duplication de composants), temporelle (traitements multiples) ou bien informationnelle (redondance de données, codes, signatures). Les mécanismes de redondances

37 2. La tolérance aux pannes 27 mis en œuvre appartiennent à deux catégories : les techniques basées sur la duplication et les techniques basées sur une mémoire stable [43] Tolérance aux pannes par duplication La tolérance aux pannes par duplication consiste en la création de copies multiples des composants sur des processeurs di érents. Cette approche par duplication rend possible le traitement des pannes en les masquant. Trois stratégies principales pour réaliser la duplication sont proposées dans la littérature : les duplications actives, passives et semi-actives. Ces di érentes stratégies visent à garantir une cohérence forte entre les copies d un composant dupliqué [67]. i) Duplication active La duplication active est dé nie par la symétrie du comportement des copies d un composant dupliqué où chaque copie joue un rôle identique à celui des autres. Toutes les copies reçoivent la même séquence ordonnée de requêtes, qui sont toutes traitées dans le même ordre [14]. Elle est bien adaptée aux systèmes critiques et à toutes les hypothèses de défaillance, tels que silence sur défaillances, arrêt sur défaillances, défaillances temporelles et défaillances byzantines (voir Figure 2.3). Fig. 2.3 Exemple de protocole de duplication active Tolérance aux fautes : Dans le protocole de réplication active, quand une copie devient défaillante, aucun mécanisme supplémentaire n est à mettre en œuvre. La défaillance d une copie est masquée par le comportement des copies non défaillantes. Ainsi, la tolérance aux fautes est réalisée par le mécanisme de masquage d erreur [55]. L exécution des requêtes doit être déterministe, sinon des mécanismes de vote sont nécessaires, après la collecte des réponses de toutes les di érentes copies, pour décider de la réponse à restituer au client [9].

38 2. La tolérance aux pannes 28 ii) Duplication passive Contrairement à la duplication active, la duplication passive (passive replication ou primary-backups replication) [54] est asymétrique. Seule une copie reçoit une requête d un client et l exécute. Cette copie est désignée sous le nom de copie primaire (primary copy). Les autres copies sont appelées copies secondaires (secondary copies). La copie primaire est la seule à e ectuer tous les traitements, alors que les copies secondaires ne font aucune action (voir Figure 2.4). En cas de défaillance de la copie primaire, une copie secondaire devient (par un protocole d élection) la nouvelle copie primaire. Pour assurer la cohérence, la copie primaire di use régulièrement son nouvel état à toutes les copies secondaires [9]. Fig. 2.4 Exemple de protocole de réplication passive Tolérance aux fautes : La tolérance aux fautes est réalisée par détection et compensation d erreur [55]. Quand une copie secondaire passe dans un état de défaillance, aucun traitement particulier n est nécessaire. Le seul e et de cette défaillance est la diminution du degré de réplication (une réplique en moins). Par contre, quand une copie primaire devient défaillante, un protocole d élection sera déclenché pour désigner la nouvelle copie primaire parmi les copies secondaires. Si la copie primaire fait défaut lors d une invocation par un client, alors celui-ci n obtient aucune réponse à sa requête. Il doit réémettre sa requête en l adressant à la nouvelle copie primaire [9]. iii) Duplication semi-active Le protocole de duplication semi-active est une hybridation des duplication active et passive [26] [27]. Il s apparente à la duplication active dans le sens où chaque copie exécute la requête, sauf que toutes les sources d indéterminisme sont résolues par

39 2. La tolérance aux pannes 29 le choix d une copie maître qui renvoie le résultat au client (voir Figure 2.5). En l absence de fautes, les autres copies (les suiveuses) mettent à jour leurs états internes en exécutant les requêtes provenant du client [9]. Fig. 2.5 Exemple de protocole de duplication semi-active Tolérance aux pannes : Dans la duplication semi-active, quand une réplique suiveuse fait défaut aucun traitement particulier n est nécessaire [26][27]. Son seul e et est de diminuer le degré de réplication. Puisque toutes les copies reçoivent la requête, le client n a pas besoin de ré-émettre sa requête lorsque la copie maître devient défaillante. La nouvelle copie maître envoie automatiquement la réponse au client. Le tableau 2.1 donne une indication comparative des di érentes approches de tolérance aux fautes basées sur la redondance active, passive ou hybride des composants logiciels d un algorithme [9]. Une propriété intéressante de la redondance active se situe dans le fait qu une faute n augmente pas la latence du système temps réel, ce qui n est pas le cas dans la redondance passive, où la faute de la réplique primaire peut de manière signi cative augmenter la latence du système. Cependant, la redondance passive présente l avantage de réduire la surcharge sur les processeurs et sur le réseau de communication, ce qui permet une meilleure exploitation des ressources matérielles o ertes par l architecture [44] Tolérance aux pannes par sauvegarde (checkpointing) Le checkpointing est considéré comme étant une technique qui consiste à sauvegarder dans un support de stockage stable l état d un processus durant son exécution. En cas de panne, le processus est redémarré depuis son dernier checkpoint [50].

40 2. La tolérance aux pannes 30 Approche Critère de Redondance active Redondance passive Redondance comparaison semi-active Surcoût un surcoût élevé un surcoût moins élevé le surcoût dépend du niveau de la réplication active par rapport à la réplication passive Détection de pas besoin de détecter mécanisme spécial mécanisme spécial, défaillance les défaillances de détection de coûteux et souvent défaillances compliqué Traitement de défaillances (Temps de réponse) Reprise après défaillance un temps de réponse prévisible, et généralement rapide dans des architectures offrant un taux élevé de parallélisme meilleur temps de réponse en absence de défaillances. La défaillance de la réplique primaire peut de manière signi cative augmenter le temps de réponse le temps de réponse dépend du niveau de la réplication active par rapport à la réplication passive immédiate non immédiate non immédiate Tab. 2.1 Comparaison entre les trois approches de redondance Dans ce contexte, plusieurs actions de checkpoint sont envisagées. En e et, nous pouvons varier les instants et les méthodes de checkpoint. En premier lieu, il se peut que l action de recon guration ne recourt à aucun checkpoint. En second lieu, nous pouvons dé nir un mécanisme de checkpoint comme étant périodique, dans ce cas les di érents checkpoints sont réalisés d une façon périodique. Comme les positions de ces checkpoints sont gées et préalablement déterminées, nous exposons en troisième lieu un autre type de checkpoint que nous notons un checkpoint adaptatif. Ce mécanisme o re une meilleure exibilité en particulier au niveau du choix à propos de l instant de checkpoint. En dernier lieu, nous pouvons recourir à réaliser un checkpoint instantané, ceci dépend du besoin de migrer à un instant donné en supposant qu il est possible d ajouter un checkpoint à cet instant de mobilité. Il est à noter que les checkpoints peuvent avoir lieu aux barrières naturelles d un processus d orchestration (c est-à-dire au début ou à la n d un bloc «Flow», ou encore dans un bloc élémentaire au début d une structure séquentielle), sinon les checkpoints seront quali és de forcés [50]. Les protocoles de tolérance aux pannes par point de reprise se basent sur la création d états directement recouvrables. Ce type de protocole crée pendant l exécution ou recherche après une panne des états globaux cohérents qui sont utilisés pour redémarrer l exécution. Un état global est alors appelé ligne de recouvrement. Il existe di érentes

41 2. La tolérance aux pannes 31 approches pour assurer la cohérence de la ligne de recouvrement. Nous décrivons dans cette section les principales approches [28] : points de reprise indépendants, synchronisés et induits par messages. i) Sauvegarde Synchronisée (coordonnée) Les points de reprises sont réalisés de manière coordonnée sur tous les processus de l exécution, de façon à assurer que l état global résultant soit cohérent. Le principal inconvénient de cette technique est le surcoût introduit par la coordination de tous les processus participants. Aussi, a n d améliorer les performances de la sauvegarde coordonnée, plusieurs techniques ont été proposées : bloquante : les protocoles de points de reprise bloquants arrêtent leur exécution pendant la prise du point de reprise et ne la reprennent que lorsque tous les processus l ont fait. Ainsi il est impossible qu un message ne traverse la vague de points de reprise ; non bloquante : ce protocole évite de bloquer le processus durant la phase de sauvegarde en créant un processus clone chargé de la sauvegarde ; la cohérence est assurée par des messages balais, qui vident les canaux de communication a n d éviter les messages orphelins. avec horloge synchronisée : les horloges de chaque machine sont synchronisées, et les processus déclenchent les points de reprise en fonction de leur horloge locale. Ce protocole évite la phase de synchronisation par envois de messages, en utilisant une horloge synchronisée ; Dans les deux premiers cas, ce type de protocole nécessite l utilisation de messages additionnels. L approche synchronisée permet d éviter l e et domino puisque tous les états globaux crées sont forcément cohérents. Une approche synchronisée est souvent choisie en pratique à cause de sa simplicité d implémentation et d intégration à un système existant. ii) Sauvegarde indépendante Cette méthode consiste à faire prendre aux di érents processus du système des points de reprise de manière totalement indépendante. La cohérence des états globaux formés n est donc pas assurée et c est en cas de panne que le protocole recherche une ligne de recouvrement parmi tous les états globaux formés. Cette recherche s e ectue généralement par la création d un graphe de dépendance entres les points de reprise locaux. L inconvénient principal de cette approche est le risque d e et domino qui peut causer une perte importante du travail réalisé avant la panne et la sauvegarde inutile de

42 2. La tolérance aux pannes 32 points de reprise, ceux-ci ne faisant jamais partie d un état global cohérent. Ces points de reprise augmentent le coût de l exécution normale (i.e. en l absence de panne) et ne servent pas à la reprise après une panne [60]. De plus, la sauvegarde non coordonnée oblige chaque processus à maintenir plusieurs points de reprise. A n de déterminer un état global cohérent (ligne de recouvrement), chaque processus dispose d un journal en mémoire stable dans lequel il enregistre tout ou partie des messages échangés ainsi que leurs historiques [15]. Lorsqu une défaillance survient, l algorithme de reprise utilise les points de reprise locaux et les journaux a n de déterminer une ligne de recouvrement. iii) Sauvegarde induite par les communications (Induits par message) La sauvegarde induite par les communications (Communication-Induced Checkpointing ou CIC) [8] est un compromis entre la sauvegarde coordonnée et la sauvegarde non coordonnée. Ce protocole utilise deux types de points de sauvegarde : les sauvegardes locales et les sauvegardes forcées. Les sauvegardes locales sont des sauvegardes que le processus décide d e ectuer indépendamment. Les sauvegardes forcées sont des sauvegardes qui doivent être e ectuées pour empêcher l e et domino en cas de reprise [14]. On distingue deux familles de protocoles : Les protocoles model-based : les communications et les prises de points de reprise doivent respecter un certain motif. Par exemple, si tout envoi et toute réception de message est précédé d un point de reprise, alors tous les points appartiennent au moins à un état global cohérent, et le dernier point pris fait toujours partie de la ligne de recouvrement [42]. Ces protocoles sont généralement basés sur les notions de chemins et de cycles pour déterminer les états globaux cohérents. Les protocoles index-based : les points de reprise sont indexés, chaque message porte l index du dernier point de l émetteur. Sur réception d un message indiquant un index supérieur au sien, le récepteur doit prendre un point de reprise avant la prise en compte du message : l incohérence est évitée au dernier moment. Ce type de protocole utilise donc une méthode basée sur la suppression des dépendances causales entre les points de reprise des processus qui ont des communications directes Analyse comparative des di érentes méthodes de point de reprise Nous allons comparer ici les approches présentées dans la partie précédente. Nous ne considérerons que les approches synchronisées et induites par messages ; en e et,

43 2. La tolérance aux pannes 33 l approche indépendante n implique pas réellement l utilisation d un protocole : la recherche d un état global cohérent est faite après une panne, au moment de la reprise. Nous comparerons sur les points suivants : - le surcoût pendant l exécution, en termes de CPU et de réseau, - le nombre de retours arrière moyen, - le surcoût de stockage, et la facilité du ramassage sur la mémoire stable des points de reprise devenus inutiles. i) Surcoût pendant l exécution Les protocoles synchronisés bloquant ont en général un surcoût élevé durant l exécution à cause de la phase de synchronisation qui stoppe l exécution. De plus, le temps de blocage de l exécution étant proportionnel au nombre de processus, ce type de protocole passe di cilement à l échelle. Dans certains cas particuliers, l approche bloquante peut cependant être intéressante : Coti et al. ont montré dans [24] que l approche bloquante était plus e cace que l approche non bloquante dans le cas des petits systèmes avec des liens réseaux haute-performance. Par rapport à une approche synchronisée, l approche induite par messages ne rajoute pas de message additionnel durant l exécution : le surcoût principal est dû aux points de reprise additionnels qui ont été forcés par le protocole durant l exécution. Il y a aussi un surcoût du à la taille des messages qui peut être très di érent d un protocole à l autre, allant de sans surcoût pour les approches model-based à un vecteur d entiers de la taille du nombre de processus dans le système. ii) Nombre moyen de retours arrière Les protocoles synchronisés ont ici un avantage certain : tous les points de reprise sont utiles, et lorsqu un processus prend un point de reprise, il est assuré de ne pas devoir retourner plus loin que ce point en cas de panne. Dans le cas des protocoles induits par messages, on trouve deux types de solution. La première est d assurer que tous les points de reprise sont utiles, c est à dire qu ils font partie d un état global cohérent. Ces protocoles sont basés sur l approche modelbased, et ont été classi és par Manivannan dans [53], selon qu ils assurent l absence de chemin "zigzag" (Strictly Z-Path Free (SZPF), Z-Path Free (ZPF)), ou l absence de cycle "zigzag" (Z-Cycle Free, ZCF). La deuxième solution est de maximiser la probabilité que tous les points soient utiles, sans pour autant l assurer. C est le cas des protocoles index-based. Cependant, avec ces deux solutions, le dernier point de reprise d un processus ne fait pas toujours partie de la dernière ligne de recouvrement. Il est donc possible que

44 2. La tolérance aux pannes 34 le processus doive reprendre depuis un point de reprise plus ancien. A la di érence d une approche synchronisée, le travail potentiellement perdu par un processus en cas de panne n est donc pas borné. iii) Surcoût de stockage et ramassage Sur ce point aussi, les protocoles synchronisés sont avantageux : puisque tout état global nouvellement créé est forcément un état cohérent, alors l état global précédent peut être e acé de la mémoire. Le surcoût est donc minimal puisqu il n est nécessaire de conserver qu un seul état global (plus bien sûr celui en construction), et le ramassage des états devenus inutiles devient trivial. Le ramassage des points de reprise dans le cas des protocoles induits par messages est dépendant de la politique choisie, et nécessite le plus souvent un mécanisme complexe pour déterminer les points devenus inutiles Tolérance aux pannes par journalisation Le principe de la tolérance aux pannes par journalisation est de sauvegarder l histoire de l application. Les protocoles par journalisation utilisent à la fois la sauvegarde locale de l état des processus et la journalisation des évènements déterministes pour permettre la reprise de l application. Il est alors possible de reprendre l exécution des processus défaillants (et uniquement des processus défaillants) à partir de leur dernière sauvegarde en rejouant les évènements non déterministes sauvegardés. Pour cela, les protocoles basés sur la journalisation reposent sur l hypothèse PWD (PieceWise Deterministic assumption) [14]. Chaque processus crée un journal des événements non déterministes qu il observe pendant l exécution normale (sans panne). En cas de panne, le processus défaillant est capable de reconstruire son état d avant la panne en partant de son état initial et en rejouant les événements non déterministes inscrits dans son journal. L hypothèse PWD garantit que cette reconstruction aboutira au même état. De plus, pour éviter la reconstruction à partir de l état initial, le processus peut e ectuer des sauvegardes périodiques de son état. Il faut également remarquer que ces informations (le journal et les sauvegardes périodiques) doivent être stockées sur une mémoire stable. Les protocoles de journalisation doivent assurer la condition de «non orphelinité» [14]. i) Journalisation pessimiste Le protocole de reprise par journalisation pessimiste [62] repose sur l hypothèse (pessimiste) qu une défaillance peut se produire immédiatement après un évènement non déterministe. Le principe de ce protocole est donc de ne pas permettre à un

45 2. La tolérance aux pannes 35 processus de dépendre d un évènement non déterministe tant que celui-ci n a pas été stocké sur un support stable. Concrètement, si on considère que les évènements non déterministes sont uniquement les réceptions de messages, ce protocole impose aux processus de sauvegarder tous les messages reçus avant d émettre un message à un autre processus [1]. Les sauvegardes e ectuées doivent donc être réalisées de manière synchrone. On trouve cette technique dans MPI-FT et CHARM [16]. L avantage de ce protocole est qu il ne crée jamais de processus orphelin. Cependant, la sauvegarde synchrone induit un surcoût conséquent lors d une exécution sans panne, en particulier pour les applications e ectuant beaucoup de communications. ii) Journalisation optimiste La journalisation optimiste [62] veut améliorer les performances en faisant l hypothèse (optimiste) qu une panne ne se produira pas avant la sauvegarde de l évènement non déterministe. Ainsi, la contrainte est relâchée et les sauvegardes peuvent être réalisées de manière asynchrone. Cependant, le désavantage de cette méthode est qu elle ne garantit pas strictement la «condition de non-orphelinité». Ainsi les processus qui n ont pas encore sauvegardé leurs évènements non déterministes sont des processus orphelins. Pour obtenir un état global cohérent, ces processus devront revenir en arrière au dernier état où ils n étaient pas orphelins. Il faut remarquer que ce calcul pour obtenir l état global cohérent à la reprise peut avoir un cout important [14]. iii) Journalisation causale La journalisation causale [33][34] combine les avantages de la journalisation pessimiste pour la reprise et les avantages de la journalisation optimiste en ce qui concerne le surcoût à l exécution. L inconvénient est sa complexité. Le principe est de conserver en mémoire locale les informations permettant de rejouer un évènement non déterministe mais également les informations de précédence (au sens de la relation de précédence causale de Lamport) avec les autres évènements non déterministes [1]. Ces informations (appelées également le déterminant) sont aussi ajoutées à tous les messages émis vers les autres processus. Ces informations sont retirées de la mémoire locale des processus une fois qu elles ont été enregistrées sur un support stable. Ainsi, à tout moment, un processus connait l historique des évènements qui ont produit son état et celui des autres processus. Ces informations le protègent des défaillances des autres processus et permettent de garantir la condition de «non or-

46 2. La tolérance aux pannes 36 phelinité» [33]. Parmi les implémentations de journalisation causale nous citions le système MANETHO [13] Comparaison de di érentes protocoles de tolérance aux pannes par reprise Le tableau 2.2 propose une comparaison des avantages et des inconvénients de di érentes techniques de tolérance aux pannes par reprise. Protocole Hypothèse PWD Processus orphelin E et Domino Nombre de sauvgardes Journalisation péssimiste Oui Non Non Une Journalisation optimiste Oui Possible Non Possible Journalisation causale Oui Non Non Une Sauvegarde coordonnée Non Non Non Une Sauvegarde indépendante Non Possible Possible Toutes Sauvegarde induite par les communications Non Possible Non Plusieurs Tab. 2.2 Comparaison des di érentes méthodes de tolérance aux pannes par reprise 2.4 La tolérance aux pannes dans les Cloud Le Cloud Computing et la virtualisation ont ouvert une nouvelle fenêtre dans la gestion des pannes. La mise en pause, la reprise, et la migration des machines virtuelles (VMs) sont des mécanismes puissants pour gérer les défaillances dans un tel environnement. Une machine virtuelle peut être facilement migrée vers un autre nœud lorsqu une panne est inspectée ou détectée. Bien que la migration soit une bonne solution a n de traiter les pannes, elle a deux problèmes principaux. Premièrement, elle a des surcoûts considérables, particulièrement si les images de VMs entières doivent être émigrées. Deuxièmement, la prévision et la détection à l avance des pannes est un problème majeur. Nous ne pouvons pas commencer la migration d une VM si le nœud dont lequel elle s exécute est défaillant. Jing Deng et al. [29] proposent des techniques pour améliorer la tolérance aux pannes et la abilité d un calcul scienti que assez général : multiplication matricielle. La multiplication de matrices sert comme une base pour la résolution et l optimisation de nombreux problèmes complexes. Ils étudient une stratégie de sélection de Cloud pour décomposer le problème de multiplication de matrice en plusieurs tâches qui seront soumises à di érents Cloud et ils montrent que la tolérance aux pannes et la abilité par rapport à la défaillance dans le cloud computing peuvent être réalisés.

47 2. La tolérance aux pannes 37 Dans les Cloud de stockage, Bonvin et al. [17] proposent une Clé-Valeur autogérée (self-managed key-value) qui alloue dynamiquement les ressources d un Cloud de données pour plusieurs applications dans une manière e cace et équitable. L approche proposée o re et maintient dynamiquement des garanties di érenciées multiples de disponibilité pour chaque application di érente en présence des pannes. Les auteurs utilisent une économie virtuelle, où chaque partition de données (c est à dire une gamme clé dans un espace cohérent de hachage) agit comme un optimiseur individuel et choisit s il faut migrer, répliquer ou de se supprimer, basée sur la maximisation des béné ces nets concernant l utilité o erte par la partition et son stockage et les coûts de maintenance. Zibin Zheng et al. [70] proposent FTCloud qui est un framwork à base de classement de composants pour construire des applications de Cloud tolérantes aux pannes. FT- Cloud utilise les structures d invocation de composants et les fréquences d invocation pour identi er les éléments importants dans une application de Cloud. Un algorithme est proposé a n de déterminer automatiquement la stratégie optimale de tolérance aux pannes pour ces composants signi catifs. 2.5 Migration La migration de processus est le déplacement d un processus en cours d exécution d une machine source vers une machine destination, ces deux machines étant reliées par un réseau de communication et n utilisant pas de mémoire partagée. La migration de processus d une machine source vers une machine destination consiste à interrompre le processus qui s exécute sur la machine source pour extraire son contexte d exécution, à transférer ce contexte vers la machine destination, à créer, sur la machine destination, un nouveau processus auquel on a ectera le contexte d exécution transféré et à mettre à jour les liens de communication avec les autres processus. Une fois ceci fait, le processus sur la machine source doit être détruit tandis que le processus sur la machine destination est lancé et représente le processus déplacé. La Figure 2.6 illustre brièvement le mécanisme de migration de processus. Il existe di érentes stratégies de migration de processus. Cette di érence est due principalement au contexte d exécution considéré et transféré lors de la migration. En e et, le contenu du contexte d exécution transféré di ère d un mécanisme à l autre ou, plus exactement, d un degré de migration à un autre. Les techniques de virtualisation permettent notamment la migration de machines virtuelles d un noeud physique à un autre. La première approche repose sur une bascule de la ressource de cluster Machine virtuelle d un nœud à un autre en passant par la fonctionnalité de sauvegarde d état :

48 2. La tolérance aux pannes 38 Fig. 2.6 Migration de processus Quick Migration. Ce mode de fonctionnement implique de réaliser un dump de la mémoire de la machine virtuelle dans un chier pour pouvoir arrêter la machine virtuelle (Saved state), basculer la ressource disque sur un autre nœud du cluster et redémarrer la machine virtuelle à l aide du dump. Tout cela implique une interruption de l activité de la machine virtuelle. Le temps d interruption dépend principalement du temps nécessaire à réaliser le dump de la mémoire sur disque. L inconvénient introduit par l opération de Quick Migration était cependant important puisqu il introduisait une perte du service égale à la somme des périodes de temps nécessaires à l opération de mise en sommeil, puis au temps de basculement et en n au temps de réveil de la machine virtuelle sur le noeud de destination. Le temps de bascule avec Quick Migration pouvait être compris entre quelques secondes et plusieurs minutes. Ce temps varie en fonction de la quantité de mémoire RAM de la machine virtuelle, du débit disponible et aussi de la charge des machines hôtes [36]. La migration à chaud permet de déplacer une machine virtuelle d un noeud physique à un autre sans interruption de service, ce qui rend le processus totalement transparent. La migration à chaud permet à un administrateur de débrancher une machine virtuelle d une infrastructure physique donnée qui nécessite une maintenance sans soumettre les utilisateurs du système à un temps d arrêt. Un autre avantage de la migration est qu elle permet d améliorer la tolérance aux fautes. Si une défaillance imminente est suspectée, le problème peut être résolu avant l interruption du service. La migration à chaud peut également être utilisée pour l équilibrage de charge, a n

49 2. La tolérance aux pannes 39 d optimiser l utilisation des ressources CPU et de mieux gérer et économiser l énergie. [48] : Les six étapes ci-dessous détaillent le processus de migration dans son ensemble Etape 1 : Initialization d une "live Migration" Un ordre de migration est initié. Le host source crée une liaison TCP avec le host de destination. Cette connexion est utilisée pour transférer les données de con guration de la VM à migrer (pro le Hardware : processeurs, RAM, etc.). Le pro le Hardware permet de construire un squelette de VM sur l hôte de destination et d allouer la mémoire en su sance à la VM de destination. Etape 2 : Tranfert des pages mémoires Les pages mémoires de la machine virtuelle source sont copiées par le réseau sur le host de destination par page généralement de 4ko directement dans la mémoire allouée à la machine virtuelle. Toutes modi cations ultérieure de la mémoire est consignée. Les pages mémoires modi ées pendant le processus de copie sont copiées à leur tour par ittérations successives. Après que la totalité de la mémoire utilisée est copiée sur l hôte de destination, l étape suivant commence. Etape 3 : Copie du reliquats des pages mémoires La machine virtuelle source est mise en "pause" (il faut bien arrêter les comptes à un moment donné) a n de permettre une ultime copie du reliquats des pages mémoires modi ées. le Host source procède au transfert des registres processeurs ainsi que l état des périphériques à la machine de destination. Une fois cette copie terminée, la machine cible est la parfaite copie de la machine source. La durée de cette étape dépend de la bande passante disponible et de la quantité de mémoire restant à copier (dépend de l activité sur la machine virtuelle). Etape 4 : Redirection du Stockage Pendant cette 4ième étape, le contrôle de l espace de stockage associé à la VM est transféré à l hôte de destination. L emplacement qui contient la machine virtuelle est rendu accessible au host Cible. Etape 5 : Relance de la machine virtuelle A ce stade, en plus d avoir un contenu mémoire identique à celui de l hôte source, l hôte destination possède à présent les accès nécessaires aux espaces de stockage utili-

50 2. La tolérance aux pannes 40 sés par la machine virtuelle (VM). A ce moment, la VM démarre sur l hôte destination. Contrairement à la Quick Migration, une restauration de l état du système n est pas nécessaire, puisque la copie s est e ectuée de mémoire à mémoire. Etape 6 : Nettoyage du Réseau A ce moment, la VM migrée est déjà exécutée sur l hôte destination. Un message est envoyé au Switch physique pour mettre à jour la table ARP (les paquets à destination de la machine virtuelle ne passent plus par le même port physique). Bien que les di érents Hosts d un cluster disposent d un Pool d adresse MAC di érent, la machine virtuelle conserve son adresse MAC tant que le système d exploitation n est pas redémarré [48] Live migration, pourquoi? Bien que la live migration augmente la exibilité pour beaucoup d application, elle peut s avérer intéressante lors de cas pratiques de la «vraie vie». Maintenance des hôtes physiques La live migration apporte deux béné ces principaux à la maintenance d hôte physique. La capacité de migrer une machine virtuelle d un hôte physique à un autre sans aucun arrêt, permettant de copier l ensemble des machines virtuelles vers un autre serveur, et de les re-copier lorsque la maintenance est terminée sur leur serveur initial, sans que les services e ectués par les machines virtuelles ne soient interrompus. Data Center Dynamiques Avec la live migration, il est possible de mettre en place des environnements IT dynamiques. Ces environnements dynamiques rendent plus facile la gestion des ressources du serveur hôte. Prenons par exemple le cas de l utilisation d un site Web comprenant de nombreux accès simultanés. Lorsque ces accès augmentent, sa charge continue d augmenter. Au fur et à mesure que la charge varie, les machines virtuelles peuvent être transférées entre les di érents hôtes a n de garder le meilleur ratio d utilisation possible. Les hôtes non utilisés sont «parqués» ( rendus inactifs), réduisant par la même occasion la consommation électrique et le refroidissement nécessaire [38].

51 2. La tolérance aux pannes Conclusion Dans ce chapitre nous avons présenté un aperçu de la tolérance aux pannes pour les systèmes distribués et les Cloud Computing. En premier lieu, nous avons abordé d un point de vue très général la sureté de fonctionnement et le vocabulaire associé au domaine de la tolérance aux fautes. Il apparait que la tolérance aux fautes n est qu une des approches qui permettent d assurer la sureté de fonctionnement. Les techniques de tolérance aux pannes spéci ques aux systèmes distribués sont basées sur la réplication ou sur l utilisation d une mémoire stable. Les protocoles basés sur la duplication nécessitent un nombre important de ressources. De plus, les protocoles basés sur la duplication ne tolèrent qu un nombre limité de pannes. Les méthodes de tolérance basées sur une mémoire stable semblent plus adaptées. Parmi les méthodes basées sur une mémoire stable, nous distinguons les approches utilisant la journalisation des événements non déterministes et les approches réalisant une sauvegarde de l état des processus. Notre but dans ce travail est de garantir la tolérance aux pannes dans les Cloud Computing. Pour cela nous proposons dans le prochain chapitre une architecture de tolérance aux pannes qui permet de garantir la continuité des services du Cloud Computing d une façon transparent et e cace en cas de pannes.

52 CHAPITRE 3 Nos contributions Sommaire 3.1 Objectifs du travail Description de la 1 ère approche proposée Les éléments fonctionnels Les di érentes phases Phase de sauvegarde Phase de surveillance La phase d analyse La phase de traitement d erreur La description de la 2 eme approche Quand utiliser le mécanisme de migration? Scénarios de la migration Paramètres fonctionnels utilisés dans les deux approches Conclusion Ce chapitre présente nos contributions à la tolérance au pannes. Nous allons présenter deux approches : l approche par point de reprise et l approche à base de la migration. La modélisation est une étape préliminaire pour la description du fonctionnement de toute approche proposée, elle tient compte les principales caractéristiques et les relations entre les di érents composants. C est également un moyen de maîtriser la complexité des applications et d assurer leur convergence. Nous avons modélisé nos propositions de sorte à leur assurer un bon niveau de qualité et une maintenance e cace une fois implémentée, tout en veillant à satisfaire les besoins inhérents aux 42

53 3. Nos contributions 43 exigences de ce travail. Nous présentons dans ce chapitre les étapes de conception de nos approches de tolérance aux pannes et la modélisation de leurs services. 3.1 Objectifs du travail Le Cloud Computing fait référence à l utilisation des capacités de calcul des ordinateurs distants, où l utilisateur dispose d une puissance informatique considérable sans avoir à posséder des unités puissantes. L approche du cloud computing s appuie principalement sur le concept de virtualisation. Où ce concept est un ensemble de techniques permettant de faire fonctionner sur une seule machine plusieurs systèmes d exploitation et/ou plusieurs applications, isolés les uns des autres. Un cloud est constitué d un ensemble de machines virtuelles qui utilisent la même infrastructure physique. La probabilité d avoir une panne intervenir durant l exécution devient un phénomène naturel lorsque le nombre de nœuds augmente. Supposons, par exemple, une application distribuée s exécutant sur plusieurs noeuds et qui nécessite un temps d exécution de 3 jours. Si un nœud participant à l exécution de cette application se bloque à cinq minutes avant la n de l exécution, En absence des mécanismes de sauvegarde/reprise (checkpoint/restart) presque 3 jours d exécution seront gaspillés. Puisqu il est impossible d empêcher totalement les pannes, une solution consiste à mettre en place des mécanismes de tolérance aux pannes. Nous nous intéressons plus particulièrement aux traitements associés aux pannes franches (crash fault) des hôtes ou Datacenter. L objectif de notre travail est de proposer un mécanisme de tolérance aux pannes pour les Cloud Computing. Nous avons proposé deux approches, la première est basée sur le mécanisme de sauvegarde et reprise (checkpoint) en tant que moyen pour la sûreté permettant Le traitement de la panne en minimisant l impact des pannes et le surcoût des points de sauvegarde. La deuxième approche est une combinaison du mécanisme de checkpoint et de la migration. L avantage de la migration est qu elle permet d améliorer la tolérance aux fautes. Si une défaillance imminente est suspectée, le problème peut être résolu avant l interruption du service. La migration à chaud peut également être utilisée pour l équilibrage de charge, a n d optimiser l utilisation des ressources CPU et de mieux gérer et économiser l énergie [30]. 3.2 Description de la 1 ère approche proposée Cette section décrit l architecture proposée et la mise en œuvre pour supporter la tolérance aux pannes dans le Cloud Computing [11].

54 3. Nos contributions 44 La démarche principale de notre proposition de tolérance aux pannes est focalisée sur quatre phases (Figure 3.1) : la sauvegarde, la détection des erreurs, l analyse et le traitement des erreurs. La détection des erreurs est la phase où la présence d une faute est déduite à partir d une panne survenue sur une composante du système. Une fois la panne détectée, cela implique une défaillance de la composante et par conséquent l arrêt de la machine virtuelle. Tout dommage dû au dysfonctionnement (défaillance) est identi é dans la phase d analyse. Après ces phases, la panne doit être corrigée et ceci se fait dans la phase de traitement des erreurs. Fig. 3.1 Les principales phases de notre proposition. Le tableau suivant (table 3.1) décrit les di érentes phases et leurs activités : phase Sauvegarde Surveillance Snalyse Traitement d erreur Activités -Sauvegarder l état de la machine virtuelle (checkpoint) -Utilisation du mécanisme de heartbeat/ watchdog -Identi er les nœuds défaillants -Identi er l état de Datacenter -Redémarrer les machines virtuelles depuis leur dernier point de reprise Tab. 3.1 Les di érentes phases et leurs activités La structure de notre architecture (voir Figure 3.2) utilise un groupe d agents qui travaillent en coopération a n de contrôler d une manière distribuée les défaillances et

55 3. Nos contributions 45 de déclencher le processus de tolérance aux pannes. Fig. 3.2 Architecture globale de l approche de tolérance aux pannes proposée Les éléments fonctionnels i) L agent de checkpoint (checkpoint agent) Pour exécuter les tâches, le fournisseur utilise les machines virtuelles (VM) qui sont créées à la demande. La création d une VM implique le traitement d une grande quantité de données, y compris l installation du système d exploitation invité (Guest Operating System) et le déploiement du logiciel requis. L agent de checkpoint est chargé de sauvegarder périodiquement une copie d état des machines virtuelles. Faire un checkpoint de la tâche qui s exécute dans une machine virtuelle doit inclure toutes les informations nécessaires pour reprendre l exécution de la tâche dans un autre nœud. Ce qui nécessite la sauvegarde de l état courant des tâches (essentiellement sa mémoire et le contenu du disque).

56 3. Nos contributions 46 ii) L agent surveillant (monitor agent) L agent surveillant est chargé de : Détecter les pannes : La détection des pannes se fait par un mécanisme de heartbeat : les nœuds émettent périodiquement des heartbeat ou des messages «I am alive». Si une séquence de messages de heartbeat est manquée à partir d un nœud, ce dernier est déclaré comme un nœud non défaillant. Contrôler la charge du Datacenter : l agent surveillant collecte les informations concernant les ressources existantes (le nombre des ressources libres, l occurrence d une nouvelle panne et le nombre des pannes). Assure que le processus de sauvegarde s est correctement terminé pour toutes les machines virtuelles. iii) L agent de traitement d erreur Cet agent consiste à analyser les informations produites par l agent surveillant dans le but d identi er l état du système. Il modi e l intervalle du checkpoint et le cycle du watchdog [21]. Il est responsable au lancement de la procédure de reprise qui correspond à redémarrer les tâches depuis leur dernier point de reprise (checkpoint). L agent de traitement d erreur sélectionne le Datacenter le moins chargé pour assurer un équilibrage de charge et sélectionne le dernier point de reprise. 3.3 Les di érentes phases Phase de sauvegarde Dans cette phase l agent de checkpoint sauvegarde l état de la machine virtuelle sur un support stable pour ne pas redémarrer l application depuis le début lorsqu une panne arrive. Plusieurs actions de checkpoint sont envisagées. En e et, nous pouvons varier les instants et les méthodes de checkpoint. En premier lieu, il se peut que l action de recon guration ne recours à aucun checkpoint. En second lieu, nous pouvons dé nir un mécanisme de checkpoint comme étant périodique, dans ce cas les di érents checkpoints sont réalisés d une façon périodique. Comme les positions de ces checkpoints sont gées et préalablement déterminées, nous décrivons en troisième lieu un autre type de checkpoint que nous notons un checkpoint adaptatif. Ce mécanisme o re une meilleure exibilité en particulier au niveau du choix à propos de l instant de checkpoint. Pour établir le modèle global et en tenant compte des étapes de sauvegarde et de reprise, nous commençons par modéliser l exécution sans ces étapes. Ce modèle d exécution est schématisé sur la Figure 3.3. La première phase représente le démarrage

57 3. Nos contributions 47 de l application dans laquelle le temps s écoule mais la quantité de travail initial noté par! 0 ne diminue pas. Ensuite, après R unités de temps le calcul démarre et la quantité de travail diminue en fonction de la pente. Finalement, s il y a une panne durant une de ces phases, l application est redémarrée à partir du début avec un coût de reprise noté R. De cette manière tout le travail calculé avant la panne est perdu(figure 3.4). Fig. 3.3 Modèle d exécution sans pannes Fig. 3.4 Modèle d exécution sans mécanisme de sauvegarde

58 3. Nos contributions 48 Quand utiliser le mécanisme sans checkpoint? D une façon naturelle, nous pouvons con rmer que si la somme du temps de checkpoint T c et celui de rétablissement T Ret de l état sauvegardé notée (T c + T Ret) est supérieure ou égale au temps d exécution T E d une application, alors il n est pas nécessaire de faire un checkpoint. Mécanisme de checkpoint périodique Pour fournir une tolérance aux pannes, les checkpoints sont pris aux intervalles réguliers (périodiquement) lors de l exécution de la tâche. Si l intervalle de checkpoint expire, l agent de checkpoint suspend les machines virtuelles pour copier les chiers nécessaires pour la sauvegarde. Si la machine virtuelle échoue en raison d une panne, le travail peut être redémarrer à partir de son dernier checkpoint et donc il ne permet pas de gaspiller beaucoup d e orts pour arriver à son état actuel (voir Figure 3.5). Les avantages de checkpoint sont limités par les facteurs suivants : le surcoût d exécution, qui est le délai résultant de l interruption de l exécution du travail pour e ectuer le checkpointig, la latence du réseau (un intervalle de temps entre la création de checkpoint et de sa disponibilité sur le serveur de checkpoint), et le temps de rétablissement, qui est le temps pour télécharger le checkpoint d une VM échouée du serveur de checkpoint vers un nouveau nœud. Mécanisme de checkpoint adaptatif Pour réduire le surcoût d exécution de checkpoint nous proposons un algorithme qui permet de calculer l intervalle de checkpoint optimal en se basant sur les historiques, l état actuel d un nœud et son environnement d exécution (l état du Datacenter). Par ce moyen, nous allons, d une part, réduire les points de reprise inutiles et, d autre part, d introduire des checkpoints supplémentaires, quand le danger de défaillance est considéré comme critique. La phase de sauvegarde est le responsable majeur de la consommation des ressources par le mécanisme de tolérance aux pannes, ainsi que pour l élargissement dans le temps d exécution en l absence de défaillances. En outre, la procédure de checkpoint introduit un delai dans le calcul, car un processus peut suspendre son fonctionnement tandis que le checkpoint se produit. L agent surveillant assure que le processus de sauvegarde s est correctement terminé pour toutes les machines virtuelles. Le lancement du processus de checkpoint augmente le temps d exécution des applications : cette augmentation est dé nie comme le surcoût de checkpoint. L intervalle de

59 3. Nos contributions 49 Fig. 3.5 Algorithme de Checkpoint checkpoint également dé nie le nombre de checkpoint pris pendant les exécutions. L interaction entre l application et les checkpoints détermine l élargissement de la durée d exécution d application. Un intervalle de checkpoint optimale minimise les surcoûts générés par les checkpoints Phase de surveillance Cette phase correspond à la supervision de l application, l agent responsable de la surveillance permet de collecter les informations concernant les ressources existantes (nœuds défaillants, surcharge des Datacenters), a n de les fournir aux agents des étapes qui suivent. La détection des pannes par l approche proposée est réalisée par l envoi des messages de vie (heartbeat) et watchdog. L agent surveillant attends les messages de vie

60 3. Nos contributions 50 de chaque nœud j. Si le message de vie d un nœud i n arrive pas après un certain temps, le nœud i sera déclaré en panne et ajouter à la liste des nœuds en pannes. Un nœud envoie régulièrement des messages de vie à l agent surveillant. Le cycle de heartbeat/ watchdog détermine la rapidité d un agent surveillant pour détecter une défaillance d un nœud, c est à dire, le temps de réponse du système de détection de panne. Pour des cycles trop courts le temps de réponse est réduit, mais par contre l interférence sur le canal de communication augmente. La détection des pannes se fait en deux parties (voir Figure 3.6). La première partie consiste à envoyer des messages de vie et la deuxième partie consiste à attendre les messages de vie des nœuds. Fig. 3.6 Mécanismes de heartbeat et watchdog Le mécanisme heartbeat/watchdog de notre architecture transmet des informations à travers le canal de communication et génère un tra c de communication qui a ecte la bande passante du réseau. La solution pour réduire le tra c généré par le mécanisme

61 3. Nos contributions 51 de heartbeat/watchdog est d élargir le cycle de heartbeat en réduisant ainsi la quantité d information transmise par le mécanisme de heartbeat/watchdog. Toutefois, un agrandissement dans le cycle de message de vie (hearbeat cycle) réduit la sensibilité du mécanisme de détection de panne, parce que le watchdog prendra plus de temps pour détecter un message de vie manquant. Par exemple, si le cycle de heartbeat est de trois secondes, dans le pire des cas, le watchdog prendra trois secondes pour détecter la panne. Si nous agrandissons le cycle a n de réduire le tra c du réseau, mettons à neuf secondes, le système prendra trois fois plus de temps pour détecter la panne. Une stratégie adaptative pour régler le cycle de heartbeat/watchdog est donc essentielle pour réaliser une détection de panne su samment able, tout en conservant une performance acceptable La phase d analyse Dans cette phase, l agent de traitement d erreur identi e l état du Datacenter. Nous avons dé ni trois états pour un Datacenter Etat léger : le nombre de nœuds en pannes est inférieur au seuil T min Etat_chargé : le nombre de nœuds en pannes entre T min et T max Etat_critique : quand le nombre de nœuds en pannes dépasse T max Deux paramètres système sont utilisés : les seuils de panne T min et T max, ces paramètres xent la marge de chacun des trois états comme le montre la Figure 3.7. Fig. 3.7 Transitions d états de la charge d un Datacenter L intervalle du checkpoint et le cycle de watchdog varient selon l état du Datacenter. L agent surveillant contrôle l équilibrage de charge de Datacenter ; Quand une machine hôte tombe en panne l agent surveillant ajoute cette machine hôte à la liste des machines hôtes en panne, et enregistre la date dans laquelle la panne est détectée et actualise l état du Datacenter. Ces informations sont nécessaires pour con gurer

62 3. Nos contributions 52 l intervalle de checkpoint et le cycle de heartbeat/watchdog. L agent de traitement d erreur identi e toutes les machines virtuelles qui exécutaient sur la machine hôte qui a tombé en panne, et déclare ces machines virtuelles comme en panne et lance la procédure de rétablissement La phase de traitement d erreur Pour exécuter des tâches, le fournisseur utilise des machines virtuelles (VM) qui sont créés à la demande. La création d une image de VM implique un traitement avec une grande quantité de données [37], y compris l installation du système d exploitation invité et le déploiement du logiciel requis. Lorsque l agent surveillant détecte une défaillance de nœud, il en informe l agent de traitement d erreur qui doit redémarrer les applications qui ont été exécutés sur ce nœud. L agent de traitement d erreur sélectionne un nœud disponible dans le même Datacenter en Etat_leger pour lancer la procédure de reprise qui correspond à redémarrer les tâches depuis leur dernier point de reprise (voir Figure 3.8). Si le Datacenter est en état chargé ou critique, l agent de traitement d erreur sélectionne le Datacenter le moins chargé pour assurer un équilibrage de charge et sélectionne le dernier point de reprise. Fig. 3.8 Procédure de rétablissement

63 3. Nos contributions 53 Le tableau suivant (table 3.2) explique comment chaque élément agit dans chaque phase de notre architecture de tolérance aux pannes Elément Phase Checkpoint L agent de traitement L agent surveillant fonctionnelle d erreur Sauvegarde -Sauvegarde l état -Modi e l intervalle -Assure que le processus de la machine virtuelle de checkpoint de sauvegarde s est correctement terminé Surveillance -Modi e le cycle de heartbeat/ watchdog Analyse -Identi e l état des Datacenters Traitement d erreur -Sélectionner un nœud disponible -redémarrer les machines virtuelles depuis leur dernier point de reprise -La détection des pannes est réalisée par l envoi des messages de vie (heartbeat) et watchdog -Contrôler la charge du Datacenter Tab. 3.2 Rôle de chaque agent dans les di érentes phases de tolérance aux pannes 3.4 La description de la 2 eme approche L approche du Cloud Computing s appuie principalement sur le concept de virtualisation, où ce dernier est un ensemble de techniques permettant de faire fonctionner sur une seule machine plusieurs systèmes d exploitation et/ou plusieurs applications, isolés les uns des autres. Un Cloud est constitué d un ensemble de machines virtuelles qui utilisent la même infrastructure physique. Les techniques de virtualisation permettent notamment la migration de machines virtuelles d un nœud physique à un autre. La migration à chaud permet de déplacer une machine virtuelle d un nœud physique à un autre sans interruption de service, ce qui rend le processus totalement transparent. La migration à chaud permet à un administrateur de débrancher une machine virtuelle d une infrastructure physique donnée qui nécessite une maintenance sans soumettre les utilisateurs du système à un temps d arrêt.

64 3. Nos contributions Quand utiliser le mécanisme de migration? La migration permet d améliorer la tolérance aux pannes. Si une défaillance imminente est suspectée, le problème peut être résolu avant l interruption du service. La migration peut également être utilisée pour l équilibrage de charge, a n d optimiser l utilisation des ressources CPU et de mieux gérer et économiser l énergie. Fig. 3.9 Architecture globale de l approche basée sur la migration et la sauvegarde Les mêmes éléments fonctionnels utilisés dans la première approche sont présents aussi dans la deuxième approche en utilisant la migration, dont le but est d améliorer la tolérance aux pannes et d équilibrer la charge. Les éléments sont : l agent surveillant, checkpoint, et l agent de traitement d erreur. Ce dernier est le responsable de déclencher le mécanisme de migration des VMs d un Datacenter susceptible d être défaillant dans un future proche vers un autre Datacenter. Un Datacenter avec un état chargé indique qu il peut faire migrer des machines

65 3. Nos contributions 55 virtuelles créées vers d autres Datacenter. Un Datacenter avec un état critique indique que tous les machines virtuelle créées doivent être transférées vers d autres Datacenters. En n, l état léger indique qu aucun e ort n est utile pour le transfert des machines virtuelles créées. A la création d une machine virtuelle, l élément de contrôle détermine le Datacenter sur lequel va s exécuter la machine virtuelle. La politique de placement est décrite par l algorithme 1 suivant : si (EtatLocal = EtatLéger) alors Crée localement la machine virtuelle; sinon si (9 voisin/ Etat(voisin)=EtatLéger) alors Crée la machine virtuelle sur le Datacenter voisin; sinon Saturation locale; nsi Algorithm 1: Politique de de placement des VMs La saturation locale correspond à la situation où aucun des Datacenter voisins n est à l état léger. Dans cette situation, un des Datacenters voisins est choisi aléatoirement ; une priorité est donnée aux Datacenter qui sont à l état chargé. En e et, la probabilité de trouver un Datacenter en état léger au voisinage d un Datacenter en état chargé est plus grande que celle de le trouver au voisinage d un Datacenter en état critique. La migration de machines virtuelle est par ailleurs utilisée pour traiter d autres problèmes tels que la tolérance aux pannes et l accès à des ressources. Alors que l algorithme de checkpoint adaptative est activé à la création d une machine virtuelle, l algorithme de migration est activé à la défaillance d une machines virtuelle. En e et seul cet événement fait passer un Datacenter à un état chargé. Par contre la défaillance de plusieurs machines virtuelles peut basculer l état du Datacenter à l état critique. Avant que l agent de traitement d erreur lance le mécanisme de migration, il exécute un algorithme de recherche pour choisir le futur Datacenter. On peut envisager plusieurs algorithmes de recherche, pour avoir un bon équilibrage de charge nous avons utilisé dans notre approche un algorithme qui choisit le Datacenter le moins chargé. L algorithme exécuté est le suivant (voir algorithme 2) : La phase de recherche d un Datacanter dans un "Etat_léger" met en œuvre le protocole de négociation suivant : Le Datacenter en "Etat_critique " envoie une requête de migration au Datacenter en "Etat_léger" (ayant été déjà sélectionné) ; ce message indique que l émetteur de la requête est en "Etat_critique" et qu il demande de faire

66 3. Nos contributions 56 si (EtatLocal =EtatCritique) alors Trouvé Chercher le plus proche Datacenter en "EtatLéger" à une nsi distance inférieure à Dmax; si (Trouvé) alors Faire migrer un (ou plusieurs) machine virtuelle du Datacenter actuel nsi vers le Datacenter sélectionné; Algorithm 2: Choisir le futur Datacenter la migration des machines virtuelles. Après avoir reçu ce message, le Datacenter en "Etat_léger" peut soit acquitter la requête ou la rejeter ou accepter la migration de certaines machines (selon l état de sa charge) pour garder un équilibrage de charge. Un rejet est envoyé notamment lorsque le Datacenter n est plus en charge normale. Durant la phase de négociation, le Datacenter en "Pas_de_danger" réserve la charge proposée. Dans le cas où la requête de migration est rejetée, le processus de recherche se poursuit avec les autres Datacenters voisins. Par ailleurs, le temps de migration d une machine virtuelle ne doit pas être supérieur au temps nécessaire pour achever l exécution de la tâche sur la machine courante. Seules les tâches ayant des durées d exécution importantes peuvent permettre un gain substantiel en les faisant migrer. Dans le présent travail nous nous limitons à un choix aléatoire des machines virtuelles à faire migrer Scénarios de la migration Nous dé nissons deux scénarios correspondants qui peuvent être appliqués dans un Datacenter selon la gravité du problème. Dans ce cas, il faut déterminer le nombre des machines virtuelles à faire migrer. Scénario 1 : Migration au prochain checkpoint Dans ce scénario illustré par la Figure 3.10, il y aura une attente jusqu au prochain checkpoint puis une migration vers le nouvel hôte. Nous pouvons utiliser soit le mécanisme de checkpoint périodique soit celui adaptatif.

67 3. Nos contributions 57 Fig Migration au prochain checkpoint Scénario 2 : Checkpoint avant migration Ce scénario se caractérise par la réalisation d un checkpoint immédiat suivi d une migration vers le nœud destinataire. Dans ce cas, les checkpoints sont envisagés instantanément (voir Figure 3.11).

68 3. Nos contributions 58 Fig Checkpoint avant migration 3.5 Paramètres fonctionnels utilisés dans les deux approches L agent de traitement d erreur permet la con guration de deux paramètres : l intervalle de checkpoint et le cycle de watchdog/heartbeat. Choisir un intervalle de checkpoint optimal est une tâche di cile. L interaction entre l application et les checkpoints détermine l élargissement du temps d exécution de l application. Dans la littérature plusieurs études sur la façon de calculer le meilleur intervalle de checkpoint a n de minimiser le temps d exécution de l application en absence de défaillances [25] [32]. D autres travaux ont étudié les points de reprises dans un point de vue pratique [52] [58]. Le cycle de watchdog/heartbeat, associé à la latence de message, dé nit la sen-

69 3. Nos contributions 59 sibilité du mécanisme de détection de défaillance. Lorsque ce cycle est court, l agent surveillant va détecter rapidement la défaillance d un nœud en panne et la procédure de récupération va démarrer rapidement. Toutefois, un cycle très court n est pas pratique, car il augmente le nombre de messages de contrôle et, par conséquent, la surcharge du réseau. En outre, les cycles courts également augmentent la sensibilité du système en ce qui concerne la latence du réseau. Le réglage de ces deux paramètres, a n de parvenir à la meilleure performance du système de tolérance aux pannes, est fortement dépendant du : l historique et l état actuel d un nœud et l état du Datacenter. 3.6 Conclusion Dans ce chapitre, nous avons proposé deux approches de la tolérance aux pannes permanentes d assurer la sureté de fonctionnement des Clouds Computing et qui consiste à faire en sorte que le système délivre un service correct malgré l occurrence des fautes. La première approche est basée sur la sauvegarde et la reprise (checkpoint) des machines virtuelles tandis que la deuxième approche est basée sur le mécanisme de checkpoint et la migration. L intégration de ces approches de tolérance aux pannes soulève des problématiques d optimisation pour déterminer le compromis entre le surcoût induit par le mécanisme de tolérance aux pannes d un côté et l impact des pannes sur l exécution d un autre côté. Le prochain chapitre sera consacré à la partie d implémentation et évaluation de nos propositions de tolérance aux pannes. Nous mettrons en évidence l importance et l e cacité des approches proposées.

70 CHAPITRE 4 Implémentation de CloudSim-FT Sommaire 4.1 Langage et environnement de développement Langage de programmation Java Environnements de développement Architecture de CloudSim Description du fonctionnement de notre application Diagramme d utilisation Diagramme de classes Diagramme de séquence Interface principale Con guration des paramètres de simulation Lancement de la simulation Résultats expérimentaux Expérience 1 : Nombre de cloudlet echouées Expérience 2 : In uence de la période de sauvegarde (intervalle de checkpoint) Expérience 3 : Impact de la fréquence des pannes sur le comportement de notre première approche Expérience 4 : Comportement de la deuxième approche Synthèse des expériences Conclusion

71 4. Implémentation de CloudSim-FT 61 Ce chapitre est consacré à la réalisation et la concrétisation de nos approches proposées, qui consistent à tolérer les pannes dans les environnements de Cloud Computing. Dans un premier temps, nous présentons l environnement de notre travail, puis nous dé nissons les di érents services de notre simulateur que nous avons appelé CloudSim-FT, ensuite nous décrivons quelques interfaces graphiques, et nalement nous présentons une série de simulations et leurs interprétations pour mettre en évidence nos propositions. 4.1 Langage et environnement de développement Nous avons développé le simulateur sur une machine avec un processeur Intel(R) Core(TM)2 Duo CPU 2.00Ghz 2.00Ghz, doté d une capacité mémoire de 4GB, sous Windows 7 64 bits. Nous avons utilisé l environnement de développement Eclipse Langage de programmation Java Java est un langage de programmation à usage général, évolué et orienté objet dont la syntaxe est proche du C++. Il a été mis au point en 1991 par la rme Sun Microsystems 1. Il s agissait de concevoir un langage bien adapté aux environnements de travail en réseau et capable de gérer des informations de nature variées (données numériques, informations sonores et graphiques). Java est devenu aujourd hui une direction incontournable dans le monde de la programmation, parmi les di érentes caractéristiques qui sont attribuées à son succès : L indépendance de toute plate-forme : le code reste indépendant de la machine sur laquelle il s exécute. Il est possible d exécuter des programmes Java sur tous les environnements qui possèdent une Java Virtual Machine. Java est également portable, permettant à la simulation d être distribuée facilement sans avoir à recompiler le code pour les di érents systèmes. Le code est structuré dans plusieurs classes, dont chacune traite une partie différente de la simulation. Il assure la gestion de la mémoire. Java est multitâches : il permet l utilisation de Threads qui sont des unités d exécution isolées. Aussi, une des principales raisons de ce choix est que le simulateur CloudSim est développé avec ce langage. 1 http ://fr.wikipedia.org/wiki/java(langage)

72 4. Implémentation de CloudSim-FT Environnements de développement Eclipse 2 est un environnement de développement intégré, libre, extensible, universel et polyvalent, permettant de créer des projets de développement mettant en œuvre n importe quel langage de programmation. Eclipse IDE est principalement écrit en Java (à l aide de la bibliothèque graphique SWT, d IBM), grâce à des bibliothèques spéci ques, ce langage est également utilisé pour écrire des extensions. La spéci cité d Eclipse IDE vient du fait de son architecture totalement développée autour de la notion de Plug-in (en conformité avec la norme OSGi) : toutes les fonctionnalités de cet atelier logiciel sont développées en tant que Plug-in. Plusieurs logiciels commerciaux sont basés sur ce logiciel libre, comme par exemple IBM Lotus Notes 8, IBM Symphony ouwebsphere Studio Application Developer, etc. CloudSim Objectif principal de simulateur CloudSim est de fournir un cadre de simulation généralisé et extensible qui permet la modélisation, la simulation et l expérimentation des nouvelles infrastructures du Cloud Computing et les services d application, permettant aux utilisateurs de se concentrer sur des questions de conception du système qu ils veulent étudier, sans être préoccupé aux détails relatifs aux services et infrastructures Cloud. Nous avons utilisé pour la réalisation de notre travail la version du simulateur Cloudsim Architecture de CloudSim La structure logicielle de CloudSim et ses composants est représentée par une architecture en couches comme il est montré par la Figure 4.1. Les premières version de CloudSim utilise SimJava, un moteur de simulation d événement discret qui met en oeuvre les principales fonctionnalités requises pour des structures de simulation de haut niveau comme la formation d une le d attente et le traitement d événements, la création de composants système (les services, les machines (Host), le centre de données (Datacenter), le courtier (Broker), les machines virtuelles), la communication entre les composants et la gestion de l horloge de simulation. Cependant, dans la version actuelle, la couche SimJava a été supprimée a n de permettre à certaines opérations avancées qui ne sont pas pris en charge par celle-ci. 2 http ://fr.wikipedia.org/wiki/eclipse 3 http ://code.google.com/p/cloudsim/downloads/detail?name=cloudsim zip

73 4. Implémentation de CloudSim-FT 63 Fig. 4.1 Architecture de CloudSim 4.2 Description du fonctionnement de notre application Pour décrire les di érentes étapes d optimisation dans notre travail, nous avons opté pour le langage UML pour plusieurs raisons : Langage servant à décrire des modèles d un système (réel ou logiciel) basé sur des concepts orienté-objets. Système de notations pour modéliser les systèmes en utilisant des concepts orienté-objets. Représente un standard de modélisation, une notation : il s agit donc d un outil et non d une méthode ; chacun peut utiliser la méthode la plus appropriée a ses besoins. Il permet de représenter l aspect traitement du système aussi bien que l aspect donné. Parmi les diagrammes d UML que nous avons jugé intéressants pour notre conception, nous citons le diagramme d utilisation, de classes, de séquence et d activité.

74 4. Implémentation de CloudSim-FT Diagramme d utilisation Nous présentons maintenant une vue globale de notre simulateur qui permet de détailler les di érentes étapes e ectuées pour réaliser une simulation. La Figure 4.2 représente les fonctionnalités d utilisation nécessaires à l application. Le diagramme des cas d utilisation, est une modélisation d une fonctionnalité du système, il se détermine en observant et en précisant acteur par acteur les séquences d interactions avec le système. Les cas d utilisation décrivent les fonctions du système selon le point de vue des utilisateurs. Selon ce diagramme, l utilisateur commence la simulation par la con guration du Cloud puis la con guration des machines virtuelles. Dès que les Cloudlets sont créés et personnalisés, l utilisateur peut injecter les pannes et sélectionner le mécanisme de tolérance aux pannes. Ensuite l utilisateur peut lancer la simulation, les résultats de cette simulation sont présentés sous forme d un tableau et un digramme. Fig. 4.2 Diagramme d utilisation du simulateur Diagramme de classes Le diagramme de classes permet de représenter la structure du système comme un ensemble de relations entre classes. Le simulateur CloudSim est composé de plusieurs classes que nous pouvons classer en deux catégories : les classes que nous avons modi-

75 4. Implémentation de CloudSim-FT 65 ées sont montrées en bleu dans la Figure 4.3 comme la classe Datacenter, Datacenter Broker,... et les classes que nous avons ajoutées sont présentées en rouge dans la même Figure. Parmi les classes fondamentales qui forment les blocs constitutifs du simulateur CloudSim, nous pouvons citer : DataCenter Cette classe modélise l infrastructure du noyau du service (matériel, logiciel) o ert par des fournisseurs de ressources dans un environnement de Cloud Computing. Il encapsule un ensemble de machines de calcul qui peuvent être homogènes ou hétérogènes en ce qui concerne leurs con gurations de ressources (mémoire, noyau, capacité, et stockage). En outre, chaque composant de DataCenter instancie un composant généralisé d approvisionnement de ressource qui implémente un ensemble de politiques d allocation de bande passante, de mémoire et des dispositifs de stockage. DatacenterBroker Cette classe modélise le courtier (Broker), qui est responsable de la médiation entre les utilisateurs et les prestataires de service selon les conditions de QoS des utilisateurs et il déploie les tâches de service à travers les Clouds. Le Broker agissant au nom des utilisateurs identi e les prestataires de service appropriés du Cloud par le service d information du Cloud CIS (Cloud Information Services) et négocie avec eux pour une allocation des ressources qui répond aux besoins de QoS des utilisateurs. VirtualMachine Cette classe modélise une instance de machine virtuelle (VM), dont la gestion pendant son cycle de vie est une responsabilité de la machine (Host). Un Host peut simultanément instancier de multiples VMs et assigner des cœurs à base de politiques prédé nies de partage de processeur (espace partagé, temps partagé). Cloudlet Cette classe modélise les services d application de base du Cloud (la livraison, la gestion de réseau sociale, le déroulement des opérations d a aires), qui sont généralement déployés dans des DataCenters. CloudSim représente la complexité d une application en termes de ses besoins informatiques (taille en nombre d instruction, temps de réponse,...). Chaque composant d application a une taille d instruction pré-assignée

76 4. Implémentation de CloudSim-FT 66 Fig. 4.3 Diagramme de classe de la conception de simulateur CloudSim

77 4. Implémentation de CloudSim-FT 67 (héritée du composant de Gridlet de GridSim) et la quantité de ux de transfert de données qui doit être entreprise pour accueillir avec succès les applications. Fault injection Cette classe permet de modéliser l inter-arrivée des pannes a n de créer les scénarios nécessaires pour évaluer le bon fonctionnement de nos approches de tolérance aux pannes. De nombreux scénarios de pannes sont possibles au cours d exécution d une application et le test exhaustif de tous ces scénarios nécessite beaucoup de travail. Avec cette classe, il est possible de créer un scénario des pannes spéci que et surveiller le comportement de l architecture de tolérance aux pannes dans un tel scénario. Checkpoint Cette classe modélise le processus de checkpoint qui consiste à sauvegarder dans un support de stockage stable l état d une application durant son exécution. En cas de panne, l application est redémarrée depuis son dernier checkpoint Diagramme de séquence Le diagramme de séquence est l un des vues dynamiques les plus importantes d UML. La Figure 4.4 illustre le ux de communication entre les principaux acteurs de CloudSim sans tolérance aux pannes. Au début de la simulation, les Datacenter s enregistrent dans un annuaire appelé CIS (Cloud Information Service). Le Broker agissant de la part d un utilisateur consulte cet annuaire et obtient la liste de tous les Datacenter qui o rent des services d infrastructure correspondant aux exigences des applications des utilisateurs. Il envoi au Datacenter un message "VM Create" dans le but de créer les machines virtuelles et y faire exécuter les applications de l utilisateur. Si la création échoue, il fait la même chose avec un autre Datacenter et ainsi de suite. Lorsque un nœud tombe en panne le Datacenter informe le Broker de cette panne et il considère les machines virtuelle qui s exécutaient sur ce nœud comme étant des machines virtuelles défaillantes ainsi toutes les tâches envoyées à ces machines virtuelles sont déclarées comme "failed". Nous allons présenter un scénario d illustration (Figure 4.5) qui montre la communication entre les principaux acteurs du CloudSim avec le mécanisme de sauvegarde. Le"checkpoint" sauvegarde périodiquement l état des machines virtuelles, après l expiration de l intervalle de checkpoint, le "Checkpoint" envoie un message au Datacenter, après la réception de ce message, le Datacenter déclenche le mécanisme de sauvegarde.

78 4. Implémentation de CloudSim-FT 68 Fig. 4.4 Diagramme de séquence sans utiliser la tolérance aux pannes Après la détection d une panne le Datacenter informe le Broker de cette panne et il envois la liste des machines virtuelles défaillantes ainsi toutes les tâches qui ont été déclarées comme "failed". Le Broker essaie de recréer les VMs failed sur le même Datacenter, si la création échouera le Broker cherche un autre Datacenter. Après la création des VMs échouées le Broker redémarre les tâches de leurs derniers points de reprise. Le Datacenter envoi le message "tasks completion" au Broker pour lui informer que toutes les tâches ont été exécutées avec un succès, à la réception de ce message et si le Broker n a pas d autres tâches à exécuter, il envoie le message "Destroy VMs" pour détruire toutes les VMs crées. La Figure 4.6 illustre la communication entre les principaux acteurs de CloudSim avec la combinaison de la sauvegarde et la migration. A la présence de plusieurs pannes l état du Datacenter peut changer de "Etat léger" à "Etat chargé" ou à "Etat_critique". Le Datacenter envoie le message "stat of datacenter changed" au Broker pour lui informer de son nouvel état. Le Broker envoie un message à ce Datacenter pour récupérer la liste des VMs à migrer (si l état est "Etat_critique" alors le Datacenter doit faire migrer tous ses machines virtuelles vers d autres Dataceters). Avant de lancer le processus de migration le Broker lance un algorithme de recherche pour trouver le Datacenter en "Etat léger" et qui satisfait les exigences des VMs à migrer. Après la création des machines virtuelles sur le nouveau Datacenter (ou plusieurs Datacenter) le Broker redémarre l exécution des tâches sur ces machines virtuelles.

79 4. Implémentation de CloudSim-FT 69 Fig. 4.5 Diagramme de séquence de l approche basée sur le mécanisme de checkpoint

80 4. Implémentation de CloudSim-FT 70 Fig. 4.6 Digramme de séquence de l approche basée sur la combinaison des mécanismes de checkpoint et de migration

81 4. Implémentation de CloudSim-FT Interface principale La version de Cloudsim n a pas d interface graphique, son exécution se fait sur console, donc nous avons créé une interface qui facilite l accès au simulateur. Nous avons aussi étendu la première version du CloudSim dans les travaux [10] et [12]. L interface doit faire appel à Cloudsim ainsi qu aux di érentes approches qui se trouvent dans di érents packages. Dès le lancement de notre logiciel, la Figure 4.7 apparaît en premier aux utilisateurs, elle est constituée d une barre de menu contenant les menus suivants : Le menu Fichier, Simulation, A chage et le menu Aide ; chacun de ces menus contient un ensemble d items qui vont être détaillés par la suite. Nous allons nous intéresser dans cette partie à la démonstration de notre application à travers un exemple en faisant référence à quelques interfaces graphiques obtenues. Fig. 4.7 Interface principale du CloudSim-FT Con guration des paramètres de simulation Les Figures 4.8,4.9, 4.10 et 4.11 montrent les fenêtres de con guration des paramètres de simulation, faite par l utilisateur, elle contient 4 parties principales :

82 4. Implémentation de CloudSim-FT 72 Datacenter Cette étape consiste à faire entrer les paramètres nécessaires propres à la topologie du réseau (Figure 4.8)comme : le nombre de Data Center, d hôtes, de CPU, la vitesse de chaque CPU, le coût de traitement, la taille de la mémoire, le coût de la mémoire, la taille du disque dur, le coût de stockage et la bande passante ainsi que son coût. Fig. 4.8 Con guration du Datacenter VirtualMachine (VM) L onglet VirtualMachine permet de con gurer les machines virtuelles (Figure 4.9) par exemples : spéci cation du nombre de VM, de CPU dans une VM, la taille de la mémoire, la taille du disque dur et la bande passante. Cloudlet Permet de con gurer les propriétés de la Cloudltet par la Figure The cloudlet length : la taille de la Cloudlet à exécuter dans un CloudResource. The cloudlet le size : la taille du chier d entrée de la Cloudlet avant l exécution (la taille du programme + les données en entrée). The cloudlet output size : la taille du chier de sortie de la Cloudlet après l exécution.

83 4. Implémentation de CloudSim-FT 73 Fig. 4.9 Con guration des machines virtuelles Fig Con guration des Cloudlets

84 4. Implémentation de CloudSim-FT 74 Fault Tolerant L onglet Fault Tolerant permet à l utilisateur d injecter les pannes et de sélectionner le mécanisme de tolérance aux pannes. Without Fault-tolerant représente l exécution sans aucune approche de tolérance aux pannes, Checkpoint est l approche basée sur le mécanisme de sauvegarde, nous pouvons sélectionner le mécanisme de checkpoint périodique ou adaptatif. L option Migration correspond au déclanchement du processus de migration. Fig con guration de mécanisme de tolérance aux pannes Lancement de la simulation Après avoir personnaliser les paramètres de simulation, l utilisateur peut lancer la simulation en cliquant sur le bouton Start Simulation ou bien à partir du menu Simulation en choisissant l item qui correspond à son choix (voir Figure 4.12). Après la création du Cloud et le lancement de la simulation, l utilisateur peut visualiser les résultats et l état de traitement de Cloudlets. Les résultats obtenus après la simulation, ils sont accessibles en cliquant sur le bouton Result.

85 4. Implémentation de CloudSim-FT 75 Fig Interface de lancement de la simulation et de la visualisation des résultats 4.4 Résultats expérimentaux A n de valider et d évaluer nos approches de tolérance aux pannes en présence des défaillances, nous avons e ectué une série d expérimentations dont les résultats et les interprétations font l objet de cette section Expérience 1 : Nombre de cloudlet echouées Dans cette première simulation, nous avons mesuré le nombre de cloudlet exécutées avec succès et le nombre de cloudlet échouées. Cette simulation a été réalisée avec les paramètres de simulations suivants : un Datacenter avec 50 hôtes, où chaque hôte a été modélisé pour avoir quatre processeurs d une vitesse de 1000MIPS chacun, 2Go de mémoire RAM. Nous avons modélisé l utilisateur (via le DatacenterBroker) pour demander la création de 100 machines virtuelles ayant les caractéristiques suivantes : 512 Mo de mémoire physique, 1 CPU. Les résultats de cette simulation sont montrés dans les Figure 4.13 et Nous remarquons une diminution signi cative du nombre de cloudlet échouées en appliquant notre approche. Et cela est dû au mécanisme de tolérance aux pannes que nous avons appliqué pour relancer les Cloudlets échouées. Nous pouvons remarquer que avec notre approche a pu exécuter les 100 cloudlets envoyés avec succèsce qui est équivalent à 100% (voir Figure 4.14), à l inverse l approche sans tolérance a terminé l exécution de 60 cloudlet sur les 100 envoyées ce qui est équivalent à 60%. Le groupe de tests suivant permet d évaluer le comportement du système en présence des défaillances et sans utilisé le mécanisme de tolérance aux pannes. La gure 4.15 contient les résultats de quatre tests, et nous avons calculé le nombre d échecs pour chaque test. Nous avons utilisé les mêmes conditions expérimentales que celle utilisée à la simulation précédente. Nous avons fait varier le nombre de Cloudlets de 100, 150, 200 et 300 avec chaque unité de Cloudlet nécessite million d instructions à exécuter sur un hôte.

86 4. Implémentation de CloudSim-FT 76 Fig Nombre de cloudlets échouées sans tolérance aux pannes Fig Nombre de cloudlets échouées avec tolérance aux pannes Expérience 2 : In uence de la période de sauvegarde (intervalle de checkpoint) La seconde série d expérimentations consiste à étudier l in uence de l intervalle de checkpoint. Nous expérimentons le système avec des intervalles di érents de checkpoint de 40, 80, 120 et 240 secondes et nous comparons les résultats avec les exécutions des Cloudlets sans l utilisation de la tolérance aux pannes. Dans cette simulation, nous avons créé un Datacenter. Le Datacenter contient 50 hôtes de calcul, chaque hôte a 2 Go de mémoire, 4 processeurs avec 1000 MIPS de capacité. Le Broker tente de crée 100 VMs et associe deux Cloudlets à chaque VM pour être exécuté. Les VMs qu on veut créer nécessite 512 Mo de mémoire, 1 Go de

87 4. Implémentation de CloudSim-FT 77 Fig In uence des pannes sur le nombre de Cloudlets stockage, une unité centrale et Chaque Cloudlet est modélisé à avoir millions d instructions. Dans la Figure 4.16, nous présentons un résumé de ces tests. La gure représente le temps d exécution total (en secondes) pour les Cloudlets. Fig Impact de l intervalle de checkpoint sur le surcoût de sauvegarde L agrandissement dans le surcoût de sauvegarde augmente quand l intervalle de

88 4. Implémentation de CloudSim-FT 78 checkpoint est plus court parce que plus de checkpoint se produisent pendant l exécution du programme. La gure 4.17 représente le temps perdu causé par les pannes. D après les résultats, le temps perdu causé par les pannes augmente avec l augmentation de l intervalle de checkpoint. L intervalle de checkpoint a plus d in uence sur le comportement du système. Cette in uence du checkpoint sur le comportement du système est la conséquence du temps nécessaire pour la sauvegarde. Fig Impact de l intervalle de checkpoint sur le temps d exécution Expérience 3 : Impact de la fréquence des pannes sur le comportement de notre première approche Dans cette série de simulations nous avons testé l impact du nombre de pannes sur le comportement du système. Nous avons lancé 3 simulations dans un Cloud constitué de 4 Datacenter, chaque Datacenter contient 50 machines et Chaque machines a deux processeurs. Les Figures 4.17, 4.18 et 4.19 présentent les résultats pour trois scénarios : sans tolérance aux pannes, avec la tolérance aux pannes en utilisant l intervalle de checkpoint périodique et checkpoint adaptatif. La seule di érence entre les simulations est que le nombre des pannes qui varie entre 25% à 75% par un pas de 25 %. Nous avons calculé le temps de réponse (en secondes) des cloudlets et le surcoût généré par le fonctionnement du mécanisme de tolérance aux pannes pour chaque scé-

89 4. Implémentation de CloudSim-FT 79 nario. Les tableaux 5.16, 5.17 et 5.19 ainsi que les gures correspondantes synthétisent l ensemble des résultats de cette série d expérimentations. E et sur le temps d exécution Le tableau 4.1 résume l e et de l augmentation du nombre de pannes sur le temps d exécution. Le tableau montre de manière évidente, la supériorité de l approche basé sur le checkpoint par rapport à une exécution sans utiliser un protocole de tolérance aux pannes en ce qui concerne le temps d exécution. approche fault without periodic adaptive 25% % % , Tab. 4.1 E et de la fréquence des pannes sur le temps d exécution Les résultats du tableau 4.1 sont schématisés dans la Figure 4.18 Fig Impact des pannes sur le temps d exécution

90 4. Implémentation de CloudSim-FT 80 E et sur le temps perdu Le tableau 4.2 montre l e et de la variation de la fréquence de pannes sur temps perdu pour les trois approches. Nous remarquons que l approche basée sur le checkpoint périodique et adaptative permet de diminuer d une façon signi cative le temps perdu causé par les pannes. approche fault without periodic adaptive 25% % % Tab. 4.2 E et de la fréquence des pannes sur le temps perdu La Figure 4.19 est une illustration graphique du tableau 4.2 Fig Impact des pannes sur Le temps perdu E et sur le surcoût de sauvegarde Le tableau présente l évolution du surcoût de sauvegarde en fonction de la variation de la fréquence des pannes. L analyse du tableau montre que l approche basée sur le

91 4. Implémentation de CloudSim-FT 81 checkpoint adaptive donne des résultats qui sont légèrement supérieurs à l approche basée sur le checkpoint périodique (voir tableau 4.3 et Figure 4.20). approche fault without periodic adaptive 25% % 0 997, % 0 883, Tab. 4.3 E et de la fréquence des pannes sur sur le surcoût de checkpoint Fig Impact des pannes sur le surcoût de checkpoint En conclusion de cette troisième série d expériences, nous pouvons dire que : Les résultats obtenus avec les di érents scénarios montrent que l intégration des approches de tolérance aux pannes proposées n ont pas imposé un grand surcoût sur le temps d exécution. Les résultats con rment le gain qui peut être obtenu lorsque nous utilisons un protocole de sauvegarde. L approche utilisant le checkpoint adaptive donne de meilleurs résultats que les autres approches du point de vue temps d exécution.

92 4. Implémentation de CloudSim-FT Expérience 4 : Comportement de la deuxième approche Nous avons réalisé trois séries d expériences pour évaluer notre deuxième approche de tolérance aux pannes basée sur la migration et le checkpointing. Tout d abord, la première série d expériences vise à comparer le temps d exécution de la deuxième approche avec la première et aussi avec une exécution sans utiliser un protocole de tolérance aux pannes. Ensuite nous étudions l impact des pannes sur le nombre de machines virtuelle à faire migrer. En n nous étudions l e et de la migration sur l équilibrage de charge des Datacenter. E et sur le temps de réponse L analyse des résultats du tableau 4.4 montre que les deux approches proposées évoluent avec des valeurs voisines. Nous pouvons aussi remarquer un grand avantage de la première et la deuxième approche par rapport à une exécution sans utiliser un protocole de tolérance aux pannes. Execution time Waste time without checkpoint 51086, migration + checkpoint 51475, Tab. 4.4 E et de la fréquence des pannes sur le surcoût de checkpoint Fig Temps d exécution pour les trois approches

93 4. Implémentation de CloudSim-FT 83 Impact des pannes sur le nombre de migration A travers cette expérience, notre objectif était de voir comment l augmentation du nombre de pannes pouvait avoir un e et sur le nombre de machine migrée. Les résultats que nous avons obtenu, et qui sont schématisés dans la Figure 4.22 montrent que le nombre de machines virtuelles à faire migrer augmente avec le nombre de pannes. Fig In uence des pannes sur le nombre de migration E et sur le taux d utilisation des Datacenter Cette métrique exprime le pourcentage des machines utilisées par Datacenter, c està-dire le nombre de machines utilisées pour crée les machines virtuelles divisé par le nombre total des machines qui se trouve dans un Datacenter. Le tableau 4.5 montre le pourcentage d utilisation de chaque Datacenter par les deux approches proposées. Datacenter_0 Datacenter_1 Datacenter_2 Datacenter_3 checkpoint 25% 55,00% 0 0 checkpoint+migration 25% 28,75% 26,25% 26,25% Tab. 4.5 Le pourcentage d utilisation des Datacenter Les valeurs contenues dans ce tableau mettent en évidence une utilisation bien équilibrée des Datacenter avec la deuxième approche.

94 4. Implémentation de CloudSim-FT 84 La Figure 4.23, qui est une illustration graphique du tableau 4.5, montre une optimisation signi cation de la réparation de la charge à la di érence de la première approche qui ne gère pas d une manière ne l équilibrage de charge. Fig E et de la migration sur le taux d utilisation des Datacenter Dans la prochaine section, nous présentons une comparaison qui montre l avantage des approches proposées. 4.5 Synthèse des expériences Le tableau 4.6 compare les temps d exécution des deux approches de tolérance aux pannes proposé. La colonne "Time gained" représente le temps gagné sur le temps de traitement des applications en implémentant la première et la deuxième approche avec la présence de défaillances par rapport au temps de traitement sans utiliser un mécanisme de tolérance aux pannes. La lecture des valeurs contenues dans ce tableau illustre clairement la diminution du temps d exécution total quand nous utilisons un protocole de tolérance aux pannes. Le temps d exécution maximum avec l approche basée sur le checkpoint ( secondes, avec un fréquence de panne de 75%) est de 24,02% plus petite que le temps d exécution sans utilisé un mécanisme de tolérance aux pannes ( seconde) et 1.81 % plus petit que le temps d exécution avec l approche basée sur la combinaison de checkpoint et migration ( secondes). Les résultats du tableau 4.6 sont schématisés dans la Figure 4.24, qui illustre, de manière beaucoup plus claire les gains obtenus par les deux approches proposées.

95 4. Implémentation de CloudSim-FT 85 Number of faults approach Execution time Time gained % of time gained without % checkpoint ,51% migration+checkpoint ,00% without % checkpoint ,39% migration+checkpoint ,37% without % checkpoint ,02% migration+checkpoint ,21% Tab. 4.6 Le temps d exécution global et le temps gagné des trois approches Fig Le temps d exécution globale et le temps gagné des trois approches Nous remarquons que, lorsque l intervalle du checkpoint est plus petit, les surcoûts causés par les checkpoint sont un peu plus grande que lorsque l intervalle de checkpoint est grand. La raison pour cela est le nombre de checkpoint pendant l exécution d application. D un autre coté lorsque l intervalle du checkpoint est plus grand, la perte

96 4. Implémentation de CloudSim-FT 86 du temps de calcul causée par les pannes est plus grande. Dans la présence des pannes, l avantage de l architecture à tolérance de pannes devient clair. Les temps d exécution des deux approches proposées ont toujours été inférieurs aux temps d exécution sans utiliser le mécanisme de sauvegarde/reprise. L avantage de l approche basée sur le checkpoint adaptative est apparu lorsque les pannes surviennent à la n de l intervalle de checkpoint (avant de lancer une nouvelle sauvegarde). Le temps de calcul perdu causé par une panne dépend totalement du moment auquel cette panne à lieu. Par exemple, une panne qui a lieu quelques secondes après la sauvegarde ne cause la perte que de quelques secondes de temps de calcul. Si au contraire cette panne a lieu quelques secondes avant le lancement d une sauvegarde, le temps de calcul perdu peut être important et l avantage de l approche basée sur le checkpoint adaptatif devient de plus en plus claire dans ces derniers cas. Dans l approche basée sur le checkpoint adaptatif l instant de checkpoint varie selon les historiques (historique des pannes) et l état actuel d un nœud et son environnement d exécution, ce qui permet de réduire le temps perdu dû au surcoût de la sauvegarde et au travail perdu après les pannes. La deuxième approche permet une meilleure répartition de charge a n de garantir un niveau de qualité des applications permanent et élevé. D une part, cette solution permet de pallier la défaillance d un Datacenter et elle a presque les mêmes résultats que la première approche de point de vu temps d exécution. D autre part, elle permet d utiliser plusieurs Datacenter pour améliorer les performances des applications et garantir des meilleurs temps de réponse. 4.6 Conclusion Nous avons e ectué une série d expérimentations pour évaluer le coût des deux approches de tolérance aux pannes proposées. Nous avons réalisé plusieurs simulations en jouant sur di érents paramètres comme : le nombre de cloudlets, le nombre de pannes, l intervalle de checkpoint. Les résultats montrent que l utilisation de notre architecture réduit le temps perdu causé par les pannes et n ont pas imposé un surcoût élevé sur le temps d exécution.

97 Conclusion générale et perspectives Un des points le plus important pour une utilisation plus e cace de Cloud Computing est sans aucun doute l étude de la abilité et la robustesse de ces systèmes. Dans un tel contexte, la sûreté de fonctionnement des applications est un élément de première importance où le taux de pannes dans des tels systèmes croit avec la taille du système lui-même, c est pourquoi un mécanisme de tolérance aux pannes devient nécessaire pour en assurer certains aspects. Les pannes sont inévitables ; une application échouera, quelque soit son environnement. En plus quand un système informatique devient plus complexe, la sensibilité du système aux défaillances augmente. Dans ce scénario, les administrateurs ont besoin d outils et des mécanismes qui les aident à tolérer les pannes de manière transparente, e cace et avec des surcoûts raisonnable sur le temps d exécution sans pannes. Au cours de ce mémoire, nous avons développé une architecture de tolérance aux fautes dans les Cloud Computing. Nous avons proposé deux approches, la première approche se base essentiellement sur le mécanisme de checkpoint dans le but de minimiser le temps perdu par les pannes, tandis que la deuxième approche c est une combinaison du mécanisme de checkpoint et de migration qui permet de garantir la continuité des services du Cloud Computing d une façon transparente et e cace en cas des pannes. Les avantages de checkpoint sont limités par le surcoût d exécution, qui est le délai résultant de l interruption de l exécution du travail pour e ectuer la sauvegarde, et le temps de rétablissement, qui est le temps nécessaire pour redémarrer une machine virtuelle de son dernier point de reprise. A partir de ces limites, nous avons proposé une approche basée sur un checkpoint adaptatif qui permet d une part, de minimiser le surcoût de sauvegarde en réduisant les points de reprise inutiles et, d autre part, de réduire le temps perdu causé par les pannes en introduisant des checkpoints supplémentaire, quand le danger de défaillance est considéré comme grave. Pour mettre en évidence les deux approches proposées nous avons étendu le simulateur CloudSim et nous avons lancé un ensemble des expérimentations en créant plusieurs scénarios de pannes. Les performances sont évaluées à l aide d un ensemble des métriques telles que : nombre d applications échouées, le temps d exécution, le surcoût de checkpoint, le surcoût de migration et le temps perdu causé par les pannes. Les résultats montrent que les deux approches proposées présentent de bonnes performances, elles induisent en particulier un surcoût faible sur le temps d exécution et elles minimisent le temps perdu causé par des pannes. 87

98 4. Conclusion générale et perspectives 88 Les travaux de recherches que nous avons mené dans le cadre de la problématique de la tolérance aux pannes dans les Cloud Computing, ainsi que les résultat que nous avons obtenu ont montré que nos propositions ont permis d obtenir e ectivement des résultats meilleurs que l approche sans tolérance aux pannes. Néanmoins, un certain nombre de piste de recherche sont envisageables pour poursuivre ce travail. Parmi ces pistes de recherche nous pouvons mentionner ce qui suit : Validation de nos propositions sur une plateforme de Cloud Computing, telle que : Eucalyptus, Nebula. Utiliser la sauvegarde incrémentale, son principe est de ne sauvegarder que les données qui ont été modi ées depuis la dernière sauvegarde. Ceci permet de réduire le surcoût de checkpoint et le volume de donné à sauvegarder car toutes les données ne sont pas forcément modi ées entre chaque étape de sauvegarde. Étendre les expérimentations et les comparaisons que nous avons réalisées en étudiant l in uence de la migration sur la consommation d énergie des Datacenter.

99 Bibliographie [1] Alvisi L. and Marzullo K. : Message logging : Pessimistic, optimistic, causal, and optimal. IEEE Transactions on Software Engineering, 24(2) pp , [2] Amazon EC2, Amazon Elastic Compute Cloud, http ://aws.amazon.com/ec2/ [3] Anderson J. : Choisissez votre cloud, Août http :// FR/CloudPublicVsPrivate_PoV.pdf. [4] ApréaJ. F. : HyperV et SC VMM Virtualisation sous Windows Server 2008 R2, [5] Arlat J., Crouzet Y., DeswarteY., Fabre J.C., Laprie J.C. et Powell D. : Encyclopédie de l Informatique et des Systèmes d Information, chapitre Tolérance aux fautes, pp Vuibert, [6] Armbrust M., Fox A., Gri th R., Joseph A. D., Katz R. H., Konwinski A., Lee G., Patterson D. A., Rabkin A., Stoica I. and Zaharia M. : A view of cloud computing. Commun. ACM, 53(4) pp , [7] Avizienis A., Laprie J.C., Randell B. et Landwehr C. E. : Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1) pp , [8] Baldoni R. : A communication-induced checkpointing protocol that ensures rollbackdependency trackability. In Proceedings of the 27th International Symposium on Fault-Tolerant Computing (FTCS 97). [9] Belalem G. : Contribution à la gestion de la cohérence de répliques de chiers dans les systèmes à grande échelles. Thèse de doctorat, Université d Oran, Algérie, 2007 [10] Belalem G. and Limam S. : Towards Improving the Functioning of CloudSim Simulator. The International Conference on Digital Information Processing and Communications (ICDIPC 2011), V. Snasel, J. Platos, E. El Qawasmeh (Eds.), Proceedings Part II, CCIS Vol. 189, pp , July 7-9, 2011, VSB- Technical University of Ostrava, Czech Republic, Springer, ISSN , ISBN

100 BIBLIOGRAPHIE 90 [11] Belalem G. and Limam S. : Fault Tolerant Architecture to Cloud Computing Using Adaptive Checkpoint. International Journal of Cloud Applications and Computing (IJCAC), Vol.1, No.4, pp , [12] Belalem G. and Limam S. : An Extension and Improvement of the CloudSim Simulator. International Journal of Digital Information and Wireless Communications (IJDIWC), Vol. 1, No.2, pp , [13] Bertier M., Marin O. and Sens P. : Performance analysis of a hierarchical failure detector. In Proceedings of the International Conference on Dependable Systems and Networks, pp , [14] Besseron X. : Tolérance aux fautes et recon guration dynamique pour les applications distribuées à grande échelle,thèse de Doctorat, Université de Grenoble, France, avril [15] Bhargava B. and Lian S. R. : Independent checkpointing and concurrent rollback for recovery an optimistic approach. In In Proceedings of the Symposium on Reliable Distributed Systems. [16] Blumofe R. D., Joerg C. F., Kuszmaul B. C., Leiserson C. E., Randall K. H. and Cilk Y. Z. : An e cient multithreaded runtime system. Journal of Paral lel and Distributed Computing, 37(1) pp , [17] Bonvin N., Papaioannou T. G. and Aberer K. : A self-organized, fault-tolerant and scalable replication scheme for cloud storage. In Proceedings of ACM Symposium on Cloud Computing, Indianapolis, IN, USA, [18] Bosilca G., Bouteiller A., Cappello F., Djailali S., Fedak G., Germain C., Herault T., Lemarinier P., Lodygensky O., Magniette F., Neri V. and Selikhov A. : Mpichv : toward a scalable fault tolerant mpi for volatile nodes. In Supercomputing 02 : Proceedings of the 2002 ACM/IEEE conference on Supercomputing, pages 1 18, Los Alamitos, CA, USA, IEEE Computer Society Press. [19] Bouchenak-Khelladi S. : Mécanismes pour la migration de processus Extension de la machine virtuelle Java, [20] Briatico D., Ciu oletti A. and Simoncini L. : A distributed domino-e ect free recovery algorithm. In IEEE International Symposium on Reliability, Distributed Software, and Databases, [21] Chandra T. And Toueg S. : Unreliable failure detectors for reliable distributed systems. J. ACM, 43(2) pp , [22] Cloud computing. http ://fr.wikipedia.org/wiki/cloud_computing. [23] Conan D. : Tolérance aux fautes par recouvrement arrière dans les systèmes informatiques répartis. Thèse de Doctorat, Université de Paris 6, France, Septembre [24] Coti C., Herault T., Lemarinier P., Pilard L., Rezmerita A., Rodriguez E. and Cappello F. : Blocking vs. non-blocking coordinated checkpointing for large-scale fault tolerant mpi. In IEEE/ACM SC 2006, Tempa, USA, Novembre [25] Daly J. T. : A higher order estimate of the optimum checkpoint interval for restart dumps. Future Generation Computer Systems, 22(3), pp , February 2006.

101 BIBLIOGRAPHIE 91 [26] Défago X. : Agreement-Related Problems. : From Semi-Passive Replication to Totally Ordered Broadcast. PhD thesis, Ecole Polytechnique Fédérale de Lausanne, Switzerland, August [27] Défago X. and Schiper A. : Semi-passive replication and lazy consensus. Journal of Parallel and Distributed Computing, 64(12) pp , December [28] Delbé C. : Tolérance aux pannes pour objets actifs asynchrones : protocole, modèle et expérimentations. Thèse de doctorat, Université de Nice, France, Janvier [29] Deng J., Huang S. C-H., Han Y. S. and Deng J. H. : Fault-Tolerant and Reliable Computation in Cloud Computing, IEEE Globecom 2010 Workshop on Web and Pervasive Security (WPS 2010), Miami, December, [30] Dib D. : Migration dynamique d applications réparties virtualisées dans les fédérations d infrastructures distribuées. Université de Rennes, France, Juin [31] Drapeau S. : Un Canevas Adaptable de Services de Duplication. Thèse de doctorat, Institut National Polytechnique de Grenoble - INPG, juin [32] Duda A. : The e ects of checkpointing on program execution time. Information Processing Letters, 16(5), pp , June [33] Elnozahy E. N. : Manetho : fault tolerance in distributed systems using roll backrecovery and process replication. Phd thesis, Rice University, Houston, TX, USA, [34] Elnozahy E. N., Alvisi L., Wang Yi-Min et Johnson D. B. : A survey of rollbackrecovery protocols in message-passing systems. ACM Computing Surveys, 34(3) pp , [35] Foster I. and Kesselman C. : The grid : blueprint for a new computing infrastructure. Morgan Kaufmann, [36] Goel S. and Buyya R. : Data replication strategies in wide area distributed systems. In Robin G. Qiu, editor, Enterprise Service Computing : From Concept to Deployment, pp Idea Group Inc., Hershey, PA, USA, [37] Goiri I., Julià F., Guitart J. and Torres J. : Checkpoint-based fault-tolerant infrastructure for virtualized service providers. 12th IEEE/IFIP Network Operations and Management Symposium (NOMS 10), Osaka, Japan, April 19-23, 2010, pp [38] Google code. http ://code.google.com/. [39] Google app engine. http ://code.google.com/intl/fr-fr/appengine/. [40] Grevet N. : Le cloud computing : évolution ou révolution. Mémoire de recherche, Aout [41] Haouati M. S. : Architectures innovantes de systèmes de commandes de vol. Thèse de doctorat, Université de Toulouse, mai [42] Hélary J., Mostefaoui A., Netzer R. and Raynal M. : Communication-based prevention of useless checkpoints in distributed computations. Distrib. Comput., 13(1) pp , 2000.

102 BIBLIOGRAPHIE 92 [43] Jafar S. : Programmation des systèmes parallèles distribués : tolérance aux pannes, résilience et adaptabilité. Thèse de doctorat, institut national polytechnique de Grenoble-INPG, juin [44] Kalla H. : Génération automatique de distributions/ordonnancements temps réel, ables et tolérants aux fautes, [45] Laprie J.C. : Concepts de base de la tolérance aux fautes ; journée de. l OFTA, Informatique tolérante aux fautes, Paris, Avril. 94. [46] L avenir est au cloud computing. http :// [47] Lefort A. : Cloud Computing. Projet tutoré en licence professionnelle ASRALL, [48] Les 6 étapes d une "Live Migration" http :// [49] Li J., Humphrey M., Cheah Y-W., Ryu Y., Agarwal D., Jackson K. and Van Ingen C. : Fault Tolerance and Scaling in e-science Cloud Applications : Observations from the Continuing Development of MODISAzure, In IEEE e-science 2010 Conference. Brisbane, Australia. Dec 7-10, [50] Maâlej A. J. : Évaluation de Politiques d Auto-Adaptabilité basées sur la Mobilité des Services Web Orchestrés. Master s thesis, École Nationale d Ingénieurs de Sfax, [51] Malvault W. : Vers une architecture pair-à-pair pour l informatique dans le nuage. Thèse de Doctorat, Université de Grenoble, France, Octobre [52] Mandal P. S. and Mukhopadhyaya. K. : Estimating Checkpointing, Rollback and Recovery Overheads. In Proceedings of The 5th International Workshop on Distributed Computing - IWDC 2003, pp. Kolkata, India. December 27-30, Springer. [53] Manivannan D. and Singhal M. : Quasi-synchronous checkpointing : Models, characterization, and classi cation. IEEE Trans. Parallel Distrib. Syst., 10(7) pp , [54] Mazouni K. R. : Etude de l invocation entre objets dupliqués dans un système tolérant aux fautes. Thèse de Doctorat, Université de Paris 6, France, [55] Monnet S. : Gestion des Données dans les Grilles de Calcul. Support pour la Tolérance aux Fautes et la Cohérence des Données. PhD thesis, Université de Rennes, France, Novembre [56] Netsuite. http :// [57] Oracle White Paper in Enterprise Architecture Architectural Strategies for Cloud Computing. [58] Plank J. S. and Thomason M. G. : Processor Allocation and Checkpoint Interval Selection in Cluster Computing Systems. Journal of Parallel and Distributed Computing 61(11), pp , November [59] Powell D. : Failure mode assumption coverage. In 22th IEEE Sumposium on Fault tolerant Computing, 1992.

103 BIBLIOGRAPHIE 93 [60] Randell B. : System structure for software fault tolerance. In Proceedings of the international conference on Reliable software. [61] Salesforce. https :// [62] Strom R. E. and Yemini S.A. : Optimistic recovery in distributed systems. ACM Transactions on Computer Systems, 3(3) pp , [63] Syntec informatique. : Tout ce que vous devez savoir sur l informatique dans le nuage. Le Livre Blanc du Cloud Computing. http ://journal-ntic.fr/wp-content/uploads/2011/06/livre-blanc-cloudcomputing.pdf. [64] Tomas G. : Con guration réseau et mise en place de Customer Immersion Experiences au Microsoft Innovation Center de Mons, [65] Vial J. : Test et Testabilité de Structures Numériques Tolérantes aux Fautes, Université de Montpellier, [66] Warin S. : Le Cloud Computing. Réelle révolution ou simple évolution. Livre Blanc sur le Cloud Computing, Février http :// [67] Wiesmann M., Pedonne F. and Schipper A. : A systematic classi cation of replited database protocols based on atomic broadcast. In Proceedings of the 3th European Research Seminar on Advances in Distributed Systems (ERSADS99). [68] Windows azure. http :// [69] Yahoo! Inc., Yahoo! and CRL to Collaborate on Cloud Computing Research, [70] Zheng Z., Zhou T. C., Lyu M. R., King I. : FTCloud. : A Component Ranking Framework for Fault-Tolerant Cloud Applications, Proceedings of the 21th IEEE International Symposium on Software Reliability Engineering (ISSRE 2010), pp

104 Résumé Le Cloud Computing fait référence à l utilisation des capacités de calcul des ordinateurs distants, où l utilisateur dispose d une puissance informatique considérable sans avoir à posséder des unités puissantes. La probabilité de voir une panne intervenir durant l exécution devient forte lorsque le nombre de nœuds augmente ; puisqu'il est impossible d'empêcher totalement les pannes, une solution consiste à mettre en place des mécanismes de tolérance aux pannes. La tolérance aux pannes est devenue une tâche majeure pour les ingénieurs informatiques et les développeurs de logiciels, car l'apparition de pannes augmente le coût de l'utilisation des ressources. Dans ce travaille nous avons développé une architecture de tolérance aux pannes dans les Cloud Computing. Nous avons proposé deux approches, la première approche se base essentiellement sur le mécanisme de checkpoint dans le but de minimiser le temps perdu par les pannes tandis que la deuxième approche c est une combinaison du mécanisme de checkpoint et de migration qui permet de garantir la continuité des services du Cloud Computing d une façon transparent et efficace en présence des pannes. Les résultats obtenus par la simulation montrent l efficacité des deux approches proposées de tolérance aux pannes en termes de temps d exécution et de masquage des effets négatifs de pannes. Mots-clés: tolérance aux pannes, Cloud computing, virtualisation, checkpointing, migration. Abstract Cloud computing refers to the use of memory and computing capabilities of computers and servers around the world, where the user has considerable computing power without the need of having powerful machines. The probability of failure occur during the execution becomes stronger when the number of node increases; since it is impossible to fully prevent failures, one solution is to implement fault tolerance mechanisms. Fault tolerance has become a major task for computer engineers and software developers because the occurrence of faults increases the cost of using resources. In this work we have developed a fault tolerant architecture to Cloud Computing. We have proposed two approaches; the first approach is essentially based on the checkpoint mechanism in order to minimize the time lost by failures while the second approach is a combination of migration and checkpoint mechanism which ensures continuity of service of Cloud Computing in a way transparent and efficient in case of failure. The results obtained by the simulation show the effectiveness of our approaches to fault tolerance in term of execution time and masking effects of failures. Keywords: Fault tolerance, Cloud computing, Virtualization, Checkpointing, migration. الخلاصة الحساب السحابي یشیر إلى استخدام قدرات حسابیة لا جھزة كمبیوتر متباعدة حیث حاسوبیة كبیرة دون الحاجة إلى امتلاك وحدات قویة.احتمال حدوث عطل أثناء التنفیذ یصبح قویا عندما یزید عدد ا لعقد. نظرا لا نھ من المستحیل منع حدوث الاخطاء تماما ال استخدام وذلك لا ن الاعطال في ا لحساب ال سحابي. اق ترحنا ا ا لموارد. قمنا نقاط لثاني أساسا على آلیة نقاط الحفظ من أجل التقلیل من الوقت الضاي ع جراء الخطا ا ل عطل. نتاي ج الحفظ وآلیة الھجرة التي تضمن استمراریة خدمات الحساب السحابي بطریقة شفافة وفعالة و اخفاء التجارب المستخلصة عن طریق المحاكاة اظھرت فعالیة النھجین المقترحین للعطل. كلمات البحث: التكیف مع الخطا, الحساب السحابي, الافتراضیة, نقاط الحفظ