Exchange 2016 : HA avec VIP du DAG

Introduction

Nous allons voir aujourd’hui comment assurer une haute disponibilité du CAS (Front-End) Exchange 2016 par le biais de la VIP du DAG.

J’ai trouvé cette solution en parcourant les forums Microsoft, toutefois elle est généralement déconseillée par les Experts, et ne constitue donc pas une best practice.

Dans un précédent post nous avons décrit la mise en place d’un DAG au sein d’une infrastructure Exchange 2016.

Lors de sa création, nous avions le choix ou non de créer une IP Virtuelle (Virtual IP ou encore « VIP ») pour notre DAG.

Cette VIP englobe les membres du cluster DAG (autrement dit ici; nos 2 serveurs Exchange), et pointe constamment vers le serveur actif (celui qui a le lead) ! On peut donc l’utiliser afin d’être sûr de joindre un serveur Exchange fonctionnel.

Dans l’exemple qui va suivre, je vais faire pointer les requêtes externes vers mon firewall (pfSense) puis ensuite faire du port forwarding pour diriger les requêtes vers la VIP de mon DAG. J’utilise en effet une configuration de NAT spécifique sur mon pfSense afin que mes VMs Exchange sortent avec l’IP du firewall et disposent d’Internet.

Voici un petit schéma pour comprendre le fonctionnement :

J’évoluerai avec l’environnement qui suit :

Serveur IP LAN IP WAN
pfSense-01 10.32.71.254 51.254.24.220
EXC-01 10.32.64.120
EXC-02 10.32.64.130
VIP DAG 10.32.64.140
PC-01 10.32.64.2

Ce qui me plait également avec cette solution est que la configuration est minime et très aisée 🙂


Configuration

DNS

Pour l’interne, sur votre DNS (serveur AD ici) :

Ajoutez un enregistrement A avec la VIP de votre DAG aux zones webmail et autodiscover :

Pour le webmail :

Pour autodiscover :

Pour l’externe, côté fournisseur :

Si vous suivez le même fonctionnement que moi, ajoutez une entrée A qui pointe vers votre firewall :

Attendez ensuite quelques instants, et assurez-vous que les zones soient à jour.

Sur une machine du domaine :

Sur une machine externe au réseau :


Firewall

Sur votre firewall, vous devez ensuite simplement faire des règles de Port Forwarding.

Si vous utilisez pfSense comme moi :

  • Firewall > NAT
  • Onglet « Port Forward » > Cliquer sur « Add »
  • Puis faites des règles pour rediriger les ports utilisés par Exchange vers la VIP du DAG

Dans mon exemple, voici ce que ça donne :

Tout étant opérationnel, on peut effectuer la phase de test concernant la haute disponibilité de nos Exchange 2016.


Test de haute disponibilité

Pour mon test je vais utiliser Outlook sur une machine Windows connectée au domaine.

Je lance la première fois mon Outlook, et je vois déjà que l’autodiscover est fonctionnel puisque mon compte est automatiquement paramétré :

Si je consulte la fenêtre « État de la connexion », je peux voir que tout est OK :

Si j’effectue ensuite le test de configuration automatique de la messagerie, aucune anomalie non plus :

Comme avec le DNS RR, je vérifie maintenant à quelle IP s’est connectée Outlook :

Je peux voir qu’Outlook s’est bien connecté à la VIP de mon DAG (10.32.64.140).

Pour déterminer à quelle serveur exactement mon client est connecté (10.32.64.2), j’utilise simplement netstat sur mes serveurs EXC :

Je peux donc voir que mon client est connecté à EXC-01. Et en toute logique, je n’ai pas de retour sur EXC-02.

On aurait pu savoir sans cette étape que EXC-01 était utilisé, puisque comme je vous l’ai expliqué, la VIP du DAG pointe vers le serveur qui a le lead dans le cluster ! Mais ça ne coute rien de vérifier.


Je vais donc pouvoir couper EXC-01 pour voir ce qui se passe avec Outlook.

Mais avant tout, je vais lancer des watch sur EXC-02, afin de voir les flux en temps réel :

  • Savoir quand EXC-01 devient DOWN
  • Savoir quand le client initie sa connexion à EXC-02

Je commence donc par ouvrir 2 fenêtres PowerShell sur EXC-02.

La commande « watch » n’existant pas sous PowerShell, je vous propose d’avoir l’équivalent en entrant les commandes ci-dessous :

Première fenêtre PowerShell :

Deuxième fenêtre PowerShell :

Tant que le ping vers EXC-01 (10.32.64.120) sera effectif, la console renvoie True, sinon False.

Ce qui donne ceci :

On procède maintenant à la coupure de EXC-01 :

Mon premier watch m’indique que le ping est perdu à 15h42 et 19 secondes :

Si je jette un oeil au deuxième watch, je peux voir que le client a établi une connexion au serveur 27 secondes plus tard :

Du côté d’Outlook, je ne constate aucune erreur. Et l’état de la connexion me le confirme :

Et dans le même temps, même si j’accède à l’OWA depuis l’extérieur, je ne suis pas impacté :

À simple titre informatif, si vous souhaitez redonner le lead à un serveur (EXC-01 par exemple), vous pouvez le faire grâce aux commandes Get-ClusterGroup et Move-ClusterGroup.

De cette manière, la VIP du DAG pointera de nouveau vers EXC-01, qui sera alors devenu le nouveau serveur hôte du cluster.

La démonstration prend fin ici 🙂

Nous avons vu à travers cet article une autre façon d’assurer une haute disponibilité pour la partie FRONT-END d’une infrastructure Exchange 2016.

Cette solution est selon moi la plus avantageuse si l’on a des moyens restreints ! 😉

Vous aimerez aussi...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.