Différents aspects de l’administration autonome

IBM cite fréquemment quatre aspects de l'auto-management [Kephart,2003] :

•

Auto-configuration : Les systèmes autonomes se configureront automatiquement selon des politiques de business définies à un niveau élevé. Par exemple, quand un composant est intégré dans le système, il s'incorporera parfaitement, et le reste du système s’adaptera à sa présence.

C’est comme une nouvelle cellule dans le corps ou une nouvelle personne dans une population.

•

Auto-optimisation : Les systèmes autonomes chercheront continuellement à améliorer leur opération, identifiant et saisissant des occasions de se rendre plus efficaces. C’est comme les muscles qui deviennent plus forts par l'exercice ou le cerveau qui modifie « ses circuits » pendant l'étude. Les systèmes autonomes surveilleront, expérimenteront, accorderont leurs propres paramètres et apprendront à faire des choix appropriés pour décider de garder des fonctions ou de les externaliser. Ils chercheront pro-activement à améliorer leur fonction en trouvant, en vérifiant, et en appliquant les dernières mises à jour.

•

Autocorrection : Les systèmes autonomes détecteront, diagnostiqueront et répareront les problèmes. En utilisant la connaissance au sujet de la configuration du système, un composant analyserait l'information à partir des journaux de logs, probablement complétés avec des données des moniteurs additionnels que ce composant a demandés. Après l’analyse, le composant responsable de l’autocorrection essaie de corriger les fautes et de dépasser le problème.

•

Autoprotection : Les systèmes autonomes sont auto-protecteurs dans deux sens. Ils défendront l'ensemble du système contre les problèmes causés par les attaques qui n’ont pas été corrigés par le mécanisme de l’auto-correction. Ils prévoiront des problèmes en utilisant des informations collectées à partir des sondes et également prendront des mesures pour éviter ces problèmes par la suite.

4.6 Conclusion

Dans ce quatrième chapitre nous avons présenté les notions d’administration les plus importantes pour répondre aux contraintes des relations contractuelles entre partenaires, d’agilité et de comportement dynamique de notre cahier des charges. Le début de ce chapitre a été consacré à l’exposition des contrats de services (SLA) et aux indicateurs

associés pour mesurer et pour garantir un niveau acceptable de performance et de qualité de service. Nous nous sommes ensuite intéressés à la définition et aux différents aspects de l’administration autonome ainsi que les bases permettant de réaliser un système proactif d’administration en insistant sur la technologie des agents mobiles.

Si les approches que nous avons présentées permettent de satisfaire partiellement notre cahier des charges, aucune d’elle ne peut suffire. Notre contribution présentée dans la deuxième partie de ce mémoire est organisée en quatre axes principaux : la modélisation des systèmes distribués, l’organisation d’une plate-forme dynamique pour le système de management, la gestion de sécurité dans les infrastructures distribuée et la mise en œuvre du prototype de management.

Partie II

Administration dynamique des

réseaux et architectures distribués

Chapitre5 Modèle générique d’administration

5.1 Problématique

Un premier projet [Mathieu,2004] visant à construire un modèle global de management d’une organisation distribuée a permis d’établir un couplage étroit entre le modèle d’infrastructure et le modèle organisationnel. Les entités de ce modèle présentent les différentes parties de l’organisation en montrant les relations entre elles. Plusieurs types de ressources ont été liés avec les différents composants de business pour expliquer les relations qui lient les processus de business et de Workflow avec les autres parties de l’infrastructure. Enfin, pour gérer pro-activement le système, une architecture de collecte et d’analyse de données a été installée. Cette architecture est basée sur un système d’agents mobiles. Les points forts que nous avons dégagés de ce travail se manifestent par la possibilité de répondre aux besoins de système distribué, hétérogène avec un grand niveau de connectivité. De plus, ce système d’agents mobiles a été capable d’assurer la sécurité de ses composants pour garantir le bon fonctionnement du réseau distribué. Cependant, ce travail présente aussi plusieurs limites : manque d’étude sur l’autonomie et le comportement dynamique des agents mobiles, peu de capacité d’adaptation de la plate-forme de management selon le contexte (context-aware management) (or ceci influence beaucoup la qualité de service du système de management), pas de prise en compte des mécanismes de calcul des indicateurs et peu de possibilité de mémorisation des résultats. Ce système ne permet donc pas de résoudre le problème de complexité des réseaux largement distribués et gérés contractuellement. Enfin, la sécurisation globale du système de management n’était pas totalement garantie.

Pour dépasser ces limites, nous proposons au début de notre de contribution une modélisation générique du processus de management qui intègre la description de l’infrastructure, des modèles organisationnels avec les composants de management. Nous proposons ensuite une organisation multi niveaux pour le système de management. Ce système est basé sur une plate-forme de management dynamique, agile et adaptée aux changements de contexte. Cette plate-forme est basée sur des aglets qui supportent deux types d’agents (mobiles et fixes). Nos aglets assurent plusieurs fonctions de management organisées selon les différentes étapes du cycle de vie du processus de management : la surveillance, le calcul des indicateurs,

l’exécution d’une action, la recherche ou le dépôt d’informations de management dans la base de données, la mise en œuvre de quelques fonctions de sécurité, etc. Dans la suite, nous présentons l’organisation de notre solution de management ainsi que la plate-forme et le prototype que nous avons mis en place pour répondre à ces besoins.

5.2 Cycle de vie de système d’administration

La démarche de construction de notre plate-forme de management est basée sur l’analyse des différentes étapes du cycle d’un système d’administration (figure 5.1). Ce cycle débute avec la déclaration des besoins de management (besoins qui couvrent toutes les parties du système distribué : le système d’information, les activités se déroulant dans le réseau et le réseau lui-même). Ensuite, il convient d’organiser un système de surveillance. Pour cela, il faut d’abord pouvoir accumuler les informations nécessaires pour construire les indicateurs de performance. Les informations rassemblées présentent une situation des activités du système d’information ou du réseau. Une méthode de calcul basée sur les équations de KPI (Key Performance Indicators) peut servir à transformer les informations accumulées en véritables valeurs mesurant les performances.

Après avoir construit ces indicateurs de performance, une étape d’analyse est nécessaire pour comparer les résultats obtenus avec des valeurs de référence, faire des analyses pour détecter les activités anormales. Une fois ces analyses réalisées, la dernière étape dans le cycle de vie de management est la décision du gestionnaire. Ce gestionnaire peut être soit la personne qui gère le réseau ou le système de management lui même, selon la portée de l’action qu’il faut faire.

Figure (5.1) : Cycle de vie de système de management.

5.3 Modèle générique d’administration

La construction d’un modèle global d’administration demande de prendre en compte toutes les étapes présentées dans le cycle de vie du système de management. Pour cela, il convient de détailler les différents composants du système (i.e. de l’infrastructure), les différents composants de business et de relier ces deux vues (infrastructure et business) pour définir les informations importantes et nécessaire pour la gestion de chaque partie du réseau et plus généralement du système distribué

En partant de cette idée, nous présenterons par la suite les composants principaux que nous avons pris en compte pour étendre le modèle d’administration de base proposé par [Mathieu,2004] et pour construire ensuite le modèle global d’administration.

5.3.1 Système d’administration de BP basé sur les rôles

L’organisation de processus de business interentreprises doit respecter l’autonomie et le patrimoine de chaque entreprise partenaire. La construction d'une telle organisation implique de tenir compte à la fois de l’organisation et du rôle tenu par les acteurs pour atteindre le but commun mais aussi de la manière selon laquelle ils adaptent dynamiquement les structures existantes pour faire face aux besoins.

En ce qui concerne une organisation virtuelle (ou Virtual Organisation, VO), le problème principal consiste à définir le mode de collaboration et l’adaptation entre les processus de business des différentes entreprises. Pour cela, nous proposons d'organiser un méta-modèle partagé par les différents partenaires, décrivant globalement le processus de business distribué selon une logique de Workflow de l’organisation. Nous partons du modèle proposé par [Mathieu,2004] pour construire un modèle plus complet qui couple le modèle organisationnel, le modèle d’infrastructure avec le modèle de management (gestion du cycle de vie).

Pour répondre à la contrainte de confidentialité, il importe de définir des éléments publics et privés. Pour intégrer cette logique publique/privée dans un Workflow nous proposons de définir plusieurs niveaux d’abstraction en associant chaque tâche qui se déroule dans une organisation à un Workflow ou à un processus privé appartenant à l’organisation en question. De cette façon, nous avons plusieurs niveaux d’authentification selon les utilisateurs

qui lancent le Workflow. Par exemple, l’exécution d’une même tâche qui se déroule entre deux utilisateurs (client final / entreprise) ne donne pas les mêmes résultats que si nous exécutons cette tâche sous forme (entreprise / entreprise). Afin d'assigner dynamiquement une tâche à un utilisateur, une organisation orientée « rôle » est couplée à ce processus de Workflow : des acteurs sont organisés en groupes selon les différentes entités pour lesquelles ils travaillent (ventes, production...) et selon leurs propres compétences. Ces rôles sont ensuite associés aux différentes tâches (figure 5.2).

Figure (5.2) : Modèle du processus d’une organisation distribuée.

Par ce biais, les acteurs convenables (des utilisateurs ou une entreprise donnée ou une entité d'organisation) sont associés dynamiquement avant l'exécution du Workflow. De la même manière, les tâches sont associées à l'utilisateur final seulement au moment nécessaire et en prenant en compte les contraintes locales (instanciation retardée). Pour répondre aux contraintes de sécurité liées au développement de relations inter entreprises, il faut que le processus de business intègre ces contraintes en termes d’informations partagées, ou plutôt, il faut penser à la gestion des droits d'accès dans le système d’administration dès la conception. Notre description de processus orientée « rôle » permet de l’associer facilement

aux systèmes de contrôle d'accès basés sur les rôles (RBAC) : de cette façon, des autorisations ou les niveaux de certification peuvent être dynamiquement donnés [Ferraiolo,1992] par les responsables sécurité des entreprises ou par un système de contrôle d'accès selon le niveau d'accréditation exigé. Comme ces certificats sont stockés avec la signature numérique de l'utilisateur, l’authentification est assurée. En ce qui concerne les services de non répudiation, les signatures électroniques ne sont pas suffisantes pour l’assurer tout au long de l’exécution du Workflow. Pour cela, il est important de lier les certificats aux tâches et aux journaux de log pour tracer les activités de chaque acteur.

Figure (5.3) : Intégration du contrôle d’accès dans le modèle.

Pour intégrer des capacités de surveillance et de gestion, nous relions cette description de Workflow basée sur les rôles aux ressources (figure 5.3). Les ressources peuvent être logicielles (les applications et les informations) ou matérielles (postes de travail, serveurs, équipements du réseau de transmission...). Puisque les postes de travail peuvent être utilisés par différents acteurs, selon leur position dans l'organisation d'entreprise, une attention particulière doit être portée sur le système de contrôle d'accès qui protège l'information stockée localement [Samarati,1994]. Ceci implique qu’une logique d'ouverture de session doit être mise en œuvre de sorte que le système de surveillance puisse relier le comportement d’un élément d'infrastructure à la description des processus d'organisation.

Comme le montre la figure 5.3, la description de processus de business peut être fortement liée à l'infrastructure exigée (matérielle et logicielle). En conséquence, cette description peut être employée pour configurer efficacement l'infrastructure selon les activités courantes, ou surveiller le déroulement des opérations d'autorisation quand des droits d'accès et des accréditations particulières d'utilisateur sont exigées.

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

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

Dans le document THÈSE. présentée devant. L Institut National des Sciences Appliquées de Lyon. pour obtenir LE GRADE DE DOCTEUR (Page 94-0)