1 / 34

L E WYS : un Canevas Logiciel à Composants pour Construire des Applications de Supervision

L E WYS : un Canevas Logiciel à Composants pour Construire des Applications de Supervision. Emmanuel Cecchet*, Oussama Layaïda et Vivien Quéma INRIA Rhône-Alpes, projet SARDES *Emic Networks. Plan. Contexte et motivations LeWYS Architecture Mise en œuvre Conclusion. Internet. Contexte.

cuyler
Download Presentation

L E WYS : un Canevas Logiciel à Composants pour Construire des Applications de Supervision

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LEWYS : un Canevas Logiciel à Composants pour Construire des Applications de Supervision Emmanuel Cecchet*, Oussama Layaïda et Vivien Quéma INRIA Rhône-Alpes, projet SARDES *Emic Networks

  2. Plan • Contexte et motivations • LeWYS • Architecture • Mise en œuvre • Conclusion

  3. Internet Contexte • Applications J2EE sur grappe • But : construire des systèmes autonomes • Ajout/suppression dynamique de noeuds • Equilibrage de charge • Contrôle d’admission, etc. • Besoin : outils de supervision

  4. Motivations • Systèmes d’observation existants • Ad-hoc : RUBiS • Spécifiques à une plateforme ou à un domaine précis • Pas réutilisables dans de nouveaux contextes • Génériques : • Supervision de ressources dans les grappes et grilles : Ganglia, NWS, JAMM, etc. • Peu flexibles • Nature des données collectées • Propagation des données • Traitement des données • Pas utilisables dans notre contexte

  5. Objectifs • Outils de supervision multi-plateformes • Flexible • Déploiement dynamique des entités d’observation • Construction des canaux de traitement et de propagation • Mode d’analyse des données • En ligne (console) • Hors ligne (stockage) • Intrusivité limitée • Conception à base de composants: (re)configurabilité

  6. Plan • Contexte et motivations • LeWYS • Architecture • Mise en œuvre • Conclusion

  7. Proposition : LeWYS • Canevas logiciel à composant pour la construction de systèmes d’observation • Bibliothèque de composants • Sondes • Canaux à événements • Observateurs (consommateurs d’événements) • Implantation en Fractal • Modèle de composants hiérarchiques et réflexifs • Outils de déploiement : ADL • Outils de contrôle : fractalexplorer

  8. Observation • Sondes (probes) permettant l’observation • Des ressources matérielles (CPU, mémoire, réseau, disque, etc.) • Du système (interruption, processus, etc.) • Des applications: JMX, JVMPI, SNMP, etc. • Etc. Nœuds 2 Nœuds 1 CPU probe Serveur MBean Disk probe JMX Probe Nœuds 3 Disk probe Kernel Probe Net probe

  9. Déploiement • Monitoring Pump sur chaque nœud • Déploiement dynamique des sondes nécessaires • Gestion des abonnements aux probes • Collecte et estampillage des observations Nœuds 2 Monitoring Pump Nœuds 1 pump thread CPU probe MBean Server Monitoring Pump Disk probe JMX Probe pump thread Nœuds 3 Disk probe Monitoring Pump pump thread Kernel probe Net probe

  10. Communications • Construction via des canaux Dream • Composants de communication: marshallers, TCP Socket, etc. • Composants de traitements: filtres, agrégateurs, etc. • Composition dynamique selon les besoins Monitoring Pump pump thread CPU probe MBean server Monitoring Pump Filtrage Disk probe JMX Probe pump thread DREAM Agrégation DREAM Disk probe Monitoring Pump pump thread Kernel probe Prétraitement DREAM DREAM Net probe

  11. Monitoring Pump Monitoring Pump pump thread pump thread CPU probe CPU probe Disk probe Net probe Observateurs (1) Stockage Boucle de contrôle …… Equilibrage de charge Observer MBean server Monitoring Pump JMX Probe pump thread DREAM DREAM Disk probe DREAM DREAM Observer

  12. Monitoring Pump Monitoring Pump pump thread pump thread CPU probe CPU probe Net probe Disk probe Observateurs (2) • Cas particulier : Entrepôt (Monitoring Repository) • Stockage des données pour analyse post-mortem • Parcours de l’historique • Corrélation entre événements Observer DREAM DREAM Monitoring Repository Query threads Storage thread Event subscribe service DREAM DREAM Observer Monitoring DB

  13. Plan • Contexte et motivations • LeWYS • Architecture • Mise en œuvre • Conclusion

  14. … JMX based probes cpu, mem, disk, net, kernel, …probes JVM probes … cpu, … probes SNMP, ad-hoc, … probes JNI JNI JNI JMX JVMPI C C C .DLL /proc JVM Linux Linux Solaris Windows Linux Linux Solaris Windows Hardware resources Hardware resources Implémentation : sondes • Sondes matérielles: Windows, Linux, et Solaris • Sondes logicielles: JMX, (JVMPI, SNMP, etc.) • Chaque sonde réifie différentes ressources • CPU : nice, idle, user, kernel

  15. Performances Sondes Linux • Pentium IV 1.8GHz, 512 MB RAM, 40 GB IDE disk (6 partitions), Linux 2.4.20 • 150µs pour collecter toutes les ressources

  16. Performances Sondes Windows • Pentium IV 2GHz, 512 MB RAM, 40 GB IDE disk (2 partitions), Windows 2000 • 16,57ms pour collecter toutes les ressources

  17. ProbeFactory Implémentation : Pompe Component ProbeManager Probe ProbeManager CachedProbe Cache Probe Probe Probe Repository Binding Controller MonitoringMumpManager Monitoring Pump Thread TimeStamp MonitoringPump Manager PullPush Multiplexer OutputManager RMI OutputManager ChannelOut Component

  18. Implémentation : Canaux à événements • Utilisation de Dream • Développement de filtres • Approximation sous forme de fonction linéaire par morceaux d’une séquence discrète de points (ti ,xi) • Réduction des données transmises : • Uniquement les segments successifs et non les points individuels • > 90% de données filtrées pour une précision de 10% • Overhead CPU quasi négligeable < 0,01%

  19. Conclusion • LeWYS • Canevas logiciel à composants pour construire des systèmes de supervision • Sondes efficaces implantées en Java • Canaux de communication arbitraires construits avec Dream • Projet ObjectWeb (http://lewys.objectweb.org) • Travaux futurs • Développement de sondes (JVMPI, SNMP) • Intégration avec CLIF • Utilisation pour la construction de boucles de contrôle pour serveurs J2EE en grappe • Développement d’algorithmes publish/subscribe adaptés aux hypothèses des clusters

  20. Questions ?

  21. Bonus slides

  22. LeWYS design choices • Component-based framework • probes, monitoring pump, event channels • provides (re)configurability capabilities • Minimize intrusiveness on monitored nodes • No global clock • timestamp generated locally by pump • Information processing in DREAM channels

  23. Centralized monitoring using a monitoring repository (2) • Monitoring repository • stores monitoring information • service to retrieve monitoring information • Pros • DB allows for storing large amount of data • powerful queries • correlate data from various probes at different locations • resynchronize clocks • browsing history to diagnose failures • use history for system provisioning • Cons • requires a DB (heavy weight solution)

  24. Perfmon Custom App 1 Custom App 2 Performance monitoring applications Network Enum, select, query, etc. PDH LeWYS RegQueryValueEx HKEY_PERFORMANCE_DATA Performance monitoring interfaces Registry Interface PerfLib Disk Service 1 Performance Extension Components Performance monitoring components System Performance Components Network Service 2 Memory Service 3 Processor Service 3 Windows hardware probes

  25. JMX probes • collect monitoring information about software applications running in J2EE environments • client-server architecture • instrumented applications (MBeans) • JMX client • generic JMX probe • JMX client that accesses all MBeans • standard RMI connector • specific probes • subset of relevant MBeans

  26. Cartography probe • Reify resources available in a Linux node • hardware: cpu, mem, disk, net, pci, … • software: rpm, kernels • network connections • Reify network topology • matches switch/router information (SNMP) with node information

  27. Linux vs Windows • Windows probes are less efficient that Linux ones • JNI calls • registry access • some Windows performance components requires a lot of processing and memory • whole data requires 95kB of memory

  28. Related work • WatchTower • Windows using PDH  less efficient • JMX monitoring service • Less general (string, counter, gauge monitors) • Ganglia • No J2EE probes available • Less flexible communication channels (centralized) • Not online-oriented • Xampler • Complementary

  29. Cache filter • if value is the same as the previous one, it is filtered • precision width is tunable • probe and observer must be aware of sampling interval

  30. Linear filter • data points around a line segment

  31. Swing filter • don’t use just the first 2 points to define the approximating line • dynamically compute optimal orientation

  32. Slide filter • allow disconnected line segments • chooses optimal start point and line orientation

  33. Filters overhead • processing overhead between 0.001% and 0.007% of cpu time • slide filter is O(n) because it needs to keep data points

  34. Online filters performance • Preliminary results • Up to 99.75% of data points filtered                                    10% precision        20% precision Cache                                 4.25%                  3.44% Linear                                  5.72%                  5.31% Non-optimized Swing          1.00%                  0.40% Optimized Swing                  0.88%                  0.39% Non-optimized Slide             0.68%                  0.29% Optimized Slide                    0.55%                  0.24%

More Related