1. S-Cube Learning Package
SLA-based Service Virtualization
in distributed, heterogenious
environments
MTA SZTAKI, TU Wien (TUW)
Attila Kertesz, SZTAKI
www.s-cube-network.eu

2. Learning Package Categorization
S-Cube
Self-* Service
Execution
Infrastructure Mechanisms for the Run-Time
Adaptation of Services
SLA-based Service Virtualization

3. Learning Package Overview
 Problem Description
 SLA-based Service Virtualization
 Federated Cloud Management
 Discussion
 Conclusions

4. Service Execution lifecycle within S-Cube
User taskflow
Agreement negotiation
Service Discovery Service Brokering
Service Registry Service Deployment
Virtual Resource

5. Problem description
 In heterogeneous, distributed service-based environments such as Grids
and Clouds, there is an emerging need for transparent, business-oriented
autonomic service execution.
 In order to develop such a robust system, the following solutions need to
be achieved:
– Service-level agreement based user interaction at the highest level
– Self-managable system architecture to autonomously interact with the system
components and services
– Federation of different service infrastructures that enables interoperation at the
lowest level

6. Learning Package Overview
 Problem Description
 SLA-based Service Virtualization
 Federated Cloud Management
 Discussion
 Conclusions

7. SLA-based service virtualization (SSV)
architecture
Meta-Negotiator
Autonomic
Manager
Meta-Broker
Broker … Broker
Automatic Sevice Deployer
Production Grids Clouds Web Services

8. Parties, components
 User: A person, who wants to use a service (also called as consumer)
 MN – Meta-Negotiator: A component/service that manages Service-level
agreements. It mediates between the user and the Meta-Broker, selects
appropriate protocols for agreements; negotiates SLA creation, handles
fulfillment and violation.
 MB – Meta-Broker: Its role is to select a broker that is capable of
deploying/executing a service with the specified user requirements.
 B – Broker: It interacts with virtual or physical resources, and in case the
required service needs to be deployed it interacts directly with the ASD.
 ASD – Automatic Service Deployment: It installs the required service on the
selected resource.
 S – Service: The service that users want to deploy and/or execute.
 R – Resource: Physical machines, on which virtual machines can be
deployed/installed.

9. Target areas, operational steps
User
Information on
availability, properties
MN
MB
...
B B
SLA negotiation,
assurance
... ...
ASD ASD ASD ASD
S S
R
R S
R
R

10. Means of negotiation
 User – MN: user supplies a specific meta-negotiation document
 MN – MB: agreeing on specific negotiation documents containing specific
negotiation strategy to be used, negotiation protocols to be used (WSLA,
WS-Ag,…) , terms of negotiation (e.g. time, price, …), security infrastructure
to be used
 MB – B: agreeing on a specific SLA written in a specific SLA language (e.g.
WSLA, WS-Agreement) containing concrete SLA parameters like concrete
execution time, concrete price, etc. Forming a service specification
document
 B – ASD: agreeing on a specific service to be available on the ASD
managed resources with the resource constraints resulted from the higher
level negotiation – the service is going to be able to use the requested
resources without disruptions from other parties
 Furthermore we need on each level (MN, MB, B, ASD) a negotiator which is
responsible for generating and interpreting SLAs.

11. Meta-Negotiation in SSV
 Responsible for
creating low-level
agreements from
general user
requirements
 MB provides
aggregated
dynamic data on
brokers and
available services

12. Sample Meta Negotiation document
<meta-negotiation xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance … >
<entity> <ID name="1234"/> … </entity>
<pre-requisite>
<role name="Consumer"/>
<security>
<authentication name="GSI"/><authorization name="xy"/>
</security>
<negotiation-terms>
<negotiation-term name="beginTime"/> <negotiation-term name="endTime"/>
<negotiation-term name="price"/>
</negotiation-terms>
</pre-requisite>
<negotiation>
<document name="WSLA" value="uri" version="1.0”/>
<document name="WS-Agreements" value="uri" version="1.0”/>
<protocol name="alternateOffers" schema="uri" version="1.0” location="uri"/>
</negotiation>
<agreement>
<confirmation name="confirmator" value="arbitrator”/>
</agreement>
</meta-negotiation>

13. Meta-negotiation steps
 Publish. A service provider publishes descriptions and conditions of
supported negotiation protocols into the registry.
 Lookup. Service consumers perform lookup on the registry database by
submitting their own documents describing the negotiations that they are
looking for.
 Match. The registry discovers service providers who support the
negotiation processes that a consumer is interested in and returns the
documents published by the service providers.
 Negotiate. Finally, after an appropriate service provider and a negotiation
protocol is selected by a consumer using his/her private selection strategy,
negotiations between them may start according to the conditions specified
on the providers document.
 The participants publishing into the registry follow a common document
structure (ie. meta-negotiation document) that makes it easy to discover
matching documents.

14. Meta-brokering in SSV
 Meta-brokering means a higher level resource management
that utilizes existing Brokers to access various resources of
different distributed environments.

15. Meta-Broker components
 The Meta-Broker is the core component: this communicates with the other
components
 The Translators are responsible for transforming the user request to the language
of the actually selected Broker (JSDL<-> JDL, RSL, xRSL…)
 The Invokers hand over the job to the brokers and wait for the results, and provide
additional information for the Information Collector about the submissions
 The Information Collector stores the connected broker properties and historical
data of the previous submissions
 The Matchmaker compares the JSDL of the actual job to the BPDL of the
registered resource brokers, and selects a ‘good’ broker for the job (or service)
 The IS Agent regularly updates current properties and availability of the virtual
resources reachable by the utilized brokers

16. Automatic Service Deployment in SSV
 Automatic service
deployment is a higher
level service
management concept
which provides the
dynamics to SBAs
 E.g. during the SBA’s
lifecycle services can
appear and disappear
without the disruption of
their overall behavior.
 On demand deployment

17. ASD architecture details
 Repository – holds the images of various services as ready to use virtual
machine images (Virtual Appliances)
 ASD – Automatic Service Deployment coordinates the proper resource
allocation for the given service according to the requirements from the
broker
 WS – Workspace service, offers the virtualization capabilities – virtual
machine creation, removal and management - of a given grid/cloud site
as a WSRF service

18. Component interactions in SSV

19. Simulation environment for managing services
in a heterogenious environment
SSV
J GridSim CloudSim
B Meta- J
B B Simulator J extension extension
Broker result
…
…
P P
Broker P … Broker P Cloud Broker
…
…
IS M M M Data- VM
Grids load Resource M Resource M … Resource M
center
VM
…
…
…
…
Workload Workload … Workload GridSim CloudSim

20. Brokers in the simulation:
 Grid brokers are extended GridUser entities:
– they can be connected to one or more resources,
– they are able to execute gridlets on these resources,
– different properties can be set to these brokers, some properties can
be marked as unreliable,
– various scheduling policies can be defined,
– finally they report to the IS Grid load database.
 A Cloud broker is an extended DatacenterBroker entity:
– it can be connected to a data center with one or more virtual machines
(VMs),
– and it is able to execute cloudlets on these virtual machines.

21. Simulator entity
 The Simulator class is an extended GridSim entity:
– it can generate and submit a requested number of gridlets (jobs) with
different properties, start and run time (length);
– it is connected to the created brokers and able to submit jobs to them;
– in case of submissions to the Cloud broker, it converts gridlets to
cloudlets;
– the default job distribution is the random Grid broker selection;
– in case of job failures a different broker is selected for the actual job;
– it is also connected to the Meta-Broker Service through its web service
interface and able to call its matchmaking service for broker selection.
 We suppose in these simulations that meta-negotiation is
done before submitting the jobs to the meta-broker. Therefore
the job description contains such requirements that can be
satisfied by one of the available brokers (or the Cloud broker).

22. Simulation setup
 4 virtual appliances encapsulate the four different services of the TINKER
workflow: GEN, TINKERALG, COLL and UPLOAD images.
 ASD have reduced the sizes of the created appliances
 Each service have been pre-deployed 50 times on an 8 node (32 CPU)
Eucalyptus cluster, and measured the interval between the deployment
request and the service's first availability.
 The measurement results are shown in the next table; these latencies
were also applied in the simulation environment within the Cloud broker.

23. Results
 On demand deployment
introduces some overhead
 Service duplication
increases performance
 Further investigation of
deployment strategies
are needed

24. Learning Package Overview
 Problem Description
 SLA-based Service Virtualization
 Federated Cloud Management
 Discussion
 Conclusions

25. Emerging Clouds
 As the interests towards Cloud Computing solutions are
growing, the need for federating separate Cloud systems is
inevitable.

26. Cloud delivery models
Software as a Service
Platform as a Service
Infrastructure as a Service

27. Federated Cloud Management
architecture
 The introduced SSV architecture can be extended and
focused on infrastructure Cloud solutions.
 Federating different clouds can be facilitated using the
brokering and meta-brokering layers of the SSV architecture
with a two-level brokering:
– At the top level a meta-brokering service chooses among available
infrastructure Clouds
– At the bottom level CloudBrokers schedule virtual machines (VM) to
available resources

28. FCM architecture
 Each CloudBroker
has an own queue
for storing the
incoming service
calls, and manages
one virtual machine
queue (VMQ) for
each appliance (VA).

29. Cloud brokering in FCM
 The default virtual machine scheduling is based on the
currently available requests in the queue, their historical
execution times, and the number of running virtual machines
(VM).
 The secondary task of the CloudBroker involves the dynamic
creation and destruction of the various VMQs.
 Virtual Machine Handler components are assigned to each
virtual machine queue. These components process the virtual
machine creation and destruction requests placed in the
queue. The requests are translated and forwarded to the
corresponding IaaS system. This component is a cloud
infrastructure-specific one, that uses the public interface of the
managed infrastructure.

30. Learning Package Overview
 Problem Description
 SLA-based Service Virtualization
 Federated Cloud Management
 Discussion
 Conclusions

31. Discussion and futher research directions
 In this learning package we revealed how to manage different
service infrastructures in a unified system:
– by supporting SLA-based user interaction,
– using an autonomic system to manage inner interactions, and
– building a federation of different infrastructures.
 There is still room for further research in:
– enhancing self-healing capabilities of the system, and
– increasing the number of supported application types to exploit more
from the available infrastructures.

32. Learning Package Overview
 Problem Description
 SLA-based Service Virtualization
 Federated Cloud Management
 Discussion
 Conclusions

33. Summary
 Service provisioning can be facilitated with an SLA-based
Service Virtualization architecture built on three areas:
– a meta-negotiation component for generic SLA management
– a meta-brokering component for diverse broker management
– and an automatic service deployment for resource virtualization on
the Cloud
 The shown service virtualization architecture can be validated
in a heterogeneous, distributed simulation environment, which
has been exeplified using a biochemical case study.
 The SSV architecture can be extended towards infrastructure
Clouds to operate as a Federated Cloud Management
solution, using a two-level brokering for Cloud selection and
optimal VM placement.

34. Further S-Cube Reading
A. Kertesz, G. Kecskemeti, I. Brandic, I. An SLA-based resource
virtualization approach for on-demand service provision. In Proceedings of
the 3rd international Workshop on Virtualization Technologies in Distributed
Computing. VTDC '09. ACM, New York, NY, 27-34, 2009.
A. Kertesz, G. Kecskemeti, I. Brandic, Autonomic SLA-aware Service
Virtualization for Distributed Systems, In proceedings of the 19th Euromicro
International Conference on Parallel, Distributed and Network-Based
Computing, IEEE Computer Society, pp. 503-510, 2011.
A. Cs. Marosi, G. Kecskemeti, A. Kertesz, P. Kacsuk, FCM: an Architecture for
Integrating IaaS Cloud Systems, In Proceedings of The Second International
Conference on Cloud Computing, GRIDs, and Virtualization.
Rome, Italy. September, 2011.

35. Acknowledgements
The research leading to these results has
received funding from the European
Community’s Seventh Framework
Programme [FP7/2007-2013] under grant
agreement 215483 (S-Cube).