Dynamic Service Level Agreement Verification in Cloud Computing

Dynamic Service Level Agreement verification
in Cloud Computing
Shireen Akter, Md Whaiduzzaman
Institute of Information Technology
Jahangirnagar University
{shireenmukta019@gmail.com, wzaman@juniv.edu}
Abstract-In the present atmosphere of tighter budgets and pressure on resources, many public sector organiza-
tions, including local authorities, are outsourcing services to outer organizations under service level agreements in
cloud computing. Cloud computing is an approach to convey facilitated benefits over the web. Services are available to the
users relying upon cloud arrangement and the Service Level Agreement (SLA) between the service providers and the cli-
ents. Service level agreements are being utilized inside associations, directing connection between various sections of the
association. It requires a commitment from both parties to support and adhere to the agreement in order for the SLA to
work effectively. In spite of the fact that it gives a straightforward view about the cloud condition, such as cloud services,
cloud distribution, security issues, responsibilities, agreements and warranties of the services. However, there are several
issues occur from incorrect SLA which can cause misunderstanding among service providers and clients. SLA checking
device confirm the SLA effectively whether it deals with all administrations as per SLA. In this paper, we represent a SLA
confirmation and checking process that can distinguish SLA verification in gathering the information. We consider IaaS
(Infrastructure as a Service) parameters for SLA verification in Cloud.
I. INTRODUCTION
Almost the entire telecommunication operators industry had been invested in large data centers. These investments
were done in order to satisfy, amongst others, growing customer requirements. However, these data centers are not
very flexible and their operation and maintenance cost is important [1]. Therefore, to reduce data centers overall cost,
large organizations have started moving to Cloud Computing, as Cloud Computing user or providers[2]. Cloud com-
puting is an emerging trend for the provision of IT infrastructure as services, with the potential of transforming
the way of offering business services and software development to become prominent and accessible for all
without the hassle of investing in expensive hardware resources nor of managing and maintaining them [3].
One of the principle parts of utilizing cloud services is the Service Level Agreement (SLA) that works as a contractual
document between the cloud providers and their customers. A SLA is a document that includes a description of
the agreed service, service level parameters, guarantees, and actions and remedies for all cases of violations[4] .
Cloud SLA expresses a few measurements and parameters that must be implemented by the cloud providers or con-
sumers[5]. If any contractual company fails to meet any SLA requirements, that party commits a violation and is
obligated to pay some punishment according to the SLA. SLA’s can help to provide a clear framework for service
delivery, monitor performance and service quality and support continuous improvement [6]. The run of the mill SLA
measurements incorporate memory estimate, CPU speed, stockpiling size, organize data transfer capacity, and frame-
work uptime and bundle misfortune. A SLA fills in as the reason for the normal level of services obtained from the
Cloud Service Provider (CSP) [7] . The bill that a client pays to the CSP is firmly related with the SLA. A CSP is a
benefit based organization. It has the motivator to undermine SLA. For instance, a CSP may give less memory to a
client, which permits the CSP to help more clients and make more benefits [8]. There are an extremely restricted
method for measuring the SLA parameters. Generally this SLA seem each time client utilizes the cloud services.
International Journal of Computer Science and Information Security (IJCSIS),
Vol. 15, No. 9, September 2017
183 https://sites.google.com/site/ijcsis/
ISSN 1947-5500

However, typically clients or organizations not read the SLA completely [9]. Because of that, service provider can
state any good specification but in reality the service not perform as good as they mention in the SLA. The service
provider unfit to confirm and approve the right administrations or capacities that asked for from customer in distributed
computing by following the SLA. The cloud benefits continually managing the verification of the SLA[10] .
In this paper we build up a SLA checking instrument with that confirm whether the SLA works accurately or not. We
propose an architectural design where Core monitoring layer deal with Infrastructure as a Service (IaaS) .The gathered
information at the Data Collector Layer send to the Service Monitoring Layer. It gathers information from the different
administrations and send to the low level marker. The actual attributed that had been filter from the data collector.
Then the real time data compare with the attributes value in SLA. If some of the attributes value in the SLA is violated
then the whole SLA is said to be invalid and unable to follow the contract. If the attributes in the SLA is not violated
then the SLA is valid and follow the contract.
The paper is organized as follows. The next section provides background about concept of Cloud Computing and SLA
compliance checking. Section 3 focuses on the SLA verification architecture we propose. Section 4 details the verifi-
cation technique and different parameters for IaaS. Section 5 presents an experimental output with different parameters
values. Section 6 presents a summary of the SLA related works. Finally, section 7 concludes this paper and gives
directions for future works.
II. BACKGROUND
A. Concept of Cloud Computing
Cloud computing is a next generation computing platform that helps the users to share the resources through com-
munication mediums. The greater part of the associations are running their applications in cloud since cloud gives
dependability, adaptability, elite, low transmission capacity. It causes the clients to share the assets through corre-
spondence mediums. It encourages the clients to share the assets through communication mediums. It refers to web
based improvement and services. Fig. 1 Shows concept of Cloud Computing and its characteristics.
Figure 1. Concept of Cloud Computing
According to National Institute of Standards and Technology (NIST) one of the most accepted definition of cloud
computing is [33], “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a
ISSN 1947-5500

shared pool of configurable computing resources that can be rapidly provisioned and released with minimal manage-
ment effort or service provider interaction”. European Community for Software and Software Services (ECSS) defines
“cloud computing as the delivery of computational resources from a location other than your current one”.
Because of progression in cloud data center architecture and virtualization procedure all most boundless storage will
be given to the registered clients. Along these lines, the cloud clients won't need to be stressed over the constrained
storage spaces. Fundamentally, Cloud computing permits the clients and enterprises with different abilities to store
and process their information in either exclusive cloud, or on an outsider server keeping in mind the end goal to make
information getting to systems substantially more simple and dependable. Data centers that might be situated a long
way from the user–ranging in remove from over a city to over the world. Cloud computing depends on sharing of
assets to accomplish intelligibility and economy of scale, like a utility (like the power matrix) over a power arrange.
It gives IaaS, Platform as a Service (PaaS), and Software as a Service (SaaS) and Storage as a Service.
B. SLA Compliance Checking
SLA Compliance Checking includes a target service and a system in charge of collecting monitoring information
and verifying SLAs compliance. The target service offers probes and its usage is contractualized with at least one SLA
(based on information that can be obtained through the probes). The SLAs compliance verification system takes as
input information concerning the target service as well as at least one SLA, and produces Service Level Checking
(SLC) results about the SLA compliance, SLA violation or errors occurred during the verification or information
collection points. The target service can include software, platforms and/or infrastructure, or can even be a Cloud
system itself.
The implementation of the SLA Compliance checking module, contained in the Service Monitoring Layer. It is made
out of three segments : the Alert manager, the Log that stores and persists the SLC results produced by the Alert
manager in log files, the SLA manager. The result provided by the SLA compliance checking can be used to inform
the target service administrator, make decisions service reconfiguration, select service providers at runtime, launch an
autonomic circle, and terminate a contract.
III. SLA VERIFICATION MODEL
The compositional example we propose is a three layer design including the Core Monitoring layer, the Data Collector
layer and the Service Monitoring layer. The most minimal layer in this design is the Core Monitoring layer. This Core
Monitoring layer manage IaaS. This layer gather information from different administration tests and collaborate with
each other's. At that point send information to the low level markers. Such low level pointers speak to a perspective
of the objective administration. This low-level pointers speak to a perspective of the objective administration. Han-
dling can appear as information collection, change, improvement, corruption, relationship, synchronization and so on.
The indicator values created are then exchanged from the core monitoring to the Data Collector layers.
The Data Collector layer is the middle person level of the example. The Data Collector layer will connect with both
the Core Monitoring and the Service Monitoring layers. The Data Collector is an apparatuses where taking the info
which is the low level markers that was delivered by the Core Monitoring layer. These indicators are then prepared
keeping in mind the end goal to acquire esteems comparing to more elevated amount business pointers. Such abnormal
ISSN 1947-5500

state markers characterize an arrangement of Service Level Objectives (SLO) which can be indicated in the SLAs
identified with the objective administration. All the need information enter the Service Monitoring to prepared. All
the required information in light of the SLA characteristics that most every now and again expressed in numerous
SLA.
Figure 2. SLA verification architecture.
The Service Monitoring layer is the upper layer of this proposed engineering. At that point the information send to
Service Monitoring for SLA checking. Once the information enter the SLA checking instruments, the information
confirmation process initiate. The check procedure is a procedure where the information got from Data Collector layer
(ongoing information) are being contrasted and the information that expressed in the Service Level Agreement by
utilizing the correlation strategy. In the event that the got information is coordinate with the SLA esteem then the
outcome demonstrate "Ok". In any case, if the information is not coordinate then the outcome indicate "Violate".
IV. VERIFICATION
CSP is very powerful and has complete control of its resources, such as physical machines, hypervisors, VMs etc. It
is a challenging task to detect SLA violations by an untrusted cloud. Violations occur at several SLA metrics such as
memory size, CPU speed, storage size, network bandwidth, and system uptime and packet loss. If a user agreements
a VM (denoted as VM1) with 3GB physical memory, the cloud may allocate less but sufficient memory (may be less
than 3GB). However, when the applications require more memory, the cloud will satisfy VM1 immediately, up to the
maximum value (3GB). The above behaviour is considered normal and the SLA is satisfied. Violation happen when
VM1 is specified with 3GB physical memory in the SLA. When VM1 is running, the hypervisor also tells VM1 (and
the user) that its maximum memory is 3GB. However, the hypervisor sets the actual maximum memory of VM1 to
ISSN 1947-5500

2.5GB, which means that VM1 will never get more than 2.5GB no matter how many processes are running. Thus,
when the workload increases, the computations will spend more time than should be in VM1. As a result, all the
computations in VM1 suffer from performance degradations.
The actual value that collected from the Data collector layer (Av) compare to the SLA value (Sv) from the cloud
services. Therefore, to verify the SLA let us introduce the following possibilities of outcome:
H1: Actual value (Av) >= SLA value (Sv)
H2: Actual value (Av) < SLA value (Sv)
If H1 occurs then the SLA is correct and follows the SLA rules in cloud services.
If H2 occurs then the SLA is incorrect and might be violated.
For verification results in tool provided can be used to inform the target service administrator to make decisions
regarding reconfiguration of the service or terminate a contract. Client also will get the notification of about
the services whether the services follow the SLA or not. This main target of this research is to analyst whether the
cloud services provided is following the contract or not. It is very important in terms of reliability, security and avail-
ability. This verification process occurs dynamically in the background. Randomly informs the cloud users and cloud
service provider. In this paper we use SLA attributes for IaaS. The SLA parameters are determined based on proposed
framework from . Here, we determined the most frequent attributes that applied in SLA. Table I shows the SLA
parameters for IaaS.
TABLE I
SLA PARAMETERS FOR IAAS
Parameters Description
CPU capacity (Cp) CPU speed for VM
Memory size (Mp) Size Cash memory size for VM
Storage (Sp) Storage size of data for short or long term of contract
Scale up (SUp1) Maximum of VMs for one user
Scale down (SDp2) Minimum number of VMs for one user
Scale up time (SUTp) Time to increase a specific number of VMs
Scale down time (SDTp) Time to decrease a specific number of VMs
Response Time (RTp) Time to complete and receive the process
Load Balance (LBp) When elasticity kicks in
ISSN 1947-5500

V. EXPERIMENTAL PROCESS AND OUTPUT
We now present performance results related to the validation in the orbit Virtualization development environment.
This development environment performs the operations by various servers to analysis data by displaying tables, graphs
or statistics. Our initial experiment is focused on the number of customers get services from cloud in the cloud envi-
ronment.
Core monitoring layer collect data from cloud and sent to the data collector layer. The Data Collector layer then
compute the latency values from different provider and client and the report is then send to the Service Monitoring
layer which contains the SLC itself. This latter then checks report received with actual values of SLA in order to
produce the violation results. All the value collected from the data collector layer apply to the SLA checking tools.
Data collected in the following steps:
 Contacting and collecting data from the probes in order to produce a raw report
 Sending this raw report to Data Collector,
 Processing and adapting the report,
 Sending the processed report to Service Monitoring,
 SLA Compliance Checking itself,
 And sending the SLC results to the Cloud
We determined several values for 9 SLA parameters. Fig. 3, 4 and 5 show the CPU capacity, storage, scale up, scale
down and response time values with continuous time. In Fig. 3 we have seen that for different SLA parameters load
values changes per minutes. Load value has increased at high time.
Figure 3. CPU speed and usage of storage varies with time.
ISSN 1947-5500

We consider the parameters value at several load such as heavy load, average load and low load. Load values varies
in different situations such as no. of customer, availability of resources, and usage of CPU at different time. Fig. 6
demonstrate that all the average times spent are very low. The green diagram demonstrates comes about acquired
when just "OK" SLC comes about are delivered, while the yellow chart indicates comes about got when SLC produces
one "Violation" and some "Ok". As it can be seen, every one of the circumstances spent are low when just 1 pertinent
SLA is included to almost 1 second when 7 important SLAs are included. Of course, the normal time stays low and
develops with the quantity of SLAs included. As an update, each report got by the SLC is checked with all the signif-
icant SLAs and each pertinent SLA prompts the outflow of a SLC result notice.
Figure 4. Scale up and down varies with time.
Figure 5. Response Time varies with time.
Figure 6. Average time spent according to the number of SLA involved.
ISSN 1947-5500

Below Fig. 7, 8 shown the result for verify the SLA for cloud services. The actual value that collected from the data
collector layer compare to the SLA values from the cloud services. Then the verification process works at different
load values for SLA parameters.
Figure 7. Comparison results between SLA values and actual values in heavy and average load
Figure 8. Comparison results between SLA values and actual values in low load
Based on the fig 7, 8 it is clearly shown that if the actual value lower than the SLA value then the SLA is violated. In
heavy load, it is shown that there have 4 violated SLA and 9 with not violated.so, here maximum SLA’s are violated
and follow the contract. In average load, it is shown that maximum SLA‘s values are higher than actual value. The
verification results are used to inform the target service administrator to make decisions regarding reconfiguration or
to terminate a contract. This result also notify the clients.
ISSN 1947-5500

VI. LITERATURE REVIEW
The analysis of existing solutions for SLA Compliance Checking shows that proposed architectures are monolithic.
By monolithic, we mean that the checking module is itself in charge of calling the probes and collecting the infor-
mation, but also that information collected is generally not processed. Examples of such architectures include:
MoDe4SLA (University of Twente), WSLA Framework (IBM Research Division), work of Layer7 Technologies ,
WSOM framework (Peking University), works of HP Labs and of Technical University of Catalonia . Proposed data
mediation approach which requires the strict definition of data and associated data formats exchanged at each layer.
We propose an architectural pattern which contain three layers. Data collector layer contacting and collecting data
from the probes in order to produce a raw report. The Data Collector layer enables the progressive constructions of
indicators at various abstraction levels, and their sharing. The report is then send to the Service Monitoring layer which
contains the SLC itself. This latter then checks report received with actual values of SLA in order to produce the
violation results. All the value collected from the data collector layer apply to the SLA checking tools. Finally, we see
that the Data Collector layer can also be used to collect and synchronize/correlate data coming from several instances
of Core Monitoring in the case in the orbit virtualization environment. This approach we follow requires the restrict
definition of data and associated data formats exchanged at each layer.
VII. CONCLUSION
In this paper we have presented an innovating architecture for Service Level agreement compliance checking that has
been applied to the cloud computing context. We proposed three layers are Core Monitoring layer, Data Collector
layer and Service Monitoring layer which produced lower response time in collecting data. It provides a flexible way
to verify the SLA is violated or not. We consider IaaS parameters value in our work. If the SLA is violated then the
result should be invalid and the SLA is not following the contract. If the SLA is not violated then the results is valid
and the SLA is follow the contract. This check result at that point used to advise the objective administration organi-
zation to settle on choices with respect to reconfiguration or to end an agreement. This outcome additionally have
gone to customer for warning reason.
REFERENCES
1. Whaiduzzaman, M., et al., Cloud service selection using multicriteria decision analysis. The Scientific World
Journal, 2014. 2014.
2. Whaiduzzaman, M., A. Gani, and A. Naveed, TOWARDS ENHANCING RESOURCE SCARCE CLOUDLET
PERFORMANCE IN MOBILE CLOUD COMPUTING. Computer Science & Information Technology: p. 1.
3. Ahmed, E., et al., Network-centric performance analysis of runtime application migration in mobile cloud
computing. Simulation Modelling Practice and Theory, 2015. 50: p. 42-56.
4. Whaiduzzaman, M., et al., A study on strategic provisioning of cloud computing services. The Scientific
World Journal, 2014. 2014.
5. Whaiduzzaman, M. and A. Gani. Measuring security for cloud service provider: A Third Party approach. in
Electrical Information and Communication Technology (EICT), 2013 International Conference on. 2014.
IEEE.
6. Qi, H., et al., Sierpinski triangle based data center architecture in cloud computing. The Journal of
Supercomputing, 2014. 69(2): p. 887-907.
7. Shiraz, M., M. Whaiduzzaman, and A. Gani, A study on anatomy of smartphone. Computer Communication
& Collaboration, 2013. 1(1): p. 24-31.
ISSN 1947-5500

8. Whaiduzzaman, M., A. Naveed, and A. Gani, MobiCoRE: Mobile device based cloudlet resource
enhancement for optimal task response. IEEE Transactions on Services Computing, 2016.
9. Whaiduzzaman, M., et al., A survey on vehicular cloud computing. Journal of Network and Computer
Applications, 2014. 40: p. 325-344.
10. Nasir, M.K. and M. Whaiduzzaman, Use of cell phone density for Intelligent Transportation System (ITS) in
Bangladesh. Jahangirnagar University Journal of Information Technology, 2012. 1: p. 49-54.
ISSN 1947-5500

Dynamic Service Level Agreement Verification in Cloud Computing

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Dynamic Service Level Agreement Verification in Cloud Computing

Similar to Dynamic Service Level Agreement Verification in Cloud Computing (20)

Recently uploaded

Recently uploaded (20)

Dynamic Service Level Agreement Verification in Cloud Computing