1 / 53

Power Aware Virtual Machine Placement

Power Aware Virtual Machine Placement. Yefu Wang. Introduction. Data centers are underutilized Prepared for extreme workloads Commonly under 20% utilized Shutting down unused servers Saves more power than DVFS Application correctness should be guaranteed Design choices

yeardley
Download Presentation

Power Aware Virtual Machine Placement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Power Aware Virtual Machine Placement Yefu Wang

  2. Introduction • Data centers are underutilized • Prepared for extreme workloads • Commonly under 20% utilized • Shutting down unused servers • Saves more power than DVFS • Application correctness should be guaranteed • Design choices • Workload redirection • VM live migration • Workload redirection + VM live migration [Meisner’09]

  3. Design Choice (1) : Workload Redirection Web requests Example: [Heo’07]

  4. Design Choice (2): VM Live Migration VM VM VM VM VM VM VM VM VM VM VM Example: [Wang’09, Verma’08]

  5. Design Choice (3): Hybrid • 6 servers and 12 VMs • 2 applications: Gold and Silver • HTTP requests are dispatched by a dispatcher [Kusic’08]

  6. pMapper: Power and Migration Cost Aware Application Placement in Virtualized Systems Akshat Verma, Puneet Ahuja, Anindya Neogi IBM India Research Lab, IIT Delhi

  7. Application Placement • Static vs. dynamic placement • Utilization of each server shows dynamic pattens • Dynamic placement saves more energy • A later paper from the save authors advocates static placement • System administrators have more control CPU utilization(0%-100%) are mapped to grayscale (0-1) in this figure.

  8. Application Placement Architecture DVFS VM resizing + idling

  9. Optimization Formulations • Cost performance tradeoff • Cost Minimization with Performance Constraint • Performance benefit maximization with power constraint Performance benefit Power Migration Cost

  10. System Modeling • Migration Cost • Independent of the background workload • Can be estimated a priori • Performance modeling • This paper does not design a performance controller • pMapper can be integrated with other performance controllers or models • Power model • It is infeasible to have an accurate power model in practice • Server power consumnption depends on the hosted applications • The potential server-VM mappings can be huge • This paper only relies on the power efficiency of servers

  11. Optimization Formulations • Cost performance tradeoff • Cost Minimization with Performance Constraint • Performance benefit maximization with power constraint Performance benefit Power Migration Cost

  12. mPP Algorithm VM VM VM VM VM VM VM VM VM VM VM VM VM Server 1 Server 2 Server 3 Server 4 Server 5

  13. mPP Algorithm Server 1 Server 2 Server 3 Server 4 Server 5 VM VM VM VM VM VM VM VM VM VM VM VM VM

  14. mPP Algorithm Sort VMs by size Server 1 Server 2 Server 3 Server 4 Server 5 VM VM VM VM VM VM VM VM VM VM VM VM VM

  15. mPP Algorithm Sort servers by slope (power efficiency) Server 1 Server 2 Server 3 Server 4 Server 5 VM VM VM VM VM VM VM VM VM VM VM VM VM

  16. mPP Algorithm Allocate the VM to servers using First Fit VM Server 1 Server 2 Server 3 Server 4 Server 5 VM VM VM VM VM VM VM VM VM VM VM VM

  17. mPP Algorithm VM VM VM VM VM VM VM VM VM VM VM VM VM Server 1 Server 2 Server 3 Server 4 Server 5 • mPP algorithm is oblivious of the last configuration • May entail large-scale migrations.

  18. mPPH Algorithm : mPP with History VM VM VM VM VM VM VM VM VM VM VM VM VM mPP VM VM VM VM VM VM VM VM VM VM VM VM VM

  19. mPPH Algorithm : mPP with History VM VM VM VM VM VM VM VM VM VM VM VM VM Target Util. Target Util. Target Util. Receiver Receiver Donor Donor Donor

  20. mPPH Algorithm : mPP with History VM VM VM VM VM VM VM VM VM VM Target VM VM Donor Donor Donor

  21. mPPH Algorithm : mPP with History Pick the smallest VMs that add to a migration list VM VM VM VM VM VM VM VM VM Migration list VM Target VM VM Donor Donor Donor

  22. mPPH Algorithm : mPP with History VM VM VM VM VM VM Receiver Receiver Donor Donor Donor VM VM VM Migration list VM VM VM VM

  23. mPPH Algorithm : mPP with History VM VM VM VM VM VM Receiver Receiver Donor Donor Donor Target VM Target Migration list VM VM VM VM VM VM

  24. mPPH Algorithm : mPP with History VM VM VM VM VM VM VM Receiver Receiver Donor Donor Donor Target Target Migration list VM VM VM VM VM VM

  25. mPPH Algorithm : mPP with History VM VM VM VM VM VM VM VM VM VM VM VM VM Receiver Receiver Donor Donor Donor Target Target • mPPH algorithm tries to minimize migrations by migrating as few VMs as possible • pMaP algorithm: before each migration, consider the benefit and migration cost

  26. System Implementation • Testbed • Virtulization platform: VMware ESX 3.0 • Power monitor: IBM Active Energy Manager • Performance manager: EWLM • DVFS is not implemented • Simulator • Replace performance manager with trace data • Simulating 4 blades, 42 VMs • Baselines • Load balanced • Static

  27. Power Consumption mPP, mPPH saves 25% of power

  28. Algorithm Cost mPP fails at high utilization pMaP has the least overall cost most of the time

  29. Conclusion • Application placement controller pMapper • Minimize power and migration cost • Meet performance guarantees • Also avaiable in the paper: • More simulation results • Proof of the propoties of the algorithm for a given platform

  30. Performance-Controlled Power Optimization for Virtualized Clusters with Multi-tier Applications Yefu Wang and Xiaorui Wang University of Tennessee, Knoxville

  31. Introduction • Power saving techniques • DVFS have a small overhead • Server consolidation saves more power • Performnce guarantee • Multi-tier applications may span multiple VMs • A controller must respond to a workload variation quickly • Integrating performance control and server consolidation is important

  32. System Architecture CPU Resource Demands Application-level Response Time Controller Application-level Response Time Controller Application-level Response Time Controller VM VM VM VM Application-level Response Time Monitor Application-level Response Time Monitor Application-level Response Time Monitor VM VM VM VM VM VM VM VM VM migration and server sleep/active commands Power Optimizer

  33. Response Time Controller Application HTTP requests VM1 VM2 VM2 Response Time Monitor CPU requirements MPC Controller Response Time Model

  34. CPU Resource Arbitrator • CPU resource arbitrator • Runs at server level • Collect the CPU requirements of all VMs • Decides CPU allocations of all VMs and DVFS level of the server • The CPU resource a VM receives depends on: • CPU allocation • Example: give 20% CPU to VM1 • DVFS level • Example: Set the CPU frequency to

  35. CPU Resource Arbitrator • Two observations • Performance depends on • Keeping a constant, a lower leads to less power consumption • CPU resource arbitrator • Use the lowest possible CPU frequency to meet the CPU requirements of the hosted VMS

  36. VM Consolidation for Power Optimization • Problem formulation • Minimize the total power consumption of all servers • Meet all CPU resource requirements • Power Model

  37. Optimization Algorithm • Minimum slack problem for a single server • Power aware consolidation for a list of servers • Incremental Power Aware Consolidation (IPAC) algorithm • Cost-aware VM migration

  38. Minimum slack problem for a single server Slack=1 Minimum Slack=1 Server VM VM VM VM VM VM VM VM VM VM VM VM VM

  39. Minimum slack problem for a single server Slack=0.8 Minimum Slack=0.8 VM Server VM VM VM VM VM VM VM VM VM VM VM VM

  40. Minimum slack problem for a single server Slack=0.2 Minimum Slack=0.2 VM VM VM Server VM VM VM VM VM VM VM VM VM VM

  41. Minimum slack problem for a single server Slack=0.2 VM VM VM VM Server VM VM VM VM VM VM VM VM VM

  42. Minimum slack problem for a single server Slack=0.5 Minimum Slack=0.2 VM VM Server VM VM VM VM VM VM VM VM VM VM VM

  43. Minimum slack problem for a single server Slack=0.2 Minimum Slack=0.2 VM VM VM Server VM VM VM VM VM VM VM VM VM VM

  44. Minimum slack problem for a single server Slack=0 Minimum Slack=0.2 VM • Algorithm stops if minimum slack < • Sounds like exhaustive search? • Complexity: the maximum number of VMs a server can host • Fast in practice [Fleszar’02] • Gives better solution than FFD VM VM VM Server VM VM VM VM VM VM VM VM VM

  45. Consolidation Algorithm • Power aware consolidation for a list of servers • Begin from the most power efficient server • Use minimum slack algorithm to fill the server with VMs • Repeate with the next server untill all the VMs are hosted • Incremental Power Aware Consolidation (IPAC) algorithm • Everytime only consider these VMs for consolidation: • Selected VMs on overloaded servers • The VMs on the least power efficient server • Repeate until the number of servers does not decrease • Cost-aware VM migration • Consider the benefit and migration cost before each migration • Benefit: power reduction estimated by the power model, etc. • Cost: administrator-defined based on their policies

  46. System Implementation • Testbed • 4 servers, 16 VMs • 8 applications (RUBBoS) • Xen 3.2 with DVFS • Simulator • Use CPU utilization trace file for 5415 servers to simulate 5415 VMs • 400 physical servers with random power models • 3 different type of CPUs

  47. Response Time Control Violation of performance requirements Lower power consumption resulted from DVFS Our solution Baseline: pMapper

  48. Server Consolidation • 69.6% power is saved • Response time is still guaranteed after the consolidation

  49. Simulation Results • IPAC saves more power than pMapper • Algorithm gives better consolidation solutions • Even more power is saved by DVFS • IPAC runs even faster than pMapper • Only a small number of VMs are considered in each period

  50. Conclusion • Performance-controlled power optimization solution for virtualized server clusters • Application-level performance guaranteed • Power savings are provided by DVFS and server consolidation • Compared with pMapper • Provides performance guarantee • Consumes less power • Less computational overhead

More Related