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+D
The research leading to these results has been partially funded by the European
Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 215605.

Overview

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

Software Architecture Definition for On-demand Cloud Provisioning

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

Presentation
SAP GUI
SAP GUI SAP GUI
Browser Three tier architecture:

 Database (DBMS)
 Central Instance (CI)
– Enqueue server
providing a high level
DI
DI CI DI
DI
Application locking mechanism
(data consistency)
– Messaging server for
load balancing
 Dialog Instance
– User request processing
DBMS
Database – Data record updates
– Batch processing



SAP GUI
SAP GUI SAP GUI
Browser
Presentation

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

- DBMS: large storage requirements
Application DI
DI CI DI
DI - DI: Processor intensive

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

Customization: Locations must be
provided at run-time.
DBMS
Database



SAP GUI
SAP GUI SAP GUI
Browser
Presentation

Application DI
DI CI DI
DI
Deployment dependencies: DBMS
and CI must be run first.

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



SAP GUI
SAP GUI SAP GUI
Browser
Presentation

Application DI
DI CI DI
DI DI DI

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

Resource requirements directly proportional
to concurrent sessions.


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


RESERVOIR Goals
 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

Infrastructure OIR Solutions
RV
SE
RE


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 …

Software April, 2009 Definition forY1 Project Review
1-2 Architecture On-demand Cloud Provisioning 12

The RESERVOIR vision

Public cloud
Private cloud

Partner cloud


RESERVOIR Architecture
Service Provider supplies:
• Prepacked Service Components
• Enforces SLA compliance by adjusting (Virtual Machine)
application capacity: • Service Manifest
• Service Components Sizing (VEEs)
Separation + Business Orientation
• Service Tiers sizing
Service Provider
• Responsible for accounting and billing

SMI
Elasticity + Business Orientation + Trust + Security Manifest

• Optimizes VEE placement
subject to constraints Service Manager
• Deals with site federation
• Distributed as OpenNebula

VMI
SLA SLA

Federation + Elasticity + Trust + Security VMI VEE Manager (VEEM) VMI

• Translates generic commands
into specific virtualization platform

VHI
commands
• Creates and maintains isolated
virtual networks
• Enables efficient and secure access VEE Host (VEEH)
(e.g., Hypervisor, VJSC Host)
to remote storage
Reservoir Site
Isolation + Elasticity + 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
• …


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

Manifest Language Syntax Virtual Execution Environment

Manifest VirtualMachine OS

+refs: Reference[] +name:String +kernel: String
+disks: Disk[] +CPU: double +initdr: String
+nets: Network[] +memory: double +kernel_cmd: String
+vm: VirtualSystem[] +Rank: String +root: String
+Requirements: +boot: String
String
ApplicationDescription +input: Input
context Association
+graphics: Graphics
+comp: Components[]
+kpi: KPIs inv:
Disk
manifest .vm −> forAll ( v | +type: String
depdescriptor . exists( d | +source: String
d.name = v. id && +target: String
ElasticityRule
d.memory = v.virtualhardware.memory +bus: String
&&
+cond: Expression +readOnly: boolean
d. disk. source =
+kpi: KPIs
(manifest.refs.file −>asSet()
+action: Operation
−> select (id = v. id))−>first().href
. . .
NIC
)
+mac: String
+bridge: String
+target: String
+script: String


Elasticity Rule Management

Application Domain Service Management Language Syntax
MonitoringAgen
DialogInstance MonitoringEvent ElasticityRule
t

CentralInstance WebDispatcher KPI
RuleEngine

Component
DBMS

context RuleInterpreter ::
evaluate(expr: Expression): Real
ApplicationDescription
LocalProcess VirtualMachine VEEM
post:

 Application level monitor if expr.op.oclIsTypeOf(GreaterThan)
then Operation
publishes measurements of Manifest
if self . evaluate((op. el −>first
Key Performance Indicators ()) > self . evaluate((op.
el−>last ())
addVM deleteVM
then result = 1
 Elasticity rules define else result = 0
resizing actions to migrateVM end if … else
undertake based on KPI . . . .
conditions
endif


Deriving Java Code – Eclipse Plugin


Concrete Syntax (Implementation)

Requirement CDDLM SDD OVF
Service Manifest requirements
Service Architecture description N Y Y
have been evaluated against
Hardware requirements N N Y existing Service Definition
Software environment N N Y Languages:
Network topology N N Y/I
Virtualization Elasticity N N P
 The Open Virtualisation
Format (OVF), DMTF standard
Migration constraints N N N
backed by XenSource and
Portability N Y Y
VMWare, was found to be the
Dependency Deployment N P P most suited
Undeployment N Y Y
Customization N Y Y  Extensions were needed:
Location Constraints N N N OVF is primarily suited for the
Non-functional Security Support N N Y
initial deployment of fixed
sized services
Extensible Y Y Y
Open Standard Y Y Y
Existing support Y Y Y
Y: Yes N: No P: Partial


OVF Additional Extensions

Extension Limitation in standard OVF for How the limitation is Extension type
RESERVOIR solved
Elasticity Rules Service elasticity is not considered <ElasticityRulesSection> New section for
standard OVF
Key Performance KPI specification to trigger elasticity <KPIsSection> New section for
Indicators standard OVF
Can specify scaling rules with an Event
Deployment No ability to specify constraints on <DeploymentSection> New section for
deployment location and exclude Condition Actionstandard (simplified):
format OVF
Constraints
specific zones
<VirtualSystem min=“0” max=“10”>
Affinity How to specify that certain machines <AffinitySection> New section for
<ElasticityArraySection>
Requirements should be located in a same location (or <Rule> standard OVF
not) <KPIName>totalUsers</KPIName>
<Window unit="mn">10</Window>
Performance How to define the expected range of <PerformanceObjectiveS New section for
<Frequency>60</Frequency>
Objective values that KPI measurements should ection> standard OVF
<Quota>20</Quota>
fall in for SLA protection
</Rule>
Availability How to specify availability guarantees <AvailabilitySection> New section for
Requirements for services standard OVF


Service Management Infrastructure

Service Manager Cloud Provider

Deploy/Undeploy Central Instance
Service Parser
Manifest Probe

KPI Lifecycle Rules
Manager Rules Engine Dialog Instance

Rules
Probe

HTTP Server
Dialog Instance
Customization
Probe

Monitoring
Disk Images
Bus


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.



Front End Web Server
Input
Web Server GridSAM Exec
.. Condor
BPEL Condor Job
Scheduler Job starter
queue

Grid Execution
Orchestration Node
Service Management
Service VM
Dynamic scaling 

RESERVOIR Service management system

Physical
resources



Front End Web Server
Input
Web Server GridSAM Exec
.. Condor
BPEL Condor Job
Scheduler Job starter
queue

Grid Execution
Orchestration Node
Service Management
Service elasticity:
Service VM
Dynamic scaling 
Scale number of cluster nodes according to
RESERVOIR Servicein queue:
jobs management system

- Monitoring agent provides job queue
information KPI
Physical
- Manifest defines upscaling and downscaling
resources
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/


Software Architecture Definition for On-demand Cloud Provisioning

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to Software Architecture Definition for On-demand Cloud Provisioning (20)

Recently uploaded (20)

Software Architecture Definition for On-demand Cloud Provisioning

Editor's Notes