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
Percer le brouillard des rançongiciels
Explorez les méandres d’une investigation de ransomware, avec les experts de Palo Alto Networks et Unit 42 pour faire la lumière dans la nébuleuse des rançongiciels. Plongez au cœur de l’enquête pour comprendre les méthodes, les outils et les tactiques utilisés par les acteurs de la menace. Découvrez comment prévenir les attaques, les contrer et minimiser leur impact. Des enseignements indispensables aux équipes cyber.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
