The BEinGrid SLA cluster Results and perspectives Igor Rosenberg, ATOS ORIGIN...

The BEinGrid SLA clusterResults and perspectives

Igor Rosenberg, ATOS ORIGIN

[email protected]

20min talk at OGF23, June 2nd 2008Dynamic Service Level Agreements workshop

Business Experiments in GRID5

BEinGrid Project Data Sheet

• Type of project: Integrated Project• Project coordinator: Mr. Santi Ristol

[email protected] (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.


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)


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 BE2 BE3

...

BE4 BE5 BE18

Gridipedia

SLA Cluster


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


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

T1 T2 T3 T4 T5 T6 T7 T8

BE03 X X X

BE06 X X X X X X X

BE07 X X

BE08 X X X X X

BE09 X X X X X X X

BE10 X

BE16 X X

Most relevant BEs (presenting major interest on SLAs)

Importance


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.


BEinGrid SLA Software components

Components Middleware Status WS-Agreement

Negotiation link GT4 WS-Core 4.0.5 RELEASEDhttp://www.gridipedia.eu/683.html

√

Optimisation link GRASPGT4

upcoming release, under testingupcoming release, under testing

X (WSLA)

X (WSLA)

Monitoring and Evaluation (based on ganglia metrics) link

GRIAGT4 WS-Core 4.0.5.NET 3.0 / WSRF 2.0

upcoming release, under testingJuly ´08July ´08

X (GRIA SLA)

√√

Accounting GRIAGT4 WS-Core 4.0.5

July ´08Nov ´08

X (GRIA SLA)

√


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


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)

THANK YOU

http://www.gridipedia.eu/slas.html

[email protected]

© BEinGRID Consortium


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


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.


BEinGRID at a glance

SP

SP

SPSP

Experiments by sectors

Experiments by technology

Common Common facilitiesfacilitiesSP

Business ExperimentValue Chain

End-User

Service Provider

Integrator

Finance

MultiMedia

Retailing

Logistics

Chemistry

Goverment - Public service

Aerospace

Enviromental Science

Textile

Ship Building

Engineering

Automotive


SLA Architecture (1st static approach)

SLA-Repository

WP4.4

SLA-ContractRepository

SLA-Negotiator

SLA-Tranlsator

SLA-DecisorSLA-Controller

WP4.3

WP4.2

DISCOVERY

MONITORING

EMS

BUSINESSSERVICE

REGISTRY

ACCOUNTING

VOMANAGEMEN

T

SLA-Contract

SLA-Contract

SLA-Template

SLA-Template

REGISTRY


Architectural design I (subsystem identification, split between WP4.3 & WP4.4)

SLA-Repository

WP4.4

SLA-ContractRepository

SLA-Negotiator

SLA-Tranlsator

WP4.3

BUSINESSSERVICE

REGISTRY

SLA-Contract

SLA-Contract

SLA-Template

SLA-Template

MONITORING EMS

ACCOUNTING

VOMANAGEMEN

T


Architectural design II (subsystem identification, split between WP4.3 & WP4.4)

WP4.4

SLA-DecisorSLA-Controller

WP4.2

DISCOVERY

MONITORING

EMS

BUSINESSSERVICE

REGISTRY

ACCOUNTINGVO

MANAGEMENT

REGISTRY

WP4.3


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)(net)

(app)(app)

Date post:	05-Jan-2016
Category:	Documents
Upload:	godfrey-perry
View:	217 times
Download:	0 times