SALSA: A Framework for Dynamic

Configuration of Cloud Services

Duc-Hung Le, Hong-Linh Truong, Georgiana Copil,

Stefan Nastic and Schahram Dustdar

Distributed Systems Group, Vienna University of Technology

http://www.infosys.tuwien.ac.at/research/viecom/

6th International Conference on Cloud Computing Technology and Science

Singapore, 15-18 December 2014

CloudCom 2014 2

Overview

Scenario

Research issues

Framework for dynamic configuration

Demo

Conclusions and future work

CloudCom 2014 3

Scenario - Complexity of configuration

(1) Interact

via web

interface

(I) Interact via

cloud API

(2) Access to

each VM by

SSH/VNC

> apt-get update

> vim configure.conf

> make clean install

Error !

(3) Configure

> service X start

> ./decommiss.sh

> ./register.sh

Warning !

(II) Configure

remotely via

SSH/JSch

Multiple IaaS

cloud providers

Service

developer

Elasticity

controller

CloudCom 2014 4

Scenario - Complexity of the cloud

service configuration

M2MDaaS topology

Topology 1 Topology 2IoT topology

Data controller

Data nodeLoad balancer

Event Processing

MOM

Sensor GatewayApplication

level

Legends:

Connect via network

CloudCom 2014 5

Scenario - Complexity of the cloud

service configuration

Linux

docker

Java

Linux

Java

Linux

Java

Linux

docker

Tomcat

Linux

Java

Linux

JavaOS/

Container

level

Legends:

Connect via network

Placed on

M2MDaaS topology

Topology 1 Topology 2IoT topology

Data controller

Data nodeLoad balancer

Event Processing

MOM

Sensor GatewayApplication

level

CloudCom 2014 6

Scenario - Complexity of the cloud

service configuration

Linux

docker

Java

Linux

Java

Linux

Java

Linux

docker

Tomcat

Linux

Java

Linux

JavaOS/

Container

level

Virtual

machine

level

m1.small

instance

m1.small

instance

c1.medium

instance

m1.medium

instance

Cloud infrastructure 1

Public

networkc1.medium

snapshot

instance

m1.large

instance

m1.medium

instanceCloud infrastructure 2

Legends:

Connect via network

Placed on

M2MDaaS topology

Topology 1 Topology 2IoT topology

Data controller

Data nodeLoad balancer

Event Processing

MOM

Sensor GatewayApplication

level

CloudCom 2014 7

Scenario - Complexity of the cloud

service configuration

Linux

docker

Java

Linux

Java

Linux

Java

Linux

docker

Tomcat

Linux

Java

Linux

JavaOS/

Container

level

Virtual

machine

level

m1.small

instance

m1.small

instance

c1.medium

instance

m1.medium

instance

Public

networkc1.medium

snapshot

instance

m1.large

instance

m1.medium

instance

Quick startup VMsHigh compute

intensive VMsLow price VMs High data

intensive VMs

M2MDaaS topology

Topology 1 Topology 2IoT topology

Data controller

Data nodeLoad balancer

Event Processing

MOM

Sensor GatewayApplication

level

CloudCom 2014 8

Requirements

Elasticity controllers– Fine-grained actions.

– Control all service levels.

– Manage the whole service.

Well-known tools- Chef, Puppet, Ansible…

- Google CDM, Slipstream,

Brooklyn, Juju …

- OpenTOSCA

Limitations- Support single configuration level.

- Need human interaction.

- Not support runtime configuration.

Multi-cloud environment

- Diversity

- Dynamicity

Service developers– Automate complex tasks.

– Manage only application level.

– Semantic service management.

CloudCom 2014 9

Research issues and Approach

Research questions- Full automated configuration for complex cloud services.

- Support multiple cloud infrastructures.

- Configure multiple software stacks: VM, container, webapp.

Approach– Capture information of multiple configuration levels:

• Cloud service structure

• Deployment information

– Coordinate of the configuration tasks by orchestration.

– Support many types of configuration on different levels.

CloudCom 2014 10

SALSA

Framework

Service configuration flow

Preprocess

Cloud systemsVM

Orchestrate

configuration

tasks

Bootstrap VMArtifact

deployment

Configure cloud

resourcesLifecycle

management

Configure VM

environment

Setup

configuration

environment

Configuration

plan

PUT [service_structure]

Configured service

Developer

POST [unit_ID, scaleout]

Controller

DELETE [instance_ID]

GET [serviceID]

CloudCom 2014 11

SALSA Framework architecture

Information services

– Provide services

information, e.g.

artifact, relationships

– Link to cloud

providers and external

repositories.

– Enable third parties

add configuration

capabilities to the

existing services.

Central service

– Orchestrate the

configuration tasks

– Interface with multiple

cloud providers.

– Plug-in configuration

algorithms

Local configurator

– Configure artifacts on VM.

– Interface with multiple

configuration tools.

CloudCom 2014 12

Capturing configuration information

Configuration

capability

categorized

Primitive

Add/remove

Complex

Start/stop

Reconfigure

Scale in/out

Redeploy

Migrate

associateDeployment stack

Cloud 1 Cloud N

Virtual machine

OS container

App container

Web service

associated

at runtime

…

Executable

Multiple service levels

Complex configuration capability

Multiple deployment stacks

[1] G. Copil, D. Moldovan, H.-L.

Truong, and S. Dustdar, “Multi-

level elasticity control of cloud

services,”, ICSOC 2013

Cloud service

Service topology

Service unit

Service instance

consist of

consist of consist of

consist of depend-on

CloudCom 2014 13

Generating deployment information

Enrich missing information

– Different service types.

– Based on many criteria.

Service unit eco-system

– Connect to clouds

– Service relationships

Plugin-able enrichment

algorithms

– Enrich based on

configuration capabilities.

– Determine the relationship

between service units.

• Hosted-on relationship

• Connect-to relationship

CloudCom 2014 14

Orchestrate configuration tasks

Maintain the dependencies and the order of tasks.

– Tasks can be executed in parallel.

– Forward tasks to the right configurator module to execute.

Plugin-able module for develop different algorithms

– Distributed orchestration.

– Workflow, plan-based.

Service unit

orchestrator

..Service unit

orchestrator

Cloud service

orchestrator

Service unit

orchestrator

actuate

actions

update

states

Topology of

service units

task

task

task

Web app.

configurator

Container

configurator

System service

configurator

Virtual machine

configurator

Interface for

applications

configuration

Interface for

cloud systems

configuration

Environment

configurator

CloudCom 2014 15

Service placement at runtime

Placement

– Decide where to place the service unit.

– Automatic manage the configuration of container and infrastructure.

Placement algorithms:

– Optimal for resource usage or

performance.

– Multi-tenant problem.

Plugin-able module

– Instance number based.

– Resource threshold based.

CloudCom 2014 16

Managing configuration states

Configuration states information

– Manage the dependencies between configuration tasks.

– Represent service lifecycle

– Feed-back to users.

Collecting state information

– States from many configuration levels

– States of service structure

Aggregating states on multiple

levels and stacks

– A configuration task exposed its state.

– State of cloud service and topology

are collected from service units.

CloudService

Allocating

Docker

configuring

Tomcat

allocating

VM

deployed

FrontEnd topo

Allocating

BackEnd topo

Running

Webapp 1

Allocating

App 1

Running

App 2

deployed

Actual

configuration

states

Aggregated

configuration

states

CloudCom 2014 17

SALSA Prototype

Interface with multiple cloud providers

– OpenStack: by Jclouds

– Flexiant: by Flexiant JADE API

– StratusLab: by StratusLab client command line

– Non-providers: configure existing machine

Interface with multiple configuration tools

– Script-based: bash

– Unix like packages: apt-get, yum, gem

– Chef enterprise and chef-solo

Specific containers and artifact support

– Tomcat, Docker

– Web application in .war artifact

TOSCA

service

definition

SALSA

• Set of VMs running.

• Cloud service

runtime structure.

• Unit configuration.

CloudCom 2014 18

Tested services

Sensors

- ~3000 lightweight instances

- On 3 clouds and normal servers

- Dynamic add/remove

M2MDaaS

- Complexity: 8 units, 3 topologies

- Running on 2 cloud systems

EventProcessing DataEnd

DSG OpenStack

- Private cloud

- Vienna

Flexiant

- Public cloud

- Commercial

- London

StratusLab

- Public cloud

- For research

- Paris

Marsa

- Connect with external services

- Distributed sites: Euro and Asia

Market Place

+ databaseIot.eclipse.org

Data customer

Sensor

Normal servers

- Hanoi and HCM

city, Vietnam

- Vienna

Controller

DataNode

EventProcessor

LB MOM

Gateway

GW

Sensor

MQTT

Internet

Sensor

Iot.eclipse.org MQTT Gateway

Scalable unit Static unit External service

CloudCom 2014 19

Examples and demo

Demo 1: Simplify complex configuration management

– M2MDaaS: 3 topologies, 7 service units.

– Multiple clouds:

• OpenStack private cloud

• Flexiant public cloud.

– Connect sensors into the running M2MDaaS.

– Maintain service units dependencies.

Demo 2: Enable dynamic and multiple levels configuration

– Focus on one topology of the M2MDaaS

– Enable complex operations at runtime: scale in, scale out.

– Enable configuration at infrastructure and application level.

CloudCom 2014 20

Conclusions and future work

Conclusion

– Introduce a framework for developing and experimenting

advanced configuration functionalities.

– Provide initial features for full automatic and dynamic

configuration of cloud services.

– Support single cloud and multiple clouds.

Future work: Focus more on the configuration of

application level

– Understand more configuration relationships of multiple levels

and application structure.

– Optimize the configuration at application level.

THANK YOU !

Duc-Hung Le

d.le@dsg.tuwien.ac.athttp://dsg.tuwien.ac.at/staff/dle/

Prototypes available http://tuwiendsg.github.io

Distributed Systems GroupVienna University of Technology

Austria