Réplication synchrone versus réplication asynchrone

Perte de données ou non sur failover 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 failover d'une application critique.

La réplication synchrone est essentiel pour le failover 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.

La vidéo "Réplication base de données interrompue par une panne informatique ?" démontre ce qui se passe lorsqu'une défaillance de serveur survient alors qu'une file de messages transactionnelle est mise à jour. La vidéo a été réalisée avec le logiciel de haute disponibilité SafeKit et sa solution de réplication temps réel et continue dans un cluster actif-passif.

Quels sont les autres points importants à considérer lorsqu'on choisit une solution de haute disponibilité ?

Si vous voulez comprendre les conséquences d'un mauvais choix avec une situation de crise réelle dans un aéroport, nous vous recommandons ce guide de choix d'une solution cluster.

Les autres points importants à considérer lors du choix d'une solution de haute disponibilité sont :

 

Considérations techniques

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 failover 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 le configuration du cluster.

Réplication asynchrone

Avec la réplication asynchrone au niveau fichier mise en œuvre par d'autres solutions comme DoubleTake, 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 second serveur 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.

Pour en savoir plus, voir ce guide de choix d'une solution cluster.


Guide de choix



contact
CONTACT


contact
NEWS

Pour recevoir des informations d'Evidian, veuillez remplir le formulaire suivant.