Répartir la charge et optimiser Exchange server 2010

Contrairement au client Lync 2010 qui intègre des fonctions de DNS NLB (ne pas confondre avec le WNLB Windows ou DNS Round Robin), le client Outlook ne connaît qu’un seul point de connexion, soit le serveur Exchange, soit le Cas Array. Dans le cadre de plusieurs serveurs d’accès client (Cas) il faudra répartir la charge.

DNS Round Robin (RRDNS)

La solution première que l’on peut mettre en place est la solution DNS round Robin qui, à un nom FQDN, fait correspondre plusieurs adresses IP. Par défaut et pour rappel, les DNS Microsoft sont configurés par défaut pour prendre en charge ce mode de fonctionnement.

Le problème majeur de cette solution est que le serveur DNS ne sait pas si le serveur CAS en question est toujours actif.  Si le serveur CAS en question n’est pas en fonction, alors la connexion n’aboutira pas.  Pour l’avoir déjà vécu dans des environnements de production, le symptôme classique pour les utilisateurs OWA par exemple est une connexion aléatoire aux services Web. D’autre part, le service DNS ne possédant pas de mécanisme d’alerte, aucun warning ne sera remonté vers les administrateurs.

Le second problème du DNS round Robin est le fait que le client va garder en cache les informations renvoyées par le service DNS. Par conséquent si vous décidez de changer la configuration des enregistrements des serveurs CAS, alors cette mise à jour ne sera pas immédiatement prise en compte par ces mêmes clients.

Le troisième problème que vous allez rencontrer est une répartition de charge très aléatoire voir inégale car le service de distribution de charge DNS  ne contrôle en aucun cas la charge serveur.

Enfin, et pour en finir avec le service DNS Round Robin, vous ne serez pas capable de maintenir une persistance de sessions. La persistance de sessions nécessaire au bon fonctionnement de certains services consiste, une fois qu’un client est connecté sur un serveur CAS, d’acheminer ses requêtes toujours vers le même serveur.

Le tableau suivant précise dans quels cas la persistance de session est nécessaire. Voir tableau 1.

Si vous ne respectez pas la persistance de session, l’utilisateur (selon le mode d’accès) risque d’être « prompté » régulièrement pour s’authentifier.

Dans le cas des accès Active Sync, la persistance de sessions est recommandée même si elle n’est pas obligatoire. Dans le cas où celle-ci n’est pas présente, certaines latences côté client peuvent être constatées.

D’autre part dans des environnements très chargés en accès Active Sync, il semblerait que l’impact de charge sur les serveurs d’accès client ne soit pas négligeable.

WINDOWS Network LOAD BALANCING (WNLB)

La seconde solution pour améliorer les performances d'exchange server 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 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é, soit de la redondance, 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. Pour plus d’informations sur le protocole NLB merci de vous rapporter à l’article Technet suivant : http://technet.microsoft.com/en-us/library/bb742455.aspx

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 article http://unifiedit.wordpress.com/2010/08/18/exchange-2010-plaidoyer-pour-les-repartiteurs-de-charges-materiels/) 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é.

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.