eviden-logo

Evidian > Produits > Logiciel de haute disponibilité - Zéro surcoût matériel > Microsoft NLB avec VMware: alternative aux adresses multicast et unicast avec le logiciel SafeKit

Microsoft NLB avec VMware: alternative aux adresses multicast et unicast avec le logiciel SafeKit

Evidian SafeKit

Mode multicast de Microsoft NLB

Comme expliqué dans la base de connaissances de VMware pour la configuration du mode multicast de Microsoft NLB, vous devez positionner manuellement la résolution ARP statique des switchs ou des routeurs réseaux pour chaque port connecté au cluster. Le déploiement du mode multicast de Microsoft NLB dans un environnement réseau inconnu peut s'avérer une tâche complexe et ardue.

Mode unicast de Microsoft NLB

Avec le mode unicast de Microsoft NLB, vous devez configurer l'hôte ESXi / ESX pour qu'il n'envoie pas de paquets RARP lorsque l'une de ses machines virtuelles est mise sous tension. C'est pourquoi VMware recommande de ne pas utiliser le mode unicast de Microsoft NLB.

Alternative avec Evidian SafeKit

La configuration de l'adresse IP virtuelle de SafeKit ne nécessite aucune configuration réseau particulière et l'équilibrage de charge réseau peut s'exécuter dans n'importe quel environnement. Une fonctionnalité importante lorsque la solution doit être déployée dans une infrastructure inconnue : switchs ou routeurs inconnus, serveurs physiques ou serveurs virtuels.

Comment fonctionne le cluster ferme de SafeKit ?

Adresse IP virtuelle dans un cluster feme

Equilibrage de charge et haute disponibilité

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.

Partage de charge dans un filtre réseau

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.

Applications à état et sans état

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.

Différentiateurs de la solution de haute disponibilité SafeKit

SafeKit Quick Installation Guides

New application (real-time replication and failover)


New application (network load balancing and failover)


Database (real-time replication and failover)


Web (network load balancing and failover)


Full VM or container real-time replication and failover


Amazon AWS


Google GCP


Microsoft Azure


Other clouds


Physical security (real-time replication and failover)


Siemens (real-time replication and failover)