File replication and failover

L'architecture miroir est une solution de haute disponibilité de type primaire, secours applicable à n'importe quelle application. 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. Avec la réplication de fichiers, cette architecture 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 fonctionne de la façon suivante :

Étape 1

: Please, click to enlarge the image

Configurer les fichiers applicatifs à répliquer. Il n'y a pas de pré-requis sur l'organisation disque des deux serveurs : par exemple, les fichiers à répliquer peuvent être sur un disque interne RAID5 dans le serveur 1 et sur un simple disque interne dans le serveur 2.

Le serveur 1 exécute l'application. SafeKit réplique les fichiers ouverts par l'application. Seules les modifications faites par l'application sont répliquées en temps réel à travers le réseau, limitant ainsi le trafic. La réplication synchrone des écritures fichiers sur les disques des deux serveurs assure la non perte de données en cas de panne.

Notamment, la réplication synchrone des fichiers assure que toute donnée commitée sur un disque par une application transactionnelle est retrouvée sur la machine secondaire. Ce que n'assure pas les produits mettant en œuvre une réplication asynchrone.

Étape 2

: Please, click to enlarge the image

Lorsque le serveur 1 est défaillant, la reprise sur le serveur 2 est assurée. SafeKit bascule l'adresse IP virtuelle du cluster et redémarre automatiquement l'application sur le serveur 2. L'application retrouve les fichiers répliqués par SafeKit avec l'assurance qu'aucune écriture synchrone sur disque n'a été perdue entre le serveur 1 et le serveur 2.

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.

Étape 3

: Please, click to enlarge the image

A la reprise après panne du serveur 1 (redémarrage du serveur après défaillance), SafeKit re-synchronise automatiquement les fichiers. Seuls les fichiers modifiés sur le serveur 2 pendant l'inactivité du serveur 1 sont re-synchronisés.

La resynchronisation du serveur 1 se fait sans arrêter l'exécution des applications sur le serveur 1. 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 resynchroniser le serveur 1.

Étape 4

: Please, click to enlarge the image

Après la re-synchronisation, les fichiers sont à nouveau en mode miroir comme à l'étape 1. Le système est de nouveau en haute disponibilité avec l'application qui s'exécute sur le serveur 2 et avec comme secours 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, soit automatiquement par configuration.

Solution de réplication synchrone qui ne perd pas de données en cas de panne

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. Avec une réplication asynchrone, toutes les données qui n'ont pas eu le temps d'être récopié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.

Avec SafeKit, la réplication synchrone et temps réel des données sur des fichiers ouverts par une application assure la haute disponibilité applicative sans perte de données en cas de panne. 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 éloignées de quelques kilomètres. 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 sur plus de 100 kilomètres.