Dtection et tolrance aux fautes dans JuxMem

1
Détection et tolérance aux fautes dans JuxMem

• Sébastien Monnet
• IRISA / PARIS
• Lyon, 05/12/2003

2
Plan

• Justification
• JuxMem lexistant
• Détection de défaillances
• Stratégies de réplication
• JuxMem objectifs
• Détection de défaillances
• Stratégies de réplication
• Implémentation en JXTA
• Objectifs à court terme

3
Tolérance aux fautes justification

• Large échelle (100 000 nuds)
• MTBF court ( heure)
• Volatilité des nuds
• Déconnections volontaires
• Crash
• Sécurité
• Fautes Byzantines

4
Architecture de JuxMem

• Architecture hiérarchique

5
Tolérance aux fautes dans le groupe cluster

• Détection
• Ping (offert par JXTA)
• Réplication semi-active du rôle de gestionnaire
• Taux de réplication fixe (2)
• Un gestionnaire principal
• Un gestionnaire secondaire

6
Tolérance aux fautes dans le groupe data

• Détection de fautes
• Ping (comme pour le groupe cluster)
• Réplication semi-active du rôle de gestionnaire
  (comme pour le groupe cluster)
• Réplication active des données
• Écriture gt multicast virtuel dans le groupe data
• Taux de réplication fixé par le client
• Perte dune copie gt création dune nouvelle
  copie

7
Améliorations

• Détection de fautes
• Passage de centralisé à décentralisé
• Passage à un modèle hiérarchique
• JuxMem plate-forme dexpérimentation pour
  plusieurs stratégies de réplications

8
Détection de défaillances Heartbeats

• Encombrement réseau moins important
• Détection plus fine
• Calcul du  delta  dynamique, (Marin Berthier,
  REGAL)
• Prise en compte des n derniers heartbeats reçus
  (historique)
• Prise en compte de la charge réseau
• Introspection (Fabio Picconi, REGAL)

?
?
Ping
Heartbeat
9
Détection de défaillances un modèle
hiérarchique (DARX)

• Décentralisé
• Au sein dun cluster all-to-all
• Optimisations possibles
• Entre les groupes cluster leader-to-leader
• Découplage
• Faute dun pair vue au niveau du cluster
• Disparition dun cluster vue par tous les
  leaders

10
Compromis réactivité / taux de fausses détections

• Permettre un choix entre
• Bonne réactivité et
• Faible taux de fausses détections
• Couche dadaptation (filtrage des détections de
  défaillance)
• En fonction du type de réplication
• En fonction de la criticité du rôle du pair
  (gestionnaire / simple fournisseur)

11
Réplication active principe

• Pessimiste
• Mise à jour simultanée de toutes les copies
• Acquittements reçus
• Directement par le client (active)
• Via un gestionnaire (semi-active)

2
3
2
3
2
1
1
1
2
2
1
1
2
1
3
1
4
Active
Semi-actives
12
Réplication active (suite)

• Avantages
• Toutes les copies sont à jour
• Possibilité de lectures parallèles sur un
  ensemble de copies
• Bonne localité des données
• Inconvénients
• Écriture lentes
• Encombrement réseau

13
Réplication passive

• Principe
• Optimiste
• Une copie primaire
• Des copies secondaires (backups)
• Avantages
• Écritures rapides (une seule copie à mettre à
  jour)
• Inconvénients
• Pas de lecture en parallèle
• Moins de localité des données
• Possibilité de perdre la copie primaire

2
1
2
14
Réplication passive (perte de la copie primaire)

• Retrouver un état application / données cohérent
• Retour arrière de lapplication
• Besoin de mécanismes de points de reprise
• Rejouer les modifications intervenue après le
  dernier backup
• Besoin de journalisation pessimiste
• Nécessité de geler lapplication

2
1
2
15
Systèmes de quorums (1)

• Définition
• S ensemble de pairs
• Q système de quorum
• Q q?S/?q1,q2?Q, q1?q2??
• Exemple
• Quorums majoritaires

16
Systèmes de quorums (2)

• Principe
• Système groupe de pairs fournisseurs possédant
  une copie dune donnée
• Réplication active au sein dun quorum
• Une modification dans un quorum est visible dans
  lensemble des quorums

17
Systèmes de quorums (3)

• Avantage
• quorumltgroupe de copies
• Moins de copies à mettre à jour lors dune
  écriture
• Écritures plus rapides
• Possibilité de conserver une bonne localité
• Construction du système de quorum
• Jean-Michel Busca (REGAL)
• Inconvénients
• Coût de la construction et du maintien du système
  de quorum
• Multiples versions de la donnée au sein dun même
  quorum
• Lectures lentes (phase de sélection de la version)

18
Stratégies hybrides

• Possibilité de  mixer  les stratégies de
  réplication
• Gros grain une stratégie par groupe data
• Criticité de la donnée
• Grain fin pour une même donnée
• Recherche de performances
• Intérêt tirer parti des avantages des
  différentes stratégies

19
Stratégies hybrides exemple

• Active / passive
• Plusieurs copies actives
• Copies secondaires en cas de nombreuses fautes
  multiples
• Avantages
• Peu de copies à mettre à jour en cas décriture
• Plus simple à mettre en uvre quun système de
  quorums

5
4
3
2
1
4
20
Exemple de stratégie hybride dans JuxMem

• Active / passive
• Copies actives placées dans les clusters où un
  client utilise la donnée
• Copies secondaires dans les autres

21
Adaptation de la stratégie de réplication

• En fonction des  conseils  donnés par
  lapplication
• En fonction des données dintrospection
• Charge réseau
• Taux de défaillances (MTBF) courant

22
Objectifs dans JuxMem

• Une plate-forme implémentant différentes
  stratégies de réplication
• Mise en place de mécanismes de choix de politique
  de tolérance aux défaillances
• Des préférences de lapplication
• État du système (introspection)

23
Implémentation avec JXTA

• Détecteurs de défaillance
• Utilisation des  lease  de JXTA
• Équivalence  lease  / heartbeats
• A quel niveau ?
• Groupes data
• Groupes JXTA
• Systèmes de quorums et stratégies mixtes
• Sous groupes des groupes data
• Utilisation de groupes  légers  de JXTA 2.2

24
Et maintenant ?

• Détecteurs de défaillances
• Définir une interface
• Implémentation et intégration dans JuxMem
• Sélection des stratégies de réplication
• Définir une interface
• Implémenter plusieurs stratégies
• Actif ?
• Hybride actif / passif ?
• Quorums ?
• Liens avec les protocoles de cohérence
• Stage de DEA de JF Deverge

25
(No Transcript)
26
juxmem group
data group
cluster group