A Case for Virtualizing Nodes on Network Experimentation Testbeds

1. A Case for Virtualizing Nodes on Network Experimentation Testbeds Konrad Lorincz Harvard University July 13, 2014

2. Motivation In the beginning …. 1960s, 1970s • hardware was expensive => commodity • computer systems shared by multiple users Today • hardware is relatively cheap • connectivity and location are a commodity • Network experimentation testbeds are expensive => shared • ex: PlanetLab, Globus, Centurion PlanetLab

3. Sharing Scenario • Current mode of sharing • Each user has an account on the testbed • To perform experiment – user logs on one node, runs script which starts jobs on a subset of the nodes • Unfortunate Scenarios • Inconsiderate user: Node N is performing critical experimental computation for user A • User B runs his/her script that starts computationally intensive job on node N • Considerate user: Node N is running A’s experiment • User B checks load on node N, determines it’s very low, starts a moderately computation intensive job on node N

4. Current Way to Solve This • In a Small Lab • John posts a message on the bulletin board … • Analysis • May work OK in a small lab => clearly does not scale • Inefficient use of resources Please don’t use machines X, Y, and Z between5/2/02 – 5/5/02. I am running my experiments. Thanks,-John PS. If you absolutely must log on one of these machines during this time, please don’t run any computationally intensive jobs.

5. Desired Sharing Properties Need a good mechanism for sharing so that users don’t get in each other’s way • Ideal Scenario: Researcher Aspecifies to the scheduler that it needs N number of machines/nodes, for H number of hours, each with W amount of RAM, X amount of disk size, CPU equivalent to Y MHz, and bandwidth of Z Mbps. Desired Properties of Mechanism for Sharing • Efficient multiplexing of resources amongst users • Control over resources • Reservation of resources • Enforcement • Isolation • Security • Performance • Customization

6. Solution Claims • Sharing problem can be solved by => virtualizing the testbed nodes • Good way to virtualize nodes => use a VMM

7. Advantages of Virtualization • Efficient Multiplexing of Resources • Takes advantage of statistical multiplexing (demand-based) • Resources requested, if granted, are guaranteed for the duration of the experiment • Only need to request resources needed => may be very few

8. Advantages of Virtualization • Control Over Resources • Can be fine-grained and precise • Allows for reservation/allocation of resources • Enforcement of reservations and policies • Commercialization? – if it can be controlled and accounted for => service could be sold

9. Advantages of Virtualization • Isolation • Security • Almost perfect security from other VMs (i.e. users) • Namespaces of each VM is private => cannot even name a resource on another VM • Even if a VM is compromised, the rest are not • Downside: • Resources don’t span multiple protection domains => can’t share a common service across VMs • Performance – aim for soft guarantees • Actions of other users on the node don’t affect my availability to resources (guarantees) • If Bob overloads his VM, it won’t affect my VM

10. Advantages of Virtualization • Customization • User may ask for exact machine configuration he/she requires (RAM, disk size, CPU, network bandwidth) • May load different OSes or modified/customized ones • User may require a particular OS (FreeBSD) • Denali kernel can be loaded and run on • User has superuser privileges • Easy management • user configures once a customized VM image => transfers it to required nodes or other testbeds

11. Arguments Against Virtualization • Overhead of Running a VMM • Relatively small! VMware server, Denali + others report about 10% • Hardware is getting faster => overhead will be even less of a factor

12. Arguments Against Virtualization • Use Dedicated Physical Machines • Reservation too-coarse grained • must dedicate an entire physical machine to a user => may require the equivalent of 1/8 of the machine • More expensive • More expensive to buy 6-12 machines then one more powerful one + VMM "We're running 20 virtual machines on one four-way system, and it's handling everything from CRM applications and security to application development and testing, all of which has saved us huge amounts of time and money in hardware costs." -- Alan Thomas Senior Technical Consultant, National Gypsum Company

13. Arguments Against Virtualization • Do/Implement the sharing at the OS level • VMMs are much simpler than conventional OSes • Other mechanisms at the OS level impose particular software interfaces or models to the user => with a VMM it’s clear, you get a “raw” machine • Cannot provide strong performance isolation => the need to support high-level abstractions prevents OSes from providing strong performance guarantees • Precise resource accounting is difficult because resources intertwined in the implementation of abstractions. ex: file buffer cache and TCP\IP socket buffers consume memory resources that aren’t charged to any particular app. [Denali paper]

14. Can It Be Implemented? • Not only feasible, but practical • Several off the shelf products exist: • VMware ESX server • IBM z/VM • Disco (for NUMA) • For us, VMMs only needs to support half-doze to dozen VMs,can easily handle (VMware ESX supports up to 64 VMs) • If a particular VMM doesn’t provide guarantees for a resource, it can be easily extended with well known scheduling algs. • Fair queuing => network bandwidth • Stride scheduling => CPU • Cello framework => disk bandwidth allocation

15. Conclusion • Network experimentation testbeds are a commodity • Users have different needs + require guarantees. Currently no formal way to handle this • Virtualizing testbed nodes by running a VMM is a good solution. • Efficient multiplexing of resources • Fine-grained control over physical resources • Isolation • Customization

16. App 1 App 2 App 1 App 1 … OS 1 OS 2 … OS 5 HW HW HW VMM Hardware (HW)