scalability patterns for platform as a service
Download
Skip this Video
Download Presentation
Scalability Patterns for Platform-As-A-Service

Loading in 2 Seconds...

play fullscreen
1 / 33

Scalability Patterns for Platform-As-A-Service - PowerPoint PPT Presentation


  • 62 Views
  • Uploaded on

2012 IEEE 5 th International Conference on Cloud Computing. Scalability Patterns for Platform-As-A-Service. Marco Ughetti Telecom Italia, TILab, Italy. Claudio A Ardagna, Ernesto Damiani, Fulvio Frate, Davide Rebeccani Universita degli Studi di Milano, Italy. 13 th November, 2012.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Scalability Patterns for Platform-As-A-Service' - hamlin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
scalability patterns for platform as a service

2012 IEEE 5th International Conference on Cloud Computing

Scalability Patterns for Platform-As-A-Service

Marco Ughetti

Telecom Italia, TILab, Italy

Claudio A Ardagna,

Ernesto Damiani,

Fulvio Frate,

Davide Rebeccani

Universita degli Studi di Milano, Italy

13th November, 2012.

Presented By,

Chidambara Nadig.

abstract
Abstract
  • Platform as a Service is a cloud based approach where enterprises have little to do with the underlying cloud infrastructure.
  • Installing, configuring and managing the underlying middleware, operating system and hardware is done by the cloud provider.
  • Thus, Scalability becomes an important factor to decide,
    • The capabilities of each virtual resource in the cloud.
    • The number of resources in the cloud.
  • This paper presents few Scalability Patterns for PAAS infrastructureand a method to automatically manage scalability.

Scalability Patterns for Platform-as-a-Service

iaas paas and saas
IAAS, PAAS and SAAS
  • IAAS – Infrastructure as a Service.
  • PAAS – Platform as a Service.
  • SAAS – Software as a Service.

Scalability Patterns for Platform-as-a-Service

levels of abstraction in cloud services
Levels of Abstraction in Cloud Services.

Scalability Patterns for Platform-as-a-Service

some examples
Some examples

Scalability Patterns for Platform-as-a-Service

actions on resource scaling
Actions on Resource Scaling
  • Vertical Scaling – Scale Up – Additional Resources are added to a single machine when the load increases. The resources can be either physical resources added to a server, or virtual resources dynamically assigned to a virtual machine or its applications.
  • Horizontal Scaling – Scale Out – New machines are added to the system providing more software and hardware resources.
  • Scale Down – Releasing Resources when they are not necessary.

Scalability Patterns for Platform-as-a-Service

scalability patterns
Scalability Patterns
  • Single Platform Pattern (SPP)
  • Shared Platform Pattern (ShPP)
  • Clustered Platform Pattern (CPP)
  • Multiple Shared Platform Patter (MShPP)
  • Multiple Clustered Platform Patter (MCPP)

Scalability Patterns for Platform-as-a-Service

single platform pattern spp
Single Platform Pattern (SPP)
  • Each customer is given a complete virtual machine with a platform installed on it. SPP is single tenant scenario.
  • Resource Utilization is scarce.
  • Scalability is low because the number of virtual machines and platforms is linear in the number of customers.

Scalability Patterns for Platform-as-a-Service

shared platform pattern shpp
Shared Platform Pattern (ShPP)
  • A Multitenant scenario.
  • One platform is installed on a set of virtual machines and is shared by multiple tenants.
  • Each tenant has a right to manage a portion of the platform and deploy their services on it independently.
  • Performance of the platform is maintained by up-scaling and down-scaling the resources assigned to the virtual machine.

Scalability Patterns for Platform-as-a-Service

slide11

Whenever the load increases – degrading the performance metrics of the platform – RAM, CPU, or bandwidth can be increased.

  • On the other hand, when the load decreases, resources can be freed and made available to other processes in the architecture.
  • In ShPP resources are shared and therefore need to be managed to ensure security and isolation among tenants.
  • Provides High utilization.
  • However, ShPP doesn’t provide linear scalability increase due to increased overheads for resource management.

Scalability Patterns for Platform-as-a-Service

clustered platform pattern cpp
Clustered Platform Pattern (CPP)
  • A single platform is deployed supporting clustering and is shared by all tenants.
  • Multiple instances of the platform components can be deployed in different machines of the cluster.
  • Similar to ShPP, CPP manages shared resources preserving security and isolation among tenants.
  • This pattern also implements load balancing, PAAS monitoring, and elastic auto-scaling.

Scalability Patterns for Platform-as-a-Service

slide13

CPP provides high resource utilization, since the machines in the cluster are shared among different tenants.

  • CPP provides some scalability as system resources can be incrementally extended.
  • The Clustered Platform Pattern also promises high reliability and availability due to increased redundancy.

Scalability Patterns for Platform-as-a-Service

multiple shared platform pattern mshpp
Multiple Shared Platform Pattern (MShPP)
  • MShPP is an extension of ShPP.
  • Initially a single Shared Platform is deployed.
  • Upon an increase in the load, additional resources (CPU, RAM or bandwidth) are assigned to maintain the performance metrics.
  • In case additional resources are not sufficient, a new platform is deployed and a part of the existing tenants are migrated to the new platform along with the resources they own.

Scalability Patterns for Platform-as-a-Service

slide15

When the load decreases, the additional platforms can be removed causing the tenants to migrate back to the available platforms.

  • MShPP has lower manageability than ShPP owing to the fact that tenants have to be migrated from one platform to another when a new platform is deployed.
  • MShPP provides high resource utilization.
  • Its scalability depends on the specific scenario and number of deployed platforms.
    • In the worst case, when all tenants experienced a traffic peak, a platform is deployed for each tenant and therefore scalability of MShPP is equivalent to the one of SPP.
    • In the average case, MShPP provides high scalability.

Scalability Patterns for Platform-as-a-Service

multiple clustered platform pattern mcpp
Multiple Clustered Platform Pattern (MCPP)
  • MCPP is an extension of CPP.
  • At initialization time, a single, shared, multi-tenant platform supporting clustering is deployed.
  • Upon an increase in the load, additional resources (i.e., machines in the cluster) are added to maintain the performance level.
  • In case the extended cluster is not sufficient to manage the new load, a new platform supporting clustering is deployed, and a part of the existing tenants are migrated to the new clustered platform together with the services they own.

Scalability Patterns for Platform-as-a-Service

slide17

When the load decreases, the additional platforms can be removed causing the tenants to migrate back to the available platforms.

  • MCPP has the lowest manageability among patterns.
  • MCPP usually provides high utilization of resources, although utilization may decrease in case of multiple platform deployments.
  • Promises
    • High Scalability.
    • High Availability.
    • High Reliability.

Scalability Patterns for Platform-as-a-Service

overview
Overview

Scalability Patterns for Platform-as-a-Service

performance measurement
Performance Measurement
  • Performance Metrics at the Platform Level
      • Total Count (TC) – Number of messages forwarded to a given end point. If the metrics exceeds a known threshold, the performance could be affected and an alarm is raised.
      • Fault Count (FC) – Number of messages that resulted in a fault while being forwarded to the end point.
      • Minimum Time (MinT)
      • Maximum Time (MaxT)
      • Average Time (AveT)

Time Taken to send a request to an end point and receive a response.

Scalability Patterns for Platform-as-a-Service

slide20

Performance Metrics at the Host Level

    • CPU Load (CL) – CPU Utilization on host and guest systems. High values of CL in a Virtual Machine signifies a problem in the fulfillment of request messages backlog.
    • Memory Occupancy (MO) – Memory Utilization on host and guest systems. Services that require a huge amount of data may require substantial portions of memory at the detriment of other services.
    • Network Utilization (NU) – Utilization of the network bandwidth. High values of NU may suggest re-allocation of external resources to manage a peak of requests.
    • Host Availability (HA) – Number of virtual machines available and accessible through the network. The falling of the HA under a pre-defined threshold indicates the new for new machines.

Scalability Patterns for Platform-as-a-Service

performance monitoring
Performance Monitoring
  • Based on the certain measurements of the Performance metrics, certain alarms are raised.
  • Two Categories of Alarms:
    • Message Alarm – A message alarm is raised when:
        • System is not able to manage the message queue efficiently.
        • Average message delivery time is above a preset threshold.
        • The difference between the maximum and minimum message time is above a preset threshold.
    • Processing Alarm – A process alarm is raised when service execution may involve high execution time or a lot of resources.

Scalability Patterns for Platform-as-a-Service

alarm rules
Alarm Rules

HIGH and LOW thresholds in the above table can be defined on the basis of previous experimental tests and/or expert knowledge.

Scalability Patterns for Platform-as-a-Service

alarm driven selection of scalability patterns
Alarm-driven selection of scalability patterns

The initial node ∗ represents the basic installation scenario in which different tenants share the same platform with default configurations.

Scalability Patterns for Platform-as-a-Service

the two fold monitoring approach
The two-fold Monitoring Approach
  • Upon an increase in the load that raises a message alarm, the algorithm moves to node ShPP and applies a ShPP pattern
  • If a processing alarm is raised, the algorithm moves to node CPP and applies a CPP pattern.
  • When the ShPP pattern is not sufficient to solve further alarms, it moves to node MShPP in case of message alarms or to node CPP in case of processing alarms.
  • The algorithm moves from CPP to MCPP for both types of alarms, while it moves from MShPP to MCCP in case of processing alarms.

Scalability Patterns for Platform-as-a-Service

experimental setting
Experimental Setting
  • WSO2 Platform is a cloud-deployable, Java-based service-oriented platform.
  • A WSO2 platform with default configurations is used as the experimental environment.
  • A realistic scenario is simulated where concurrent requests come from different clients.
  • Each test case starts with 20 active clients sending SOAP (Simple Object Access Protocol) requests, which ramp up to a maximum of 100 clients.
  • All test cases have a duration of 60 seconds.
  • Load Varying is done by increasing the requests per second (rps) from 10rps to 500 rps.

Scalability Patterns for Platform-as-a-Service

baseline measurement without security
Baseline Measurement without security

RT – Response Time

(in a logarithmic scale)

TPS – Transactions per Second

rps – Requests per second

Scalability Patterns for Platform-as-a-Service

baseline measurement with security
Baseline Measurement with security

RT – Response Time

(in a logarithmic scale)

TPS – Transactions per Second

rps – Requests per second

Scalability Patterns for Platform-as-a-Service

performance of shpp without security
Performance of ShPP without security

Scalability Patterns for Platform-as-a-Service

performance of shpp with security
Performance of ShPP with security

Scalability Patterns for Platform-as-a-Service

performance of cpp without security
Performance of CPP without security

Scalability Patterns for Platform-as-a-Service

performance of cpp with security
Performance of CPP with security

Scalability Patterns for Platform-as-a-Service

comment
Comment..
  • Result 1 – Security causes a substantial decrease in the performance of a SOA deployed on the cloud.
  • Result 2 – ShPP results in a performance gain both on TPS and RT with respect to the baseline.
  • Result 3 – CPP provides a further improvement with respect to ShPP.

Scalability Patterns for Platform-as-a-Service

thank you
THANK YOU!

Scalability Patterns for Platform-as-a-Service

ad