1 / 48

Lecture 9: More Cloud Applications

Lecture 9: More Cloud Applications. Xiaowei Yang (Duke University). 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. Review. Cloud Computing Elasticity Pay-as-you-go Challenges

tyanne
Download Presentation

Lecture 9: More Cloud Applications

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. 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

  31. 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)

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

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

  38. 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

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

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

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

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

  43. 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

  44. 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

  45. 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

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

  47. 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

More Related