5.3 Modèle générique d’administration
5.3.2 Modèle global du système d’administration
La surveillance d’un processus de business est réalisé de la manière suivante : une tâche de business qui est réalisée par un acteur est enregistrée dans le journal de log des services de business. Ainsi, l'exécution d’un processus de business génère un ensemble des variables (variables des fichiers de logs ou variables liées à l’utilisation de ressources). Ces variables sont surveillées et collectées par le système de gestion pour assurer le bon fonctionnement des services de business [Mathieu,2004]. Pour faire une gestion convenable de l’infrastructure, ces informations brutes (collectées directement dans l’infrastructure distribuée) ne sont pas suffisantes : il faut donc les transformer en mesures de performance et de qualité de service pour pouvoir les analyser. Pour cela, nous proposons d’intégrer dans notre modèle le processus de calcul des indicateurs et de construction de mesures utilisables. Ces calculs sont définis à partir de données enregistrées dans une base de données (en ayant utilisé au préalable un processus d’acquisition). Les résultats de calcul sur les données élémentaires seront également stockés dans la BD pour qu’elles soient utilisées par l’administrateur.
Dans la suite, nous présenterons d’abord les éléments principaux pour permettre une compréhension globale de notre modèle, qui est
présenté dans la figure 5.4, avant de détailler les composants qui appartiennent à chaque élément principal.
•
Les valeurs sémantiques : De manière à introduire des valeurs de types différents dans la base de données, l’auteur de [Mathieu,2004] a proposé d’introduire la notion de valeur sémantique. Ces valeurs sémantiques sont générées par plusieurs sources.Pour qu’on puisse utiliser ces valeurs dans le processus d’administration, il faut développer un système de monitoring capable de procéder à l’acquisition des variables adaptées avant d’enregistrer les mesures dans la base de données.
Dans ce travail, nous focaliserons sur les valeurs de performance proposées traditionnellement dans la gestion des SLA [Forum,2004]. Pour cela, nous utiliserons les valeurs sémantiques pour créer les indicateurs de performance clé (Key Performance Indicator ou KPI) qui sont utilisées pour décrire la qualité de service. La qualité de service quant à elle est présentée en utilisant les indicateurs de qualité de service (Key Quality Indicator KQI).
De cette façon, pour effectuer une tâche de gestion, on s’intéresse aux informations qui aident à construire les indicateurs convenables de mesure des performances. Par exemple pour analyser les comportements et éventuellement formuler de nouvelles signatures on devra s’intéresser à des données différentes comme la charge liée aux communications et la gestion des droits d’accès. Par contre, si on a besoin de mesurer la charge réseau, on prend comme valeur le nombre de paquets transférés par seconde alors que pour intégrer le système de contrôle d’accès on pourra acquérir le nombre d’accès non autorisées.
Après la phase d’acquisition des données et la construction de mesures, on peut déterminer les seuils d’alarme pour prendre soit une décision immédiate soit une décision à plus long terme en fonction des types de patterns identifiés.
Figure (5.4) : Modèle global de processus avec les indicateurs.
•
Le contexte : Dans le modèle global de [Mathieu,2004] plusieurs types de ressources ont été intégrés : les ressources organisationnelles et les ressources d’infrastructure (figure 5.5). Les ressources d’infrastructure correspondent à tous les équipements matériels appartenant au réseau ou au système informatique. Les ressources organisationnelles sont liées à l’organisation de l’entreprise. Ces ressources contiennent les applications,les informations et les utilisateurs. Les ressources informatiques peuvent être définies aussi récursivement comme un regroupement d’autres ressources (complexes ou élémentaires). Ensuite, les ressources sont associées aux valeurs et mesures qui ont été présentées dans le paragraphe précédent.
Figure (5.5) : Différents types de ressources proposées par [Mathieu,2004].
Dans le but de pouvoir gérer dynamiquement l’organisation et assurer la qualité de service qui évolue selon le contexte (en impactant le système et/ou le réseau), nous avons enrichi ce modèle de ressources en intégrant la dimension contextuelle. La description du contexte permet de fournir directement des informations sur les ressources, équipements, utilisateurs… ou de renseigner indirectement sur le système d’information ou sur l’infrastructure globale. On parle alors de contexte explicite ou implicite (figure 5.6).
Figure (5.6) : Informations fournies par le contexte.
Les sous branches de cet arbre décrivant le contexte fournissent toutes les informations concernant de manière directe les utilisateurs, les équipements, les ressources (informationnelles ou matérielles) ou des informations concernant indirectement le système d’information ou l’infrastructure. De cette façon, nous avons une vision globale sur toutes les entités du système d’information et du réseau. Le détail des informations que le contexte peut fournir seront présentés dans le chapitre 7.
•
Le processus d’acquisition : Ce processus utilise deux sources de données principales : le journal de log (pour le système de workflow) et la base de données contenant les mesures et valeurs sémantiques (figure 5.7). Dans le journal de log, on peut trouver toutes les tâches exécutées ou en cours. A partir de ce journal nous disposons des informations sur les durées des tâches, leur date de début et de fin, les rapports d’erreurs (éventuellement)…En ce qui concerne les données liées aux autres sources (donc celles stockées dans la base de données), nous utilisons les valeurs sémantiques pour décrire comment les données acquises via le processus de monitoring sont utilisées par le processus de calcul pour construire des mesures. Ces mesures sont aussi enregistrées dans la base de données pour que l’administrateur puisse les utiliser ultérieurement.
Figure (5.7) : Différents types de données et des journaux de logs.
•
Les journaux de logs : Dans le modèle précédent nous avons différencié deux types de journaux de logs : la base de données historique et les journaux de logs du Workflow.La base de données historique peut contenir plusieurs types de journaux logs [Costes,1999] :
• les logs de transfert : contiennent les informations concernant les transferts entre le client et le serveur.
• les logs d'erreur : aide, par exemple, à indiquer le fichier qui aurait causé l’arrêt d’un téléchargement pour un client
• les logs référentiels : avec ce type de journal de log nous pouvons savoir à partir de quelle page web le client est arrivé.
• les logs d'agent : ces logs archivent les informations concernant les équipements informatiques.
Pour résumer, l’analyse des données contenues dans tous ces fichiers de logs historique permet, par exemple [L'ergonome,2001] :
• de connaitre le nombre de requêtes destinées au serveur
• de fixer la date et l’heure de connexion
• d’identifier la machine d’origine des requêtes à partir de l’adresse IP ou le pays d’origine à partir du DNS (par exemple .fr, signifie la France).
• d’identifier les pages qui sont les plus et les moins visitées sur le serveur, les documents (PDF ou Word…) les plus téléchargés et les applications les plus utilisées
• etc.
Nous prendrons par la suite un exemple de journal de log historique (figure 5.8). Comme le montre la figure suivante, lorsqu’un utilisateur adresse une requête à un site Web hébergé sur un serveur de l’entreprise, une ligne de texte s’inscrit dans les fichiers de logs du serveur.
Ces journaux de logs existent déjà dans le système informatique et constituent, avec le système de surveillance du gestionnaire du système distribué (qui peut par exemple cumuler des informations concernant par exemple la charge CPU ou mémoire à des heures précises dans la journée) les journaux de logs historiques.
Figure (5.8) : Base de données historique.
Les fichiers de logs de Workflow sont parfois appelés les fichiers de traces ou journaux de connexions. Ces fichiers de logs aident à extraire les informations concernant les processus de business à partir des logs de transaction. Nous supposons, en utilisant cette sorte de fichier de log, qu'il est possible d'enregistrer des renseignements concernant [Aalst,2003] : les tâches qui présentent les différentes étapes du Workflow, la situation du Workflow, l’heure de l’exécution du Workflow et l’ordre chronique des événements. En effet, le serveur sur lequel est implémenté le moteur de Workflow est le seul moyen d’accéder à des services de Workflow dans le contexte des réseaux distribués.
La figure suivante montre l’exemple d’un Workflow se déroulant entre deux entreprises. Le sous processus de Workflow appelé processus local 1 est hébergé sur le serveur de l’entreprise 1. Ce sous-processus 1 appelle le processus local 2 qui est sur le serveur de l’entreprise 2, pour exécuter une tâche ou consulter une application. Le journal de log de Workflow qui est généré pendant l’exécution de ce Workflow contient plusieurs informations intéressantes sur ce Workflow comme par exemple, l’heure de début et de fin, le type d’activité (consulter les informations de l’autre entreprise, faire une commande, voir l’état des ressources...), les deux partenaires qui ont lancé ce Workflow…
Figure (5.9) : Journal de log de Workflow.
•
La base de données : c’est l’endroit où nous pouvons mémoriser toutes les données qui aident à réaliser la tâche d’administration du réseau. Nous distinguons plusieurs sortes de données :• les valeurs enregistrées dans la base de données historique qui sont accumulées à partir des journaux de logs.
• Les données concernant les Workflows qui sont mis en place dans le système.
• Les autres indicateurs de performances qui aident à construire les mesures de performance en utilisant des opérateurs convenables.
• Les résultats du calcul sur des mesures
• Les valeurs de référence de la qualité de service.
• Les rapports d’administration qui sont rédigés par les gestionnaires du réseau.
• Etc.
•
Les seuils et les indicateurs : Les indicateurs permettent aux administrateurs d’appréhender et d'analyser les données de performance fournies par les applications, les services… Les administrateurs peuvent utiliser ces informations pour détecter les intrusions dans le système informatique ainsi que pour régler les performances du système et des applications. Par exemple, il est possible d’utiliser des indicateurs pour suivre le délai nécessaire au traitement d'une commande ou à l'interrogation d'une base de données, ou bien surveiller la taille d'une file d'attente de messages. On pourra écrire un code pour déclencher une action de reconfiguration précise chaque fois que la file d'attente atteint une limite prédéfinie (seuil).Chaque indicateur se rapporte à une partie bien spécifique des fonctionnalités système. Il existe, par exemple, des indicateurs qui surveillent la plage de temps occupée du processeur, l'utilisation de la mémoire ou encore le nombre d'octets reçus par une connexion réseau.
Les seuils sont normalement gérés par les indicateurs de qualité de service. Ils ont comme nous avons déjà mentionné des limites prédéfinies selon les exigences de la qualité de service demandée. De cette manière nous pouvons différencier plusieurs niveaux de seuils selon les besoins dans chaque sous-réseau ou pour chaque composant de l’organisation (selon le contexte qui correspond à la situation).