> Mobilité > Les solutions de répartition de charge pour Exchange 2010

Les solutions de répartition de charge pour Exchange 2010

Mobilité - Par Laurent Teruin - Publié le 17 février 2012
email

La répartition de charge en environnement Exchange 2010 est une problématique systématique dès lors que l’on envisage la mise en place des fonctionnalités de haute disponibilité. Dans l’univers Microsoft plusieurs solutions sont possibles. Selon le nombre de boîtes aux lettres, la configuration du réseau de l’entreprise mais également le budget associé, celles-ci seront plus ou moins élaborées voir compliquées. Nous allons donc passer en revue les différentes techniques et problématiques de répartition de charge que vous devrez « affronter » dans le cas où vous envisagez de déployer une solution Exchange en environnement de haute disponibilité.

Ce dossier est issu de notre publication Exchange Magazine (05/11). Pour consulter les schémas et illustrations associés, rendez-vous dans le club abonnés.

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.
 

Persistance de sessions requise Persistance de session recommandée Persistance de sessions non requise
Exchange Control Panel ActiveSync Autodécouverte / AutoDiscover
OWA Outlook Anywhere (Rpc Over Https) Carnet d’adresses en mode hors connextion / Offline Address Book
Service RPC d’accès client
RPC Client Access Service
Remote PowerShell IMAP4
Service Web d’Exchange
Exchange Web Services
Service de carnet d’adresses
Address Book Service
POP 3


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.
 

Téléchargez gratuitement cette ressource

Aborder la Blockchain, comprendre et démarrer

Aborder la Blockchain, comprendre et démarrer

Une véritable révolution se prépare progressivement... les entreprises doivent veiller à ne pas rester à l’écart et se faire prendre de vitesse. Tout comme la mobilité ou encore le cloud, la blockchain est une composante essentielle de la transformation numérique. Découvrez, dans ce dossier, comment aborder, comprendre et démarrer la Blockchain

Mobilité - Par Laurent Teruin - Publié le 17 février 2012