Nouvelles fonctionnalités de haute disponibilité et de résilience de site dans Exchange 2010 SP1

Article
05/13/2016

S’applique à : Exchange Server 2010 SP1

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

Microsoft Exchange Server 2010 Service Pack 1 (SP1) inclut des fonctionnalités inédites et des améliorations des fonctionnalités introduites dans la version de publication (RTM) d’Exchange 2010. Les fonctionnalités inédites et améliorées étendent les scénarios dans lesquels vous pouvez bénéficier d’une disponibilité des données et des services pour votre environnement Exchange 2010.

Exchange 2010 SP1 ajoute les nouvelles fonctionnalités et améliorations suivantes aux fonctionnalités de haute disponibilité existantes :

Mode Réplication continue - blocage
Redistribution des bases de données de boîtes aux lettres actives
Meilleure prise en charge du mode de coordination de l’activation du centre de données
Nouveaux scripts de gestion et d’analyse améliorés
Améliorations de l’interface utilisateur de la console de gestion Exchange
Améliorations des performances de basculement
Récupération de l’ESE (Extensible Storage Engine) dans des E/S bloquées

Ces fonctionnalités sont décrites plus en détail ci-dessous.

Mode Réplication continue - blocage

Dans la version de publication (RTM) d’Exchange 2010 et dans toutes les versions d’Exchange Server 2007, la réplication continue fonctionne en envoyant des copies des fichiers journaux générés par la copie de base de données active vers les copies de bases de données passives. À partir d’Exchange 2010 SP1, cette forme de réplication continue est appelée mode réplication continue - fichier. Exchange 2010 SP1 introduit également une nouvelle forme de réplication continue appelée mode réplication continue - blocage. En mode blocage, à chaque fois qu’une mise à jour est enregistrée dans le tampon journal actif de la copie de la base de données active, elle est envoyée dans le tampon journal de chacune des copies de base de données de boîte aux lettres passives. Lorsque le tampon journal est plein, chaque copie de base de données constitue, inspecte et crée le fichier journal suivant dans la séquence de génération. En cas de défaillance de la copie active, les copies passives sont mises à jour avec la plupart sinon l’intégralité des dernières mises à jour. La copie active n’attend pas la fin de la réplication pour empêcher les problèmes de réplication de nuire à l’utilisation du client.

Le mode réplication continue - blocage est uniquement actif lorsque la réplication continue est à jour en mode fichier. La transition entre l’activation et la désactivation du mode blocage est effectuée automatiquement par le copieur de journal. Le mode blocage réduit considérablement la latence entre le moment où un changement est effectué dans la copie active et le moment où il est répliqué dans les copies passives. En plus de répliquer les écritures de fichier journal, le mode blocage modifie également le processus d’activation d’une copie passive. Si une défaillance se produit sur une copie en mode blocage, le système utilise le contenu disponible du fichier journal au cours du processus d’activation. Le fichier journal actif sur la copie active ne constitue alors plus un point de défaillance.

Redistribution des bases de données de boîtes aux lettres actives

Exchange 2010 SP1 comprend un script appelé RedistributeActiveDatabases.ps1 qui peut être régulièrement exécuté par les administrateurs pour équilibrer la distribution des copies de base de données actives dans un groupe de disponibilité de base de données (DAG) basé sur la préférence d’activation configurée par un administrateur. En outre, un suivi de la distribution des copies a été ajouté au processus de sélection de la meilleure copie par le gestionnaire Active Manager. Ainsi, la première séquence de sélection de la meilleure copie en vue de basculements sans perte trie désormais les cibles possibles par préférence et non par cibles pouvant présenter une moindre perte.

Meilleure prise en charge du mode de coordination de l’activation du centre de données

Exchange 2010 RTM comporte un mode de configuration destiné à la prise en charge de la résilience de site DAG appelé mode de coordination de l’activation du centre de données (DAC, Datacenter Activation Coordination). En mode DAC, les cmdlets Exchange peuvent être utilisées pour effectuer un basculement de centre de données. Dans la version RTM, le mode DAC est limité aux DAG comportant au moins trois membres, deux membres au moins se trouvant dans le centre de données principal.

Dans Exchange 2010 SP1, le mode DAC a été étendu pour prendre en charge des DAG à deux membres, chaque membre se trouvant dans un centre de données distinct. Le mode DAC pour les DAG à deux membres utilise le serveur témoin à des fins d’arbitrage supplémentaire. En outre, le mode DAC a été étendu pour prendre en charge les DAG dont tous les membres sont déployés dans un site Active Directory unique, y compris dans les sites Active Directory qui ont été étendus à plusieurs emplacements.

Nouveaux scripts de gestion et d’analyse améliorés

Exchange 2010 SP1 comprend plusieurs nouveaux scripts améliorés qui facilitent considérablement les tâches de gestion et de surveillance :

CheckDatabaseRedundancy.ps1 (nouveau) Vous pouvez utiliser ce script pour vérifier la redondance des bases de données répliquées et il générera des événements si la résilience des bases de données n’est pas satisfaisante (par exemple, s’il n’y a qu’une seule copie saine d’une base de données répliquée). Le script est accompagné d’un changement du pack de gestion Microsoft System Center Operations Manager 2007 pouvant être utilisé pour surveiller les bases de données sans redondance, ce qui s’avère particulièrement utile dans les environnements sans RAID.
StartDagServerMaintenance.ps1 et StopDagServerMaintenance.ps1 (nouveau) Vous pouvez utiliser StartDagServerMaintenance.ps1 pour mettre un membre d’un DAG hors service à des fins de maintenance. Ce script extraie alors les bases de données actives du serveur et empêche des bases de données d’être placées sur ce serveur. Il veille également à ce que toutes les fonctionnalités de prise en charge de DAG critiques (par exemple, le rôle gestionnaire Active Manager principal) pouvant se trouver sur le serveur soient placées sur un autre serveur et ne puissent pas revenir sur le serveur d’origine. Un autre script, StopDagServerMaintenance.ps1, est fourni pour terminer l’opération et désactiver les blocages.
CollectOverMetrics.ps1 (amélioré) Vous pouvez utiliser ce script pour rassembler des données de basculement. Ce script a été amélioré dans Exchange 2010 SP1 pour inclure des mesures du mode réplication continue - blocage et des informations détaillées provenant du pipeline de réplication et de relecture. En outre, il comporte une fonctionnalité de création de rapport améliorée.
CollectReplicationMetrics.ps1 (amélioré) Ce script constitue une forme active d’analyse, car il collecte des mesures de réplication continue en temps réel, pendant son exécution. Ce script prend en charge des paramètres qui vous permettent de personnaliser son comportement et ses résultats.

Interface utilisateur de la console de gestion Exchange améliorée

Exchange 2010 SP1 comporte des améliorations de la console de gestion Exchange (EMC) pour gérer les DAG. Par exemple, l’EMC permet désormais de gérer les adresses IP et les paramètres de serveur témoin alternatif pour les DAG. Il n’est par conséquent plus nécessaire d’utiliser l’environnement de ligne de commande Exchange Management Shell pour configurer ces paramètres.

Amélioration des performances de basculement

Des changements ont été effectués dans Exchange 2010 SP1 pour améliorer les performances et le comportement du basculement. Dans la version RTM d’Exchange 2010, lorsqu’un basculement se produit, la copie passive activée sur laquelle des fichiers journaux ont été copiés cesse immédiatement de relire ces derniers. La copie active est alors démontée (si elle ne l’est pas déjà) et les fichiers journaux restants sont copiés sur la copie passive activée. En supposant que toutes les données manquantes sont conformes au paramètre de numérotation de montage automatique de la base de données, la copie passive devient la nouvelle copie active et la base de données est montée dans un état d’arrêt incorrect. À ce stade, tous les fichiers journaux copiés dans l’ancienne copie passive (qui est désormais active) sont remplacés pour que la base de données soit homogène.

Dans Exchange 2010 SP1, lorsqu’un basculement se produit, le service de réplication Microsoft Exchange sur la copie passive activée continue à relire les fichiers journaux copiés sur celle-ci jusqu’à ce que le dernier fichier journal généré par la copie active y soit copié. Cela déclenche une opération de montage d’une base de données presque entièrement homogène.

D’autres changements d’amélioration des performances incluent des délais d’attente et des détails d’algorithme pour améliorer les performances de basculement et les performances d’E/S à la suite de basculements.

Récupération de l’ESE (Extensible Storage Engine) dans des E/S bloquées

Exchange 2010 SP1 comprend une nouvelle logique de récupération utilisant le comportement de vérification d’erreur Windows intégré lorsque certaines conditions sont remplies. L’ESE (Extensible Storage Engine) a été mis à jour en particulier pour détecter les blocages d’E/S et prendre des mesures correctives afin de récupérer automatiquement le serveur. Il assure une surveillance des E/S qui détecte une E/S ne répondant plus dans un délai spécifique. Par défaut, si une E/S dans une base de données ne répond plus pendant plus d’une minute, l’ESE enregistre un événement. Si ce délai dépasse 4 minutes, un événement d’échec particulier est enregistré, le cas échéant. Les événements ESE 507, 508, 509, ou 510 peuvent être enregistrés ou non selon la nature de l’E/S bloquée. Si le volume du système d’exploitation ou la capacité d’enregistrement vers le journal des événements sont affectés, les événements ne sont pas enregistrés. Si les événements sont enregistrés, le Service de réplication Microsoft Exchange (MSExchangeRepl.exe) met volontairement fin au processus wininit.exe pour provoquer une vérification d’erreur de Windows.

Dans certains cas, toute la pile de stockage peut être affectée par le blocage, ce qui rend impossible l’enregistrement des événements d’échec vers le canal Crimson ou toute autre zone du journal des événements Windows. ESE surveille également le canal Crimson en vérifiant qu’il est possible d’enregistrer des événements dans le journal correspondant. S’il s’avère impossible d’enregistrer des événements dans le journal pendant une longue période, MSExchangeRepl déclenche volontairement une vérification d’erreur de Windows en mettant fin au processus wininit.exe. Si le système d’exploitation est bloqué, le système est évidemment incapable d’enregistrer les événements ESE dans le journal correspondant.

Remarque :
Les journaux des applications et des services sont une nouvelle catégorie de journaux d’événements dans Windows Server 2008. Ces journaux stockent les événements d’une application ou d’un composant unique au lieu des événements qui concernent le système entier. Cette nouvelle catégorie de journaux d’événements est désignée par les termes « canal crimson d’une application ». Pour plus d’informations, consultez la rubrique Analyse de la haute disponibilité et de la résilience de site.

Les journaux des applications et des services sont une nouvelle catégorie de journaux d’événements dans Windows Server 2008. Ces journaux stockent les événements d’une application ou d’un composant unique au lieu des événements qui concernent le système entier. Cette nouvelle catégorie de journaux d’événements est désignée par les termes « canal crimson d’une application ». Pour plus d’informations, consultez la rubrique Analyse de la haute disponibilité et de la résilience de site.

Dans Exchange 2010 SP1, cette nouvelle fonctionnalité de récupération basée sur la vérification d’erreur permet une récupération rapide en cas de blocage d’une E/S ou d’un contrôleur. Cela évite de renouveler les tentatives ou d’attendre que la pile de stockage signale une erreur à l’origine du basculement. Le code d’erreur se présente comme suit lorsque la vérification d’erreur est exécutée :

CRITICAL_OBJECT_TERMINATION (f4)

Un processus ou un thread crucial au fonctionnement du système s’est terminé ou été interrompu de façon inattendue.

Avertissement :
La présence de ce code d’erreur de vérification ne signifie pas nécessairement qu’Exchange était la cause de l’erreur. Toute interruption de wininit.exe, même provoquée par un administrateur utilisant le Gestionnaire des tâches ou tout autre outil de gestion des tâches, engendrera le même code d’erreur de vérification.

Partager via