SLA Management

in
Cloud Computing
Unit – V (Part_1)
TRADITIONAL APPROACHES TO SLO
MANAGEMENT

• Traditionally, load balancing techniques and

admission control mechanisms have been used
to provide guaranteed quality of service (QoS)
for hosted web applications.
• These mechanisms can be viewed as the first
attempt towards managing the SLOs
Load Balancing:
• Objective: To distribute the incoming requests onto a set of physical
machines, each hosting a replica of an application

Fig. General Taxonomy of Load-balancing algorithms

• The load balancing algorithm executes on a physical machine that

interfaces with the clients.
• This physical machine, also called the front-end node, receives the
incoming requests and distributes these requests to different physical
machines for further execution.
• This set of physical machines is responsible for serving the incoming
requests and are known as the back-end nodes.
a. class-agnostic:
• Typically, the algorithm executing on the front-end node is agnostic to
the nature of the request. This means that the front-end node is neither
aware of the type of client from which the request originates nor aware of
the category (e.g., browsing, selling, payment, etc.) to which the request
belongs to.
b. class-aware:
• load balancing and requests distribution, the front-end node must
additionally inspect the type of client making the request and/or the type
of service requested before deciding which back-end node should service
the request. Inspecting a request to find out the class or category of a
request is difficult because the client must first establish a connection
with a node (front-end node) that is not responsible for servicing the
request.
Admission Control:
• Objective: To police the incoming requests and identify a
subset of incoming requests that can be admitted into the
system when the system faces overload situations.

• play an important role in deciding the set of requests that

should be admitted into the application server when the server
experiences “very” heavy loads During overload situations,
since the response time for all the requests would invariably
degrade if all the arriving requests are admitted into the server,
it would be preferable to be selective in identifying a subset of
requests that should be admitted into the system so that the
overall pay-off is high.
 Fig. General Taxonomy for admission control mechanisms

(1)request-based algorithms: reject new requests if the servers are

running to their capacity
(2) session-based algorithms: try to ensure that longer sessions are
completed and any new sessions are rejected
For Eg: New requests/session with high priority admitted & low priority
rejected

QoS-aware control mechanisms: A requests consume more resources

rejected during overload situations.
 TYPES OF SLA
Definition: the level of service expected by a customer from a supplier,
laying out the metrics by which that service is measured, and the remedies
or penalties, if any
• Service-level agreement provides a framework within which both seller and
buyer of a service can pursue a profitable service business relationship.

Conducting business

Mutual beneficial relationship

• SLA can be modeled using web service-level agreement
(WSLA) language specification. Although WSLA is
intended for web-service-based applications, it is equally
applicable for hosting of applications.
• There are two types of SLAs from the perspective of application
hosting infrastructure and Hosting
a. Infrastructure SLA
• The infrastructure provider manages and offers guarantees on
availability of the infrastructure, namely, server machine, power,
network connectivity, and so on.
• Enterprises manage themselves, their applications that are deployed
on these server machines. The machines are leased to the customers
and are isolated from machines of other customers.
b. Application SLA
• the server capacity is available to the applications based solely on
their resource demands.
• Hence, the service providers are flexible in allocating and de-
allocating computing resources among the co-located applications
LIFE CYCLE OF SLA
• Each SLA goes through a sequence of steps starting from identification
of terms and conditions, activation and monitoring of the stated terms
and conditions, and eventual termination of contract once the hosting
relationship ceases to exist.

• Such a sequence of steps is called SLA life cycle and consists of the
following five phases:

1. Contract definition 2. Publishing and discovery 3. Negotiation

4. Operationalization 5. De-commissioning

1. Contract Definition.
• Generally, service providers define a set of service offerings and corresponding
SLAs using standard templates.
• These service offerings form a catalog. Individual SLAs for enterprises can be
derived by customizing these base SLA templates
2. Publication and Discovery:
• Service provider advertises these base service offerings through
standard publication media, and the customers should be able to
locate the service provider by searching the catalog.
• The customers can search different competitive offerings and shortlist
a few that fulfill their requirements for further negotiation.
3. Negotiation:
• Once the customer has discovered a service provider who can meet
their application hosting need, the SLA terms and conditions needs to
be mutually agreed upon before signing the agreement for hosting the
application.
 For a standard packaged application which is offered as service, this phase
could be automated.
 For customized applications that are hosted on cloud platforms, this phase
is manual.
• The service provider needs to analyze the application‘s behavior with
respect to scalability and performance before agreeing on the
specification of SLA
• At the end of this phase, the SLA is mutually agreed by both customer
and provider and is eventually signed off.
• SLA negotiation can utilize the WS negotiation specification.

4. Operationalization:
• SLA operation consists of SLA monitoring, SLA accounting, and SLA
enforcement.
▫ SLA monitoring involves measuring parameter values and calculating the
metrics defined as a part of SLA and determining the deviations.
▫ SLA accounting involves capturing and archiving the SLA adherence for
compliance.
▫ SLA enforcement involves taking appropriate action when the runtime
monitoring detects a SLA violation.

5. De-commissioning:
• SLA decommissioning involves termination of all activities performed
under a particular SLA when the hosting relationship between the
service provider and the service consumer has ended.
• Contract termination and legally ended.
SLA MANAGEMENT IN CLOUD
• SLA management of applications hosted on cloud
platforms involves five phases.

1. Feasibility
2. On-boarding
3. Pre-production
4. Production
5. Termination

• Different activities performed under each of these

phases are shown in Figure
1. Feasibility Analysis:
MSP(managed service provider) conducts the
feasibility study of hosting an application on their cloud
platforms. This study involves three kinds of feasibility: (1)
technical feasibility, (2) infrastructure feasibility, and (3)
financial feasibility.

• The technical feasibility of an application implies determining

the following:
1. Ability of an application to scale out.
2. Compatibility of the application with the cloud platform
being used within the MSP’s data center.
3. The need and availability of a specific hardware and
software required for hosting and running of the
application.
4. Preliminary information about the application
performance and whether they can be met by the MSP.
• The infrastructure feasibility involves determining the
availability of infrastructural resources in sufficient quantity so
that the projected demands of the application can be met.

• The financial feasibility study involves determining the

approximate cost to be incurred by the MSP and the price the
MSP charges the customer so that the hosting activity is
profitable to both of them.

• A feasibility report consists of the results of the above three

feasibility studies. If customer agree upon findings it proceeds
to the next phase.
2. On-Boarding of Application:
• Once the customer and the MSP agree in principle to host the
application, the application is moved from the customer servers
to the hosting platform.
• Moving an application to the MSP’s hosting platform is called
on-boarding
• As part of the on-boarding activity, the MSP understands the
application runtime characteristics using runtime profilers.
• This helps the MSP to identify the possible SLAs that can be
offered to the customer for that application.
• This also helps in creation of the necessary policies (also called
rule sets) required to guarantee the SLOs mentioned in the
application SLA.
• The application is accessible to its end users only after the on-
boarding activity is completed.
On-boarding activity consists of the following steps:
1. Packing of the application for deploying on physical or virtual
environments.
2.The packaged application is executed directly on the physical
servers to capture and analyze the application performance
characteristics.
3.Identify the nature of application—that is, whether it is CPU-
intensive or I/O-intensive or network-intensive and the potential
performance bottlenecks.
4.Based on the measured performance characteristics, different
possible SLAs are identified.
5. Once the customer agrees to the set of SLOs and the cost, the MSP
starts creating different policies required by the data center for
automated management of the application.
6.This implies that the management system should automatically
infer the amount of system resources that should be allocated/de-
allocated to/from appropriate components of the application when
the load on the system increases/decreases.
These policies are of three types:
(1) business, (2) operational, and (3) provisioning.

1. Business policies: help prioritize access to the resources in case of

contentions. Business policies are in the form of weights for different
customers or group of customers.
2. Operational policies: are the actions to be taken when different
thresholds/conditions are reached. Also, the actions when thresholds/
conditions/triggers on service-level parameters are breached or about to
be breached are defined.
• The corrective action could be different types of provisioning such as
scale-up, scale-down, scale-out, scale-in, and so on, of a
particular tier of an application.
• Additionally, notification and logging action (notify the enterprise
application’s administrator, etc.) are also defined. Operational policies
(OP) are represented in the following format:

OP = collection of (Condition, Action)

For example, one OP is

OP = (average latency of web server > 0.8 sec, scale-out the web-server tier)
3. Provisioning policies: help in defining a sequence of actions
corresponding to external inputs or user requests.
• Scale-out, scale-in, start, stop, suspend, resume are some of the examples
of provisioning actions.
• A provisioning policy (PP) is represented as

PP = collection of (Request, Action)

• For example, a provisioning policy to start a web site consists of the

following sequence:
▫ start database server, start web-server instance 1,
▫ followed by start the web-server instance 2, and so on.
3. Preproduction:
• Once the determination of policies is completed, the
application is hosted in a simulated production environment.

• It facilitates the customer to verify and validate the MSP’s

findings on application’s runtime characteristics and agree on
the defined SLA.

• Once both parties agree on the cost and the terms and
conditions of the SLA, the customer sign-off is obtained.

• On successful completion of this phase the MSP allows the

application to go on-live.
4. Production:
• In this phase, the application is made accessible to its
end users under the agreed SLA.
• Customer may request the MSP for inclusion of new
terms and conditions in the SLA.
• If the application SLA is breached frequently or if the
customer requests for a new non-agreed SLA, the on-
boarding process is performed again.
▫ In the case of the former, on-boarding activity is repeated
to analyze the application and its policies with respect to
SLA fulfillment.
▫ In case of the latter, a new set of policies are formulated to
meet the fresh terms and conditions of the SLA.
5. Termination:
• When the customer wishes to withdraw the hosted
application and does not wish to continue to avail
the services of the MSP for managing the hosting of
its application, the termination activity is initiated.
• On initiation of termination, all data related to the
application are transferred to the customer and only
the essential information is retained for legal
compliance.
• This ends the hosting relationship between the two
parties for that application, and the customer sign-
off is obtained.
AUTOMATED POLICY-BASED
MANAGEMENT
• This section explains in detail the operationalization of the
“Operational” and “Provisioning”
• The policies specify the sequence of actions to be performed
under different circumstances.
• Operational policies specify the functional relationship
between the system level infrastructural attributes and the
business level SLA goals.
▫ For example, consider a three-tier web application consisting of
web server, application server, and database server. Each of the
servers is encapsulated using a virtual machine and is hosted
on virtualized servers. Furthermore, assume that the web tier
and the database tier of the application have been provisioned
with sufficient resources at a particular work-load
• To understand the system resource requirements for each of the tiers of
an application at different workloads necessitates the deployment of the
application on a test system.
• Some of the parameters often used to prioritize action and perform
resource contention resolution are:
▫ The SLA class (Platinum, Gold, Silver, etc.) to which the application belongs to.
▫ The amount of penalty associated with SLA breach.
▫ Whether the application is at the threshold of breaching the SLA.
▫ Whether the application has already breached the SLA.
▫ The no. of applications belonging to the same customer that has breached SLA.
▫ The no. of applications belonging to the same customer about to breach SLA.
▫ The type of action to be performed to rectify the situation
The basic functionality of these components is described below:
1. Prioritization Engine. Requests from different customers’ web
applications contending for the same resource are identified, and
accordingly their execution is prioritized.
2. Provisioning Engine. Every user request of an application will be
enacted by the system
3. Rules Engine. The operation policy defines a sequence of actions to be
enacted under different conditions/trigger points.
4. Monitoring System. Monitoring system collects the defined metrics in
SLA.
5. Auditing. The adherence to the predefined SLA needs to be monitored
and recorded
6. Accounting/Billing System. Based on the payment model, charge
backs could be made based on the resource utilized by the process
during the operation.