Disponibilité et durabilité

obsolète non obsolète

les plus récents)

jetable doit être gardé pointeur du début du journal

début du journal (enregistrements les plus anciens)

fin du journal (enregistrements

Fig. 4.5  Purge dy journalet début du journal 4.5.2.2 Le rôle du paginateur

Le paginateur garde une table de correspondance qui donne, pour chaque zone cohérente, l'identicateur de l'enregistrement de journal qui décrit la dernière modi-cation apportée à cette zone. Lorsque le paginateur a sauvegardé la zone en question sur l'image stable, il en communique l'identicateur au SGJ.

4.5.2.3 Le rôle du SGJ

Le SGJ garde en mémoire une table de correspondance qui permet de déterminer à partir de l'identicateur d'un enregistrement sa position dans le journal physique. Cette table est organisée en le d'attente, triée selon les positions croissantes16, an de pouvoir facilement déterminer quel est le plus vieil enregistrement qui n'est pas encore répercuté sur l'image. Cet enregistrement marque la limite entre les enregist-rements obsolètes et les enregistenregist-rements non obsolètes.

4.5.2.4 Nature des identicateurs

Les identicateurs sont obtenus par concaténation de l'identicateur du JL (que le PJS obtient lors de la création du JL), d'un numéro de séquence local à ce journal et éventuellement du numéro du site client émetteur. Ceci permet au PJS de générer des identicateurs qui sont globalement uniques.

4.6 Disponibilité et durabilité

4.6.1 Réplication

L'image stable assure la durabilité des données, à condition qu'il n'y ait pas de pannes de disque. La réplication de données sur plusieurs disques permet de se protéger contre ce genre de pannes: Si un exemplaire des donnés est en panne, on accède l'autre. De plus, la réplication permet d'obtenir une meilleure disponibilité, aussi en cas de panne temporaire de la machine à laquelle le disque est attaché. La réplication permet de garder le système distribué opérationnel et disponible en

80 Chapitre 4. Conception du système de stockage des données

dépit de pannes partielles. Cependant, an de garantir une sémantique correcte en cas de partition de réseau, des protocoles de synchronisation complexes et souvent coûteux sont nécessaires an de garder les répliques en phase. En général, le coût des opérations dans des bases de données répliquées augmente, étant donné que le système doit éventuellement accéder à des copies multiples d'un même objet an de garantir la cohérence mutuelle des copies.

Le protocole de réplication le plus simple est le protocoleread-one write-all. Dans ce protocole, une lecture est réalisée en accédant n'importe laquelle des répliques (en général la plus proche). Une écriture nécessite une mise à jour de toutes les copies, an d'assurer que la prochaine lecture retourne la valeur appropriée de l'objet. L'inconvénient de cette approche est que la disponibilité n'est pas vraiment améliorée pour les écritures: en eet, la panne d'une seule des répliques interdit toute évolution des données répliquées. Par contre, les accès en lecture seule restent possible tant qu'il y a au moins un exemplaire accessible.

An d'améliorer la disponibilité, des protocoles basés sur levoteont été proposés. Dans le protocole de vote statique [Tho79], une opération d'écriture écritQ

e copies, et une opération de lecture accède à Q

l copies. L'écriture réussit seulement si au moins Q

e copies sont accessibles, et la lecture réussit seulement si au moins Q l copies sont accessibles et identiques entre elles.

Q e et Q

l sont appelés quorum d'écriture et quorum de lecture respectivement, et sont choisis de manière à ce que Q

e + Q

l soit supérieur au nombre total des exemplaires de l'objet. Cette contrainte protège l'algorithme contre les partitions de réseau. En eet, à cause de cette relation numérique, il y a parmi lesQ

lcopies lues au moins une desQ

ecopies écrites précédemment. Donc si la lecture est possible (accord entre copies lues), son résultat est obligatoirement la dernière valeur écrite. An de se protéger contre des mises à jour contradictoires et cohérentes, deux approches sont possibles:

 Le système peut exiger qu'une lecture soit fait immédiatement avant l'écriture,  Le système peut imposer la contrainte supplémentaire que Q

e >

n 2.

Ce système diminue la disponibilité pour la lecture au prix de la disponibilité pour l'écriture. Il existe des variantes de ce protocole, qui introduisent un des changements suivants:

 On peut associer des poids au sites [Gif79]. Ainsi un site qui est connu comme étant hautement disponible peut par exemple compter pour 3 dans le calcul du quorum,

 On peut introduire des votants phantômes qui ne stockent pas de copie sur disque, mais qui servent uniquement à augmenter la disponibilité grâce au vote qu'ils peuvent émettre. Évidemment, les quorums devront être choisis de telle manière qu'une majorité peut être atteinte sans les votants phantômes. Dans Arias, nous n'avons pour l'instant pas mis en ÷uvre de protocole de répli-cation, mais nous prévoyons éventuellement de faire ceci plus tard.

Mise en ÷uvre du service de stokage

Dans ce chapitre, nous décrivons la structuration interne du service de journali-sation et de stockage.

5.1 Architecture interne du sous-système de stockage

Récupération PJS Paginateur Service générique de journalisation (SGJ) de volume Journaux logiques JLL Journal physique Gestionnaire

Fig.5.1  Architecture interne du service de stockage

Comme le montre la gure 5.1, le service de stockage met en jeu les modules suivants:

 Le gestionnaire de volume est responsable du stockage de l'image stable des données.

 Le PJS prend, pour le compte de l'application, l'initiative des opérations de sauvegarde, et supervise tout en tant que coordonnateur.

82 Chapitre 5. Mise en ÷uvre du service de stokage

 Le SGJ, qui est subdivisé en plusieurs parties:

 Le gestionnaire du journal physique (GJP) est responsable du stockage physique des journaux. Lors de la reprise, il localise le début et la n du journal,

 Le gestionnaire des journaux logiques locaux (SJLL) est responsable de multiplexer plusieurs journaux logiques locaux au-dessus d'un même jour-nal physique,

 Le gestionnaire des journaux logiques (SJL) est responsable d'éclater un journal logique en plusieurs journaux logiques locaux, qui seront chacun stockés sur un site diérent, auprès de leur images stables,

 Le gestionnaire de la récupération est responsable de remettre en état l'image stable après une panne, en rejouant ou en défaisant les opérations décrites par le journal.

Dans la suite de ce chapitre, nous passerons en revue le rôle et la mise en ÷uvre de ces diérents modules.