Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Chapitre 5: Cohérence des Données Réparties (Cohérence des données distribuées)

Chapitre 5: Cohérence des Données Réparties (Cohérence des données distribuées) 5.1. introduction La réplication de données est une technique ancienne permettant de tolérer les échecs et d'augmenter la disponibilité des données. Avec en ligne activités occupant nos vies, nos données critiques, tant personnelles que professionnelles, sont en cours de plus en plus stockés dans des centres de données quelque part dans le monde. Ces données sont répliquées sur plusieurs centres de données de sorte que même lorsque certaines des copies sont perdues à cause d'un blocage ou deviennent inaccessibles En raison d'une partition réseau, nos données restent toujours intactes et accessibles. Caché des copies de téléchargé les données sur nos appareils personnels nous permettent de les utiliser même si la connectivité réseau est absente. En plus de tolérer les échecs, la réplication réduit la latence d'accès (la latence est un intervalle de temps). entre la requête et la réponse ). Les serveurs DNS des niveaux supérieurs sont hautement répliqués, sans cette recherche d'adresse IP sera très lente. Un problème majeur dans la gestion de la réplication est celui de la mise à jour du réplica. Le problème n'existe pas si les données sont en lecture seule, ce qui est vrai pour les codes de programme. Lorsqu'un réplica est mis à jour, une copie sur deux de ces données doit être mis à jour pour maintenir la cohérence. Cependant, en raison de la vitesse de calcul de processeurs et les latences de réseau impliquées dans la mise à jour de copies dispersées géographiquement, il est possible qu'après la mise à jour d'une copie, les utilisateurs des autres copies aient toujours accès à l'ancien version. Quelles incohérences sont autorisées? et comment la cohérence peut-elle être restaurée? sont importants problèmes de gestion des données répliquées. 5.2. Fiabilité versus disponibilité Deux principales motivations derrière la réplication des données sont la fiabilité ( « Fiabilité » en français ) et disponibilité ( «Disponibilité» en français ). Données répliquées dans le cloud ( cloud computing, in English l'informatique en nuage, consiste à exploiter la puissance de calcul ou de stockage de serveurs informatiques distants by Internet to Internet. ) non seulement servir de sauvegarde contre les pannes, mais facilite également la disponibilité à tout moment, via un simple navigateur. Dans Web, les serveurs proxy fournissent des services lorsque le serveur principal est surchargé (“ surchargé ” en français ). Tous ces exemples illustrent comment la réplication peut améliorer la disponibilité des données ou des services. Il peut arriver que le service fourni par un serveur proxy ne soit pas aussi efficace que le service fourni par le serveur principal, mais il est certainement préférable de ne pas avoir de service du tout. Ceci est un exemple de dégradation élégante en français ). Le système RAID ( Redundant Array of Array) Disques peu coûteux ) est un autre exemple de fiabilité et d’amélioration de la disponibilité via réplication. ( RAID) est un ensemble de techniques de virtualisation du stockage permettant de répartir des données sur plusieurs disques durs afin que soit soit les performances, soit la tolérance aux pannes du système. ) La fiabilité et la disponibilité répondent à deux problèmes importants. Un serveur fiable mais rarement disponible ne sert à rien. De même, un serveur disponible mais souvent défaillant ou alimenté des données incorrectes causent mal à la tête ( mal de tête ) pour tous. Considérons deux utilisateurs, Alice et Bob, mettant à jour un F. partagé. Il peut y avoir une seule copie de F, ou plusieurs répliques (copies) de F. Voir figure 5.1. Figure 5.1: Deux manières différentes de partager un fichier F: (a) Utilisateurs partageant une seule copie et (b) plusieurs des répliques du fichier existent dans le système. Les actions de chaque utilisateur peuvent être les suivantes: Selon la façon dont le fichier est maintenu, l’opération d’écriture (1) mettra à jour une copie centrale de F qui est partagé par les deux ou (2) met à jour les copies de F séparément. Dans les deux cas, idéalement, les mises à jour d'Alice doit parvenir à Bob avant qu'il ne lance l'opération de lecture, et inversement. Cependant, avec des locaux séparés copies, cela peut ne pas être possible en raison de la transmission tardive des messages. Donc, Bob peut soit lire un copie obsolète ( “qui n'est pas fraiche” ou “qui est ancienne” en français ) ou différée ( “renvoyer à plus”tard ”en français ) jusqu'à la mise à jour. Qu'est-ce qu'une sémantique acceptable du partage de F avec maintenir la cohérence des données? La section suivante présente les architectures utilisées pour les données répliquées. gestion afin de maintenir la cohérence des données. Il est à noter que le maintien de la cohérence parmi les répliques est un problème difficile. 5.3 Architectures de gestion des données répliquées Idéalement, la gestion des données répliquées doit être transparente. La transparence implique que les utilisateurs aient l’illusion d’utiliser une seule copie des données ou de l’objet même s’il existe plusieurs copies d’une donnée partagée. Les clients ne doivent pas avoir des connaissances dont réplique fournit données. Il est rassurant pour les clients de croire en l'existence d'un seul serveur qui est très disponible et digne de confiance, bien que dans la vie réelle différentes répliques peuvent se relayer pour créer l’illusion d’une copie fiable unique des données. Bien qu'idéal la transparence de réplication peut être rarement obtenue, l’approximation de la transparence de réplication est l’un des objectifs architecturaux de la gestion des données répliquées. Les deux techniques principales de réplication sont appelées réplication passive et réplication active. Autre Les techniques de réplication peuvent être considérées comme des variantes ou des combinaisons de ces deux techniques de base. 5.3.1 Réplication passive Pour conserver la transparence de la réplication, deux modèles architecturaux différents sont largement utilisés: les systèmes passifs. réplication et réplication active . Dans la réplication passive, chaque client communique avec un seul serveur contenant une réplique des données appelée primaire. En plus du primaire, un ou plusieurs Les serveurs de répliques sont utilisés comme copies de sauvegarde. La figure 5.2 en est une illustration. Si le primaire est opérationnel, il fournit le service souhaité. Si la demande d’un client ne modifie pas les données, aucune autre l'action est nécessaire. Si, toutefois, les actions du client modifient les données, conserver les états de la sauvegarde serveurs cohérents, le principal effectue une multidiffusion atomique des mises à jour sur les serveurs de sauvegarde, avant d'envoyer la réponse au client. Si le serveur principal plante, l'un des serveurs de sauvegarde est élu comme le nouveau primaire. Figure 5.2: Réplication passive L'architecture de réplication de sauvegarde principale répond aux spécifications suivantes: 1) Au plus, un serveur de sauvegarde peut être le serveur principal à tout moment. 2) Chaque client maintient une variable L (leader) qui spécifie le serveur de réplica auquel il sera envoyé. envoyer des demandes. Les demandes sont mises en file d'attente sur le serveur principal. 3) Les serveurs de sauvegarde ignorent les requêtes des clients. Il peut y avoir des périodes où il n’ya pas de serveur principal, cela se produit pendant une période donnée. commutation ( « changement » en français ) après que le serveur primaire est écrasé, et un serveur de sauvegarde est encore être désigné comme le nouveau primaire. Cette période est appelée temps de basculement ( «temps de basculement ”en français ). L’ approche de réplication passive implémente un service qui peut tolérer une nombre limité de défauts sur la durée de vie du service. Ici, un échec implique un crash du serveur. Puisque le serveur principal renvoie une réponse au client après avoir terminé une multidiffusion atomique, lorsqu'un Si le client reçoit une réponse, il est assuré que chaque réplique non défectueuse a reçu la mise à jour. le Le serveur principal diffuse périodiquement des messages « battement de coeur » en français à destination du sauvegardes. Si un serveur de sauvegarde ne parvient pas à recevoir ce message dans un délai déterminé, il conclut que le primaire s'est écrasé et initie une élection. Le nouveau chef prend la relève en tant que nouveau principal et informe les clients. La figure 5.3 illustre les étapes de base du protocole de sauvegarde primaire. Figure 5.3: Illustration du protocole de sauvegarde primaire. Les lignes brisées représentent le messages de battement de coeur. Pour conserver la transparence de la réplication, le basculement antérieur (« commutation » en français ) doit être instantané. Mais dans la vraie vie, cela peut ne pas être vrai. Considérons la description suivante des actions d'un client: // Algorithme d'un client Au début faire Demande de service. Fin À la réception du serveur, faites-le Arrêter l'exécution Fin À la fin du temps imparti Retransmettre la demande au serveur Fin Si, en raison du crash du serveur principal, le client ne reçoit pas de réponse dans un délai donné, le demande de service est retransmise. En fait, plusieurs retransmissions peuvent être nécessaires, jusqu'à ce qu'un Le serveur de sauvegarde devient le nouveau serveur principal. Cela se produit pendant le temps uploads/Litterature/ chapitre-5-coherence-des-donnees-reparties-coherence-des-donnees-distribuees.pdf