Leçons du Centre de données : disponibilité gérée

Article d’origine publié le samedi 22 septembre 2012

La surveillance est un composant clé de la réussite de tout déploiement Exchange. Dans les versions précédentes, nous avons investi lourdement dans le développement d’un moteur de corrélation et travaillé étroitement avec le groupe de produit System Center Operations Manager (SCOM) pour offrir une solution d’alerte complète pour les environnements Exchange.

Traditionnellement, la surveillance nécessite la collecte de données et, si nécessaire, l’exécution d’une action basée sur les données recueillies. Par exemple, dans le contexte de SCOM, différents mécanismes étaient utilisés pour recueillir des données par le biais du Pack de gestion Exchange :

Objectifs de surveillance d’Exchange Server 2013

Lors de la phase initiale du développement d’Exchange 2013, l’une des priorités consistait à améliorer la surveillance de bout en bout pour tous les déploiements d’Exchange, du plus petit déploiement local au plus grand déploiement au monde, Office 365. Nous avions trois principaux objectifs en tête :

1. Faire bénéficier les clients locaux de nos connaissances et de notre expérience du service Office 365  Le groupe de produit Exchange utilise Exchange Online depuis maintenant presque six ans. Le modèle d’opérations que nous utilisons est connu sous le nom de modèle d’opérations de développement (DevOps). Dans ce modèle, les problèmes sont remontés directement au développeur d’une fonctionnalité si celle-ci offre de mauvaises performances dans le cadre du service ou lorsqu’un client signale un problème inconnu. Quelle que soit l’origine du problème, le fait qu’il soit transmis directement au développeur responsabilise l’équipe de développement logiciel en mettant l’accent sur les défauts du logiciel.

   L’adoption de ce modèle nous a permis d’apprendre beaucoup de choses. Par exemple, dans le Pack de gestion Exchange 2010, il existe près de 1100 alertes. Mais au fil des ans, nous nous sommes rendu compte que seules environ 150 de ces alertes étaient utiles dans Office 365 (nous avons désactivé le reste). Nous avons également constaté que lorsqu’un problème était remonté jusqu’au développeur, celui-ci était plus enclin à essayer de résoudre le problème (par exemple avec un correctif de code, de nouveaux flux de travail de récupération ou en effectuant un réglage fin de l’alerte) car il ne souhaitait pas être constamment interrompu pour résoudre le même problème. Dans le cadre du modèle DevOps, nous avons mis en place un processus selon lequel les responsables ont chaque semaine une réunion durant laquelle sont étudiés les incidents de la semaine écoulée. Il en résulte le développement de flux de travail de récupération internes, tels que la réinitialisation des pools d’applications IIS. Avant Exchange 2013, nous avions notre propre moteur interne qui gérait ces flux de travail de récupération. Ces connaissances n’étaient jamais insérées dans les produits locaux. Avec Exchange 2013, nous avons séparé en composants le moteur de flux de travail de récupération de manière à partager ce que nous apprenons avec nos clients locaux.

2. Surveillance basée sur l’expérience de l’utilisateur final  Nous avons également découvert qu’une grande partie des méthodologies que nous utilisions pour la surveillance ne nous aidaient pas à exploiter l’environnement. En conséquence, nous avons décidé de basculer vers une vision orientée vers le client dans la manière dont nous abordons la surveillance.

   Dans les versions précédentes, chaque équipe de composant développait un modèle d’intégrité en articulant tous les différents composants au sein de son système. Par exemple, le transport est composé de SMTP-IN, SMTP-OUT, agents de transport, catégoriseur, moteur de routage, pilote de stockage, et ainsi de suite. L’équipe de composant générait ensuite des alertes relatives à chacun de ces composants. Ensuite, dans le Pack de gestion figurent des alertes qui vous indiquent que le pilote de stockage a subi une défaillance. Mais il manque une chose : l’alerte ne fournit aucune information sur l’expérience utilisateur de bout en bout ou sur ce qui peut être rompu dans cette expérience. Dans Exchange 2013, nous essayons par conséquent d’inverser le modèle. Nous ne nous débarrassons pas de notre surveillance au niveau du système car elle est importante, mais ce qui est vraiment important quand on souhaite gérer un service, c’est ce que voient les utilisateurs. Nous avons par conséquent retourné le modèle et nous essayons de surveiller l’expérience utilisateur.

3. Protéger l’expérience de l’utilisateur grâce à l’informatique orientée vers la récupération  Dans les versions précédentes d’Exchange, la surveillance était axée sur le système et les composants, et non sur la manière de récupérer et de restaurer automatiquement l’expérience de l’utilisateur final.

Surveillance d’Exchange Server 2013 - Disponibilité gérée

La disponibilité gérée est une infrastructure de surveillance et de récupération intégrée à la solution de haute disponibilité d’Exchange. Elle détecte les problèmes et met en œuvre une récupération dès qu’ils surviennent et qu’ils sont découverts.

La disponibilité gérée est centrée sur l’utilisateur. Nous souhaitons mesurer trois aspects clés : la disponibilité, l’expérience (qui, pour la plupart des protocoles clients, est mesurée en tant que latence) et si des erreurs se produisent. Pour mieux comprendre ces trois aspects, prenons comme exemple un utilisateur d’Outlook Web App (OWA).

L’aspect lié à la disponibilité revient simplement à savoir si l’utilisateur peut accéder à la page web OWA d’authentification basée sur les formulaires. Si ce n’est pas le cas, l’expérience est rompue, ce qui génèrera une escalade jusqu’au service d’assistance. En termes d’expérience, si l’utilisateur peut se connecter à OWA, à quoi ressemble l’expérience ? L’interface se charge-t-elle, peut-il accéder à son courrier électronique ? Le dernier aspect est la latence ; l’utilisateur peut se connecter et accéder à l’interface, mais avec quelle rapidité le courrier est-il affiché dans le navigateur ? Ce sont ces trois aspects qui composent l’expérience utilisateur final.

L’une des principales différences entre les versions précédentes et Exchange 2013 est le fait que dans Exchange 2013 notre solution de surveillance n’essaie pas de fournir la cause racine (ce qui ne veut pas dire que les données ne sont pas enregistrées dans les journaux, que des vidages ne sont pas générés ou que la cause racine ne peut pas être découverte). Il est important de comprendre qu’avec les versions précédentes, nous n’étions jamais très efficaces lorsqu’il s’agissait de communiquer la cause racine ; dans certains cas nous avions raison, dans de nombreux autres nous avions tort.

Composants de la disponibilité gérée

La disponibilité gérée est intégrée aux deux rôles serveur dans Exchange 2013. Elle comprend trois principaux composants asynchrones. Le premier composant est le moteur de sondage. Il est chargé de prendre des mesures sur le serveur, qui sont ensuite transmises au second composant, le moniteur. Celui-ci contient la logique métier qui code ce que nous considérons comme intègre. Il s’apparente un peu à un moteur de reconnaissance de modèle ; il recherche différents modèles dans les différentes mesures dont nous disposons et peut ensuite prendre une décision quant à l’intégrité d’un composant spécifique. Pour finir, il y a le moteur répondeur, ce que j’ai étiqueté « Recover » dans le schéma ci-dessous. Lorsqu’un composant est défectueux, la première action du moteur de réponse consiste à essayer de récupérer ce composant. La disponibilité gérée fournit des actions de récupération en plusieurs étapes : la première action peut consister à tenter de redémarrer le pool d’applications, la deuxième à redémarrer le service, la troisième à redémarrer le serveur et la dernière à mettre le serveur hors connexion afin qu’il n’accepte plus aucun trafic. Si ces tentatives échouent, la disponibilité gérée transfère alors le problème à quelqu’un par le biais de la notification de journal des événements.

Vous remarquerez peut-être également que nous avons décentralisé quelques éléments. Dans le passé, l’agent SCOM était installé sur chaque serveur et nous diffusions toutes les mesures vers un serveur SCOM central. Le serveur SCOM devait évaluer toutes les mesures pour déterminer si quelque chose était intègre ou non. Dans un environnement à grande échelle, la corrélation est plus complexe. Nous avons observé, entre autres, que le déclenchement des alertes était plus long. Le fait de « pousser » quelque chose vers un emplacement central n’offrait pas d’extensibilité. Au lieu de cela, chaque serveur joue le rôle d’île ; il exécute ses propres sondes, se surveille lui-même, exécute des actions de récupération automatique et, bien entendu, d’escalade en cas de besoin.

Figure 1: Composants de disponibilité gérée

Sondes

L’infrastructure de sondes est constituée de trois structures distinctes :

1. Les sondes sont des transactions synthétiquescréées par chaque équipe de composant. Elles sont semblables aux applets de commande de test dans les versions précédentes. Elles mesurent la perception du service en exécutant des transactions synthétiques d’utilisateur à utilisateur.
2. Les vérifications sont un mécanisme de surveillance passive. Elles mesurent le trafic client réel.
3. La structure de notification nous permet de prendre des mesures immédiates et de ne pas attendre l’exécution d’une sonde. De cette manière, en cas de détection d’une défaillance, nous pouvons prendre des mesures immédiates. La structure de notification est basée sur des notifications. Par exemple, lorsqu’un certificat expire, un événement de notification est déclenché afin de signaler aux opérations que le certificat doit être renouvelé.

Moniteurs

Les données recueillies par les sondes sont fournies à des moniteurs. Il n’existe pas obligatoirement une corrélation un-à-un entre les sondes et les moniteurs ; de nombreuses sondes peuvent fournir des données à un même moniteur. Les moniteurs examinent les résultats des sondes et parviennent à une conclusion. Celle-ci est binaire : le moniteur est intègre ou non intègre.

Comme mentionné plus haut, la surveillance Exchange 2013 est axée sur l’expérience utilisateur final. Nous devons pour cela surveiller différentes couches de l’environnement :

Figure 2 : Surveillance de différentes couches afin de vérifier l’expérience utilisateur

Comme vous pouvez l’observer sur le schéma ci-dessus, nous avons quatre vérifications différentes. La première est l’auto-test de boîte aux lettres ; cette sonde vérifie que l’interface ou le protocole local peut accéder à la base de données. La seconde vérification est l’auto-test de protocole ; elle vérifie que le protocole local sur le serveur de boîtes aux lettres fonctionne. La troisième vérification est l’auto-test de proxy ; elle s’exécute sur le serveur d’accès au client et vérifie que la fonctionnalité de proxy pour le protocole fonctionne. La quatrième et dernière vérification est une vérification complète qui valide l’expérience de bout en bout (du proxy de protocole aux fonctions de stockage). Chaque vérification exécute une détection à différents intervalles.

Nous effectuons une surveillance à différents niveaux afin de gérer les dépendances. Étant donné l’absence de moteur de corrélation dans Exchange 2013, nous essayons de différencier nos dépendances avec des codes d’erreurs uniques qui correspondent à différentes sondes et avec des sondes qui ne touchent aucune dépendance. Par exemple, si vous constatez qu’une sonde d’auto-test de boîte aux lettres et une sonde d’auto-test de protocole échouent toutes deux en même temps, qu’est-ce que cela signifie ? Que le magasin est défectueux ? Pas nécessairement ; cela signifie plutôt que l’instance de protocole locale sur le serveur de boîtes aux lettres ne fonctionne pas. Si un auto-test de protocole fonctionne mais qu’un auto-test de boîte aux lettres échoue, cela signifie qu’il y a un problème au niveau de la couche de « stockage » (il se peut notamment que le magasin ou la base de données soit hors connexion).

D’un point de vue de la surveillance, tout cela signifie que nous contrôlons désormais plus étroitement les alertes qui sont émises. Par exemple, si nous évaluons l’intégrité d’OWA, il est plus probable que nous retardions le déclenchement d’une alerte dans le cas où l’auto-test de boîte aux lettres a échoué mais l’auto-test de protocole a réussi. En revanche, une alerte est émise en cas de non-intégrité des moniteurs d’auto-test de boîte aux lettres et d’auto-test de protocole.

Répondeurs

Les répondeurs exécutent des réponses basées sur les alertes générées par un moniteur. Ils ne s’exécutent que si un moniteur est non intègre.

Plusieurs types de répondeurs sont disponibles :

• Répondeur de redémarrage  Arrête et redémarre le service
• Répondeur de réinitialisation de pool d’applications  Exécute un cycle de réinitialisation du pool d’applications IIS
• Répondeur de basculement  Met hors service un serveur de boîtes aux lettres Exchange 2013
• Répondeur de vérification d’erreur  Initie une vérification d’erreur sur le serveur
• Répondeur hors connexion  Met hors service un protocole sur un ordinateur
• Répondeur d’escalade  Fait remonter un problème
• Répondeurs de composants spécialisés 

Le répondeur hors connexion sert à annuler l’utilisation d’un protocole sur les serveurs d’accès au client. Ce répondeur a été conçu de manière à être agnostique du point de vue de l’équilibrage de la charge. Lorsque ce répondeur est appelé, le protocole ne reconnaît pas le contrôle d’intégrité du programme d’équilibrage de la charge, ce qui permet à ce dernier de supprimer le serveur ou le protocole du pool d’équilibrage de la charge. De même, il existe un répondeur en ligne correspondant initié automatiquement dès que le moniteur correspondant redevient intègre (en supposant qu’aucun autre moniteur associé n’est dans un état de non-intégrité) ; le répondeur en ligne permet simplement au protocole de répondre au contrôle d’intégrité du programme d’équilibrage de la charge, ce qui permet à ce dernier de rajouter le serveur ou le protocole au pool d’équilibrage de la charge. Le répondeur hors connexion peut également être appelé manuellement par le biais de l’applet de commande Set-ServerComponentState. Cela permet aux administrateurs de placer manuellement les serveurs d’accès au client en mode de maintenance.

Lorsque le répondeur d’escalade est appelé, il génère un événement Windows reconnu par le Pack de gestion Exchange 2013. Il ne s’agit pas d’un événement Exchange normal, qui signale qu’OWA a subi une défaillance générale ou une défaillance d’E/S, mais plutôt d’un événement Exchange qui indique qu’un jeu d’intégrité est non intègre ou intègre. Nous utilisons des événements d’instances uniques de ce genre pour manipuler les moniteurs dans SCOM sur la base d’un événement généré dans le répondeur d’escalade, par opposition aux événements distribués dans tout le produit. Il y a par conséquent un certain niveau d’indirection. La disponibilité gérée décide quand nous inversons un moniteur dans SCOM. Elle décide quand une remontée doit avoir lieu, autrement dit quand faire appel à une intervention humaine.

Les répondeurs peuvent également être limités afin de s’assurer que le service entier n’est pas compromis. La limitation varie selon le répondeur :

• Certains répondeurs prennent en compte la quantité minimale de serveurs dans le DAG ou le pool de serveurs d’accès au client à équilibrage de la charge.
• Certains répondeurs prennent en compte la durée entre les exécutions.
• Certains répondeurs prennent en compte le nombres de fois que le répondeur a été initié.
• Certains répondeurs peuvent prendre en compte une combinaison des critères ci-dessus.

En fonction du répondeur, quand la limitation se produit, l’action du répondeur peut être retardée ou simplement ignorée.

Séquences de récupération

Il est important de bien comprendre que les moniteurs définissent les types de répondeurs exécutés et la chronologie selon laquelle ils sont exécutés ; nous appelons cela une « séquence de récupération » de moniteur. Supposons par exemple que les données de sonde pour le protocole OWA (l’auto-test de protocole) signale la non-intégrité du moniteur. À ce stade, l’heure actuelle est enregistrée (nous la nommerons T). Le moniteur démarre un pipeline de récupération basé sur l’heure actuelle. Il peut définir des actions de récupération à certains intervalles de temps nommés dans le cadre du pipeline de récupération. Dans le cas du moniteur de protocole OWA sur le serveur de boîtes aux lettres, la séquence de récupération est la suivante :

1. À T=0, le répondeur de réinitialisation du pool d’applications IIS est exécuté.
2. Si à T=5 minutes le moniteur n’est pas revenu à un état d’intégrité, le répondeur de basculement est initié et les bases de données sont déplacées hors du serveur.
3. Si à T=8 minutes le moniteur n’est pas revenu à un état d’intégrité, le répondeur de vérification d’erreur est initié et un redémarrage du serveur est forcé.
4. Si à T=15 minutes le moniteur n’est toujours pas revenu à un état d’intégrité, le répondeur d’escalade est déclenché.

Le pipeline de séquence de récupération s’arrête quand le moniteur revient à un état d’intégrité. Notez qu’il n’est pas obligatoire que la dernière action temporelle nommée se termine avant le démarrage de l’action temporelle suivante.  De plus, un moniteur peut avoir une quantité quelconque d’intervalles de temps nommés.

Systems Center Operations Manager (SCOM)

Systems Center Operations Manager (SCOM) est utilisé comme portail pour afficher les informations d’intégrité liées à l’environnement Exchange. Les états de non-intégrité sur le portail SCOM sont déclenchés par des événements consignés dans le journal des applications via le répondeur d’escalade. Le tableau de bord SCOM a été affiné et contient désormais trois principales zones :

• Alertes actives
• Intégrité de l’organisation
• Intégrité du serveur

Le pack de gestion SCOM Exchange Server 2013 sera pris en charge avec SCOM 2007 R2 et SCOM 2012.

Substitutions

Dans tout environnement, il se peut que les paramètres par défaut ne soient pas optimaux ou que certaines conditions exigent une action d’urgence. La disponibilité gérée inclut la capacité à activer des substitutions pour l’ensemble de l’environnement ou sur un serveur spécifique. Chaque substitution peut être définie pour une durée spécifiée ou de façon à s’appliquer à une version spécifique du serveur. Les applets de commande *-ServerMonitoringOverride et *-GlobalMonitoringOverride permettent aux administrateurs de définir, supprimer ou afficher les substitutions.

Détermination de l’intégrité

Les moniteurs qui sont semblables ou liés à l’architecture d’un composant particulier sont regroupés de façon à former des jeux d’intégrité. L’intégrité d’un jeu d’intégrité est toujours déterminée par la « pire » évaluation des moniteurs appartenant au jeu d’intégrité, ce qui signifie que si vous avez neuf moniteurs dans un jeu et que l’un d’entre eux est non intègre, le jeu d’intégrité est considéré comme non intègre. Vous pouvez déterminer la collection de moniteurs (et de sondes et répondeurs associés) dans un jeu d’intégrité donné à l’aide de l’applet de commande Get-MonitoringItemIdentity.

Pour afficher l’intégrité, vous devez utiliser les applets de commande Get-ServerHealth et Get-HealthReport. Get-ServerHealth sert à extraire les données d’intégrité brutes, tandis que Get-HealthReport opère sur les données d’intégrité brutes et fournit un instantané de l’intégrité. Ces applets de commande peut opérer à différents niveaux :

• Elles peuvent afficher l’intégrité d’un serveur donné, avec une répartition par jeu d’intégrité.
• Elles peuvent servir à effectuer une analyse approfondie d’un jeu d’intégrité donné et à visualiser l’état de chaque moniteur.
• Elles peuvent servir à obtenir un résumé de l’intégrité d’un jeu de serveurs donné (membres DAG ou baie de serveurs d’accès au client à équilibrage de charge).

Les jeux d’intégrité sont à leur tour regroupés en unités fonctionnelles nommées groupes d’intégrité. Il existe quatre groupes d’intégrité, qui servent à générer des rapports sur le portail de gestion SCOM :

1. Points de contact avec les clients – composants avec des interactions directes et en temps réel avec les clients (par exemple OWA).
2. Composants de service – composants sans interaction directe et en temps réel avec les clients (par exemple génération de carnet d’adresses en mode hors connexion).
3. Composants de serveur – ressources physiques d’un serveur (par exemple disque ou mémoire).
4. Disponibilité des dépendances – capacité d’un serveur à appeler des dépendances (par exemple Active Directory).

Conclusion

La disponibilité gérée effectue différentes évaluations d’intégrité sur chaque serveur. Ces tests périodiques déterminent la viabilité de différents composants sur le serveur, ce qui permet d’établir l’état d’intégrité du serveur (ou de l’ensemble de serveurs) avant et durant la charge utilisateur. En cas de détection d’un problème, des actions correctives en plusieurs étapes sont exécutées pour ramener le serveur à un état opérationnel ; dans le cas où l’état d’intégrité d’un serveur ne serait pas rétabli, la disponibilité gérée peut alerter les opérateurs et leur signaler qu’une attention est nécessaire.

La conséquence est que la disponibilité gérée est axée sur l’expérience utilisateur et que même si des problèmes peuvent survenir, ils n’ont qu’un impact minimal, voire nul, sur l’expérience.

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Lessons from the Datacenter: Managed Availability