Sunday, June 11, 2017

Exchange 2016 (23) : récupération d'un serveur membre d'un DAG (3)

English summary: after reinstalling our failed Exchange 2016 server with the /recoverserver parameter, reconfiguring the client access Urls and the SSL certificate (see previous blog post), we readd the recovered server to the DAG and create a copy of the MBXDB-01 database on the recovered server. Various functions are tested (client access, send/receive email) and we consider the interaction with our load balancer. Lastly, I point out that there may be other elements to reinstall and reconfigure such as the antivirus and backup programs


***
 

Maintenant que le serveur EX16-3 est remis sur pied, nous sommes prêts à le rajouter à notre DAG et à lui ajouter une copie de la base de données MBXDB-01.


Voici notre point de départ...

Seul le serveur EX16-4 fait partie du DAG en ce moment :



Les lecteurs E: et F: du serveur EX16-3 sont vides :



Voici, par exemple, le contenu du lecteur E: (rien) :



Si nous mettons de côté la base de donnée MBXDB-03 (qui ne joue aucun rôle dans cet exercice), nous pouvons observer que la base de données MBXDB-01 ne compte qu'une seule copie qui se trouve sur le serveur EX16-4 :





Rajouter le serveur au DAG

Maintenant, nous allons rajouter le serveur récupéré, EX16-3, au DAG avec la commande suivante :

Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX16-3



Nous devrions voir les opérations affichées à mesure qu'elles se réalisent :


Note : oui, c'est au serveur EX16-4 que je me trouve et où j'exécute la commande qui cible bel et bien le serveur EX16-3.


Les résultats sont observables tout de suite. Notre DAG compte de nouveau deux serveurs :





Ajouter une copie de la base de données à EX16-3

Maintenant que le serveur récupéré (EX16-3) fait de nouveau partie du DAG, nous sommes en mesure d'ajouter une copie des bases de données à répliquer. Dans notre cas, il s'agit de la base de données MBXDB-01. Il n'est pas obligatoire de faire une copie de toutes nos bases de données sur tous les serveurs membres du DAG. Nous avons, par exemple, une autre base de données, MBXDB-03, et nous n'en garderons qu'une seule copie.

Nous ajoutons donc une copie de la base de données MBXDB01 sur EX16-3 avec la commande suivante :

Add-MailboxDatabaseCopy MBXDB-01 -MailboxServer EX16-3


Note : l'avertissement en caractères jaunes concernent les permissions sur les répertoires qui viennent d'être créés. Il est recommandé de créer les répertoires au préalable pour avoir les permissions les plus sûres. Je ne vais pas traiter de cette question ici.


Si tout se passe bien, nous devrions avoir vu les opérations se réaliser en haut de l'écran :


 

En outre, nous pouvons observer  le progrès des données copiées vers EX16-3. La file d'attente où les données attendent d'être copiées décroît en nombre pour enfin arriver à zéro :




Quant à l'état de l'index du contenu, il est "en échec". J'ai essayé de le réparer avec la commande suivante :

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



Mais son état n'a pas changé tout de suite et il a fallu attendre encore un moment avant que tout rentre dans l'ordre :



Peut-être fallait-il simplement faire preuve de plus de patience ? Je me suis demandé si l'état de l'index serait redevenu normal sans la commande Update-MailboxDatabaseCopy ?

En tout cas, les lecteurs E: et F: qui étaient vides au départ contiennent désormais une copie de la base de données et les fichiers des journaux de transaction respectivement :



Voici l'exemple du lecteur E:



Les répertoires ont été créés de façon automatique sans intervention manuelle aucune. Cependant, il paraît que le processus n'ajuste pas les permissions selon les recommandations que nous avons vues dans les avertissements en caractères jaunes plus haut.


****


Nous avons rétabli notre DAG mais est-il vraiment en état de marche ? Les commandes exécutées plus haut semblent le confirmer mais pouvons-nous rendre la base de données MBXDB-01 active sur EX16-3 avec succès ? Je fais le changement avec cette commande :

Move-ActiveMailboxDatabase MBXDB-01 -ActivateOnServer EX16-3



Je confirme l'état de la base de donnée (et ses copies) avec cette commande :

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus



Ensuite, je vérifie que mes utilisateurs peuvent accéder à leur boîte aux lettres, envoyer et recevoir des messages, à la fois entre eux et avec des correspondants à l'extérieur. Nous avons déjà vu dans le texte précédent que si nous devons remplacer les Urls et le certificat SSL pour le service Accès client, les services Transport s'étaient rétablis sans intervention manuelle au cours de l'installation du serveur, grâce au paramètre /recoverserver.

 ***

Dans la plupart des réseaux, Exchange ne fonctionne pas tout seul (sans même compter l'interaction nécessaire avec Active Directory). Il faudrait sans doute réinstaller, par exemple, un logiciel d'antivirus et de sauvegarde. Il arrive aussi que le système de messagerie recourt à un répartiteur de charge. Dans le scénario de panne et de récupération que j'ai mis en scène ici, le basculement s'est fait sans mal et l'utilisateur d'Outlook n'a remarqué qu'une courte déconnexion (une minute au plus ? ). Il faut penser que le répartiteur a bien géré la panne de son côté aussi.

A ce sujet, je voulais prendre note de l'état des éléments concernant mes serveurs Exchange lors de la panne, afin de savoir ce qui est normal dans une telle situation. Bien entendu, l'interface de chaque répartiteur varie. Ce qui suit montre les effets de la panne d'un serveur Exchange vus de la perspective de mon répartiteur (Citrix NetScaler VPX v. 11).

Dans la section "Servers", rien ne change. Les "voyants" restent verts :



Dans la section "Virtual Servers", tout est au vert, sans doute parce qu'au moins un des serveurs est en état de marche et capable de fournir le service en question (HTTPS, SMTP). C'est seulement si nous regardons de plus près, dans la colonne " % Health " que nous voyons qu'un des deux serveurs manque à l'appel :



Dans la section "Services", nous avons une vue plus détaillée de ceux-ci et nous voyons que c'est EX16-3 (le serveur en panne) qui ne fournit plus le service en question (HTTPS et SMTP dans notre configuration) :

  

Bien entendu, après la récupération d'EX16-3, tous les voyants sont verts de nouveau.

De plus, je n'ai été obligé de prendre aucune action sur le répartiteur de charge. Quand le serveur en panne était remis sur pied, les communications avec le répartiteur ont repris automatiquement.





1 comment: