Analyse de la haute disponibilité et de la résilience de site

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

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

S’assurer que vos serveurs fonctionnent de manière fiable et que vos copies de base de données sont saines constituent des objectifs clés pour les opérations de messagerie quotidiennes. Pour garantir la disponibilité et la fiabilité de votre organisation Microsoft Exchange Server 2010, vous devez analyser activement le matériel, le système d’exploitation Windows et les services Exchange 2010. L’analyse proactive associée à la maintenance préventive peut vous aider à identifier les erreurs potentielles avant qu’un problème grave n’affecte le fonctionnement de votre organisation Exchange.

L’analyse de votre organisation Exchange implique de vérifier régulièrement qu’il n’existe aucun problème avec les services ou les données. L’analyse comprend généralement un système de notification qui envoie des alertes lorsque les problèmes surviennent. Windows Server 2008 et Exchange 2010 incluent plusieurs outils et services qui permettent de vous assurer que votre organisation Exchange fonctionne correctement. L’analyse quotidienne présente plusieurs avantages. Elle permet de :

• satisfaire les exigences de vos contrats SLA ;

• garantir l’exécution de tâches administratives spécifiques, comme les sauvegardes quotidiennes ;

• détecter et traiter les problèmes qui peuvent affecter le service de messagerie ou la disponibilité des données.

Dans une organisation Exchange 2010, les procédures, rôles et responsabilités intervenant dans les opérations doivent être formalisés. Il est primordial de comprendre le lien entre des méthodes opérationnelles et des procédures solides et une infrastructure saine. Bien documentées, les méthodes et procédures détaillées permettent de s’assurer que tous les composants de l’environnement d’une organisation sur lesquels Exchange s’appuie sont gérés de façon efficace.

Exchange 2010 comprend plusieurs outils, scripts et fonctionnalités intégrés qui peuvent être utilisés dans le cadre de l’analyse proactive lorsqu’Exchange est configuré pour la haute disponibilité ou la résilience de site. Les principales cmdlets d’analyse de la résilience de site et de la disponibilité élevée sont Get-MailboxDatabaseCopyStatus et Test-ReplicationHealth. Outre la fourniture de cmdlets qui peuvent exécuter des fonctions d’analyse et des rapports d’état, Exchange 2010 comporte également un nouveau flux de journal d’événements qui exploite les possibilités du canal crimson de Windows Server, ainsi que des scripts intégrés qui collectent et analysent les données à partir de ces canaux d’événements.

Vous pouvez utiliser les informations de cette rubrique pour analyser l’intégrité et l’état des copies de la base de données de boîtes aux lettres pour les groupes de disponibilité de base de données (DAG).

Contenu de cette rubrique

Cmdlet Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

Journalisation des événements du canal Crimson

Script CollectOverMetrics.ps1

Script CollectReplicationMetrics.ps1

Script CheckDatabaseRedundancy.ps1

Cmdlet Get-MailboxDatabaseCopyStatus

Vous pouvez utiliser la cmdlet Get-MailboxDatabaseCopyStatus pour afficher des informations sur l’état des copies de la base de données de boîtes aux lettres. Cette cmdlet vous permet de consulter des informations sur toutes les copies d’une base de données spécifique, des informations sur une copie spécifique d’une base de données installée sur un serveur donné ou des informations sur toutes les copies de base de données installées sur un serveur. Le tableau suivant décrit les valeurs possibles de l’état d’une copie de base de données de boîtes aux lettres.

État de copie de la base de données

La cmdlet Get-MailboxDatabaseCopyStatus comprend également un paramètre appelé ConnectionStatus qui renvoie des informations sur les réseaux de réplication en cours d’utilisation. Si vous utilisez ce paramètre, les deux champs supplémentaires IncomingLogCopyingNetwork et SeedingNetwork seront renseignés dans la sortie de la tâche.

Exemples Get-MailboxDatabaseCopyStatus

Les exemples suivants utilisent la cmdlet Get-MailboxDatabaseCopyStatus. Chaque exemple transfère les résultats à la cmdlet Format-List afin qu’ils soient affichés sous la forme d’une liste.

Cet exemple renvoie les informations relatives à l’état de toutes les copies de la base de données nommée DB2.

Get-MailboxDatabaseCopyStatus -Identity DB2 | Format-List

Cet exemple renvoie l’état de toutes les copies de base de données sur le serveur de boîtes aux lettres nommé MBX2.

Get-MailboxDatabaseCopyStatus -Server MBX2 | Format-List

Cet exemple renvoie l’état de toutes les copies de base de données sur le serveur de boîtes aux lettres local.

Get-MailboxDatabaseCopyStatus -Local | Format-List

Cet exemple renvoie des informations sur l’état, l’envoi des journaux et le réseau d’amorçage pour la base de données DB3 sur le serveur de boîtes aux lettres nommé MBX1.

Get-MailboxDatabaseCopyStatus -Identity DB3\MBX1 -ConnectionStatus | Format-List

Pour plus d’informations sur l’utilisation de la cmdlet Get-MailboxDatabaseCopyStatus, voir Get-MailboxDatabaseCopyStatus.

Cmdlet Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

Vous pouvez utiliser la cmdlet Test-ReplicationHealth pour afficher des informations sur l’état de réplication continue des copies de la base de données de boîtes aux lettres. Cette cmdlet permet de vérifier tous les aspects de l’état de réplication et de relecture afin d’offrir une vue d’ensemble complète d’un serveur de boîtes aux lettres spécifique dans un groupe de disponibilité de base de données.

La cmdlet Test-ReplicationHealth a été conçue pour l’analyse proactive de la réplication continue et du pipeline de la réplication continue, la disponibilité d’Active Manager, l’état du service de cluster sous-jacent, le quorum et les composants réseau. Elle peut être exécutée localement ou à distance sur n’importe quel serveur de boîtes aux lettres dans un groupe de disponibilité de base de données. La cmdlet Test-ReplicationHealth exécute les tests répertoriés dans le tableau suivant.

Tests de la cmdlet Test-ReplicationHealth

Exemple Test-ReplicationHealth

Cet exemple utilise la cmdlet Test-ReplicationHealth pour tester l’intégrité de la réplication pour le serveur de boîtes aux lettres MBX1.

Test-ReplicationHealth -Identity MBX1

Cmdlet Get-MailboxDatabaseCopyStatus

Journalisation des événements du canal Crimson

Windows Server 2008 comprend deux catégories de journaux d’événements : les journaux Windows et les journaux des applications et des services. La catégorie de journaux Windows inclut les journaux d’événements disponibles dans les versions précédentes de Windows : les journaux des événements d’application, de sécurité et système. Elle inclut également deux nouveaux journaux : le journal d’installation et le journal des événements transmis (ForwardedEvents). Les journaux Windows sont conçus pour le stockage d’événements appartenant à des applications héritées et d’événements qui s’appliquent à la totalité du système.

Les journaux des applications et des services sont une nouvelle catégorie de journaux d’événements. 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 ».

La catégorie de journaux des applications et services inclut quatre sous-types : les journaux d’administration, opérationnels, d’analyse et de débogage. Les événements des journaux d’administration sont particulièrement utiles si vous utilisez des enregistrements du journal d’événements pour résoudre les problèmes. Les événements contenus dans le journal d’administration doivent vous indiquer comment répondre aux événements. Les événements du journal opérationnel sont eux aussi utiles, mais ils nécessitent une interprétation plus détaillée. Les journaux d’administration et de débogage ne sont pas aussi conviviaux. Les journaux d’analyse (masqués et désactivés par défaut) stockent des événements qui effectuent le suivi d’un problème. Ils contiennent généralement un grand nombre d’événements. Les journaux de débogage sont utilisés par les développeurs lors du débogage d’applications.

Exchange 2010 enregistre les événements dans les canaux crimson, dans la zone des journaux des applications et services. Vous pouvez afficher ces canaux en procédant comme suit :

1. Ouvrez l’Observateur d’événements.

2. Dans l’arborescence de la console, accédez à Journaux des applications et des services > Microsoft > Exchange.

3. Sous Exchange, sélectionnez un canal crimson : HighAvailability ou MailboxDatabaseFailureItems.

Le canal HighAvailability contient des événements liés au démarrage et à la fermeture du service de réplication Microsoft Exchange ainsi que les divers composants qui s’exécutent au sein de ce service Microsoft Exchange, comme Active Manager, l’API de réplication synchrone tiers, le serveur de tâches RPC, le port d’écoute TCP et l’enregistreur VSS (Service de cliché instantané de volumes). Le canal HighAvailability permet également à Active Manager de journaliser les événements associés aux événements d’analyse de rôle et d’action de base de données Active Manager, comme le montage de la base de données et la troncation du journal, et d’enregistrer des événements associés au cluster sous-jacent du DAG.

Le canal MailboxDatabaseFailureItems sert à journaliser les événements associés aux défaillances qui affectent une base de données de boîte aux lettres répliquées.

Cmdlet Get-MailboxDatabaseCopyStatus

Script CollectOverMetrics.ps1

Exchange 2010 comprend un script appelé CollectOverMetrics.ps1 disponible dans le dossier Scripts. CollectOverMetrics.ps1 lit les journaux des événements relatifs aux membres du DAG pour rassembler des informations sur les opérations relatives aux bases de données (telles que montages, déplacements et basculements de bases de données) sur une période donnée. Pour chaque opération, le script enregistre les informations suivantes :

• Identité de la base de données

• Heure de début et de fin de l’opération

• Serveurs sur lesquels la base de données a été montée au début et à la fin de l’opération

• Raison de l’opération

• Les informations en cas de réussite ou d’échec de l’opération

Le script consigne ces informations dans des fichiers .csv avec une opération par ligne. Il crée un fichier .csv pour chaque DAG.

Ce script prend en charge des paramètres qui vous permettent de personnaliser son comportement et ses résultats. Par exemple, les résultats peuvent être limités à un sous-ensemble spécifique à l’aide des paramètres Database et ReportFilter. Seules les opérations correspondant à ces filtres seront consignées dans le rapport récapitulatif au format HTML. Les paramètres disponibles sont répertoriés dans le tableau suivant.

Paramètres du script CollectOverMetrics.ps1

Exemples CollectOverMetrics.ps1

L’exemple suivant collecte des mesures pour toutes les bases de données correspondant à DB* (avec un caractère générique) dans un groupe de disponibilité de base de données nommé DAG1. Une fois les mesures recueillies, un rapport HTML est généré et affiché.

CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport

Les exemples suivants montrent différentes manières de filtrer un rapport récapitulatif HTML. Le premier exemple utilise le paramètre Database qui récupère une liste de noms de base de données. Le rapport récapitulatif contient alors uniquement des données sur ces bases de données. Les deux exemples suivants utilisent l’option ReportFilter. Le dernier exemple filtre toutes les bases de données par défaut.

CollectOverMetrics -SummariseCsvFiles (dir *.csv) -Database MailboxDatabase123,MailboxDatabase456
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { $_.DatabaseName -notlike "Mailbox Database*" }
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { ($_.ActiveOnStart -like "ServerXYZ*") -and ($_.ActiveOnEnd -notlike "ServerXYZ*") }

Cmdlet Get-MailboxDatabaseCopyStatus

Script CollectReplicationMetrics.ps1

Le script d’évaluation de l’intégrité CollectReplicationMetrics.ps1 est lui aussi inclus dans Exchange 2010. Il fournit une forme active d’analyse, car il collecte des mesures en temps réel, pendant son exécution. CollectReplicationMetrics.ps1 collecte des données à partir des compteurs de performance liés à la réplication des bases de données. Le script rassemble des données de compteur à partir de plusieurs serveurs de boîtes aux lettres, consigne ces données dans un fichier .csv et établit des statistiques à partir de celles-ci (par exemple, la durée pendant laquelle chaque copie était en panne ou suspendue, la longueur moyenne de la file d’attente de copie ou de relecture ou la durée pendant laquelle les copies ne correspondaient plus aux critères de basculement).

Vous pouvez spécifier les serveurs individuellement ou vous pouvez spécifier des DAG entiers. Vous pouvez exécuter le script pour collecter des données afin de générer un rapport, ou bien vous pouvez l’exécuter pour collecter uniquement des données ou établir un rapport à partir des données déjà collectées. Vous pouvez spécifier la fréquence à laquelle les données doivent être collectées et la durée totale de la collecte.

Les données collectées sur chaque serveur sont consignées dans un fichier nommé CounterData.<Nom_serveur>.<horodatage>.csv. Le rapport récapitulatif sera enregistré dans un fichier nommé HaReplPerfReport.<Nom_DAG>.<horodatage>.csv ou HaReplPerfReport.<horodatage>.csv si vous n’avez pas exécuté le script avec le paramètre DagName.

Le script lance des tâches PowerShell pour collecter les données de chaque serveur. Ces tâches sont exécutées pour toute la durée de la collecte des données. Si vous spécifiez un grand nombre de serveurs, ce processus peut consommer une quantité considérable de mémoire. L’étape finale du processus, lorsqu’un rapport récapitulatif est établi à partir des données, peut également prendre beaucoup de temps pour de grands volumes de données. Il est possible d’exécuter l’étape de collecte sur un ordinateur, puis de copier les données ailleurs pour les traiter.

Le script CollectReplicationMetrics.ps1 prend en charge des paramètres qui vous permettent de personnaliser son comportement et ses résultats. Les paramètres disponibles sont répertoriés dans le tableau suivant.

Paramètres du script CollectReplicationMetrics.ps1

Exemple CollectReplicationMetrics.ps1

L’exemple suivant collecte des données sur une période d’une heure, et à des intervalles d’une minute, à partir de tous les serveurs dans le DAG « DAG1 », puis génère un rapport récapitulatif. Le paramètre ReportPath est également utilisé pour que le script place tous les fichiers dans le répertoire actuel.

CollectReplicationMetrics.ps1 -DagName DAG1 -Duration "01:00:00" -Frequency "00:01:00" -ReportPath

L’exemple suivant lit les données dans tous les fichiers correspondant à « CounterData* », puis génère un rapport récapitulatif.

CollectReplicationMetrics.ps1 -SummariseFiles (dir CounterData*) -Mode ProcessOnly -ReportPath

Cmdlet Get-MailboxDatabaseCopyStatus

Script CheckDatabaseRedundancy.ps1

Comme son nom l’indique, l’objet du script CheckDatabaseRedundancy.ps1 est 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 saines. Le script vous prévient s’il n’existe qu’une seule copie saine 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.

Lorsque le rôle serveur de boîtes aux lettres est installé, le script CheckDatabaseRedundancy.ps1 est automatiquement configuré par Exchange afin d’exécuter une tâche planifiée appelée Database One Copy Alert. Par défaut, la tâche planifiée Database One Copy Alert est configurée pour une exécution toutes les 60 minutes. Vous pouvez modifier ce comportement et les paramètres de la tâche planifiée à l’aide du service Planificateur de tâches de Windows. Ce script est conçu avant tout pour vérifier l’appartenance à un groupe de disponibilité de base de données (DAG). Ainsi, si le serveur de boîtes aux lettres n’est pas membre d’un groupe de disponibilité de base de données, le script se ferme aussitôt.

Le script peut également être exécuté interactivement à partir du dossiers Scripts. Si vous exécutez le script de manière interactive, vous devez spécifier le nom d’une base de données ou le nom d’un membre du groupe de disponibilité de base de données. Deux paramètres sont prévus à cet effet, MailboxDatabaseName pour spécifier une base de données et MailboxServerName pour spécifier un membre du DAG. Lorsque vous exécutez le script dans la console, celui-ci effectue la vérification de redondance une seule fois et en indique l’état à l’écran (rouge ou vert).

Comme d’autres scripts et cmdlets, le script CheckDatabaseRedundancy.ps1 peut également être exécuté en mode de surveillance et générer des événements. Il suffit pour cela d’ajouter le paramètre MonitoringContext. La tâche planifiée créée par Exchange exécute le script en mode de surveillance. Ce mode permet également d’appeler le script au moyen d’une solution de contrôle, telle que Microsoft System Center Operations Manager (SCOM). En mode de surveillance, le script génère des événements d’alerte rouge et verte dans le journal des événements d’application du serveur local. Un événement d’alerte rouge (ID d’événement 4113) est généré uniquement si la base de données a été « rouge » pendant plus de 20 minutes non consécutives sur la durée d’une heure de l’exécution du script. Un événement d’alerte verte (ID d’événement 4114) est, quant à lui, généré lorsque la base de données a été « verte » pendant 10 minutes consécutives. Par défaut, une fois qu’un événement d’alerte rouge est généré, il continuera à être signalé toutes les 15 minutes.

Le script offre également des options utiles. Par exemple, vous pouvez ajouter le paramètre ShowDetailedErrors pour obtenir plus de détails sur les erreurs qui se produisent et le paramètre Verbose pour obtenir plus d’informations de dépannage. Le script comprend également le paramètre SendSummaryMailTos qui lui permet d’envoyer, à la fin de son exécution, un rapport récapitulatif par courrier électronique à une liste d’adresses de messagerie spécifiées. Les administrateurs peuvent alors consulter rapidement les rapports émis toutes les heures pour voir si des problèmes de redondance se sont produits. Si vous utilisez la fonctionnalité de messagerie, vous devrez inclure le paramètre SummaryMailFrom à chaque fois que vous utilisez le paramètre SendSummaryMailTos.

Microsoft recommande d’exécuter régulièrement ce script dans le cadre de vos activités normales de surveillance, soit au moyen d’une tâche planifiée automatisée, soit à l’aide d’un système de surveillance comme SCOM. Pour éviter que la redondance des bases de données soit incorrecte pendant de longues périodes, exécutez le script toutes les 60 minutes. Le script comprend un paramètre appelé TerminateAfterDurationSecs, qui lorsqu’il est défini sur -1 ou 0, permet d’exécuter le script pour une durée indéterminée.

Si vous n’exécutez aucune solution de surveillance telle que SCOM, nous vous recommandons de créer une tâche planifiée créé automatiquement afin d’automatiser et de planifier l’exécution du script.

Il existe des problèmes connus dans le planificateur de tâches Windows Server 2008 SP2 qui peuvent entraîner un blocage de ce dernier lorsque vous avez planifié une tâche devant s’exécuter sur une longue durée. Ces problèmes ne concernent pas Windows Server 2008 R2 ; si possible, exécutez alors le script à partir de Windows Server 2008 R2. Si vous ne pouvez pas exécuter le script à partir de Windows Server 2008 R2 et l’exécutez à partir de Windows Server 2008 SP2, deux modifications sont préconisées. D’abord, au lieu d’exécuter le script avec sa suppression temporaire intégrée de 60 minutes, exécutez-le toutes les 5 minutes avec les paramètres suivants :

CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors

Ensuite, si possible, utilisez SCOM pour définir le comportement de suppression temporaire (par exemple, si 3 événements d’alerte rouge sont consignés au cours d’une période de 20 minutes, une alerte est générée, et si un événement d’alerte verte est consigné, changez l’état courant de sorte qu’il soit vert).

Si la tâche planifiée Database One Copy Alert est modifiée ou supprimée, vous pouvez tout supprimer et replanifier en exécutant la commande suivante :

schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY

Remplacez les paramètres dans le script ci-dessus par les paramètres que vous voulez utiliser. D’autres paramètres sont également décrits dans le script.

Lorsque vous créez une tâche planifiée à l’aide de l’outil de ligne de commande schtasks, l’option /TR est limitée à 261 caractères. L’exemple ci-dessus dépasse cette limite. Si les paramètres et les chemins que vous utilisez dépassent la limite de 261 caractères pour l’option /TR, vous devez manuellement créer la tâche planifiée à l’aide de l’applet Planificateur de tâches du menu Outils d’administration. Vous pouvez également copier et coller le code XML suivant dans le Bloc-notes, le modifier comme il convient, l’enregistrer dans un fichier XML et l’importer à l’aide de l’applet Planificateur de tâches.

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="https://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2010-05-11T15:55:47</Date>
    <Author>administrator</Author>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT1H</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2010-05-11T15:55:00</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>SYSTEM</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <IdleSettings>
      <Duration>PT10M</Duration>
      <WaitTimeout>PT1H</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>Powershell.exe</Command>
      <Arguments>-NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue</Arguments>
    </Exec>
  </Actions>
</Task>

Cmdlet Get-MailboxDatabaseCopyStatus

 © 2010 Microsoft Corporation. Tous droits réservés.