Tolérance aux fautes pour les applications de type

"Diviser pour régner" est un paradigme populaire et ecace pour développer des applications parallèles de la grille [206]. Le paradigme "Diviser pour régner" est une généralisation du paradigme maître/esclave recommandé par le Global Grid Forum, comme un paradigme ecace pour le développement des applications de grille [120]. Les applications "Diviser pour régner" fonctionnent en divisant un pro- blème de manière récursive en sous-problèmes. La subdivision récursive continue jusqu'à ce que les sous-problèmes deviennent triviaux à résoudre. Après la résolu- tion des sous-problèmes, les résultats sont combinés de façon récursive jusqu'à ce que la solution nale est assemblée. Cela conduit à un arbre d'exécution de tâches imbriquées. Diérents mécanismes de tolérance aux fautes pour des applications "Diviser pour régner" ont été développés [188]. DIB (Distributed Implementa- 44 5. TOLÉRANCE AUX FAUTES DANS LES GRILLES DE CALCUL

CHAPITRE 2. TOLÉRANCE AUX FAUTES DANS LES GRILLES DE CALCUL tion of Back tracking) [56] utilise le parallélisme "Diviser pour régner" et le vol de tâches. Dans DIB, lorsqu'un processeur n'arrive pas à exécuter un job, il émet une requête de vol, mais en attendant il commence à refaire le travail inachevé qui a été volé plus tôt. Cette approche est robuste parce que les défaillances peuvent être manipulées, même sans être détectées. "Diviser pour régner" se prête très bien pour la tolérance aux fautes, car tout job de l'arbre d'exécution d'une application peut toujours être recalculée en cas où son résultat a été perdu. Cependant, cette stratégie peut conduire à des calculs redondants très élevés. Système MW (Mas- ter.Worker) [77]. MW est un framework de programmation qui fournit une API pour implémenter les applications de grille " maître/esclave ". Dans le paradigme " maître/esclave ", les jobs à exécuter sont soumis à un processeur, appelé le maître, qui va les répartir à plusieurs processeurs, appelés esclaves. La tolérance aux fautes dans les systèmes "maître/esclave" peut être fournie par une réexécution des jobs perdus dans une défaillance. Etant donné que seul le processeur maître génère le job et recueille les résultats, il n'y a pas de problème de jobs orphelins, tant que le maître reste vivant. La défaillance du maître doit, par contre, être traitée sépa- rément. Dans [219], les auteurs ont présenté un mécanisme qui permet la tolérance aux fautes, la malléabilité et de la migration pour les applications "Diviser pour régner". L'approche proposée utilise les résultats partiels par la restructuration de l'arbre d'exécution, ce qui permet de réduire énormément le calcul redondant.

6 Conclusion

Dans ce chapitre, nous avons fait un survol sur les diérentes techniques de dé- tection et de tolérance aux fautes qui datent depuis l'émergence des systèmes distri- bués. Les politiques de tolérance aux fautes comme la réplication et le recouvrement donnent des résultats très satisfaisants dans les systèmes distribués ordinaires. Le passage à l'échelle de ces systèmes, qui s'est accentué par l'apparition des clusters et plus tard par les grilles de calcul, a créé des contraintes nouvelles, comme la dyna- micité et l'hétérogénéité. Ceci a conduit les chercheurs à faire des choix stratégiques, entre la mise à jour des anciennes techniques de tolérance aux fautes et à les adap- ter aux nouveaux systèmes ou le développement de nouvelles techniques répondant convenablement aux nouvelles contraintes.

Chapitre 3

Modèles hiérarchiques de tolérance

aux fautes

1 Introduction

La présence de fautes et les défaillances qui peuvent en découler sont l'une des conséquences de la dynamicité des grilles. Les principales fautes sont de type fautes franches et concernent essentiellement les n÷uds d'une grille [84]. Il existe de nom- breux travaux de recherche, aussi bien sur la détection que sur la tolérance de ce type de fautes [198]. La plupart de ces travaux ont proposé des approches basées sur des techniques de réplication et sur des mécanismes de points de reprise [104]. A l'exception de l'approche décrite dans [128], ces travaux n'ont pas pris en compte la topologie réseau des grilles de calcul. Aussi, de nombreuses solutions proposées reposent sur des synchronisations entre groupes de n÷uds. Dès lors que l'on sou- haite adapter ce type de solutions aux grilles de calcul, il est nécessaire de prendre en compte la topologie du réseau utilisé pour dénir une stratégie de tolérance aux fautes qui puisse donner de bons résultats. Dans ce chapitre, nous proposons deux modèles hiérarchiques de tolérance aux fautes dans les grilles de calcul. Ces modèles se caractérisent par : (i) l'utilisation d'une structure hiérarchique des n÷uds ; (ii) l'existence d'un gestionnaire pour superviser chaque niveau de la hiérarchie ; (iii) une coopération entre les gestionnaires pour assurer la tolérance aux fautes au niveau de toute la grille..

2

Modèle hiérarchique dynamique

Une grille peut contenir plusieurs centaines de milliers de ressources hétérogènes et dynamiques, réparties sur une très large échelle. Parmi les modèles de structu- ration de ces ressources, nous trouvons les modèles hiérarchiques ou arborescents répondant favorablement aux architectures client/serveur, aux diérents niveaux de 47

connexion réseau (LAN et WAN) et aux capacités des diérentes ressources. La ma- jorité des modèles proposés sont statiques, dans lesquels une grille est formée d'un ensemble de clusters reliés par une connexion WAN. Chaque cluster est constitué d'un ensemble de sites locaux gérant un ensemble de n÷uds chargés d'exécuter les tâches des utilisateurs. Malgré que ces modèles aient donné des résultats encoura- geants, ils restent limités sur certains aspects :

1. Mauvaise gestion du volume de la grille : cette mauvaise gestion concerne aussi bien l'ajout que la suppression des n÷uds d'une grille. Dans le cas de la réduction de ressources, il serait inutile de les structurer en un nombre de niveaux élevés ; dans le cas d'une augmentation, le nombre de niveaux peut devenir relativement grand.

2. Mauvaise gestion de la dynamicité : parmi les caractéristiques fondamentales des grilles de calcul, la dynamicité reste un élément essentiel. Or cette dy- namicité ne peut être en aucun cas être traitée par un modèle hiérarchique statique.

Partant de ce constat, nous proposons un modèle hiérarchique dynamique, composé d'une racine, d'un nombre variable de niveaux intermédiaires et d'un niveau feuille (terminal) contenant les n÷uds chargés d'exécuter les jobs. La dynamicité du mo- dèle proposé est liée au nombre de ressources disponibles dans la grille et de leurs distributions dans l'arborescence [163].