I NTERIM R EPORT ON C OOPERATION

Transcription

1 I NTERIM R EPORT ON C OOPERATION WITH EGEE AND GEANT ON N ETWORK M ONITORING A CTIVITIES Document Filename: Activity: Partner(s): Lead Partner: Document classification: SA2 KTH, IMCS UL IMCS UL PUBLIC Abstract: This document provides a comparison between the network monitoring approaches deployed in EGEE, GEANT2 and BalticGrid-II respectively. It also gives an overview on the requirements for joining the global European monitoring infrastructures of the GEANT2 project - perfsonar and the EGEE project NPM. The lightweight Gridimon network monitoring approach developed and deployed within BalticGrid proves to be as efficient as more heavyweight perfsonar and NPM alternatives. PUBLIC Page 1 of 23

2 Released for moderation to Approved for delivery by Document review and moderation Name Partner Date Signature PMB All Oct 31, 2009 Document Log Version Date Summary of changes Author /10/2009 Plan and structure of the deliverable Katrina Sataki /10/2009 First draft Mārtiņš Lībiņš, Dana Ludviga, Edgars Znots /10/2009 Updates version Guntis Barzdins, Baiba Kaskina, Katrina Sataki /10/2009 Minor corrections after the review Tonu Raitviir, Katrina Sataki PUBLIC Page 2 of 23

3 Contents 1. INTRODUCTION PURPOSE APPLICATION AREA REFERENCES TERMINOLOGY NETWORK MONITORING IN GÈANT PERFSONAR Architecture Use cases Implementation NETWORK MONITORING IN EGEE REQUIREMENTS ARCHITECTURAL OVERVIEW Monitoring Frameworks NPM Services NPM Clients SIMILARITIES AND DIFFERENCES WITH BALTICGRID MONITORING POSSIBLE COOPERATION AND EXCHANGE OF BEST PRACTICES COMPARISON OF NETWORK MONITORING APPROACHES LINK UTILIZATION MONITORING IN GÈANT AND BALTICGRID-II CONNECTIVITY MONITORING IN GÈANT AND BALTICGRID CONCLUSIONS PUBLIC Page 3 of 23

4 1. INTRODUCTION 1.1. PURPOSE The purpose of this document is to provide a comparison between the network monitoring approaches deployed in EGEE, GEANT2 and BalticGrid-II. This document also gives an overview on the requirements for joining the global European monitoring infrastructures of the GEANT2 project - perfsonar and the EGEE project NPM and evaluates associated benefits/costs for BalticGrid, where the lightweight Gridimon network monitoring approach is already successfully deployed 1.2. APPLICATION AREA Network monitoring and network performance measurements REFERENCES [1] Brian Tierney, Jeff Boote, Eric Boyd, Aaron Brown, Maxim Grigoriev, Joe Metzger, Martin Swany, Matt Zekauskas, Yee-Ting Li, and Jason Zurawski, Instantiating a Global Network Measurement Framework [2] Jeliazkova, N., Iliev, L., Jeliazkov, V., PerfsonarUI - a Standalone Graphical User Interface for Querying perfsonar Services, jva, pp , [3] Andreas Hanemann1, Athanassios Liakopoulos2, Maurizio Molina3, D. Martin Swany4 A Study on Network Performance Metrics and their Composition [4] Network Performance Monitoring in EGEE LBNL Technical Report LBNL-1452E, January In Proceedings of the IEEE John Vincent Atanasoff 2006 International Symposium on Modern Computing (JVA'06), 2006, download PRE-EDMSnumber-Terena v1-1.ppt 1.4. TERMINOLOGY ACRONYMS EXPLANATION AS Authentication service CNCC Central Network Coordination Centre DT Diagnostic Tool EGEE Enabling Grids for E-sciencE GÈANT European Academic Network LS Lookup Service MA Measurement Archive MP Measurement Point NNCC National Network Coordination Centre PUBLIC Page 4 of 23

5 NOC NPM NREN PCP PERT PoP RP TrS TS WS XML Network Operations Centre Network Performance Monitoring National Research and Education Network Probes Control Protocol Performance Enhancement and Response Team Point of Presence Resource Protector Transformation service Topology Service Web Service extensible Markup Language PUBLIC Page 5 of 23

6 2. NETWORK MONITORING IN GÈANT3 There is a vast variety of network monitoring and management tools created by different commercial vendors and available on the market. However, these tools are designed for network providers internal use only, hence are not tailored for multi-domain environments. In order to provide users with reliable and consistent performance monitoring data from multiple networks, GÈANT2's 1 Performance Measurement and Monitoring joint research activity group (JRA1), in collaboration with Internet2, Esnet, RNP, University of Delaware and 16 European NRENs developed a network monitoring facility perfsonar ( Performance focused Service Oriented Network monitoring ARchitecture ). More information is available at The aim of the perfsonar project is to create a framework for performing multi-domain measurements in the European Research Network GÈANT and the connected NRENs PERFSONAR The perfsonar system is a framework that enables network performance information to be gathered and exchanged in a multi-domain, federated manner. The goal of perfsonar is to enable ubiquitous gathering and sharing of this performance information in order to ease management of advanced networks, facilitate crossdomain troubleshooting and to allow next-generation applications to tailor their execution to the state of the network. This system has been designed to accommodate easy extensibility for new network metrics and to facilitate the automatic processing of these metrics as much as possible. [1] Architecture The perfsonar architecture is composed of three layers (see Fig. 1). The Measurement Points (MP) are the lowest layer in the system, performing active or passive measurements and storing network characteristics. The Measurement Point Layer of a domain consists of different monitoring components or agents, deployed within its boundaries. A monitoring agent provides information on a specific metric (e.g., one-way delay, jitter, loss, available bandwidth) by accessing the corresponding Measurement Points. Each network domain can, in principle, deploy Measurement Points of its choice. [2] The MP is wrapped into a higher level abstraction called Measurement Point Service, belonging to the Service Layer, which hides the implementation details of the MP. The Service Layer is the middle layer of the system and consists of separate administrative domains. It allows exchange of measurement data and management information between those domains. In each domain, a set of entities (services) is responsible for the domain control. Each of them is in charge of a specific functionality, like authentication and authorisation, discovery of the other entities providing specific functionalities, resource management, or measurement of network traffic parameters. In particular, the Measurement Archive (MA) Service is designed as a repository for measurement results. The interaction of the entities inside a domain as well as the access to the Measurement Point Layer or other domains may not be visible to the end user. Some of the entities contain an interface which can be accessed by the User Interface Layer. [2] 1 GÈANT2 network built and operated by the previous EU project ended in Network of the current project started after the end of the previous project is called GÈANT3 PUBLIC Page 6 of 23

7 The User Interface Layer consists of visualization tools (user interfaces), which adapt the presentation of performance data to be appropriate for the needs of specific user groups. In addition, they may allow users to perform tests, using the lower layers of the framework. [2] The whole architecture is based on Web Services (WS) technology, which allows defining the interaction between services through well defined, language independent interfaces. Web Services are closely tied to the extensible Markup Language (XML). PerfSONAR uses and extends a schema defined by the Global Grid Forum s Network Measurement Working Group. This schema defines an extensible message and storage format for network measurements. The perfsonar approach removes any dependencies from the lower networking technologies and permits new services to be easily added. The following services have been defined in the perfsonar framework: [3] Measurement Point (MP) service: performs the measurements and forwards data to other services Measurement Archive (MA) service: stores the measurement data Lookup service (LS): registers information regarding active services and their capabilities Topology service (TS): stores network topology information Authentication service (AS): provides authentication and authorisation services required in users services interactions Transformation service (TrS): performs manipulation (aggregation, statistics) on available data sets Resource Protector (RP) service: arbitrates the use of limited measurement resources Fig. 1 The PerfSONAR Service Oriented Architecture for multi-domain network monitoring [3] The aim of the above illustrated perfsonar s design is to provide all the main functionalities at Service Layer as independent entities, thus allowing increased flexibility for the system. Very easily the existing elements can be replaced or even new ones inserted. If the number of entities is large, they can be identified, invoked using discovery functionalities. PUBLIC Page 7 of 23

8 Use cases PerfSONAR is aiming to support a number of higher-level services and user groups: the members of NOCs (Network Operations Centers) and PERTs (Performance Enhancement and Response Teams); the international project (with demanding network performance requirements), such as LHC, EGEE and DEISA participants; the administrative network staff (engineers) - that could use perfsonar to help automate the detection of large bulk data flows that may require special handling, such as tagging the flow as high or low-priority, depending on its source or destination; the end user (Network researchers) - that can find perfsonar-enabled networks a convenient source of performance and topology information; the data transfer middleware - that could use perfsonar to locate the best replica/copy of a file to request, or to help determine the optimal network protocol to use for a given link. PerfSONAR is also targeting a wide range of use cases, for example: latency data collection and publication; achievable bandwidth result collection and publication; publication of utilization and network topology data; diagnosing performance and other issues. However perfsonar is designed to be flexible enough to handle also new metrics from technologies such as middleware or host monitoring Implementation PerfSONAR framework is widely used in the GÉANT network. BalticGrid-II SA2 activity was considering joining the perfsonar monitoring infrastructure to complement the existing BalticGrid- II monitoring solution. The first step was to analyse the perfsonar framework. Results of the analysis are described in the previous chapters. It was decided to try out the implementation of perfsonar. Version 3.1 was tested as it is partially supported on CentOS and Ubuntu. Although installation was performed according to official documentation installation of the perfsonar MDM 3.1 distribution on CentOS did not succeed due to RPM package dependency problems. Fewer problems were faced using Ubuntu 8.10 for deployment; however, the "oppd-mp-bwctl" component couldn't be installed because of some circular package dependency problem that couldn't be resolved. Therefore it wasn't possible to use bwctl bandwidth measurement tests within the test setup. PUBLIC Page 8 of 23

9 Fig. 2 Implemented perfsonar test setup The tests of PerfSONAR show no exceptional advantages over the Gridimon tool used by the BalticGrid-II project team ( Tests showed that perfsonar requires dedicated hardware and a lot of time and expertise to deploy. Gridimon is used for network link congestion and throughput monitoring for the whole BalticGrid network infrastructure. For link throughput testing between clusters Iperf in combination with standard glite job submission facilities can be used. Considering the needs of the BalticGrid-II monitoring infrastructure, several perfsonar advantages were recognized as well as some drawbacks. PerfSONAR advantages: Disadvantages: host to host bandwidth measurement; host link usage information; network circuit throughput monitoring. necessary dedicated monitoring hardware at every major network hub; specific software demands, supported only on RedHat enterprise Linux and Debian, hard to install and maintain; perfsonarui is not user-friendly and still requires some tuning; incomprehensive documentation (only for supported Linux distributions). The overall conclusion was that for the BalticGrid-II monitoring infrastructure the existing solution is sufficient and perfsonar implementation requires a lot of resources which can not be justified with the potential gains. PUBLIC Page 9 of 23

10 3. NETWORK MONITORING IN EGEE EGEE has developed Network Performance Monitoring (NPM) services that use Service Oriented Architecture (SOA) to provide network monitoring data through web services. Such NPM architecture allows to use various network monitoring technologies in the underlying layer and share data between them using XML schema defined by the Global Grid Forum s Network Measurement Working Group. Such approach allows data to be used by several types of clients: grid middleware, grid operation centres, network operation centres and grid users. The most common network monitoring tools used for producing monitoring data are perfsonar, E2EMONIT, Perfmonit and PiPES. EGEE NPM also includes PCP framework for coordinating and scheduling execution of measurements. Also, a Diagnostic Tool (DT) is used to allow grid users, NOC and GOC to view monitoring data and trigger specific measurements REQUIREMENTS Due to heterogeneity and scale of EGEE infrastructure and resources network performance is crucial. Thus, a Network Performance Monitoring services have to provide multitude of ways for data collection and representation, various measurement types and be efficiently usable across many administrative domains and different user groups. The following table summarizes the EGEE NPM metric requirements: Metric / Info Relevant to group Middleware NOC GOC TCP Achievable Bandwidth Yes Yes Packet-loss Yes Yes Yes Round-trip time Yes Yes Yes Round-trip IPDV Yes Yes One-way delay Yes Yes One-way delay variation Available bandwidth (path) Available bandwidth (hop) Yes Yes Yes Yes Yes Packet reordering Yes Yes Hop/list network topology Yes Yes PUBLIC Page 10 of 23

11 Availability Yes Yes Path MTU Yes Yes QoS Class Yes Yes Service Level Agreement On-demand test on all metrics Yes Yes Yes Yes Table 1 EGEE NPM Metric Requirements [1] 3.2. ARCHITECTURAL OVERVIEW EGEE NPM is based on Service Oriented Architecture (SOA), network monitoring data is provided through web services. Such architecture easily copes with multiple measurement providers and clients that request measurement data. The NPM middleware consists of several components: NPM core services (NPM Mediator, NPM Discoverer), NPM clients (NPM Diagnostic Tool, NPM Publisher) and Monitoring Frameworks. Monitoring Framework can use any of several possible software solutions for producing measurement data, which is then passed to central gathering point the NPM Mediator by means of standardized XML schema (NM-WG). All NPM Clients can then query NPM Mediator to retrieve network measurement data. Fig. 3 EGEE NPM architecture overview [1] PUBLIC Page 11 of 23

12 Monitoring Frameworks Monitoring Framework is the component of NPM middleware that produces network performance monitoring data. Due to usage of NM-WG proposed XML schema, the data provided by Monitoring Framework can be passed further through standardized interface, which allows the use of any appropriate software in the underlying layer for actual measurements, providing there is appropriate wrapper for the gathered data to export it in the NM-WG standardized XML format. Most popular choices for actual data measurements in EGEE NPM are perfsonar, Perfmonit and PiPES for NREN and ISP level monitoring of network and E2EMONIT for site and end-to-end level monitoring, but any existing or new home-grown monitoring tool can be used as long as appropriate XML wrappers are produced. Two most notable solutions are perfsonar (described above) and E2EMONIT E2EMONIT E2EMONIT provides tools for the measurement of end-to-end network performance, therefore giving results that are directly relevant to end users of the network. Three active tools (PingER, Iperf and UDPmon) are used for the measurement of the most relevant metrics (RTT, TCP and UDP Throughput, UDP and ICMP Packet Loss) between defined sites on the network. / EGEE NPM, E2EMONIT homepage, / The notable feature of E2EMONIT is use of existing production quality open source tools like Iperf, UDPmon and PingER. This greatly increases usability of produced measurements, since there are many existing tools that can parse and process results from these tools. E2EMONIT can provide gathered results to NPM Mediator, as well as to RGMA for direct use by job brokering and workload management systems. Also E2EMONIT benefits greatly from portability of the used tools, since they are available and well tested on many Linux distributions and other UNIX-like systems. In contrast, perfsonar, although extensively using Java for intent to provide great portability, is very prone to Java library version dependency problems and other distribution specific dependencies. On the downside to plain tools that comprise E2EMONIT is the dependency of it on YAIM tool, as well as MON and R-GMA services, thus E2EMONIT cannot be deployed stand-alone, or used on other Linux distributions other than those supported by glite middleware NPM Services The core services of NPM middleware are NPM Mediator and NPM Discoverer. These services are using data provided by Monitoring Framework components and storing or passing the monitoring data to NPM client services. NPM Discoverer is responsible for discovering available network measurement producer instances, informing NPM Mediator about their availability and status. NPM Mediator is the single point of contact for all NPM client services and Monitoring Framework level data producers. It gathers monitoring data, and NPM client services send requests to NPM Mediator for specific monitoring data. This both simplifies the entire NPM architecture as well as imposes several limitations on it. For example, since the NPM Mediator is the single point of contact for everybody that uses the measurement data (NPM clients), it is also the single point of failure NPM Clients NPM Clients are services that send requests to NPM Mediator for specific measurement data. The main two NPM clients are NPM Diagnostic Tool (DT) and NPM Publisher. Diagnostic Tool is used PUBLIC Page 12 of 23

13 by grid users, NOC and GOC members to view monitoring and other measurement data to troubleshoot problems. NPM Publisher is used by resource brokering services like WMS. Fig. 4 NPM Diagnostic Tool [1] 3.3. SIMILARITIES AND DIFFERENCES WITH BALTICGRID MONITORING Currently there are several similarities between EGEE NPM and BalticGrid Network monitoring. Most notable is the use of open-source, time-proven and portable tools for gathering measurement data. In case of E2EMONIT EGEE NPM uses PingER, Iperf and UDPmon; meanwhile BalticGrid uses rping and Iperf. The differences are that EGEE NPM has chosen to use PUBLIC Page 13 of 23

14 several heavyweight or in-house developed solutions like perfsonar or E2EMONIT, and EGEE NPM services have several interdependencies in order for the monitoring data to propagate and take effect across the grid infrastructure. Crucial are the points that NPM has single point of contact (thus single point of failure) NPM Mediator. BalticGrid instead relies on integration of several independently developed and self-sustained tools. Also, BalticGrid network monitoring architecture does not have central point information like the NPM Mediator, thus the monitoring infrastructure really is distributed and fault tolerant, since unavailability of some service affects either only the specific site, or specific measurement type or its representation. Also, in BalticGrid the data from monitoring infrastructure does not have such critical effect on workload management system, thus there is no failure/error cascading effect in case some monitoring services fail to provide correct data to other grid services. The plain tools used in BalticGrid are more light-weight and portable across various Linux distributions and other UNIX-like systems, thus their adoption and maintenance requires significantly less effort POSSIBLE COOPERATION AND EXCHANGE OF BEST PRACTICES The best practices that can be exchanged between EGEE NPM and BalticGrid network monitoring is to keep using open-source production quality tools, as well as to try to create monitoring infrastructure in distributed and fault-tolerant manner. BalticGrid can benefit significantly from using EGEE experience in standardizing interfaces between data producers and data consumers, and using the information gathered by monitoring tools in other grid services. EGEE NPM can benefit from BalticGrid experience in integrating self-sustainable software and having fault tolerant monitoring infrastructure without single-points-of-failure. PUBLIC Page 14 of 23

15 4. COMPARISON OF NETWORK MONITORING APPROACHES In this chapter the similarities and differences of BalticGrid-II and GÈANT monitoring systems are shown. The gridimon.balticgrid.org is an openly accessible system, available to everyone, while stats.geant2.net requires a username and password provided by GÈANT. When comparing the manner of monitoring in GÈANT and BalticGrid-II there are similar methods and ways of collecting and representing the data of Link utilisation and connectivity LINK UTILIZATION MONITORING IN GÈANT AND BALTICGRID-II GÈANT provides a simple overview map that shows the utilization of the GÈANT link for each NREN. It is intended more like an overview tool and is not informative enough to be used like a continuous indicator. It is publicly available at Fig. 5 GÈANT2 Usage Map The GÈANT s most frequently used and most applicable monitoring system is the Taksometro GÉANT2. It is organised as a networking map of GÈANT infrastructure and provides long-term statistics of NREN access traffic for GÉANT2. It collects information from the GÈANT routers and represents a graph for each NREN. PUBLIC Page 15 of 23

16 Fig. 6 NREN access traffic monitoring Considering that all BalticGrid members belong to the GÈANT network, the structure of the BalticGrid monitoring portal is fairly similar. The main page gives an overview of network topology and allows easy access the necessary section. PUBLIC Page 16 of 23

17 Fig. 7 BalticGrid Network monitoring portal Gridimon The similarities of the GÈANT and the BalticGrid monitoring are represented by the statistics graphs of both systems. Both collect long-term statistics and the graphical pattern are very similar. GÈANT graph of the Latvian NREN SigmaNet: PUBLIC Page 17 of 23

18 Fig. 8 GÈANT graph of the Latvian NREN SigmaNet Gridimon.balticgrid.org graph of the Latvian NREN SigmaNet: Fig. 9 Gridimon.balticgrid.org graph of the Latvian NREN SigmaNet GÈANT graph of the Lithuanian NREN LITNET: PUBLIC Page 18 of 23

19 Fig. 10 GÈANT graph of the Lithuanian NREN LITNET Gridimon.balticgrid.org graph of the Lithuanian NREN LITNET: Fig. 11 Gridimon.balticgrid.org graph of the Lithuanian NREN LITNET GÈANT graph of the Estonian NREN EENet: PUBLIC Page 19 of 23

20 Fig. 12 GÈANT graph of the Estonian NREN EENet Gridimon.balticgrid.org graph of the Estonian NREN EENet: Fig. 13 Gridimon.balticgrid.org graph of Estonian NREN EENet The only exception is Belarus which does not have a direct access to GÈANT and is connected to it trough the Polish NREN Pionier. For this reason there are no long-term statistics for Belarus in the GÈANT monitoring system and its traffic is included in the total traffic graph of Pionier. GÈANT graph of the Polish NREN Pionier: PUBLIC Page 20 of 23

21 Fig. 14 GÈANT graph of the Polish NREN Pionier Whereas the the Gridimon provides long-term statistics for the Belarus NREN BASNET: Fig. 15 Gridimon.balticgrid.org graph of the Belarusian NREN BASNET 4.2. CONNECTIVITY MONITORING IN GÈANT AND BALTICGRID Besides the monitoring of link utilisation, BalticGrid-II monitors also the parameters of each link. It is done by graphical implementation of remote ping (rping). The result of periodic rping queries is represented graphically and provides easy overview and use of long-term statistics. It shows packet loss and delay of the link. PUBLIC Page 21 of 23

22 Fig. 16 Gridimon.balticgrid.org rping graph of the Latvian NREN SigmaNet connectivity to GÈANT GÈANT publicly provides Backbone Weathermap that allows seeing the current state of link, but is not usable for long term availability statistics. Map is showing the GÉANT PoPs, the circuits interconnecting them and other international circuits. The circuits are coloured according to their utilisation. Map can be found at Fig. 17 GÈANT Backbone Weathermap PUBLIC Page 22 of 23

23 5. CONCLUSIONS This document provided a comparison between the network monitoring approaches deployed in EGEE, GEANT2 and BalticGrid-II respectively. The requirements for joining the global European monitoring infrastructures of the GEANT2 project and the EGEE project have been studied. PerfSONAR framework is widely used in the GÉANT network. The analysis of the perfsonar framework and test installations was performed within the BalticGrid-II SA2 activity. The overall conclusion was that for the BalticGrid-II monitoring infrastructure the existing solution is sufficient. High requirements of perfsonar implementation can not be justified with the potential gains. It was concluded that BalticGrid-II can benefit significantly from using EGEE experience in standardizing interfaces between data producers and data consumers, and using the information gathered by monitoring tools in other grid services. EGEE NPM can benefit from BalticGrid experience in integrating self-sustainable software and having fault tolerant monitoring infrastructure without single-points-of-failure. The overall conclusion is that the lightweight next generation Gridimon network monitoring approach developed and deployed within BalticGrid proved to be as efficient for the scale of BalticGrid-II network as more heavyweight legacy perfsonar and NPM alternatives of GEANT2 and EGEE. PUBLIC Page 23 of 23