1 / 24

GN2 Multidomain Monitoring Service: Serving IP NOCs

GN2 Multidomain Monitoring Service: Serving IP NOCs. Nicolas Simar, DANTE APM Meeting, Utrecht 24 th of November 2006. Agenda. Provide the general concepts of the Multi Domain Monitoring service. Set the scenes. You’ll use it soon! The Support that will be offered to you.

yahto
Download Presentation

GN2 Multidomain Monitoring Service: Serving IP NOCs

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. GN2 Multidomain Monitoring Service: Serving IP NOCs Nicolas Simar, DANTE APM Meeting, Utrecht 24th of November 2006

  2. Agenda • Provide the general concepts of the Multi Domain Monitoring service. • Set the scenes. • You’ll use it soon! • The Support that will be offered to you. • Demo the visualisations • Provide feedback • Explain the next steps and what your role will be: • Taking part to the Pilot and Prototype. • Using the tools. • What metric and services will be available – validate the first choice.

  3. What is JRA1? • JRA1 (Performance Measurement and Management) main objective is to build a multi-domain monitoring framework inter-operable across which is the basis to offer a Multi-Domain Monitoring (MDM) Service. • Consists of the following main parts: • Design and develop the framework (perfSONAR). • Integrate measurement tools and databases within the perfSONAR framework. • Build user visualisation tools using the perfSONAR framework. • There are about 25 participants (12.5 FTE), from 17 organisations. • Main partners are CARNet, CESNET, Cynet, Dante, DFN, NORDUnet, PSNC.

  4. perfSONAR philosophy

  5. What is perfSONAR? • perfSONAR is a consortium of organisationswho seek to build network performance middleware that is inter-operable across multiple networks. • perfSONAR is a protocol. • SOAP XML messages and following the Open Grid Forum (OGF) Network Measurement Working Group (NM-WG). • perfSONAR is, an example set of code (implementation of web-services using the perfSONAR protocol).

  6. PerfSONAR Web-Services • The framework takes care of the data movement. • It covers the following perfSONAR web-services • Auth Service (JRA5) • Autz Service • Lookup Service (LS) • Measurement Archives services (MA) • RRD MA, SQL MA, Hades MA • Measurement Point services (MP) • BWCTL MP, SSH/Telnet MP, CLI MP (I2), L2 status MP (JRA4) • Topology Service (TopS, cNIS – SA3). • Allows diversity on the measurement layer and on the visualization layer.

  7. perfSONAR philosophy

  8. Multi-Domain Monitoring Service (MDM) • User : role – group of people making use of a MDM Service. • There may be several categories of users having different needs. • An MDM service is an access to a set of metrics or functionalities offered to a group of users by several networks using the perfSONAR protocol. • An MDM service is offered by deploying on a set of perfSONAR web-services and/or visualisations. • E2E really means Edge to Edge, not End to End (unless end institutions buy into it).

  9. Multi-Domain Monitoring Service

  10. Multi-Domain Monitoring Service • Multi-Domain Monitoring Service • Access to a set of monitoring functionalities (e.g. accessing metric or performing tests) offered to a group of users accessible directly through an XML SOAP interface (perfSONAR protocol) or through a visualisation tools. • Based on an underlying set of perfSONAR web-services. • perfSONAR web-service • Web service (providing data or allowing to perform an action) using the XML NM-WG. The perfSONAR web-services are the basic building blocs of a MDM service.

  11. Demos • http://wiki.geant2.net/bin/view/JRA1/Jra1WorkingArea • perfsonarUI • http://wiki.perfsonar.net/jra1-wiki/index.php/PerfsonarUI • CNM • http://wiki.perfsonar.net/jra1-wiki/index.php/CNM • BWCTL MP • Any interest for a deployment? • Looking-glass • http://wiki.perfsonar.net/jra1-wiki/index.php/Looking_Glass • ABW • https://perfmon.cesnet.cz/abw-intro.html • Questions • perfsonar-user@perfsonar.net

  12. Demos - thanks • perfsonarUI • Vedrin Jeliazkov, Nina Jeliazkova (ISTF/ACAD) • CNM • Andreas Hanneman, David Schmitz (DFN) • BWCTL MP • Verena Venus, Stephan Kraft, Roland Karch (DFN) • Looking-glass • Stijn Verstichel (IBBT) • ABW • Sven Ubik (Cesnet) • And to all those providing the data…

  13. Users Segmentation

  14. MDM Service Benefits • For the NOCs • NRENs, EU RENs, GÉANT2 (Abilene(?), ESnet(?), RNP(?), etc). • In DJ1.1.1 • NOCs encounter 5-10% of the problems involving coordination of between multiple domains. • E2E services/IP packets don’t stop at the boundaries of a domain. • To have an E2E view. • In particular when offering added value E2E services. • Link capacity, link utilisation, packet drops, topology. • To have in multiple domain on stand-by tools to perform basic tests. • TCP throughput, link utilisation, delay, looking glass. • To have the capability of finding out where the tools are located. • To answer the question “End system vs network based problem?” • Send tests results easily. • Save time.

  15. MDM Service Benefits • PERT • Similar than for the NOCs. • L2 project users (LHC OPN, DEISA, eVLBI). • Can see the health of their service. • Verify SLA. • Integrate the data within their own tools. • L3 project users (EGEE, eVLBI). • Can see the health of their service. • Verify SLA. • Integrate the data within their own tools • We can provide them added value services (traffic matrix between project sites). • End-users when appropriate tools will be made available. • Empowering the network users: indication about the network. • Work not started.

  16. Going Operational • Pre-roll Out – define and set-up support structure now – March 07. • Pilot – April 07 – August 07 – 5 RENs + GÉANT2 • For NOC and PERT (no AA) • Understand the issues of going operational. • Validate the support structure, get feedback for next phase. • Release in January, deployment training in February. • Prototype – October 07 – February 08 – 11 RENs + GÉANT2 • For NOC, PERT and a limited number of projects. • Verify the MDM SLA. • Dedicated support team. • Verify how to provide the service to external parties. • Test the turn key solution. • Operation – April 08 • More RENs, closer to end-institution. • More projects supported.

  17. MDM Service Pilot portfolio (*) L2 status MP or SQL MA

  18. MDM Service Prototype portfolio In orange, the additional foreseen functionality from the prototype over the Pilot.

  19. Taking part to the Pilot • Deploy the web-services and provide the appropriate data. • Set-up an MDM Level2 support, provide an operational service. • Ensuring availability of the web-services (Monitor the web-services), reporting problems following the MDM service procedures. • Having the NOC and PERT using the infrastructure, solving issues thanks to it and providing feedback. • Training the NOC and PERT. • Validate the Service at the end of the phase. • Tools, metrics, services.

  20. MDM Web-services (Pilot phase) (*) To offer L2 status information, you can either chose the L2 status MP or SQL MA. An NRENs will only provide L2 status information when offering L2 circuits to LHC and DEISA.

  21. MDM Service Support • Infrastructure to support the perfSONAR web-services and the visualisation tools used by the MDM will be set-up. • For the deployers: installation, configuration, incident, monitoring. • For users: installation, utilisation. Deployers (RENs) SLA Users (NOC, PERT, Projects) Deployer Service Desk SLA ISS User Service Desk

  22. MDM Service Support • Level1 – Service Desk (ISS) • Help to install, configure the tools, run reachability tests, help on usability, track the RFE, forward problem to proper person, log the requests, update the documentation, track bugs. This is a central function (rotating member or group of people - ownership). • Level2 – Administrator (RENs) • Administrator of the machines where the services are installed. The function lies within the providers. They are in charge of taking care of the security of the services, of their availability (up) and reachability (no firewall, etc). The service should be available 24/7. • Level3 – Developers (3 years subcontract). • The JRA1 developers who have build the services. They are in charge of implementing new features and fixing bugs and of answering the query forwarded by level1. • The three levels of support will be available to both the users and the deployers.

  23. MDM Service Support • A turn key solution service could be provided for the web-services of a MDM service or part of it. • HW bought. • Web-services installed, monitored and managed on the REN behalves. • REN would still have to do a little bit. • More information about the MDM service in January • Transition to Service session on Tuesday afternoon. • What question have you got to be answered during that session?

  24. Visualisations In Red: Targeted for the Pilot. In Orange: Probablytargeted for the Prototype (in addition to the Pilot ones) To find out what user group will use as visualisation tool, chose one type of usage and find out, in the same column in the second table the tools available for this usage.

More Related