1 / 21

Détection de défaillances et algorithmes répartis pour les GRIDs

Détection de défaillances et algorithmes répartis pour les GRIDs. Marin BERTIER. Thèmes SRC Laboratoire d'Informatique de Paris 6 Université Pierre & Marie Curie. Introduction. Contexte. Développement des GRIDs Grand nombre de sites Organisé hiérarchique Niveau local  cluster

dalton-nielsen
Download Presentation

Détection de défaillances et algorithmes répartis pour les GRIDs

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. Détection de défaillances et algorithmes répartis pour les GRIDs Marin BERTIER Thèmes SRC Laboratoire d'Informatique de Paris 6 Université Pierre & Marie Curie

  2. Introduction Contexte • Développement des GRIDs • Grand nombre de sites • Organisé hiérarchique • Niveau local  cluster • Niveau Global  Inter-cluster • Dissymétrie des communications • cluster: Fiables et rapides • Inter-cluster: …

  3. Introduction Détection de défaillances • Impossibilité de résoudre le consensus dans un système asynchrone [FLP85] • Caractéristiques : • Fournissent une liste non fiable des processus suspectés d’être défaillants • Complétude : Un processus défaillant doit être considéré comme défaillant par les autres • Justesse : Un processus correct ne doit pas être considéré défaillant • Modèle partiellement synchrone (GTS)

  4. Introduction 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

  5. Introduction Qualité de service • Métriques • Temps de détection • Temps entre deux erreurs (TMR) • Durée des erreurs (TM) DF TM TMR Processus p up

  6. Détecteurs de défaillances • Fonctionnement « hearbeat » • Défaillances: • crash / ‘recovery’ • perte de messages • Adaptable : • Estimations dynamiques • Intervalle d’émission • Permet le transport d’information

  7. Organisation Hiérarchique Organisation • Organisation hiérarchique • Communication • IP-Multicast au niveau local • UDP au niveau global cluster 1 cluster 2 cluster 3

  8. Organisation Hiérarchique Niveaux Hiérarchiques • Visions: • Niveau Local : • Liste des sites du cluster • Niveau global : • Liste des clusters • Qualité de service différentes

  9. Organisation Hiérarchique Comportement cluster 2 S1.5 cluster 1 S2.1 S1.1 S1.5 S1.4 S1.5 S1.2 S1.2 S3.5 S1.5 S1.4 S1.3 LENT S1.5 cluster 3

  10. Organisation Hiérarchique Avantages / Désavantages • Avantages: • Nombre de messages (n: nb sites, k: nb groupes) • Système plat: n * (n -1) • Hiérarchique: n2 / k + k2 – k – 1 • Si n > k2 un leader gère moins de messages • Partitionnement des informations • Mise en place de mécanisme • Élection de leader

  11. Organisation Hiérarchique Election de leader • Sur le principe de  : • Liste triée de leaders non suspectés (Trusted_Process) • Leader : 1er de Trusted_Process • Objectifs : • Temps de recouvrement court • Avoir au moins un leader

  12. Architecture • Emission de message « I-am-alive » • Estimation de base • Compromis entre le temps de détection et le nombre de fausses détection • Fournit : • Liste de sites suspects • Informations sur la détection • Adaptation de l’intervalle d’émission Application 1 Application 2 Liste de suspects QoS 1 Liste de suspects QoS 2 Couche d’adaptation 1 Couche d’adaptation 2 i 2 i 1 Liste de sites suspects Intervalle d’émission Marge de détection QoS observée Couche de base Blackboard

  13. Architecture • Spécifique à l’application • Adapte la QoS • Différents algorithmes • Adaptation de l’interface • Pop ou Push • Permet différentes vision du système Application 1 Application 2 Liste de suspects QoS 1 Liste de suspects QoS 2 Couche d’adaptation 1 Couche d’adaptation 2 i 2 i 1 Liste de sites suspects Intervalle d’émission Marge de détection QoS observée Couche de base Blackboard

  14. Architecture • Représente l’utilisateur des détecteurs de défaillance : • Service de nommage • Fournir le besoin en QoS local • Utilise la liste des sites suspects Application 1 Application 2 Liste de suspects QoS 1 Liste de suspects QoS 2 Couche d’adaptation 1 Couche d’adaptation 2 i 2 i 1 Liste de sites suspects Intervalle d’émission Marge de détection QoS observée Couche de base Blackboard

  15. Architecture Couche de baseFonctionnement i hi-1 hi hi+1 hi+2 Processus p Processus q Ai to Freshness points: i-1 i i+1 i+2 FD de q

  16. Architecture Couche de baseEstimation de la date d’arrivée • Calcul de la date butoir • Timeout (k+1)= date théorique (EAk+1) + marge dynamique (k+1) • Date théorique : estimation de Chen • Marge dynamique (algorithme de jacobson)

  17. Architecture Adaptation du délai d’émission • Motivation : • Besoins variables des applications • Etat du réseau • Négocier entre récepteurs et l’émetteur

  18. Performances couche de base Performance • Adaptation : • Court terme (Marge) • Moyen terme (Estimation date) • Conclusion • Bon compromis entre temps de détection et le nombre de fausses détections

  19. Performances couche d’adaptation Plateforme de test • Utilisation de « dummynet » (simulateur reseau) • Introduction de délai de propagation • Variation du délai de propagation • Introduction de perte de messages Group 1 Paris Délai : 50ms +/- 10ms Perte de messages : 1.2% Délai : 10ms +/- 4ms Perte de messages : 0.5% Group 2 San Francisco Group 3 Toulouse Délai : 150ms +/- 25ms Perte de messages : 3%

  20. Organisation à plat Leader en hiérarchique Non leader en hiérarchique Performances couche d’adaptation Organisation • Conditions: • i = 700ms

  21. Conclusion • Service de détection de défaillances: • Scalable • Partagé • Adaptable • Fournissant une QoS locale

More Related