AN SLA-BASED RESOURCE VIRTUALIZATION APPROACH FOR ON-DEMAND SERVICE PROVISION Gabor Kecskemeti MTA SZTAKI International Workshop on Virtualization Technologies in Distributed Computing 2009 Attila Kertesz MTA SZTAKI Presented by: Yun Liaw Ivona Brandic TU Vienna

Outline  Introduction  SLA-Based Resource Virtualization (SRV) Architecture  Requirements and Solutions to Realize SRV  Agreement Negotiation – Meta Negotiation  Service Brokering – Meta Brokering  Service Deployment and Virtualization  Case Study  Related Works  Conclusions and Comments 2015/12/4 2

Introduction  This paper provides an architecture for SLA-based resource virtualization that provides an solution for executing user applications in Clouds  To combine SLA-based resource negotiations with virtualized resource in terms of on-demand service provision  Most related works focus on either virtualization approaches without considering SLA management, or concentrates on SLA management neglecting the resource virtualization 2015/12/4 3

Introduction  This paper’s focus:  Agreement negotiation  Service brokering  Deployment using virtualization technology  Contributions of this paper  Presentation of a architecture for the SLA-based resource virtualization and on-demand service provision  Description of the architecture including meta-negotiation, meta-brokering, brokering and automatic service deployment (ASD)  Demonstration of the presented approach based on a case study 2015/12/4 4

SLA-based resource Virtualization Architecture  MN: Meta-Negotiator  MB: Meta-Broker  B: Broker  ASD: Automatic Service Deployment unit  S: Service  R: Resource 2015/12/4 5

SLA-based resource Virtualization Architecture  User: a person who wants to user a service  MN – Meta-Negotiator: mediates between user and meta- broker that selecting appropriate protocols for agreements; negotiates SLA creation, handles fulfillment and violation  MB – Meta-Broker: to select a broker that is capable of deploying a service with the user needs  B – Broker: interacts with resources and ASD  ASD – Automatic Service Deployment: installs the required service on the selected resource on demand  S – Service: the service that users want to deploy and execute  R – Resource: physical machines, on which virtual machines can be deployed 6

7 Interactions of SRV Components  SLA Negotiation:  Step 1: User starts a negotiation for executing a service with certain QoS requirements (specified in a Service Description (SD) with an SLA)  Step 2: MN asks MB, if it could execute the service with the requirement  Step 3: MB matches the requirements to the properties of the available brokers and replies with an acceptance or a different offer for renegotiation  Step 4: MN replies with the answer of MB, step 1-4 may continue for renegotiation until both sides achieve an agreement :MN Service request with QoS requirements Reply :User If MB could execute the service? :MB Do_Match Accept or other offerings

8 Interactions of SRV Components  Service Initiation:  Step 5: User calls the service with the SD and SLA  Step 6: MN passes the SD and the possibly transformed SLA (to the protocol that selected broker understands)  Step 7: MB calls the selected Broker with SLA and a possibly translated SD (to the language of Broker)  Step 8: Broker executes the service with respect to the term of SD and SLA :MN Service call Reply :User Service call :MB Reply Broker Service Execution Service call Reply Resource

9 Interactions of SRV Components  Automatic Service Deployment (ASD)  ASD monitors the states of the virtual resources and deployed services  ASD reports service availability and properties to its Broker  All Brokers report available service properties to the MB

Agreement Negotiation – Meta Negotiation  Meta-Negotiation documents includes:  The pre-requisites to be satisfied for a negotiation Example: authentication method, terms that participants want to negotiate on  The negotiation protocols and document languages for the specification of SLAs  Conditions for the establishment of an agreement Example: a required third-party arbitrator  Meta-Negotiation documents are published into a searchable registry through which participants can discover suitable partners for conducting negotiations 2015/12/4 10

Agreement Negotiation – Meta Negotiation  Meta-Negotiation Example 2015/12/4 11

2015/12/4 12 Meta-Negotiation Infrastructure Meta-Negotiation Middleware: 1.Facilitates the publishing of meta- negotiation document 2.Integrates with existing service infrastructure 3.Delivers information for negotiation

Service Brokering  Meta-Broker (MB) acts as a mediator between users or higher level tools and environment-specific resource managers (i.e., brokers)  To gather broker properties (availability, provided services, etc.)  To interact with MN to create agreements for service calls  To schedule service calls to lower level brokers  To forward service calls to the brokers 2015/12/4 13

14 Meta-Broker Architecture  Translator: responsible for translating the resource specification defined by the user to the language of the appropriate resource broker  Information Collector (IC): Stores the data of the reachable brokers and the historical data of the previous submissions  BPDL: Broker Property Description Language

15 Service Brokering Architecture  IS Agent: A component that regularly checks the load of underlying resources of each connected broker and the ASD (to estimate the service invocation time). The data would be stored into IC  MatchMaker (MM): Lists a group of brokers that can provide the service, and rank them based on IC’s data

Interactions of the Components of Meta-Broker during Utilization 2015/12/4 16 :MB_Core Service call :MN :MatchMaker :InfColl :Parser Parse doMatch :Invoker :Broker getInfo Service call Selected Broker

Service Deployment and Virtualization - ASD  Automatic Service Deployment (ASD):  A component that can install the required service on the selected resource on demand  Built on a repository where all master copies (virtual appliance, VA) of deployable services are stored  Allows broker to check if the service is deployed and available. If not, it checks whether any of the resource can deliver the service taking into account of the deployment cost  Monitors the states of the virtual resources and deployed services, and report to the brokers  Workspace Service (WS): to offer virtualization capabilities 2015/12/4 17

Service Deployment and Virtualization - ASD 2015/12/4 18

Case Study – Maxillo Facial Surgery Simulation (MFSS)  MFSS application facilitates the work of medical practitioners and provides the pre-operative virtual planning of maxilla-facial surgery  Steps of MFSS 1. Mesh generation: is used for generating meshes necessary for the finite element method simulation 2. Mesh manipulation: defines the initial and boundary conditions for the simulation 3. Finite element method (FEM): a fully parallel numeric technique application usually running on a remote HPC cluster 2015/12/4 19

Case Study – Maxillo Facial Surgery Simulation (MFSS) 1. Transform the meta-negotiation document into XML-based document 2. The document is passed to meta-broker 3. Meta-broker receives service description (SD) and SLA 1. Matchmaking to select the broker 2. Selected broker receives SD and calls the ASD to deploy the service, or chooses an already deployed, but idle computing service 4. The job is executed and the result are returned to the workflow enactor 5. ASD decommission the service 20

Related Work  SLA handling – negotiation, brokering and deployment – in web services and Grid services  Brokering that aims on supporting Grid applications with resources located in different domains  Service deployment solutions that focus on Grid applications 2015/12/4 21

Conclusions & Comments  Conclusion:  An architecture of SLA-based resource virtualization with on-demand service deployment is introduced Meta-negotiation for generic SLA management Meta-brokering for diverse broker management ASD for resource virtualization in the Cloud  Comments:  An architecture-wise paper that does not touch deeper issues, especially in service deployment section 2015/12/4 22