An Architecture for a Mashup Container in Virtualized Environments Massimo Maresca Computer Platform Research Center (CIPI) University of Padova & Genova (Italy) [email_address]
The Mashup Container
The monolithic solution in Virtualized Environments
1. Introduction (1/4)
High availability of contents and services (often provided according to the Software as a Service - SaaS model) through different technologies such as RSS Feed, Atom, JSON, REST-WS, SOAP-WS, etc.
Availability of tools for the rapid development of convergent Composite Services (a.k.a. Mashups) that combine different resources such as Yahoo Pipes!, JackBe Presto, etc.
Such tools mainly support Data Mashups (i.e., those Mashups that combine data extracted by different sources), while they do not support Event Driven Mashups (i.e., those Mashups in which the basic components interact through events)
Adoption of the Cloud Computing paradigm for Service Delivery. In this presentation we mainly refer to the PaaS (Platform as a Service) model.
We describe an architecture for a Mashup Container that allows to execute Mashups according to the PaaS model.
1. Introduction (2/4)
Service Taxonomy and Mashup Patterns: the “Monitor Resource + Notification” pattern
Notification of interesting events Mashup
1. Introduction (3/4)
Service Taxonomy and Mashup Patterns: the “Monitor Resource + Processing + Notification” pattern
Time or Location or Presence dependent Notification Mashup
Non repudiation Mashup
1. Introduction (4/4)
Service Taxonomy and Mashup Patterns: traditional Data Mashup and “something” + Map Mashup
Traffic on Map
Wheather on Map
2. The Mashup Container (1/7)
Server Side versus Client Side
The use of the Server Side Solution is preferable for the following reasons:
User Terminal power consumption
Client side Server side Svc1 Svc2 Svc3 User Node (Browser) Svc1 Svc2 Svc3 Browser (User) Mashup Engine (Server) Request Results
2. The Mashup Container (2/7)
A Mashup is created by means of a (possibly graphical) Service Creation Environment and stored as a XML file in a repository.
The new Mashup is deployed into a software system - the Service Execution Platform – that is in charge of executing the composite services.
The Mashup is now ready to be used by final users. There are two phases to take into account:
Activation: the SEP is configured by the user (i.e., he sets the input properties of the service) to be ready to execute the Mashup when a new initial event occurs.
Execution: when a Mashup previously activated by the user receives a new initial event, the actual execution of the service logic takes place.
2. The Mashup Container (3/7)
Requirements for the Mashup Container
Deployment support according to the PaaS model
Automatic Scalability , to support the simultaneous execution of a very large numbers of Mashup instances on variable size hardware systems.
Fault Tolerance , to guarantee the levels of reliability and availability typical of the Telecoms Operators (99.99999%).
Low latency , to effectively support also the execution of long sequences short lived Telco services.
Authentication, Authorization and Accounting , to support the seamless integration of the Mashup with the AAA modules already existing in the owner’s platform environment.
Management, to have the complete control of the platform resources, to control Mashup activation/execution as well as to allow the platform administrator to perform the appropriate management actions (e.g., enforcing SLA rules).
2. The Mashup Container (4/7)
Description of the Mashup Container
The Mashup Container is composed by two sub-systems:
The Deployment Module manages the installation of new components in the SEP. It is composed by two sub-modules, namely:
Mashup Deployer (i.e., translation of an XML file)
Service Deployer (i.e., interaction with the JAVA classloading system for the addition of new JAVA classes)
The Service Execution Platform is composed by two software entities (see figure in next slide):
The Service Proxy – SP: it wraps an external resource to make it compliant with the APIs used by the Orchestrator (invokeAction / notifyEvent)
The Orchestrator: it executes the Mashups’ logics combining the available SPs
2. The Mashup Container (5/7)
Two approaches for the Container implementation:
Framework-based solution (distributed approach)
Monolithic solution (all-in-one-JVM approach)
2. The Mashup Container (6/7)
Framework-based Mashup Container implementation
Technology: Java Message Service – JMS
Implementation used: Red Hat JBoss Application Server
Deployment module: Application Server dependent
Latency: 85% of the processing time needed to handle a single request is waste in framework operations (e.g., message parsing, queues management, communication delay, etc.)
Monolithic-based Mashup Container implementation
Technology: POJO (Plain Old JAVA Objects)
Implementation used: JDK version 6
Deployment module: development of a new classloader JAVA class
Latency: x8 times faster than framework based
2. The Mashup Container (7/7)
Comparison between the two solutions
Framework-based version Monolithic 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
3. The monolithic solution in Virtualized Environments (1/3)
Replication of the monolithic SEP (called Service Processor VM).
Session level scalability: each Session is completely executed on a single VM.
The Orchestration Management System – OMS manages Session Launching on the basis of the resources available in the system.
The OMS is in charge of adding / removing VMs in the system on the basis of the workload.
The fault tolerance requirement is fulfilled by means of the Hypervisor-based Fault Tolerance mechanism provided by the Virtualized Environment (see next slide for details).
3. The monolithic solution in Virtualized Environments (2/3)
The Hypervisor based Fault Tolerance mechanism provided by VMware
Two VMs (namely the Primary and the Secondary/Backup VM) run in lockstep on two distinct physical hosts.
The two VMs are connected through Logging Traffic network link.
The two VMs run independently but only the Primary VM actually communicates with the external world.
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 with zero downtime.
Source: VMware whitepaper “Protecting Mission-Critical Workloads with VMware Fault Tolerance”
3. The monolithic solution in Virtualized Environments (3/3) Performance test Testbed Hosts: IBM Blade Center HS22 (2 Intel E5530 processors at 2,4 GHz, 32GB RAM) Guest OS: Red Hat Enterprise Linux 5.4 64 bit Results The performance degradation is negligible Latency Avg (µs) Throughput (Events/sec) Log. Traffic (KB/sec) SEP FT On 82 15948870 761 SEP FT Off 60 16187340 Not Applicable
We defined a Mashup Container that allows users to deploy their Composite Services according to the PaaS model.
We described an architecture that leverages on the functionalities provided by the Virtualized Environments to fulfill the scalability and fault tolerance requirements.
We developed a prototype of the Architecture that we have defined based on the vmWare commercial product.
We performed some evaluating tests showing that the Hypervisor-base Fault Tolerance mechanism is suitable for the implementation of this kind of platforms.