1 / 27

Réunion DataGraal 30-31 Janvier 2003 Grenoble

DataGRAAL. Réunion DataGraal 30-31 Janvier 2003 Grenoble. Tolérance aux fautes et passage à l’échelle Pierre Sens. Généralités sur la tolérance aux fautes. But : fournir des garanties de fiabilité en cas de défaillance

elliot
Download Presentation

Réunion DataGraal 30-31 Janvier 2003 Grenoble

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DataGRAAL Réunion DataGraal 30-31 Janvier 2003Grenoble 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 30-31 Janvier 2003

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

  4. Détection Large échelle 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 DataGraal – Grenoble 30-31 Janvier 2003

  5. Détection 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 30-31 Janvier 2003

  6. 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 • Active • Semi-active • Coordinateur-cohorte • Passive DataGraal – Grenoble 30-31 Janvier 2003

  7. 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 30-31 Janvier 2003

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

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

  10. Réplication 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 30-31 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 30-31 Janvier 2003

  12. 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 30-31 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 30-31 Janvier 2003

  14. Comparatif DataGraal – Grenoble 30-31 Janvier 2003

  15. Contrôle de réplication adaptatif Observation SMA Agent Adaptateur DARX Réplication Nommage/Localisation Détection de défaillances 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) DataGraal – Grenoble 30-31 Janvier 2003

  16. 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 30-31 Janvier 2003

  17. 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 30-31 Janvier 2003

  18. 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 G B sous-réseau 1 sous-réseau 2 sous-réseau 3 C H F D E DataGraal – Grenoble 30-31 Janvier 2003

  19. 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 30-31 Janvier 2003

  20. DARX - Détection Performances • Adaptation : • Court terme (Marge) • Moyen terme (date) DataGraal – Grenoble 30-31 Janvier 2003

  21. 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 30-31 Janvier 2003

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

  23. 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 30-31 Janvier 2003

  24. 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 30-31 Janvier 2003

  25. 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 30-31 Janvier 2003

  26. 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 30-31 Janvier 2003

  27. Performance sur application DataGraal – Grenoble 30-31 Janvier 2003

More Related