Cloud 2010
Upcoming SlideShare
Loading in...5
×
 

Cloud 2010

on

  • 653 views

 

Statistics

Views

Total Views
653
Views on SlideShare
653
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Cloud 2010 Cloud 2010 Presentation Transcript

    • An Architecture for a Mashup Container in Virtualized Environments Massimo Maresca Computer Platform Research Center (CIPI) University of Padova & Genova (Italy) [email_address]
    • Agenda
      • Introduction
      • The Mashup Container
      • The monolithic solution in Virtualized Environments
      • Conclusions
    • 1. Introduction (1/4)
      • Scenario
      • 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
      • Examples:
      • Reminder Mashup
      • Alert Mashup
      • Notification of interesting events Mashup
    • 1. Introduction (3/4)
      • Service Taxonomy and Mashup Patterns: the “Monitor Resource + Processing + Notification” pattern
      • Examples:
      • 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
      • Examples:
      • Data Fusion
      • Data Migration
      • Examples:
      • 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:
      • Service continuity
      • User Terminal power consumption
      • Security
      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)
      • Mashup Lifecycle
      • 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
      • Performance:
        • 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
      • Performance:
        • 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
    • 4. Conclusions
      • 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.
    • Thank you for your attention