Exchange 2013/2016 Loadbalancing
Un changement dans l’architecture d’Exchange version 2016 a rendu plus probable l’intégration dans les réglages d’un équilibreur de charge (Loadbalancer). Pourquoi donc, quelles sont les options que vous avez et comment peuvent-elles être implémentées, Markus Hengstler le détaille dans cet article.
Un changement dans l’architecture d’Exchange dans la version 2016 a rendu l’intégration d’un équilibreur de charge bien plus probable dans l’environnement. Pourquoi est-ce ainsi ; quelles sont les options que vous avez et comment peuvent-elles être mises en œuvre ? Elles sont décrites dans le contenu de cet article. J’utilise un équilibreur de charge virtuelle de l’entreprise Kemp Technologies mais les concepts s’appliquent de façon générale aussi pour d’autres produits.
Pourquoi avons-nous besoin d’un équilibreur de charge ?
Si vous décidez d’installer plus d’un Exchange Server en vue d’accroître la disponibilité des données et des services de courriers électroniques, vous utiliserez en arrière-plan le « clustering » de Windows et la réplication des bases de données applicatives. De cette manière, vous ne couvrez pas la distribution de l’accès et la fiabilité de l’accès aux données simultanément. Dans Exchange 2010 et 2013, il était encore possible d’installer séparément le rôle de « Client-Access-Server» qui garantit l’accès ainsi que la fonction d’équilibrage de la charge réseau de Windows (WNLB). L’équipe Microsoft Exchange a cependant toujours recommandé l’utilisation d’un équilibreur de charge matériel parce que WNLB, dans de nombreux domaines, ne suffisait pas aux exigences, par exemple, lors des Healthchecks ou d’options d’affinité.
La plupart des produits offrent en plus de l’équilibrage de charge, des fonctions supplémentaires telles que l’authentification, le pare-feu d’application-Web ou de détection d’intrusion réseau.
Concepts importants relatifs à l’équilibrage de charge
À ce stade, je voudrais expliquer quelques termes qui jouent un rôle important dans l’équilibrage de charge :
Couche 4 / Couche 7
L’équilibreur de charge peut évaluer soit l’adresse IP et le port TCP/UDP (niveau 4) ou également avoir une vue dans la couche application des paquets réseaux (couche 7). Dans le cas de HTTPS un certificat doit être installé de telle sorte que le trafic puisse être déchiffré.
Affinité/Persistance
Pour certaines demandes, il est important que l’utilisateur soit toujours dirigé vers le même serveur d’arrière-plan à savoir celui qui dispose des informations de la session existante. Les critères qui peuvent être utilisés pour réaliser cela incluent l’adresse IP du client, les cookies établis par le serveur Web ou l’équilibreur de charge ou ID de la session SSL.
Transparence
L’équilibreur de charge peut soit seulement envoyer le paquet réseau au serveur cible (transparence) ou remplacer l’adresse source de ce paquet avec sa propre adresse (Network Address Translation, NAT). NAT doit souvent être utilisé lors de l’équilibrage de charge lorsque le serveur Exchange et l’équilibreur de charge se trouvent dans le même sous-réseau, sinon les paquets réponse seraient envoyés directement au client et ne passeraient pas par l’équilibreur de charge. Cela peut conduire à des problèmes.
Scheduling
La méthode de distribution : cela peut par exemple être « Round Robin » répartition uniforme, « Weighted » pondéré (dans un certain rapport) ou « Least Connection » (le moins de connexions, du point de vue de l’équilibreur de la charge).
Content Rules
L’équilibreur de charge peut évaluer l’URL demandé du trafic HTTP et HTTPS et appliquer des règles de distribution différentes pour les demandes. Il peut, par exemple, distinguer une demande de connexion client Outlook https://mail.contoso.com/mapi ou navigateur Web https://mail.contoso.com/owa.
Healthcheck
L’équilibreur de charge est en mesure de surveiller les serveurs « backend » et ne plus en tenir compte en cas d’erreur. Cela peut être un simple ‘ping’ vers le serveur, l’ouverture d’une connexion TCP ou une requête à un site particulier. Exchange fournit pour chaque protocole, en dépendance avec l’auto surveillance interne, un point de test. Pour OWA cela ressemble par exemple à ceci : https://mail.contoso.com/owa/healthcheck.htm
Cours : Loadbalancing d’Exchange ServerPour plus d’informations sur l’équilibrage de charge d’Exchange 2013 et 2016, vous pouvez suivre l’un des cours suivants :
Autres informations sur Microsoft Exchange Server |
Plusieurs solutions :
Ci-dessous, je vous présente les trois variantes de Microsoft prises en charge pour l’équilibrage de charge. En général, il convient de noter que tous les serveurs Exchange utilisent le même certificat pour les services frontaux. Sinon, l’utilisateur doit être ré authentifié à nouveau lors du changement du backend.
Variante 1: Loadbalancing de couche 4
Depuis Exchange 2013 aucun protocole ne nécessite plus d’affinité. Par conséquent, il est possible d’envoyer le trafic vers n’importe lequel des services d’accès client. Celui-ci passe ensuite la connexion au serveur où se trouve la base de données active avec la boîte aux lettres de l’utilisateur. La solution présente un inconvénient majeur car il ne peut être défini qu’un service « Healthcheck ». Si un service cesse de fonctionner et qu’il ne s’agit pas de celui qui est surveillé, l’équilibreur de charge continuera de l’utiliser au lieu de l’évincer. A l’inverse, l’échec du service surveillé mènera à l’éviction de l’ensemble du serveur.
Voici l’exemple de configuration:
Dans la capture d’écran, il est visible que la couche 7 est utilisée et ceci est une particularité du Kemp Loadbalancer, seuls les services de L7 peuvent être configurés de manière non-transparente. Puisque le trafic n’est pas analysé (l’accélération SSL n’est pas enclenchée), seuls l’IP et le port sont utilisés pour la distribution.
La persistance est « None » donc aucune affinité pour un serveur « backend » particulier et la distribution s’oriente vers le serveur avec le plus petit nombre de connexions (least connections). Il est important lors d’un ajout d’un nouveau serveur dans le groupe d’équilibrage de charge. Notamment après un redémarrage de lui laisser assez de temps pour revenir à un niveau similaire à celui des serveurs existants. Sinon, il serait obligé au vu du nombre de connexions (0) de traiter toutes les nouvelles connexions. La capture d’écran ci-dessous montre l’option appropriée « Least Connection Slow Start » :
Si le produit d’équilibrage de charge ne fournit pas une telle option, la recommandation « Round Robin » est recommandée à la place de « Least Connection ».
La dernière illustration montre la configuration du serveur « backend » et le « Healthcheck ». Ici seulement une vérification du port TCP 443 est actif. Au lieu de cela, l’un des répertoires virtuels idéalement celui contenant les clients les plus importants ou les plus nombreux pourrait être surveillé.
Variante 2: Loadbalancing de couche 4 avec plusieurs espaces de noms
Pour réaliser des « Healthchecks » plus granulaires, on peut également travailler avec plusieurs espaces de noms à la place de la couche 7 et des règles contenues. Cela ressemble à ceci: 
Chaque protocole est configuré en tant qu’un service virtuel distinct. Une entrée dans le DNS doit être créée pour chacun des services virtuels distincts avec son propre nom et doivent tous être présents dans le certificat des serveurs Exchange. Un certificat Wildcard peut être pratique dans ce cas.
Bien entendu, les noms doivent être également ajustés dans la configuration Exchange. A titre d’exemple, OWA et ECP:
Voici encore les paramètres des services virtuels en utilisant l’exemple d’OWA:
Les options par défaut sont les mêmes que dans la variante précédente, donc transparence désactivée, persistance sur « None » et méthode de planification sur « Least Connection ».
Variante 3: Loadbalancing de couche 7 avec des règles de contenu
Bien que cette variante exige une mise en place un peu plus complexe, la granularité de la sécurité en cas de panne et de la simplicité à l’égard de l’espace de noms et des certificats en font la solution recommandée par Microsoft.
Un service virtuel (VS) est mis en place et à la place de serveurs « backend », des Sub-VS seront créés. Ils auront leurs propres paramètres et « Healthchecks ». Là encore, l’exemple OWA:
Cela exige que le certificat utilisé par le serveur Exchange soit importé et l’accélération SSL activée:
Enfin, l’ensemble des règles doivent être établies permettant la répartition du trafic qui sera basé sur les URL dans les requêtes, sur les Sub-VS :
Voici un exemple OWA:
L’important est l’option « Ignore Case » et bien entendu la chaîne de recherche.
Dans le Sub-VS, cette règle sera référencée dans les propriétés avancées:
Conclusion
L’équilibrage de charge est un élément important de presque tous les environnements Exchange. Avec un peu de connaissances de configuration et de conception, ce n’est pas particulièrement difficile mais quelques points importants doivent être compris et pris en compte.