eviden-logo

Evidian > Produits > SafeKit : Logiciel de haute disponibilité simple et économique > Réplication synchrone versus réplication asynchrone

Réplication synchrone versus réplication asynchrone

Evidian SafeKit

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 lors du basculement et de la reprise d'une application critique sur le serveur secondaire.

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.

Le choix entre réplication synchrone versus réplication asynchrone détermine s'il y a perte de données ou pas sur panne.

Réplication synchrone

Avec une réplication synchrone comme le propose le logiciel SafeKit, lorsqu'une IO disque est réalisée par l'application ou le cache système sur le serveur primaire, 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 lorsqu'elles committent leurs transactions.

Réplication asynchrone

Avec la réplication asynchrone 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 serveur primaire. Une application transactionnelle perd des transactions committées lors d'une reprise après panne.

Réplication semi-synchrone

Avec une réplication semi-synchrone, SafeKit attend toujours l'acquittement des deux serveurs avant d'envoyer l'acquittement à l'application ou au cache système. Mais dans le cas semi-synchrone, le serveur secondaire envoie l'acquittement au serveur primaire dès réception de l'IO puis écrit sur disque. Dans le cas synchrone, le serveur secondaire écrit l'IO sur disque puis envoie l'acquittement au serveur primaire.

Conclusion

Une réplication asynchrone perd des données en cas de basculement et de reprise après panne. Même une réplication semi-synchrone perd des données dans le cas particulier d'une double panne électrique simultanée sur les deux serveurs avec l'impossibilité de redémarrer sur l'ex serveur primaire et l'obligation de redémarrer sur le serveur secondaire. 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 ou semi-synchrone pour une application critique.

Vidéo : réplication synchrone versus réplication asynchrone >

Comment fonctionne le cluster miroir SafeKit?

Étape 1. Réplication en temps réel

Le Serveur 1 (PRIM) exécute l'application. Les clients sont connectés à une adresse IP virtuelle. SafeKit réplique en temps réel les modifications apportées à l'intérieur des fichiers à travers le réseau.

Réplication de fichiers au niveau octet dans un cluster miroir

La réplication est synchrone sans perte de données en cas de défaillance, contrairement à la réplication asynchrone.
Il vous suffit de configurer les noms des répertoires à répliquer dans SafeKit. Il n'y a pas de prérequis sur l'organisation des disques. Les répertoires peuvent être situés dans le disque système.

Étape 2. Bascule automatique (failover)

Lorsque le Serveur 1 tombe en panne, le Serveur 2 prend le relais. SafeKit bascule l'adresse IP virtuelle et redémarre l'application automatiquement sur le Serveur 2.
L'application retrouve les fichiers répliqués par SafeKit à jour sur le Serveur 2. L'application continue de fonctionner sur le Serveur 2 en modifiant localement ses fichiers qui ne sont plus répliqués vers le Serveur 1.

Bascule (failover) dans un cluster miroir

Le temps de bascule est égal au temps de détection de panne (30 secondes par défaut) plus le temps de démarrage de l'application.

Étape 3. Reprise automatique (failback)

La reprise (failback) consiste à redémarrer le Serveur 1 après avoir résolu le problème qui a causé sa défaillance.
SafeKit resynchronise automatiquement les fichiers, mettant à jour uniquement les fichiers modifiés sur le Serveur 2 pendant que le Serveur 1 était arrêté.

Reprise (failback) dans un cluster miroir

La reprise a lieu sans perturber l'application, qui peut continuer à s'exécuter sur le Serveur 2.

Étape 4. Retour à la normale

Après la réintégration, les fichiers sont à nouveau en mode miroir, comme à l'étape 1. Le système est de retour en mode haute disponibilité, avec l'application fonctionnant sur le Serveur 2 et SafeKit répliquant les mises à jour de fichiers vers le Serveur 1.

Retour au fonctionnement normal dans un cluster miroir

Si l'administrateur souhaite que l'application s'exécute sur le Serveur 1, il/elle peut exécuter une commande "swap" soit manuellement à un moment opportun, soit automatiquement via la configuration.

Utilisation typique avec SafeKit

Pourquoi une réplication de quelques téraoctets ?

Temps de resynchronisation après une panne (étape 3)

  • Réseau 1 Gb/s ≈ 3 heures pour 1 téraoctet.
  • Réseau 10 Gb/s ≈ 1 heure pour 1 téraoctet ou moins selon les performances d’écriture disque.

Alternative

Pourquoi une réplication < 1 000 000 fichiers ?

  • Performance du temps de resynchronisation après une panne (étape 3).
  • Temps nécessaire pour vérifier chaque fichier entre les deux nœuds.

Alternative

  • Regrouper les nombreux fichiers à répliquer dans un disque dur virtuel / une machine virtuelle.
  • Seuls les fichiers représentant le disque dur virtuel / la machine virtuelle seront répliqués et resynchronisés dans ce cas.

Pourquoi un basculement ≤ 32 VM répliquées ?

  • Chaque VM fonctionne dans un module miroir indépendant.
  • Maximum de 32 modules miroir exécutés sur le même cluster.

Alternative

  • Utiliser un stockage partagé externe et une autre solution de clustering de VM.
  • Plus coûteux, plus complexe.

Pourquoi un réseau LAN/VLAN entre sites distants ?

  • Basculement automatique de l’adresse IP virtuelle avec 2 nœuds dans le même sous-réseau.
  • Bonne bande passante pour la resynchronisation (étape 3) et bonne latence pour la réplication synchrone (typiquement un aller-retour inférieur à 2 ms).

Alternative

  • Utiliser un load balancer pour l’adresse IP virtuelle si les 2 nœuds sont dans 2 sous-réseaux (pris en charge par SafeKit, notamment dans le cloud).
  • Utiliser des solutions de sauvegarde avec réplication asynchrone pour un réseau à forte latence.

Comparaison de SafeKit avec les clusters de Haute Disponibilité (HA) traditionnels

Comment SafeKit se compare-t-il aux solutions de cluster de Haute Disponibilité (HA) traditionnelles ?

Cette comparaison met en évidence les différences fondamentales entre SafeKit et les solutions de cluster de Haute Disponibilité (HA) traditionnelles comme les clusters de basculement, la HA de virtualisation et SQL Always-On. SafeKit est conçu comme une solution logicielle à faible complexité pour la redondance d'applications génériques, contrastant avec la complexité élevée et les exigences de stockage spécifiques (stockage partagé, SAN) typiques des mécanismes HA traditionnels.
Comparaison de SafeKit avec les clusters de Haute Disponibilité (HA) traditionnels
Solutions Complexité Commentaires
Cluster de Basculement (Microsoft) Élevée Stockage Spécifique (stockage partagé, SAN)
Virtualisation (VMware HA) Élevée Stockage Spécifique (stockage partagé, SAN, vSAN)
SQL Always-On (Microsoft) Élevée Seul SQL est redondant, nécessite SQL Enterprise Edition
Evidian SafeKit Faible Le plus simple, générique et uniquement logiciel. Ne convient pas à la réplication de grandes quantités de données.

L'avantage de SafeKit en matière de redondance d'application

SafeKit atteint sa Haute Disponibilité à faible complexité grâce à un simple mécanisme de miroir basé sur logiciel qui élimine le besoin de matériel coûteux et dédié comme un SAN (Storage Area Network). Cela en fait une solution très accessible pour la mise en œuvre rapide de la redondance d'application sans modifications d'infrastructure complexes.

Solutions HA SafeKit et Guides d'Installation Rapide (avec modules .safe préconfigurés)

Comment Configurer la HA pour les Nouvelles Applications avec Réplication en Temps Réel et Basculement?


Comment Configurer la HA pour les Nouvelles Applications avec Équilibrage de Charge Réseau et Basculement?


Comment Configurer la HA pour les Services Cloud Amazon AWS?


  • AWS (Réplication en Temps Réel et Basculement - mirror.safe)
  • AWS (Équilibrage de Charge Réseau et Basculement - farm.safe)

Comment Configurer la HA pour les Services Cloud Google GCP?


  • GCP (Réplication en Temps Réel et Basculement - mirror.safe)
  • GCP (Équilibrage de Charge Réseau et Basculement - farm.safe)

Comment Configurer la HA pour les Services Cloud Microsoft Azure?


  • Azure (Réplication en Temps Réel et Basculement - mirror.safe)
  • Azure (Équilibrage de Charge Réseau et Basculement - farm.safe)