Enabling Grids for Escienc E g Lite Configuration

Enabling Grids for E-scienc. E g. Lite Configuration & Instrumentation Overview Integration Team JRA 1 all-hands-meeting, Brno 21. 06. 2005 www. eu-egee. org INFSO-RI-508833

Overview Enabling Grids for E-scienc. E • Where we stand today • Service Management proposal • Details: – Configuration Service – Service Instrumentation – User Interface • Discussion INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 2

Where we stand today Enabling Grids for E-scienc. E • Timeline – Discussion in the area of configuration an service management is going on for almost a year now – If we want to have something in g. Lite 2. 0 we don’t have much time left • Framework for discussion – So far discussion concentrated much on configuration, dynamic configuration, … – … however the scope is much wider and is about proper service management and instrumentation – If you have the basic service management infrastructure in place, you can start building up on this • Priorities – In our opinion a proper working service management is a key corner stone of g. Lite § How do you want to manage the software on the grid § Do you want to be called at 3 am in case something doesn’t work? INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 3

Where we stand today II Enabling Grids for E-scienc. E • Configuration – XML configuration – Deployment modules – We got a lot positive feedback from system administrator about the homogeneity of the configuration system – However: § Deployment modules still hide • service specific configuration files • service specific configuration methods § Unnecessary extra layer • Duplication of effort • Error cause § Misconfiguration still a major source for problems • Check of configuration has to be improved • Possibility to understand the system has to be improved • Possibility to control the system has to be improved INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 4

Where we stand today III Enabling Grids for E-scienc. E • Logging & Error handling – Common place for logging – Error handling still open – e. g. how to inform about upcoming errors – No possibility to get logs remotely • Service Instrumentation – No instrumentation in place – System administrator have no possibility to § know what the system is doing (besides going through log files…) § Control the system (besides going directly to the machine …) § Change the behavior of the system (besides cycling the system …) How do you want to manage the system running on the grid ? INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 5

Requirements Enabling Grids for E-scienc. E • Different sources – JRA 1 / SA 1 presentation in Athens – Discussions with SA 1 & user community – PTF Requirements Database • Entries in PTF database – Many entries related to configuration / management / logging & error handling – 100724: Administrative interface in grid services for • monitoring • creating alarms • Taking out sites/services by grid operation center etc. . . § They should have common, extensible, set of APIs – 100727 Error & Logging § All grid services must be able to use standardized interface for error and log messages and files. Log level has to be adaptable for e. g. different level of debugging. Minimal level has to guarantee audit trails. – 100726 Quality measurements § Grid services must enable the measurement of quantities relevant to the verification of service level agreements (SLA) INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 6

The challenge … Enabling Grids for E-scienc. E The service management has to take into account … • Heterogeneous system • Several information sources – Service / container / node • Reuse existing capabilities – Web services § C++ § Java – Daemons • Heterogeneous Service types • – Services that will implement a service management interface on • the long term – Services that will not implement a service management interface • Common vs. service specific management interfaces – e. g. start/stop Different use cases – Manage service – Manage a node … Use standard outside communication – standard outside SOAP interface: CIM, WBEM, WSDM, …. – self descriptive • Separate management from business logic – basic common set for all services – users => service API – can be extended by an individual service – managers => management API – separate WSDL interfaces INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 7

Management scenario I Enabling Grids for E-scienc. E • Two kinds of services: – Services with proper management instrumentation § Implemented of management via a common library § Provides common functionality • • Direct access for management Loading of configuration Interface to management service …. . – Services without proper management instrumentation § will be managed by a stub § stub implements common management library § Only base set will be provided – Management in service will be provided by § Common Java library (Glite. Service) § Common C++ library (DM Configurator) INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 8

Management scenario II Enabling Grids for E-scienc. E • Management access points: – one global management service per node § gateway to the outside management § collects information from different sources • Service(s) • Container(s) • System § directs commands to different destinations • Service(s) • Container(s) • System – “Management users” can decide to access management info via § central management service § Individual service management interface (or their stub) – Use standard SOAP communication (CIM model) see Joachim’s presentation … INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 9

Management scenario III Enabling Grids for E-scienc. E • Configuration: – Central configuration service § g. Lite instrumented service can get configuration from configuration service § Configuration service can have several back ends • File system • DB • LDAP … – Service-Service interaction § an instrumented g. Lite service can ask directly another service for its configuration • e. g. give me the port you are listening on see Robert’s presentation. . . INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 10

Management scenario IV Enabling Grids for E-scienc. E • Glite User Interface: – Configuration § Get configuration information from configuration service § Update configuration information via configuration service § Get configuration information from instrumented service – Managing of services § Access central glite management service on a node to • Get information about services • Node • Container • Start/stop services § Access individual service on a node to • Get information of individual service see Robert’s/Joachim presentation. . . INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 11

The global picture Enabling Grids for E-scienc. E User interface Glite. Manager Tomcat Node info Glite. Server Configuration Service other service Java webservice INFSO-RI-508833 C++ Non java service Glite. Service daemon DM service configurator JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 12

Service management Enabling Grids for E-scienc. E User interface SOAP Glite. Manager SOAP Configuration Service Tomcat Glite. Server SOAP other service Java webservice INFSO-RI-508833 C++ Non java service Node info Glite. Service daemon DM service management configurator JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 13

Configuration Enabling Grids for E-scienc. E User interface SOAP Glite. Manager Tomcat get / update SOAP Node info Glite. Server SOAP Configuration Service SOAP other service Java webservice INFSO-RI-508833 C++ Non java service Glite. Service daemon DM service configurator configuration exchange JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 14

Security Enabling Grids for E-scienc. E • Service management & configuration must use proper security – g. Lite has a proper security system in place for web services based on certificates – g. Lite management & configuration is based on webservices – Reuse the available system for service management & configuration – Several layers for § User role(s) to access the information § Management role(s) to access and change information § Probably more than one user/manager role • Hope for close collaboration with JRA 3 INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 15

Configuration Enabling Grids for E-scienc. E • Storing the configuration – XML has been proven to a valid file format for storing the information § Compromise between formatting and readability § Fast accessibility via trees – Improvements necessary for g. Lite 2. 0 § verification of values § More homogeneous naming § Support for different plugins (File, DB…. ) – We foresee the usage of a proper schema § Evolve from glite 1. x by taking into account • ITeam experiences • Feedback from testers, SA 1, developers – Discussion is still ongoing … § Discussions on schema have started within the i. Team – We will provide a proposal in the next weeks § Use of schema for verification § Balance between most complex (and complete) and usability § For services this will be dealt with via the configuration service INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 16

Service discovery: Iteam proposal Enabling Grids for E-scienc. E • Service type • org. glite. <subsystem>. <component> – Unique string in reversed domain name structure. – For non-g. Lite software: corresponding prefixes can be chosen (e. g. following their package domain names). Service name <hostname>_<VO-name>_<service-type> – Unique string in reversed domain name structure including hostname and VO name (if available) § where <hostname> is the fully qualified DNS hostname (e. g. lxb 1212. cern. ch) • Service Version – The version of the service in the form major. minor. patch. – For the moment we recommend to use the version of the deployment scripts. As the services start to implement the proper interfaces to provide the service version directly, this version will be taken. • URL Endpoint / URL WSDL / URL semantics – Proper string if available – ‘not available” if not available • Publishing times – 3600 s for service details, 30 s for service status Where do we store the list of possible values? INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 17

Discussion time Enabling Grids for E-scienc. E • We would like to have an open discussion with everybody – What they like/do not like about our proposal – Management interface § Most important service information § Most important service methods § Common base line set for management interface – Service discovery • We would like to come home from Brno with – a clear path to go – a timeframe for the remaining time to g. Lite 2. 0 INFSO-RI-508833 JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 18

Management Interface: Service Information Enabling Grids for E-scienc. E • State – deployed, started, stopped – Status: running/not running • Relationships – Dependencies (e. g. needs service A, B, C) – Replacement services (is duplicate of service D, E) • Generic information – Name – Version – Package signature – Interface version • Configuration – Values – Last updates INFSO-RI-508833 • Timing – uptime – present time • Service performance metrics – Last processing time – Longest processing time • Logging – Log information – Number of errors • Service specific internal information – Number of used DB connections – Number of requests • Available services in container / node JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 19

Management interface: Service operation Enabling Grids for E-scienc. E • Status operation – start, restart, stop, pause, reconfigure, … • Internal operations – pinging – Different kind of service specific operations § § § INFSO-RI-508833 cleanup connections reset redirect log information add user …. JRA 1 all-hands-meeting Brno June 2005 Joachim Flammer 20