Modifications apportées à la haute disponibilité et la résilience de site par rapport aux versions précédentesChanges to high availability and site resilience over previous versions

Résumé: une vue d’ensemble des améliorations et ajouts aux fonctionnalités de résilience haute disponibilité et de site depuis la version d’Exchange 2010.Summary: An overview of enhancements and additions to high availability and site resilience capabilities since the Exchange 2010 release.

Exchange Server 2016 utilise DAG et copie, ainsi que d’autres fonctionnalités telles que récupération d’élément unique, les stratégies de rétention, de base de données de boîtes aux lettres et retardées de copies de base de données, pour fournir une haute disponibilité, une résilience de site et la protection des données natives Exchange. La plateforme de haute disponibilité, la banque d’informations Exchange et le moteur ESE (Extensible Storage) ont été tout améliorés pour fournir une disponibilité et gestion moins complexe et à réduire les coûts. Ces améliorations incluent :Exchange Server 2016 uses DAGs and mailbox database copies, along with other features such as single item recovery, retention policies, and lagged database copies, to provide high availability, site resilience, and Exchange native data protection. The high availability platform, Exchange Information Store and Extensible Storage Engine (ESE) have all been enhanced to provide availability and less complex management, and to reduce costs. These enhancements include:

  • Réduction des IOPS par: cela vous permet de bénéficier de disques plus grands en termes de capacité et d’IOPS aussi efficaces que possible.Reduction in IOPS: This enables you to leverage larger disks in terms of capacity and IOPS as efficiently as possible.

  • Disponibilité gérée: avec disponibilité gérée, la surveillance interne et fonctionnalités récupération sont étroitement intégrées pour aider à éviter les échecs, proactive restaurer les services et initier des basculements server automatiquement ou d’alerte administrateurs d’effectuer une action. Le focus est sur la surveillance et la gestion de l’utilisateur final plutôt que simplement serveur et disponibilité composant pour assurer le service disponible en permanence.Managed availability: With managed availability, internal monitoring and recovery-oriented features are tightly integrated to help prevent failures, proactively restore services, and initiate server failovers automatically or alert administrators to take action. The focus is on monitoring and managing the end-user experience rather than just server and component uptime to help keep the service continuously available.

  • Banque gérée: la banque gérée est le nom des processus de banque d’informations nouvellement réécrites dans Exchange 2016. Le nouveau magasin géré est écrit en c# et étroitement intégré avec le service de réplication Microsoft Exchange (MSExchangeRepl.exe) pour fournir une plus grande disponibilité à l’amélioration de la résilience.Managed Store: The Managed Store is the name of the newly rewritten Information Store processes in Exchange 2016. The new Managed Store is written in C# and tightly integrated with the Microsoft Exchange Replication service (MSExchangeRepl.exe) to provide higher availability through improved resiliency.

  • Prise en charge de bases de données multiples par disque : Exchange 2016 comprend des améliorations qui vous permettent de prendre en charge de bases de données multiples (mélange de copies actives et passives) sur le même disque, ce qui améliore l’efficacité des disques en tirant parti d’une plus grande capacité et d’un nombre d’opérations d’E/S par seconde accru.Support for multiple databases per disk: Exchange 2016 includes enhancements that enable you to support multiple databases (mixtures of active and passive copies) on the same disk, thereby leveraging larger disks in terms of capacity and IOPS as efficiently as possible.

  • AutoReseed: automatique réamorçage fonctionnalité vous permet de restaurer rapidement la redondance de base de données après défaillance de disque. Si un disque tombe en panne, la copie de base de données stockée sur ce disque est copiée à partir de la copie de base de données active sur un disque de rechange sur le même serveur. Si plusieurs copies de base de données ont été stockées sur le disque défaillant, ils peuvent tout automatiquement réamorcées sur un disque de rechange. Cela permet le réamorçage plus rapide, comme les bases de données actives sont susceptibles de se trouver sur plusieurs serveurs et les données sont copiées en parallèle.AutoReseed: Automatic reseeding capability enables you to quickly restore database redundancy after disk failure. If a disk fails, the database copy stored on that disk is copied from the active database copy to a spare disk on the same server. If multiple database copies were stored on the failed disk, they can all be automatically reseeded on a spare disk. This enables faster reseeds, as the active databases are likely to be on multiple servers and the data is copied in parallel.

  • Suite à des défaillances de stockage: cette fonctionnalité continue l’innovation introduite dans Exchange 2010 pour autoriser la récupération suite à des défaillances qui affectent la résistance ou la redondance du système. 2016 Exchange inclut désormais les comportements de récupération supplémentaires pour le temps d’e/s élevés, consommation excessive de mémoire par MSExchangeRepl.exe et pire des cas où le système se trouve dans cet mauvais état que les threads ne peuvent pas être planifiée.Automatic recovery from storage failures: This feature continues the innovation introduced in Exchange 2010 to allow the system to recover from failures that affect resiliency or redundancy. Exchange 2016 now includes additional recovery behaviors for long I/O times, excessive memory consumption by MSExchangeRepl.exe, and severe cases where the system is in such a bad state that threads can't be scheduled.

  • Améliorations de la copie Lagged: copies Lagged peuvent désormais en charge pour lire eux-mêmes dans une certaine mesure à l’aide d’ouverture de session automatique. Copies retardées lira automatiquement les fichiers journaux dans de nombreuses situations, telles que la mise à jour corrective de page et les scénarios d’espace disque faible. Si le système détecte que la mise à jour corrective de page est requis pour une copie retardée, les journaux seront automatiquement relus dans la copie retardée pour effectuer la mise à jour corrective de page. Copies retardées appelle également cette fonctionnalité de relecture automatique lorsque le seuil d’espace disque faible est atteint, et lorsque la copie retardée a été détectée comme la copie disponible uniquement pour une période spécifique. En outre, les copies retardées peuvent tirer parti de Safety Net, facilite la récupération ou l’activation.Lagged copy enhancements: Lagged copies can now care for themselves to a certain extent using automatic log play down. Lagged copies will automatically play down log files in a variety of situations, such as page patching and low disk space scenarios. If the system detects that page patching is required for a lagged copy, the logs will be automatically replayed into the lagged copy to perform page patching. Lagged copies will also invoke this auto replay feature when a low disk space threshold has been reached, and when the lagged copy has been detected as the only available copy for a specific period of time. In addition, lagged copies can leverage Safety Net, making recovery or activation much easier.

  • Améliorations de l’alerte de copie unique: l’alerte de copie unique d’abord introduite dans Exchange 2010 n’est plus un script planifié distinct. Il est désormais intégré dans les composants de gestion de la disponibilité du système et est une fonction native dans Exchange.Single copy alert enhancements: The single copy alert first introduced in Exchange 2010 is no longer a separate scheduled script. It's now integrated into the managed availability components within the system and is a native function within Exchange.

  • Configuration automatique de réseau DAG: réseaux DAG peuvent être configurées automatiquement par le système en fonction des paramètres de configuration. Outre les options de configuration manuelle, DAG peut également faire la distinction entre réseaux MAPI et la réplication et configure automatiquement les réseaux DAG.DAG network auto-configuration: DAG networks can be automatically configured by the system based on configuration settings. In addition to manual configuration options, DAGs can also distinguish between MAPI and replication networks and configure DAG networks automatically.

Réduction des IOPS parReduction in IOPS

Dans Exchange 2010, les copies de base de données passives ont une très faible profondeur de point de contrôle, ce qui est nécessaire pour un basculement rapide. En outre, la copie passive effectue une prélecture agressive des données afin de maintenir une profondeur de point de contrôle de 5 mégaoctets (Mo). En raison de l'utilisation d'une faible profondeur de point de contrôle et de la réalisation de ces opérations de prélecture agressive, le nom d'E/S par seconde d'une copie de base de données passive était égal à celui d'une copie active dans Exchange 2010.In Exchange 2010, passive database copies have a very low checkpoint depth, which is required for fast failover. In addition, the passive copy performs aggressive pre-reading of data to keep up with a 5-megabyte (MB) checkpoint depth. As a result of using a low checkpoint depth and performing these aggressive pre-read operations, IOPS for a passive database copy was equal to IOPS for an active copy in Exchange 2010.

Dans Exchange 2016, le système est en mesure de fournir le basculement rapide lors de l’utilisation d’une profondeur de haut sur la copie passive (100 Mo). Étant donné que les copies passives ont profondeur de 100 Mo, elles ont été déduplication réglés ne peut plus être donc agressif. À la suite d’augmenter la profondeur de point de contrôle et réglage des lectures préalables agressifs, IOPS pour une copie passive est 50 pour cent de la copie active IOPS dans Exchange 2016.In Exchange 2016, the system is able to provide fast failover while using a high checkpoint depth on the passive copy (100 MB). Because passive copies have 100-MB checkpoint depth, they've been de-tuned to no longer be so aggressive. As a result of increasing the checkpoint depth and de-tuning the aggressive pre-reads, IOPS for a passive copy is about 50 percent of the active copy IOPS in Exchange 2016.

Avoir une profondeur supérieure sur la copie passive entraîne également dans d’autres modifications. Lors du basculement dans Exchange 2010, le cache de la base de données est vidé la base de données est convertie à partir d’une copie passive en une copie active. Dans Exchange 2016, journalisation ESE a été réécrit afin que le cache est conservé par le biais de la transition entre passive et active. Étant donné que ESE ne doit pas vider le cache, vous obtenez le basculement rapide.Having a higher checkpoint depth on the passive copy also results in other changes. On failover in Exchange 2010, the database cache is flushed as the database is converted from a passive copy to an active copy. In Exchange 2016, ESE logging was rewritten so that the cache is persisted through the transition from passive to active. Because ESE doesn't need to flush the cache, you get fast failover.

Une autre modification a été apportée au processus de maintenance de base de données en arrière-plan. Ce processus traite désormais environ 1 à 2 Mo par seconde et par copie.One other change was made to the background database maintenance (BDM) process. BDM now processes around 1-2 MB per second per copy.

À la suite de ces modifications, 2016 Exchange offre une diminution IOPS par rapport aux versions antérieures.As a result of these changes, Exchange 2016 provides a significant reduction in IOPS over earlier versions.

Disponibilité géréeManaged Availability

Disponibilité gérée est l’intégration d’intégrée, la surveillance active et la plateforme de haute disponibilité 2016 Exchange. Avec la disponibilité gérée, le système peut faire un moment faire basculer une base de données en fonction de l’intégrité du service. Disponibilité gérée est une infrastructure interne qui est déployé sur l’accès au Client et boîte aux lettres de rôles de serveur dans Exchange 2016. La disponibilité gérée comprend trois principaux composants asynchrones qui sont constamment du travail. Le premier composant est le moteur de sonde, qui est chargé de prendre des mesures sur le serveur et la collecte de données. Les résultats de ces mesures flux dans le deuxième composant, le moniteur. Le moniteur contient tous de la logique métier utilisée par le système en fonction de ce qui est considéré comme intègre des données collectées. Semblable à un moteur de reconnaissance de modèle, l’Analyseur de recherche pour différents motifs différents sur toutes les mesures, puis il détermine si un élément est considéré comme sain. Enfin, il est le moteur de répondeur, qui est responsable des actions de récupération. Lorsqu’un objet est défectueux, la première action consiste à essayer de récupérer ce composant. Il peut s’agir d’actions de récupération multi-étape ; par exemple, la première tentative peut-être redémarrer le pool d’applications, le second est peut-être redémarrer le service, la troisième tentative peut-être redémarrer le serveur, et peut-être la tentative suivante pour déconnecter le serveur afin qu’elle n’accepte plus le trafic. Si les actions de récupération échoue, le système transmet le problème à une personne via les notifications du journal des événements.Managed Availability is the integration of built-in, active monitoring and the Exchange 2016 high availability platform. With Managed Availability, the system can make a determination on when to fail over a database based on service health. Managed Availability is an internal infrastructure that's deployed on the Client Access and Mailbox server roles in Exchange 2016. Managed Availability includes three main asynchronous components that are constantly doing work. The first component is the probe engine, which is responsible for taking measurements on the server and collecting data. The results of those measurements flow into the second component, the monitor. The monitor contains all of the business logic used by the system based on what is considered healthy on the data collected. Similar to a pattern recognition engine, the monitor looks for the various different patterns on all the collected measurements, and then it decides whether something is considered healthy. Finally, there is the responder engine, which is responsible for recovery actions. When something is unhealthy, the first action is to attempt to recover that component. This could include multi-stage recovery actions; for example, the first attempt may be to restart the application pool, the second may be to restart the service, the third attempt may be to restart the server, and the subsequent attempt may be to take the server offline so that it no longer accepts traffic. If the recovery actions are unsuccessful, the system escalates the issue to a human through event log notifications.

La disponibilité gérée est implémentée sous la forme de deux services :Managed availability is implemented in the form of two services:

  • Service Exchange Health Manager (MSExchangeHMHost.exe): il s’agit d’un processus contrôleur qui sert à gérer les processus de travail. Il est utilisé pour créer, exécuter et démarrer et arrêter le processus de travail selon vos besoins. Il est également utilisé pour récupérer le processus de travail en cas de ce processus tombe en panne, pour empêcher que le processus de travail en cours d’un point de défaillance unique.Exchange Health Manager Service (MSExchangeHMHost.exe): This is a controller process that's used to manage worker processes. It's used to build, execute, and start and stop the worker process as needed. It's also used to recover the worker process in case that process crashes, to prevent the worker process from being a single point of failure.

  • Processus Exchange Health Manager Worker (MSExchangeHMWorker.exe): il s’agit du processus de travail chargé d’effectuer les tâches d’exécution.Exchange Health Manager Worker process (MSExchangeHMWorker.exe): This is the worker process that's responsible for performing the runtime tasks.

La disponibilité gérée utilise un stockage persistant pour remplir ses fonctions :Managed availability uses persistent storage to perform its functions:

  • Les fichiers de configuration XML sont utilisés pour initialiser les définitions d'éléments de travail lors du démarrage du processus de travail.XML configuration files are used to initialize the work item definitions during startup of the worker process.

  • Le registre est utilisé pour stocker des données d'exécution, telles que des signets.The registry is used to store runtime data, such as bookmarks.

  • L'infrastructure de journal des événements du canal Crimson est utilisée pour stocker les résultats d'éléments de travail.The crimson channel event log infrastructure is used to store the work item results.

Pour plus d’informations sur la disponibilité gérée, consultez la rubrique disponibilité géré.For more information about managed availability, see Managed availability.

Banque géréeManaged Store

Les versions précédentes d’Exchange Server ont pris en charge une seule instance du processus de banque d’informations (Store.exe) en cours d’exécution sur le rôle serveur de boîtes aux lettres. Cette instance unique de la banque héberge toutes les bases de données sur le serveur : active, passive, retardées et de récupération. Dans les architectures Exchange précédents, il est peu, le cas échéant, une isolation entre les différentes bases de données hébergées sur un serveur de boîtes aux lettres. Un problème avec une base de données de boîte aux lettres unique a la possibilité d’un impact négatif sur tous les autres bases de données et service pour tous les utilisateurs dont bases de données hébergées sur ce serveur peuvent affecter les incidents résultant d’une altération de la boîte aux lettres.Previous versions of Exchange Server have supported running a single instance of the Information Store process (Store.exe) on the Mailbox server role. This single Store instance hosts all databases on the server: active, passive, lagged, and recovery. In the previous Exchange architectures, there is little, if any, isolation between the different databases hosted on a Mailbox server. An issue with a single mailbox database has the potential to negatively affect all other databases, and crashes resulting from a mailbox corruption can affect service for all users whose databases are hosted on that server.

L'autre défi avec une seule instance de banque dans les versions précédentes d'Exchange tient au fait que le moteur de stockage extensible (ESE) s'adapte bien de 8 à 12 cœurs de processeur. Au-delà, cependant, les problèmes de communication entre les processeurs et de synchronisation du cache entraînent un redimensionnement négatif. Étant donné que les serveurs actuels sont beaucoup plus importants, et qu'ils proposent plus de 16 systèmes centraux, cela compliquerait la gestion de l'affinité des 8 à 12 cœurs pour ESE, les autres cœurs servant pour les processus non liés à la banque (par exemple, les assistants, la tâche Rechercher la fondation, la disponibilité gérée, etc.). En outre, l'architecture précédente restreignait la mise à l'échelle pour le processus de banque.Another challenge with a single Store instance in previous versions of Exchange is that the Extensible Storage Engine (ESE) scales well to 8-12 processor cores, but beyond that, cross-processor communication and cache synchronization issues lead to negative scale. Given today's much larger servers, with 16+ core systems available, this would mean impose the administrative challenge of managing the affinity of 8-12 cores for ESE and using the other cores for non-Store processes (for example, Assistants, Search Foundation, Managed Availability, etc.). Moreover, the previous architecture restricted scale-up for the Store process.

Le processus Store.exe a évolué considérablement au fil des années en tant que serveur Exchange lui-même évolué, mais comme un seul processus finalement son évolutivité est limitée, et il représente un point de défaillance unique. En raison de ces limites, Store.exe a été passé depuis Exchange 2013 et remplacée par la banque gérée.The Store.exe process has evolved considerably throughout the years as Exchange Server itself evolved, but as a single process, ultimately its scalability is limited, and it represents a single point of failure. Because of these limits, Store.exe has been gone since Exchange 2013 and replaced by the Managed Store.

Pour plus d'informations, voir Banque gérée.For more information, see Managed Store.

Plusieurs bases de données par volumeMultiple databases per volume

Bien que les améliorations de stockage dans Exchange 2016 sont adressent principalement aux simplement une série de configurations de disques (JBOD), elles sont disponibles pour une utilisation par toutes les configurations de stockage prises en charge. Une de ces fonctionnalités est la possibilité d’héberger plusieurs bases de données sur le même volume. Cette fonctionnalité est sur l’optimisation des Exchange disques de grande capacité. Ces optimisations de résultat dans une utilisation beaucoup plus efficace de disques de grande capacité en termes de capacité, les IOPS et les heures de réamorçage, et ils sont destinés à relever les défis associés en cours d’exécution dans une configuration de stockage JBOD :Although the storage improvements in Exchange 2016 are designed primarily for just a bunch of disks (JBOD) configurations, they're available for use by all supported storage configurations. One such feature is the ability to host multiple databases on the same volume. This feature is about Exchange optimizing for large disks. These optimizations result in a much more efficient use of large disks in terms of capacity, IOPS, and reseed times, and they're meant to address the challenges associated with running in a JBOD storage configuration:

  • Les tailles de base de données doivent pouvoir être gérées.Database sizes must be manageable.

  • Les opérations de réamorçage doivent être rapides et fiables.Reseed operations must be fast and reliable.

  • La capacité de stockage augmente, contrairement aux E/S par seconde.Although storage capacity is increasing, IOPS aren't.

  • Les disques qui hébergent les copies de base de données passives sont sous-utilisés pour ce qui est des E/S par seconde.Disks hosting passive database copies are underutilized in terms of IOPS.

  • Les copies retardées ont des exigences de stockage asymétriques.Lagged copies have asymmetric storage requirements.

  • Vous avez peu de marge de manœuvre pour effectuer une récupération à partir d'un espace disque faible.Limited agility exists to recover from low disk space conditions.

La tendance à l'augmentation des capacités de stockage continue ; des lecteurs 8 téraoctets (To) seront en effet bientôt disponibles. Si vous utilisez des lecteurs de 8 téraoctets (To) et que vous suivez les meilleures pratiques Exchange relatives à la taille maximale des bases de données (2 téraoctets), vous gaspillez plus de 5 téraoctets d'espace disque. Une solution consiste à augmenter la taille des bases de données. Toutefois, elle réduit la facilité de gestion, car de longs délais de réamorçage sont nécessaires et, dans certains cas, les délais de réamorçage deviennent ingérables sur le plan opérationnel, et la fiabilité de la copie de cette quantité de données sur le réseau est compromise.The trend of increasing storage capacity is continuing, with 8-terabyte drives expected to be available soon. When using 8-terabyte drives in conjunction with the Exchange maximum database size best practices guidelines (2 terabytes), you would waste more than 5 terabytes of disk space. One solution would be to simply grow the databases larger, but that inhibits manageability because it introduces long reseed times, including in some cases, operationally unmanageable reseed times, and the reliability of copying that amount of data over the network is compromised.

De plus, dans le modèle Exchange 2010, le disque qui stocke une copie passive est sous-exploité en E/S par seconde. En cas de copie passive retardée, non seulement le disque est sous-exploité en E/S par seconde, mais il est aussi asymétrique par sa taille, par rapport aux disques employés pour stocker les copies actives et passives non retardées.In addition, in the Exchange 2010 model, the disk storing a passive copy is underutilized in terms of IOPS. In the case of a lagged passive copy, not only is the disk underutilized in terms of IOPS, but it's also asymmetric in terms of its size, relative to the disks used to store the active and non-lagged passive copies.

2016 Exchange est optimisé pour utiliser des disques de grande taille (8 téraoctets) dans une configuration JBOD plus efficacement. Dans Exchange 2016, avec plusieurs bases de données par disque, vous pouvez avoir les même taille disques stocker plusieurs copies de base de données, y compris les copies retardées. L’objectif est de la distribution des utilisateurs entre le nombre de volumes existe, vous fournissant une conception symétrique où lors d’opérations normales chaque membre du DAG héberge une combinaison de copies retardées actives, passives et facultatifs sur les mêmes volumes du lecteur.Exchange 2016 is optimized to use large disks (8 terabytes) in a JBOD configuration more efficiently. In Exchange 2016, with multiple databases per disk, you can have the same size disks storing multiple database copies, including lagged copies. The goal is to drive the distribution of users across the number of volumes that exist, providing you with a symmetric design where during normal operations each DAG member hosts a combination of active, passive, and optional lagged copies on the same volumes.

Vous trouverez ci-dessous un exemple de configuration qui utilise plusieurs bases de données par volume.An example of a configuration that uses multiple databases per volume is illustrated below.

Configuration utilisant plusieurs bases de données par volumeConfiguration that uses multiple databases per volume

Plusieurs bases de données par volume

La configuration ci-dessus offre une conception symétrique. Les quatre serveurs ont les quatre mêmes bases de données, qui sont toutes hébergées sur un seul disque par serveur. L'élément clé est que le nombre de copies de chaque base de données dont vous disposez doit être égal au nombre de copies de base de données sur chaque disque. Dans l'exemple ci-dessus, il existe quatre copies de chaque base de données : une copie active, deux copies passives et une copie retardée. Puisqu'il existe quatre copies de chaque base de données, la bonne configuration est celle qui comporte quatre copies par volume. En outre, la préférence d'activation est configurée afin d'être équilibrée dans le DAG et sur chaque serveur. Par exemple, la copie active aura une valeur de préférence d'activation de 1, la première copie passive une valeur de préférence d'activation de 2, la deuxième copie passive une valeur de préférence d'activation de 3 et la copie retardée une valeur de préférence d'activation de 4.The above configuration provides a symmetrical design. All four servers have the same four databases all hosted on a single disk per server. The key is that the number of copies of each database that you have should be equal to the number of database copies per disk. In the above example, there are four copies of each database: one active copy, two passive copies, and one lagged copy. Because there are four copies of each database, the proper configuration is one that has four copies per volume. In addition, activation preference is configured so that it's balanced across the DAG and across each server. For example, the active copy will have an activation preference value of 1, the first passive copy will have an activation preference value of 2, the second passive copy will have an activation preference value of 3, and the lagged copy will have an activation preference value of 4.

En plus de fournir une meilleure répartition des utilisateurs dans les volumes existants, l’utilisation de plusieurs bases de données par disque offre l’avantage supplémentaire de réduire la durée de restauration de la protection des données en cas de défaillance nécessitant un réamorçage (par exemple, une défaillance de disque).In addition to having a better distribution of users across the existing volumes, another benefit of using multiple databases per disk is that it reduces the amount of time to restore data protection in the event of a failure that necessitates a reseed (for example, disk failure).

À mesure que la taille d’une base de données augmente, son réamorçage prend de plus en plus de temps. Par exemple, le réamorçage d’une base de données de 2 téraoctets peut prendre 23 heures, alors que le réamorçage d’une base de données de 8 téraoctets peut prendre jusqu’à 93 heures (presque 4 jours). Les deux amorçages se produiraient à une fréquence moyenne de 20 Mo par seconde. Cela signifie généralement qu’une base de données de très grande taille ne peut pas être amorcée dans un délai raisonnable sur le plan opérationnel.As a database gets bigger, reseeding the database takes longer. For example, a 2-terabyte database could take 23 hours to reseed, whereas an 8-terabyte database could take as long as 93 hours (almost 4 days). Both seeds would occur at about 20 MB per second. This generally means that a very large database can't be seeded within an operationally reasonable amount of time.

Dans un scénario impliquant une seule copie de base de données par disque, l’opération d’amorçage est effectivement liée à la source, car elle amorce toujours le disque à partir d’une seule source. En divisant le volume en plusieurs copies de base de données et en stockant sur des membres de DAG distincts la copie active des bases de données passives d’un volume donné, le système n’est plus lié à la source dans le contexte de réamorçage du disque. Lorsqu’un disque défectueux est remplacé, il peut être réamorcé depuis plusieurs sources. Cela permet au système de réamorcer et de restaurer la protection des données pour ces bases de données dans un délai beaucoup plus court.In the case of a single database copy per disk scenario, the seeding operation is effectively source-bound, because it's always seeding the disk from a single source. By dividing the volume into multiple database copies, and by having the active copy of the passive databases on a specified volume stored on separate DAG members, the system is no longer source bound in the context of reseeding the disk. When a failed disk is replaced, it can be reseeded from multiple sources. This allows the system to reseed and restore data protection for these databases in a much shorter amount of time.

Si vous utilisez plusieurs bases de données par volume, nous vous recommandons de respecter les meilleures pratiques et exigences suivantes :When using multiple databases per volume, we recommend adhering to the following best practices and requirements:

  • Utilisez une seule partition de disque logique unique par disque physique. Ne créez pas plusieurs partitions sur le disque. Chaque copie de base de données et ses fichiers compagnons (tels que les journaux des transactions et l’index de contenu) doivent être hébergés dans un répertoire unique de la partition unique.A single logical disk partition per physical disk must be used. Don't create multiple partitions on the disk. Each database copy and its companion files (such as transaction logs and content index) should be hosted in a unique directory on the single partition.

  • Le nombre de copies de base de données configurées par volume doit être égal au nombre de copies de chaque base de données. Par exemple, si vous avez quatre copies de vos bases de données, vous devez utiliser quatre copies de base de données par volume.The number of database copies configured per volume should be equal to the number of copies of each database. For example, if you have four copies of your databases, you should use four database copies per volume.

  • Les copies de base de données doivent avoir les mêmes voisins. (par exemple, elles doivent toutes partager le même disque sur chaque serveur.)Database copies should have the same neighbors. (For example, they should all share the same disk on each server.)

  • La préférence d’activation sur le DAG doit être équilibrée afin que chaque copie de base de données sur un disque ait une valeur unique de préférence d’activation.Activation preference across the DAG should be balanced, such that each database copy on a specified disk has a unique activation preference value.

AutoReseedAutoReseed

La fonctionnalité de réamorçage automatique, AutoReseed, remplace une action généralement initiée par l'administrateur en cas de défaillance d'un disque, d'endommagement d'une base de données ou de tout autre problème nécessitant le réamorçage d'une copie de base de données. La fonctionnalité AutoReseed permet de restaurer automatiquement la redondance de base de données après une défaillance de disque par le biais de disques de rechange qui ont été configurés sur le système.Automatic reseed, or AutoReseed, is a feature that's the replacement for what is normally administrator-driven action in response to a disk failure, database corruption event, or other issue that necessitates a reseed of a database copy. AutoReseed is designed to automatically restore database redundancy after a disk failure by using spare disks that have been provisioned on the system.

Pour plus d'informations, voir Fonctionnalité AutoReseed. Pour obtenir la procédure détaillée de configuration de la fonctionnalité AutoReseed, voir Configuration d'AutoReseed pour un groupe de disponibilité de base de données.For more information, see AutoReseed. For detailed steps to configure AutoReseed, see Configure AutoReseed for a database availability group.

Récupération automatique suite à des défaillances de stockageAutomatic recovery from storage failures

Suite à des défaillances de stockage permet la récupération suite à des défaillances qui affectent la résistance ou la redondance du système. Outre les comportements de vérification d’erreur introduites dans les versions antérieures, 2016 Exchange inclut les comportements de récupération supplémentaires pour la consommation excessive de mémoire par le service de réplication Microsoft Exchange (MSExchangeRepl.exe) et le pire des cas, les temps d’e/s élevés où les threads ne peuvent pas être planifiées.Automatic recovery from storage failures allows the system to recover from failures that affect resiliency or redundancy. In addition to bugcheck behaviors introduced in earlier versions, Exchange 2016 includes additional recovery behaviors for long I/O times, excessive memory consumption by the Microsoft Exchange Replication service (MSExchangeRepl.exe), and severe cases where threads can't be scheduled.

Même dans les environnements JBOD, contrôleurs de baie de stockage peuvent avoir des problèmes, tels que les blocages ou négatif. Le tableau suivant répertorie les fonctionnalités qui fournissent bloqué e/s détection et récupération des fonctionnalités qui fournissent la résilience améliorée.Even in JBOD environments, storage array controllers can have issues, such as crashing or hanging. The following table lists features that provide hung I/O detection and recovery features that provide enhanced resilience.

NomName VérificationCheck ActionAction SeuilThreshold
Détection des E/S bloquées de la base de données ESEESE Database Hung IO Detection
ESE recherche la présence d'E/S exceptionnellesESE checks for outstanding I/Os
Génère un élément de défaillance dans le canal Crimson pour redémarrer le serveurGenerates a failure item in the crimson channel to restart the server
240 secondes240 seconds
Pulsation du canal des éléments défectueuxFailure Item Channel Heartbeat
S'assure que les éléments de défaillance peuvent être écrits vers le canal Crimson et lus à partir de ce dernierEnsures failure items can be written to and read from crimson channel
Le service de réplication contrôle la pulsation du canal Crimson et redémarre le serveur suite à des défaillancesReplication service heartbeats crimson channel and restart server on failures
30 secondes30 seconds
Pulsation de disque systèmeSystem Disk Heartbeat
Vérifie l'état du disque système du serveurVerifies server's system disk state
Envoie régulièrement des E/S non mises en mémoire tampon au disque système ; redémarre le serveur à l'expiration du délai de pulsationPeriodically sends unbuffered I/O to system disk; restarts server on heartbeat time out
120 secondes120 seconds

Exchange 2016 améliore la résilience de serveur et de stockage en y compris les comportements d’autres conditions graves. Ces conditions et les comportements décrits dans le tableau suivant.Exchange 2016 enhances server and storage resilience by including behaviors for other serious conditions. These conditions and behaviors are described in the following table.

NomName VérificationCheck ActionAction SeuilThreshold
État du système incorrectSystem bad state
Aucun thread, y compris les threads non gérés, ne peut être planifiéNo threads, including non-managed threads, can be scheduled
Redémarrer le serveurRestart the server
302 secondes302 seconds
Temps d'E/S élevésLong I/O times
Mesures de la latence de fonctionnement des E/SI/O operation latency measurements
Redémarrer le serveurRestart the server
41 secondes41 seconds
Utilisation de la mémoire du service de réplicationReplication service memory use
Mesurer la plage de travail de MSExchangeRepl.exeMeasure the working set of MSExchangeRepl.exe
1 : enregistrer l’événement 4395 dans le canal crimson avec une demande de terminaison de service1: Log event 4395 in the crimson channel with a service termination request
2 : initier la fin de MSExchangeRepl.exe2: Initiate termination of MSExchangeRepl.exe
3 : si la fin du service échoue, redémarrez le serveur3: If service termination fails, restart the server
4 gigaoctets (Go)4 gigabyte (GB)
Événement système 129 (réinitialisation du bus)System Event 129 (Bus reset)
Vérifier la présence de l'événement 129 dans les journaux des événements systèmeCheck for Event 129 in System event log
Redémarrer le serveurRestart the server
Lorsque l'événement se produitWhen event occurs
Blocage de la base de données de clusterCluster database hang
Les mises à jour du Gestionnaire de mises à jour globales sont bloquéesGlobal Update Manager updates are blocked
Redémarrer le serveurRestart the server
Lorsque l'événement se produitWhen event occurs

Améliorations apportées à la copie retardéeLagged copy enhancements

Améliorations de la copie retardée incluent l’intégration avec Safety Net- and -play automatique vers le bas des fichiers journaux dans certains scénarios. Filet de sécurité introduite dans Exchange 2013, est une fonctionnalité de transport qui remplacé la fonctionnalité Exchange 2010 appelée transport benne. Filet de sécurité est similaire à transport benne, en ce sens qu’il s’agit d’une file d’attente de remise est associé le service de Transport sur un serveur de boîtes aux lettres. Cette file d’attente stocke les copies des messages qui ont été remis à la base de données de boîtes aux lettres actives sur le serveur de boîtes aux lettres. Chaque base de données de boîtes aux lettres actives sur le serveur de boîtes aux lettres possède sa propre file d’attente qui stocke les copies des messages remis. Vous pouvez spécifier la durée pendant laquelle Safety Net stocke les copies des messages remis avec succès avant leur expiration et sont automatiquement supprimés.Lagged copy enhancements include integration with Safety Net and automatic play down of log files in certain scenarios. Safety Net, introduced in Exchange 2013, is a feature of transport that replaced the Exchange 2010 feature known as transport dumpster. Safety Net is similar to transport dumpster, in that it's a delivery queue that's associated with the Transport service on a Mailbox server. This queue stores copies of messages that were successfully delivered to the active mailbox database on the Mailbox server. Each active mailbox database on the Mailbox server has its own queue that stores copies of the delivered messages. You can specify how long Safety Net stores copies of the successfully delivered messages before they expire and are automatically deleted.

Safety Net assume une part de responsabilité en ce qui concerne la redondance des clichés instantanés dans des environnements DAG. Dans les environnements DAG, la redondance des clichés instantanés n'a pas besoin de conserver une autre copie du message remis dans une file d'attente de clichés instantanés pendant qu'elle attend que message remis soit répliqué vers les copies passives des bases de données de boîtes aux lettres sur les autres serveurs de boîtes aux lettres du DAG. La copie du message remis est déjà stockée dans Safety Net. Ainsi, la redondance des clichés instantanés peut de nouveau remettre le message à partir de Safety Net si nécessaire.Safety Net takes some responsibility from shadow redundancy in DAG environments. In DAG environments, shadow redundancy doesn't need to keep another copy of the delivered message in a shadow queue while it waits for the delivered message to replicate to the passive copies of mailbox databases on the other Mailbox servers in the DAG. The copy of the delivered message is already stored in Safety Net, so shadow redundancy can redeliver the message from Safety Net if necessary.

Filet de sécurité, l’activation d’une copie retardée de base de données devient beaucoup plus facile. Par exemple, imaginons une copie retardée ayant un retard de relecture de 2 jours. Dans ce cas, vous configurerez filet de sécurité pour une période de 2 jours. Si vous rencontrez une situation dans laquelle vous devez utiliser votre copie retardée, vous pouvez suspendre la réplication lui et copiez-le à deux reprises (pour préserver la nature retardée de la base de données et pour créer une copie supplémentaire au cas où vous avez besoin). Ensuite, une copie et supprimer tous les fichiers journaux, à l’exception de ceux de la plage requise. Montez la copie, ce qui déclenche une demande automatique à filet de sécurité pour remettre les deux derniers jours de la messagerie. Filet de sécurité, vous n’êtes pas obligé de recherche pour où le point de corruption a été introduit. Vous obtenez le dernier courrier deux jours, moins les données perdues généralement sur un basculement avec perte.With Safety Net, activating a lagged database copy becomes significantly easier. For example, consider a lagged copy that has a 2-day replay lag. In that case, you would configure Safety Net for a period of 2 days. If you encounter a situation in which you need to use your lagged copy, you can suspend replication to it, and copy it twice (to preserve the lagged nature of the database and to create an extra copy in case you need it). Then, take a copy and discard all the log files, except for those in the required range. Mount the copy, which triggers an automatic request to Safety Net to redeliver the last two days of mail. With Safety Net, you don't need to hunt for where the point of corruption was introduced. You get the last two days mail, minus the data ordinarily lost on a lossy failover.

Les copies retardées peuvent désormais se gérer elles-mêmes en appelant la relecture automatique des journaux pour lire les fichiers journaux dans certains scénarios :Lagged copies can now care for themselves by invoking automatic log replay to play down the log files in certain scenarios:

  • Lorsque le seuil d'espace disque faible est atteintWhen a low disk space threshold is reached

  • Lorsque la copie retardée est physiquement endommagée et doit faire l'objet d'une mise à jour corrective de pagesWhen the lagged copy has physical corruption and needs to be page patched

  • Quand il y a moins de trois copies intègres disponibles (actives ou passives uniquement, les copies de base de données retardées ne sont pas comptées) pendant plus de 24 heuresWhen there are fewer than three available healthy copies (active or passive only; lagged database copies are not counted) for more than 24 hours

Dans Exchange 2010, mise à jour corrective de page n’est pas disponible pour les copies retardées. Dans Exchange 2016, mise à jour corrective de page est disponible pour les copies retardées par le biais de cette fonctionnalité de lecture automatique. Si le système détecte que la mise à jour corrective de page est requis pour une copie retardée, les journaux sont automatiquement relus dans la copie retardée pour effectuer la mise à jour corrective de page. Copies retardées également appellent cette fonctionnalité de relecture automatique des lorsque le seuil d’espace disque faible est atteint, et lorsque la copie retardée a été détectée comme la copie disponible uniquement pour une période spécifique.In Exchange 2010, page patching wasn't available for lagged copies. In Exchange 2016, page patching is available for lagged copies through this automatic play down feature. If the system detects that page patching is required for a lagged copy, the logs are automatically replayed into the lagged copy to perform page patching. Lagged copies also invoke this auto replay feature when a low disk space threshold has been reached, and when the lagged copy has been detected as the only available copy for a specific period of time.

Le comportement de lecture de copie retardée est désactivé par défaut, mais peut être activé en exécutant la commande suivante :Lagged copy play down behavior is disabled by default, and can be enabled by running the following command.

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

Une fois activée, la lecture a lieu lorsque le nombre de copies est inférieur à trois. Vous pouvez modifier la valeur 3 par défaut en changeant la valeur de registre DWORD suivante :After being enabled, play down occurs when there are fewer than three copies. You can change the default value of 3, by modifying the following DWORD registry value.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopiesHKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

Pour activer la lecture pour les seuils d'espace disque faible, vous devez configurer l'entrée de registre suivante :To enable play down for low disk space thresholds, you must configure the following registry entry.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMBHKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

Après avoir configuré un de ces paramètres de registre, redémarrez le service de gestion des groupes de disponibilité de base de données (DAG) Microsoft Exchange pour que les modifications prennent effet.After configuring either of these registry settings, restart the Microsoft Exchange DAG Management service for the changes to take effect.

À titre d’exemple, prenons un environnement où une base de données dispose de 4 copies (3 copies hautement disponibles et une copie retardée), et où le paramètre par défaut est utilisé pour ReplayLagManagerNumAvailableCopies. Si une copie non retardée est hors de service pour une raison quelconque (elle est par exemple suspendue, etc.), la copie retardée lira automatiquement ses fichiers journaux dans les 24 heures.As an example, consider an environment where a given database has 4 copies (3 highly available copies and 1 lagged copy), and the default setting is used for ReplayLagManagerNumAvailableCopies. If a non-lagged copy is out-of-service for any reason (for example, it is suspended, etc.) then the lagged copy will automatically play down its log files in 24 hours.

Améliorations apportées à l'alerte de copie uniqueSingle copy alert enhancements

S’assurer que vos serveurs fonctionnent correctement et que les copies de base de données de boîtes aux lettres sont sains est des objectifs principaux de tous les jours Exchange 2016 opérations de messagerie. Vous devez surveiller activement le matériel, le système d’exploitation Windows et les services Exchange. Mais lors de l’exécution dans un environnement de résilience de boîte aux lettres Exchange 2016, il est important de surveiller l’intégrité et l’état de DAG et les copies de base de données de boîtes aux lettres. Il est particulièrement indispensable pour effectuer la gestion des risques de la redondance des données et surveiller pour les périodes où est une base de données répliquée jusqu'à une copie unique. Ceci est particulièrement important dans les environnements qui ne pas utiliser d’indépendante des disques RAID (Redundant Array) et déployer des configurations JBOD au lieu de cela. Dans un environnement RAID, une défaillance de disque n’affecte pas une copie de base de données de boîtes aux lettres actives. Toutefois, dans un environnement JBOD, une défaillance de disque entraînera un basculement de base de données.Ensuring that your servers are operating reliably and that your mailbox database copies are healthy are primary objectives of daily Exchange 2016 messaging operations. You must actively monitor the hardware, the Windows operating system, and the Exchange services. But when running in an Exchange 2016 mailbox resiliency environment, it's important that you monitor the health and status of the DAG and your mailbox database copies. It's especially vital to perform data redundancy risk management and monitor for periods in which a replicated database is down to just a single copy. This is particularly critical in environments that don't use Redundant Array of Independent Disks (RAID) and instead deploy JBOD configurations. In a RAID environment, a single disk failure doesn't affect an active mailbox database copy. However, in a JBOD environment, a single disk failure will trigger a database failover.

Dans Exchange 2010, le script CheckDatabaseRedundancy.ps1 a été introduit. Comme son nom l'indique, l'objet du script était de surveiller la redondance des bases de données de boîtes aux lettres répliquées en vérifiant qu'au moins deux copies configurées sont à jour et intègres. Le script prévient un administrateur, via la génération du journal des événements, s'il n'existe qu'une seule copie intègre d'une base de données répliquée. Dans ce cas, il compte les copies actives et passives pour déterminer la redondance des bases de données.In Exchange 2010, the script CheckDatabaseRedundancy.ps1 was introduced. As its name implies, the purpose of the script was to monitor the redundancy of replicated mailbox databases by validating that there is at least two configured, healthy, and current copies, and to alert an administrator through event log generation when only a single healthy copy of a replicated database exists. In this case, both active and passive copies are counted when determining redundancy.

Les conditions de copie unique incluent, entre autres :Single copy conditions include, but aren't limited to:

  • Échec de la réplication d'une copie active vers une copie passive.Failure of an active copy to replicate to any passive copy.

  • Échec de toutes les copies passives ; cela inclut les états FailedAndSuspended et Failed, en plus des états d’intégrité où la copie se trouve derrière lors de la relecture ou de la copie de journal. Notez que les copies retardées ne sont pas considérées comme étant derrière si elles sont dans l’intervalle de dix minutes de relecture de leurs journaux par rapport à la période de retard.Failure of all passive copies, which includes FailedAndSuspended and Failed states in addition to healthy states where the copy is behind in log copying or replay. Note that lagged copies aren't considered behind if they're within ten minutes in replaying their logs to their lag period.

  • Échec de l'identification précise par le système de la génération actuelle du journal de la copie active.Failure of the system to accurately know the current log generation of the active copy.

Puisque la priorité absolue des administrateurs est de savoir quand il ne reste plus qu'une seule copie intègre d'une base de données, le script CheckDatabaseRedundancy.ps1 a été remplacé par une fonctionnalité native intégrée faisant partie du groupe d'intégrité DataProtection de la disponibilité gérée.Because it's a top priority for administrators to know when they're down to a single healthy copy of a database, the CheckDatabaseRedundancy.ps1 script has been replaced with integrated, native functionality that's part of managed availability's DataProtection Health Set.

La fonctionnalité native alerte toujours les administrateurs via les notifications du journal des événements, mais pour distinguer les alertes de 2016 Exchange à partir d’Exchange 2010, Exchange 2016 utilise l’ID d’événement suivants :The native functionality still alerts administrators through event log notifications, and to distinguish Exchange 2016 alerts from Exchange 2010, Exchange 2016 uses the following Event IDs:

  • Événement 4138 (alerte rouge)Event 4138 (Red Alert)

  • Événement 4139 (alerte verte)Event 4139 (Green Alert)

Dans Exchange 2016, la fonctionnalité native est améliorée pour réduire le niveau de bruit de l’alerte qui peut se produire lorsque plusieurs bases de données sur le même serveur entrent dans une condition de copie unique. Dans la version précédente d’Exchange, les alertes de copie unique ont été créées sur un niveau par base de données. Par conséquent, qu’il y a un problème au niveau du serveur qui ont affecté les bases de données de plusieurs et plusieurs copies de base de données, vagues d’alertes peuvent se produire. Plusieurs échecs, tel que contrôleur ou des problèmes de mémoire sont au niveau du serveur, il n’a pas été Moyennement haute probabilité qu’une telle vague d’alertes se produise pour chaque incident de serveur. Dans Exchange 2016, alertes sont générés sur chaque serveur. Lorsqu’une panne affecte un serveur entier et la redondance de données devient exposés à plusieurs copies de base de données, une alerte par serveur est maintenant générée.In Exchange 2016, the native functionality is enhanced to reduce the level of alert noise that can occur when multiple databases on the same server enter into a single copy condition. In previous version of Exchange, single copy alerts were generated on a per-database level. As a result, when there was a server-wide issue that affected multiple databases and multiple database copies, alert storms could occur. Because several failures, such as controller or memory problems, are server-wide, there was a moderately high probability that such an alert storm would occur for each server incident. In Exchange 2016, alerts are generated on a per-server basis. When an outage affects an entire server and data redundancy becomes at risk for multiple database copies, a single alert per server is now generated.

Configuration automatique de réseau DAGDAG network auto-configuration

Un réseau DAG regroupe un ou plusieurs sous-réseaux utilisés soit pour le trafic de réplication, soit pour le trafic MAPI. Chaque DAG contient au maximum un réseau MAPI et aucun, un ou plusieurs réseaux de réplication. Dans Exchange 2010, les réseaux DAG initiaux (par exemple, DAGNetwork01 et DAGNetwork02) étaient créés par le système à partir des sous-réseaux énumérés par le service de cluster. Dans les environnements où plusieurs réseaux étaient utilisés et où les interfaces d'un réseau donné (par exemple, le réseau MAPI) se trouvaient sur le même sous-réseau, l'administrateur devait effectuer une petite configuration supplémentaire. Cependant, dans les environnements où les interfaces d'un réseau donné se trouvaient sur plusieurs sous-réseaux, l'administrateur devait effectuer une tâche appelée réduction des réseaux DAG.A DAG network is a collection of one or more subnets used for either replication traffic or MAPI traffic. Each DAG contains a maximum of one MAPI network and zero or more replication networks. In Exchange 2010, the initial DAG networks (for example, DAGNetwork01 and DAGNetwork02) were created by the system based on the subnets enumerated by the Cluster service. In environments where multiple networks are used and the interfaces for a specified network (for example, the MAPI network) were on the same subnet, there was little additional configuration that an administrator needed to perform. However, in environments where the interfaces for a specified network were on multiple subnets, the administrator had to perform a task referred to as collapsing DAG networks.

Dans Exchange 2016, réduction des réseaux DAG n’est plus nécessaire. 2016 Exchange utilise toujours les mêmes mécanismes de détection pour faire la distinction entre les réseaux MAPI et la réplication, mais il réduit maintenant automatiquement les réseaux DAG comme il convient.In Exchange 2016, collapsing DAG networks is no longer necessary. Exchange 2016 still uses the same detection mechanisms to distinguish between the MAPI and replication networks, but it now automatically collapses DAG networks as appropriate.

En outre, par défaut, les réseaux DAG sont désormais automatiquement gérés par le système. Pour afficher les propriétés de réseau DAG à l’aide du centre d’Administration Exchange (CAE), vous devez configurer le DAG pour le contrôle réseau manuelle en modifiant les propriétés du DAG à l’aide du centre d’administration Exchange, ou à l’aide de l’applet de commande Set-DatabaseAvailabilityGroup pour définir le ManualDagNetworkConfiguration paramètre True.In addition, by default, DAG networks are now automatically managed by the system. To view DAG network properties using the Exchange Administration Center (EAC), you must configure the DAG for manual network control by modifying the properties of the DAG using EAC, or by using the Set-DatabaseAvailabilityGroup cmdlet to set the ManualDagNetworkConfiguration parameter to True.

Modifications apportées à la sélection de la meilleure copieChanges to best copy selection

La sélection de la meilleure copie (Best Copy Selection, BCS) est un processus d'algorithme interne permettant de rechercher la meilleure copie d'une base de données individuelle à activer, en fonction d'une liste de copies potentielles disponibles pour l'activation, de leur intégrité et de leur état. Active Manager sélectionne la meilleure copie disponible (et non bloquée) pour qu'elle devienne la nouvelle copie de base de données active en cas d'échec de la copie existante, ou si un administrateur effectue un basculement non ciblé. Dans Exchange 2010, le processus de sélection de la meilleure copie (BCS) a évalué plusieurs aspects de chaque copie de base de données pour déterminer la meilleure copie à activer. Il s'agit notamment des points suivants :Best copy selection (BCS) is an internal algorithm process for finding the best copy of an individual database to activate, given a list of potential copies for activation and their health and status. Active Manager selects the best available (and unblocked) copy to become the new active database copy when the existing active database copy fails or when an administrator performs a targetless switchover. In Exchange 2010, the BCS process evaluated several aspects of each database copy to determine the best copy to activate. These included:

  • Longueur de la file d'attente de copieCopy queue length

  • Longueur de la file d'attente de relectureReplay queue length

  • État de la base de donnéesDatabase status

  • État de l'index de contenuContent index status

Dans Exchange 2016, Gestionnaire Active Manager effectue les mêmes vérifications de BCS et phases pour déterminer l’état de réplication, mais il maintenant inclut également l’utilisation d’une contrainte de l’ordre décroissant des États d’intégrité. À la suite de ces modifications, BCS s’appelle désormais meilleure copie et sélection du serveur (BCSS).In Exchange 2016, Active Manager performs the same BCS checks and phases to determine replication health, but it now also includes the use of a constraint of the decreasing order of health states. As a result of these changes, BCS is now called best copy and server selection (BCSS).

BCSS inclut plusieurs nouveaux contrôles d’intégrité qui font partie de la disponibilité gérée intégrée dans les composants dans Exchange 2016 de surveillance. Il existe quatre contrôles supplémentaires effectuées par le Gestionnaire Active (répertoriés dans l’ordre dans lequel elles sont exécutées) :BCSS includes several new health checks that are part of the built in managed availability monitoring components in Exchange 2016. There are four additional checks performed by Active Manager (listed in the order in which they're performed):

  1. Tous les intègre: recherche un serveur hébergeant une copie de la base de données concernée dispose tous les composants de surveillance dans un état intègre.All Healthy: Checks for a server hosting a copy of the affected database that has all monitoring components in a healthy state.

  2. Jusqu'à intègre Normal: recherche un serveur hébergeant une copie de la base de données concernée dispose tous les composants de surveillance avec une priorité normale dans un état intègre.Up to Normal Healthy: Checks for a server hosting a copy of the affected database that has all monitoring components with Normal priority in a healthy state.

  3. Tous les mieux que Source: recherche un serveur hébergeant une copie de la base de données dont la surveillance des composants dans un état qui est préférable que le serveur actuel qui héberge la copie concernée.All Better than Source: Checks for a server hosting a copy of the affected database that has monitoring components in a state that's better than the current server hosting the affected copy.

  4. Identique à la Source: recherche un serveur hébergeant une copie de la base de données dont la surveillance des composants dans un état qui est le même que le serveur actuel qui héberge la copie concernée.Same as Source: Checks for a server hosting a copy of the affected database that has monitoring components in a state that's the same as the current server hosting the affected copy.

Si BCSS est appelé suite à un basculement déclenché par un composant de surveillance de disponibilité gérée (par exemple, via un répondeur à basculement), le système applique une contrainte obligatoire supplémentaire selon laquelle l’intégrité du composant du serveur cible doit être meilleure que celle du serveur sur lequel le basculement s’est produit. Par exemple, si un échec de Microsoft Office Outlook Web App déclenche un basculement de disponibilité gérée via un répondeur à basculement, BCSS doit sélectionner un serveur hébergeant une copie de la base de données concernée sur laquelle Outlook Web App est intègre.If BCSS is invoked as a result of a failover that's triggered by a managed availability monitoring component (for example, via a Failover responder), an additional mandatory constraint is enforced where the target server's component health must be better than the server on which the failover occurred. For example, if a failure of Microsoft Office Outlook Web App triggers a managed availability failover via a Failover responder, BCSS must select a server hosting a copy of the affected database on which Outlook Web App is healthy.

Service de gestion des groupes de disponibilité de base de données (DAG)DAG Management Service

Exchange 2016 contient un nouveau service sur les serveurs de boîtes aux lettres qui sont membres d’un DAG. Ce service est appelé Service de gestion de Microsoft Exchange DAG (MSExchangeDAGMgmt). Ce service offre des fonctionnalités surveillance interne DAG précédemment exécutées à l’intérieur du service de réplication Microsoft Exchange (MSExchangeRepl).Exchange 2016 contains a new service on Mailbox servers that are members of a DAG. This service is called the Microsoft Exchange DAG Management Service (MSExchangeDAGMgmt). This service contains internal DAG monitoring functionality that previously executed inside the Microsoft Exchange Replication service (MSExchangeRepl).

Groupes de disponibilité de base de données (DAG) sans point d'accès administratif de clusterDAGs without a cluster administrative access point

Tous les DAG exécutant Windows Server 2008 R2 ou Windows Server 2012 nécessitent au moins une adresse IP sur chaque sous-réseau inclus dans le réseau MAPI. Les adresses IP attribuées au DAG sont utilisées par le cluster du DAG avec le point d'accès administratif du cluster (également appelé nom du réseau de cluster) pour permettre la résolution du nom et la connectivité au cluster (ou plus précisément, la connectivité au membre du cluster qui détient actuellement le groupe de ressources principal du cluster) à l'aide du nom de cluster. Windows Server 2012 R2 vous permet de créer un cluster de basculement sans point d'accès administratif. Les clusters de basculement Windows sans points d'accès administratif ont les caractéristiques suivantes :All DAGs running Windows Server 2008 R2 or Windows Server 2012 require at least one IP address on every subnet included in the MAPI network. The IP address(es) assigned to the DAG are used by the DAG's cluster with the cluster's administrative access point (also known as the cluster network name) to enable name resolution and connectivity to the cluster (or more precisely, connectivity to the cluster member that currently owns the cluster core resource group) using the cluster name. Windows Server 2012 R2 enables you to create a failover cluster without an administrative access point. Windows failover clusters without administrative access points have the following characteristics:

  • Aucune adresse IP n'est attribuée au cluster, par conséquent il n'y a pas de ressource d'adresse IP dans le groupe de ressources principal du cluster.There is no IP address assigned to the cluster, and therefore no IP Address Resource in the cluster core resource group.

  • Aucun nom réseau n'est attribué au cluster, par conséquent il n'y a aucune ressource de nom de réseau dans le groupe de ressources principal du cluster.There is no network name assigned to the cluster, and therefore no Network Name Resource in the cluster core resource group

  • Le nom du cluster n'est pas enregistré dans le DNS et il ne peut pas être résolu sur le réseau.The name of the cluster is not registered in DNS, and it is not resolvable on the network.

  • Aucun objet nom de cluster (CNO) n'est créé dans Active Directory.A cluster name object (CNO) is not created in Active Directory.

  • Le cluster de basculement Windows ne peut pas être géré à l'aide de l'outil de gestion du cluster de basculement. Il doit être géré à l'aide de Windows PowerShell et les cmdlets PowerShell doivent être exécutées sur des membres individuels du cluster.The Windows failover cluster cannot be managed using the Failover Cluster Management tool. It must be managed using Windows PowerShell, and the PowerShell cmdlets must be run against individual cluster members.

Lors de l’exécution sur Windows Server 2012 R2 ou version ultérieure, 2016 Exchange vous permet de créer un DAG sans point d’accès administratif de cluster. Vous pouvez créer un DAG sans point d’accès administratif à l’aide du centre d’administration Exchange ou à l’aide de l’environnement Exchange Management Shell. Pour plus d’informations, voir Création d’un DAG et créer un groupe de disponibilité de base de données.When running on Windows Server 2012 R2 or later, Exchange 2016 enables you to create a DAG without a cluster administrative access point. You can create a DAG without an administrative access point using the Exchange admin center or by using the Exchange Management Shell. For more information, see Creating DAGs and Create a database availability group.