¶ II – Gestion avancée de la Haute disponibilité DAG
¶ A – Présentation du DAG avancé
¶ 1 - Présentation
Rappel :
La haute disponibilité des bases de données dans Exchange s’effectue à l’aide d’un DAG.
Ce terme signifie « Database Availability Group » ou en français « Groupe de disponibilité de base de données ».
Il assure pour cela une redondance au niveau du « BACK-END ».
Son principe de fonctionnement est simple : il réplique des bases de données sur un regroupement plusieurs serveurs Exchange ayant le rôle de boites aux lettres pour en effectuer la haute disponibilité pour de prévenir les pannes ou les coupures de service potentielles. Ce qui veut dire que les serveurs Exchange peuvent ainsi récupérer automatiquement des bases de données à la suite d’une panne d’un serveur ou lorsqu’une base de données n’est plus accessible.
Un DAG se base sur le service de « Cluster » de Windows Serveur mais ne peut pas être géré par les outils de Cluster de basculement de Windows Server.
Lorsque la création d’un DAG est initiée, les rôles et fonctionnalités de cluster sont installés sur chaque nœud qui en fait partie.
Au sein d’un DAG il est possible de configurer plusieurs éléments. Voici quelques exemples :
- Configuration des réseaux du DAG
- Configuration manuelle des réseaux MAPI et de réplication
- Ignorance de certains réseaux comme les réseaux iSCSI par exemple
- Configuration du port pour le réseau de réplication
- Chiffrement des communications
- Compression des communications
- Ordre de préférence d’activation des copies de bases de données (numérotation)
- Comportement du montage automatique des bases de données
- Stratégies d’activations automatique des copies de bases de données
- Le nombre maximal de bases de données actives sur un même serveur
- Le comportement du montage automatique des bases de données d’un DAG au démarrage (Data Activation Coordination - DAC)
- Configuration d’un serveur témoin de secours
- Le retard des copies de bases de données
- Renommer et déplacer l’emplacement des fichiers de bases de données
Attention :
Réseau MAPI : réseau LAN
Réseau de réplication : réplication entre les serveurs du DAG
¶ 2 – Vérifier la configuration du DAG
Voici deux commandes très utiles pour vérifier la configuration du DAG :
- Voir les paramètres généraux du DAG
Get-DatabaseAvailabilityGroup «nom_du_DAG» -Status | Format-List
- Voir les informations réseau du DAG
Get-DatabaseAvailabilityGroupNetwork -Identity «nom_du_DAG»¶ B – Présentation de la fonction DAG « autoreseed »
¶ 1 - Présentation
La fonction « autoreseed » est apparue à partir de Exchange 2013 et ne fonctionne que dans un DAG.
Elle est activée par défaut mais ne fonctionne pas par défaut puis qu’elle nécessite une configuration spécifique.
Son but est de détecter et de résoudre automatiquement les problèmes de stockages des copies de bases de données et est basée sur des systèmes de volumes dont un volume de secours (SPARE).
Cette fonction nécessite que les fichiers de données de bases de données soient colocalisés dans le même répertoire (fichiers de logs et de bases de données)
Le mécanisme est le suivant :
- Analyse toutes les 15 minutes de l’état des copies de bases de données pour trouver celles dont le statut est « FailedAndSuspended »
- En cas de détection de statut « FailedAndSuspended » sur une copie de base de données, le mécanisme tente alors de la réparer 3 fois
- En cas d’échec de réparation, donc après les 3 tentatives, le mécanisme recherche alors un volume non utilisé et configuré comme étant un volume de secours (SPARE). Il essaie chaque heure jusqu’à 4 fois de remplacer le volume utilisé par les copies de bases de donnes en erreurs par le volume SPARE. Lorsque l’opération réussie, il relance la mise à jour des copies de bases de données.
Il est recommandé d’utiliser un stockage de type JBOD pour les DAG avec plus de 2 copies de bases de données.
Exemple avec un schéma :
On retrouve ici, la partition système qui est en RAID 1 dans laquelle nous avons créé deux dossiers. Un pour les bases de données et un deuxième pour les « Exchangevolumes ». C’est dans ce dernier que la liste des volumes sera disponible, y compris le volume SPARE permettant à l’autoreseed de fonctionner.
La partition C : stockera donc les deux dossiers mais pas les contenus, ils seront disponibles via le réseau qu’ils soient physiques ou virtuels via des points de montage. La même chose sera faite pour les bases de données et les copies de bases de données.
¶ 2 – La pratique
- Vérification de l’activation par défaut
Get-DatabaseAvailabilityGroup «nom_du_DAG» | fl AutoDagAutoReseedEnabled
- Création d’un répertoire « volumes » associé à une partition (point de montage)
md C:\ExchangeVolumes
- Création d’un répertoire pour les bases de données (point de montage)
md C:\ExchangeDatabases
- Configuration du répertoire racine pour les volumes dans le DAG
Set-DatabaseAvailabilityGroup «nom_du_DAG» -AutoDagVolumesRootFolderPath «C:\ExchangeVolumes»
- Configuration du répertoire racine pour les bases de données du DAG
Set-DatabaseAvailabilityGroup «nom_du_DAG» -AutoDagDatabasesRootFolderPath «C:\ExchangeDatabases»
- Configuration du nombre de copie de bases de données par volume
Set-DatabaseAvailabilityGroup «nom_du_DAG» -AutoDagDatabaseCopiesPerVolume «numéro»
- Monter les volumes de stockages, via la gestion des disques de Windows (diskmgmt.msc)
C:\ExchangeVolumes\Volume1
C:\ExchangeVolumes\Volume2
- Création des répertoires de bases de données
md : C:\ExchangeDatabases\DB01
- Créer des points de montage pour les bases de données
Mountvol.exe C:\ExchangeDatabases\DB01 \\?\Volume (GUID)
- Création de la structure des répertoires des bases de données
md : C:\ExchangeDatabases\DB01\DB01.db
md : C:\ExchangeDatabases\DB01\DB01.log
- Création des bases de données
New-MailboxDatabase -Name DB01 -Server «nom_du_serveur» -LogFolderPath C:\ExchangeDatabases\DB01\DB01.log -EdbFilepath C:\ExchangeDatabases\DB01\DB01.db\DB01.edb
Attention : il est IMPERATIF que la solution soit étudiée et configurée avant la mise en place des bases de données et de leur copies
¶ C – Mise en place de la fonction DAG « autoreseed »
La mise en place devra se dérouler de la manière suivante :
- Monter le même nombre de disques dur sur chaque Serveur du DAG
- Formater les disques
- Réaliser la procédure précédente
- Vérification du fonctionnement
Exemple avec des VMs :
- Ajout des disques
Gestion et mise en ligne des disques depuis Windows
- Formatage des disques
- Lancer EMS en administrateur pour effectuer la procédure précédente
Vérification de l’activation par défaut
Création d’un répertoire « volumes » associé à une partition (point de montage)
Création d’un répertoire pour les bases de données (point de montage)
Configuration du répertoire racine pour les volumes dans le DAG
Configuration du répertoire racine pour les bases de données du DAG
Configuration du nombre de copie de bases de données par volume
Monter les volumes de stockages, via la gestion des disques de Windows (diskmgmt.msc)
Cliquer sur « ajouter »
Cliquer sur « nouveau dossier » et créer le dossier « volume1 »
Sélectionner le dossier créé et valider par « OK »
Valider le montage par OK
Refaire la même chose pour chacun des disques en prenant soin de nommer le dossier qui sera créé correctement (volume2, volume 3).
Lorsque cette manipulation est faite sur un serveur il faudra obligatoirement la refaire sur le ou les autres serveurs du DAG afin d’avoir une configuration uniforme partout.
Création des répertoires de bases de données
Créer des points de montage pour les bases de données.
Faire la commande suivante afin d’identifier les GUID des volumes précédemment créés sur les disques.
Via l’EMS
Une fois le GUID du volume identifié le point de montage peut être créé depuis une invite de commande CDM
On peut vérifier le point de montage en refaisant la commande « mountvol.exe »
Via l’EAC
Valider par « OK »
Création de la structure des répertoires des bases de données
Création des bases de données
Pour redémarrer le service il est possible de le faire directement depuis les services Windows mais également en PowerShell via l’EMS
Pour monter les bases de données
- Ajout d’une copie de base de données sur un autre serveur
Vérification du statut des bases de données sur les serveurs
La vérification permet de constater que les bases de données sont montées sur le serveur EXCH-01 et que leurs copies sont saines sur EXCH-02.
- Vérification du bon fonctionnement de l’autoreseed
Pour vérifier le bon fonctionnement, on peut simuler une panne sur le volume1. Pour rappel il s’agit du volume qui contient les bases de données active et montées.
Mettre hors connexion le volume1
Utilisation de la commande EMS pour voir le statut des bases de données. On constate que les bases de données obtiennent le statut « FailedAndSuspended ».
Si le basculement automatique via l’« autoreseed » fonctionne elles devraient être montée sur le deuxième serveur. Il ne reste plus qu’a vérifier avec la même commande.
Les bases de données sont en train de remonter, la fonction « autoreseed » est donc fonctionnelle.
Attention : cela peut prendre plusieurs heures
¶ D – Configuration des paramètres avancés du DAG
¶ 1 – La configuration des réseaux
Les réseaux peuvent être configurés de deux façons :
Via l’EAC
Dans la partie « serveur » cliquer sur « groupes de disponibilité de la base de données »
Pour modifier le DAG cliquer sur l’icône
activer la configuration manuelle en cochant la case
Une fois la configuration manuelle activée il sera possible de modifier les options dans la partie de droite du DAG
L’option « afficher les détails » permet d’éditer les différents paramètres
Via l’EMS
- Activation de la configuration manuelle
Set-DatabaseAvailabilityGroup «nom_du_DAG» -ManualDagNetworkConfiguration $True- Création d’un réseau pour le DAG avec option de nommage, description, informations IP et activation de la réplication
New-DatabaseAvailabilityGroupNetwork – DatabaseAvailabilityGroup «nom_du_DAG» -Name «nom_du_réseau» -Description «description_du_réseau» -Subnets «réseau/masque» -ReplicationEnabled $True- Changer l’adressage réseau du réseau MAPI du DAG
Set-DatabaseAvailabilityGroupNetwork -Subnest ««réseau/masque» -Identity «nom_du_DAG\MapiDagNetwork»- Supprimer un réseau du DAG
Remove-DatabaseAvailabilityGroupNetwork -Identity «nom_du_DAG\nom_du_réseau»- Désactiver la réplication d’un réseau ciblé et activer l’ignorance d’un réseau
Set-DatabaseAvailabilityGroupNetwork -Identity «nom_du_DAG\nom_du_réseau» -ReplicationEnabled $False -IgnoreNetwork $True- Configuration du port pour la réplication du DAG
Set-DatabaseAvailabilityGroup -Identity «nom_du_DAG» -ReplicationPort «numéro_du_port»- Modifier la configuration de la compression et du chiffrement pout le DAG
Set-DatabaseAvailabilityGroup -Identity «nom_du_DAG» -NetworkCompression Enabled -NetworkEncryption InterSubnetOnly¶ 2 – Configuration de l’ordre d’activation des bases de données
Via l’EAC
Dans la section « serveur » cliquer sur « base de données »
Sélectionner la base de données dont l’ordre d’activation devra être modifier puis cliquer sur « afficher les détails » à droite de l’écran
La modification peut être faite dans la section « Numéro de préférence d’activation »
Via l’EMS
Set-MailboxDatabaseCopy -Identity «nom_de_la_BDD\nom_du_serveur» -ActivationPreference «numéro»- Exemple
Set-MailboxDatabaseCopy -Identity DB01\EXCH01 -ActivationPreference 1
Set-MailboxDatabaseCopy -Identity DB01\EXCH02 -ActivationPreference 2
Set-MailboxDatabaseCopy -Identity DB02\EXCH01 -ActivationPreference 2
Set-MailboxDatabaseCopy -Identity DB02\EXCH02 -ActivationPreference 1La base de données « DB01 » sera montée par défaut sur le serveur EXCH01 tandis que la base de données « DB02 » sera montée par défaut sur EXCH02. Dans chacun des cas, l’autre serveur servira en second pour monter les bases de données s’il n’est pas possible de le faire sur les serveurs par défaut.
¶ 3 – Comportement du montage automatique
Il est possible de modifier le comportement du montage automatique des bases de données.
Pour cela, le paramètre « AutoDatabaseMountDial » sera utilisé pour spécifier le comportement du montage automatique des bases de données après le basculement d’une base de données notamment avec les options suivantes :
- BestAvailability
Cette valeur spécifie que la base de données sera remontée automatiquement après un basculement SI la longueur de la file d’attente de copies est inférieur ou égale à « 12 » C’est-à-dire le nombre de journaux reconnus par la copie passive devant être répliqués
- GoodAvailability (valeur par défaut)
Cette valeur spécifie que la base de données sera remontée automatiquement après un basculement SI la longueur de la file d’attente de copies est inférieur ou égale à « 6 ». C’est-à-dire le nombre de journaux reconnus par la copie passive devant être répliqués
- Lossless
Cette valeur spécifie que la base de données ne sera pas remontée automatiquement tant que tous les journaux générés par la copie active ne seront pas copiés sur la copie passive.
Set-MailboxServer -Identity «nom_du_serveur» -AutoDatabaseMountDial «valeur_du_paramètre»Exemple :
Set-MailboxServer -Identity EXCH-01 -AutoDatabaseMountDial BestAvailabilityLe montage automatique est connu sous le nom de Datacenter Activation Coordination (DAC).
Il permet de prévenir le comportement de « Split Brain » dans le cas d’une coupure de communication entre serveurs (Datacenter).
Il est désactivé par défaut mais il est recommandé de l’activer si le DAG possède plus de 2 serveurs membres.
Définition Wikipédia du « Split Brain »
Un « Split-Brain » se produit lorsque deux parties d'un cluster d'ordinateurs sont déconnectées, chaque partie croyant que l'autre ne fonctionne plus. Le terme est une analogie médicale du syndrome Split-Brain (littéralement « cerveau scindé »).
Les clusters à haute disponibilité utilisent le réseau afin de surveiller l'état des nœuds le composant. Une des fonctionnalités les plus critiques qu'un logiciel de clustering doit pouvoir gérer est le Split-Brain. En effet, si le lien réseau entre les nœuds vient à tomber, mais que ces nœuds sont toujours en fonctionnement, ceux-ci vont croire que les autres nœuds ne fonctionnent plus et vont essayer de démarrer des services qui en réalité tournent toujours. Ceci peut occasionner des duplications de services, voire de la corruption de données dans certains cas. Les données peuvent ainsi se trouver dans un état incohérent.
Pour prévenir ce phénomène, les machines doivent utiliser des liens redondants, être équipées d'un mode gérant le Split-Brain et pouvoir se mettre en état d'auto-fencing - c'est-à-dire de pouvoir s'isoler par elle-même de la grappe - lorsque des nœuds semblent hors ligne.
Pour configurer le DAC via EMS :
Set-DatabaseAvailabilityGroup -Identity «nom_du_DAG» -DatacenterActivationMode DagOnlyIl est également possible d’utiliser les commandes suivantes :
- Stop-DatabaseAvailabilityGroup
- Restore-DatabaseAvailabilityGroup
- Start-DatabaseAvailabilityGroup
¶ 4 – Stratégie d’activation automatique
Le paramètre « DatabaseCopyAutoActivationPolicy » permet de spécifier la stratégie à adopter pour l’activation automatique des copies de bases de données de boites aux lettres sur les serveurs de boites aux lettres ciblés.
Pour cela les valeurs suivantes seront utilisées :
- Blocked
- IntrasiteOnly
- Unrestricted
Configuration via EMS :
Set-MailboxServer «nom_du_serveur» -DatabaseCopyAutoActivationPolicy «valeur»Exemple :
Set-MailboxServer EXCH-01 -DatabaseCopyAutoActivationPolicy BlockedDans cet exemple l’activation automatique des copies de bases de données sur le serveur EXCH-01 sont bloquées.
Par défaut la valeur est placé à « Unrestricted »
¶ 5 – Nombre maximal de base de données de boite aux lettres actives
Le paramètre « MaximumActiveDatabases » permet de spécifier le nombre maximal de base de données qui peuvent être montées en même temps sur un serveur de boite aux lettres.
Set-MailboxServer -Identity «nom_du_serveur» -MaximumActiveDatabases «nombre »Par défaut il n’y a pas de valeur à ce paramètre
Exemple :
Set-MailboxServer -Identity EXCH-01 -MaximumActiveDatabases 20
Attention : il ne s’agit pas du nombre total de bases de données sur le serveur mais bien le nombre maximum de bases de données qui sont MONTEES (donc actives) sur le serveur
¶ 6 – Configuration d’un second serveur témoin pour le DAG
Set-DatabaseAvailabilityGroup -Identity «nom_du_DAG» -AlternateWitnessDirectory «chemin_du_répertoire» -AlternateWitnessServer «nom_du_serveur»Exemple :
Set-DatabaseAvailabilityGroup -Identity DAG01 -AlternateWitnessDirectory D:\DAGFileShareWitness\DAG01 -AlternateWitnessServer SRV-Temoin-02¶ E – Renommer et déplacer une base de données
¶ 1 – Présentation du renommage
Comme le nom l’indique, cela permet de renommer une base de données et c’est généralement utilisé pour changer les noms par défaut des bases de données.
Il est toutefois conseillé de renommer une base de données avec le même nom que les fichiers binaires (« .edb » et les « .log »)
En pratique comment ça marche :
Il est possible de renommer les bases de données à l’aide de l’EAC ou de l’EMS
Via l’EAC :
Dans la section « serveur » cliquer sur « base de données »
Cliquer sur l’icône
pour faire apparaître les paramètres de la base de données
Pour renommer la base de donner, il suffit de modifier le nom dans la section « nom » de la base de données.
Penser à donner le même nom aux fichiers binaires (« .edb » et les « .log »)
En cas de nécessité, le chemin est indiqué dans la section « chemin d’accès à la base de données »
Cliquer sur enregistrer
Via l’EMS
En utilisant la commande suivante :
Set-MailboxDatabase -Identity «nom_par_défaut_de_la_BDD» -Name «nouveau_nom_de_la_BDD»Exemple :
Set-MailboxDatabase -Identity «Mailbox Database 0102030405» -Name DB05Avant renommage :
Après renommage :
¶ 2 – Présentation du déplacement de base de données
Le déplacement est généralement utilisé pour déplacer la base de données par défaut du serveur.
Pour effectuer un déplacement il est obligatoire d’avoir une copie de la base de données.
Cette fonction n’est absolument pas recommandée en cas d’utilisation de l’« autoreseed ».
De plus le déplacement entraine une coupure de service pour les boites aux lettres contenues dans la base de données qui sera déplacée.
Marche à suivre :
- Démontage de la base de données (si cette dernière est montée)
- Copie des fichiers vers le nouvel emplacement
- Montage de la base de données dans le nouvel emplacement
Uniquement via l’EMS :
Move-DatabasePath -Identity «nom_de_la_BDD» -EdbFilePath «nouveau_chemin_du_fichier_edb_correspondant\nom_BDD.edb» -LogFolderpath «nouveau_chemin_du_fichier_log_correspondant\nom_BDD.log»
Attention : bien peser à créer les différentes répertoires avant de lancer la commande
¶ F – Replay Lag
¶ 1 – Présentation
Le « Replay Lag » est une solution de retard de relecture, c’est-à-dire la mise en place retardée d’une copie de base de données.
Cette fonction fait partie du plan « Native Data Protection » de Exchange 2016 mais est également retrouvé dans Exchange Online (Office365). Elle permet de s’affranchir des anciens processus de sauvegardes.
Toutefois attention, cette fonction n’est PAS une sauvegarde mais une solution alternative de récupération d’urgence qui fonctionne uniquement lorsqu’un DAG est configuré.
La copie retardée de la base de données n’aura pas les mêmes informations que la base de données original à un instant T.
En effet elle aura les informations à un « instant T - X heures » ou X jours en fonctions de ce qui a été configuré.
Elle peut s’appliquer sur une ou plusieurs copies de bases de données et par défaut est désactivée.
Attention : Plus le délai de retard (Replay Lag) est grand, plus le processus de récupération de base de données sera long dû aux logs de transaction qui devront passer les informations manquante dans la base de données.
La période de délai peut aller de 0 à 14 jours (jours.heures:minutes:secondes).
Il est conseillé de configurer les valeurs de « Safety Net » (file d’attente) avec des valeurs égales ou supérieurs.
La solution de « Replay Lag » va stocker un grand nombre de journaux de transactions pour les bases de données qui sont configurées en retard. Il faut prévoir le stockage adéquat.
Lors de la configuration d’une base de données avec retard, il est impératif de désactiver le montage automatique pour ne pas entrainer une corruption logique des autres copies.
Cette solution est idéale pour se coupler avec une solution de sauvegarde ou la configuration des journaux circulaires.
¶ 2 – Configuration
Via l’EMS
- Activation d’un délai sur une copie de base de données
Set-MailboxDatabaseCopy -Identity «nom_de_la_BDD\nom_du_serveur» -ReplayLagTime «jours.heures:minutes:secondes»- Suppression de la partie activation d’une copie de base de données
Suspend-MailboxDatabaseCopy -Identity «nom_de_la_BDD\nom_du_serveur» -ActivationOnly -SuspendComment «commentaire_pour_la_suspension» - Configuration d’un délai sur la « troncation » des logs
Set-MailboxDatabaseCopy -Identity «nom_de_la_BDD\nom_du_serveur» -TrucationLagTime «jours.heures:minutes:secondes»
¶ 3 – Activation et utilisation de la copie retardée
En cas de problème sur une base de données il est possible que l’on veuille activer sa copie retardée.
Avant l’activation il est conseillé de faire une copie des données binaires (« .edb » et « .log »).
Voici les étapes :
- Suspendre la copie sur un serveur afin de l’activer par la suite sur un autre serveur (ne pas oublier de mettre un commentaire indiquant qu’elle va être activée sur un autre serveur pour plus de lisibilité)
Suspend-MailboxDatabaseCopy «nom_de_la_BDD\nom_du_serveur» -SuspendComment «Activation_de_la_copie_sur_le_serveur_XXX» -Confirm:$False- Faire une copie des fichiers binaires
- Activation de la copie (plusieurs manières possibles)
Soit faire l’activation de la copie de base de données en jouant tous les journaux non validés
Move-ActiveMailboxDatabase «nom_de_la_BDD» -ActivateOnServer «nom_du_serveur» -SkipLagChecksSoit faire l’activation avec la fonctionnalité de récupération SafetyNet
Eseutil /mh «chemin_dufichier.edb_de_la_BDD» | findstr /C:«Log Required»Déplacer les journaux qui ne sont pas compris entre la valeur « LowGeneration » et « HighGeneration ».
Arrêter le service de réplication Exchange sur le serveur avec la copie active.
Puis faire la commande suivante :
Move-ActiveMailboxDatabase «nom_de_la_BDD» -ActivateOnServer «nom_du_serveur» -MountDialOverride Besteffort -SkipActiveCopyChecks -SkipClientExperienceChecks -SkipHealthChecks -SkipLagChecksSoit faire l’activation en jouant les journaux d’un moment spécifique
Déterminer les fichiers journaux à relire impérativement dans la base de données afin de satisfaire aux besoins de la récupération en se basant sur l’heure et la date des fichiers journaux.
Tous les fichiers journaux créés par la suite devront être déplacés dans un répertoire jusqu’à ce que le processus de récupération soit terminé et que les fichiers journaux ne soient plus nécessaires.
Supprimer le fichier point de contrôle (« .chk ») de la base de données
Eseutil.exe /r eXX /aUne fois la relecture des journaux terminée, la base de données se trouvera dans un état d’arrêt et pourra être copiée puis utilisée dans le cadre d’une récupération
Resume-MailboxDatabaseCopy -Identity «nom_de_la_BDD\nom_du_serveur»¶ G – Mise en maintenance
¶ 1 – Présentation
La procédure de mise en maintenance est généralement utilisée dans un environnement DAG.
Elle permet d’isoler proprement un serveur pour y effectuer des opérations de maintenance, permettant de prévenir toute utilisation non souhaitée de ce serveur et la perturbation utilisateur :
- Prévenir le point de montage automatique des bases de données par Active Manager, manuellement ou par scripts
- Prévenir la remise de message dans les files d’attentes
- Prévenir les connexions clients
Exemple de maintenances :
- Mise à jour système
- Mise à jour matériel
- Cumulatives Update
- Etc.
¶ 2 – Les bonnes pratiques
- Rediriger les connexions des clients vers d’autres serveurs
- Avoir des sauvegardes valides ou que les membres du DAG possèdent des copies de bases de données en bonnes santé.
- Effectuer l’opération en dehors des heures de production
- Mettre en maintenance le moins de serveurs d’un DAG possible en même temps
- Valider le bon fonctionnement du serveur avant la sortie pour maintenance
- Répartir les bases de données actives après la remise en production
¶ 3 – Procédure de mise en maintenance
Uniquement via l’EMS
- Mise en maintenance du service de transport sur le serveur (il sera en statut « draining » et non pas désactivé. Ça sera utile pour transférer les « Queues »)
Set-ServerComponentState «nom_du_serveur» -Component HubTransport -State Draining -Requester Maintenance- Redirection des emails des files d’attentes vers un autre serveur
Redirect-Message -Server «nom_du_serveur» -Target «FQDN_du_serveur_qui_aura_les_mails»- Suspendre le serveur dans le DAG
Suspend-ClusterNode -Name «nom_du_serveur»- Arrêt de l’activation automatique des BDD et déplacement des bases de données actives du serveur de manière automatique vers d’autres serveurs
Set-MailboxServer «nom_du_serveur» -DatabaseCopyActivationDisabledAndMoveNow $True- Mettre en maintenance la partie activation des copies de BDD sur le serveur
Set-mailboxServer «nom_du_serveur» -DatabaseCopyAutoActivationPolicy Blocked- Contrôle les copies sur le serveur et vérification des BDD qui sont montées
Get-MailboxDatabaseCopyStatus -Server «nom_du_serveur» | Where {$._Status -eq «Mounted»}- Mise en maintenance du serveur lui-même au niveau Exchange
Set-ServerComponentState «nom_du_serveur» -Component ServerWideOffline -State Inactive -Request Maintenance¶ 4 – Procédure de sortie de maintenance
Uniquement via l’EMS
- Réactivation du serveur lui-même au niveau Exchange
Set-ServerComponentState «nom_du_serveur» -Component ServerWideOffline -State Active -Request Maintenance- Réactiver le serveur dans le DAG
Resume-ClusterNode -Name «nom_du_serveur»- Démarrage de l’activation automatique des BDD et arrêt du déplacement des bases de données actives du serveur de manière automatique vers d’autres serveurs
Set-MailboxServer «nom_du_serveur» -DatabaseCopyActivationDisabledAndMoveNow $False- Réactivation de la police des copies de base de données (pour l’exemple : Unrestricted)
Set-mailboxServer «nom_du_serveur» -DatabaseCopyAutoActivationPolicy Unrestricted- Réactivation du service de transport sur le serveur
Set-ServerComponentState «nom_du_serveur» -Component HubTransport -State Active -Requester Maintenance- Remettre des copies de bases de données automatiquement sur le serveur via le script disponible dans les sources Exchange
%ExchangeInstallPath%\Scripts\RedistributeActiveDatabase.ps1 -DagName «nom_du_DAG» -ShowDatabase DistributionByServer | ft- Remettre des copies de bases de données par ordre de préférence d’activation sur le serveur via le script disponible dans les sources Exchange
%ExchangeInstallPath%\Scripts\RedistributeActiveDatabase.ps1 -DagName «nom_du_DAG» -BalanceDbsBy ActivationPreference¶ H – Diagnostique
¶ 1 – Exemples de scénarios
- Files d’attentes qui se remplissent
- Des problèmes sur l’état des copies de bases de données
- Des problèmes de connexions des clients
- Des copies de bases de données qui bougent de serveurs toutes seules
¶ 2 – Quoi contrôler
- Les files d’attentes (messages d’erreurs, etc.)
En filtrant sur les erreurs :
Il est également possible de vérifier les listes d’attentes via l’outil « Exchange Toolbox »
- La partie réseau des serveurs du DAG
Vérification des cartes réseaux (leur activation, les configurations réseaux, etc.)
Vérification du DAG Network pour voir si tout est bien configuré et actif
- Les journaux d’événements Windows
- L’état de santé et la répartition des copies de bases de données
- L’état de santé et la charge des serveurs
Via le gestionnaire de service et la vérification des ressources.
Mais également consulter l’état de santé du serveur avec la commande suivante :
- Les services
- Les journaux Exchange
Directement dans les répertoires de Exchange
¶ I – Réparation d’une copie de base de données
¶ 1 – Présentation
Il est possible que dans certaines situations les copies d’une base de données ne soient pas complètement saines voir totalement en erreur pour des raisons de stockage, réplication, de services ou autres.
Attention : avant de commencer les manipulations de réparation il est impératif de disposer de sauvegardes et/ou de copies saines de la base de données
¶ 2 – En pratique
Pour contrôler l’état des copies de bases de données sur un serveur il faut utiliser la commande suivante
Get-MailboxDatabaseCopyStatus -Server «nom_du_serveur»En cas de problème de stockage :
- Remplacer le stockage et le reconfigurer dans Windows.
- Mettre à jour la copie d’une base de données en la copiant depuis un autre serveur qui dispose d’une copie saine
Update-MailboxDatabaseCopy -Identity «nom_de_la_BDD\nom_du_serveur» -SourceServer «nom_du_serveur»En cas de problème d’index :
Mettre le serveur en maintenance (client pas exchange) et faire la commande suivante
Update-MailboxDatabaseCopy -Identity «nom_de_la_BDD\nom_du_serveur» -CatalogOnlySi cela ne fonctionne pas il faudra alors faire la démarche suivante
- Arrêter les services « Microsoft Exchange Search » et « Microsoft Exchange Search Host Controller » puis les mettre en désactivé
- Supprimer le dossier xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxx.x.single dans les fichiers de la base de données. Il devrait être au même emplacement que le « .edb »
- Démarrer les services « Microsoft Exchange Search » et « Microsoft Exchange Search Host Controller » puis les mettre en automatique
Autre problème
Il est possible de supprimer les données sur le serveur puis de les récupérer sur un autre serveur possédant d’une copie saine.
Faire très attention avec cette commande car elle efface tout de la base de données sur un serveur ciblé.
Update-MailboxDatabaseCopy -Identity «nom_de_la_BDD\nom_du_serveur» -SourceServer «nom_du_serveur» -DeleteExistingFiles