Monday, April 24, 2017

Exchange 2016 (18) : DAG - première partie

English summary: more recent versions of Exchange Database Availability Groups (DAG) have options that were not present with Exchange 2010 (the concept of an "IP-less DAG" for example). After briefly presenting some (but not all) of these options, I complete the pre-requisites of the configuration that I've selected and then proceed to create the DAG. All in all (and excluding pre-requisites), it is a three step process: create the Database Availability Group itself, add servers to the DAG, add mailbox databases to the DAG for replication.


***


L'acronyme "DAG" signifie "Database Availability Group" que je traduirais par "Groupe de base de données en haute disponibilité". Il s'agit des bases de données de boîtes aux lettres, une innovation en haute disponibilité qui existe depuis Exchange 2010. Je tiens à préciser que cette méthode de haute disponibilité concerne seulement le rôle des boîtes aux lettres (Mailbox Role). Il faut d'autres méthodes pour assurer la haute disponibilité du rôle Accès client et du rôle Transport. De plus, même si nous parlons plutôt des "services" Accès client et Transport pour Exchange 2016, le principe reste valable : le DAG est un concept relatif aux boîtes aux lettres.

Le DAG version Exchange 2016 comporte certaines améliorations par rapport à Exchange 2010 que je voudrais examiner. D'abord, nous n'avons plus besoin de mettre sur pied un réseau distinct pour l'accès client et la réplication entre membres du DAG. Déjà, avec Exchange 2010, c'était recommandé mais non pas absolument nécessaire. En outre, nous n'avons plus besoin d'assigner une addresse IP à notre DAG. Ce sont les "DAG sans IP" ou "IP-less DAGs). Cependant, nous avons encore l'option d'assigner une adresse IP si, par exemple, notre logiciel de sauvegarde n'est pas en mesure de fonctionner sans cela.

Ma présentation n'est pas exhaustive. Pour des informations plus complètes, je renvoie le lecteur aux articles suivants :

Groupe de disponibilité de base de données

Ou dans la version originale :


Dans mon cas, je vais choisir d'assigner une adresse IP à mon DAG mais me contenter d'un seul réseau pour tout le trafic, tant accès client que réplication.


***


La mise en oeuvre d'un DAG se décompose en trois étapes principales :
  1. Nous créons le DAG lui-même, soit un objet dans Active Directory, avec ou sans adresse IP.
  2. Nous ajoutons un minimum de 2 serveurs Exchange (avec le rôle "boîte aux lettres") au DAG créé à la première étape. Un DAG peut avoir un maximum de seize serveurs membres. 
  3. Nous ajoutons des bases de données (de boîtes aux lettres) au DAG. La réplication se fait au niveau de la base de données. Toutes les bases de données d'un serveur Exchange peuvent faire l'objet d'une réplication ou seulement une partie d'entre elles. 

Selon nos choix (multiples réseaux ou non, adresse IP ou non), il faut, en plus,  accomplir certaines tâches au préalable.

Etant donné mes choix de configuration, je dois préparer un serveur qui sera notre "File Share Witness" (FSW - ou Témoin de partage de fichiers en français) et créer un compte ordinateur dans Active Directory de façon manuelle.

Je vais donc désigner un serveur comme "FSW". Il s'agit d'un nœud qui joue le rôle d'arbitre dans un DAG avec un nombre pair de membres. Il n'aurait aucun rôle à jouer si le nombre de membres était impair.

Dans mon réseau d'essai, je n'ai que quatre hôtes  :
  • 1 contrôleur de domaine Windows 2008 R2
  • 2 serveurs Windows 2012 R2 (avec Exchange 2016 CU5)
  • 1 client Windows 7 SP1

Pour des raisons de sécurité, il est déconseillé d'utiliser un contrôleur de domaine  pour le FSW. Mais, faute d'autre choix, et s'agissant précisément d'un simple réseau d'essai, je vais donc utiliser mon contrôleur de domaine.

Si le serveur qui tient le FSW n'est pas un serveur Exchange, nous devons y ajouter le compte "Exchange Trusted Subsystem" au groupe "Administrateurs locaux" ou "Administrateurs" dans le cas d'un contrôleur de domaine. Le compte hérite ainsi des privilèges considérables, voire excessifs, ce qui explique qu'il est normalement déconseillé. Il s'agit d'ajouter le compte dans les propriétés du groupe (onglet "Membres") :




De plus, si nous utilisons Windows 2012 R2, et si nous tenons à avoir un "cluster administrative access point" (en substance, un DAG avec une adresse IP), nous devons créer un compte ordinateur pour notre DAG. Je vais essayer cette option en raison d'un logiciel de sauvegarde qui est peut-être incompatible avec un DAG sans (adresse) IP. Soulignons, cependant, que ce "point d'accès" (et son adresse IP) n'est plus obligatoire. Dans la plupart des cas, nous pourrions sans doute nous en passer.

Je crée un compte (ordinateur) pour notre DAG, je l'appelle "DAG1" et je le désactive aussitôt : 


Note : je crée le compte dans le conteneur qui abrite les comptes de nos deux serveurs Exchange mais cela n'est pas nécessaire.


Pour l'étape suivante, je m'assure que l'option "Fonctionnalités avancées" est cochée (sous l'onglet "Affichage" dans Utilisateurs et ordinateurs Active Directory) : 



Ensuite, dans les propriétés de l'objet "DAG1", et sous l'onglet "Sécurité", nous allons ajouter le compte "Exchange Trusted Subsystem" et lui accorder un contrôle total sur cet objet (voir les trois captures d'écran suivantes) :









Créer le DAG

Tout cela accompli, nous pouvons passer à la création du DAG lui-même. Celle-ci peut se faire dans l'interface graphique (EAC-CDE) ou à la ligne de commande (EMS ou "Exchange Mangement Shell"). Je vais employer cette dernière option.

Je saisis la commande suivante, tenant compte du système de fichiers du volume qui contient les bases de données (ReFS) :

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer DC4 -WitnessDirectory C:\FSW_DAG1 -DatabaseAvailabilityGroupIpAddresses 10.4.1.18 -FileSystem ReFS


Note : il suffit de cliquer sur l'image pour l'agrandir.


L'opération réussit sans le moindre accroc. Dans le cas contraire, nous aurions vu un message d'erreur en caractères rouges (ce qui n'est pas le cas).

On aurait pu croire que l'opération a échoué, du moins en partie, parce que le répertoire pour le FSW n'a pas été créé :



En fait, cela est normal. A cette étape, le DAG existe surtout en tant qu'objet en Active Directory. C'est seulement ensuite que les autres éléments vont se matérialiser.

Nous le voyons bien si nous exécutons la commande suivante :


Le DAG ne compte encore aucun serveur et les paramètres du FSW en sont de simples propriétés.



Ajouter des serveurs Exchange au DAG

La prochaine étape consiste à ajouter des serveurs au DAG. A mon premier essai, cette opération a échoué. Je vais montrer ce qui s'est passé et puis la solution au problème.

Nous ajoutons un serveur au DAG avec la commande suivante...

Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX16-3

Et nous devrions voir l'affichage des opérations en cours en haut de l'écran : 



Mais pour moi, l'opération ne s'est pas achevée comme il fallait :



Qu'est-ce qui ne va pas ?

Le fichier journal mentionné dans le message d'erreur fournit des indices.

Le DAG a bel et bien une adresse IP (10.4.1.18) mais la résolution du nom "DAG1" échoue parce que l'hôte est inconnu :



Je dois créer une entrée pour DAG1 dans la zone DNS qui convient :



Le problème a persisté lors d'une seconde tentative mais ne s'est plus manifesté après la mise hors tension de tout mon réseau d'essai et son redémarrage un jour plus tard. Je pose comme hypothèse qu'il fallait purger DNS côté client où le premier échec de résolution bloquait les résolutions suivantes. Il est plus que probable que cette commande aurait accompli la même chose :

ipconfig /flushdns


A ma troisième tentative d'ajouter un serveur, tout s'est donc bien passé. Il faut environ une minute pour que toutes les opérations finissent :



Et notre serveur EX16-3 fait désormais partie du DAG :




***

En principe, il suffirait de faire la même chose pour EX16-4 mais, là aussi, je me suis heurté à des obstacles. Comme pour le problème de résolution de noms, je tiens à présenter le problème et puis la solution. Ce sera le sujet de mon prochain billet de blogue où, en plus, nous ajouterons une base de données au DAG.

No comments:

Post a Comment