PowerPoint Presentation
Scalability Patterns for Platform-As-A-ServiceClaudio A Ardagna,
Ernesto Damiani, Fulvio Frate, Davide RebeccaniUniversita degli
Studi di Milano, ItalyMarco UghettiTelecom Italia, TILab, Italy13th
November, 2012.
Presented By,Chidambara Nadig.2012 IEEE 5th International
Conference on Cloud Computing1AbstractPlatform 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
infrastructure and a method to automatically manage
scalability.
2Scalability Patterns for Platform-as-a-Service2IAAS
Infrastructure as a Service.PAAS Platform as a Service.SAAS
Software as a Service.3Scalability Patterns for
Platform-as-a-ServiceIAAS, PAAS and SAAS
3Scalability Patterns for Platform-as-a-Service4
Levels of Abstraction in Cloud Services.
Scalability Patterns for Platform-as-a-Service55Some
examplesScalability Patterns for Platform-as-a-Service6
Actions on Resource ScalingVertical 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-Service77Scalability PatternsSingle 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-Service88Single 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-Service99Shared 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-Service1010Whenever
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 doesnt provide linear scalability increase due to
increased overheads for resource management.Scalability Patterns
for Platform-as-a-Service1111Clustered 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-Service1212CPP 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-Service1313Multiple 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-Service14When 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-Service15Multiple 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-Service16When 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.
PromisesHigh Scalability.High Availability.High
Reliability.Scalability Patterns for
Platform-as-a-Service17OverviewScalability Patterns for
Platform-as-a-Service18
Performance MeasurementPerformance Metrics at the Platform
LevelTotal 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-Service19Performance Metrics at the Host LevelCPU
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-Service20Performance MonitoringBased 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-Service21Alarm
RulesScalability Patterns for Platform-as-a-Service22
HIGH and LOW thresholds in the above table can be defined on the
basis of previous experimental tests and/or expert
knowledge.Alarm-driven selection of scalability patternsScalability
Patterns for Platform-as-a-Service23
The initial node represents the basic installation scenario in
which different tenants share the same platform with default
configurations.The two-fold Monitoring ApproachUpon 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-Service24Experimental
SettingWSO2 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-Service25
Baseline Measurement without securityScalability Patterns for
Platform-as-a-Service26
RT Response Time (in a logarithmic scale)
TPS Transactions per Second
rps Requests per secondBaseline Measurement with
securityScalability Patterns for Platform-as-a-Service27
RT Response Time (in a logarithmic scale)
TPS Transactions per Second
rps Requests per secondPerformance of ShPP without
securityScalability Patterns for Platform-as-a-Service28
Performance of ShPP with securityScalability Patterns for
Platform-as-a-Service29
Performance of CPP without securityScalability Patterns for
Platform-as-a-Service30
Performance of CPP with securityScalability Patterns for
Platform-as-a-Service31
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-Service32THANK
YOU!Scalability Patterns for Platform-as-a-Service33