Comment Configurer la HA pour les Nouvelles Applications avec Réplication en Temps Réel et Basculement?
- Windows (mirror.safe)
- Linux (mirror.safe)
Haute disponibilité dans le marché de la sécurité physique
Architectures de base
Architectures avancées
Bonnes pratiques en matière de haute disponibilité
Bonnes pratiques en matière de clustering
Essai gratuit
Information produit
Evidian > Produits > SafeKit : Logiciel de haute disponibilité simple et économique > Solutions SafeKit sur Windows et Linux avec des modules applicatifs
Avec le logiciel SafeKit, la configuration d'un cluster de basculement est très simple. Il faut configurer soit un module applicatif ferme, soit un module applicatif miroir suivant l'architecture de haute disponibilité adaptée à l'application critique à sécuriser.
Un module applicatif inclut :
Une fois un module applicatif configuré et testé, le déploiement d'un cluster de basculement avec le logiciel SafeKit ne requiert pas de compétence informatique spécifique :
La configuration est simplifiée grâce à une console web.
Dans cette solution, seules les données de l’application sont répliquées. En cas de panne, seule l’application est redémarrée, et non le système d’exploitation ou la VM entière.

Dans cette solution, la machine virtuelle complète (VM) est répliquée, incluant l’application et le système d’exploitation (OS). En cas de panne, la VM entière est redémarrée.

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.
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.
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.
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.
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é.
La reprise a lieu sans perturber l'application, qui peut continuer à s'exécuter sur le Serveur 2.
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.
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.
Temps de resynchronisation après une panne (étape 3)
Sur la figure précédente, l'application tourne sur les 3 serveurs (3 est un exemple, il peut y en avoir 2 ou plus). Les utilisateurs sont connectés à une adresse IP virtuelle.
L'adresse IP virtuelle est configurée localement sur chaque serveur de la ferme.
Le trafic du réseau à destination de l'adresse IP virtuelle est reçu par l'ensemble des serveurs. Puis ce trafic est distribué entre les serveurs grâce à un filtre réseau chargé dans le noyau du système d'exploitation de chaque serveur.
SafeKit détecte les pannes matérielles et logicielles, reconfigure les filtres réseau en cas de panne et offre des checkers et des scripts de reprise applicatifs configurables.
L'algorithme de load balancing dans le filtre réseau est basé sur l'identité des paquets client (adresse IP client, port TCP client). Suivant l'identité du paquet client en entrée, seul un filtre dans un serveur accepte le paquet ; les autres filtres dans les autres serveurs le rejettent.
Une fois un paquet accepté par le filtre sur un serveur, seuls le CPU et la mémoire de ce serveur sont utilisés par l'application qui répond à la requête du client. Les messages de retour de l'application sont envoyés directement du serveur vers le client.
Lorsqu'un serveur est défaillant, le protocole de gestion du groupe des serveurs en vie reconfigure les filtres pour redistribuer le trafic vers les serveurs disponibles.
Avec une application à état, il y a affinité de session. Le même client doit être connecté sur le même serveur sur plusieurs sessions TCP pour retrouver son contexte sur le serveur. Dans ce cas, la règle de load balancing SafeKit est configurée sur l'adresse IP des clients. Ainsi, le même client est toujours connecté sur le même serveur sur plusieurs sessions TCP. Et différents clients sont répartis sur les différents serveurs de la ferme.
Avec une application sans état, il n'y a pas d'affinité de session. Le même client peut être connecté sur des serveurs différents dans la ferme lors de sessions TCP successives. Dans ce cas, la règle de load balancing SafeKit est configurée sur l'identité de la session TCP du client. Cette configuration est celle qui répartit le mieux les sessions entre les serveurs mais elle requiert un service TCP sans affinité de session.