Office Servers and Services

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Exchange 2010 SP1 : Répartition de charge 1/2

Posted by Teruin laurent sur octobre 30, 2011


Introduction

La venue de Microsoft Exchange 2010 a fortement nécessité l’acquisition ainsi que la mise en place de répartiteur de charge matériel. Bien sûr me direz-vous, la répartition Windows est toujours là, mais est-ce vraiment jouable ? Comment répartir correctement la charge réseau dans un environnement exchange 2010 avec ce type de procédé. C’est ce que je vous propose de regarder.

En premier lieu, et par déontologie, je vous propose un petit retour sur les solutions possibles que vous pourriez mettre en place. A ce jour 3 choix sont envisageables.

  • Répartition de charge NLB
  • Répartition de charge Round Robin
  • Répartition de charge matérielle
  1. Répartition de charge Windows NLB ou WNLB.

Cette répartition de charge est présente dans n’importe quels serveurs Windows, qu’il soit en version standard ou en version Entreprise. Comme dans quasi-totalité des cas, vos serveurs de transport HUB ou vos serveurs d’accès clients s’exécutent sur des serveurs possédant la licence Standard, Cette solution est activable nativement.

Seulement, si elle fait partie de la licence serveur, la couche NLB n’as pas grand rapport avec l’environnement Exchange. Cette couche logicielle ne va pas par exemple, vérifier si les services publiés derrière l’adresse IP NLB sont en ordre de marche. Ainsi, si pour une raison quelconque un serveur IIS s’arrête, le NLB continuera à distribuer ce serveur comme destination aux clients de messagerie. En fait, tant que votre serveur répond via TCPIP alors le service NLB considère qu’il est valide, et ce même si tous les services Exchange sont arrêtés. D’autre part la mise en place de l’environnement NLB s’avère également complexe dans des environnements géographiquement étendus comme le sont de plus en plus les environnements Exchange.

La couche WNLB est également limitée par plusieurs facteurs comme le nombre de nœud quelle peut supporter, 8 au maximum. De plus, elle est incompatible avec des serveurs Exchange qui exécutent la couche Windows Failover clustering. Dans les environnements possédant un nombre de boites aux lettres important, elle va poser problème en raison du nombre de port limité à 65 000 depuis une seule et unique adresse IP. Mais nous allons expliciter cela. Pour finir, l’ajout ou la suppression d’un nœud au sein d’un cluster IP va provoquer la déconnexion des utilisateurs. Ce qui va de facto limiter son usage dans le cas des opérations de maintenance. Voici donc résumé les limitations de cette répartition de charge, qui vous l’aurez compris ne retient que peu mon attention dans la construction d’architecture Exchange redondantes. Son principal avantage ?… il est d’être gratuit.

  1. Répartition de charge Round Robin.

La répartition de charge Round Robin distribue le flux grâce aux fonctionnements DNS. Le principe est simple. Créez deux enregistrements DNS portant le même nom de domaine (nom de votre Client Access Array) et attribuez-lui deux adresses IP différentes. Activez le mode RoundRobin dans le server DNS (Par défaut dans Windows Server) et le tour est joué. Un coup sur deux, le DNS va renvoyer l’adresse 1 ou l’adresse 2. Enfantin, pas cher, simple, sauf que … c’est nettement insuffisant pour l’environnement Exchange 2010.

Comme WNLB, le round Robin n’a aucune idée de l’état des services Windows et même si le serveur est arrêté, il continuera à renvoyer au client l’adresse IP en question. Quant aux chances de connexion du client, sur un serveur hors service…… elles seront faibles.

En réalité ces deux modes de répartition de charge, sont relativement obsolètes et non pas évolués au fur et à mesure de l’évolution de l’environnement Windows. Conçus pour de la répartition de charge TSE ou de simple connexion IP, ils s’avèrent totalement dépassés dans l’environnement Exchange.

Mais est-ce vraiment si compliqué que cela de faire de la répartition de charge Exchange correctement. ? Et bien … cela dépend ! Comme un jour m’a dit un jour une personne de Microsoft, Exchange 2007 vous a fait découvrir les coulisses des certificats, Exchange 2010 vous fera découvrir les sous-sols de la répartition de charge matérielle. Alors c’est parti !

  1. Répartiteur de charge matériel (HLB ou ADC).

En opposition avec les deux protocoles que je vous ai présenté, les répartiteurs de charges matériels offrent beaucoup plus de possibilité et notamment la répartition de charge selon plusieurs critères. Car une des questions à se poser c’est sur quels critères votre répartiteur de charge va se baser pour répartir le flux clients vers les serveurs Exchange

La première possibilité est l’adresse IP du client. Lorsque le répartiteur de charge matériel identifie un client avec son adresse Ip (ex : 192.168.1.1) , il le connecte sur le serveur Exchange Numéro 1. Pour une autre adresse IP (ex : 192.168.1.2) , il le positionnera sur le numéro 2 , etc etc . L’avantage de cette répartition est de garantir que pour une session IP, le client à l’adresse 192.168.1.1, sera toujours affecté au serveur Exchange 1.

Pour quelle raison ? Pour tout simplement garantir par exemple dans OWA que l’utilisateur n’ait pas à se reconnecter lorsqu’il demande à voir le message suivant. C’est effectivement ce qui se passerait si pour une même session IP Owa, le répartiteur de charge acheminait le client vers un autre serveur d’accès client. Tout cela pour maintenir la persistance de session. Deux termes qu’il nous faut définir.

  1. Session et persistance

Les problèmes de persistance de sessions viennent entre du fait que par nature, le protocole HTTP n’a pas été conçu pour à l’origine pour être de type applicatif mais plutôt orienté lecture et récupération de document. De ce fait, le protocole HTTP ne maintient pas de connexion (Stateless) en permanence avec les serveurs Web qu’il consulte. Parallèlement, l’usage de ce protocole à évolué, et il est utilisé aujourd’hui pour comme un frontal applicatif (Exchange OWA par exemple, Site d’achat en ligne etc..) usage qui demande nécessairement la persistance de session (Statefull).

Une des solutions et qui fonctionne correctement pour mettre en place une notion de session entre le client et le serveur est l’usage de Cookie qui, stocké sur le poste client permet à l’applicatif de retrouver les éléments des sessions (SessionID). C’est par ailleurs grâce à ce mécanisme que nous arrivons à maintenir les sessions Outlook Web Access.

L’exemple ci-dessous donne une idée de ce que l’on peut trouver dans un Coolie de session et notamment la notion d’Id de session.

Cookie: JSESSIONID=9879876473431
Cache-Control: no-cache
Host: 127.0.0.1:8080
Connection: Keep-Alive

 Une fois la session créée par le biais de Session ID et de cookie, les répartiteurs de charges ou plutôt les ADC (Application Delivery Controller) vont se charger de récupérer cette session ID de chaque client de façon à orienter les requêtes d’un client toujours sur le même serveur. On parle alors de persistance. Plusieurs solutions sont possibles. La première est de se baser sur L’ID SSL d’une session HTTPS (généré par le serveur dans la phase de négociation) par exemple. La seconde est simplement d’utiliser un cookie de session transféré dans l’entête HTTP et généré par le serveur Web.

Autre solution alternative consiste pour garantir la notion de session, à ce baser sur l’adresse IP du client. Ce baser sur l’adresse IP c’est bien, mais à condition que vos clients en possèdent une toutes différentes ! Je m’explique. Si vos clients viennent d’un sous réseau naté de votre entreprise ou si ils utilisent un serveur proxy d’agence, ils posséderont virtuellement la même adresse IP et votre répartiteur de charge sera bien incapable de répartir la charge. Résultat vous vous retrouverez, avec tous les clients connectés sur le même serveur Exchange.

En réalité tout dépend de la façon dont vous allez implémenter votre répartiteur de charge matériel et comment se dernier agira sur les flux clients vis-à-vis de votre infrastructure Exchange d’accès client.

Snat / Dnat

La mise en place d’un répartiteur de charge ou ADC va en partie conditionner la façon dont ce dernier doit agir avec vos serveurs Exchange. La première possibilité est de placer votre Répartiteur de charge en coupure de vos infrastructures Parefeux


 

La seconde est de le placer sur le réseau de l’entreprise.


Dans le cas où le répartiteur de charge est en coupure, il est évident que le flux entrant et sortant (réponse des serveurs d’accès client) passera par le répartiteur de charge. Dans Le cas contraire, ou le répartiteur de charge est sur le réseau local, il est possible que le flux entrant passe alors par le répartiteur de charge mais que le serveur réponde directement aux clients.

En fait tout dépend d dont la translation d’adresse est faite et dont le réseau est organisé. Un petit tour vers les notions de Snat et Dnat s’impose donc.

  1. SNAT ou Source NAT

Le Source NAT (translation d’adresse source) correspond à la modification de l’adresse source dans un paquet translaté. Dans ce cas, votre répartiteur de charge va changer l’adresse source du paquet client par une adresse IP positionnée sur votre répartiteur que vous aurez désignée. Le but de cette opération est par conséquent de s’assurer que votre serveur CAS, renvoi la réponse de facto à votre répartiteur de charge au lieu de le renvoyer directement au client originel. Vous noterez que dans ce cas précis, le répartiteur de charge n’a même pas besoin d’être en coupure physique. Pour effectuer cette opération vous aurez plusieurs choix et notamment le choix de faire une simple translation d’adresse vers un adresse ip unique ou alors, vers un pool d’adresse IP positionné sur votre répartiteur. Dans le premier cas on parlera de SNAT Standard dans le second de SNAT pool.

 


Ce mode de translation peut être utile car d’un point de vue firewall seul le Répartiteur de charge est concerné. Par contre dans Exchange les choses se compliquent un peu.

 

Explication : Dans le cas du SNAT, et vous l’aurez compris, vous perdez (coté Exchange) la notion d’adresse client, puisque toutes les adresses IP du client sont modifiées par l’adresse ou les adresses sélectionnées (Snat Pool) dans votre répartiteur de charge. De ce fait, et si vous faites cela pour l’environnement SMTP interne par exemple, vous perdez notamment la possibilité dans les connecteurs de réception de limiter le relai par adresses IP.
Pour rappel, voir set-receiveconnector et le paramètre RemoteIprange des connecteurs de réception. (http://technet.microsoft.com/fr-fr/library/bb125140.aspx)

Limitation du SNAT

.

Les fonctionnalités de SNAT sont intéressantes mais limitées, car le nombre de port ouverts maximum pour une seule adresse Ip est de 65,535 par destination. Ce qui peut être très vite atteint (environ 6000 utilisateurs). Dans ce cas il faudra privilégier l’utilisation des fonctions de SNAT pool pour dépasser cette limite.
Par contre, si vous projetez d’utiliser les fonctions de SNAT Pool et que vos serveurs d’accès client doivent recevoir des flux Mapi RPC (Je ne parle pas de Outlook anywhere ici mais de connexion MAPI Outlook) alors, il faudra que le répartiteur de charge adresse vers le serveur CAS toujours la même adresse source par connexion RPC. En gros si un client Mapi se connecte sur un HLB effectuant du SNAT pool, il faut que cette connexion garde toujours la même adresse IP de sortie vers le serveur Cas.

DNAT ou Destination NAT
Le Destination NAT correspond à la modification de l’adresse destination dans un paquet translaté. Il est utilisé pour la NAT statique, lorsqu’on veut accéder à un serveur sur un réseau local. Cette solution consiste à garder l’adresse IP du client mais cacher les adresses IP local du serveur d’accès client Exchange.

Bon vous voilà paré pour la seconde partie plus axée sur l’environnement Exchange 2010

Cordialement
Laurent Teruin

3 Réponses to “Exchange 2010 SP1 : Répartition de charge 1/2”

  1. Merci Laurent pour ce post, j’attend la suite🙂

    Tu n’en as pas parlé mais que penses tu de la solution de répartition de charge via TMG en mode OA (interne et externe) ? La solution est elle viable pour les petits environnements ?

    @+

    • La solution TMG reste une excellente solution pour la publication des services Exchange 2010. Maintenant tout le monde ne posséde pas cette solution et bien souvent elle n’est utilisée que pour l’extérieur. Beaucoup de société n’ont pas intégrer leurs solutions Exchange dans un environnement d’hébergement et utilise encore mapi comme protocole par défaut. TMG est et demeure pour l’instant une solution de publication pour les accés Externes dans la plupart de société. le positionner en Interne offre bien évidement des avantages comme notamment le renforcement de la sécurité d’accès à la plateforme Exchange cependant je ne pense pas que l’on puisse se passer reellement de répartiteur de charge matériel .

      Cordialement
      Laurent teruin

  2. […] Vous trouverez un article intéressant à cette adresse. […]

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

 
%d blogueurs aiment cette page :