fesr ssicilia – a gridbased infrastructure for business ... · ssicilia.unime.it catania,...

www.consorziocometa.it

FESR

Consorzio COMETA Progetto PI2S2

SSicilia – a Gridbased infrastructure for business

applicationsCarmelo RagusaFrancesco Longo

Cometa Consortium Research Group @University of Messina

Catania 04/03/2008

http://www.consorziocometa.it/ssicilia/ssicilia.unime.it

http://www.consorzio-cometa.it/

ssicilia.unime.it Catania, 04.03.2008 2

Outline

• Project goals• Scenarios• Architecture overview• Modules details• Technology used• Things to look in the future• Conclusion and future work


Project goals

SSicilia is a 2year collaboration between the Cometa Consortium and ORACLE.

The project aims to address specifics needs• create a business processes platform over a Grid

infrastructure• offer business services with guaranteed QoS• provide customers' Data protection• regulate B2B relationships through SLA business

contracts


Scenarios• AS hosting service

– Hosting for web applications: ecommerce, CMS, website builders, etc.

– Test with an ecommerce application• GridVideo

– Hosting for content providers– Video fruition for content provider's customers

• Grid for Industry– Host for companies applications, e.g. Productivity software, legacy

applications, etc.– Host of Virtual Machines running applications for company's employer– Customized environment– Support for user's mobility


Architecture overview


Modules details 1/2•Accounting Service: this service registers the user and grants the access to the infrastructure;

•Negotiation Service: this process is started by the user that request an offer for a service. The service gets the SLA from the user and submits it to the prediction service. Based on the result from the Performance Prediction service, the strategy and the pricing model in use it fills the SLA and sends the completed offer, in form of an SLA, back to the user;

•Performance Prediction Service: it returns the confidence with which the system can satisfy the SLA, based on the past of similar SLAs stored within the DB;

•SEUploader: this service uploads customer's files to the gLite SE;

•Process Scheduler Service: this service receives the user agreed SLA and stores it in the DB along the associated paths, within the SE, of the user's application files;


Modules details 2/2•Monitoring Service: this service monitors the SLA lifecycle. It checks if there are SLA in a new state and sends them to the QoS service. It also detects if an SLA needs attention and informs the QoS service. Finally, it determines when an SLA finished and contacts the billing service. The operations performed by this service are also implemented by some procedures within the Service Repository;

•QoS service: this service performs a match operation of the user requests with the Grid resources. It also deals with SLAs that need attentions;

•Billing Service: this service gets the finished SLA, invokes the credit service (which is usually an external service) and informs the user that his/her service has been completed;

•Credit service: this service invokes an external service, usually given by a bank, which issue the payment from the user credit card or account;

•JDL maker service: this service invokes a script that creates a JDL for the SLA and sends it to the gLite UI;


Technical details• DB architecture

• Service Composition

• WAI

• SEUploader

• Resource monitors

• JDLMaker

• QoS mechanisms


DB architecture (1/2)


Service Composition• Web application may need services such as:

– Bpel server

– ESB server

– OWSM

– DB

– Rule authors

– Apache web server

– ...

• GridOffice– VM server

– VPN service

Different SLA sub types


WAI


SE Uploader • Composed of bash scripts and TCL expect scripts.• Called by Web Access Interface via jsp.• It connects to the UI and upload the files to the SE using command line interface.• It updates the Service Repository with information about the files associated with the SLA.• Possible future use of GFAL library.

WAI SE Uploader UI

SLA Engine ServiceRepository SE

gLite


ServiceRepository

Resource monitors

WN Sensor

Service Sensor

Service Sensor

Service Sensor

Service

Service

Service

Monitoring Job

Monitoring Job

Monitoring Job

Application

Application

Application

• Bash scripts that use OS tools for monitoring (top, mpstat, nethogs, ...).• Cron demon's schedules based on repository information• Monitored resources are CPU, memory, disk, net.• WN Monitor and WN Sensors are installed when a WN joins the system.• Service Sensors are automatically installed with the service.• Monitoring Jobs monitor the applications during their life time.

CPU, memory, net, .... WN MonitorWN


JDL Maker • Composed of bash scripts and TCL expect scripts.• Represents the contact point between SLAEngine and gLite.• Called by QoS Service for the submission of SLA associated jobs to the grid.• Connects to the UI and submits the job using command line interface.• The JDL is dynamically composed based on the SLA subtype.• Possible future use of resource broker web service interface.

QoS Service JDL maker UI

SLA EngineRepository RB

gLite

JDLmaker <sla_id> <wn_id> <new | kill>

PerformancePredictionService

MonitorService


QoS mechanisms

• Performance prediction– Average on history values of resource consumption of similar SLAs, used by the QoS

service

• Monitoring procedures– Detection of critical SLAs that need attention

– Detection of resource overallocation

• QoS service– Initially, choose of WN that satisfies SLA requirements from performance prediction

– Allocation of further WNs for critical SLA

– Deallocation of WNs for SLAs with resources overallocated


Technology used• SOA > ORACLE SOA suite: used for the implementation of the SLA

engine– BPEL Process Manager– Enterprise Service Bus (ESB)– Web Services Manager (OWSM)– Business Rules– Application Server

• Oracle DB 10G 10.2.0.3: used for the Service repository and as a service offered to run the AS applications

• Web Cache 10.1.2.0: used to balance the load to the connected machines• JDeveloper 10.1.3.2: used to develop Bpel processes for the SLA engine• WSLA > SLAs: used to represent business contracts• Linux scripts: used to implement QoS mechanisms and gLite middleware

integration


Things to look in the future • JDLMaker web service interaction with Resource Broker

• Use of GridIce monitoring mechanisms

• Automatic services deployment (e.g. the all AS)

• Use of GFAL library for SEUploader process

• Direct submission to WN

• “Smarter” QoS mechanisms

• ...


Conclusions and Future work• Integration made• System tests undergoing• AS hosting scenario developed• Tuning of current processes• Improvements of current mechanisms• Integration of virtualization solution• Integration of GridVideo application• Setup of remaining scenarios


gLite

Demo Testbed configuration

WAISLAengineUI

WN1

WN2

WN3


Demo Steps1. SLA submission trough WAI2. SLA acceptance trough WAI3. Customer files upload4. Application deployment5. Application load generation6. Critical SLA detection7. Resource reallocation and new application deployment8. Application load stop9. Overallocation detection10.Resource reallocation and application undeployment11.SLA end

fesr ssicilia – a gridbased infrastructure for business ... · ssicilia.unime.it catania,...

Documents