Conclusion sur l’évaluation de la gestion des pannes

Les expériences effectuées dans cette section montrent l’importance de la gestion des pannes dans le protocole de routage des transactions. Les résultats montrent qua la prise en compte des pannes réduit la dégradation des performances en présence de pannes. La tolérance aux pannes borne les temps de réponse qui sont des critères forts pour les applications. Par exemple, les ap-plications Web 2.0 fonctionnent avec les revenus générés par les publicités qui sont versés que s’il y a des visiteurs. Ainsi, des temps de réponses longs engendrés par les indisponibilités du service réduisent la présence de visiteurs et donc de fonds pour les fournisseurs d’applications.

7.4 Conclusion

Dans ce chapitre, nous avons présenté la validation de notre approche. Nous avons développé deux prototypes DTR et TRANSPEER pour implémenter les composants de notre routeur. DTR est conçu au dessus de JuxMem et donc nous a permis d’implémenter notre approche de gestion du catalogue avec verrouillage. TRANSPEER est implémenté au dessus d’un réseau P2P afin de gérer le catalogue sans verrouillage. Nous les avons utilisé pour mener une série d’expériences et les résultats obtenus démontrent la faisabilité de nos approches. Les résultats obtenus sont les suivants :

– la surcharge induite par la gestion d’un catalogue réparti est acceptable ;

– la redondance du routeur accroît le débit de routage et réduit le temps de réponse tout en introduisant plus de disponibilité ;

– le choix d’une gestion de catalogue sans verrouillage facilite le passage à l’échelle ;

– le relâchement de la fraîcheur améliore le temps de réponse et donne au routeur plus de choix. Le calcul de la fraîcheur est effectué avec l’utilisation du catalogue sans besoin de contacter les SGBD.

– la prise en compte de la dynamicité du système est indispensable et permet de borner le temps de réponse. Les méthodes de détection et de résolution des pannes utilisées sont simples à mettre en œuvre et s’avèrent bien adaptées pour un système à large échelle.

Conclusion et Perspectives

8.1 Synthèse

Les travaux présentés dans cette thèse montrent que l’utilisation d’un catalogue réparti associé à un modèle de routage réparti permet d’améliorer le débit transactionnel d’une base de données répliquées à large échelle tout en préservant la cohérence à terme et en contrôlant la fraîcheur des données lues par les requêtes. La prise en compte de la dynamicité des nœuds du système permet de maintenir les performances du système en cas d’occurrence de pannes.

Architecture du système de routage. Notre architecture se présente comme un intergiciel pour contrôler l’accès à la base de données et peut être divisée en deux parties : une partie assurant le service de médiation entre les différents composants du système (intergiciel) et une autre chargée de la gestion des métadonnées qui sont les données nécessaires au fonctionnement du système en entier. Le choix d’une architecture hybride à mi-chemin entre les systèmes P2P structurés et ceux non structurés nous permet de tirer profit des avantages des uns et des autres. En fait, la structura-tion des nœuds GT autour d’un anneau logique permet de faciliter leur collaborastructura-tion pour assurer le traitement cohérent des transactions alors que la structuration faible des nœuds ND leur confère une grande autonomie. Notre intergiciel redondant permet de faire face à la volatilité d’un environ-nement à large échelle puisqu’à chaque fois qu’un nœud GT ou ND tombe en panne, nous utilisons un autre nœud disponible pour continuer le traitement ou récupérer les données. L’utilisation d’un catalogue réparti facilite l’exploitation des ressources disponibles et un contrôle global de l’état du système. Pour rendre disponible les informations stockées à l’intérieur du catalogue, nous les avons répliquées par l’intermédiaire de systèmes garantissant le passage à l’échelle et la disponi-bilité, notamment JuxMem et une DHT. Pour exploiter avec efficacité, les ressources du systèmes (équilibrer les charges, identifier rapidement le nœud optimal, etc.), nous collectons plusieurs in-formations dans le catalogue comme métadonnées et nous les structurons logiquement pour que leur manipulation (lecture et modification) soit simple.

Protocole de routage. Nous avons proposé un mécanisme de routage des transactions pour ga-rantir une exécution rapide et cohérente, des transactions. Les algorithmes de routage proposés

requièrent des accès au catalogue réparti pour maintenir la cohérence mutuelle des répliques et ils définissent l’ordre dans lequel les transactions doivent être exécutées pour ne pas compromettre la cohérence. Le premier algorithme est dit pessimiste et ordonne toutes les transactions conflictuelles en s’appuyant sur les conflits potentiels. En d’autres mots, le protocole de routage assure une séria-lisation globale définie de manière pessimiste et qui est utilisé pour router les transactions. Chaque transaction est associée avec ses classes de conflits, qui contiennent les données que la transaction peut potentiellement lire (resp. modifier). En fonction des classes de conflits, les transactions sont ordonnées dans un GSG en s’appuyant sur leur ordre d’arrivée. Bien que cette approche assure une sérialisation globale, elle réduit malheureusement la parallélisation du traitement des transactions puisqu’elle s’appuie sur des sur-ensembles potentiels de données réellement accédées.

Pour améliorer le parallélisme du traitement des transactions, nous avons proposé un second algorithme qui combine une approche pessimiste et optimiste. Ce second algorithme s’appuie sur une tentative d’exécution des transactions afin deréduire le temps de réponse des transactions. Autrement dit, les transactions conflictuelles sont exécutées de manière optimiste et une phase de validation est utilisée à la fin pour garantir la cohérence. Dans le contexte des applications Web 2.0 où les transactions courantes et potentiellement conflictuelles sont peu nombreuses, les chances de réussite du routage optimiste s’avèrent très élevées et donc il apparaît plus adapté.

Catalogue réparti. Pour maintenir la cohérence globale, nous avons conçu un catalogue pour stocker les métadonnées (GSG). Le catalogue est utilisé à chaque processus de routage et peut faire alors l’objet d’accès concurrents qui peuvent être source d’incohérence. Pour garantir la co-hérence du catalogue lors de l’accès au métadonnées, nous avons proposé deux approches : une approche utilisant le verrouillage et une autre sans verrouillage. La gestion avec verrouillage est implémentée via JuxMem dans le but d’intégrer nos travaux dans le cadre du projet ANR Respire [Prod]. Malheureusement, nous avons remarqué que le verrouillage ne facilite pas le passage à l’échelle. C’est pourquoi nous avons opté pour une solution sans verrouillage lors de l’accès au catalogue. De plus, nous nous sommes intéressés à des systèmes tels que les DHT qui permettent de gérer des données répliquées sans utilisation de mécanismes de verrouillage. Ainsi, nous avons implémenté la gestion du catalogue à travers une DHT d’autant plus que celle-ci facilite le passage à l’échelle et une grande disponibilité, deux caractéristiques très importantes pour notre système de routage.

Gestion des pannes. Nous avons présenté un mécanisme de gestion de la dynamicité. Ce méca-nisme est basé sur la détection sélective des fautes et sur un algorithme de reprise. Contrairement à la plupart des autres approches, notre mécanisme n’implique pas l’utilisation de nœuds qui ne par-ticipent pas à léxécution de la transaction en cours, ce qui permet de passer à l’échelle. Pour cela, nous adaptons des approches existantes de détection des pannes afin de les rendre opérationnelles pour chaque type de nœud (gestionnaire de transaction et nœud de données) de notre système. Nous avons proposé un protocole permettant de gérer toutes les situations lorsqu’un nœud quitte le système pendant le traitement d’une transaction. Ceci est nécessaire et suffisant pour contrôler la cohérence du système, surtout en cas de déconnexions intempestives.

capable d’ajouter de nouvelles ressources en fonction des déconnexions. Pour ce faire, nous avons proposé un modèle permettant de déterminer et contrôler le nombre de répliques requises pour garder le système disponible. Ce modèle permet de déterminer le nombre minimum de répliques nécessaires au bon fonctionnement du système et donc de minimiser les surcoûts liés à la gestion des répliques.

Validation. Pour valider la faisabilité de nos approches, nous avons implémenté deux prototypes nommés respectivement DTR(Distributed Transaction Routing) et TRANSPEER(TRANSaction on PEER-to-peer). L’implémentation de deux prototypes est liée au besoin de gérer le catalogue avec verrouillage ou sans verrouillage. De fait, DTRconstitue le prototype développé avec verrouillage du catalogue alors que TRANSPEER est conçu pour une gestion du catalogue sans verrouillage et un modèle de communication de type P2P. Puis, nous avons effectué quelques simulations pour étudier le passage à l’échelle et la tolérance aux pannes de notre solution. Notre choix d’utiliser à la fois de l’expérimentation et de la simulation se justifie par le fait que : (1) l’expérimentation permet d’évaluer un système dans des conditions réelles ; et (2) la simulation est une représentation simplifiée du système, facile à réaliser et requiert moins de ressources que l’implémentation, ce qui favorise l’évaluation d’un système à grande échelle. Nous avons mené une série d’expériences sur nos deux prototypes pour étudier les performances de notre système : débit transactionnel, temps de réponse, passage à l’échelle et tolérance aux pannes. Les résultats obtenus montrent que l’utilisation d’un catalogue pour stocker les métadonnées permet de router les transactions en contrôlant le niveau de fraîcheur sollicité par les applications. De plus, la surcharge induite par la gestion d’un catalogue réparti est acceptable et donc n’a pas trop d’impact négatif sur le débit du routage. Les expériences ont montré que le relâchement de la fraîcheur des données améliore le temps de réponse des requêtes et l’équilibrage des charges, ce qui est économiquement important vis-à-vis l’utilisation totale des ressources disponibles. Les résultats montrent également que la redondance du routeur accroît le débit de routage et réduit le temps de réponse tout en introduisant plus de disponibilité. Les résultats obtenus avec notre prototype TRANSPEERdémontrent le gain de la gestion des métadonnées sans verrouillage, ce qui favorise la réduction du temps de réponse. Enfin, nous avons montré que la prise en compte de la dynamicité du système est indispensable et permet de borner le temps de réponse. Les méthodes de détection et de résolution des pannes utilisées sont simples à mettre en œuvre et s’avèrent bien adaptées pour un système à large échelle.