Aujourd'hui, nous allons voir comment mettre en maintenance un DAG sur Exchange 2019.
Dans le dernier épisode, nous avions pu voir la mise en place d'un DAG Exchange 2019, mais qui dit produit Microsoft dit bien évidemment mises à jour de nos serveurs Exchange (Cumulatifs Windows Server, Rollup Exchange..).
L'exemple le plus marquant pour la mise en maintenance d'un nœud Exchange sera bien évidement le passage d'un rollup Exchange.
L'installation d'un rollup Exchange mettra hors connexion votre noeud, puisque le rollup désinstalle complètement l'application pour la réinstaller avec la nouvelle version.
Mais les questions qui reviennent le plus souvent sont les suivantes:
- Mais pourquoi mettre en maintenance un serveur Exchange alors que je passe mes rollup le soir ou le Week-end?
- Mais pourquoi mettre en maintenance un serveur Exchange car je trouve que cela prend beaucoup de temps à faire toutes ces manipulations?
Comme toutes mises à jours il y a des phénomènes que l'on ne peut pas toujours anticipés, tout ne se passe pas comme prévu (il faut reconnaître qu'il n' y a plus beaucoup de problèmes, Microsoft ayant fait beaucoup d'effort sur la façon d'installer un nouveau rollup).
Chacun doit prendre conscience que l'on doit prendre un maximum de précautions même si cela doit prendre un peu plus de préparation.
Les avantages d'un DAG sont les suivants:
- Eviter de perdre des données et de rendre indisponible une base de données.
- Possibilité de passer un rollup en pleine Journalisée sans impacts sur les utilisateurs
- Possibilité de passer des cumulatifs update et redémarrer le serveur en pleine journée
- Possibilité de prendre du temps pour investiguer un problème matériel
Pour mettre un nœud Exchange en maintenance, nous n'allons pas utiliser le scripts présents par défaut dans le répertoire des binaires Exchange car je trouve qu'ils ne fonctionnent pas très bien donc je ne les recommande pas. (voir ci-dessous).
Nous allons en détails effectuer les différentes commandes.
Il est très important de comprendre le fonctionnement de mise en maintenance d'un nœud Exchange configuré dans un DAG.
Une fois que l'on maîtrise les différentes commandes on pourra automatiser le tout dans un script.
Pour commencer, nous allons nous connecter à la console "Exchange Management Shell".
La première commande à passer sera de vider le "Hub Transport" du nœud Exchange et de le passer en mode "drainage"
Set-ServerComponentState EXCH2019A -Component HubTransport -State Draining -Requester Maintenance
Redémarrage du service.
Restart-Service MSExchangeTransport
Nous allons ensuite forcer à rediriger tous les messages de la file d'attente vers l'autre serveur du DAG.
Redirect-Message -Server EXCH2019A -Target EXCH2019B.labo.local
Nous vérifions le résultat de la commande.
Get-ServerComponentState EXCH2019A -Component HubTransport
Nous vérifions ensuite quel serveur gère le "Primary Active Manager (https://docs.microsoft.com/fr-fr/exchange/high-availability/database-availability-groups/active-manager?view=exchserver-2019)
Get-DatabaseAvailabilityGroup -Status | fl Name, PrimaryActiveManager
Nous constatons que le PAM est géré par le noeud que souhaitons mettre en maintenance.
Il faudra donc le déplacer.
Nous allons donc déplacer le PAM vers l'autre nœud.
Remarque: vous devrez vous connecter en "PowerShell Remoting avec WinrM sur l'un deux serveurs.
Move-ClusterGroup "Groupe du cluster" -Node EXCH2019B
On vérifie la bonne migration du PAM vers le deuxième serveur.
Get-DatabaseAvailabilityGroup -Status | fl Name, PrimaryActiveManager
Nous mettons en pause le cluster sur le Nœud Exchange.
Suspend-ClusterNode EXCH2019A
On vérifie le résultat.
Get-ClusterNode
Nous allons maintenant déplacer les copies Actives sur le nœud.
Nous vérifions quelles bases de données sont actives (Mounted) sur le Nœud Exchange.
Get-MailboxDatabaseCopyStatus -Server EXCH2019A
Nous remarquons que la base de données DB01 est active sur le serveur Exch2019A.
Nous déplaçons donc la copie active de la base de données DB01 vers le serveur Exch2019B.
Get-MailboxDatabaseCopyStatus -Server EXCH2019A | ? {$_.Status -eq "Mounted"} | % {Move-ActiveMailboxDatabase $_.DatabaseName -ActivateOnServer EXCH2019B -Confirm:$false}
Nous vérifions les copies actives sur le serveur Exch2019B
Get-MailboxDatabaseCopyStatus -Server EXCH2019B
DB01 est bien active sur le serveur EXCH2019B.
On peut également vérifier la présence dans le Centre d'Administration Exchange.
La commande ci-dessous sera nécessaire pour empêcher le serveur EXCHA2019A de pouvoir à nouveau monter la base de données DB01.
Set-MailboxServer EXCH2019A -DatabaseCopyAutoActivationPolicy Blocked
Vérification de la stratégie.
Get-MailboxServer EXCH2019A | ft Name,DatabaseCopyAutoActivationPolicy
Pour terminer nous mettons notre nœud en maintenance.
Set-ServerComponentState EXCH2019A -Component ServerWideOffline -State Inactive -Requester Maintenance
Notre serveur est maintenant totalement hors ligne du DAG!!! 💪😏
Vous pouvez maintenant effectuer votre maintenance en toute sécurité!!!
Une fois votre maintenance terminée, nous allons pouvoir sortir le serveur Exchange de sa maintenance.
On sort le serveur du mode maintenance.
Set-ServerComponentState EXCH2019A -Component ServerWideOffline -State Active -Requester Maintenance
On réactive le cluster du le nœud.
Resume-ClusterNode EXCH2019A
On autorise à nouveau la possibilité l'auto-montage de la base de données sur le nœud.
Set-MailboxServer EXCH2019A -DatabaseCopyAutoActivationPolicy Unrestricted
Et on vérifie.
Get-MailboxServer EXCH2019A | ft Name,DatabaseCopyAutoActivationPolicy
On réactive le transport sur le serveur Exchange.
Set-ServerComponentState EXCH2019A -Component HubTransport -State Active -Requester Maintenance
Et on vérifie.
Get-ServerComponentState EXCH2019A -Component HubTransport
On vérifie que le serveur est à nouveau hors maintenance.
Get-ServerComponentState EXCH2019A | ft Component,State -AutoSize
On rétablit le PAM sur le serveur Principal (Juste plus clair pour moi).
Move-ClusterGroup "Groupe du cluster" -Node EXCH2019A
On vérifie les bases de données.
Get-MailboxDatabaseCopyStatus -Server EXCH2019A
Get-MailboxDatabaseCopyStatus -Server EXCH2019B
On peu constater que tout est revenu comme à l'origine:
- DB01 est Active sur Exch2019A et Passive sur EXCH2019B
- DB02 est Active sur Exch2019B et Passive sur EXCH2019A
Voilà c'est terminé, tout est maintenant opérationnel. 😃😄
Dans cet article nous avons pu voir et comprendre la mise en maintenance d'un serveur Exchange 2019 présent dans un DAG.
Si vous avez compris et que vous maîtrisez les différentes étapes effectuées ci-dessus vous n'avez plus qu'à construire votre script.
A vos tests!Scriptez!!😊😊
Aucun commentaire:
Enregistrer un commentaire