1. The BEinGrid SLA cluster Results and perspectives Igor Rosenberg, ATOS ORIGIN igor.rosenberg@atosorigin.com 20min talk at OGF23, June 2 nd 2008 Dynamic Service Level Agreements workshop

2. Business Experiments in GRID 2 "Dynamic Service Level Agreements" OGF23 OGF23 is featuring a workshop on "Dynamic Service Level Agreements" which will take place on Monday 2nd of June 2008 in Barcelona (Spain): http://www.gridforum.org/gf/event_schedule/index.php?id=1225 http://www.gridforum.org/gf/event_schedule/index.php?id=1308 The workshop consists of invited talks and a panel discussion. It will bring together researchers and engineers whose organisations are actively addressing Service Level Agreements concerns to share experiences and to describe their research in order to facilitate better understanding of Grid Quality of Service issues and requirements. 23rd Open Grid Forum - OGF23/BEinGRID Industry Days June 2 - 6, 2008 Barcelo Sants Hotel Barcelona, Spain http://www.gridforum.org/OGF23/ http://www.gridforum.org/OGF23/ Invited projects: –BEinGRID, SmartLM, GridEcon, SORMA, BREIN, SLA@SOI, AssessGrid, RESERVOIR

3. Business Experiments in GRID 3 Workshop: Dynamic Service Level Agreements Grid computing systems need to achieve levels of Quality of Service (QoS) necessary for enterprise applications in science and industry. A Service Level Agreement (SLA) specification provides a formal method for describing QoS requirements. This workshop seeks to bring together researchers and engineers whose organisations are actively addressing SLAs concerns, for example through WS-Agreement standardisation, to share experiences and describe their research in order to facilitate better understanding of Grid QoS issues and requirements. SLAs become particularly important in the context of emerging computing infrastructure such as Cloud Computing. Within such infrastructure, it is necessary for providers to establish SLAs within a Cloud to ensure that some acceptable level of quality can be offered to an external user. Examples of this can be seen in the Amazon S3 and EC2 Cloud services, where Amazon offers SLAs defined in terms of uptime and availability for their Cloud services, even though the Cloud itself is implemented through a distributed data center managed by Amazon. We believe therefore that as Grids evolve towards the Cloud and "ensemble" computing concept (from Irvin Wladawsky-Berger's talk at OGF22), SLAs will gain greater significance, especially the focus on negotiation mechanisms to support SLA formation and subsequent use. In recent years, it has become clear that there is considerable overlap between the goals of Grid computing and the benefits of an SOA based on Web services; the rapid advances in Web services technology and standards have thus provided an evolutionary path from the architecture of current Grids to the standardised, service-oriented, enterprise-class Grid of the future. Grid Service Level management contains QoS descriptions for Web services in the form of SLAs and support infrastructures and tools for service design, design validation and run-time verification. SLAs are formal contracts negotiated between end-users and service providers. WS-Agreement is a language and protocol designed for advertising the capabilities of providers and creating agreements based on initial offers, and for monitoring agreement compliance at runtime. The motivations for the design of WS-Agreement stem out of QoS concerns. The definition of the protocol is totally general and allows for the negotiation of QoS in any Web service enabled distributed system. However, the WS-Agreement specification does not contemplate the possibility of changing an agreement at runtime. Therefore the challenge is to provide extensions of WS-Agreement and of its semantics in order to make agreements robust and more long-lived to individual term violations. This workshop will seek to bring together researchers and engineers working on SLA issues in order to facilitate better understanding of requirements for QoS provision of Grid systems. Two considerations will merit special attention. First, Grid SLA management is complicated by the inherent composition of the Grid. Second, commercial Grids are identified as an emerging specialisation of Grid technology, therefore a fundamental requirement is the need to define and satisfy SLAs. An important focus of this workshop will be on how SLA management systems and Grid standards currently being developed can specify, negotiate, monitor and adapt SLAs to provide a level of QoS needed for scientific and industrial purposes. The workshop will address techniques and mechanisms employed by, or being considered for, current Grid systems to manage SLAs to ensure QoS provision. These include, but are not limited to, SLA specification, SLA negotiation, SLA re-negotiation, WS-Agreement extensions, QoS monitoring. Of special interest is the relationship of these mechanisms to, and interactions with, specifications being developed within OGF (GRAAP) and related organisations, for example for Grid middleware services.

4. Business Experiments in GRID 4 Workshop main focus WS-Agreement standardisation facilitate better understanding of requirements for QoS provision of Grid systems –Grid SLA management is complicated by the inherent composition of the Grid –commercial Grids are identified as an emerging specialisation of Grid technology, therefore a fundamental requirement is the need to define and satisfy SLAs. –how SLA management systems and Grid standards currently being developed can specify, negotiate, monitor and adapt SLAs to provide a level of QoS needed for scientific and industrial purposes. –The workshop will address techniques and mechanisms employed by, or being considered for, current Grid systems to manage SLAs to ensure QoS provision: SLA specification, SLA negotiation, SLA re-negotiation, WS-Agreement extensions, QoS monitoring.

5. Business Experiments in GRID 5 BEinGrid Project Data Sheet Type of project: Integrated Project Project coordinator: Mr. Santi Ristol santi.ristol@atosorigin.com (ATOS ORIGIN) Project start date: 1st June 2006 Duration: 42 months (until Nov 2009) Budget: 24.7 M Euros Max EC contribution: 15.7 M Euros (63%) Consortium: 75 + 23 partners Effort: 2713 PM (226 PY,65 P,360.000h) The mission of BEINGRID is to Exploit European Grid middleware by creating a toolset repository of Grid services from across the Grid research domain and to use these services to deliver a set of successful business experiments that stimulate the early adoption of Grid technologies across the European Union.

6. Business Experiments in GRID 6 BEinGrid at a glance 18 + 5 Business experiences –Service Provider + Integrator + End User –12 different sectors : retailing, architecture, textile, finance, … –Two BE waves: first is just finished, second started March ´08 Real world! Cross activities –Analysis of the ongoing experiments –Technical “clusters” (security, portals, VO, SLA, …) –Business Gridipedia (General Repository) –Documents (designs, howtos, success stories, …) –Software (generic components)

7. Business Experiments in GRID 7 BEinGRID S&T Approach Technical cross activities Trust & Security VO Management Service & Data Mgt Architecture & Interop...... Selected branches: GTv4, UNICORE/GS, g-Lite, GRIA, WS-* Business cross activities Dissem. & Exploitation Market Study Business Modeling...... Middleware 1 Middleware 2 Mdw -n BE1 BE2BE3... BE4 BE5 BE18 Gridipedia SLA Cluster

8. Business Experiments in GRID 8 SLA Cluster General Presentation The Service Level Agreement Cluster considers the typical SLA lifecycle: –Stage 1: Development of a service and creation of SLA templates for this service –Stage 2: Discovery and negotiation of an SLA –Stage 3: Service provisioning and deployment –Stage 4: Execution of the service –Stage 5: Assessment and corrective actions (when necessary) –Stage 6: Decommission of the service √ √ √ –Produce generic components: Negotiation, Optimisation Eval&Monitoring, July Accounting, July SLA Framework, Nov √ √ Aim of the cluster: –Discover requirements –Sort by importance –Produce design patterns –Produce Best Practices Report July

9. Business Experiments in GRID 9 Classification of the initial topics by the first BEs T1: SLA Template Guidance to the write-up of the SLA template offered by providers: how-tos, skeleton, GUI, traps to avoid. Medium T2: Publication and Discovery Mechanism to allow an efficient management of distributed resources is proposed (good-use rules, to facilitate the work of a matcher). Low T3: Negotiation Tools easing the negotiation (bargain) of an SLA Medium T4: Optimisation of Resource Selection Selection of the most suitable host (to deploy and execute a service), optimise a predefined measure of system efficiency. Medium T5: Monitoring SLA Monitor system that checks the status of the SLA is proposed High T6: Re-negotiation Changing an already accepted SLA. Novelty is the existence of a previous contract providing initial values, and possibly running jobs (migration). Low T7: Evaluation Comparing predicting all the terms of the agreed SLA with the current situation (gained through monitoring), to discover potential violations to the agreement. High T8: Accounting Calculate the price for a given service (related to the SLA-metrics) Low T1T2T3T4T5T6T7T8 BE03XXX BE06XXXXXXX BE07XX BE08XXXXX BE09XXXXXXX BE10X BE16XX Most relevant BEs (presenting major interest on SLAs) Importance

10. Business Experiments in GRID 10 The most relevant first findings Most important requirements  Monitoring SLA Monitor system that checks the status of the SLA is proposed  Evaluation Comparing predicting all the terms of the agreed SLA with the current situation (gained through monitoring), to discover potential violations to the agreement.  Depending on BE votes, business relevance, technical innovation, and dependencies... lead to design patterns (middleware independent software component architecture) http://www.gridipedia.eu/204.html  Negotiation - First step needed to create an SLA  Monitoring and Evaluation - System checking the status of the SLA, notifying of violations  Accounting - providing the financial department with the log of the SLA resource usage  Optimisation of resource selection - adapt the scheduling algorithm to focus on business value of SLAs.

11. Business Experiments in GRID 11 BEinGrid SLA Software components ComponentsMiddlewareStatusWS- Agreement Negotiation linklink GT4 WS-Core 4.0.5 RELEASED http://www.gridipedia.eu/683.html √ Optimisation linklink GRASP GT4 upcoming release, under testing X (WSLA) Monitoring and Evaluation (based on ganglia metrics) link link GRIA GT4 WS-Core 4.0.5.NET 3.0 / WSRF 2.0 upcoming release, under testing July ´08 X (GRIA SLA) √ AccountingGRIA GT4 WS-Core 4.0.5 July ´08 Nov ´08 X (GRIA SLA) √

12. Business Experiments in GRID 12 An SLA framework for GT4 v4.0.5 Most capacities are in the SLA framework  Negotiation  Optimisation  Monitoring and Evaluation  Accounting included Not yet contemplated Ganglia + MDS

13. Business Experiments in GRID 13 Research openings Within BEinGrid: Most needed capacities Design patterns Components Repository Templates? Discovery? SLA Standard? Research: –Justification from real world situations (new BEs) –Composition of SLAs –Re-Negotiation –Negotiation 1—* –Translate QoS terms from user language to provider language –Crisis strategies (lowering violation impact)

14. THANK YOU http://www.gridipedia.eu/slas.html igor.rosenberg@atosorigin.com © BEinGRID Consortium

15. Business Experiments in GRID 15 2nd wave of experiments… and opportunity for collaboration There will be an open call to establish a set of 5-6 new Business Experiments -The new BE should last round 12-14 month maximum. -Available 330K€ (approx) funding per experiment -The BE must be based on semi-mature technology, include the full value chain (End- User, Integrator and Service Provider) and present a preliminary business plan -Open call text available after this summer, new BE start in Jan/Feb 2008

16. Business Experiments in GRID 16 BEinGrid - 8 main objectives To study and gather the requirements for the commercial Grid environment, evaluating current and proposing new business models considering aspects To design and build a Grid toolset repository based on different Grid foundation middleware (Globus Toolkit v4, Unicore/GS, gLite, WSRF.NET, GRIA and open Axis plus WS-* standards) To enable and validate the adoption of Grid technologies in industry and services, addressing in particular small and medium sized enterprises (SMEs). To realize a critical mass of business experiments (Grid-enabled pilots) embracing a broad spectrum of economic sectors To produce a set of successful case studies as a result of putting into practice the real-world pilots and to report the best-practice guidelines of Grid pilot experiences. To contribute to making the NGG transparently usable, persistent and scalable up to global pervasiveness, Identify further generic components out of the Business Experiments to complete the available solutions and integrate them into the repository. For the second phase of the business experiments, to provide through the repository, a mechanism for current research projects in the Grid domain a platform to provide their software and components to a wide community.

17. Business Experiments in GRID 17 BEinGRID at a glance SP Experiments by sectors Experiments by technology Common facilities SP Business Experiment Value Chain End- User Service Provider Integrator Finance MultiMedia Retailing Logistics Chemistry Goverment - Public service Aerospace Enviromental Science Textile Ship Building Engineering Automotive

18. Business Experiments in GRID 18 SLA Architecture (1 st static approach)

19. Business Experiments in GRID 19 Architectural design I (subsystem identification, split between WP4.3 & WP4.4)

20. Business Experiments in GRID 20 Architectural design II (subsystem identification, split between WP4.3 & WP4.4)

21. Business Experiments in GRID 21 Basic metrics and policies System Metrics (we must delimit a reduced set) –CPU (mean values) –Memory –Disk storage –Availability (%) –Network profile (BW offered Rb, traffic priority of packets, etc) for a period time –Number of invocations –Response time –... (any application specific – high level) Recovery Polices (when QoS is not fulfilled) –Service destruction –Increase process priority –Reinstantiation of service –Q.Recovery actions at network level? –Q.Recovery actions derived from mobility… (grid) (grid) (net) (app) (app)