REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE L ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE

Transcription

1 REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE L ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE Ecole Supérieure d Informatique (ESI) Ecole Doctorale Mémoire Soutenu pour l obtention du diplôme de Magister en Informatique Option : Systèmes d Information et de Communication (SIC) Thème Validation atomique de transactions réparties pour un système de stockage à base de LH* (Distributed Linear Hashing) Proposé par : Réalisé par : M. Hidouci W.K. Djail Boubekeur Soutenue publiquement le 15 mai 2012 devant le jury composé de : Mr. ZEGOUR Djamel Eddine Prof (ESI) Président Mme AISSANI Aicha Prof (USTHB) Examinatrice Mme. TEBIBEL Thouraya M.C A (ESI) Examinatrice Mr. HADDADOU Hamid M.C A (ESI) Examinateur Mr. HIDOUCI Walid Khaled M.C A (ESI) Directeur de mémoire Année : 2010/2011

2 A la mémoire de mon très cher père.

3 REMERCIEMENTS Je remercie, en premier, Dieu le tout puissant pour la force et le courage qu il m a donné afin de pouvoir réaliser et terminer ce travail. Mes remerciements vont ensuite à M. Hidouci pour avoir accepté de proposer et de diriger ce travail. Je le remercie vivement pour sa disponibilité, ses conseils et sa patience durant toute la durée du stage. Mes remerciements vont également à tous les enseignants qui ont participé à ma formation depuis son début. Je remercie encore le Professeur El-Houmailey pour sa précieuse aide, et sa prise en charge rapide de ma requête. Je tiens aussi à adresser mes remerciements à mes collègues dans la classe de Magister et particulièrement à Boualem Abed pour son aide. Soient vivement remerciés les membres de jury qui ont accepté de juger ce travail et qui m ont honoré par leur présence. Enfin, à tous ceux qui ont participé de près ou de loin à la réalisation de ce travail, je transmettrai un grand merci.

4 Resume Dans le présent mémoire, nous tentons l application d un protocole de validation des transactions réparties à des bases de données stockées sur des systèmes à base de LH*. Nous avons accès alors, dans cette étude, sur : - Une nouvelle structure de données pour le stockage des données distribuées, à savoir la structure LH*. - L étude et la sélection d un protocole de validation 2PC. Le modèle de stockage de données adopté (LH*) répartit les données d une base de données parallèle sur les mémoires de plusieurs serveurs connectés en réseau. On commence par allouer de l espace (case) chez un seul serveur, et on procédera par éclatement à chaque débordement de case. On permettra ainsi un temps d accès plus rapide que dans le cas d une base de données stockée sur un disque local. Le modèle LH* est cependant très sensible aux pannes pouvant entrainer des pertes de données. L application d un protocole permettant la reprise après panne s avère alors, dans ce cas, très indispensable. Nous avons étudié alors les principales variantes du protocole de validation 2PC, et avons ensuite présenté une étude comparative pour sélectionner une des variantes (PrA) pour qu elle soit implémentée. La solution a été implémentée sur une machine virtuelle simulant un réseau constitué d un ensemble de PCs fonctionnant sous linux (ubuntu), et communiquant en s échangeant des messages à l aide des fonctions fournies par la librairie PVM (Parallel Virtual Machine). Nous avons pu vérifier, après réalisation du prototype, l applicabilité du protocole PrA sur des bases de données stockées à base de LH*, tout en mettant en évidence les points caractérisant cette implémentation. Mots clés : Base de données parallèle, transaction, protocole de validation, Structure de Données Distribuée et Scalable. i

5 abstract In the present report, we try the application of a protocol of validation of the distributed transactions to databases stored on systems based on LH*. We then have access, in this study, on: - A new structure of data for the distributed data storage, namely structure LH*. - The study and selection of a protocol of validation 2PC. The model of adopted data storage (LH*) distributes the data of a parallel database on the memories of several servers connected in network. One starts by allocating space (bucket) at only one server, and one will proceed by splitting to each overflow of bucket. One will allow thus an access time faster than in the case of a database stored on a local disc. Model LH* is however very sensitive to the failure being able to involve losses of data. The application of a protocol allowing the recovery after failure proves then, in this case, very essential. We then studied the principal alternatives of the protocol of validation 2PC, and then presented a comparative study to select one of the alternatives (PrA) so that it is implemented. The solution was implemented on a virtual machine simulating a network made up of a whole of PCs functioning under linux (ubuntu), and communicating by exchanging messages using the functions provided by PVM library (Parallel Virtual Machine). We could check, after realization of the prototype, the applicability of the PrA protocol on databases stored containing LH*, while highlighting the points characterizing this implementation. Key words: Parallel database, transaction, protocol of validation, Structure of Data Distributed and Scalable. ii

6 Table des matières Résumé... i Liste des Figures... viii Liste des Tableaux... ix Liste des Algorithmes... x Introduction générale... 1 Chapitre I : Les systèmes de gestion des bases de données parallèles 1. Introduction Architectures matérielles Architecture à Mémoire Partagée (Shared-Memory) Architecture à Disques Partagés (Shared-Disk) Architecture distribuée ou sans partage (Shared-Nothing) Architecture hybride Partitionnement des données Schémas de partitionnement Partitionnement horizontal Partitionnement vertical Partition hybride Stratégies de partitionnement Partitionnement circulaire (ou Round Robin) Partitionnement par intervalle Partitionnement par hachage Traitement parallèle des données Les limites du parallélisme Conclusion Chapitre II : Les structures de données distribuées et scalables SDDS 1. Introduction Principe des SDDS Règles d utilisation des SDDS iii

7 4. Caractéristiques d une SDDS a. La scalabilité b. La disponibilité c. La distribution Classification des SDDS a. SDDS basées sur les arbres b. SDDS basées sur le hachage Etude de LH Principe Extension du fichier Fusion dans le fichier Etude de LH* Principe général Calcul d adresse au niveau du client Calcul d adresse au niveau du serveur Réajustement de l image du client Extension d un fichier LH* a. Eclatement non contrôlé b. Eclatement contrôlé Fusion dans un fichier LH* Variantes de LH* Conclusion Chapitre III : Les transactions 1. Introduction Définition d une transaction Les propriétés ACID des transactions Le système transactionnel La journalisation des transactions Définition Types d'enregistrements du journal Le protocole WAL Déroulement de la journalisation Points de reprise Transaction distribuée Structure d un système de transaction distribué Conclusion iv

8 Chapitre IV : La validation atomique 1. Introduction Spécifications de la validation Le protocole de validation biphasé (2PC = Two-Phase Commit Protocol) Principe Résistance aux pannes Les écritures journal Les enregistrements du journal Traitements des pannes a. Panne d'un site participant b. Panne du coordinateur c. Partition de réseau Inconvénients du protocole 2PC Protocole de terminaison Variantes du protocole 2PC Variantes améliorant les performances du protocole 2PC durant une exécution normale Le protocole Presumed-Abort (PrA) Presumed-Commit (PrC) Comparaison de 2PC de base et ses principales variantes Autres variantes Early Prepare (EP) Coordinator Log (CL) Protocole Implicit-Yes Vote (IYV) Variantes du protocole 2PC réduisant le blocage après une panne Le protocole de validation triphasé 3PC Le protocole 2PC décentralisé (D2PC) Optimisations du protocole 2PC Read-Only One -Phase Commit Comparaison des protocoles Conclusion Chapitre V : Architecture du prototype 1. Introduction v

9 2. Architecture générale du prototype Architecture du serveur Architecture du client Déroulement des transactions Opérations de mise à jour Opération de lecture La validation a. La validation au niveau des clients b. la validation au niveau des serveurs Conclusion Chapitre VI : Présentation détaillée du prototype 1. Introduction Protocole de validation adopté Structure de données Journalisation Structure du journal Les points de reprise a. Point de reprise consistant b. Point de reprise non consistant Opérations d accès Présentation des fonctionnalités du prototype Génération automatique des transactions Affichage des enregistrements d un serveur Affichage des enregistrements du journal Récupération du fichier SDDS Sauvegarder un serveur Description détaillée des traitements Les traitements réalisés par les serveurs a. Traitement d insertion b. Traitement d éclatement c. Traitement de suppression d. Traitement de fusion e. Traitement de modification vi

10 f. Traitement de lecture g. Traitement de validation h. Algorithme principal d un serveur Les traitements au niveau des clients a. Réception et traitement des requêtes des utilisateurs b. Validation des transactions Conclusion Conclusion générale Bibliographie Annexe vii

11 LISTE des figures Figure. I.1. Architecture à Mémoire Partagée... 6 Figure. I.2. Architecture à disques partagés... 7 Figure. I.3. Architecture sans partage... 8 Figure. I.4. Architecture hybride Figure. I.5. Partitionnement circulaire Figure. I.6. Partitionnement par intervalle Figure. I.7. Partitionnement par hachage Figure. II.1. Fichier classique vs SDDS Figure. II.2. Courbe du facteur de rapidité Figure. II.3. Courbe du facteur d échelle Figure. II.4. Les familles de SDDS Figure. II.5. Etat initial d un fichier LH de N cases Figure. II.6. Fichier LH après éclatement de la case Figure. II.7. Principe de l algorithme LH* Figure III.1. Schéma général d un système transactionnel Figure III.2. Architecture globale d un système de base de données centralisé Figure III.3. Ordre d exécution des mises à jour Figure III.4. Structure d un système de transaction distribuée Figure IV.1. Le protocole 2 PC de base Figure IV.2. Panne d un participant après s être déclaré prêt Figure IV.3. Panne d un participant avant d être prêt Figure IV.4. Panne du coordinateur Figure IV.5. Quelques étapes significatives de l évolution des protocoles de validation atomique Figure IV.6. Le protocole Presumed-Abort (PrA) viii

12 Figure IV.7. Le protocole Presumed-Commit (PrC) Figure IV.8. Le protocole Early Prepare Figure IV.9. Le protocole 3PC Figure V.1. Architecture générale du prototype Figure V.2 : Architecture d un serveur Figure V.3. Architecture d un client Figure V.4. Déroulement du traitement d éclatement Figure V.5 Déroulement du traitement de fusion Figure VI.1. Structure d une case du fichier SDDS Figure VI.2. Structure d un enregistrement du fichier SDDS Figure VI.3. Structure d un enregistrement du journal Figure VI.4. Point de reprise consistant Figure VI.5. Point de reprise inconsistant Figure VI.6. Menu principal du prototype Figure VI.7. Un exemple de génération de transactions Figure VI.8. Un exemple d affichage d une case de serveur Figure VI.9. Menu d accès aux journaux Figure VI.10. Un exemple du contenu du journal du serveur Figure VI.11. Cas d insertions Figure VI.12. Cas de suppressions Figure VI.13. Echanges de messages dans le cas d une validation Figure VI.14. Echanges de messages dans le cas d une annulation Liste des tableaux Tableau. I.1. Temps d accès aux données... 9 Tableau IV.1. Coût des mises à jour dans les variantes 2PC Tableau IV.2. Comparaison des principaux protocoles (cas de validation) ix

13 Tableau IV.3. Comparaison des principaux protocoles (cas d annulation) Liste des ALGORITHMES Algorithme II.1. Algorithme de calcule de l adresse d une clé Algorithme II.2. : Mise à jour du couple (i, n) après un éclatement d une case Algorithme II.3. Mise à jour du couple (i, n) après la fusion de deux cases Algorithme II.4. Adressage d un serveur Algorithme II.5. Vérification de l adressage par le serveur Algorithme II.6. Ajustement de l image client Algorithme VI.1. Insertion d un enregistrement Algorithme VI.2. Eclatement de cases Algorithme VI.3. Suppression d un enregistrement Algorithme VI.4. Fusion de cases Algorithme VI.5. Modification d un enregistrement Algorithme VI.6. Lecture d un enregistrement Algorithme VI.7. Validation d une transaction au niveau serveur Algorithme VI.8. Algorithme principal d un serveur Algorithme VI.9. Algorithme de traitement d une opération au niveau du client Algorithme VI.10. Validation d une transaction au niveau client x

14 Introduction générale Introduction générale Les volumes des bases de données ne cessant de s accroître ces dernières décennies ont rendu difficile la gestion de données stockées sur mémoires secondaires. Les causes reviennent aux temps de réponses et aux débits fournis par de telles mémoires, qui restent toujours insuffisantes malgré les progrès technologiques réalisés. Les débits n ont augmenté que d un facteur de deux durant les dix dernières années [Valduriez 93]. Cependant, d autres composants ont connus une évolution impressionnante, tels que : les processeurs dont les performances augmentent d environ 50% par an, et les mémoires centrales dont les capacités augmentent d un facteur de 16 tous les six ans. [Sahri 2006]. De même, l accès au disque local n est plus rapide que celui à une mémoire sur une machine distante d un réseau d ordinateurs, vu les améliorations qu ont connait ces derniers. [Gray 93] [Mokadem 06] Un multiordinateur réseau est une configuration de stations de travail et de PCs à grande diffusion, interconnectés par un réseau local de haut débit tel que Ethernet 100 Mb/s [Tanenbaum 95]. Grâce à leur capacité de stockage et leur rapidité d exécution et au rapport qualité/prix imbattable, les multiordinateurs marquent de plus en plus leur importance dans le domaine de la recherche en informatique. Ces recherches se sont intéressées surtout à traiter les limitations des fichiers traditionnels enregistrés sur un disque local. Limitations liées à la taille, la rapidité d accès et la vulnérabilité aux pannes. Afin de dépasser ces limitations, il eut apparition de nouvelles structures de données appelées : SDDS (Structure de Données Distribuées et Scalables) avec un premier schéma (LH*) proposé par litwin en 1993 [litwin 93]. Il fut suivi par plusieurs autres variantes, tels que : LH* LH [Karlson 96], LH* M [Litwin 96], LH* S [Litwin 97a], LH*g[Litwin 97b], Les données d une SDDS résident en RAM distribuée du multiordinateur, permettant un accès aux données très rapide par rapport à un accès aux fichiers traditionnels sur disque. 1

15 Introduction générale D un autre côté, Les systèmes actuels exigent de plus en plus des garanties de base de fiabilité afin d'assurer des résultats déterministes même en présence de panne. Dans les systèmes de base de données, des garanties semblables de fiabilité sont fournies par la propriété d atomicité des transactions. Cette propriété signifie que chaque transaction est exécutée comme une unité atomique indivisible et termine soit par valider, soit par annuler tous ses effets sur l'état de la base de données. Dans les systèmes de bases de données réparties et les systèmes de bases de données parallèles, cette propriété peut être assurée localement au niveau de chaque site, mais doit l'être aussi globalement dans le cas de transactions réparties (exécutées sur les données de plusieurs sites) : c'est l'objectif de l'application des protocoles dits de validation atomique. Un protocole de validation atomique est un protocole qui assure l'atomicité globale d'une transaction répartie malgré les pannes possibles d'emplacement et de communication. Il garantit des résultats finaux déterministes pour que chaque transaction répartie soit complètement effectuée sur tous les sites participants ou pas du tout. Les protocoles de validation atomique demeurent à l'heure actuelle les seuls moyens permettant d'assurer l'atomicité des transactions réparties, et ce malgré les effets nuisibles d'exécution qu'ils présentent et qui sont résumés dans les points suivants : - consommation importante du temps d'exécution due aux messages échangés et aux écritures disques réalisées, - blocage dans certains cas d'échec, où certains participants ne pourraient plus savoir la situation finale de la transaction, pendant que des ressources sont détenues par la transaction qui attend d'être terminée. Objectif de ce travail : Nous nous intéressons à sélectionner un des protocoles de validation atomique parmi plusieurs qui doivent être étudiés et comparés, afin de l'appliquer par la suite à des transactions réparties sur une base de données stockées sur un système à base de LH*. 2

16 Introduction générale Organisation du mémoire Ce mémoire est organisé en six chapitres. Le chapitre I présentera les concepts des SGBDs parallèles, en décrivant les différentes architectures matérielles possibles, les différents schémas et stratégies de partitionnement. Ensuite, il expliquera le déroulement de l exécution des traitements parallèles dans de tels systèmes, pour mentionner à la fin les limites du parallélisme avant de terminer par une synthèse du chapitre. Le chapitre II détaille les différents aspects des structures de données distribuées et Scalables (SDDS). Les principes généraux de ces structures sont présentés en premier. Sont suivis par l énumération des règles d utilisation et des différentes classes de SDDS. Une structure SDDS de référence, à savoir LH*, est détaillée par la suite, et ce ainsi que la structure LH sur laquelle elle est basée. LH* étant la structure pour laquelle nous tentons d appliquer un protocole de validation de transaction répartie. Un bilan des SDDS termine ce chapitre. Le chapitre III est consacré aux notions de base des transactions. Les propriétés ACID des transactions sont rappelées. La structure du système transactionnel est décrite pour les deux cas centralisé et distribué. Le principe de la journalisation est détaillé par la suite ainsi que le protocole qui lui est lié : le protocole WAL. Le chapitre IV s intéresse aux protocoles de la validation atomique des transactions réparties. Il en décrit les principes et détaille le principal protocole : le protocole 2PC. Sont aussi décrites ses principales variantes et les optimisations y pouvant être appliquées. Le chapitre est terminé par une comparaison entre les variantes 2PC étudiées et une synthèse finale. Le chapitre V présente l architecture globale du prototype réalisé, suivie de l architecture des serveurs et de celle des clients. Les principaux éléments de ces architectures sont expliqués le long du chapitre. 3

17 Introduction générale Le chapitre VI présente une description détaillée du prototype implémenté, en commençant par préciser le choix adopté quant à la variante du protocole 2PC, ainsi que la structure du journal utilisé et les opérations d accès fournies. Sont présentés ensuite les différents algorithmes écrits et exécutés au niveau des serveurs et au niveau des clients. Une synthèse du travail conclut le chapitre. Le mémoire est terminé par une conclusion générale dressant un bilan général du travail réalisé et présentant les perspectives pour l extension du système. 4

18 Chapitre I/ Les systèmes de gestion des bases de données parallèles Chapitre I Les systèmes de gestion de bases de données parallèles 1. Introduction : Un système de gestion de base de données est actuellement à la base des systèmes informatique de gestion, sachant qu il permet différentes opérations sur les données d une base de données, tels que : la recherche, la consultation, la mise à jour, Les SGBD ont connu dans le temps plusieurs évolutions, allant des SGBD centralisés aux SGBD parallèles en passant par les SGBD distribués. Les SGBD centralisés permettaient l accès à un serveur de base de données unique. Les inconvénients étaient ceux de toute solution centralisée. L apparition des mini et micro-ordinateurs et l évolution des réseaux de communication étaient à l origine du développement des SGBD distribués permettant la répartition des données sur plusieurs serveurs. Les volumes des données ne cessant de s accroitre et les requêtes ne cessant encore d être plus complexes ont marqué la nécessité de penser les SGBD parallèles pour de meilleures performances et de disponibilité de données. Ce chapitre présentera les concepts de base des systèmes de bases de données parallèles. Les architectures matérielles utilisées seront détaillées ainsi que les stratégies et schémas de partitionnement des données. 2. Architectures matérielles : Les systèmes de base de données sont établis à base de processeurs conventionnels, mémoires et disques, selon diverses architectures classifiées selon le critère de partage de ressources. Nous décrirons les trois architectures les plus utilisées ainsi que les 5

19 Chapitre I/ Les systèmes de gestion des bases de données parallèles architectures hybrides qui tentent de profiter des avantages de chaque architecture parmi les trois : [Dewitt 92] 2.1. Architecture à Mémoire Partagée (Shared-Memory) : Plusieurs processeurs indépendants sont connectés entre eux et partagent une mémoire commune. Cette architecture présente l avantage de permettre une rapidité dans l accès aux données et dans les communications entre processeurs, ainsi qu une facilité dans la mise en œuvre (vu que l espace d adressage est global) et dans la réalisation de l équilibrage de charge. De plus, l échec d un processeur n entraîne pas la non-possibilité d accès aux données. Cependant, l inconvénient majeur de cette architecture est dans la complexité du réseau d interconnexion entrainant un coût élevé du système et limitant le nombre de processeurs à En effet, un nombre supérieur crée des goulots d étranglement. Parmi les systèmes de gestion de bases de données qui utilisent ce type d architecture, nous citons : XPRS(U. de berkeley), DBS3 (Bull) [Bergsten 91] et Volcano [Graefe 90]. Pour les systèmes commerciaux, Oracle [Davis 92] et Informix [Davison 92] proposent des solutions sur ce type d architecture. P P P 1 2 n Interconnection réseau Mémoire partagée Figure. I.1. Architecture à Mémoire Partagée 6

20 Chapitre I/ Les systèmes de gestion des bases de données parallèles 2.2. Architecture à Disques Partagés (Shared-Disk) : Chaque processeur est doté de sa propre mémoire et peut accéder à n importe quel disque à travers un réseau d interconnexion. La répartition de la charge de travail est ainsi facile à réaliser. Les accès conflictuels aux mémoires centrales sont réduits. Le disque partagé offre donc une excellente utilisation des ressources, et un bon niveau de tolérance aux pannes puisque l échec d un processeur n entraîne pas la non-disponibilité des données. Par contre, il peut être nécessaire de dupliquer une page disque sur plusieurs nœuds vu que la mémoire n est pas partagée, d où nécessité de gestion cohérente de toutes les copies du disque. Le coût élevé de la maintenance de cette cohérence s avère comme l inconvénient de cette architecture. L accès aux disques peut créer un goulot d étranglement, dû à la limite de la capacité du bus, ce qui entraine encore une difficulté d extension aux milliers de processeurs et de disques. Parmi les SGBD utilisant cette architecture, nous citons VAXcluster de DEC, IMS/VS Data Sharing de IBM, Oracle (Oracle Parallel Server) [Davis 92]. P P P 1 2 n Mémoire Mémoire Mémoire Interconnection réseau Figure. I.2. Architecture à disques partagés 7

21 Chapitre I/ Les systèmes de gestion des bases de données parallèles 2.3. Architecture distribuée ou sans partage (Shared-Nothing) : Chaque processeur dispose de sa propre mémoire locale et de son propre espace disque. Le coût du système est abordable, puisqu il s agit d une simple collection de PCs. Cette architecture permet une extension facile pouvant atteindre plusieurs milliers de PCs, et une bonne disponibilité des données si la réplication est faite au niveau de plusieurs nœuds, sinon difficulté d accès aux données en cas de panne d un nœud. Architecture réduisant au minimum l'interférence en minimisant le partage de ressource. L équilibrage de charge est difficile à réaliser vu le placement prédéterminé des données. Et, contrairement aux architectures précédentes, il y a nécessité de modifier les applications pour tirer profit de l augmentation de puissance procurée. Notons enfin que ces systèmes restent difficiles à administrer et à programmer. De nombreux systèmes de gestion de bases de données utilisent ce type d architecture notamment NonStopSQL de Tandem [Boral 90], Gamma (U. de Wisconsic) [Dewitt 86],et PRISMA/DB [Apers 92]. Interconnection réseau P 1 P 2 P n Mémoire Mémoire Mémoire Figure. I.3. Architecture sans partage 8

22 Chapitre I/ Les systèmes de gestion des bases de données parallèles Une forme intéressante de cette architecture est : les multi-ordinateurs. Un Multi-ordinateur étant un réseau de stations de travail et de PCs faiblement couplés, interconnectés par un réseau d au moins 10Mb/s (Ethernet, ATM, Fast et Giga Ethernet). [Gray 93] D autres termes sont utilisés pour désigner ces configurations, tels que : réseau de stations de travail ou plus récemment Grid computing. Les multi-ordinateurs présentent l avantage de permettre un accès aux données chargées dans les mémoires des PCs plus rapide qu un accès aux données stockées sur un disque dur local. Ressource Disque local RAM distante (Ethernet) RAM distante (Réseau gigabit) RAM locale Temps d accès 10 msec 100 µsec 1 µsec 100 nsec Tableau. I.1. Temps d accès aux données [Mokadem 06] Ceci est justifié par l'augmentation régulière de la vitesse du CPU (Central Processor Unit), soit 60% par an, et par l'optimisation des architectures ayant entraîné une baisse continue du temps d'accès à la RAM (Random Access Memory) soit 10% par an. Les disques durs, par contre, limités par leurs structures mécaniques, n'ont pas obtenu le même succès. [Mokadem 06] De même, les réseaux ont connu des améliorations importantes au cours des dernières années. Des recherches menées depuis plusieurs années étudient l influence des réseaux à très haut débit sur la gestion de l information. Les résultats montrent qu il est actuellement plus rapide d aller chercher une information dans la mémoire centrale d une machine distance que sur un disque local [Mokadem 06]. De l autre côté, un nombre croissant d applications exige une capacité de stockage et de traitement qui dépasse celle des plus puissantes machines actuelles. Pour répondre à de 9

23 Chapitre I/ Les systèmes de gestion des bases de données parallèles tels besoins, de plus en plus grand, une approche suivie depuis quelques années vise à combiner la puissance de traitement et de stockage d un grand nombre de machines, d où un autre intérêt particulier des multi-ordinateurs Architecture hybride : Une architecture hybride est le résultat de la combinaison des architectures à mémoires partagées et sans partage, afin tirer profil des avantages des deux architectures tout en compensant leurs inconvénients respectifs. L architecture hybride combine l équilibre de charge des architectures à mémoire(s) partagée(s) et l extensibilité des architectures à mémoire(s) distribuée(s). Réseau d interconnexion P P P P 2 P 2 P 2 P n P n P n Mémoire Mémoire Mémoire Figure I.4. Architecture hybride 3. Partitionnement des données : Dans un système parallèle, les données sont partitionnées sur plusieurs serveurs afin de permettre des traitements parallèles. Nous présenterons dans cette section, les différents schémas de partitionnement (ou fragmentation) ainsi que les stratégies de partitionnement qui peuvent être adoptées. 10

24 Chapitre I/ Les systèmes de gestion des bases de données parallèles 3.1. Schémas de partitionnement : On distingue principalement deux schémas de partitionnement : le partitionnement horizontal et le partitionnement vertical. Un troisième schéma permet la combinaison des principes des deux précédents. [Ozsu 99] [Sahri 06] Partitionnement horizontal : La fragmentation se fait selon les tuples de la table à l aide de prédicats définis sur les propriétés de la table. Chaque fragment résultant est un sous-ensemble des tuples de la table. Le partitionnement est dit primaire si les prédicats sont définis sur la table elle-même. Il est dit dérivé si les prédicats sont définis sur une table qui lui est liée Partitionnement vertical : Le partitionnement vertical d une table produit des fragments par des projections sur un ensemble d attributs disjoints. Chaque fragment doit posséder la clé de la table. Etant donné le grand nombre de possibilités, le partitionnement vertical est plus complexe que le partitionnement horizontal Partitionnement hybride : Pour les besoins des applications, on peut tenter la combinaison des deux schémas précédents, en procédant par un partitionnement horizontal suivi d un partitionnement vertical ou vice versa. 11

25 Chapitre I/ Les systèmes de gestion des bases de données parallèles 3.2. Stratégies de partitionnement : Plusieurs stratégies peuvent être adoptées pour obtenir les schémas présentés précédemment : le partitionnement circulaire [Teradata 88], le partitionnement par hachage [Kitsuregawa 88] et le partitionnement par intervalle [Dewitt 86] Partitionnement circulaire (ou Round Robin) : Les données sont distribuées uniformément sur les différents nœuds du système. Si on dispose de N nœuds, le i ème tuple est inséré dans le nœud de numéro (i mod N). Cette stratégie est facile à mettre en œuvre. Cependant, elle présente l inconvénient de la difficulté d optimiser les temps de réponses des requêtes vu qu il est possible de parcourir la plupart des nœuds lors de l exécution d une requête. Notons encore que cette stratégie convient aux requêtes nécessitant un parcours séquentiel des tuples, et permet de les paralléliser. Elle est implantée dans les systèmes RAID [Patterson 88]. Figure. I.5. Partitionnement circulaire Partitionnement par intervalle : Les tuples d une table sont distribués en fonction de la valeur d un ou de plusieurs attributs. L espace des valeurs des attributs sélectionnés est divisé en intervalles puis chaque intervalle est affecté à un nœud. Chaque tuple est alors affecté au nœud d intervalle incluant les valeurs d attributs spécifiés. 12

26 Chapitre I/ Les systèmes de gestion des bases de données parallèles Cette stratégie convient aux requêtes dont le prédicat implique les attributs de partitionnement et donc les requêtes par intervalle. Mais, ne garantit pas un équilibre de charge entre les nœuds. Figure. I.6. Partitionnement par intervalle Partitionnement par hachage : Cette stratégie distribue les tuples d une table en utilisant une fonction de hachage h sur un ensemble d attributs. La fonction de hachage donne le numéro du nœud qui recevra le tuple. Ce partitionnement convient aux applications qui veulent accéder aux données de façon séquentielle et associative. C est parmi les partitionnements les plus utilisés dans les bases de données. [Hidouci 07]. Il existe deux méthodes de hachage : hachage statique et hachage dynamique. Le hachage statique est très simple et donne d excellentes performances, et ce tant qu il n y a pas de débordements, sinon les performances risquent de se dégrader rapidement. Le hachage dynamique permet de faire grandir progressivement un fichier haché saturé en distribuant les tuples dans de nouvelles régions allouées à une table. On distingue principalement deux méthodes de hachage dynamique : le hachage extensible [Fagin 79] et le hachage linéaire [Litwin 80] reconnu pour la simplicité de son algorithme. Il sera détaillé plus loin. Le hachage linéaire est utilisé par plusieurs SGBDs. Notamment SQL Server, Postgres, DB Library (Oracle), et MySQL. 13

27 Chapitre I/ Les systèmes de gestion des bases de données parallèles Figure. I.7. Partitionnement par hachage 4. Traitement parallèle des données : L objectif d un traitement parallèle des données est d atteindre de hautes performances dans l exécution des requêtes en réduisant le temps de réponses de cellesci [kim 95]. On distingue deux formes de parallélisme, suite à un partitionnement des données : - Le parallélisme inter-requête : qui permet l exécution parallèle de plusieurs requêtes, agissant chacune sur des partitions différentes. - Le parallélisme intra-requête : qui permet l exécution parallèle de plusieurs opérations relationnelles à l intérieur de la requête même. 5. Les limites du parallélisme : L exécution parallèle d un traitement peut être limitée par plusieurs facteurs : - L initialisation des tâches (Startup) : correspond temps nécessaire pour démarrer une opération parallèle. Ce temps peut être trop important par rapport au temps d exécution de la requête elle-même, surtout si le degré de parallélisme est trop élevé. - L interférence entre les processus parallèles : augmente le temps d exécution des requêtes et dégrade les performances du système. - Le biais (ou skew en anglais) : Le temps de réponse de plusieurs processus s exécutant en parallèle est le temps de réponse du processus le plus lent. 14

28 Chapitre I/ Les systèmes de gestion des bases de données parallèles 6. Conclusion : Le long de ce chapitre, nous avons présenté les différents aspects des systèmes parallèles, allant des architectures possibles en montrant les avantages et les inconvénients de chacune, et en terminant par mettre en évidence les facteurs limitant leurs performances. Nous avons évoqué aussi les différents schémas et stratégies de partitionnement des données sur des sites dispersés puisque le partitionnement est à la base de la réalisation du parallélisme des traitements. Comme nous avons présenté les différentes formes de parallélisme pouvant être adoptées dans de tels systèmes. Sachant qu on a marqué l intérêt du partitionnement dynamique par rapport au partitionnement statique, nous aborderons dans le chapitre suivant une des classes du partitionnement dynamique. Il s agit bien des structures de données distribuées et scalables (SDDSs). 15

29 Chapitre II Les structures de données distribuées et scalables SDDS 1. Introduction : Les multiordinateurs sont de plus en plus utilisés en entreprises, et suscitent encore plus l intérêt des chercheurs motivés par le potentiel de stockage et d accès rapide que présentaient ces configurations. Configurations composées de PCs interconnectés par des réseaux à hauts débits. L exploitation de données réparties sur un multiordinateur a rendu nécessaire l adoption de nouvelles structures de données. En effet, c était en 1993 que Litwin [Litwin 93] a proposé une structure de données, appelée SDDS (Structure de Données Distribuées et Scalable), permettant de gérer des fichiers distribués sur un multiordinateur. Les données d une SDDS peuvent résider sur disques comme elles peuvent l être en RAM distribuée. Et, c est cette dernière alternative qui a été préférée vu le temps d accès très rapide qu elle permet et sachant la quantité mémoire très élevée disponible sur l ensemble du multiordinateur. Plusieurs variantes de la SDDS proposée par Litwin se sont suivies, et plusieurs prototypes ont été développés dans les grands centres de recherches afin de prouver l efficacité de ces nouvelles structures de données. Ce chapitre présentera une étude des SDDS, en décrivant les principes, les règles d utilisations, ainsi que les différentes classes existantes. 2. Principe des SDDS : Les structures de données distribuées et scalables (SDDS) sont de nouvelles structures de données applicables à des architectures client-serveur. 16

30 Chapitre II/ Les structures de données distribuées et scalables SDDS Les données d un fichier distribué sont stockées sous forme de fragments appelés : cases, (bucket en anglais) dans les mémoires centrales des sites serveurs et accédées par des sites clients à l aide de requêtes. Les données sont initialement stockées dans un seul serveur, puis sont étendues vers de nouveaux serveurs par insertion de nouvelles données, d où une capacité de stockage illimitée. Les SDDS présente également l avantage d un traitement parallèle augmentant les performances d accès quel que soit la taille des données manipulées, sachant qu il est beaucoup plus rapide d accéder à des données se trouvant dans la mémoire d une machine distante que sur un disque, même local [Gray 93]. 3. Règles d utilisation des SDDS : L utilisation des SDDS doit respecter les règles suivantes : [Litwin94] a. Pas de répertoire central d accès : afin d éviter les goulots d étranglements engendrés par un point commun d accumulation et entrainant des temps d accès élevés aux fichiers. b. Extension du fichier SDDS suite à des insertions d une manière incrémentale et transparente pour l application (client) : A chaque surcharge d un fichier sur un site, il est éclaté et transféré en partie vers un nouveau site. Un nombre infini de sites peut être utilisé à cet effet. c. Gestion autonome du client de sa propre image de la structure du fichier SDDS tout en supportant le logiciel propre aux SDDS. Les modifications du schéma de la structure du fichier SDDS, dues aux éclatements, ne sont pas diffusées d une manière synchrone aux clients, entrainant une inexactitude de l image du client, et des erreurs d adressage des sites serveurs. 17

31 Chapitre II/ Les structures de données distribuées et scalables SDDS d. Détection des erreurs d adressage à la charge des serveurs, qui doivent dans ce cas rediriger les requêtes vers un autre serveur susceptible d être le correct. Sinon, d autres redirections vont s avérer nécessaires. La conception doit garantir un nombre de redirection réduit. L un des serveurs ayant redirigé une requête doit transmettre au client un message correctif appelé : IAM (Image Adjustment Message), afin que celui-là puisse ajuster son image. Blocs du fichier Serveurs en RAM Redirection SGF Calcul d adresse Interconnexion réseau IAM Clients Image de client Clients Figure. II.1. Fichier classique vs SDDS 4. Caractéristiques d une SDDS : Plusieurs propriétés caractérisent les SDDS [Litwin 96]. On note principalement : la scalabilité, et la disponibilité. a. La scalabilité : La scalabilité est la possibilité de gérer un fichier grandissant et accédé par davantage de clients avec les mêmes performances d accès [Gray 93] [Gray 99]. C est une caractéristique des architectures multiprocesseur. La scalabilité d un système est caractérisée par deux principaux facteurs : 18

32 Chapitre II/ Les structures de données distribuées et scalables SDDS Facteur de rapidité (ang : Speed-up): mesure le temps de réponse d une requête par rapport au nombre de nœuds avec un même volume de données. Dans un système scalable, si le nombre de nœud augmente d un facteur n, alors le temps de réponse diminue d un facteur n. Figure. II.2. Courbe du facteur de rapidité Facteur d échelle (ang : scale-up) : mesure la conservation du temps de réponse d une requête par rapport à une augmentation de la taille de la base de données et des capacités de la configuration. Dans de tels systèmes, si la taille de la base de données augmente d un facteur de n, alors il suffit d augmenter la capacité de la configuration. Figure. II.3. Courbe du facteur d échelle 19

33 Chapitre II/ Les structures de données distribuées et scalables SDDS b. La disponibilité : Propriété assurée par l ajout de serveurs de parité à la structure distribuée, ou par duplication des données afin d assurer un fonctionnement continu sans interruption même en cas de panne. c. La distribution : Les données et les répertoires d accès sont distribués entre plusieurs sites du réseau, permettant ainsi un traitement parallèle et distribué. 5. Classification des SDDS : Plusieurs SDDS ont été définies jusqu à présent. Considérant l organisation interne des données et le mécanisme qui permet d y accéder, les SDDS peuvent être classées en les catégories suivantes : a. SDDS basées sur les arbres : Elles étendent les structures ordonnées traditionnelles (B-arbres, Arbres de recherche binaires) aux environnements distribués. La SDDS la plus connue de cette classe est RP*. RP* (distributed Range Partitionning) est une structure basée sur les principes des arbores B+ développée dans le laboratoire CERIA à l université Paris-Dauphine [Litwin 94]. Elle distribue un fichier sur un ensemble de serveurs (cases), en associant à chaque serveur un intervalle de valeurs de clés. A la suite de plusieurs insertions de données, une case d un serveur peut subir un éclatement dû au fait que la capacité de la case a été atteinte. L éclatement consiste a transférer approximativement la moitié du contenu de la case surchargée vers une nouvelle case RP*. 20

34 Chapitre II/ Les structures de données distribuées et scalables SDDS b. SDDS basées sur le hachage : Le hachage est efficace pour l adressage scalable et distribué utilisant la clé. W. Litwin était le premier à proposer une SDDS basée sur le hachage linéaire. Il s agit de LH* [Litwin 93] qui était une adaptation du hachage linéaire LH (LinearHashing) [Litwin 80] aux environnements distribués. Ensuite, plusieurs variantes ont vu le jour, telles que: - LH*LH [Karlson 96], - LH*s [Litwin 97a] - LH*RS [Litwin 04] qui est une version LH* à haute disponibilité. Sont suivies de plusieurs autres SDDS, telles que : - DDH (Distributed Dynamique Hashing) [Devine 93] qui est une version scalable et distribuée du hachage dynamique DH. - Et encore EH*[Hilford 97] et IH* [Boukhalef 02]. Structure de Données SDDS Classiques Hachage Arbre - LH* - LH* LH - LH* g - LH* RS - DDH - - RP* - RP* N - RP* c - RP* s - DRT - Figure. II.4. Les familles de SDDS 21

35 Chapitre II/ Les structures de données distribuées et scalables SDDS 6. Etude de LH : 6.1. Principe : LH (Linear Haching) [Litwin 80] était l une des meilleures techniques de hachage virtuel, puisque d une part elle a besoin de très peu de mémoire pour son fonctionnement, et d autre part les recherches se font généralement avec un seul accès. Un fichier est composé de N cases LH numérotés de 0 à N-1, chacune de taille = b enregistrements. Un pointeur p pointe la case prochaine à éclater. i=0 b>>1 Case 0 Case 1 Case N-1 Figure. II.5. Etat initial d un fichier LH de N cases A chaque clé est associée une adresse de case. Cet adressage est calculé à l'aide de la fonction de hachage : h i (clé)=clé mod 2 i N où : N : est le nombre initial de cases (généralement pris égal à 1), i : le niveau du fichier ; i est initialisé à 0 et s incrémente de 1 à chaque fois que la taille du fichier double. La taille du fichier double lorsque toutes les cases sont éclatées chacune en 2. L algorithme qui permet de déterminer pour chaque clé son adresse est le suivant : a = h i (clé) ; si a <p alors a = h i+1 (clé) ; Algorithme. II.1. Algorithme de calcule de l adresse d une clé. 22

36 Chapitre II/ Les structures de données distribuées et scalables SDDS 6.2. Extension du fichier : Lorsque la taille maximale de la case est dépassée, un débordement est signalé, et un éclatement de case doit se faire. De tels systèmes sont dits : LH non contrôlés. Dans ces systèmes, le taux de remplissage du fichier est de 65-69% [Litwin 93, Benga 00]. Ce taux peut être amélioré, en ajoutant des contraintes conditionnant l éclatement des cases, par exemple la procédure d éclatement se fait si le taux de remplissage actuel est supérieur à un certain seuil t. De tels systèmes sont dits : LH contrôlés. La case qui va éclater n'est pas forcément celle qui a débordé mais celle dont le numéro correspond au pointeur d'éclatement p (initialement p vaut 0). Après chaque éclatement, p est incrémenté de 1 pour pointer la case suivante à éclater. Il ne redevient nul que s'il est strictement supérieur à 2 i *N. Si la case éclatée n est pas celle qui a débordé, une zone de débordement sera créée pour celle-ci. Notons que cette case finira par éclater et la zone de débordement sera éliminée, vu que l ordre du choix de la case à éclater est séquentiel. L'éclatement d'une case provoque la création d'une nouvelle case dans le fichier LH. Les clés contenues dans la case qui éclate vont être redistribuées par la fonction de hachage h i+1 qui sera associée à la case qui éclate et à la nouvelle case. Les cases qui n'ont pas encore éclaté ont une fonction de hachage associée qui est h i. Les éclatements se font dans un ordre déterministe : 0.. N-1, 0..2 i *N-1, etc. A chaque niveau i du fichier, on utilise au maximum deux générations de fonctions de hachage : h i+1 : pour les cases éclatées une autre fois après l éclatement numéro i. h i : pour les cases n ayant éclaté que i fois. 23

37 Chapitre II/ Les structures de données distribuées et scalables SDDS h 1 h 0 h 1 N=2 i=0 p= Case 0 Case 1 Case 2 Figure. II.6. Fichier LH après éclatement de la case 0 L algorithme utilisé pour mettre à jour le couple (i, p) après un éclatement d une case est le suivant : p = p +1 ; si p >=2 i *N alors p =0 ; i=i+1 finsi ; Algorithme II.2. : Mise à jour du couple (i, n) après un éclatement d une case Fusion dans le fichier : Le phénomène inverse de l éclatement est la fusion. Phénomène déclenché suite à des suppressions répétitives dans le fichier diminuant le taux de remplissage. Avec un taux inférieur à un certain seuil t, l algorithme utilisé pour mettre à jour le couple (p, i) est le suivant : p = p -1; si p <0 alors i=i-1; p=2 i *N -1 finsi ; Algorithme II.3. Mise à jour du couple (i, n) après la fusion de deux cases 24

38 Chapitre II/ Les structures de données distribuées et scalables SDDS 7. Etude de LH* : 7.1. Principe général : LH* [Litwin 93] [Litwin 96] consiste à mettre chaque case du fichier sur un serveur différent d un multi-ordinateur. Chaque case étant chargée dans la RAM du serveur. Le niveau j de la fonction de hachage (hj (clé) = clé mod 2 j ) est stocké dans l'en-tête de chaque case LH*. Chaque client maintient son image qui consiste aux deux indices i et p ; i' est la valeur présumée du niveau du fichier i dans l'image du client et p' est la position présumée de p. p étant le pointeur du prochain serveur qui doit éclater. Initialement i' = p' = 0. Serveurs j j j j j: niveau de la fonction de hachage i,p i,p i,p i,p Clients Figure. II.7. Principe de l algorithme LH* 7.2. Calcul d adresse au niveau du client : Le client envoie sa requête (insertion, modification, suppression ou de lecture ) relative à la clé au serveur numéro a en appliquant l algorithme suivant [Litwin 93] [Litwin 96] pour le calcul de l adresse du serveur destinataire : 25

39 Chapitre II/ Les structures de données distribuées et scalables SDDS a = h i (clé) si a < p alors a = h i +1 (clé) ; Algorithme II.4. Adressage d un serveur par un client 7.3. Calcul d adresse au niveau du serveur : Le serveur recevant la requête du client vérifie si elle lui est correctement destinée en recalculant l adresse avec son propre paramètre : j ; sinon il l a transmet au serveur d adresse déterminée (a ). a = h j (clé) si a <> a alors a = h j-1 (clé) ; si (a >a) et (a <a ) alors a =a Algorithme II.5. Vérification de l adressage par le serveur D après [Litwin 93], dans le pire des cas, il y a deux messages d'expédition, ou trois cases visitées. Après éventuellement quelques redirections de la clé, l un des serveurs ayant participé à la redirection de la requête envoie un message correctif au client ayant fait l'erreur d'adressage. Le message IAM contient le niveau j de la case où le client a envoyé la clé. Le client met alors à jour son image (i' et n') Réajustement de l image du client : L algorithme de mise à jour de l image du client est le suivant [Litwin 93] [Litwin 96]: 26

40 Chapitre II/ Les structures de données distribuées et scalables SDDS i =j-1 p = a +1 (a : numéro du serveur ayant transmis l IAM). si p >= 2 i alors p =0 ; i =i +1 finsi; Algorithme II.6.: Ajustement de l image client Cet algorithme doit être exécuté par le client recevant un message d ajustement d image (IAM) comportant le niveau actuel de la case (j) et l adresse logique du serveur émetteur a Extension d un fichier LH* Un fichier LH* est étendu de la même manière qu un fichier LH, à travers le mouvement linéaire du pointeur et l éclatement de chaque case p. Les valeurs de j et p sont maintenues par un site appelé Site Coordinateur (SC) ; par exemple le serveur 0, qui doit déterminer quelle case éclater et quand? De la même façon qu avec LH, on distingue deux types d éclatements : éclatement contrôlé et éclatement non contrôlé. c. Eclatement non contrôlé : A la réception d un message d un serveur ayant subi une collision, le coordinateur transmet un message de demande d éclatement au serveur p qui met à jour les valeurs de p et de i comme indiqué pour LH. Le serveur (de niveau j) ayant reçu le message d éclatement, exécute les étapes suivantes : - Créer une case (serveur) de numéro 2 j +p de niveau j+1. - Eclate sa propre case en appliquant la fonction h j+1, et transmet les éléments correspondants à la nouvelle case. - Met à jour j=j+1, et - Confirme l éclatement au coordinateur. 27

41 Chapitre II/ Les structures de données distribuées et scalables SDDS d. Eclatement contrôlé : Cet éclatement est déclenché à chaque fois que le taux de remplissage des cases passe au-dessus d un seuil maximal prédéfini, suite à une opération d insertion Fusion dans un fichier LH* : La fusion est provoquée par un taux de remplissage passant au-dessous d un seuil minimal calculé suite à des opérations de suppression. Une stratégie proposée par litwin [Litwin 96], dans ce cas, consiste en les étapes suivantes : - Un serveur s transmet un message au coordinateur suite à une opération de suppression, en lui communiquant le nombre d éléments dans la case (soit x). - Le coordinateur calcule d=x/b (b=taille d une case), et met d=d*2 si s<p ou s>=2 i. - Le coordinateur calcule ensuite : taux = (2 i *d)/(2 i +p). - Si taux < seuil_min, le coordinateur convoque le serveur p pour déclencher une fusion. - Au retour d appel, le coordinateur met à jour p et i comme indiqué pour LH Variantes de LH* : Plusieurs variantes du schéma LH* ont été proposées après le premier schéma proposé par litwin [Litwin 93]. On distingue essentiellement les suivantes : LH*LH [Karlson 96] est une variante de LH* visant les architectures multiprocesseurs sans partage. Ce schéma utilise un premier niveau d index correspondant à LH*, permettant aux clients d accéder aux serveurs. Le deuxième niveau d index correspond à l organisation interne des cases de données suivant l algorithme LH. 28

42 Chapitre II/ Les structures de données distribuées et scalables SDDS LH*M (with Mirroring) [Litwin 96] : C est une SDDS a tolérance de fautes (fault tolerant). Un fichier LH*M consiste en deux fichiers LH* indépendants F1 et F2 appelés miroirs (mirrors. Chaque modification sur un des deux fichiers (insertion ou suppression) est propagée à l autre miroir. Des algorithmes sont utilisés pour la cohérence du miroir ainsi que pour la récupération d informations et le remplacement de serveurs. Le principal inconvénient de cette SDDS est le coût de stockage qui est facteur du nombre de répliques. LH*S (with Stripping) [Litwin 97 a] : Cette SDDS utilise le partitionnement, en fragmentant chaque enregistrement en k segments. Chaque segment est inséré dans un fichier segment Si contenant tous les segments si de tous les enregistrements. A chaque enregistrement est ajouté un segment sk+1 appelé segment de parité, calculé à partir des segments s1, s2,, sk et est inséré dans le fichier segment Sk+1. Un fichier LH*S est un ensemble de k+1 fichiers LH* indépendants appelés fichiers segment. La gestion de l ensemble des fichiers segment ainsi que la récupération est effectuée par un seul coordinateur SC. Notons que cette SDDS LH*S nécessite moins d espace de stockage que la SDDS LH*M mais les opérations de mises à jour demandent plus de temps et utilisent plus de messages. LH*G (with Record Grouping) [Litwin 97 b] : Cette SDDS ajoute un autre mécanisme de haute disponibilité au schéma LH*. Des pages de parités sont ajoutées par groupe d enregistrements afin d augmenter la disponibilité du fichier. Des algorithmes spécifiques à la méthode décrivent la création des pages de parité ainsi que la récupération des pages manquantes. LH*SA (Scalable Availability) [Litwin 98] : Cette SDDS étend le schéma LH*G pour pouvoir récupérer plusieurs erreurs en même temps. Ceci est rendu possible par l utilisation de plusieurs fichiers LH* de parité. 29

43 Chapitre II/ Les structures de données distribuées et scalables SDDS 8. Conclusion : Dans ce chapitre, nous avons détaillé les principes de bases des SDDS, tout en mettant en évidence leurs avantages par rapport aux structures de données classiques. Nous avons présenté les différentes classes de SDDS, et nous nous sommes étalés sur la SDDS LH*. Cette dernière étant la structure choisie pour être implémentée dans le prototype à réaliser. Puisqu on doit implémenter la structure LH* pour la validation des transactions réparties, le chapitre suivant reprendra les notions de base des transactions d une façon générale, et des transactions réparties plus particulièrement. 30

44 Chapitre III Les transactions 1. Introduction : Sachant que nous tentons la validation atomique d une transaction répartie, il est indispensable à ce niveau de rappeler les notions de base concernant les transactions d une façon générale et en particulier les transactions réparties. Nous nous intéresserons alors, dans ce chapitre, à la définition, aux propriétés des transactions, et à la journalisation des transactions. Comme, nous décrirons, le système transactionnel centralisé et par la suite le système transactionnel réparti. 2. Définition d une transaction : La notion de transaction a été introduite afin d isoler les unités de traitements respectant la cohérence de la base de données, [Gardarin 94], ainsi une transaction est définie comme : Une unité de traitement séquentiel, exécutée pour le compte d un usager, qui appliquée à une base de données cohérente, restitue une base de données cohérente. Une transaction est constituée d unités de traitements plus fines appelées : actions. On distingue essentiellement, parmi ces actions : - Read(x) : lire la donnée x. - Write(x) : enregistrer la donnée x. - Commit : valider la transaction. - Abort : annuler les effets de la transaction. Il est à noter que dans la plupart des systèmes, les modifications des données par les transactions sont tout d abord exécutées dans des tampons en mémoire cache. L enregistrement dans la base ne s effectuera que lors de la validation de la transaction. 31

45 Chapitre III/ Les transactions 3. Les propriétés ACID des transactions : Une transaction est aussi l unité de traitement qui doit satisfaire les quatre propriétés, appelées propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité) [Bernstein 87] : - Atomicité : Chaque transaction doit s'exécuter entièrement ou alors tous ses effets partiels (sur la BD) seront annulés. Cohérence : Aucune transaction ne doit laisser la BD (lors de sa terminaison) dans un état incohérent (relativement aux contraintes d'intégrités). Isolation : L'état intermédiaire (de la BD) généré par une transaction ne doit pas être visible par les autres transactions concurrentes. Durabilité: Une transaction validée ne peut plus être annulée. 3. Le système transactionnel : Le système de transactions se compose de trois modules [Hidouci 09] : - le gestionnaire des transactions (TM : transaction manager), - le gestionnaire de concurrence ( CM : concurrence manager) - et le gestionnaire de données (DM : Database Manager) - Le gestionnaire de transaction (TM Transactions Manager) : le gestionnaire de transaction permet : - d identifier les transactions, - d orienter les opérations vers le gestionnaire de concurrence, - et de coordonner la validation atomique dans le cas de transactions réparties. 32

46 Chapitre III/ Les transactions Transaction 1 Transaction 2 Transaction n Gestionnaire de transactions (TM) Gestionnaire de concurrence(cm) Gestionnaire de Données (DM) Base de données Figure III.1. Schéma général d un système transactionnel - Le gestionnaire de concurrence (CM concurrence manager): contrôle l'ordre d'exécution des opérations des transactions afin de maintenir la propriété d isolation, et gère éventuellement l interblocage. Il peut suspendre ou annuler une opération d une transaction, en implémentant : le verrouillage, l estampillage, la certification ou le graphe de sérialisation. - Le gestionnaire de données et de recouvrement (DM Database Manager) : exécute les requêtes read, write réellement sur la base de données. Il implémente en plus les techniques de reprise et de points de contrôle. Le schéma suivant indique la position du système transactionnel dans un système de BD centralisé. 33

47 Chapitre III/ Les transactions Client 1 Client 2 opérations résultats SQL Optimiseur TM CM D M Buffers BD Client n Système transactionnel Figure III.2. Architecture globale d un système de BD centralisé 4. La journalisation des transactions (Log-Based Recovery) : Afin de pouvoir reprendre suite à une panne, le système transactionnel doit garder la trace des mises à jour réalisées par toutes les transactions. Une des méthodes des plus utilisées est la journalisation Définition : Le journal (ou log) est une séquence d enregistrements (enregistrements journal), enregistrant toutes les activités de mise à jour de la base de données Types d'enregistrements du journal : On distingue plusieurs types d enregistrements du journal : a. Enregistrement de mise à jour (update log record) : Décrit une simple opération d écriture (write) sur une base de données. Il présente les champs suivants : 34

48 Chapitre III/ Les transactions L'identificateur de transaction : est l'identifiant unique de la transaction qui a exécuté l opération du Write. L'identificateur de donnée élémentaire : est l'identifiant unique de la donnée élémentaire mise à jour. Typiquement, c'est l'emplacement sur le disque de la donnée élémentaire. La vieille valeur : est la valeur de la donnée élémentaire avant le Write. La nouvelle valeur : est la valeur que la donnée élémentaire aura après le Write. On note alors : <Ti, Xj, V1, V2> qui signifie que la transaction Ti a réalisé un write sur la donnée Xj en remplaçant la valeur V1 par la valeur V2. b. Enregistrements spéciaux : D'autres enregistrements spéciaux de journal existent pour enregistrer des événements significatifs pendant le traitement de transaction, tel que le début d'une transaction et l'engagement ou l'arrêt d'une transaction : <Ti start> La transaction Ti a démarré. <Ti commit> La transaction Ti a validé. <Ti abort> La transaction Ti a annulé. Note : Le journal doit résider dans la mémoire stable Le protocole WAL : [Gray 77] Afin de pouvoir annuler ou refaire toute transaction dans tous les cas de panne, deux règles définies sous le nom du protocole WAL (Write Ahead Log) doivent être appliquées. Elles consistent à écrire des informations redondantes dans le journal avant toute écriture dans la base de données : 1. Avant d écrire dans la base de données la valeur d un objet modifié par une transaction non validée, des informations permettant de compenser cette écriture 35

49 Chapitre III/ Les transactions (l image avant) doivent être notées dans le journal ; cette règle permet d assurer l atomicité et s appelle : règle du UNDO. 2. Avant de valider, une transaction doit noter dans le journal les informations permettant de refaire les modifications faites (les images après) aux objets de la base de données ; règle permettant d assurer la durabilité, et s appelle : règle du REDO. TAMPONS JOURNAL BASE DE DONNEES Figure III.3. Ordre d exécution des mises à jour Remarque : Sachant qu une écriture sur disque des enregistrements journal coûte cher, on utilise un tampon journal (log-buffer) et on reporte l écriture du journal sur disque : - A chaque commit de transaction. - Quand le tampon journal est plein Déroulement de la journalisation : Les étapes liées à la journalisation lors de l exécution d une transaction Ti sont les suivantes : - Avant qu'une transaction Ti ne commence son exécution, le système sauve l enregistrement < Ti start> dans le journal. - Pendant l exécution de n importe quel Write (X) par Ti, celle-ci est précédée par l'écriture du nouvel enregistrement approprié de mise à jour dans le journal. 36

50 Chapitre III/ Les transactions - Quand Ti valide partiellement, le système sauve le <Ti commit> dans le journal. Le système de recouvrement utilisera les deux procédures de reprise suivantes : undo(ti) : pour restaurer les valeurs de toutes les données élémentaires mises à jour par Ti aux anciennes valeurs. redo(ti) : pour positionner les valeurs de toutes les données élémentaires mises à jour par Ti aux nouvelles valeurs. Après qu'une panne se soit produite, le système de recouvrement consulte le journal pour déterminer quelles transactions doivent être refaites (redo), et lesquelles ont besoin d'être défaites (undo) : Ti doit être défaite si le journal contient <Ti start>, mais ne contient pas<ti commit>, c'est-à-dire non encore validée. Les données reprennent les valeurs initiales. Ti doit être refaite si le journal contient <Ti start>, et <Ti commit>. Les données recevront les nouvelles valeurs Points de reprise : Quand une défaillance du système se produit, le journal est parcouru en entier pour déterminer les transactions qui doivent être refaites et celles qui doivent être défaites. Ce qui est entrainera une perte de temps énorme, sachant que le processus de recherche sera très long et que certaines transactions vont être refaites inutilement. Pour réduire ces pertes de temps, on a introduit la notion de point de reprise (Checkpoint). Un point de reprise est la sauvegarde (périodique) de certaines informations en mémoire stable durant le déroulement normal des transactions, afin de réduire la quantité de travail que doit faire la procédure de reprise après une panne. Une mémoire stable est caractérisée par le fait que l'information qui y inscrite n est jamais détruite. Caractéristique impossible théoriquement à obtenir, mais peut être 37

51 Chapitre III/ Les transactions étroitement rapprochée par les techniques qui rendent la perte de données extrêmement peu probable. 6. Transaction distribuée : Une transaction répartie ou distribuée est une transaction dont les opérations manipulent des données distribuées sur plusieurs sites. Une transaction répartie est décomposée en autant de branches que de sites accédés. 7. Structure d un système de transaction distribué : Chaque site a son propre Gestionnaire des transactions local, dont la fonction est d'assurer les propriétés ACID de ces transactions qui s exécutent dans ce site. Les divers Gestionnaires des transactions coopèrent à exécuter des transactions globales. Chaque Gestionnaire de transactions est responsable des tâches suivantes : La mise à jour d'un journal pour la reprise. Participer à un contrôle de concurrence pour coordonner l'exécution simultanée des transactions s exécutant dans ce site. Lors d une transaction répartie, le gestionnaire de transaction lançant la transaction est désigné comme : coordinateur de transaction, vu qu il doit coordonner l'exécution des diverses transactions (locales et globales) lancées dans ce site. Le coordinateur est responsable de : Commencer l'exécution de la transaction. Diviser la transaction en un certain nombre de sous-transactions et distribuer ces sous-transactions aux sites appropriés pour l'exécution tout en coordonnant l'arrêt de la transaction, qui peut avoir comme conséquence la validation de la transaction par tous les sites ou son annulation par tous les sites. 38

52 Chapitre III/ Les transactions Site i Site j Site k Coordinateur de transaction Gestionnaire de transactions Gestionnaire de transactions Gestionnaire de transactions Contrôleur de concurrence Gestionnaire de Données et recouvrement Contrôleur de concurrence Gestionnaire de Données et recouvrement Contrôleur de concurrence Gestionnaire de Données et recouvrement Fig III.4. Structure d un système de transaction distribuée 8. Conclusion : Ce chapitre a repris les notions, concernant les transactions, qui seront à la base de la suite de notre étude, en particulier les propriétés ACID des transactions (Atomicité, Cohérence, Isolation, durabilité), pour lesquelles le chapitre suivant reprendra en détail une propriété principale dans l exécution de toute transaction, en l occurrence l atomicité. La propriété d atomicité demeure donc une propriété essentielle à toute exécution de transaction et en particulier les transactions distribuées, exécutées sur plusieurs sites, et lesquelles doivent être exécutées en totalité ou pas. Le protocole qui permet de vérifier cette propriété dans un environnement distribué est appelé : protocole de validation atomique. Il fera donc l objet du chapitre suivant. 39

53 Chapitre IV La validation atomique 1. Introduction : Les systèmes logiciels avancés exigent de plus en plus des garanties de fiabilité afin d assurer des résultats déterministes en présence de pannes. Dans les systèmes de base de données, ces garanties sont fournies par la propriété d atomicité qui assure qu une transaction est exécutée soit en totalité, soit pas. Dans les systèmes de bases de données réparties, ces garanties sont atteintes par le protocole dit de validation atomique. La validation atomique assure que tous les sites participants à une transaction répartie prennent la même décision : soit tous qui valident, soit tous qui annulent. Ce protocole doit être lancé à la fin d'une transaction distribuée par le coordinateur de transaction. C est un protocole qui doit permettre une résistance aux pannes. Le protocole le plus populaire est le protocole de validation à deux phases ou protocole 2PC (Two Phase Commit), que nous présenterons dans cette partie ainsi que ses variantes et optimisations. 2. Spécifications de la validation : Sachant que chaque site participant à une transaction répartie doit contribuer à la décision finale en votant par OUI ou NON, et sachant qu un site qui vote OUI est prêt à rendre ses modifications permanentes, le protocole de validation atomique doit vérifier les propriétés suivantes [Krakowiak 2004]: - Validité : La décision finale est soit valider, soit annuler. - Intégrité : Tous processus décide au plus une fois, c-à-d qu une décision est définitive. 40

54 Chapitre IV/ La validation atomique - Accord uniforme : Tous les processus qui décident prennent la même décision. - Justification : Si la décision est valider, alors il y a au moins x processus qui ont voté OUI (x dépend de la variante 2PC utilisés et est égal au nombre de participants dans la pratique). - Cette propriété n est pas symétrique, car la décision d annuler peut être prise même si tous les processus auront voté OUI (cas d un processus qui vote OUI, ensuite tombe en panne). - Obligation ou Non trivialité : Si x processus votent OUI, et si ces x processus sont corrects, alors la valeur décidée est : valider. En pratique, elle est égale n. Cette propriété [Babaoglu 93] exclut la solution triviale au problème dans laquelle les participants décident toujours d'abandonner la transaction. - Terminaison : Tout processus correct décide au bout au bout d un temps fini, donc tous finissent par décider. 3. Le protocole de validation biphasé (2PC = Two-Phase Commit Protocol) : [Gray 77] [Lampson 76] 3.1. Principe : Considérons une transaction distribuée T lancée par un site S, où le coordinateur de transaction est C. Le protocole 2PC est lancé par C, quand T termine son exécution ; ce qui correspond au moment où tous les sites exécutant T informent C que T a terminé. Le protocole 2PC est formé de deux phases: une phase de vote (phase 1) et une phase de décision (phase 2). Phase 1 : 1. C envoie un message de demande de vote, appelé message prepare, à tous les participants. 2. À la réception d'un tel message, le Gestionnaire des transactions de chaque site 41

55 Chapitre IV/ La validation atomique détermine s'il est disposé à valider sa partie de T. Si la réponse est non, il répond en envoyant un message d annulation de T à C. Si la réponse est oui, il répond alors avec un message prêt de T à C. Phase 2 : 1. Quand C reçoit les réponses au message de la préparation T de tous les sites, ou quand un intervalle pré-spécifié de temps s'est écoulé depuis que le message de la préparation T a été envoyé, C peut déterminer si la transaction T peut être validée ou annulée. La transaction T peut être validée si C recevait un message prêt de T de tous les sites participants. Autrement, la transaction T doit être annulée. 2. A ce point, le coordinateur informe tous les sites participants de sa décision en envoyant un commit (valider) ou un abort (annuler). Les participants répondent alors par des acquittements. Coordinateur Processeur 1 Processeur 2 Phase I D Demande de préparation Réponse(vote) P/A Demande de préparation Réponse(vote) P/A Phase II V/A Décision Acquitter V/A Décision Acquitter V/A F Ecriture forcée Ecriture non forcée P/A : Prêt ou Annuler V/A : Valider ou Annuler D : Début F : Fin Figure IV.1. Le protocole 2 PC de base 42

56 Chapitre IV/ La validation atomique 3.2. Résistance aux pannes : Les écritures journal : Sachant que 2PC doit permettre une résistance aux pannes, des écritures sur journal sont prévues au niveau du site coordinateur et de chaque site participant. On distingue deux types d'écriture dans un journal [Abdellah 98]: Une écriture non forcée : dans le cas où l'enregistrement correspondant est mémorisé dans un journal en mémoire puis reporté de façon asynchrone sur disque. Une écriture est dite forcée : le cas où le report immédiat du contenu du journal est imposé sur disque. Le résultat d'une écriture forcée n'est jamais perdu en cas de panne. Les écritures journal des participants sont comme suit : Pendant l'exécution de la transaction, une écriture non forcée de chaque opération exécutée. Pendant l'exécution du protocole, une écriture forcée du vote ainsi qu'une écriture forcée de la décision reçue du coordinateur. Quant au coordinateur, les écritures journal sont : une écriture non forcée du démarrage du protocole, une écriture forcée de la décision et une écriture non forcée de la fin de transaction. L'écriture forcée de la décision garantit qu'une fois la décision prise, elle ne peut être perdue même si le coordinateur tombe en panne. L'écriture non forcée de fin de transaction est un moyen pour le coordinateur d'oublier cette transaction et de purger ultérieurement son journal. Cette écriture ne peut avoir lieu qu'après avoir reçu l'acquittement de la décision de la part de tous les participants, qui s'engagent par cette action à ne plus jamais interroger le coordinateur sur la décision prise même en cas de panne. 43

57 Chapitre IV/ La validation atomique Les enregistrements du journal : Parmi les enregistrements devant être inscrits dans le journal du coordinateur ou ceux des participants : Commit T : valider la transaction. Abort T : annuler la transaction. Ready T : se mettre à l état prêt. Start T End T : démarrer la transaction. : mettre fin à la transaction Traitements des pannes : a. Panne d'un site participant. Lors d une panne d un site participant, deux cas se présentent au coordinateur C : C n a pas reçu de message prêt du site en panne au bout d un délai de garde : il suppose qu'il a répondu avec un message d annulation de la transaction T. Ci a reçu le message le message prêt Ti du site : il exécute le reste du protocole ignorant la panne du site. P1 Coordinateur P2 préparer Prêt valider acquitter préparer Prêt valider Prêt panne reprise valider acquitter Figure IV.2. Panne d un participant après s être déclaré prêt 44

58 Chapitre IV/ La validation atomique P1 Coordinateur P2 préparer préparer Prêt abandon timeout abandon panne acquitter acquitter reprise Figure VI.3. Panne d un participant avant d être prêt Quand un site participant S k récupère d'une panne, il doit examiner son journal pour déterminer le destin de la transaction qui était au milieu de l'exécution quand la panne s'est produite. Nous considérons chacun des cas suivants : Le journal contient l'enregistrement <commit T>. Dans ce cas-ci, le site exécute redo (T). Le journal contient un enregistrement <abort T>. Dans ce cas-ci, le site exécute undo (T). Le journal contient l'enregistrement <ready T>. Dans ce cas-ci, le site doit consulter C pour déterminer le destin de T. Si C est en ligne, il informe S k concernant T si a commis ou s'est interrompu. Dans le premier cas, il exécute redo (T). Dans le dernier cas, il exécute undo (T). Si C est hors ligne, le site S K exécute un protocole dit de terminaison pour tenter de savoir le sort de la transaction chez d autres sites ayant participé à la même transaction. Ce protocole sera décrit plus bas dans ce chapitre. Le journal ne contient aucun ordre de gestion (arrêt, validation, prêt) au sujet de T, S k exécute undo (T). La panne étant survenue avant l envoi du message prêt. 45

59 Chapitre IV/ La validation atomique b. Panne du coordinateur. Si le coordinateur C échoue entre la phase de vote et la phase de décision (période appelée : fenêtre de vulnérabilité), il sera impossible de déterminer si une décision a été prise, jusqu'à ce que le coordinateur récupère. Ainsi, les sites actifs doivent attendre jusqu à ce que C récupère. Pendant ce temps d attente, T peut continuer à tenir des ressources systèmes. Par exemple, si le verrouillage est utilisé, T peut tenir des verrous sur des données aux sites actifs. Ce qui amène à une situation de blocage. P1 Coordinateur P2 préparer Prêt préparer préparer Prêt préparer panne reprise Prêt valider acquitter Prêt valider acquitter Figure IV.4. Panne du coordinateur c. Partition de réseau. Quant au partitionnement d'un réseau, deux possibilités existent : 1. Le coordinateur et tous ses participants restent dans une partition. Dans ce cas-ci, la panne n'a aucun effet sur le protocole d'engagement. 2. Le coordinateur et ses participants appartiennent à plusieurs partitions. Du point de vue des sites dans une des partitions, il s'avère que les sites dans d'autres partitions ont échoué. Les sites qui ne sont pas dans la partition contenant le coordinateur exécutent simplement le protocole 46

60 Chapitre IV/ La validation atomique pour traiter la panne du coordinateur. Le coordinateur et les sites qui sont dans la même partition que le coordinateur suivent l'habituel protocole, supposant que les sites dans les autres partitions ont échoué Inconvénients du protocole 2PC : Le protocole 2PC présente deux principaux inconvénients : - il est bloquant ; si le coordinateur tombe en panne entre la phase de vote et la phase de décision, tous les participants qui sont en attente de la décision finale seront bloqués jusqu'à la reprise du celui-là. Ainsi, la transaction concernée peut détenir des verrous sur des ressources partagées pour une durée indéterminée, pénalisant d'autres transactions du système. - Une perte de temps considérable est enregistrée à cause du nombre important de messages échangés et du nombre d écritures forcées réalisées Protocole de terminaison : Dans le cas où le coordinateur tombe en panne, ou est isolé par une panne dans le réseau de communication, après la phase de vote, un protocole de terminaison [Abdellah 98] peut être utilisé par les participants bloqués tentant de contacter d autres participants pour voir s il y a un participant qui a la décision finale, qui est soit reçue par le coordinateur avant sa panne, soit décidée par le participant lui-même dans le cas d annulation. Le protocole de terminaison ainsi décrit ne résout pas le problème dans le cas où les participants communiquant à la recherche de la décision finale ont tous voté OUI. 4. Variantes du protocole 2PC : Plusieurs variantes du protocole 2PC ont été mises au point [Abdellah 98] et se distinguant les unes des autres par : 47

61 Chapitre IV/ La validation atomique - le nombre de messages échangés - le nombre d écritures forcées dans le journal, - la latence du protocole. La latence d'un protocole de validation est le temps écoulé entre le moment où l'application décide de terminer une transaction et le moment où cette terminaison devient effective pour chaque participant. Elle est exprimée en nombre d'étapes de communication entre le moment où la validation est soumise au coordinateur et le moment où la validation devient effective sur chaque participant. On distingue deux grandes classes de variantes :[Al-Houmaily 10] - les variantes améliorant les performances du protocole 2PC durant une exécution normale, - les variantes réduisant le blocage après une panne. 48

62 Chapitre IV/ La validation atomique Améliorer les performances durant une exécution normale Réduire le blocage après panne 2PC PrA PrC UV L2PC IBM-PrN C2PC D2PC 3PC 4PC OPT-PrA IYV ML-PrA OPT-PrC ML-PrC NPrC EP OPT-3PC IYV-WCC ReSPrA RCT-UP PrA RPrC ReSPrC RCT-UP PrC CL Notes : Two-Phase commit [1976], L2PC:Linear 2PC [1978], UV : unsolicited-vote [1979], 4PC : fourphase commit [1980], D2PC : decentralised 2PC [1981], 3PC : three-phase commit [1981], C2PC : Cooperative 2PC [1981], PrA : presumed abort [1983], ML-PrA : multi-level PrA [1983], PrC : presumed commit [1983], IBM-PrN : IBM s 2PC [1990], EP : early prepare [1990], CL :Coordinator Log [1990], NPrC : New PrC [1993], IYV : implicit yes-vote [1995], IYV-WCC : IYV with a commit coordinator [1996], RPrC : rooted PrC [1997], ReSPrC : restructured PrC [1997], OPT-PrA : optimistic PrA [1997], OPT-PrC : optimistic PrC [1997], OPT-3PC : optimistic 3PC [1997], RCT-UP PrA : restructured-comittree around update-participant PrA [2003], RCT-UP PrC : restructured-comit-tree around updateparticipant PrC [2003] Figure IV.5. : Quelques étapes significatives de l évolution des protocoles de validation atomique [Al-Houmaily 10] 49

63 Chapitre IV/ La validation atomique 4.1. Variantes améliorant les performances du protocole 2PC durant une exécution normale : Le protocole Presumed-Abort (PrA) [MOHAN 86] Le protocole Presumed-Abord (PrA) s intéresse à réduire le nombre de message échangés et le nombre d écritures forcées dans les journaux dans le cas où une transaction abandonne. Si la validation échoue, aucune écriture forcée n est enregistrée dans le journal du coordinateur ni dans celui des participants ayant voté négativement. De plus, aucun acquittement de la décision d abandon n est fait par les participants. En cas de panne du coordinateur, la trace d une transaction annulée peut être perdue. Si, après reprise du coordinateur, un participant réclame l état d une transaction et que le coordinateur ne trouve aucune trace dans son journal, il déduit que la transaction a été annulée : c est le principe de la présomption d abandon. Notons bien que Presumed-Abord est identique à 2PC de base dans le cas d une validation se terminant avec succès. Coordinateur Processeur 1 Processeur 2 Coordinateur Processeur 1 Processeur 2 Phase I D Demande de préparation Réponse(vote) P Demande de préparation Réponse(vote) P D Demande de préparation Réponse(vote ) P Demande de préparation Réponse(vote ) A Phase II V Décision Acquitter V Décision Acquitter V A F Décision F 1/ cas de validation 2/ cas d annulation Figure IV.6. Le protocole Presumed-Abort (PrA). 50

64 Chapitre IV/ La validation atomique Il est à noter que PrA est le choix actuel des normes ISO-OSI et X/OPEN des traitements des transactions distribuées. [Chrysanthis 98] Avec 2PC, PrA a été implémentée sur plusieurs produits commerciaux tels que : DECdtm Services, DEC VMS, Transac s Encina and TUXEDO des laboratoires Unix system. [Chrysanthis 98] Presumed-Commit (PrC) : [MOHAN 86] A l opposé de Presumed-Abort, Presumed-Commit tente le même objectif de réduire le nombre de messages échangés et le nombre d écritures forcées dans les journaux mais dans le cas où la transaction valide. L absence d information concernant une transaction dans le journal du coordinateur est interprétée comme un cas de validation. Les décisions de validation ne sont pas alors acquittées par les participants, et ne sont enregistrées dans leurs journaux que par des écritures non forcées. Le coordinateur doit en plus faire une écriture forcée du démarrage de la transaction ainsi qu une mémorisation de la liste des participants à la transaction. L écriture forcée du démarrage est indispensable lors de la reprise du coordinateur suite à une panne avant la validation, car elle évite que la transaction ne soit faussement présumée validée. Coordinateur Processeur 1 Processeur 2 Coordinateur Processeur 1 Processeur 2 Phase I B Demande de préparation Réponse(vote) P Demande de préparation Réponse(vote) P B Demande de préparation Réponse(vote ) P Demande de préparation Réponse(vote) A Phase II V Décision V Décision V A F Décision Accusé A 1/ cas de validation 2/ cas d annulation Figure IV.7. Le protocole Presumed-Commit (PrC). 51

65 Chapitre IV/ La validation atomique Quant à la liste des participants, elle sera utile pour informer ces participants de l abandon de la transaction, et permettra au coordinateur de purger son journal après avoir reçu l acquittement de tous les participants. Le protocole PrC est plus intéressant que PrA dans le cadre où la majorité des transactions valident. Mais, dans la pratique, PrA est plus adoptée que PrC vu que PrC impose une écriture forcée supplémentaire au démarrage Comparaison de 2PC de base et ses principales variantes : Une comparaison entre le protocole 2PC de base et ses deux principales variantes PrA et PrC est montrée dans les deux tableaux suivants, en distinguant les deux cas de décision : valider et annuler. On déterminera distinctement pour le coordinateur et chaque participant le nombre total d écritures journal, le nombre d écritures forcées et le nombre de messages transmis. (a) Avec une décision : valider Variantes 2PC Coordinateur participant Total Écritures Nombre Total Écritures Nombre enregistrements forcées messages enregistrements forcées messages 2PC de base Presumed Abort Presumed commit (b) Avec une décision : annuler Variantes 2PC Coordinateur participant Total Écritures Nombre Total Écritures Nombre enregistrements forcées messages enregistrements forcées messages 2PC de base Presumed Abort Presumed commit Tableau IV.1 Coût des mises à jour dans les variantes 2PC [Al-Houmaily 10] 52

66 Chapitre IV/ La validation atomique Ainsi, on déduit que la variante PrC sera le meilleur choix pour les systèmes dans lesquels la majorité des transactions sont de mise à jour et terminent par valider. Cependant la variante PrA demeure la plus utilisée. Ceci parce que le coût d une annulation de transaction dans PrA est inférieur au coût d une validation dans PrC Autres variantes : Early Prepare (EP) : [Stamos 90] Le protocole Early Prepare est une variante de PrC où l objectif est de réduire au maximum le nombre de messages échangés pour valider une transaction. Ceci est réalisé en mettant chaque participant dans l état «prêt à valider» après l exécution de chaque opération de la transaction et avant d acquitter l opération. Si au moins une opération échoue pendant l exécution de la transaction, celle-ci est abandonnée. Si toutes les opérations sont exécutées avec succès, le coordinateur enregistre la décision de valider par une écriture forcée, et diffuse la décision à tous les participants sans attendre d acquittement. Ce protocole est considéré à une phase, car la phase du vote est incluse à l exécution de l opération. Par contre, il présente quelques inconvénients : Chaque participant est tenu de déclencher une écriture forcée pour chaque opération qu il exécute pour qu il puisse se mettre à l état «prêt à valider». Le coordinateur doit faire une écriture forcée dans son journal à chaque fois qu'un nouveau participant se joint à la transaction, pour maintenir la liste des participants à une transaction. La fenêtre de vulnérabilité s étend à toute la transaction au lieu que ce soit pour l intervalle entre la phase de vote et la phase de décision. 53

67 Chapitre IV/ La validation atomique Coordinateur Processeur 1 Processeur 2 Coordinateur Processeur 1 Processeur 2 +P Op i +P Op i Prêt R Prêt R +P +P Op j Op j Prêt R Annuler A C valider C valider C A Accusé Annuler A 1/ cas de validation 2/ cas d annulation F Figure IV.8. : Le protocole Early Prepare Coordinator Log (CL) : [Stamos 93] Afin de réduire le nombre d écritures forcées, le protocole Coordinator Log (CL) centralise l ensemble des journaux des participants sur le coordinateur. Les participants sont ainsi tenus d envoyer au coordinateur dans le message d acquittement de chaque opération exécutée, les enregistrements correspondants du journal. Le coordinateur enregistre la décision de validation et les enregistrements de journaux reçus en une seule écriture forcée dans son journal, et ce avant de diffuser la décision aux participants sans attendre d acquittements. Si un participant tombe en panne après la prise de décision et avant qu il valide effectivement, il réclamera à sa reprise les enregistrements transférés au coordinateur pour restaurer les mises à jour effectuées. Notons enfin que le protocole Coordinator Log est comme le protocole early Prepare un protocole à une seule phase. 54

68 Chapitre IV/ La validation atomique Son point fort est que les participants passent dans «prêt à valider» en une seule écriture forcée et ne gère pas une liste dynamique des participants. Cependant, il présente l inconvénient de rendre les participants dépendants du coordinateur Protocole Implicit-Yes Vote (IYV) : [Al-Houmaily 95] Le protocole IYV s inspire du protocole Coordinator Log et propose de ne transmettre au coordinateur que les enregistrements du journal d images d après (Redo Log) pour être utilisé après reprise d une panne d un participant. Toutefois, chaque participant continue à gérer son journal localement, permettant ainsi une certaine autonomie aux participants. Ce protocole comme ses prédécesseurs se déroule en une seule phase, phase équivalente à la phase de décision du protocole PrA. Une autre caractéristique de ce protocole est qu après avoir exécuté une opération, un participant transmet avec le message d acquittement la liste des verrous posés en lecture par cette opération, et ce en plus des enregistrements du journal. Ce qui permet au coordinateur, en cas de panne du participant de restaurer le contexte d'exécution de la branche de transaction localement abandonnée et ainsi de poursuivre l'exécution de la transaction globale Variantes du protocole 2PC réduisant le blocage après une panne : Le protocole de validation triphasé 3PC : [Skeen 81] Le protocole de validation triphasé était le premier protocole non-bloquant qu a été proposé. Il constitue une extension du protocole 2PC, en proposant une troisième phase entre la phase de vote et la phase de validation, appelée : phase de pré-validation, 55

69 Chapitre IV/ La validation atomique qui permettra aux participants corrects, en cas de panne du coordinateur, de prendre une décision uniforme sans attendre les sites incorrects. Pendant cette phase, le coordinateur reçoit les votes des participants. Il prend la décision d annuler si un ou plusieurs décident d annuler, sinon il envoie un message de demande de pré-validation à tous les participants et attend les acquittements. Si le coordinateur reçoit les messages d acquittement de tous les participants, il prend la décision finale de valider, et informe les participants de sa décision, qui doivent acquitter par la suite. En cas de panne du coordinateur, les participants en attente du message de prévalidation lancent un protocole de terminaison, qui consiste à choisir, parmi les sites corrects, un nouveau coordinateur qui dirigera les participants à prendre une décision de validation ou d annulation en tenant compte de son état local. Le nouveau coordinateur décide de valider s il est en état de pré-validation (a acquitté la demande de pré-validation) ou de validation (a reçu la décision de validation). S il est en état d attente (de la demande de pré-validation), il décide d abandonner la transaction. Le protocole de validation triphasé demeure peu utilisé vu la perte de temps qu il engendrera avec l ajout de la troisième phase. Coordinateur prepare Phase I oui Coordinateur Etat attente Phase II pré-validation Ack Etat de pré-validation Phase III Ack Decision Etat de validation Figure IV.9 : Le protocole 3PC 56

70 Chapitre IV/ La validation atomique Le protocole 2PC décentralisé (D2PC): [Skeen 81] Le protocole D2PC s exécute en deux phases et se trace comme objectif de réduire le nombre d étapes de communication. En utilisant ce protocole, le coordinateur diffuse une demande de vote à tous les participants et chaque participant diffuse son vote à tous les autres. Ainsi, chaque participant peut prendre une décision de façon décentralisée, car en recevant les votes oui de tous les autres, chaque participant pourra valider la transaction, sinon il l abandonne. Le protocole D2PC gagne une étape de communication par rapport à 2PC de base, au coût d un nombre plus élevé de message émis. Ce protocole peut être utile si le nombre de participants est faible ou si le réseau de communication utilisé est un réseau à diffusion. 5. Optimisations du protocole 2PC : Les chercheurs tentent à distinguer les variantes du protocole 2PC des optimisations de ce dernier en mettant en évidence deux points qui marquent la différence [El Houmaily 10] [Chrysanthis 98] - Une optimisation ne peut être employée sans un protocole de validation atomique, tandis qu une variante le peut. - Une optimisation peut coexister avec d autres optimisations sans aucun conflit. Ce qui n est pas le cas pour les variantes. Plusieurs optimisations ont été proposées afin de réduire les coûts liés aux protocoles de validation Read-Only : [Mohan 86] L'optimisation Read-Only est utilisée dans le cas où un ou plusieurs des participants ne font des opérations de lecture, c.-à-d. aucune mise à jour. 57

71 Chapitre IV/ La validation atomique De tels participants, en recevant la demande de vote du coordinateur, répondent par «Read-Only» et ne participeront pas à la phase de validation. Cette optimisation permettra un gain en nombre de messages transmis, voire même le nombre d écritures forcées réalisées One -Phase Commit : [Abdallah 98] L'optimisation One-Phase Commit est utilisée dans le cas où on ne dispose que d un seul participant. Dans ce cas, la coordination entre sites est bien évidemment inutile et le coordinateur diffuse à l unique participant sa décision, sans vote préalable. 6. Comparaison des protocoles : Les tableaux ci-dessous présentent une comparaison entre les principales variantes 2PC étudiées, en considérant les métriques : Nombre de messages total échangés, nombre d écritures forcées réalisées et la latence. La latence étant exprimée en nombre d'étapes de communication entre le moment où la validation est soumise au coordinateur et le moment où la validation devient effective sur chaque participant. (a) Décision de validation Métrique Messages Ecritures forcées latence ACP (coordinateur+participants) 2PC 4P 1+2P 3 PrC 3P 2+P 3 PrA 4P 1+2P 3 EP P 1+(P+N) 1 CL P 1 1 IYV 2P 1+P 1 D2PC P+2P(P-1) 1+2P 2 Tableau IV.2 : Comparaison des principaux protocoles (cas : validation) [Abdallah 98] Avec : P=Nombre de participants et N= nombre d'opérations exécutées par la transaction. 58

72 Chapitre IV/ La validation atomique (b) Décision d annulation Métrique Messages Ecritures forcées latence ACP (coordinateur+participants) 2PC 4P 1+2P 3 PrC 4P 1+2P 3 PrA 3P P 3 EP 2P N+2P 1 CL 4N+P 0 4N+1 IYV P 0 1 D2PC 2(P²+P) 2(P+1) 2 Tableau IV.3 : Comparaison des principaux protocoles (cas d annulation) [Abdallah 98] Avec : P=Nombre de participants et N= nombre d'opérations exécutées par la transaction. Les protocoles EP, CL et IYV présentent l avantage de minimiser la détention des ressources d une transaction, vu ont la plus faible latence (=1). Comme ils génèrent le nombre le plus faible de messages et d écritures forcées. Ce sont encore des protocoles à une seule phase seulement. Cependant, ils présentent de fortes contraintes : - Ils étendent la fenêtre de vulnérabilité à toute la durée d exécution d une transaction. - Les protocoles CL et IYV limitent l autonomie des sites participants en leur obligeant l exportation de tout ou partie de leurs journaux. 7. Conclusion : Tout au long de ce chapitre, nous avons présenté les principes de la validation atomique. Le principal protocole 2PC a été détaillé, suivi de ses variantes ainsi que quelques de ses optimisations. Nous nous sommes étalés sur les deux principales variantes de 2PC en l occurrence Presumed Abort et Presumed Commit, les deux qui ont été proposées [Mohan 86] afin 59

73 Chapitre IV/ La validation atomique de réduire le nombre d écritures surtout forcées dans le journal et le nombre de messages échangés. D autres variantes ont suivi, nous nous sommes intéressés à quelques-unes, tel que : Early Protocole et Coordinator Log. En association avec une variante, plusieurs optimisations peuvent être utilisées sans poser de conflits. L optimisation la plus répandue est : Read-Only, qui permet de simplifier le protocole en présence de sites n exécutant que des opérations de lecture. Nous avons tenté à deux reprises dans cette présentation des comparaisons entre les différents protocoles pour marquer les points forts et les points faibles de chaque. Pour notre implémentation, nous choisirons d utiliser la variante Presumed Abort vu qu elle est largement adoptée étant donné les simplifications qu elle permet. Cette variante peut être combinée avec l optimisation Read-only pour de meilleures performances. 60

74 Chapitre V Architecture du prototype 1. Introduction : Ce chapitre présentera l architecture générale du prototype réalisé ainsi que l architecture des serveurs et celle des clients. Seront encore discutés les principaux traitements réalisés au niveau des serveurs et au niveau des clients. 2. Architecture générale du prototype : Le prototype est constitué d un ensemble d applications clients, et d un ensemble d applications serveurs permettant l accès aux données SDDS en réponse aux transactions provenant des clients. Les applications serveurs participent aussi à la mise en œuvre du protocole de validation atomique PrA, en collaboration avec les applications clients. Tous les échanges d informations se font à travers un réseau d interconnexion. Client1 Client2 Client3 Clientn Application Application Application. Application Réseau d interconnexion Serveur 1 Serveur 2 Serveur 3 Serveur n Application Application Application Application Données SDDS Données SDDS Données SDDS Données SDDS Figure V.1. Architecture générale du prototype 61

75 Chapitre V/ Architecture du prototype 3. Architecture du serveur : Les applications au niveau des serveurs s exécutent en multitâches grâce à l utilisation des routines fournies dans la librairie PVM (Parallel Virtuel Machine). L architecture générale des serveurs est donnée par le schéma suivant : Case SDDS Eclatement Fusion Redirection Insertion Modification Suppression Lecture MAJ Validation Analyse requête Journal Réponse Réseau validation d interconnexion Demande validation Réponse Requête Requête client CLIENT Figure V.2 : Architecture d un serveur A la réception d une requête (opération d une transaction) client, le serveur analyse la requête pour vérifier si elle lui est correctement destinée, sinon il l a redirige vers le serveur qu il faut, tout en transmettant un message IAM au client pour corriger son image de la SDDS et éviter de répéter cette erreur d adressage ultérieurement. Le serveur concerné par l exécution de la requête exécute l opération demandée, et transmet éventuellement des résultats au client (cas de lecture seulement). 62

76 Chapitre V/ Architecture du prototype Notons que l opération d insertion peut entrainer une opération d éclatement, et l opération de suppression peut déclencher une fusion. Toutes les opérations s exécutent sur les cases du fichier SDDS, et réalisent des mises à jour sur le journal du serveur en question, à l exception de l opération de lecture. D une façon générale, les serveurs exécutent d une façon itérative les étapes suivantes : Recevoir une opération d une transaction émise par un client. Exécuter l opération. Retourner éventuellement une réponse au client qui a émis la transaction. Aller à l étape 1. Les serveurs traitent également, à chaque fin de transaction, les demandes de validation provenant du client, tout en mettant à jour le journal correspondant. 4. Architecture d un client : Le client joue le rôle d interface aux utilisateurs, leurs permettant d adresser leurs transactions aux serveurs, comme il joue le rôle du coordinateur de transactions, puisque à lui revient la tâche de répartir les opérations d une transaction entre les serveurs concernés. Donc, Il reçoit les transactions, les analyses opération par opération pour déterminer, pour chacune, l adresse du serveur auquel elle doit être envoyée, en se basant sur sa propre image du fichier SDDS. Le client maintient à cet effet deux principaux paramètres : le niveau présumé du fichier, soit i, et le numéro du prochain serveur à éclater, soit p. Une fois l adresse, du serveur destinataire de l opération, déterminée, il lui transmet l opération à exécuter en lui envoyant un message. Le message n est qu une routine de la librairie fournie avec PVM. Le client restera à l écoute de réponses de la part des serveurs. Une réponse qui peut être le résultat d une opération, telle que la lecture, une indication de fin exécution 63

77 Chapitre V/ Architecture du prototype d une opération ou un message d ajustement de l image du client (IAM) suite à une erreur d adressage. Dans ce dernier cas, le client mettra à jour son image en appliquant l algorithme approprié de mise à jour des images. De plus, le client déclenche, à la fin de l exécution d une transaction, l opération de validation de celle-ci, et suit son déroulement en recevant les réponses des serveurs participants et en mettant à jour son propre journal. Le schéma suivant illustre les tâches principales exécutées par le client : SERVEUR Réseau d interconnexion Requête client Réponse Requête Demande validation Réponse validation Envoyer requête MAJ Recevoir réponse Déterminer adresse serveur Traiter opération Image client Retourner réponse validation Générer transaction Journal MAJ Interface client Utilisateur Figure V.3. Architecture d un client 64

78 Chapitre V/ Architecture du prototype 5. Déroulement des transactions : Une transaction étant constituée d une suite d opérations (insertion, suppression, modification ou lecture). On présentera alors le déroulement de chacune de ces opérations et des opérations qui en découlent (éclatement, fusion, et validation) Opérations de mise à jour : a. L insertion : La requête d insertion émise par un client, dans le cadre d une transaction, est reçue au niveau d un serveur. Celui-ci, utilisant le paramètre unique dont il dispose (le niveau j de sa case), recalcule l adressage pour vérifier si la requête le concerne ou pas. Si l adresse calculée ne correspond pas à sa propre adresse, il l a redirige vers le serveur d adresse déterminée. Et, dans le cas où ce serveur est le premier à rediriger cette requête, il transmet un message d ajustement d image (IAM) au client pour qu il corrige l image correspondante au fichier. Dans le cas contraire (cas où le message le concerne), le serveur vérifie si la valeur de la clé de l enregistrement à insérer existe dans sa case. Si c est oui, l insertion est abandonnée. Si c est non, deux possibilités d insertion se posent : Insertion directe dans la case, si celle-ci dispose toujours de l espace libre. Insertion en zone de débordement, si la case est saturée. Dans ce dernier cas, le serveur coordinateur des SDDS (serveur 0 dans notre cas) est consulté pour un traitement d éclatement de case. Ce traitement se décrit plus loin dans ce chapitre. Notons enfin qu avant d insérer un nouvel enregistrement, une écriture journal est réalisée en mémoire. 65

79 Chapitre V/ Architecture du prototype b. L éclatement : Le serveur coordinateur (serveur 0) vérifie la position (p) du serveur à éclater. Si cette position est à 0, c est à lui de s éclater, sinon il transmet un message au serveur de numéro p lui ordonnant de s éclater. Le serveur devant s éclater lance un nouveau serveur de numéro : 2 j *N+p (j étant le niveau actuel du serveur et N : nombre initial de serveur). La fonction de hachage suivante est appliquée à toutes les valeurs des clés du serveur actuel : f(clé) = clé mod 2 j+1 * N. Les enregistrements vérifiant f(clé)=0 sont gardés dans la case du serveur en cours, le reste est transféré vers la case du nouveau serveur. Il est important de noter encore que des enregistrements d insertions sont ajoutés dans le journal du serveur 2 j *N+p et des enregistrements de suppression dans le journal du serveur p. Le serveur ayant éclaté doit informer le coordinateur de la fin de l éclatement. Le coordinateur mettra à jour la position d éclatement p, et éventuellement le niveau du fichier i (si la taille du fichier double). Notons bien que les niveau du serveur ayant éclaté et celui du nouveau serveur passera à j+1. Serveur 0 i, p 3. Ordre d éclatement 5. Fin éclatement Serveur p j 4. Transfert de données Serveur 2 j *N+p j 2. Débordement Client 1. insertion Serveur x i,p j Figure V.4. Déroulement du traitement d éclatement 66

80 Chapitre V/ Architecture du prototype c. La suppression : Comme pour l insertion, le traitement de suppression démarre avec la vérification de l adressage et la vérification de l existence de la clé (si adressage correct). Si adressage incorrect, un IAM est transmis au client pour corriger son image. Dans le cas contraire, et après l écriture journal, l enregistrement est supprimé. On s intéresse ensuite à vérifier si le taux de remplissage passe au-dessous d un seuil minimal. Si c est le cas, un appel au serveur coordinateur est fait pour une éventuelle fusion de cases. d. La fusion : Le serveur coordinateur estime le taux de remplissage du fichier. Si le taux de remplissage est inférieur à un seuil minimal, alors le traitement de fusion est lancé. La position de fusion est décrémentée et le niveau du fichier i est mis à jour. Deux cas alors se présentent : Soit la position de fusion est à zéro. Le coordinateur se fusionne avec le serveur 2 i *N. Soit la position de fusion est différente de zéro : dans ce cas, le coordinateur transmet un message au serveur p lui demandant de se fusionner avec le serveur 2 i *N+p. Le serveur p demande au serveur 2 i *N+p de lui transférer sa case, pour qu elle soit fusionnée avec la case courante. Il est essentiel de noter ici que des enregistrements d insertions sont ajoutés dans le journal du serveur p et des enregistrements de suppression dans le journal du serveur 2 i *N+p. Le schéma suivant illustre les différentes étapes de l exécution de l opération de suppression ainsi que celle de fusion : 67

81 Chapitre V/ Architecture du prototype Serveur 0 3. Ordre de fusion Serveur p 4. Demande transfert de case Serveur 2 i *N+p i, p 6. Fin fusion j 5. Transfert de case j 7. IAM 2. Taux de remplissage au dessous du seuil min Client 1. Suppression Serveur x i,p j Figure V.5 Déroulement du traitement de fusion Le niveau de la case p est décrémenté, et le serveur 2 i *N+p libéré (processus correspondant tué). Pour terminer, le coordinateur transmet, à la fin de la fusion, un IAM au client avec un niveau de fichier i=0, et une position d éclatement p=0. e. La modification : De la même façon que précédemment, la vérification d adressage est faite en premier, suivie du test d existence de la clé (cas adressage correct), avant que l enregistrement soit modifié. L écriture journal est toujours réalisée avant la mise à jour de l enregistrement Opération de lecture : Se déroule pratiquement de la même manière que la modification, sauf que la valeur lue (lorsque la clé existe) est retourné au client demandeur, sinon un code d erreur est transmis. 68

82 Chapitre V/ Architecture du prototype 5.3. La validation : La validation est lancée par le coordinateur de la transaction, qui est dans notre cas le client ayant généré la transaction, et est exécutée en collaboration avec tous les participants à la même transaction. a. La validation au niveau des clients : La validation reprend les étapes du protocole PrA, en commençant par une écriture simple dans le journal en mémoire du début du processus de validation de la transaction, puis en transmettant un message de préparation à tous les participants. Si tous les participants répondent par Prêt dans un délai ne dépassant pas un time out fixé, la décision qui sera prise par le coordinateur sera de valider la transaction. Si au moins un participant répond par annuler ou ne répond pas au bout du temps fixé, la décision sera d annuler la transaction. Une écriture forcée de la décision est réalisée dans le journal. Deux cas se présentent ensuite : La décision est valider : et elle est transmise à tous les participants. La décision est annuler : et elle n est transmise qu aux participants ayant voté prêt seulement. Il est à noter que si la décision est valider, le coordinateur doit attendre la réception des acquittements de chaque participant, avant d enregistrer la fin de la transaction dans le journal. b. La validation au niveau des serveurs : A la réception d un message de préparation, et avant que le serveur répond par 'prêt', il doit écrire sur disque tous les enregistrements du journal en mémoire, concernant la transaction, ainsi que l'enregistrement prêt. Dans le cas contraire ; il répond par annuler. 69

83 Chapitre V/ Architecture du prototype A la réception d un message de validation, le serveur réalise une écriture forcée de la décision avant d acquitter le message. Dans le cas d annulation, en recevant le message du coordinateur, le serveur ne procède à aucun traitement, à part annuler les mises à jour effectuées par la transaction. 6. Conclusion : Dans ce chapitre, nous avons présenté l architecture générale du prototype, ainsi que les architectures des clients et des serveurs. Nous avons encore fait passer en revue les modules de chaque architecture. Le chapitre suivant sera consacré à revoir avec plus de détail les éléments du prototype réalisé, en décrivant les fonctionnalités offertes. 70

84 Chapitre VI Présentation détaillée du prototype 1. Introduction : Dans ce chapitre, nous présenterons d une façon plus détaillée le prototype développé, implémentant le protocole PrA et le système de stockage LH*. L environnement de développement est constitué d une machine virtuelle regroupant en réseau un ensemble de PCs fonctionnant sous linux (ubuntu), et communiquant en s échangeant des messages à l aide des fonctions fournies par la librairie PVM (Parallel Virtual Machine). PVM (Parallel Virtual Machine ) étant un système pour la programmation parallèle dans un réseau d ordinateurs, facilitant les traitements sur les tâches parallèles (création, suppression, ) et surtout la communication entre les tâches des différentes machines. 2. Le protocole de validation adopté : Le protocole de validation implémenté est le protocole 2PC, dans sa variante PrA (Presumed Abort). La variante PrA est l une des deux principales variantes parmi les plus adoptées. Elle présente cependant plus d avantages que PrC (Presumed Commit), vu qu elle présente moins de messages échangés et moins d opérations d accès disque lors des opérations de journalisation. 3. Structure de données : Les données sont enregistrées dans un fichier SDDS distribué sur un ensemble de serveurs numérotés à partir de zéro (0, 1, 2, ). 71

85 Chapitre VI/ Présentation détaillée du prototype Chaque serveur contient une case du fichier SDDS. Chaque case étant constituée d un nombre fixe d enregistrements avec éventuellement une zone de débordement qui doit être créée lors de la saturation de la case. Cette zone étant pointée par la case principale du serveur. La case de chaque serveur doit contenir également le niveau j du serveur en cours. Niveau j Zone débordement Enregistrements de la case Pointeur zone débordement Figure VI.1. Structure d une case du fichier SDDS Notons encore que chaque enregistrement d une case est constitué de deux champs : un champ clé et un champ valeur. Clé Valeur ancienne Figure VI.2. Structure d un enregistrement du fichier SDDS Le serveur 0 est sélectionné comme principal et joue le rôle du coordinateur. Il détient et met à jour les identifiants des tâches ou TID (Task Identifier). Un TID est un numéro attribué par la machine virtuelle à chaque processus (ou serveur, dans notre cas) qui démarre. Ainsi, chaque machine, client soit-elle ou serveur doit récupérer les TIDs des machines avec lesquelles elle doit communiquer auprès du coordinateur. 72

86 Chapitre VI/ Présentation détaillée du prototype Le coordinateur est aussi responsable de déterminer, dans le cadre de l application du principe des SDDS, le prochain serveur à éclater ou celui à fusionner, car il est le seul à connaitre la position (p) d éclatement ou de fusion. 4. La journalisation : 4.1. Structure du journal : La journalisation est une étape fondamentale dans l application du protocole 2PC, où chaque serveur doit maintenir son propre journal lui permettant de reprendre en cas de panne. Le journal est mis à jour en MC, à chaque opération d une transaction, et est écrit en mémoire secondaire à chaque de fin de transaction ou quand la zone réservée au journal est saturée. Il est à rappeler que les écritures forcées du protocole 2PC doivent être réalisées directement en mémoire secondaire. Les enregistrements du journal sont constitués des champs suivants : - Numéro transaction. - code opération (insertion, suppression, modification, lecture, prêt, valider, annuler, ). - Clé. - Valeur_ancienne. - Valeur_nouvelle. Numéro transaction code opération Clé Valeur ancienne ancienne Valeur nouvelle nouvelle Figure VI.3. Structure d un enregistrement du journal 73

87 Chapitre VI/ Présentation détaillée du prototype 4.2. Les points de reprise : Afin d éviter le parcours complet du journal lors d une reprise après panne, les points de reprise doivent être définis périodiquement. A chaque point de reprise, il doit y avoir sauvegarde sur mémoire secondaire de la case au niveau de chaque serveur. Et, afin de réduire le temps du blocage du système transactionnel lors de cette sauvegarde, nous optons pour les points de reprise non consistants, qui évitent de stopper l acceptation de nouvelles transactions et stoppent uniquement l acceptation de nouvelles opérations, tout en évitant d attendre la fin de l exécution des transactions en cours pour effectuer les sauvegardes nécessaires. Deux principales possibilités de sauvegardes sont alors offertes selon qu on a choisi des points de reprise consistant ou des points de reprise non consistant : a. Point de reprise consistant : Le point de reprise n est réalisé qu après avoir arrêté la réception de nouvelles transactions, tout en terminant l exécution de celles déjà en cours. D où le déroulement des étapes suivantes : Stopper l'acceptation de nouvelles transactions. Attendre que les transactions actives se terminent. Sortir sur la mémoire stable tous les enregistrements du journal résidants actuellement dans la mémoire centrale. Enregistrer mémoire stable tous les blocs modifiés de la mémoire tampon. Ajouter sur la mémoire stable un enregistrement <checkpoint> du journal. Après qu'une panne se soit produite, le système de recouvrement exécute les étapes suivantes : - Localiser le dernier checkpoint dans le journal. - Restaurer le cache (blocs déjà sauvegardés de la mémoire tampon). - Créer deux listes UNDO et REDO. - Lire le journal en arrière : Si commit T, REDO := REDO +T ; Si abort T, UNDO := UNDO +T ; Si start T et T REDO, UNDO := UNDO +T ; - Défaire les transactions dans UNDO ; 74

88 Chapitre VI/ Présentation détaillée du prototype - Refaire les transactions dans REDO. T0 T1 T2 T3 T4 T5 start commit abort checkpoint panne temps redo undo A la reprise : Les transactions validées : T1 (redo) Les transactions annulées : T5 (undo) Les transactions non terminées : T4 (undo) Figure VI.4. Point de reprise consistant b. Point de reprise non consistant : Le point de reprise non consistant vise à réduire le temps de blocage du système transactionnel durant l'opération du checkpoint, en bloquant la réception de nouvelles opérations des transactions en cours ou celles nouvelles. Les étapes de déroulement de ce type de point de reprise sont les suivantes : Stopper l'acceptation de nouvelles opérations (en laissant les transactions actives dans un état bloqué). Sortir sur la mémoire stable tous les enregistrements du journal résidants actuellement dans la mémoire centrale. Sauvegarder toutes les pages modifiées du cache. Marquer le journal stable par un enreg < checkpoint, L> où L est la liste des transactions actives durant le checkpoint. La reprise se fera alors en les étapes suivantes : - Localiser le dernier checkpoint dans le journal. 75

89 Chapitre VI/ Présentation détaillée du prototype - Restaurer le cache (blocs déjà sauvegardés de la mémoire tampon). - Créer deux listes UNDO et REDO. - Lire le journal en arrière : Si commit T, REDO := REDO +T ; Si abort T, UNDO := UNDO +T ; Si start T et T REDO, UNDO := UNDO +T ; Si T L (liste des transactions bloquées au point de reprise), UNDO := UNDO +T. - Défaire les transactions dans UNDO ; - Refaire les transactions dans REDO. T0 T1 T2 T3 T4 start commit T5 abort checkpoint panne temps redo undo A la reprise : Les transactions validées : T0, T4 (redo) Les transactions annulées : T5 (undo) Les transactions actives au checkpoint : T1, T3 (undo) Figure VI.5. Point de reprise inconsistant Les points de reprise non consistants permettent ainsi un gain de temps considérable vu qu à chaque sauvegarde à chaque sauvegarde on n attend pas la fin de l exécution des transactions en cours pour entamer les enregistrements. Etant cet avantage, nous avons opté dans notre implémentation pour ce dernier type de point de reprise. 76

90 Chapitre VI/ Présentation détaillée du prototype 5. Les opérations d accès : Il s agit des opérations permettant l accès aux données réparties sur l ensemble des serveurs. Elles sont lancées par les clients, et exécutées par les serveurs : - Ecrire (T,C,val) : pour remplacer la valeur actuelle de l enregistrement de clé C par la valeur val. T est la transaction qui contient l opération d insertion. - Lire (T,C,val) : pour lire dans val la valeur correspondant à la clé C. Si la clé n existe pas, un code d erreur est retourné. - Insert (T, C, val) : pour insérer un nouvel enregistrement dans le fichier réparti, de clé C et de valeur val. Cette opération peut entrainer un éclatement de case, introduisant des insertions dans la nouvelle case créée et des suppressions dans la case en cours. - Supprime (T,C) : pour supprimer l enregistrement de clé C. Cette opération peut être la cause de fusion de cases, suite à des taux de remplissage passant au dessous d un seuil minimal. Ce qui aura pour effet, des insertions dans la case en cours et des suppressions dans la case avec laquelle se fera la fusion. - Preparer (T) : pour demander un vote sur la terminaison de la transaction T. - Valider (T) : pour valider la transaction T. - Annuler (T) : pour annuler la transaction T. 6. Présentation des fonctionnalités du prototype : La figure suivante montre le menu des fonctionnalités assurées par le prototype réalisé. L ensemble de ces fonctionnalités est disponible au niveau de chaque client. 77

91 Chapitre VI/ Présentation détaillée du prototype Figure VI.6. Menu principal du prototype La fonctionnalité principale est celle permettant la génération automatique des transactions en nombre aléatoire, avec des opérations en nombre et de type aléatoires. Les autres fonctionnalités viennent compléter la fonctionnalité principale en permettant différents services. Dans ce qui suit, une description détaillée de l ensemble de fonctionnalités assurées par le prototype : 6.1. Génération automatique des transactions : Les transactions sont générées de la façon suivante : - Un nombre aléatoire de transactions. - Un nombre aléatoire d opérations par transactions. - Un type d opération aléatoire par opération (insertions, suppressions, modifications et lectures). - Une valeur aléatoire pour la clé. - Une valeur aléatoire pour le champ valeur, éventuellement (cas de modification). 78

92 Chapitre VI/ Présentation détaillée du prototype La figure suivante affiche un exemple de génération de transactions, et détaille leurs contenus : (code_opération = 1 pour l insertion, 2 pour la suppression, 3 pour la modification et 4 pour la lecture). Figure VI.7. Un exemple de génération de transactions 6.2. Affichage des enregistrements d un serveur : Pour pouvoir consulter le contenu de chaque case (serveur), la deuxième fonctionnalité est appelée. Ce qui est illustré par la figure suivante qui affiche pour chaque enregistrement d une case les champs clé et valeur : 79

93 Chapitre VI/ Présentation détaillée du prototype Figure VI.8. Un exemple d affichage d une case de serveur 6.3.Affichage des enregistrements du journal : Afin de pouvoir vérifier les contenus des journaux générés pendant l exécution des transactions, la troisième fonctionnalité du prototype présente un menu spécial : Figure VI.9. Menu d accès aux journaux Un exemple d affichage d un journal d un serveur est illustré dans la figure suivante. Sachant que l opération de lecture n est pas enregistrée dans le journal, les codes choisis pour les opérations sont comme suit : 1-insertion, 2- Suppression, 3-Modification, 4- Prêt, 5-valider et 6-Annuler. 80

94 Chapitre VI/ Présentation détaillée du prototype Figure VI.10. Un exemple du contenu du journal du serveur Récupération du fichier SDDS : Cette fonctionnalité permet au client de récupérer le contenu du fichier de données SDDS pour être sauvegardé sur disque. Chaque serveur transmettant la partie qu il 81

95 Chapitre VI/ Présentation détaillée du prototype contient. Cette récupération permettra, par exemple, au client de redistribuer le fichier SDDS sur de nouveaux serveurs. La restauration du fichier SDDS permet de recharger le fichier déjà sauvegardé, dans les mémoires des serveurs. 6.5.Sauvegarder un serveur : Pour des raisons d administration, le client peut être amené à demander à un serveur d effectuer la sauvegarde de sa case sur le disque. Le serveur peut être ainsi arrêté. On peut même procéder à des opérations de maintenance sur le serveur concerné. Les données sauvegardées de la case doivent l être ainsi que le journal si on utilise toujours des points de reprise inconsistants, et ce afin de permettre une reprise correcte après redémarrage du serveur. 7. Description détaillée des traitements : 6.3. Les traitements réalisés par les serveurs : En plus des opérations d accès aux données, les serveurs exécutent les algorithmes concernant l implantation des structures LH*, à savoir l éclatement et la fusion. a. Traitement d insertion : L algorithme d insertion est présenté en premier, suivi de l algorithme de traitement de l éclatement en cas d insertion avec débordement. Et, pour plus d éclaircissements un exemple illustratif reprend les deux principaux cas d insertion : cas simple, sans débordement et cas avec débordement donc avec éclatement. 82

96 Chapitre VI/ Présentation détaillée du prototype Recevoir les données transmises par le client (clé, valeur). a1 = cle mod 2 i * N ; /* calculer la clé correspondante au niveau du serveur*/ si (a1!= a) { a2 = cle mod 2 i-1 * N; si ((a2 > a) et (a2<a1)) { a1=a2;}; }; si (a!=a1) { si première redirection { transmettre un IAM au client} ; transmettre un message au serveur a1 ; } sinon { si (non existe(cle)) /* si la clé à insérer n'existe pas, l'insérer */ { Ecrire enregistrement dans le journal ; si (case vide) /* vérifier Si serveur vide : sans aucun élément */ { première insertion } sinon /* si serveur non vide */ {Si (case complète) {Insertion en zone de débordement ; Lancer la procédure d éclatement en appelant le serveur zéro. } Sinon {Insertion dans la case ;} } }; }; Algorithme VI.1. Insertion d un enregistrement b. Traitement d éclatement : L éclatement s exécute à deux niveau : au niveau du serveur coordinateur (serveur 0) pour déterminer quel serveur éclater et ordonner l éclatement par conséquent, et au niveau du serveur concerné par l éclatement qui doit exécuter l algorithme approprié. Donc, deux algorithmes sont proposés ci-dessous pour les deux niveaux d exécution. 83

97 Chapitre VI/ Présentation détaillée du prototype b.1. Algorithme de lancement de l éclatement par le serveur zéro : if (p==0) { Eclater serveur zéro (coordinateur). } else { /* si autre serveur, envoi de message de demande d'éclatement */ Envoyer message de demande d éclatement au serveur p. Réception du tid du nouveau serveur créé }; Envoi des nouvelles maj de tids à tous les serveurs et au client. /* MAJ de p et de i */ p=p+1; if (p >= (puiss (2,i)*N)) {p=0;i=i+1;} b.2. Algorithme de l exécution de l éclatement par tous serveur : Lancer le nouveau serveur (de n 2 j *N+p) devant recevoir une partie de l'éclatement Parcourir la case et la zone de débordement du serveur p. Si (element mod 2 j+1 *N=0) { transférer vers tableau 1 } Sinon { transférer vers tableau 2 } Libérer la case du serveur. Transférer Tableau 1 vers la case du serveur actuel. Transférer Tableau 2 vers la case du nouveau serveur. Si (serveur actuel <> 0) {Répondre au coordinateur et transférer le tid du nouveau serveur.} Algorithmes VI.2. Eclatement de cases L exemple suivant met en évidence les deux cas d insertions déjà évoqués, à savoir : le cas d insertion simple (sans débordement) et le cas d insertion avec débordement. Notons que les valeurs utilisées dans cet exemple sont celles générées par le prototype réalisé. 84

98 Chapitre VI/ Présentation détaillée du prototype Serveur j=0 a/ Insertion de 98 Serveur 0 Serveur j= j=1 b/ Insertion de 19, 70, 49, 45, 83 Serveur 0 Serveur j= j=1 p=0 p=0 p=0 Taille case = 10 enreg a/ Insertion avec éclatement : le serveur 0 est éclaté en deux, car saturé. Un enregistrement d insertion (de 98) est ajouté au journal du serveur 0, ainsi que deux enregistrements de suppression (de 79 et 77). Deux enregistrements d insertions (de 79 et 77) sont ajoutés au journal du serveur 1. b/ Insertions sans éclatement : Un enregistrement d insertion (de 70) est inséré dans le journal du serveur 0, et des enregistrements d insertions (de 19, 49, 45,83) sont insérés dans le journal du serveur 1. Serveur 0 Serveur 1 Serveur c/ Insertion de 100 j=2 p=1 j=1 j=2 c/ Insertion avec éclatement : Un enregistrement d insertion (de 100) est ajouté au journal du serveur 0, ainsi que des enregistrements de suppression (de 38, 2, 30, 98,70). Des enregistrements d insertions (de 38, 2, 30, 98, 70) sont ajoutés au journal du serveur 2. Figure VI.11. Cas d insertions 85

99 Chapitre VI/ Présentation détaillée du prototype c. Traitement de suppression : Le traitement de suppression peut être suivi d un traitement de fusion, dans le cas où le taux de remplissage passe au-dessous d un seuil minimum fixé. D où la présentation successives des algorithmes des deux traitements : Recevoir les données transmises par le client (clé). a1 = cle mod 2 i * N ; /* calculer la clé correspondante au niveau du serveur*/ si (a1!= a) { a2 = cle mod 2 i-1 * N; si ((a2 > a) et (a2<a1)) { a1=a2;}; }; si (a!=a1) { si première redirection {transmettre un IAM au client} ; transmettre un message au serveur a1 ; } sinon { Rechercher (cle) dans la case; Si (existe) {Ecrire enregistrement dans le journal ; Supprimer enregistrement correspondant ; Si (zone débordement non vide) { Transférer dernier élément de débordement vers la case du serveur ; } Si (taux de remplissage < seuil_min) { lancer fusionner(); } } ; Sinon { Rechercher (cle) en zone de débordement ; Si (existe) {Ecrire enregistrement dans le journal ; Supprimer enregistrement correspondant ; } } }; Algorithme VI.3. Suppression d un enregistrement 86

100 Chapitre VI/ Présentation détaillée du prototype d. Traitement de fusion : La fusion est lancée au niveau du serveur coordonnateur pour désigner les serveurs devant être fusionnés, ensuite au niveau des serveurs concernés. Nous présentons alors, dans cette suite, les deux algorithmes : f.1. Algorithme de lancement de la fusion par le serveur zéro : Estimer le taux_remplissage du fichier. if (taux_remplissage < seuil_min) { /* maj de p et de i */ p=p-1; if (p<0) {i=i-1; p=2 i -1; }; if (p==0) {Executer fusion(); /* du serveur 0 et du serveur 2 i *N*/ } else { Envoyer message de demande de fusion au serveur p. Recevoir le message de fin de fusion }; Tuer le processus du serveur 2 i *N+p; */ Maj de ttid Diffuser un message pour la mise à jour de ttid Transmission d'un IAM au client, avec i=0 et p=0 f.2. Algorithme d exécution de la fusion Envoi de message au serveur à fusionner pour demander le transfert d'une case. Réception de la case demandée. Fusionner la case reçue et la case courante. Décrémenter le niveau de la case courante. Si (serveur <> coordinateur) {Transmettre réponse au coordinateur} Algorithmes VI.4. Fusion de cases 87

101 Chapitre VI/ Présentation détaillée du prototype L exemple suivant illustre les différents cas de suppressions : a/ Suppression de b/ Suppression de j=1 j=1 j=1 j=1 j=0 p=0 p=0 p=0 a/ Suppression simple (sans fusion) : L enregistrement concerné est supprimé de la case. Un enregistrement de suppression (de 98) est ajouté au journal du serveur 0. b/ Suppression avec fusion (taux de remplissage < seuil_min (=0.5)) : Après suppression de l enregistrement concerné, une fusion est déclenchée, un enregistrement d insertion (de 79) est ajouté dans le journal du serveur 0 et un enregistrement de suppression (de 77) est ajouté dans le journal du serveur 1. Figure VI.12. Cas de suppressions e. Traitement de modification : La modification aura pour effet de modifier le champ valeur, avec une recherche suivant la valeur de la clé. Dans le journal du serveur concerné par la modification, un enregistrement de modification doit être inséré selon le protocole WAL, et ce afin de permettre de reprendre l image avant lors d une panne. 88

102 Chapitre VI/ Présentation détaillée du prototype Recevoir les données transmises par le client (clé, valeur). a1 = cle mod 2 i * N ; /* calculer la clé correspondante au niveau du serveur*/ si (a1!= a) { a2 = cle mod 2 i-1 * N; si ((a2 > a) et (a2<a1)) { a1=a2;}; }; si (a!=a1) { si première redirection { transmettre un IAM au client} ; transmettre un message au serveur a1 ; } sinon {Rechercher (cle) dans la case; Si (existe) {Ecrire enregistrement dans le journal ; modifier enregistrement correspondant ; } ; Sinon {Rechercher (cle) en zone de débordement ; Si (existe) { Ecrire enregistrement dans le journal ; modifier enregistrement correspondant ; } } }; Algorithme VI.5. Modification d un enregistrement f. Traitement de lecture : Le traitement de lecture se déroule comme les traitements précédents (recherche du serveur, redirection de la requête, transmission du message d ajustement de image client) sauf qu à la fin, la valeur lue, lorsqu elle existe, est retournée au client demandeur, sinon un code d erreur est transmis. Notons encore que concernant cette opération aucune écriture journal n est réalisée. Cependant, le serveur concerné participera toujours à la phase de validation. 89

103 Chapitre VI/ Présentation détaillée du prototype Recevoir les données transmises par le client (clé). a1 = cle mod 2 i * N ; /* calculer la clé correspondante au niveau du serveur*/ si (a1!= a) { a2 = cle mod 2 i-1 * N; si ((a2 > a) et (a2<a1)) { a1=a2;}; }; si (a!=a1) sinon } { si première redirection { transmettre un IAM au client} ; transmettre un message au serveur a1 ; {Rechercher (cle) dans la case; Si (existe) { Transmettre enregistrement correspondant au client; } ; Sinon {Rechercher (cle) en zone de débordement ; Si (existe) { Transmettre enreg. correspondant au client; } Sinon {Transmettre code d erreur ; } } }; Algorithme VI.6. Lecture d un enregistrement g. Traitement de validation : Chaque serveur participant à une transaction doit coordonner les étapes de la validation avec le client ayant déclenché la transaction, et qui doit encore déclencher la validation en transmettant les messages de préparation, de validation ou d annulation. A la réception de l un des trois messages, le serveur réagira suivant l algorithme suivant : 90

104 Chapitre VI/ Présentation détaillée du prototype Si message de préparation alors Si Prêt alors {Ecrire sur disque les enregistrements du journal ; Ecrire sur disque l enregistrement prêt T ; Transmettre le message prêt au coordinateur } sinon {Transmettre le message annuler au coordinateur } sinon Si message de validation alors { Ecrire sur disque l enregistrement valider T ; Acquitter le message } sinon {Annuler les mises à jour effectuées ; } Algorithme VI.7. Validation d une transaction au niveau serveur h. Algorithme principal d un serveur : Chaque serveur exécute un programme avec une boucle infinie exécutant à chaque passage une requête reçue du client. Chaque requête étant identifié par un numéro (appelé tag en PVM). Chaque exécution est suivie par une attente de réception de la requête suivante. Le programme principal présente de ce fait la structure générale suivante : 91