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