cloud 2010

cipi

Centro di Ricerca sull’Ingegneria delle Piattaforme Informatiche

11

An Architecture for a Mashup Container in An Architecture for a Mashup Container in Virtualized EnvironmentsVirtualized Environments

Massimo MarescaComputer Platform Research Center (CIPI)

University of Padova & Genova (Italy)

[email protected]

cipi


22

AgendaAgenda

1.1. IntroductionIntroduction

2.2. The Mashup ContainerThe Mashup Container

3.3. The monolithic solution in Virtualized The monolithic solution in Virtualized EnvironmentsEnvironments

4.4. ConclusionsConclusions

cipi


33

1. Introduction (1/4)1. Introduction (1/4)

ScenarioScenario High availability of contents and services (often provided High availability of contents and services (often provided

according to the Software as a Service - SaaS model) through according to the Software as a Service - SaaS model) through different technologies such as RSS Feed, Atom, JSON, REST-different technologies such as RSS Feed, Atom, JSON, REST-WS, SOAP-WS, etc.WS, SOAP-WS, etc.

Availability of tools for the rapid development of convergent Availability of tools for the rapid development of convergent Composite Services (a.k.a. Mashups) that combine different Composite Services (a.k.a. Mashups) that combine different resources such as Yahoo Pipes!, JackBe Presto, etc. resources such as Yahoo Pipes!, JackBe Presto, etc. Such tools mainly support Such tools mainly support Data MashupsData Mashups (i.e., those Mashups that (i.e., those Mashups that

combine data extracted by different sources), while they do not support combine data extracted by different sources), while they do not support Event Driven MashupsEvent Driven Mashups (i.e., those Mashups in which the basic (i.e., those Mashups in which the basic components interact through events)components interact through events)

Adoption of the Cloud Computing paradigm for Service Delivery. Adoption of the Cloud Computing paradigm for Service Delivery. In this presentation we mainly refer to the PaaS (Platform as a In this presentation we mainly refer to the PaaS (Platform as a Service) model.Service) model.

We describe an architecture for a Mashup Container that We describe an architecture for a Mashup Container that allows to execute Mashups according to the PaaS model.allows to execute Mashups according to the PaaS model.

cipi


44


Service Taxonomy and Mashup Patterns: the “Monitor Service Taxonomy and Mashup Patterns: the “Monitor Resource + Notification” patternResource + Notification” pattern

Examples: Examples: Reminder MashupReminder Mashup Alert MashupAlert Mashup Notification of interesting events MashupNotification of interesting events Mashup

cipi


55


Service Taxonomy and Mashup Patterns: the “Monitor Resource + Service Taxonomy and Mashup Patterns: the “Monitor Resource + Processing + Notification” patternProcessing + Notification” pattern

Examples: Examples: Time or Location or Presence dependent Notification MashupTime or Location or Presence dependent Notification Mashup Non repudiation MashupNon repudiation Mashup

cipi


66

1. Introduction (4/4)1. Introduction (4/4)Service Taxonomy and Mashup Patterns: traditional Data Mashup and Service Taxonomy and Mashup Patterns: traditional Data Mashup and

“something” + Map Mashup“something” + Map Mashup

Examples:Examples:• Data FusionData Fusion• Data MigrationData Migration• … …

Examples:Examples:• Traffic on MapTraffic on Map• Wheather on MapWheather on Map• … …

cipi


77

2. The Mashup Container (1/7)2. The Mashup Container (1/7)Server Side versus Client SideServer Side versus Client Side

The use of the Server Side Solution is preferable for the The use of the Server Side Solution is preferable for the following reasons: following reasons:

Service continuityService continuity User Terminal power consumptionUser Terminal power consumption SecuritySecurity

Client side

Server side

Svc1Svc2

Svc3User Node (Browser)

Svc1

Svc2

Svc3Browser (User)

Mashup Engine (Server)Request

Results

cipi


88

2. The Mashup Container (2/7)2. The Mashup Container (2/7)Mashup LifecycleMashup Lifecycle

1.1. A Mashup is created by means of a (possibly graphical) A Mashup is created by means of a (possibly graphical) Service Service Creation EnvironmentCreation Environment and stored as a XML file in a repository. and stored as a XML file in a repository.

2.2. The new Mashup is deployed into a software system - the The new Mashup is deployed into a software system - the Service Service Execution PlatformExecution Platform – that is in charge of executing the composite – that is in charge of executing the composite services.services.

3.3. The Mashup is now ready to be used by final users. There are two The Mashup is now ready to be used by final users. There are two phases to take into account:phases to take into account: Activation:Activation: the SEP is configured by the user (i.e., he sets the the SEP is configured by the user (i.e., he sets the

input properties of the service) to be ready to execute the input properties of the service) to be ready to execute the Mashup when a new initial event occurs.Mashup when a new initial event occurs.

Execution:Execution: when a Mashup previously activated by the user when a Mashup previously activated by the user receives a new initial event, the actual execution of the service receives a new initial event, the actual execution of the service logic takes place.logic takes place.

cipi


99

2. The Mashup Container (3/7)2. The Mashup Container (3/7)

Requirements for the Mashup Container Requirements for the Mashup Container

1.1. Deployment support Deployment support according to the PaaS modelaccording to the PaaS model2.2. Automatic Automatic ScalabilityScalability, to support the simultaneous execution of a very , to support the simultaneous execution of a very

large numbers of Mashup instances on variable size hardware large numbers of Mashup instances on variable size hardware systems.systems.

3.3. Fault ToleranceFault Tolerance, to guarantee the levels of reliability and availability , to guarantee the levels of reliability and availability typical of the Telecoms Operators (99.99999%).typical of the Telecoms Operators (99.99999%).

4.4. Low latencyLow latency, to effectively support also the execution of long , to effectively support also the execution of long sequences short lived Telco services.sequences short lived Telco services.

5.5. Authentication, Authorization and AccountingAuthentication, Authorization and Accounting, to support the , to support the seamless integration of the Mashup with the AAA modules already seamless integration of the Mashup with the AAA modules already existing in the owner’s platform environment.existing in the owner’s platform environment.

6.6. Management,Management, to have the complete control of the platform resources, to have the complete control of the platform resources, to control Mashup activation/execution as well as to allow the platform to control Mashup activation/execution as well as to allow the platform administrator to perform the appropriate management actions (e.g., administrator to perform the appropriate management actions (e.g., enforcing SLA rules).enforcing SLA rules).

cipi


1010


Description of the Mashup Container Description of the Mashup Container

The Mashup Container is composed by two sub-systems:The Mashup Container is composed by two sub-systems:

The The Deployment Module Deployment Module manages the installation of new manages the installation of new components in the SEP. It is composed by two sub-modules, namely:components in the SEP. It is composed by two sub-modules, namely: Mashup Deployer (i.e., translation of an XML file)Mashup Deployer (i.e., translation of an XML file) Service Deployer (i.e., interaction with the JAVA classloading system for the Service Deployer (i.e., interaction with the JAVA classloading system for the

addition of new JAVA classes)addition of new JAVA classes)

The The Service Execution PlatformService Execution Platform is composed by two software entities is composed by two software entities (see figure in next slide):(see figure in next slide): The Service Proxy – SP: it wraps an external resource to make it compliant with The Service Proxy – SP: it wraps an external resource to make it compliant with

the APIs used by the Orchestrator (invokeAction / notifyEvent)the APIs used by the Orchestrator (invokeAction / notifyEvent) The Orchestrator: it executes the Mashups’ logics combining the available SPsThe Orchestrator: it executes the Mashups’ logics combining the available SPs

cipi


1111


Two approaches for the Container implementation: Two approaches for the Container implementation: Framework-based solution (distributed approach)Framework-based solution (distributed approach) Monolithic solution (all-in-one-JVM approach)Monolithic solution (all-in-one-JVM approach)

cipi


1212


Framework-based Mashup Container implementationFramework-based Mashup Container implementation Technology: Java Message Service – JMSTechnology: Java Message Service – JMS Implementation used: Red Hat JBoss Application ServerImplementation used: Red Hat JBoss Application Server Deployment module: Application Server dependentDeployment module: Application Server dependent Performance: Performance:

Latency: 85% of the processing time needed to handle a single request is waste in Latency: 85% of the processing time needed to handle a single request is waste in framework operations (e.g., message parsing, queues management, framework operations (e.g., message parsing, queues management, communication delay, etc.) communication delay, etc.)

Monolithic-based Mashup Container implementationMonolithic-based Mashup Container implementation Technology: POJO (Plain Old JAVA Objects)Technology: POJO (Plain Old JAVA Objects) Implementation used: JDK version 6Implementation used: JDK version 6 Deployment module: development of a new classloader JAVA classDeployment module: development of a new classloader JAVA class Performance: Performance:

Latency: x8 times faster than framework based Latency: x8 times faster than framework based

cipi


1313

2. The Mashup Container (7/7)2. The Mashup Container (7/7)Comparison between the two solutionsComparison between the two solutions

Framework-based versionFramework-based version Monolithic versionMonolithic version

• Replicated instances of the Orchestrator and SPs are deployed on different nodes• A Session is usually executed on different nodes to balance the workload• Communication overhead due to the framework• Framework-based Fault Tolerance

• Each node runs a “complete” SEP• A Session is completely executed on one node• NO Communication overhead due to the framework (the components are implemented as POJO)• Fault Tolerance given by the Virtualization Environment

cipi


1414

3. The monolithic solution in Virtualized Environments (1/3)3. The monolithic solution in Virtualized Environments (1/3)

Replication of the monolithic SEP (called Service Replication of the monolithic SEP (called Service Processor VM). Processor VM).

Session level scalability: each Session is Session level scalability: each Session is completely executed on a single VM.completely executed on a single VM.

The Orchestration Management System – OMS The Orchestration Management System – OMS manages Session Launching on the basis of the manages Session Launching on the basis of the resources available in the system.resources available in the system.

The OMS is in charge of adding / removing VMs The OMS is in charge of adding / removing VMs in the system on the basis of the workload. in the system on the basis of the workload.

The fault tolerance requirement is fulfilled by The fault tolerance requirement is fulfilled by means of the Hypervisor-based Fault Tolerance means of the Hypervisor-based Fault Tolerance mechanism provided by the Virtualized mechanism provided by the Virtualized Environment (see next slide for details).Environment (see next slide for details).

Orchestration Management

System

Session Launcher

Orchestration Management

System

Session Launcher

Orchestrator

Service Proxies

Orchestrator

Service Proxies

Orchestrator

Service Proxies

Orchestrator

Service Proxies

Session Processor

VM

Service Processor

VMs

cipi


1515

3. The monolithic solution in Virtualized Environments (2/3)3. The monolithic solution in Virtualized Environments (2/3)

The Hypervisor based Fault Tolerance mechanism provided by VMwareThe Hypervisor based Fault Tolerance mechanism provided by VMware Two VMs (namely the Primary and the Secondary/Backup VM) run in lockstep on Two VMs (namely the Primary and the Secondary/Backup VM) run in lockstep on

two distinct physical hosts.two distinct physical hosts. The two VMs are connected through Logging Traffic network link.The two VMs are connected through Logging Traffic network link. The two VMs run independently but only the Primary VM actually communicates The two VMs run independently but only the Primary VM actually communicates

with the external world.with the external world. In case of a failure of the Primary VM, the Secondary VM replaces it and continues In case of a failure of the Primary VM, the Secondary VM replaces it and continues

the execution of the applications installed in the first VM in transparent way and the execution of the applications installed in the first VM in transparent way and with zero downtime.with zero downtime.

Source: VMware whitepaper “Protecting Mission-Critical Workloads with VMware Fault Tolerance”

cipi


1616

3. The monolithic solution in Virtualized Environments (3/3)3. The monolithic solution in Virtualized Environments (3/3)Performance testPerformance test

Testbed Testbed Hosts: Hosts: IBM Blade Center HS22 (2 Intel E5530 processors at 2,4 GHz, 32GB

RAM)Guest OS: Guest OS: Red Hat Enterprise Linux 5.4

64 bit

ResultsResultsThe performance degradation isnegligible

Latency Avg (µs)

Throughput (Events/sec)

Log. Traffic (KB/sec)

SEP FT On

82 15948870 761

SEP FT Off 60 16187340Not

Applicable

cipi


1717

4. Conclusions4. Conclusions

We defined a Mashup Container that allows users to We defined a Mashup Container that allows users to deploy their Composite Services according to the PaaS deploy their Composite Services according to the PaaS model.model.

We described an architecture that leverages on the We described an architecture that leverages on the functionalities provided by the Virtualized Environments functionalities provided by the Virtualized Environments to fulfill the scalability and fault tolerance requirements.to fulfill the scalability and fault tolerance requirements.

We developed a prototype of the Architecture that we We developed a prototype of the Architecture that we have defined based on the vmWare commercial product. have defined based on the vmWare commercial product.

We performed some evaluating tests showing that the We performed some evaluating tests showing that the Hypervisor-base Fault Tolerance mechanism is suitable Hypervisor-base Fault Tolerance mechanism is suitable for the implementation of this kind of platforms.for the implementation of this kind of platforms.

cipi


1818

Thank you for Thank you for your attentionyour attention

cloud 2010

Technology

mashup examples

mashup patterns

new mashup

repudiation mashup

mashup lifecycle

traditional data mashup

service model

service taxonomy