Tolérance aux fautes du n÷ud

Dans ce cas, le n÷ud (diérent d'un n÷ud de travail) n'est plus opérationnel. Le RMS doit réaecter toutes les tâches qui sont en cours d'exécution ou en attente aux voisins collaborateurs du n÷ud défaillant. En pratique, le RMS recherche, pour chaque tâche, les voisins collaborateurs les plus ables. Supposons que le noeud Nk

est défaillant et le RMS veut réaecter la tâche Ti au voisin collaborateur Nl. A

partir de l'équation (5.7), le n÷ud le plus able pour l'exécution de la tâche Ti est

le noeud Nl qui vérie l'équation suivante :

M igr(Ti, RM S, Nl) = M ax{NRil} (5.13)

5 Illustration numérique

Nous donnons une illustration numérique de notre modèle de abilité du service de la grille. Supposons un service composé de cinq tâches qui peuvent être aectées à 10 n÷uds. Les informations relatives aux n÷uds de la grille et les liaisons de communication sont montrées dans le Tableau 5.3, et les attributs des cinq tâches sont présentés dans le Tableau 5.4.

Nous avons utilisé les mêmes valeurs d'attributs de n÷uds et des tâches comme ceux présentés dans [83], an d'être en mesure de comparer les résultats. La abilité de service de grille dépend non seulement de son temps d'exécution mais aussi du volume de données échangées entre le RMS et les n÷uds qui exécutent ce service. Lorsque le volume des données échangées entre les n÷uds et le RMS augmente, la valeur de la abilité du service de grille est réduite (voir Figure 5.4). Pour un vo- lume de données de 0.01 Go le RS = 0.9926 tandis que pour un volume de données de 200 Go le RS = 0.0643. Nous pouvons maintenant comparer nos résultats avec les résultats présentés dans [83] pour une tolérance aux fautes, i.e. , x = 1, ce qui implique qu'il n'y a aucune défaillance et pour un volume de données de 0.012 Go. Les auteurs de [83] trouvent une abilité du service R = 0.9767, sans contraintes sur le temps de vie des tâches et sur le nombre de recouvrements eectués. Pour le même volume de données, nous avons trouvé RS = 0.9916. Les auteurs de [83] n'ont pas donné une analyse sur l'inuence du volume de données échangées sur la abi- lité du service, mais il est clair dans leurs formules que cette inuence est négligeable. Dans la Figure 5.5, nous analysons l'inuence du temps d'exécution sur la abilité du service. Si le temps d'exécution des tâches est long, la abilité du service de grille diminue. En eet, pour ζik = 500 sec., RS = 0.9916 et pour ζik = 100000

CHAPITRE 5. MODÈLE FIABLE DE TOLÉRANCE AUX FAUTES N÷ud k Sk λk W Tk λRk SRk 1 10 0.1 3 0.1 2 2 20 1.8 4 0.2 3 3 15 1.2 10 0.3 4 4 25 1.5 30 0.4 5 5 12 1.9 12 0.1 6 6 20 0.8 5 0.2 6 7 13 0.9 6 0.3 3 8 10 1.2 24 0.1 4 9 29 1.2 15 0.2 3 10 32 0.8 23 0.3 4

Table 5.3  Attributs des n÷uds et des liens

Tâche i ci (Gops) DRik DR R ik T1 6 12 15 T2 8 16 20 T3 7 14 17 T4 10 20 25 T5 8.5 17 22

Table 5.4  Attributs des tâches

sec (27h 46mn 40s), RS = 0.2859. Nous pouvons noter que lorsque la tâche a une complexité de calcul élevée, sa abilité est considérablement réduite, ce qui nécessite le développement de techniques de tolérance aux fautes. Nous pouvons comparer nos résultats avec les résultats présentés dans [82]. Pour x = 1, et un temps d'exécution = 2000 sec., la abilité du service est R = 0.8892, sans contraintes sur le temps de vie des tâches et sur le nombre de recouvrements eectués et pour une récupération après défaillance, i.e. , x = 0, et un temps d'exécution = 2000 sec., R = 0.0832. Pour les mêmes conditions, nous avons trouvé RS = 0.9732. Dans les Figures 5.4 et 5.5, nous pouvons observer l'inuence du volume de données échangées et de la complexité de calcul des tâches sur la abilité des services de grille.

Figure 5.4  Inuence du volume de données échangé sur la abilité du service de grille

Figure 5.5  Inuence du temps d'exécution du processus sur la abilité du service de grille

6 Conclusion

L'approche fondamentale dans les recherches sur la tolérance aux fautes dans les grilles de calcul est le mécanisme RNFR. Le LNFR est proposé pour réduire la charge du RNFR. Le LNFR pourrait être plus utile que le RNFR pour redémarrer l'exécution d'une tâche sur le n÷ud défaillant une fois ce n÷ud est réparé. Par conséquent, le LNFR peut être utilisé avec le RNFR de manière complémentaire

CHAPITRE 5. MODÈLE FIABLE DE TOLÉRANCE AUX FAUTES pour atteindre la tolérance aux fautes dans un environnement de grille. Dans ce chapitre, nous avons proposé une technique de tolérance aux fautes qui combine les deux approches RNFR et LNFR sur la base d'une migration périodique. Dans ce modèle, nous faisons une abstraction de l'architecture de RMS en trois couches de base (couche haute, couche de matchmaking et couche basse). Basé sur cette architecture, un nouveau modèle de abilité du service de grille a été présenté. Ce modèle tient en compte tout le processus d'exécution d'une tâche, dès la soumission jusqu'à la récupération des résultats. La technique de tolérance aux fautes met en ÷uvre une nouvelle technique de migration, qui combine le RNFR et le LNFR, en sélectionnant le n÷ud le plus able parmi l'ensemble des collaborateurs voisins. Le processus de migration est périodique, ayant le MDTTR du n÷ud défaillant comme période, la migration continue jusqu'à la réparation du n÷ud défaillant ou la migration de toutes ses tâches.

Chapitre 6

Expérimentations

1 Introduction

Dans ce chapitre, nous allons présenter la mise en ÷uvre des modèles dénis dans les chapitres 3, 4 et 5. Le modèle hiérarchique dynamique est validé sous Globus Toolkit 4.0.1, en exploitant les PC's disponibles à l'Université de Mascara, ce qui nous a permis de créer un Dektop Grid de 15 n÷uds. En ce qui concerne le modèle de la grille mobile, les modèles décentralisés basés sur les graphes colorés dynamiques et le modèle able de tolèrance aux fautes, nous avons développé, pour chaque modèle, un simulateur pour valider les modèles correspondants.

2 Environnement d'évaluation

Comme environnement de test du modèle hiérarchique dynamique, nous avons utilisé Globus Toolkit [59]. Globus est un projet open source visant à créer des lo- giciels et des outils nécessaires pour la conception et la mise en ÷uvre de grilles de calcul. Il est principalement développé aux Etats-Unis dans l'Argonne National laboratory par l'équipe d'Ian Foster. Le travail sur Globus a commencé en 1997 et le projet est toujours actif. Le " Globus Toolkit " est formé d'un ensemble de composants. Son architecture modulaire permet d'apporter les modications et les améliorations d'une manière rapide et ecace. Globus est devenu le standard utilisé dans les projets grilles de calcul. Ainsi, de nombreuses entreprises l'ont adopté pour servir comme base de leurs produits commerciaux en terme de sécurité, de services d'information, de gestion des communications, de gestion des ressources et de trai- tement des données.

Fonctionnalités de Globus : Globus fournit les fonctionnalités et les services de base nécessaires pour la construction de grilles de calcul. Ainsi, nous trouvons des services et des mécanismes tels que la sécurité, la localisation et la gestion des res- sources, la communication, etc. [55].

Il est composé d'un ensemble de modules ayant chacun une interface, an que les 105

services de niveau supérieur puissent les invoquer pour développer leurs propres mo- dules.

Parmi ces modules, nous trouvons :

 Localisation et allocation des ressources : Ce composant permet aux applications d'exprimer leurs besoins en ressources et il fournit les mécanismes permettant d'identier les ressources adéquates.

 Communications : Ce composant donne la possibilité aux diérentes ap- plications de communiquer entre elles. Un certain nombre de paradigmes de communication sont fournis, comme communication par messages, mémoire distribuée, appel de procédure à distance, etc.

 Informations sur les ressources : Ce composant permet d'obtenir des infor- mations sur l'état et la structure globale du système du point de vue ressources.  Mécanismes de sécurité : Ce composant fournit les mécanismes d'authen-

tication et d'autorisation des utilisateurs.

 Accès aux données : Ce composant ore un accès consistant aux données stockées dans des chiers et des bases de données (Voir Tableau 6.1).

Service Nom Description

Gestion de ressources GRAM Allocation des ressources et gestion des processus Communications Nexus Services de communication unicast et multicast Sécurité GSI Authentication et autorisation

Informations d'état MDS Informations sur la structure et l'état de la grille Table 6.1  Diérents services de Globus

3

Modèle hiérarchique dynamique