Monday, June 26, 2017

Exchange 2016 (24) : le mode maintenance pour le DAG (1)

English summary: with Exchange 2010, we could place Database Availability Group (DAG) servers in maintenance mode with a simple script. Since Exchange 2013, this is supposedly no longer possible or at least recommended. After consulting various sources (cited at the end of the text), I demonstrate the method that worked for me. It is essentially a matter of executing a number of PowerShell cmdlets that modify not only the status of the DAG but also Client Access and Transport functions.

***

La mise en mode maintenance pour les DAG (Database Availability Groups) ne fonctionne plus de la même manière pour Exchange 2016 (ou 2013) que pour Exchange 2010.

Avec Exchange 2010, il s'agissait d'exécuter le script ci-dessous pour la mise hors ligne du serveur auquel on allait appliquer des mises à jour de sécurité (ou autres) :

StartDagServerMaintenance.ps1

Après l'installation des mises à jour (et le redémarrage du serveur), il suffisait d'exécuter le script ci-dessous pour remettre le DAG en ligne :

StopDagServerMaintenance.ps1

Il convient de préciser que si le serveur tenait des copies dites "actives" des bases de données, ou bien le rôle "PAM" (Primary Active Manager) avant la mise hors ligne, l'exécution du second script ne rétablissait pas le statu quo antérieur. Il fallait déplacer les ressources qu'on voulait remettre au serveur en question par une opération distincte.

De plus, le script n'agissait que sur le fonctionnement du DAG. Les autres rôles (accès client et transport) ne subissaient aucun effet.

Avec Exchange 2016, ces scripts sont toujours disponibles mais il paraît que nous ne devons pas les utiliser (si j'ai bien compris les discussions à ce sujet sur divers forums en ligne dont les forums Exchange de TechNet).


Il faut plutôt suivre le processus que je vais présenter dans les lignes suivantes.


***


Voici le statu quo à notre point de départ. Nous allons mettre en mode maintenance le serveur EX16-4 qui tient la copie active de la base de données MBXDB-01 ainsi que le rôle "PAM" de notre DAG :






1. Purger les files d'attente

Nous commençons le processus par l'exécution de cette commande :

Set-ServerComponentState EX16-4 -Component HubTransport -State Draining -Requester Maintenance

Dans mon réseau d'essai, les files d'attente sont déjà vides. Les voici avant l'exécution de la commande :


C'est à peu près pareil sur EX16-3 :


De plus, je n'observe aucun changement après l'exécution de la commande.




2. Faire redémarrer deux services Transport

En fait, il est recommandé de faire redémarrer deux services Transport afin que le changement prenne effet tout de suite...

Restart-Service MSExchangeTransport

Restart-Service MSExchangeFrontEndTransport

Note : certaines sources que j'ai consultées ne mentionnent que le premier service.

Note : je me trouve au serveur EX16-3 mais je veux que ces commandes agissent sur le serveur EX16-4. Entre autres options, je peux recourir à "Invoke-Command" :




Mais quel effet ces commandes ont-elles ?

D'une part, des messages s'accumulent dans la file d'attente "ShadowRedundancy" du serveur EX16-4 (ce sont des messages de la boîte "Health Mailbox [GUID]")

D'autre part, le serveur EX16-3, lui, perd sa file d'attente "ShadowRedundancy" :


Note : il faudra que je me renseigne sur le rôle de ces messages qui s'accumulent dans la file d'attente du serveur EX16-4. Je pose comme hypothèse qu'ils doivent avoir une fonction de "message de vie" pour vérifier la voie de communication entre les deux serveurs.



3. Rediriger des messages en attente de livraison vers d'autres serveurs

Il s'agit d'exécuter cette commande :

Redirect-Message -Server EX16-4 -Target EX16-3.machlinkit.biz


Note : il faut, paraît-il, utiliser le FQDN du serveur cible.




4. Déplacer le rôle "PAM" vers un autre membre du DAG

Nous utilisons deux sortes de commandes PowerShell pour gérer le cluster (le DAG se bâtit sur la fondation du service cluster de Windows) :

*-ClusterNode
*-ClusterGroup

Pour observer le statu quo, nous utilisons...

Get-ClusterNode
Get-ClusterGroup




Je constate que le serveur EX16-4 est le propriétaire du nœud pour le groupe du cluster "Groupe du Cluster".

Note : c'est pareil dans la version originale anglaise : le "Cluster Group" a pour nom "Cluster Group". 

Je fais du serveur EX16-3 le propriétaire du nœud avec la commande suivante (et il faut bien utiliser le nom français) :

Move-ClusterGroup "Groupe du cluster" -Node EX16-3



Et cela revient à transférer le rôle PAM vers EX16-3... mais sans mettre EX16-4 hors ligne.

Observez que l'état du nœud est toujours "Up") :



Ainsi, nous devons également suspendre EX16-4 afin qu'on ne puisse pas lui renvoyer le rôle PAM en plein entretien par mégarde : 

Suspend-ClusterNode EX16-4


Note : cela n'a aucun autre effet sur le DAG (capture d'écran ci-dessus).




5. Déplacer les bases de données actives vers un autre membre du DAG

Jusqu'à présent, nous nous sommes occupés des services Transport et du cluster. Il nous reste encore un certain nombre de tâches à accomplir et en particulier le déplacement des copies actives vers un autre membre du DAG. Nous y parvenons avec cette commande : 

Set-MailboxServer EX16-4 -DatabaseCopyActivationDisabledAndMoveNow $True


Attention ! Il faut un moment (quelques minutes au moins) pour que le déplacement s'achève. Quand j'ai exécuté la commande...

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus

une première fois, la copie active se trouvait toujours sur EX16-4. Il a fallu attendre encore quelques minutes avant d'observer le résultat désiré :





6. Bloquer la possibilité d'activation 

Comme pour les services de cluster, nous devons empêcher la copie active de revenir au serveur EX16-4 pendant la maintenance, ce qu'accomplit cette commande :

Set-MailboxServer EX16-4 -DatabaseCopyAutoActivationPolicy Blocked





7. Mettre le serveur en mode maintenance (services Accès client)

C'est ainsi que certaines sources décrivent cette dernière étape bien que le processus de mise en maintenance ait réellement commencé plus tôt. Voici la commande à exécuter :

Set-ServerComponentState EX16-4 -Component ServerWideOffline -State Inactive -Requester Maintenance


Cette commande agit notamment sur les services Accès client (CAS). Le serveur, mis en mode maintenance, ne répond plus, en principe, aux messages de vie des répartiteurs de charge (load balancer heart beats).

En fait, cette commande ne semble rien changer si on considère l'état des services vu de mon répartiteur de charge (Citrix NetScaler VPX) :



Quant aux services Transport, nous devrions veiller à ce que les files d'attente soient effectivement purgées. Mais qu'arriverait-il aux messages encore dans les files d'attente après l'exécution de cette commande ? Les messages en cours de traitement par les services Transport sont stockés dans une base de données. A priori, ils y seraient retenus pendant l'arrêt du service Transport et traités seulement à la remise en marche de celui-ci. Ils ne seraient pas perdus comme s'ils n'existaient que dans la mémoire vive.

Quoi qu'il en soit, nous vérifions l'effet de cette dernière commande avec sa variation "Get" :

Get-ServerComponentState EX16-4

Toutes les composantes, sauf "Monitoring" et "RecoveryActionEnabled" devraient avoir, pour la propriété "State" (état), la valeur "Inactive" :




***

A cette étape, nous pouvons (enfin) accomplir ce que nous avons à faire (installer des mises à jour de sécurité, par exemple).

Dans les lignes ci-dessus, j'ai cherché non seulement à présenter la marche à suivre mais aussi à vérifier pour moi-même si les commandes ont l'effet escompté. Il en résulte que le texte s'est allongé plus que je m'y attendais. De ce fait, je remets à plus tard la présentation de la remise en ligne du serveur.


Liens

Managing database availability groups - Exchange 2016

C'est la version anglaise originale.

La procédure présentée dans ce texte consiste...
  1. A exécuter certaines des commandes que j'ai utilisées plus haut.
  2. A exécuter le script StartDagServerMaintenance.ps1 (nommé à tort "StartDagServerMaintenanceScripts.ps1") comme avec Exchange 2010.
  3. A exécuter encore d'autres commandes utilisées dans mon billet de blogue ici.

En traduction française :

Gestion de groupes de disponibilité de base de données

---

Exchange 2013 Maintenance mode

La procédure est valable pour Exchange 2016 mais j'ai remarqué que la commande Suspend-ClusterNode ne déplace pas le PAM vers un autre membre du DAG. Il faut d'abord utiliser la commande Move-ClusterGroup.

---

Installing Cumulative Updates on Exchange Server 2016 - Paul Cunningham

Le sujet concerne l'installation des mises à jour mais l'auteur (fort respecté dans la communauté Exchange) présente sa façon de mettre les serveurs en mode maintenance.

No comments:

Post a Comment