Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

25
Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005 CSE 598c April 17, 2006 Bhuvan Urgaonkar

description

Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005. CSE 598c April 17, 2006 Bhuvan Urgaonkar. Problem Setting. Growing trend of hosting applications at third-party platforms Two challenges Isolation, security to co-located applications - PowerPoint PPT Presentation

Transcript of Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Page 1: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Friendly Virtual Machines

Zhang,Bestavros etc., Boston Univ.ACM/USENIX VEE 2005

CSE 598c April 17, 2006

Bhuvan Urgaonkar

Page 2: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Problem Setting• Growing trend of hosting applications at

third-party platforms• Two challenges

• Isolation, security to co-located applications• Efficient and fair resource allocation

• Virtualization seen as a promising approach for isolation

• What about resource allocation?

Page 3: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Challenge - Resource Allocation in Hosting

Environments• Traditional solutions

• Over-provisioning => wasteful• Fair schedulers in the OS, dynamic provisioning,

admission control• Complex• Deprive the application of meaningfully adapting

its behavior to match available resources• Against the famous end-to-end argument

developed in the networking community

Page 4: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

End-to-end Argument• Clark et. al

• A functionality should be pushed to the higher layer whenever possible• IP network implements packet forwarding, leaving

congestion control to end systems• When applied to hosting platforms

• Let the applications decide how many resources they need

Page 5: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

How do VMs make end-end idea realizable?

• In a traditional hosting system, applications would have to be modified• Always undesirable, often impossible

• In a virtualized hosting system• VMM is like OS, guest OS is like application• Guest OS modification not so unacceptable

• E.g., Xen, Denali• Main idea: It is possible to achieve good efficiency

and fairness using “friendly” virtual machines

Page 6: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Outline• Motivation• Approach• Implementation• Evaluation• Conclusions

Page 7: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Friendly Virtual Machine• Not malicious• Dynamically adapts its resource needs to

system conditions• Inspiration: AIMD congestion control in TCP• Gradually increase resource requirements, back-

off when resource contention increases• How a TCP researcher would approach the

resource management problem in data centers

Page 8: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

System Goals• Efficiency

• Resources should not be overloaded• E.g., Heavy paging during overload => low

throughput• Resources should not be unnecessarily

underutilized• Fairness

• Each VM is allocated a proportional share of the bottleneck resource for that VM

Page 9: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Overload Detection• Unlike TCP, there are multiple resources to

consider• CPU, virtual memory, network bandwidth

• Resource utilization metrics not reliable• E.g., CPU util may be high but the bottleneck

may be the memory sub-system• Use application-centric metrics like

response time or throughput

Page 10: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Overload Detection• Virtual Clock Time (VCT)

• Real time interval between consecutive virtual clock cycles

• Bottleneck resource• The resource that is the first to trigger a significant

increase in VCT• Bottleneck-equivalence classes• Detection: Measure the ratio of current VCT to

minimum VCT observed• Compare with a threshold (2)

Page 11: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Adaptation Mechanisms• Control number of processes/threads

• In practice, suspending running processes may not be a good idea

• Alternatives • Suspend less important (e.g., younger) processes• Don’t allow new processes instead of suspending existing

ones• Rate control by forcing VM to sleep• Follow an AIMD style adaptation that converges to

fair/efficient allocation• Paper presents a control-theoretic model to prove

convergence/stability properties

Page 12: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Salient Features• Underlying system requirements

• Schedulers should be unbiased like round-robin, unlike multi-level feedback

• VMM should implement resource policing to enforce AIMD behavior

• Various adaptation strategies can co-exist• Think TCP-reno, TCP-tahoe, …

• Suggestion: VMM could provide incentives for friendly behavior

Page 13: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Discussion• Is this system practical?

• Rate of adaptation• Would it be fast enough for hosted applications?• Applications need resources soon after overload starts• How would the system behave with biased schedulers?

• Can the adaptation mechanism be extended to handle different levels of importance?• This system might punish an application precisely when it

is crucial for it to service its workload• E.g., An e-commerce app during Thanksgiving

• Global knowledge can be crucial for efficiency• E.g., LRU page replacement

• Security, isolation• To me it seems this would be as secure as a system with a

more heavy-weight VMM

Page 14: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Implementation• User-mode Linux• Implement adaptation of number of

processes and rate control• 500 lines of code

Page 15: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Outline• Motivation• Approach• Implementation• Evaluation• Conclusions

Page 16: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Memory intensive benchmark - Performance metrics vs # VMs

• Linux suspends processes arbitrarily when excessive thrashing occurs, their system spreads the punishment evenly

Page 17: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Benchmark - Performance metrics vs # threads/VM (2

VMs)

• Graceful degradation

Page 18: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

How not to do Evaluation

• No confidence intervals!• Observations for light loads are meaningless

• Pick someone your own size• Of course, their system is better than vanilla

UML, so what?• Should have compared with a system that

implements fair schedulers

Page 19: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Apache - 4 VMs

• Graceful degradation

Page 20: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Evolution of VCT w/ UML

• Unfairness at high load

Page 21: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Evolution of VCT w FVM

• Fair CPU allocation

Page 22: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Tput per VM w UML

• Unfairness at high load• Unfair CPU allocations due to different paging treatment and process suspension

Page 23: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Per VM Tput w FVM

• Fair behavior

Page 24: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

Conclusions• Distributed, application-driven

resource allocation• (+) Cool idea• (-) Needs more research to be

convincing• Experimental evaluation not

satisfactory

Page 25: Friendly Virtual Machines Zhang,Bestavros etc., Boston Univ. ACM/USENIX VEE 2005

More Discussion