1 Détecteurs de défaillances adaptables Marin BERTIER Thèmes SRC Laboratoire d'Informatique de Paris 6 Université Pierre & Marie Curie

2 Introduction Détection de défaillances ► Impossibilité de résoudre le consensus dans un système asynchrone [FLP85] ► Caractéristiques :  Fournissent une liste non fiable des processus suspectés d’être défaillants  Complétude : Un processus défaillant doit être considéré comme défaillant par les autres  Justesse : Un processus correct ne doit pas être considéré défaillant ► Modèle partiellement synchrone (GTS)

3 Techniques de détection ► Applicatif (refus de services) ► Pinging ► Heatbeat  Détecteur sur q p up p down p up p q  Détecteur sur q p up p down p up p q Introduction

4 Qualité de service ► Métriques  Temps de détection  Temps entre deux erreurs (T MR )  Durée des erreurs (T M ) Introduction DF TMTM T MR Processus p up

5 Détecteurs de défaillances ► Fonctionnement « hearbeat » ► Défaillances:  crash / ‘recovery’  perte de messages ► Adaptable :  Estimations dynamiques  Intervalle d’émission ► Permet le transport d’information

6 Organisation ► Organisation hiérarchique ► Communication  IP-Multicast au niveau local  UDP au niveau global LAN 1 LAN 3 LAN 2 Organisation Hiérarchique

7 Niveaux Hiérarchiques ► Visions:  Niveau Local : ► Liste des sites du LAN  Niveau global : ► Liste des LANs ► Qualité de service différentes Organisation Hiérarchique

8 Comportement S 1.1 S 1.5 S 1.2 S 1.4 S 1.3 S 1.2 S 2.1 S 3.5 LAN 1 LAN 2 LAN 3 LENT S1.5 S1.4 S1.5 Organisation Hiérarchique

9 Avantages / Désavantages ► Avantages:  Nombre de messages (n: nb sites, k: nb groupes) ► Système plat: n * (n -1) ► Hiérarchique: n 2 / k + k 2 – k – 1 ► Si n > k 2 un leader gère moins de messages ► Partitionnement des informations ► Mise en place de mécanisme  Élection de leader Organisation Hiérarchique

10 Election de leader ► Liste triée de leaders ► Leader suspecté par une majorité changement de leader changement de leader Organisation Hiérarchique

11 Architecture ► Emission de message « I-am-alive » ► Estimation de base  Compromis entre le temps de détection et le nombre de fausses detection ► Fournit :  Liste de sites suspects  Informations sur la détection ► Adaptation de l’intervalle d’émission Couche de base Blackboard Liste de sites suspects Intervalle d’émission Marge de détection QoS observée Couche d’adaptation 1Couche d’adaptation 2 Application 1Application 2 QoS 1 QoS 2 Liste de suspects Liste de suspects  i 1  i 2

12 Architecture Couche de base Blackboard Liste de sites suspects Intervalle d’émission Marge de détection QoS observée Couche d’adaptation 1Couche d’adaptation 2 ► Spécifique à l’application ► Adapte la QoS  Différents algorithmes ► Adaptation de l’interface  Pop ou Push ► Permet différentes vision du système Application 1Application 2 QoS 1 QoS 2 Liste de suspects Liste de suspects  i 1  i 2

13 Architecture Couche de base Blackboard Liste de sites suspects Intervalle d’émission Marge de détection QoS observée Couche d’adaptation 1Couche d’adaptation 2 Application 1Application 2 QoS 1 QoS 2 Liste de suspects Liste de suspects  i 1  i 2 ► Représente l’utilisateur des détecteurs de défaillance :  Service de nommage ► Fournir le besoin en QoS local ► Utilise la liste des sites suspects

14 Couche de base Fonctionnement Architecture Processus q FD de q Processus p h i-1 hihi h i+1 h i+2 ii ii  i+1  i+2 Freshness points:  i-1 AiAi  to

15 Couche de base Estimation de la date d’arrivée ► Calcul de la date butoir  Timeout ()= date théorique (EA k+1 ) + marge dynamique (  k+1 )  Timeout (  k+1 )= date théorique (EA k+1 ) + marge dynamique (  k+1 ) ► Date théorique : estimation de Chen ► Marge dynamique (algorithme de jacobson) Architecture

16 Adaptation du délai d’émission ► Motivation :  Besoins variables des applications  Etat du réseau ► Négocier entre récepteurs et l’émetteur Architecture

17 Plateforme de test ► Utilisation de « dummynet » (simulateur reseau)  Introduction de délai de propagation  Variation du délai de propagation  Introduction de perte de messages Group 3 Toulouse Group 2 San Francisco Group 1 Paris Délai : 50ms +/- 10ms Perte de messages : 1.2% Délai : 10ms +/- 4ms Perte de messages : 0.5% Délai : 150ms +/- 25ms Perte de messages : 3% Performances couche d’adaptation

18 Adaptateur ► Adaptateur 1: Réévaluation de la marge périodiquement ► Adaptateur 2: Réévaluation de la marge à chaque fausse détection ► Expérimentation: durée 32h, intervalle 1000ms Détecteur Adaptateur 1 Adaptateur 2 Durée totale Temps détection 1216,12089,92311,9 Nb fausses détection 4368 Durée des erreurs 1100,6272,5101,4 Initialisation Temps détection 1113,21749,31351,9 Nb fausses détection 854 Durée des erreurs 953,2339,3529,1 Performances couche d’adaptation

19 Organisation ► Conditions:   i = 700ms Nb de sites Nb de sites par groupe local Nb de groupes local Organisation à plat Leader en hiérarchique Non leader en hiérarchique Performances couche d’adaptation

20 Conclusion et perspectives ► Service de détection de défaillances:  Scalable  Partagé  Adaptable  Fournissant une QoS locale ► Perspectives  Gestion du partitionnement  Utilisation pour un service de nommage  Application de gestion de verrou ► Web : (DNS’2002 adaptation, DSN’2003 hiérarchie)

21 Comportement de la détection Initialisation Performances couche de base

22 Performances avec charge Performances couche de base

23 Performance ► Adaptation :  Court terme (Marge)  Moyen terme (Estimation date) ► Conclusion  Bon compromis entre temps de détection et le nombre de fausses détections DynamiqueRTTChen Nb fausses détections Durée erreurs (ms) 31,625,2336,61 Temps de détection (ms) 5131,75081,795672,53 Performances couche de base