1. 1 Agility in Virtualized Utility Computing Hangwei Qian, Elliot Miller, Wei Zhang Michael Rabinovich, Craig E. Wills {EECS Department, Case Western Reserve University} {CS Department, Worcester Polytechnic Institute}

2. 2 Internet Applications: Resource Provisioning Challenge  Unpredictable demand  Challenge: how much resource to provision?  Too little – lose business  Too much – poor utilization  Utility Computing is a promising answer

3. 3 Resource Management Alternatives  Application server sharing  Different applications running on the same app server  OS-level sharing  Each application runs in dedicated app server  Several app servers share physical machine  Dedicated physical machines  Each physical machine runs one app server with one app  Resources are assigned at the granularity of entire machines  Isolation (security, fault, performance) vs. utilization tradeoff

4. 4 An Appealing Option: Virtual Machines  Almost as good isolation as physical machines reassignment  Much better utilization than physical machine reassignment  Heterogeneity support

5. 5 Target Utility Computing Platform Applications run on dedicated app servers App servers run on dedicated VMs App instances form app-level clusters

6. 6 Goal  Improve the agility of Utility Computing “how quickly Utility Computing Platform can react to changing demands.”

7. 7 VM-based resource management alternatives  Migration of VMs  Redeployment of Application Servers on Demand

8. 8 Migration of VMs  Start/Stop VMs  Predeploy everywhere  Start more instances in high-demand areas  Stop underloaded instances  Clone VM  Stop overloaded VMs on overutilized hosts  Copy stopped VMs to other underutilized hosts  Start the cloned VM on target hosts  Suspend/resume  Pre-deploy VMs across Hosts  Suspend VMs with Unpopular Applications  Resume VMs with popular Applications  Live VM Migration

9. 9 Redeployment of Application Servers on Demand  Pre-deploy VMs across Hosts  Remove app servers with Unpopular Applications from VMs  Add app servers with popular Applications to VMs

10. 10 Our Approach: Ghost VMs  Active VM: alive and utilized for application request processing  Ghost VM: alive but unutilized Fully participate in cluster maintenance Do not process any requests Spend little CPU cycles

11. 11 Resource Reassignment Mechanism Ghost implementation options: switch reconfiguration on demand -Remove VMs from switch -Set the Max Connection option to minimum (1) for the ghost VMs

12. 12 Evaluation  Experiment Environment  Hardware: Intel (R) 4-core 2.33 GHz, CPU, 4G memory, 146G disk with 15K RPM Nortel Alteon 2208 Application Switch  Software: Linux 2.6.17-10-generic SMP VMware Server 1.0.1 Websphere 6 Network Deployment

13. 13 Migration of VMs  Start/Stop VM  About 64s to start a VM when its memory is flushed out, with a competing VM allocating memory moderately  About 20s to start the cluster node agent  About 97s to start the application server  Totally about 181s  Clone VMs  About 15 minutes for a VM with 1G memory and 10G disk in a 100Mbps local network.

14. 14 Migration of VMs (cont’ed)  Suspend/Resume VMs  About 5s on average in a repeated experiments  About 10s on average for VM with memory swapped out  About 14s on average with a competing VM (more realistic)  About 30s for app server on the resumed VM to get re- integrated into the cluster  Totally about 44s

15. 15 Redeployment of Application Servers on Demand  About 95s to stop a cluster member (application server)  About 19s to create a cluster member  About 97s to start a cluster member  Totally about 211s

16. 16 Agility of the Above Methods MethodAgility (sec) Migration of VMs~180 Redeployment of App Servers~210 Suspend/Resume VMs>44  The best agility we can expect is: 44s

17. 17 Active/Ghost VMs  Overhead of ghost VM: 1.4%-3.3% CPU  Agility  7s: Add/remove VM from switch  2s: Set the Max connection to minimum(1)

18. 18 Memory Swap-in Problem?  For a VM with 1G memory  about 652s to swap in all the memory  about 267s to swap in 50% memory  about 80s to swap in 5% memory  Solution: Keep Ghosts in memory!  Only run as many active+ghost VMs as total physical memory allows  Also reserve memory for host OS (1G) Adding memory is much cheaper than adding physical machines Only very small number of ghost VMs are needed to hide resource reassignment latency  VMware ESX: Reserved Memory for VMs  VM state hierarchy  Suspended  Ghost  Active

19. 19 Evaluation Summary MethodAgility (sec) Migration of VMs~180 Redeployment of App Servers~210 Suspend/Resume VMs>44 Active/Ghost VMs2-7  Active/Ghost VMs has the best Agility  The price is memory overhead  Summary

20. 20 Future Work  Extend the scale of our test platform  Move to VMware ESX  More investigation of resource tradeoffs for ghost, suspended and active VMs  Explore more on global and local data center resource management  Build full-function prototype for resource management in Utility Computing

21. 21 Summary  Internet applications introduce resource provisioning challenge  Utility computing is a promising paradigm  VMs gain popularity as resource management approach  Agility is an important characteristic of a utility computing platform  Ghost VMs as a mechanism for agile utility computing

22. 22 Thank you ! Questions?