Thursday, April 27, 2017

Exchange 2016 (19) : DAG - seconde partie

English summary: after creating a Database Availability Group (DAG) and adding the first of two servers in the previous blog post, we attempt to add a second server and encounter some difficulties. We resolve the problem and then add a mailbox database to the DAG for replication.

***

Après avoir ajouté au DAG le premier de nos deux serveurs Exchange (EX16-3), je croyais qu'il serait aussi facile d'en ajouter le second (EX16-4). En fait, il semblait encore plus facile, trop facile.

Je saisis la commande suivante...

Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX16-4

En quelques secondes, je me retrouve à l'invite de la ligne de commande. Les opérations en cours ne se sont pas affichées en caractères jaunes sur fond turquoise comme pour le premier serveur :



Je remarque aussi que le DAG ne comprend aucun "Operational Server(s)". J'y réfléchis un instant et je me souviens qu'il faut ajouter le paramètre -status pour afficher certaines propriétés (c'est ainsi). Je saisis la commande suivante, ce qui fournit des détails plus amples :



Quelque chose cloche. Je n'ai qu'un seul serveur opérationnel : EX16-3. Cette commande le confirme avec plus de concision :



Je commence le processus de dépannage.

Dans l'Observateur d'événements, je découvre un avertissement concernant le "FailoverClustering-Manager". Il faut savoir que le DAG repose sur des éléments de Windows Clustering bien que nous ne gérions pas le DAG avec cet outil directement. A première vue, cet avertissement pourrait avoir un lien avec l'absence du serveur EX16-4 parmi les serveurs opérationnels. Mais à y regarder de plus près, l'avertissement semble se rapporter à Hyper-V :



Quoi qu'il en soit, l'avertissement m'amène à vérifier l'installation des rôles et des fonctionnalités qui pourraient être nécessaires au DAG. D'emblée, je constate un message qui fait état d'un redémarrage en attente :




C'est la fonctionnalité "Outils de clustering de basculement" (Failover clustering tools) qui nécessite un redémarrage :



En comparaison, ces outils sont installés sur EX16-3 :




Malheureusement, le redémarrage n'a pas résolu le problème. J'observe même, dans le Gestionnaire du cluster de basculement, qu'il n'y a... rien :




Je décide de retirer EX16-4 du DAG...



Et d'essayer de l'ajouter à nouveau. Cette fois-ci, cela réussit mieux. Au lieu de sembler terminer en quelques secondes, l'opération prend environ une minute et chaque étape de l'opération s'affiche en haut de l'écran, en caractères jaunes sur fond turquoise :



Qui plus est, les deux serveurs sont maintenant affichés comme opérationnels :



En outre, nous pouvons comparer cette vue du Gestionnaire de cluster de basculement avec la précédente (plus haut). Tout est en place, y compris le Témoin de partage de fichiers (FSW) :



Et comme on pouvait (logiquement) s'y attendre, le répertoire "FSW-DAG1" a été créé sur le serveur que nous avons désigné comme "Témoin de partage de fichiers" :



Il nous reste encore à ajouter une base de données (de boîte aux lettres) au DAG pour la réplication. Comparons l'avant et l'après. Nous allons utiliser la base de données MBXDB-01 qui réside seulement sur EX16-3 pour le moment :

Get-MailboxDatabaseCopyStatus



A l'inverse, EX16-4 abrite la base de données MBXDB-03 sur le volume E: et les fichiers de journaux de transaction (log files) sur le volume F:




Gardons à l'esprit que le chemin pour la base de données et les journaux de transaction doit être le même sur tous les serveurs qui tiennent une copie de la base de données.

Pour le moment, EX16-4 n'a donc que les répertoires associés à la base de données MBXDB-03. Quand nous ajouterons MBXDB-01 au DAG, celui-ci créera un exemplaire (ou "replica") de cette base de données sur EX16-4 (sur le volume E:) et copiera les fichiers des journaux de transaction vers un répertoire sur le volume F:. A mesure que l'opération de copie se fait, les transactions seront consignées à la base de données.

Nous ajoutons la copie de la base de données MBXDB-01 sur EX16-4 avec la commande suivante :

Add-MailboxDatabaseCopy MBXDB-01 -MailboxServer EX16-4

Deux avertissements s'affichent concernant les permissions sur les répertoires créés (de façon automatique) sur EX16-4 pour la base de données et les journaux de transaction. Il est recommandé de limiter l'accès au SYSTEM et aux administrateurs locaux. C'est une recommandation que je vais étudier mais sans m'y étendre ici. 



Le troisième avertissement nous demande de faire redémarrer le service "Microsoft Exchange Information Store", ce qui est assez facile à faire :




Et voici les changements que nous pouvons observer après la mise en place du DAG et surtout après avoir ajouté la base de données MBXDB-01. D'abord, le serveur EX16-4 (adresse IP 10.4.1.17) a désormais une copie de la base de données MBXDB-01 à côté de la base de données MBXDB-03 qui s'y trouvait déjà (à comparer avec les captures d'écran plus haut) :



Et oui, Exchange crée le répertoire contenant le fichier .edb et l'index du contenu (le répertoire nommé MBXDB-01 dans la capture d'écran juste au-dessus). Il n'est pas nécessaire de le créer à la main.

Il en va de même pour le répertoire contenant les fichiers de journaux de transaction :



Et en dernier lieu, la commande dans la capture d'écran ci-dessous montre qu'il y a désormais deux copies de la base de données MBXDB-01. La première sur EX16-3 est montée ("Mounted") et la copie sur EX16-4 est en bonne santé ("Healthy").



No comments:

Post a Comment