1
Détection et tolérance aux fautes dans JuxMem
Sébastien MonnetIRISA / PARIS
Lyon, 05/12/2003
2
Plan Justification JuxMem : l’existant
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 nœuds)
MTBF court (~ heure) Volatilité des nœuds
Déconnections volontaires Crash
Sécurité Fautes Byzantines
4
Architecture de JuxMem
Architecture hiérarchique
juxmem group
cluster A group
cluster B group
cluster C group
Data group
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 => multicast virtuel dans le groupe data Taux de réplication fixé par le client Perte d’une copie => création d’une nouvelle
copie
7
Améliorations Détection de fautes
Passage de centralisé à décentralisé Passage à un modèle hiérarchique
JuxMem : plate-forme d’expé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 d’un cluster : all-to-all Optimisations possibles
Entre les groupes cluster : leader-to-leader
Découplage Faute d’un pair : vue au niveau du cluster Disparition d’un 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 d’adaptation (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)
Semi-actives Active
111111
2
3
2
2
2
21
3
4
3
2
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
12 2
14
Réplication passive (perte de la copie primaire) Retrouver un état application /
données cohérent Retour arrière de l’application
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 l’application
12 2
15
Systèmes de quorums (1) Définition
S = ensemble de pairs Q = système de quorum Q = {qS/q1,q2Q, q1q2}
Exemple Quorums majoritaires
16
Systèmes de quorums (2) Principe
Système = groupe de pairs fournisseurs possédant une copie d’une donnée
Réplication active au sein d’un quorum
Une modification dans un quorum est visible dans l’ensemble des quorums
17
Systèmes de quorums (3) Avantage
|quorum|<|groupe de copies| Moins de copies à mettre à jour lors d’une é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 d’un 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 qu’un système de quorums1
3
42
4
5
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 l’application En fonction des données
d’introspection 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 l’application É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
26
juxmem group
cluster group
data group