Disponibilité gérée

[Cette rubrique est une documentation préliminaire et peut être modifiée dans les versions ultérieures. Des rubriques vides sont incluses comme espaces réservés. N’hésitez pas à nous transmettre vos commentaires. Envoyez-nous un e-mail à l’adresse ExchangeHelpFeedback@microsoft.com.]  

S’applique à :Exchange Online, Exchange Server 2016

Découvrez comment surveiller votre organisation UNRESOLVED_TOKEN_VAL(ex+2k16) pour résoudre rapidement les problèmes afin d’améliorer la disponibilité et la fiabilité.

L’objectif des administrateurs de système de messagerie a toujours été de fournir une expérience de messagerie optimale aux utilisateurs. Dans votre organisation Exchange Server 2016, tous les aspects du système doivent être surveillés activement, et les problèmes détectés résolus rapidement. Pour ce faire, la fonctionnalité Disponibilité gérée fournit des actions intégrées de surveillance et de récupération qui permettent de préserver l’expérience de l’utilisateur final.

La disponibilité gérée, également appelée Surveillance active ou Surveillance active locale, est l’intégration des actions de récupération et de surveillance intégrées avec 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 à ce service ?

  • Latence   Quelle est l’expérience pour les utilisateurs ?

  • Erreurs   Les utilisateurs peuvent-ils faire ce qu’ils veulent ?

La disponibilité gérée offre une solution native de surveillance de l’intégrité et de récupération. 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é gérée est un processus interne qui s'exécute sur chaque serveur Exchange 2016. 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.

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

  • ExchangeService de gestionnaire d’intégrité Exchange (MSExchangeHMHost.exe)   Il s’agit d’un processus contrôleur permettant de gérer des 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.

  • Exchange Processus de travail du gestionnaire d’intégrité Exchange (MSExchangeHMWorker.exe)   Il s’agit du processus de travail qui est chargé de réaliser les tâches d’exécution dans la structure de disponibilité géré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.

Composants de la disponibilité gérée

Composants de disponibilité gérée dans Exchange Server 2016

Sondes

Le premier composant est une sonde. Les sondes prennent les mesures sur le serveur et collectent des données.

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 contrôles constituent l’infrastructure qui effectue la collecte des données de performances, y compris le trafic utilisateur. Les contrôles mesurent également les données collectées et les comparent aux seuils définis pour déterminer les pointes de pannes des utilisateurs, ce qui permet à l’infrastructure des contrôles d’être informée au moment où les utilisateurs rencontrent des problèmes. Enfin, la logique de notification permet au système de prendre immédiatement des mesures en cas d’événement grave sans devoir attendre les résultats des données collectées par une sonde. Il s'agit généralement d’exceptions ou de conditions détectables et reconnaissables sans échantillonnage important.

Les sondes récurrentes sont exécutées à quelques minutes d’intervalle et évaluent certains aspects de l’état du service. Elles peuvent transmettre un courrier électronique à une boîte aux lettres de surveillance via Exchange ActiveSync. Elles peuvent aussi être connectées à un point de terminaison RPC ou vérifier la connectivité d’accès à la boîte aux lettres du client.

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

  • Name : nom de la sonde, qui commence avec un SampleMask du moniteur de la sonde.

  • TypeName : type d’objet de code de la sonde qui contient la logique de la sonde.

  • ServiceName : nom du groupe d’intégrité contenant cette sonde.

  • TargetResource : objet que la sonde valide. Cet élément est ajouté au nom de la sonde lors de son exécution afin de devenir un élément ResultName de résultat de la sonde.

  • RecurrenceIntervalSeconds : fréquence d’exécution de la sonde.

  • TimeoutSeconds : temps d’attente de la sonde avant échec.

Il existe des centaines de sondes récurrentes. Beaucoup de ces sondes sont propres à des bases de données. Par conséquent, leur nombre augmente à mesure que des bases de données sont ajoutées. 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 le contrôle a échoué et un ResultType de 1 signifie qu’il a expiré. Un grand nombre de sondes sont réexécutées si elles expirent, jusqu’à la valeur de la propriété MaxRetryAttempts.

noteRemarque :
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. Un moniteur du type Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor ou Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor signifie que la sonde qu’il surveille est une sonde de contrôle.

Moniteur

Les résultats des mesures collectées par les sondes sont transmis au deuxième composant, le moniteur. Le moniteur contient toute la logique métier utilisée par le système 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.

Les moniteurs interrogent les données pour déterminer si une action doit être menée selon un ensemble de règles prédéfinies. 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. De plus, les moniteurs définissent le délai au bout duquel le répondeur est exécuté après une panne, ainsi que 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 :

  • Intègre   Le moniteur fonctionne correctement et toutes les mesures collectées sont dans les tolérances normales des paramètres de fonctionnement.

  • Non intègre   Le moniteur est défectueux et a lancé une action de récupération via un répondeur ou averti un administrateur par le biais d’une escalade.

Du point de vue de l’administrateur, les moniteurs ont d’autres états qui apparaissent dans le Shell :

  • Dégradé   Lorsque l’état d’un moniteur est « non intègre » sur une période de 0 à 60 secondes, il est considéré comme Dégradé. 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.

  • Indisponible   Le service d’intégrité 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.

  • En cours de réparation   Un administrateur définit l’état « En cours de réparation » pour indiquer au système qu’une action correctrice est en cours d’exécution par une intervention humaine : cela permet au système et aux personnes de faire la distinction avec d’autres pannes qui peuvent se produire au même moment alors que l’action correctrice est en cours d’exécution (par exemple, l’opération de réamorçage d’une copie d’une base de données).

La définition de chaque moniteur contient une propriété SampleMask. Lors de l’exécution du moniteur, celui-ci recherche les événements du canal ProbeResult qui possèdent un ResultName correspondant à l’élément SampleMask du moniteur. 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.

L’échec d’une seule sonde ne traduit pas nécessairement un dysfonctionnement au niveau du serveur. Le but des moniteurs est d’identifier correctement les problèmes réels qui doivent être corrigés. C’est la raison pour laquelle de nombreux moniteurs ne signalent un dysfonctionnement qu’après l’échec de plusieurs sondes. Et même dans ce cas, la plupart de ces problèmes peuvent être résolus automatiquement par les répondeurs. Par conséquent, le meilleur emplacement pour rechercher des problèmes qui nécessitent une intervention manuelle est le canal pourpre Microsoft.Exchange.ManagedAvailability\Monitoring. Ce canal inclut l’erreur de sonde la plus récente.

Répondeurs

Enfin, les répondeurs sont responsables des actions de récupération et de réaffectation. Comme leur nom l’indique, ils répondent en quelque sorte à une alerte générée par un moniteur. 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.

Les répondeurs effectuent diverses actions de récupération, comme la réinitialisation d’un pool de travail d’applications ou le redémarrage d’un serveur. Il en existe plusieurs types :

  • Répondeur de redémarrage Arrête et redémarre un service.

  • Répondeur de réinitialisation de pool d’applications Arrête et redémarre un pool d’applications dans IIS (Internet Information Services).

  • Répondeur de basculement Lance un basculement de base de données ou de serveur.

  • Répondeur de vérification d’erreurs Lance une vérification d’erreurs sur le serveur, ce qui provoque un redémarrage du serveur.

  • Répondeur hors ligne Met hors service un protocole sur un serveur (rejette les demandes des clients).

  • Répondeur en ligne Remet en service un protocole sur un serveur (accepte les demandes des clients).

  • Répondeur de réaffectation Transmet 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 comprennent un comportement de limitation, qui fournit un mécanisme de séquencement intégré pour le contrôle des actions de 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.

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 de Exchange 2016 (par exemple, Outlook sur le web, Exchange ActiveSync, le service de banque d’informations, l’indexation de contenu, les services de transport, etc.) est surveillé par la disponibilité gérée à l’aide de sondes, de moniteurs et de répondeurs. Un groupe de sondes, de moniteurs et de répondeurs d’un composant donné est appelé un indicateur 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 indicateur d’intégrité (par exemple, s’il est intègre ou non) est déterminé à l’aide de l’état des moniteurs de cet indicateur 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 Gérer les indicateurs d’intégrité et l’intégrité du serveur.

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 2012 R2.

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

  • Points de contact du client Composants qui affectent les interactions des utilisateurs en temps réel, tels que les protocoles ou la banque d’informations.

  • Composants de service Composants sans interaction directe des utilisateurs en temps réel, tels que le service de réplication de boîtes aux lettres Microsoft Exchange ou le processus de génération de carnet d’adresses en mode hors connexion (OABGen).

  • Composants de serveur Ressources physiques du serveur, telles que l’espace disque, la mémoire et la mise en réseau.

  • Disponibilité des dépendances La capacité du serveur à accéder aux dépendances nécessaires, telles que 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 et ceux-ci sont utilisés par le moniteur dans SCOM. Cela apparaît 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’organisation Exchange est affiché 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 indicateurs d’intégrité associés sont réunis en groupes d’intégrité et résumés dans cette vue.

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 substitutions peuvent être créées et appliquées à un seul serveur (elles sont alors appelées substitutions de serveur), ou elles peuvent être appliquées à un groupe de serveurs (elles sont alors appelées substitutions globales ). 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 la procédure détaillée d’affichage et de configuration des substitutions de serveur ou globales, reportez-vous à la rubrique Configurer des substitutions de disponibilité gérée.

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.

 

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

 
Afficher: