L’informatique autonomique ou « Autonomic Computing »

L’informatique autonomique ou « Autonomic Computing »

Automatique, Autonome et Autonomique

Différence entre automatique et autonome

Les termes automatique et autonome se réfèrent à un même but : celui de soulager ou de restreindre au strict minimum une intervention humaine. Dans le domaine de l’informatique, ces termes concernent des processus qui peuvent être exécutés indépendamment, du début à la fin, en évitant au maximum l’intervention humaine. La différence réside dans le fait que les processus automatiques remplacent simplement une routine manuelle contre une routine codée (de manière logicielle ou matérielle) qui suit une séquence décrite étape par étape. Cette séquence peut éventuellement faire intervenir de nouveau l’humain à une certaine étape. Un processus autonome quant à lui, émule un comportement humain dans le sens où il englobe un ensemble de tâches. Un système autonome peut être vu comme une imbrication de systèmes automatiques en y ajoutant la communication entre ces systèmes automatiques.

Différence entre autonome et autonomique

L’autonomie est le fait de déléguer de la responsabilité au système autonome pour atteindre des objectifs définis. C’est à dire que l’autonomie est l’automatisation de la prise de responsabilité et de la prise de décision pour que les différentes tâches du système soient réussies. L’autonomique, quant à lui, est le fait que le système se contrôle lui-même, sa spontanéité résulte en général de stimulus. C’est à dire que l’autonomique est l’automatisation de la prise de responsabilité et de la prise de décision pour que tout le processus d’opération du système fonctionne. Ainsi, en fonction du degré d’automatisation, on peut imaginer qu’un système autonomique puisse créer ses propres buts. Par exemple, un système qui a pour tâche de détecter un phénomène particulier peut utiliser un ensemble d’éléments prédéfinis. Ce système peut être autonome et décider par lui-même de quels éléments il a besoin pour détecter ce phénomène, c’est à dire qu’il choisit ses paramètres internes afin d’accomplir ses tâches de détection. Par contre, tout ce qui assure que le système continue d’opérer au mieux, même quand plusieurs éléments tombent en panne, ne fait pas directement partie des buts premiers du système, c’est à dire de son autonomie de détection. Un système autonome peut donc échouer dans son but premier s’il ne gère pas les changements dynamiques, les comportements incertains dans son propre environnement. Dans cette optique, l’autonomique peut se définir comme une spécialisation de l’autonomie, c’est à dire une autonomie vis-à-vis de la gestion du système lui-même. Le système autonomique peut en effet être considéré comme un système autonome qui inclue nécessairement ses propres systèmes de contrôle, c’est à dire qu’il s’auto-contrôle.

La vision de l’informatique autonomique : historique et inspiration biologique 

A la fin des années 90, la DARPA  (agence initiatrice du développement d’Internet) développe une des premières implémentations du concept de « self-management » au sein de son projet militaire SAS  . Le but était de créer un réseau de petits équipements que portent les soldats sur le terrain pour transmettre des informations sous forme de texte ou de petits messages vocaux. La particularité de ces équipements est leur capacité de pouvoir se configurer et de se reconfigurer automatiquement en cours de fonctionnement. Les paramètres modifiables sont par exemple le débit de transmission, la fréquence de la porteuse du signal émis, qui sont adaptés en fonction de l’environnement (bas débit et basse fréquence pour les grandes distances, haute fréquence et haut débit pour les courtes distances). Chaque équipement communique avec ses voisins qui retransmet à son tour l’information aux voisins suivants. Les équipements sont aussi capables de se reconfigurer en cas de brouillage du signal par des ennemis, ainsi que pour minimiser l’interception d’information. Cette reconfiguration dynamique en fonction de l’environnement et du maillage formé par les voisins relève de plusieurs problématiques [6] comme le routage adaptatif multi-sauts (pour n’envoyer les données qu’aux voisins les plus proches), le facteur d’échelle (pour gérer jusqu’à 10000 équipements sur le terrain), les contraintes temporelles (pas plus de 200ms pour l’adaptation dynamique et le début de la transmission du message avec le risque de perdre le début du message).

Au début des années 2000, la DARPA se penche ensuite sur une approche architecturale nommée DASADA  [7] qui introduit systématiquement des sondes spécialisées renvoyant des informations sur l’environnement. Ces informations sont ensuite utilisées pour la reconfiguration dynamique et automatique en cours d’exécution. C’est en 2003 que Kephart expose une vision pour l’informatique autonomique dans son article fondateur « A vision for autonomic computing » [4]. Il s’inspire d’une métaphore biologique du système nerveux humain qui permet à chacun de faire des efforts cognitifs, physiques ou de prendre des décisions sans avoir à se soucier du calcul du rythme cardiaque, de la pression sanguine ou de la quantité d’adrénaline à produire. En transposant délibérément le mot « autonomique » utilisé dans le domaine de la biologie vers le domaine informatique, il affirme que ces futurs systèmes informatiques autonomiques agiraient et réagiraient de même, permettant aux utilisateurs et aux administrateurs de se focaliser sur des problématiques de plus haut niveau. Kephart s’inspire aussi de la conviction exprimée il y a presque un siècle par le grand mathématicien Alfred North Whitehead qui déclarait « La civilisation progresse par l’automatisation croissante des tâches et fonctions ce qui permet de libérer l’homme qui peut ainsi consacrer de plus en plus de temps à la réflexion théorique et conceptuelle ».

La gestion autonomique

Le but de l’informatique autonomique est de surpasser la complexité des systèmes logiciels et matériels utilisés dans l’informatique d’aujourd’hui et de demain en leur procurant des capacités d’auto-gestion  . Nous pouvons soulever à nouveau le paradoxe de la complexité des systèmes : pour arriver à intégrer des capacités d’auto-gestion, le système global a besoin de devenir encore plus complexe. Ce point n’est pas négligeable car très souvent, une complexification du système est encore synonyme de plus de problèmes et plus de maintenance. Cette complexification peut donc rebuter au premier abord. C’est au domaine de recherche en autonomic computing de convaincre de la nécessité d’une complexification et de démontrer l’efficacité finalement apportée au système global.

Paul Horn définit les « 7 commandements » d’un système informatique autonomique dans son manifesto de l’autonomic computing [1] :

1. Apprendre à se connaître lui-même – Une parfaite connaissance de soi et de son environnement implique, pour un système informatique autonomique, que chacun de ses éléments indique son état et ses performances à un « organe » de supervision. Aussi, le système autonomique a besoin de connaître ses capacités ultimes ou d’être en mesure de les identifier ou de les calculer. Il doit aussi connaitre les systèmes auxquels il est relié et éventuellement pouvoir fusionner avec eux ou se séparer en plusieurs petits sous-systèmes en cas de besoin.

2. Détecter les pannes et les éviter – Si une panne survient dans le système, il faut qu’elle soit détectée. L’élément perturbateur doit alors être isolé et ses tâches en cours déportées automatiquement vers un autre système. L’idéal restera que le système puisse prévoir la panne et apporter des actions en prévention.

3. Réparer les pannes et les erreurs commises – Puisque les pannes et les erreurs humaines ne pourront jamais être totalement évitées, des mécanismes de réparation sont essentiels et doivent être intégrés au système. Un mécanisme d’annulation ou de retour dans un état de fonctionnement doit exister pour contrer n’importe quel fonctionnement anormal.

4. Garder la maîtrise des données – Si un ordinateur tombe en panne, ses disques durs ne seront plus accessibles. Les données doivent donc être conservées indépendamment des machines qui les traitent et être partagées entre tous les éléments le constituant.

5. S’optimiser en s’auto-éduquant – L’ordinateur doit apprendre à optimiser de luimême le fonctionnement du système d’exploitation ou d’une base de données, à rechercher une meilleure voie de communication et, au mieux, à tirer parti de ses propres erreurs.

6. Comprendre les intentions des humains – Autonomes, autonomiques ou pas, les machines travaillent quand même pour l’homme. Elles doivent comprendre nos intentions, dénicher l’information où qu’elle se trouve et la présenter différemment selon l’appareil utilisé.

7. L’informatique autonomique ne peut pas se concevoir et exister dans un environnement clos. Elle doit pouvoir évoluer dans un environnement ouvert, hétérogène et caractérisé par la multiplicité des normes et des protocoles informatiques. Il ne peut donc s’agir d’une solution propriétaire .

Table des matières

INTRODUCTION
1 Introduction
1.1 Motivation principale : la gestion de la complexité grandissante
1.1.1 Le compliqué, le complexe et le simple
1.1.2 Histoire de simplifications
1.1.3 La dualité simplicité – complexité
1.2 Problématiques soulevées par la thèse
1.2.1 Les défis de la complexité grandissante
1.2.2 Les objectifs de la thèse : l’auto-gestion – « Self-management »
1.2.3 L’auto-gestion – « Self-management »
1.2.4 Le besoin de généricité
1.3 Vue globale de la thèse
2 État de l’art
2.1 L’informatique autonomique ou « Autonomic Computing »
2.1.1 Automatique, Autonome et Autonomique
2.1.1.1 Différence entre automatique et autonome
2.1.1.2 Différence entre autonome et autonomique
2.1.2 La vision de l’informatique autonomique : historique et inspiration biologique
2.1.3 La gestion autonomique
2.2 La boucle de contrôle autonomique
2.2.1 La boucle MAPE-K
2.2.1.1 Le gestionnaire autonomique
2.2.1.2 L’observation ou « monitoring »
2.2.1.3 L’analyse
2.2.1.4 La planification
2.2.1.5 L’exécution
2.2.1.6 La base de connaissances
2.3 Contexte de l’étude et définitions
2.3.1 Grappes de machines ou « Clusters »
2.3.2 Grilles informatiques
2.3.3 Centres de calcul et de traitement des données « Data centers » et nuages informatiques « clouds »
2.3.4 Réseaux de capteurs
2.3.4.1 Exemple : les SunSPOTs
2.3.5 L’intergiciel XSStreaMWare de gestion des réseaux de capteur
2.3.5.1 Présentation globale d’XSStreaMWare
2.3.5.2 Hiérarchie du modèle générique XSStreaMWare : le DATAMODEL
2.3.6 Les logiciels patrimoniaux existants
2.3.7 L’application DIET
2.3.8 Les applications de simulation électromagnétiques
2.3.8.1 Les sciences CEM : TLM et SCT
2.3.8.2 L’application YatPac
2.4 Positionnement par rapport à l’existant
2.4.1 Degré d’autonomicité et degré de généricité
2.4.2 Exemples d’approches existantes
2.4.2.1 Niveau 1 : Gestion intégrée spécifique à une application
2.4.2.2 Niveau 2 : Gestion appliquée à un domaine de compétences
2.4.2.3 Niveau 3 : Gestion générique par API avec modification des logiciels
2.4.2.4 Niveau 4 : Gestion générique sans modification des logiciels patrimoniaux
2.4.2.4.1 Le concept d’encapsulation, modèle à composants Fractal
2.4.2.4.2 DeployWare
2.4.2.4.3 Adage
2.4.2.4.4 JADE
2.5 Présentation du système pour l’intégration des contributions
2.5.1 Le système de gestion autonomique TUNe : Toulouse University Network
2.5.2 Les phases d’administration autonomique dans TUNe
2.5.3 Vocabulaire du triangle TUNe et fonctionnement global
2.5.4 Etapes de construction d’une gestion autonomique avec TUNe
2.5.4.1 1ère étape : description de l’infrastructure matérielle
2.5.4.2 2ème étape : description de l’infrastructure logicielle
2.5.4.3 3ème étape : définition de l’encapsulation des logiciels
2.5.4.4 4ème étape : définition des règles de configuration
2.5.4.5 Vue globale de la construction d’une gestion autonomique avec TUNe
2.5.4.6 Introduction d’une dénomination
2.6 Etat de l’art : synthèse
3 Auto-guérison – « Self-healing »
3.1 Introduction
3.2 Méta-modélisation des diagrammes de spécification de politiques de gestion – « Policy Description Diagrams » (PDD)
3.2.1 Forme MOF « Meta-Object Facility » et forme EBNF « étendue de Backus-Naur »
3.2.2 Méta-modèle des PDD
3.2.2.1 Méta-modèle de la partie graphique sous forme MOF
3.2.2.1.1 Le stéréotype Action
3.2.2.1.2 Le stéréotype Control
3.2.2.2 Méta-modéle de la partie syntaxique sous forme EBNF
3.3 Validation
3.3.1 Description des expériences
3.3.1.1 Cadre matériel de l’expérience
3.3.1.2 Cadre logiciel de l’expérience
3.3.1.2.1 Expérience sans agrégation des événements
3.3.1.2.2 Expérience avec agrégation des événements
3.3.2 PDD utilisés pour les expériences
3.3.2.1 PDD utilisés pour la phase de démarrage
3.3.2.2 PDD utilisés pour les reconfigurations durant la phase de gestion
3.3.2.2.1 PDD pour le « self-healing » des LA
3.3.2.2.2 PDD pour le « self-healing » des SEDs
3.3.2.3 Temps de réparation du cluster
3.4 Conclusion
4 Auto-configuration – « Self-configuring »
CONCLUSION

Lire le rapport complet