Détecteurs de défaillances adaptables

1. Détecteurs de défaillancesadaptables 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. Introduction Techniques de détection • Applicatif (refus de services) • Pinging • Heatbeat p q p up D p up Détecteur sur q p down p q D p up p up Détecteur sur q p down

4. Introduction Qualité de service • Métriques • Temps de détection • Temps entre deux erreurs (TMR) • Durée des erreurs (TM) DF TM TMR 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 Hiérarchique Organisation • Organisation hiérarchique • Communication • IP-Multicast au niveau local • UDP au niveau global LAN 1 LAN 2 LAN 3

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

8. Organisation Hiérarchique Comportement LAN 2 S1.5 LAN 1 S2.1 S1.1 S1.5 S1.4 S1.5 S1.2 S1.2 S3.5 S1.5 S1.4 S1.3 LENT S1.5 LAN 3

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

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

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 Application 1 Application 2 Liste de suspects QoS 1 Liste de suspects QoS 2 Couche d’adaptation 1 Couche d’adaptation 2 i 2 i 1 Liste de sites suspects Intervalle d’émission Marge de détection QoS observée Couche de base Blackboard

12. Architecture • 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 1 Application 2 Liste de suspects QoS 1 Liste de suspects QoS 2 Couche d’adaptation 1 Couche d’adaptation 2 i 2 i 1 Liste de sites suspects Intervalle d’émission Marge de détection QoS observée Couche de base Blackboard

13. Architecture • 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 Application 1 Application 2 Liste de suspects QoS 1 Liste de suspects QoS 2 Couche d’adaptation 1 Couche d’adaptation 2 i 2 i 1 Liste de sites suspects Intervalle d’émission Marge de détection QoS observée Couche de base Blackboard

14. Architecture Couche de baseFonctionnement i hi-1 hi hi+1 hi+2 Processus p Processus q Ai to Freshness points: i-1 i i+1 i+2 FD de q

15. Architecture Couche de baseEstimation de la date d’arrivée • Calcul de la date butoir • Timeout (k+1)= date théorique (EAk+1) + marge dynamique (k+1) • Date théorique : estimation de Chen • Marge dynamique (algorithme de jacobson)

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

17. Performances couche d’adaptation 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 1 Paris Délai : 50ms +/- 10ms Perte de messages : 1.2% Délai : 10ms +/- 4ms Perte de messages : 0.5% Group 2 San Francisco Group 3 Toulouse Délai : 150ms +/- 25ms Perte de messages : 3%

18. Performances couche d’adaptation 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

19. Organisation à plat Leader en hiérarchique Non leader en hiérarchique Performances couche d’adaptation Organisation • Conditions: • i = 700ms

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 : http://www-src.lip6.fr/darx http://regal.lip6.fr/publi (DNS’2002 adaptation, DSN’2003 hiérarchie)

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

22. Performances couche de base Performances avec charge

23. Performances couche de base Performance • Adaptation : • Court terme (Marge) • Moyen terme (Estimation date) • Conclusion • Bon compromis entre temps de détection et le nombre de fausses détections