Les solutions de répartition de charge pour Exchange 2010

Deux ou trois choses à savoir.

La première chose que vous devez prendre en compte est le fait que si tous vos services Exchange principaux, (j’entends par là les services Hub, Cas et Mailbox) sont concentrés sur une seule machine, vous devrez utiliser obligatoirement un répartiteur de charge matériel. Dans le cas contraire l’utilisation éventuelle et sous certaines conditions de services comme la répartition de charge Windows (WNLB) est possible.

La seconde chose que vous devrez prendre en compte est que si vous envisagez de déployer un environnement WNLB il faudra que les deux nœuds soient dans le même réseau IP.

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.