Lecture 9: More Cloud Applications

1. Lecture 9: More Cloud Applications Xiaowei Yang (Duke University)

2. News: Buffalo as Data Center Mecca • $1.9 billion, at least 200 employees • Low-cost electric power, tax incentives, plenty of shovel-ready sites, cool climate

3. Review • Cloud Computing • Elasticity • Pay-as-you-go • Challenges • Security: co-residence, inference • Performance • Coarse-grained sharing • Lack of virtualized interface for specialized hardware

4. Today • Cloud Applications • Execution augmentation for mobile devices • Energy saving for mobile • Energy saving for desktops • Disaster recovery

5. The Case for Energy-Oriented Partial Desktop Migration NiltonBila†, Eyal de Lara†, MattiHiltunen, Kaustubh Joshi, H. Andr´esLagar-Cavillaand M. Satyanarayanan

6. Motivations • Offices and homes have many PCs • But, they areoften left running idle • PCs idle on average 12 hours a day • “Skilled in the art of being idle” by Nedevschi et al. in NSDI 2009 • 60% of desktops remain powered overnight • “After-hours power status of office equipment in the USA” by Webber, in Energy 2006

7. Why is it important? • Dell Optiplex 745 Desktop • Peak power: 280W • Idle power: 102.1W • Sleep power: 1.2W • If we put one to sleep when it is idle, the saving is (102.1-1.2)W.

8. Why do we leave desktops on? • Applications with always on semantics • Skype, IM, email, personal media sharing • Interspersed activities with idle periods • Lunch break • Chatting with colleagues

9. Related work • Full VM migration • LiteGreen, USENIX 2010 best paper • Encapsulate user session in VM • When idle, migrate VM to consolidation server and power down PC • When busy, migrate back to user’s PC User0 User1 Dom0 Xen

10. Partial VM migration • Idle VM only access partial memory and disk state (working set) • Migrate only the working set to a server • Potentially a cloud server • Cloud provider can further aggregate

11. Advantages • Small migration footprint • Client • Fast migration • Low energy cost • Network • Reduce bandwidth demand •   Server • More VMs per server

12. Feasibility Study • Can its desktop save energy by sleeping when an VM runs on the cloud? • Does the entire domain save energy by migrating idle sessions by sleeping?

13. Methodology • Prototyped simple on-demand migration approach with SnowFlock • Prepared a VM image, and run the VM • After five minutes, used SnowFlock to clone the VM • Monitor memory and disk page migration to cloneVM

14. Setup • Dell Optiplex 745 Desktop • 4GB RAM, 2.66GHz Intel C2D • Peak power: 280W • Idle power: 102.1W • Sleep power: 1.2W • VM Image: • Debian Linux 5 • 1GB RAM • 12 GB disk

15. Workloads

16. Memory Request Pattern • Spatial locality • Pre-fetching

17. Page Request Interval • 98% of request arrive in close succession

18. Potential Sleep Intervals

19. Potential Sleep Intervals

20. Potential Sleep Intervals

21. Potential Sleep Intervals

22. Energy Savings: an hour-long trace

23. Hourly Energy Savings: an overnight session • Saves 69% of energy

24. Memory footprint • A cloud node with 4GB of RAM can run ~30 VMs

25. Domain-wide Energy Savings

26. Annual Energy Savings • No partial migration

27. Annual Energy Savings • V = 23

28. Annual Savings

29. Open issues • Can it save cost? • Network • Cloud Rental • Frequent power cycling reduces hw life expectancy and limits power savings • Reduce number of sleep cycles and increase sleep duration • Predict page access patterns and prefetch • Leverage content addressable memory • Fast reintegration • Big Q: Can it be fast enough so that a user does not suffer a long delay? • Policies • When to migrate/re-integrate? • When does the desktop go to sleep? • On re-integration, should state be maintained in the cloud? For how long?

30. Disaster Recovery as a Cloud Service: Economic Benefits & Deployment Challenges Timothy Wood and Emmanuel Cecchet, University of Massachusetts Amherst; K.K. Ramakrishnan, AT&T Labs—Research; PrashantShenoy, University of Massachusetts Amherst; Jacobus van derMerwe, AT&T Labs—Research; ArunVenkataramani, University of Massachusetts Amherst

32. Datacenter Disasters • Disasters cause expensive application downtime • Truck crash shuts down Amazon EC2 site center (May 2010) • Lightning strikes EC2 data (May 2009) • Comcast Down: Hunter shoots cable (2008) • Squirrels bring down NASDAQ exchange (1987 and 1994)

33. DR Fits in the Cloud • Customer: pay-as-you-go and elasticity • Normal is cheap (fewer resources for backup than normal operations) • Rapidly scale up resources after disaster is detected • Provider: high degree of multiplexing • Customers will not fail at once • Can offer extra services like disaster detection

34. What is disaster recovery • Use DR services to prevent lengthy service disruptions • Data backups + failover mechanism • Periodically replicate state • Switch to backup site after disaster

35. DR Metrics • Recovery Point Objective (RPO): the most recent backup time prior to any failure • Recovery Time Objective (RTO): how long it can take for an application to come back online after a failure occurs • Time to detect failure • Provision servers • Initialize applications • Configure networks to connect

36. Performance • Have a minimal impact on the performance of each application being protected under failure-free operation • How can DR impact performance? • Consistency • The application can be restored to a consistent state • Geographic separation • Challenge: increasing network latency

37. DR Mechanisms • Hot Backup Site • Provides a set of mirrored stand-by servers that are always available • Minimal RTO and RPO • Use synchronous replication to prevent any data loss

38. Warm backup Site • Cheaply synchronize state during normal operations • Obtain resources on demand after failure • Short delay to resource provision and applications

39. Cost analysis study • Compare DR in Colocation center to Cloud • Colocation • pays for servers and space at all times • Cloud DR • Pays for resources as they are used

40. Case Study 1 • RUBiS: an ebay-like multi-tier web application • Three front ends • One database server • Only database state is replicated

41. Cost analysis • 99% Uptime cost (3 days of disaster per year)

42. Case 2: Data Warehouse • Post-disaster expensive due to high powered VM instance • Overall cheaper because 99% Uptime

43. RPO vs Cost Tradeoff • Flexible • Colo has a fixed cost regardless of RPO requirements

44. Cost Analysis Summary • Cloud DR’s benefits depend on • Type of resources to run application • Variation between normal and post-disaster costs • RPO and RTO requirements • Uptime • Cloud is better if post-disaster cost much higher than normal mode

45. Provider Challenges • How to maximize revenue? • Makes money from storage in normal case • But must pay for servers and keep them available for DR • Possible solutions • Spot instances (EC2 uses them) • Higher prices for higher priority resources • Correlated failures • Large disasters may affect many • Possible solutions • Decide provision using a risk model • Spread out customers

46. Mechanisms Needed for Cloud DR • Network reconfiguration • Application must be brought up online after moved to a backup site • May require setting up a private business network • Security and Isolation • VM migration and cloning • Restore an application after a disaster is handled • Cloud provider does not support VM migration in and out cloud yet

47. Summary • Cloud based disaster recovery • Can reduce cost • Up to 85% from a case study • Flexible tradeoff between cost and RPO

48. Forecast • Next lecture • Another cloud application for group collaboration • Monday is in fall break • Next Wednesday • Midterm • http://www.cs.duke.edu/courses/fall10/cps296.2/syllabus.html