1 / 27

Energy-efficient Dynamic Capacity Provisioning in Server Farms

Energy-efficient Dynamic Capacity Provisioning in Server Farms. VARUN GUPTA Carnegie Mellon University. Partly based on joint work with : Anshu l Gandhi Mor Harchol-Balter Mike Kozuch (CMU) (CMU) (Intel Research ).

teige
Download Presentation

Energy-efficient Dynamic Capacity Provisioning in Server Farms

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. Energy-efficient Dynamic Capacity Provisioning in Server Farms VARUN GUPTA Carnegie Mellon University Partly based on joint work with: Anshul Gandhi MorHarchol-Balter Mike Kozuch (CMU) (CMU) (Intel Research)

  2. The “provisioning for peak” problem Data Center Capacity ? Demand (t) Time (t) PROBLEM: Want to turn servers OFF/ON to match (t)… … and also minimize setup penalties!

  3. First Attempt: ON/OFF policy (t) # Busy servers # Jobs Mean Job Size = 1s Setup delay = 200s Busy power = 240W

  4. First Attempt: ON/OFF policy (t) # Busy servers # Jobs Mean Job Size = 1s Setup delay = 200s Busy power = 240W

  5. First Attempt: ON/OFF policy (t) # Busy servers # Jobs Mean Job Size = 1s Setup delay = 200s Busy power = 240W

  6. First Attempt: ON/OFF policy (t) # Busy servers # Jobs Mean Job Size = 1s Setup delay = 200s Busy power = 240W WITH SETUP: E[Power] = 51.9 kW E[Response time] = 13s NO SETUP: E[Power] = 14.4 kW E[Response time] = 1s

  7. First Attempt: ON/OFF policy (t) # Busy servers # Jobs Mean Job Size = 1s Setup delay = 200s Busy power = 240W Can we do better than ON/OFF? . Add inertia while turning servers OFF

  8. Our Prescription: DELAYEDOFF Turn OFF a server after idle for twait twait independent of (t)! new arrival routed to the most recently busy (MRB) server arriving job turns a server ON if all servers busy

  9. twait timers

  10. twait timers

  11. twait timers

  12. Our Prescription: DELAYEDOFF THEOREM: For Poisson arrivals, as the load , the number of ON servers is concentrated around --- Proof Intuition --- Step 1: An equivalent system view k jobs run on the “first” k servers Step 2: Analysis of idle periods of M/G/∞ Time from a k(k-1) to the next (k-1)k transition

  13. Intuition for idle periods 1. # jobs  Normal with mean and variance  2. 3. Events happen at rate  4. Mean idle period of server 3 2 MRB  servers for any constant twait! In practice, we choose twait to amortize setup cost 1

  14. ON/OFF (t) # Busy+idle servers # Jobs DELAYEDOFF Mean Job Size = 1s Setup delay = 200s Busy power = 240W

  15. ON/OFF (t) # Busy+idle servers # Jobs DELAYEDOFF Mean Job Size = 1s Setup delay = 200s Busy power = 240W

  16. ON/OFF (t) # Busy+idle servers # Jobs DELAYEDOFF Mean Job Size = 1s Setup delay = 200s Busy power = 240W DELAYEDOFF: E[Power] = 18.9 kW E[Response time] = 1.002s NO SETUP: E[Power] = 14.4 kW E[Response time] = 1s .

  17. DELAYEDOFF (t) # Busy+idle servers # Jobs SQ. ROOT W/ LOOKAHEAD (“optimal offline”) Mean Job Size = 1s Setup delay = 200s Busy power = 240W

  18. DELAYEDOFF (t) # Busy+idle servers # Jobs SQ. ROOT W/ LOOKAHEAD (“optimal offline”) Mean Job Size = 1s Setup delay = 200s Busy power = 240W

  19. DELAYEDOFF (t) # Busy+idle servers # Jobs SQ. ROOT W/ LOOKAHEAD (“optimal offline”) Mean Job Size = 1s Setup delay = 200s Busy power = 240W DELAYEDOFF: E[Power] = 18.9 kW E[Response time] = 1.002s  w/LOOKAHEAD: E[Power] = 15.8 kW E[Response time] = 1.036s

  20. DELAYEDOFF mods Speed scaling algorithms A simple proxy for MRB routing Heterogeneous servers Managing Virtual Machines in the Cloud Wear-leveling/Performance tradeoffs

  21. Effect of DELAYEDOFF on speed-scaling Power P(s) Speed (s) Q: Optimal speed to balance energy-performance? A: your favorite metric =

  22. A simple proxy for MRB routing • MRB requires a lot of state updates • Proxy policy • Assign static ranks to servers • Route a new arrival to highest ranked idle server • Almost the same performance as MRB • + easier to implement than MRB • + easy to extend 5 4 3 (MRB) Rank-based 2 1 Rank

  23. DELAYEDOFF for heterogeneous servers less efficient 5 Assign ranks to servers based on efficiency (1 = most efficient) Route a new arrival to highest ranked idle server 4 3 2 1 more efficient

  24. Managing Virtual Machines in the Cloud 2GB RAM 1GB 1GB 2GB RAM 1GB 2GB RAM

  25. Managing Virtual Machines in the Cloud 6 Split physical servers into “virtual” servers Assign static ranks to virtual servers Route a new VM request to highest ranked idle virtual server Turn the physical server OFF after each virtual server has idled for twait 5 4 3 2 1

  26. Conclusions Max Capacity Demand ? Time Problem: unpredictable demand and non-trivial setup costs DELAYEDOFF : A new traffic-oblivious capacity scaling scheme Extensions to real-world scenarios

  27. The Importance of Being MRB THEOREM [MRB]: As the load , the number of ON servers is concentrated around THEOREM [Round-Robin]: As the load , for constant job sizes, the number of ON servers is Arrival rate = λ N servers

More Related