Stratégie proposée pour gérer la réplication de données

Stratégie proposée pour gérer la réplication de données

Problématique

La croissance constante des volumes de données, introduit plusieurs déÖs tel que, le stockage, líaccËs, la gestion et le traitement incluant la recherche des donnÈes. En plus, les systËmes de stockage de donnÈes Cloud doivent généralement fournir une qualitÈ de service (QoS) Öable pour satisfaire les engagements contractuels SLA (Service Level Agrement). Les spéciations techniques díun SLA sont gÈnÈralement dÈcrites dans un SLO (Service Level Objectives). Les SLOs sont considÈrÈs comme un moyen pour mesurer la qualité des services comme la disponibilité ou le temps de rÈponse. Dans ce contexte, La réplication de donnÈes est une technique largement utilisÈe dans les environnements distribués qui stocke des donnÈes sur plusieurs sites, elle fournit la disponibilité et la performance. Si un site de stockage tombe en panne, le système peut continuer ‡ fonctionner en utilisant des donnÈes rÈpliquÈes, ce qui augmente la disponibilité et la tolÈrance aux pannes. En mÍme temps, comme les données sont stockÈes sur plusieurs sites de stockage. La réplication des donnÈes permet de rapprocher les donnÈes des utilisateurs pour diminuer la latence, ou de crÈer de nombreuses copies pour des donnÈes extrÍmement populaires aÖn de rÈpartir la charge sur di§Èrents serveurs. Ce qui permet díaugmenter líe¢ cacitÈ du systËme, de rÈduire la consommation de la bande passante et díamÈliorer líÈvolutivitÈ du systËme. Donc, la rÈplication des donnÈes est trËs utile pour o§rir de bonnes performances díaccËs. La rÈplication est largement utilisÈe dans les systËmes parallËles [6], base de donnÈes [7], mobile [8], et ‡ grande Èchelle y compris les grilles [9], Peer to Peer [10] Lorsque la donnÈe est frÈquemment mise ‡ jour, la maintenance des rÈpliques peut dÈgrader les performances. En plus, maintenir plusieurs copies díune mÍme donnÈe peut poser des problËmes de cohÈrence lors des mises ‡ jour. En e§et, lorsquíune copie est modiÖÈe, la modiÖcation doit Ítre propagÈe ‡ toutes les autres copies du systËme aÖn de garantir leur cohÈrence. Des mÈcanismes de gestion de cohÈrence, Ègalement appelÈs protocoles de cohÈrence, doivent Ítre prÈsents dans tous les systËmes de rÈplication. Plusieurs modËles et protocoles de cohÈrence o§rant di§Èrents niveaux de garantie/performance ont ÈtÈ proposÈs. DíaprËs le thÈorËme de CAP [12], Brewer a¢ rme quíil est impossible pour un systËme distribuÈ de fournir ‡ la fois cohÈrence, disponibilitÈ et support des partitions. Il est donc nÈcessaire de faire des compromis sur líune des trois propriÈtÈs en fonction des contraintes des applications. Assurer une cohÈrence forte nÈcessite díÈnormes e§orts de synchronisation sur di§Èrents sites et expose ainsi les utilisateurs ‡ des latences de rÈseau ÈlevÈes. Cela a§ecte les performances et la disponibilitÈ des donnÈes. Une alternative particuliËre qui est devenue trËs populaire est la cohÈrence faible. Elle permet une certaine divergence entre les rÈpliques. Lorsque la cohÈrence garantie est faible, une demande díaccËs ne reáËte pas forcÈment toutes les modiÖcations antÈrieures, par contre, ces modiÖcations seront transmises au bout díun temps Öni. Nous avons comme premier objectif de proposer une stratÈgie e¢ cace de rÈplication dynamique de donnÈes dans les Cloud Computing. Il existe un certain nombre de travaux dans la littÈrature qui traitent la rÈplication des donnÈes dans les systËmes de Cloud [13], [14]. Des stratÈgies ont ÈtÈ proposÈes pour amÈliorer les performances [11], [6], rÈduire la consommation de bande passante [15], augmenter le niveau de disponibilitÈ des donnÈes [16], [17] et líÈquilibrage des charges [18]. Cependant, ces objectifs semblent Ítre di¢ cilement satisfaits simultanÈment. Par exemple, la rÈplication des donnÈes garantit la disponibilitÈ. Mais, cela se fait au dÈtriment des communications entre les sites qui surchargent le rÈseau et donc un e§et sur les performances. De plus, la plupart de ces stratÈgies nÈgligent le co˚t de rÈplication et ne prennent pas en compte le proÖt du fournisseur.

Première contribution

Nous proposons une stratégie de réplication de données dynamique qui répond simultanément aux exigences de disponibilité et de performance tout en prenant en compte le prout du fournisseur (DRAPP). Dans notre stratégie, nous traitons les trois problèmes suivants : 1. Quelles donnÈes doivent Ítre rÈpliquÈes et quand répliquer pour répondre ‡ la fois aux exigences des utilisateurs et au bÈnÈÖce Èconomique du fournisseur ? par exemple, des donnÈes rÈpliquÈes trop tÙt ne rÈduiront pas le temps díattente ou níaccÈlÈreront pas líaccËs aux donnÈes. 2. Combien de nouvelles rÈpliques appropriÈes doivent Ítre crÈÈes pour garantir une disponibilitÈ minimale et de rÈaliser un proÖt Èconomique raisonnable pour le fournisseur ? ¿ mesure que le nombre de rÈpliques augmente, la disponibilitÈ des donnÈes augmente. Mais en mÍme temps, le co˚t de crÈation et le maintien de ces nouvelles rÈpliques vont augmenter aussi de maniËre signiÖcative et donc faire des dÈpenses inutiles. 3. O˘ les nouvelles rÈpliques doivent Ítre placÈes ? Des donnÈes proches des requÍtes des utilisateurs, peuvent diminuer la latence et de rÈduire la consommation de la bande passante. Des donnÈes distribuÈes díune faÁon optimisÈe peuvent amÈliorer líÈquilibrage de charge des di§Èrents serveurs. Notre idÈe gÈnÈrale est de crÈer de nouvelles rÈpliques en fonction des contraintes de disponibilitÈ et de performance (SLO). La crÈation de nouvelles rÈpliques est dÈclenchÈe uniquement si la contrainte de disponibilitÈ de la donnÈe níest pas garantie ou si le temps de rÈponse díune requÍte díun client est supÈrieur au seuil de temps de rÈponse convenu dans le SLA. Certaines informations collectÈes, par exemple la charge de travail díun núud et la popularitÈ des donnÈes, sont Ègalement utilisÈes lors de la prise de dÈcision. Dans notre stratÈgie nous calculons le nombre de rÈpliques minimum ‡ crÈer pour maintenir une disponibilitÈ ÈlevÈe des donnÈes pendant que les performances du systËme sont amÈliorÈes. Le nombre de rÈpliques requises est ajustÈ dynamiquement. Les requÍtes des locataires sont classÈes selon di§Èrentes..

Table des matières

Introduction
I Gestion de la rÈplication de donnÈes
1 Etat de líart sur les stratÈgies de rÈplication de donnÈes
1.1 Introduction
1.2 StratÈgies de rÈplication dans les grilles
1.2.1 StratÈgie de rÈplication statique vs dynamique
1.2.2 StratÈgies de rÈplication centralisÈ vs dÈcentralisÈ
1.2.3 StratÈgies de rÈplication basÈes sur des fonctions objectives
1.2.4 StratÈgies de rÈplication dynamique selon líarchitecture
1.3 StratÈgies de rÈplication dans le Cloud Computing
1.3.1 Statique vs dynamique
1.3.2 StratÈgies de rÈplication de donnÈes selon les fonctions objectives
1.4 Conclusion
2 StratÈgie proposÈe pour gÈrer la rÈplication de donnÈes
2.1 Introduction
2.2 Topologie de Cloud
2.3 SchÈma de rÈplication
2.3.1 Phase de surveillance
2.3.2 Phase de traitement
2.3.3 Phase de dÈclenchement de rÈplication
2.4 StratÈgie de rÈplication proposÈe
2.4.1 Quand et quoi rÈpliquer ?
2.4.2 Estimation du bÈnÈÖce du fournisseur
2.4.3 Combien de rÈpliques ?
2.4.4 Ordonnancement díaccËs
2.4.5 Placement des rÈpliques
2.4.6 Suppression des rÈpliques
2.5 Conclusion
3 Evaluation expÈrimentale de la stratÈgie DRAPP
3.1 Introduction
3.2 CloudSim
3.3 RÈsultats expÈrimentaux
3.3.1 Impact du budget
3.3.2 Impact du nombre de centres de donnÈes Table des matiËres v
3.3.3 Impact du nombre de requÍtes
3.4 Conclusion II Gestion de la cohÈrence de donnÈes
4 Etat de líart sur les stratÈgies de cohÈrence de donnÈes
4.1 Introduction
4.2 StratÈgies de cohÈrence dans les grilles
4.3 StratÈgies de cohÈrence dans les Clouds
4.3.1 StratÈgies de cohÈrence faible
4.3.2 StratÈgie de cohÈrence adaptative
4.4 Conclusion
5 StratÈgie proposÈe pour gÈrer la cohÈrence de donnÈes
5.1 Introduction
5.2 Topologie de Cloud
5.3 Service de cohÈrence locale
5.3.1 Agent de surveillance
5.3.2 Agent de cohÈrence
5.3.3 Agent de gestion des conáits
5.4 Service de cohÈrence globale
5.5 Conclusion
6 Evaluation expÈrimentale de la stratÈgie AC2R
6.1 Introduction
Table des matiËres vi
6.2 MÈtriques utilisÈes
6.3 Simulation et rÈsultats
6.3.1 ExpÈrience 1 : Impact du nombre de Cloudlets
6.3.2 ExpÈrience 2 : Impact du type de Cloudlet
6.4 Conclusion
Conclusion générale
References

Télécharger le rapport complet