La seconde solution qui s’offre à vous est l’utilisation des services Windows Network Load Balancing. Pour en avoir installé plusieurs fois, ce service « fonctionne » mais possède pas mal de défauts.
Le premier tient parfois à sa complexité de mise en place selon l’environnement
WINDOWS Network LOAD BALANCING (WNLB)
réseau, surtout dans des environnements virtuels ou lorsque vous être confronté à deux sites physiques distants inscrits dans le même sous réseau IP.
Le second problème est qu’il ne prend pas en compte la vérification du fonctionnement des services. Comme le DNS Round Robin, la couche NLB Windows n’a pas grand-chose à voir avec l’environnement Exchange. Si l’un des serveurs d’accès client vient à cesser de fonctionner, le WNLB lui, toujours actif, tentera d’acheminer les requêtes clients vers le serveur hors service.
Le troisième problème comme je l’ai rappelé en introduction, vient du fait qu’il est incompatible avec le service Windows failover Clustering que vous allez trouver sur les machines Exchange 2010 qui supporteront les rôles de serveur de boîtes aux lettres. Par conséquent, si vous vous engagez sur la mise en place deux machines en haute disponibilité abritant les rôles Hub, Cas et Mailbox, vous ne pourrez pas utiliser la couche WNLB.
Le quatrième problème que vous risquez de rencontrer en mode unicast, est ce que l’on appelle le Port Flooding. C’est d’ailleurs pour cette raison que le WNLB est souvent installé en mode Multicast (Voir sur le site Technet de Microsoft). Pour plus d’informations sur le protocole NLB merci de vous rapporter à l’article Technet suivant.
Ensuite, viennent quelques petits inconvénients d’administration.
- Le premier inconvénient vient du fait que si vous ajoutez un membre du cluster ou si vous en supprimez un, alors les clients Exchange vont devoir se reconnecter.
- Le second tient à la limitation de 8 Nœuds au sein d’un même cluster.
Viennent ensuite les véritables solutions (voir l’article WordPress) que sont les solutions de répartition de charge matériel qui vont réellement prendre en charge les problématiques de persistance de sessions, de panne de services en testant véritablement la présence du service concerné.
La figure 1 montre un exemple de ce qu’est capable de faire un répartiteur de charge : Tester la réponse d’une page OWA et de s’y connecter si besoin est.
Nous reviendrons bien évidement à l’offre matérielle actuellement disponible à ce jour en fin d’article. Intéressons maintenant aux principes de répartition de charge dans ce cas précis.
Téléchargez cette ressource
Guide de Cyber-résilience pour Microsoft 365
La violation de votre tenant M365 va au-delà d’un simple incident de cybersécurité. Elle peut entraîner une interruption opérationnelle généralisée, des perturbations commerciales et une exposition de vos données sensibles. Découvrez les méthodes et technologies pour évaluer, comparer et renforcer votre posture de sécurité Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Full Cloud : une transformation numérique inévitable pour les entreprises ?
- Pilotage de la DSI : lucidité, exigences et engagement
- Les entreprises n’ont plus le luxe d’expérimenter l’IA
- Le changement, moteur d’engagement au travail
Articles les + lus
Alliée ou menace ? Comment l’IA redessine le paysage cyber
CES 2026 : l’IA physique et la robotique redéfinissent le futur
Les 3 prédictions 2026 pour Java
Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
Face à l’urgence écologique, l’IT doit faire sa révolution
À la une de la chaîne Tech
- Alliée ou menace ? Comment l’IA redessine le paysage cyber
- CES 2026 : l’IA physique et la robotique redéfinissent le futur
- Les 3 prédictions 2026 pour Java
- Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
- Face à l’urgence écologique, l’IT doit faire sa révolution
