1 / 95

La validation 2 phases

La validation 2 phases. Travail d'étude et de recherche, DESS TNI 2000/2001 Andréani Xavier, Boulat Eric, Haderer Gauthier. Présentation des systèmes distribués. Définition

alexis
Download Presentation

La validation 2 phases

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. La validation 2 phases Travail d'étude et de recherche, DESS TNI 2000/2001 Andréani Xavier, Boulat Eric, Haderer Gauthier

  2. Présentation des systèmes distribués • Définition • Un système distribué se constitue d'un ensemble de sous-systèmes informatiques interconnectés coordonnés par un système maître.

  3. Quelques exemples... • Un processeur central (CPU) de micro-ordinateur • Un serveur de calcul distribué (cluster) • Un SGBDR réparti

  4. Votre microprocesseur est un« micro système distribué »! • La plupart des processeurs ont plusieurs unités de calcul ! • Ces dernières travaillent en parallèle. • L'exécution d'une tâche est répartie au coeur du processeur mais de l'extérieur on ne voit qu'un seul acteur.

  5. Les serveurs de calcul, l'union fait la force... • Un ordinateur pour répartir la tâche de calcul, sur les autres ordinateurs. • Utilisation de tout un ensemble d'ordinateurs, mais tout se passe comme si l'on restait en local. • Utilisé pour tout types de calcul long comme : • rendu de scène en trois dimension (Titanic !) • Décryptage (seti@home)

  6. Les S.G.B.D.R répartis, ou comment se passer des bottes de sept lieues. • SGBDR+SGBDR = SGBDR ! • Accés en plusieurs points grâce à de multiples vues. • Le SGBDR global, coopérera avec les autres SGBDR distants pour obtenir le résultat demandé.

  7. Problèmes rencontrés pour gérer les systèmes distribués • La tâche globale n'est accomplie que si toutes les sous-tâches l'ont été ! • Comment savoir qu'un sous-système a terminé sa tâche ? • Que faire si un des sous-systèmes tombe en panne ? • Que faire si des messages se perdent entre le système coordinateur et les sous-systèmes.

  8. Définition d'une transaction • Une transaction, au sein d'un système informatique, est une série d'actions qui vérifie les propriétés suivantes : • A pour Atomicité. • C pour Cohérence. • I pour Isolation. • D pour Durabilité.

  9. Atomicité • Les changements d'états sont atomiques : • L'exécution d'une transaction ne laisse pas apparaître d'états intermédiaires. • Tout ou rien (Valide/abandon)

  10. Cohérence • La transaction fait passer la base d'un état cohérent à un autre état cohérent de la base. • La transaction doit donc être un programme correct par rapport à la base.

  11. Isolation • Même si des transactions s'exécutent de manière concurrente, de l'extérieur tout doit apparaître comme si elles s'exécutaient en série. • L'isolation est nécessaire pour garantir une entrée cohérente, nécessaire pour que des programmes cohérents aient des sorties cohérentes.

  12. Durabilité • Une fois la transaction terminée avec succés (validée), les changements doivent avoir été sauvés sur un support durable. • La seule manière de se débarasser de ce qu'a fait une transaction validée et de faire la transaction inverse (ce qui parfois est impossible).

  13. Problèmes au sein d'un système distribué • Atomicité : Les données doivent être validées sur tout les sites ou sur aucun => Protocole à prévoir. • Cohérence : le système global doit s'assurrer que l'on s'est arrêté dans un état cohérent. • Isolation : Gestion des exécutions concurrentes. • Durabilité : Les données doivent être écrites sur support durable sur tous les sites.

  14. Garantie de l'atomicité et de la durabilité • Chaque sous système doit préparer son écriture dans un cache et ne les écrire définitivement que lorsqu'on lui demandera. Ceci permet de garantir l'atomicité locale et globale. • Il faut que l'ordre de valider soit ordonné que si tout les sous systèmes prétendent être aptes à valider. • Problème en cas de perte de messages.

  15. Le protocole de validation 2 phases : 2PC • Présentation • Fonctionnement général • Fiabilité • Critique du protocole • Améliorations possibles

  16. Présentation • Coordonne la validation de transactions sur les systèmes distribués • Garantit l'atomicité d'une transaction même en cas de pannes • Utilisé avec succès depuis les années 80 • Pas de normalisation : implémentations propriétaires

  17. Fonctionnement général • Hypothèses de fonctionnement • Algorithme simplifié • Gestion des pertes de messages • Gestion des pannes • « Preuve » de correction de l'algorithme

  18. Hypothèses de fonctionnement • Le système est composé de noeuds indépendants reliés par un réseau • Un des noeuds est le coordinateur • Les autres sont les participants (cohorts) • Aucun noeud ne reste en panne indéfiniment • Chaque noeud dispose d'un support de stockage fiable

  19. Participant Participant Noeuds Réseau Coordinateur Participant Application Participant Figure 1 - Organisation d'un système distribué pour 2PC

  20. Algorithme simplifié • L'application initiatrice de la transaction demande au coordinateur de la valider • Le coordinateur valide la transaction en 2 phases • 1ère phase : le vote • 2ème phase : la validation

  21. 1ère phase : le vote • Le coordinateur envoie un message « commit request » à chaque participant • Puis, il attend les réponses • Chaque participant renvoie « commit vote » si la transaction a réussi et « abort vote » sinon

  22. 2ème phase : la validation • Si tous les participants ont envoyé un « commit vote », le coordinateur leur envoit un message « commit » • Sinon, le coordinateur envoit un message « abort » à tous ceux qui ont envoyé un « commit vote » • Puis, il attend les acquittements des participants

  23. 2ème phase : la validation (2) • Sur réception de « abort » ou « commit », chaque participant termine la transaction • Puis, il envoie un acquittement au coordinateur

  24. Commit request Commit request Commit vote Commit vote Commit Commit Ack Ack Figure 2 - Transaction validée Coordinateur Participant 1 Participant 2

  25. Commit request Commit request Commit vote Abort vote Abort Ack Figure 3 - Transaction annulée Coordinateur Participant 1 Participant 2

  26. Gestion des pertes de messages • Perte du « commit request » • Perte du vote • Perte du message de validation ou d'annulation • Perte de l'accusé de réception

  27. Perte du « commit request » • Avant envoi, le coordinateur arme un temporisateur • Le message se perd • Le temporisateur se déclenche • Le coordinateur peut : • Renvoyer le « commit request » à ceux qui n'ont pas voté • Passer à la phase 2 (envoi de « abort »)

  28. Temporisateur armé Commit request Commit request Time out Commit vote Abort Temporisateur désarmé Abort Ack Ack Figure 4 - 1er cas de perte d'un « commit request » Coordinateur Participant 1 Participant 2

  29. Perte du « commit request » (2) • Chaque participant arme un temporisateur lorsqu'il est prêt à valider • S'il n'a pas reçu de « commit request » avant expiration du temporisateur, il annule la transaction

  30. Temporisateur armé Commit request Commit request Time out Time out Commit vote La transaction est annulée Abort Abort Ack Ack Figure 5 - 2nd cas deperte d'un « commit request » Coordinateur Participant 1 Participant 2

  31. Perte du vote • Côté coordinateur : même gestion que pour la perte du « commit request » • Côté participant : • Avant d'envoyer son vote, il arme un temporisateur • S'il expire avant de recevoir le résultat du vote, il envoie une demande au coordinateur pour connaître le résultat du vote : bloquant

  32. Commit Request Commit request Temporisateur armé Commit vote Time out Commit vote Time out Abort Abort Vote? Ack Ack Abort Ack Figure 6 - Perte d'un vote Coordinateur Participant 1 Participant 2

  33. Perte du résultat du vote • Côté coordinateur : • Il arme un temporisateur avant l'envoi du résultat du vote • Il envoie le résultat du vote et attend l'acquittemement • Le messsage se perd et le temporisateur expire • Il renvoie le résultat • Côté participant : même gestion que la perte du vote

  34. Commit Request Commit request Commit vote Commit vote Temporisateur armé Commit Commit Time out Ack Commit Temporisateur désarmé Ack Figure 7 - perte du résultat du vote Coordinateur Participant 1 Participant 2

  35. Perte de l'accusé de réception • Côté coordinateur : même gestion que la perte du résultat du vote • Côté participant : aucune mesure prise

  36. Commit request Commit request Commit vote Commit vote Commit Commit Time out Ack Ack Commit Ack Figure 8 - Perte d'un acquittement Coordinateur Participant 1 Participant 2

  37. Gestion des pannes • Panne du coordinateur • Panne d'un participant • Panne du réseau

  38. Panne du coordinateur • Avant l'envoi du « commit request » : la transaction est annulée • Avant l'envoi du résultat du vote : • Les participants qui ont voté « commit » attendent la reprise du coordinateur pour connaître le résultat du vote : ils sont bloqués • Ceux qui ont voté « abort » ont déjà annulé la transaction • Ceux qui n'ont pas voté peuvent annuler la transaction

  39. Panne du coordinateur (2) • Avant réception de tous les acquittements : après la reprise, il renvoie le résultat du vote aux participants pour lesquels il n'a pas reçu d'acquittement • Après réception des acquittements : la transaction est déjà validée

  40. Panne d'un participant • Avant l'envoi du vote : la transaction sera annulée • Après l'envoi du vote : • « commit vote » : après reprise, le participant demandera le résultat du vote et terminera la transaction • « abort vote » : après reprise, ne fait rien car le gestionnaire de reprise a déjà annulé la transaction

  41. Panne d'un participant (2) • Avant l'envoi de l'accusé de réception : le coordinateur renverra le résultat du vote qui provoquera l'envoi d'un nouvel acquittement

  42. Panne du réseau • Pour le coordinateur, tous les participants semblent en panne. Si un « commit » ou « abort » a déjà été envoyé, il le renverra jusqu'à obtenir un acquittement. Sinon, la transaction est annulée • Pour un participant, le coordinateur semble en panne. Un participant qui déjà voté est bloqué. Sinon, la transaction est annulée

  43. « Preuve » de correction de l'algorithme 1. Si un participant valide la transaction, tous la valident 2. Si un participant annule la transaction, tous l'annulent

  44. Q1 « commit_request » envoyé à tous les participants. Un ou plusieurs participants ont répondu « abort ». « Abort » est envoyé à tous les participants. W1 F Tous les particpants ont accepté. Envoie « commit » à tous les participants. C1 A1 T,F A1 - état d'acceptation C1 - état de validation Q1 - état de demande W1 - état d'attente T Time-out Failure F Figure 9 - Diagramme d'états finis du protocole de validation pour le coordinateur

  45. Qi « commit request » reçu. « abort vote » envoyé au coordinateur « commit request » reçu. « commit vote » envoyé au coordinateur T,F Wi Ai « abort » reçu du coordinateur « commit » reçu du coordinateur A? - état d'acceptation C? - état de validation Q? - état de demande W? - état d'attente Ci Time-out Failure T F Figure 10 - Diagramme d'états finis du protocole de validation pour les participants (i=2,3,...,n)

  46. « Preuve » de correction de l'algorithme (2) Preuve de 1. : 1. le participant valide la transaction, donc message « commit » reçu 2. or, « commit » envoyé uniquement quand coordinateur dans l'état C1 3. donc, tous les participants ont envoyé un « commit vote » : mesures prises pour valider la transaction même après une panne (données en mémoire permanente)

  47. « Preuve » de correction de l'algorithme (3) 4. le coordinateur termine la transaction quand il a reçu tous les AR. Donc, tous les participants ont validé la transaction : une panne ne remet pas en cause la validation (fiabilité) 5. donc, si un participant valide alors tous ont validé Idem pour 2.

  48. Fiabilité • Définition • La base de données du protocole • La journalisation • Optimisation de la fiabilité

  49. Définition • Capacité à restaurer un système dans un état connu comme correct après une erreur quelconque • Pour la validation sur un système réparti, il faut s 'assurer qu'une panne ne remette pas en cause la validation sur l'un des noeuds

  50. La base de données du protocole • Présentation • Organisation interne • Utilisation

More Related