Comment fonctionne une adresse IP virtuelle (Windows/Linux) ?

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)

• Réseau 1 Gb/s ≈ 3 heures pour 1 téraoctet.
• Réseau 10 Gb/s ≈ 1 heure pour 1 téraoctet ou moins selon les performances d’écriture disque.

Alternative

• Pour un volume de données important, utiliser un stockage partagé externe.
• Plus coûteux, plus complexe.

• Performance du temps de resynchronisation après une panne (étape 3).
• Temps nécessaire pour vérifier chaque fichier entre les deux nœuds.

Alternative

• Regrouper les nombreux fichiers à répliquer dans un disque dur virtuel / une machine virtuelle.
• Seuls les fichiers représentant le disque dur virtuel / la machine virtuelle seront répliqués et resynchronisés dans ce cas.

• Chaque VM fonctionne dans un module miroir indépendant.
• Maximum de 32 modules miroir exécutés sur le même cluster.

Alternative

• Utiliser un stockage partagé externe et une autre solution de clustering de VM.
• Plus coûteux, plus complexe.

• Basculement automatique de l’adresse IP virtuelle avec 2 nœuds dans le même sous-réseau.
• Bonne bande passante pour la resynchronisation (étape 3) et bonne latence pour la réplication synchrone (typiquement un aller-retour inférieur à 2 ms).

Alternative

• Utiliser un load balancer pour l’adresse IP virtuelle si les 2 nœuds sont dans 2 sous-réseaux (pris en charge par SafeKit, notamment dans le cloud).
• Utiliser des solutions de sauvegarde avec réplication asynchrone pour un réseau à forte latence.

Sur la figure précédente, l'application s'exécute 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 du cluster en ferme.
Le trafic entrant vers l'adresse IP virtuelle est reçu par tous les serveurs et réparti entre eux par un filtre réseau à l'intérieur du noyau de chaque serveur.
SafeKit détecte les pannes matérielles et logicielles, reconfigure les filtres réseau en cas de panne et offre des vérificateurs d'application et des scripts de récupération configurables.

L'algorithme d'équilibrage de charge réseau à l'intérieur du filtre réseau est basé sur l'identité des paquets clients (adresse IP client, port TCP client). En fonction de l'identité du paquet client entrant, un seul filtre dans un serveur accepte le paquet; les autres filtres dans les autres serveurs le rejettent.
Une fois qu'un paquet est 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 sortie sont envoyés directement du serveur d'application au client.
Si un serveur tombe en panne, le protocole de battement de cœur de la ferme reconfigure les filtres dans le cluster d'équilibrage de charge réseau pour rééquilibrer le trafic sur les serveurs disponibles restants.

Avec une application avec état (stateful), il y a une affinité de session. Le même client doit être connecté au même serveur sur plusieurs sessions TCP pour récupérer son contexte sur le serveur. Dans ce cas, la règle d'équilibrage de charge SafeKit est configurée sur l'adresse IP du client. Ainsi, le même client est toujours connecté au même serveur sur plusieurs sessions TCP. Et différents clients sont répartis sur différents serveurs de la ferme.
Avec une application sans état (stateless), il n'y a pas d'affinité de session. Le même client peut être connecté à différents serveurs de la ferme sur plusieurs sessions TCP. Il n'y a aucun contexte stocké localement sur un serveur d'une session à l'autre. Dans ce cas, la règle d'équilibrage de charge SafeKit est configurée sur l'identité de la session client TCP. Cette configuration est celle qui est la meilleure pour répartir les sessions entre les serveurs, mais elle nécessite un service TCP sans affinité de session.

Ce tableau présente les solutions de Haute Disponibilité (HA) SafeKit, classées par catégorie d'application et environnement d'exploitation (Bases de données, Serveurs Web, VM, Cloud). Identifiez le module .safe pré-configuré spécifique (par exemple, mirror.safe, farm.safe, et autres) nécessaire pour la réplication en temps réel, l'équilibrage de charge et le basculement automatique des applications critiques sur Windows ou Linux. Simplifiez la configuration de votre cluster HA grâce à des liens directs vers les guides d'installation rapide, chacun incluant un lien de téléchargement pour le module .safe correspondant.

Un module .safe SafeKit est essentiellement un modèle de Haute Disponibilité (HA) pré-configuré qui définit la manière dont une application spécifique sera mise en cluster et protégée par le logiciel SafeKit. En pratique, il contient un fichier de configuration (userconfig.xml) et des scripts de redémarrage.