1 Détection et tolérance aux fautes dans JuxMem Sébastien Monnet IRISA / 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 (~ 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 groupcluster 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) PingHeartbeat  

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

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 = {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 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 quorums

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