Gestion de la disponibilité

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, tous les aspects du système doivent être activement surveillés et tous les problèmes détectés doivent être 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.

Disponibilité gérée

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 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é managée est un processus interne qui s’exécute sur chaque serveur Exchange. 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é managée fait remonter le problème à un administrateur avec la journalisation 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 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) : il s’agit du 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.

Composants de la disponibilité gérée

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

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 vérifications sont 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 s’exécutent toutes les quelques minutes et évaluent 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 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. Ceci 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: temps d'attente de la sonde avant échec.

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 .

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

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. 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 des états supplémentaires qui apparaissent dans Exchange Management Shell :

• 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é 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 convient de 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. C’est pourquoi de nombreux moniteurs ont des seuils de plusieurs échecs de sonde avant de devenir non sain. 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. Cela 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, telles que la réinitialisation d’un pool de workers d’application 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 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 Server (par exemple, Outlook sur le web, Exchange ActiveSync, le service de magasin 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 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 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 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’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 indicateurs d'intégrité associés sont réunis 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 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 un remplacement, il 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

Les administrateurs effectuent généralement trois tâches opérationnelles principales en ce qui concerne la disponibilité managé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é managée sont le journal des événements Windows et l’environnement de ligne de commande Exchange Management 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.

• Détails sur les actions de récupération du répondeur, notamment quand l’action de récupération est démarrée et qu’elle est considérée comme terminée (qu’elle soit réussie ou non), qui sont consignées 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.