Market-Based Resource Allocation for Utility Data Centers Byde et al. HP Labs Taewon Hwang

1. Market-Based Resource Allocation for Utility Data Centers Byde et al. HP Labs Taewon Hwang

2. Introduction ￭ Today, organizations must adapt to their environments fast. ￭ IT became a key determinant of a company's overall effectiveness. ￭ To ensure that sufficient resources are available to support growth, IT planners have traditionally overbuilt and underutilized the datacenter resources or infrastructure. ￭ As a result, IT infrastructure has evolved into a complex collection of legacy systems that are hard to understand and manage in a uniform fashion.

3. Introduction ￭ Traditionally, IT infrastructure is static, requiring significant manual intervention for each change. ￭ However, today's enterprise is far more dependent on the availability of IT service to conduct business and demands a flexible datacenter architecture. ￭ To address this issue, HP introduce “Utility Data Center (UDC)”, which allowed large scale, heterogeneous IT infrastructure (servers, storages, networks, security devices, etc.) to be aggregated into a dynamically delivered resource pool for applications.

4. Introduction • ￭ In this context (dynamic resource allocation), under-utilized resources can be redeployed wherever they are most needed and a service that is experiencing low load can relinquish resources (e.g. bandwidth or CPU cycles) to another service that is experiencing high load. • ￭ Market-based resource allocation system has three high-level components. • - Resource Market • - Application Agent • Business Agent

6. Market Mechanism ￭ In market-based approach, different agents have different knowledge, goals and preferences, but nonetheless must express their desires in a common currency. ￭ How to resolve the issue of who gets the resource? - bidding ￭ Markets are at their most useful when the participants are unwilling to reveal their information directly. However, because the agents are owned and operated by the UDC owner, they are essentially cooperative.

7. Market Mechanism • ￭ Mechanism choices (general assumptions) • Servers or other computing devices are the essential resources. • 2. Resources are rented from the UDC in time periods. • 3. The market is centralized. • 4. It is not necessary to collect payments for resources.

8. Application Agent ￭ “Glue” between the business level and the IT level. ￭ It should understand both resource descriptions and service metric specifications. Business Agent ￭ It should analyze both SLA and strategic value.

9. Simulations • ￭ Market Mechanism (Simple Market) • Find the bids of all agents for all servers; A server is tradable if the highest bid for it is not that of the server currently in possession of it. • 2. If there is at least one tradable server, find the server whose trade value is greatest, and effect the trade. • 3. If a server was traded then start again from step 1. • - This mechanism was used in most of the experiments.

10. Simulations • ￭ Market Mechanism(Globally Optimal Assignment Market) • Get the bids bida(n) of each agent a for each number of servers it may receive, n, from 0 up to the total number of servers available. • 2. Construct the set of all assignments (n1,…,nA) of numbers of servers to agents; choose the assignment (n*1,…,n*A) for which total value is maximized: • 3. Assign n*a servers to agent a, for each a. Value(n1,…,nA)=

11. Service Specification

12. Service Specification ￭ Cn is the sum of the capacities of all servers allocated to processing node n. Here, the time taken for the node to do a unit of work: (time per unit work) = mn + (vn/Cn) ￭ mn is an un-parallelizable component of the processing time that does not depend on the set of resources allocated to the node, whereas vn represents the part that is parallelizable, and hence which will be affected by adding resources to the node.

13. Service Level Agreements (SLAs) ￭ The UDC operator is rewarded for completing jobs on time, and pays penalties for delivering jobs late or not at all.

14. Business Agent Algorithm ￭ The amount bid for the resources that the agent actually received is averaged over the lifetime of a service. ￭ In order to accomplish such application, the authors spread the predicted utility of all jobs in the queue out over the period of time that is predicted for the last job to exit the queue – the longest service time.

15. Application Agent Algorithm ￭ The agent maintains an estimate of the average amount of work per job for each processing node, (av work)n, and an estimate (av length)n of the queue length at each node. Λ = max(Λ min, (1/n+1)) (av length)n := Λ*(Q length)n + (1- Λ)*(av length)n ￭ This update rule smoothes out the observations of actual queue length over multiple time steps, but ensures that (av length) is kept up-to-date by placing a lower limit of λmin on the weight given to new observations is not less than λmin.

16. Application Agent Algorithm ￭ To estimate the time at which job j, currently either being processed or waiting to be processed at node n, will be delivered: (Q position)j * (av work)n + workn,j (time per unit work) n (av length)m * (av work)m + workm,j (time per unit work)m ￭Where (Q position)j is the number of jobs ahead of j in the queue for processing node n, and workm,j is the amount of work node m has to do on job j. +

17. Application Agent Algorithm ￭ To allow the agent to manage risk sensibly, the expected utility of processing each job is evaluated not just with respect to this delivery time, but with respect to a cluster of times around this value, with corresponding approximate likelihoods. expected_utility(job,t) = wj * utility(job, sj * t) ￭ Scale factors sj (j = 1,..,S) and associated weights, wj. In simulations, arbitrary values are assigned to these parameters.

18. Results ￭ Basic setup - It consists of two statistically identical services (no gold or sliver customers). - The resource pool for these services typically consisted of 20 identical servers. - A typical “run” lasted 1000 time steps, and results regarding average performance were taken over 100 such runs. - Each job was due to be delivered 10 time steps after arriving in the first queue, would pay 1 unit of money on successful delivery, and would incur a fine of 1 if late.

19. Results ￭ Basic setup 0.88 The optimal static assignment is to give half the servers to each service, in which case almost all (94.0%) jobs are completed on time

20. Results ￭ Basic setup - The average earnings per job for the market controlled scenario is 0.94 (completing 97% of jobs on time). - The average earnings per job for the symmetric static allocation is 0.88 (completing 94% of jobs on time). - The ability to re-provision resources dynamically in response to business impact does not lead to dramatic changes in the combined effectiveness of the two services.

21. Results ￭ Market Volatility The volatility of the allocations The volatility of the job stream Work Arrival rate 200 20 1200 3.3 3200 1.25 Demand fluctuates less, and hence so does the allocation

22. Results ￭ Emergent Time Sharing - The clear advantage of the dynamic allocation mechanism is due to the fact that there is no symmetric static allocation in this scenario.

23. Results ￭ Emergent Time Sharing The market mechanism “discovers” the time-sharing solution.

24. Results • ￭ Admission Control • Work (5000), arrival rate (1) -> highly fluctuating demand • - Using the market-based resource allocator allows more services to be hosted, by increasing utilization of the underlying • infrastructure.

25. Results ￭ Heterogeneous Value 2 4 6 8 10

26. Results ￭ Heterogeneous Value Workload 4000 - The market automatically makes the necessary trade-offs to provision more resources to application 2 than application 1. 5000 6000 7000

27. Results ￭ Mechanism Comparison Basic market static global - For a fixed mechanism, using the true job delivery times actually leads to worse performance. simulation & global In “simulation”, the agent has access to actual delivery time simulation

28. Conclusions ￭ The market mechanism never performed worse than a static allocation, and often performed significantly better. ￭ When demand fluctuates highly, it was able to balance application requirements so as to give earnings that exceeded those from hosting fewer services. ￭ However, In environment, market mechanism choices have far less impact on allocation value than bidding algorithm design (need to be addressed in the future work).