Conception de notre plateforme de gestion de connaissances

Conception de notre plateforme de gestion de connaissances

Conception de la plateforme

De nombreuses plateformes autonomes ont été développées et comportent des outils et des modules mis à la disposition des administrateurs et des développeurs pour être utilisés et déployés dans un réseau de manière à rendre celui-ci autonome (au sens du concept self-*) (cf. section 1.6.3). Néanmoins, elles ont des visions différentes de la gestion des connaissances (cf. section 1.7.3.4). Le travail décrit ici s’inscrit dans le cadre du projet Européen 1 CELTIC IPNQSIS (IP Network monitoring for Quality of Service Intelligent Support) 2 . L’objectif de ce projet est de développer des systèmes de surveillance continue des performances du réseau et des services et d’évaluer leur impact sur les utilisateurs finaux. Une innovation importante d’IPNQSIS est l’utilisation, en plus de la Qualité de service (QdS), de la Qualité d’Expérience (QdE) comme élément d’évaluation des services du réseau [Mellouk et al., 2013]. Afin de gérer les informations (paramètres de QdS, QdE, …) collectées à partir de sondes actives qui permettront de simuler le comportement des utilisateurs dans le cadre des applications qui leur sont adressées, nous avons proposé une nouvelle plateforme de gestion de connaissances. Cette plateforme que nous décrivons ci-dessous, nommée Autolay, est générique et sous licence libre.

Architecture générale

Figure 3.1 – Architecture générale de la plateforme de gestion de connaissances. La plateforme a été conçue sur la base de 3 composants essentiels (cf. fig. 3.1) : un composant chargé de la collecte des données, un autre responsable de la gestion des connaissances (c’est dans ce module que les données et les informations sont transformées en connaissances avant d’être stockées) et un dernier s’occupant de la dissémination des connaissances. Ces trois composants ne sont pas forcément dupliqués dans chacun des éléments du réseau. Comme l’architecture adoptée pour notre plateforme est hiérarchisée, seuls  les super noeuds (et par extension, les hyper noeuds) sont en charge de la gestion et de la dissémination des connaissances (cf. fig. 3.2). Les noeuds normaux se contentent quant à eux de collecter les données qui seront transformées ensuite en connaissances (cf. section 1.7.3.1). Figure 3.2 – Modélisation UML la plateforme de gestion et de dissémination des connaissances. Nous détaillons dans la suite chacun de ses trois composants. 3.2.2 Collecte des données La collecte des données constitue la tâche la plus élémentaire pour une plateforme de gestion de connaissances. Il s’agit de monitorer un certain nombre de métriques de performance, en utilisant des capteurs actifs ou des capteurs passifs, dans le but de connaître l’état de chaque élément du réseau à un instant donné. Dans le cadre de ces travaux de thèse, nous avons réalisé un  ensemble de modules de collecte (cf. figure 3.3). Cet ensemble est bien évidemment évolutif en fonction du contexte d’utilisation et des besoins spécifiques de l’application. Nous nous sommes intéressés à trois d’entre eux : le taux de perte, la mesure du délai aller retour et la bande passante résiduelle. Figure 3.3 – Modélisation UML du composant de collecte des données Ces modules de collecte se basent sur des mesures actives. Les mesures des taux de perte et des délais aller-retour consistent à envoyer des requêtes de type demande/réponse (de type de celles utilisées par le protocole ICMP 3 ) et d’en déduire ensuite les valeurs associées à ces deux métriques. La mesure de la bande passante consiste à générer un trafic important entre deux points du réseau (par le biais de l’outil iperf 4 ) afin d’évaluer la bande passante résiduelle du lien qui les relie. Les données récoltées sont ensuite transmises au composant de gestion des connaissances.

Gestion des connaissances

L’une des caractéristiques les plus importantes de notre plateforme est la séparation des connaissances en différentes instances de la base de connaissances. Ainsi, nous pouvons constater, sur la figure 3.4, que la base de connaissance est abstraite. Chaque super noeud peut donc gérer un ensemble de bases de connaissances locales. Ces dernières sont relatives à une zone de propagation ou encore à un type d’application défini a priori. Dans le cadre de cette thèse, nous avons mis en place les trois bases de connaissances suivantes : 3. ICMP : Internet Control Message Protocol. 4. Iperf est développé par le National Laboratory for Applied Network Research  Figure 3.4 – Modélisation UML du composant de gestion de connaissances — Une base globale : utilisée pour gérer les connaissances interdomaines et, plus particulièrement, les connaissances nécessaires au maintien de l’architecture hiérarchique. — Une base de zone : utilisée pour gérer les connaissances d’une zone du réseau, la portée de la zone restant à prédéfinir. Dans notre cas, il s’agit d’une plage d’adresses IP. — Une base d’application générique : elle s’occupe de la gestion des connaissances correspondant à une application donnée. D’un point de vue technique, nos différentes bases sont gérées dans un système de gestion de base de données (SGBD) orienté document de type Not Only SQL (NoSQL 5 ). Chaque base de connaissances représente donc une collection de documents de type JavaScript Object Notation (JSON 6 ). L’intérêt de ce type de SGBD est double : — Il ne nécessite pas la spécification du schéma des données correspondant. Prenons l’exemple de la figure 3.5, le document n° 1 (correspondant au noeud 1) a une structure différente du document numéroté 2 (correspondant au noeud 2). Ils se différencient en effet par leur structure atomique ( “number of interfaces” dans un cas et “service” dans l’autre). — Toutes les versions d’un document peuvent être sauvegardées permetant ainsi de récupérer facilement des informations sur l’état antérieur du réseau.