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 :




No comments:

Post a Comment