Réplication de données temps réel et continue dans un cluster miroir actif-passif

Réplication de données temps réel et continue dans un cluster miroir actif-passif

Haute disponibilité d'une application base de données critique avec réplication de données temps réel

Le logiciel SafeKit permet de construire un cluster actif-passif avec failover applicatif et réplication de données temps réel et continue des données. Le cluster actif-passif de SafeKit apporte une solution simple à la haute disponibilité d'applications base de données critiques sur Windows ou Linux (même les éditions Windows pour PCs). SafeKit implémente une réplication continue synchrone comme les SAN miroirs répliqués mais sans le coût et la complexité des clusters de failover matériel.

Réplication de données temps réel et continue dans un cluster actif-passif de type miroir

Le cluster actif-passif est une architecture de haute disponibilité de type miroir. L'application est exécutée sur un serveur primaire et redémarrée automatiquement sur un serveur secondaire si le serveur primaire est défaillant.

La réplication des données est configurée avec les répertoires de fichiers à répliquer. Les répertoires peuvent contenir des bases de données ou des fichiers plats. Avec sa fonction de réplication de données temps réel synchrone, cette architecture est particulièrement adaptée aux applications transactionnelles avec des données critiques à protéger contre les pannes.

SafeKit fournit un module générique miroir sur Windows et Linux pour construire un cluster actif/passif. Vous pouvez écrire votre propre module applicatif pour votre application. Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Firebird sont des exemples de modules applicatifs de type miroir. A partir d'un module miroir, une machine virtuelle complète peut être répliquée dans un cluster Hyper-V avec une reprise automatique sur panne. Notez que cet article permet de comprendre la différence entre la haute disponibilité de machines virtuelles vs la haute disponibilité d'applications.

Exemple: cluster Microsoft SQL Server 2012 avec réplication de données temps réel et reprise sur panne

Si vous souhaitez mettre en œuvre cette démonstration d'un cluster Microsoft SQL Server 2012 avec réplication temps réel et reprise sur panne, lisez cet article.

Comment fonctionne un cluster miroir avec le logiciel SafeKit ?

Etape 1. Réplication de données temps réel et continue

Cette étape correspond à la figure précédente. Le serveur 1 (PRIM) exécute l'application. Les utilisateurs sont connectés à l'adresse IP virtuelle du cluster miroir. SafeKit réplique les fichiers ouverts par l'application. Seules les modifications faites par l'application à l'intérieur des fichiers sont répliquées en continue à travers le réseau, limitant ainsi le trafic.

Réplication de données temps réel et continue dans un cluster actif-passif de type miroir

Avec la réplication de données temps réel de SafeKit, seuls les noms des répertoires de fichiers sont à configurer dans le module miroir. Les répertoires à répliquer peuvent être localisés dans le disque système.

Etape 2. Failover

Failover applicatif dans un cluster miroir avec réplication de données temps réel

Lorsque le serveur 1 est défaillant, SafeKit bascule l'adresse IP virtuelle du cluster sur le serveur 2 et redémarre automatiquement l'application. L'application retrouve les fichiers répliqués à jour grâce à la réplication continue synchrone réalisée par SafeKit entre le serveur 1 et le serveur 2. L'application poursuit son exécution sur le serveur 2 en modifiant localement ses fichiers qui ne sont plus répliqués vers le serveur 1.

Le temps de basculement est égal au temps de détection de la panne (time-out configuré à 30 secondes par défaut) et au temps de relance de l'application. Sur la machine secondaire, il n'y a pas de temps lié au remontage du système de fichiers ou au passage des procédures de recovery du système de fichiers, comme avec les solutions de réplication de disques.

Etape 3. Failback et réintégration

Failback et réintégration dans un cluster miroir avec réplication de données temps réel

A la reprise après panne du serveur 1 (réintégration du serveur 1), SafeKit resynchronise automatiquement les fichiers de ce serveur à partir de l'autre serveur. Seuls les fichiers modifiés sur le serveur 2 pendant l'inactivité du serveur 1 sont resynchronisés.

La réintégration du serveur 1 se fait sans arrêter l'exécution des applications sur le serveur 2. Cette propriété est un gros différentiateur du produit SafeKit par rapport à d'autres solutions qui nécessitent d'arrêter les applications sur le serveur 2 pour réintégrer le serveur 1.

Pour optimiser la réintégration de fichiers, il y a plusieurs cas de figure :

  1. Si SafeKit a été proprement arrêté sur le serveur 1, alors à son redémarrage, seules les zones modifiées à l'intérieur des fichiers sont réintégrées suivant des bitmaps de modification.
  2. Si la serveur 1 a crashé (power off) ou a été incorrectement arrêtée (exception dans le processus de réplication), les bitmaps de modification ne sont pas sûres et elles ne sont donc pas utilisées. Tous les fichiers qui ont été modifiés depuis le moment de l'arrêt moins une période de grâce (typiquement une heure) sont réintégrés.

Etape 4. Retour à la normale avec réplication de données temps réel continue et synchone

Retour à la normale d'un cluster actif-passif avec réplication de données temps réel

Après la réintégration, les fichiers sont à nouveau en mode miroir comme à l'étape 1. Le système est en haute disponibilité avec l'application qui s'exécute sur le serveur 2 et avec comme secours le serveur 1. Les modifications de l'application dans les fichiers sont répliquées en temps réel du serveur 2 vers le serveur 1.

Si l'administrateur souhaite que son application s'exécute en priorité sur le serveur 1, il peut exécuter une commande de basculement, soit manuellement à un moment opportun, soit automatiquement par configuration.

En savoir plus :

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

3 démonstrations [+]

Modules de haute disponibilité appicatifs [+]

Solutions Cloud [+]

Clients [+]

Meilleurs cas d'utilisation [+]

Avantages distinctifs [+]

Plus d'information sur le cluster miroir [+]

Webinaire SafeKit [+]

Prix - Essai gratuit [+]