Réplication (informatique) - Replication (computing)

La réplication en informatique implique le partage d'informations afin d'assurer la cohérence entre les ressources redondantes, telles que les composants logiciels ou matériels , pour améliorer la fiabilité, la tolérance aux pannes ou l'accessibilité.

Terminologie

La réplication en informatique peut faire référence à :

La réplication des données , où les mêmes données sont stockées sur plusieurs périphériques de stockage
Réplication de calcul , où la même tâche de calcul est exécutée plusieurs fois. Les tâches de calcul peuvent être :
- Répliqué dans l'espace , où les tâches sont exécutées sur des appareils séparés
- Répliqué dans le temps , où les tâches sont exécutées à plusieurs reprises sur un seul appareil

La réplication dans l'espace ou dans le temps est souvent liée à des algorithmes d'ordonnancement.

L'accès à une entité répliquée est généralement uniforme avec l'accès à une seule entité non répliquée. La réplication elle-même doit être transparente pour un utilisateur externe. Dans un scénario d'échec, un basculement des réplicas doit être caché autant que possible en ce qui concerne la qualité de service .

Les informaticiens décrivent en outre la réplication comme étant soit :

Réplication active , qui est effectuée en traitant la même demande à chaque réplica
La réplication passive , qui consiste à traiter chaque requête sur une seule réplique et à transférer le résultat sur les autres répliques

Lorsqu'un réplica leader est désigné via l' élection du leader pour traiter toutes les demandes, le système utilise un schéma de sauvegarde primaire ou de réplica primaire , qui est prédominant dans les clusters à haute disponibilité . En comparaison, si une réplique peut traiter une demande et distribuer un nouvel état, le système utilise un schéma multi-primaire ou multi-maître . Dans ce dernier cas, une forme de contrôle de concurrence distribuée doit être utilisée, comme un gestionnaire de verrouillage distribué .

L'équilibrage de charge diffère de la réplication de tâches, car il répartit une charge de différents calculs entre les machines et permet de supprimer un seul calcul en cas d'échec. L'équilibrage de charge, cependant, utilise parfois la réplication des données (en particulier la réplication multi-maîtres ) en interne, pour répartir ses données entre les machines.

La sauvegarde diffère de la réplication en ce que la copie enregistrée des données reste inchangée pendant une longue période. Les répliques, en revanche, subissent des mises à jour fréquentes et perdent rapidement tout état historique. La réplication est l'un des sujets les plus anciens et les plus importants dans le domaine global des systèmes distribués .

La réplication des données et la réplication des calculs nécessitent toutes deux des processus pour gérer les événements entrants. Les processus de réplication des données sont passifs et ne fonctionnent que pour conserver les données stockées, répondre aux demandes de lecture et appliquer les mises à jour. La réplication de calcul est généralement effectuée pour fournir une tolérance aux pannes et reprendre une opération en cas de défaillance d'un composant. Dans les deux cas, les besoins sous-jacents sont de s'assurer que les réplicas voient les mêmes événements dans des ordres équivalents, afin qu'ils restent dans des états cohérents et que tout réplica puisse répondre aux requêtes.

Modèles de réplication dans les systèmes distribués

Il existe trois modèles largement cités pour la réplication des données, chacun ayant ses propres propriétés et performances :

Réplication transactionnelle : utilisée pour répliquer des données transactionnelles , telles qu'une base de données. Le modèle de sérialisation à une copie est utilisé, qui définit les résultats valides d'une transaction sur des données répliquées conformément aux propriétés ACID globales (atomicité, cohérence, isolation, durabilité) que les systèmes transactionnels cherchent à garantir.
Réplication de la machine à états : suppose que le processus répliqué est un automate fini déterministe et que la diffusion atomique de chaque événement est possible. Il est basé sur un consensus distribué et a beaucoup de points communs avec le modèle de réplication transactionnelle. Ceci est parfois utilisé à tort comme synonyme de réplication active. La réplication de la machine d'état est généralement mise en œuvre par un journal répliqué composé de plusieurs cycles successifs de l' algorithme Paxos . Ceci a été popularisé par le système Chubby de Google et est au cœur du magasin de données open source Keyspace .
Synchronisation virtuelle : implique un groupe de processus qui coopèrent pour répliquer des données en mémoire ou pour coordonner des actions. Le modèle définit une entité distribuée appelée groupe de processus . Un processus peut rejoindre un groupe et est doté d'un point de contrôle contenant l'état actuel des données répliquées par les membres du groupe. Les processus peuvent alors envoyer des multidiffusions au groupe et verront les multidiffusions entrantes dans le même ordre. Les changements d'adhésion sont traités comme une multidiffusion spéciale qui fournit une nouvelle "vue d'adhésion" aux processus du groupe.

Réplication de base de données

La réplication de base de données peut être utilisée sur de nombreux systèmes de gestion de base de données (SGBD), généralement avec une relation primaire/réplique entre l'original et les copies. Le maître enregistre les mises à jour, qui se répercutent ensuite sur les répliques. Chaque réplique émet un message indiquant qu'elle a reçu la mise à jour avec succès, permettant ainsi l'envoi de mises à jour ultérieures.

Dans la réplication multimaître , les mises à jour peuvent être soumises à n'importe quel nœud de base de données, puis se répercuter sur d'autres serveurs. Ceci est souvent souhaité mais introduit des coûts et une complexité sensiblement accrus qui peuvent le rendre peu pratique dans certaines situations. Le défi le plus courant dans la réplication multimaître est la prévention ou la résolution des conflits transactionnels . La plupart des solutions de réplication synchrone (ou avide) effectuent la prévention des conflits, tandis que les solutions asynchrones (ou paresseuses) doivent effectuer la résolution des conflits. Par exemple, si le même enregistrement est modifié sur deux nœuds simultanément, un système de réplication dynamique détectera le conflit avant de confirmer la validation et annulera l'une des transactions. Un système de réplication paresseux permettrait aux deux transactions de s'engager et d'exécuter une résolution de conflit pendant la resynchronisation. La résolution d'un tel conflit peut être basée sur un horodatage de la transaction, sur la hiérarchie des nœuds d'origine ou sur une logique beaucoup plus complexe, qui décide de manière cohérente sur tous les nœuds.

La réplication de base de données devient plus complexe lorsqu'elle évolue horizontalement et verticalement. La mise à l'échelle horizontale a plus de répliques de données, tandis que la mise à l'échelle verticale a des répliques de données situées à des distances physiques plus grandes. Les problèmes soulevés par la mise à l'échelle horizontale peuvent être atténués par un protocole d' accès multicouche et multivue . Les premiers problèmes de mise à l'échelle verticale ont été largement résolus en améliorant la fiabilité et les performances d' Internet .

Lorsque les données sont répliquées entre les serveurs de base de données, de sorte que les informations restent cohérentes dans tout le système de base de données et que les utilisateurs ne puissent pas dire ou même savoir quel serveur du SGBD ils utilisent, le système est censé présenter une transparence de réplication.

Réplication de stockage sur disque

Réplication de stockage

La réplication du stockage actif (en temps réel) est généralement implémentée en distribuant les mises à jour d'un périphérique bloc sur plusieurs disques durs physiques . De cette façon, tout système de fichiers pris en charge par le système d'exploitation peut être répliqué sans modification, car le code du système de fichiers fonctionne à un niveau supérieur à la couche du pilote de périphérique de bloc. Il est implémenté soit dans le matériel (dans un contrôleur de réseau de disques ) soit dans le logiciel (dans un pilote de périphérique ).

La méthode la plus basique est la mise en miroir de disque , qui est typique pour les disques connectés localement. L'industrie du stockage restreint les définitions, la mise en miroir est donc une opération locale (à courte distance). Une réplication est extensible à travers un réseau informatique , de sorte que les disques peuvent être situés dans des emplacements physiquement éloignés, et le modèle de réplication de base de données maître-esclave est généralement appliqué. Le but de la réplication est d'empêcher les dommages dus à des pannes ou des catastrophes qui peuvent se produire à un endroit ou, si de tels événements se produisent, d'améliorer la capacité de récupération des données. Pour la réplication, la latence est le facteur clé car elle détermine soit la distance qui sépare les sites, soit le type de réplication qui peut être utilisé.

La principale caractéristique d'une telle réplication intersites est la manière dont les opérations d'écriture sont gérées, via une réplication asynchrone ou synchrone ; la réplication synchrone doit attendre la réponse du serveur de destination dans toute opération d'écriture, contrairement à la réplication asynchrone.

La réplication synchrone garantit "zéro perte de données" au moyen d' opérations d'écriture atomique , où l'opération d'écriture n'est pas considérée comme terminée tant qu'elle n'est pas reconnue par le stockage local et distant. La plupart des applications attendent la fin d'une transaction d'écriture avant de poursuivre le travail, ce qui réduit considérablement les performances globales. Par nature, les performances chutent proportionnellement à la distance, car la latence minimale est dictée par la vitesse de la lumière . Pour une distance de 10 km, l'aller-retour le plus rapide possible prend 67 s, alors qu'une écriture locale entière en cache se termine en environ 10 à 20 s.

Dans la réplication asynchrone , l'opération d'écriture est considérée comme terminée dès que le stockage local l'acquitte. Le stockage distant est mis à jour avec un petit décalage . Les performances sont considérablement améliorées, mais en cas de défaillance du stockage local, il n'est pas garanti que le stockage distant dispose de la copie actuelle des données (les données les plus récentes peuvent être perdues).

La réplication semi-synchrone considère généralement qu'une opération d'écriture est terminée lorsqu'elle est reconnue par le stockage local et reçue ou enregistrée par le serveur distant. L'écriture distante réelle est effectuée de manière asynchrone, ce qui entraîne de meilleures performances, mais le stockage distant sera à la traîne par rapport au stockage local, de sorte qu'il n'y a aucune garantie de durabilité (c'est-à-dire une transparence transparente) en cas de défaillance du stockage local.

La réplication à un instant donné produit des instantanés périodiques qui sont répliqués à la place du stockage principal. Ceci est destiné à répliquer uniquement les données modifiées au lieu du volume entier. Comme moins d'informations sont répliquées à l'aide de cette méthode, la réplication peut se produire sur des liaisons à bande passante moins coûteuses telles que iSCSI ou T1 au lieu de lignes à fibre optique.

Implémentations

De nombreux systèmes de fichiers distribués utilisent la réplication pour garantir la tolérance aux pannes et éviter un point de défaillance unique.

De nombreux systèmes de réplication synchrone commerciaux ne se bloquent pas lorsque la réplique distante échoue ou perd la connexion - un comportement qui garantit une perte de données nulle - mais continuent à fonctionner localement, perdant l' objectif de point de récupération zéro souhaité .

Des techniques d' optimisation de réseau étendu (WAN) peuvent être appliquées pour répondre aux limites imposées par la latence.

Réplication basée sur des fichiers

La réplication basée sur des fichiers effectue la réplication des données au niveau logique (c'est-à-dire des fichiers de données individuels) plutôt qu'au niveau du bloc de stockage. Il existe de nombreuses façons d'effectuer cela, qui reposent presque exclusivement sur des logiciels.

Capture avec un pilote de noyau

Un pilote de noyau (en particulier un pilote de filtre ) peut être utilisé pour intercepter les appels aux fonctions du système de fichiers, capturant toute activité au fur et à mesure qu'elle se produit. Cela utilise le même type de technologie que les vérificateurs de virus actifs en temps réel utilisent. À ce niveau, les opérations de fichiers logiques sont capturées comme l'ouverture, l'écriture, la suppression de fichiers, etc. Le pilote du noyau transmet ces commandes à un autre processus, généralement via un réseau vers une machine différente, qui imitera les opérations de la machine source. Comme la réplication de stockage au niveau des blocs, la réplication au niveau des fichiers autorise les modes synchrone et asynchrone. En mode synchrone, les opérations d'écriture sur la machine source sont suspendues et ne sont pas autorisées à se produire tant que la machine de destination n'a pas reconnu la réplication réussie. Le mode synchrone est moins courant avec les produits de réplication de fichiers bien que quelques solutions existent.

Les solutions de réplication au niveau des fichiers permettent de prendre des décisions éclairées sur la réplication en fonction de l'emplacement et du type de fichier. Par exemple, des fichiers temporaires ou des parties d'un système de fichiers qui n'ont aucune valeur commerciale pourraient être exclus. Les données transmises peuvent également être plus granulaires ; si une application écrit 100 octets, seuls les 100 octets sont transmis au lieu d'un bloc disque complet (généralement 4 096 octets). Cela réduit considérablement la quantité de données envoyées depuis la machine source et la charge de stockage sur la machine de destination.

Les inconvénients de cette solution uniquement logicielle incluent l'exigence de mise en œuvre et de maintenance au niveau du système d'exploitation, et une charge accrue sur la puissance de traitement de la machine.

Réplication du journal du système de fichiers

À l'instar des journaux de transactions de base de données , de nombreux systèmes de fichiers ont la possibilité de journaliser leur activité. Le journal peut être envoyé à une autre machine, soit périodiquement, soit en temps réel par streaming. Du côté de la réplique, le journal peut être utilisé pour lire les modifications du système de fichiers.

L'une des implémentations notables est le System Center Data Protection Manager (DPM) de Microsoft , publié en 2005, qui effectue des mises à jour périodiques mais n'offre pas de réplication en temps réel.

Réplication par lots

C'est le processus de comparaison des systèmes de fichiers source et de destination et de s'assurer que la destination correspond à la source. Le principal avantage est que ces solutions sont généralement gratuites ou peu coûteuses. L'inconvénient est que le processus de synchronisation est assez gourmand en système et, par conséquent, ce processus s'exécute généralement peu fréquemment.

L'une des implémentations notables est rsync .

Réplication de mémoire partagée distribuée

Un autre exemple d'utilisation de la réplication apparaît dans les systèmes de mémoire partagée distribuée , où de nombreux nœuds du système partagent la même page de mémoire. Cela signifie généralement que chaque nœud a une copie distincte (réplique) de cette page.

Sauvegarde primaire et réplication multi-primaire

De nombreuses approches classiques de la réplication sont basées sur un modèle de sauvegarde primaire dans lequel un périphérique ou un processus a un contrôle unilatéral sur un ou plusieurs autres processus ou périphériques. Par exemple, le primaire peut effectuer certains calculs, en diffusant un journal des mises à jour vers un processus de sauvegarde (en veille), qui peut ensuite prendre le relais en cas de défaillance du primaire. Cette approche est courante pour la réplication de bases de données, malgré le risque qu'en cas de perte d'une partie du journal lors d'une panne, la sauvegarde puisse ne pas être dans un état identique à la principale, et les transactions pourraient alors être perdues.

Une faiblesse des schémas de sauvegarde principale est qu'un seul exécute réellement des opérations. La tolérance aux pannes est gagnée, mais le système de sauvegarde identique double les coûts. Pour cette raison, à partir de c. 1985 , la communauté des chercheurs sur les systèmes distribués a commencé à explorer des méthodes alternatives de réplication des données. Une conséquence de ce travail a été l'émergence de schémas dans lesquels un groupe de répliques pourrait coopérer, chaque processus agissant comme une sauvegarde tout en gérant une partie de la charge de travail.

L'informaticien Jim Gray a analysé les schémas de réplication multi-primaires sous le modèle transactionnel et a publié un article largement cité sceptique quant à l'approche « Les dangers de la réplication et une solution ». Il a fait valoir qu'à moins que les données ne se séparent d'une manière naturelle afin que la base de données puisse être traitée comme n $n$ sous-bases de données disjointes, les conflits de contrôle de concurrence entraîneront une dégradation importante des performances et le groupe de répliques ralentira probablement en fonction de n . Gray a suggéré que les approches les plus courantes sont susceptibles d'entraîner une dégradation à l'échelle de O(n³) . Sa solution, qui consiste à partitionner les données, n'est viable que dans les situations où les données ont en fait une clé de partitionnement naturelle.

Dans les années 1985-1987, le modèle de synchronie virtuelle a été proposé et est devenu une norme largement adoptée (il a été utilisé dans les systèmes Isis Toolkit, Horus, Transis, Ensemble, Totem, Spread , C-Ensemble, Phoenix et Quicksilver, et est le base de la norme de calcul à tolérance de panne CORBA ). La synchronie virtuelle permet une approche multi-primaire dans laquelle un groupe de processus coopère pour paralléliser certains aspects du traitement des requêtes. Le schéma ne peut être utilisé que pour certaines formes de données en mémoire, mais peut fournir des accélérations linéaires de la taille du groupe.

Un certain nombre de produits modernes prennent en charge des programmes similaires. Par exemple, Spread Toolkit prend en charge ce même modèle de synchronisation virtuelle et peut être utilisé pour implémenter un schéma de réplication multi-primaire ; il serait également possible d'utiliser C-Ensemble ou Quicksilver de cette manière. WANdisco permet une réplication active où chaque nœud sur un réseau est une copie exacte ou une réplique et donc chaque nœud sur le réseau est actif en même temps ; ce schéma est optimisé pour une utilisation dans un réseau étendu (WAN).

Languages

In other projects