1. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Blink: Managing Server Clusters on Intermittent Power Navin Sharma, Sean Barker, David Irwin, and Prashant Shenoy

2. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Energy’s Impact Datacenters are growing in size 100k servers + millions of cores possible Energy demands also growing Cost of energy is increasing Estimates of >30% of TCO and rising ≈ ½ the emissions of the airline industry

3. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Reducing Energy’s Impact Must regulate energy footprint Financial: optimize energy budget Regulate usage for variable prices Environmental: use green energy Leverage more renewables Solar Wind

4. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Challenge How do we design server clusters that run on intermittent power?  Power fluctuate independent of workload  Maximize performance subject to available energy

5. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Outline Motivation Overview: Blink Abstraction Application Example: Blinking Memcached Implemenation: Blink Prototype Evaluation: Power/workload Traces Related Work Conclusion

6. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Running Clusters on Intermittent Power Short term fluctuations (~minutes) Smooth power using UPSes Long term fluctuations Increase/decrease power consumption One approach: activate/deactivate servers But servers maintain memory/disk state… …that will be unavailable if not transferred/replicated

7. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Server Blinking Blinking == a duty cycle for servers Continuous active-to-inactive transitions Extends PowerNap (ASPLOS ‘09) Goal: cap energy use over short intervals Feasible Today: ACPI S3 (Suspend-to-RAM) Fast transitions (~seconds) Large power reductions (>90% peak) 100% power (0% duty cycle) 50% power (50% duty cycle) Blink Interval

8. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Blinking Abstraction Blinking policies: coordinate blinking across servers Activation: vary active servers Synchronous: blink servers in tandem Asymmetric: blink servers at different rates Node 1 (100%) Node 2 (100%)Node 3 (0%) Node 4 (0%) Node 1 (50%)Node 2 (50%)Node 3 (50%) Node 4 (50%) Node 1 (100%) Node 2 (50%)Node 3 (35%) Node 4 (15%)

9. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Proof-of-Concept Example: Memcached Distributed in-memory cache Popular optimization for web applications E.g., Facebook, LiveJournal, Flikr Smart Clients/Dumb Servers Simple client hash function maps keys  servers get(key) get_from_db(key) Web App DB Memcached Node #1 Memcached Node #2 Memcached Node #N...... Memcached Client Example: hash(key) = 2

10. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Activation for Memcached Initial approach: no memcached modifications Keys randomly distributed across servers Problem: which node to deactivate? Arbitrarily favor keys on active servers MCD Client Memcached Node #1 Memcached Node #2 get key1 obj1 get key2 miss key1 key2 node 1 node 2

11. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Reducing Activation’s Performance Penalty Popularity-based key migration Group similarly popular objects on same server Deactivate “least popular” servers Invalidates least popular objects Benefit: higher hit rates Problem: unfair if many keys have same popularity No server is “least popular” Still arbitrarily favors keys on active servers

12. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Synchronous for Memcached Benefits for Uniform Popularity Fairness: all keys equally available Performance: same hit rate as activation Problem: poor hit rate if keys not equally popular hit misshit miss hit miss hit miss Node #1Node #2 Synchronous Hit Rate = 50% (50% requests) hitmiss Node #1Node #2 Activation Hit Rate = 50% (50% requests) hit misshit miss hit miss hit miss Node #1Node #2 Synchronous Hit Rate = 50% (80% requests) (20% requests) hitmiss Node #1Node #2 Activation Hit Rate = 80% (80% requests)(20% requests)

13. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Best of Both Worlds: Load-proportional Blink servers in proportion to load Balance performance and fairness Works well for Zipf popularity distributions Few popular keys, many (equally) unpopular keys Fair for (mostly) synchronously blinking less popular servers High hit rate for (mostly) active popular servers

14. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Blink Prototype Low Power Node Power Manager Battery + - + - Programmable Power Supply + - Power trace via serial port Experimental Deployment Field Deployment solarwind

15. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 BlinkCache Implementation Place proxy between clients and servers Proxy maintains key  server table Tracks key popularity and migrates keys Modest implementation complexity No client/server memcached modifications Added ~300LOC to existing proxy PHP Server MCD Client Application Server PHP Server MCD Client Application Server MCD Proxy Power Manager UPS MCD Server Backend Server Power Client MCD Server Backend Server Power Client

16. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Experimental Setup Test Deployment Cluster of 10 low-power nodes AMD Geode LX (433MHz) CPU, 256 MB RAM Power consumption well-matched to production ~100 watts peak production/consumption Workloads and Metrics Solar + wind traces from deployment Zipf popularity distributions ( α = 0.6) Hit Rate (Performance), Standard Deviation (Fairness)

17. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 S3 Transition Overhead Blink Prototype

18. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Balancing Performance and Fairness Activation with key migration (green) Best hit rate Load-proportional (red) Slightly lower hit rate, but more fair

19. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Case Study: Tag Clouds in GlassFish GlassFish: Java application server that creates tag clouds Cache dynamically-generated HTML pages in memcached Each HTML page: 20 requests to a MySQL database

20. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Related Work Sensor and Mobile Research Use duty-cycling to reduce energy footprint Lexicographic (SenSys 09), AdaptiveCycle (SECON 07) Blink: power delivery infrastructure shared Energy-efficient Computing Minimize energy to satisfy a workload FAWN (SOSP 09), PowerNap (ASPLOS 09) Blink: optimize workload to satisfy energy budget Dealing with Variability Similar to churn in DHTs Chord (SIGCOMM 01), Bamboo (USENIX 04) Blink: introduce regulated/controllable churn

21. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Conclusions Blink: new abstraction for regulating energy footprint Blinking is feasible in modern servers Highlight differences in blinking policies Modify example application (Memcached) for blinking Modest implementation overhead Ongoing work Explore more applications Distributed storage is more important/challenging Explore more power profiles Variable pricing, battery capacities

22. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Questions?

23. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Activation for Memcached MCD Client Server #1 Server #2 get key1 obj1 get key2 obj2 key1 key2 node 1 node 2 key1 key2 node 1 Next approach: alter client hash function Add/remove servers from hash Problem: penalizes power fluctuations Invalidates keys on every change Consistent hashing: 1/n th keys for single addition/removal

24. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Uniform Popularity Synchronous Same hit rate as activation More fair than activation

25. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2011 Proxy Overhead Memcached Proxy Imposes modest overhead