Résumé Le pack d'administration de Microsoft Exchange Server 2010 inclut un modèle d'intégrité complet, une couverture étendue des transactions synthétiques de protocole et un supplément complet d'alertes basées sur des diagnostics et de rapports orientés services,








télécharger 330.77 Kb.
titreRésumé Le pack d'administration de Microsoft Exchange Server 2010 inclut un modèle d'intégrité complet, une couverture étendue des transactions synthétiques de protocole et un supplément complet d'alertes basées sur des diagnostics et de rapports orientés services,
page4/10
date de publication29.04.2018
taille330.77 Kb.
typeRésumé
ar.21-bal.com > droit > Résumé
1   2   3   4   5   6   7   8   9   10

Considérations relatives à la sécurité


En raison du modèle de sécurité selon lequel Microsoft Exchange Server 2010 a été testé, l'exécution de l'agent sous une autre forme que LocalSystem n'a pas été testée.

Attention :

Si vous exécutez l'agent sous une autre forme que LocalSystem, l'exécution des transactions synthétiques échoue. Vous pouvez également rencontrer d'autres problèmes.

Présentation des opérations du pack d’administration


La compréhension des classes et de la fonction de corrélation d’alertes employée dans le pack d’administration de Microsoft Exchange Server 2010 est primordiale.

Consultez les rubriques suivantes pour en savoir plus sur les classes et la corrélation d’alertes dans le cadre du pack d’administration de Exchange Server 2010 :

    Présentation des classes

    Présentation de la corrélation d’alertes

Présentation des classes


Microsoft Exchange Server 2010 inclut un modèle de classe étendu. Les diagrammes qui présentent le modèle de classe peuvent être consultés à la section Annexe : hiérarchie de classes plus loin dans ce guide. Vous devez tenir compte des informations suivantes concernant les classes serveur d’accès au client et les classes agrégées à l’échelle du site.

Classes du protocole d’accès au client et du service d’accès au client

Le rôle serveur d’accès au client est fortement associé aux limites du site Active Directory. Le modèle de classe pour l’accès au client est le reflet de cette association. Pour la plupart des classes de protocole hébergées sur l’ordinateur agent/Exchange, il existe une classe hébergée sur le serveur d’administration racine qui décrit le bon fonctionnement du protocole concerné sur le site. Il y a alors cumul de l’état entre ce protocole sur chaque serveur et l’instance à l’échelle du site.

Classes agrégées à l’échelle du site

Les classes agrégées à l’échelle du site ont recours à une agrégation dans leurs analyses de dépendance pour permettre un changement d’état uniquement lorsque tous les serveurs d’accès au client détecte l’échec d’un protocole en particulier. Cette opération a pour but de modeler les actions correctives entreprises par les technologies d’équilibrage de charge afin de transférer la charge vers des serveurs fonctionnels en cas d’échec des protocoles/serveurs. Dans la section « Annexe : Hiérarchie des classes » de ce guide, ces classes sont dotées du suffixe « Service ». Elles sont représentées dans l’affichage « État du service ».

Pour plus de détails sur la manière dont ces classes agrégées à l’échelle du site influent sur les rapports de disponibilité, consultez la section « Annexe : Rapports » plus loin dans ce guide.

Présentation de la corrélation d’alertes


Le moteur de corrélation est le composant central du pack d’administration de Microsoft Exchange Server 2010. Il est conçu dans le but de réduire considérablement le nombre des alertes susceptibles de n’exiger aucune action de la part de l’administrateur chargé de surveiller l’environnement Exchange au moyen de la console System Center Operations Manager.

Architecture


Le moteur de corrélation est un service Windows autonome qui utilise l’interface du Kit de développement logiciel (SDK) de Microsoft Operations Manager pour extraire d’abord le modèle d’intégrité (ou espace d’instance), puis gérer les événements liés à un changement d’état. En conservant en mémoire le modèle d’intégrité et en traitant les événements de changement d’état, le moteur de corrélation peut déterminer à quel moment il doit émettre une alerte en fonction de l’état du système.



Dans le diagramme ci-dessus, vous pouvez constater que, en réponse à un problème, plusieurs analyses changent d’état et les événements de changement d’état correspondants sont transmis par l’agent au serveur d’administration racine. Une fois reçus sur le serveur d’administration racine, ils sont traités par le moteur de corrélation qui peut émettre une alerte via l’interface du Kit de développement logiciel (SDK) du serveur d’administration racine. Cette alerte est ensuite visible dans la console Operations Manager.

Classification des alertes


Les alertes du pack d’administration Exchange Server 2010 sont classées en trois catégories. Reportez-vous aux instructions suivantes pour comprendre les classifications des alertes.

    Indicateurs clés d’intégrité (KHI)   Les indicateurs clés d’intégrité (KHI) sont des éléments qui affectent l’intégrité du service. La majorité des alertes appartiennent à cette classe (par exemple, « Une base de données de boîtes aux lettres est démontée ».)

    NSI (Non-Service Impacting)   Les analyses NSI permettent de détecter des problèmes susceptibles d’avoir une incidence sur certains utilisateurs, mais pas tous les utilisateurs du système. Un bon exemple de situation NSI est l’utilisation d’une même adresse proxy par deux utilisateurs. Les messages émis à cette adresse seront retournés comme éléments non remis sans que cela nuise au système de transport global.

    Analyse d’investigation   Les analyses d’investigation permettent d’enregistrer des informations pertinentes tout en apportant une solution à un problème mais elles n’indiquent pas nécessairement une panne système importante ou existante. Par exemple, un processeur fonctionnant à 90 % pendant 5 minutes est un cas de problème d’investigation : il est possible qu’un processus n’applique pas comme il se doit les cycles processeur ou le serveur a peut-être été redémarré et le système se remet lentement à fonctionner de manière normale. Ces analyses sont visibles dans le champ Contexte de l’alerte des propriétés de l’alerte et dans l’Explorateur d’intégrité. Aucune alerte n’est émise pour les analyses d’investigation.

Remarque :

L’état n’est pas mis à jour lorsqu’une seule alerte d’analyse d’investigation est déclenchée. Il peut néanmoins l’être avec l’agrégation des alertes d’analyse d’investigation en cours pour chaque composant.
Gravité des alertes

Les alertes du pack d’administration Exchange Server 2010 sont également classées en fonction de la gravité des alertes. Reportez-vous aux instructions suivantes pour comprendre la gravité des alertes.

    Alertes d’erreur   Les alertes d’erreur nécessitent une intervention humaine pour rétablir le bon fonctionnement du service.

    Alertes d’avertissement   Les alertes d’avertissement sont le signe avant-coureur d’une éventuelle panne du système (pouvant entraîner une erreur, le cas échéant).

    Alertes d’information   Les alertes d’information ne sont pas déclenchées par le pack d’administration de Microsoft Exchange 2010.

Facteurs de corrélation


Les actions entreprises par le moteur de corrélation sont déterminées en fonction de plusieurs facteurs.

Événements de changement d’état des analyses   Les analyses chargées de surveiller les données de diagnostics propres à Exchange, notamment les messages du journal des événements, les seuils des compteurs de performance, les événements de sortie des tâches PowerShell, enregistrent les événements de changement d’état lorsqu’elles détectent un problème qui est survenu ou qui a été supprimé (passage de l’état rouge à l’état vert et inversement) ou lorsque des agents ne sont plus disponibles ou ont été placés en mode maintenance (pour être ensuite disponibles et/ou retirés du mode maintenance).

Généralement, les règles des alertes sont configurées pour permettre le déclenchement d’alertes en cas de changement d’état (passage du vert au rouge). Dans le pack d’administration Exchange Server 2010, vous constaterez que ce n’est pas le cas. Pour être plus précis, les alertes ne sont pas automatiquement déclenchées suite à des changements d’état des analyses. Le moteur de corrélation peut déterminer la meilleure alerte à déclencher.

Modèle d’intégrité   La hiérarchie de classes importée dans Operations Manager par le pack d’administration Exchange Server 2010 est très étendue. Elle inclut des relations de classes qui définissent les dépendances des composants dans le système tout entier. En définissant les dépendances de ces composants dans la représentation objet du produit, le pack d’administration Exchange Server 2010 peut mieux comprendre l’intégrité de l’organisation Exchange. Par exemple, si le pack d’administration Exchange Server 2010 identifie Active Directory comme étant en mode hors connexion, il signalera également que la messagerie Exchange ne fonctionne pas pleinement.

Calcul du temps Le moteur de corrélation fonctionne par intervalles de 90 secondes. Lorsque des événements de changement d’état de plusieurs analyses surviennent en même temps, il attend de voir si des éléments potentiellement liés à la panne peuvent être détectés afin de déterminer au mieux la cause première du problème.
Algorithme de corrélation

Présentation du processus du moteur de corrélation

    1. Avant toute chose, il se connecte au Kit de développement logiciel (SDK) de Microsoft Operations Manager afin de télécharger l’état d’instance et de hiérarchie du modèle d’intégrité (au démarrage du service uniquement ou selon les besoins si des erreurs l’exigent).

    2. Ensuite, il interroge Operations Manager sur les derniers événements de changement d’état associés à des entités dans le pack d’administration Exchange.

    3. Si des nouveaux changements d’état NSI sont détectés, il émet alors des alertes à ce sujet.

    4. Les analyses KHI sont alors évaluées et des « chaînes » d’analyses KHI rouges sont isolées. Ces « chaînes » indiquent des problèmes d’échec d’une dépendance ayant un impact sur les processus qui en découlent. La reconnaissance de ces relations est l’étape clé.

    5. Des alertes sont émises pour l’analyse à l’origine du problème dans la chaîne KHI.

    6. Il patiente alors 90 secondes, puis redémarre à l’étape 2 ci-dessus.

Autres éléments d’intérêt concernant le processus du moteur de corrélation

     Si la « chaîne » des indicateurs KHI comprend à la fois des analyses d’erreur et d’avertissement, l’alerte est alors déclenchée en tant qu’erreur, quelle que soit la classe de l’analyse à l’origine du problème. Par exemple, si un processus de niveau supérieur définit une analyse d’erreur pour identifier des pannes et s’il est associé à une analyse d’avertissement au sein d’une dépendance, l’alerte sera alors déclenchée par rapport à la dépendance mais elle apparaîtra sous la forme d’une erreur et non d’un avertissement.

     Toutes les relations de classes ne sont pas utilisées pour la corrélation des alertes. Consultez la section Annexe : hiérarchie de classes plus loin dans ce guide pour connaître les relations spécifiques employées par le moteur de corrélation.

     La chaîne KHI, y compris les analyses d’investigation, est incluse dans le champ Contexte de l’alerte des propriétés de l’alerte finale. Les analyses associées à l’alerte concernée peuvent ainsi être inspectées. Ceci est également requis dans le cas des alertes déclenchées à partir des analyses de dépendance afin de déterminer la panne spécifique référencée par l’alerte.

     Les analyses en mode maintenance sont simplement ignorées au moment de l’évaluation du modèle d’intégrité.

Éléments affectés et non affectés par la corrélation d’alertes

Un aspect essentiel à retenir au sujet du pack d’administration Exchange Server 2010, et le moteur de corrélation en particulier, concerne les éléments affectés ou non par ce dernier.

Les éléments suivants diffèrent en raison du moteur de corrélation :

     Les analyses sont configurées afin qu’aucune alerte ne soit automatiquement émise lors d’événements de changement d’état. Ceci permet au moteur de corrélation de déterminer la meilleure alerte à déclencher (comme décrit ci-avant).

     Le pack d’administration Exchange Server 2010 ne déclenche pas des alertes Exchange relatives à l’intégrité de votre environnement lorsque vous arrêtez le moteur de corrélation. En cas d’arrêt du moteur de corrélation, une alerte générale est déclenchée pour vous informer que le moteur de corrélation n’est pas en cours d’exécution.

Les éléments suivants ne changent pas avec la présence du moteur de corrélation :

     Les remplacements fonctionnent toujours comme il se doit ; vous pouvez modifier certaines valeurs ou désactiver des analyses comme vous le faites actuellement.

     Les analyses/objets en mode maintenance sont ignorés par le moteur de corrélation. Aucune attention particulière n’est requise puisque les analyses ne déclenchent pas des événements de changement d’état à traiter avec le moteur de corrélation.

     Des règles d’alerte par analyse ont été ajoutées au pack d’administration Exchange Server 2010. Les règles d’alerte par analyse permettent au personnel de surveillance de saisir des notes relatives à l’entreprise pour une alerte donnée dans le champ Base de connaissances de la société, même lorsque les règles d’alerte ne sont pas utilisées pour déclencher des alertes pour leurs analyses correspondantes.

     La présence du moteur de corrélation n’a aucun impact sur d’autres packs d’administration.

Pour résumer, gardez à l’esprit que seule l’étape d’alerte de changement d’état d’analyse est optimisée dans le cadre de la corrélation.

Notes opérationnelles

Puisque le moteur de corrélation doit mémoriser l’espace d’instance du groupe de gestion afin de déterminer les analyses/alertes associées, son espace mémoire est défini en fonction du nombre d’instances dans le groupe de gestion. En termes simples, plus vous disposez de serveurs et de bases de données Exchange, plus la mémoire requise sera importante.

Dans certains environnements observés chez Microsoft, le moteur de corrélation évolue approximativement à 5 mégaoctets par serveur Exchange analysé. Ces facteurs peuvent faire augmenter ou baisser ce chiffre mais c’est un bon point de départ pour comprendre l’impact des ressources sur le serveur qui héberge le service.

Comme mentionné ci-avant, l’emplacement de prédilection pour le service est le rôle serveur d’administration racine en raison du lien étroit avec le Kit de développement logiciel (SDK) et les fonctionnalités clés liées au déclenchement d’alertes.
1   2   3   4   5   6   7   8   9   10

similaire:

Résumé Le pack d\Résumé Ce guide présente la manière dont Exchange Server 2003 Management...

Résumé Le pack d\Résumé Ce guide décrit la connexion et la migration des systèmes...

Résumé Le pack d\Résumé Ce guide contient des informations sur l'utilisation de Microsoft...

Résumé Le pack d\Résumé Ce guide contient des informations sur les performances et...

Résumé Le pack d\Guide du pack d'administration des services Terminal Server pour Operations Manager 2007

Résumé Le pack d\Résumé : Le pack d’administration du service Routage et accès à distance...

Résumé Le pack d\Guide d'administration de Microsoft Exchange Server 2003

Résumé Le pack d\Académie Microsoft Exchange Server 2010

Résumé Le pack d\Résumé Ce guide décrit le fonctionnement du transport et du routage...

Résumé Le pack d\Résumé Ce manuel est conçu pour guider les administrateurs et les...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com