Détection et tolérance 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 : 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. juxmem group Data group cluster A group cluster C group cluster B group 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 => 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) 2 3 2 3 2 1 1 1 2 2 1 1 2 3 1 4 1 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 2 1

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 2 2 1

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 5 4 3 2 4 1

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

26. juxmem group data group cluster group