Organisation du système global d’administration

La nouvelle présentation de notre système global d’administration vise à remplacer les entités de management présentées dans le modèle global d’administration qui est exposé dans la section 5.3.2 de ce chapitre en réelles méthodes d’administration adaptées des méthodes présentées dans les chapitres 3 et 4 comme le montre la figure 5.12.

Figure (5.12) : Organisation du système global de management.

L’architecture de notre plate-forme d’administration intègre des composants destinés à la surveillance, à l’acquisition, à l’analyse et au stockage des données. Le modèle servant de base à cette plate-forme est structuré en trois parties principales : la zone organisationnelle (associée à

la description des processus de business), la zone de surveillance et de management des informations et la zone d’implémentation (figure 5.12).

La zone organisationnelle : Cette zone est utilisée pour décrire l'organisation de business, représentée principalement par les Workflows associés aux processus. Cette description basée sur des workflows s’adapte également au contexte d’organisation de collaborations interentreprises dans la mesure où cette représentation nous permet de définir des processus distribués de business. Pour prendre en compte les contraintes de sécurité inhérente à la collaboration industrielle, nous avons choisi d’adapter ces contraintes sous forme de descriptions publique/privée de Workflow en définissant plusieurs niveaux d’abstraction. De cette manière, on peut associer une description de tâche du workflow global inter-entreprise soit à un Workflow plus détaillé soit directement à un cœur de processus (tâche élémentaire).

Afin d'assigner dynamiquement une tâche à un utilisateur convenable, une organisation orientée par rôle est couplée à cette organisation de 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. De cette façon, on peut associer dynamiquement les acteurs convenables (soit des utilisateurs humains, soit une entité d’organisation, soit une entreprise prise globalement) juste avant l'exécution de Workflow. De la sorte, les tâches élémentaires sont associées à l'utilisateur final seulement lorsque c’est nécessaire en fonction des contraintes définies localement sur les processus.

Pour intégrer les capacités de surveillance et de gestion, nous relions cette description de Workflow basée sur les rôles à la zone de surveillance et de management en décrivant pour chaque tâche les ressources nécessaires. De cette façon, la collecte, les processus de calcul de base ou les méthodes d'extraction (process-mining) peuvent être intégrée dans notre modèle et utilisé pour évaluer les besoins courants et configurer dynamiquement l'infrastructure en conséquence.

La zone de surveillance : Cette zone intègre une description de l’infrastructure (matérielle et logicielle) comme un ensemble de ressources gérables. Ces ressources peuvent être soit logicielles (applications et informations) soit matérielles (postes de travail, serveurs, équipements du réseau et de transmission...). Selon le type de ressource, il faut intégrer différentes informations de surveillance (ex. les journaux de logs, les mesures concernant les activités d'équipement...). A partir de ces informations brutes (informations comme les journaux de logs [Aalst,2004b], les MIB des équipements [Hood,1997], les mesures

concernant le flux de donnée (ex, le débit de transfert de donnée dans le réseau), la gestion de l’adresse IP... [Barbara,2001b], [Feather,2000]), des indicateurs plus complexes peuvent être construits. Par exemple, les journaux de logs peuvent être traités grâce à la méthode α-Algorithme, tandis que la de méthode ADAM peut être employée comme guide pour le processus d’exploitation des données collectées. Afin de traiter efficacement la quantité énorme de données que l’infrastructure rapporte, les méthodes de détection des anomalies comme (PAMS ou AADS) [Aalst,2004b] peuvent être utilisées.

Les indicateurs d'activités complexes ainsi que les processus de calcul qui permettent de les évaluer sont également stockés dans le système d'information global. De cette façon, le système intégré de gestion inclut toutes les informations nécessaires pour surveiller, évaluer et préparer les décisions de gestion de manière dynamique. En effet, nous proposons de relier les différents indicateurs et leur processus de calcul à la zone d’implémentation qui permet de stocker les processus de calcul réellement utilisés (et donc de ne pas se limiter à un seul modèle de calcul). Cette interconnexion avec la zone d’implémentation nous permet donc de pouvoir produire « à la demande » des fonctions de surveillance, de calcul ou de configuration dynamiquement.

Dans la zone de mise en œuvre, pour répondre au besoin d'autonomie dans les organisations distribuées, un système de management décentralisé et évolutif doit être mis en place. Les contraintes de distribution, comportement dynamique et agilité nous avons conduit à intégrer une architecture des agents mobiles pour supporter cette zone d'exécution. Notre solution organise les agents selon différentes classes pour que ceux-ci puissent hériter de « patrons de management » (intégrant la gestion de patrons de calcul, de gestion d’itinéraire ou de gestion de configuration). Le code associé à ces patrons est également relié aux processus de calcul définis dans la zone de surveillance. Ceci permet donc de produire des agents dynamiquement selon les besoins en termes de surveillance ou de management (ex. collecte de données, configuration d'équipement...). Ces informations collectées sont enregistrées et peuvent être employées ultérieurement pour servir à d’autres décisions de management.

5.4 Conclusion

Dans ce chapitre, nous avons traité la partie modélisation de notre projet d’administration.

Pour construire notre modèle global de management, le modèle organisationnel d’une entreprise a été couplé avec le modèle d’infrastructure. Ce couplage nous a permis de voir d’une manière plus claire les relations qui lient les trois parties principales d’une organisation : applications, équipements et utilisateurs.

Le modèle global de base fourni par le projet précédent nous a donné une idée sur le fonctionnement des organisations distribuées. En partant de ce modèle, nous avons pu suivre le cycle de vie de système d’administration en intégrant de bout en bout les méthodes ou les moyens de management qui doivent répondre aux besoins de chaque étape de management de ce cycle de vie (collecte des informations, calcul des mesures de management, analyse de comportement, etc).

Après cette phase théorique, nous montrerons au fur et à mesure des chapitres suivants comment nous mettons en œuvre nos idées en définissant une stratégie pour générer le système de management et organiser une stratégie de "distribution". Puis, nous présenterons notre plate-forme de management qui met en œuvre notre système d’administration et nous terminerons avec la présentation de quelques résultats.

Chapitre6 Architecture pour un système

d’administration agile et autonome

6.1 Introduction

La difficulté des activités d’administration (surveillance, contrôle, configuration et management) des systèmes distribués dans un contexte d’organisations étendues (i.e. intégrant des collaborations et donc des interconnexions interentreprises) dépasse largement la complexité de l'administration des environnements de petits réseaux dans un seul bâtiment par exemple.

Dans des systèmes aussi complexes (nombre de postes, contraintes différentes, variabilité des configurations et usage…), la capacité de décision humaine reste limitée et ne correspond pas aux besoins : il faut donc envisager un système d’aide à la décision. De plus, les exigences des collaborations interentreprises conduisant à interconnecter plusieurs environnements hétérogènes et « prolonger » l’infrastructure au delà des frontières de l’entreprise augmente encore la complexité. Le fort développement des technologies de l’information et de la communication comme la facilité d’interconnexion via internet rendent l’organisation même de ces systèmes complexes dynamique augmentant ainsi le degré de complexité et transformant l’activité d’administration en cauchemar.

Bien entendu, ces progrès technologiques ont aussi permis de construire des environnements d’aide à la gestion plus puissant ce qui permet de « réduire » un peu la complexité de cette tâche de management.

Toutefois ces progrès ne pourront à eux seuls apporter une réponse face à cette augmentation de la complexité des systèmes distribués. En outre, les changements « dynamiques » de l’organisation de l’infrastructure supposent de pouvoir prendre en compte (voire prévoir) les interactions entre composants pour apporter des réponses opportunes face à ces changements d’organisation en essayant de maîtriser les éventuelles contradictions.

Pour satisfaire ces contraintes, les solutions à base de systèmes autonomes (donc capables de s’adapter et de s’autogérer) semblent les plus prometteuses. En effet, ces solutions laissent envisager la construction d’un système dynamique de management répondant aux besoins d’agilité, d’autonomie et d’action en temps réel si nécessaire.

Notre contribution à la construction d’un tel système autonome reprend les points clef de ce cahier des charges en générant des agents qui sont paramétrés et recomposés dynamiquement selon les besoins exigés par

le contexte actuel. Ensuite, pour la mise en œuvre de cette plate-forme, nous avons proposé une stratégie adaptée à la configuration inter-entreprise. Dans ce chapitre, nous présenterons tout d’abord globalement notre architecture de management avant d’en détailler les différents composants. Ensuite, nous expliquerons les différentes étapes pour mettre en place une telle plate-forme ainsi que les algorithmes de management que nous proposons.