Adaptive SLA-aware Cloud Federations

Attila Kertész (SZTAKI), Ivona Brandic (TUW), Gabor Kecskemeti (SZTAKI), Marc Oriol (UPC),

S-Cube Industry Workshop, Thales, France Feb. 24, 2012.

www.s-cube-network.eu

© S-Cube – 2

Introduction

• Highly dynamic service environments require a novel infrastructure to handle on demand deployment and decommission of service instances.

• Cloud Computing allows:

• Outsourcing these dynamic environments

• Constructing extensible service-based applications

• Utilizes the latest achievements of Grid Computing, Service-oriented computing, business-processes and virtualization

• Virtual Appliances encapsulate metadata with a complete system (OS, libraries and applications)

• Infrastructure cloud systems (IaaS) allow to instantiate VA’s on their virtualized resources: Virtual Machines

• Several public and private IaaS systems co-exist

• Only a “Federated Cloud” could offer the different capabilities as a whole

Repository

VA VA VA

Infrastructure as a Service Cloud

Host VMM

Host VMM

Host VMM

Host VMM

Host VMM

Host VMM

Host VMM

Host VMM

2. Delivery

IaaS utilization steps

VA Host

VMM

VA

Insta

ntiation

VM

Virtual

Appliance

Service Libs

+

OS

Support

Environment

© S-Cube – 3

1. Upload

3. Deployment

4. Access

© S-Cube – 4

Federated Cloud Management (FCM)

• An autonomic resource management solution

• Provides an entry point to a cloud federation

• Provides transparent service execution for users

• Following challenges are considered:

• Varying load of user requests

• Enabling virtualized management of applications

• Establishing interoperability and provider selection

• Minimizing Cloud usage costs

• Builds on meta-brokering, cloud brokering and automated on-demand service deployment

• Layered architecture

• Meta-broker

• Cloud Brokers

• Cloud infrastructure providers

Cloud

Cloud

Cloud Cloud FCM

A. Cs. Marosi, G. Kecskemeti, A. Kertesz, P. Kacsuk, FCM: an Architecture for Integrating IaaS

Cloud Systems, In Cloud Computing 2011, IARIA, pp. 7-12, Rome, Italy, 2011.

© S-Cube – 5

FCM Architecture: overview

CloudBroker

Clouda

FCM

Repository

Cloudb

• Top-level brokering

• Autonomously manage

the interconnected

cloud infrastructures

• Forms a federation with

the help of Cloud

Brokers

Generic Meta-Broker Service

CloudBroker

1

G. Kecskemeti, A. Kertesz, A. Marosi, P. Kacsuk, Interoperable Resource Management for establishing Federated

Clouds, In Achieving Federated and Self-Manageable Cloud Infrastructures: Theory and Practice, IGI Global (USA), 2011.

© S-Cube – 6

FCM Architecture: overview

CloudBroker

Clouda

FCM

Repository

Cloudb

• Manages VA

distribution among the

various cloud

infrastructures

• Automated federation-

wide repository content

management

• Offers current VA

availability and

estimates its future

deployment

Generic Meta-Broker Service

CloudBroker

2

© S-Cube – 7

FCM Architecture: overview

CloudBroker

Clouda

FCM

Repository

Cloudb

• Interacts with a single

IaaS system

• Manages resources

• Schedules service calls

Generic Meta-Broker Service

CloudBroker

3 3

© S-Cube – 8

Generic Meta-Broker Service

FCM

Repository

VAx..VAy

Cloudc

Generic Meta-Broker Service

CloudBroker

IS Agent

Meta-Broker

Core

MatchMaker Invoker

Information

Collector

BPDL list

Service call

(+requierments) Call result

Cloudb

CloudBroker

Clouda

CB

• BPDL – Broker Property

Description Language

• Cloud Brokers are

described

• Basic and aggregated

dynamic properties

• Estimated availability time

for a specific VA in the

native repository

• Average VA deployment

time

• Scheduling filters and

ranks Cloud Brokers

© S-Cube – 9

Cloud Broker

CloudBroker a

Q1

Clouda

VMQx

Clouda

VMQy

VAx VAy

VMx1

VMx2

VMxn

Clouda

…

VMy1

VMy2

VMym

…

Clouda VM Handler

Native R

epository

Generic Meta-Broker Service

FCM

Repository

VAx..VAy

• Dynamic requirements

may be specified with a

service call

• Treated as a new VA type

• Some IaaS systems offer

predefined classes of

resources

• Resource class selected

with at least the required

resources

© S-Cube – 10

Cloud Broker: Scheduling of service calls

• The Cloud Broker performs scheduling of service calls to

resources (VMs)

• Based on the monitoring information gathered

• May decide to start new resources based on:

• The number of running VM’s to handle the service call

• The number of waiting service calls in the Service call queue

• The average execution time of service calls

• The average deployment time of VA’s

• SLA constraints

• VM decommission

• Takes into account the “billing period”

Service monitoring with SALMon

• Service Level Agreement Monitor (SALMon): designed for

monitoring QoS of software services

• Capable of passive monitoring and testing purposes

• Supports any type of service technology (SOAP-based WS,

RESTful services, etc.)

• It is itself an SBA with two main components:

• Monitor: retrieves values of quality metrics with the help of Measure

Instruments

• Analyzer: evaluates conditions over these metrics

• It is suitable for monitoring running services in Cloud infra-

structures

© S-Cube – 11

The SALMon service monitoring framework

© S-Cube – 12

© S-Cube – 13

Integrated Monitoring Approach for Seamless Service Provisioning (IMA4SSP)

© S-Cube – 14

IMA4SSP details

• We have integrated SALMon to enable performance-driven SLA-based service executions in Cloud federations

• Metrics related to service methods may be defined to monitor service operations

• Metric values are regularly refreshed in the Generic Service Registry (GSR) of the architecture

• Finally information stored in the GSR are used by the GMBS for Cloud infrastructure selection based on service reliability

A. Kertesz, G. Kecskemeti, M. Oriol, A. Marosi, X. Franch, J. Marco, Integrated Monitoring Approach for

Seamless Service Provisioning in Federated Clouds, Proc. of PDP '12, IEEE CS, 2012.

© S-Cube – 15

Enhanced monitoring with M3S

• SALMon reports

service metrics to

a DB regularly

checked by the

meta-broker

• The Minimal Metric

Montoring Service

(M3S) is used to

monitor:

• Availability;

• Computing

capability;

• and data transfer

reliability.

GMBS Users

CloudBroker

Amazon

CloudBroker

OpenNebula

SALMon

VM

1. Test

metrics

3. Fetch

reliability

info

2. Send

results

SALMon

DDBB

M3S

Miminizing monitoring costs

© S-Cube – 16

• Keeping the monitoring VMs in the Cloud can be costly

• To reduce these costs, the IS Agent component of GMBS has been extended to initiate the deployment and decommission of these VMs

• The monitored metric values have timestamps

• When the retrieved metric value of a service is outdated, the IS Agent contacts the responsible Cloud Broker to initiates a M3S and SALMon VM deployment

• When metric values with new timestamps are read from the registry, the IS Agent contacts the CB again, to decommission the monitoring VMs

Autonomous behavior

• Inter-Cloud management for optimized resource usage and SLA violation prevention

• Predefined set of reactive actions in the Knowledge management system requiring local/global intervention in the system

• Adaptation actions are triggered by a rule-based system, based on monitored metrics

© S-Cube – 17

Action Involved Component Integration

Reschedule calls Meta-Broker Global

Rearrange VM queues Cloud-Broker Global

Extend/Shrink VM Queue Cloud-Broker Local

Rearrange VA storage FCM repository Global

Self-Initiated Deployment Service instances Local

Hybrid knowledge management in FCM

© S-Cube – 18

Hybrid approach for incorporting a Knowledge Management System to FCM: global and local

Allows global control over local decisions

Global KM could stop the application of a locally optimal action to avoid an autonomic chain reaction

Enables the execution of more fine-grained actions postponing adaptation action exhaustion

G. Kecskemeti, M. Maurer, I. Brandic, A. Kertesz, Zs. Nemeth, and S. Dustdar,

Facilitating self-adaptable Inter-Cloud management, Proc. of PDP '12, IEEE CS, 2012.

VM

qu

eu

e

rea

rra

ng

em

ents

a

nd

q

ue

ue

e

xte

nsio

n/s

hrinkin

g

Monitored metrics C

all

reschedulin

g

rea

rrang

ing

VA

sto

rag

e

- Service call queue length in every Cloud-Broker

- VM queue length for every appliance in every Cloud-Broker

- Call throughput

- Average waiting time for particular service

- Average waiting time of a queue

- Number of service (s) instances in an IaaS system (x): vms(x,s)

- Call/VM ratio

- overall infrastructure load

- Global storage cost

© S-Cube – 19

© S-Cube – 20

Conclusions

• We have designed a Federated Cloud Management solution that acts as an entry point to cloud federations

• Meta-brokering, cloud brokering and on-demand service deployment

• We have shown how Cloud Brokers manage the number and location of VMs for the various service requests

• We have extended FCM with enhanced SLA monitoring capabilities with the SALMon framework in collaboration with Universitat Politecnica de Catalunya (UPC)

• We have developed a method to enable SLA-aware self-adaptable Inter-Cloud management with a rule-based knowledge model in collaboration with the Technical University of Vienna (TUW)

Relation to S-Cube learning packages

• The presented work is related to the following packages:

• JRA-1.2: Service Level Agreement based Service infrastructures in the context of multi layered adaptation

• JRA-2.3: SLA-based Service Virtualization in distributed, heterogenious environments

• The following research topics are covered:

• T-JRA-2.3.1: Infrastructure Mechanisms for the Run-Time Adaptation of

Services

• T-JRA-1.2.2: Integrated Adaptation Principles, Techniques and Methodologies

• T-JRA-1.2.3: Comprehensive, Context-Aware Monitoring

Thank You for your attention!

Questions?

https://www.lpds.sztaki.hu/CloudResearch

© S-Cube – 22