Réplication synchrone versus réplication asynchrone

Réplication synchrone versus réplication asynchrone

Perte de données ou non sur basculement d'une application critique ?

Il existe une grande différence entre une réplication synchrone versus une réplication asynchrone. Le choix détermine s'il y a perte de données sur panne et reprise d'une application critique sur un autre serveur.

La réplication synchrone est essentiel pour le basculement d'applications transactionnelles. Avec une réplication synchrone, toutes les données committées sur le disque du serveur primaire se retrouvent sur le disque du serveur secondaire. Avec une réplication asynchrone, des données committées sur le disque du serveur primaire peuvent être perdues en cas de panne. Il existe une solution alternative appelée réplication semi-synchrone, avec les données committées sur le serveur secondaire mais pas forcément sur son disque.

Pour vous aider à prendre la bonne décision entre réplication synchrone versus réplication asynchrone, nous expliquons maintenant les mécanismes techniques et leurs impacts sur le basculement d'une application.

La réplication synchrone nécessite la bande passante d'un LAN entre les serveurs, avec la possibilité d'avoir un LAN étendu dans deux salles machines géographiquement distantes. La réplication asynchrone peut être mise en œuvre sur un WAN bas débit.

Réplication synchrone

Avec une réplication synchrone au niveau fichier comme le propose le logiciel de haute disponibilité SafeKit, lorsqu'une IO disque est réalisée par l'application ou le cache système sur le serveur primaire et sur un fichier répliqué, SafeKit attend l'acquittement de l'IO du disque local et du serveur secondaire avant d'envoyer l'acquittement à l'application ou au cache système. Ce mécanisme est indispensable pour la reprise d'applications transactionnelles. Notez que SafeKit réalise une réplication temps réel et continue en répliquant des répertoires de fichiers et non des disques entiers, ce qui simplifie grandement la configuration du cluster.

Notez que de nombreuses solutions de haute disponibilité avec réplication synchrone de Microsoft SQL Server, PosgreSQL, fichiers plats, etc. sont disponibles avec un essai gratuit de SafeKit dans l'article suivant. Notez également que SafeKit est capable de resynchroniser automatiquement un serveur défaillant sans aucune opération manuelle et sans arrêter l'application critique. C'est un facteur de différenciation important lorsqu'on compare SafeKit à des solutions de réplication dont le basculement ne marche qu'une fois : le serveur en panne ne peut être réintégré dans le cluster qu'avec des opérations manuelles complexes et non automatisées.

Réplication asynchrone

Avec la réplication asynchrone au niveau fichier mise en œuvre par la plupart des solutions, les IOs sont mises dans une file sur le serveur primaire et les acquittements du serveur secondaire ne sont pas attendus. Donc, toutes les données qui n'ont pas eu le temps d'être recopiées à travers le réseau sur le serveur secondaire sont perdues en cas de panne du premier serveur.

Notamment, une application transactionnelle perd des données commitées en cas de panne. La réplication asynchrone est adaptée à la réplication de données à travers un réseau bas débit de type WAN, pour réaliser un backup à distance.

Réplication semi-synchrone

Avec une réplication semi-synchrone au niveau fichier comme le propose le logiciel de haute disponibilité SafeKit, l'asynchronisme n'est pas réalisé sur la machine primaire mais sur la machine secondaire. Dans cette solution, l'acquittement des deux machines est toujours attendu avant d'envoyer l'acquittement à l'application ou au cache système. Mais sur la secondaire, il y a 2 options asynchrone ou synchrone.

Dans le cas asynchrone, la secondaire envoie l'acquittement à la primaire dès réception de l'IO puis écrit sur disque. Dans le cas synchrone, la secondaire écrit l'IO sur disque puis envoie l'acquittement à la primaire.

Mais attention, le mode synchrone sur la secondaire est nécessaire si l'on considère une double panne électrique simultanée des deux serveurs avec impossibilité de redémarrer l'ex serveur primaire et obligation de redémarrer sur le secondaire.

Conclusion

Vous voyez que juste retarder les écritures sur le serveur secondaire a un impact direct sur le failover applicatif. Donc soyez prudent sur les conséquences du choix entre réplication synchrone versus réplication asynchrone. Préférez toujours une réplication synchrone pour une application critique.

Différenciateurs clés de la solution de réplication et de haute disponibilité avec le cluster miroir d'Evidian SafeKit

Cluster miroir d'Evidian SafeKit avec réplication de fichiers temps réel et reprise sur panne

Réplication synchrone Synchronous replication

Like  La réplication en temps réel est synchrone sans perte de données en cas de panne

Dislike  Ce n'est pas le cas avec une réplication asynchrone

Retour d'un serveur tombé en panne totalement automatisé (failback) Automatic failback

Like  Suite à une panne de serveur et à un basculement, le retour du serveur tombé en panne se fait de manière totalement automatique avec une resynchronisation de ses données et sans arrêter l'application sur le seul serveur restant

Dislike  Ce n'est pas le cas avec la plupart des solutions de réplication particulièrement celles avec une réplication au niveau base de données. Des opérations manuelles sont requises pour resynchroniser le serveur défaillant. Il peut être même nécessaire d'arrêter l'application sur le seul serveur restant

Toutes les fonctionnalités de clustering All clustering features

Like  La solution inclut toutes les fonctionnalités de clustering: surveillance de la défaillance des serveurs, surveillance de la défaillance réseau, surveillance de la défaillance logicielle, redémarrage automatique de l'application avec un temps de reprise rapide, une adresse IP virtuelle basculée en cas de panne pour rerouter automatiquement les clients. Une configuration de clustering est simplement réalisée au moyen d'un module de haute disponibilité applicatif. Il n'y a pas de contrôleur de domaine ou d'Active Directory à configurer sur Windows. La solution fonctionne sur Windows et Linux

Dislike  Ce n'est pas le cas avec les solutions de réplication pure comme la réplication au niveau base de données

Dislike  Un redémarrage rapide de l'application n'est pas assuré avec une réplication complète de machines virtuelles. En cas de panne d'un hyperviseur, une machine virtuelle doit être rebootée sur un nouvel hyperviseur avec un temps de redémarrage inconnu

Réplication de n'importe quel type de données

Like  La réplication fonctionne pour les bases de données mais aussi pour n'importe quel fichier qui doit-être répliqué

Dislike  Ce n'est pas le cas pour la réplication au niveau base de données

Réplication de fichiers vs réplication de disque File replication vs disk replication

Like  La réplication est basée sur des répertoires de fichiers qui peuvent être localisés n'importe où (même dans le disque système)

Disike  Ce n'est pas le cas avec la réplication de disque où une configuration spéciale de l'application est nécessaire pour placer les données applicatives dans un disque spécial

Réplication de fichiers vs disque partagé File replication vs shared disk

Like  Les serveurs peuvent être placés dans deux sites distants

Dislike  Ce n'est pas le cas avec les solutions à disque partagé

Sites distants Remote sites

Like   Avec des sites distants, la solution fonctionne avec seulement 2 serveurs et pour le quorum (isolation réseau), un simple split brain checker est offert

Dislike  Ce n'est pas le cas pour la plupart des solutions de clustering où un 3ième serveur est nécessaire pour le quorum

Like   Si les deux serveurs sont connectés au même réseau IP via un réseau local étendu entre deux sites distants, l'adresse IP virtuelle de SafeKit fonctionne avec une redirection au niveau 2

Like   Si les deux serveurs sont connectés à deux réseaux IP différents entre deux sites distants, l'adresse IP virtuelle peut être configurée au niveau d'un load balancer. SafeKit propose un "health check": le load balancer est configuré avec une URL gérée par SafeKit qui renvoie OK sur le serveur primaire et NOT FOUND sinon. Cette solution est implémentée pour SafeKit dans le Cloud, mais elle peut être également mise en œuvre avec un load balancer sur site

Dislike   L'adresse IP virtuelle n'est pas offerte par une solution de pure réplication

Solution de haute disponibilité uniforme Uniform high availability solution

Like  SafeKit implémente un cluster miroir avec une réplication et une reprise sur panne. Mais il implémente aussi un cluster ferme avec load balancing et reprise sur panne. Ainsi une architecture N-tiers peut-être rendue hautement disponible et load balancée avec la même solution sur Windows et Linux (même installation, configuration, administration avec la console SafeKit ou les commandes en ligne). Ceci est unique sur le marché

Dislike  Ce n'est pas le cas avec une architecture mixant des technologies différentes pour le load balancing, la réplication et la reprise sur panne

FAQ sur Evidian SafeKit (réplication synchrone)

3 démonstrations [+]

Modules de haute disponibilité appicatifs [+]

Solutions Cloud [+]

Clients [+]

Meilleurs cas d'utilisation [+]

Avantages distinctifs [+]

Plus d'information sur le cluster miroir [+]

Plus d'information sur le cluster ferme [+]

Webinaire SafeKit [+]

Prix - Essai gratuit [+]