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 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... Un processeur central (CPU) de micro-ordinateur Un serveur de calcul distribué (cluster) Un SGBDR réparti Il existe des systèmes distribués dedifférents types et à différentes échelles : Microscopique Réseau local : International ! On peut trouver d'autres exemples. ..

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. Une partie du processeur se charge de recevoir le flot d'instructions, et de le répartir sur les différentes unités de calcul. Accélération certaine du traitement du flot d'instructions. (NB : Simplification ! Les unités de calcul ne travaillent pas toujours en parallèle suivant le flot d'instructions re₤u par le processeur. Les instructions successives ne peuvent être traitées en parallèle que si elles n'utilisent pas les mêmes registres !)

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) A une autre échelle, le cluster se compose d'un ordinateur de saisie et d'un ensemble d'ordinateurs connectés en réseau. Une fois la tâche de calcul saisie, l'ordinateur de commande va la découper en sous tâches et la répartir sur l'ensemble des ordinateurs auquels il est connecté. Tout les ordinateurs du réseau vont calculer leur sous tâche sans avoir « conscience » de la tâche globale. Une fois les sous tâches effectuées et moyennant parfois un travail de fusion des résultats non négligeable, l'ordinateur de commande rend le résultat et de l'extérieur on a l'impression qu'il a été le seul a travaillé ! (ex ordi de commande un pentium 200mmx 32 mo de ram, commandant un réseau de 50 octoprocesseurs à 933 Mhz et 512 Mo de ram chacun, une tâche qui aurait du prendre des heures se faira en 5 minutes) Applications : Toutes tâches ne peut se décomposer facilement (recherche Habib). Certaines tâches se décomposent plus facilement : Rendu de scène 3D (Titanic) Décryptage (RC5, seti@home)

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é. Les principaux produits du marché (Oracle, sybase, sql server) permettent d'établir une connexion avec d'autres bases de données et de les intégrer de manière transparente au sein du schéma local. Par exemple on peut obtenir un schéma relationnel avec une table des employés de production située sur un serveur dans la ville de production, une table des employés commerciaux située dans une autre ville et le tout serait consultable dans les différents sièges de la société avec des présentations et des droits différents (mécanisme de vue). Le sgbd global ordonnera les mises à jours des différents sites, d'une manière quasi transparente (suivant les cas, problèmes de performances, passage par des couches intermédiaires « middle-tiers »)

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. L'utilisateur final désire accomplir une tâche, si le système distribué échoue l'utilisateur voudrait retrouver dans le même état qu'avant, sinon l'utilisation du système deviendra assez chaotique ! Chaque sous système doit donc se préparer à effectuer la tâche sans l'accomplir de manière définitive (système de cache) Une fois que le sous-système est convaincu qu'il peut accomplir la tâche, il pourra en attester auprés du coordinateur. De même si le sous-système se rend compte qu'il échoue, il pourra encore en rendre compte au coordinateur. En fonction des messages qu'il recevra le coordinateur décidera s'il doit transmettre l'ordre de mise à jour définitive ou pas. Problèmes si un des messages se perd dans le réseau ou si un des sous systèmes tombe en panne.

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é. Pour gérer les problèmes cités, il faut que chaque tâche donnée au système distribué soit une transaction.

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) De l'extérieur on voit le système distribué passer de l'état initial à l'état final d'un seul coup. Ainsi on garantit que la transaction est insécable (comme un atome au sens étymologique !) Si la transaction échoue, on ne se sera pas arrêté sur un état intermédiaire, qui pourrait être incohérent au sein du système global.

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. Les transactions validées par le coordinateur doivent avoir aboutit sur un état cohérent du système global. Si celà n'était pas vérifié le système global pourrait devenir incohérent avec ses spécifications et par conséquent avoir un comportement non fiable.

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. L'utilisateur n'étant pas forcément conscient qu'il accéde au données en même temps que d'autres utilisateurs, il peut y avoir des conflits d'accés aux ressources, des résultats incohérents. Le système distribué doit savoir gérer cela (Ceci n'est pas le but de l'algorithme 2PC, mais celui du 2PL dont on ne parlera pas)

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). La durabilité permet de garantir la sauvegarde durable de la tâche effectuée. Les critères de durabilité peuvent varier suivant les besoins. Cette propriété garantit que si une panne survient avant la validation, la transaction est à refaire, et si elle survient aprés elle a été sauvegardée et on n'a pas à la refaire. (Tout le problème est de réduire au maximum la durée de la validation, pour qu'il n'y ait pas de panne durant cette phase critique.)

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. Particularité, différence pour les systèmes distribués pour la notion d'atomicité, de cohérence et d'isolation.

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. Maintenant Eric va vous expliquer comment la solution proposée par l'algorithme 2PC réponds aux problèmes que je vous ai exposé.

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

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 1. utilisé depuis les années 80 dans les systèmes de réservations des hôtels et de compagnies aériennes, dans le système boursier, ainsi que dans les systèmes banquaires

Fonctionnement 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 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 1. le coordinateur est généralement le noeud initiateur de la transaction 2. si un noeud reste en panne indéfiniment, cela peut dans certains cas provoquer un blocage des autres noeuds 3. le support de stockage fiable est nécessaire pour la reprise après une panne

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

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. tous les noeuds peuvent donc jouer le rôle de coordinateur suivant la transaction

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 1. « commit request » demande aux participants de se mettre dans un état où ils peuvent appeler soit « commit » soit rollback 2. le « commit vote » engage le participant à valider la transaction

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 1. on utilise un vote à l'unanimité 2. un participant qui envoit un « abort vote » a déjà défait la transaction. Inutile de lui dire que celle-ci a été annulée car il le sait déjà ayant usé de son droit de véto 3. l'acquittement signale au coordinateur que le participant a bien reçu le résultat du vote, et qu'il ne le redemandera plus

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

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

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

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 1. toutes les pertes se gèrent avec des temporisateurs

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 ») 1. renvoi « commit request » : un participant peut voter plusieurs fois pour une même transaction 2. le coordinateur peut recevoir plusieurs fois le même vote

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

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 1. ce temporisateur permet de ne pas attendre indéfiniment que la validation d'une transaction commence. On libère ainsi les verrous dont dispose la transaction, rendant les données disponibles 2. un participant peut donc recevoir un « commit request » pour une transaction qu'il a déjà annulée. Dans ce cas, il renvoie « abort »

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

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 1. le coodinateur ne peut pas distinguer la perte du « commit request » de la perte du vote 2. cette demande de résultat du vote est bloquante. Il renverra une demande tant qu'il n'aura pas reçu le résultat 3. même problème de duplication de messages

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

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

Coordinateur Participant 1 Participant 2 Commit Request Commit request Figure 7 - perte du résultat du vote Participant 1 Coordinateur Participant 2 Commit request Commit vote Commit Ack Temporisateur armé Time out Commit Request Temporisateur désarmé 1. on suppose que le temporisateur côté participant qui gère la perte du résultat du vote n'a pas eu le temps de se déclencher

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

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

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

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 1. avant envoi « commit request » : les temporisateurs des participants expirent, donc ils annulent 2. avant envoi résultat : ceux qui n'ont pas voté peuvent ne pas annuler la transaction si le panne du coordinateur est résolue avant le time-out du participant

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 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 1. avant envoi du vote : comme le coordinateur peut envoyer plusieurs « commit request », la transaction ne sera pas forcément annulée si le participant est rétabli et a l'occasion de voter « commit » 2. un participant doit connaître son vote même après une panne

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é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 1. Dans chaque cas, transaction annulée lorsque le temporisateur expire

« 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

Figure 9 - Diagramme d'états finis du protocole de validation pour le coordinateur Failure T Time-out W1 A1 C1 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'acceptation C1 - état de validation Q1 - état de demande W1 - é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 Ci A? - état d'acceptation C? - état de validation Q? - état de demande W? - état d'attente F Failure T 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 l'algorithme (2) 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 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é Définition La base de données du protocole La journalisation Optimisation de la fiabilité 1. Fiabilité = recovery

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 1. si un des noeuds a envoyé un « commit vote » et que la transaction est effectivement validée, il doit la valider

La base de données du protocole Présentation Organisation interne Utilisation 1. PrN garde les informations sur toutes les transactions non terminées. Ce ne sera pas le cas de PrA et PrC 2. panne du coordinateur -> perte de cette base de données -> journalisation de celle-ci

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

Figure 11 - Organisation interne de la base de données du protocole est exécutée par 0..n 1..n

Utilisation 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) 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 1. l'entrée de chaque participant peut être supprimée lorsque l'acquittement est reçu 2. les transactions qui n'ont pas été acquittées par tous les participants restent dans la base. Cela permet aux participants qui n'ont pas reçu le résultat du vote de l'obtenir en interrogeant le coordinateur

est exécutée par 0..n 1..n Figure ? - La base données du protocole avant le lancement de la transaction

Figure ? - La base données du protocole après le lancement de la transaction est exécutée par 0..n 1..n

Figure ? - La base données du protocole après l'envoi du « commit request » est exécutée par 0..n 1..n

Figure ? - La base données du protocole après le vote des participants est exécutée par 0..n 1..n

Figure ? - La base données du protocole après l'envoi du « commit » est exécutée par 0..n 1..n

Figure ? - La base données du protocole après réception des acquittements est exécutée par 0..n 1..n

Figure ? - La base données du protocole après la fin de la transaction est exécutée par 0..n 1..n

La journalisation Nécessité de la redondance Principe de la journalisation Utilisation dans 2PC : PrN

Né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 1. supports mémoires altérés ou perdus : on perd le cache de la transaction, la base de données du protocole et toutes les informations sur les transactions validées ou pas. On peut aussi perdre une partie ou toute la BD (panne d'un disque). 2. perte de la BD -> sauvegardes de la BD et des journaux correspondants

Principe 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 1. support sûr : support sur lequel l'écriture d'une unité d'enregistrement (page ou bloc) est atomique 2. support fiable : support sûr + correction des défaillances physiques par des redondances et des comparaisons systématiques. Mémoires secondaires fiables les plus répandues = RAID (Redundant Array of Inexpensive Disks) 3. enregistrement avant modif assure qu'on peut défaire les modifs. Panne pendant refaire ou défaire -> redo ou undo multiples même effet qu'un seul

Utilisation dans 2PC : PrN coordinateur 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 1. PrN (Presumed Nothing) car n'utilise (presque) pas d'hypothèse sur les transactions qui ne sont pas dans la BDP 2. forcer l'écriture : recopier les pages du journal en RAM sur le support où est stocké le journal 3. une panne avant l'écriture forcée annule la transaction (acceptable) 4. récupération de l'entrée permet de fournir résultat du vote aux participants qui ne l'ont pas eu

Utilisation dans 2PC : PrN 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 1. écriture non forcée de l'enregistrement de fin de transaction indique de ne pas restaurer l'entrée. Pas forcée car si panne, l'entrée est restaurée et le coordinateur renvoie résultat du vote. Puis, les participants renverront les acquittements : OK !!

Utilisation dans 2PC : PrN participant 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 1. il doit absolument mémoriser le résultat du vote car l'envoi de l'acquittement signifie qu'il l'a reçu et qu'il ne le demandera plus (même après une panne)

Utilisation dans 2PC : PrN participant (2) Puis, il envoie l'acquittement En cas de panne, cet enregistrement assure qu'il ne redemandera plus le résultat au coordinateur 1. le coordinateur se sert des accusés de réception pour gérer la base de données du protocole. S'il reçoit un acquittement, il conclut que le participant ne lui redemandera plus le résultat de la transaction. Donc, quand il a reçu tous les acquittements pour une transaction, il peut l'effacer de la BDP. Le résultat de la transaction n'est plus disponible. Mais ayant reçu tous les acquittements, aucun participant ne lui demandera plus le résultat

Coordinateur Participant 1 Participant 2 Commit Request Commit request Figure 12 - Validation d'une transaction dans PrN Participant 1 Coordinateur Participant 2 Commit request Commit vote Commit Commit Request Vote? panne Enregistrement transaction validée dans le journal enregistrement de validation forcé dans le journal Panne Ack enregistrement de fin de transaction non forcé la transaction se retrouve dans la BDP car dans le journal

Coordinateur Participant 1 Participant 2 Commit Request Commit request Figure 13 - annulation d'une transaction dans PrN Participant 1 Coordinateur Participant 2 Commit request Abort vote Commit Request Abort Ack enregistrement forcé dans le journal enregistrement non forcé dans le journal

Critique du protocole + Simple + Efficace - Bloquant - Nombre d'échanges de messages - Nombre d'écritures forcées 1. bloquant : participant demande le résultat du vote tant qu'il ne l'a pas reçu. Résolu par 3PC grâce à l'ajout d'un état intermédiaire entre l'état W et l'état C 2. coût en messages et écritures forcées : PrA, PrC et Linear 2PC

Améliorations possibles Presumed Abort 2PC : PrA Presumed Commit 2PC : PrC Linear 2PC Distributed 2PC

Presumed abort 2PC Principe En pratique Critique 1. transaction validée : si pas d'entrée dans la BDP, considérée comme annulée

Principe 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 1. hypothèse utilisée par PrN lorsqu'une panne interrompt une transaction avant l'envoi du résultat du vote. Sinon, on devrait enregistrer forcer un enregistrement pour toutes les transactions dès leur lancement

PrA 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 1. validation : même coût 2. pas d'ACK pour annulation car plus dans la BDP 3. annulation : un message de moins (ACK), une écriture forcée en moins côté participant et pas de journalisation côté coordinateur

Coordinateur Participant 1 Participant 2 Commit Request Commit request Figure 14 - annulation d'une transaction dans PrA Participant 1 Coordinateur Participant 2 Time out Commit request Abort vote Abort Commit Request 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 Enregistrement forcé enregistrement non forcé

Critique 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 1. 2 écritures forcées pour PrN

Presumed commit 2PC Principe En pratique Critique

Principe 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 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 1. enregistrement au lancement car sinon, si une panne survient, la transaction sera supposée validée car elle ne sera pas présente dans la BDP 2. cet enregistrement de validation efface logiquement l'enregistrement précédent; plus facile que d'effacer réellement l'enregistrement par nature du journal 3. enregistrement non forcé car un enregistrement « prepare » sans enregistrement de vote -> demande résultat d'une transaction non présente dans BDP

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 1. ACK inutile car pas dans la BDP

Coordinateur Participant 1 Participant 2 Commit Request Commit request Figure 15 - Validation d'une transaction dans PrC Participant 1 Coordinateur Participant 2 Time out Commit request Commit vote Commit Commit Request Vote? Transaction pas dans BDP donc validée panne on efface la transaction de la BDP pas d'Ack envoyé

Coordinateur Participant 1 Participant 2 Commit Request Commit request Figure 16 - Annulation d'une transaction dans PrC Participant 1 Coordinateur Participant 2 Commit request Commit vote Abort Ack Time out Commit Request Vote? Transaction dans BDP donc annulée panne

Critique 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 1. pas d'ACK car les transactions validées ne sont pas dans la BDP

Linear 2PC Principe Critique

Principe 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 2PC + Réduit le nombre de messages transmis - Réduit l'exécution en parallèle : un participant « actif » à la fois 1. adapté aux réseaux connectés de manière linéaire où l'on ne peut pas envoyer de messages à tous les sites simultanément

Distributed 2PC Principe Critique

Principe 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 2PC + Plus de 2nd phase + Améliore l'exécution en parallèle - Coût élevé en messages 1. les participants déduisent eux-mêmes le résultat du vote 2. plus besoin de passer par le coordinateur avant de valider ou d'annuler

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 1. points de reprise : on écrit un enregistrement spécial dans le journal et on force les pages du journal sur le support secondaire. On écrit l'adresse de cet enregistrement dans un fichier de démarrage

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). Pour conclure, je rappellerai que l'algorithme que nous avons vu s'applique aux systèmes distribués. Son but est de garantir la validation d'une tâche répartie au sein d'un de ces systèmes. En cas d'erreurs internes au système distribué, de l'extérieur on ne doit pas s'en occuper, soit il réussit, soit il échoue et dans tout les cas il aboutit à un état prévu dans les spécifications. Si jamais le système s'arr₨tait dans un état non prévu, l'utilisateur (homme, machine ou logiciel) serait à son tour dans une situation imprévue et donc certainement incohérente. Rappellons aussi que l'algorithme gère très classiquement les défaillances du réseau entre les différents systèmes internes par des « time-out ». Les trois inconvénients majeurs de cet algorithme sont le grands nombre de messages qui doivent circuler sur le réseau, son grand nombre d'écritures forcées et le fait qu'il bloque les ressources dans l'attente d'un message de validation/annulation. Le nombre de messages et d'écritures forcées est diminué dans les variantes « presummed commit » et « presumed abort ». La variante « linear 2pc » réduit le nombre de messages mais au prix de la perte du parallélisme. La variante « distributed 2PC» améliore au contraire le parallélisme mais au prix d'une augmentation du nombre de messages transmis. Ces variantes sont plus ou moins adaptées aux nombreuses applications des systèmes distribués.

Bibliographie « 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/