28
Ruppa K. Thulasiram Slide 1/24 Resource Provisioning Policies to Increase IaaS Provider’s Profit in a Federated Cloud Environment Adel Nadjaran Toosi * , Rodrigo N. Calheiros*, Ruppa K. Thulasiram , and Rajkumar Buyya* * Cloud Computing and Distributed Systems (CLOUDS) Laboratory, Department of Computer Science and Software Engineering The University of Melbourne, Australia Department of Computer Science University of Manitoba, Canada Ruppa K. Thulasiram Email: [email protected]

Ruppa K. Thulasiram Slide 1/24 Resource Provisioning Policies to Increase IaaS Provider’s Profit in a Federated Cloud Environment Adel Nadjaran Toosi *,

Embed Size (px)

Citation preview

Ruppa K. Thulasiram Slide 1/24

Resource Provisioning Policies to Increase IaaS

Provider’s Profit in a Federated Cloud EnvironmentAdel Nadjaran Toosi*, Rodrigo N. Calheiros*, Ruppa K. Thulasiram, and Rajkumar Buyya*

* Cloud Computing and Distributed Systems (CLOUDS) Laboratory, Department of Computer Science and Software Engineering

The University of Melbourne, Australia

Department of Computer ScienceUniversity of Manitoba, Canada

Ruppa K. ThulasiramEmail: [email protected]

Ruppa K. Thulasiram Slide 2/24

Outlinel Cloud Computing and Cloud Federation

• Cloud computing motivations

l Resource Provisioning in Federated Cloud Environmentsl System Modell Problem Statementl Proposed Policiesl Performance Evaluation

• Experimental Setup

• Results

l Conclusion and Future Work

Ruppa K. Thulasiram Slide 3/24

Cloud Computingl Cloud Computing

• Long-held dream of computing as a utility• On-demand delivery of IT services• Customers pay for what they use• virtualized resources

l Clouds services:• Software as a Service (SaaS)

» Software solutions on a subscription model (Salesforce.com)

• Platform as a Service (PaaS)» Development and runtime environments (Google App Engine)

• Infrastructure as a Service (IaaS)» Hosted Virtual Machines (VMs) providing computing, storage and a customized

software stack (Amazon EC2/S3)

Ruppa K. Thulasiram Slide 4/24

Cloud Federationl Desired feature of Cloud

• Illusion of infinite computing resources

l Resources available in a single data center are limited• A large demand may put pressure in the data center capacity• One possible source for additional resources is idling resources

from other providers

l Cloud Federation is a collection of individual Cloud providers, which collaborate by trading resources (e.g. computing, storage)

Ruppa K. Thulasiram Slide 5/24

Cloud Federation Motivationsl Obtain extra resources from other members (Outsourcing)

• Avoid losing customers

• Avoid paying penalties

• Avoid losing reputation by violating SLAs

l Lease idle resources (Contributing to Federation) • Avoid wasting their non-storable compute resources

l Supplying resources in specific geographic locations• Low-latency access regardless of location

• meet regulations in place for the customers

l Disaster recovery

Ruppa K. Thulasiram Slide 6/24

Resource Provisioning Policies in Cloud

l Current resource management strategies hinder providers market potential by limiting the amount of resources allocated to requests• QoS is met in a conservative way• Over-provisioning of datacenter capacity

» average demand of the system is several times smaller than the peak demand

l By exploiting cloud federation potentials, providers are able to dynamically increase the available resources to serve requests

l Outsourcing requests or renting part of idling resources to other providers is not a trivial issue

Ruppa K. Thulasiram Slide 7/24

Federation-Aware Resource Provisioning

l How providers can exploit federation to dynamically increase their data center capacity?

l When providers should sell and buy resources and what are the proper contracts and pricing schemes?

l What are the appropriate market making mechanisms in a federated Cloud environment?

l What types of high-level infrastructure and mechanisms are required to outsource extra demands and contribute under-utilized capacity to federation members?

Ruppa K. Thulasiram Slide 8/24

Research Objectivesl Study the impact of federation as a mechanism for

maximizing cloud provider’s profit, utilization and reputation

l Leverage federation potentials by creating resource provisioning mechanisms for Cloud providers

l Investigate the effect of applying different resource trading paradigms to facilitate federation of providers

Ruppa K. Thulasiram Slide 9/24

System ModelInteraction between customers and providers

l On-demand Virtual Machines Requests• Without long-term commitment

• Request will be accepted if provider has enough resources

• Customers can retain machines as long as they need them

l Spot Virtual Machines Requests• Lower cost of using VMs by accepting the risk of being terminated in favor of customers willing to pay more

for the same resources

• Maximum price they are willing to pay per VM hour is called bid

• VMs will run until either customer decides to terminate them or the price goes above the bid

• One time» are not restarted after termination by providers

• Persistent» Providers automatically instantiate new VMs for the persistent request each time the current spot price

goes below the bidding price

l On-demand and spot resources differ on availabilityl QoS characteristics of VMs (such as memory and CPU power) are the same for

both models

Ruppa K. Thulasiram Slide 10/24

System ModelInteraction between providers and Cloud Federation

l Cloud Exchange• Information service directory• Available resources from the members of federation• With corresponding service prices

l Cloud Coordinator• Decision on allocating additional resources from another Cloud Provider• Publishing Idling capacity shares with Cloud Exchange• Resources pricing for contributing capacity

l Federation Level Agreement (FLA)• Instant federation price of a resource per hour

» Mp : Total capacity

» Midle: idling capacity of the provider data center

» Fmax : the on-demand VM price to customers

» Fmin : the minimum profitable price for the provider

Ruppa K. Thulasiram Slide 11/24

System Model

Cloud Coordinator

Cloud Coordinator

Cloud Coordinator

Provider A

Provider C

Cloud Exchange Service

User Interface

User Interface

User Interface

Provider B

ResourceTrading

Ruppa K. Thulasiram Slide 12/24

System Model (Cont.)l VM Placement is transparent for customers.l Coallocation of requests is not considered in our

model.l Outsourcing is only considerd for On-demand

requests.

Ruppa K. Thulasiram Slide 13/24

Problem StatementPrioritizing and outsourcing VM requests

l Fully-utilized provider may receive an on-demand request (there is no idle resources)• To be able to offer QoS guarantees without limiting number of

accepted requests:» Increasing spot price and terminate some spot VMs to accept more

profitable on-demand requests; or

» Outsourcing the request to other federation members

l We proposed policies that helps in the decision-making process to increase resources utilization and profit.

Ruppa K. Thulasiram Slide 14/24

Outsourcing decision scenario

Cloud Coordinator

User Interface

S

S

S

2 On-demand 3 Spot

1 On-demand

Outsource or terminate

Spot?

Resource provisioning policies for federated-aware providers in the presence of terminable local VMs

Ruppa K. Thulasiram Slide 15/24

Policiesl No Federated Totally In-house (NFTI)

• Termination of spot VMs with lowest bid • If action does not release enough resources for the new on demand

request the request will be rejected

l Federation-Aware Outsourcing Oriented (FAOO)• Fully utilized provider firstly checks the Cloud exchange service for

available resources by other members• It outsources the request to the provider that offers the cheapest price

l Federation-Aware Profit Oriented (FAPO)• Based on analytical analysis of instant profit, it decides between

outsourcing and termination of spot VMs

Ruppa K. Thulasiram Slide 16/24

Performance Evaluation - Setupl Simulation study with CloudSim

• CloudSim: A discrete simulator for modelling and simulation of Cloud Computing

l The VM configuration is inspired by Amazon EC2 instances• One VM type (Small Instances:1 CPU core, 1.7 GB RAM, 1 EC2 Compute Unit, and 160 GB of local

storage)

l Each datacenter 128 servers, and each one supports 8 VMs. l Due to lack of publicly available workload models and real traces of IaaS

Clouds, l Lublin workload model (one week long simulation)

• Each experiment is carried out 20 times

• Average of the results is reported.

l Bidding Algorithm:• A uniformly-distributed random value between the minimum of bid $0.020 and maximum of $0.085(on-

demand price)

• The minimum price is set in such a way that the value offered by customers is still enough to cover operational costs of serving the request

Ruppa K. Thulasiram Slide 17/24

Evaluation Parametersl System load

• The arrival rate of requests has been selected to adjust the load of a provider

• aarr parameter of the Lublin Workload model between 8.2 and 6.4

l α • Contains the rate of spot requests that are persistent

• 10% ≤ α ≤ 90%

l β • Ratio of spot requests to total requests (on-demand plus spot requests)

• 0% ≤ β ≤ 100%

l Number of Providers• 3,5,7

Ruppa K. Thulasiram Slide 18/24

Performance Metricsl Profit

Achieved revenue during a time period minus the cost incurred in the same time period excluding operational costs.

l Utilization

The total number of hours of VMs used by requests (both local and contributed to the federation) and the maximum possible of number of hours of VMs in a time period in the datacenter.

l Number of rejected on-demand VMsNumber of on-demand VMs rejected

Ruppa K. Thulasiram Slide 19/24

Resultsl Results for profit and utilization are the normalized

values for each metric using the result obtained for the NFTI policy as the base value.

l The NFTI policy reflects the situation where providers do not explore capacities of the federation, the use of normalized values allows us to quantify the benefits of federation-aware policies on each provider

Ruppa K. Thulasiram Slide 20/24

Results

Impact of load on (a) Profit (b) Utilization (c) Number of rejected on-demand VMs, for a provider with different policies.

Impact of number of providers on (a) Profit (b) Utilization (c) Number of rejected on-demand VMs for a provider with different policies.

Ruppa K. Thulasiram Slide 21/24

Results(cont.)

Impact of percentage of spot requests on (a) Profit (b) Utilization (c) Number of rejected on-demand VMs, for a provider with different policies.

Impact of percentage of persistent spot requests on (a) Profit (b) Utilization (c) Number of rejected on-demand VMs for a provider with different policies.

Ruppa K. Thulasiram Slide 22/24

Conclusionl We proposed policies to enhance IaaS providers’ profit when the

provider is member of a Cloud federation• Having the possibility of canceling their terminable less profitable VMs (e.g.

spot VMs) in favor of more profitable requests (e.g. on-demand VMs).

l Experimental results also allow us to derive some guidelines for providers:

• Running on-demand requests locally is more profitable » If the provider has high ratio of spot VMs

» And termination of spot VMs may lead to less discontinuation of service by customers.

• Moreover, outsourcing is more profitable » Spot VMs are scarce

» and termination of them may result in discontinuation of using the services by customers.

• Furthermore, federation also helps underutilized providers in making profit by selling idling resources to other members.

Ruppa K. Thulasiram Slide 23/24

Future Workl The impact of strategies that include shutting down

unused hosts of the data centers to save electric power consumption as an option

l Strategies that consider prediction of future resource availability to drive decisions

l Proposing policies for dynamic pricing of resources to offer idling capacity of the data center

Ruppa K. Thulasiram Slide 24/24

THANK YOU

Questions?

Ruppa K. Thulasiram Slide 25/24

Federation-Aware Profit Oriented (FAPO)

P(t), the instant profit of the provider in time t:

R(t): revenue at time tC(t): cost at time t

R(t) can be obtained as follow:

Ro(t): revenue of On-demand VMs at time tRs(t): revenue of Spot VMs at time tRfed(t): revenue of contributed VMs to federation

those local resources used by other members of the federationRout(t): revenue of outsourced VM requests

Ruppa K. Thulasiram Slide 26/24

Revenue

Fo: the on-demand resource price per resource per hourFs(t): the price of the spot VMs at time tvmo(t): the number of on-demand VMs running locallyvmout(t): the number of outsourced VMsvms(t): the number of running spot VMs

Ruppa K. Thulasiram Slide 27/24

Cost

CP(t) is the operational cost:

Cost of acquiring and operating the data center nodes hardware and software acquisition, staff salary, power consumption, cooling costs, physical space,amortization of facilities, etc.

Cout(t) is the cost of outsourced VMs that a provider pays to federation members hosting its requests.

Fout-i is the price per resource per which is paid for each outsourced vmi.

Ruppa K. Thulasiram Slide 28/24

Federation-Aware Profit Oriented (FAPO)

FAPO policy has two choices for incoming n On-demand VMs arrives at time t, and local infrastructure can only accommodate m VMs (m < n).

Putting all the above equations together

1. Terminate the n-m spot VMs 2.Outsource the new request