Administration autonomique dans le contexte du Edge Computing ...

Rapport de projet de Master 2 Recherche

Administration autonomique dans le contexte du Edge Computing Soutenu par : Clément ESCOFFIER Sous la direction de : Didier DONSEZ Jury : Yves DEMAZEAU, Jean CAELEN et Jean-Marc VINCENT Rapporteurs : Gaëlle CALVARY (IMAG-CLIPS) et Patrick REIGNIER (IMAG-GRAVIR)

20 juin 2005

Equipe ADELE URL : http://www-adele.imag.fr/Les.Publications/reports/DEA2005Esc.pdf

Résumé Le Edge Computing consiste a rapprocher les ressources (de calcul et de données) des usagers dans un réseau d'opérateur ou de distribution de contenu (multimédia, flux, ...). En vue de diminuer les coûts de maintenance et d'augmenter la qualité de services d'un système, l'approche de l'informatique autonomique semble être une voie prometteuse. Ce rapport étudie l'intégration d'une boucle de rétro-action "intelligente" pour le Edge Computing. L'approche que nous proposons est applicable (et appliquée) à l'administration de plates-formes générales de serveurs IT et à sa déclinaison dans le contexte du "Edge Computing". Elle est basée sur la définition d'un ensemble de règles d'adaptation exécutées au sein d'un gestionnaire autonomique.

Mots clés : Informatique autonomique, règles ECA, Edge Computing, Administration

Remerciements Je tiens à remercier toutes les personnes de l’équipe ADELE du laboratoire LSR pour m’avoir accueilli lors de ce stage et permis d’acquérir une expérience très agréable. Je tiens à remercier particulièrement : – M. Didier Donsez pour m’avoir encadré, pour ses conseils, sa patience et ses encouragements. – M. Jacky Estublier pour m’avoir donné la possibilité de travailler dans son équipe ; – Mme Gaëlle Calvary et M. Patrick Reignier pour avoir accepté de rapporter ce travail. – Tous les membres du jury qui ont accepté d’évaluer mon travail. – M. Mikaël Desertot pour m'avoir aidé tout au long de cette année, pour ces réponses à mes questions, ces remarques et ces conseils – A mes parents et à Deborah qui ont compris et accepté que je sois loin d'eux.

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing

Table des matières 1.Introduction.............................................................................................................................. 5 1.1.Problématique...................................................................................................................5 1.2.Le Edge Computing..........................................................................................................7 1.2.1.Avantage du Edge Computing..................................................................................7 1.2.2.Domaines d'application.............................................................................................8 a)Transmission de flux média....................................................................................... 8 b)Portails web............................................................................................................... 8 c)Communication instantanée.......................................................................................9 d)Jeux massivement multi-joueurs............................................................................... 9 1.2.3.Technologies mises en oeuvre.................................................................................. 9 a)Les caches réversibles................................................................................................ 9 b)Edge Side Includes ..................................................................................................10 1.2.4.Les inconvénients du Edge Computing.................................................................. 10 1.3.Notre proposition............................................................................................................11 2.Etat de l’art sur l’informatique autonomique......................................................................... 12 2.1. Introduction et Concepts................................................................................................12 2.1.1.Constat.................................................................................................................... 12 2.1.2.Informatique autonomique......................................................................................12 2.1.3.Travaux industriels et académiques en cours......................................................... 13 2.1.4.Propriétés des systèmes autonomiques................................................................... 13 2.1.5.Niveaux autonomiques........................................................................................... 14 a)échelle autonomique selon IBM.............................................................................. 14 b)Catégorisation de Oreizy......................................................................................... 14 2.2.Architecture de référence pour l’informatique autonomique......................................... 16 2.2.1.Boucle de contrôle.................................................................................................. 16 2.2.2.Gestionnaire autonomique...................................................................................... 16 2.2.3.Ressources.............................................................................................................. 17 2.2.4.Points de contrôle................................................................................................... 17 2.2.5.L’administration..................................................................................................... 18 a)Analyse interactive multidimensionnelle (OLAP)...................................................18 b)La fouille de données (DATA MINING)................................................................ 18 2.3.Des systèmes autonomiques à plusieurs couches .......................................................... 19 2.4.Un ensemble de standard pour l'administration..............................................................20 2.4.1.Common Information Model .................................................................................20 2.4.2.Simple Network Management Protocol..................................................................20 2.4.3.Java Management Extension.................................................................................. 21 2.4.4.Application Response Management (ARM)...........................................................22 2.4.5.JSR 47: Logging API Specification........................................................................22 2.4.6.JSR 87 : Java Agent Service...................................................................................23 2.4.7.OGSA & OGSI....................................................................................................... 23 2.4.8.Conclusion sur les standards pour l’informatique autonomique ........................... 24 2.5.Utilisation de politique pour les systèmes autonomiques...............................................24 2.5.1.Modèles de règles................................................................................................... 25 a)Evènements.............................................................................................................. 25 b)Conditions................................................................................................................25 c)Actions..................................................................................................................... 25 2.5.2.Modèle d’exécution................................................................................................ 25 2.5.3.Modèle de détection et de production des évènements...........................................26 1 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing 2.5.4.Travaux en cours ....................................................................................................26 2.6. Exemples d’applications des systèmes autonomiques.................................................. 27 3.Administration autonomique de plates-formes...................................................................... 28 3.1.Architecture globale....................................................................................................... 28 3.1.1.Mise en place d'une boucle de rétroaction.............................................................. 29 3.1.2.Description de l'environnement.............................................................................. 29 a)Les applications....................................................................................................... 29 b)Les infrastructures....................................................................................................30 c)Les utilisateurs......................................................................................................... 30 3.1.3.Les points de contrôle............................................................................................. 30 a)Exemples de points de contrôle pour l'administration............................................. 30 b)Points de contrôle synthétiques............................................................................... 30 c)Graphe de points de contrôle .................................................................................. 32 d)Utilisation d'un intergiciel orienté message............................................................. 32 3.1.4.Gestionnaire autonomique pour l'administration de plates-formes........................ 33 a)Moniteur...................................................................................................................33 b)Analyseur................................................................................................................. 34 c)Planificateur............................................................................................................. 34 d)Exécuteur................................................................................................................. 35 e)Administration......................................................................................................... 36 3.2.Définition de politique pour l'administration autonomique........................................... 36 3.2.1.Modèle de politique................................................................................................ 36 a)Ensemble de règles.................................................................................................. 37 b)Intégration des règles ECA dans l'architecture........................................................ 38 c)Règles de corrélation et règles d'action....................................................................39 d)Règles d'actions et plan parallèle............................................................................. 40 3.2.2.Classification des composants d'une application....................................................40 a)Ecriture de règles pour les applications à composants.............................................40 b)Classification des composants................................................................................. 41 c)Problèmes de cohérence et composants critiques.................................................... 43 3.2.3.Modèle d'évènement............................................................................................... 43 a)Modèle d'évènement................................................................................................ 43 b)Exemples d'évènements dans le cadre de l'administration...................................... 44 3.2.4. Expressions des conditions....................................................................................45 3.3.Une implémentation d'une boucle de contrôle pour l'administration autonomique....... 46 3.3.1.Modélisation du gestionnaire autonomique............................................................46 3.3.2.Les points de contrôle ............................................................................................ 47 a)Modélisation des points de contrôle dédiés captures............................................... 47 b)Modélisation des points de contrôle dédiés actions.................................................48 c)Cas des points de contrôle hybrides.........................................................................49 3.4.Conclusion sur l'administration autonomique de plates-formes.....................................49 4.Application dans le contexte du Edge Computing.................................................................51 4.1.Affinage de l'architecture pour le Edge Computing....................................................... 51 4.1.1.Environnement particulier...................................................................................... 51 4.1.2.Recherche de performances.................................................................................... 52 4.1.3.Le contexte « EDGE Computing »......................................................................... 52 4.2.Gestionnaire autonomique pour le Edge Computing..................................................... 52 4.2.1.Politiques pour le Edge...........................................................................................52 4.2.2.Evaluation des moteurs de règles............................................................................53 4.2.3.Interceptions des connexions ................................................................................. 54 4.3.Validation de la boucle autonomique pour le Edge Computing.....................................54 2 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing 4.3.1.Scénario du prototype............................................................................................. 54 4.3.2.Politique proposée.................................................................................................. 54 4.3.3.Architecture du prototype....................................................................................... 55 4.3.4.Validation............................................................................................................... 56 4.3.5.Perspectives du prototype....................................................................................... 56 5.Conclusion et Perspectives.....................................................................................................58 5.1.Perspectives à court terme.............................................................................................. 58 5.2.Perspectives à long terme............................................................................................... 58 6.Bibliographie..........................................................................................................................60

3 / 64


4 / 64


1. Introduction Depuis une dizaine d'années, l'utilisation d'Internet s'est considérablement développée, notamment grâce à la démocratisation du haut débit et du très haut débit, rendant l'utilisation d'Internet plus confortable pour les particuliers. Les applications web ont donc vu leur nombre de client augmenter considérablement. Parallèlement, les applications sont devenues de plus en plus complexes. Cependant, ces dernières années, les serveurs d'applications ont été banalisés dans les entreprises, grandes ou petites. Grâce à leur souplesse en matière de développement et de maintenance d'application, ils ont réussi à faire face à l'accroissement de la taille des applications. Si la plate-forme J2EE (Java 2 Enterprise Edition) reste une spécification défendue par la plupart des éditeurs (IBM, BEA, Sun,...), l'architecture .NET de Microsoft vise le même secteur d'activité. Les applications J2EE et .NET sont déployées sur des architectures multi-étages. Une telle architecture comprend généralement une couche de présentation, une couche de services et d'objets métiers et une couche d'accès aux données. Dans la plupart des cas, ces couches sont réparties sur 3 serveurs différents : le serveur web réceptionnant les requêtes utilisateurs et fournissant la réponse, le serveur d'application a proprement dit, et le serveur de base de données. Néanmoins J2EE et .NET utilisent des technologies différentes pour les composants formant chaque étage. J2EE propose d'utiliser des pages JSP et des servlets pour la couche de présentation alors que .NET utilise des webforms et ASP.NET. La couche de logique applicative est composée de Session Beans pour J2EE et alors que .NET utilise des composants C# (ou tout autre langage .NET). J2EE accède aux données via des Entity Beans alors que .NET utilise la technologie ADO.NET. La structure des applications web reste similaire malgré les différentes technologies. La flexibilité et la robustesse de cette architecture permettent le support des applications web complexes. Cependant, les hébergeurs de ces applications luttent pour maintenir un temps de réponse acceptable.

1.1. Problématique L'utilisation croissante d’Internet entraîne des problèmes de performance chez les fournisseurs de service Web ainsi que sur les réseaux d’accès à ces services. Cet enjeu est important car lorsqu’une page ou qu’un service a un temps de réponse trop grand, l’utilisateur abandonne généralement la demande, ce qui engendre une perte de clientèle pour le commerçant. Les acteurs de l’Internet sont donc confrontés à la nécessité d’optimiser les ressources utilisées, que ce soit au niveau du réseau ou des serveurs. Par exemple ( Figure 1) des millions d’utilisateurs envoient des requêtes depuis leur navigateur Web. Ces requêtes transitent à travers d'Internet vers le(s) fournisseur(s) des pages demandées. Côté fournisseur, le traitement d’une telle quantité de requête nécessite l’utilisation de machine à grosse capacité de traitement ou de grappes de serveurs « bas coût ». Cela implique une mise en œuvre difficile et coûteuse pour pouvoir supporter les phénomènes de surcharge transitoire (sortie de clip vidéo, bande annonce d'un nouveau film, vente flash suite à une campagne publicitaire ...) .

5 / 64


Figure 1: Acheminement des requêtes pour les applications web classiques

Figure 2: Situation des serveurs frontières ( Edge ) La principale réponse pour surmonter les problèmes de performance est l'utilisation de grappes de machines. C'est à dire un ensemble de serveurs interconnectés agissant virtuellement comme une seule machine afin d'offrir une grande disponibilité et une meilleure tolérance au panne. Par exemple, le moteur de recherche Google utiliserait une grappe de 79,112 machines1. Cependant, il est courant qu'une partie des machines ne soient pas utilisées. Le dimensionnement des grappes est un problème important pour lequel il n'y a pas de réponse exacte à l'heure actuelle. Les hébergeurs d'applications (mutualisant les ressources provenant de plusieurs fournisseurs de services) tentent de prédire les montées de charge afin 1

Estimation effectué en 2004 : http://www.tnl.net/blog/entry/How_many_Google_machines

6 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing de construire l'infrastructure pouvant la supporter. Il y a donc souvent un surdimensionnement des grappes. Cependant une autre voie tend à apparaître afin de supporter les pics d'affluences. Lorsque le fournisseurs de services est lui même hébergeur, il est possible « d' externaliser » une partie de l'application (par exemple la couche de présentation) vers des serveurs plus proches des utilisateurs. Cette technologie émergente nommée « Edge Computing ».

1.2. Le Edge Computing La réponse au problème de qualité de services des applications web peut venir des FAI (Fournisseurs d'Accès Internet) qui, en plus de fournir les moyens de transit d’informations entre les utilisateurs et les fournisseurs de services, sont maintenant également en mesure de proposer aux fournisseurs d’héberger les services qu’ils fournissent. Cela vient du fait qu’ils disposent de serveurs de plus en plus puissant aux frontières de leurs réseaux. La puissance dont ces serveurs disposent peut être utilisée pour l’exécution de service ou comme cache pour des documents web[1]. Cette architecture est illustrée sur la Figure 2 en conservant le même exemple. Cette fois-ci, les requêtes des utilisateurs seront interceptées puis traitées par un serveur frontière au niveau du point d’accès du FAI. Si celui-ci dispose de la réponse, il lui retourne automatiquement. Dans le cas contraire, il interroge le serveur du fournisseur, met en cache la réponse pour une demande future et retourne le résultat.

1.2.1.Avantage du Edge Computing La mise en œuvre d’une telle architecture[2] apporte de multiples avantages : ●

●

●

●

●

Diminution du temps de réponse pour les utilisateurs. Le serveur frontière (Serveur Edge) peut déjà disposer de la réponse dans son cache et donc répondre immédiatement. Dans le cas où le serveur principal du fournisseur doit être interrogé en cas de défaut de cache, le temps d’accès n’est que très peu augmenté de part le passage par l’intermédiaire du point d’accès et de la sauvegarde dans le cache permettra d’accélérer la prochaine requête semblable. Mutualisation transparente des ressources de calculs entre plusieurs fournisseurs. Les points d’accès des FAI sont des ressources existantes et disponibles. Utilisées à bon escient, elles peuvent servir à plusieurs fournisseurs sans que ces derniers s'en rendent compte. Diminution du coût de l’infrastructure pour la prise en charge des requêtes des clients et mettre en cache les réponses afin de les réutiliser pour des requêtes similaires. De ce fait, le serveur d’application du fournisseur de service sera beaucoup moins sollicité. Une machine moins puissante donc coûteuse pourra répondre au besoin et à une éventuelle grappe de machine devient superflu. Rendre les services plus disponibles. La disparition d’un serveur frontière du FAI ne remet pas en cause l’architecture car un autre serveur proche peut se suppléer à lui pour répondre aux demandes. Diminuer l'usage de la bande passante du backbone du FAI. En effet, les transferts utilisent moins la bande passante reliant chaque point d'accès à un autre.

7 / 64


1.2.2.Domaines d'application Parmi les applications ciblées par le Edge Computing, on peut citer principalement la transmission de flux de média, les portails web. Nous pensons aussi qu'une telle technologie peut être utilisée pour le bulk-mailing, les forums de discussion et les jeux massivement multijoueurs. Plus généralement, le Edge Computing peut être employé dans la plupart des cas où les échanges client/serveur sont importants et où les temps de calcul demandé sur le serveur sont conséquents.

a) Transmission de flux média Le transfert de flux de média, dans le cadre par exemple de la visualisation en ligne d’une vidéo ou de l’écoute d’un morceau musical, est très gourmand en ressource. En effet, une bande passante importante est nécessaire pour faire transiter une vidéo depuis un serveur de flux vers un client tout en garantissant avec une qualité acceptable pour la visualisation. De plus, un temps de calcul conséquent est nécessaire au serveur pour transmettre le flux et sa capacité peut donc être vite limitée et il se trouvera dans l’incapacité de répondre à la demande. Enfin, le serveur Edge peut aussi adapter le flux vidéo en fonction du terminal sur lequel le client va le visualiser (PC, PDA, TV, TV Haute Définition, Téléphonie 3G…). Mettre en œuvre du Edge Computing permet de répondre à ces besoins particuliers. Pour le cas d’une vidéo demandée une première fois par un client, celle-ci sera "poussée" sur le serveur frontière du FAI et mise en cache. Au plus près du client final, le réseau sera moins surchargé par le flux. Seul un transfert est nécessaire. Pour toute demande d’un autre client sur le même point d'accès, il ne sera pas nécessaire de transférer de nouveau la vidéo. Le point d’accès accueillant la vidéo ayant beaucoup moins de client à gérer que le serveur du fournisseur de la vidéo, il pourra fournir facilement la vidéo à tous les demandeurs et disposer de la puissance de calcul nécessaire pour l’adapter éventuellement à un client particulier.

b) Portails web Un portail web (web portals) peut se personnaliser automatiquement en fonction de l’utilisateur demandant la page. Ce type de page se décompose en deux parties : une partie générique commune à toutes pages et une partie spécifique à l’utilisateur. Ce dernier peut choisir d’afficher la météo, le cours de la bourse ou l’affichage de ses mails à l’intérieur de la page du portail. Ce type de portail se base sur une technologie appelée portlet qui permet d’effectuer cet assemblage. Si cet assemblage est toujours calculé par le serveur de l'hébergeur, qui requiert un grand nombre de requêtes et nécessite une puissance de calcul importante. Comme dans le cas de l’exemple précédent, le Edge Computing permet de limiter les échanges entre client de fournisseur de service. L’ensemble des caractéristiques particulières à un utilisateur sont servies et mises en cache sur le point d’accès. Seuls les mises à jour sont envoyées vers le serveur frontière. Il est aussi chargé de l’assemblage afin de décharger le serveur du fournisseur. Pour le cas où un certain composant est demandé par plusieurs clients, sa présence en cache économise un nouveau téléchargement (par exemple plusieurs clients demandant la météo). Les courriers électroniques publicitaires (bulk-mailing) (ainsi que leur variante par SMS / MMS) sont de plus en plus composés d'une partie générique valable pour tous les clients et d'une partie personnalisé en fonction des informations issue du profil client. Suivant le même 8 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing fonctionnement que le portails web, l'envoi de ces messages publicitaires peut être amélioré en utilisant le Edge Computing. Les informations personnalisées d'un client sont envoyées aux serveurs SMTP frontières afin de calculer les courriers à envoyer. Cette technique permet à l'hébergeur de réduire le trafic SMTP dans son réseau.

c) Communication instantanée Un autre domaine d'application particulièrement en vogue aujourd'hui concerne la communication instantanée (Instant Messaging). En effet, des groupes d'utilisateurs tchatent et se réunissent en communautés géographiques ou thématiques. Il est donc envisageable d'héberger le canal de discussion sur des serveurs géographiquement proches des utilisateurs. Ainsi le temps de réponse du forum de discussion sera amélioré.

d) Jeux massivement multi-joueurs Les jeux massivement multi-joueurs hébergent les parties sur des serveurs de jeu (réflecteurs). Les joueurs se connectent sur ces serveurs afin de se rencontrer, jouer ... Ces nouveaux types de jeux ont un très fort succès2. Par exemple « World of Warcraft » a enregistré plus de 1 500 000 d'abonnements en moins de 6 mois. L'utilisation du Edge Computing peut améliorer le temps de réponse lors des parties de ces jeux. En effet, en hébergeant les parties sur des réflecteurs plus proches de l'utilisateur, les transferts seront plus rapides (et la qualité du jeu améliorée).

1.2.3.Technologies mises en oeuvre Certains constructeurs fournissent déjà l’infrastructure nécessaire à la mise en œuvre d’une architecture Edge. Parmi ceux-ci, on peut citer IBM, Sun, Oracle… Les serveurs fournis proposent de mettre en cache soit des pages web complètes, soit uniquement des parties de pages au plus près possible des demandeurs. Le premier cas n’est réalisable que lorsque les pages sont statiques. Pour le deuxième cas, ils peuvent s’appuyer sur des caches réversibles ou alors sur une technologie ESI (Edge Side Includes)[3]. IBM commercialise une solution appelée Websphere Dynamic Cache pour améliorer les performances des plates formes J2EE. Cette solution intègre un processeur ESI ainsi qu'un cache réversible, permettant de mettre en cache les réponses HTML retournées par les Servlets ou les JSP.

a) Les caches réversibles Le principe des caches réversibles est le suivant : chaque donnée du cache possède un temps de vie (time to live) transmis dans la requête HTTP. Au delà de la date limite, la donnée est invalidée du cache. Une requête sur cette donnée provoque une requête auprès du serveur principale et la mise en cache. Cependant, cela impose aux développeurs à fixer le temps de vie de chaque donnée pouvant être caché. De plus, il est possible de remplacer des éléments sans qu'ils aient été modifiés.

2

Une analyse des jeux massivement multi joueurs est disponible sur http://www.mmogchart.com/

9 / 64


b) Edge Side Includes Un document ESI est un document en script dynamique (par exemple JSP) principal composé de fragments. Grâce à ces fragments de code particuliers insérés à l’intérieur des pages web principale, un processeur ESI assemble dynamiquement des fragments de document de plusieurs provenances pour former un document unique retourné a l’utilisateur. Comme les processeurs ESI (Figure 3) sont déployés sur les serveurs frontières, les pages fournies par le serveur d’application incluent les balises ESI relatifs à l’assemblage des pages. La demande d’une page par un client est interceptée par le serveur Edge. Celui-ci va faire la demande auprès du serveur principal de tous les fragments nécessaires au calcul de la page à retourner et mettre ces fragments en cache. La page produite est ensuite renvoyée à l’utilisateur. Les fragments n'ont qu'une durée de vie limite dans le cadre des serveurs frontières. Leur invalidation du cache se fait soit par expiration d'une date limite, soit par une demande d'invalidation partant de serveur d'origine[4].

Figure 3: Utilisation du protocole d'invalidation ESI L'implémentation des ESI de référence s'appelle JESI et permet l'insertion de fragments ESI dans des pages JSP. Voici un exemple de cette technologie : La première ligne configure le cache. Les objets ont une durée de vie de 300 secondes et sont forcément rechargés depuis leur source toutes les 1000 secondes. Les deux lignes suivantes insèrent des pages JSP à l'endroit de la balise JESI. Les fragments insérés suivent les règles d'invalidation données par la première ligne. Toutefois ces fragments peuvent être invalidés avant l'expiration via une requête du serveur d'application.

1.2.4.Les inconvénients du Edge Computing Le principal problème du Edge Computing concerne son administration plus complexe. Il est nécessaire d'administrer les migrations, réplications, rapatriements de composants, ainsi que 10 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing les reroutages de requêtes. En effet, il est déjà difficile d'administrer correctement des applications J2EE / .NET sur un serveur central ou sur une grappe. Le rêve du « Zero Administration » est très loin d'être obtenu pour ce genre d'application. L'externalisation d'une partie de celles-ci rend la tâche encore plus complexe.

1.3. Notre proposition Afin de diminuer la complexité des tâches d'administration, nous proposons d'utiliser l'informatique autonomique dans le cadre du Edge Computing. L'informatique autonomique tend à créer des applications autonomes c'est à dire qui s'administrent toute seules. Lancé en 2001 par IBM, l'informatique autonomique propose construire des applications dotées se configurant, s'optimisant, se réparant et se protégeant toutes seules. Afin de simplifier l'administration d'application déployée sur un réseau Edge, nous nous sommes intéressés à la possibilité d'administrer ces plates-formes de manière autonomique. La suite de ce rapport est organisée de la manière suivante. Tout d'abord, nous présenterons un état de l'art sur l'informatique autonomique et sur l'utilisation de politiques pour diriger les adaptations. Ensuite, nous verrons la mise en place d'une boucle de contrôle dédié à l'administration de système, suivi de son application dans le contexte du Edge Computing. Nous conclurons en énonçant quelques perspectives.

11 / 64


2. Etat de l’art sur l’informatique autonomique 2.1. Introduction et Concepts 2.1.1.Constat Aujourd’hui, les grands acteurs de l’informatique luttent pour accroître leur qualité de service tout en réduisant les coûts de maintenance et de production. Parallèlement à la croissance des réseaux et des systèmes distribués, les problèmes de déploiement, les erreurs matérielles, les défaillances logicielles ainsi que les mauvaises manipulations humaines entraînent une administration des systèmes de plus en plus coûteuse et complexe[5]. IBM ainsi que d’autres grandes entreprises informatiques ne voient pas le ralentissement de la loi de Moore comme un des obstacles principaux pour la croissance des systèmes informatiques. La crise de la complexité des programmes vient de l’augmentation de la taille des systèmes ainsi que de l’accroissement des technologies utilisées. Une croissance exponentielle du nombre et de la variété des systèmes expliquent en grande partie cette crise. Par exemple, l’entrain autour des bases de données et d'Internet a alimenté significativement la croissance des systèmes de stockages, capable dorénavant de contenir des peta-octets d’informations structurées ou non. Les réseaux sont maintenant inter-connectés et sont composés de systèmes et de machines hétérogènes. De plus, il n’est plus possible de prédire avec exactitude la charge de ces réseaux et de ces serveurs. Toutes ces raisons expliquent pourquoi il est devenu extrêmement complexe de développer et de maintenir des systèmes informatiques.

2.1.2.Informatique autonomique L’informatique autonomique3 a pour but de diminuer cette complexité en utilisant des technologies pour gérer un système en minimisant l'intervention d'opérateurs humains. Son objectif est de créer des environnements ayant la capacité de s’autogérer et de s’adapter aux changements dynamiques. Le terme autonomique se réfère au système nerveux humain qui « surveille inconsciemment les battements du cœur, le taux de sucre ainsi que la température corporelle »[6]. De la même manière, l’informatique autonomique a pour but l’anticipation et la résolution de problèmes avec le minimum d’interventions humaines. Néanmoins, il existe une différence cruciale entre le système nerveux et l’informatique autonomique : les décisions du corps humain sont involontaire, alors que pour l’informatique autonomique, ces décisions sont décidées précédemment par des experts du système. En effet, les décisions prises suivent des politiques d’adaptation déterminant les actions à faire en fonction des évènements. Il n’existe pas de définition précise de l’informatique autonomique, on peut cependant se baser sur la définition la plus utilisée provenant d’IBM[7]: « Informatique autonomique : modèle de programmation dans lequel le système est capable de se configurer, se réparer, de se protéger et de se gérer tout seul »

3

Le terme autonomique, bien qu'il n'existe pas dans le dictionnaire français, a été préféré au terme autonome afin de refléter la distinction entre les termes anglais « autonomic » et « autonomous »

12 / 64


2.1.3.Travaux industriels et académiques en cours L’informatique autonomique suscite un vif intérêt aussi bien dans le monde industriel que dans le monde académique. La plupart des industriels du logiciel ont lancé des initiatives dans la foulée de celle d’IBM : HP avec « Adaptive Infrastructure »[8], Fujitsu-Siemens avec « Organic Systems », Microsoft avec « Dynamic Systems »[9], Hitachi avec « Harmonious Computing »[10], Sun avec « N1 », Intel avec « Proactive Computing »[11], etc... Leurs matériels et leurs logiciels d’infrastructure (OS, serveur d’applications) commencent ainsi à intégrer quelques fonctions isolées qui peuvent s’apparenter à l’informatique autonomique. Les projets académiques peuvent être divisés en deux catégories : ● Ceux qui s’intéressent à automatiser certaines fonctions particulières : la reprise sur panne à Berkeley et à Stanford, la sécurité au CMU, l’évolution du logiciel à Duke, l’automatisation des systèmes patrimoniaux à Columbia … ●

Ceux qui visent au développement de mécanismes et d' infrastructures spécifiques permettant la réalisation de « boucles de rétro-action génériques » : Automate à Rutgers[12], Autonomia[13][14] à Arizona University …

On peut aussi remarquer qu'IBM a lancé une grande campagne de communication grand public sur l'informatique autonomique.

2.1.4.Propriétés des systèmes autonomiques Dans un système autonomique, les composants du système – du composant matériel au composant logiciels – se configure tout seul, se répare tout seul, s’optimise tout seul et se protège tout seul[7]. L’auto configuration (self-configuring) concerne la capacité de s’adapter automatiquement aux changements dynamiques de l’environnement. Les systèmes auto configurable s’adaptent en suivant des politiques données par les experts du système. Ces changements peuvent inclure le déploiement de nouveaux composants ou le retrait de certains ou bien la découverte d’une montée en charge importante. La réparation automatique (self-healing) permet la découverte et le diagnostic du problème. De plus, cette capacité permet aussi la mise en œuvre d’action pour « soigner » le système. Les systèmes possédant cette capacité peuvent détecter les dysfonctionnements et corriger ces problèmes sans interrompre la totalité du système. La tolérance aux pannes entre dans cette propriété[15]. L’auto optimisation (self-optimizing) concerne la capacité de surveiller et d’améliorer le système. Les systèmes possédant cette capacité s’adaptent pour remplir les besoins des utilisateurs finals ou pour suivre les fluctuations des demandes. Les optimisations incluent les réallocations de ressource pour faire face à un pic de demande ou la mise en place de mécanismes optimisés pour certaines activités. L’auto protection (self-protecting) est la capacité qu’à un système d’anticiper, de détecter, d’identifier et de se protéger contre les attaques malveillantes. Il est donc possible de détecter des comportements hostiles et de prendre les mesures protectrices nécessaires. Ces comportements incluent les accès non autorisés, les infections virales (ainsi que leur prolifération) … Ce type de système permet d’améliorer considérablement les politiques de sécurité. 13 / 64


Ces quatre capacités ont été introduites par IBM[16]. Cependant d’autres capacités dérivées sont apparues comme l’auto-déploiement[17], la survie[18], l’auto-organisation[19] , la fiabilité[20], l'auto-contrôle[21]….

2.1.5.Niveaux autonomiques Bien que les propriétés des systèmes autonomiques soient intéressantes, une transformation d’un système existant vers un système réellement autonomique est un processus d’évolution hasardeux. C’est pourquoi, les systèmes évoluent par palier afin de détecter au fur et à mesure les réelles nécessités de l’environnement. Il existe donc des échelles pour déterminer le niveau autonomique d’un système, d’un composant ou d’un environnement. Il faut noter que l’infrastructure fournissant le comportement autonomique s’applique généralement à un système cible n’ayant aucune capacité autonomique. La première échelle, est celle publiée par IBM. Elle possède cinq niveaux, allant de l’application « simple » à l’application entièrement autonomique. Une autre catégorisation classe les systèmes auto-adaptatifs, mais peut s’appliquer au système autonomique. Elle se base sur un nombre de propriétés déterminées.

a) Échelle autonomique selon IBM Cette classification[7][16] a pour but de montrer l’évolution d’une application simple vers une application autonomique. Elle a cinq niveaux. Le niveau 1 (niveau basique) de cette échelle concerne les applications basiques. La maintenance des infrastructures nécessite des interventions humaines. Tous les éléments sont surveillés et maintenus indépendamment. Au niveau 2 (niveau administré), des systèmes d’administration peuvent être utilisés pour collecter des informations (mesures, métriques, alertes...) provenant de plusieurs systèmes disparates et pour rassembler ces informations dans une console de gestion sommaire. Ces systèmes permettent de réduire les coûts de surveillance du système global et permettent une corrélation plus aisée des évènements. Néanmoins, l’étude des informations collectées est à la charge des experts du système. Le niveau 3 (niveau prédictif) rajoute au système des capacités d’analyse des informations collectées. Cela aide les administrateurs à déterminer les actions à prendre. Le système ne prend aucune décision, il indique simplement le résultat de ses analyses. Le système peut néanmoins proposer des actions lui semblant correctes. Le niveau 4 (niveau adaptatif) englobe les systèmes capables de s’adapter tout seul. Le système peut prendre des décisions simples seuls. Ces décisions sont guidées par des politiques d’adaptations et par les connaissances que le système possède sur l’environnement. Le niveau 5 (niveau autonomique) concerne les systèmes réellement autonomiques, dans le sens ou l’opérateur n’intervient que très rarement sur le système. Celui-ci est guidé non plus par des politiques d’adaptation à court terme mais par des objectifs à long terme. Les interactions entre les opérateurs et le système ne concernent que les changements d’objectifs.

b) Catégorisation de Oreizy 14 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing Cette catégorisation[22] porte sur les capacités réelles du système autonomique et peut se montrer complémentaire par rapport à l’échelle d’IBM. Pour cela, il faut répondre à six questions. Dans quel but les adaptations ont-elles lieux ? Le système a-t-il pour but des adaptations en vue d’améliorer ces performances, de réparer une défaillance ou de modifier des fonctionnalités du système global ? Les politiques d’adaptation sont-elles dynamiques ? Peut-on modifier les politiques d’adaptation durant l’exécution du système ? Le système peut- il lui-même rajouter des règles d’adaptation ? Quel type d’autonomie a le système ? Gestionnaire Autonomique Analyse

Moniteur

Plan

Base de connaissances

Exécuteur

Point de contrôle Capteurs

Actionneurs Ressource supervisée

Figure 4: Architecture de référence de l’informatique autonomique d'après [23] Le système est-il entièrement autonome ? A-t-il besoin de l’aval des opérateurs ? Jusqu’à quel niveau, l’opérateur est-il nécessaire ? Dans quelle circonstance l’adaptation est-elle efficace ? Le système applique-t-il l’adaptation en permanence ? Sait-il quand elle apportera un gain ? Connaît-il les coûts engendrés par l’adaptation ? Quelle est la fréquence des adaptations ? Le système doit-il s’adapter fréquemment ? Rarement ? De manière variable ? Les adaptations sont-elles opportunistes ? Sont-elles continues ? Sporadiques ? Paresseuses ? Effectuées seulement lorsqu’elles sont nécessaires ? Quelles sont les informations nécessaires pour effectuer une adaptation ? Quelles données sont nécessaires pour déclencher une adaptation ? Quelles précisions doivent-elles avoir ? L’information doit-elle être à jour ? Récente ? A-t-on besoin de données antérieures ? Quelle est la fenêtre temporelle surveillée dans ce cas là ? Cette classification permet de fixer certains paramètres d’un système autonomique et permet de cibler exactement ce que le système doit être capable de faire. Elle est complémentaire à l’échelle d’IBM car elle détermine des paramètres et des propriétés non prises en compte dans les niveaux d’autonomie. 15 / 64


2.2. Architecture de référence pour l’informatique autonomique Les concepts d’architecture pour l’informatique autonomique, présentés dans cette section, sont reconnus pour tous les acteurs du domaine. Ces concepts mettent en place une terminologie permettant de comparer les différents systèmes autonomiques intervenant sur des environnements hétérogènes. Bien que cette architecture soit issue des travaux de recherche d’IBM[7][16], elle est utilisée dans de nombreux autres projets industriels et académiques[12][24].

2.2.1.Boucle de contrôle L’architecture de référence de l’informatique autonomique a pour but de permettre l’implémentation des propriétés des systèmes autonomiques. Pour cela, elle repose sur une boucle de contrôle « intelligente ». Cette boucle collecte les informations du système, prend les décisions et ajuste le système si nécessaire. Elle va permettre la mise en place de systèmes auto-configurable, auto-optimisable, auto-protégé et auto-réparable. L’architecture de référence est composée de trois acteurs (Figure 4) : le gestionnaire autonomique, les ressources et les points de contrôle4. Le gestionnaire autonomique est le composant implémentant UNE boucle de contrôle particulière. Un point de contrôle est un composant permettant le contrôle d’une ressource supervisée5. Une ressource supervisée représente ce qui est contrôlable par le gestionnaire autonomique, à la fois pour recevoir des données et pour modifier le système. Le reste de ce chapitre décrit brièvement chacun des éléments de l’architecture de référence et mentionne quelques fonctionnalités permettant la mise en place d’un comportement autonomique.

2.2.2.Gestionnaire autonomique L’architecture de référence décompose le gestionnaire autonomique en quatre parties : ● Le moniteur : permet la collecte, l’agrégation, le filtrage des données provenant de l’environnement ● L’analyseur : possède les algorithmes d’analyse et de corrélation permettant au gestionnaire d’apprendre et de déterminer les situations futures ● Le planificateur : construit le plan d’action nécessaire pour atteindre les buts et les objectifs fixés par les administrateurs ● L’exécuteur : contrôle l’exécution des actions du plan d’action Ces quatre parties travaillent ensemble pour former la boucle de contrôle. Ils ont besoin et produisent des informations rassemblées dans la base de connaissances. Cet ensemble de connaissance est construit lorsque l’application s’exécute (le gestionnaire étudie alors le système). Ces connaissances sont partagées par les quatre autres composants. Bien que la communication entre les entités est multi-directionnelle, il existe néanmoins un ordre et des interactions bien définies (Figure 5). 4

Point de contrôle est la traduction choisie pour « touchpoint ». Une ressource supervisée peut fournir des informations ou effectuer des actions, le terme supervision a été choisi pour traduire « managed » qu’utilise IBM 5

16 / 64


Demande de changement

Analyse

Symptômes Moniteur

Mesures & Informations

Plan Plan d'action


Exécuteur

Actions



Figure 5: Interactions au sein du gestionnaire autonomique

2.2.3.Ressources Les ressources managées sont des composants contrôlables situés dans l’environnement permettant de capturer des métriques ou d’agir sur lui. Il peut s’agir d’une seule ressource (un serveur, une base de données, un routeur) ou un ensemble (grappes …). Ces ensembles peuvent être composés d’autres ressources comme une grappe va représenter un ensemble de serveur et un réseau d’interconnexion. Il y a alors hiérarchisation de la présentation. L'ensemble des ressources forme l'environnement sur lequel le gestionnaire peut agir, il peut être composé de ressources supervisables ou non.

2.2.4.Points de contrôle Les points de contrôle font partis des trois acteurs importants de l’architecture de référence de l’informatique autonomique. Ils servent d’interface pour la gestion des ressources managées. Ils existent deux types de points de contrôle : les capteurs et les actionneurs. Les capteurs (ou points de contrôle dédiés captures) sont typiquement utilisés pour transmettre des évènements ou des propriétés à un gestionnaire autonomique. Les actionneurs (ou points de contrôle dédiés actions) sont utilisés pour effectuer des changements sur l’environnement pour changer des propriétés de configuration ou pour modifier un état. La combinaison des capteurs et des actionneurs forme l’interface gestion qui permet l’utilisation d’un gestionnaire autonomique. Les points de contrôle possèdent des propriétés comme un nom, un état, un ensemble de mesure (capteur), une configuration… Les capteurs et les actionneurs peuvent avoir des formes différentes : ● Sondes physiques (thermomètre, bouton, appareil électrique …) ● Analyse de fichiers journaux 17 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing ● ●

Remontés d’évènements Modification d’un fichier de configuration

2.2.5.L’administration Un point important dans les systèmes autonomiques concerne leurs administrations. En effet, il faut pouvoir surveiller, modifier et optimiser le système. De plus, il se peut que le gestionnaire autonomique puisse collaborer avec d’autres gestionnaires pour manager le même environnement (ils partageraient alors les points de contrôle). Aujourd’hui, il n’existe pas de technologie standard pour l’administration de système autonomique. Cependant de nombreux travaux autour de l'analyse en ligne et l'optimisation de performances sont en cours[25] ainsi que hors-ligne[26]. IBM propose un « Integrated Solution Console6 » qui est un console web permettant l’administration d’un système. Cette solution est lourde et souvent coûteuse à mettre en place. L’environnement de développement Eclipse peut servir d'environnement d’administration, grâce à de nombreux plug-in comme Hyade7 (récemment nommée TPTP : Test & Performance Tools Platform). Certains projets considèrent que le tableau Excel est une bonne console d’administration pour les systèmes autonomiques. Une autre approche consiste à utiliser un logiciel de « data mining » comme SAS8, pour administrer les systèmes autonomiques, permettant d’effectuer un traitement statistique sur les données collectées. En effet, un système autonomique risque d'enregistrer un grand nombre d'information. Il va être nécessaire de les analyser afin d'optimiser le système. Les années 90 ont vu le développement des entrepôts de données (datawarehouse). Ces gigantesques bases de données ont pour but de faciliter l'analyse d'information issues des systèmes de l'entreprise pour la prise de décision en interaction avec des analystes. Autour des entrepôts se sont développés des outils OLAP (On Line Analysis Processing) permettant l'analyse en ligne de données historisées, ainsi que des outils de data mining permettant l'extraction de règles, de tendances, de modèles et la validation d'hypothèse à partir des données.

a) Analyse interactive multidimensionnelle (OLAP) Le développement de l'analyse en ligne de donnée (OLAP) a été basé sur l'utilisation de cubes multidimensionnels[27]. Un cube permet la visualisation et l'analyse d'une mesure selon N dimensions. Par exemple, un relevé des charges CPU d'une grappe sera représenté dans un espace 3-D, en fonction du temps, du nombre d'utilisateur de la machine et des différentes machines de la grappe. Ce cube de donnée (datacube) peut être manipulé par des opérateurs de tranches, d'extensions et agrégats (slide, dice, roolup, drilldown, drillup). Les problèmes de performances dans le cadre de larges bases de données sont nombreux et sont retrouvés dans l'informatique autonomique. La conception de la base de connaissances ainsi que le choix des données stockées et le maintient des méta-données sont en cours d'études depuis le milieux des années 90[28].

b) La fouille de données (DATA MINING) Au delà de l'analyse interactive multidimensionnelle, les techniques de fouilles de données 6

Integrated Solution Console est disponible sur http://www-128.ibm.com/developerworks/autonomic/csa.html HYADE / TPTP est disponible sur http://eclipse.org/tptp/index.html 8 SAS est un produit commercial pour l'aide à la décision : http://www.sas.com/ 7

18 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing (data mining) se sont répandues. Il s'agit d'un ensemble de technique d'exploration de larges bases de données afin d'en tirer des liens sémantiques significatifs et plus généralement des règles et des modèles pour la compréhension et l'aide à la décision. L'approche consiste souvent à induire des règles avec des coefficients de vraisemblance à partir de larges ensembles de données. Les techniques de base sont issues de l'intelligence artificielle et de l'analyse de donnée (analyse statistique, modèle fonctionnel, réseaux de neurones, réseaux bayésiens, recherche de règles associatives, classification, segmentation...). Les techniques concernant les règles associatives ont particulièrement été traitées dans [29] et [30].

2.3. Des systèmes autonomiques à plusieurs couches Un seul gestionnaire autonomique est une entité isolée gérant le comportement autonomique de ressource qu’il connaît. Pour étendre le comportement autonomique à un grand système, il est nécessaire de faire collaborer plusieurs gestionnaires autonomiques. La collaboration9 de gestionnaire autonomique permet d’étendre la portée du comportement autonomique à un Inheritance w w

*

Association Association with WEAK reference Aggregation Aggregation with WEAK reference Composition Aggregation Equivalent to: 0 .. n

Component Logical Identity

* *

*

*

ManagedElement (See Core Model)

*

Dependency

* ManagedSystemElement

(See Core Model)

LogicalElement (See Core Model)

EnabledLogicalElement (See Core Model)

ServiceAccessPoint

Service

(See Core Model)

RemoteServiceAccessPoint (See Core Model)

RemotePort

SNMPCommuityStrings CommunityString: string TypeOfAccess: uint16 {enum} LogicalEntitiesAccessed : string[ ] LogicalEntitiesDescriptions : string[ ]

ProtocolEndpoint (See Core and Networks Models (Protocol Endpoints))

(See Core Model)

*

SNMPService

TrapSourceFor SNMPService 0..1

(See Core Model)

SNMPTrapTarget NotificationMessage: uint16 {enum} SNMPVersion: uint16 {enum} CommunityString: string

Figure 6: Structure de donnée pour SNMP selon l’IETF système plus grand. Une architecture de plus en plus utilisée consiste à considérer les gestionnaires autonomiques subalternes comme des points de contrôle et de les connecter à un gestionnaire autonomique chargé de les coordonner. On obtient ainsi un système autonomique à multi-couches. Des travaux récents se penchent vers l'utilisation des processus pour la gestion de la collaboration entre les différents gestionnaires[31].

9

IBM utilise plutôt le terme « orchestration » en référence aux services web

19 / 64


2.4. Un ensemble de standard pour l'administration Par nature, l’informatique autonomique utilise de nombreux domaines de l’informatique et s’exécute sur des environnements hétérogènes. Elle repose donc sur un grand nombre de recommandations permettant de standardiser à la fois le déploiement du / des gestionnaires autonomiques que des points de contrôle ainsi que la collecte d'information. Cette section présente quelques uns des standards que l’informatique autonomique s'appuie.

2.4.1.Common Information Model Le Distributed Management Task Force propose un ensemble de définition pour le management d’information pour les systèmes, les réseaux, les applications et les services appelés Common Information Model[32](CIM). Ces définitions permettent aux industriels de s’échanger ces informations sur leurs systèmes au travers de réseaux. CIM possède deux composantes principales : un schéma et une spécification. Le schéma est la description du modèle actuel alors que la spécification définit les détails pour l’intégration avec d’autre modèle de gestion. La version la plus utilisée du schéma est la CIM 2.9.0. Celle-ci joue un rôle clé dans l’interconnexion de système, la disponibilité et l’augmentation de la qualité de service des systèmes. De nombreux standards s’appuient sur le modèle CIM dans des domaines très diverses. Ceuxci proposent principalement des structures de données communes dédiées à un domaine d'application. Par exemple, l’Application Working Group, a publié un modèle de métriques génériques[33]. Celui-ci a pour but de standardiser les mesures effectuées par des capteurs physiques. Ces structures de données peuvent être utilisées pour la collecte de donnée qu’effectue le gestionnaire autonomique.

2.4.2.Simple Network Management Protocol L’Internet Engineering Task Force10 (IETF) a développé plusieurs standards pour la collecte de donnée et la gestion de réseau. Le plus connu est Simple Network Management Protocol. SNMP11 a pour objectif le management d'équipement réseau en environnement IP (Internet Protocol). Il permet : ● de configurer les éléments réseaux, ● de détecter et d’analyser les problèmes sur un réseau, ● de surveiller les performances réseaux... Ce protocole utilise un modèle CIM pour les structures de données (Figure 6). Mais il instaure aussi un protocole de communication pour la collecte d’information et définit les données manageables. Le système de gestion de réseau est basé sur deux éléments principaux: un superviseur et des agents. Le superviseur est la console qui permet à l’administrateur réseau d’exécuter des 10

IETF : http://www.ietf.org/ La spécification de SNMP est disponible sur : http://www.faqs.org/rfcs/rfc1157.html

11

20 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing requêtes de management. Les agents sont des entités qui se trouvent au niveau de chaque interface connectant l’équipement managé au réseau et permettant de récupérer des informations sur différents objets. Il représente le point de contrôle de l’informatique autonomique. Alors que le superviseur est plutôt le gestionnaire autonomique. SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets souhaités.

2.4.3.Java Management Extension Le Java Community Process a publié de nombreuse JSR pouvant être utilisé pour l’informatique autonomique. La plus connu est la JSR 3 – Java Management Extension (JMX). La technologie JMX est une spécification pour la gestion et le monitoring. Elle repose principalement sur deux JSR : 12 ● JSR 3 , Java Management Extensions Instrumentation and Agent Specification 13 ● JSR 160 , Java Management Extensions Remote API Ce standard est adaptable y compris sur des systèmes patrimoniaux et offre une interface de gestion et de monitoring standardisé. JMX offre également les outils pour construire des solutions distribuées, orienté Internet, modulaire et dynamique pour la supervision de périphérique, d’application et de réseaux.

Navigateur Web

Manageur JMX

Manageur SMNP

Adaptateur Connecteur Adaptateur HTTP RMI SMNP Serveur MBEAN

MBean

NIVEAU SUPERVISION

NIVEAU CONNECTEUR

NIVEAU AGENT

MBean NIVEAU INSTRUMENTATION

Application

Figure 7: Architecture de JMX JMX définit une architecture (Figure 7), des motifs de conception, une API et des services pour la supervision d’application et de réseaux en Java. Une ressource est instrumentée par un ou plusieurs objets Java appelés Managed Beans (ou MBeans). La manière dont les ressources sont instrumentées est indépendante de l’infrastructure de supervision. Les MBeans sont enregistrés dans un objet serveur, appelé MBean Server, qui agit comme un agent de supervision. Un agent JMX est constitué d’un serveur de MBeans dans lequel des MBeans sont enregistrés et d’un ensemble de service pour gérer les MBeans. De cette manière, les agents JMX contrôlent directement les ressources et rendent la supervision possible à distance 12

JSR 003 : http://www.jcp.org/en/jsr/detail?id=3 http://www.jcp.org/en/jsr/detail?id=160

13

21 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing via une couche de connexion (utilisant différent protocole de communication) et une couche de supervision composée des applications de supervision. JMX propose une infrastructure utilisable pour l’informatique autonomique. En effet, les MBeans et les serveurs de MBeans représentent les points de contrôle. La couche de connexion permet la mise en place de la communication entre les points de contrôle et le gestionnaire autonomique intégré à la couche application.

2.4.4.Application Response Management (ARM) ARM[34] est un standard de l’Open Group14 pour la mesure du niveau de service d’une application principalement dans le cadre des systèmes répartis. ARM mesure la disponibilité et les performances des transactions pour les utilisateurs de l’application ainsi que pour les administrateurs du système. Il est utilisé entre une application et un système d’analyse de performance pour mesurer le temps de réponse et le statut des transactions. Typiquement, lorsqu’un utilisateur initie une transaction avec un serveur, l’application coté client appelle le dispositif ARM quand la transaction démarre et s’arrête. Ensuite, ARM transmet ces informations à un système de monitoring d’application fournissant une analyse et un rapport sur les données collectées. ARM prévoit la prise en compte de métrique sur les transactions pouvant être des informations textuelles, des compteurs, des jauges et des informations numériques. Ces données capturées doivent être spécifiées par les administrateurs. Par contre, ARM ne prévoit pas de mécanisme d’action sur le système. Il n’est donc pas possible de créer complètement une boucle de rétro-action avec ARM. Néanmoins, son système de capture de donnée concernant les transactions peut être utilisé dans l’informatique autonomique comme un point de contrôle dédié capture à part entière.

2.4.5.JSR 47: Logging API Specification IBM utilise les fichiers journaux (rassemblant des informations issues de l'exécution d'une application) pour la détection de problème dans une application autonomique 15. C’est pourquoi les techniques de traçage d’application sont importantes pour les points de contrôle. La JSR 4716 est une spécification pour le traçage d’application pour Java adaptable au cours de l’exécution de l’application. Cette caractéristique est importante dans le cadre de l’informatique autonomique car elle permet l’ajustement des paramètres d’un traceur en fonction des évènements collectés. Cette API est adaptable pour le traçage d’évènement dans la machine virtuelle Java ainsi que pour le traçage d’application écrite en Java. Elle prévoit les spécificités suivantes : ● Possibilité de démarrer et d’arrêter le traçage en cours d’exécution ● Possibilité de contrôler la granularité du traçage en cours d’exécution ● L’API permet l’enregistrement de nouveau traceur en cours d’exécution ● Possibilité de connecter le service de traçage de cette spécification avec d’autres systèmes de traçage (comme celui du système d’exploitation) 14

Open Group : http://www.opengroup.org/ Une démonstration de cette application est téléchargeable sur : http://www128.ibm.com/developerworks/autonomic/probdet.html 16 JSR 47 : http://www.jcp.org/en/jsr/detail?id=47 15

22 / 64


Ces propriétés font de la JSR 47, une spécification importante pour les points de contrôle de l’informatique autonomique. En effet, à la fois pour la collecte de donnée et pour l’ajustement des paramètres du traçage en cours d’exécution.

2.4.6.JSR 87 : Java Agent Service Cette JSR17 propose un standard autour de Java concernant les systèmes multi-agents. Cette spécification propose un ensemble d’objet et d’interface pour le déploiement et les opérations d’agents autonomes communicant. Elle est basée sur une architecture abstraite développée par la Fondation pour des Agents Physiques Intelligents (FIPA). Cette couche abstraite définit comment les agents s’enregistrent et se découvrent entre eux et comment ils agissent ensemble en s’échangeant des messages. Ce standard définit deux types d’entités : ● L’ACL (agent communication language) permettant la mise en place d’un protocole de communication ● Les interfaces pour l’enregistrement, la découverte et la communication des agents Cette spécification peut être utilisée pour les points de contrôle. En effet, elle permet d’implémenter des points de contrôle dynamiques communicant et permet au gestionnaire une gestion dynamique de ceux-ci grâce au mécanisme de découverte. La collecte d’information utilise l’ACL incluse dans la spécification. Cependant, cette spécification est au point mort depuis 2003.

2.4.7.OGSA & OGSI L' Open Grid Service Architecture (OGSA)[35] développé par le Global Grid Forum, cible la définition d'une architecture standard et ouverte pour les applications utilisant une grille. Le but d'OGSA est de standardiser les services des applications utilisant une grille comme l'administration des tâches, la supervision des ressources, la sécurité ... en spécifiant un ensemble d'interface standard pour ces services[36]. Cependant, en vue d'obtenir cette architecture, le Global Grid Forum utilise un intergiciel distribué à base de services web : les Services de Grille (Grid Services). Il s'agit d'un service web avec des extensions le rendant adéquat pour les grilles de calculs spécifiés par le standard Open Grid Service Infrastructure (OSGI) (Figure 8)[37]. Cette recommandation propose une spécification formelle et technique des services de grilles. Elle contient, en autre, un langage de description des services de grille très proche de WSDL (langage de description des services web) mais décrivant les extensions dues aux grilles. Il existe une implémentation complète de cette spécification développée par la Globus Alliance : Le Globus Toolkit18[38]. La version actuelle ne prend en compte que OGSI mais les futures versions devraient englober aussi OGSA. Ces deux spécifications ont été créées pour faciliter l'administration des grilles de calculs. 17

JSR 87 : http://www.jcp.org/en/jsr/detail?id=87 La dernière version de cette implémentation est la version 3.

18

23 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing Néanmoins ils peuvent être utilisés dans l'informatique autonomique. En effet, OGSA définit les services de grilles très proches des points de contrôle alors qu'OGSI spécifie une infrastructure pour ces services de grilles comprenant la communication des services avec les clients ( le formalisme utilisé est d'ailleurs très proche de SOAP).

Application

En cours de standardisation, pas d'implémentation

OGSA

Standardisé par GGF et implémenté (GT3)

OGSI

Standardisé par le W3C et implémenté ( Apache Axis par exemple )

Web Service

Figure 8: Architecture d'OGSI et d'OGSA

2.4.8.Conclusion sur les standards pour l’informatique autonomique Nous avons présenté quelques uns des standards utilisés dans l’informatique autonomique. Aucun n’est parfait et permet une implémentation complète d’une boucle autonomique. En effet, bien qu’il existe de nombreux standards purs de la collecte d’information, il n’en existe pas concernant le traitement de ces données et comment répercutées les adaptations sur le système.

2.5. Utilisation de politique pour les systèmes autonomiques L’infrastructure d’une application autonomique nécessite la fonction de décision / réaction contenue dans le gestionnaire autonomique, afin de déterminer les actions correctives à mettre en œuvre – éventuellement après filtrage, agrégation, composition des évènements pour l’aider à trouver un diagnostic. Cette analyse peut être effectuée via un ensemble de règles rassemblées en « politique ». Les systèmes autonomiques sont par essence réactifs, c’est-à-dire qu’ils possèdent la capacité d’effectuer automatiquement des opérations lors d’occurrence de faits significatifs sans intervention humaine / externe. Pour fournir cette capacité, une possibilité consiste à utiliser un système à base de règles actives ou règles Evènements – Conditions – Actions (ECA), largement étudiées dans le domaine des bases de données actives[39]. La suite de cette section rappelle les caractéristiques des règles actives – avec pour objectif de montrer leurs utilisations pour la réalisation des systèmes autonomiques. La sémantique générale d’une règle active est la suivante : lorsqu’un évènement de type E se produit, si la condition C est satisfaite, alors exécuter l’action A. Cette formulation naïve cache en réalité une très grande variabilité de mécanisme de règles actives. Leurs principales caractéristiques peuvent être analysées de la manière suivante : ● Le modèle de règle décrit comment il est défini, représenté et manipulé les évènements, les conditions et les actions 24 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing ●

●

Le modèle d’exécution spécifie quand et comment est exécuté un ensemble de règle potentiellement interdépendante et comment ces exécutions de règles s’intègrent dans le modèle d’exécution général du système considéré Le modèle de détection et de production des évènements exprime comment les évènements sont reconnus et signalés en vue de leur prise en compte pour l’exécution des règles

2.5.1.Modèles de règles a) Evènements Les classes de faits significatifs à détecter et les conditions dans lesquelles ils se produisent sont exprimées d’une manière abstraite par des types d’évènements. Ces évènements peuvent être classés en deux catégories : ● Les évènements primitifs sont associés à des opérations atomiques comme l’invocation d’une méthode, le franchissement d’un seuil par une sonde… ● Les évènements composites sont construits récursivement par des opérateurs logiques tels que la conjonction, la disjonction, la négation, les opérateurs de chroniques tels que la séquence, l’itération, les opérateurs temporels relatifs. Les principales notions[40] associées aux évènements sont : ● L’instant d’occurrence qui précise quand l’évènement se produit. ● L’environnement qui est décrit par une structure de donnée portant des informations sur le contexte dans lequel l’évènement a été produit comme la localisation, la valeur avant et après la modification… Un évènement est ainsi une occurrence d’un type d’évènement auquel on peut associer un instant d’occurrence.

b) Conditions Une condition est un prédicat sur l’état du système. Les conditions les plus simples sont construites à partir d’expressions logiques ayant un résultat booléen. Des conditions complexes peuvent être exprimées par des requêtes sur la structure ou sur le comportement du système. Par exemple, une requête pour identifier si il y a un lien entre deux composants. Une condition est considérée comme satisfaite si la requête retourne un ensemble non vide. Une première approche sur la conception d’un service de requête ouvert sur les composants est présentée dans [41] qui permet des requêtes sur des référentiels persistants de composants et aussi sur les composants en exécution.

c) Actions La partie « action » de la règle détermine le pouvoir d’adaptabilité du système [42] car c’est ici que sont exprimées les transformations qui peuvent être réalisées sur le système cible. Ces actions peuvent être des paramétrages d’attribut des composants ou l’ajustement des propriétés de capteurs (fréquence de capture…). D’autres types d’actions peuvent être envisagés comme des notifications vers une autre machine ou vers un humain.

2.5.2.Modèle d’exécution L’exécution d’une règle est réalisée en trois phases : le déclenchement, après qu’une 25 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing occurrence d’un type d’évènement déclenchant ait été détecté et notifié, l’évaluation de la condition et l’exécution de l’action si la condition est satisfaite. L’évaluation ne suit pas forcément immédiatement le déclenchement de la règle. De même, l’exécution de l’action ne suit pas forcément immédiatement l’évaluation de la condition. Si l’exécution du système considéré comporte plusieurs activités concurrentes, l’évaluation de la condition ne se déroule pas forcément dans la même activité que celle qui a produit l’évènement. On parle de mode de couplage qui a également été longuement étudié dans les SGBD actifs. Par ailleurs, dans un système réparti, plusieurs évènements peuvent se produire simultanément. De plus, l’exécution des règles déclenchées pas ces évènements produisent généralement à leurs tours d’autres évènements déclenchant d’autres règles… Le modèle d’exécution intervient ici pour spécifier quand et comment ces règles sont exécutées et doit répondre aux questions suivantes : Quand doit avoir lieu l’action ? : Doit-on exécuter l’action avant, après, à la place de l’opération qui a produit l’évènement ? 19 Que doit faire l’opération qui a déclenché la règle ? Faut-il suspendre l’opération qui a déclenché la règle ou bien exécuter la règle en parallèle ? Quand doit avoir lieu l’évaluation ? Doit-on différer l’évaluation, l’exécution et jusqu’à quand ? Le modèle d’exécution envisage aussi des stratégies dans l’établissement d’un plan d’exécution des règles multiples et pour les cascades de règles. Plusieurs stratégies existent pour les règles multiples comme le choix d’une règle (aléatoire, priorité, première rencontrée), l’exécution parallèle, l’exécution séquentielle (ordre de la séquence par priorité ou aléatoire) et pour les cascades de règles : à plat, en profondeur d’abord, en largeur d’abord …

2.5.3.Modèle de détection et de production des évènements Ce modèle concerne l’observation du système cible par la pose de sonde et la notification par ces sondes d’évènements, en vue de leur prise en compte pour l’exécution des règles. Les points de contrôle sont la projection de ce modèle dans le cadre de l’informatique autonomique. En effet, les points de contrôle dédiés captures sont chargés de reconnaître les évènements et de les notifier au moteur d’exécution des règles, situé dans le gestionnaire autonomique. Seuls les points de contrôle sont habilités à produire des évènements qui déclenchent des règles.

2.5.4.Travaux en cours Les travaux autour de l'intégration de règles dans les système autonomiques commencèrent vers 2001[6]. Cependant, de nombreux travaux autour de l’utilisation de règle active dans l’informatique autonomique sont en cours. Nous citerons le projet d’IBM ABLE[44], fournissant un canevas logiciel pour l’écriture et l’évaluation de règles (déjà utilisé par IBM dans [45] et [46]), ainsi que France Telecom R&D ayant un projet sur l’informatique autonomique pour les applications à composants[47].

19

Cette problématique est très proche de celle rencontrée dans la programmation par aspects[43]

26 / 64


2.6. Exemples d’applications des systèmes autonomiques L’informatique autonomique est très en vogue aujourd’hui. Cette section présente quelques travaux d’application de l’informatique autonomique. Les grappes de serveurs ont une administration complexe et l’optimisation des travaux sur une grappe peut s’avérer complexe. L’informatique autonomique pourrait permettre de simplifier cette administration en automatisant les migrations de tâches et le partage des ressources sur la grappe. De plus, il serait possible d’augmenter considérablement la détection de panne (ainsi que la tolérance). De nombreux travaux sont en cours pour appliquer les principes de l’informatique autonomique sur des grappes et des grilles de serveurs web comme par exemple dans l’équipe SARDES de l’INRIA Rhône-Alpes20. L’informatique autonomique comprend l’auto-configuration et l’auto-optimisation de système. Ces propriétés sont de plus en plus importantes dans les réseaux ad hoc ainsi que dans les réseaux pairs à pairs. En effet, le gestionnaire autonomique permettrait d’automatiser les configurations des différentes machines du réseau, de permettre la gestion de la dynamicité du réseau ainsi que de tenir à jour les ressources/machines présentes sur le réseau. Certains travaux permettent la gestion de la dynamique de ces réseaux mais pas de manière autonomique [48]. Un autre domaine où l’informatique autonomique parait prometteuse concerne les interfaces homme/machine plastiques. La plasticité d’une interface dénote sa capacité à s’adapter de son contexte d’interaction (plate-forme /environnement) dans le respect de son utilisabilité. En effet, l’interface doit s’adapter en cours d’exécution et ceci peut être fait par une boucle autonomique. L'informatique ubiquitaire et l'informatique mobile nécessitent des adaptations[49] afin de s'adapter au contexte d'utilisation. Là encore, une boucle autonomique peut automatiser ces adaptations afin de les rendre plus simple à programmer et plus transparente pour l'utilisateur. De manière générale, la plupart des systèmes nécessitant une adaptation liée au contexte environnemental, logiciel ou matériel peuvent être automatisés grâce à une boucle autonomique. Néanmoins, il peut s’avérer long et complexe de transformer un système non autonomique en un système autonomique. La suite de ce rapport concerne une application de l’informatique autonomique pour l'administration d’application à composants en général puis dans le contexte du Edge Computing.

20

SARDES développe une boucle autonomique nommée JADE visant à administrer des grappes de serveurs J2EE

27 / 64


3. Administration autonomique de plates-formes L'administration de plates-formes (serveurs d'application, ...) doit couvrir une grande partie du cycle de vie des applications. En effet, du moment que l'application est mise en production, toute la gestion de l'application doit être supportée par la plate-forme[50](Figure 9). Celle-ci doit donc gérer l'installation, la mise à jour, la configuration / reconfiguration, l'adaptation, l'activation ( et la désactivation ) ainsi que la désinstallation d'une application ou d'une partie de l'application.

Version

Développement

Retrait

Production

Mise à jour

Installation

Reconfiguration

Adaptation

Activation

Désinstallation

Desactivation

Figure 9: Cycle de vie d'une application d'après [50] La taille des applications augmentant, la plate-forme a de plus en plus de difficulté à supporter ces opérations. Il devient difficile aux administrateurs de superviser correctement des systèmes de plus en plus grands, tout en gérant individuellement les composants des applications. C'est pourquoi, nous pensons qu'une administration autonomique pourrait faciliter ces tâches en automatisant une partie21 ou la totalité du processus. Cette section présente notre contribution, c'est à dire une architecture pour l'administration de système de manière autonomique, ainsi qu'une gestion des adaptations via des politiques de gestion autonome.

3.1. Architecture globale Afin de promouvoir une administration autonomique, nous allons présenter une architecture proche de l'architecture de référence[51]. Néanmoins, le domaine particulier pour lequel cette proposition est destinée, permet un raffinage de cette architecture. En effet, l'architecture de référence peut être spécialisée pour l'administration de plates-formes. Les travaux effectués 21

IBM propose une administration autonomique de l'installation et le déploiement d'application : http://www128.ibm.com/developerworks/autonomic/solins.html

28 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing ciblent particulièrement les points de contrôle et les différents composants du gestionnaire autonomique.

3.1.1.Mise en place d'une boucle de rétroaction La boucle de contrôle destinée à permettre une administration autonomique possède trois éléments. Tout d'abord, un ensemble de capteur doit permettre la saisie de mesure sur l'environnement. Ensuite un organe de décision (le gestionnaire autonomique) doit analyser ces mesures et demander des changements si nécessaires. Enfin, un ensemble d'actionneur effectue ces changements. Dans le cadre de l'administration de plates-formes, l'environnement supervisé est principalement composé des applications, des infrastructures ( réseau, machine, capteurs... ) ainsi que des utilisateurs des applications déployées (ainsi que leur contexte ). Le gestionnaire autonomique aura en charge la gestion du cycle de vie des applications ainsi que leur adaptation en fonction des infrastructures et des clients.

Environnement Applications Gestionnaire autonomique

Points de contrôle

Infrastructures Utilisateurs

Figure 10: Boucle de contrôle pour l'administration de plates-formes

3.1.2.Description de l'environnement Nous avons déduit que l'environnement dans le cas de l'administration de plates-formes est composé principalement par : ● Les applications ● Les infrastructures ● Les utilisateurs Cette section détaille brièvement le contenu de l'environnement supervisé.

a) Les applications Nous ciblons l'administration de plates-formes hébergeant des applications à composants. Il est primordial de superviser les composants des applications hébergées. En effet, la gestion des composants individuellement nous permet d'adapter les applications de manière suffisamment précise et d'optimiser le système global. Une classification des composants manageables est effectuée dans le chapitre 3.2.2.

29 / 64


b) Les infrastructures Les infrastructures regroupent des dispositifs matériels et logiciels. En effet, il est nécessaire de superviser à la fois les serveurs d'applications composant la plate-forme mais aussi le réseau inter-connectant ces serveurs. Donc il doit être possible de superviser : les serveurs d'applications, le réseau mais aussi les différents conteneurs dans le cadre d'application J2EE (conteneurs de Servlets, conteneur d'EJB (Enterprise Java Beans) ...), les machines physiques, les serveurs de bases de données ... Afin de superviser ces éléments de l'environnement, il faut prévoir les points de contrôle adéquats (sonde sur les routeurs, interface d'administration pour les serveurs...).

c) Les utilisateurs La dernière catégorie d'entité composant de l'environnement est les utilisateurs de la plateforme supervisée. Cela comprend à la fois les utilisateurs humains (clients des applications, administrateurs...) ainsi que utilisateurs logiciels. Chaque utilisation est accompagnée d'un contexte (session ...) qu'il faut prendre en compte afin d'adapter au mieux l'environnement. Il peut s'avérer difficile de manipuler les usagers sans trop perturber leur utilisation (par exemple sans augmenter le temps de réponse ...).

3.1.3.Les points de contrôle Les points de contrôle forment l'interface de supervision entre le gestionnaire autonomique et l'environnement. Ce sont des entités autonomes et configurables, pouvant être déployées dynamiquement ou statiquement. Ils représentent les points d'accès sur les ressources supervisées. Les capteurs permettent la collecte d'information permettant d'instancier les variables d'états utilisées par le gestionnaire pour définir l'état du système. D'autre part, les actionneurs doivent effectuer des actions et en vérifier la bonne exécution. Cependant, il n'existe pas de classification plus fine concernant ces points de contrôle. La suite de cette section présente différents types de points de contrôle ainsi que les graphes de point de contrôle permettant leur collaboration, tout en réduisant l'intrusion.

a) Exemples de points de contrôle pour l'administration Il est possible d'utiliser de nombreux points de contrôle pour l'administration. Cependant, certaines mesures sont souvent utilisées comme le nombre de sessions, les défaillances sur le réseau ou sur les disques, le temps de réponse de l'application, le nombre de requête, le nombre de vente / d'enchère par secondes (utilisée par E-bay et Amazon ) ... Les actionneurs peuvent agir sur la réplication de donnée (sur plusieurs serveurs) ou peuvent simplement démarrer, redémarrer ou éteindre une application, ou une infrastructure, rerouter des requêtes ...

b) Points de contrôle synthétiques Les points de contrôle décrits dans le paragraphe précédent ont simplement comme but de remonter les mesures brutes acquises. Les points de contrôle synthétiques sont capables d'effectuer des traitements sur les mesures collectées. Ceci permet à un point de contrôle de proposer plusieurs informations issues d'un même ensemble de mesure. 30 / 64


Cette capacité a plusieurs objectifs : ● Les calculs effectués n'ont pas besoin d'être fait par le gestionnaire autonomique, lui fournissant directement la mesure désirée. ● Le point de contrôle a la possibilité de n'envoyer que la mesure calculée au lieu de toutes les mesures brutes, cela diminue le trafic réseau. Demande d'action Demande de mesure Demande d'état

Envoi de mesure Envoi d'état Envoi de résultat

Mémoire

Point de contrôle capteur

actionneur

Ressource managée

Figure 11: Interactions pour un point de contrôle synthétique Les calculs réalisables à faible coût par les points de contrôle sont principalement des calculs statistiques sur une période comme une moyenne, un maximum, un minimum, un écart-type ... Cependant, ces points de contrôle peuvent effectuer des calculs spécifiques comme le temps moyen entre panne (mean-time between failure) pour un détecteur de panne. Certains calculs plus perfectionnés peuvent être effectués, par exemple pour découvrir des tendances (augmentation, diminution ...). Des systèmes de monitoring ont déjà inclus ce genre de possibilité comme le projet Objectweb LeWys22. De plus, en détectant les tendances des mesures qu'il collecte, le point de contrôle peut adapter sa période de collecte (par exemple la diminuer si l'activité est nulle). La prédiction a pour but de prévoir les prochaines valeurs collectées et peut donc alerter le gestionnaire autonomique d'un risque éventuel (par exemple si les valeurs capturées tendent à franchir un seuil). Les prédictions réalisées peuvent être faites à courts termes (à partir de tendances) ou à longs termes. Cependant, les prédictions à long termes sont plus difficiles à prévoir et peuvent s'avérer trompeuses[52]. De nombreux travaux autour de l'informatique pro-active utilisent la prédiction afin d'anticiper les besoins[53]. Néanmoins pour cela, il faut équiper le point de contrôle d'une mémoire (pouvant être une base de données) et de la puissance de calcul suffisante. Ce surcoût n'est pas réellement possible dans les cas de capteurs physiques et peut s'avérer trop intrusif pour les capteurs logiciels (mesure de l'utilisation mémoire...). Il est donc nécessaire d'étudier si la diminution du trafic réseau et l'allégement de la tâche du gestionnaire autonomique justifient l'augmentation de l'intrusion du point de contrôle. Cependant, il est possible de créer un graphe de capteur permettant de déporter cette intrusion sur d'autres points de contrôle plus « éloignés » de l'environnement. 22

LeWys est un canevas logiciel pour le monitoring de système distribué. Le projet est disponible sur http://lewys.objectweb.org

31 / 64


c) Graphe de points de contrôle Le but d'un graphe de point de contrôle est de limiter l'intrusion de la collecte d'information tout en effectuant un pré-traitement sur les mesures collectées. Pour cela, nous interconnectons les points de contrôle afin de former un graphe dans lequel nous distinguons trois types de capteurs suivant leur accès sur l'environnement : ● Les points de contrôle de base effectuant réellement la collecte de mesures brutes ou agissant directement sur l'environnement ● Les points de contrôle utilisant les mesures brutes collectées par des capteurs de base ou déléguant une partie des actions à effectuer à d'autres points de contrôle ● Les points de contrôle mixtes collectant des informations sur l'environnement et utilisant aussi d'autres mesures Les points de contrôle de base sont en contact direct avec l'environnement, ils ne doivent pas être trop intrusifs car ils fausseraient les mesures de performances. Néanmoins, les points « arrières » peuvent demander aux points de base afin d'effectuer une agrégation, une concaténation ou un traitement statistique sur les données réceptionnées (Figure 12). Cette solution permet de diminuer l'intrusion des points de contrôle, tout en diminuant la charge du moniteur. En effet, les traitements de données peuvent être effectués par des points de contrôle sans toutefois affecter l'environnement. Point de contrôle 1 Aggregateur

Gestionnaire autonomique

Filtre

Min - Max

Point de contrôle 2

Environnement

Point de contrôle 3

Figure 12: Réseau de points de contrôle dédiés capture D'autre part, les certains actionneurs peuvent diviser les actions en plusieurs sous-actions. Ils délèguent alors l'exécution de ses sous-actions à d'autres points de contrôle. Cependant, les graphes d'actionneurs sont moins avantageux que les graphes de capteurs. En effet, le gestionnaire peut envoyer directement des actions « atomiques » aux points de contrôle de base, ceci diminuant le nombre global de messages envoyés.

d) Utilisation d'un intergiciel orienté message Les points de contrôle et le gestionnaire autonomique n'étant pas centralisé, la mise en place d'un système de communication est nécessaire. Pour cela, deux types de communications existent: les communications synchrones et les communications asynchrones. Malheureusement, la communication synchrone étant bloquante, ce type de communication ne peut pas être utilisé dans l'informatique autonomique de manière convenable. Nous nous 32 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing tournons donc vers des communications asynchrones et vers l'utilisation de mécanisme de publications / souscriptions afin de diffuser les mesures. Inspiré par les espaces de tuples [54], la stratégie publication / souscription (publish/subscribe) est apparu comme une alternative aux appels de procédures distantes asynchrones. Les messages sont produits par des producteurs n'ayant pas connaissance du nombres d'abonnés. Les évènements sont envoyés aux consommateurs ayant souscrits à ces évènements. Ce paradigme permet le passage à l'échelle en ce qui concerne l'espace, le temps (persistance) et les flots de données (l'envoi et la réception de messages ne bloquent pas les participants). Ces caractéristiques rendent ce type de communication très intéressant pour la communication entre les points de contrôle et le gestionnaire autonomique. Le modèle d'interaction publication / souscription basé sur la notion de sujets (topics) se rapproche de la notion de groupe dans les systèmes distribués[55]. Souscrire à un sujet revient à devenir membre du groupe des abonnés au sujet. De plus, la plupart des intergiciels orientés messages permettent une gestion hiérarchique des sujets et permettent la mise en place de filtre rendant les souscriptions plus expressives. Cependant nous avons remarqué que l'utilisation d'un intergiciel orienté message pouvait alourdir le trafic réseau par rapport à des intergiciels de notification d'évènement (comme JMX). En effet, lors d'une expérimentation nous avons constaté que les paquets IP transférés lors d'un envoi d'un entier, via JMX étaient deux fois plus petit que lors d'un envoi du même entier via un intergiciel orienté message (JORAM dans notre cas).

3.1.4.Gestionnaire autonomique pour l'administration de plates-formes Le gestionnaire autonomique est composé des mêmes composants que celui de l'architecture de référence. Cependant, il est possible de spécifier plus précisément la tâche de chacun des composants. Nous parlerons aussi des problèmes algorithmiques et architecturaux rencontrées.

a) Moniteur Le moniteur a en charge la collecte des données récoltées par les points de contrôle et issues de l'environnement. Pour cela, il rédige un rapport d'activité contenant le résumé des événements de la période de collecte. Trois problèmes se posent pour un moniteur : le choix de la période que couvre un rapport d'activité, la gestion de la collecte de donnée et la prise en compte du déroulement d'un plan d'action. La taille de la période que couvre un rapport d'action est un paramètre important pour la performance des adaptations : une période trop longue provoquerait des adaptations pouvant être critiques, trop tardives; un période trop courtes peut interrompre le déroulement du plan d'action ou surcharger : ne pas attendre la stabilisation des précédents changements. Cependant , afin d'avoir un système réactif, il faut pouvoir déclencher l'évaluation de l'état du système lorsque le moniteur détecte un évènement critique ( par exemple : le franchissement du seuil de la charge d'une machine ). Pour cela, le moniteur doit également pouvoir envoyer un rapport d'activité même incomplet, afin de résoudre le problème détecté. Le moniteur a aussi comme tâche la sauvegarde des mesures réceptionnées dans la base de connaissances afin de constituer une base de prédicats extensionnels (prédicats dont les instances sont stockées dans une base de données sous la forme de tuple). Cette sauvegarde 33 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing sert à faire une analyse à posteriori de l'application afin de l'optimiser. Il faut cependant bien choisir les données à sauvegarder afin de ne pas surcharger la base de données inutilement. De plus, les actions prises par le gestionnaire peuvent interférer avec les valeurs collectées. Il faut alors arrêter totalement ou partiellement (seulement les mesures concernées par les actions) la rédaction d'un rapport d'activité. La prise en compte du temps de propagation des actions provoquent des rapports d'activités faussés. Il faut donc prendre en compte la propagation des actions sur l'environnement. Pour cela, plusieurs manières peuvent être utilisées. La première est de majorer de façon raisonnable le temps d'exécution du plan d'action. Malheureusement, bien qu'il soit possible d'estimer le temps d'exécution de chacune des actions par expérience, il demeure très compliqué de prendre en compte les temps de transport réseau et le temps de réponse des points de contrôle. Une deuxième solution consiste à demander un acquittement à chaque action. Une fois que tous les acquittements sont arrivés, on réactive la collecte de mesure. Néanmoins, cette solution augmente le nombre de messages transitant sur le réseau et surcharge les points de contrôle. Cette solution est donc plus intrusive sur le réseau. Cependant, si l'on considère que les actions ne rentrent pas en conflit avec les données collectées, il n'est pas obligatoire d'implémenter de telles solutions.

b) Analyseur L'analyseur a pour but de déterminer l'état du système en fonction des rapports d'activités fournis par le moniteur. Il essaie de déterminer des tendances et peut déterminer les événements futurs par prédiction. Il complète la base de connaissances avec des prédicats intentionnels (Prédicats dont les instances sont déduites à partir d'une base de prédicats extensionnels). Cependant, afin d'effectuer cette analyse, il lui est nécessaire d'avoir accès aux événements antérieurs et de pouvoir effectué une analyse temporelle sur ces évènements. L'analyseur a donc accès à la base de connaissances afin de déterminer plus précisément l'état du système, soit parce que certaines informations ne sont pas dans le rapport d'activité, soit parce que l'analyseur a besoin de mesures antérieures afin d'établir des tendances. Les informations que l'analyseur déduit sont enregistrées dans la base de connaissances. Le principal problème réside dans la taille de cet historique. En effet, ce paramètre est important pour les performances du système. Il est probable que de très nombreuses informations soient collectées créant une base de connaissances grande, augmentant ainsi le temps des requêtes. Il est donc nécessaire de créer un ensemble réduit composé des événements ayant eu lieu dans un passé proche. Nous nommons cet ensemble l'historique. La taille de cet historique doit être choisie avec soin. En effet, un temps trop long ralentirait les recherches et un temps trop court empêcherait une bonne analyse. L'analyseur fournit un rapport d'analyse au planificateur. A partir de celui-ci, le planificateur doit pouvoir déterminer si il faut ou non effectuer des actions afin de modifier l'environnement.

c) Planificateur Le planificateur a pour but la création d'un plan d'actions parallèle. Cependant, cette tâche peut s'avérer extrêmement compliquée et longue. De plus afin d'améliorer l'exécution du plan, il est envisageable de construire des plans parallèles. Ces plans peuvent être obtenus de deux manières distinctes : ● Par objectifs ● Par politique d'adaptation 34 / 64


L'utilisation d'objectif[56] est une méthode plus ambitieuse. En effet, au lieu de construire le plan à partir de règle ECA, il est construit par planification. Cette technique consiste à déterminer la suite d'action pour obtenir la configuration désirée à partir de la configuration donnée par le rapport d'analyse. Le problème majeur avec cette méthode réside dans la complexité du problème. La planification est un problème NP-Complet. Il existe de nombreux algorithmes pour la planification, nous pouvons citer les algorithmes Back-ward, Strips[58] (malheureusement victime de l'anomalie de Sussman23) et Graphplan[59]. Malheureusement, ces algorithmes nécessitent de connaître l'ensemble des actions supportées par les points de contrôle, leurs pré-conditions et leurs effets. De plus, malgré de nombreuses optimisations, ces algorithmes restent relativement coûteux en mémoire et en temps de calcul. Ce désagrément limite le passage à l'échelle de ces algorithmes sur des grands systèmes. En effet dans notre cas, l'environnement peut contenir plusieurs applications, des milliers de clients et des infrastructures complexes ( grappes, routeurs, réseau, bases de données... ). L'autre méthode fait intervenir, une politique d'adaptation. Une politique est un ensemble de règle ECA. L'utilisation de politique facilite le travail du planificateur. En effet, pour créer le plan d'action, le planificateur résout les dépendances sur les actions des règles, en déduit un ordre ( total ou partiel ) puis écrit le plan d'action. Les règles ont accès à l'historique et le planificateur peut se servir de cet ensemble comme de mémoire de travail. Cependant, l'utilisation d'algorithme de planification comme Graphplan permet la conception de plan parallèle. Ceux-ci permettent d'effectuer deux actions en parallèles et peut réduire considérablement le temps d'exécution du plan d'action (à la condition que les actions du plan puissent s'effectuer sans conflit). Néanmoins, il est possible d'obtenir un plan d'action parallèle en utilisant une politique d'adaptation. En effet, celui-ci est rédigé à partir de l'ordre obtenu sur les actions. Si l'ordre trouvé est partiel alors le plan est un plan parallèle (Figure 13). Une fois le plan d'action parallélisé, il est envoyé à l'exécuteur. Action 1

Action 2

Action 4

Action 3

Action 5

Plan d'action à étage : Action 1 // Action 6 (Action 2- Action 3) // (Action 4 –Action 5)

Action 6 Doit précéder

Figure 13: Obtention d'un plan parallèle à partir d'un ordre partiel

d) Exécuteur L'exécuteur a en charge l'envoi des actions à exécuter aux points de contrôle en fonction du plan d'action. Il doit ainsi gérer l'exécution de plan d'action (pouvant être parallèle). Il doit aussi activer et désactiver la rédaction des rapports d'activités (rédigé par le moniteur) afin que les actions ne perturbent pas les mesures effectuées. 23

Strips ne renvoie pas obligatoirement le plan d'action minimal, ce problème est appelé Anomalie de Sussman[57]

35 / 64


L'exécution de plans d'action a déjà été traitée dans l'équipe ADELE dans le DEA de Cristina Marin soutenu en juin 2004. Ces travaux permettent l'exécution d'un plan d'action avec une reprise sur panne en cas de défaillance. De plus afin de coordonner l'exécution d'un plan, il est envisageable d'utiliser les techniques mises au point pour la gestion des processus. Ce genre de problématique est également traité dans l'équipe.

e) Administration L'administration est un point important dans l'informatique autonomique. En effet, bien qu'elle ait pour but de simplifier la maintenance des applications, la configuration et la surveillance de la boucle de contrôle peuvent être complexes. Comme nous l'avons vu tout au long de cette section, les administrateurs ont un certain nombre de choix à effectuer afin de configurer la boucle de manière optimum. Malheureusement, ces paramètres sont très dépendants de l'environnement ciblé. De plus, nous avons rajouter aux tâches d'administration : ● Le déploiement / l'arrêt / le retrait des points de contrôle ● La gestion des informations collectées par le moniteur ● L'ajout de données (mesures effectuées manuellement, nouvelles ressources disponibles, informations issues d'analyse à posteriori ...) dans la base de connaissances ● Le changement de politique d'adaptation / d'objectifs Cependant, une fois les paramètres fixés correctement, la boucle de contrôle permet un comportement autonomique de la plate-forme et diminue grandement les difficultés de maintenance.

3.2. Définition de politique pour l'administration autonomique L'architecture décrite dans le paragraphe précédent permet la mise en place d'une boucle de contrôle afin d'administrer une plate-forme de manière autonomique. Nous avons raffiner l'architecture de référence afin de la rendre adéquate à l'administration de plates-formes complexes. Néanmoins, l'architecture ne décrit pas comment sont décrites et exécutées les politiques d'adaptations. Cette section définit comment les règles d'adaptation peuvent être utilisées pour adapter l'environnement en vue de son administration. Nous ne ciblons pas le traitement des objectifs mais seulement des règles ECA. Cependant l'utilisation d'objectifs peut être utilisée dans certains domaines où l'environnement et les effets des actions sont bien définis.

3.2.1.Modèle de politique Afin de décrire les adaptations, nous utilisons des politiques. Elles sont utilisées par le gestionnaire autonomique qui exécute les règles contenues dans la politique et en vérifient la bonne application. Cette section montre comment les règles ECA peuvent être utilisées au sein de l'architecture décrite précédemment. 36 / 64


a) Ensemble de règles Une politique d'adaptation (Figure 14) est un ensemble de règle ECA (une instance de PolicySet). Celles-ci peuvent formées des groupes (PolicyGroup) permettant de réunir des règles collaborant dans un même but ou étant déclenchées par le même évènement. Chaque groupe (qui est en fait lui-même une politique) possède une priorité utilisée pour déterminer le plan d'action24. L'attribut PolicyDecisionStrategy permet de déterminer le mode d'analyse des règles de la politique, c'est à dire si les règles sont évaluées séquentiellement ou parallèlement. Ce choix influe sur le temps d'évaluation des règles du groupe. Les règles sont des instances de PolicyRule (Figure 14). Elles sont composées d'Event (représentant les événements déclencheurs), de ConditionsSet (représentant les conditions à évaluer lors de l'analyse de la règle) et d'Actions. L'attribut RuleDescription apporte seulement des informations sur la règle mais ne rentre pas en jeux lors de l'évaluation. ExecutionStrategy sert à déterminer le mode d'exécution de la stratégie (prioritaire, sans concurrence ... ) afin de gérer les règles critiques, c'est à dire qu'elle doivent être les seules à exécuter leurs actions sur l'environnement. L'attribut priority permet de spécifier un ordre d'exécution sur les règles du groupe. Ceci permettant de confectionner le plan d'action. Event représente simplement les évènements déclencheurs. Il se peut qu'une règle possède plusieurs clauses évènements. Elle est alors déclenchée si une occurrence d'un de ces événements est capturée. Il est donc nécessaire d'utiliser la clause condition pour vérifier une séquence d'évènement ... Les conditions sont représentées comme un ensemble de PolicyConditions. Celui-ci peut être formé soit par une seule instance de PolicyCondition, soit par des groupes (ConditionsGroup) pouvant être des groupes logiques ( disjonction, conjonction, négation ... ) ou des groupes temporels (suite d'occurrence d'évènement, la simultanéité ainsi que la relation précède permettant d'ordonner des évènements). Un ensemble de condition doit pouvoir être évalué, le résultat de cette opération dépend des occurrences d'évènements stockés dans la mémoire de travail (historique). Ce résultat est stocké dans l'attribut ConditionNegated. La clause Action de la règle est représentée par un ensemble d'instance d'Action. Chaque action possède une priorité (ActionOrder). Cette priorité a pour but la détermination d'un ordre entre les actions de la règle. Le modèle présenté décrit des politiques ECA utilisables dans de nombreux domaines. Il s'agit d'un modèle possible mais il en existe d'autres[60]. De plus, nous n'introduisons pas de syntaxe pour la description de politique. Il serait possible de décrire ces politiques en étendant RuleML25 (langage basé sur XML dédié à l'écriture de règles ). La section suivante présente comment sont intégrées les politiques dans l'architecture présentée dans la section 3.1.

24

Les priorités ne sont pas obligatoires, il est possible de déterminer le plan d'action à partir des pré-condition et des effets des actions. 25 Le projet RuleML propose une syntaxe XML pour l'expression de règles : http://www.ruleml.org/

37 / 64


Figure 14: Modèle de politique ECA exprimé en UML

b) Intégration des règles ECA dans l'architecture L'architecture de la section 3.1 permet la mise en place d'une boucle de contrôle afin d'administrer des plates-formes. Néanmoins, cette architecture ne montre pas comment intégrer les politiques d'adaptation nécessaire à cette administration. Les règles ECA de la politique configurent le déroulement de la boucle de contrôle. En effet, les évènements vont pas exemple agir sur le moniteur, alors que les actions sont à la charge de l'exécuteur. Il y a une répartition des règles ECA sur l'ensemble des composants de l'architecture. Cette distribution est présentée par la Figure 15. Les clauses évènements des règles sont sous la responsabilité du moniteur qui doit donc capturer les évènements nécessaires aux déclenchements des règles. Pour cela, il doit collecter les informations aux points de contrôle capturant ces évènements. L'analyseur doit permettre l'évaluation des conditions en fournissant un état complet du système. En effet, les conditions peuvent porter sur des prédicats intentionnels faisant partie de l'état du système. Ces informations peuvent être déduit en utilisant certaines règles (par exemple détecter des tendances) ... Ces règles ont la particularité de permettre la détermination de l'état du système.

38 / 64


Le planificateur a en charge l'application de la politique d'adaptation à proprement dit (c'est à dire contenant les actions à faire exécuter). D'après les informations capturées par le moniteur et l'état du système déduit par l'analyseur, le planificateur déclenche les règles en suivant la politique d'adaptation. Les conditions sont analysées en fonction du rapport d'analyse et de l'historique. Une technique que nous aborderons dans la suite de ce rapport consiste à utiliser un moteur de règle pour évaluer les règles. Evaluation des conditions (C) Construction d'un plan d'action (A)

Determination de l'état du système Analyse

Moniteur Capture des évènements (E) Collecte des Evènements (E)

Plan Envoi Plandes actions(A) d'action


Exécuteur

Exécution des actions (A)



Figure 15: Répartition des règles ECA sur l'architecture L'exécuteur reçoit le plan d'action puis envoie ces actions aux points de contrôle, il doit donc connaître les points de contrôle et les actions possibles. Si une action n'est pas valide (c'est à dire qu'elle ne peut pas s'exécuter sur l'environnement supervisée), il doit notifier les administrateurs qui devront modifier la politique ou les points de contrôle.

c) Règles de corrélation et règles d'action Chaque règle peut appeler une ou plusieurs actions. Nous distinguons deux types de règles suivant leur type d'action : ● Les règles de corrélation ● Les règles d'action Les règles de corrélation sont exécutées par l'analyseur et ont pour but de déterminer les prédicats intentionnelles. C'est-à-dire qu'elles déterminent des caractéristiques de l'environnement à partir des informations collectées. Ces actions affectent l'état connu du système mais n'interagissent pas directement avec l'environnement. Elles mettent à jour les variables d'état qui permettront l'évaluation des conditions des règles d'action. Les conditions des règles de corrélation sont plus limitées. En effet, elles ne doivent faire intervenir que des informations collectées ou des informations déjà déduites (par l'exécution antérieure d'autres règles de corrélation). Les règles d'action sont exécutées par le planificateur. Les actions sont récupérées, ordonnées puis seront exécutées par l'exécuteur. Il s'agit d'actions réelles dans le sens ou elles vont 39 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing directement modifier l'environnement ou la configuration des points de contrôle. Cependant, il est possible de classifier différemment les règles en fonction de leur utilité. Pour cela, nous pouvons nous baser sur les propriétés des système autonomiques. En effet, chaque règle peut être associée à une propriété[15]. Par exemple, les règles se référant à la tolérance aux pannes peuvent être associées à l'auto-réparation.

d) Règles d'actions et plan parallèle Les clauses actions des règles d'action déterminent les adaptations nécessaires à effectuer pour corriger l'environnement. Il faut néanmoins ordonner ces actions afin de construire le plan d'action. Le modèle de politique de la Figure 14 utilise les priorités pour la rédaction des plans d'action. Dans ce cas, les priorités se font à trois niveaux : ● priorité entre les groupes de règle ● priorité entre les règles d'un même groupe ● priorité entre les actions d'une règle Deux groupes de même priorité peuvent exécuter leurs actions parallèlement mais il se peut que celles-ci soient contradictoires ou incompatibles. Le plan d'action ne peut alors pas s'exécuter correctement et peut se retrouver interrompu laissant l'environnement dans un état incohérent. Pour éviter les erreurs d'incompatibilité, il est nécessaire de vérifier la cohérence des actions. Chaque action possède des pré-conditions nécessaires à son exécution. Elle ne peut pas s'exécuter correctement si ces pré-conditions ne sont pas vérifiées. De plus chaque action possède des effets, formalisant les changements quelles effectuent sur l'environnement. Grâce à ces deux informations, il est possible de déterminer un ordre partiel sur les actions, et d'en déduire un plan parallèle. Le planificateur part de l'état courant du système et cherche un ordre pour les actions afin de toutes les exécuter. Néanmoins, cette manipulation doit respecter l'ordre des priorités fixées par les administrateurs. De plus, il n'existe pas nécessairement d'ordre valide et il se peut qu'un plan d'action ne puisse pas s'exécuter. Dans de tels cas, les administrateurs doivent être notifiés et la politique doit être remplacée.

3.2.2.Classification des composants d'une application La suite de cette section est consacrée au contenu des politiques dans le cadre de l'administration d'application à composants. Les problèmes que nous abordons portent sur les applications à composants. C'est notamment le cas des applications J2EE et .NET. Afin d'adapter les application, il est logique que la plupart des actions portent sur ces composants qu'il faut migrer, modifier, répliquer[61].... Cela nécessite une classification des composants afin de pouvoir exprimer facilement des groupes sur lesquels portent les actions. Cependant, certains composants ne supportent ni les migrations ni les réplications.

a) Ecriture de règles pour les applications à composants

40 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing L'écriture de règles ciblant un ensemble de composant est importante, car elle diminue le nombre d'action a écrire, et augmente le pouvoir d'expression. La possibilité de décomposer une application en composant permet, par exemple, l'écriture de la règle de la Figure 16. Il est néanmoins possible de considérer les infrastructures comme des composants à part entière. Nous n'avons pas fait ce choix dans cette classification mais pourrait tout à fait être rajouté.

Figure 16: Exemple de politique écrite en XML faisant intervenir des composants Cette règle permet le déploiement d'une partie d'une application suite à la montée en charge de la machine 192.168.0.2. Elle porte sur des composants. Intéressons nous à la partie Action de la règle. La première action cible tous les composants de présentation de l'application «my_application ». La deuxième action cible un composant spécifique de l'application « another_application » : « /img/image.png ». Quand à la troisième action, elle cible tous les composants logiques de n'importe quelle application située sur la machine ayant l'IP 192.168.0.1. Le fait de classifier les composants d'une d'administration plus aisée. En effet, au lieu de est possible d'exprimer des ensembles comme présentation. Néanmoins le gestionnaire doit applications et en connaître le type.

application permet l'écriture de politique détailler les composants individuellement, il par exemple l'ensemble des composants de connaître l'ensemble des composants des

b) Classification des composants

41 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing La classification (Figure 17) effectuée est basée sur le modèle multi-étage. Elle a pour but d'être assez générale et permet son raffinement suivant le domaine voulu. L'objectif d'une telle classification est de pouvoir sélectionner un ensemble de composants suivant leurs caractéristiques.

Figure 17: Classification des composants d'une application Les composants sont classés en quatre grandes catégories : ● Les composants de présentation ● Les données ● Les composants formant la logique applicative ● Les composants non-fonctionnels Les composants de présentation sont eux même répartis en plusieurs catégories. Il est possible d'exprimer l'ensemble des composants participant à un espace de travail, à l'interface primaire (première interface d'une application) ou à l'interface globale (composants utilisés par toute l'application). Il est aussi possible de sélectionner un seul composant individuel ou même seulement un fichier. Les données sont classées en trois grandes branches. Tout d'abord les propriétés de l'application et le contexte d'exécution (contenant les sessions en cours) sont considérés comme des composants. La dernière branche des composants « données » sont les bases de données. Il est possible d'agir sur une base de données en entière ou sur quelques tables seulement ou bien sur des requêtes (tables calculées). 42 / 64


Les composants formant la logique applicative sont répartis en trois ensembles : les composants individuels ( un session bean pour J2EE), l'ensemble des composants contenant la logique applicative ou le composant « bootstrap » (c'est à dire le premier composant invoqué d'une application). La dernière catégorie de composants sont les composants non-fonctionnels. Il en existe deux types : les services nécessitant une configuration et les services sans configuration (par exemple si la configuration est déjà présente). Un composant peut être dans plusieurs catégories, dans ce cas il pourra être sélectionné par plusieurs expressions. Par exemple, la table « ma_table » de la base de données « ma_base » peut être sélectionnée par l'expression : ma_table mais aussi ma_base qui contient la table ainsi que par l'expression donnée qui contient l'ensemble des bases de données utilisées par l'application.

c) Problèmes de cohérence et composants critiques Certains composants ne doivent pas subir d'action. Par exemple, si un composant représente un stock, il ne faut pas le répliquer. En effet, le maintient de la cohérence entre toutes les copies de ce composant aurait un coût très élevé et réduirait grandement les performances de l'application. Donc il faut bannir certaines actions sur ces composants. La synchronisation entre plusieurs copies d'une même donnée à fait l'objet de nombreux travaux, notamment dans [62], [63], [64] et [65]. Cependant le poids de ces mécanismes ne sont pas négligeables. Il est nécessaire d'être prudent lorsque qu'un composant est répliqué. Si le nombre de réplications et si les mises à jour sont fréquentes, le nombre de messages nécessaire pour maintenir la cohérence de la donnée deviendra trop grand et réduira considérablement les performances d'une application. De plus, le client demandeur ne sera pas assuré de l'exactitude de l'information. Cependant, certaines applications n'ont pas nécessairement besoin d'une valeur exacte. D'autre part, certains composants ne doivent pas être redéployés pour des mesures de sécurité ou par ce qu'il s'agit d'un composant partagé avec une autre application. Ces composants sont considérés comme critiques. Afin de spécifier l'ensemble des composants critiques, la liste des actions autorisées sur chaque composant est fournit au gestionnaire.

3.2.3.Modèle d'évènement Les occurrences d'évènements déclenchant les règles doivent auparavant être capturées par le moniteur. Les évènements doivent donc suivre un modèle déterminé avant le démarrage de la boucle de contrôle. De plus le modèle d'évènement choisit l'influence des politiques avant de décrire les évènements déclencheurs des règles. Cette section présente un modèle d'évènement simpliste mais utilisable pour l'administration de plates-formes de manière autonomique.

a) Modèle d'évènement La notion de types d'évènements est importante pour le traitement des occurrences. Ce peut être un niveau (jauge), mais aussi un dépassement de seuil (alarme), un message simple ou 43 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing bien une mesures brut[66].

Figure 18: Exemples d'évènements capturables pour la répartition de charge Afin d'être utilisable par le gestionnaire autonomique, les types d'évènements doivent posséder un certain nombre d'information nécessaire à leurs traitements : ● Le nom de la sonde ● Le lieu de la prise ● La date de la prise (si le gestionnaire utilise la date de la prise comme référence) ● Le niveau de gravité (si il faut demander une analyse immédiatement) ● La valeur et l'unité ou le message de l'évènement ou le niveau de la jauge Il existe de nombreux modèles d'évènements plus complets. Nous pouvons citer le modèle d'évènement du CIM[33] ainsi que celui utilisé par IBM pour l'informatique autonomique26 Cependant, comme la taille des messages transitant peut être importante dans les perturbations de l'application, le choix du modèle est important.

b) Exemples d'évènements dans le cadre de l'administration La Figure 16 montre trois évènements de types différents. L'évènement qui demandent si l'ensemble des composants de présentation sont déployés. Ces conditions sont plus difficiles a traiter et demandent souvent une algèbre sur les ensembles. Une possibilité pour traiter ce problème consiste à utiliser une base de données (Les requêtes SQL permettent aisément l'expression de ces conditions). De plus, les moteurs de base de données sont optimisés pour la gestion des ensembles. Cependant, le coût des interactions avec la base de données n'est pas négligeable. Les conditions sont reliées entre elles par des opérateurs logiques. L'exemple montre une conjonction, mais la disjonction est tout de même possible. Les conditions temporelles sont les plus compliquées à évaluer et nécessite généralement une plus grande mémoire de travail. En effet, il faut enregistrer les événements sur une plage temporelle afin de pouvoir connaître les relations temporelles entre les évènements. La comparaison des dates des événements dans la mémoire de travail permet l'extraction de relation entre ces évènements. Nous nous sommes aperçus que les conditions temporelles nécessitaient des primitives afin de pouvoir exprimer simplement la plupart des opérateurs chroniques : ● précède(occurrence E) : occurrence : renvoi l'occurrence d'événement de même type précédent E ● dernier(type T) : occurrence : renvoi la dernière occurrence d'évènement de type T reçu ● date(occurrence E) : date : renvoi la date de réception de E ● précède(occurrence E1,E2) : booléen : vrai si la date de E1 est antérieure à la date de E2 Grâce à ces primitives il est possible d'exprimer les séquences, les itérations et les opérateurs chroniques relatifs ( suit, précède, périodique ...). 45 / 64


3.3. Une implémentation d'une boucle de contrôle pour l'administration autonomique Cette section présente une modélisation en Fractal[67][68] (annexe A) d'une boucle Administration On/Off Capture

Correlated Information

Report

Analyzer

Event Event

Monitor

Configuration

Result

Analysis Report Plan

Planner

Needed Info

Policy

Knowledge Database

Added Info Policy & Human Info

Action

Executor

Administration

Ctrl

Figure 19: Gestionnaire autonomique en Fractal autonomique adaptable. Plus de détails sur cette modélisation sont donnés dans l'annexe B. Le but de cette modélisation est de proposer une implémentation d'une infrastructure autonomique la plus adaptable possible. En effet, nous souhaitions que cette modélisation puisse s'adapter à de nombreuses situations. C'est pourquoi, certaines relations sont optionnelles. Nous présenterons tout d'abord le gestionnaire autonomique puis les points de contrôle.

3.3.1.Modélisation du gestionnaire autonomique Le gestionnaire autonomique (Figure 19) est l’implémentation d’une boucle de contrôle particulière. Bien que la Figure 19 paraisse plus complexe que l’architecture de référence, elle est composée des mêmes composants principaux. La principale différence concerne les liens Fractal qui sont unidirectionnels alors que l’architecture de référence utilise un bus de données commun multi-directionnel. Chaque composant est un composant Fractal. Ils sont détaillés dans l'annexe B. Chacun de ces 46 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing composants sont interchangeables ce qui permet d'adapter le gestionnaire à de nombreuses applications. Le composant primitif représentant le gestionnaire autonomique possède deux interfaces clientes ( event et result ) ainsi que deux interfaces serveurs (action et ctrl). De plus, le gestionnaire est muni d'une interface de contrôle dédiée à l'administration. L'interface ctrl est dédié à l'administration des points de contrôle. Elle permet le déploiement, la configuration et la gestion du cycle de vie de chacun des points de contrôle supervisés. L'interface event collecte les informations issues des points de contrôle. Elle réceptionne des messages et les transmet au moniteur. Les actions sont envoyées par l'interface action. L'interface result sert à gérer l'exécution des actions si cette exécution utilise des acquittements. Nous pouvons distinguer les principales interactions entre les composants : ● la liaison report entre le moniteur et l'analyseur transmettant les rapports d'activités et les alarmes critiques ● la liaison analysis report entre l'analyseur et le planificateur fournissant un état du système ● l'interface plan du planificateur est connectée à l'exécuteur afin de lui fournir les plans d'actions Le composant d'administration permet en plus de la gestion des points de contrôle, l'analyse en ligne de la base de connaissances, le rajout d'informations (déduites par des analystes), le changement de la politique d'adaptation, la gestion des souscriptions du moniteur...

3.3.2.Les points de contrôle Nous avons vu auparavant que les points de contrôle peuvent être de deux types : les points de contrôle dédiés captures et les points de contrôle dédié actions. Cette caractéristique change leur architecture. Nous verrons tout d'abord les capteurs puis les actionneurs. Nous terminerons sur l'architecture de points de contrôle hybrides.

a) Modélisation des points de contrôle dédiés captures La modélisation suivante (Figure 20) représente un capteur. Nous pouvons remarqué qu'un capteur est contrôle via l'interface ctrl. Cependant, ils sont aussi capables de recevoir des actions. Celles-ci peuvent être des demandes de mesures, une demande de souscription ou un changement de configuration (comme le temps entre chaque mesure). Chacune des actions doit être acquittée via l'interface result. Les interfaces Event in et Event out ont pour but la construction du graphe de capteurs. Elles ont la tâche de recevoir et de transmettre des informations.

47 / 64


Action

Configuration Manager

Result

Values Manager

Event Out

Sender

ctrl

Statistic Event Receiver

Event In

Pump

Figure 20: Architecture d'un point de contrôle dédié capture Le composant statistic permet l'implémentation de points de contrôle statistiques. Il doit apporter les méthodes permettant le calcul de statistique. Dans ce cas, le gestionnaire de valeurs (values manager), entreprend ces calculs et peut envoyer les nouvelles informations. Celui-ci peut posséder une mémoire afin d'effectuer des traitements sur plusieurs valeurs. Cette mémoire peut être flottante sur une période (c'est à dire que les nouvelles valeurs remplacent les plus anciennes), ou complète (toutes les mesures sont sauvegardés). Cette mémoire peut aussi stocker des mesures calculé avant l'envoie. Par exemple, si dix valeurs ont été collectées, le point de contrôle décide d'envoyer ces dix valeurs en un seul message. Le gestionnaire de valeurs a accès à une pompe. Il s'agit d'un composant primordiale pour les capteurs. En effet, ce composant à la charge de la collecte réelle des informations. La pompe est le seul composant qui a accès au capteur réel. Celui-ci n'est pas forcément un composant Fractal et peut être un Mbean JMX ou une sonde Lewys[69]. Il se peut que le capteur réel et la pompe ne soient pas collocalisés. La communication entre eux est alors à la charge de la pompe. Il est tout de même important que la pompe puisse être configurée afin de régler la période de mesure. Il se peut qu’un capteur n’ait pas de pompe. En effet, il raffine simplement les mesures récoltées par le canal d’évènements event in, en les assemblant ou en appliquant un traitement mathématique (grâce au composant de statistique).

b) Modélisation des points de contrôle dédiés actions Les actionneurs sont modélisés sur la Figure 21. Tout comme les capteurs, les points de contrôle dédiés actions possèdent d'un actionneur (effector), seul composant ayant accès à l'actionneur réel. La configuration des actionneurs se fait par l'interface ctrl. Il est possible de configurer un actionneur pour plusieurs raisons. Tout d’abord, il doit être possible de gérer son cycle de vie (l’arrêter, le démarrer ou le passiver). De plus, il se peut que certains actionneurs proposent plusieurs méthodes pour effectuer une action, il doit être possible de 48 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing sélectionner cette méthode. Ces deux types de configuration sont des décisions d'origine humaine. Donc il n'est pas nécessaire de connecter le gestionnaire de configuration à l'interface action car aucune configuration n'est effectuée ainsi.

Configuration Manager

ctrl

Action Receiver

Action

Result

Action Executor

Effector Figure 21: Architecture d'un point de contrôle dédié action Les actions reçues sont transmises à l'exécuteur qui a la charge l'exécution de l'action aussi que son contrôle. Si l'action s'exécute correctement, il envoie alors l'acquittement via l'interface result. Cette modélisation ne prend pas en compte la délégation d'action explicitement. Elle peut être réalisée par le composant actionneur qui décomposera l'action en sous-action puis déléguera leurs exécutions à d'autres points de contrôle. Il faudra tout de même informer l'actionneur de l'exécution des actions afin qu'il informe l'exécuteur de la réussite des actions.

c) Cas des points de contrôle hybrides Les points de contrôle hybrides peuvent à la fois effectuer de la collecte de mesure et effectuer des actions. Dans un tel cas, nous superposons les deux architectures présentées. Certains composants sont alors mis en commun comme le gestionnaire de configuration.

3.4. Conclusion sur l'administration autonomique de plates-formes Nous avons vu dans ce chapitre comme mettre en place une boucle autonomique pour l'administration de plate-forme et comment y intégrer des politiques d'adaptation. De plus, nous avons présenté une implémentation possible d'une telle infrastructure.

49 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing La suite de ce rapport porte sur un exemple d'application de cette implémentation pour le Edge Computing. De plus dans le cadre d'un prototype, nous avons élaboré une nouvelle classification des composants pour les applications J2EE.

50 / 64


4. Application dans le contexte du Edge Computing Le Edge Computing a pour but de mettre à disposition à des prestataires des ressources plus proches des utilisateurs afin d'améliorer leur qualité de services. Cependant cette technologie « on-demand », nécessite une administration lourde. En effet, au lieu d'administrer seulement l'application sur le réseau du prestataire, il faut aussi prendre en compte, les serveurs Edge, les migration d'une partie des applications, et la redirection des utilisateurs. De plus, le fait de vouloir être « on-demand » demande une grande réactivité ainsi qu'une grande flexibilité. Il apparaît alors intéressant d'utiliser une administration autonomique présentée dans la section précédente pour le Edge Computing. La suite de cette section présente un raffinage de l'architecture donnée dans la partie 4 et ainsi qu'un prototype pour les applications J2EE.

4.1. Affinage de l'architecture pour le Edge Computing Le Edge Computing est une technologie applicable dans un contexte déterminé. Cette section propose d'affiner l'architecture pour l'administration autonomique pour être en adéquation pour ce contexte particulier.

4.1.1.Environnement particulier Le fait de vouloir utiliser des serveurs Edge rend la plate-forme à administrer particulière. En effet, on peut distinguer deux types de ressources bien distinctes : ● Les serveurs primaires hébergés chez le prestataire ● Les serveurs Edge situé à plus près des utilisateurs De plus les actions principales effectuées sont les migrations (ou des réplications) et les rappatriement de « morceaux » d'application entre les serveurs primaires et les serveurs Edge. Ces deux particularités rendent l'environnement mieux défini par rapport au cadre générique. Cela permet de déterminer certains points de contrôle indispensables : ● Les « migrateurs » : gérant la migration / réplication / rapatriement des composants ● Les capteurs de charge et d'affluence : mesurant la charge et l'affluence de chacun des serveurs ● Les intercepteurs d'invocation permettant d'adapter la réponse (par exemple rediriger le client sur un serveur Edge) Il est aussi possible de déterminer les connaissances importantes que devra maintenir le gestionnaire autonomique afin de prendre les « bonnes » décisions : ● Les composants présents sur chacun des serveurs ( Edge et Primaires ) ● Les différents relevés de charges et d'affluence de chaque machine afin de détecter d'éventuelle montée de charge et d'affluence ● La disponibilité de chacun des serveurs Edge ( si le serveurs est disponible ou non )

51 / 64


4.1.2.Recherche de performances Néanmoins l'Edge Computing a pour but d'améliorer la qualité de services. Donc il est important que l'administration autonomique ne détériore pas les performances de l'application. Cette particularité influe directement sur les points de contrôle qui doivent limiter les perturbations qu'ils entraînent et sur le gestionnaire autonomique qui doit répondre rapidement aux demandes d'analyse. En effet, il n'est pas envisageable de mettre en attente les clients trop longtemps par ce que la prise de décision est longue. Il est envisageable d'avoir deux types de demande d'analyse : les analyses périodiques pour tout ce qui réfère à l'état du système, et les analyses critiques, plus rapide mais n'évaluant pas toutes les règles. Par exemple, lorsqu'une nouvelle session est ouverte, un intercepteur envoie une notification au gestionnaire autonomique tout en stoppant la connexion. Le gestionnaire répond à l'intercepteur si il faut accepter la connexion ou rediriger la requête.

4.1.3.Le contexte « EDGE Computing » Le contexte du Edge Computing nécessite une administration autonomique rapide et des points de contrôle limitant leurs intrusions. Malgré ces nécessités, les connaissances sur lesquels l'adaptation est réalisée sont réduites. De plus, les types d'action ne sont pas très diversifiées, ce qui permet la mise en place d'un protocole de communication léger.

4.2. Gestionnaire autonomique pour le Edge Computing Cette section présente une architecture raffinée afin de répondre aux exigences du Edge Computing. Nous commencerons par les contraintes sur les politiques que le Edge Computing impose. Ensuite nous nous intéresserons problèmes de performances que cela influe sur ls système.

4.2.1.Politiques pour le Edge Dans le cadre du Edge Computing, nous pouvons distinguer quatre sortes de règles : ● Les règles de migrations de composants ● Les règles de gérant les redirections de requêtes ● Les règles de tendances (donnant les tendances des différents niveaux de charges) ● Les règles assurant la tolérance aux pannes (s'assurant l'état des serveurs primaires et des serveurs Edge) Les deux premiers types de règles sont des règles d'actions, en fonction des informations courantes, elles vont agir sur l'environnement. Le troisième type de règles est des règles de corrélation. Quand règles du dernier type, elles peuvent être à la fois des règles de corrélation (en indiquant au reste du système l'état des ressources) et à la fois des règles d'action (si une panne est détectée, la règle décide peut déclencher des actions afin des réparer ). Il est donc possible de rendre autonomique une grande partie de l'administration pour de Edge Computing avec seulement quatre types de règles, rendant la rédaction de politiques relativement aisée. Cependant, le nombre de règles à écrire peut varier en fonction du prestataire, de l'application et du nombre de serveurs Edge à disposition. Il se peut alors que les politiques soient composées de très nombreuses règles afin d'avoir le comportement souhaité. Ce problème peut jouer sur les performances. 52 / 64


4.2.2.Evaluation des moteurs de règles Le Edge Computing demande une analyse rapide. Le gestionnaire autonomique doit répondre rapidement aux demandes de changements. Néanmoins cela demande une analyse évaluation rapide des règles. Passage à l'echelle de Drools et JRules 50 45

Temps en ms

40 35 30 Drools Jrules

25 20 15 10 5 0 100

1000

5000

10000

Nombre d'objets insérés

Figure 22: Passage à l'échelle suivant le nombre d'évènement de Jrules et Drools Passage à l'echelle de Drools et JRules 50 45

Temps en ms

40 35 30 Drools Jrules

25 20 15 10 5 0 100

1 000

5 000

9 000

Nombre de règles

Figure 23: Passage à l'échelle suivant le nombre de règle de Drools et JRules Afin de savoir si il était possible de concevoir des gestionnaires assez rapides pour un environnement aussi complexe, nous avons effectué un test des moteurs de règles disponibles sur le marché. Nous voulions un moteur de règles capables répondre rapidement malgré un grand de nombres de règles et un grand nombre d'information à prendre en compte. Les détails de ce test sont donnés dans l'annexe C. Les résultats de ces tests ont montré que certains moteurs de règles (Figure 22, Figure 23) étaient capables de supporter les contraintes du Edge Computing. Néanmoins, une hypothèse a 53 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing été faite : l'analyseur et le planificateur sont réunies afin d'analyser la politique en une seule fois. Cette hypothèse permet de réduire le temps de lancement de l'analyse. Cependant, dans certains cas particuliers, il peut être préférable de ne pas utiliser de moteurs de règles et d'utiliser un algorithme spécifique (ce choix est souvent fait lorsque l'environnement est très complexe à manipuler). Néanmoins, un tel algorithme peut être difficile à mettre au point, à maintenir et à étendre.

4.2.3.Interceptions des connexions Afin de rerouter les clients, nous sommes obliger de rajouter un point de contrôle d'interception et une interrogation au gestionnaire autonomique. Cette nécessité est très pénalisant pour les performances du système. Pour que notre approche soit acceptable, il faut que les clients reroutés profitent aux clients connectés de manière significative. C'est à dire que pour justifier cette interception l'application hébergée doit être assez gourmande en ressource et que le serveur ne puisse plus assurer le client sans diminuer la qualité de service des autres utilisateurs.

4.3. Validation de la boucle autonomique pour le Edge Computing Afin de valider notre approche pour une administration autonomique dirigée par des politiques dans le cadre du Edge Computing, nous avons implémenté un prototype basé sur des serveurs J2EE JONAS. Le but de cette implémentation est de montrer qu'il est possible de dirigé la adaptation du Edge Computing en utilisant des règle. Cette implémentation suit le modèle Fractal vu auparavant. Cependant, il a été pris en compte les particularités du Edge Computing.

4.3.1.Scénario du prototype Le prototype est composé de deux serveurs JONAS, un serveur primaire et un serveur Edge. De plus une troisième machine héberge le gestionnaire autonomique ainsi que les topics (nous avons utilisé l'intergiciel orienté messages JORAM). Nous simulons une montée de charge sur le serveur primaire déclenchant la migration de l'application sur le serveur Edge ainsi que la redirection des clients. Une fois que la charge du serveur primaire est redevenue normale, il accepte de nouveaux clients. Lorsque le serveur Edge n'est plus utilisé l'application est désinstallée.

4.3.2.Politique proposée La politique proposée est composée de quatorze règles. Les détails de cette politique sont donnés en Annexe D. Il peut s'avérer inquiétant que la gestion de seulement deux serveurs nécessite autant de règles. Cependant, les règles se ressemblent beaucoup et suivent les catégories citées auparavant. De plus, le fait qu'il existe des moteurs de règles capables de prendre en compte un très grand nombre de règles sans pour autant être trop lent permet d'envisager des politiques d'administration assez grandes pour gérer des systèmes réels. 54 / 64


Néanmoins, aujourd'hui nous n'avons pas d'estimation du nombre de règles pour les systèmes réels.

4.3.3.Architecture du prototype Le prototype est composé de trois machines. Deux d'entre elle simulent le serveur Edge et Primaire. La troisième machine est dédiée au gestionnaire autonomique, cependant elle héberge les topics Joram nécessaire à la communication. Nous avons choisi l'administrer une application simple fourni avec Jonas : earsample. Cette application contient une page d'authentification sur laquelle un client se connecte. Une fois, l'utilisateur authentifié, un certains nombre de tests sont effectués (invocation d'EJB ...). Nous avons choisi cette application pour sa simplicité à mettre en oeuvre tout en étant complet aux niveaux des fonctionnalités techniques (session bean, entity bean, servlet, JSP ...). Nous avons déployé plusieurs points de contrôle : ● Un intercepteur de connexions fournissant une réponse au client (soit l'accès à l'application, soit une redirection vers un autre serveur) ● Un intercepteur de déconnexion, permettant de capturer les fins de session ● Un session bean déployé sur les serveurs Jonas collecte l'utilisation mémoire du serveur. Cette mesure permet la détection de montée de charge. ● Un capteur d'utilisation mémoire installé sur la machine virtuelle du gestionnaire pour mesurer l'utilisation mémoire du gestionnaire

Figure 24: Architecture du prototype Les clients sont simulés avec JMETER27. Leur scénario est simple : il se connecte à 27

JMETER est disponible sur http://jmeter.apache.org

55 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing l'application, s'authentifie et exécute l'application. Ensuite il se déconnecte. Nous avons choisi JMETER car il permet une bonne configuration des clients virtuels et collecte un certain nombre de métrique comme le temps de réponse, le débit ... Le gestionnaire autonomique suit notre architecture. Le seul changement concerne l'analyseur et le planificateur qui sont réunis afin de diminuer le temps d'analyse. La base de connaissances est une base de données mysql stockant les événements, la nature des hôtes (Edge ou Primaire) et des paramètres comme le nombre de session acceptée, les niveaux d'utilisation mémoire ...Bien qu'il existe de nombreuses autres bases de données envisageables, il est nécessaire que cette base supporte les connexions simultanées et soit suffisamment robuste pour enregistrer les flots d'évènements. La politique est actuellement analysée par un algorithme spécialisé pour le prototype. Nous envisageons d'intégrer drools afin de permettre le passage à l'échelle. La communication entre le gestionnaire autonomique et les points de contrôle sont effectués par deux topics : event et action. Nous faisons l'hypothèse que les actions sont forcément correctement exécutées, c'est pourquoi le topic result n'est pas utilisé. Les politiques sont pour l'instant fixe, c'est à dire qu'il n'est pas possible de changer de politique sans redémarrer le gestionnaire autonomique.

4.3.4.Validation Le prototype est actuellement en cours de finalisation afin de respecter entièrement l'architecture présentée. Cependant, des tests ont déjà été effectués. Il est donc possible de mettre en place une boucle de contrôle autonomique dirigée par des politiques afin de gérer une application Edge. Le réseau Edge est donc administré à l'aide de politiques flexibles et facilement maintenables dirigeant un gestionnaire autonomique.

4.3.5.Perspectives du prototype Les résultats obtenus nous laisse penser qu'il est possible d'administrer de manière autonomique un réseau Edge à l'aide de la boucle de contrôle présentée auparavant. Cependant, le système prototypé est loin d'être adéquat aux systèmes réels et de nombreux développements doivent être encore entrepris. Plusieurs perspectives concernant le prototype sont en cours d'études. Elles concernent principalement l'optimisation de l'architecture ainsi que des tests plus approfondis. Actuellement, seule une partie de l'architecture proposée est implémentée. Afin d'améliorer l'analyse et le passage à l'échelle du prototype, l'intégration du moteur Drools est envisagée. De plus, afin d'améliorer le temps de communication, nous allons testé l'utilisation de RMI et de JMX à la place de l'intergiciel orienté message. Ceci permettra d'évaluer plus précisément si l'utilisation de message est trop pénalisante par rapport à d'autres techniques de communications. Nous envisageons aussi de d'utiliser une application plus complexe comme « petstore » 56 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing (application simulant une boutique en ligne), ou « TPC-W » (application de test de performance pour les bases de données). Nous voulons aussi perfectionner les clients afin de se rapprocher des systèmes réels. Parallèlement nous désirons adapter la politique actuelle afin de prendre en compte ces nouveaux paramètres.

57 / 64


5. Conclusion et Perspectives Nous avons vu que l'utilisation croissante d'Internet pose de plus en plus de problème au hébergeur d'application qui mutualisent des ressources provenant de plusieurs fournisseurs de service. Face à cette montée d'affluence, la technologie du « Edge Computing » émerge. Cette technologie consiste a rapprocher les ressources (de calcul et de données) des usagers dans un réseau d'opérateur ou de distribution de contenu afin d'améliorer la qualité de service. Cependant, l'administration d'un tel réseau est très complexe. En vue de diminuer les coûts de maintenance et d'augmenter la qualité de services d'un système, l'approche de l'informatique autonomique nous a semblé être une voie prometteuse. Nous avons étudié si son application dans le contexte du Edge Computing était envisageable. Pour cela, nous avons présenté, tout au long de ce rapport, la mise en place d'une boucle autonomique pour l'administration de plates-formes et son application dans le cadre du Edge Computing. Les principales contributions de ce rapport concernent le raffinement de l'architecture de l'informatique autonomique pour l'administration de plates-formes ainsi que la définition de politiques pour diriger les adaptations du gestionnaire autonomique. De plus, nous avons validée cette architecture dans le cadre de Edge Computing. Les résultats obtenus sont prometteurs et montrent qu'il est possible de simplifier l'administration de réseau Edge en utilisant les principes de l'informatique autonomique.

5.1. Perspectives à court terme Cependant, bien que le prototype prouve qu'il est possible de simplifier l'administration de plates-formes, sa mise en place reste complexe. Nous nous sommes aperçus que la configuration du graphe de points de contrôle s'avère difficile. Nous nous intéresserons actuellement à automatiser également le déploiement et la configuration des points de contrôle. Des travaux concernant ces mécanismes sont en cours dans l'équipe au sein du projet PISE. L'objectif de ces travaux est de spécifier et de prototyper des outils qui permettent à l'opérateur de déployer et de (re)configurer à distance des services pouvant être des points de contrôle et de superviser leur fonctionnement. La rédactions des rapports d'activité peut-elle aussi être améliorer en ajustant les données le composants en fonction de l'analyseur (taille de l'historique) et des plans d'action en cours d'exécution (perturbation de mesures). Un autre point que nous désirons améliorer concerne les politiques. Il nous paraît possible de créer des politiques capables d'adapter l'environnement mais aussi la configuration de la boucle autonomique en créant de nouvelles règles.

5.2. Perspectives à long terme Bien que nous simplifions l'administration en utilisant une boucle de contrôle, nous avons besoin de spécifier explicitement les adaptations. Nous désirons maintenant, aller plus loin en utilisant un planificateur par objectifs. Nous nous sommes limités à l'utilisation de règles ECA et à la construction d'un plan d'action à partir de ces règles, mais des moteurs de règles basés 58 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing sur Prolog pourraient être utilisés pour l'analyse et la planification. Ainsi, nous espérons atteindre le niveau 5 de l'échelle autonomique d'IBM, c'est à dire diriger un système à partir d'objectifs. La boucle autonomique serait dirigée par une liste d'objectifs qu'elle doit maintenir. Nous obtiendrons ainsi une administration grandement facilitée à l'aide de politiques aisément maintenables.

59 / 64


6. Bibliographie Bibliographie [1] Akamai - Turbo-charging Dynamic Web Sites with Akamai EdgeSuite, Rapport technique de Akamai Technologie, 2001, http://www.akamai.com/en/resources/pdf/whitepapers/ [2] Nottingham, M. et Liu, X. - Edge Architecture Specification, Rapport technique de Akamai Technologie et Oracle, 2001, http://www.esi.org/architecture_spec_1-0.html [3] Tsimelzon, M.; Weihl, B.l et Jacobs, L. - ESI Language Specification 1.0, Rapport technique de Akamai Technologie, 2001, http://www.esi.org/language_spec_1-0.html [4] Jacobs, L.; Ling, G. et Liu, X. - ESI Invalidation Protocol 1.0,W3C Note, 2001, http://www.esi.org/invalidation_protocol_1-0.html

[5] IBM - Autonomic Computing Manifesto, Rapport de recherche de IBM, octobre 2001, http://www.research.ibm.com/autonomic/manifesto/autonomic_computing.pdf

[6] Kephart, J. O.; Walsh, W. E. et Watson, T. J. - An Artificial Intelligence Perspective on Autonomic Computing Policies, Actes des Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'04), juin 2001 [7] Kephart, Jeffrey O. et Chess, David M.- The Vision of Autonomic Computing, dans Computer numéro 36, 2003 [8] HP - Adaptive Infrastructure – http://h20247.www2.hp.com/PublicSector/cache/5003-0-0-39-121.aspx [9] Microsoft - Dynamic Systems, http://www.microsoft.com/windowsserversystem/dsi/default.mspx [10] Hitachi - Harmonious Computing, http://www.hitachi.co.jp/Prod/comp/soft1/global/vision/harmonious.html

[11] Intel - Proactive Computing, http://www.intel.com/research/exploratory/ [12] Agarwal, M.; Bhat, V.; Liu, H. et Matossi, V. - Automate: Enabling Autonomic Applications On The Grid, http://automate.rutgers.edu/ [13] Dong X; Hariri S.; Lizhi X.; Huoping C.; Ming Z.; Sathija P. et Soujanya R. AUTONOMIA : An Autonomic Computing Environment, IEEE Journal, numéro 1, 2003 [14] Hariri, S.; Huoping, C.; Ming, Z.; Byoung, K.; Yeliang, Z. et Bithika, K.- An Autonomic Application Development & Management Environment, Rapport de recherche de Tucsown University, 2003 [15] Sterritt, R. - Exploring Autonomic Options in an Unified Fault Management Architecture through Reflex Reactions via Pulse Monitoring.,Actes de Engineering of Computer Based Systems (ECBS'04), 2004

60 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing [16] White S; Hanson J; Whalley I; Chess D et Kephart J - An Architectural Approach to Autonomic Computing, Actes de International Conference on Autonomic Computing (ICAC04), mai 2004 [17] Dearle, A.; Kirby, G. et McCarthy, A. - A Framework for Constraint-Based Deployment and Autonomic Management of Distributed Applications, Actes de International Conference on Autonomic Computing (ICAC-04), mai 2004 [18] Knight, John C.; Heimbigner, D.; Wolf, A.; Carzaniga, A. et Hill, J.- The Willow Survivability Architecture, Actes de Fourth Information Survivability Workshop, décembre 2001 [19] Georgiadis, I.; Magee, J. et Kramer, J. - Self-organising software architectures for distributed systems, Actes de WOSS '02: Proceedings of the first workshop on Self-healing systems, novembre 2002 [20] Sterritt Roy, Bustard Dave, Autonomic Computing — A Means of Achieving Dependability?,Actes de Engineering of Computer Based Systems (ECBS'03), avril 2003 [21] Kokar, M.; Baclawski, K. et Eracar, Y. A. - Control Theory-Based Foundations of SelfControlling Software, dans IEEE Intelligent Systems, numéro 14, mai-juin1999 [22] Oreizy P.; Michael M.; Richard T.; Heimbigner D.; Johnson G.; Medvidovic N.; Quilici A.; Rosenblum D. et Wolf, A. - An Architecture-Based Approach to Self-Adaptive Software, dans IEEE Intelligent Systems, volume 1,1999 [23] Andrade L. et Fiadeiro JL. - An Architectural Approach to Auto-Adaptive Systems, Actes de International Conference on Distributed Computing System (ICDCS'02), juillet 2002 [24] IBM - An architectural blueprint for autonomic computing, Rapport technique de IBM, avril 2003, http://www-03.ibm.com/autonomic/pdfs/ACBP2_2004-10-04.pdf [25] Carzaniga, A. et Orso, A. - Continuous Remote Analysis for Improving Distributed Systems Performance,Actes de RAMSS'03 : 1st International Workshop on Remote Analysis and Measurement of Software Systems, mai 2003 [26] Hilbert, D. M. et Redmiles, I - Extracting usability information from user interface events, dans ACM Computing Surveys, numéro 32, décembre 2000 [27] Gray, J. ; Bosworth, A.; Layman, A. et Pirabesh, H. - Data Cube : a relational aggregation operator generalizing group-by, cross-tab and sub-total, Actes des Proceedings of the 12th IEEE Data Engineering Conference, février 1996 [28] Mumick, S.I.; D. Quass et Mumick, B.S. - Maintenance of data cubes and summary tables in a warehouse, Actes de Special Interest Goup On Management On Data (SIGMOD'97), mai 1997 [29] Agrawal, R.; Imielinski, T.; Swami, A. N. - Mining Association Rules between Sets of Items in large databases, Actes de Special Interest Goup On Management On Data (SIGMOD'93), mai 1993

61 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing [30] Gardarin, G.; Pucheral., P. et Wu, F. - Bitmap based algorithm for mining association rules, Acte des Journées Bases De Données Avancées (BDA'98), octobre 1998 [31] Valetto, G. et Kaiser, G. - Using process technology to control and coordinate software adaptation, Rapport de recherche de Telecom Italia Lab et de Columbia University, 2003 [32] DMTF - Utility Computing Interface Standards – An Industry Frontier, Distributed Rapport technique de Management Task Force, août 2004, http://www.dmtf.org/standards/published_documents/DSP2005.pdf

[33] DMTF - Common Information Model Metrics Model, Rapport technique de Distributed Managment Task Force, 2003, http://www.dmtf.org/standards/documents/CIM/DSP0141.pdf [34] OpenGroup - Application Response Management - Java Binding, Rapport technique de l' Open Group, décembre 2004, ISBN : 1931624399, http://www.opengroup.org/onlinepubs/ [35] Foste, I.; Savva, A.; Berry, D.; Djaoui, A.; Grimshaw, A.; Horn, B.; Maciel, F. ; Siebenlist, F.; Subramaniam, R. ;Treadwell, J. et Reich, J. Von - Open Grid Service Architecture Specification 1.0, Rapport technique de Global Grid Forum, janvier 2005, http://forge.gridforum.org/projects/ogsa-wg

[36] Maciel, F. - Resource management in OGSA, Rapport de recherche de Hitachi, mars 2005, http://www.gridforum.org/documents/GFD.45.pdf [37] Tuecke, S.; Czajkowski, K.; Foster, I.; Frey, J.;Graham, S.; Kesselman, C.; Maquire, T. ; Sandholm, T. ; Snelling, D. et Vanderbilt, P., Open Grid Service Infrastructure, Rapport technique de Global Grid Forum, 2003, http://forge.gridforum.org/projects/ogsi-wg [38] Globus - The Globus Toolkit, http://www.globus.org/toolkit/ [39] Paton, Norman W. - Active Rules in Database Systems, Edition Springer, décembre 1999, ISBN : 0-387-98529-8 [40] Collet C. et Coupaye T - Primitive and Composite Events in NAOS, Actes des 12e Journées Bases de Données Avancées (BDA'96), août 1996 [41] Alia, M.; Lenglet, R. , Coupaye, T. et Lefebvre, A. - Querying reflexive componentbased architecture, Actes des Proceedings of the 30th EUROMICRO Conference, septembre 2004 [42] Collet C.; Coupaye T. et Svensen T. - NAOS Efficient and modular reactive capabilities in an Object-Oriented Database System, Actes des Proceedings of the Twentieth International Conference on Very Large Databases, 1994 [43] Cilia M.; Haupt M.; Mezini M. et Buchmann A. - The Convergence of AOP and Active Databases: Towards Reactive Middleware, Actes des Proceedings of the International Conference on Generative Programming and Component Engineering (GPEC'03), septembre 2003 [44] Bigus JP; Schlosnagle D.A.; Pilgrim J.R.; Mills III et Y., Diao - ABLE: A toolkit for building multiagent autonomic systems, dans IBM Systems Journal, numéro 41, 2002 62 / 64


[45] Kaminsky, D. - An Introduction to Policy for Autonomic Computing, Rapport technique de IBM, mars 2005, http://www-128.ibm.com/developerworks/autonomic/library/ac-policy.html [46] Pilgrim, J. ; Bigus, J. et Don, S. - Adding rules to applications, Rapport technique de IBM, février 2005, http://www-106.ibm.com/developerworks/autonomic/library/ac-able2/ [47] Nagapraveen, J.; Coupaye, T. et Collet, C. et Rivierre, N. - Des règles actives au sein d'une infrastructure logicielle autonomique, Actes de RENPAR'16 / CFSE'4 / SympAAA'2005 / Journées Composants, avril 2005 [48] Helal; Desai et Verma - Konark - A Service Discovery and Delivery Protocol for Ad-hoc Networks, Actes des Third IEEE Conference on Wireless Communication Networks, mars 2003 [49] Chefrour, D. et André, F. - Développement d'applications en environnements mobiles à l'aide du modèle du composant adaptatif ACEEL, dans STI, numéro 9, février 2003 [50] Hall, R.S. - Présentation invité Déploiement et Reconfiguration (DECOR'2004), octobre 2004 [51] Sterritt, R. D. - Towards an Autonomic Computing Environment, Acte des 14th International Workshop on Database and Expert Systems Applications, 2003. [52] Vitalya, R.; Hellerstein, C.V; Apteand J.L. et Ma, S. - Predictive algorithms in the management of computer systems, dans IBM System Journal, numéro 41, 2002 [53] Want, R.; Pering, T. et Tennenhouse, D. - Comparing autonomic and proactive computing., dans IBM Systems Journal, numéro 42, 2003 [54] Gelernter, D. - Generative communication in Linda, Actes de ACM Transaction on programming languages, janvier 1985 [55] Powell, D. - Group Communications, Actes de Communications of the ACM, avril 1996 [56] Neema, S. and Ledeczi, A. - Constraint-Guided Self-adaptation, Actes de International Workshop on Self-Adaptive Software (IWSAS) , 2001 [57] Sussman, G. - A Computational Model of Skill Acquisition,Rapport de recherche du MIT, 1973 [58] Fikes R. E. et Nilsson, N. - STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving., Actes de Automatic SAT-compilation of planning problems, 1971 [59] Blum, A. et Furst, M. - Fast Planning Through Planning Graph Analysis, Actes des Proceedings of the 14th International Joint Conference on Artificial Intelligence, 1995 [60] DMTF - CIM Policy Model White Paper CIM Version 2.7, Rapport technique de DMTF, juin 2003, http://www.dmtf.org/standards/documents/CIM/DSP0108.pdf

63 / 64

ESCOFFIER Clément – Administration autonomique dans le contexte du Edge Computing [61] Batista, V.; et Carvalho, G. - Component-Based Applications : A Dynamic Reconfiguration Approach with Fault Tolerance Support, dans Electronic Notes Theoretical Computer Science, numéro 65,2002 [62] Aashish, P. - A good synchronization process is the key to a usable PvC app, Rapport technique IBM, septembre 2001, http://www-106.ibm.com/developerworks/library/wi-trap.html [63] Pabla, C. - A beginner's look at the SyncML protocol and procedures, Rapport technique IBM, avril 2002, http://www-106.ibm.com/developerworks/xml/library/wi-syncml2/ [64] Stemberger, S. - An introduction to SyncML, Rapport technique IBM, octobre 2001, http://www-106.ibm.com/developerworks/wireless/library/wi-syncml/

[65] Suryanarayana, J. et Tunnicliffe, R. - JDBC and open source technologies simplify generic database replication, Rapport technique IBM, janvier 2005, http://www106.ibm.com/developerworks/java/library/j-sync4j/

[66] Gross, P.; Gupta, S.; Kaiser, G.; Kc, G. et Parekh, J. - An Active Events Model for Systems Monitoring, Rapport de recherche Columbia University, janvier 2001, http://www.psl.cs.columbia.edu/ftp/psl/CUCS-011-01.pdf

[67] Bruneton, E.; Coupaye, T.; Leclercq, M.; Quema, V. et Stefani, J.B. - An Open Component Model and Its Support in Java, Actes du International Symposium on Componentbased Software Engineering (CBSE'2004), mai 2004 [68] Coupaye, T.; Bruneton, E. et Stefani, JB. - The Fractal Component Model, France Rapport de recherche Telecom R&D, juillet 2002, http://fractal.objectweb.org/ [69] Cecchet, E.; Elmeleegy, H.; Layaïda, O. et Quéma, V. - Implementing Probes for J2EE Cluster Monitoring, Actes des Proceedings of OOPSLA 2004 : Workshop on Component and Middleware Performance, octobre 2004

64 / 64

Table des annexes Annexe A : FRACTAL........................................................................................................................ 2 Le modèle........................................................................................................................................ 2 Symbolisme..................................................................................................................................... 3 Annexe B : Modèle d'une boucle autonomique en Fractal...................................................................4 Objectifs...........................................................................................................................................4 Gestionnaire autonomique............................................................................................................... 4 Modélisation du moniteur................................................................................................................8 Modélisation de l’analyseur...........................................................................................................10 Modélisation du planificateur........................................................................................................ 10 Modélisation de l’exécuteur...........................................................................................................12 Les Capteurs.................................................................................................................................. 13 Les Actionneurs............................................................................................................................. 13 Utilisation d’un intergiciel orienté message ................................................................................. 14 Annexe C : Evaluation des moteurs de règles.................................................................................... 15 Annexe D : Politique utilisée dans le cadre du prototype ................................................................ 18

I / XXI

Annexe A :FRACTAL

Annexe A : FRACTAL Le modèle FRACTAL est dédié à la construction et la configuration dynamique de systèmes. F RACTAL est un modèle général qui n'est pas dédié à un langage particulier. Il existe plusieurs implémentation de ce modèle : Julia ( implémentation de base ), AOPKell, Julius...

Le modèle FRACTAL distingue deux types de composants : les composants primitifs sont essentiellement des classes Java standards avec quelques conventions de codage. Les composants composites encapsulent un groupe de composants primitifs et/ou composites. Une caractéristique originale du modèle est qu'un composant peut être encapsulé simultanément dans plusieurs composites. Un tel composant est appelé composant partagé. Les composants partagés sont particulièrement adaptés à la modélisation des ressources. Un composant est constitué de deux parties : la partie de contrôle, qui expose les interfaces du composant et comporte des objets contrôleurs et intercepteurs; et la partie fonctionnelle. Les interfaces d'un composant correspondent à ses points d'accès. On distingue deux types d'interfaces : les interfaces serveurs sont des points d'accès acceptant des appels de méthodes entrants. Elles correspondent donc aux services fournis par le composant. Les interfaces clientes sont des points d'accès permettant des appels de méthodes sortants. Elles correspondent aux services requis par le composant. Ces deux types d'interfaces sont décrits par une signature Java standard et une indication sur le rôle de l'interface (client ou serveur). Par ailleurs, le modèle définit une interface client particulière, appelée interface cliente de collection, qui peut être liée à plusieurs interfaces serveurs. La communication entre composants FRACTAL est uniquement possible si leurs interfaces sont liées. FRACTAL supporte deux types de liaisons : primitives et composites. Une liaison primitive est une liaison entre une interface client et une interface serveur appartenant au même espace d'adressage. Elle signifie que les appels de méthodes émis par l'interface client doivent être acceptés par l'interface serveur. Une liaison composite est un chemin de communication entre un nombre arbitraire d'interfaces de composants. Ces liaisons sont construites à l'aide d'un ensemble de liaisons primitives et de composants de liaisons (stubs, skeletons, adaptateurs, etc). Le modèle FRACTAL n'impose aucune limite sur les niveaux de composition (d'où son nom), et ne contraint pas la nature des contrôleurs contenus dans la partie de contrôle. Il est ainsi possible d'exercer un contrôle adapté sur les composants. La librairie FRACTAL fournit actuellement quatre contrôleurs : Le contrôleur d'attributs permet de modifier les attributs primitifs d'un composant. Ces attributs incluent les types primitifs Java (booléens, entiers, etc.) et les chaînes de caractères. II / XXI

Annexe A :FRACTAL

Le contrôleur de liaisons permet d'établir ou de rompre une liaison primitive entre les interfaces clients du composant qui possède le contrôleur, et une ou plusieurs interfaces serveurs d'autres composants. Le contrôleur de contenu permet d'ajouter et de retrancher des sous-composants à un composant composite. Le contrôleur de cycle de vie permet de contrôler le cycle de vie du composant qui possède le contrôleur. Le cycle de vie d'un composant est représenté par un automate à deux états : started et stopped. Le contrôleur permet de passer d'un état à l'autre.

Symbolisme La Figure 1 représente un exemple de composant FRACTAL. Les composants sont représentés par des rectangles. Le tour du rectangle correspond à la partie de contrôle du composant. L'intérieur du rectangle correspond à la partie fonctionnelle du composant. Les flèches correspondent aux liaisons entre composants. Les interfaces sont représentées par des T (noir pour les interfaces clients ; gris pour les interfaces serveurs). Notons que les interfaces internes permettent à un composite de contrôler l'exposition de ses interfaces externes à ses sous-composants. Les interfaces externes apparaissant au sommet des composants représentent les interfaces de contrôle du composant. Enfin, le composant hachuré est un composant partagé, il peut être partagé par plusieurs composites l'encapsulant.

Autre composant composite

Interfaces de contrôle Interface Sous-composant

Composant

Interface interne

Lien

Composant partagé

Contrôleur Figure 1: Exemple de modèle Fractal

III / XXI

Annexe A :FRACTAL

Annexe B : Modèle d'une boucle autonomique en Fractal Objectifs Le but de cette modélisation est de montrer une implémentation possible d’un cycle autonomique. Il a été voulu de montrer l’ensemble des interactions entre les différents composants. Ceci montre qu’il n’est pas aisé de concevoir une application autonome « from scratch ». Dans certains cas, toutes ces interactions ne sont pas nécessaires.

Gestionnaire autonomique Le gestionnaire autonomique (Figure 2), est l’implémentation d’une boucle de contrôle particulière. C’est lui qui va collecter les informations, les traiter et ainsi décider des actions à prendre. Il va aussi vérifier l’exécution de ces actions. Bien que la paraisse plus complexe que l’architecture de référence, elle est composée des mêmes composants. La différence, est que les liens en fractal sont unidirectionnels, alors que l’architecture de référence utilise un bus de données commun à toutes les entités multidirectionnel. Le fait de rajouter ces liens unidirectionnels permet de rendre séquentielle le processus d’analyse ayant lieu dans le gestionnaire autonomique. Administration On/Off Capture

Correlated Information

Report

Analyzer

Event Event

Monitor

Configuration

Result

Analysis Report Plan

Planer

Needed Info

Policy

Knowledge Database

Action

Executor

Administration

CTRL

Figure 2: Architecture du gestionnaire autonomique

Description des interfaces du moniteur IV / XXI

Added Info Policy & Human Info

Annexe B :Modèle d'une boucle autonomique en Fractal

Rappel : le moniteur a pour but de réceptionner les évènements provenant de l’environnement, de remplir la base de connaissance ainsi que de fournir un rapport d’activité à l’analyseur. Event C’est une interface cliente du gestionnaire autonomique. Les évènements sont transmis au moniteur. Les évènements sont des messages transmis par un intergiciel orienté messages (Dream dans notre cas). Le but de cette interface est la capture des évènements et des mesures prises sur l’environnement. Les points de contrôle dédiés captures utilisent cette interface pour envoyer les valeurs récoltées, les alarmes, les valeurs statistiques. Cette interface est nécessaire à tout cycle autonomique. On / Off Capture Cette interface permet d’activer ou de désactiver la prise en compte des évènements capturés. Elle sert principalement à stopper la collecte lorsqu’un plan est en cours d’exécution. Il peut s’agir d’un arrêt total ou seulement partiel des mesures (seulement les point de contrôle touché par le plan). Lorsque le plan est exécuté entièrement, l’exécuteur peut redémarrer les mesures du moniteur, et lui indique de recommencer un rapport d’activités. Cette interface n’est pas obligatoire, si on considère que les actions en cours d’exécution ne trouble pas les valeurs récoltées. Configuration L’interface Configuration est reliée directement au composant Administration, et permet de gérer les abonnements aux différents points de contrôle déployés dans l’environnement. Ainsi le moniteur sait quelles sont les sondes dont il reçoit les données, et peut donner la liste des actionneurs à l’analyseur. Ceci permet une gestion dynamique des points de contrôle déployés en gérant les abonnements aux sondes, et gérant la liste les actionneurs présents. Cette interface n’est pas obligatoire, il se peut que les points de contrôle déployés ne change pas, ainsi il est n’est pas nécessaire de gérer la dynamique de cet ensemble. Added Information L’interface Added Informations a pour but d’enregistrer dans la base de connaissances les mesures et évènements collectés. Cette interface permet de remplir la base de connaissances avec les données « brutes ». Report L’interface Report permet le passage d’un rapport d’activité à l’analyseur. Ce rapport est concocté à partir des informations obtenues par le moniteur, et résume l’activité de l’environnement à l’analyseur. Lorsque l’analyseur reçoit un rapport, il commence l’analyse. Cette interface est évidement obligatoire, elle fait partie des communications de base de du gestionnaire autonomique.

Description des interfaces de l’analyseur Rappel : l’analyseur a pour but de créer un rapport d’analyse à partir des rapports d’activités V / XXI


provenant du moniteur. Pour cela, il essaie de corréler les informations et de déterminer un modèle de la situation du système. L’analyseur reprend l’interface Report du moniteur. Il obtient par cette interface un rapport d’activités contenant les dernières informations reçues. Needed Information Cette interface cliente permet à l’analyseur d’obtenir d’autres informations que celles contenu dans le rapport. Il peut être nécessaire d’avoir une valeur antérieure, ou bien une valeur absente. Cette facette permet l’accès aux informations contenues dans la base de connaissances. Les informations ainsi demandées peuvent être corrélées avec celle reçue dans le rapport. On peut limiter l’analyse aux informations contenues dans le rapport, ainsi cette interface est facultative. Correlated Informations L’analyseur doit enregistrer les valeurs qu’il capture dans la base de connaissances, ainsi qu’effectuer une étude de corrélation et de comportement sur ces valeurs (simultanéité, tendance …). Cette interface n’est pas obligatoire si on considère que le planificateur n’a besoins que du rapport d’analyse pour trouver un plan. Mais cette interface sert à remplir la base de connaissances afin de permettre des analyses en ligne plus complète ainsi que des analyses post-mortem. Donc elle peut être intéressante au moment de la mise au point de la politique d’adaptation. Analysis Report L’interface Analysis Report permet le passage d’un rapport d’analyse au planificateur. Ce rapport est concocté à partir des informations obtenues par le moniteur, ainsi que des mesures corrélées. Lorsque le planificateur reçoit un rapport, il commence la recherche d’une solution pour rétablir l’environnement si cela s’avère nécessaire. Cette interface est évidement obligatoire, elle fait partie des communications de base de du gestionnaire autonomique.

Interfaces du planificateur Rappel : le planificateur a pour but de déterminer si il est nécessaire d’effectuer des actions pour rectifier l’environnement. Il fournit un plan d’action à l’exécuteur contenant les actions à exécuter. Le planificateur reprend 2 interfaces déjà décrite pour l’analyseur : needed informations et analysis report. Pour le planificateur, le rapport d’analyse peut ne pas suffire et ainsi demander d’autres informations à la base de connaissances. L’interface needed informations est donc nécessaire au planificateur, afin d’obtenir ces informations. Analysis Report est l’interface d’entrée du planificateur, dans le sens ou une recherche de plan ne peut se faire que lorsqu’un rapport d’analyse arrive. Policy VI / XXI


L’interface Policy sert au planificateur pour obtenir la dernière politique. En effet, il se peut que la politique change durant l’exécution de l’application. La nouvelle politique sera prise en compte lors de l’analyse suivant sont apparition dans la base de connaissances. Cette interface n’est pas obligatoire si le système utilise une politique fixe. Plan Cette interface sert à transmettre un plan d’action à l’exécuteur. Elle fait partie des interactions de bases du gestionnaire autonomique.

Interfaces de l’exécuteur Rappel : L’exécuteur a pour objectifs de faire exécuteur les actions définit dans le plan d’action ainsi que de vérifier leurs applications. Il doit aussi informer le moniteur si une exécution d’un plan d’action est en cours. L’exécuteur utilise l’interface Plan afin d’obtenir la plan d’action créé par l’analyseur. L’exécution commence lors de la réception du plan d’action et se termine lorsque toutes les actions ont été acquittées. L’interface On / Off capture permet de stopper la saisie par le moniteur des données provenant de l’environnement en lui indiquant qu’un plan est en cours d’exécution. De plus l’exécuteur à une interface reliée à la base de connaissances afin de diffuser les actions effectuées, ainsi que l’état des actionneurs (marche ou erreur). Result L’interface result à pour but de recevoir les acquittements des actions. En effet, lorsque l’exécuteur envoie une action à un actionneur, celui-ci doit renvoyer un résultat (réussie ou erreur). Il s’agit d’une interface client du gestionnaire autonomique. L’interface result n’est pas obligatoire, si on ne veut pas savoir si les actions ont bien été exécutées. Néanmoins, elle est utilisée pour déterminer lorsqu’un plan d’action est terminé donc nécessaire pour l’interface On / Off capture, et permet de contrôle la cohérence du système. Action L’interface action est une interface serveur du gestionnaire autonomique. Elle permet d’envoyer aux actionneurs les actions spécifiées dans le plan d’action. Les actions sont spécifiées sous la forme de messages et transit à l’aide d’un MOM. Si le plan est parallèle, les actions parallèles n’attendent pas l’acquittement des précédentes pour s’exécuter.

Interfaces de la base de connaissances Rappel : La base de connaissances à pour but d’enregistrer toutes les valeurs obtenues de l'environnement ainsi que les valeurs déduites. On y stocke aussi les rapports d’activités, les plans d’actions, les actions effectuées, les sondes déployés et leur état de marche.

VII / XXI


On peut distinguer 2 types d’interfaces concernant la base de connaissances : • Les interfaces de type requêtes : renvoyant des informations stockées (needed information, policy) •

Les interfaces de type ajout : rajoutant des informations (correlated informations, policy & human informations).

Policy & Human informations Cette interface sert aux administrateurs pour changer la politique en cours ou rajouter des informations issues d’analyses post-mortem. Elle n’est pas nécessaire si le gestionnaire autonomique n’a pas besoin d’être administré.

Interface du composant Administration Le composant Administration a en charge l’administration du gestionnaire. Il permet de connecter une console d’administration sur le manager afin de le configurer, de changer de politique, d’obtenir l’état du système, connaître les évènements capturées … Pour cela il est relié à l’interface de contrôle Administration du gestionnaire. Le composant d’administration contrôle la liste des mesures que reçoit le moniteur ainsi que la liste des actionneurs qu’il connaît via l’interface Configuration. L’interface Policy & Human informations permet d’ajouter des informations issues d’analyses postmortem dans la base de connaissances ainsi que de changer la politique actuelle. L’interface needed informations permet d’obtenir les informations actuellement stockées dans la base de connaissances. CTRL L’interface CTRL permet le déploiement et le contrôle des points de contrôle. Il permet aussi la gestion de leur cycle de vie, et leurs configurations. L’administrateur est prioritaire sur le manager, donc les actions spécifiant un changement de configuration (par exemple le temps de capture) ne seront pas exécutées.

Modélisation du moniteur La Figure 3 décrit un moniteur. Il s’agit d’une implémentation possible. Il se peut que dans certains cas, certains composants soient inutiles. Ce moniteur est composé de 3 composants. Il possède 3 interfaces clientes et 2 interfaces serveurs comme spécifié auparavant. Le Récepteur a pour but la réception des évènements provenant des sondes. Cette capture peut être démarrer ou arrêter via l’interface On / Off Capture. De plus, il peut être configuré via l’interface Configurer. Cette configuration sert à abonner le récepteur aux sondes (réception des mesures, des alertes …). VIII / XXI


Filter

Collected Info

Receiver

Configuration

Report Maker

Report

Event On / Off Capture

MONITOR

Figure 3: Structure d'un moniteur La réception des évènements se fait via l’analyse d’un message transporté par un intergiciel orienté message. Ce message contient les informations suivantes si il s’agit d’une mesure: • Nom du capteur •

Date de capture

•

Nom de la mesure

•

Unité de la mesure

Si il s’agit d’une alerte : • Nom du capteur •

Date de capture

•

Nom de l’alerte

•

Valeur capturée précédente (optionnel)

•

Unité de la mesure

Si il s’agit d’un ensemble de valeurs : • Nom du capteur •

Unité de mesure

•

Couples date de capture / valeur capturée

Le filtre est un composant spécifique à l’application. Il permet d’éliminer certaines mesures, considérées comme invalides, ou inutiles pour la suite de l’analyse. Il serait possible de configurer ces filtres, en connectant ce composant à l’interface Configuration. Les informations reçues par le moniteur sont enregistrées dans la base de connaissances, via l’interface Collected Informations. Cela permet de stocker toutes les mesures capturées. Le créateur de rapport crée le rapport d’activités à partir des valeurs récoltées. Ce composant peut être configuré afin de spécifier le temps de période d’émission des rapports ou les situation critiques forçant l’envoie d’un rapport. Le créateur est relié à l’interface On / Off Capture afin de lui indiquer quand il doit recommencer un nouveau rapport (lorsqu’un plan d’exécution se termine). Le rapport contient : IX / XXI

Annexe B :Modèle d'une boucle autonomique en Fractal •

La date de début du rapport

•

La date de fin

•

L’ensemble des valeurs collectées

•

L’ensemble des tendances déduites

•

L’ensemble des abonnements

•

L’ensemble des actionneurs déployés

Une fois le rapport terminé, il est envoyé à l’analyseur.

Modélisation de l’analyseur L’analyseur a pour but de déterminer d’autres informations importantes ainsi que la situation du système à partir du rapport d’activité. La montre l’exemple d’un analyseur possible. Cet analyseur possède 2 interfaces clientes et 2 interfaces serveurs (Figure 4). Correlated Info

Analysis Report

Report Parser

Correlation

Report

Needed Info

Report Maker

ANALYZER

Figure 4: Architecture d'un analyseur Le composant « parseur de rapports », récupère un rapport d’activités et le transforme afin qu’il soit analysable par le composant de corrélation. Le composant Corrélation recherche les tendances, les mesures corrélées à partir des valeurs reçues. Il se peut qu’il ait besoin de valeurs antérieures donc à accès aux informations contenues dans la base de connaissances (via l’interface Needed Info). Le Corrélateur a aussi comme charge d’enregistrer les informations déduites dans la base de connaissances (via l’interface Correlated Info). Une fois l’analyse du corrélateur terminée, le composant de création de rapport crée un rapport d’analyse contenant une description de la situation du système ainsi que les informations déduites par corrélation.

Modélisation du planificateur

X / XXI


Le modèle Fractal suivant (Figure 5) modélise un planificateur. Le planificateur a pour but de déterminer un plan d’action en fonction du rapport d’analyse en suivant la politique donnée par l’administrateur. Le planificateur suivant ne prend pas en compte le fait que le système peut instaurer de nouvelle règle à rajouter dans la politique. Cette option nécessiterait un moteur d’apprentissage permettant d’élaborer de nouvelles règles en fonctions des rapports d’analyses. Cette élaboration nécessite une grande compréhension et une grande connaissance de l’environnement et des effets des actions faisables. Le Rapport, obtenu par l’analyseur, est tout d’abord analysé afin de le rendre utilisable par le composant d’analyse. Celui-ci utilise un moteur de règles permettant d’inférer sur les règles présentes dans la politique et découpée en règle par le parseur de règles. De plus il se peut que le rapport d’activité ne suffise pas (par exemple pour les règles temporelles), il faut alors permettre au composant d’analyse la possibilité d’obtenir des informations de la base de connaissances (via l’interface Needed Info). Analysis Report

Report Parser Rule Engine Analysis

Needed Info

Rule Parser

Plan

Plan Maker

Policy

PLANER

Figure 5: Architecture d'un planificateur Le choix du moteur de règles est déterminant pour la rapidité et la justesse de l’analyse. Ce choix dépend du domaine d’application ainsi que du but recherché (performance, maintenance, monitoring, détection de pannes …). Une fois l’analyse effectuée, un plan d’actions est concocté par le créateur de plan. Il existe plusieurs manières d’obtenir un plan. Si les actions sont déterminées dans les règles il suffit d’agencer ces actions et d’établir un ordre total ou partiel (plan parallèle) sur cette liste d’actions. Si les règles stipulent seulement une configuration finale désirée (et non plus les actions à faire), il faut alors effectuer une recherche de plan en utilisant des algorithmes comme GraphPlan. Ce genre d’algorithme est coûteux et nécessite des structures de données lourdes (base de faits, écriture des actions généralement en STRIPS ainsi que les prédicats …) XI / XXI


Le choix de l’un ou l’autre des techniques peut s’avérer crucial pour la performance du système. En effet, la recherche de plan est un problème NP-complet, donc dégradant les performances de l’analyse. Néanmoins elle ne nécessite pas la détermination des actions dans les règles. Ce choix va influencer le format des règles ainsi que le moteur de règles choisit. Le plan d’action sera composé d’une suite de d’ensemble d’action pouvant être réalisées simultanément. Un fois définit, il est envoyé à l’exécuteur qui a en charge sa mise en application.

Modélisation de l’exécuteur L’exécuteur a pour but de faire exécuter et de vérifier l’exécution des actions stipulées dans le plan d’action. Il doit aussi activer ou désactiver la rédaction de rapport d’activité du moniteur. De plus, il doit signaler les actions effectuées ainsi que les pannes éventuelles au reste du système en enregistrant ces informations dans la base de connaissances.

On / Off Capture

Info

Action

Result Analyzer

Action Manager

Action Sender

Plan Parser

Result

Plan

EXECUTOR

Figure 6: Architecture d'un exécuteur L’exécuteur modélisé (Figure 6) est constitué de 4 composants. Lorsqu’un plan est réceptionné il est tout d’abord analysé et découpé. Il est ensuite transmis au gestionnaire des actions. Ce composant est un noyau de l’exécuteur. Il doit générer les messages des actions à envoyé tout en prenant en compote les activités suivantes : • Gestion des plans parallèles •

Activation / Désactivation des rapports d’activités

•

Décision de réémission si une erreur est détectée (nombre de réémission avant la déclaration de panne)

•

Décision de continuer ou d’arrêter un plan lorsqu’une erreur est détectée (catégorisation des erreurs)

•

Informer la base de connaissances des actions effectuées et des défaillances trouvées XII / XXI


Les actions sont réellement envoyées aux actionneurs par le composant d’envoie des actions. Elles sont transmises sous la forme de messages (rédigé par le gestionnaire d’actions) via un intergiciel orienté messages. Les résultats des actions sont réceptionnés par l’analyseur de résultats, qui va informer le gestionnaire de la réussite ou non des actions. Les résultats sont aussi transmis sous forme de messages, et contiennent les informations suivantes : • Identifiant de l’action (il est unique) •

Date de réception / traitement

•

Classe du résultat (INFO, WARN, ERROR)

•

Message

Les Capteurs Nous appellons capteur la partie permettant la collecte de donnée. Celles-ci sont collectées par un composant spécifique appelé pompe. Son rôle est de récupéré des données sur demande ou de manière périodique (de période configurable). Les réseaux de capteurs utilisent les mêmes canaux de messages que le gestionnaire autonomique. Le récepteur d’évènements a pour tâche de récupérer ces messages en sélectionnant ceux auquel le capteur est abonné. Cette liste d’abonnement peut être mise à jour via une interface d’administration sur le récepteur. Un capteur est configurable de deux manières, soit par le dispositif d’administration du gestionnaire autonomique (via l’interface CTRL). Soit en envoyant une action, classée comme étant un action de configuration. Ensuite ces demandes de configuration sont traités par le gestionnaire de configuration puis sont réparties vers la pompe (pour configurer les période de prise de mesures), soit vers le gestionnaire de mesures pour la configuration des alertes, soit vers le récepteur d’évènements pour la gestion des abonnements. Le gestionnaire de valeurs est le composant central d’un capteur. Il est lié directement à la pompe et à la capacité de recevoir et de demander des mesures à la pompe. De plus il lui est possible de faire appel à un composant dédié au calcul de statistiques permettant de calculer des moyennes ou de faire de la prédiction sur les futures valeurs. Le composant de statistiques peut s’avérer gourmand en mémoire et en ressources, mais il permet de limiter le nombre d’évènements transitant sur le réseau en y affectant un prétraitement. Le gestionnaire de valeurs reçoit aussi les évènements auquel le capteur est abonné, afin de composer d’autres mesures à partir de celle recueilli par la pompe et celle du canal. Il se peut qu’un capteur n’ait pas de pompe. En effet, il raffine simplement les mesures récoltées par le canal d’évènements, en les assemblant ou simplement y appliquant un traitement mathématique dessus (grâce au composant de statistiques).

Les Actionneurs XIII / XXI


Les actionneurs sont les points de contrôle permettant d’agir sur l’environnement. Il exécute des actions décidées par le gestionnaire autonomique. Bien que les actionneurs puisse aussi former un réseau afin d’affiner les actions en sous actions jusqu’au actions élémentaires, nous n’avons pas modéliser explicitement se comportement, en admettant que le planificateur fournira directement des actions élémentaires (c'est-à-dire ne nécessitant qu’un seul actionneur). Les actionneurs délèguent l’action à faire à un composant charger d’effectuer l’action réellement. Celui-ci doit tout de même renvoyer le résultat de l’action pour savoir si elle a bien été effectuée. L’actionneur est composé principalement de l’exécuteur d’action chargé de faire appliquer l’action et de renvoyer le résultat. Il est possible de configurer un actionneur pour plusieurs raisons. Tout d’abord, on doit pouvoir gérer son cycle de vie (l’arrêter, le démarrer ou le passiver). De plus, il se peut que certains actionneurs proposent plusieurs méthodes pour effectuer une action, il doit être possible de choisir cette méthode.

Utilisation d’un intergiciel orienté message La communication entre le gestionnaire autonomique et les points de contrôle est faite par un MOM, utilisant la politique de producteur / consommateur sur des canaux déterminé à l’avance. La figure suivante montre comment la communication entre le gestionnaire et les point de contrôle peut être réalisé en utilisant un MOM genre JMS ou DREAM (Figure 7).

Sensor - Mesure A - Mesure A’

Event

A, B

A’ Sensor - Mesure B

Autonomic Manager Result

*

Actions Actuator AC1

Ac1

Figure 7: Utilisation d'un MOM

XIV / XXI

Annexe C :Evaluation des moteurs de règles

Annexe C : Evaluation des moteurs de règles Introduction Cette évaluation a été réalisé par Marc Calvisi (Bull) et Clément Escoffier (LSR/ADELE) Ce document décrit le protocole de test adopté pour tester les performances de différents moteurs de règles. Les moteurs de règles suivants ont été testés. • Mandarax • Ilog JRules • Drools Ils ont été sélectionnés selon les critères suivants : • Ecrit entièrement en Java et accompagnée d'une API documentée • L'écriture de règle doit être relativement simple • Le moteur de règle doit être suffisamment rapide • Il doit être possible d'implémenter les opérateurs chroniques • Il doit être possible d'écrire une règle en fonction d'une autre règle voir d'elle même Protocole de test Afin de tester les performances des moteurs de règles, nous avons expérimenté ces moteurs selon le nombre de règles et selon le nombre d'évènement à prendre en compte ( tous de même type (type1)) Les différentes valeurs des paramètres étaient les suivantes : ● nombre de règles : 100-1000-5000-9000 ● nombre d'objets: 100-1000-5000-1000 Nous avons donc effectué 16 configurations ( évaluée 6 fois chacune). Les objets “type1” introduits dans la mémoire ne déclenchent pas de règles à eux seul. Les règles sont déclenchées avec un deuxième objet “type2”. Les conditions des règles étaient les suivantes: objetType1.getValue() == objetType2.getValue() Cinq objets de type “type2” ont été introduits dans la mémoire et les valeurs des objets ont été choisis afin que seulement 5 règles se déclenchent parallèlement. Les test ont été réalisé sur une machine cadencé à 1Ghz avec 256 Mo de RAM. La machine virtuelle utilisée est la JRE 1.5-03 de Sun Microsystem, sous Windows XP SP2. Les temps mesurés Données mesurées XV / XXI


Les données mesurées sont les temps en ms pour : ● écrire les règles dans un fichier, si c'était nécessaire pour le moteur ● analyser les règles et les placer en mémoire ● initialiser le moteur de règles, pour construire par exemple dans le cas de l'utilisation de l'algorithme Rete, le réseaux des noeuds de décision. ● insérer des objets de type “type1”, (temps nécessaire pour inséré les objets dans la mémoire de travail ) ● le temps d'exécution du moteur de règles ( durée d'évaluation des règles ) Evaluation ● ●

Mandarax n'est pas réactifs malgrés de bonne performances pour des utilisations normales. JRules et Drools sont beaucoup plus rapides. Leurs performances sont relativement identiques

Résultats Mandarax :

Temps en ms

Passage à l'echelle de Mandarax 37500 35000 32500 30000 27500 25000 22500 20000 17500 15000 12500 10000 7500 5000 2500 0 1 000

5 000

9 000

Nombre de règles

Temps en ms

Passage à l'échelle de Mandarax 37500 35000 32500 30000 27500 25000 22500 20000 17500 15000 12500 10000 7500 5000 2500 0

Mandrarax

100

1000

5000


XVI / XXI

10000


Drools et Jrules :

Passage à l'echelle de Drools et JRules 50 45

Temps en ms

40 35 30 25

Drools Jrules

20 15 10 5 0 100

1000

5000

10000


Passage à l'echelle de Drools et JRules 50 45 40

Temps en ms

35 30 25

Drools Jrules

20 15 10 5 0 100

1 000

5 000

Nombre de règles

XVII / XXI

9 000

Annexe D : Politique utilisée dans le cadre du prototype

Annexe D : Politique utilisée dans le cadre du prototype Variables d’état : MEM1 : niveau d’utilisation mémoire de la JVM du serveur primaire MEM2 : niveau d’utilisation mémoire de la JVM du serveur Edge NbSession1 : nombre de session sur le serveur primaire NbSession2 : nombre de session sur le serveur Edge EdgeOk : vrai si le serveur Edge répond (détecteur de panne) Appdisponible : vrai si l’application est déployée sur le serveur Edge MonteeCharge1 : vrai si une montée de charge a été notifiée pour le serveur primaire MonteeAffluence1 : vrai si une montée d’affluence a été notifiée pour le serveur primaire Constantes à fixer : $LIMITE : nombre de session acceptée sans surcharge par les serveurs $HIGH : niveau d’utilisation mémoire élevée $NORMAL : niveau d’utilisation mémoire normale $TIMEOUT : temps maximum d’attente avant notification mémoire Actions : GarderClient : Le client est gardé {Pre: il y a une connexion d’un client} {Post: NbSession1++} Redirection client : Le client est redirigé vers un serveur Edge {Pre: EdgeOk && AppDisponible && il y a une connexion d’un client sur le serveur primaire} {Post : EdgeOk && AppDisponible} Migration de l’application : L’application est migré sur le serveur Edge {Pre: EdgeOk && not(AppDisponible)} {Post: EdgeOk && AppDisponible} Suppression application : L’application déployée sur le Edge est supprimée {Pre : EdgeOk && AppDisponible} {Post : EdgeOk && not(AppDisponible)} Evènements : ConnexionPrimaire : un client se connecte sur le serveur primaire, la connexion est capturée à son établissement par le filtre AlarmeMEM1 : La mémoire de la JVM 1 (serveur primaire) subit une montée de charge AlarmeMEM2 : La mémoire de la JVM 2 (serveur Edge) subit une montée de charge AlarmeSession1 : Le serveur primaire subit une montée d’affluence AlarmeSession2 : Le serveur Edge subit une montée d’affluence Règles :

XVIII / XXI

Annexe D : Politique utilisée dans le cadre du prototype

Règles de migration et de redirection clients Règle1 : Sur [ConnexionPrimaire] Si [MEM1 = $LIMITE && NbSession2 >=$LIMITE] Faire [Garder client] // Migration sur surcharge mémoire serveur primaire Règle3 : Sur [ConnexionPrimaire] Si [MEM1 >= $HIGH && MEM2 pre(MEM1) && pre(MEM1) => pre(pre(MEM1))] Faire [MonteeCharge1==true] Règle11 : Sur [ConnexionPrimaire] Si [NbSession1 => pre(NbSession1) && MontéeAffluence1] Faire [MonteeAffluence1==true] // Notification « retour à la normale » Règle12 : Sur [Notification MEM1] Si [MEM1 < pre(MEM1) && MonteeCharge1] Faire [MonteeCharge1==false] Règle13 : Sur [ConnexionPrimaire] Si [NbSession1 < pre(NbSession1) && MontéeAffluence1] Faire [MonteeAffluence1==false] Règle détectant les pannes Règle14 : Sur [Notification MEM1] Si [(date(last(notification MEM2))