Soutenance mémoire
Niveau système
Au niveau système, on s’intéresse principalement à la gestion des ressources systèmes physiques et logicielles (Cf. Page.26) : on vérifiepar exemple, la disponibilité des ressources physiques car souvent la dégradation de la QoS (e.gtemps de réponse très élevé) est due à des ressources systèmes insuffisantes. L’intérêt du framework que nous proposons est d’aider à la mesure de l’utilisation des ressources systèmes et d’identifier celles qui causent les goulots d’étranglement. Car l’erreur à éviter est d’augmenter inutilement des ressources qui ne sont pas, à la base, responsables des dégradations des performances.
Autre aspect à considérer dans la gestion de la QoSest le choix du système d’exploitation. Une application n’offre pas les mêmes performances si elle est déployée sur un système Linux ou sur un système Windows car la gestion des ressources logicielles (Thread, processus, etc.) n’est pas du tout la même. En effet, Linux crée des « processus » plus rapidement que Windows 2000 par exemple, mais ordonnance « Schedule » moins vite les « threads » d’un même « processus ».
Linux aura donc un fort avantage dans les cas où l’on doit créer et détruire beaucoup de threads ou processus, et ceci très fréquemment (typiquementun serveur web avec des scripts CGI créant un processus à chaque requête), mais sera contre performant dans un système où on utilise beaucoup de threads créés une fois pour toute (ex :base de données ou serveur web moderne ne créant pas de processus supplémentaire pour exécuter un script).
Concepts de l’évaluation des performances systèmes
Dans ce paragraphe nous nous intéressons au critèrede la performance d’un système. Cet aspect de la QoS est important car il met en jeu plusieursfacteurs et métriques nécessaires pour son évaluation.
Définitions
Performance
Du point de vue de l’utilisateur, une application distribuée est performante si elle assure un temps d’exécution raisonnable suite à la sollicitation d’un client. Ce temps dépend d’une part des capacités de calcul et de communication des machines (sites du réseau) et d’autres part des canaux de communication logiciels (Intergiciels) et de la qualité de l’application (Cf. 1.2 Gestion de la QoS).
Ressource système
Une ressource système est une entité physique/matérielle (i.e., mémoire, processeur, disques, etc.) ou logicielle/conceptuelle (i.e., fichier, thread, file d’attente, etc.) qui participe à l’exécution d’une application et dont les services sont décrits par des caractéristiques quantitatives. L’étude des ressources systèmes utilisées par une application peut se faire à une granularité plus ou moins importante selon les besoins. Par exemple, l’étude de la mémoire consommée peut couvrir la mémoire vive réellement disponible, la mémoire mise en cache et la mémoire bufférisée. La commande « free –m » sous l’environnement Linux fournit ce genred’information (Cf. Figure 2).
Performance de la plate-forme de supervision
Nous définissons la performance d’un outil de supervision comme étant sa capacité à collecter et traiter des informations sans perturber ou modifier le comportement du système observé. En général, cette condition peut être atteinte de deuxfaçons :
En minimisant « l’intrusivité » des sondes,
En réduisant la masse d’information que l’outil doit gérer tout au long du processus de supervision
Intrusivité des sondes
Définition
« L’intrusivité » dérive du mot intrusion qui veut dire « l’occurrence d’un processus ou d’un événement qui ne fait pas partie du contexte d’exéc ution d’une tâche mais qui interfère dans sa réalisation » [Ramchurn, et al.’04]. [Mansouri-Samani.’95] définit l’intrusivité d’un système de supervision par : « Intrusiveness or the probe effect is the effect t hat monitoring may have on the behaviour of the monitored system, and results from the monitoring system sharing resources with the observed system (e.g., processing power, communication chann els, storage space)……Monitoring may affect the behaviour of the system under observatio n. This is particularly true when the application references external state or its behavi our is affected by race conditions. In general this intrusion or interference is undesirable and m ust be reduced or, when possible, completely eliminated. This can be achieved through suitable i nstrumentation techniques » .
Cette définition souligne que l’intrusivité est causée par l’interférence avec le système observé.
Cette interférence peut s’opérer à deux niveaux : d’un côté le partage des ressources système (CPU, mémoire, etc.) et de l’autre côté le partage des ressources réseaux (bande passante). Ces deux facettes de l’intrusivité doivent être évaluées pour caractériser globalement l’intrusivité d’une sonde.
Intrusivité au niveau des ressources réseaux
[Goutelle and Primet.’03] définit globalement le degré d’intrusivité d’une technique de mesure comme étant la capacité à réaliser la mesure en générant le minimum de trafic supplémentaire. Cette définition, plutôt générale, met l’accent surle volume du trafic généré par les sondes pour caractériser son intrusivité. On peut définir alorsmathématiquement l’intrusivité par la formule donnée dans (Équation 1).
Filtrage à la présentation
Ce type de filtrage permet à l’utilisateur d’afficher uniquement les informations qui l’intéressent parmi celles stockées. En pratique, l’utilisateur dispose d’un formulaire pour sélectionner les types d’informations et les critères associés. Implicitement, cela déclenche une suite de requêtes vers le médium de stockage (ex système de base de données) qui vérifie la disponibilité desinformations demandées et qui renvoie le résultat.
Synthèse
Mesurer les performances d’une application est essentiel pour mieux comprendre sa dynamique et anticiper les évolutions et les optimisations. Cependant, la réalisation de cette activité nécessite des outils utilisant des techniques de collecte qui soient peu-intrusives. Cette intrusivité peut être coûteuse en terme de consommation des ressources systèmes et peut perturber le comportement de l’application ou du système supervisé. De plus, la réduction de la masse d’information peut s’avérer très utile pour augmenter l’efficacité de l’activité de la supervision et faciliter le diagnostic. Le filtrageet l’ajustement de la fréquence de collecte sont des mécanismes parmi d’autres qui permettent cette réduction.
Outre l’aspect intrusivité, la possibilité de fournir un environnement commun où des sondes hétérogènes peuvent fonctionner ensemble nous semble très utile pour la supervision. Dans la suite, nous exposons l’intérêt de cette caractéristique et nous présentons quelques techniques quifacilitent cette intégration.
L’intégration des sondes hétérogènes
Introduction
Les systèmes actuels sont construits par intégration de composants existants. Il en résulte des architectures complexes (hétérogènes, distribuées, etc.). D’une part, la contrainte d’hétérogénéité peut prendre plusieurs formes : hétérogénéité de l’environnement d’exécution (Linux, Windows, etc.) et hétérogénéité des formatsde données manipulées (XML, formats non standardisés, etc.). La supervision de tels systèmes nécessite parfois de combiner plusieurs outils de mesure. Cela pose cependant un problème d’interopérabilité entre les résultats générés par ces outils; ces résultats peuvent être générés dans des formats différents (XML, CSV, etc.) et nécessitent d’abord d’être uniformisés avant de les exploiter. D’autre part, mesurer les performances d’un système distribué nécessite de placer des sondes sur les différentes parties de ce système. L’horodatage des informations collectées est indispensable à la supervision parce qu’il permet de savoir à quel moment la mesure a été effectuée. Le problème qui peut se poser à ce stade est celui de la synchronisation des informations.
Dans cette partie, nous dressons un état de l’art des techniques utilisées pour uniformiser les formats de données et celles utilisées pour les synchroniser.
Standard SNMP
Principe
SNMP est un protocole d’administration de réseau qui se veut simple dans son utilisation. Son concept lui permet de gérer aussi bien des informations applicatives que des informations liées à l’utilisation des ressources systèmes (processeur, mémoire, charge des interfaces réseaux, etc.).
Afin de pouvoir l’utiliser, il est nécessaire que les éléments à superviser soient équipés d’un agent SNMP. L’information qu’on pourra recueillir dans un agent SNMP se trouve regroupée dans la MIB que nous présentons dans le paragraphe suivant. Ceprotocole étant basé sur un modèle Client/Serveur (Cf. Figure 13), la station d’administration émet un paquet UDP représentant une requête SNMP à destination de l’équipement à superviser. L’agent, qui met à jour régulièrement sa table MIB, retourne dans un paquet UDP vers la station d’administration, les valeurs des variables SNMP demandées.
Discussion
Le protocole SNMP, comme l’acronyme l’indique, est simple et c’est d’ailleurs l’une des raisons de sa popularité. De plus, il est adopté par de nombreux constructeurs des équipements réseaux comme l’outil incontournable pour superviser leurs équipements. Cependant, le mode de fonctionnement du protocole basé sur une communication synchrone (requête/réponse) est pénalisant en terme d’intrusivité au niveau du réseau car il est générateur de trafic. De plus, la fréquence de collecte doit être choisit en fonctiondu nombre des équipements supervisés ce qui constitue une limite pour un large passage à l’échelle.
Le standard SNMP est utilisé dans le cadre d’une supervision « online» et donc hérite des avantages et des inconvénients de ce type de supervision. La synchronisation est réalisée au niveau de la machine d’administration qui constitue d’ailleurs le point « chaud » de l’architecture d’une plate-forme de supervision utilisant SNMP.
Eclipse TPTP
Introduction
Eclipse est un environnement de développement intégré (IDE), ouvert et open source. Le projet a été lancé par IBM et largement utilisé grâce à son architecture basée sur les plug-ins.
Le projet Eclipse Test & Performance Tools Platform(TPTP), anciennement appelé Hyades, est un ensemble de plug-ins Eclipse développés en licence EPL . Il a été lancé en 2002, et est soutenu par des grands acteurs industriels tels queIntel, IBM, Computer Associates, Scapatech, etc.
Discussion
NAGIOS est un framework de supervision doté de mécanismes de notifications pour envoyer des messages dès qu’un comportement anormal est détecté. Son architecture est hiérarchique et nécessite le déploiement d’un démon sur chaque machine supervisée. Ce démon a la tâche d’exécuter périodiquement les sondes locales et d’envoyer les informations collectées vers le moteur d’exécution de NAGIOS.
La communication entre le démon NRPE et le moteur d’exécution est synchrone ce qui augmente le trafic échangé sur le réseau. De plus, l’architecture « pseudo »-fermée de NAGIOS ne permet par d’insérer des traitements supplémentaires entre la phase de collecte et la phase de présentation. De plus, il est difficile d’adapter NAGIOS pour qu’il puisse prendre en charge les informations collectées par des outils externes (i.e. résultats d’OpenSTA ). Malgré les limites du framework NAGIOS, son étude a permis d’identifier diverses techniques/scripts pour collecter les informations sur l’utilisation des ressources système et sur la charge du réseau.
LeWYS (Lewys is Watching Your System)
Présentation
Nous clôturons cet état de l’art avec un projet issu de la recherche académique sur les modèles de composants. LeWYS est une bibliothèque de sondes développées à l’aide du modèle FRACTAL (Cf. ANNEXE E). L’objectif de ce projet estde fournir un canevas générique pour construire des systèmes de supervision de tailles variables.
LeWYS est implémenté en java en utilisant les API Julia et s’appuie sur la bibliothèque DREAM (Cf. ANNEXE E) pour diffuser les informations collectées par les sondes. Cette bibliothèque s’intègre plus facilement dans LeWYS car tous les deux sont basés sur le même modèle de composant FRACTAL.
Synthèse
Le but de ce chapitre est de montrer le contexte technologique de la thèse, et en particulier les principaux standards et plates-formes de supervision. En plus du standard SNMP, nous avons étudié trois autres solutions qui nous semblent représentatives du reste et qui se distinguent par leurs architectures et leurs modes de fonctionnement. Ces solutions sont la plate-forme TPTP, le framework NAGIOS et la bibliothèque LeWYS.
A travers une étude comparative, nous exposons les principaux atouts et faiblesses des ces solutions et nous discutons la possibilité de répondre totalement ou partiellement aux trois exigences que nous avons fixé, à savoir : la faibleintrusivité, la possibilité d’intégrer des sondeshétérogènes et le découplage entre l’acquisition etla présentation des informations collectées.
La plate-forme TPTP fournit une solution globale aux diverses fonctionnalités allant du domaine du test jusqu’à l’activité de monitoring et de profiling des applications java. La fonctionnalité de monitoring, qui nous intéresse en particulier, est assurée par un ensemble d’agents capables de mesurer l’activité des systèmes Linux et Windows. Ses agents sont déployés sur la machine observée et communiquent avec le client (console Eclipse) à travers le contrôleur d’agent appelé « RAC » qui est aussi installé sur la même machine. Ce dernier, assure plusieurs tâches dont le filtrage et la miseen forme des informations collectées par les agents. Ces différentes tâches requièrent des ressources systèmes ce qui augmente l’intrusivité de cette solution. Les deux autres exigences semblent difficilement réalisables et en particulier l’intégration des informations hétérogènes. En effet, le monitoringdans TPTP ne propose pas de mécanisme pour importer des fichiers et même si on développe un agent pour le faire, il serait difficile de gérer l’horodatage des informations contenues dans ces fichiers.
Présentation des résultats
Au terme de la phase de traitement, la phase de présentation a pour objectif de permettre une exploitation facile des informations collectées. Généralement, les représentations graphiques sont les mieux adaptées pour avoir une vue de l’ensemble des résultats et faciliter la tâche de corrélation et de diagnostic.
Le module de présentation prend en entrée des fichiers homogènes qu’il analyse pour extraire les valeurs des métriques à représenter. Le format adopté pour les fichiers en sortie est le CSV (Comma-separated values) dans lequel les valeurs sont séparées par des virgules.
|
Table des matières
PARTIE 1 INTRODUCTION
A. Introduction
1. La performance des applications : un enjeu de taille
2. Les outils d’évaluation des performances
3. Plan du document
PARTIE 2 ETAT DE L’ART
B. Concepts de base de la qualité de service et de l’évaluation des performances
1. Qualité de service
1.1. Définitions
1.2. Gestion de la QoS
1.2.1. Composantes de la gestion de QoS
1.2.2. Niveaux d’intervention pour la gestion la QoS
1.2.3. Niveau réseau
1.2.4. Niveau système
1.2.5. Niveau intergiciel « middleware »
1.2.6. Niveau applicatif
1.3. Synthèse
2. Concepts de l’évaluation des performances systèmes
2.1. Définitions
2.2. Intérêts de l’évaluation des performances système
2.3. Les techniques d’évaluation des performances
3. Besoins de l’industrie
3.1. Performance de la plate-forme de supervision
3.1.1. Intrusivité des sondes
3.1.2. Masse d’information
3.1.3. Synthèse
3.2. L’intégration des sondes hétérogènes
3.2.1. Introduction
3.2.2. Contrainte d’hétérogénéité
3.2.3. Synthèse
3.3. Découplage entre la collecte et la présentation
3.3.1. Introduction
3.3.2. Intérêt du découplage
4. Conclusion
C. Outils et techniques de mesure des performances systèmes
1. Standard SNMP
1.1. Principe
1.2. MIB
1.3. Atouts et faiblesses du standard SNMP
1.4. Discussion
2. Eclipse TPTP
2.1. Introduction
2.2. Architecture de TPTP
2.3. Atouts et faiblesses de la plate-forme TPTP
2.4. Discussion
3. NAGIOS
3.1. Présentation
3.2. Architecture
3.3. Atouts et faiblesses de la plate-formeNAGIOS
3.4. Discussion
4. LeWYS (Lewys is Watching Your System)
4.1. Présentation
4.2. Architecture
4.3. Atouts et faiblesses de la bibliothèque LeWYS
4.4. Discussion
5. Synthèse
PARTIE 3 CONCEPTION & MISE EN OEUVRE
D. Conception.
1. Rappel de la problématique
2. Description du framework de supervision
2.1. Introduction
2.2. Architecture physique
2.3. Déroulement d’une supervision
2.4. Architecture logicielle de la plate-forme
2.5. Description des composants de la plate-forme
2.5.1. Les sondes
2.5.2. Moteur de traitement
3. Conclusion
E. Mise en oeuvre
1. Introduction
2. Implémentation d’une sonde
2.1. Sonde Vmstat
2.1.1. Description de la sonde
2.1.2. Implémentation
2.2. Autres exemples de sondes
3. Implémentation du moteur de traitement
3.1. L’analyseur « parseur »
3.2. Structuration des informations
3.3. Le module d’export « outputter »
3.4. Création de l’adaptateur
4. Fonctionnement de la plate-forme
4.1. Tâche de transfert des fichiers
4.2. Tâche de pilotage des sondes
4.3. Tâche de traitement des fichiers de résultat
4.4. Tâche de reporting
5. Conclusion
PARTIE 4 EXPERIMENTATIONS
F. Validation expérimentale
1. Description du contexte de l’expérimentation
1.1. Plate-forme expérimentale
1.2. Démarche expérimentale
2. Bilan de l’expérimentation
2.1. Intrusivité au niveau des ressources systèmes
2.1.1. Résultats
2.1.2. Analyses
2.2. Passage à l’échelle « scalability »
2.2.1. Conclusions
2.3. Intrusivité au niveau des ressources réseaux
2.3.1. Cas TPTP
2.3.2. Cas SNMP
2.3.3. Conclusion
2.3.4. Effet de l’intrusivité sur la bande passante
3. Conclusion générale
G. Cas d’utilisation de la plate-forme de supervision
1. Premier exemple : Test de montée en charge
1.1. Description de la plate-forme de test
1.2. Déroulement du test
1.3. Résultats et analyses
2. Deuxième exemple : plate-forme d’observation réactive
2.1. Description
2.2. Mise en œuvre
PARTIE 5 CONCLUSIONS & PERSPECTIVES
H. Conclusion et perspectives
1. Conclusion
2. Perspectives
PARTIE 6 ANNEXE
ANNEXE A. Network Time Protocol
ANNEXE B. Oids des ressources systèmes
ANNEXE C. TPTP (Test & Performance Tools Platform)
ANNEXE D. NAGIOS
ANNEXE E. FRACTAL & DREAM
ANNEXE F. Format CBE (Common Based Event)
ANNEXE G. Les métriques collectées par Vmstat
ANNEXE H. Performance d’une analyse statique Vs une analyse basée sur des règles
ANNEXE I. Simple Event Correlator
PARTIE 7 BIBLIOGRAPHIE
