La validation 2 phases

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