Software Architecture Definition for On-demand Cloud Provisioning

Software Architecture Definition for On-Demand Cloud provisioning

Clovis Chapman, Wolfgang Emmerich, Fermín Galán Marquez, Stuart Clayman, Alex Galis

University College London

Telefonica I+DThe research leading to these results has been partially funded by the EuropeanCommunity's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 215605.

Software Architecture Definition for On-demand Cloud Provisioning

Overview

Problem overview Background: Resources And Service Virtualization Without Barriers Approach: Software architecture definition Evaluation


Problem overview

Clouds introduce opportunity to lease computational resources on demand:– Manage the execution of service applications across multiple physical

locations in a seamless manner

– Virtualisation allow a wide range of new capabilities (migration, on demand allocation, dynamic resizing)

Software systems hosted on clouds may be composed of numerous loosely coupled components:– Application may present architectural constraints, co-dependencies between

components.

– Providers must be able to define software composition and requirements related to the provisioning of the service.


Example: SAP ERP System

Three tier architecture:

Database (DBMS) Central Instance (CI)

– Enqueue server providing a high level locking mechanism (data consistency)

– Messaging server for load balancing

Dialog Instance– User request processing– Data record updates– Batch processing

DIDIDIDI

SAP GUISAP GUISAP GUISAP GUI SAP GUISAP GUIBrowserBrowser

CICI DIDIDIDI

DBMSDBMS

Presentation

Application

Database



Software composition: Individual components may have different software and hardware requirements:

- DBMS: large storage requirements- DI: Processor intensive

Topology: All components must belong to the same virtual network.

Customization: Locations must be provided at run-time.

DIDIDIDI


CICI DIDIDIDI

DBMSDBMS

Presentation

Application

Database



Deployment dependencies: DBMS and CI must be run first.

Location constraints: Must be co-located on the same physical site to minimise latency

DIDIDIDI


CICI DIDIDIDI

DBMSDBMS

Presentation

Application

Database DBMSDBMS

CICI



Dynamic capacity adjustment: Might require new DIs to meet increases in workload.

Resource requirements directly proportional to concurrent sessions.

DIDIDIDI


CICI DIDIDIDI

DBMSDBMS

Presentation

Application

Database

DIDI DIDI


Example 2: Thales eGov

Dynamic capacity adjustment: Each layer invoked to process user requests.

Each scale independently according to load and average response time.


Focus of this work

Define a software architecture definition language:– Enable service providers to control the deployment and management of

services deployed on Clouds throughout their lifetime.

– Introduce abstractions to support capabilities introduced by cloud computing (e.g. service elasticity)

Define underlying service management infrastructure support:– Monitoring / lifecycle management / elasticity enforcement

Define behavioural semantics for the language:– Link between software architecture definition and infrastructure

– Derive service management lifecycle from software architecture definition

– Constrain infrastructure operation


Overview



Develop and promote (through standardization) an open architecture for federated cloud computing- where resources and services can be transparently and dynamically

managed, provisioned and relocated like utilities

RESERVOIR is an open framework of modular components that enable a wide range of setups within the cloud space

RESERVOIR Goals

Infrastructure SolutionsInfrastructure SolutionsRESERVOIR

Software Architecture Definition for On-demand Cloud Provisioning1-2 April, 2009 Y1 Project Review 12

Challenges

Inherently limited scalability of single-provider clouds Lack of interoperability among cloud providers

- Inability to scale through partnerships across providers- Prevents small and medium infrastructure providers from

entering the market - Locks consumers to a single vendor

Dynamic and automated application scaling

BSM through Service Level Agreements, Monitoring, Security …


The RESERVOIR vision

Private cloud

Partner cloud

Public cloud


Reservoir Site

VEE Manager (VEEM)

Service Manager

VH

I

VEE Host (VEEH) (e.g., Hypervisor, VJSC Host)

VM

I

Service Provider

SLA SLA

Manifest SM

I

VMI VMI

RESERVOIR Architecture

• Translates generic commands into specific virtualization platform commands

• Creates and maintains isolated virtual networks

• Enables efficient and secure access to remote storage

Isolation + Elasticity + Trust + Security

Service Provider supplies:• Prepacked Service Components

(Virtual Machine)• Service Manifest

Separation + Business Orientation

• Optimizes VEE placement subject to constraints

• Deals with site federation• Distributed as OpenNebula

Federation + Elasticity + Trust + Security

• Enforces SLA compliance by adjusting application capacity:

• Service Components Sizing (VEEs)• Service Tiers sizing

• Responsible for accounting and billing

Elasticity + Business Orientation + Trust + Security


Service Manifest Requirements

Service Manifest Language

– Define language for service definition manifest to express:• Application structure (software architecture)• Constraints (grouping / topology / cost)• Capacity requirements (with elasticity rules)• Monitoring specification• Additional information (requirements / service levels / Customisation )

– Contract between provider and infrastructure provider

Service Lifecycle Management– Derive various representations and execution plans for underlying

layers:• Deployment descriptor• Elasticity rules• …


Overview



Model-denotational Approach

Language definition using OMG’s Model Driven Architecture

Abstract syntax defined using the Essential Meta Object facility – Define core syntactic elements of the language (software

architecture, requirements, etc.)

Various concrete syntaxes (XMI, HUTN, …) as may be required– Based on open standards – in particular the Open Virtualisation Format

(OVF)

Semantics expressed as constraints on relationship between domain model and syntactic model using the Object Constraints Language. Domain model represents cloud infrastructure and


Service Deployment

ManifestManifest

Manifest Language Syntax

+refs: Reference[]+disks: Disk[]+nets: Network[]+vm: VirtualSystem[]

+refs: Reference[]+disks: Disk[]+nets: Network[]+vm: VirtualSystem[]

ApplicationDescriptionApplicationDescription

+comp: Components[]+kpi: KPIs+comp: Components[]+kpi: KPIs

ElasticityRuleElasticityRule

+cond: Expression+kpi: KPIs+action: Operation

+cond: Expression+kpi: KPIs+action: Operation

VirtualMachineVirtualMachine

+name:String+CPU: double+memory: double+Rank: String+Requirements: String+input: Input+graphics: Graphics

+name:String+CPU: double+memory: double+Rank: String+Requirements: String+input: Input+graphics: Graphics

OSOS

+kernel: String+initdr: String+kernel_cmd: String+root: String+boot: String

+kernel: String+initdr: String+kernel_cmd: String+root: String+boot: String

DiskDisk

+type: String+source: String+target: String +bus: String+readOnly: boolean

+type: String+source: String+target: String +bus: String+readOnly: boolean

NICNIC

+mac: String+bridge: String+target: String+script: String

+mac: String+bridge: String+target: String+script: String

context Association

inv:

manifest .vm −> forAll ( v | depdescriptor . exists( d | d.name = v. id &&

d.memory = v.virtualhardware.memory && d. disk. source =

(manifest.refs.file −>asSet() −> select (id = v. id))−>first().href . . .

)

Virtual Execution Environment


Elasticity Rule Management

MonitoringAgent

MonitoringAgent

WebDispatcherWebDispatcher

DialogInstanceDialogInstance

CentralInstanceCentralInstance

DBMSDBMS

LocalProcessLocalProcess

MonitoringEventMonitoringEvent

RuleEngineRuleEngine

VirtualMachineVirtualMachine ApplicationDescriptionApplicationDescription

ComponentComponent

KPIKPI

ManifestManifest

VEEMVEEM

OperationOperation

addVMaddVM deleteVMdeleteVM

migrateVMmigrateVM ……

ElasticityRuleElasticityRule

Application Domain Service Management Language Syntax

Application level monitor publishes measurements of Key Performance Indicators

Elasticity rules define resizing actions to undertake based on KPI conditions

context RuleInterpreter :: evaluate(expr: Expression): Real

post:

if expr.op.oclIsTypeOf(GreaterThan) then if self . evaluate((op. el −>first

()) > self . evaluate((op. el−>last ())

then result = 1 else result = 0 end if else

. . . .

endif


Concrete Syntax (Implementation)

Requirement CDDLM SDD OVF

Service Architecture description N Y Y

Hardware requirements N N Y

Software environment N N Y

Network topology N N Y/I

Virtualization Elasticity N N P

Migration constraints N N N

Portability N Y Y

Dependency Deployment N P P

Undeployment N Y Y

Customization N Y Y

Location Constraints N N N

Non-functional Security Support N N Y

Extensible Y Y Y

Open Standard Y Y Y

Existing support Y Y Y

Service Manifest requirementshave been evaluated against existing Service Definition Languages:

The Open Virtualisation Format (OVF), DMTF standard backed by XenSource and VMWare, was found to be the most suited

Extensions were needed: OVF is primarily suited for the initial deployment of fixed sized services

Y: Yes N: No P: Partial


OVF Additional Extensions

Extension Limitation in standard OVF for RESERVOIR

How the limitation is solved

Extension type

Elasticity Rules Service elasticity is not considered <ElasticityRulesSection> New section for standard OVF

Key Performance Indicators

KPI specification to trigger elasticity <KPIsSection> New section for standard OVF

Deployment

Constraints

No ability to specify constraints on deployment location and exclude specific zones

<DeploymentSection> New section for standard OVF

Affinity Requirements

How to specify that certain machines should be located in a same location (or not)

<AffinitySection> New section for standard OVF

Performance Objective

How to define the expected range of values that KPI measurements should fall in for SLA protection

<PerformanceObjectiveSection>

New section for standard OVF

Availability Requirements

How to specify availability guarantees for services

<AvailabilitySection> New section for standard OVF

Can specify scaling rules with an Event Condition Action format (simplified):

<VirtualSystem min=“0” max=“10”> <ElasticityArraySection> <Rule>

<KPIName>totalUsers</KPIName> <Window unit="mn">10</Window> <Frequency>60</Frequency> <Quota>20</Quota></Rule>


Service Management Infrastructure

Service ManifestService Manifest

KPIKPI

RulesRules

ParserParser

Lifecycle ManagerLifecycle Manager

HTTP ServerHTTP Server

Rules EngineRules Engine

Probe Probe

Probe Probe

Probe Probe

Central Instance

Dialog Instance

Dialog Instance

Disk ImagesMonitoring

Bus

Service Manager Cloud Provider

Deploy/Undeploy

Rules

Customization


Overview



Evaluation: Scientific Grid Computing

Scientific grid application deployed on Cloud infrastructure – polymorph prediction:- Involves a number of grid and web based services to trigger and monitor the

search – up to 7200 executions of fortran programs

Objective: If software architecture is correctly described - can we obtain:- An equivalent quality of service than that of a dedicated environment

- Reduced resource consumption through elasticity rule definitions

Testbed: six servers, Quad-Core AMD Opteron(tm) Processor 2347 HE CPU and 8 GBs of RAM and with shared storage via NFS.


RESERVOIR Service management system


GridSAMCondor

Job starter

InputExec..

Orchestration Service

Grid Management

Service

ExecutionNode

VMDynamic scaling

Physicalresources

Condor Scheduler

Web Server

Web Server

BPEL

Front End

Jobqueue


RESERVOIR Service management system

GridSAMCondor

Job starter

InputExec..

Orchestration Service

Grid Management

Service

ExecutionNode

VMDynamic scaling

Physicalresources

Condor Scheduler

Web Server

Web Server

BPEL

Front End

Jobqueue

Service elasticity:

Scale number of cluster nodes according to jobs in queue:

- Monitoring agent provides job queue information KPI

- Manifest defines upscaling and downscaling rules e.g.:

If (queusize / instances ) > 4-> deploy(executeNode)



Evaluation: Results

Full turn around time for overall grid search:

Dedicated service (static): 2h23 Elastic provisioning: 2h39 (+7%)

Resource Cost saving for single run: 34% - over a week: 69.18%


Acknowledgments

RESERVOIR consortium : http://www.reservoir-fp7.eu OpenNebula: http://www.opennebula.org UCL-MDA tools: http://uclmda.sourceforge.net/

Technology

Software Architecture Definition for On-demand Cloud Provisioning