Disponibilité gérée

S’applique à : Exchange Server 2013 SP1

L'objectif des administrateurs de système de messagerie a toujours été de fournir une expérience de messagerie optimale aux utilisateurs. Pour garantir la disponibilité et la fiabilité de votre organisation Microsoft Exchange Server 2013, tous les aspects du système doivent être activement surveillés et tous les problèmes détectés doivent être résolus rapidement. Dans les versions précédentes d’Exchange, la surveillance des composants système critiques impliquait généralement l’utilisation d’une application externe telle que Microsoft System Center 2012 Operations Manager pour collecter des données et fournir une action de récupération pour les problèmes détectés suite à l’analyse des données collectées. Exchange 2010 et les versions antérieures incluaient des manifestes d’intégrité et des moteurs de corrélation sous forme de packs d’administration. Ces composants ont permis à Operations Manager de déterminer si un composant particulier était sain ou non sain. En outre, Operations Manager a également utilisé l’infrastructure d’applet de commande de diagnostic intégrée à Exchange 2010 pour exécuter des transactions synthétiques sur différents aspects du système.

Exchange 2013 adopte une nouvelle approche pour surveiller et préserver l’expérience de l’utilisateur final en mode natif à l’aide d’une fonctionnalité appelée Disponibilité managée qui fournit des actions intégrées de surveillance et de récupération.

La disponibilité managée, également appelée supervision active ou supervision active locale, est l’intégration d’actions intégrées de surveillance et de récupération à la plateforme de haute disponibilité Exchange. Elle est conçue pour détecter des problèmes et procéder à une récupération dès qu'ils apparaissent ou sont découverts par le système. À la différence des techniques et solutions externes de surveillance précédentes pour Exchange, la disponibilité gérée ne tente pas d'identifier ni de communiquer la cause première d'un incident. Au contraire, elle se concentre sur les aspects de récupération qui visent trois domaines clés de l'expérience utilisateur :

• Disponibilité : les utilisateurs peuvent-ils accéder au service ?
• Latence : comment est l’expérience pour les utilisateurs ?
• Erreurs : les utilisateurs sont-ils en mesure d’accomplir ce qu’ils veulent ?

La consolidation des rôles serveur et d’autres modifications architecturales dans Exchange 2013 nécessitent une nouvelle approche des méthodologies de surveillance et du modèle d’intégrité utilisés dans les versions précédentes d’Exchange. La disponibilité managée est conçue pour répondre à ces modifications en fournissant une solution native de surveillance et de récupération de l’intégrité. Elle s'écarte des tronçons distincts et individuels de surveillance du système pour se rapprocher de la surveillance de l'expérience utilisateur de bout en bout et de la protection de l'expérience de l'utilisateur final par le biais d'actions centrées sur la récupération.

La disponibilité managée est un processus interne qui s’exécute sur chaque serveur Exchange 2013. Elle interroge et analyse des centaines de paramètres d'intégrité par seconde. Si un élément est considéré comme incorrect, il sera généralement corrigé automatiquement. Cependant, il existera toujours des problèmes que la disponibilité gérée ne sera pas en mesure de corriger elle-même. Dans ce cas, la disponibilité gérée fait remonter le problème à un administrateur par le biais de la journalisation des événements.

Disponibilité managée implémentée sous la forme de deux services :

• Service Exchange Health Manager (MSExchangeHMHost.exe) : ce service est un processus de contrôleur utilisé pour gérer les processus de travail. Il permet de générer, d'exécuter et de démarrer et d'arrêter le processus de travail, selon les besoins. Il permet également de récupérer le processus de travail en cas d'échec de ce dernier, afin d'empêcher le processus de travail de devenir un point de défaillance unique.

• Processus du worker Exchange Health Manager (MSExchangeHMWorker.exe) : ce service est le processus de travail responsable de l’exécution des tâches d’exécution dans l’infrastructure de disponibilité managée.

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

• Les fichiers XML du dossier \bin\Monitoring\config sont utilisés pour stocker les paramètres de configuration de certains éléments de surveillance et de sondage.
• Active Directory est utilisé pour stocker les substitutions globales.
• Le registre de Windows est utilisé pour stocker des données d'exécution, comme les signets, et les substitutions locales (propres à un serveur).
• L'infrastructure du journal des événements du canal pourpre de Windows est utilisée pour stocker les résultats d'éléments de travail.
• Les boîtes aux lettres d'intégrité sont utilisées pour l'activité de sondage. Plusieurs boîtes aux lettres d'intégrité seront créées sur chaque base de données de boîtes aux lettres qui existe sur le serveur.

Comme le montre l'illustration ci-dessous, la disponibilité gérée comprend trois principaux composants asynchrones qui fonctionnent en permanence.

Le premier composant est une sonde. Les sondes prennent les mesures sur le serveur et collectent 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, les répondeurs sont responsables des actions de récupération et de réaffectation. En cas d'état défectueux, la première action consiste à essayer de récupérer le composant. Cet effort de récupération peut inclure des actions de récupération à plusieurs étapes ; par exemple, la première tentative peut être de redémarrer le pool d’applications, la deuxième peut être de redémarrer le service, la troisième tentative peut être de redémarrer le serveur et la tentative suivante peut être de mettre le serveur hors connexion afin qu’il n’accepte plus le 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.

Il existe trois principales catégories de sondes : les sondes récurrentes, les notifications et les contrôles. Les sondes récurrentes sont des transactions synthétiques effectuées par le système pour tester l'expérience utilisateur de bout en bout. Les vérifications sont l’infrastructure qui effectue la collecte des données de performances, y compris le trafic utilisateur, et mesure les données collectées par rapport aux seuils définis pour déterminer les pics de défaillance des utilisateurs. Cette fonctionnalité de mesure permet à l’infrastructure de vérification de prendre conscience des problèmes rencontrés par les utilisateurs. Enfin, la logique de notification permet au système d’agir immédiatement en fonction d’un événement critique, sans avoir à attendre les résultats des données collectées par une sonde. Ces exceptions ou conditions peuvent être détectées et reconnues sans ensemble d’exemples volumineux.

Les sondes récurrentes s’exécutent toutes les quelques minutes et vérifient certains aspects de l’intégrité du service. Ces sondes peuvent transmettre un e-mail via Exchange ActiveSync à une boîte aux lettres d’analyse, se connecter à un point de terminaison RPC ou vérifier la connectivité de l’accès client aux boîtes aux lettres.

Toutes les sondes sont définies au démarrage du service du Gestionnaire d'intégrité dans le canal pourpre Microsoft.Exchange.ActiveMonitoring\ProbeDefinition. Chaque définition de sonde a de nombreuses propriétés, mais les propriétés les plus pertinentes sont les suivantes :

• Nom : nom de la sonde, qui commence par un SampleMask du moniteur de la sonde.
• TypeName : type d’objet code de la sonde qui contient la logique de la sonde.
• ServiceName : nom du jeu d’intégrité qui contient cette sonde.
• TargetResource : objet que la sonde valide. Ce nom de propriété est ajouté au nom de la sonde lorsqu’elle est exécutée pour devenir un résultat de sonde ResultName
• RecurrenceIntervalSeconds : fréquence d’exécution de la sonde.
• TimeoutSeconds : durée d’attente de la sonde avant d’échouer.

Il existe des centaines de sondes récurrentes. La plupart de ces sondes sont par base de données, donc à mesure que le nombre de bases de données augmente, il en va de même pour le nombre de sondes. La plupart des sondes sont définies dans le code et ne sont donc pas directement détectables.

Les bases d’une sonde récurrente sont les suivantes : démarrer toutes les RecurrenceIntervalSeconds et vérifier (ou sonder) certains aspects de l’intégrité. Si le composant est en bon état, la sonde transmet et écrit un événement d’informations dans le canal Microsoft.Exchange.ActiveMonitoring\ProbeResult avec un ResultType de 3. Si le contrôle échoue ou expire, la sonde échoue et écrit un événement d’erreur dans le même canal. Un ResultType de 4 signifie que la vérification a échoué et un ResultType de 1 signifie qu’il a expiré. De nombreuses sondes sont réexécutées si elles expirent, jusqu’à la valeur de la propriété MaxRetryAttempts .

Remarque

Le canal pourpre ProbeResult peut être très occupé, car des centaines de sondes sont exécutées toutes les minutes et journalisent des événements. L'impact réel sur les performances de votre serveur Exchange peut s'avérer considérable si vous tentez d'exécuter des requêtes coûteuses sur les journaux des événements dans un environnement de production.

Les notifications sont des sondes qui ne sont pas exécutées par l'infrastructure du Gestionnaire d'intégrité, mais par un autre service sur le serveur. Ces services effectuent leur propre surveillance, puis fournissent leurs données à l'infrastructure de disponibilité gérée en écrivant directement les résultats des sondes. Vous ne verrez pas ces sondes dans le canal ProbeDefinition, car ce canal ne décrit que les sondes exécutées par l'infrastructure de disponibilité gérée. Par exemple, le moniteur ServerOneCopyMonitor est déclenché par les résultats de la sonde écrits par le service MSExchangeDAGMgmt. Ce service effectue sa propre surveillance, détermine s'il y a un problème et enregistre le résultat de la sonde. La plupart des sondes de notification peuvent journaliser un événement rouge qui rend le moniteur défectueux et un événement vert qui rétablit l'état du moniteur.

Les contrôles sont des sondes qui journalisent les événements uniquement lorsque le compteur de performances passe au-dessus ou en dessous d'un seuil défini. Ils correspondent vraiment à un cas particulier de sondes de notification, car il s'agit d'un service qui surveille les compteurs de performances sur le serveur et qui journalise les événements dans le canal ProbeResult lorsque le seuil configuré est atteint.

Pour connaitre le compteur et le seuil considéré comme défectueux, vous pouvez consulter ce contrôle dans le moniteur. Les moniteurs de type Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor ou Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor signifient que la sonde qu’ils observent est une sonde de vérification

Les moniteurs interrogent les données collectées par les sondes pour déterminer si une action doit être effectuée en fonction d’un ensemble de règles prédéfini. Selon la règle ou la nature du problème, un moniteur peut lancer un répondeur ou faire remonter le problème pour une intervention humaine via une entrée dans le journal des événements. En outre, les moniteurs définissent la durée d’exécution d’un répondeur après une défaillance et le flux de travail de l’action de récupération. Les moniteurs ont différents états. Du point de vue de l'état système, les moniteurs ont deux états :

• Sain : le moniteur fonctionne correctement et toutes les métriques collectées sont comprises dans les paramètres de fonctionnement normaux
• Non sain : le moniteur n’est pas sain et a lancé la récupération par le biais d’un répondeur ou a averti un administrateur par escalade.

D’un point de vue administratif, les moniteurs ont de nombreux autres états qui apparaissent dans l’interpréteur de commandes :

• Détérioré : lorsqu’un moniteur est dans un état non sain de 0 à 60 secondes, il est considéré comme détérioré. Si un moniteur est dans l'état non intègre pendant plus de 60 secondes, il est considéré comme Non intègre.
• Désactivé : le moniteur a été explicitement désactivé par un administrateur.
• Non disponible : le service d’intégrité Microsoft Exchange interroge régulièrement chaque moniteur pour connaître son état. S'il ne reçoit pas de réponse à la requête, l'état du moniteur devient Indisponible.
• Réparation : un administrateur définit l’état de réparation pour indiquer au système que l’action corrective est en cours par un humain, ce qui permet au système et aux humains de faire la distinction entre d’autres défaillances qui peuvent se produire en même temps qu’une action corrective est prise (par exemple, une opération de copie de base de données à nouveau).

Chaque moniteur a une propriété SampleMask dans sa définition. Au fur et à mesure que le moniteur s’exécute, il recherche des événements dans le canal ProbeResult qui ont un ResultName qui correspond au SampleMask de l’analyse. Ces événements peuvent provenir de sondes récurrentes, de notifications ou de contrôles. Si les seuils du moniteur sont atteints, celui-ci devient défectueux. Du point de vue du moniteur, les trois types de sonde sont identiques, car ils journalisent tous les événements dans le canal ProbeResult.

Il est à noter qu’une seule défaillance de sonde n’indique pas nécessairement qu’un problème est survenu avec le serveur. Il s’agit de la conception des moniteurs pour identifier correctement lorsqu’il y a un problème réel qui doit être résolu. Par conséquent, de nombreux moniteurs ont des seuils de plusieurs échecs de sonde avant de devenir défectueux. Même dans ce cas, un grand nombre de ces problèmes peuvent être résolus automatiquement par les répondeurs, de sorte que le meilleur endroit pour rechercher les problèmes qui nécessitent une intervention manuelle est dans le canal Microsoft.Exchange.ManagedAvailability\Monitoring crimson. Ce canal inclut l’erreur de sonde la plus récente.

Comme leur nom l'indique, ils répondent en quelque sorte à une alerte générée par un moniteur. Les répondeurs effectuent diverses actions de récupération, telles que la réinitialisation d’un pool de workers d’application au redémarrage d’un serveur. Il en existe plusieurs types :

• Redémarrer le répondeur : arrête et redémarre un service
• Réinitialiser le répondeur AppPool : arrête et redémarre un pool d’applications dans Internet Information Services (IIS)
• Répond au basculement : lance un basculement de base de données ou de serveur
• Répond à la vérification de bogue : lance une vérification d’erreur du serveur, provoquant ainsi un redémarrage du serveur
• Répondeur hors connexion : prend un protocole sur un serveur hors service (rejette les demandes du client)
• Répondeur en ligne : place un protocole sur un serveur de nouveau en production (accepte les demandes des clients)
• Réaffecter le répondeur : fait remonter le problème à un administrateur via la journalisation des événements

Outre les répondeurs mentionnés ci-dessus, certains composants disposent également de leurs propres répondeurs spécialisés.

Tous les répondeurs incluent un comportement de limitation, qui fournit un mécanisme de séquencement intégré pour contrôler les actions du répondeur. Le comportement de limitation est conçu pour garantir que le système n'est pas compromis ni aggravé suite aux actions de récupération du répondeur. Tous les répondeurs sont limités d'une certaine façon. Lorsque la limitation se produit, l'action de récupération du répondeur peut être ignorée ou différée, selon l'action du répondeur. Par exemple, lorsque le répondeur de vérification d’erreurs est limité, son action est ignorée, et non différée.

Indicateurs d’intégrité

Du point de vue des rapports, la disponibilité gérée offre deux vues de l’intégrité, une interne et une externe. La vue interne utilise les indicateurs d’intégrité. Chaque composant dans Exchange 2013 (par exemple, Outlook Web App, Exchange ActiveSync, le service banque d’informations, l’indexation de contenu, les services de transport, etc.) est surveillé par une disponibilité managée à l’aide de sondes, de moniteurs et de répondeurs. Un groupe de sondes, de moniteurs et de répondeurs pour un composant donné est appelé jeu d’intégrité. Un indicateur d'intégrité est un groupe de sondes, de moniteurs et de répondeurs qui détermine si ce composant est intègre. L’état actuel d’un jeu d’intégrité (par exemple, s’il est sain ou non sain) est déterminé à l’aide de l’état des moniteurs du jeu d’intégrité. Si tous les moniteurs d'un indicateur d'intégrité sont intègres, alors l'indicateur d'intégrité est également intègre. Si un moniteur n'est pas intègre, alors l'état de l'indicateur d'intégrité sera déterminé par son moniteur le moins intègre.

Pour obtenir la procédure détaillée pour l’affichage de l’intégrité d’un serveur ou de l’état des indicateurs d’intégrité, reportez-vous à la rubrique Manage health sets and server health.

Groupes d’intégrité

La vue externe de la disponibilité gérée est composée de groupes d’intégrité. Les groupes d’intégrité sont exposés à System Center Operations Manager 2007 R2 et System Center Operations Manager 2012.

Il existe quatre principaux groupes d'intégrité :

• Points de contact client : composants qui affectent les interactions utilisateur en temps réel, tels que les protocoles ou la banque d’informations
• Composants de service : composants sans interactions utilisateur directes en temps réel, comme le service de réplication de boîte aux lettres Microsoft Exchange ou le processus de génération de carnet d’adresses en mode hors connexion (OABGen)
• Composants du serveur : ressources physiques du serveur, telles que l’espace disque, la mémoire et la mise en réseau
• Disponibilité des dépendances : capacité du serveur à accéder aux dépendances nécessaires, telles qu’Active Directory, DNS, etc.

Lorsque Exchange Management Pack est installé, System Center Operations Manager (SCOM) agit comme un portail d'intégrité pour l'affichage des informations relatives à l'environnement Exchange. Le tableau de bord SCOM comprend trois vues de l'intégrité du serveur Exchange :

• Alertes actives : les répondeurs d’escalade écrivent des événements dans le journal des événements Windows qui sont consommés par le moniteur dans SCOM. Ces événements apparaissent sous forme d’alertes dans la vue Alertes actives.
• Intégrité de l’organisation : un résumé cumulatif de l’intégrité globale de l’intégrité de l’organisation Exchange s’affiche dans cette vue. Ces cumuls comprennent l'affichage de l'intégrité pour les différents groupes de disponibilité de base de données, et de l'intégrité de sites Active Directory spécifiques.
• Intégrité du serveur : les ensembles d’intégrité associés sont combinés en groupes d’intégrité et résumés dans cette vue.

Substitutions

Les substitutions offrent à l’administrateur la possibilité de configurer certains aspects des sondes, des moniteurs et des répondeurs de disponibilité gérée. Les substitutions peuvent être utilisées pour régler certains des seuils utilisés par la disponibilité gérée. Elles peuvent également être utilisées pour permettre des actions d'urgence pour les événements imprévus qui peuvent nécessiter des paramètres de configuration différents des valeurs par défaut prédéfinies.

Les remplacements peuvent être créés et appliqués à un seul serveur (ce processus est appelé remplacement de serveur), ou ils peuvent être appliqués à un groupe de serveurs (ce processus est appelé remplacement global). Les données de configuration des substitutions de serveur sont stockées dans le Registre de Windows sur le serveur sur lequel la substitution est appliquée. Les données de configuration des substitutions globales sont stockées dans Active Directory.

Les substitutions peuvent être configurées pour durer indéfiniment, ou elles peuvent être configurées pour une durée déterminée. En outre, les substitutions globales peuvent être configurées pour s'appliquer à tous les serveurs, ou seulement aux serveurs exécutant une version spécifique de Exchange.

Lorsque vous configurez une substitution, elle ne prend pas effet immédiatement. Le service du gestionnaire d'intégrité Microsoft Exchange vérifie que les données de configuration sont mises à jour toutes les 10 minutes. En outre, les substitutions globales dépendent de la latence de réplication Active Directory.

Pour obtenir des instructions détaillées pour afficher ou configurer les remplacements de serveur ou globaux, consultez Configurer les remplacements de disponibilité managée.

Cmdlets et tâches de gestion

Il existe trois tâches opérationnelles principales que les administrateurs effectueront généralement pour la disponibilité gérée :

• Extraction ou affichage de l'intégrité du système
• Affichage des indicateurs d'intégrité et des détails des sondes, moniteurs et répondeurs
• Gestion des substitutions

Les deux principaux outils de gestion pour la disponibilité gérée sont le journal des événements Windows et le Shell. La disponibilité gérée consigne une grande quantité d'informations dans les journaux des événements du canal Crimson Exchange ActiveMonitoring et ManagedAvailability, tels que :

• Définitions des sondes, moniteurs et répondeurs, qui sont consignées dans les journaux d’événements *Définition respectifs.
• Résultats de sondes, moniteurs et répondeurs, qui sont consignés dans les journaux d’événements *Résultats respectifs.
• Les détails sur les actions de récupération de répondeur, y compris lorsque l’action de récupération est lancée, et qu’elle est considérée comme terminée (réussie ou non), qui sont consignés dans le journal des événements RecoveryActionResults.

Il existe 12 cmdlets utilisées pour la disponibilité gérée, qui sont décrites dans le tableau suivant.

Applet de commande	Description
Get-ServerHealth	Permet d'obtenir des informations brutes sur l'intégrité du serveur, comme les indicateurs d'intégrité et leur état actuel (intègre ou non), les moniteurs d'indicateurs d'intégrité, les composants de serveur, les ressources cibles pour les sondes, les horodatages liés à l'heure de démarrage ou d'arrêt des sondes et ou des moniteurs, et les durées des transitions d'état.
Get-HealthReport	Permet d'obtenir une vue récapitulative de l'intégrité comprenant les indicateurs d'intégrité et leur état actuel.
Get-MonitoringItemIdentity	Permet d'afficher les sondes, les moniteurs et les répondeurs associés à un indicateur d'intégrité spécifique.
Get-MonitoringItemHelp	Permet d'afficher les descriptions de certaines des propriétés de sondes, de moniteurs et de répondeurs.
Add-ServerMonitoringOverride	Permet de créer une substitution locale propre au serveur d'une sonde, d'un moniteur ou d'un répondeur.
Get-ServerMonitoringOverride	Permet d'afficher la liste des substitutions locales sur le serveur spécifié.
Remove-ServerMonitoringOverride	Permet de supprimer une substitution locale d'un serveur spécifique.
Add-GlobalMonitoringOverride	Permet de créer une substitution globale pour un groupe de serveurs.
Get-GlobalMonitoringOverride	Permet d'afficher la liste des substitutions globales configurées dans l'organisation.
Remove-GlobalMonitoringOverride	Permet de supprimer une substitution globale.
Set-ServerComponentState	Permet de configurer l'état d'un ou plusieurs composants de serveur.
Get-ServerComponentState	Permet d'afficher l'état d'un ou plusieurs composants de serveur.