S-Cube Learning PackageSLA-based Service Virtualization in distributed, heterogenious          environments    MTA SZTAKI,...
Learning Package Categorization                        S-Cube                     Self-* Service                      Exec...
Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion ...
Service Execution lifecycle within S-Cube                                User taskflow                          Agreement ...
Problem description In heterogeneous, distributed service-based environments such as Grids  and Clouds, there is an emerg...
Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion ...
SLA-based service virtualization (SSV)architecture                                 Meta-Negotiator                        ...
Parties, components    User: A person, who wants to use a service (also called as consumer)    MN – Meta-Negotiator: A c...
Target areas, operational steps                User                                                        Information on ...
Means of negotiation   User – MN: user supplies a specific meta-negotiation document   MN – MB: agreeing on specific neg...
Meta-Negotiation in SSV Responsible for  creating low-level  agreements from  general user  requirements MB provides  ag...
Sample Meta Negotiation document<meta-negotiation xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance … > <entity> <ID nam...
Meta-negotiation steps Publish. A service provider publishes descriptions and conditions of  supported negotiation protoc...
Meta-brokering in SSV Meta-brokering means a higher level resource management  that utilizes existing Brokers to access v...
Meta-Broker components   The Meta-Broker is the core component: this communicates with the other    components   The Tra...
Automatic Service Deployment in SSV Automatic service  deployment is a higher  level service  management concept  which p...
ASD architecture details Repository – holds the images of various services as ready to use virtual  machine images (Virtu...
Component interactions in SSV
Simulation environment for managing services  in a heterogenious environment    SSV                          J            ...
Brokers in the simulation: Grid brokers are extended GridUser entities:   – they can be connected to one or more resource...
Simulator entity The Simulator class is an extended GridSim entity:   – it can generate and submit a requested number of ...
Simulation setup 4 virtual appliances encapsulate the four different services of the TINKER  workflow: GEN, TINKERALG, CO...
Results On demand deployment  introduces some overhead Service duplication  increases performance                       ...
Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion ...
Emerging Clouds As the interests towards Cloud Computing solutions are  growing, the need for federating separate Cloud s...
Cloud delivery models                   Software as a Service                   Platform as a Service                 Infr...
Federated Cloud Managementarchitecture The introduced SSV architecture can be extended and  focused on infrastructure Clo...
FCM architecture Each CloudBrokerhas an own queuefor storing theincoming servicecalls, and managesone virtual machinequeu...
Cloud brokering in FCM The default virtual machine scheduling is based on the  currently available requests in the queue,...
Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion ...
Discussion and futher research directions In this learning package we revealed how to manage different  service infrastru...
Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion ...
Summary Service provisioning can be facilitated with an SLA-based  Service Virtualization architecture built on three are...
Further S-Cube ReadingA. Kertesz, G. Kecskemeti, I. Brandic, I. An SLA-based resourcevirtualization approach for on-demand...
Acknowledgements      The research leading to these results has      received funding from the European      Community’s S...
Upcoming SlideShare
Loading in …5
×

S-CUBE LP: SLA-based Service Virtualization in distributed, heterogenious environments

639 views

Published on

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

S-CUBE LP: SLA-based Service Virtualization in distributed, heterogenious environments

  1. 1. S-Cube Learning PackageSLA-based Service Virtualization in distributed, heterogenious environments MTA SZTAKI, TU Wien (TUW) Attila Kertesz, SZTAKI www.s-cube-network.eu
  2. 2. Learning Package Categorization S-Cube Self-* Service Execution Infrastructure Mechanisms for the Run-Time Adaptation of Services SLA-based Service Virtualization
  3. 3. Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion Conclusions
  4. 4. Service Execution lifecycle within S-Cube User taskflow Agreement negotiationService Discovery Service BrokeringService Registry Service Deployment Virtual Resource
  5. 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. 6. Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion Conclusions
  7. 7. SLA-based service virtualization (SSV)architecture Meta-Negotiator Autonomic Manager Meta-Broker Broker … Broker Automatic Sevice Deployer Production Grids Clouds Web Services
  8. 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. 9. Target areas, operational steps User Information on availability, properties MN MB ... B B SLA negotiation, assurance ... ... ASD ASD ASD ASDS S R R S R R
  10. 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. 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. 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. 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. 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. 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. 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. 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. 18. Component interactions in SSV
  19. 19. Simulation environment for managing services in a heterogenious environment SSV J GridSim CloudSimB Meta- JB B Simulator J extension extension Broker result… … P P Broker P … Broker P Cloud Broker … … IS M M M Data- VMGrids load Resource M Resource M … Resource M center VM … … … … Workload Workload … Workload GridSim CloudSim
  20. 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. 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. 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 services 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. 23. Results On demand deployment introduces some overhead Service duplication increases performance  Further investigation of deployment strategies are needed
  24. 24. Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion Conclusions
  25. 25. Emerging Clouds As the interests towards Cloud Computing solutions are growing, the need for federating separate Cloud systems is inevitable.
  26. 26. Cloud delivery models Software as a Service Platform as a Service Infrastructure as a Service
  27. 27. Federated Cloud Managementarchitecture 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. 28. FCM architecture Each CloudBrokerhas an own queuefor storing theincoming servicecalls, and managesone virtual machinequeue (VMQ) foreach appliance (VA).
  29. 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. 30. Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion Conclusions
  31. 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. 32. Learning Package Overview Problem Description SLA-based Service Virtualization Federated Cloud Management Discussion Conclusions
  33. 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. 34. Further S-Cube ReadingA. Kertesz, G. Kecskemeti, I. Brandic, I. An SLA-based resourcevirtualization approach for on-demand service provision. In Proceedings ofthe 3rd international Workshop on Virtualization Technologies in DistributedComputing. VTDC 09. ACM, New York, NY, 27-34, 2009.A. Kertesz, G. Kecskemeti, I. Brandic, Autonomic SLA-aware ServiceVirtualization for Distributed Systems, In proceedings of the 19th EuromicroInternational Conference on Parallel, Distributed and Network-BasedComputing, IEEE Computer Society, pp. 503-510, 2011.A. Cs. Marosi, G. Kecskemeti, A. Kertesz, P. Kacsuk, FCM: an Architecture forIntegrating IaaS Cloud Systems, In Proceedings of The Second InternationalConference on Cloud Computing, GRIDs, and Virtualization.Rome, Italy. September, 2011.
  35. 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).

×