Réplication de données temps réel et continue dans un cluster 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, Linux ou AIX (même Windows 7 et 8). 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 pour construire un cluster actif/passif. Vous pouvez écrire votre propre module applicatif pour votre application. Microsoft SQL Server, MySQL, Oracle 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.

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 :


Démonstration




Livres blancs



contact
CONTACT


contact
NEWS

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