Switchovers et basculements

S’applique à : Exchange Server 2013 SP1

Les permutations et les basculements sont deux formes de panne rencontrées dans Microsoft
Exchange Server 2013.

 Une permutation est une panne planifiée d’une base de données ou d’un serveur qui est
initiée explicitement par une cmdlet ou par le système de disponibilité géré dans
Exchange 2013. Les permutations sont généralement effectuées pour préparer une
opération de maintenance. Les permutations impliquent le déplacement de la copie de
base de données de boîtes aux lettres active vers un autre serveur du groupe de
disponibilité de base de données (DAG). Si aucune cible saine n’est trouvée pendant
une permutation, les administrateurs reçoivent une erreur et la base de données de boîte
aux lettres reste en exécution ou montée.
 Un basculement désigne des événements inattendus qui provoquent l’indisponibilité des
services, des données ou des deux. Un basculement suppose que la défaillance du
système soit automatiquement réparée en activant une copie de base de données de
boîtes aux lettres passive pour la convertir en copie active. Si aucune cible saine n’est
trouvée pendant un basculement, la base de données de boîte aux lettres est démontée.

Exchange 2013 est conçu pour gérer les basculements et les basculements.

Souhaitez-vous rechercher des tâches de gestion liées à la haute disponibilité et la résilience

de site ? Consultez la rubrique Gestion de la haute disponibilité et de la résilience de site.

Permutations
Il existe trois types de permutation dans Exchange 2013 :

 Permutation de base de données

 Permutation de serveur
 Permutation de centre de données

Permutation de base de données

Une permutation de base de données est le processus par lequel une base de données active
individuelle est permutée vers une autre copie de base de données (copie passive), qui est
ensuite définie comme nouvelle copie de base de données active. Les permutations de base de
données peuvent se produire dans un centre de données et entre plusieurs centres de données.
Un basculement de base de données peut être effectué à l’aide du Centre d’administration
Exchange (EAC) ou de l’interpréteur de commandes. Quelle que soit l'interface utilisée, le
processus de permutation est le suivant :

1. L'administrateur initie une permutation de base de données pour déplacer la copie de

base de données de boîtes aux lettres active vers un autre serveur.
2. Le client utilisé pour la tâche lance un appel de procédure distante au service de
réplication Microsoft Exchange sur un membre du DAG.
 3. Si le membre du DAG ne détient pas le rôle de gestionnaire Active Manager principal
(PAM), il redirige la tâche vers le rôle PAM.
4. La tâche émet un appel de procédure distante (RPC) au service de réplication Microsoft
Exchange sur le serveur qui détient le rôle PAM.
5. Le Gestionnaire Active Manager principal lit et met à jour les informations sur
l'emplacement de la base de données qui sont stockées dans la base de données du
cluster pour le DAG.
6. Le Gestionnaire Active Manager principal contacte le service de réplication Microsoft
Exchange sur le membre du DAG dont la copie passive est activée en tant que nouvelle
copie de base de données de boîtes aux lettres active.
7. Le service de réplication Microsoft Exchange du serveur cible interroge les services de
réplication Microsoft Exchange sur tous les autres membres du DAG pour déterminer la
source de journal optimale pour la copie de base de données.
8. La base de données est démontée du serveur actuel et le service de réplication Microsoft
Exchange du serveur cible copie les journaux restants vers ce dernier.
9. Le service de réplication Microsoft Exchange du serveur cible sollicite le montage d'une
base de données.
10. Le service de banque d'informations Microsoft Exchange sur le serveur cible relit les
fichiers journaux et monte la base de données.
11. Tous les codes d'erreur sont renvoyés vers le service de réplication Microsoft Exchange
du serveur cible.
12. Le Gestionnaire Active Manager principal met à jour les informations sur l'état de la
copie de base de données dans la base de données du cluster pour le DAG.
13. Tous les codes d'erreur sont renvoyés par le service de réplication Microsoft Exchange
du serveur cible vers le service de réplication Microsoft Exchange du Gestionnaire
Active Manager principal.
14. Le service de réplication Microsoft Exchange du Gestionnaire Active Manager principal
renvoie toutes les erreurs vers l'interface d'administration où la tâche a été appelée.
15. Remote PowerShell renvoie les résultats de l'opération vers l'interface d'administration
appelante.

Pour connaître la procédure détaillée d'exécution d'une permutation de base de données,

consultez la rubrique Activer une copie de la base de données de boîtes aux lettres.

Permutation de serveur
Une permutation de serveur est le processus par lequel toutes les bases de données actives sur
un membre du DAG sont activées sur un ou plusieurs membres du DAG. Comme pour la
permutation de base de données, une permutation de serveur peut se produire tant au sein d’un
centre de données qu’entre plusieurs centres de données, et peut être lancée par le Centre
d’administration Exchange ou l’environnement de ligne de commande Exchange
Management Shell. Quelle que soit l’interface utilisée, le processus de permutation de serveur
est le suivant :

1. L'administrateur initie la permutation d'un serveur pour déplacer toutes les copies de
base de données de boîtes aux lettres actives vers un ou plusieurs autres serveurs.
2. L'opération est constituée des mêmes étapes que celles décrites plus haut dans cette
rubrique pour les permutations de base de données (étapes 2 à 4), pour chacune des
bases de données actives sur le serveur actuel.
 3. Le Gestionnaire Active Manager principal lit et met à jour les informations sur
l'emplacement de la base de données qui sont stockées dans la base de données du
cluster pour le DAG.
4. Il contacte le service de réplication Microsoft Exchange de chaque membre du DAG sur
lequel une copie passive est activée.
5. Le service de réplication Microsoft Exchange des serveurs cible interroge les services
de réplication Microsoft Exchange de tous les autres membres du DAG pour déterminer
la source de journal optimale pour la copie de base de données.
6. La base de données est démontée du serveur actuel et le service de réplication Microsoft
Exchange de chaque serveur cible copie les journaux restants.
7. Le service de réplication Microsoft Exchange de chaque serveur cible sollicite le
montage d'une base de données.
8. Le service de banque d'informations Microsoft Exchange sur chaque serveur cible relit
les fichiers journaux et monte la base de données.
9. Tous les codes d'erreur sont renvoyés vers le service de réplication Microsoft Exchange
du serveur cible.
10. Le Gestionnaire Active Manager principal met à jour les informations sur l'état de la
copie de base de données dans la base de données du cluster pour le DAG.
11. Tous les codes d'erreur sont renvoyés par le service de réplication Microsoft Exchange
du serveur cible vers le service de réplication Microsoft Exchange du Gestionnaire
Active Manager principal.
12. Le service de réplication Microsoft Exchange du Gestionnaire Active Manager principal
renvoie toutes les erreurs vers l'interface d'administration où la tâche a été appelée.
13. Remote PowerShell renvoie les résultats de l'opération vers l'interface d'administration
appelante.

Pour connaître la procédure détaillée d'exécution d'une permutation de serveur, consultez la

rubrique Effectuer un basculement de serveur.

Permutation de centre de données

Dans une configuration de résilience de site, la récupération automatique suite à une
défaillance au niveau du site peut se produire dans un DAG, ce qui permet au système de
messagerie de conserver un état fonctionnel. Cette configuration nécessite au moins trois
emplacements, car elle nécessite le déploiement de membres du DAG dans deux
emplacements et le déploiement du serveur témoin du DAG dans un troisième emplacement.

Si vous n’avez pas trois emplacements, ou même si vous en avez trois, mais que vous
souhaitez contrôler les actions de récupération au niveau du centre de données, vous pouvez
configurer un DAG pour une récupération manuelle en cas d’échec au niveau du site. Dans ce
cas, vous devez exécuter un processus appelé permutation de centre de données. Comme dans
de nombreux scénarios de récupération d’urgence, la planification et la préparation
préliminaires d’une permutation de centre de données permettent de simplifier le processus de
récupération et de réduire la durée de la panne.

En raison des nombreuses modifications architecturales apportées à Exchange 2013,

notamment la consolidation des rôles serveur, il est plus facile d’effectuer un basculement de
centre de données dans Exchange 2013 que dans Exchange 2010. Pour obtenir des
instructions détaillées sur les étapes d'exécution d'une permutation de centre de données,
voir Switchovers de centre de données.
Basculements
Le basculement est un processus d’activation automatique qui peut se produire au niveau de la
base de données, du serveur ou du centre de données. Les basculements ont lieu suite à la
défaillance d’une base de données spécifique (perte de stockage isolé, par exemple), d’un
serveur complet (défaut de la carte mère ou coupure de courant, par exemple) ou d’un site
complet (perte de tous les membres du DAG d’un site, par exemple).

Les DGD et les copies de base de données de boîte aux lettres fournissent une redondance
complète et une récupération rapide des données et des services qui fournissent l’accès aux
données. Le tableau suivant répertorie les actions de récupération attendues pour différents
échecs. Certains échecs nécessitent que l’administrateur lance la récupération, et d’autres
défaillances sont gérées automatiquement par le système.

Description Activation Action de État lors État lors Actions de Commentai

automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
Erreur Brève Correction Permutati Échec Reconstruct Il existe
logicielle de la interruption automatiqu on ion RAID, d'autres
base de données possible. e d'une manuelle, réparation codes
Extensible page basculem de la base d'erreur
Storage Engine Basculemen incorrecte. ent de données logicielle de
(ESE) : Les t automatiq et de la base de
lecteurs de automatiqu ue ou copie de données.
stockage de la e possible. réparation base de
base de données en ligne. données, N'inclut pas
renvoient des restauration les erreurs
erreurs lors de et exécution de bloc du
certaines de la système de
opérations de récupératio fichiers
lecture (par n, puis NTFS.
exemple, erreur correction
-1018). de la page Si une
ou opération de
correction basculement
de la page à ou de
partir de la permutation
copie. est
effectuée, le
serveur hôte
est mis à
jour.
Erreur de base Brève Reconstruc Démonté Failed La Le terme «
de données interruption tion s’il ne reconstructi erreur
« semi- pendant le automatiqu peut pas on RAID d'écriture
logicielle » ES basculemen e du être peut semi-
E : Les lecteurs t volume/dis récupéré. remédier au logicielle
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
de stockage de automatiqu que après problème. ESE »
la base de e. un éventuel signifie que
données remplacem Copie et certaines
renvoient des ent du réparation, opérations
erreurs lors de lecteur. restauration d'écriture
certaines et exécution aboutissent.
opérations de la
d’écriture. récupératio N'inclut pas
n, ou une erreur
reconstructi de bloc
on du NTFS.
volume/disq
ue après un
éventuel
remplaceme
nt.
Erreur de Brève Reconstruc Démonté Failed La Le terme «
journal « semi- interruption tion s’il ne reconstructi erreur de
logicielle » ESE pendant le automatiqu peut pas on RAID lecture/écrit
: Les lecteurs basculemen e du être peut ure semi-
de stockage des t volume/dis récupéré. remédier au logicielle
données du automatiqu que après problème. ESE »
journal e. un éventuel signifie que
renvoient des remplacem Copie et certaines
erreurs non ent du réparation, opérations
résolues lors de lecteur. restauration de
certaines et exécution lecture/écrit
opérations de de la ure
lecture ou récupératio aboutissent.
d'écriture. n, ou
reconstructi En cas
on du d'échec de la
volume/disq base de
ue après un données, la
éventuel récupération
remplaceme automatique
nt. se produira
avant le
début du
traitement de
la
récupération
des données
du journal.
Erreur Brève Aucun. Démonté Failed Remédiez Cette erreur
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
logicielle ou interruption s’il ne au problème peut
épuisement des pendant le peut pas de ressource dissimuler
ressources basculemen être sous-jacent. d'autres
ESE : Erreur t récupéré. problèmes.
d'interruption automatiqu
de l'instance par e.
ESE (par
exemple, ID
d'événement
1022,
profondeur
excessive du
point de
contrôle).
Erreurs de bloc Brève Volume Démonté Failed La Cet
NTFS : Les interruption reconstruit s’il ne reconstructi événement
lecteurs de pendant le après le peut pas on RAID est plus
stockage de la basculemen remplacem être peut susceptible
base de données t ent récupéré. remédier au de se
ou des journaux automatiqu possible du problème. produire
détectent une e. lecteur. Les lorsque
erreur de utilitaires RAID n’est
lecture ou NTFS pas utilisé.
d'écriture sur peuvent Si cet
une structure de résoudre les événement a
contrôle NTFS. problèmes un impact
NTFS. Une sur le
récupératio volume de
n Exchange journaux
peut actif,
s'avérer certains
nécessaire. fichiers
journaux
récents sont
perdus.

N'inclut pas
les erreurs
automatique
ment
résolues par
NTFS ni sa
pile
logicielle ou
matérielle
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
sous-jacente.
Échec de la Brève Reformata Démonté Failed Remplacem Non
base de données interruption ge ou s’il ne ent du applicable.
ou du lecteur de pendant le remplacem peut pas lecteur suivi
journal : un basculemen ent du être d'une
lecteur stockant t lecteur, récupéré. éventuelle
la base de automatiqu suivi d'une reconstructi
données ou les e. reconstruct on RAID.
journaux a ion du
échoué et est volume Remplacem
inaccessible. complet. ent du
lecteur suivi
d'une
reconstructi
on du
volume
complet.

Reconstruct
ion du
volume
complet.
Échec de la Brève Reformata Démonté Failed Remplacem Non
base de données interruption ge ou s’il ne ent du applicable.
ou du volume pendant le remplacem peut pas lecteur suivi
de journal : le basculemen ent du être d'une
volume échoue t lecteur. récupéré. éventuelle
en raison de automatiqu reconstructi
problèmes de e. on RAID.
volume NTFS
ou de niveau Remplacem
inférieur. ent du
lecteur suivi
d'une
reconstructi
on du
volume
complet.

Reconstruct
ion du
volume
complet.
Espace du Basculemen Aucun. Démontée Failed Exécution Non
volume de base t . de applicable.
Description Activation Action de État lorsÉtat lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatioréparati
ue n : Actifon :
Passif
de données ou automatiqu sauvegardes
de journal e si une complètes
insuffisant : autre copie ou
L'espace du ne se trouve incrémentie
système de pas dans un lles,
fichiers NTFS, état suppression
ainsi que des similaire. manuelle
fichiers de base des
de données ou journaux,
journaux est attente de
saturé. l'expiration
du délai,
reprise de la
copie de la
base de
donnés ou
réparation
de la copie
de base de
données
défaillante.
L'administrateu Si le Aucun. Démontée Non L'administr Non
r démonte la basculemen . applicabl ateur applicable.
base de données t e corrige
incorrecte. automatiqu l'erreur.
e n'est pas
bloqué par
l'administra
teur, une
brève
interruption
se produira.

Si le
basculemen
t
automatiqu
e est évité,
une panne
se produira
jusqu'à ce
que la base
de données
soit montée.
L'administrateu Selon la Aucun. Non Suspendu L'administr Non
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
r suspend la configuratio applicable ateur applicable.
copie de base n et la copie . corrige
de données affectée, la l'erreur.
incorrecte. récupératio
n
automatiqu
e peut être
évitée.
L'administrateu Si le Aucun. Démontée Non L'administr Non
r démonte une basculemen . applicabl ateur applicable.
base de données t e termine la
pour le automatiqu tâche.
stockage, NTFS e n'est pas
ou la bloqué par
maintenance du l'administra
volume. teur, une
brève
interruption
se produira.

Si le
basculemen
t
automatiqu
e est
bloqué, une
panne se
produira
jusqu'à ce
que
l'administra
teur termine
la tâche.
L'administrateu Selon la Aucun. Non Suspende L'administr Non
r suspend une configuratio applicable d ateur applicable.
copie de base n et la copie . termine les
de données affectée, la opérations.
pour le récupératio
stockage, NTFS n
ou la automatiqu
maintenance du e peut être
volume. évitée.
L'administrateu Panne Aucun. Démontée Suspende L'administr Les copies
r démonte une nécessitant . d ateur de base de
base de données une termine les données
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
en vue de sa réparation. opérations. actives et
maintenance passives sont
hors connexion. différentes.

L'administra
teur doit
suspendre
les copies.
Défaillance du Brève Aucun. Démontée N'import Réparation Une copie
réseau de interruption . e lequel du matériel. de base de
stockage pendant le données
(SAN), du basculemen passive sera
disque ou du t à l'état dans
contrôleur de automatiqu lequel elle se
stockage. e. trouvait
avant la
panne du
système.
Maintenance du Brève Aucun. Démontée N'import Achèvemen Une copie
matériel de interruption . e lequel t des de base de
serveur. pendant le actions. données
basculemen passive sera
t à l'état dans
automatiqu lequel elle se
e (sauf en trouvait
cas de avant l'arrêt
blocage par du système.
un
administrat
eur).
Maintenance du Brève Aucun. Démontée N'import Achèvemen Une copie
logiciel de interruption . e lequel t des de base de
serveur. pendant le actions. données
basculemen passive sera
t à l'état dans
automatiqu lequel elle se
e (sauf en trouvait
cas de avant l'arrêt
blocage par du système.
un
administrat
eur).
Le service de Brève Aucun. Démontée N'import Redémarrag Non
banque interruption . e lequel e du service applicable.
d'informations pendant le de banque
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
Microsoft basculemen d'informatio
Exchange est t ns
arrêté ou a été automatiqu Microsoft
interrompu par e. Exchange.
un
administrateur.
Échec du Brève Le Démontée N'import Redémarrag Une copie
service de interruption Gestionnair . e lequel e manuel ou de base de
banque pendant le e de automatique données
d'informations basculemen contrôle du service passive sera
Microsoft t des de banque à l'état dans
Exchange ; le automatiqu services d'informatio lequel elle se
système e. redémarre ns trouvait
d'exploitation le service Microsoft avant l'échec
fonctionne de banque Exchange. du service
toujours. d'informati de banque
ons d'informatio
Microsoft ns
Exchange. Exchange.
Échec partiel du Brève Aucun. Montée et N'import Redémarrag Non
service interruption partiellem e lequel, e du applicable.
Microsoft possible ent mais peut système
Exchange pendant le fonctionn ne d'exploitatio
Information basculemen elle. fonctionn n ou du
Store ; une t er que service de
partie du automatiqu partielle banque
magasin e. ment d'informatio
Exchange cesse ns
de fonctionner, Microsoft
mais elle n’est Exchange.
pas identifiée
comme ayant
échoué.
Échec du Brève Redémarra Démontée N'import Rétablissem Non
serveur : Le interruption ge de . e lequel ent de applicable.
serveur échoue pendant le l'ordinateur l'alimentatio
pour l'une des basculemen . n,
raisons t modificatio
suivantes : automatiqu n des
 Panne de e. paramètres
courant du système
totale d'exploitatio
 Défaillan n,
ce Échec modificatio
non n des
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
résolu du paramètres
processeu du matériel,
r, de la remplaceme
carte nt du
mère ou matériel,
de la carte redémarrag
d'insertio e du
n système
 Erreur d'exploitatio
d'arrêt du n,
système réparation
d'exploita du système
tion d'exploitatio
 Le n,
système réparation
d'exploita du matériel
tion ne ou
répond résolution
plus des
 Échec problèmes
total de la de
communi communicat
cation ion.
Le DAG Panne Aucun. Démontée N'import Réparation Une copie
détecte une nécessitant . e lequel du quorum de base de
défaillance du une défaillant, données
quorum. réparation. affectation passive sera
d'un à l'état dans
nouveau lequel elle se
quorum ou trouvait
restauration avant la
du réseau panne du
responsable système.
de la
défaillance
du quorum.
Échec de Brève Aucun. Démontée N'import Résolution Non
communication interruption Tentatives . e lequel du applicable.
du réseau pendant le de problème de
MAPI : Le basculemen communica communicat
serveur n'est t tion ion en
plus disponible automatiqu répétées. remédiant
sur le réseau e ; doit être aux
MAPI. sans perte. problèmes
matériels ou
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
logiciels.
Échec de Brève Aucun. Aucun. N'import Résolution Résilience
communication interruption Tentatives e lequel du affectée par
du réseau de possible de de problème de une
réplication : Le la copie ou communica communicat défaillance.
serveur ne peut de tion ion en
pas recevoir de l'amorçage répétées. remédiant
pulsations, lorsque la aux
journaliser les charge de problèmes
copies ni travail est matériels ou
s'amorcer sur le permutée logiciels.
réseau de vers un
réplication autre
défaillant. réseau.
Échecs de Brève Aucun. Démontée N'import Résolution Au moins un
communication interruption Tentatives . e lequel du réseau
réseau pendant le de problème de fonctionne
multiples : le basculemen communica communicat toujours.
serveur ne peut t tion ion en
pas recevoir de automatiqu répétées. remédiant
pulsations, de e ; doit être aux
copies de sans perte. problèmes
journal ou matériels ou
d’amorçage via logiciels.
plusieurs
réseaux.
Échec partiel Échec non Aucun. Montée, N'import Résolution Le réseau
d'un ou de détecté ; mais e lequeldu rencontre un
plusieurs aucune problèmes problème de nombre
réseaux : Les action. de communicat d'erreurs
réseaux performan ion en anormaleme
rencontrent un ces remédiant nt élevé.
nombre possibles. aux
d'erreurs élevé. problèmes
matériels ou
logiciels.
Blocage des Aucun. Aucun. N'importe N'import Redémarrag Le blocage
systèmes lequel. e lequel e ou arrêt n'est pas
d’exploitation des détecté. Par
non détectés : le ressources conséquent,
système qui ne aucune
d’exploitation répondent action n'est
cesse de pas. effectuée.
répondre, mais
il n’est pas Certaines
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
détecté par la fonctionnalit
surveillance ou és peuvent
le clustering. être
opérationnel
les.
Le lecteur du Brève Aucun. Démontée N'import Remplacem Non
système interruption . e lequel ent du applicable.
d'exploitation pendant le lecteur et
détecte une basculemen reconstructi
erreur. t on du
automatiqu serveur ou
e. du volume
via RAID.
Espace du Brève Aucun. Démontée N'import Libération Non
lecteur de interruption . e lequel manuelle applicable.
système pendant le d'espace sur
d'exploitation basculemen le volume.
insuffisant. t
automatiqu
e.
Les lecteurs Brève Aucun. Démontée N'import Remplacem Non
contenant des interruption . e lequel ent du applicable.
fichiers binaires pendant le lecteur et
Exchange basculemen réinstallatio
rencontrent une t n de
défaillance de automatiqu l'application
volume ou de e. ou
lecteur. reconstructi
on du
volume via
RAID.
Espace du Brève Aucun. Démontée N'import Libération Non
lecteur interruption . e lequel manuelle applicable.
contenant les pendant le d'espace sur
fichiers binaires basculemen le volume.
Exchange t
insuffisant. automatiqu
e.
Nouveau Brève Aucun. Démontée Failed Suppression Les journaux
journal non interruption . des gênants ne
valide détecté : pendant le journaux doivent pas
La séquence du basculemen gênants être
journal est t après répliqués.
entravée par un automatiqu déterminati
Description Activation Action de État lors État lors Actions de Commentai
automatiq réparation de la de la réparation res
ue automatiq réparatio réparati
ue n : Actif on :
Passif
fichier existant. e ; on de la
problème source.
interprété
comme un
événement
isolé ne
concernant
pas les
autres
copies.
La Non Suppressio Non Failed Suppression Non
fonctionnalité applicable. n du applicable du journal applicable.
de réplication journal. . non valide ;
continue déplacemen
détecte un t du flux de
journal non journaux à
valide : La l'origine du
fonctionnalité problème.
de relecture
détecte un
journal
inapproprié
pendant la
copie ou la
relecture.

Basculement de base de données

Un basculement de base de données se produit lorsqu’une copie de base de données qui était
active ne peut plus l’être. Les occurrences suivantes font partie d’un basculement de base de
données :

1. La défaillance de la base de données est détectée par le service de banque

d'informations Microsoft Exchange.
2. Le service de banque d'informations Microsoft Exchange écrit les événements d'erreur
d'écriture dans le journal des événements du canal Crimson.
3. Le Gestionnaire Active Manager sur le serveur qui contient la base de données
défaillante détecte les événements d'échec.
4. Le Gestionnaire Active Manager demande l'état de la copie de base de données aux
autres serveurs qui contiennent une copie de la base de données.
5. Les autres serveurs renvoient l'état de la copie de base de données au Gestionnaire
Active Manager.
 6. Le Gestionnaire Active Manager principal initie un déplacement de la base de données
active vers un autre serveur du groupe de disponibilité de base de données en utilisant
un algorithme de sélection de la meilleure copie.
7. Le Gestionnaire Active Manager principal met l'emplacement de montage de la base de
données à jour dans la base de données du cluster pour refléter le serveur sélectionné.
8. Le Gestionnaire Active Manager principal envoie une requête au Gestionnaire Active
Manager sur le serveur sélectionné afin de devenir maître de la base de données.
9. Le Gestionnaire Active Manager sur le serveur sélectionné demande au service de
réplication Microsoft Exchange d'essayer de copier les derniers journaux du serveur
précédent et de définir l'indicateur montable pour la base de données.
10. Le service de réplication Microsoft Exchange copie les journaux du serveur qui
contenait précédemment la copie active de la base de données.
11. Le Gestionnaire Active Manager lit le nombre maximal de journaux générés dans la
base de données du cluster.
12. Le service de banque d'informations Microsoft Exchange monte la nouvelle copie de
base de données active.

Basculement de serveur
Un basculement de serveur se produit lorsque le membre du DAG ne parvient plus à réparer
le réseau MAPI, ou lorsque le service de cluster sur un membre du DAG ne peut plus
contacter les autres membres du DAG. Les occurrences suivantes font partie d’un
basculement de serveur :

1. Le service de cluster envoie une notification au Gestionnaire Active Manager principal

dans l'un des deux cas :

a. Nœud vers le bas : le serveur est accessible, mais ne peut pas participer aux
opérations DAG.
b. Réseau MAPI vers le bas : le serveur ne peut pas être contacté via le réseau MAPI
et ne peut donc pas participer aux opérations DAG.
2. Si le serveur est accessible, le Gestionnaire Active Manager principal contacte Active
Manager sur le serveur affecté et demande le démontage immédiat de toutes les bases
de données.
3. Pour chacune des copies de base de données affectées :

a. Le Gestionnaire Active Manager principal demande l'état de la copie de base

de données à tous les serveurs du DAG.
b. Le Gestionnaire Active Manager principal reçoit une réponse de tous les membres du
DAG accessibles et actifs.
c. Le Gestionnaire Active Manager principal tente de déterminer la source de journal
optimale parmi tous les serveurs chargés de répondre en demandant à chacun des
répondeurs le numéro de génération de journaux le plus récent.
d. Chacun des serveurs répond par le numéro de génération de journaux.
4. Le Gestionnaire Active Manager principal récupère l'état du catalogue d'indexation de
recherche actuel dans la base de données du cluster.
5. Selon le numéro de génération de journaux et l'intégrité du catalogue de chaque copie
de base de données, le Gestionnaire Active Manager principal sélectionne les meilleures
copies à activer.
 6. Le Gestionnaire Active Manager principal met l'emplacement monté de la base de
données à jour dans la base de données du cluster.
7. Le Gestionnaire Active Manager principal lance le basculement de la base de données
en communiquant avec Active Manager sur un ou plusieurs serveurs.
8. Le Gestionnaire Active Manager sur les serveurs sélectionné demande au service de
réplication Microsoft Exchange d'essayer de copier les derniers journaux du serveur
précédent et de définir l'indicateur montable.
9. Lorsque la base de données peut être montée, le Gestionnaire Active Manager sur les
serveurs monte les bases de données.

Pour plus d'informations sur le processus de sélection de la meilleure copie par le

Gestionnaire Active Manager, consultez la rubrique Active Manager.

Basculements de centres de données

Des modifications importantes ont été apportées dans Exchange 2013 ; elles permettent de
relever les défis d’une configuration de résilience de site Exchange 2010. Grâce à la
simplification de l'espace de noms, la consolidation des rôles serveur, la séparation de serveur
d'accès au client et de récupération de DAG (dans Exchange 2013, il n'est pas nécessaire que
l'espace de noms soit déplacé avec le DAG), et les changements concernant l'équilibrage de
charge, Exchange 2013 fournit de nouvelles options de résilience de site, telles que la
possibilité d'utiliser un seul espace de noms global. En outre, si vous avez plus de deux
emplacements dans lesquels déployer des composants de service de messagerie, Exchange
2013 permet également la configuration du service de messagerie pour le basculement
automatique en réponse aux échecs nécessitant une intervention manuelle dans Exchange
2010.

La résilience de site a été simplifiée sur le plan opérationnel dans Exchange 2013. Exchange
applique la tolérance de panne intégrée à l’espace de noms via plusieurs adresses IP,
l’équilibrage de charge (et, le cas échéant, la possibilité d’intégrer et de mettre hors service les
serveurs). L’une des modifications les plus importantes que nous avons apportées à Exchange
2013 a été d’utiliser la capacité des clients à mettre en cache plusieurs adresses IP retournées
par un serveur DNS en réponse à une demande de résolution de noms. Si l'on suppose que le
client a la capacité de mettre en cache plusieurs adresses IP (ce qui est le cas pour presque
tous les clients HTTP et puisque presque tous les protocoles d'accès au client dans Exchange
2013 sont basés sur HTTP (Outlook, Outlook Anywhere, EAS, EWS, OWA, EAC, RPS, etc.),
tous les clients HTTP pris en charge peuvent utiliser plusieurs adresses IP), le basculement est
de ce fait possible côté client. Vous pouvez configurer DNS pour remettre plusieurs adresses
IP à un client lors de la résolution de noms. Le client demande mail.contoso.com et retourne
deux adresses IP, ou quatre adresses IP, par exemple. Toutefois, de nombreuses adresses IP
que le client récupère sont utilisées de manière fiable par le client. Cette utilisation optimale
rend le client beaucoup plus performant, car si l’une des adresses IP échoue, le client a une ou
plusieurs autres adresses à laquelle tenter de se connecter. Si un client en essaie une mais
qu'elle échoue, il attend environ 20 secondes puis essaie la suivante dans la liste. Ainsi, si
vous perdez la connectivité à votre tableau de serveur d'accès au client (CAS) principal, et que
vous disposez d'une deuxième adresse IP publiée pour un deuxième tableau CAS, la
récupération pour les clients se fait automatiquement (et en 21 secondes environ).

Les clients HTTP modernes (systèmes d’exploitation et navigateurs web qui ont dix ans ou
moins) fonctionnent automatiquement avec cette redondance. La pile HTTP peut accepter
plusieurs adresses IP pour un nom de domaine complet et, si la première adresse IP échoue
difficilement (par exemple, impossible de se connecter), elle essaie l’adresse IP suivante dans
la liste. En cas de défaillance réversible (connexion perdue après l’établissement de la session,
en raison d’une défaillance intermittente dans le service où, par exemple, un appareil
supprime des paquets et doit être retiré du service), l’utilisateur peut avoir besoin d’actualiser
son navigateur.

Si la configuration est correcte, le basculement peut s'effectuer au niveau du client et les

clients sont automatiquement redirigés vers un second centre de données comportant des
serveurs d'accès au client en fonctionnement, et ces serveurs d'accès au client en
fonctionnement envoient par proxy la communication vers le serveur de boîtes aux lettres de
l'utilisateur, qui n'est pas touché par la panne (car vous ne procédez à aucune permutation).
Au lieu de travailler à la récupération du service, le service se récupère et vous pouvez vous
concentrer sur la résolution du problème principal (par exemple, en remplaçant un équilibreur
de charge défaillant).

Étant donné que vous pouvez basculer l’espace de noms entre les centres de données, tout ce
qui est nécessaire pour obtenir un basculement de centre de données est un mécanisme de
basculement du rôle boîte aux lettres entre les centres de données. Pour obtenir le basculement
automatique pour le DAG, vous concevez une solution où le DAG est réparti uniformément
entre deux centres de données, puis placez le serveur témoin dans un troisième emplacement
afin qu’il puisse être arbitré par les membres DAG dans l’un ou l’autre centre de données,
quel que soit l’état du réseau entre les centres de données qui contiennent les membres DAG.
L'essentiel est que le troisième emplacement soit isolé des défaillances réseau susceptibles de
se produire dans les emplacements contenant les membres du DAG.

Si vous n'avez que deux centres de données et que vous souhaitez pouvoir configurer un
basculement automatique, vous pouvez utiliser Microsoft Azure comme troisième
emplacement. Vous devez créer un réseau virtuel Azure et le connecter à vos deux centres de
données à l'aide d'un VPN multi-points. Vous pourrez ensuite placer votre serveur témoin sur
une machine virtuelle Microsoft Azure. Pour plus d'informations,

voir Utilisation d'une machine virtuelle Microsoft Azure comme serveur témoin du groupe de
disponibilité de base de données (DAG).
Gestion de la haute disponibilité et de
la résilience de site dans Exchange
Server
Article

 11/02/2022
 4 minutes de lecture
 2 contributeurs
Commentaires

Une fois que vous avez construit, validé et déployé une solution de haute
disponibilité ou de résilience de site Microsoft Exchange Server, la solution passe de
la phase de déploiement à la phase opérationnelle du cycle de vie global de la
solution. Toutes les tâches sont liées à l'un des domaines suivants : groupes de
disponibilité de base de données (DAG), copies de base de données de boîte aux
lettres, réalisation de la surveillance proactive, et gestion des switchovers et des
basculements.

Gestion des groupes de disponibilité de base de

données
Les tâches de gestion des opérations associées aux DAG sont les suivantes :

 Création d’un ou de plusieurs DAG : la création d’un DAG est généralement

une procédure unique effectuée lors de la phase de déploiement du cycle de vie
de la solution. Il est cependant possible de créer des groupes de disponibilité de
base de données (DAG) pendant la phase opérationnelle, par exemple :
o Le DAG est configuré pour un mode de réplication tiers mais vous souhaitez
revenir à la réplication continue. Vous ne pouvez pas faire revenir un DAG à
la réplication continue, vous devez en créer un autre.
o Vous disposez de serveurs dans plusieurs domaines. Tous les membres d'un
même DAG doivent également être membres du même domaine.
 Gestion de l’appartenance au DAG : la gestion des membres du DAG est une
tâche rare généralement effectuée pendant la phase de déploiement du cycle
de vie de la solution. Toutefois, en raison de la flexibilité offerte par le
déploiement incrémentiel, la gestion de l'appartenance au DAG peut aussi avoir
lieu tout au long du cycle de vie de la solution.
 Configuration des propriétés du DAG : chaque DAG possède différentes
propriétés qui peuvent être configurées selon les besoins. Ces propriétés sont
les suivantes :
o Serveur témoin et répertoire témoin : le serveur témoin est un serveur en
dehors du DAG qui agit comme un votant de quorum lorsque le DAG
contient un nombre de membres even. Le répertoire témoin est créé et
partagé sur le serveur témoin afin d'être utilisé par le système lors de la
gestion du quorum.
o Adresses IP : chaque DAG aura une ou plusieurs adresses IPv4, et
éventuellement une ou plusieurs adresses IPv6. Les adresses IP attribuées au
DAG sont utilisées par le cluster sous-jacent du DAG. Le nombre d'adresses
IPv4 affectées au DAG est égal au nombre de sous-réseaux qui incluent le
réseau MAPI utilisé par le DAG. Vous pouvez configurer le DAG pour qu'il
utilise des adresses IP statiques ou pour qu'il obtienne des adresses
automatiquement à l'aide du protocole DHCP.
o Mode de coordination de l’activation du centre de données : le mode de
coordination de l’activation du centre de données est un paramètre de
propriété sur un DAG conçu pour empêcher les conditions split-brain au
niveau de la base de données, dans un scénario dans lequel vous restitiez le
service dans un centre de données principal après un basculement de centre
de données. Pour plus d'informations sur le mode de coordination de
l'activation du centre de données, voir l'article Mode de coordination de
l'activation du centre de données.
o Serveur témoin alternatif et répertoire témoin alternatif : le serveur témoin
de remplacement et le répertoire témoin alternatif sont des valeurs que vous
pouvez préconfigurer dans le cadre du processus de planification d’un
basculement de centre de données. Ces valeurs font référence au serveur
témoin et au répertoire témoin qui sera utilisé lorsqu'un basculement de
centre de données a eu lieu.
o Port de réplication : par défaut, tous les DGS utilisent le port TCP 64327
pour la réplication continue. Vous pouvez modifier le DAG pour utiliser un
port TCP différent pour la réplication à l’aide du paramètre ReplicationPort de
la cmdlet Set-DatabaseAvailabilityGroup .
o Découverte de réseau : vous pouvez forcer le DAG à découvrir les réseaux et
les interfaces réseau. Cette opération permet d'ajouter ou de supprimer des
réseaux ou d'introduire de nouveaux sous-réseaux. Vous pouvez forcer la
découverte de tous les réseaux DAG à l’aide du
paramètre DiscoverNetworks de la cmdlet Set-DatabaseAvailabilityGroup .
o Compression réseau : par défaut, les DAG utilisent la compression
uniquement entre les réseaux du DAG sur différents sous-réseaux. Vous
pouvez activer la compression pour tous les réseaux du DAG ou pour des
opérations d'amorçage uniquement, ou désactiver la compression pour tous
les réseaux du DAG.
o Chiffrement du réseau : par défaut, les DAG utilisent le chiffrement
uniquement entre les réseaux du DAG sur différents sous-réseaux. Vous
pouvez activer le chiffrement pour tous les réseaux du DAG ou pour des
 opérations d'amorçage uniquement, ou désactiver le chiffrement pour tous
les réseaux du DAG.
 Arrêt des membres du DAG : la solution Exchange Server haute disponibilité
est intégrée au processus Windows’arrêt. Si un administrateur ou une
application arrête un serveur Windows dans un DAG qui a une base de données
montée répliquée sur un ou plusieurs membres du DAG, le système tentera
d'activer une autre copie des bases de données montées avant de terminer le
processus d'arrêt. Toutefois, ce nouveau comportement ne garantit pas que
toutes les bases de données sur le serveur en cours de fermeture bénéficieront
d'une activation sans perte. C'est pourquoi il est préférable d'effectuer un
basculement de serveur avant d'arrêter un serveur membre d'un DAG.

Pour obtenir la procédure détaillée de création d'un DAG, voir Créer un groupe de

disponibilité de base de données. Pour obtenir la procédure détaillée de
configuration des DAG et des propriétés de DAG, voir l'article Configuration des
propriétés du groupe de disponibilité de base de données. Pour plus d’informations
sur chacune des tâches de gestion précédentes et sur la gestion des groupes de
disponibilité de base de données en général, voir Gérer les groupes de disponibilité
de base de données.

Gestion des copies de base de données de boîtes aux

lettres
Les tâches de gestion des opérations associées aux copies de base de données de
boîte aux lettres sont les suivantes :

 Ajout de copies de base de données de boîtes aux lettres : lorsque vous

ajoutez une copie d’une base de données de boîtes aux lettres, la réplication
continue est automatiquement activée entre la base de données existante et la
copie de la base de données.
 Configuration des propriétés de copie de base de données de boîtes aux
lettres : vous pouvez configurer diverses propriétés, telles que la stratégie
d’activation de base de données, la durée, le cas cas, du retard de relecture et
du retard de troncation, ainsi que la préférence d’activation pour la copie de
base de données.
 Suspension ou reprise d’une copie de base de données de boîtes aux lettres :
vous pouvez suspendre une copie de base de données de boîtes aux lettres en
préparation de l’amorçage ou pour d’autres formes de maintenance. Vous
pouvez également interrompre la copie de base de données de boîte aux lettres
pour l'activation uniquement. Cette configuration empêche le système d'activer
automatiquement la copie suite à une défaillance, mais permet néanmoins au
système de conserver la copie de la base de données à jour par rapport à l'envoi
des journaux et à leur relecture.
  Mise à jour d’une copie de base de données de boîtes aux lettres : la mise à
jour, également appelée amorçage , est le processus au cours duquel une copie
d’une base de données de boîtes aux lettres est ajoutée à un autre serveur de
boîtes aux lettres. Elle devient la base de données de base pour la copie. Après
le premier amorçage de la copie de la base de données de base, ce n'est que
dans de très rares circonstances que la base de données nécessitera un nouvel
amorçage.
 Activation d’une copie de base de données de boîtes aux lettres : l’activation
consiste à désigner une copie passive spécifique comme nouvelle copie active
d’une base de données de boîtes aux lettres. Ce processus est parfois
appelé switchover. Pour plus d'informations, voir « Switchovers et
basculements » plus loin dans cette rubrique.
 Suppression d’une copie de base de données de boîtes aux lettres : parfois, il
peut être nécessaire de supprimer une copie de base de données de boîtes aux
lettres. Par exemple, vous ne pouvez pas supprimer une copie de base de
données de boîtes aux lettres d'un DAG tant que toutes les copies de base de
données de boîtes aux lettres n'ont pas été supprimées du serveur. Par ailleurs,
vous devez supprimer toutes les copies d'une base de données de boîtes aux
lettres avant de modifier le chemin d'accès d'une base de données de boîtes
aux lettres.

Pour obtenir la procédure détaillée d'ajout d'une copie de base de données de boîtes
aux lettres, voir Ajout d'une copie de base de données de boîtes aux lettres. Pour
obtenir la procédure détaillée de configuration des copies de base de données de
boîtes aux lettres, voir Configurer les propriétés des copies de la base de données de
boîtes aux lettres. Pour plus d’informations sur chacune des tâches de gestion
précédentes et sur la gestion générale des copies de base de données de boîtes aux
lettres, voir Gérer les copies de base de données de boîtes aux lettres. Pour obtenir la
procédure détaillée de suppression d'une copie de base de données de boîtes aux
lettres, voir Supprimer une copie de base de données de boîtes aux lettres.

Surveillance proactive
Vérifier que vos serveurs fonctionnent correctement et que vos copies de base de
données sont saines est un objectif essentiel pour les opérations de messagerie
quotidiennes. Exchange Server inclut un certain nombre de fonctionnalités qui
peuvent être utilisées pour effectuer diverses tâches d’analyse d’état de santé pour
les DG et les copies de base de données de boîtes aux lettres, notamment :

 Get-MailboxDatabaseCopyStatus
 Test-ReplicationHealth
 Journalisation des événements du canal Crimson
Outre l'analyse du fonctionnement et de l'état, il est également essentiel de surveiller
des situations risquant de compromettre la disponibilité. Par exemple, nous vous
conseillons de surveiller la redondance de vos bases de données répliquées. Il est
essentiel d'éviter des situations dans lesquelles il ne vous reste qu'une seule copie
d'une base de données. Ce scénario doit être prioritaire et résolu le plus tôt possible.

Pour plus d’informations sur la surveillance de l’état et de l’état des groupes de

disponibilité de base de données et des copies de bases de données de boîtes aux
lettres, voir Surveiller les groupes de disponibilité de base de données.

Switchovers et basculements
Un switchover est un processus manuel par lequel un administrateur active
manuellement une ou plusieurs copies de base de données de boîtes aux lettres. Les
switchovers peuvent avoir lieu au niveau de la base de données ou du serveur et sont
généralement exécutés dans le cadre de la préparation des activités de maintenance.
La gestion des switchovers implique l'exécution de switchovers de base de données
ou de serveur selon les besoins. Par exemple, si vous devez effectuer des opérations
de maintenance sur un serveur de boîtes aux lettres de votre DAG, il est préférable
d'exécuter en premier lieu un switchover de serveur afin que ce dernier n'héberge
aucune copie active de base de données de boîtes aux lettres. Pour connaître la
procédure détaillée d'exécution d'un basculement de base de données, consultez la
rubrique Activer une copie de la base de données de boîtes aux lettres. Les
switchovers peuvent également être effectués au niveau du centre de données.

Un basculement est l'activation automatique par le système d'une ou de plusieurs

copies de base de données en réaction à une défaillance. Par exemple, la perte d'un
disque dans un environnement non-RAID déclenche un basculement de base de
données. La perte d'un réseau MAPI ou une panne d'électricité déclenche un
basculement de serveur.
Planifier la haute disponibilité et la
résilience des sites
Article

20/04/2022

13 minutes de lecture

2 contributeurs

Commentaires

Pendant la phase de planification, les architectes, administrateurs et autres intervenants sur le

système doivent identifier les impératifs de l'entreprise et de l'architecture pour le
déploiement, en particulier les exigences de haute disponibilité et de résilience de site.

Certaines configurations sont requises pour le déploiement de ces fonctionnalités. Les

configurations de matériel, de logiciel, et de réseau doivent également être remplies.

Conditions requises générales

Avant de déployer un groupe de disponibilité de base de données (DAG) et de créer des
copies de base de données de boîtes aux lettres, assurez-vous que les recommandations
suivantes à l'échelle du système sont prises en compte :

 Un serveur DNS (Domain Name System) doit être exécuté. Idéalement, le serveur DNS
doit accepter des mises à jour dynamiques. Si cela n'est pas possible, vous devez créer
un enregistrement (A) d'hôte DNS pour chaque serveur Exchange. Dans le cas contraire,
Exchange ne fonctionnera pas correctement.
 Chaque serveur de boîtes aux lettres d'un groupe de disponibilité de base de données
doit être un serveur membre du même domaine.
 L’ajout d’un serveur de boîtes aux lettres Exchange qui est également un serveur
d’annuaires à un DAG n’est pas pris en charge.
 Le nom que vous attribuez au groupe de disponibilité de base de données doit être un
nom d'ordinateur valide, disponible, unique et composé tout au plus de 15 caractères.

Configuration matérielle requise

En règle générale, aucune configuration matérielle n'est exigée pour les groupes de
disponibilité de base de données ou les copies de bases de données de boîtes aux lettres. Les
serveurs utilisés doivent répondre à toutes les exigences définies dans Exchange Server
conditions préalables.

Contraintes de stockage
Il n'y a généralement pas de contrainte de stockage requise pour les groupes de disponibilité
de base de données ou les copies de bases de données de boîtes aux lettres. Les groupes de
disponibilité de base de données ne nécessitent pas ou n'utilisent pas le stockage partagé géré
par cluster. Le stockage partagé géré par cluster est pris en charge pour une utilisation dans un
DAG uniquement lorsque le DAG est configuré pour utiliser une solution qui tire parti de
l’API de réplication tierce intégrée à Exchange Server.
Configuration logicielle requise
Chaque membre d'un DAG doit exécuter le même système d'exploitation. Exchange Server
2016 est pris en charge sur les Windows Server 2012, les Windows Server 2012 R2 et les
Windows Server 2016. Exchange Server 2019 est pris en charge sur le système d’exploitation
Windows Server 2019 et Windows Server 2022. Dans un DAG spécifique, tous les membres
doivent exécuter le même système d'exploitation pris en charge.

 Notes

La prise en charge des serveurs Windows Server 2022 a été introduite avec Exchange Server
2019 CU12 (2022H1).

En plus de respecter les conditions préalables à l’installation de Exchange Server, il existe des
exigences de système d’exploitation qui doivent être satisfaites. Les DGD utilisent Windows
technologie de clustering de basculement et, par conséquent, ils nécessitent la version
Standard ou Datacenter des Windows Server 2012, Windows Server 2012 R2, Windows
Server 2016, Windows Server 2019 ou Windows Systèmes d’exploitation Server 2022.

Configuration réseau requise

Chaque groupe de disponibilité de base de données et chacun de leurs membres doivent
remplir certaines configurations réseau spécifiques. Chaque DAG doit avoir un réseau
MAPI unique, qui est utilisé par un membre DAG pour communiquer avec d’autres serveurs
(par exemple, d’autres serveurs Exchange ou serveurs d’annuaires), et zéro ou
plusieurs réseaux de réplication, qui sont des réseaux dédiés à la copie et à l’amorçage des
journaux de transaction.

Dans les versions précédentes d'Exchange, nous recommandions l'utilisation d'au moins deux
réseaux (un réseau MAPI et un réseau de réplication) pour les groupes de disponibilité de
bases de données. Dans Exchange 2016 et Exchange 2019, plusieurs réseaux sont pris en
charge, mais notre recommandation dépend de votre topologie de réseau physique. Si les
membres de votre groupe de disponibilité de base de données exploitent plusieurs réseaux
physiques séparés physiquement les uns des autres, l'utilisation d'un réseau MAPI et d'un
réseau de réplication distincts est redondante. Si vos différents réseaux sont partiellement
séparés physiquement, mais qu'ils convergent vers un seul réseau physique (par exemple, un
lien WAN unique), il est recommandé de n'utiliser qu'un seul réseau (de préférence de type 10
Gigabit Ethernet) pour le trafic MAPI et le trafic de réplication. Cette configuration sera plus
simple non seulement pour le réseau, mais également pour le chemin d'accès réseau.

Prenez en compte les informations suivantes lors de la conception de l'infrastructure réseau de

votre groupe de disponibilité de base de données :

 Chaque membre du groupe de disponibilité de base de données doit avoir au moins une
carte réseau capable de communiquer avec tous les autres membres du groupe de
disponibilité de base de données. Si vous disposez d'un chemin d'accès réseau unique,
nous vous recommandons d'utiliser au minimum la technologie 1 Gigabit Ethernet, avec
toutefois une préférence pour le 10 Gigabit Ethernet. En outre, lorsque vous utilisez une
carte réseau unique dans chaque membre du groupe de disponibilité de base de données,
 nous vous recommandons de concevoir la solution générale tout en gardant à l'esprit la
carte et le chemin d'accès réseau unique.
 L'utilisation de deux cartes réseau dans chaque membre du groupe de disponibilité de
base de données vous procure un réseau MAPI et un réseau de réplication, et entraîne
une redondance du réseau de réplication, ainsi que les comportements de récupération
suivants :
o Un basculement de serveur aura lieu en cas de défaillance au niveau du réseau MAPI
(s'il y a des copies de base de données de boîtes aux lettres en bon état qui peuvent
être activées).
o En cas de défaillance affectant le réseau de réplication, si le réseau MAPI n’est pas
affecté par l’échec, les opérations de copie des journaux de transaction et
d’amorçage sont rétablies pour utiliser le réseau MAPI, même si la
propriété ReplicationEnabled est définie sur False sur le réseau MAPI. Lorsque le
réseau de réplication défaillant est à nouveau en bon état et prêt à poursuivre l'envoi
de journaux et les opérations d'amorçage, vous devez passer manuellement au réseau
de réplication. Pour passer de la réplication sur le réseau MAPI à un réseau de
réplication restauré, vous pouvez soit interrompre et reprendre la réplication continue
en utilisant les cmdlets Suspend-MailboxDatabaseCopy et Resume-
MailboxDatabaseCopy, soit redémarrer le service de réplication Microsoft
Exchange. Nous recommandons l'utilisation des opérations d'interruption et de
reprise pour éviter la brève interruption provoquée par le redémarrage du service de
réplication Microsoft Exchange.
 Chaque membre du groupe de disponibilité de base de données doit posséder le même
nombre de réseaux. Par exemple, si vous envisagez d'utiliser une carte réseau unique
dans un membre du groupe de disponibilité de base de données, tous les membres de ce
groupe doivent aussi utiliser une carte réseau unique.
 Chaque groupe de disponibilité de base de données ne doit avoir qu'un seul réseau
MAPI. Le réseau MAPI doit offrir une connectivité à d'autres serveurs et services
Exchange, tels que Active Directory et DNS.
 Des réseaux de réplication supplémentaires peuvent être ajoutés si nécessaire. Vous
pouvez aussi empêcher les points de défaillance uniques d'une carte réseau unique en
utilisant une collaboration de cartes réseau ou une technologie similaire. Cependant,
même l'utilisation d'une collaboration de cartes réseau n'empêche pas le réseau lui-
même d'être un point de défaillance unique. De plus, une collaboration de cartes réseau
complique inutilement le DAG.
 Chaque réseau sur chaque serveur membre du groupe de disponibilité de base de
données doit se trouver sur son propre sous-réseau. Chaque serveur du groupe de
disponibilité de base de données peut se trouver sur un autre sous-réseau, mais les
réseaux MAPI et de réplication doivent pouvoir être routés et offrir une connectivité de
manière à ce que :
o Chaque réseau de chaque serveur membre du groupe de disponibilité de base de
données soit sur son propre sous-réseau, séparé du sous-réseau utilisé par chacun des
autres réseaux sur le serveur.
o Chaque réseau MAPI de serveur membre du DAG puisse communiquer avec tout
autre réseau MAPI membre du DAG.
o Chaque réseau de réplication de serveur membre du DAG puisse communiquer avec
tout autre réseau de réplication membre du DAG.
o Aucun routage direct ne permet la transmission de signaux de pulsation du réseau de
réplication d'un serveur membre du DAG vers le réseau MAPI d'un autre membre du
 DAG, ou l'inverse, ou entre plusieurs réseaux de réplication au sein du groupe de
disponibilité de base de données.
 Quel que soit son emplacement géographique par rapport à d'autres membres du groupe
de disponibilité de base de données, chaque membre du groupe doit présenter une
latence de réseau en boucle de 500 millisecondes maximum par rapport aux autres
membres. Lorsque la latence en boucle entre deux serveurs de boîtes aux lettres
hébergeant des copies d'une base de données augmente, le potentiel de réplication non
actualisé augmente également. Quelle que soit la latence de la solution, les utilisateurs
doivent vérifier que les réseaux entre tous les membres du groupe de disponibilité de
base de données sont capables de satisfaire aux objectifs de protection et de
disponibilité des données du déploiement. Les configurations présentant des valeurs de
latence plus élevées peuvent exiger un réglage spécial des paramètres du groupe de
disponibilité de base de données, de la réplication et du réseau (tel que l'augmentation
du nombre de bases de données ou la réduction du nombre de boîtes aux lettres par base
de données) pour atteindre les objectifs escomptés.
 La configuration de latence en boucle peut ne pas être la configuration de bande
passante et de latence réseau la plus stricte pour une configuration à centres de données
multiples. Vous devez évaluer la charge totale du réseau, qui inclut l'accès au client,
Active Directory, le transport, la réplication continue et autre trafic pour déterminer la
configuration réseau nécessaire pour votre environnement.
 Les réseaux de groupes de disponibilité de base de données prennent en charge les
protocoles Internet IPv4 et IPv6. Le protocole IPv6 n'est pris en charge que lorsque le
protocole IPv4 est aussi utilisé ; un environnement exclusivement IPv6 n'est pas pris en
charge. L'utilisation d'adresses IPv6 et de plages d'adresses IP n'est prise en charge que
si les protocoles IPv6 et IPv4 sont activés sur cet ordinateur et si le réseau prend en
charge les deux versions d'adresse IP. Si Exchange Server est déployé dans cette
configuration, tous les rôles de serveur peuvent envoyer et recevoir des données à partir
d’appareils, de serveurs et de clients qui utilisent des adresses IPv6.
 APIPA (Automatic Private IP Addressing) est une fonctionnalité d'Windows qui
attribue automatiquement les adresses IP quand aucun serveur DHCP (Dynamic Host
Configuration Protocol) n'est disponible sur le réseau. Les adresses APIPA (y compris
les adresses attribuées manuellement à partir de la plage d’adresses APIPA) ne sont pas
prises en charge pour une utilisation par les D DAG ou par Exchange Server.

Conditions requises pour le nom et l’adresse IP des groupes de disponibilité de base de

données

Lors de la création, chaque groupe de disponibilité de base de données reçoit un nom unique,
et est soit affecté à une ou plusieurs adresses IP statiques soit configuré pour l’utilisation de
DHCP. Que vous utilisiez des adresses statiques ou dynamiques, toute adresse IP affectée au
groupe de disponibilité de base de données doit se trouver sur le réseau MAPI.

Chaque DAG exécuté sur Windows Server 2012 nécessite au moins une adresse IP sur le
réseau MAPI. Un groupe de disponibilité de base de données nécessite des adresses IP
supplémentaires quand le réseau MAPI est étendu sur plusieurs sous-réseaux. Les groupes de
disponibilité s’exécutant sur Windows Server 2012 R2, Windows Server 2016, Windows
Server 2019 ou Windows Server 2022 créés sans point d’accès administratif de cluster ne
nécessitent pas d’adresse IP.
L'illustration suivante représente un groupe de disponibilité de base de données dans lequel
tous les nœuds ont le réseau MAPI sur le même sous-réseau.

Groupe de disponibilité de base de données avec réseau MAPI sur le même sous-réseau

Dans cet exemple, le réseau MAPI dans chaque membre du groupe de disponibilité de base de
données est sur le sous-réseau 172.19.18. x. Par conséquent, le groupe de disponibilité de base
de données exige une adresse IP unique sur ce sous-réseau.

L'illustration suivante représente un groupe de disponibilité de base de données dont le réseau

MAPI s'étend sur deux sous-réseaux : 172.19.18. x et 172.19.19. x.

Groupe de disponibilité de base de données avec réseau MAPI sur plusieurs sous-
réseaux

Dans cet exemple, le réseau MAPI de chaque membre du groupe de disponibilité de base de
données se trouve sur un sous-réseau distinct. Par conséquent, le groupe de disponibilité de
base de données exige deux adresses IP, une pour chaque sous-réseau sur le réseau MAPI.

À chaque fois que le réseau MAPI du groupe de disponibilité de base de données est étendu
sur un sous-réseau supplémentaire, une adresse IP supplémentaire pour ce sous-réseau-là doit
être configurée pour le groupe de disponibilité de base de données. Chaque adresse IP
configurée pour le groupe de disponibilité de base de données est affectée au cluster de
basculement sous-jacent du groupe de disponibilité de base de données et utilisée par celui-ci.
Le nom du groupe de disponibilité de base de données est aussi utilisé comme nom pour le
cluster de basculement sous-jacent.

À n'importe quel moment spécifique, le cluster du groupe de disponibilité de base de données

n'utilisera qu'une des adresses IP affectées. La fonction de clustering avec basculement
Windows enregistre cette adresse IP dans le DNS quand l'adresse IP du cluster et les
ressources de nom du réseau sont mises en ligne. En plus de l'utilisation d'une adresse IP et
d'un nom de réseau, un objet nom de cluster (CNO) est créé dans Active Directory. Le nom,
l'adresse IP et le CNO du cluster sont utilisés en interne par le système pour sécuriser le
groupe de disponibilité de base de données et à des fins de communication interne. Les
administrateurs et les utilisateurs finaux n'ont pas besoin d'interface ni de connexion avec le
nom du groupe de disponibilité de base de données ni avec l'adresse IP.
 Notes

Bien que l’adresse IP et le nom du réseau du cluster soient utilisés en interne par le système, il
n’existe aucune dépendance forte dans Exchange Server que ces ressources soient
disponibles. Même si le point d’accès administratif du cluster sous-jacent (par exemple, son
adresse IP et ses ressources de nom de réseau) est hors connexion, la communication interne
se produit toujours dans le DAG à l’aide des noms de serveur membres DAG. Cependant,
nous vous recommandons de contrôler périodiquement la disponibilité de ces ressources afin
de vous assurer qu'elles ne sont pas hors ligne pendant plus de 30 jours. Si le cluster sous-
jacent est hors ligne pendant plus de 30 jours, le compte de CNO peut être invalidé par le
mécanisme de nettoyage de la mémoire dans Active Directory.

Configuration de la carte réseau pour les groupes de disponibilité de base de données

Chaque carte réseau doit être correctement configurée selon l'usage prévu. La configuration
d'une carte réseau destinée à un réseau MAPI n'est pas la même que celle d'une carte réseau
destinée à un réseau de réplication. Pour configurer correctement chaque carte réseau, vous
devez configurer l'ordre de connexion au réseau dans Windows de manière à ce que le réseau
MAPI se connecte en premier. Pour savoir comment modifier l'ordre de connexion au réseau,
consultez la rubrique relative à la modification de l'ordre des liaisons du protocole.

Configuration de la carte du réseau MAPI

Une carte réseau destinée à l’utilisation par un réseau MAPI doit être configurée comme
décrit dans le tableau suivant.

Fonctionnalités de mise en réseau Paramètres

Client pour les réseaux Microsoft Activé

Planificateur de paquets QoS Éventuellement activé

Partage de fichiers et d'imprimantes pour les réseaux Microsoft Activé

Internet Protocol Version 6 (TCP/IP v6) Activé

Internet Protocol Version 4 (TCP/IP v4) Activé

Pilote E/S Mappage de découverte de couche liaison Activé

Répondeur de découverte de couche de liaison Activé

Les propriétés TCP/IP v4 d'une carte de réseau MAPI sont configurées de la manière suivante
:

 L'adresse IP du réseau MAPI d'un membre du groupe de disponibilité de base de

données peut être affectée ou configurée manuellement pour utiliser le protocole DHCP.
Dans ce cas, nous vous recommandons d'utiliser les réservations persistantes pour
l'adresse IP du serveur.
 Le réseau MAPI utilise généralement une passerelle par défaut, bien que ce ne soit pas
obligatoire.
  Au moins une adresse de serveur DNS doit être configurée. Pour la redondance, il est
recommandé d'utiliser plusieurs serveurs DNS.
 La case Enregistrer les adresses de cette connexion dans le serveur DNS doit être
cochée.

Configuration de la carte du réseau de réplication

Une carte réseau destinée à l’utilisation par un réseau de réplication doit être configurée
comme décrit dans le tableau suivant.

Fonctionnalités de mise en réseau Paramètres

Client pour les réseaux Microsoft Désactivé

Planificateur de paquets QoS Éventuellement activé

Partage de fichiers et d'imprimantes pour les réseaux Microsoft Désactivé

Internet Protocol Version 6 (TCP/IP v6) Activé

Internet Protocol Version 4 (TCP/IP v4) Activé

Pilote E/S Mappage de découverte de couche liaison Activé

Répondeur de découverte de couche de liaison Activé

Les propriétés TCP/IP v4 d'une carte de réseau de réplication sont configurées de la manière
suivante :

 L'adresse IP du réseau de réplication d'un membre du groupe de disponibilité de base de

données peut être affectée ou configurée manuellement pour utiliser le protocole DHCP.
Dans ce cas, nous vous recommandons d'utiliser les réservations persistantes pour
l'adresse IP du serveur.
 Les réseaux de réplication n'ont généralement pas de passerelle par défaut et, si le
réseau MAPI en a une, aucun autre réseau ne doit avoir de passerelle par défaut. Le
routage du trafic réseau sur un réseau de réplication peut être configuré à l'aide de routes
persistantes et statiques au réseau correspondant sur d'autres membres du groupe de
disponibilité de base de données utilisant des adresses de passerelle qui peuvent
effectuer le routage entre les réseaux de réplication. Tout autre trafic ne correspondant
pas à cette route sera traité par la passerelle par défaut configurée sur la carte du réseau
MAPI.
 Les adresses de serveur DNS ne doivent pas être configurées.
 La case à cocher Enregistrer les adresses de cette connexion dans le serveur DNS ne
doit pas être activée.

Configuration requise pour le serveur témoin

Un serveur témoin est un serveur extérieur au groupe de disponibilité de base de données qui
sert à obtenir et maintenir le quorum quand le groupe de disponibilité de base de données a un
nombre de membres pair. Les groupes de disponibilité de base de données ayant un nombre
de membres impair n’utilisent pas de serveur témoin. Tout groupe de disponibilité de base de
données ayant un nombre de membres pair doit utiliser un serveur témoin. Le serveur témoin
peut être n'importe quel ordinateur exécutant Windows Server. Il n'est pas nécessaire que la
version du système d'exploitation Windows Server du serveur témoin corresponde au système
d'exploitation utilisé par les membres du groupe de disponibilité de base de données.

Le quorum est géré au niveau du cluster, sous le groupe de disponibilité de base de données.
Un groupe de disponibilité de base de données a le quorum quand la majorité de ses membres
sont connectés et peuvent communiquer les uns avec les autres. Cette notion de quorum est un
aspect du concept de quorum dans le clustering de basculement Windows. Parmi les aspects
liés et nécessaires au quorum dans les clusters de basculement se trouve la ressource quorum.
La ressource quorum est une ressource située dans un cluster de basculement, fournissant un
moyen d’arbitrage conduisant à l’état de cluster et aux décisions d’appartenance. La ressource
quorum fournit également un stockage permanent pour le stockage des informations de
configuration. La ressource de quorum est accompagnée du journal de quorum qui est une
base de données de configuration pour le cluster. Il contient des informations telles que les
serveurs membres du cluster, les ressources installées dans le cluster et l’état de ces ressources
(par exemple, en ligne ou hors connexion).

Il est fondamental que chaque membre du groupe de disponibilité de base de données ait une
vue cohérente de la configuration du cluster sous-jacent du groupe. Le quorum agit comme le
référentiel définitif pour toutes les informations de configuration relatives au cluster. Le
quorum est utilisé pour départager les nœuds afin d’éviter le syndrome Split-Brain. Le
syndrome Split-Brain est une situation qui se produit lorsque les membres du groupe de
disponibilité de base de données ne peuvent pas communiquer entre eux bien qu’ils soient
opérationnels. Ce syndrome est évité en exigeant toujours qu’une majorité des membres du
groupe de disponibilité de base de données (et dans le cas des groupes de disponibilité de base
de données ayant un nombre de membres pair, le serveur témoin du groupe de disponibilité de
base de données) soient disponibles et en interaction pour que le groupe de disponibilité de
base de données soit opérationnel.

Planification de résilience de site

Chaque jour, un nombre croissant d'entreprises reconnaît que l'accès à un système de
messagerie fiable et disponible est essentiel à leur réussite. Pour de nombreuses organisations,
le système de messagerie fait partie des plans de continuité d'activité et la résilience du site
doit être conçue dans leur déploiement de service de messagerie. Fondamentalement, de
nombreuses solutions de résilience de site impliquent le déploiement de matériel dans un
deuxième centre de données.

En définitive, la conception générale d'un groupe de disponibilité de base de données, y

compris le nombre de membres du groupe de disponibilité de base de données et le nombre de
copies de base de données de boîtes aux lettres, dépendra des accords de niveau du service de
récupération (SLA) de chaque organisation pour traiter divers scénarios d'échec. Pendant la
phase de planification, les architectes et administrateurs du système identifient les besoins du
déploiement, y compris les exigences de résilience de site. Ils déterminent les emplacements à
utiliser et les cibles SLA requises pour la récupération. L'accord SLA déterminera les deux
éléments spécifiques qui doivent être la base de la conception d'une solution de haute
disponibilité et de résilience de site : l'objectif de temps de récupération et l'objectif de point
de récupération. Ces deux valeurs sont mesurées en minutes. L'objectif de temps de
récupération correspond au temps nécessaire à la restauration du service. L'objectif de point
de récupération correspond à l'actualité des données après l'opération de récupération. Un
accord SLA peut aussi être défini pour restaurer le centre de données principal pour qu'il
fonctionne complètement une fois les problèmes résolus.

Les architectes et administrateurs de la solution identifieront aussi les ensembles d'utilisateurs

qui requièrent une protection de résilience de site et détermineront si la solution multi-site doit
être une configuration actif/passif ou actif/actif. Dans une configuration actif/passif, aucun
utilisateur n'est normalement hébergé dans le centre de données de secours. Dans une
configuration actif/actif, les utilisateurs sont hébergés aux deux emplacements, et un certain
pourcentage du nombre total de bases de données dans le cadre de cette solution a un
emplacement actif préféré dans un deuxième centre de données. Quand le service est
défaillant pour les utilisateurs d'un centre de données, ces utilisateurs sont activés dans l'autre
centre de données.

L'élaboration des contrats de niveau de service appropriés requiert souvent de répondre aux
questions de base suivantes :

 Quel niveau de service est requis suite à un échec du centre de données principal ?
 Les utilisateurs ont-ils besoin de leurs données ou uniquement des services de
messagerie ?
 À quelle fréquence les données sont-elles requises ?
 Combien d'utilisateurs doivent être pris en charge ?
 Comment les utilisateurs accèderont-ils à leurs données ?
 Qu'est-ce que le SLA d'activation de centre de données en mode veille ?
 Comment le service est-il ramené vers le centre de données principal ?
 Les ressources sont-elles dédiées à la solution de résilience de site ?

En répondant à ces questions, vous commencez à donner forme à une conception de résilience
de site pour votre solution de messagerie. Une exigence clé en relation avec la récupération
suite à une défaillance de site consiste à créer une solution permettant de récupérer les
données nécessaires dans un centre de données de sauvegarde hébergeant le service de
messagerie de sauvegarde.

Planification de certificat

Il n’y a pas de considération de conception spéciale ou unique pour les certificats lors du
déploiement d’un groupe de disponibilité de base de données dans un centre de données
unique. Toutefois, lorsque vous étendez un groupe de disponibilité de base de données sur
plusieurs centres de données dans une configuration de résilience de site, il y a quelques
considérations spécifiques en matière de certificats. Généralement, votre conception de
certificat dépend des clients utilisés, ainsi que des conditions des autres applications utilisant
des certificats. Certaines recommandations et meilleures pratiques doivent être observées en
ce qui concerne le type et le nombre de certificats.

Il est recommandé de réduire le nombre de certificats que vous utilisez pour vos serveurs
Exchange et d'inverser les serveurs proxy. Il est recommandé d'utiliser un certificat unique
pour tous ces points finaux de service dans chaque centre de données. Cette approche
minimise le nombre de certificats nécessaires, ce qui réduit à la fois le coût et la complexité
de la solution.
Pour les clients Outlook Anywhere, il est recommandé d'utiliser un seul certificat SAN (autre
nom d'objet) par centre de données, en incluant plusieurs noms d'hôtes dans le certificat. Pour
assurer la connectivité d'Outlook Anywhere après un basculement de base de données, de
serveur ou de centre de données, vous devez utiliser le même nom de principal pour chaque
certificat et paramétrer l'objet configuration de fournisseur OutlookActive Directory avec le
même nom de principal dans le formulaire Microsoft-Standard (msstd). Par exemple, si vous
utilisez le nom de principal de certificat mail.contoso.com, vous configurez les attributs de la
manière suivante :

PowerShellCopier
Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Certaines applications qui s’intègrent à Exchange ont des exigences de certificat spécifiques
qui peuvent nécessiter l’utilisation de certificats supplémentaires. Exchange Server peut
coexister avec Office Communications Server (OCS). OCS requiert des certificats avec des
certificats 1024 bits ou supérieurs qui utilisent le nom du serveur OCS pour le nom principal
du certificat. Étant donné que l’utilisation d’un nom de serveur OCS pour le nom principal du
certificat empêcherait Outlook n’importe où de fonctionner correctement, vous devez utiliser
un certificat supplémentaire et distinct pour l’environnement OCS.

Planification de réseau

En plus des conditions spécifiques de mise en réseau nécessaires pour chaque groupe de
disponibilité de base de données ainsi que pour chaque serveur membre d’un groupe de
disponibilité de base de données, il existe d’autres conditions et recommandations spécifiques
aux configurations de résilience de site. Comme avec tous les groupes de disponibilité de base
de données, que les membres soient déployés dans un seul ou plusieurs sites, la latence en
boucle du réseau entre les membres du groupe de disponibilité de base de données ne doit pas
dépasser 500 millisecondes. En outre, certains paramètres spécifiques de configuration sont
recommandés pour les groupes de disponibilité de base de données étendus sur plusieurs
sites :

 Les réseaux MAPI doivent être isolés des réseaux de réplication : Windows les
stratégies réseau, les stratégies de pare-feu Windows ou les listes de contrôle d’accès du
routeur doivent être utilisées pour bloquer le trafic entre le réseau MAPI et les réseaux
de réplication. Cette configuration est nécessaire pour empêcher la pulsation de réseau
inter-conversation.
 Les enregistrements DNS orientés client doivent avoir une valeur de durée de vie
(TTL) de 5 minutes : le temps d’arrêt que les clients connaissent dépend non seulement
de la rapidité à laquelle un basculement peut se produire, mais aussi de la rapidité à
laquelle la réplication DNS se produit et les clients interrogent les informations DNS
mises à jour. Enregistrements DNS pour tous les services clients Exchange, y compris
les Outlook sur le web (anciennement Outlook Web App), les Exchange ActiveSync,
les services web Exchange Outlook En tout lieu, SMTP, POP3 et IMAP4 dans les
serveurs DNS internes et externes doivent être définis avec une durée de vie de 5
minutes.
 Utilisez des itinéraires statiques pour configurer la connectivité entre les réseaux
de réplication : pour fournir une connectivité réseau entre chacune des cartes réseau de
réplication, utilisez des itinéraires statiques persistants. Ce processus consiste en une
configuration rapide et unique, effectuée sur chaque membre du groupe de disponibilité
 de base de données lors de l'utilisation d'adresses IP statiques. Si vous utilisez un
protocole DHCP pour obtenir des adresses IP pour vos réseaux de réplication, vous
pouvez aussi vous en servir pour affecter des routages statiques à la réplication et ainsi
simplifier le processus de configuration.

Planification générale de résilience de site

Outre les exigences listées ci-dessus pour la haute disponibilité, il existe d’autres
recommandations pour le déploiement de Exchange Server dans une configuration résiliente
de site (par exemple, l’extension d’un DAG sur plusieurs centres de données). Ce que vous
faites pendant la phase de planification conditionnera directement la réussite de votre solution
de résilience de site. Par exemple, une conception d'espace de noms médiocre peut entraîner
des complications avec les certificats et une configuration de certificat incorrecte peut
empêcher les utilisateurs d'accéder aux services.

Afin de minimiser le temps que prend l'activation d'un deuxième centre de données et de
permettre à celui-ci d'héberger des points finaux de service d'un centre de données défaillant,
il faut effectuer la planification de façon appropriée. Voici quelques exemples :

 Vos objectifs SLA pour la solution de résilience de site doivent être bien compris et
bien documentés.
 Les serveurs du deuxième centre de données doivent disposer d'une capacité suffisante
pour héberger la population d'utilisateurs des deux centres de données.
 Tous les services fournis dans le centre de données principal doivent être activés dans le
deuxième centre de données (à moins que le service ne soit pas inclus dans le cadre de
l'accord SLA de résilience de site). Cela inclut Active Directory, l’infrastructure réseau
(par exemple, DNS ou TCP/IP), les services de téléphonie (si la messagerie unifiée dans
Exchange 2016 est en cours d’utilisation) et l’infrastructure de site (par exemple,
l’alimentation ou le refroidissement).
 Pour que certains services puissent fonctionner à partir du centre de données défaillant,
les certificats de serveur appropriés doivent être configurés. Certains services ne
permettent pas l'instanciation (par exemple, POP3 et IMAP4) et ne permettent
l'utilisation que d'un seul certificat. Dans ces cas, soit il doit s'agir d'un certificat SAN
(autre nom d'objet) incluant plusieurs noms, soit les différents noms doivent être
suffisamment similaires pour permettre le recours à un certificat générique (à condition
que les stratégies de sécurité de l'organisation autorisent l'utilisation de certificats
génériques).
 Les services nécessaires doivent être définis dans le deuxième centre de données. Par
exemple, si le premier centre de données a trois URL SMTP différentes sur plusieurs
serveurs de transport, la configuration appropriée doit être définie dans le deuxième
centre de données afin d'activer au moins un (si ce n'est les trois) serveur(s) de transport
pour héberger la charge de travail.
 La configuration de réseau nécessaire doit être en place pour prendre en charge le
basculement de centre de données. Cela peut impliquer de veiller à ce que les
configurations d'équilibrage de charge soient en place, que le serveur DNS général soit
configuré et que la connexion Internet soit activée avec la configuration de routage
appropriée.
 La stratégie d'activation des changements du DNS nécessaires au basculement de centre
de données doit être comprise. Les changements DNS spécifiques, dont leurs
 paramètres de durée de vie, doivent être définis et documentés pour prendre en charge le
SLA en vigueur.

 Une stratégie de test de la solution doit aussi être établie et prise en compte dans
l'accord SLA. La validation périodique du déploiement représente la seule manière de
garantir que la qualité et la viabilité du déploiement ne se dégradent pas avec le temps.
Après la validation du déploiement, nous vous recommandons de documenter
explicitement la partie de la configuration affectant directement la réussite de la
solution. En outre, nous vous recommandons aussi d'améliorer vos processus de gestion
des changements liés à ces segments du déploiement.
Déploiement de la haute disponibilité
et de la résilience de site dans Exchange
Server
 Article
 23/03/2022
 7 minutes de lecture
 2 contributeurs
Commentaires

Microsoft Exchange Server utilise le concept de déploiement incrémentielle à la fois

pour la haute disponibilité et la résilience de site. Il vous suffit d’installer deux
serveurs de boîtes aux lettres Exchange ou plus en tant que serveurs autonomes, puis
de les configurer de manière incrémentielle et les bases de données de boîtes aux
lettres pour la haute disponibilité et la résilience de site, selon vos besoins.

Vue d’ensemble du processus de déploiement

Bien que les étapes réelles utilisées par chaque organisation varient légèrement, le
processus global de déploiement de Exchange Server dans une configuration
hautement disponible ou résiliente de site est généralement le même. Après avoir
réalisé les tâches de planification et de conception nécessaires à l'établissement et au
déploiement d'un groupe de disponibilité de base de données (DAG) et à la création
de copies de bases de données de boîtes aux lettres, vous pouvez également
effectuer les opérations suivantes :

1. Créer un groupe de disponibilité de base de données. Pour obtenir la procédure

détaillée, voir Créer un groupe de disponibilité de base de données. Il est
important de noter que tous les serveurs au sein d’un DAG doivent être en
cours d’exécution de la même version d’Exchange. Par exemple, vous ne pouvez
pas Exchange serveurs 2013 Exchange 2016 dans le même DAG.

2. Si nécessaire, préparer l'objet réseau de cluster (CNO). Une préparation de

l'objet réseau de cluster est nécessaire lors du déploiement d'un groupe de
disponibilité de base de données avec des serveurs de boîtes aux lettres
exécutant Windows Server 2012. Si vous déployez un DAG sans point d’accès
administratif à l’aide de serveurs de boîtes aux lettres exécutant Windows Server
2012 R2, vous n’avez pas besoin de pré-phaser un CNO. La préparation est
également obligatoire dans les environnements dans lesquels la création du
compte d'ordinateur est restreinte ou lorsque les comptes d'ordinateur sont
créés dans un conteneur autre que le conteneur d'ordinateurs par défaut. Pour
 obtenir la procédure détaillée, voir Préinstallation de l'objet nom de cluster pour
un groupe de disponibilité de base de données.

3. Ajouter au moins deux serveurs de boîtes aux lettres au groupe de disponibilité

de base de données. Pour obtenir la procédure détaillée, voir Gérer
l'appartenance au groupe de disponibilité de la base de données.

4. Configurer les propriétés du groupe de disponibilité de base de données selon

vos besoins :

5. Configurer éventuellement le chiffrement et la compression pour le groupe de

disponibilité de base de données, la réplication de port, les adresses IP du
groupe de disponibilité de base de données et d'autres propriétés relatives à ce
groupe. Pour obtenir la procédure détaillée, voir Configuration des propriétés
du groupe de disponibilité de base de données.

6. Activer le mode de coordination de l'activation du centre de données (DAC)

pour le groupe de disponibilité de base de données. Cela permet de protéger le
groupe de disponibilité de base de données contre les conditions de Split-Brain
au niveau de la base de données lors d'un switchback vers le centre de données
principal après un basculement, et active l'utilisation des cmdlets intégrées de
récupération de groupe de disponibilité de base de données. Pour plus
d'informations, consultez la rubrique Mode de coordination de l'activation du
centre de données.

7. Ajouter des copies de base de données de boîtes aux lettres entre les serveurs
de boîtes aux lettres du groupe de disponibilité de base de données. Pour
obtenir la procédure détaillée, voir Ajout d'une copie de base de données de
boîtes aux lettres.

Exemple de déploiement : Groupe de disponibilité de

base de données à quatre membres dans deux
centres de données
Cet exemple détaille la façon dont une organisation, Contoso, Ltd., configure et
déploie un DAG à quatre membres qui sera étendu à deux emplacements physiques :
État de City et City.

Infrastructure de base

Chaque emplacement contient les éléments d’infrastructure nécessaires au

fonctionnement d’une infrastructure de messagerie basée sur Exchange Server, à
savoir :
  Services d'annuaire (Active Directory ou services de domaine Active Directory
(AD DS))

 Résolution de noms DNS (Domain Name System)

 Plusieurs serveurs Exchange exécutant les services d’accès au client

 Serveurs de Exchange serveurs de boîtes aux lettres multiples

La figure suivante illustre la configuration de l'organisation Contoso.

Configuration réseau

Comme l'illustrait la figure précédente, la solution implique l'utilisation de plusieurs

sous-réseaux et de plusieurs réseaux. Chaque serveur de boîtes aux lettres du groupe
de disponibilité de base de données dispose de deux cartes réseau sur des sous-
réseaux distincts. Dans chaque serveur de boîtes aux lettres, une carte réseau sera
utilisée pour le réseau MAPI (192.168. x. x) et l'autre pour le réseau de réplication
(10.0. x. x). Seul le réseau MAPI fournit la connectivité à Active Directory, aux services
DNS et autres serveurs et clients Exchange. La carte utilisée pour le réseau de
réplication de chaque membre fournit la connectivité uniquement aux cartes du
réseau de réplication des autres membres du groupe de disponibilité de base de
données.

Le tableau suivant présente en détail les paramètres de chaque carte réseau dans
chacun des nœuds.

Nom Adresse IPv4 Masque de sous-réseau Passerelle par défaut

MBX1 (MAPI) 192.168.1.4 255.255.255.0 192.168.1.1

MBX2 (MAPI) 192.168.1.5 255.255.255.0 192.168.1.1

MBX3 (MAPI) 192.168.2.4 255.255.255.0 192.168.2.1

MBX4 (MAPI) 192.168.2.5 255.255.255.0 192.168.2.1

MBX1 (réplication) 10.0.1.4 255.255.255.0 Aucun

MBX2 (réplication) 10.0.1.5 255.255.255.0 Aucun

MBX3 (réplication) 10.0.2.4 255.255.255.0 Aucun

MBX4 (réplication) 10.0.2.5 255.255.255.0 Aucun

Comme le montrait le tableau précédent, les cartes des réseaux de réplication

n'utilisent pas de passerelles par défaut. Pour assurer la connectivité réseau entre
chacune des cartes de réseau de réplication, Contoso utilise des itinéraires statiques
permanents, configurés au moyen de l'outil Netsh.exe.

Pour configurer le routage des cartes de réseau de réplication sur MBX1 et MBX2, la
commande suivante a été exécutée sur chaque serveur.

PowerShellCopier
netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

Pour configurer le routage des cartes de réseau de réplication sur MBX3 et MBX4, la
commande suivante a été exécutée sur chaque serveur.

PowerShellCopier
netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

Les paramètres réseau supplémentaires suivants ont également été configurés :

  La case Enregistrer les adresses de cette connexion dans le système DNS est
cochée pour la carte réseau de chaque membre du groupe de disponibilité de
base de données et désactivée pour chaque carte de réseau de réplication.

 Au moins une adresse de serveur DNS est configurée pour la carte de réseau
MAPI de chaque membre de groupe de disponibilité de base de données ;
aucune adresse n'est configurée pour les cartes de réseau de réplication. À des
fins de redondance, Contoso utilise plusieurs adresses de serveur DNS pour
leurs cartes de réseau MAPI.

 Contoso n'utilise pas le Pare-feu Windows et l'a désactivé sur ses serveurs.

Lorsque les cartes réseau ont été configurées, Contoso est prêt à créer un groupe de
disponibilité de base de données et à y ajouter les serveurs de boîtes aux lettres.

Création et configuration du groupe de disponibilité de base de données

L'administrateur a décidé de créer un script d'interface de ligne de commande

Windows PowerShell qui effectue plusieurs tâches :

 Il utilise la cmdlet New-DatabaseAvailabilityGroup pour créer le groupe de

disponibilité de base de données. Étant donné que LA FONCTION SONT
considérées comme le centre de données principal, Contoso a choisi d’utiliser
un serveur témoin dans le même centre de données, à savoir MBX5.

 Il utilise la cmdlet Set-DatabaseAvailabilityGroup pour préconfigurer un serveur

témoin et un répertoire témoin de remplacement si un basculement de centre
de données s'avérait nécessaire.

 Il utilise la cmdlet Add-DatabaseAvailabilityGroupServer pour ajouter chacun

des quatre serveurs de boîtes aux lettres au groupe de disponibilité de base de
données.

 Il utilise la cmdlet Set-DatabaseAvailabilityGroup pour configurer le groupe de

disponibilité de base de données en mode DAC. Pour plus d'informations sur le
mode DAC, voir Mode de coordination de l'activation du centre de données.

Les commandes utilisées dans le script sont les suivantes :

PowerShellCopier
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer MBX5 -WitnessDirectory C:\
DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses
192.168.1.8,192.168.2.8
La commande précédente crée le DAG DAG1, configure MBX5 comme serveur
témoin, configure un répertoire témoin spécifique (C:\DAGWitness\
DAG1.contoso.com) et configure deux adresses IP pour le DAG (une pour chaque
sous-réseau sur le réseau MAPI).

PowerShellCopier
Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\
DAGWitness\DAG1.contoso.com -AlternateWitnessServer MBX10

La commande précédente configure DAG1 pour utiliser un autre serveur témoin

MBX10 et un autre répertoire témoin sur MBX10 qui utilise le même chemin d’accès
que celui configuré sur MBX5.

 Notes

L'utilisation d'un chemin d'accès identique n'est pas obligatoire. Contoso a choisi
cette option pour standardiser la configuration de son organisation.

PowerShellCopier
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX3
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX4

Les commandes précédentes ajoutent chaque serveur de boîtes aux lettres au groupe
de disponibilité de base de données, un par un. Elles installent également le
composant Clustering avec basculement Windows sur chaque serveur de boîtes aux
lettres (s'il n'est pas encore installé), créent un cluster de basculement et rattachent
chaque serveur de boîtes aux lettres au nouveau cluster.

PowerShellCopier
Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

La commande précédente active le mode DAC pour le groupe de disponibilité de

base de données.

Bases de données de boîtes aux lettres et copies de bases de données de boîtes aux
lettres

Lorsque le groupe de disponibilité de base de données a été créé et que les serveurs
de boîtes aux lettres ont été ajoutés à ce groupe, Contoso prépare la création des
bases de données de boîtes aux lettres et de leurs copies. Pour répondre aux critères
de tolérance aux pannes, Contoso prévoit de configurer chaque base de données de
boîtes aux lettres avec trois copies non retardées et une copie retardée. La copie
retardée sera configurée avec un délai de réexécution de journal de trois jours.
Cette configuration fournit au total quatre copies de chaque base de données (une
active, deux passives non retardées et une passive retardée). Contoso prévoit d'avoir
quatre bases de données actives par serveur. Par conséquent, la solution Contoso
contient 16 copies de base de données au total.

Comme l'illustre la figure suivante, Contoso adopte une approche équilibrée pour
l'agencement de ses bases de données.

Agencement des copies de bases de données pour Contoso, Ltd

Chaque serveur de boîtes aux lettres héberge une copie active de base de données
de boîtes aux lettres, deux copies passives non retardées et une copie passive
retardée. La copie retardée de chaque base de données de boîtes aux lettres active
est hébergée sur un serveur de boîtes aux lettres dans l'autre site.

Pour créer cette configuration, l'administrateur exécute plusieurs commandes.

Sur MBX1, exécutez les commandes suivantes :

PowerShellCopier
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime
3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -SuspendComment "Seed from MBX4" -
Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX3 -SourceServer MBX4
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -ActivationOnly

Sur MBX2, exécutez les commandes suivantes :

PowerShellCopier
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX4 -ReplayLagTime
3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -SuspendComment "Seed from MBX3" -
Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX4 -SourceServer MBX3
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -ActivationOnly

Sur MBX3, exécutez les commandes suivantes :

PowerShellCopier
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1 -ReplayLagTime
3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -SuspendComment "Seed from MBX2" -
Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1 -SourceServer MBX2
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -ActivationOnly

Sur MBX4, exécutez les commandes suivantes :

PowerShellCopier
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2 -ReplayLagTime
3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -SuspendComment "Seed from MBX1" -
Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2 -SourceServer MBX1
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -ActivationOnly

Dans les exemples précédents pour la cmdlet Add-MailboxDatabaseCopy , le

paramètre ActivationPreference n’était pas spécifié. La tâche incrémente
automatiquement le numéro de préférences d'activation à chaque copie ajoutée. Le
numéro de préférence 1 est toujours attribué à la base de données d'origine. Le
numéro de préférence 2 est attribué automatiquement à la première copie ajoutée
par la cmdlet Add-MailboxDatabaseCopy. Si aucune copie n'est supprimée, le
numéro de préférence 3 est automatiquement attribué à la prochaine copie ajoutée,
et ainsi de suite. Dans les exemples précédents, le numéro de préférence 2 est donc
attribué à la copie passive dans le même centre de données que la copie active ; le
numéro de préférence 3 est attribué à la copie passive non retardée dans le centre de
données distant et le numéro de préférence 4 est attribué à la copie passive retardée
dans le centre de données distant.

Bien qu'il existe deux copies de chaque base de données active sur le réseau étendu
de l'autre emplacement, l'amorçage sur le réseau étendu n'a été réalisé qu'une seule
fois. En effet, Contoso tire parti de la Exchange Server d’utiliser une copie passive
d’une base de données comme source pour l’amorçage. L’utilisation de la
cmdlet Add-MailboxDatabaseCopy avec le paramètre SeedingPostponed empêche la
tâche d’amorçage automatique de la nouvelle copie de base de données en cours de
création. Ensuite, l’administrateur peut suspendre la copie non amorçage et, à l’aide
de la cmdlet Update-MailboxDatabaseCopy avec le paramètre SourceServer , il peut
spécifier la copie locale de la base de données comme source de l’opération
d’amorçage. Il en résulte que l'amorçage de la deuxième copie de base de données
ajoutée à chaque emplacement se déroule au niveau local et non sur le réseau
étendu.

 Notes

Dans l'exemple précédent, la copie de base de données non retardée est amorcée sur
le réseau étendu, puis elle sert à amorcer la copie retardée de la base de données
située dans le même centre de données que la copie non retardée.

Contoso a configuré une des copies passives de chaque base de données de boîtes
aux lettres en tant que copie retardée pour qu’elle serve de protection dans
l’éventualité, rare mais catastrophique, d’une corruption logique de la base de
données. Par conséquent, l’administrateur utilise la cmdlet Suspend-
MailboxDatabaseCopy et le paramètre ActivationOnly pour configurer les copies
retardées comme étant bloquées pour l’activation. Ceci garantit que les copies de
bases de données retardées ne seront pas activées si un basculement de base de
données ou de serveur devait se produire.

Validation de la solution

Une fois la solution déployée et configurée, l'administrateur effectue plusieurs tâches

validant l'état de préparation de la solution avant de déplacer les boîtes aux lettres de
production vers les bases de données du groupe de disponibilité de base de
données. La solution doit être soumise à des tests et à des inspections, en faisant
appel à plusieurs méthodes et notamment des simulations de défaillance. Pour
valider la solution, l'administrateur effectue plusieurs tâches.

Pour vérifier l'intégrité globale du groupe de disponibilité de base de données,

l'administrateur exécute la cmdlet Test-ReplicationHealth. Cette cmdlet vérifie
plusieurs aspects de l'état de réplication et de réexécution pour fournir des
informations sur chaque serveur de boîtes aux lettres et chaque copie de base de
données du groupe de disponibilité de base de données.

Pour vérifier l'activité de réplication et de réexécution, l'administrateur exécute la

cmdlet Get-MailboxDatabaseCopyStatus. Cette cmdlet peut fournir des informations
en temps réel sur l'état d'une copie spécifique de base de données de boîtes aux
lettres ou sur l'ensemble des copies de bases de données de boîtes aux lettres sur un
serveur précis. Pour plus d’informations sur la surveillance de l’état et de l’état des
bases de données répliquées dans un DAG, voir Surveiller les groupes de
disponibilité de base de données.

Pour vérifier que les basculements fonctionnent comme prévu, l'administrateur utilise
la cmdlet Move-ActiveMailboxDatabase pour exécuter une série de basculements de
bases de données et de serveurs. Une fois ces tâches réalisées, il utilise la même
cmdlet pour déplacer les copies actives de bases de données vers leur emplacement
d'origine.

Pour vérifier les comportements attendus dans divers scénarios de défaillance,

l'administrateur effectue plusieurs tâches destinées à simuler une défaillance ou à
provoquer une véritable défaillance. Par exemple :

 Débrancher le cordon d'alimentation sur MBX1, déclenchant ainsi un

basculement de serveur. L'administrateur vérifie alors que la base de données
DB1 s'active sur un autre serveur (de préférence MBX2, sur la base des numéros
de préférence d'activation).

 Débrancher le câble réseau de la carte réseau MAPI sur MBX2, déclenchant ainsi
un basculement de serveur. L'administrateur vérifie alors que la base de
données DB2 s'active sur un autre serveur (de préférence MBX1, sur la base des
numéros de préférence d'activation).

 Mettre hors connexion le disque utilisé par la copie active de la base de

données (DB3), déclenchant ainsi un basculement de base de données.
L'administrateur vérifie alors que la base de données DB3 s'active sur un autre
serveur (de préférence MBX4, sur la base des numéros de préférence
d'activation).
Une organisation peut aussi tester d'autres scénarios de défaillance en fonction de
ses besoins. À la suite de la simulation d'une seule défaillance (par exemple,
débrancher le cordon d'alimentation) et de l'observation de la capacité de
récupération de la solution, l'administrateur peut opter pour un retour à la
configuration d'origine. Dans certains cas, la solution peut être testée pour résister à
plusieurs défaillances simultanées. En fin de compte, votre plan de tests vous
indiquera s'il faut rétablir la configuration d'origine de la solution après avoir réalisé
chaque simulation de défaillance.

En outre, un administrateur peut décider de débrancher la connexion réseau entre

deux centres de données pour simuler une défaillance de site. La réalisation d’un
basculement de centre de données est une opération plus complexe exigeant une
plus grande coordination, mais elle est recommandée si la solution en cours de
déploiement doit apporter la résilience de site aux services et données de
messagerie.

Transition vers le mode d’exploitation

Une fois la solution déployée, son extension peut être poursuivie au moyen du
déploiement incrémentiel. À ce stade, la gestion de la solution doit se tourner vers
des processus d’exploitation impliquant l’exécution des tâches suivantes :

 Surveiller l'intégrité et l'état des groupes de disponibilité de base de données et

des copies de bases de données de boîtes aux lettres. Pour plus d’informations,
voir Surveiller les groupes de disponibilité de base de données.

 Effectuer les basculements de base de données si cela est nécessaire. Pour

connaître la procédure détaillée d'exécution d'un basculement de base de
données, voir Activer une copie de la base de données de boîtes aux lettres.