Le cluster logiciel miroir

Haute disponibilité avec réplication temps réel de fichiers et reprise applicative sur panne

Le cluster logiciel miroir est une solution de haute disponibilité applicative de type primaire - secours. L'application est exécutée sur un serveur primaire et redémarrée automatiquement sur un serveur de secours si le serveur primaire est défaillant.

Le cluster miroir peut être configurée avec ou sans réplication de fichiers. Avec la réplication de fichiers, ce cluster est particulièrement adaptée à la haute disponibilité des applications base de données avec des données critiques à protéger contre les pannes.

Microsoft SQL Server.Safe, MySQL.Safe, Oracle.Safe sont des exemples de modules applicatifs de type "miroir". Vous pouvez écrire votre propre module miroir pour votre application à partir du module générique Mirror.Safe.

Le système de reprise d'un cluster logiciel miroir fonctionne de la façon suivante.

Etape 1. Etat normal d'un miroir

Seuls les noms des répertoires de fichiers à répliquer sont configurés dans SafeKit. Il n'y a pas de pré-requis sur l'organisation disque des deux serveurs. Les répertoires à répliquer peuvent être localisés dans le disque système.

Le serveur 1 (PRIM) exécute l'application.

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 temps réel à travers le réseau, limitant ainsi le trafic.

Etape 2. Reprise sur panne

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 synchrone réalisée par SafeKit entre le serveur 1 et le serveur 2. L'application continue 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. Réintégration après panne

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

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.

Solution de réplication synchrone versus réplication asynchrone

Il existe une grande différence entre réplication synchrone de données mise en œuvre par la solution miroir de SafeKit et réplication asynchrone de données telle qu’elle est traditionnellement mise en œuvre dans les solutions de réplication de fichiers.

Avec une réplication synchrone, 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.

La bande passante d'un LAN entre les deux serveurs est nécessaire pour mettre en œuvre une réplication synchrone de données avec éventuellement un LAN étendu dans deux salles machines géographiquement éloignées.

Avec la réplication asynchrone mise en œuvre par d'autres 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 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.

SafeKit propose une solution asynchrone avec un asynchronisme non pas sur la machine primaire mais sur la machine secondaire. Dans cette solution, SafeKit attend toujours l'acquittement des deux machines 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. 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.

Livre blanc Safekit >>