Architecture HA 3-tiers : clustering avec load balancing et mirroring

Le Serveur 1 (PRIM) exécute l'application Windows ou Linux. 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 Windows ou Linux 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 Windows ou Linux, 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 Windows ou Linux 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.

Sur la figure précédente, l'application Windows ou Linux 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 Windows ou Linux 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) Windows ou Linux, 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) Windows ou Linux, 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.