Friday, March 31, 2017

Exchange 2016 (16) : répartition de charge - Outlook MAPI/HTTP - avec Citrix Netscaler

English summary: with high availability as our objective, we configure a load balancer for client access via MAPI/HTTP to Exchange 2016 mailboxes. In this first section, I concentrate on the creation and configuration of entries for servers, services and virtual servers. There is a problem. We suspect that, like OWA, Outlook MAPI/HTTP requires the importation of an SSL certificate on the load balancer. That will be the subject of the following blog post. Note : we use a Citrix NetScaler VPX for the load balancer.

***

A la fin de mon billet précédent, je me suis donné pour objectif de rendre l'accès client aux boîtes aux lettres le plus fiable possible. Je pourrais me contenter de la méthode "Round Robin" et j'en serais même obligé si je ne disposais pas d'un répartiteur de charge. Mais mon réseau d'essai en compte bien un, et plus précisément un Citrix Netscaler VPX (une version virtuelle du répartiteur). Je m'en suis déjà servi pour des expériences avec Exchange 2010 dans une série de billets de blogue ici (en anglais) :

NetScaler VPX - load balance Exchange - Part 1 (Installation and Configuration)

Dans ce cadre-là, il s'agissait de répartir les connexions RPC pour Outlook (MAPI/RPC). Maintenant que nous en sommes à Exchange 2016 (mais toujours à Outlook 2010 SP2), il s'agit de répartir des connexions HTTP (MAPI/HTTP). Il est vrai que j'ai déjà configuré HTTP à ce moment-là pour OWA et je suis curieux de savoir si je peux faire fonctionner Outlook sur ce modèle.

Quelques remarques...

Je vais m'y prendre en deux parties. Dans ce premier texte (ce que vous lisez en ce moment), je vais mettre en place les fondations pour la répartition du trafic Outlook (MAPI/HTTP). Cependant, à la différence du trafic RPC (et SMTP), le trafic requiert l'utilisation d'un certificat SSL. En effet, même si on écrit "HTTP" il s'agit en fait presque toujours de "HTTPS" (attention à la lettre "S" qui signifie "secure"). Nous verrons qu'à la fin de la configuration, nous aurons des "voyants" rouge dans notre interface, contrastant avec les voyants vert de la répartition SMTP (déjà mise en place).

Dans un texte à suivre (la seconde partie), je vais voir si le fait d'importer un certificat SSL et de l'associer au service HTTP (sur le Netscaler) résout le problème comme il l'a résolu pour OWA dans la série de billets de blogue pour laquelle j'ai mis un lien plus haut.

Je vais présenter les étapes à suivre avec moins de détails que pour Exchange 2010. Je vise avant tout à déterminer ce qu'il faut faire pour répartir le trafic Outlook (MAPI/HTTP). Je n'ai pas l'intention de refaire à l'identique (mais en français) la même présentation qu'en mars 2016. Si vous voulez une présentation plus générale ou plus complète de la répartition de charge (pour Exchange ou pas), je me permets de vous renvoyer à ma première série de textes ou de vous inviter à consulter la documentation disponible en ligne.


***


Je commence par saisir l'adresse IP de l'interface de gestion du NetScaler VPX et j'ouvre une session. Ensuite, je vais à la rubrique "Traffic Management | Load Balancing". Il s'agit de créer les composants suivants :
  • Deux "serveurs" qui représentent nos serveurs Exchange.
  • Un "service" HTTP(S) pour chacun de nos deux serveurs Exchange. Dans d'autres circonstances, nous pourrions en créer pour RPC, IMAP, POP, ou SMTP.
  • Un "serveur virtuel" qui présente le service au clients grâce à son adresse "VIP" (IP virtuelle) vers laquelle ceux-ci sont dirigés via DNS. Nous devons associer les deux services créés pour chacun des serveurs à ce serveur virtuel. Ainsi, tout est relié et fonctionne ensemble.

Dans ce cas, j'ai déjà créé les deux serveurs (il s'agit essentiellement de donner un nom à chaque objet qui les représente et d'en indiquer l'adresse IP qui convient). Voilà ce que cela donne : 



Quant aux services, j'en ai déjà créé pour SMTP (un pour chaque serveur). Faisons-en de même pour HTTP. Dans la section "Services", je clique sur le bouton "Add"... 





Et je configure un service HTTP pour chacun de nos deux serveurs. La forme du nom peut varier selon vos conventions de nommage et n'a pas besoin de ressembler exactement à ce que j'ai mis plus bas dans les captures d'écran. Je sélectionne un serveur existant pour chacun des services. Je choisis "SSL" (le nom choisi pour le service - au lieu de "HTTPS") et le port 443 :







Nous cliquons sur "OK" et nous voyons nos deux nouveaux services :




Ensuite, nous passons à la section "Virtual Servers" où nous en avons déjà un pour SMTP. Ajoutons-en un autre pour HTTP(S) :


(Oui, nous cliquons sur "Add". C'est pourquoi j'y ai mis le point rouge.)


Les paramètres de base sont d'une configuration facile. Je donne un nom au serveur virtuel, je choisis le protocole (SSL) et j'indique l'adresse IP (et port) par laquelle les clients passeront pour accéder au service :




Je clique sur OK et, sur la page suivante, je cherche la section "Services and Service Groups" parmi les propriétés de notre nouveau serveur virtuel, et enfin, j'ouvre la partie "No Load Balancing Virtual Server Binding" : 




Dans la fenêtre qui s'affiche, nous allons créer une association (ou un lien) entre le serveur virtuel et les deux services HTTPS (SSL) que nous avons créés plus tôt pour chacun de nos serveurs Exchange. Nous sélectionnons donc le service...




Ce qui nous amène à cette fenêtre où nous cochons les deux services HTTPS...



Et puis nous cliquons sur le bouton "Bind" :




Nous avons maintenant deux associations :



Mais cela ne semble pas suffire. L'état du virtuel serveur est "Down" (ce qu'on pourrait traduire par hors service) :



***

Changer de "Method" ou de "Persistence" ne change rien. Comme pour mes expériences avec Exchange 2010, je vais devoir essayer d'importer un certificat. Cela résoudra-t-il le problème ? Nous le verrons dans mon prochain billet de blogue. A suivre...

No comments:

Post a Comment