La validation 2 phases

La validation 2 phasesLa validation 2 phases

Travail d'étude et de recherche, DESS TNI2000/2001

Andréani Xavier, Boulat Eric, Haderer Gauthier

Présentation des systèmes Présentation des systèmes distribuésdistribué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.

Quelques exemples...Quelques exemples...

Un processeur central (CPU) de micro-ordinateur Un serveur de calcul distribué (cluster) Un SGBDR réparti

Votre microprocesseur est unVotre microprocesseur est un« micro système distribué »!« 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.

Les serveurs de calcul, Les serveurs de calcul, l'union fait la force...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)

Les S.G.B.D.R répartis, ou Les S.G.B.D.R répartis, ou comment se passer des bottes de comment se passer des bottes de

sept lieues.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é.

Problèmes rencontrés Problèmes rencontrés pour gérer les systèmes distribuéspour 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.

Définition d'une transactionDé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é.

Atomicité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)

CohérenceCohé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.

IsolationIsolation

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.

Durabilité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).

Problèmes au sein Problèmes au sein d'un système distribué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.

Garantie de l'atomicité Garantie de l'atomicité et de la durabilité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.

Le protocole de validation 2 Le protocole de validation 2 phases : 2PCphases : 2PC

Présentation

Fonctionnement général

Fiabilité

Critique du protocole

Améliorations possibles

PrésentationPré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

Fonctionnement généralFonctionnement général

Hypothèses de fonctionnement

Algorithme simplifié

Gestion des pertes de messages

Gestion des pannes

« Preuve » de correction de l'algorithme

Hypothèses de fonctionnementHypothè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

Réseau Coordinateur

ParticipantParticipant

Participant

Participant

Noeuds

Application

Figure 1 - Organisation d'un système distribué pour 2PC

Algorithme simplifié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

1ère phase : le vote1è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

2ème phase : la validation2è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

2ème phase : la validation (2)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

CoordinateurParticipant 1 Participant 2

Commit request Commit request

Commit voteCommit vote

CommitCommit

AckAck

Figure 2 - Transaction validée



Commit voteAbort vote

Abort

Ack

Figure 3 - Transaction annulée

Gestion des pertes de messagesGestion 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

Perte du « commit request »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 »)


Commit vote

AbortAbort

AckAck

Temporisateur armé

Temporisateur désarmé

Time out

Commit requestCommit request

Figure 4 - 1er cas de perte d'un « commit request »

Perte du « commit request » (2)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



Commit vote

AbortAbort

AckAck

Temporisateur armé

La transaction est annulée

Time outTime out

Figure 5 - 2nd cas de perte d'un « commit request »

Perte du votePerte 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


Time out

Commit request

Commit vote

AbortAbort

AckAck

Temporisateur armé

Time out

Commit Request

Commit vote

Ack

Abort

Vote?

Figure 6 - Perte d'un vote

Perte du résultat du votePerte 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

Figure 7 - perte du résultat du vote


Commit request

Commit vote

CommitCommit

Ack

Temporisateur armé

Time out

Commit Request

Ack

Commit

Commit vote

Temporisateur désarmé

Perte de l'accusé de réceptionPerte 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


Figure 8 - Perte d'un acquittement


Commit voteCommit vote

Commit Commit

Ack

Ack

AckCommit

Time out

Gestion des pannesGestion des pannes

Panne du coordinateur

Panne d'un participant

Panne du réseau

Panne du coordinateurPanne 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

Panne du coordinateur (2)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

Panne d'un participantPanne 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

Panne d'un participant (2)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

Panne du réseauPanne 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

« Preuve » de correction de « Preuve » de correction de l'algorithmel'algorithme

1. Si un participant valide la transaction, tous la valident

2. Si un participant annule la transaction, tous l'annulent

Figure 9 - Diagramme d'états finis du protocole de validation pour le coordinateur

F FailureT Time-out

W1

A1 C1

F

T,F

Un ou plusieurs participants ont répondu « abort ». « Abort » est envoyé à tous les participants.

Tous les particpants ont accepté. Envoie « commit » à tous les participants.

A1 - état d'acceptationC1 - état de validationQ1 - état de demandeW1 - état d'attente

« commit_request » envoyé à tous les participants.

Q1

Figure 10 - Diagramme d'états finis du protocole de validation pour les participants (i=2,3,...,n)

Qi

Wi Ai

CiA? - état d'acceptationC? - état de validationQ? - état de demandeW? - état d'attente

F FailureT Time-out

T,F

« commit » reçu du coordinateur

« abort » reçu du coordinateur

« commit request » reçu. « abort vote » envoyé au coordinateur

« commit request » reçu. « commit vote » envoyé au coordinateur

« Preuve » de correction de « Preuve » de correction de l'algorithme (2)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)

« Preuve » de correction de « Preuve » de correction de l'algorithme (3)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.

FiabilitéFiabilité

Définition

La base de données du protocole

La journalisation

Optimisation de la fiabilité

DéfinitionDé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

La base de données du protocoleLa base de données du protocole

Présentation

Organisation interne

Utilisation

PrésentationPrésentation

Structure de données en mémoire principale

Utilisée uniquement par le coordinateur

Contient les informations sur les transactions actives, validées ou annulées qui ne sont pas encore terminées

Organisation interneOrganisation interne

Tid : identificateur de la transaction

Stable : indique si l'existence de la transaction est enregistrée de manière stable dans le journal

State : Initiated : la transaction est connue du système Preparing : un « commit request » a été envoyé Aborted : un « abort » a été envoyé Commited : un « commit a été envoyé

Organisation interne (2)Organisation interne (2)

La liste des participants Cid : identificateur du participant Vote : réponse du participant au « commit

request » Ack : indique si l'acquittement de l'ordre de

validation a été reçu

Cid Vote AckNone YesAbort

R- O NoCommit

Tid Stable StateYes Init iated

Preparing

No AbortedCommited

est exécutée par0..n

1..n

Figure 11 - Organisation interne de la base de données du protocole

UtilisationUtilisation

Une transaction est lancée

Nouvelle entrée avec l'état « initiated » et la liste des participants

La validation de la transaction est demandée

L'état de l'entrée passe à « preparing »

Envoi du « commit request »

Chaque vote reçu est reporté dans l 'entrée

Utilisation (2)Utilisation (2)

Le résultat du vote est reporté dans l'entrée

Il est envoyé aux participants

A chaque acquittement, on le reporte dans l'entrée

Lorsque tous les acquittements ont été reçus, l'entrée est supprimée

Cid Vote Ack

Tid Stable State


1..n

Figure ? - La base données du protocole avant le lancement de la transaction

Cid Vote Ack12 None No35 None No

Tid Stable State5 No Init iated


1..n

Figure ? - La base données du protocole après le lancement de la transaction

Cid Vote Ack12 None No35 None No

Tid Stable State5 No Preparing


1..n

Figure ? - La base données du protocole après l'envoi du « commit request »

Cid Vote Ack12 Commit No35 Commit No

Tid Stable State5 No Preparing


1..n

Figure ? - La base données du protocole après le vote des participants

Cid Vote Ack12 Commit No35 Commit No

Tid Stable State5 Yes Committed


1..n

Figure ? - La base données du protocole après l'envoi du « commit »

Cid Vote Ack12 Commit Yes35 Commit Yes

Tid Stable State5 Yes Committed


1..n

Figure ? - La base données du protocole après réception des acquittements

Cid Vote Ack

Tid Stable State


1..n

Figure ? - La base données du protocole après la fin de la transaction

La journalisationLa journalisation

Nécessité de la redondance

Principe de la journalisation

Utilisation dans 2PC : PrN

Nécessité de la redondanceNécessité de la redondance

Une panne peut survenir à un moment critique de la validation

Des informations vitales peuvent être altérées ou perdues

Le système doit garantir que les modifications effectuées par une transaction validée seront effectivement écrites sur les bases de données concernées

Principe de la journalisationPrincipe de la journalisation

Les modifications sur les informations critiques sont conservées dans un journal (valeurs avant et après) sur un support fiable

Toute modification est précédée par un enregistrement forcé dans le journal

On est capable de refaire les modifications : lecture en avant

On est capable de défaire les modifications : lecture en arrière

Utilisation dans 2PC : PrN Utilisation dans 2PC : PrN coordinateurcoordinateur

Le coordinateur journalise les modifications de la base de données du protocole

Lorsque le résultat du vote est connu, il force le résultat dans le journal avant de l'envoyer

Cela permet la récupération de l'entrée de la transaction si une panne se produit après, et de finir la validation

Utilisation dans 2PC : PrN Utilisation dans 2PC : PrN coordinateur (2)coordinateur (2)

Après réception de tous les acquittements, il écrit un enregistrement de fin de transaction dans le journal : plus de demande d'acquittement

Utilisation dans 2PC : PrNUtilisation dans 2PC : PrNparticipantparticipant

Avant d'envoyer un « commit vote », il le force sur le journal

Si une panne survient avant la fin de la transaction, cet enregistrement lui permet de voir qu'une transaction était en cours de validation. Il (re)demande le résultat du vote

Lorsqu'il reçoit le résultat du vote, il force ce résultat dans le journal

Utilisation dans 2PC : PrNUtilisation dans 2PC : PrNparticipant (2)participant (2)

Puis, il envoie l'acquittement

En cas de panne, cet enregistrement assure qu'il ne redemandera plus le résultat au coordinateur

Figure 12 - Validation d'une transaction dans PrN


Commit request

Commit vote

Commit

Commit Request

Commit

Vote?

Commit vote

Vote?

panne

Enregistrement transaction validée dans le journal

enregistrement de validation forcé dans le journal

Panne

Ack Ack

enregistrement de fin de transaction non forcé

la transaction se retrouve dans la BDP car dans le journal

Figure 13 - annulation d'une transaction dans PrN

Participant 2CoordinateurParticipant 1

enregistrement forcé dans le journal

enregistrement non forcé dans le journal

Commit request

Abort vote

Commit Request

Abort

Abort vote

Abort

Ack Ack

Critique du protocoleCritique du protocole

+ Simple

+ Efficace

- Bloquant

- Nombre d'échanges de messages

- Nombre d'écritures forcées

Améliorations possiblesAméliorations possibles

Presumed Abort 2PC : PrA

Presumed Commit 2PC : PrC

Linear 2PC

Distributed 2PC

Presumed abort 2PCPresumed abort 2PC

Principe

En pratique

Critique

Principe de PrAPrincipe de PrA

Supposer qu'une transaction absente de la base de données du protocole est annulée

Garantir qu'une transaction validée a une entrée dans la BD du protocole

PrA en pratiquePrA en pratique

Même algorithme pour la validation Aucune journalisation nécessaire côté coordinateur

pour les transactions annulées Une transaction est retirée de la BD du protocole

dès son annulation Pas d'acquittement pour les « abort » Un participant qui a voté « abort » n’enregistre rien

dans le journal Les participants ne forcent plus l’écriture du

résultat du vote

Figure 14 - annulation d'une transaction dans PrA Tid137


enregistrement non forcé

Tid17

Enregistrement forcé

Time out

Commit request

Abort vote

Abort

Commit Request

Abort

Vote?

Commit vote

On retire la transaction de la BDP

pas d'Ack envoyé

pas d'écriture dans le journal

transaction pas dans la base => annulée

Critique de PrACritique de PrA

- Même coût que PrN pour la validation

+ Pas d'acquittement nécessaire pour l'annulation

+ Pas de journalisation côté coordinateur pour les transactions annulées

+ Une seule écriture forcée côté participant pour les transactions annulées

Presumed commit 2PCPresumed commit 2PC

Principe

En pratique

Critique

Principe de PrCPrincipe de PrC

Supposer qu'une transaction absente de la base de données du protocole est validée

Garantir qu'une transaction annulée a une entrée dans la BD du protocole

PrC en pratiquePrC en pratique

Enregistrement forcé de la transaction dans la BD du protocole dès son lancement

Suite du traitement identique pour les transactions annulées côté coordinateur

Les participants écrivent l'enregistrement de validation mais ne le forcent pas sur le journal

PrC en pratique (2)PrC en pratique (2)

Une transaction est retirée de la BD du protocole dès sa validation après écriture forcée d'un enregistrement de validation dans le journal

Pas d'acquittement pour les transactions validées


Time out

Commit request

Commit vote

Commit

Commit Request

Commit

Vote?

Commit vote

Vote?

Time out

Transaction pas dans BDP donc validée

panne

on efface la transaction de la BDP

pas d'Ack envoyé

Figure 15 - Validation d'une transaction dans PrC


Figure 16 - Annulation d'une transaction dans PrC

Commit request

Commit vote

Abort

Ack

Time out

Commit Request

Ack

Abort

Vote?

Commit vote

Vote?

Time out

Transaction dans BDP donc annulée

panne

Critique de PrCCritique de PrC

- Un enregistrement forcé au début de chaque transaction par le coordinateur

+ Un seul enregistrement forcé côté participant pour les transactions validées

+ Pas d'acquittement nécessaire pour les transactions validées

Linear 2PCLinear 2PC

Principe

Critique

Principe de linear 2PCPrincipe de linear 2PC

Minimiser les messages

Propagation linéaire d'un message depuis le coordinateur

Arrêt de la propagation dès qu'un participant vote « abort »

Critique de linear 2PCCritique de linear 2PC

+ Réduit le nombre de messages transmis

- Réduit l'exécution en parallèle : un participant « actif » à la fois

Distributed 2PCDistributed 2PC

Principe

Critique

Principe de distributed 2PCPrincipe de distributed 2PC

Les participants peuvent s'échanger des messages

Chaque participant envoie son vote à tous les participants et au coordinateur

Le coordinateur et les participants examinent les votes et en déduisent le résultat du vote

Critique de distributed 2PCCritique de distributed 2PC

+ Plus de 2nd phase

+ Améliore l'exécution en parallèle

- Coût élevé en messages

Optimisation de la fiabilité Optimisation de la fiabilité

Utilisation de points de reprises dans les journaux

Supports séparés pour les données du système et les journaux

Sauvegardes fréquentes des données du système et des journaux correspondants

Pour conclure ...Pour conclure ...

Algorithme pour gérer la validation de tâches sur les systèmes distribués.

Fiable, mais coûts élevés en messages réseau et écritures forcées.

Des améliorations de cet algorithme (Presumed abort,commit, linear, distributed).

BibliographieBibliographie

« Transaction Processing System »,Yair Amir, http://www.cs.jhu.edu/~yairamir/cs437/600-437.html

« The Two-Phase Commit Protocol », Mike Duckett

« Oracle7 Server Distributed Systems Manual, Vol. 1 », Oracle Edition

« Base de données : Polycopié 2, chapitre 14 », Stefano Spaccapietra, http://lbdsun.epfl.ch/f/teaching/courses/poly2/14/14.html, Ecole Polytechnique Fédérale de Lausanne

« Distributed Transaction Management», M. Tamer Özsu & Patrick Valduriez , http://www.cs.ualberta.ca/~database/ddbook/notes/Transaction/

http://lbdsun.epfl.ch/f/teaching/courses/poly2/14/14.html







http://www.cs.ualberta.ca/~database/ddbook/notes/Transaction/







La validation 2 phases

Documents

Transcript of La validation 2 phases