Cet article a fait l’objet d’une traduction automatique. Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez également afficher le texte anglais dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte traduit.
Traduction
Anglais

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

[Cette rubrique est une documentation préliminaire et peut être modifiée dans les versions ultérieures. Des rubriques vides sont incluses comme espaces réservés. N’hésitez pas à nous transmettre vos commentaires. Envoyez-nous un e-mail à l’adresse ExchangeHelpFeedback@microsoft.com.]  

S’applique à :Exchange Server 2016

Résumé: en savoir plus sur la gestion des copies de base de données de boîtes aux lettres sur le serveur de boîtes aux lettres dans Exchange 2016.

Dans Exchange 2016, vous pouvez utiliser la Console de gestion Exchange (FAC) ou le Environnement de ligne de commande Exchange Management Shell pour ajouter des copies de base de données de boîte aux lettres après qu’un groupe de disponibilité de base de données (DAG) a été créé, configuré et renseigné avec des membres de serveur de boîtes aux lettres.

Après avoir créé plusieurs copies d’une base de données, vous pouvez utiliser l’estimation à l’achèvement ou la Environnement de ligne de commande Exchange Management Shell pour surveiller la santé et l’état de chaque copie et effectuer d’autres tâches de gestion associées aux copies de la base de données. Vous devrez peut-être effectuer les tâches de gestion parmi suspendre ou de reprendre une copie de la base de données, l’amorçage d’une copie de la base de données, analyse des copies de la base de données, configuration des paramètres de copie de base de données et la suppression d’une copie de la base de données.

Pour diverses raisons, par exemple une opération de maintenance planifiée, vous devez suspendre et reprendre l’activité de réplication continue pour une copie de la base de données. En outre, certaines tâches administratives, telles que l’amorçage, nécessitent que vous suspendez tout d’abord une copie de la base de données. Nous vous recommandons de vous suspendez toutes les activités de réplication lors de la modification du chemin d’accès de la base de données ou ses fichiers journaux. Vous pouvez suspendre et reprendre l’activité de copie de base de données à l’aide de l’estimation à l’achèvement, ou en exécutant les applets de commande de Suspend-MailboxDatabaseCopy et Resume-MailboxDatabaseCopy dans les Environnement de ligne de commande Exchange Management Shell. Pour obtenir la procédure détaillée suspendre ou reprendre l’activité de réplication continue pour une copie de la base de données, consultez Interruption ou reprise d’une copie de base de données de boîtes aux lettres.

Amorçage, également connu sous le nom de mise à jour, est le processus dans lequel une base de données vide, ou une copie de la base de données de production, est ajouté à l’emplacement cible de la copie sur un autre serveur de boîtes aux lettres dans la même DAG comme la base de données active. Cela devient la base de données de référence pour la copie conservée par ce serveur.

Selon le cas, vous pouvez amorcer une base de données à l’aide d’un processus automatique ou un processus manuel qui vous lancez. Lorsqu’une copie de la base de données est ajoutée, la copie sera être automatiquement amorcée, à condition que le serveur cible et son emplacement de stockage sont correctement configurés. Si vous souhaitez amorcer manuellement une copie de la base de données et que vous ne souhaitez automatique pour se produire lors de la création de la copie de l’amorçage, vous pouvez utiliser le paramètre SeedingPostponed lors de l’exécution de l’applet de commande Add-MailboxDatabaseCopy .

Copie de la base de données est rarement nécessaire être redéfinie après l’amorçage initial. Toutefois, si le réamorçage est nécessaire ou si vous souhaitez amorcer manuellement une copie de la base de données au lieu d’avoir le système automatiquement amorcer la copie, vous avez deux options. Vous pouvez réamorcer une base de données à l’aide de l’Assistant copie de base de données de boîte aux lettres de mise à jour de l’estimation à l’achèvement, ou à l’aide de l’applet de commande Update-MailboxDatabaseCopy dans la Environnement de ligne de commande Exchange Management Shell. Avant l’amorçage d’une copie de la base de données, vous devez tout d’abord suspendre la copie de base de données de boîtes aux lettres. Pour obtenir la procédure détaillée amorcer une copie de la base de données, consultez Mise à jour d'une copie de 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.

Lorsque vous effectuez une opération de valeur de départ, vous pouvez choisir amorcer la copie de base de données de boîte aux lettres, le catalogue de l’index de contenu pour la copie de base de données de boîtes aux lettres, ou la copie de la base de données et la copie du catalogue index de contenu. Il est le comportement par défaut de l’Assistant copie de base de données de boîte aux lettres de mise à jour et de l’applet de commande Update-MailboxDatabaseCopy pour amorcer la copie de base de données de boîtes aux lettres et de la copie du catalogue index de contenu. Pour amorcer simplement la copie de base de données de boîte aux lettres sans amorçage du catalogue de l’index de contenu, utilisez le paramètre DatabaseOnly lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy . Pour amorcer la copie du catalogue index de contenu uniquement, utilisez le paramètre CatalogOnly lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy .

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 pour l’amorçage. Ce faisant, vous évitez l’amorçage sur le réseau étendu (WAN) qui relie Portland à New York.

Pour utiliser une copie spécifique en tant que source pour l’implantation lors de l’ajout d’une nouvelle copie de la base de données, vous pouvez effectuer les opérations suivantes :

  • Utilisez le paramètre SeedingPostponed lors de l’exécution de l’applet de commande Add-MailboxDatabaseCopy pour ajouter la copie de la base de données. Si vous n’utilisez pas le paramètre SeedingPostponed , la copie de la base de données sera explicitement amorcée à l’aide de la copie active de la base de données comme source.

  • Vous pouvez spécifier le serveur source que vous souhaitez utiliser dans le cadre de l’Assistant copie de base de données de boîte aux lettres de mise à jour de l’estimation à l’achèvement, ou vous pouvez utiliser le paramètre SourceServer lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy pour spécifier le serveur source de votre choix pour l’implantation. Dans l’exemple précédent, vous spécifiez MBX3 comme le serveur source. Si vous ne ' t utiliser le paramètre de SourceServer , la copie de la base de données sera explicitement amorcée à partir de la copie active de la base de données.

Outre la sélection d’un serveur source spécifique pour l’implantation d’une copie de base de données de boîtes aux lettres, vous pouvez également utiliser le Environnement de ligne de commande Exchange Management Shell pour spécifier les réseaux DAG à utiliser. Vous avez la possibilité de substituer des paramètres de cryptage et la compression du réseau DAG pendant l’opération d’amorçage.

Vous pouvez spécifier les réseaux que vous souhaitez utiliser pour l’amorçage à l’aide du paramètre Network lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy et spécifiez les réseaux DAG que vous souhaitez utiliser. Si vous n’utilisez pas le paramètre Network , le système utilise le comportement par défaut suivants pour la sélection d’un réseau à utiliser pour l’opération d’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 DAG, réseaux de DAG sont configurés pour le cryptage et la compression. Les paramètres par défaut utilisent le cryptage et la compression uniquement pour les communications sur des sous-réseaux différents. Si la source et la cible se trouvent sur des sous-réseaux différents et le DAG est configuré avec les valeurs par défaut pour NetworkCompression et NetworkEncryption, vous pouvez remplacer ces valeurs en utilisant les paramètres NetworkCompressionOverride et NetworkEncryptionOverride , respectivement, lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy .

Lorsque vous commencez un processus d’amorçage à l’aide des applets de commande Add-MailboxDatabaseCopy ou Update-MailboxDatabaseCopy , les tâches suivantes sont effectuées :

  1. Propriétés de base de données à partir de Active Directory sont lus pour valider la base de données spécifiée et les serveurs et pour vérifier que les serveurs source et cible sont en cours d’exécution Exchange 2016, ils sont tous deux membres de la même DAG et que la base de données spécifiée n’est pas une base de données de récupération. Les chemins d’accès du fichier de base de données sont également lues.

  2. 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.

  3. 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.

  4. 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.

  5. Si tous les contrôles préliminaires ont été effectués avec succès, vous serez invité à 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.

  6. L’opération d’amorçage est lancée à partir du service de réplication Microsoft Exchange sur le serveur cible.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. 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.

  15. L’opération de sauvegarde en continu sur le serveur source se termine à la fin de la base de données.

  16. 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é.

  17. 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.

  18. 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.

  19. 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.

  20. 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.

  21. Le service de réplication Microsoft Exchange du serveur source lit les fichiers de catalogue du répertoire.

  22. 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.

  23. 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.

  24. 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.

  25. Le service de réplication Microsoft Exchange déplace les données de catalogue complètes vers l’emplacement final.

  26. Le service de réplication Microsoft Exchange du serveur cible reprend l’indexation de recherche sur la base de données cible.

  27. Le service de réplication Microsoft Exchange du serveur cible renvoie un état d’exécution.

  28. Le résultat final de l’opération est transmis à l’interface d’administration à partir de laquelle la cmdlet a été exécutée.

Après avoir créé une copie de la base de données, vous pouvez afficher et modifier ses paramètres de configuration lorsque cela est nécessaire. Vous pouvez afficher des informations de configuration en examinant la page de Propriétés pour une copie de la base de données dans l’estimation à l’achèvement. Vous pouvez également utiliser le Get-MailboxDatabase et Set-MailboxDatabaseCopy des applets de commande dans le Environnement de ligne de commande Exchange Management Shell pour afficher et configurer les paramètres de copie de base de données, telles que la relecture sans temps de retard, délai de troncation et l’ordre de préférence de l’activation. Pour obtenir la procédure détaillée afficher et configurer les paramètres de copie de base de données, consultez Configurer les propriétés des copies de la base de données de boîtes aux lettres.

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.

Temps d’attente de relecture est une propriété de copie de base de données de boîtes aux lettres qui spécifie la durée, en minutes, délai de relecture de journal pour la copie de la base de données. Le temporisateur de retard de relecture démarre lorsqu’un fichier journal a été répliqué vers la copie passive et a passé avec succès le contrôle. En différant la relecture des journaux pour la copie de la base de données, vous avez la possibilité de récupérer la base de données à un point spécifique dans le temps dans le passé. Une copie de base de données de boîte aux lettres configurée avec un retard de relecture supérieur à 0 est appelé une copie de base de données de boîtes aux lettres étaient en retard, ou simplement une copie étaient en retard.

Une stratégie que les litiges et copies de base de données utilise contiennent des fonctions dans Exchange 2016 peut fournir une protection contre un éventail d’échecs qui serait normalement perdre des données. Toutefois, ces fonctionnalités ne peut pas fournir une protection contre la perte de données en cas de corruption logique, il est rare que peut entraîner une perte de données. Copies calorifugées sont conçus pour éviter toute perte de données en cas de corruption logique. En règle générale, il existe deux types de corruption 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 magasin   Données sont ajoutées, supprimées ou manipulées de manière à ce que l’utilisateur ne s’attend pas. Ces cas sont généralement causés par des applications tierces. Il est généralement uniquement des dommages en ce sens que l’utilisateur l’affiche sous forme de corruption. Le magasin Exchange considère que la transaction qui a produit la corruption logique à une série d’opérations de MAPI valides. La fonction de blocage en cas de litige dans Exchange 2016 fournit une protection contre la corruption logique de magasin (car il empêche le contenu d’être définitivement supprimés par un utilisateur ou une application). Toutefois, il peut être les scénarios où une boîte aux lettres de l’utilisateur devient tellement endommagé qu’il serait plus simple de restaurer la base de données à un point antérieur à la corruption, puis exporter la boîte aux lettres de l’utilisateur pour récupérer des données non corrompues.

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 :

  • 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.

  • Étaient en retard de copies dévers être appliqué avec la fonction de restauration ESE page unique. Si une copie calorifugée rencontre la corruption des pages de base de données (par exemple, une erreur -1018), la copie devra être redéfinie. Réamorçage perdrez l’aspect calorifugée de la copie.

i

Si vous souhaitez que la base de données pour les relire tous les fichiers journaux et de rendre la copie de la base de données en cours, puis activer et récupération d’une copie de base de données de boîtes aux lettres calorifugée sont un processus simple. Si vous souhaitez relire les fichiers journaux jusqu'à un point précis dans le temps, le CONCENTREES est plus difficile, car vous devez manipuler les fichiers journaux manuellement et d’exécuter des utilitaires de base de données Exchange Server (Eseutil.exe).

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 Activation d’une copie de la base de données de boîtes aux lettres retardée.

Délai de troncation est la propriété d’une copie de base de données de boîtes aux lettres qui spécifie la durée, en minutes, délai de suppression du journal pour la copie de la base de données après que le fichier journal a été relu dans la copie de la base de données. Le temporisateur de retard de troncature démarre lorsqu’un fichier journal a été répliqué vers la copie passive, inspection, avec succès et a été relu avec succès dans la copie de la base de données. En différant la troncature des fichiers journaux de la copie de la base de données, vous avez la possibilité de récupérer de défaillances qui affectent les fichiers journaux pour la copie active de la base de données.

La troncature du journal fonctionne de la même dans Exchange 2016 comme dans Exchange 2010. Comportement de troncation est déterminée par les relecture retard troncature décalage temps paramètres de temps et pour 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 (à l’exception des copies calorifugées) doivent avoir relire 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.

Dans Exchange 2016, la troncature du journal ne se produit pas sur une copie de base de données de boîtes aux lettres actives lorsqu’un ou copies plus passives sont suspendus. Si prévu la gestion des activités vont prendre un certain temps (par exemple, plusieurs jours), vous devrez peut-être buildup de fichier journal considérable. Pour empêcher le lecteur de journal de remplir avec les journaux de transactions, vous pouvez supprimer la copie passive affectés de la base de données au lieu de la suspension. Lorsque la maintenance planifiée est terminée, vous pouvez ajouter de nouveau la copie passive de la base de données.

Exchange 2016 a maintenant une fonctionnalité appelée troncature libre qui est désactivé par défaut. Pendant des opérations normales, chaque copie de la base de données conserve des fichiers journaux qui doivent être expédiés vers les autres copies de la base de données jusqu'à ce que toutes les copies d’une base de confirmer qu’ils ont relu (copies passives) ou reçu (copies calorifugées) les fichiers journaux. Il s’agit de comportement de troncation de journal par défaut. Si une copie de la base de données se déconnecte pour une raison quelconque, les fichiers journaux commencent à accumuler sur les disques utilisés par les autres copies de la base de données. Si la copie de la base de données concernée reste hors connexion pendant une longue période, cela peut entraîner les autres copies de base de données manque d’espace disque.

Comportement de troncage est différent lorsque la troncature libre est activée. Chaque copie de la base de données effectue le suivi de son propre espace disque libre et applique les comportement de troncage libre si l’espace disponible devient faible.

  • Pour la copie active, le plus ancien suspecte (la copie passive de la base de données qui se trouve derrière le plus de la relecture du journal) est ignorée et troncature respecte les autres copies passives plus anciens. La copie de la base de données active est où troncature globale est calculée.

  • Pour une copie passive, si l’espace vient à manquer, il indépendamment tronque les fichiers journaux en utilisant les paramètres de configuration décrits plus loin dans le tableau de valeur de Registre. La copie passive tente de respecter la décision de troncation sur la copie active. En dépit de l’implication du nom de MinCopiesToProtect, Exchange n’ignore le plus ancien suspecte connu au moment de l’exécution de troncature.

Les fichiers journaux ayant été supprimés des autres copies saines seront manquants sur la base de données déconnectée lorsque celle-ci sera remise en ligne, et son statut sera FailedAndSuspended. Dans ce cas, si Autoreseed est configuré, la copie concernée sera réamorcée automatiquement. Si Autoreseed n’est pas activé, la copie de base de données devra être amorcée manuellement par un administrateur.

Le nombre requis de copies saines, le seuil d’espace disque libre et le nombre de journaux à conserver sont tous des paramètres configurables. Par défaut, le seuil d’espace disque disponible est de 204 800 Mo (200 Go) et le nombre de journaux à conserver est de 100 000 (100 Go) pour les copies passives et de 10 000 (10 Go) pour les copies actives.

Activation de troncature libre et la configuration des paramètres de la troncation libre sont effectuée en modifiant le Registre Windows sur chaque membre DAG. Il existe trois valeurs de Registre qui peuvent être configurés, qui sont tous stockés sous HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. La clé de BackupInformation les valeurs DWORD suivantes n’existent pas par défaut et doivent être créés manuellement. Les valeurs de Registre DWORD sous BackupInformation sont décrites dans le tableau suivant :

 

Valeur de RegistreDescriptionValeur par défaut

LooseTruncation_MinCopiesToProtect

Cette clé permet d’activer la troncation souple. Elle représente le nombre de copies passives à protéger de la troncation souple sur la copie active d’une base de données. Si la valeur de cette clé est définie sur 0, la troncation souple est désactivée.

0

LooseTruncation_MinDiskFreeSpaceThresholdInMB

Seuil d’espace disque disponible (en Mo) pour le déclenchement de la troncation souple. Si l’espace disque disponible descend en dessous de cette valeur, la troncation souple est déclenchée.

Si cette valeur de registre n’est pas configurée, la valeur par défaut utilisée par la troncation souple est 200 Go.

LooseTruncation_MinLogsToProtect

Nombre minimal de fichiers journaux à conserver sur les copies saines dont les journaux sont tronqués. Si cette valeur de registre est configurée, la valeur configurée s’applique alors aux copies actives et passives.

Si cette valeur de registre n’est pas configurée, les valeurs par défaut 100 000 pour les copies de base de données passives et 10 000 pour les copies de base de données actives sont utilisées.

Lors de l’utilisation de la valeur de registre LooseTruncation_MinLogsToProtect, vous remarquerez que le comportement est différent pour les copies de base de données actives et passives. Sur la copie de base de données active, il s’agit du nombre de journaux supplémentaires conservés avant ceux requis par les copies passives protégées et la plage requise de la copie active. Sur une copie de base de données passive, il s’agit du nombre de journaux conservés depuis le dernier journal disponible. Un dixième de ce nombre est également utilisé pour conserver des journaux avant la plage requise de cette copie passive. Les deux limites permettent de veiller à ce que les copies retardées de base de données n’utilisent pas trop d’espace, car leur plage requise est généralement très étendue.

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 de remplacement ou de veille.

  • Si vous configurez une copie retardée de base de données à 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 la stratégie d’activation de base de données pour l’ensemble d’un serveur à l’aide de la cmdlet Set-MailboxServer ou pour une copie de base de données individuelle à l’aide de la cmdlet Set-MailboxDatabaseCopy pour définir le paramètre DatabaseCopyAutoActivationPolicy sur Blocked.

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

Sur une base de données de boîtes aux lettres très occupé avec un taux de génération de journal élevé, il est plus de chances une perte de données si la réplication de la copie passive de la base de données ne peut effectuer la génération du journal. Un scénario qui peut introduire un taux de génération de journal haute est déplace les boîtes aux lettres. Exchange 2016 inclut une API de garantie de données qui est utilisé par les services tels que le service de réplication de boîte aux lettres Exchange (Mme) pour vérifier l’état de santé de l’architecture de copie de base de données en fonction de la valeur du paramètre DataMoveReplicationConstraint qui a été définie par le système ou un administrateur. En particulier, l’API de garantie des données peut servir à :

  • Vérifier l’intégrité de la réplication   Elle confirme que le nombre requis de copies de base de données est disponible.

  • Vérifier le vidage de réplication   Elle confirme que les fichiers journaux requis ont été relus selon le nombre requis de copies de base de données.

Lorsqu’elle est exécutée, l’API retourne les informations d’état suivantes à l’application appelante :

  • Retry (Nouvelle tentative)   Signifie qu’il y a des erreurs temporaires qui empêchent une condition d’être vérifiée par rapport à la base de données.

  • Satisfied (Satisfait)   Signifie que la base de données remplit les conditions requises ou que la base de données n’est pas répliquée.

  • NotSatisfied (Non satisfait)   Signifie que la base de données ne respecte pas les conditions requises. De plus, des informations sont fournies à l’application appelante sur le motif du retour de la réponse NotSatisfied.

La valeur du paramètre DataMoveReplicationConstraint pour la base de données de boîtes aux lettres détermine combien de copies de base de données doivent être évaluées dans le cadre de la requête. Le paramètre DataMoveReplicationConstraint accepte les valeurs suivantes :

  • None   Lorsque vous créez une base de données de boîtes aux lettres, cette valeur est définie par défaut. Lorsque cette valeur est définie, les conditions de l’API de garantie des données sont ignorées. Ce paramètre doit être utilisé uniquement pour les bases de données de boîtes aux lettres qui ne sont pas répliquées.

  • SecondCopy   C’est la valeur par défaut lorsque vous ajoutez la deuxième copie d’une base de données de boîtes aux lettres. Lorsque cette valeur est définie, au moins une copie passive de base de données doit respecter les conditions de l’API de garantie des données.

  • SecondDatacenter   Lorsque cette valeur est définie, au moins une copie passive de la base de données dans un autre site de Active Directory doit répondre aux conditions API de garantie des données.

  • AllDatacenters   Lorsque cette valeur est définie, au moins une copie passive de la base de données dans chaque site Active Directory doit répondre aux conditions API de garantie des données.

  • AllCopies   Lorsque cette valeur est définie, toutes les copies de base de données de boîtes aux lettres doivent respecter les conditions de l’API de garantie des données.

Vérifier l’intégrité de la réplication

Lorsque l’API de garantie des données est exécutée pour évaluer l’intégrité de l’infrastructure de la copie de base de données, plusieurs éléments sont évalués.

 

Si le paramètre DataMoveReplicationConstraint est défini sur…Alors, pour une certaine base de données...Conditions

SecondCopy

Au moins une copie passive de base de données pour une base de données répliquée doit respecter les conditions dans la colonne suivante.

La copie passive de base de données doit :

  • Être intègre.

  • Avoir une file d’attente de relecture comprise dans les 10 minutes du délai d’attente de relecture.

  • Avoir une longueur de file d’attente de copie inférieure à 10 journaux.

  • Avoir une longueur moyenne de file d’attente de copie inférieure à 10 journaux. La longueur moyenne de file d’attente de copie est calculée en fonction du nombre de fois où l’application a demandé l’état de la base de données.

SecondDatacenter

Au moins une copie passive de la base de données dans un autre site de Active Directory doit respecter les conditions dans la colonne suivante.

AllDatacenters

La copie active doit être montée et une copie passive dans chaque site Active Directory doit respecter les conditions dans la colonne suivante.

AllCopies

La copie active doit être montée, et toutes les copies passives de base de données doivent respecter les conditions dans la colonne suivante.

Vérifier le vidage de réplication

L’API de garantie des données permet également de valider qu’un nombre préalablement requis de copies de base de données ont relu les journaux des transactions requis. Ceci est vérifié en comparant l’horodatage du dernier journal relu à celui de validation du service d’appel (dans la plupart des cas, c’est l’horodatage du dernier fichier journal qui contient les données requises) plus cinq secondes supplémentaires (pour tenir compte des variations ou des décalages de l’horloge système). Si l’horodatage de relecture est supérieur à celui de validation, le paramètre DataMoveReplicationConstraint est respecté. Si l’horodatage de relecture est inférieur à celui de validation, le paramètre DataMoveReplicationConstraint n’est pas respecté.

Avant de déplacer de grands nombres de boîtes aux lettres vers ou à partir de bases de données de réplication au sein d’un DAG, nous vous recommandons de configurer le paramètre DataMoveReplicationConstraint sur chaque base de données de boîtes aux lettres selon ce qui suit :

 

Si vous déployez...Définissez la valeur DataMoveReplicationConstraint sur...

Des bases de données de boîtes aux lettres qui ne possèdent aucune copie de base de données

None

Un DAG au sein d’un site unique Active Directory

SecondCopy

Un DAG dans plusieurs centres de données à l’aide d’un site étiré Active Directory

SecondCopy

Un DAG qui s’étend sur les deux sites deActive Directory et que vous aura des copies de la base de données hautement disponible sur chaque site

SecondDatacenter

Un DAG qui s’étend sur les deux sites de Active Directory et que vous vous ont uniquement étaient en retard de copies de base de données dans le deuxième site

SecondCopy

En effet, l’API de garantie des données ne garantira pas des données en cours de validation avant la relecture du fichier journal dans la copie de base de données et, en raison de la nature de la copie de base de données étant retardée, cette contrainte va faire échouer la demande de déplacement, à moins que la valeur de ReplayLagTime de la copie de base de données retardée soit inférieure à 30 minutes.

Un DAG qui s’étend sur les trois sites ou plus Active Directory et chaque site contiendra des copies de la base de données hautement disponible

AllDatacenters

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

ServeurNombre de bases de données activesNombre de bases de données passivesNombre de bases de données montéesNombre de bases de données démontéesListe de décompte des préférences

EX1

5

11

5

0

4, 4, 3, 5

EX2

1

15

1

0

1, 8, 6, 1

EX3

12

4

12

0

13, 2, 1, 0

EX4

1

15

1

0

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 sur un DAG. 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

ServeurNombre de bases de données activesNombre de bases de données passivesNombre de bases de données montéesNombre de bases de données démontéesListe de décompte des préférences

EX1

4

12

4

0

4, 4, 4, 4

EX2

4

12

4

0

4, 4, 4, 4

EX3

4

12

4

0

4, 4, 4, 4

EX4

4

12

4

0

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ètreDescription

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.

Confirm

Le commutateur Confirm peut être utilisé pour supprimer la boîte de dialogue de confirmation qui s’affiche par défaut lorsque ce script est exécuté. Pour supprimer la boîte de dialogue de confirmation, utilisez la syntaxe de -Confirm:$False. Vous devez inclure un signe deux-points ( : ) dans la syntaxe.

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 sans intervention de l’utilisateur.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

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, ainsi que la création d’un récapitulatif de la distribution.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Vous pouvez afficher un certain nombre d’informations, notamment la longueur de file d’attente de copie, relire la longueur de la file d’attente, l’état et les informations d’état d’index de contenu, en examinant les détails d’une base de données à copier dans l’estimation à l’achèvement. Vous pouvez également utiliser la cmdlet Get-MailboxDatabaseCopyStatus dans les Environnement de ligne de commande Exchange Management Shell à afficher un certain nombre d’informations d’état pour obtenir une copie de la base de données.

noteRemarque :
Une copie de la base de données est votre première défense si une défaillance se produit qui affecte la copie active d’une base de données. Par conséquent, il est essentiel de surveiller la santé et l’état de copies de base de données pour vous assurer qu’elles sont disponibles, lorsque cela est nécessaire.

Pour plus d’informations sur la surveillance des copies de base de données, consultez la rubrique Surveillance des groupes de disponibilité des bases de données.

Une copie de la base de données peut être supprimée à tout moment à l’aide de l’estimation à l’achèvement, ou à l’aide de l’applet de commande Remove-MailboxDatabaseCopy dans la Environnement de ligne de commande Exchange Management Shell. Après la suppression d’une copie de la base de données, vous devez supprimer manuellement les fichiers journaux de transactions et de base de données à partir du serveur à partir duquel la copie de la base de données est en cours de suppression. Pour obtenir la procédure détaillée pour la suppression d’une copie de la base de données, consultez Supprimer une copie de base de données de boîtes aux lettres.

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 identifier rapidement le serveur de boîte aux lettres est le maître de base de données de boîtes aux lettres en cours en consultant la colonne de droite sous l’onglet de Copies de la base de données de l’estimation à l’achèvement. Vous pouvez effectuer un basculement en utilisant le lien Activer dans l’estimation à l’achèvement, ou à l’aide de l’applet de commande Move-ActiveMailboxDatabase dans la Environnement de ligne de commande Exchange Management Shell.

Il existe plusieurs contrôles internes sont effectués avant l’activation de la copie passive. Dans certains cas, le basculement de la base de données est bloqué ou annulé. Dans les autres cas, vous pouvez utiliser les applets de commande à déplacer ou à ignorer certaines vérifications.

  • L’état de la copie de la base de données est vérifiée. Si la copie de la base de données est dans un état d’échec, le basculement est bloqué. Vous pouvez substituer ce comportement et ignorer la vérification d’état en utilisant le paramètre SkipHealthChecks de l’applet de commande Move-ActiveMailboxDatabase . Ce paramètre vous permet de déplacer la copie active d’une copie de la base de données en état d’échec.

  • La copie de base de données active est vérifiée pour voir si elle est actuellement une source d’amorçage pour toute copie de base de données passive. Si la copie active est actuellement utilisée comme source d’amorçage, le basculement est bloqué. Vous pouvez modifier ce comportement et éviter le contrôle de source d’amorçage en utilisant le paramètre SkipActiveCopyChecks de la cmdlet Move-ActiveMailboxDatabase. Ce paramètre vous permet de déplacer une copie active qui est utilisée comme source d’amorçage. L’utilisation de ce paramètre entraîne l’annulation de l’opération d’amorçage qui est alors considérée défectueuse.

  • 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 inexploitable 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 la base de données, vous avez également la possibilité de remplacer les paramètres de connexion à montage configurés pour le serveur qui héberge la copie passive de la base de données en cours d’activation. En utilisant le paramètre MountDialOverride de l’applet de commande Move-ActiveMailboxDatabase demande au serveur cible de substituer ses propres paramètres d’accès à distance de montage et utiliser celles qui sont spécifiées 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.

 
Afficher: