EGI-InSPIRE RI EGI-InSPIRE EGI-InSPIRE RI EGI Network Support task force January 24, 2011 EGI OMB f2f meeting Amsterdam EGI.eu 1 Mario Reale IGI / GARR

EGI-InSPIRE RI EGI-InSPIRE EGI-InSPIRE RI Overview Introduction to the Task Force Definition of the identified use cases Answers from the NGI

EGI-InSPIRE RI Goals and duration Mandate: assessment of the current stand of Network Support for EGI and the formulation of a proposal for it –Gather user requirements from NGIs –Assess the status of the available tools –Further develop and consolidate new proposed tools –Identify missing bits / tools –Propose tools and workflows to the EGI Net Sup community –Define draft workplan for the next months Started on October 20, 2010, ended on January 21, 2011 –around 8 working weeks duration –coordinated from remote met 5 times in VideoConference: 20/10, 10/11, 22/11,10/12, 14/1 3

EGI-InSPIRE RI Membership Etienne Duble France-Grille (UREC CNRS) Xavier Jeannin France-Grille (UREC CNRS) Esther Robles (RedIRIS) Alberto Escolano (RedIRIS) Bruno Hoeft (D-GRID KIT) Mario Reale (IGI GARR) Fulvio Galeazzi (IGI GARR) Alfredo Pagano (IGI GARR) Wenshui Chen (ASGC) Domenico Vicinanza (DANTE Int.Rel.Team) Szymon Trocha (PSNC/GN3 SA2 T3 PerfSONAR)

EGI-InSPIRE RI What has been done Identified 7 network related Use Cases Organized a questionnaire about them for the NGIs, gathered and published the results Identified a strategy for all of them –although we specified strategies at different levels of accuracy and technical insight Some of us worked on further development of tools –PerfSONAR live-CD, HINTS, NetJobs Designed the GGUS network support workflow to be implemented for EGI Liaised with GN3 about the current PerfSONAR status/tools

EGI-InSPIRE RI What has NOT been done Brought all proposed new tools to a final, frozen production status after extensive validation phase –But all proposed tools can usefully be used by early adopters Made a world-wide, general assessment of all available tools for network monitoring and network support in general Developed new tools in all cases we felt either a brand new tool or a major improvement of the existing ones would be required –Example: Network-related Scheduled Maintenances

EGI-InSPIRE RI Identified Use Cases (7) Answers from the NGI Questionnaire

EGI-InSPIRE RI GGUS Grid Users and Site Administrators open a ticket in the GGUS support system when they think a network issue is behind the problems they are experiencing. Tickets are assigned to the GGUS Network Support Unit and processed until solved. We need to give a home to all network related issues in EGI – currently unattended To whom assign network related issues ? –A support team made by network experts from volunteering NGIs or NRENs ? –Skip the Grid community and assign tickets directly to the NRENs and/or GEANT/DANTE ? Many parties involved in ticket processing: Site Admins, NREN NOCs and APMs, GEANT NOC and APMs

EGI-InSPIRE RI Answers on GGUS Answer n.3: Having a GGUS support unit for Network Support is useful, but tickets should be handled automatically according to a given workflow and routed to NRENs/NGIs contacts; no need to have a permanent team behind this unit

EGI-InSPIRE RI EGI PERT Grid Users experiencing poor performances in data transfers can refer to a global EGI PERT Contact Team (with both Grid Middleware/Applications and Network Know-How) to get support The idea would be to have EGI-wise a unique team of experts with both Grid Middleware/Applications and Network know- how (merging the 2 communities) Expensive idea, but useful: –bottleneck identification involve digging into both domains and its interface/interaction –Middleware and Application experts (VO,VRCs) could start excluding higher level issues in the ISO/OSI stack before NRENs and Federated EduPERT networking experts come in It turned out to be too expensive for the NGIs’ manpower/budget – at least at this stage

EGI-InSPIRE RI Provided Answers on EGI PERT Answer n.4: Having a Global EGI PERT access point for users experiencing poor performances – forming a PERT Team with Grid-added know how – is useful, but we cannot commit any resource/manpower to it

EGI-InSPIRE RI Scheduled Maintenances warned in advanceinformed asapWhen an identified accident or the scheduled maintenances of network devices/PoPs is impacting on a Grid resource center/site, users, site admins and Operations teams are warned in advance (Sched Maint) or informed asap (Accident) The idea would be inform users/site Admins about why things are not working when there are obvious reasons for experiencing problems – Currently GOCDB is used for Grid- related Sched M. Requires NREN-NGI communication/coordination: mapping between Network devices/PoPs and Grid resource centers/sites –a mapping between Network devices/PoPs and Grid resource centers/sites mapping between Grid resource centers/sites and Users –a mapping between Grid resource centers/sites and Users Can be managed using a pull or a push logic –Users subscribe to a given site and get notified –Impacted sites publish information on a web site and users fetch information from there

EGI-InSPIRE RI Provided Answers on Scheduled Maintenances Answer n.3 Having a global EGI tool/service to warn users and site administrators about Sched Maint is useful; storing the information in one place is the solution to go for, but we cannot commit any manpower/resource to develop nor maintain such a tool

EGI-InSPIRE RI Network TroubleShooting on Demand Grid site administrators, Operation Centers or authorized users experiencing problems in reaching a given site/resource perform troubleshooting on demand to exclude basic network issues behind the problems they’re experiencing Requires local deployment at the sites of probes controlled by a central system Results in the introduction of different roles Basic checks would involve ping, traceroute, reverse DNS checks, port scan, available bandwidth measurements

EGI-InSPIRE RI Provided answers on Network Troubleshooting on Demand Answer n.3: Having a network tool for troubleshooting on Demand is useful, but we cannot commit any resource/manpower to contribute to develop nor test it

EGI-InSPIRE RI e2e MultiDomain monitoring Users and Site Administrators get network performances measurements for a subset of e2e paths within the EGI Infrastructure, getting monitoring information gathered by scheduled, periodic measurements Muldidomain: NRENs, GEANT Monitoring data may include –Link Availability ( i/f utilization, Input Errors, Output Drops) –One-way Delay –RTT, number of hops –IPDV(Jitter) –Available TCP Bandwidth

EGI-InSPIRE RI Provided answers on e2e multidomain monitoring Answer n.3: Having an e2e MultiDomain monitoring tool for a specific subset of of the whole set of e2e paths within EGI is useful, but we cannot commit resources nor manpower and cannot afford deploying anything locally at the sites

EGI-InSPIRE RI DownCollector Users, Site Admins and Operation Centers need to check if services available at various grid sites are reachable and responsive DownCollector developed during EGEE for monitoring Grid services at the sites Migrated from EGEE ENOC to EGI Checks services are reachable on specific ports from a central location, star-based architecture Possible evolution would be to have additional geographically distributed instances, gathering results

EGI-InSPIRE RI Provided answers on DownCollector Answer n.3: Having a DownCollector tool is useful but we cannot commit any manpower nor resources to contribute to its deployment

EGI-InSPIRE RI Policy & Collaboration establish an EGI group of people, a body permanently in charge of interfacing the NRENs, EGI.eu, EMI, DANTE, GEANT and TERENA to discuss issues related to –the provisioning of network connectivity or the upgrade of existing links, –new services and new standards –new tools for monitoring, –new joint initiatives on tutorials, dissemination on tools, –testing and prototyping of middleware with respect to the network layer so that the requirements, coming from the EGI user community and the VRCs could be shipped to the Network community and relevant information is exchanged

EGI-InSPIRE RI Provided Answers on Policy & Cooperation Answer n.2: Having a Policy and Cooperation Group is useless.

EGI-InSPIRE RI How we structured today’s meeting 1. Introduction to the TF and its objectives 2. Report on what we propose for each use case 3. Presentation of tools 4. General Discussion/Feedback from NGIs –We should decide upon Approve a GGUS workflow –So that it can be implemented within the GGUS system Adopting or dropping the proposed tools Identify volunteering NGIs for early adoption, initial extended deployment of tools Identify possible missing bits or uncovered use cases/unsatisfied requirements to work upon