Cluster ferme avec load balancing et reprise sur panne

Équilibrage de charge réseau et basculement d’application

Le cluster ferme est une solution de haute disponibilité active-active, créée en déployant un module ferme au sein d'un cluster de deux nœuds ou plus. Le cluster ferme fournit à la fois l'équilibrage de la charge réseau, grâce à une distribution transparente du trafic réseau, et le basculement logiciel et matériel. Cette architecture offre une solution simple pour supporter l’augmentation de la charge du système.

La même application s'exécute sur chaque serveur, et la charge est équilibrée par la répartition de l'activité réseau sur les différents serveurs de la ferme.

Les clusters fermes sont adaptés aux applications frontales telles que les services Web.

Les solutions Apache, Microsoft IIS, NGINX sont des exemples de modules ferme. Vous pouvez écrire votre propre module ferme pour votre application, basé sur le module générique farm.safe.

Adresse IP virtuelle dans un cluster en ferme

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.

Équilibrage de charge dans un filtre réseau

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.

Applications avec ou sans état (Stateful ou Stateless)

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.

Comment configurer un cluster farm SafeKit ?

Console Web SafeKit : Configuration d'un cluster farm pour l'équilibrage de charge réseau et la gestion de l'IP virtuelle.

Le cluster farm SafeKit est conçu pour la haute disponibilité et l'évolutivité des services. La configuration se concentre sur la répartition du trafic entrant sur les deux nœuds simultanément :

Services avec équilibrage de charge (onglet Macros) : Définissez les services applicatifs spécifiques (ex : Apache, IIS, Nginx) qui doivent rester actifs sur tous les nœuds.
Réseau(x) de heartbeat : Chemin(s) de communication utilisé(s) pour détecter si un nœud a quitté la ferme, déclenchant une redistribution immédiate de la charge.
IP virtuelle (Farm VIP) : Contrairement à un cluster miroir, l'IP virtuelle Farm est partagée entre les nœuds à l'aide d'un algorithme de filtrage noyau pour répartir le trafic réseau.
Règles d'équilibrage de charge : Définissez la politique de répartition du trafic en fonction de l'adresse IP source ou du port.
Checkers (Vérificateurs) : Surveillez l'état de santé de l'application et déclenchez un redémarrage automatique si une défaillance de processus est détectée.

Comment surveiller un cluster farm SafeKit ?

Console SafeKit : Surveillance d'un cluster Farm à 2 nœuds montrant les deux nœuds à l'état UP avec un équilibrage de charge actif.

La surveillance d'un cluster farm offre une visibilité sur la nature Active-Active de l'infrastructure, où tous les nœuds contribuent aux performances de l'application (exemple ici avec 2 nœuds) :

État UP (50% sur 2 nœuds) : Dans une ferme saine, les deux nœuds sont à l'état « UP » (50%), ce qui signifie qu'ils reçoivent et traitent activement les requêtes clients via l'IP virtuelle partagée.
Rééquilibrage automatique : Si un nœud tombe en panne, la console montre visuellement que le nœud restant prend 100% du trafic. Il n'y a pas de délai de basculement, car le nœud survivant est déjà actif (hormis un temps de détection de quelques secondes).
Insertion de nœud : Lorsqu'un nœud réparé est redémarré, il passe de l'état « STOP » à « UP » et commence automatiquement à recevoir sa part de la charge sans intervention de l'administrateur.
Pas de synchro de données : Notez que dans un cluster farm, il n'y a pas d'état de resynchronisation « Orange », car les nœuds sont censés être sans état (stateless) ou partager une base de données backend (qui peut être protégée séparément dans un cluster miroir).

Au-delà des icônes d'état, l'interface permet une gestion des nœuds en un clic, vous permettant d'arrêter ou de démarrer manuellement un nœud pour une maintenance planifiée pendant que l'IP virtuelle partagée redistribue automatiquement le trafic sans interrompre l'activité des utilisateurs.

🔍 Hub de navigation SafeKit Haute Disponibilité

Explorez SafeKit : fonctionnalités, vidéos techniques, documentation et essai gratuit
Type de ressource	Description	Lien direct
Fonctionnalités clés	Pourquoi choisir SafeKit pour une haute disponibilité simple et économique ?	Voir pourquoi choisir SafeKit pour la Haute Disponibilité
Modèle de déploiement	HA SANless tout-en-un : Cluster logiciel sans partage (Shared-Nothing)	Voir SafeKit HA SANless tout-en-un
Partenaires	SafeKit : La référence en haute disponibilité pour les partenaires	Voir pourquoi SafeKit est la référence HA pour les partenaires
Stratégies HA	SafeKit : Infrastructure (VM) vs Haute Disponibilité au niveau applicatif	Voir SafeKit HA & Redondance : Niveau VM vs Niveau Applicatif
Spécifications techniques	Limitations techniques pour le clustering SafeKit	Voir les limitations de la Haute Disponibilité SafeKit
Preuve de concept	SafeKit : Démos de configuration HA et de basculement	Voir les tutoriels de basculement SafeKit
Architecture	Fonctionnement du cluster miroir SafeKit (Réplication et basculement en temps réel)	Voir Cluster miroir SafeKit : réplication et basculement en temps réel
Architecture	Fonctionnement du cluster de ferme SafeKit (Répartition de charge réseau et basculement)	Voir Cluster de ferme SafeKit : répartition de charge et basculement
Avantages concurrentiels	Comparaison : SafeKit vs Clusters de Haute Disponibilité (HA) traditionnels	Voir la comparaison SafeKit vs Clusters HA traditionnels
Ressources techniques	SafeKit Haute Disponibilité : Documentation, téléchargements et essai	Voir l'essai gratuit SafeKit HA & la documentation technique
Solutions préconfigurées	Bibliothèque de modules applicatifs SafeKit : solutions HA prêtes à l'emploi	Voir les modules applicatifs de Haute Disponibilité SafeKit