Modifications apportées à la haute disponibilité et à la résilience de site par rapport aux versions précédentes

S’applique à : Exchange Server 2013 SP1

Exchange 2013 utilise des groupes de disponibilité de base de données et des copies de bases de données de boîtes aux lettres, en plus d'autres fonctionnalités comme la récupération d'élément unique, les stratégies de rétention et les copies de bases de données retardées pour fournir la haute disponibilité, la résilience de site et la protection des données natives d'Exchange. La plateforme de haute disponibilité, La banque d’informations Exchange et le moteur de stockage extensible (ESE) sont améliorées pour offrir une plus grande disponibilité et une gestion plus facile, et pour réduire les coûts. Ces améliorations sont les suivantes :

• Réduction des IOPS par rapport à Exchange 2010 : cela vous permet de tirer parti de disques plus volumineux en termes de capacité et d’IOPS aussi efficacement que possible.

• Disponibilité gérée: avec la disponibilité gérée, la surveillance interne et les fonctionnalités orientées récupération sont étroitement intégrées afin d'aider à prévenir les pannes, à restaurer proactivement les services et à initialiser les basculements automatiques de serveurs ou à alerter les administrateurs afin qu'ils prennent des mesures. L'accent est mis sur le suivi et la gestion de l'expérience utilisateur final plutôt que simplement sur le temps d'activité du serveur et des composants pour contribuer à la conservation d'une disponibilité permanente du service.

• Magasin géré : le magasin géré est le nom des nouveaux processus de magasin d’informations réécrits dans Exchange 2013. La nouvelle Banque gérée est écrite en C# et elle est étroitement intégrée avec le Service de réplication Microsoft Exchange (MSExchangeRepl.exe) afin de fournir une plus grande disponibilité grâce à une résilience accrue.

• Prise en charge de plusieurs bases de données par disque : Exchange 2013 inclut des améliorations qui vous permettent de prendre en charge plusieurs bases de données (combinaisons de copies actives et passives) sur le même disque, tirant ainsi parti de disques plus volumineux en termes de capacité et d’IOPS aussi efficacement que possible.

• AutoReseed : la fonctionnalité de reseeding automatique vous permet de restaurer rapidement la redondance de base de données après une défaillance du disque. Si un disque est défectueux, la copie de la base de données stockée sur ce disque est copiée à partir de la copie de base de données active vers un disque de rechange sur le même serveur. Si plusieurs copies de bases de données ont été stockées sur le disque défectueux, elles peuvent toutes être automatiquement réamorcées sur un disque de rechange. Cela permet des réamorçages plus rapides, car les bases de données actives se trouvent probablement sur de multiples serveurs et les données sont copiées de manière parallèle.

• Récupération automatique après des défaillances de stockage : cette fonctionnalité poursuit l’innovation introduite dans Exchange 2010 pour permettre au système de récupérer après des défaillances qui affectent la résilience ou la redondance. En plus des comportements de case activée de bogues Exchange 2010, Exchange 2013 inclut des comportements de récupération supplémentaires pour des temps d’E/S longs, une consommation de mémoire excessive par MSExchangeRepl.exe et des cas graves où le système est dans un état si mauvais que les threads ne peuvent pas être planifiés.

• Améliorations de la copie en retard : les copies en retard peuvent désormais prendre soin d’elles-mêmes dans une certaine mesure à l’aide de la lecture automatique du journal. Les copies en retard vont automatiquement réduire les fichiers journaux dans différentes situations, telles que les mises à jour correctives de page et les scénarios d’espace disque insuffisant. Si le système détecte qu'une mise à jour corrective de page est nécessaire pour une copie retardée, les journaux sont automatiquement relus dans la copie retardée pour exécuter la mise à jour corrective de page. Les copies décalées appellent également cette fonctionnalité de relecture automatique lorsqu’un seuil d’espace disque faible est atteint et que la copie retardée est détectée comme la seule copie disponible pendant une période spécifique. En outre, les copies en retard peuvent utiliser le filet de sécurité, ce qui facilite la récupération ou l’activation.

• Améliorations apportées aux alertes de copie unique : l’alerte de copie unique introduite dans Exchange 2010 n’est plus un script planifié distinct. Elle est maintenant intégrée aux composants de disponibilité gérée au sein du système et constitue une fonction native dans Exchange.

• Configuration automatique du réseau DAG : les réseaux DAG peuvent être configurés automatiquement par le système en fonction des paramètres de configuration. En plus des options de configuration manuelle, les DAG peuvent aussi faire la distinction entre les réseaux de réplication et MAPI, et configurer des réseaux DAG automatiquement.

Réduction du nombre d’opération d’E/S par seconde par rapport à Exchange 2010

Dans Exchange 2010, les copies de base de données passives ont une 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 l’exécution de ces opérations de pré-lecture agressives, les IOPS pour une copie de base de données passive étaient égales aux IOPS pour une copie active dans Exchange 2010.

Dans Exchange 2013, le système peut fournir un basculement rapide tout en utilisant une grande profondeur de point de contrôle sur la copie passive (100 Mo). Étant donné que les copies passives ont une profondeur de point de contrôle de 100 Mo, elles sont dé-paramétrées pour ne plus être aussi agressives. En raison de l'augmentation de la profondeur de point de contrôle et du déréglage des prélectures agressives, le nombre d'E/S par seconde d'une copie passive correspond à environ la moitié de celui de la copie active dans Exchange 2013.

La définition d'une plus grande profondeur de point de contrôle sur la copie passive génère également d'autres changements. Lors du basculement dans Exchange 2010, le cache de base de données est vidé, car la base de données est convertie d'une copie passive en une copie active. Dans Exchange 2013, la journalisation ESE a été réécrite pour que le cache soit conservé lors de la transition de la copie passive en copie active. Comme ESE n'a pas besoin de vider le cache, vous bénéficiez d'un basculement rapide.

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.

Le résultat de ces changements est qu'Exchange 2013 offre une diminution de moitié du nombre d'E/S par seconde par rapport à Exchange 2010.

Disponibilité gérée

La disponibilité managée est l’intégration de la supervision intégrée et active et de la plateforme de haute disponibilité Exchange 2013. Avec la disponibilité managée, le système peut déterminer quand basculer une base de données en fonction de l’intégrité du service. La disponibilité managée est une infrastructure interne déployée sur les rôles serveur d’accès au client et de boîte aux lettres dans Exchange 2013. La disponibilité managée comprend trois composants asynchrones main qui effectuent constamment un travail. Le premier composant est le moteur de sonde, qui est chargé de prendre des mesures sur le serveur et de collecter des données. Les résultats de ces mesures sont transmis au deuxième composant, le moniteur. Le moniteur contient toute la logique métier utilisée par le système en fonction de ce qui est considéré comme sain sur les données collectées. Comme un moteur de reconnaissance de suites logiques, le moniteur recherche les différentes suites logiques sur toutes les mesures collectées, puis détermine ce qu'il considère comme intègre. Enfin, il y a le moteur de répondeur, qui est responsable des actions de récupération. En cas d'état défectueux, la première action consiste à essayer de récupérer le composant. Il peut s'agir d'actions de récupération en plusieurs étapes ; par exemple, la première tentative peut consister à redémarrer le pool d'applications, la deuxième à redémarrer le service, la troisième à redémarrer le serveur et la suivante à mettre le serveur hors ligne de manière à ce qu'il n'accepte plus aucun trafic. En cas d'échec des actions de récupération, le système réaffecte le problème à un utilisateur au moyen de notifications dans le journal des événements.

La disponibilité gérée est implémentée sous la forme de deux services :

• Service Exchange Health Manager (MSExchangeHMHost.exe) : il s’agit d’un processus de contrôleur utilisé pour gérer les processus de travail. Il est utilisé pour créer, exécuter, démarrer et arrêter le processus de travail selon les besoins. Il est également utilisé pour récupérer le processus de travail en cas de blocage afin d'empêcher que le processus de travail soit un point de défaillance unique.

• Processus du worker Exchange Health Manager (MSExchangeHMWorker.exe) : il s’agit du processus de travail responsable de l’exécution des tâches d’exécution.

La disponibilité gérée utilise un stockage persistant pour remplir ses fonctions :

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

• Le registre est utilisé pour stocker des données d'exécution, telles que des signets.

• L'infrastructure de journal des événements du canal Crimson est utilisée pour stocker les résultats d'éléments de travail.

Pour plus d'informations sur la disponibilité gérée, consultez la rubrique Disponibilité gérée.

Banque gérée

Toutes les versions antérieures d’Exchange Server, d’Exchange Server 4.0 à Exchange Server 2010, prennent en charge l’exécution d’une seule instance du processus de la banque d’informations (Store.exe) sur le rôle serveur de boîte aux lettres. Cette instance de banque unique héberge toutes les bases de données sur le serveur : actives, passives, retardées et de récupération. Dans les architectures Exchange précédentes, il existe peu d’isolation, voire aucune, entre les différentes bases de données hébergées sur un serveur de boîtes aux lettres. Un problème avec une seule base de données de boîtes aux lettres peut avoir un impact négatif sur toutes les autres bases de données, et les incidents résultant d'un endommagement de boîte aux lettres peuvent influer sur le service pour tous les utilisateurs dont les bases de données sont hébergées sur ce serveur.

Un autre défi avec un seul store instance dans les versions précédentes d’Exchange est que le moteur de stockage extensible (ESE) est bien mis à l’échelle vers 8 à 12 cœurs de processeur, mais au-delà, les problèmes de communication interprocesseur et de synchronisation du cache entraînent une mise à l’échelle négative. Étant donné les plus grands serveurs d’aujourd’hui, avec plus de 16 systèmes de base disponibles, cela imposerait le défi administratif de gérer l’affinité de 8 à 12 cœurs pour ESE et d’utiliser les autres cœurs pour les processus non-Store (par exemple, Assistants, Search Foundation, Managed Availability, etc.). De plus, l’architecture précédente restreignait le scale-up pour le processus store.

Le processus Store.exe a considérablement évolué au fil des années, car Exchange Server lui-même a évolué, mais en tant que processus unique, sa scalabilité est limitée et représente un point de défaillance unique. En raison de ces limites, Store.exe a été supprimé dans Exchange 2013 et remplacé par le magasin géré.

Pour plus d'informations, voir Managed Store.

Plusieurs bases de données par volume

Même si les améliorations apportées au stockage dans Exchange 2013 sont d'abord conçues pour les configurations JBOD, elles peuvent être utilisées par toutes les configurations de stockage prises en charge. L'une des fonctionnalités est la possibilité d'héberger plusieurs bases de données sur le même volume. Cette fonctionnalité vise à optimiser Exchange pour les grands disques. Ces optimisations permettent une utilisation beaucoup plus efficace des disques disposant d'une capacité élevée, d'E/S par seconde et de durées de réamorçage, et elles permettent de relever les défis associés à l'exécution dans une configuration de stockage JBOD :

• Les tailles de base de données doivent pouvoir être gérées.

• Les opérations de réamorçage doivent être rapides et fiables.

• La capacité de stockage augmente, contrairement aux E/S par seconde.

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

• Les copies retardées ont des exigences de stockage asymétriques.

• Vous avez peu de marge de manœuvre pour effectuer une récupération à partir d'un espace disque faible.

La tendance à l’augmentation de la capacité de stockage se poursuit, avec des lecteurs de 8 téraoctets qui devraient bientôt être disponibles. Lorsque vous utilisez des lecteurs de 8 téraoctets conjointement avec les recommandations des meilleures pratiques relatives à la taille maximale de base de données Exchange (2 téraoctets), vous gaspillez plus de 5 téraoctets d’espace disque. L’une des solutions consisterait à agrandir les bases de données, mais cela empêche la gestion, car elle introduit de longues durées de reseed, y compris, dans certains cas, des temps de réseed opérationnellement non gérables, et la fiabilité de la copie de cette quantité de données sur le réseau est compromise.

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.

Afin de poursuivre une pratique bien établie, Exchange 2013 est optimisé de façon à pouvoir utiliser plus efficacement des disques de grande taille (8 To) dans une configuration JBOD. Dans Exchange 2013, avec plusieurs bases de données par disque, des disques de même taille peuvent stocker plusieurs copies de base de données, y compris des copies retardées. L'objectif est de gérer la répartition des utilisateurs sur les différents volumes existants, ce qui vous permet de bénéficier d'une conception symétrique où, lors des opérations normales, chaque membre du DAG héberge une combinaison de copies actives, passives et parfois retardées sur les mêmes volumes.

Vous trouverez ci-dessous un exemple de configuration qui utilise 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 a une valeur de préférence d’activation de 1, la première copie passive a une valeur de préférence d’activation de 2, la deuxième copie passive a une valeur de préférence d’activation de 3 et la copie en retard aura une valeur de préférence d’activation de 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).

À mesure que la taille d'une base de données augmente, son réamorçage prend de plus en plus de temps. Par exemple, une base de données de 2 téraoctets peut prendre 23 heures, tandis qu’une base de données de 8 téraoctets peut prendre jusqu’à 93 heures (près de quatre 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.

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 ayant la copie active des bases de données passives sur un volume spécifié stocké sur des membres DAG distincts. Le système n’est plus lié à la source dans le contexte de la réinseration du disque. Lorsqu'un disque défectueux est remplacé, il peut être réamorcé depuis plusieurs sources. Cela permet au système de resserrer et de restaurer la protection des données pour ces bases de données dans un laps de temps plus court.

Si vous utilisez plusieurs bases de données par volume, nous vous recommandons de respecter les meilleures pratiques et exigences suivantes :

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

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

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

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

AutoReseed

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.

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.

Récupération automatique suite à des défaillances de stockage

La récupération automatique suite à des défaillances de stockage s'inscrit dans la continuité des innovations initiées dans Exchange 2010 afin de permettre la récupération du système suite à des défaillances ayant une incidence sur la résilience ou la redondance. En plus des comportements de case activée de bogues Exchange 2010, Exchange 2013 inclut des comportements de récupération supplémentaires pour des temps d’E/S longs, une consommation excessive de mémoire par le service de réplication Microsoft Exchange (MSExchangeRepl.exe) et des cas graves où les threads ne peuvent pas être planifiés.

Même dans les environnements JBOD, les contrôleurs de baies de stockage peuvent rencontrer des problèmes, tels qu'un arrêt ou un blocage. Exchange 2010 incluait des fonctionnalités de détection et de récupération des E/S bloquées qui assuraient une meilleure résilience. Ces fonctions sont répertoriées dans le tableau suivant.

Nom	Vérifier	Action	Seuil
Détection des E/S bloquées de la base de données ESE	ESE recherche la présence d'E/S exceptionnelles	Génère un élément de défaillance dans le canal Crimson pour redémarrer le serveur	240 secondes
Pulsation du canal des éléments défectueux	S'assure que les éléments de défaillance peuvent être écrits vers le canal Crimson et lus à partir de ce dernier	Le service de réplication contrôle la pulsation du canal Crimson et redémarre le serveur suite à des défaillances	30 secondes
Pulsation de disque système	Vérifie l'état du disque système du serveur	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 pulsation	120 secondes

Exchange 2013 améliore la résilience du serveur et du stockage en incluant de nouveaux comportements pour d'autres situations sérieuses. Ces conditions et comportements sont décrits dans le tableau suivant.

Nom	Vérifier	Action	Seuil
État du système incorrect	Aucun thread, y compris les threads non gérés, ne peut être planifié	Redémarrer le serveur	302 secondes
Temps d'E/S élevés	Mesures de la latence de fonctionnement des E/S	Redémarrer le serveur	41 secondes
Utilisation de la mémoire du service de réplication	Mesurer la plage de travail de MSExchangeRepl.exe	Enregistrer l'événement 4395 dans le canal Crimson avec une demande de fin de service Initier la fin de MSExchangeRepl.exe Si la fin du service échoue, redémarrer le serveur	4 gigaoctets (Go)
Événement système 129 (réinitialisation du bus)	Vérifier la présence de l'événement 129 dans les journaux des événements système	Redémarrer le serveur	Lorsque l'événement se produit
Blocage de la base de données de cluster	Les mises à jour du Gestionnaire de mises à jour globales sont bloquées	Redémarrer le serveur	Lorsque l’événement se produit

Améliorations apportées à la copie retardée

Les améliorations apportées à la copie retardée incluent l'intégration à Safety Net et la lecture automatique des fichiers journaux dans certains scénarios. Safety Net est une fonction de transport qui remplace la fonction Exchange 2010 appelée benne de transport. Safety Net est semblable à une benne de transport, car il s'agit d'une file d'attente de remise qui est associée au service de transport sur un serveur de boîtes aux lettres. Cette file d'attente stocke les copies des messages qui ont été correctement remis à la base de données de boîtes aux lettres active sur le serveur de boîtes aux lettres. Chaque base de données de boîtes aux lettres active sur le serveur de boîtes aux lettres a 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 correctement remis avant leur expiration et leur suppression automatique.

Safety Net assume une certaine responsabilité de la redondance de l’ombre dans les environnements DAG. Dans les environnements DAG, la redondance de l’ombre n’a pas besoin de conserver une autre copie du message remis dans une file d’attente fantôme pendant qu’elle attend que le message remis soit répliqué sur les copies passives des bases de données de boîtes aux lettres sur les autres serveurs de boîtes aux lettres dans le DAG. La copie du message remis est déjà stockée dans Safety Net. La redondance de l’ombre peut donc redéliser le message à partir de Safety Net si nécessaire.

Avec l’introduction de Safety Net, l’activation d’une copie de base de données en retard devient plus facile. Par exemple, supposons qu'il existe une copie retardée dont le délai d'attente de relecture est de 2 jours. Dans ce cas, vous devez configurer Safety Net pour une période de 2 jours. Si vous vous retrouvez dans une situation où vous devez utiliser votre copie retardée, vous pouvez suspendre la réplication vers celle-ci et la copier deux fois (afin de conserver la nature retardée de la base de données et de créer une copie supplémentaire au cas où vous en auriez besoin). Ensuite, prenez une copie et supprimez tous les fichiers journaux, à l'exception de ceux qui se trouvent dans la plage requise. Montez la copie, ce qui déclenche l'envoi d'une demande automatique à Safety Net pour remettre de nouveau les messages électroniques des deux derniers jours. Grâce à Safety Net, vous n'avez pas besoin de rechercher le point de départ de l'endommagement. Vous recevez le courrier électronique des deux derniers jours, moins les données habituellement perdues lors d'un basculement avec perte.

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 :

• Lorsque le seuil d'espace disque faible est atteint

• Lorsque la copie retardée est physiquement endommagée et doit faire l'objet d'une mise à jour corrective de pages

• Lorsqu’il y a moins de trois copies saines disponibles (actives ou passives uniquement ; les copies de base de données en retard ne sont pas comptabilisées) pendant plus de 24 heures

Dans Exchange 2010, la mise à jour corrective de pages n'était pas disponible pour les copies retardées. Dans Exchange 2013, la mise à jour corrective de pages est disponible pour les copies retardées via cette fonction de lecture automatique. Si le système détecte qu'une mise à jour corrective de page est nécessaire pour une copie retardée, les journaux sont automatiquement relus dans la copie retardée pour exécuter la mise à jour corrective de page. Les copies décalées appellent également cette fonctionnalité de relecture automatique lorsqu’un seuil d’espace disque faible est atteint et que la copie retardée est détectée comme la seule copie disponible pendant une période spécifique.

Le comportement de lecture de copie retardée est désactivé par défaut, mais peut être activé en exécutant la commande suivante :

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 :

HKLM\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 :

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

Prenons l’exemple d’un environnement où une base de données donnée a 4 copies (3 copies hautement disponibles et une copie à 1 décalage) 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.

Améliorations apportées à l’alerte de copie unique

Garantir que vos serveurs fonctionnent de manière fiable et que les copies de votre base de données de boîtes aux lettres sont saines sont les principaux objectifs des opérations de messagerie Exchange 2013 quotidiennes. Vous devez surveiller activement le matériel, le système d’exploitation Windows et les services Exchange. Toutefois, lors de l’exécution dans un environnement de résilience de boîte aux lettres Exchange 2013, il est important de surveiller l’intégrité et la status du DAG et des copies de votre base de données de boîtes aux lettres. Il est particulièrement essentiel d’effectuer une gestion des risques de redondance des données et de surveiller les périodes pendant lesquelles une base de données répliquée ne peut être qu’une seule copie. Cela est essentiel dans les environnements qui n’utilisent pas RAID (Redundant Array of Independent Disks) et déploient plutôt des configurations JBOD. Dans un environnement RAID, une seule défaillance de disque n’affecte pas la copie de la base de données de boîte aux lettres active. Toutefois, dans un environnement JBOD, une seule défaillance de disque déclenche un basculement de base de données.

Dans Exchange 2010, le script CheckDatabaseRedundancy.ps1 a été introduit. Comme son nom l’indique, l’objectif du script était de surveiller la redondance des bases de données de boîtes aux lettres répliquées en validant qu’il existe au moins deux copies configurées, saines et actuelles, et d’alerter un administrateur via la génération du journal des événements lorsqu’une seule copie saine d’une base de données répliquée existe. Dans ce cas, les copies actives et passives sont comptabilisées lors de la détermination de la redondance.

Les conditions de copie unique incluent, entre autres :

• Échec de la réplication d'une copie active vers une copie passive.

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

• Échec de l'identification précise par le système de la génération actuelle du journal de la copie active.

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.

La fonctionnalité native alerte toujours les administrateurs via les notifications du journal des événements, mais pour distinguer les alertes Exchange 2013 des alertes Exchange 2010, Exchange 2013 utilise les ID d'événement suivants :

• Événement 4138 (alerte rouge)

• Événement 4139 (alerte verte)

Dans Exchange 2013, la fonctionnalité native a été améliorée pour diminuer le niveau de bruit généré par l'alerte lorsque plusieurs bases de données sur le même serveur entrent dans une condition de copie unique. Dans Exchange 2010, les alertes de copie unique étaient générées par base de données. Par conséquent, lorsqu'un problème au niveau du serveur concernait plusieurs bases de données et plusieurs copies de base de données, de multiples alertes pouvaient être générées. Comme plusieurs défaillances, telles que des problèmes de contrôleur ou de mémoire, concernent l'ensemble du serveur, il existe une probabilité relativement grande qu'une telle série d'alertes se produise pour chaque incident de serveur. Dans Exchange 2013, les alertes sont désormais générées par serveur. Quand une interruption concerne un serveur entier et que la redondance des données court un risque pour plusieurs copies de base de données, une seule alerte par serveur est désormais générée.

Configuration automatique de réseau DAG

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.

Dans Exchange 2013, la réduction des réseaux DAG n'est plus nécessaire. Exchange 2013 utilise toujours les mêmes mécanismes de détection pour faire la distinction entre les réseaux MAPI et de réplication, mais il réduit maintenant automatiquement les réseaux DAG de façon appropriée.

En outre, par défaut, les réseaux DAG sont désormais gérés automatiquement par le système. Pour afficher les propriétés réseau du DAG à l’aide du Centre d’administration Exchange (EAC), vous devez configurer le DAG pour le contrôle réseau manuel en modifiant les propriétés du DAG à l’aide du CAE ou en utilisant l’applet de commande Set-DatabaseAvailabilityGroup pour définir le paramètre ManualDagNetworkConfiguration sur True.

Modifications apportées à la sélection de la meilleure copie

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 :

• Longueur de la file d'attente de copie

• Longueur de la file d'attente de relecture

• État de la base de données

• État de l'index de contenu

Dans Exchange 2013, Active Manager effectue les mêmes étapes et vérifications BCS pour déterminer l'intégrité de la réplication, mais inclut aussi désormais l'utilisation d'une contrainte d'ordre décroissant des états d'intégrité. Suite à ces modifications, BCS se nomme désormais BCSS (Best Copy and Server Selection).

BCSS inclut plusieurs nouveaux contrôles d’intégrité qui font partie des composants intégrés de surveillance de la disponibilité managée dans Exchange 2013. Active Manager effectue quatre nouvelles vérifications supplémentaires (répertoriées par ordre d'exécution) :

1. Tout sain : recherche un serveur hébergeant une copie de la base de données affectée qui a tous les composants de surveillance dans un état sain.

2. Jusqu’à normal sain : recherche un serveur hébergeant une copie de la base de données affectée qui a tous les composants de surveillance avec une priorité normale dans un état sain.

3. Tout mieux que la source : recherche un serveur hébergeant une copie de la base de données affectée qui a des composants de surveillance dans un état meilleur que le serveur actuel hébergeant la copie affectée.

4. Identique à la source : recherche un serveur hébergeant une copie de la base de données affectée qui a des composants de surveillance dans un état identique à celui du serveur actuel hébergeant la copie affectée.

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 une défaillance d’Outlook Web App déclenche un basculement de disponibilité managée via un répondeur de basculement, BCSS doit sélectionner un serveur hébergeant une copie de la base de données affectée sur laquelle Outlook Web App est sain.

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

La mise à jour cumulative 2 (CU2) de la version RTM d'Exchange 2013 offre un nouveau service sur les serveurs de boîtes aux lettres qui sont membres d'un DAG. Il s'agit du service de gestion DAG Microsoft Exchange (MSExchangeDAGMgmt). Ce nouveau service propose des fonctionnalités de surveillance de DAG internes, auparavant exécutées dans le service de réplication Microsoft Exchange (MSExchangeRepl).

Groupes de disponibilité de base de données (DAG) sans point d’accès administratif de cluster

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 :

• Aucune adresse IP n’est affectée au cluster, et donc aucune ressource d’adresse IP dans le groupe de ressources principal du cluster.

• Aucun nom réseau n’est attribué au cluster, et par conséquent, aucune ressource de nom réseau dans le groupe de ressources principal du cluster

• Le nom du cluster n’est pas inscrit dans DNS et ne peut pas être résolu sur le réseau.

• Un objet de nom de cluster (CNO) n’est pas créé dans Active Directory.

• Le cluster de basculement Windows ne peut pas être géré à l’aide de l’outil 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.

Lorsqu'il est exécuté sur Windows Server 2012 R2 ou version ultérieure, le Service Pack 1 (SP1) pour Exchange 2013 et version ultérieure 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 de l’interpréteur de commandes. Pour plus d'informations, consultez les rubriques Création de groupes de disponibilité de base de données et Créer un groupe de disponibilité de base de données.