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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Performance sur application DataGraal – Grenoble 30-31 Janvier 2003