Hierarchical SLA-based Service Selection for Multi-Cloud Environments
•
3 likes•1,016 views
Cloud computing popularity is growing rapidly and consequently the number of companies offering their services in the form of Software-as-a-Service (SaaS) or Infrastructure-as-a-Service (IaaS) is increasing. The diversity and usage benefits of IaaS offers are encouraging SaaS providers to lease resources from the Cloud instead of operating their own data centers. However, the question remains for them how to, on the one hand, exploit Cloud benefits to gain less maintenance overheads and on the other hand, maximize the satisfactions of customers with a wide range of requirements. The complexity of addressing these issues prevent many SaaS providers to benefit from the Cloud infrastructures. In this paper, we propose HS4MC approach for automatic service selection by considering SLA claims of SaaS providers. The novelty of our approach lies in the utilization of prospect theory for the service ranking that represents a natural choice for scoring of comparable services due to the users preferences. The HS4MC approach first constructs a set of SLAs based on the given accumulated SaaS provider requirements. Then, it selects a set of services that best fulfills the SLAs. We evaluate our approach in a simulated environment by comparing it with a state-of-the-art utility based algorithm. The evaluation results show that our approach selects services that more effectively satisfy the SLAs.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Hierarchical SLA-based Service Selection for Multi-Cloud Environments
Similar to Hierarchical SLA-based Service Selection for Multi-Cloud Environments (20)
Recently uploaded
Recently uploaded (20)
Hierarchical SLA-based Service Selection for Multi-Cloud Environments
- 1. Hierarchical SLA-based Service Selection for Multi-Cloud Environments Soodeh Farokhi, Foued Jrad, Ivona Brandic and Achim Streit Vienna University of Technology, Austria
- 2. Motivation Scenario SaaS providers potentianl IaaS users • Less maintenance overhead • More customer satisfaction Multiple Clouds • Various QoSs and pricing models Service Level Agreement Multi-Cloud delivery model Problem: SLA-based Multi-Cloud Service selection for the SaaS provider 2 CAD Application UI (1 Large VM) CAD Models (2x 1000 GB Storage) GPU (5 Large VM) CAD App Provider CAD App Customer HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 3. Approach Overview Problem domain • Handling SLA heterogeneity • Maximizing SaaS provider benefits Solution domain • InterCloud-SLA • Service selection by utilizing prospect theory 3HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 4. Prospect Theory is a behavioral economic theory • by Daniel Kahneman in 1979 (Nobel prize in 2002) • a descriptive model for decision making under uncertainty • based on the potential value of losses and gains rather than the final outcome Alternative decision making model for the Utility Theory • more realistic in calculating the user satisfaction • psychologically more accurate First application at Cloud service selection problem What is the Prospect Theory? 4HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 5. Service Ranking • Calculating the user satisfaction based on Prospect Theory principles Determining how well a service satisfies a user’s requirements • Satisfaction with a specific service is not the same for different users • The most suitable service for a user is not the one with the best QoS Modeling user satisfaction as a function of • Service quality • The importance of each QoS parameter Using Prospect Theory 5HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 6. HS4MC Phases and Architecture Phases • Phase 1: SLA Construction − Meta-SLA − Sub-SLA • Phase 2: Service Selection − Service Selection Algorithm 6 SLA Repository IaaS offers Repository SLA Construction Engine Meta-SLA Sub-SLA Service Selection Engine Service Ranker Composite Service Ranker SaaS provider Requirements Phase 1 Phase 2 2 sub SLA InterCloud SLA Meta SLAsub SLA sub SLA sla sla sla sla Composite Infrastructure Service
- 7. Meta-SLA and Sub-SLA 7 Meta-SLA Parameters Functional Contract duration hour Non-functional VM Budget $ per hour Storage Budget $ per month Data-traffic Budget $ per month Availability % Throughput Mbit/ sec Latency ms Reputation 1 to 10 Sub-SLA Parameters Functional Resource type VM or Storage Resource Size S, M, L Number How many? Geo-location Where? Non-functional Availability % Response time sec Reputation 1 to 10 For Multi-Cloud App (Composite infrastructure service) For each component of composite service Non-functional tuple= {Min, Max, Weight, Type} e.g. Availability (%) = {99.5, 100, very important, soft} HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 8. Motivation Scenario (details) CAD application distributed on Multi-Cloud (CAD-as-a-Service) (1) Computation, GPU (VMs) • high performance (2) CAD application UI (VM) • high availability, low response time (3) Cloud storages • geo-location, reputation Aggregated QoS • resource cost, traffic costs, latency 8 meta-SLA CAD Application UI (1 Large VM) sub-SLA (UI) CAD Models (2x 1000 GB Storage) sub- SLA (Storage) GPU (5 Large VM) sub- SLA (Computation) CAD App Customer sub-SLAs meta-SLA HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 9. Service Selection Algorithm (simplified) 9{s4, s10, s2, s3} 1 23 {s8, s4} {s5, s10, s3} Scored lists Step 2 {S2, S3, S4, S10} 1 23 {S4, S8} {S3, S5, S10} Filtered lists Step 1 Available services : {S1, S2, S3, …, S10} Step1 Filtering out unqualified services for each sub-SLA • Hard non-functional constraints • Functional constraints Step 2 Local scoring of services • Sub-SLA values and weights • Sub-scoring based on satisfaction function
- 10. Satisfaction Function 10 Availability = {Min, Max, Weight} = {99.5, 100, w1 / w2 / w3} Service1 = {QoS, Value} = {Availability, 99.7} -------------------------------------------------------------------------------- Normalize value 99.7% = 0.4 as normalized value -------------------------------------------------------------------------------- Calculate satisfaction score HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 11. All possible combinations (meta-SLA ranking) ranked 1: {s10, s4,s2} ranked 2: {s5, s4, s4} …. ranked 24: {s3, s8, s3} Service Selection Algorithm (simplified) 11 Step 3 Step 4 Best combination (meta-SLA and sub-SLA ranking) {s5, s4, s4} {s4, s10, s2, s3} 1 23 {s8, s4} {s5, s10, s3} Sorted lists Step 3 Scoring of possible compositions • Meta-SLA values and weights • Aggregated QoS values of selected services • Meta-scoring based on satisfaction function Step 4 Finding the best combination of services • Considering both meta-score and sub-scores Evaluation
- 12. Evaluation (1) Comparing functionality with a utility-based algorithm [Jrad et al., 2013] • Implementing both algorithms • Considering SLA satisfaction as metric Setup a realistic simulation environment • Simulating 12 commercial IaaS Cloud providers (20 distributed DC) − QoS attributes by using CloudHarmony service (via a Client located at Europe) − Pricing models based on real Cloud providers Considering the impact of 3 aspects on service selection • Cost, meta-SLA, and sub-SLA 12
- 13. Evaluation (2) Using CAD app scenario for users (3 software editions) • One Meta-SLA for each software edition • Three sub-SLA (UI, Computation, Storage) for each software edition 13 Meta-SLAs Sub-SLAs
- 14. Theorotical Comparison Features Utility-based algorithm Prospect-based Algorithm Cost Focused, fixed and predefined impact Flexible impact like other QoSs Weighting From (0,1] dependently for each parameter From (0, 1] independently SLA satisfaction Meta-SLA Both meta-SLA and sub-SLA Hard non-functional - supported Fitting function Separated and predefined for each QoS Unified based on prospect theory, flexible by weight (scalable to support more QoS) 14
- 15. Experimental results (1) Impact of cost on service selection • Minimizing cost is the main goal for the user • 3 executions of both algorithms for each software edition − result of standard edition: 15 HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 16. Experimental results (2) Impact of meta-SLA parameters on service selection • Availability is as important for the user as cost • One execution of both algorithms − result of enterprise edition setup: 16HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 17. Experimental results (3) Impact of sub-SLA parameters on service selection • User has specific non-functional requirements for sub-components (UI, Storage) • One execution of both algorithms − result of professional edition setup: 17HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 18. Summary Proposing for the SaaS providers • Multi-Cloud Service selection • InterCloud-SLA concept (sub-SLA and meta-SLA) Service Selection Algorithm • Justification of using prospect theory to rank the Cloud services Evaluation • Tendency of choosing a single Cloud (latency and traffic cost) • The importance of Sub-SLA concept in a Multi-Cloud environment • Cost is not always the most important factor 18HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 19. Future Work scalability of algorithm (performance evaluation) Complete InterCloud-SLA construction phase • IEEE InterCloud Working Group (ICWG), InterCloud-SLA Investigating on Multi-Cloud SLA management steps at runtime • SLA monitoring strategies • SLA violation detection and (pre) reaction • SLA validation and enforcement (developing penalty model) Related paper • Soodeh Farokhi, “Towards a Multi-Cloud SLA Management Framework”, Doctoral Symposium 14th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid 2014), USA, May 26-29, 2014 - accepted. 19HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 20. Thank you for your attention Soodeh Farokhi Distributed System Group, Institute of Information Systems, Vienna University of Technology, Austria soodeh.farokhi@tuwien.ac.at http://www.infosys.tuwien.ac.at/staff/sfarokhi/ 20HS4MC: Hierarchical SLA-based Service Selection for Multi-Cloud Environments (CLOSER 2014)
- 21. 21 Backup slides
- 22. Multi-Cloud SLA Management FW 22
- 23. Theoretical Comparison (2) Utility-base Algorithm Utility = QoS Scores * Budget – Service Cost Prospect-based Algorithm Final Score = SS sub-SLAs* Wsub-SLA + SS meta-SLA * Wmeta-SLA 23
- 24. Aggregate Functions Non-functional parameters in the meta-SLA • corresponding aggregation function • To calculate the aggregated values of composite service non-functional parameters based on its constituent services. 24
- 25. Latency Calculation W(Sij) is the connectivity value of each edge in the graph Lat(Sij) is gathered from the latency matrix • According to the data center geographical location of included services in the composition. 25
- 28. Utility based algorithm (details) The utility for each composite service is calculated by subtracting the total service usage costs (include VM, traffic, storage) from its monetized usage benefit. Monetized usage benefits: multiplying his overall score for the SLAs with his maximal payment for a perfect service The overall SLA scores (a normalized value between 0 and 1), defined as the sum of the weighted single SLA parameter scores, express the overall user satisfaction for a certain service quality. SLA score: uses fitting functions to map each SLA metric value to a satisfaction level between 0 and 1. 28
- 29. Prospect theory (details) This theory implies that changes in a specific quality aspects of a service is sensed more by users who have assigned higher weights to those quality parameters. The satisfaction of user for a service is based on the gains and losses relative to the reference point (normalized value of 0.5) instead of absolutely determined by the normalized QoS parameters of that service. The satisfaction function should be concave for gains, and convex for losses. 29
- 30. What is missing in the related work? Cloud Service Selection • Maximizing the profit of either the customer or the IaaS provider • Using only single Cloud services • Without throughly investigate SLA challenges 30
- 31. Budget Calculation/ Cost Prediction Budget: willingness of the user’s investment • VM a unit of cost: value of renting a small VM per hour • Storage cost: value of storing1GB of data per month • Data Traffic cost: value of transferring 1GB of data per month − Considering contract duration and the size of possible transferred data 31
- 33. Experimental results (1st and 2nd) Impact of cost on service selection • Minimizing cost is the main goal for the user • 3 executions of both algorithms for each software edition setup − result of standard edition: 13
- 34. Multi-Cloud middleware SLA hierarchy 34 Multi-Cloud SLA SLA SLA SLA SaaS provider customer customer SLA SLA Infrastructure Requirement Sub SLA sub SLA sub SLA Middleware Layer meta SLA InterCloud SLAs SLA SLA SLA SLA IaaS provider Layer IaaS provider SLAs SaaS Provider Layer SaaS provider Infrastructure Requirement
Editor's Notes
- Good morning everybody and welcome to my talk. I‘m gonna present a new method for service selection for Multi-Cloud called HS4MC. Let‘s start with a motivation scenari >> General points: Speed of my talking Start my talk with asking a simple Q: How many of you thinking about how to select a Cloud service so far? My core message should be repeated and emphaisized several times (specially in summary and motivation) Use coloring to make some points special ... Very rare but for important ones Pause in talking before saying important points and give signal in talking when I want to start major slides. Pronounce: Multi, Component, virtual Machine, Economics, nobel prize, Daniel Kahneman, Tell them that Intro and Background they are familiar with and it is only for reminding some points
- Consider a Computer Aided Design (CAD) software company who wants to offer its CAD software to its customers as a Cloud software services. It has various way to deploy the various components of this software (Data based for keeping CAD models, Virtual machine for deploying the CAD application user interface and another virtual machine for Graphical Processing Unit (GPU) with various QoS requirements for each component whether a private data center or using public Cloud infrastructure services. For decreasing maintenance overhead and more importantly increase the customer satisfaction level in a very comparative environment, SaaS provider decides to deploy on Cloud infrastructure services. There are two major points in this scenarios, first this deployment is not for a short time as we consider Software-as-a-Service (SaaS) provider as a Cloud infrastructure user (so we work in the level of a software company not an end user), and moreover, realizing the requested requirements effect the quality of offered services and consequently the reputation of SaaS provider. As I mentioned there are various components which are needed to be deployed on Could in order to execute the CAD software, each may need different quality of service requirements, it is like a composite infrastructure service request high availability and good response time for the application UI Good reputation and geo-location (security aspects) for DB High performance for VM related to the GPU So all these requirements are not satisfiable only by using a single Cloud so we need to utilize Multiple Cloud services (based on a Multi-Cloud delivery model) is an effective solution which we used in our approach. The problem remains is how to choose services for the SaaS provider in order to catch its goal (decrease overhead and increase the customer satisfaction) Well, let’s look at the overview of our approach at the next slide >> IaaS and SaaS providers and their offered services are growing rapidly! - SaaS providers are looking into solutions that minimize their overall infrastructure leasing cost without adversely affecting the customers (which have wide range of requirements these days). To achieve this goal, it is essential to have a clear definition of user requirements and then provide a solution by which these requirements are met. Computer-aided design (CAD) is the use of computer systems to assist in the creation, modification, analysis, or optimization of a design. CAD software is used to increase the productivity of the designer, improve the quality of design, improve communications through documentation, and to create a database for manufacturing. The rationale behind choosing this example is that deploying CAD applications in the Cloud has been investigated widely; for example it is used in the Cloudflow project 4 which has the aim to make the Cloud infrastructures a practical solution for manufacturing by automatic provisioning of SaaS applications over Cloud infrastructure services. The advantages of deploying on cloud: 1. Scalable infrastructure (VM and storage) 2. client with sharing and collaboration support 3. Cost: pay per usage
- We took provider perspective. There are three layers in this problem, customer layer, SaaS provider layer and IaaS provider layer. As I mentioned SaaS provider is considered as our user, so it has various requirements for the software deployment, On the other hand, we have a Multi-Cloud IaaS environment with different QoSs and pricing models. As all of us is know, in a Multi-Cloud delivery model, we have a middle-ware which handles the interaction among various Cloud services. The proposed approach sits at the middle-ware layer and assists SaaS providers to effectively select best fit infrastructure services in such a way to Maximize the SaaS provider benefits Handling SLA heterogeneity How to achieve that? Our solution has these features: In such environment, SLA plays a critical roles, so we construct SLAs which are provider independent called InterCloud-SLAs We consider the SaaS provider request as a Composite infrastructure request And the major point is using the principles of an economics theory called prospect theory for the service ranking in our method Well, in order to see what is this theory about and how we use it in this work let’s look at the next slides >> SaaS providers is our USER (By user we mean SaaS provider) The position of our approach SLA Hierarchy problem Multi-Criteria SLA-based Service selection in a Multi-Cloud environment Looking at the problem as a Composite Infrastructure Request, and defining SLAs for both sub-service and composite service - in Multi-Cloud dependent components of a single SaaS application can be distributively deployed in diverse Cloud infrastructures with various QoS attributes, from the SaaS provider perspective, the deployment can be considered as a Composite Infrastructure Service with a set of functional and nonfunctional requirements for each included application component. How to score and select services for each single component and on the other hand, optimize this allocation to satisfy the requirements of the composite service. 2) These concerned QoS parameters can be conflicting or have differing importance degrees for the SaaS provider.
- The diagram shows that the pain of losses is stronger than the pleasure of gains (The loss side of the curve is steeper than the gain side) Prospect theory is a behavioral economic theory that describes the way people make decisions It developed by Daniel Kahneman in 1979 as a psychologically more accurate description of decision making, comparing to the expected utility theory He won Nobel prize for this theory in 2002! This theory says people make decisions regarding to the potential values of losses and gains instead of final outcome So somehow we can consider it as a descriptive model to model real-life choices rather than optimal decisions Utility based theory is a widely accepted theory in service selection and now as an alternative model for that, we’re gonna apply prospect theory as the first application on Service Selection on Cloud Computing, At the next slide we will figure out where we can use the principle of this theory in service selection >>> A bit history about it! Nobel prize - Utility is the satisfaction one gets from consuming a good or service Many previous research works simply took utility values as satisfaction values. However, such approach assumes that the user’s satisfaction of a service candidate is proportionate to the service QoS attributes which is not always true as shown the prospect theory in economics. Using utility value as satisfaction value directly implies the satisfaction of a service candidate is only determined by service utility, and user’s satisfaction will be doubled if service’s utility value is doubled. For example, according to such hypothesis, a service’s price changes from 2$ per day to 1$ per day will double the user’s satisfaction. However, prospect theory [15,16] points out that the satisfaction should be based on the gains and losses relative to the reference point instead of absolutely determined by services’ normalized QoS utility value. According to the prospect theory, the satisfaction value function should be concave for gains and convex for losses, and the satisfaction value function that passes through the reference point is s-shaped and asymmetrical. It means that losses hurt more than gains feel good. Satisfaction is subjective and various for different users. The same QoS value will be gains for a user who lower weights while be losses for the user with higher weight.
- We user this theory in calculating the user satisfaction score for a specific Cloud service Indeed based on this theory the satisfaction with a specific service is not the same for different users How to model the user satisfactions? As you can see in this satisfaction function diagram, the satisfaction is a function of service quality and the importance and each QoS attribute for the user as it change the steep of the diagram based on the weight (we will discuss this modeling with more details later) - This theory implies that changes in a specific quality aspects of a service is sensed more by users who have assigned higher weights to those quality parameters. - Now that you got familiar with an overview of the solution, let’s have a look at the phases and the architecture which we realize this solution on at the next slide >> This theory is proper for describing user decisions among various choices with uncertainty, and considers human behavior in computation of the user satisfaction. Nobel prize - Utility is the satisfaction one gets from consuming a good or service Many previous research works simply took utility values as satisfaction values. However, such approach assumes that the user’s satisfaction of a service candidate is proportionate to the service QoS attributes which is not always true as shown the prospect theory in economics. Using utility value as satisfaction value directly implies the satisfaction of a service candidate is only determined by service utility, and user’s satisfaction will be doubled if service’s utility value is doubled. For example, according to such hypothesis, a service’s price changes from 2$ per day to 1$ per day will double the user’s satisfaction. However, prospect theory [15,16] points out that the satisfaction should be based on the gains and losses relative to the reference point instead of absolutely determined by services’ normalized QoS utility value. According to the prospect theory, the satisfaction value function should be concave for gains and convex for losses, and the satisfaction value function that passes through the reference point is s-shaped and asymmetrical. It means that losses hurt more than gains feel good. Satisfaction is subjective and various for different users. The same QoS value will be gains for a user who lower weights while be losses for the user with higher weight.
- The whole solution is realized through two main phases, at the first one, the interCloud SLAs are constructed for the requested composite infrastructure service and also each included component. At the second phase the Cloud infrastructures services are chosen based on the constructed SLAs and the SLAs of the Cloud IaaS offers. The introduced phases are mapped to the following architecture, which includes two main components, SLA constructor Engine (corresponding to the first phase) and Service selection which has the responsibilities of the second phase. The focus of this work is on the second phase. Well, you are wondering what are these two concepts, Meta-SLA and sub-SLAs, right? So, we are going to explain them at the next slide >> Say composite service here two main phases: SLA Construction phase the Composite Infrastructure Service of SaaS provider is broken down to a set of functional and non-functional requirements ,called sub-SLAs and a meta-SLA. (forms SLAs named InterCloud-SLAs that are provider-independent.) - As the input of this phase, the SaaS provider submits its Cloud infrastructure requirements to the SLA Construction Engine as a single XML file. (two abstract parts: one including the requirements for each infrastructure component (Cloud virtual machine (VM) or storage), and the other enfolding the requirements of the whole set of requested infrastructures.) (2) Service Selection phase - The InterCloud-SLAs and the IaaS providers’ offers are two inputs of this phase. - Meta-SLA includes the requirements of a more abstract level related to the whole composite service Sub-SLAs express requirements of each infrastructure service included in this composite service.
- In order to have InterCloud SLAs, we proposed two new concepts called meta-SLA and sub-SLA both have some functional and non-functional parameters: While Meta-SLA consists of the parameters related to the whole composite service sub-SLA includes the parameters corresponding to each included service of the composite service request For example for the whole composite service, as meta-SLA parameters, we will support availability, throughput, latency and reputation (a number from 1 to 10) And for each component, we define sub-SLA and cover functional parameters such as resource type (we support both Storage and VM in our work), number of each, size and location as well as availability, response time and reputation as non-functional parameters. Sub-SLA concept is a new concept in comparison with existing service selection approaches. Our general modeling is this way that for each non-functional parameter we have four attributes, lower accepted boundary, upper accepted boundary, the important of this parameter for the user and type of it. E.g. consider availability as a non-func parameter, …. , we treat with the hard non-functional parameters like functional parameters which have to be covered in the final solution instead of user preference Now, in order to have a clearer view of the introduced models, let’s again loot at he motivation scenario but this time with the constructed meta-SLA and sub-SLAs at the next slide >>
- We have three sub-SLAs which are related to each component: for the GPU and computation unit we need 5 large high performance VM For the application UI we need one large high available and low response time VM And for storing CAD models we need 2 large (1000 GB) Cloud storage, located in Europe and their provider has high reputation We also have some parameters corresponding to the whole CAD software deployment, which are meta-SLA parameters such as resource cost (VM, storage), traffic cost and latency. Until now, we introduced the supported SLA, motivation scenarios and the idea of our service selection, now let’s start the “Service Selection Algorithm” which are based on the principles of prospect theory at the next slides >> - Deploying CAD applications in the Cloud has been investigated widely; - CAD software provider aims to deploy its CAD software in Cloud and offers it as a public Cloud SaaS, called CAD-as-a-Service (CAD-aaS), in three software editions: enterprise, professional and standard. Each edition has a specific set of requirements. The CAD-aaS provider wants to deploy the various components of its CAD service. The components communicate with each other based on the CAD software application topology. 5 large VM with GPU features for the computation component
- The cornerstone of the Service Selection Phase is a selection algorithm that works based on prospect theory to compute the user satisfaction score for a certain service. - Due to the variety of differing nonfunctional parameters in metrics and scales for a given service set, they are needed to be normalized before being used in service ranking.
- So again consider availability as a non-functional parameter requested at sub-SLA by Min, Max and importance weight, we want to see how to calculate the satisfaction score of a service based on this SLA values in our “Service Selection Algorithm”: First of all Step (2) Due to the variety of differing nonfunctional parameters in metrics and scales for a given service set, they are needed to be normalized before being used in service ranking, where NF is the value of availability of the Cloud service, and Min and Max are the accepted boundaries included in the SLA. Then based on the satisfaction scoring function, which is a function of the normalized value and the importance weight, we calculate the satisfaction score of a specific service aspect (like availability) for a certain SLA parameter. Suppose we have three users who assign three different weights to “Availability” as a non-functional values, based on the following diagrams, the satisfaction of them for the same service are not the same, if we consider 0.5 as a reference normalized value, for example the higher the importance weight the lower satisfaction of user of that service and vise versa for the normalized values greater than 0.5, e.g. 0.6 Until now we have introduced the “Service Selection Algorithm” along with the sub-SLA and meta-SLA concepts, at the next slides we will explain how we have evaluated our work >> We normalize service quality parameters in such a way that the higher value always means better. This formula computes the user satisfaction score of the normalized value Nik of each non-functional parameter in Si based on the Wj in subSLAj - In the diagram that the accepted boundaries are 99.5% as minimum and 100% as maximum, then the normalized value of 0.4 (value=99.7%) has different satisfaction scores for standard, professional and enterprise users based on their specified weights. - Justify how I use the prospect-theory to calculate the satisfaction function for each normalized value of NF and Weight.
- We will explain the prospect-based satisfaction function at the next slide >>
- As mentioned before now, proposed theory is an alternative model for the widely accepted and used utility theory, so for the evaluation, we compare the result with a state-of-the-art utility-based algorithm, For this reason, we setup up a simulation environment and to model a heterogeneous multi-Cloud environment we simulated 12 commercial IaaS provider profiles (in total 20 distributed data centers) by using Cloud test at “Cloud Harmony” service to have To have various SLA parameters, we consider that CAD software provider is going to deploy three different software editions (standard, professional and enterprise) of the CAD software on Cloud, so it has different set of requirements (sub-SLAs and meta-SLA) for each software edition. At the next slides we will see the experimental results via various test scenarios >>
- Practice More (these 3 slides)! At the first scenario, we showed that the proposed algorithm (prospect-based) can behave almost the same as as the utility-based algorithm in case that cost is the most important factor in service selection. We consider the standard software edition SLAs, as cost is a major factor for the standard users. although the impact of cost in the prospect-based algorithm is not a predetermined like the utility-based algorithm, by assigning proportional weights to the service selection criteria, the proposed algorithm can behave the same as a utility-based method which is widely accepted at Cloud service selection from the efficiency point of view. At the diagrams, the first column shows the requested meta-SLA value for different non-functional parameters (availability, throughput, latency and reputation) The second column (green one) shows the value of this parameter for the selected services included in the composite service using the utility-based algorithm and the red one is the corresponding values of these parameters by using the prospect-based algorithm. For example Reputation is not supported by the utility-based algorithm, that’s why we don’t have any value for it here Both algorithm at this scenario chose services from the same provider, that’s why the value of Traffic-cost at the last diagram are zero for them.
- At this scenario, we consider a case in which another non-functional parameter is as important as cost for the user, for example SaaS provider need high available composite service for the deployment of an enterprise software edition, at this case the prospect-based algorithm outperformed the utility based algorithm. As there is a violation of SLA (availability) for the chosen services by utility-based algorithm corresponding. It selects more suitable services which first do not violate any requested meta-SLA parameters, and then chooses the services with better quality values for the parameters that are more important for the user.
- The last test scenario, highlights one of a new features of the proposed algorithm, which is supporting sub-SLA instead of only considering an SLA for the whole composte service as almost all the existing service selection algorithm support. It means the proposed algorithm not only tries to find an optimum composite service with accepted aggregated QoS values to satisfy the meta-SLA, but also consider the sub-SLA. While, existing service selection algorithms that support composite service selection, only focus on finding the set of services which satisfies the aggregated QoS parameters and neglect to view the included services in this composite service separately. We can cover this need easily by the sub-SLA concept. Utility-based algorithm could not support non[-functional parameters as sub-SLAs! The diagrams shows that the selected services satisfied all requested values mentioned at sub-SLAs as well as aggregated values of meta-SLA. Well now let’s summarize my talk at the next slide >>
- Let me just summarize We proposed a method called HS4MC as an assistant of the SaaS provides for two goals: Service selection for Multi-Cloud environmnts Constructing Inter-Cloud SLA concept in order to handle SLA heterogeneity of IaaS providers in this environment The cornerstone of our work was a service selection algorithm which works based on the principle of an economics theory called “Prospect theory” for the calculation of user satisfaction of a certain service based on the SLA (The top ranked service has largest satisfaction score not the best QoS!) Well, let’s briefly look at the future steps of our work as the last slide >> The top ranked service is the service with the largest satisfaction score which means that the service’s QoS can best satisfy users’ QoS requirements. Hence, the services whose QoS qualities are not the best among those of all available services satisfying the user’s QoS requirements can still be ranked on the top as long as they can perfectly satisfy users’ QoS requirements. This is helpful in improving services’ utilizations, and save resources. users’ feeling on how well services’ QoS qualities satisfy their QoS requirements is modeled with the prospect theory, which considers human behavior and psychological principles in the computation of services’ satisfaction scores. Make it clear for my message ! (less text and very clear focus ! >>> and focus on benefits of my model) >>> Coloring and mention the HS4MC!!
- Let me just summarize We proposed a method called HS4MC as an assistant of the SaaS provides for two goals: Service selection for Multi-Cloud environmnts Constructing Inter-Cloud SLA concept in order to handle SLA heterogeneity of IaaS providers in this environment The cornerstone of our work was a service selection algorithm which works based on the principle of an economics theory called “Prospect theory” for the calculation of user satisfaction of a certain service based on the SLA (The top ranked service has largest satisfaction score not the best QoS!) Well, let’s briefly look at the future steps of our work as the last slide >> The top ranked service is the service with the largest satisfaction score which means that the service’s QoS can best satisfy users’ QoS requirements. Hence, the services whose QoS qualities are not the best among those of all available services satisfying the user’s QoS requirements can still be ranked on the top as long as they can perfectly satisfy users’ QoS requirements. This is helpful in improving services’ utilizations, and save resources. users’ feeling on how well services’ QoS qualities satisfy their QoS requirements is modeled with the prospect theory, which considers human behavior and psychological principles in the computation of services’ satisfaction scores. Make it clear for my message ! (less text and very clear focus ! >>> and focus on benefits of my model) >>> Coloring and mention the HS4MC!!
- Invite the audience to ask any questions (I am looking forward to comments and Qs) Thank people for good Qs (I am glad you ask that …)
- The last part in our modeling is a graph which describes the degree of connectivity among sub-SLAs (a number between 1 to 3, larger means higher connectivity). In this graph, the nodes present the sub-SLAs and the edge shows to which degree these two corresponding components are going to transfer data at runtime, which influence the traffic cost and latency of the composite deployment. As depicted in Figure 3, the connectivity value for each edge shows the amount of data transfer between the involved nodes. For example, the computation node transfers the highest amount of data with the storage node, among other edges in the CAD-aaS graph.
- although the impact of cost in the prospect-based algorithm is not a predetermined like the utility-based algorithm, by assigning proportional weights to the service selection criteria, the proposed algorithm can behave the same as a utility-based method which is widely accepted Cloud service selection from the efficiency point of view. Describe these three slides with every details, we have time so don’t worry about it! (describe every things, how we measure them, why traffic cost is 0, why there is no line for reputation of utility-based theory) ….
- The position of our approach SLA Hierarchy problem Multi-Criteria SLA-based Service selection in a Multi-Cloud environment Looking at the problem as a Composite Infrastructure Request, and defining SLAs for both sub-service and composite service - in Multi-Cloud dependent components of a single SaaS application can be distributively deployed in diverse Cloud infrastructures with various QoS attributes, from the SaaS provider perspective, the deployment can be considered as a Composite Infrastructure Service with a set of functional and nonfunctional requirements for each included application component. How to score and select services for each single component and on the other hand, optimize this allocation to satisfy the requirements of the composite service. 2) These concerned QoS parameters can be conflicting or have differing importance degrees for the SaaS provider.