S-CUBE LP: SLA-based Service Virtualization in distributed, heterogenious environments
-
Upload
virtual-campus -
Category
Education
-
view
472 -
download
0
description
Transcript of S-CUBE LP: SLA-based Service Virtualization in distributed, heterogenious environments
www.s-cube-network.eu
S-Cube Learning Package
SLA-based Service Virtualization in distributed, heterogenious
environments
MTA SZTAKI, TU Wien (TUW)
Attila Kertesz, SZTAKI
Learning Package Categorization
S-Cube
Infrastructure Mechanisms for the Run-Time
Adaptation of Services
SLA-based Service Virtualization
Self-* Service
Execution
Learning Package Overview
Problem Description
SLA-based Service Virtualization
Federated Cloud Management
Discussion
Conclusions
User taskflow
Agreement negotiation
Service Discovery Service Brokering
Service Deployment
Virtual Resource
Service Registry
Service Execution lifecycle within S-Cube
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
Learning Package Overview
Problem Description
SLA-based Service Virtualization
Federated Cloud Management
Discussion
Conclusions
SLA-based service virtualization (SSV) architecture
Production Grids Clouds Web Services
Meta-Negotiator
Meta-Broker
Automatic Sevice Deployer
Broker Broker …
Au
ton
om
ic
Ma
nag
er
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.
S
R
S S
R
Target areas, operational steps
R R
ASD ASD ASD ASD
B B
MB
User
MN
. . .
. . . . . .
SLA negotiation,
assurance
Information on
availability, properties
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.
Meta-Negotiation in SSV
Responsible for
creating low-level
agreements from
general user
requirements
MB provides
aggregated
dynamic data on
brokers and
available services
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>
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.
Meta-brokering in SSV
Meta-brokering means a higher level resource management that utilizes existing Brokers to access various resources of different distributed environments.
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
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
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
Component interactions in SSV
Simulation environment for managing services in a heterogenious environment
Simulator Meta- Broker
J J
B B …
…
J
B result
Broker P P …
Broker P P …
…
Resource M M …
Resource M M …
Resource M M …
…
Workload Workload Workload …
IS Grids load
GridSim
GridSim extension
CloudSim extension
Cloud Broker
CloudSim
Data- center
VM …
VM
SSV
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.
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).
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.
Results
On demand deployment
introduces some overhead
Service duplication
increases performance
Further investigation of
deployment strategies
are needed
Learning Package Overview
Problem Description
SLA-based Service Virtualization
Federated Cloud Management
Discussion
Conclusions
Emerging Clouds
As the interests towards Cloud Computing solutions are
growing, the need for federating separate Cloud systems is
inevitable.
Cloud delivery models
Infrastructure as a Service
Platform as a Service
Software as a Service
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
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).
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.
Learning Package Overview
Problem Description
SLA-based Service Virtualization
Federated Cloud Management
Discussion
Conclusions
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.
Learning Package Overview
Problem Description
SLA-based Service Virtualization
Federated Cloud Management
Discussion
Conclusions
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.
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.
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).