Principe de fonctionnement de la fonction de contrôle de Java ES

Le fonction de contrôle fait référence au processus complet qui consiste à collecter les données d'exécution, les exposer et calculer des critères de qualité de service pour permettre à l'administrateur de pouvoir accéder aux performances du système et d'être informé du déclenchement d'alarmes. Pendant les opérations d'exécution, l'application Monitoring Console permet uniquement d'afficher les statistiques de performances, de créer des règles de contrôle automatique et d'accuser réception des alarmes. En revanche, elle constitue un précieux outil dans le cadre des opérations de configuration, de dépannage et de contrôle avancé car elle permet de mieux comprendre l'architecture du composant Monitoring Framework et ses interactions avec le composant Monitoring Console.

La fonction de contrôle de Java ES repose sur les principes suivants :

• Le modèle CMM (Modèle de contrôle commun) veille à ce que tous les composants de Java ES exposent des objets et des valeurs universels afin de disposer d'attributs comparables.

• Les objets Java définis par les interfaces CMM fournissent une instrumentation standardisée pour les composants du produit.

• Un agent de noeud expose tous les objets contrôlés pour l'ensemble des composants installés sur un système et assure la gestion des statistiques, des règles et des alarmes pour ces mêmes objets.

• Un agent maître résidant sur un hôte distinct regroupe tous les objets contrôlés à partir des différents agents de noeud et met les données résultantes à la disposition de l'application Monitoring Console.

La section suivante décrit plus en détail chacun de ces principes sur lesquels repose l'architecture de contrôle.

Modèle CMM (Modèle de contrôle commun)

Tout mécanisme de contrôle standardisé repose sur la définition des objets à contrôler et sur l'adoption de ces derniers par tous le composants contrôlés. Pour ce faire, l'architecture de contrôle définit le modèle CMM (Modèle de contrôle commun) comme l'extension du modèle d'information commune (CIM, Common Information Model) développé et gérée par le consortium DMTF (Distributed Management Task Force). Le modèle CMM est à la fois un modèle d'information qui spécifie les objets contrôlés (tels que les ordinateurs, les applications, etc.) et un modèle de données qui définit des valeurs universelles (comme les valeurs d'état opérationnel). Dans son rôle de modèle d'information, le modèle CMM définit également les attributs d'un objet (par exemple, le nombre de requêtes traitées par un service) et les relations entre les objets (par exemple, le fait qu'un service soit hébergé sur un ordinateur donné).

Grâce au modèle CMM, les concepts comme les applications, les services, les points d'accès et autres, sont les mêmes pour tous les composants du produits et ce, même si l'implémentation sous-jacente diffère. Par exemple, le composant Web Server peut exposer un service qui gère les requêtes HTTP, tandis que le composant Directory Server expose un service de traitement des requêtes LDAP. L'objet standard permettra de capturer les données communes à ces deux fonctions, comme la possibilité de mesurer le nombre de requêtes traitées, le temps moyen de réponse à une requête sur un intervalle spécifique, etc.

De plus, certaines valeurs sont standardisées, ce qui permet de leur conférer un sens universel à l'échelle de tout le système. À titre d'exemple, l'état opérationnel ENDOMMAGÉ signifie toujours qu'un service reste disponible, mais que ses performances ont considérablement chuté, indépendamment du composant contrôlé.

La spécification CMM est intégrée aux interfaces Java et des classes sont utilisées pour l'instrumentation, comme décrit dans l'Annexe A, Références sur les objets CMM.

Instrumentation CMM

Dans Monitoring Framework, l'instrumentation désigne l'ensemble d'interfaces et de classes Java qui implémentent les définitions du modèle CMM. Pour les besoins de la nouvelle fonction de contrôle de Java ES, le code des composants du produit a été instrumenté afin de pouvoir instantier les objets CMM et exposer des valeurs d'exécution au travers des attributs des objets contrôlés. Les objets CMM implémentés par chaque composant déterminent les éléments contrôlables, ce qui explique que certains composants exposent moins d'attributs que d'autres. La liste des objets et des attributs associés exposés à des fins de contrôle par chaque composant est fournie dans l'Annexe B, Objets contrôlés exposés par chaque composant.

Agents de noeud

Dans le contexte de la fonction de contrôle, un noeud désigne un hôte logique identifié par un nom de domaine complet unique ou une adresse IP. Il peut s'agir d'un système complet ou d'une zone Solaris configurée en tant que système virtuel. L'agent de noeud communique avec tous les composants instrumentés qui réside sur cet hôte et expose l'ensemble des objets contrôlés associés. Il peut également gérer l'ensemble de la structure logique pour collecter les statistiques de performances, surveiller les seuils définis dans le règles et générer des alarmes pour les objets contrôlés qu'il contient.

Le schéma ci-dessous représente le contenu d'un agent de noeud sur un seul hôte où existent des instances de trois composants de Java ES. Il explique également comment l'instrumentation est générée au niveau de l'agent de noeud pour exposer les valeurs transmises par les composants du produit.

Figure 1–1 Schéma d'un agent de noeud

L'agent de noeud est implémenté sous forme de module dans le Conteneur d'agents communs , lequel est lui-même une machine virtuelle Java. L'implémentation de l'agent de noeud est basée sur la technologie JMX (Java Management Extensions), l'extension Java standard utilisée pour le contrôle et la gestion à distance. Toute application de contrôle compatible JMX qui comprend le modèle CMM peut accéder aux objets contrôlés contenus dans l'agent de noeud. La fonction JMX permet également à l'agent de noeud d'exposer certains objets contrôlés via le protocole SNMP (Simple Network Monitoring Protocol).

Agent maître

L'agent maître est déployé sur une machine distincte dans le cadre de l'installation de l'application Monitoring Console. Il est configuré avec le nom ou l'adresse de tous les noeuds afin de pouvoir regrouper tous les objets contrôlés des différents agents de noeud. L'agent de noeud utilise également la technologie JMX pour communiquer avec les agents de noeud et il est aussi chargé dans son Conteneur d'agents communs local.

Le schéma suivant montre un agent maître connecté à deux noeuds. L'application Monitoring Console se connecte à l'agent maître pour contrôler les trois composants sur chaque noeud. Si vous souhaitez utiliser le protocole SNMP à des fins de contrôle, vous devez vous connecter à chaque noeud de façon individuelle car l'agent maître n'assure pas le regroupement des attributs SNMP. L'agent maître est destiné à être utilisé avec l'application Monitoring Console uniquement, c'est pourquoi il n'est pas accessible via d'autres applications de contrôle.

Figure 1–2 Schéma de l'architecture de contrôle globale