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

Article
05/13/2016

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2015-03-09

La mobilité de base de données est une nouvelle architecture de Microsoft Exchange Server 2010 qui supprime le concept de groupes de stockage et découple une base de données de boîtes aux lettres Exchange 2010 d’un serveur de boîtes aux lettres. Comme les groupes de stockage ont été supprimés d’Exchange 2010, la réplication continue fonctionne alors au niveau de la base de données. Dans Exchange 2010, les journaux de transactions sont répliqués vers un ou plusieurs serveurs de boîtes aux lettres et relus dans une ou plusieurs copies d’une base de données de boîtes aux lettres stockées sur ces serveurs. Plusieurs concepts utilisés dans la réplication continue d’Exchange Server 2007 ont été conservés dans Exchange 2010, notamment les concepts de divergence, l’utilisation de la numérotation de montage de base de données automatique et des réseaux publics et privés.

Gestion des copies de base de données

Après avoir créé plusieurs copies d’une base de données, vous pouvez utiliser la console de gestion Exchange (EMC) et l’environnement de ligne de commande Exchange Management Shell pour contrôler l’intégrité et l’état de chaque copie, et pour effectuer les autres tâches de gestion associées aux copies de base de données. Voici quelques tâches de gestion que vous devrez peut-être effectuer : interruption ou reprise de la copie d’une base de données, amorçage de la copie d’une base de données, contrôle des copies de base de données, configuration des paramètres de copie de base de données et suppression d’une copie de base de données.

Interruption et reprise des copies de base de données

Vous pouvez être amené à interrompre et à reprendre la réplication continue de la copie d’une base de données pour plusieurs raisons, telles qu’une opération de maintenance prévue. En outre, certaines tâches administratives, telles que l’amorçage, nécessitent que vous suspendiez d’abord la copie d’une base de données. Il est aussi recommandé de suspendre toute activité de réplication en cas de modification du chemin ou des fichiers journaux de la base de données. Vous pouvez suspendre et reprendre l’activité de copie de base de données à l’aide de la console de gestion Exchange ou en exécutant les cmdlets Suspend-DatabaseCopy et Resume-DatabaseCopy dans l’environnement de ligne de commande Exchange Management Shell. Pour obtenir la procédure détaillée de suspension ou de reprise de l’activité de réplication continue d’une copie de base de données, consultez la rubrique Interrompre ou reprendre une copie de base de données de boîte aux lettres.

La troncation de journal ne s’effectue pas sur la copie de base de données de boîtes aux lettres active lorsqu’au moins une copie passive est interrompue. Si vos activités de maintenance planifiées doivent s’effectuer sur une période prolongée (par exemple, plusieurs jours), la création de fichiers journaux risque d’être considérable. Afin d’éviter le remplissage du lecteur de journaux de transactions, vous pouvez supprimer la copie de base de données passive concernée au lieu de l’interrompre. Lorsque la maintenance planifiée est terminée, vous pouvez rajouter la copie de base de données passive.

Amorçage d’une copie de base de données

L’amorçage, ou mise à jour, est le processus au cours duquel une base de données, qu’il s’agisse d’une base de données vierge ou de la copie d’une base de données de production, est ajoutée en tant que base de données de production à l’emplacement de copie cible sur un autre serveur de boîtes aux lettres dans le même groupe de disponibilité de base de données (DAG). Cela devient la base de données de base pour la copie gérée par ce serveur.

Selon la situation, l’amorçage peut être un processus automatique ou manuel que vous lancez. Quand une copie de base de données est ajoutée, la copie sera automatiquement amorcée si le serveur cible et son stockage sont configurés comme il faut. Si vous souhaitez amorcer manuellement une copie de base de données et que vous ne voulez pas qu’un amorçage automatique s’effectue lors de la création de la copie, vous pouvez utiliser le paramètre SeedingPostponed au moment de l’exécution de la cmdlet Add-MailboxDatabaseCopy.

Les copies de base de données nécessitent rarement d’être amorcées à nouveau une fois que l’amorçage initial a eu lieu. Toutefois, si un réamorçage s’avère nécessaire ou si vous voulez amorcer manuellement une copie de base de données au lieu de laisser le système amorcer automatiquement la copie, vous pouvez le faire à l’aide de l’assistant Mise à jour d’une copie de base de données dans la console de gestion Exchange ou à l’aide de la cmdlet Update-MailboxDatabaseCopy dans l’environnement de ligne de commande Exchange Management Shell. Avant d’amorcer une copie de base de données, vous devez d’abord interrompre la copie de la base de données de boîtes aux lettres. Pour obtenir la procédure détaillée d’amorçage d’une copie de base de données, consultez la rubrique Mise à jour d’une copie de la base de données de boîtes aux lettres.

Après une opération d’amorçage manuel, la réplication de la copie de base de données de boîtes aux lettres amorcée reprend automatiquement. Si vous ne souhaitez pas que la réplication reprenne automatiquement, utilisez le paramètre ManualResume lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Choix des éléments à amorcer

Lors d’un amorçage, vous pouvez choisir d’amorcer la copie de la base de données de boîtes aux lettres, son catalogue d’index de contenu ou les deux. L’assistant Mise à jour de la copie de base de données et la cmdlet Update-MailboxDatabaseCopy amorceront les deux par défaut. Pour n’amorcer que la copie de base de données de boîtes aux lettres et pas le catalogue d’index de contenu, utilisez le paramètre DatabaseOnly lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy. Pour n’amorcer que le catalogue d’index de contenu, utilisez le paramètre CatalogOnly lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Sélection de la source d’amorçage

Dans Exchange 2007, la réplication continue ne pouvait amorcer une copie de base de données qu’en copiant la copie active de la base de données. Dans Exchange 2010, toute copie de base de données en bon état peut être utilisée comme source d’amorçage pour une copie supplémentaire de cette base de données. Cela s’avère particulièrement utile quand un groupe de disponibilité de base de données a été étendu sur plusieurs emplacements physiques. Par exemple, imaginez le déploiement d’un groupe de disponibilité de base de données de quatre membres, dont deux membres (MBX1 et MBX2) sont situés à Portland dans l’Oregon et deux membres (MBX3 et MBX4) sont situés à New York. Une base de données de boîtes aux lettres appelée DB1 est active sur MBX1 et des copies passives de DB1 se trouvent sur MBX2 et MBX3. Lorsque vous ajoutez une copie de DB1 à MBX4, vous avez la possibilité d’utiliser la copie sur MBX3 comme source d’amorçage, et ainsi, vous évitez d’amorcer sur la liaison WAN entre Portland et New York.

Pour utiliser une copie spécifique comme source d’amorçage lors de l’ajout d’une nouvelle copie de base de données, il faudrait procéder comme suit :

Utilisez le paramètre SeedingPostponed lors de l’exécution de la cmdlet Add-MailboxDatabaseCopy pour ajouter la copie de base de données. Si le paramètre SeedingPostponed n’est pas utilisé, la copie de base de données sera explicitement amorcée avec la copie active de la base de données comme source.
Utilisez le paramètre SourceServer lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy et indiquez le serveur source souhaité pour l’amorçage. Dans l’exemple précédent, vous indiqueriez MBX3 comme serveur source. Si le paramètre SourceServer n’est pas utilisé, la copie de base de données sera explicitement amorcée avec la copie active de la base de données comme source.

Amorçage et réseaux

En plus de choisir un serveur source spécifique pour l’amorçage d’une copie de base de données de boîtes aux lettres, vous pouvez aussi indiquer quels réseaux DAG vous souhaitez utiliser et éventuellement remplacer les paramètres de compression et de chiffrement du réseau DAG pendant l’opération d’amorçage.

Pour indiquer les réseaux que vous souhaitez utiliser pour l’amorçage, utilisez le paramètre Network lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy et indiquez les réseaux DAG que vous voulez utiliser. Si vous n’utilisez pas le paramètre Network, le système utilise la procédure par défaut pour le choix du réseau à utiliser pour l’amorçage :

Si le serveur source et le serveur cible sont sur le même sous-réseau et qu’un réseau de réplication a été configuré incluant le sous-réseau, le réseau de réplication sera utilisé.
Si le serveur source et le serveur cible sont sur différents sous-réseaux, même si un réseau de réplication contenant ces sous-réseaux a été configuré, le réseau client (MAPI) sera utilisé pour l’amorçage.
Si le serveur source et le serveur cible se trouvent dans des centres de données différents, le réseau client (MAPI) sera utilisé pour l’amorçage.

Au niveau du groupe de disponibilité de base de données (DAG), les réseaux DAG sont configurés pour le chiffrement et la compression. Les paramètres par défaut n’utilisent le chiffrement et la compression que pour les communications sur des sous-réseaux différents. Si la source et la cible sont sur différents sous-réseaux et que le groupe de disponibilité de base de données (DAG) est configuré avec les valeurs par défaut pour NetworkCompression et NetworkEncryption, vous pouvez remplacer ces valeurs à l’aide des paramètres NetworkCompressionOverride et NetworkEncryptionOverride, respectivement, lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Processus d’amorçage

Lorsque vous lancez le processus d’amorçage à l’aide de la cmdlet Add-MailboxDatabaseCopy ou Update-MailboxDatabaseCopy, les tâches suivantes sont effectuées :

Les propriétés de base de données d’Active Directory sont lues pour valider la base de données et les serveurs indiqués et pour vérifier que les serveurs sources et cibles exécutent Exchange 2010, qu’ils sont tous les deux des membres du même groupe de disponibilité de base de données et que la base de données indiquée n’est pas une base de données de récupération. Les chemins d’accès aux fichiers de base de données sont également lus.
Il y a une préparation aux contrôles de réamorçage à partir du service de réplication Microsoft Exchange sur le serveur cible.
Le service de réplication Microsoft Exchange du serveur cible contrôle la présence de fichiers journaux des bases de données et des transactions dans le répertoire de fichiers lu lors des contrôles Active Directory à l’étape 1.
Le service de réplication Microsoft Exchange renvoie les informations sur l’état du serveur cible à l’interface d’administration à partir de l’emplacement d’exécution de la cmdlet.
Si tous les contrôles préliminaires ont été effectués avec succès, vous serez invités à confirmer l’opération avant de continuer. Si vous confirmez l’opération, le processus se poursuit. Si une erreur se produit lors des contrôles préliminaires, elle est signalée et l’opération échoue.
L’opération d’amorçage est lancée à partir du service de réplication Microsoft Exchange sur le serveur cible.
Le service de réplication Microsoft Exchange suspend la réplication de base de données de la copie de base de données active.
Les informations sur l’état de la base de données sont mises à jour par le service de réplication Microsoft Exchange pour rendre compte de l’état de l’amorçage.
Si le serveur cible ne contient pas déjà les répertoires pour les fichiers journaux et de base de données cibles, ils sont alors créés.
Une demande d’amorçage de la base de données est transmise du service de réplication Microsoft Exchange du serveur cible au service de réplication Microsoft Exchange du serveur source à l’aide du protocole TCP. Cette demande et les communications qui suivent pour l’amorçage de la base de données ont lieu sur un réseau DAG qui a été configuré comme réseau de réplication.
Le service de réplication Microsoft Exchange du serveur source lance une sauvegarde en continu ESE (Extensible Storage Engine) via l’interface du service de banque d’informations Microsoft Exchange.
Le service de banque d’informations Microsoft Exchange transmet les données de la base de données au service de réplication Microsoft Exchange.
Les données de la base sont transférées du service de réplication Microsoft Exchange du serveur source au service de réplication Microsoft Exchange du serveur cible.
Le service de réplication Microsoft Exchange du serveur cible écrit la copie de la base de données dans un répertoire temporaire situé dans le répertoire principal de la base de données appelé temp-seeding.
L’opération de sauvegarde en continu sur le serveur source se termine à la fin de la base de données.
L’écriture sur le serveur cible se termine et la base de données est déplacée du répertoire temp-seeding à l’emplacement final. Le répertoire temp-seeding est supprimé.
Sur le serveur cible, le service de réplication Microsoft Exchange traite la demande et la communique au service de recherche Microsoft Exchange pour monter le catalogue d’index de contenu de la copie de base de données, s’il existe. S’il y a des fichiers du catalogue qui n’ont pas été mis à jour depuis la fois précédente sur la copie de base de données, l’opération de montage échoue, ce qui entraîne la nécessité de répliquer le catalogue du serveur source. De la même manière, si le catalogue n’existe pas et qu’il n’existe pas sur un nouvel exemplaire de la copie de base de données du serveur cible, il faut une copie du catalogue. Le service de réplication Microsoft Exchange dirige le service de recherche Microsoft Exchange pour qu’il interrompe l’indexation de la copie de base de données pendant qu’un nouveau catalogue est copié à partir de la source.
Le service de réplication Microsoft Exchange du serveur cible envoie alors une demande d’amorçage du catalogue au service de réplication Microsoft Exchange du serveur source.
Sur le serveur source, le service de réplication Microsoft Exchange demande les informations de répertoire du service de recherche Microsoft Exchange et demande la suspension de l’indexation.
Le service de recherche Microsoft Exchange du serveur source renvoie les informations du répertoire du catalogue de recherche au service de réplication Microsoft Exchange.
Le service de réplication Microsoft Exchange du serveur source lit les fichiers de catalogue du répertoire.
Le service de réplication Microsoft Exchange du serveur source déplace les données de catalogue vers le service de réplication Microsoft Exchange du serveur cible à l’aide d’une connexion sur le réseau de réplication. Une fois la lecture finie, le service de réplication Microsoft Exchange envoie une demande au service de recherche Microsoft Exchange pour qu’il reprenne l’indexation de la base de données source.
Si des fichiers de catalogue existent déjà sur le serveur cible du répertoire, le service de réplication Microsoft Exchange sur le serveur cible les supprime.
Le service de réplication Microsoft Exchange du serveur cible écrit les données de catalogue dans un répertoire temporaire appelé CiSeed.Temp jusqu’à ce que les données soient complètement transférées.
Le service de réplication Microsoft Exchange déplace les données de catalogue complètes vers l’emplacement final.
Le service de réplication Microsoft Exchange du serveur cible reprend l’indexation de recherche sur la base de données cible.
Le service de réplication Microsoft Exchange du serveur cible renvoie un état d’exécution.
Le résultat final de l’opération est transmis à l’interface d’administration à partir de laquelle la cmdlet a été exécutée.

Configuration de copies de base de données

Après la création d’une copie de base de données, vous pouvez afficher et modifier ses paramètres de configuration, si nécessaire. Vous pouvez afficher certaines informations de configuration sur la page Propriétés d’une copie de base de données dans la console de gestion Exchange. Vous pouvez aussi utiliser les cmdlets Get-MailboxDatabase et Set-MailboxDatabaseCopy dans l’environnement de ligne de commande Exchange Management Shell pour afficher et configurer les paramètres de copie de base de données, tels que le délai d’attente de relecture, le délai d’attente de troncation et l’ordre de préférence pour l’activation. Pour obtenir la procédure détaillée d’affichage et de configuration des paramètres de copie de base de données, consultez la rubrique Configurer les propriétés des copies de la base de données de boîtes aux lettres.

Utilisation des options de délai d’attente de relecture et de troncation

Les copies de base de données de boîtes aux lettres prennent en charge l’utilisation d’un délai d’attente de relecture et d’un délai d’attente de troncation ; les deux sont définis en minutes. Le paramétrage d’un délai d’attente de relecture vous permet de renvoyer la copie de base de données à un certain moment dans le temps. Le paramétrage d’un délai d’attente de troncation vous permet d’utiliser les fichiers journaux sur une copie passive de base de données à récupérer après la perte de fichiers journaux sur la copie active de base de données. Parce que ces deux fonctionnalités entraînent l’accumulation temporaire des fichiers journaux, leur utilisation aura des répercussions sur votre conception de stockage.

Délai d’attente de relecture

Le délai d’attente de relecture est une propriété de la copie de base de données de boîtes aux lettres qui indique la durée, en minutes, du retard de relecture du journal de la copie de base de données. Le minuteur de retard de relecture se déclenche quand un fichier journal est répliqué dans la copie passive et passe l’inspection avec succès. En retardant la relecture des journaux de la copie de base de données, vous avez la possibilité de récupérer la base de données à un certain moment dans le temps passé. Une copie de base de données de boîtes aux lettres configurée avec un délai d’attente de relecture supérieur à 0 s’appelle une copie retardée de base de données de boîtes aux lettres ou simplement une copie retardée.

Une stratégie qui utilise des copies de bases de données et des fonctionnalités de mise en attente pour litige dans Exchange 2010 peut offrir une protection contre un large éventail de défaillances habituellement responsables d’une perte de données. Toutefois, ces fonctionnalités ne peuvent pas fournir de protection contre la perte de données en cas d’altération logique qui, bien que rare, peut entraîner une perte de données. Les copies retardées sont faites pour éviter la perte de données en cas d’altération logique. En règle générale, il existe deux types d’altération logique :

Corruption logique de la base de données Le total de contrôle des pages de la base de données correspond, mais les données sur les pages sont erronées au niveau logique. Cela peut arriver quand l’ESE tente d’écrire sur une page de base de données et, même si le système d’exploitation envoie un message de succès, soit les données ne sont pas écrites sur le disque soit elles sont écrites à la mauvaise place. Il s’agit d’un vidage perdu. Afin d’éviter la perte de données par les vidages perdus, l’ESE comporte un mécanisme de détection des vidages perdus dans la base de données ainsi qu’une fonctionnalité de mise à jour corrective (restauration d’une seule page).
Corruption logique de banque d’informations Les données sont ajoutées, supprimées ou manipulées d’une manière à laquelle l’utilisateur ne s’attend pas. Ces cas sont généralement provoqués par des applications tierces. Ce n’est généralement de la corruption que dans le sens où l’utilisateur voit cela comme une altération. La banque d’informations Exchange considère la transaction qui est à l’origine de l’altération logique comme une série d’opérations MAPI valides. La fonction de mise en attente pour litige d’Exchange 2010 assure une protection contre l’altération logique de la banque d’informations (car elle évite que le contenu soit supprimé définitivement par un utilisateur ou une application). Toutefois, dans certains cas, une boîte aux lettres d’utilisateur est si endommagée qu’il serait plus facile de la restaurer à un point antérieur à l’altération, et d’exporter ensuite la boîte aux lettres de l’utilisateur pour récupérer les données intactes.

La combinaison des copies de base de données, de la stratégie de rétention et de la restauration ESE des pages uniques ne laisse que les cas rares mais catastrophiques d’altération logique de banque d’informations. Votre choix d’utiliser une copie de base de données avec retard de relecture (une copie retardée) dépendra des applications tierces que vous utilisez et de l’historique de votre organisation quant à l’altération logique de banque d’informations.

Si vous choisissez d’utiliser des copies retardées, prenez en compte les conséquences suivantes lors de leur utilisation :

Contrairement à la réplication continue de secours (SCR) dans Exchange 2007, qui avait un retard de relecture de 50 fichiers journaux codés de manière irréversible, il n’y a pas de nombre de fichiers journaux retardés codés de manière irréversible. À la place, le délai d’attente de relecture est une valeur configurée par l’administrateur qui est désactivée par défaut.
Par défaut, le paramètre de délai d’attente de relecture est défini sur 0 jour et le paramètre maximal sur 14 jours.
Les copies retardées ne sont pas considérées comme des copies hautement disponibles. Elles sont plutôt prévues à des fins de récupération d’urgence pour éviter l’altération logique de la banque d’informations.
Plus le délai d’attente de relecture est important, plus le processus de récupération de base de données est long. Selon le nombre de fichiers journaux qui doivent être relus pendant la récupération, et selon la vitesse à laquelle votre matériel peut les relire, le processus peut mettre plusieurs heures à récupérer une base de données.
Nous vous recommandons de déterminer si les copies retardées sont essentielles à votre stratégie générale de récupération d’urgence. Si elles sont essentielles à votre stratégie, nous vous recommandons d’utiliser plusieurs copies retardées ou un RAID (Redundant array of independant disks) pour protéger une seule copie retardée, si vous n’avez pas plusieurs copies retardées. Si vous perdez un disque ou si une altération se produit, vous ne perdez pas votre moment retardé dans le temps.
Les copies retardées ne peuvent pas être corrigées avec la fonctionnalité de restauration de page unique ESE. Si une copie retardée rencontre une altération de page de base de données (par exemple, une erreur -1018), elle devra être réamorcée (ce qui entraînera la perte de l’aspect retardé de la copie).

L’activation et la récupération d’une copie retardée de base de données de boîtes aux lettres est un processus simple si vous voulez que la base de données relise tous les fichiers journaux et actualise la copie de la base de données. Si vous souhaitez relire les fichiers journaux jusqu’à un moment spécifique dans le temps, l’opération se complique car il vous faut manipuler manuellement les fichiers journaux et exécuter l’outil Eseutil.

Pour obtenir la procédure détaillée d’activation d’une copie retardée de base de données de boîtes aux lettres, consultez la rubrique Activer une copie de la base de données de boîtes aux lettres retardée.

Délai d’attente de troncation

Le délai d’attente de troncation est une propriété de la copie de base de données de boîtes aux lettres qui indique le temps, en minutes, du retard de suppression de la copie de base de données après relecture du fichier journal dans la copie de base de données. Le minuteur de délai d’attente de troncation se déclenche quand un fichier journal est répliqué dans la copie passive, a passé l’inspection avec succès et a été relu avec succès dans la copie de la base de données. En retardant la troncation des fichiers journaux de la copie de base de données, vous avez la possibilité de récupérer des échecs concernant les fichiers journaux de la copie active de la base de données.

Copies de la base de données et troncation de journaux

La troncation de journaux fonctionne de la même manière dans Exchange 2010 que dans Exchange 2007. Le comportement de troncation est déterminé par les paramètres de délai d’attente de relecture et de délai d’attente de troncation de la copie.

Les critères suivants doivent être remplis pour que le fichier journal d’une copie de base de données soit tronqué lorsque les paramètres sont laissés par défaut sur 0 (désactivé) :

Le fichier journal doit avoir été sauvegardé ou la journalisation circulaire doit être activée.
Le fichier journal doit être en-dessous du point de contrôle (fichier journal minimum nécessaire pour la récupération) de la base de données.
Toutes les autres copies retardées doivent avoir inspecté le fichier journal.
Toutes les autres copies (copies non retardées) doivent avoir relu le fichier journal.

Pour la troncation d’une copie retardée de base de données, les critères suivants doivent être remplis :

Le fichier journal doit être inférieur au point de contrôle de la base de données.
Le fichier journal doit être plus ancien que ReplayLagTime + TruncationLagTime.
Le fichier journal doit avoir été tronqué sur la copie active.

Stratégie d’activation de la base de données

Les stratégies d’activation de la base de données sont des scénarios dans lesquels vous voulez créer une copie de base de données de boîtes aux lettres et éviter que le système active automatiquement cette copie en cas de panne. Par exemple :

Si vous déployez une ou plusieurs copies de base de données de boîtes aux lettres dans un centre de données secondaire ou de veille.
Si vous configurez une copie de base de données comme copie retardée à des fins de récupération.
Si vous effectuez la maintenance ou la mise à niveau d’un serveur.

Dans chacun des scénarios évoqués ci-dessus, vous avez des copies de base de données que vous ne voulez pas voir activées automatiquement par le système. Si vous voulez éviter que le système active automatiquement une copie de base de données de boîtes aux lettres, vous pouvez configurer la copie pour qu’elle soit bloquée (suspendue) à l’activation. Cela permet au système de maintenir l’actualité de la base de données par l’envoi de fichiers journaux et la relecture, mais l’empêche d’activer et d’utiliser automatiquement la copie. Les copies bloquées pour l’activation doivent être activées manuellement par un administrateur. Vous pouvez configurer une stratégie d’activation de base de données à l’aide de la cmdlet Set-MailboxServer et définir le paramètre DatabaseCopyAutoActivationPolicy sur Bloqué.

Pour plus d’informations sur la configuration des stratégies d’activation de la base de données, consultez la rubrique Configurer la stratégie d’activation pour une copie de base de données de boîte aux lettres.

Équilibrage des copies de base de données

De par la nature inhérente des groupes de disponibilité de base de données, lorsqu’un basculement ou une permutation de base de données se produit, les copies de base de données de boîtes aux lettres actives changent d’hôte plusieurs fois tout au long du cycle de vie d’un groupe de disponibilité de base de données. Par conséquent, les groupes de disponibilité de base de données se trouvent en déséquilibre au niveau de la distribution des copies de base de données de boîtes aux lettres actives. Le tableau suivant illustre un exemple de groupe de disponibilité de base de données comportant quatre bases de données et quatre copies de chacune (pour un total de 16 bases de données sur chaque serveur) avec une distribution inéquitable des copies de base de données actives.

Groupe de disponibilité de base de données avec une distribution inéquitable des copies actives

Serveur	Nombre de bases de données actives	Nombre de bases de données passives	Nombre de bases de données montées	Liste de décompte des préférences
EX1	5	11	5	4, 4, 3, 5
EX2	1	15	1	1, 8, 6, 1
EX3	12	4	12	13, 2, 1, 0
EX4	1	15	1	1, 1, 5, 9

Dans l’exemple précédent, on dénombre quatre copies de chaque base de données et donc, seulement quatre valeurs possibles pour la préférence d’activation (1, 2, 3 ou 4). La colonne Liste de décompte des préférences indique le nombre de bases de données avec chacune de ces valeurs. Par exemple, sur EX3, il existe 13 copies de base de données avec la préférence d’activation 1, deux copies avec la préférence d’activation 2, une copie avec la préférence d’activation 3 et aucune copie avec la préférence d’activation 4.

Comme vous pouvez le voir, ce groupe de disponibilité de base de données n’est pas équilibré en termes de nombre de bases de données actives hébergées par chaque membre du groupe, de nombre de bases de données passives hébergées par chaque membre du groupe ou de décompte de préférences d’activation des bases de données hébergées.

Vous pouvez utiliser le script RedistributeActiveDatabases.ps1 pour équilibrer les copies de base de données de boîtes aux lettres actives dans un groupe de disponibilité de base de données. Ce script déplace les bases de données d’une copie vers une autre afin d’essayer d’obtenir un nombre équitable de bases de données montées sur chaque serveur dans le groupe de disponibilité de base de données. Si nécessaire, le script essaie également d’équilibrer les bases de données actives dans les sites.

Le script inclut deux options permettant d’équilibrer les copies de base de données actives dans un groupe de disponibilité de base de données :

BalanceDbsByActivationPreference Lorsque cette option est spécifiée, le script tente de déplacer les bases de données vers leur copie préférée (en fonction de la préférence d’activation), indépendamment du site Active Directory.
BalanceDbsBySiteAndActivationPreference Lorsque cette option est spécifiée, le script tente de déplacer les bases de données actives vers leur copie préférée, tout en essayant d’équilibrer les bases de données actives dans chaque site Active Directory.

Après avoir exécuté le script avec la première option, le groupe de disponibilité déséquilibré précédent est rééquilibré, comme l’illustre le tableau suivant.

Groupe de disponibilité de base de données avec une distribution équitable des copies actives

Serveur	Nombre de bases de données actives	Nombre de bases de données passives	Nombre de bases de données montées	Liste de décompte des préférences
EX1	4	12	4	4, 4, 4, 4
EX2	4	12	4	4, 4, 4, 4
EX3	4	12	4	4, 4, 4, 4
EX4	4	12	4	4, 4, 4, 4

Comme indiqué dans le tableau précédent, ce groupe de disponibilité de base de données est à présent équilibré en termes de nombre de bases de données actives et passives sur chaque serveur et de préférence d’activation sur les serveurs.

Le tableau suivant répertorie les paramètres disponibles pour le script RedistributeActiveDatabases.ps1.

Paramètres du script RedistributeActiveDatabases.ps1

Paramètre	Description
DagName	Indique le nom du groupe de disponibilité de base de données que vous souhaitez rééquilibrer. Si ce paramètre est omis, le groupe de disponibilité de base de données dont fait partie le serveur local est utilisé.
BalanceDbsByActivationPreference	Indique que le script doit déplacer les bases de données vers leur copie préférée, indépendamment du site Active Directory.
BalanceDbsBySiteAndActivationPreference	Indique que le script doit essayer de déplacer les bases de données actives vers leur copie préférée, tout en essayant d’équilibrer les bases de données actives dans chaque site Active Directory.
ShowFinalDatabaseDistribution	Indique qu’un rapport de distribution des bases de données actuelles doit s’afficher une fois la redistribution terminée.
AllowedDeviationFromMeanPercentage	Spécifie l’écart autorisé des bases de données actives dans les sites, exprimé en pourcentage. La valeur par défaut est de 20 %. Par exemple, si 99 bases de données ont été distribuées entre trois sites, la distribution idéale serait de 33 bases de données dans chaque site. Si l’écart autorisé est de 20 %, le script tente d’équilibrer les bases de données afin que chaque site ne contienne pas plus de 10 % par rapport à ce nombre. 10 % de 33 équivaut à 3,3, chiffre arrondi à 4. Par conséquent, le script essaie d’avoir entre 29 et 37 bases de données dans chaque site.
ShowDatabaseCurrentActives	Indique que le script doit créer, pour chaque base de données, un rapport indiquant la manière dont celle-ci a été déplacée et si elle est maintenant active sur sa copie préférée.
ShowDatabaseDistributionByServer	Indique que le script doit générer un rapport décrivant la distribution des bases de données pour chaque serveur.
RunOnlyOnPAM	Indique que le script s’exécute uniquement sur le membre du groupe de disponibilité de base de données exerçant actuellement le rôle de gestionnaire Active Manager principal (PAM). Le script vérifie qu’il est exécuté à partir du gestionnaire Active Manager principal. Si tel n’est pas le cas, le script prend fin.
LogEvents	Indique que le script consigne un événement (événement 4115 MsExchangeRepl) contenant un résumé des actions.
IncludeNonReplicatedDatabases	Indique que le script doit inclure les bases de données non répliquées (bases de données sans copies) lors de la détermination du mode de redistribution des bases de données actives. Même si les bases de données non répliquées ne peuvent pas être déplacées, elles peuvent influencer la distribution des bases de données répliquées.

Exemples de script RedistributeActiveDatabases.ps1

Cet exemple illustre la distribution des bases de données actuelles pour un groupe de disponibilité de base de données, notamment la liste de décompte des préférences.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

Cet exemple illustre la redistribution et l’équilibrage des copies de base de données de boîtes aux lettres actives dans un groupe de disponibilité de base de données utilisant la préférence d’activation.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Surveillance des copies de base de données

Une copie de base de données est votre premier recours en cas de panne touchant la copie active de la base de données. Il est donc essentiel de contrôler l’intégrité et l’état des copies de base de données pour s’assurer qu’elles seront disponibles, si nécessaire. Vous pouvez afficher certaines informations sur l’intégrité et l’état sur la page Propriétés d’une copie de base de données dans la console de gestion Exchange. Vous pouvez aussi utiliser la cmdlet Get-MailboxDatabaseCopyStatus dans l’environnement de ligne de commande Exchange Management Shell pour afficher les diverses informations sur l’état d’une copie de base de données.

Pour plus d’informations sur la surveillance des copies de base de données, consultez la rubrique Analyse de la haute disponibilité et de la résilience de site.

Suppression d’une copie de base de données

Une copie de base de données peut être supprimée à tout moment à l’aide de la console de gestion Exchange ou de la cmdlet Remove-MailboxDatabaseCopy dans l’environnement de ligne de commande Exchange Management Shell. Après suppression d’une copie de base de données, vous devez manuellement supprimer tout fichier journal de transaction et de base de données du serveur à partir duquel la copie de base de données est en cours de suppression. Pour obtenir la procédure détaillée de suppression d’une copie de base de données, consultez la rubrique Supprimer une copie de base de données de boîte aux lettres.

Permutation de base de données

Le serveur de boîtes aux lettres qui héberge la copie active de la base de données est le maître de la base de données de boîtes aux lettres. Le processus d’activation d’une copie de base de données active modifie le maître de la base de données de boîtes aux lettres et convertit la copie passive en nouvelle copie active. Ce processus est appelé basculement de base de données. Dans un basculement de base de données, la copie active de la base de données est démontée d’un serveur de boîtes aux lettres et une copie passive de cette base est montée en tant que nouvelle base de données de boîtes aux lettres active sur un autre serveur de boîtes aux lettres. Lorsque vous effectuez un basculement, vous pouvez éventuellement remplacer les paramètres de numérotation de montage de la base de données sur le nouveau maître de la base de données de boîtes aux lettres.

Vous pouvez rapidement identifier le serveur de boîtes aux lettres qui est actuellement le maître de la base de données de boîtes aux lettres en affichant la colonne État de la copie sous l’onglet Copies de base de données dans la console de gestion Exchange. Seule la copie active présente l’état Monté. Toutes les autres copies de base de données afficheront l’état de réplication actuel pour la copie de base de données. Vous pouvez effectuer un basculement à l’aide de l’assistant Déplacement d’un maître de base de données de boîtes aux lettres dans la console de gestion Exchange ou à l’aide de la cmdlet Move-ActiveMailboxDatabase dans l’environnement de ligne de commande Exchange Management Shell.

Plusieurs vérifications internes seront effectuées avant l’activation de la copie passive :

L’état de la copie de base de données est contrôlé. Si la copie de base de données est indisponible, le basculement est bloqué. Vous pouvez modifier ce comportement et éviter le contrôle d’état en utilisant le paramètre SkipHealthChecks de la cmdlet Move-ActiveMailboxDatabase. Ce paramètre vous permet de déplacer la copie active vers une copie de base de données indisponible.
Les longueurs de la file d’attente de copie et de relecture de la copie de base de données sont contrôlées afin de veiller à ce que les valeurs correspondent aux critères configurés. De même, la copie de base de données est vérifiée pour s’assurer qu’elle n’est pas utilisée actuellement comme source d’amorçage. Si les valeurs des longueurs de file d’attente ne font pas partie des critères configurés ou si la base de données est actuellement utilisée comme source d’amorçage, le basculement est bloqué. Vous pouvez modifier ce comportement et éviter ces contrôles en utilisant le paramètre SkipLagChecks de la cmdlet Move-ActiveMailboxDatabase. Ce paramètre permet d’activer une copie disposant de files d’attente de relecture et de copie en dehors des critères configurés.
L’état du catalogue de recherche (index du contenu) de la copie de base de données est contrôlé. Si le catalogue de recherche n’est pas à jour, n’est pas en bon état ou est endommagé, le basculement est bloqué. Vous pouvez modifier ce comportement et éviter le contrôle du catalogue de recherche en utilisant le paramètre SkipClientExperienceChecks de la cmdlet Move-ActiveMailboxDatabase. Grâce à ce paramètre, la recherche n’effectue pas le contrôle d’état du catalogue. Si le catalogue de recherche de la copie de base de données que vous activez n’est pas en bon état ou est inutilisable et que vous utilisez ce paramètre pour passer le contrôle d’état du catalogue et activer la copie de base de données, il vous faudra à nouveau analyser ou amorcer le catalogue de recherche.

Lorsque vous effectuez un basculement de base de données, vous avez la possibilité de remplacer les paramètres de numérotation de montage configurés pour le serveur hébergeant la copie passive de base de données en train d’être activée. Le paramètre MountDialOverride de la cmdlet Move-ActiveMailboxDatabase donne l’ordre au serveur cible de remplacer ses propres paramètres de numérotation de montage et d’utiliser ceux indiqués par le paramètre MountDialOverride.

Pour obtenir la procédure détaillée de basculement d’une copie de base de données, consultez la rubrique Activer une copie de la base de données de boîtes aux lettres. Pour plus d’informations sur les basculements de base de données, consultez la rubrique Switchovers et basculements.

Partager via