Cluster ferme avec load balancing et reprise sur panne

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.