Réunion DataGraal Janvier 2003 Grenoble

Présentation au sujet: "Réunion DataGraal Janvier 2003 Grenoble"— Transcription de la présentation:

1 Réunion DataGraal 30-31 Janvier 2003 Grenoble
Tolérance aux fautes et passage à l’échelle Pierre Sens

2 Généralités sur la tolérance aux fautes
But : fournir des garanties de fiabilité en cas de défaillance permettre la continuité de l'exécution lorsque l'un des nœuds ne répond plus Types de fautes Détection de fautes Traitement des fautes : Réplication Exemple : DARX DataGraal – Grenoble Janvier 2003

3 DataGraal – Grenoble 30-31 Janvier 2003
Types de fautes Franche (fail-silent, crash) Arrêt permanent Omission (recovery) Transitoire Temporaire Trop tôt ou trop tard Byzantin malicieux DataGraal – Grenoble Janvier 2003

4 Problèmatique de la détection
Très dépendant du modèle temporel Réseau synchrone : délai de transmission / traitement borné et connus Détection sûre => Fournir une liste de site en panne Réseau asynchrone : pas de délai Consensus impossible [Fisher Lynch Paterson 85] Partiellement synchrone : délais bornés inconnus Pas de solution exacte Détecteurs de fautes non fiables [Chandra Toueg 94] => Fournir une liste de suspects Large échelle DataGraal – Grenoble Janvier 2003

5 Techniques de détection
Applicatif (refus de services) Pinging Heatbeat p q p up D p up Détecteur sur q p down p q D p up p up Détecteur sur q p down DataGraal – Grenoble Janvier 2003

6 DataGraal – Grenoble 30-31 Janvier 2003
Réplication La réplication : méthode de base pour la sûreté de fonctionnement délais de recouvrement relativement courts 2 principaux mécanismes (stratégies) de réplication : Active Semi-active Coordinateur-cohorte Passive DataGraal – Grenoble Janvier 2003

7 DataGraal – Grenoble 30-31 Janvier 2003
Réplication Réplication active S1 S2 S3 requête réponse C Adapté au temps réel : erreurs masquées Traite les fautes byzantines Serveurs déterministes DataGraal – Grenoble Janvier 2003

8 Réplication semi-active
notification S2 S3 requête réponse C Recouvrement rapide Fautes franches DataGraal – Grenoble Janvier 2003

9 DataGraal – Grenoble 30-31 Janvier 2003
Réplication Réplication passive S1 sauvegarde S2 S3 requête réponse C Temps de recouvrement important Possibilité de non-déterminisme Fautes franches DataGraal – Grenoble Janvier 2003

10 Comparaison des stratégies de réplication
Actives Surcoût élevé Degré de réplication N => multiplication des coûts par N Très bon recouvrement Passive Surcoût moins élevé La mise à jour des réplicats s'effectue indépendamment du calcul Recouvrement plus hasardeux Les traitements survenus depuis la dernière sauvegarde sont perdus => solutions de recouvrement plus coûteuses Choix de la stratégie Se fait en fonction des contraintes et des besoins applicatifs active : fortes contraintes de temps, défaillances fréquentes, … passive : exécution non-déterministe, beaucoup de communication, … DataGraal – Grenoble Janvier 2003

11 Point de reprise (checkpointing)
Sauvegardes régulières sur supports stables Nombreux algorithmes, 2 approches Points de reprise coordonnés Sauvegarde d’un état global cohérent Pose de point de reprise coûteux Pas de contrôle de sauvegarde Recouvrement lent Points de reprise indépendant Assurer la cohérence => effet domino Journalisation de message => reprise confinée, coût des communication DataGraal – Grenoble Janvier 2003

12 DataGraal – Grenoble 30-31 Janvier 2003
Constats La plupart des plates-formes sont peu adaptées au large échelle Eloignement => Forte latence des protocoles à 3 phase Nombre de sites => Coût en ressources (réseau) Dynamicité => Approche statique (stratégie figée ou guidée par l'utilisateur) Topologie => Partitionnement Modèle de faute restreint (crash, recovery) Tendance à élargir vers fautes byzantines (dans P2P) Outils : librairie BFT, pb très coûteux ! DataGraal – Grenoble Janvier 2003

13 Réplication dans systèmes P2P
Réplication complète de données immutables (PAST) Réplication de données modifiables par peu d’ecrivain (Ivy) Réplication avec information redondante(type RAID) OceanStore N3FS (Turin) DataGraal – Grenoble Janvier 2003

14 DataGraal – Grenoble 30-31 Janvier 2003
Comparatif DataGraal – Grenoble Janvier 2003

15 Expérience de passage à l’échelle au LIP6
Projet DARX : Plate-forme pour système multi-agents Equipe OASIS (S. Aknine, JP Briot, Z. Guessoum) Equipe SRC (M. Bertier, O. Marin, P. Sens) Agent Adaptateur Réplication Détection de défaillances Contrôle de réplication adaptatif Observation DARX SMA Nommage/Localisation DataGraal – Grenoble Janvier 2003

16 DataGraal – Grenoble 30-31 Janvier 2003
DARX Approche Rendre la tolérance aux fautes dynamique & personnalisée Qualité de service exprimée par l ’agent (criticité, nombre et type de fautes acceptés, ...) + Observation de l ’évolution de l ’environnement (latence, temps d’accès, taux de fautes, ...) Adaptation aux contraintes dynamiques de l’environnement Domaines applicatifs visés Simulation à large échelle Qualité de service dynamique : gestion de crise (exemple : nuage toxique) Collecte d’information à large échelle Domotique Stratégie au runtime DataGraal – Grenoble Janvier 2003

17 Détection de défaillances
DARX Détection de défaillances Contrôle de réplication adaptatif Observation SMA Agent Adaptateur DARX Réplication Nommage/Localisation Détection de défaillances DataGraal – Grenoble Janvier 2003

18 Organisation des détecteurs de défaillances
DARX - Détection Organisation des détecteurs de défaillances But S’abstraire des problèmes de synchronisme Optimiser le temps de recouvrement Organisation hiérarchique Un module de nommage par site et un module de détection A B G sous-réseau 1 sous-réseau 2 C sous-réseau 3 H F D E DataGraal – Grenoble Janvier 2003

19 DataGraal – Grenoble 30-31 Janvier 2003
DARX - Détection Fonctionnement Diffusion de « heartbeats » Défaillances : Crash / Recovery Composé de 2 couches : Détection de base Adaptation de la qualité de service à l’application Adaptable : Estimations dynamiques Intervalle d’émission Utilisation d’IP-multicast Permet le transport d’information DataGraal – Grenoble Janvier 2003

20 Performances DARX - Détection Détection Darx RTT Chen 24 54 29 31,6
Fausses détections 24 54 29 Durée d’erreur (ms) 31,6 25,23 36,61 Temps de détection (ms) 5131,7 5081,79 5672,53 Adaptation : Court terme (Marge) Moyen terme (date) DataGraal – Grenoble Janvier 2003

21 Expérimentation à large échelle
DARX - Détection Expérimentation à large échelle Utilisation de dummynet pour simuler la latence réseau LAN 2 LAN 3 LAN 1 Ajout latence Perte DataGraal – Grenoble Janvier 2003

22 Comparaison Hiérarchique / Plat
DARX - Détection Comparaison Hiérarchique / Plat 60 ms 20 ms 80 ms DataGraal – Grenoble Janvier 2003

23 Nommage/Localisation
DARX - Réplication Réplication Contrôle de réplication adaptatif Observation SMA Agent Adaptateur DARX Réplication Nommage/Localisation Détection de défaillances DataGraal – Grenoble Janvier 2003

24 Stratégies de réplication
DARX - Réplication Stratégies de réplication 4 stratégies de réplication: active tous les réplicats traitent les requêtes passive seul le réplicat primaire traite les requêtes semi-active comme active, mais un seul réplicat répond quorum réduction du nombre de copies à jour DataGraal – Grenoble Janvier 2003

25 DataGraal – Grenoble 30-31 Janvier 2003
DARX - Réplication Dynamicité A tout moment l’agent peut : Ajouter/retirer un réplicat Changer la stratégie Changer les mécanismes internes (Modifier la fréquence de mise à jour des copies ...) Stratégies hybrides DataGraal – Grenoble Janvier 2003

26 DataGraal – Grenoble 30-31 Janvier 2003
Philosophes Philosophes Table = 1 agent répliqué activement Philosophe = agent à 3 états : Stateless : Philosophe pense Localstate : Philosophe demande les couverts Globalstate : Philosophe possède les couverts et mange DataGraal – Grenoble Janvier 2003

27 Performance sur application
DataGraal – Grenoble Janvier 2003