Scalability patterns for platform as a service
This presentation is the property of its rightful owner.
Sponsored Links
1 / 33

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


  • 34 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Scalability Patterns for Platform-As-A-Service

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


Scalability patterns for platform 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


Scalability patterns for platform as a service

  • 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


Scalability patterns for platform as a service

  • 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


Scalability patterns for platform as a service

  • 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


Scalability patterns for platform as a service

  • 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


Scalability patterns for platform as a service

  • 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


  • Login