Sunday, May 28, 2017

Exchange 2016 (21) : récupération d'un serveur membre d'un DAG (1)

English summary: we manage the recovery of a failed Exchange server that is a member of a DAG (Database Availability Group). First (out of curiosity), I simulate the failure of the server and observe the resilience of the DAG. Can users still access their mailbox and send/receive messages? I review some of the general steps for the recovery of a failed server using the /recoverserver option. However, when the server is a member of a DAG, we have to perform three other actions first: 1) Remove mailbox database copies on the failed server, 2) Remove the failed server from the DAG and 3) purge the failed server from the cluster. The reinstallation of the server OS, Exchange prerequisites and Exchange itself, will take place in the following blog post. 


***

Dans ce texte, nous allons démontrer la démarche à suivre pour récupérer un serveur Exchange en panne quand il est aussi membre d'un DAG (Database Availability Group).

Une récupération réussie suppose l'installation d'Exchange sur un nouveau serveur avec le même nom et aussi avec la même configuration des disques. Si, par exemple, la base de données MBXDB-01 se trouvait sur le lecteur F: avant la panne, il faut un lecteur F: sur le nouveau serveur. Dans un DAG, les chemins vers les bases de données sont censés être les mêmes et nous pourrions déduire la configuration des disques du serveur en panne à partir de la configuration des disques d'un serveur en bon état. Cela étant, il vaudrait mieux posséder une documentation à jour de nos serveurs. Je vais supposer que nous avons mis en pratique ce principe et pris note de la disposition des disques.

Remarque : nous devons installer la même version d'Exchange sur le nouveau serveur (de remplacement). Si le serveur en panne exécutait Exchange 2016 CU5, nous devons installer Exchange 2016 CU5 sur le serveur de remplacement.

Dans notre scénario, nous avons deux serveurs Exchange dont chacun compte un lecteur C: pour le système d'exploitation et les binaires Exchange, un lecteur E: pour les bases de données et un lecteur F: pour les fichiers des journaux de transaction.



Je sais aussi que les noms de nos serveurs sont EX16-3 et EX16-4. Nous pouvons aussi documenter d'autres éléments comme les paramètres TCP/IP. Il vaudrait sans doute mieux que le serveur ait la même adresse IP mais je ne vois pas cela comme une exigence dans la documentation.


***

Voici notre point de départ...

Nous avons donc deux serveurs Exchange (EX16-3 et EX16-4) qui font partie de "DAG1". Chacun possède une copie de la base de données "MBXDB-01".

La copie de MBXDB-01 est "active" sur EX16-3. De plus, EX16-3 tient le rôle "PAM" (Primary Active Manager).


Note : vous pouvez cliquer sur les images pour les agrandir.



Note : EX16-4 compte aussi une "simple" base de données (MBXDB-03) qui ne fait pas partie du DAG. Cette base de données n'entre pas en jeu dans notre scénario.

C'est donc le pire des scénarios : la base de données est "active" sur EX16-3, EX16-3 tient le PAM et c'est EX16-3 qui va connaître une panne soudaine. Pour simuler une telle panne, j'ai éteint la machine virtuelle tout d'un coup, comme si on avait coupé le courant à un serveur physique dépourvu d'une batterie de secours.

 Qu'est-ce qui se passe au moment de cette panne brusque ?

Les clients Outlook perdent leur connexion, d'autant plus que les boîtes aux lettres ne sont pas en mode cache (dans mon environnement). Mais Outlook essaie de rétablir la connexion :



Après une minute environ, la connexion se rétablit :



Dès que le connexion est rétablie, les clients peuvent envoyer (et recevoir) des courriels (et cela même si leur boîte aux lettres se trouve dans la base de données MBXDB-01). Dans l'exemple ci-dessous, Sonia Smith envoie un message à Paul York, malgré la panne de EX16-3 :






Je me connecte en tant que Paul York et je vois le message dans ma boîte de réception :




Le DAG a donc résisté à la perte d'un de ses membres sans la moindre difficulté.

***

Ainsi, notre système de messagerie continue à fonctionner mais nous n'avons plus qu'un seul serveur Exchange, ce qui nous rend vulnérables à une perte totale des services en cas d'une nouvelle panne. Nous devons donc mettre en service un second serveur, plus ou moins vite, et en faire un membre du DAG. Quelles sont nos options ? Nous pourrions avoir un logiciel de sauvegarde compatible avec Exchange, capable de restaurer une sauvegarde récente du serveur défaillant. Dans mon cas, je vais installer Exchange sur un nouveau serveur (une nouvelle machine virtuelle) avec l'option /recoverserver. Cette option permet au nouveau serveur de prendre l'identité de l'ancien mais il faut veiller à faire deux choses au préalable :
  1. Réinitialiser le compte ordinateur d'EX16-3 en Active Directory.
  2. Donner le même nom de hôte au nouveau serveur et l'ajouter au domaine (après avoir ré-initialisé le compte ordinateur. Il est crucial de respecter l'ordre des opérations).

De plus, lorsqu'il s'agit d'un serveur membre d'un DAG (comme dans le cas présent), nous devons réaliser d'abord trois autres opérations :
  1. Supprimer les copies des bases de données qui se trouvaient sur le serveur hors service. Dans notre scénario, il s'agit de la base de données MBXDB-01.
  2. Retirer le serveur en panne du DAG.
  3. Expulser le serveur en panne du "cluster". Il faut préciser que le DAG utilise des éléments du service Windows Clustering.


Je vais présenter ces trois opérations dans les paragraphes suivants et réserver l'installation de Windows, et puis d'Exchange, pour un texte à suivre.

Voici l'état du DAG après la panne du serveur EX16-3 :


EX16-3 et EX16-4 s'affichent comme serveurs membres (du DAG) mais seulement EX16-4 s'affiche comme serveur opérationnel. De plus, EX16-4 est devenu le PAM.

L'état de la copie de la base de données MBXDB-01 sur EX16-3 s'affiche comme "ServiceDown" et l'état de l'index de contenu comme "Unknown" : 



Nous commençons notre récupération en supprimant cette copie de la base de données avec la commande suivante :

Remove-MailboxDatabaseCopy MBXDB-01\EX16-3


Un assez long avertissement en caractères jaunes s'affiche. Il nous apprend ce que nous savons déjà : le serveur EX16-3 n'est pas accessible. La copie de la base de données est supprimée tout de même et l'avertissement nous rappelle de supprimer de façon manuelle les fichiers constituant la base de données (si nécessaire). Au fond, nous avons supprimé la référence à cette copie de la base de données dans les propriétés du DAG. Bien entendu, nous n'avons pas littéralement supprimé la base de données sur EX16-3 parce qu'il n'est plus en état de fonctionnement et nous ne pouvons pas accéder à ces fichiers pour les supprimer.

Il en résulte que la base de données MBXDB-01 ne compte plus de copie sur le serveur EX16-3. Il n'en reste plus que la copie sur EX16-4 :




La seconde de nos trois opérations consiste à retirer le serveur EX16-3 du DAG. En voici la commande :

Remove-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX16-3 -ConfigurationOnly



Remarque : si le serveur n'est pas accessible (cas probable s'il est en panne), il faut ajouter le paramètre -ConfigurationOnly. Sinon, vous verrez un message d'erreur comme ceci :




La troisième opération consiste à expulser EX16-3 du cluster. Nous pouvons voir des détails sur le cluster et puis expulser EX16-3 avec les commandes suivantes :




***

A cette étape, nous avons achevé les opérations concernant notre DAG. Cela faisant, nous avons sans doute éliminé certains messages d'erreur qui auraient commencé à inonder les journaux si le DAG essayait toujours de communiquer avec un serveur membre qui n'existe plus.

Mais nous devons remettre sur pied un second serveur Exchange. En effet, une seconde panne en ce moment signifierait la perte totale de notre système de messagerie. Nous allons donc réinitialiser le compte ordinateur d'EX16-3, installer Windows 2012 R2 avec les mêmes caractéristiques d'EX16-3 (notamment le nom et la disposition des disques), l'ajouter au domaine et puis installer tous les prérequis pour Exchange et enfin, installer Exchange 2016 CU5.

Ce sera, avec plus de détails, le sujet de mon prochain texte.

---

Ressources :




Thursday, May 18, 2017

Exchange 2016 (20) : recréer un index en état d'échec

English summary : when verifying the status of our Exchange mailbox databases, we notice that the content indexes are in a failed state. We need to rebuild the content index which is a three part operation: stop Exchange services related to content indexing, delete the content index folder and then restart the Exchange services that were stopped. The indexes will be recreated. With a DAG, we can reseed the content index from a healthy copy. If all copies of the database have a failed index, we can rebuild one and then reseed from this good copy.

***

Scénario : nous vérifions l'état de nos bases de données de boîtes aux lettres et nous constatons que l'index du contenu ("Content Index") est corrompu.

Dans mon réseau d'essai, nous avons trois bases de données :

  • MBXDB-01\EX16-3 (Note : la base de données fait partie d'un DAG)
  • MBXDB-01\EX16-4 (Note : la base de données fait partie d'un DAG)
  • MBXDB-03\EX16-4 (Note : base de données à une seule copie - ne fait pas partie d'un DAG)

Pour une raison que j'ignore, l'index de chacune des trois bases de données est corrompu. Chose curieuse, les bases de données elles-mêmes semblent en parfait état. A mon avis, cet affichage montre ce qu'il faut savoir le mieux :



Alors, comment réparer nos index ?

Il s'agit d'un processus en trois étapes :

  • Nous arrêtons deux services touchant aux index : MSExchangeFastSearch et HostcontrollerService.
  • Nous supprimons l'index corrompu. Il s'agit en fait de supprimer un répertoire qui contient les fichiers composant l'index.
  • Nous faisons redémarrer les services que nous avons arrêtés. Exchange va constater l'absence de l'index et le recréer.

Si la base de données fait partie d'un DAG, il faut compter une autre étape. Dans les paragraphes qui suivent, je présente d'abord la marche à suivre pour une base à données à copie unique (qui ne fait pas partie d'un DAG) et ensuite pour une base de données à deux copies (qui fait partie d'un DAG).  

Remarque : faites surtout attention à supprimer l'index de la base de données et non pas la base de données elle-même !


Première étape

Nous arrêtons les services en question avec les commandes suivantes :

Stop-Service MSExchangeFastSearch
Stop-Service HostcontrollerService

Vous pourriez voir ceci :


C'est normal.

Nous pouvons vérifier l'état des deux services avec ces commandes :


Il est important que les services soient bel et bien arrêtés. Sinon, nous rencontrerions beaucoup de messages d'erreur en caractères rouges à la prochaine étape (supprimer les fichiers composant l'index).


Seconde étape

Voici le répertoire que nous devons supprimer :


Comme nous pouvons le voir, il correspond à la base de données MBXDB-03 qui se trouve seulement sur le serveur EX16-4. Il contient des sous-répertoires et des fichiers. Nous pouvons le supprimer dans l'interface graphique ou à la ligne de commande :

Remove-Item [GUID] -Recurse


Note : "gci" est un raccourci (ou "alias") pour Get-ChildItem. D'ailleurs, nous aurions pu utiliser "ri" comme raccourci pour Remove-Item. Le paramètre -Recurse est nécessaire si nous voulons tout supprimer d'un seul coup, au lieu de supprimer les sous-répertoires un à un au préalable (ce qui serait fastidieux).


Troisième étape

Après la suppression du répertoire contenant les fichiers de l'index, nous pouvons faire redémarrer les services suivants :

Start-Service MSExchangeFastSearch
Start-Service HostcontrollerService



L'état de l'index change. C'est maintenant "Crawling" (ou "rampant") :



Après une durée variable, l'index retrouve son état "sain" :



Chose bizarre, les deux autres index ont eux aussi retrouvé un état sain bien que rien n'ait été supprimé à cette fin. Je ne peux pas expliquer cette évolution inattendue. Je ne peux qu'émettre l'hypothèse que le redémarrage des services associés aux index ait provoqué une action réparatrice là aussi.

Attention : la reconstruction de l'index peut peser sur les ressources du système et prendre beaucoup de temps. Je crois avoir lu un exemple où elle a mis un jour. La taille des bases de données à indexer et la puissance du matériel sont deux facteurs à prendre en considération.

***

Mais que ferions-nous si nous avions un DAG (et si les index ne s'étaient pas réparés apparemment tous seuls) ?

Si tous les index étaient corrompus, nous réparerions l'un d'entre eux en suivant la méthode démontrée ci-dessus. Quand nous aurions un index en bonne santé, nous pourrions mettre à jour l'index encore corrompu avec la commande suivante : 

Update-MailboxDatabaseCopy MBXDB-01\EX16-4 -CatalogOnly

Nous désignons la base de données sur laquelle nous voulons agir. Exchange va chercher les données nécessaires à un serveur avec un index sain. Si nous n'avons que deux copies de la base de données, nul besoin de désigner l'autre serveur puisqu'il n'y a pas d'autre choix.