Dtecteurs de dfaillances adaptables

1
Détecteurs de défaillances adaptables

• Marin BERTIER

Thèmes SRC Laboratoire d'Informatique de Paris
6 Université Pierre Marie Curie
2
Détection de défaillances
Introduction

• 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
Introduction

• Applicatif (refus de services)
• Pinging
• Heatbeat

p
q
D
p up
p up
Détecteur sur q
p down
p
q
D
p up
p up
Détecteur sur q
p down
4
Qualité de service
Introduction

• 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 dinformation

6
Organisation
Organisation Hiérarchique

• Organisation hiérarchique
• Communication
• IP-Multicast au niveau local
• UDP au niveau global

LAN 1
LAN 2
LAN 3
7
Niveaux Hiérarchiques
Organisation Hiérarchique

• Visions
• Niveau Local
• Liste des sites du LAN
• Niveau global
• Liste des LANs
• Qualité de service différentes

8
Comportement
Organisation Hiérarchique
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
Avantages / Désavantages
Organisation Hiérarchique

• 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 gt k2 un leader gère moins de messages
• Partitionnement des informations
• Mise en place de mécanisme
• Élection de leader

10
Election de leader
Organisation Hiérarchique

• 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 lintervalle démission

Application 1
Application 2
Liste de suspects
QoS 1
Liste de suspects
QoS 2
Couche dadaptation 1
Couche dadaptation 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 à lapplication
• Adapte la QoS
• Différents algorithmes
• Adaptation de linterface
• 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 dadaptation 1
Couche dadaptation 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
Application 1
Application 2

• Représente lutilisateur des détecteurs de
  défaillance
• Service de nommage
• Fournir le besoin en QoS local
• Utilise la liste des sites suspects

Liste de suspects
QoS 1
Liste de suspects
QoS 2
Couche dadaptation 1
Couche dadaptation 2
?i 2
?i 1
Liste de sites suspects Intervalle
démission Marge de détection QoS observée
Couche de base
Blackboard
14
Couche de baseFonctionnement
Architecture
?i
hi-1
hi
hi1
hi2
Processus p
Processus q
Ai
?to
?i
?i1
?i2
Freshness points
?i-1
FD de q
15
Couche de baseEstimation de la date darrivée
Architecture

• Calcul de la date butoir
• Timeout (?k1) date théorique (EAk1) marge
  dynamique (?k1)
• Date théorique estimation de Chen
• Marge dynamique (algorithme de jacobson)

16
Adaptation du délai démission
Architecture

• Motivation
• Besoins variables des applications
• Etat du réseau
• Négocier entre récepteurs et lémetteur

17
Plateforme de test
Performances couche dadaptation

• 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
Adaptateur
Performances couche dadaptation

• 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
Performances couche dadaptation

• 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
• (DNS2002 adaptation, DSN2003 hiérarchie)

21
Comportement de la détection
Performances couche de base
Initialisation
22
Performances avec charge
Performances couche de base
23
Performance
Performances couche de base

• Adaptation
• Court terme (Marge)
• Moyen terme (Estimation date)
• Conclusion
• Bon compromis entre temps de détection et le
  nombre de fausses détections