PlanetLab V3 and beyond Steve Muir Princeton University September 17, 2004

Overview Why upgrade? What will change? Resource management in V3 PLC database access Enabling helper services PlanetLab-in-a-box

Why Upgrade? To make future maintenance easier To improve resource management To support new slice services To enable multiple PlanetLab instances

What Will Change? Node software will be based on Fedora –2.6.x kernel broader hardware device support –up-to-date versions of packages Slice-visible changes should be minimal –some packages added to base vserver

Resource Management in V3 plkmod replaced by CKRM + VNET Class-based Kernel Resource Management –started at IBM, now at ckrm.sf.net –framework + resource controllers –memory, disk I/O bandwidth, CPU share Virtualised Network Interface –no more safe raw sockets –controls outgoing network bandwidth (a la plkmod) Disk quotas supported by vserver subsystem

CKRM Resource Controllers Class-aware enhancements to existing schedulers Physical resources (CPU, RAM, I/O) Virtual resources (number of tasks) Get Involved: need to build more/alternate resource controllers to further improve system Get Involved: build work load management system that use these resource management knobs to improve overall system efficiency

PLC database access The heart of PlanetLab Slice API currently in use Admin API for access to user, node, site information Future: authentication against PLC db –step towards federated PlanetLabs

Enabling helper services Move slice support services into slices –more flexibility for users –less dependency on small core team Slices need to associate with helpers Helper services need access to privileged operations –provided by Proper

Privileged Operations Service Poking holes in the sandbox –in a safe, controlled manner To be integrated with Node Manager Operations supported –mount other slice filesystems –get/set file flags –execute processes in other slices –open real raw sockets

Example 1: Seurat (CMU) Monitoring of slice filesystems for intrusions Read-only access to slice filesystems –voluntarily provided by slices Monitors each slice for file changes Uses spatial and temporal correlation to detect anomalous changes

Example 2: Stork (U. of Arizona) Manages packages installed in multiple client slices –arranges efficient sharing of files Initialises slices with files required by user Provides upgrades when new package available

Future: PlanetLab-in-a-box How to create multiple PlanetLabs Both federated and independent Federated share PLC database –or pieces of it e.g., user authentication Independent has its own database –corporate internal PlanetLab –personal testing and development

Example 3: Authentication Service ssh in a slice Proper provides sudo-like access from authentication slice to client slices Easily extended to other authentication mechanisms –GSSAPI - Grid Security System –Rex (NYU) - Secure File System

Example 4: SHARP (Intel/UCSD) Resource broker for slices Node Manager allows SHARP to trade resources between slices –trade one resource for another –or concentrate resources in one period Decentralised from PLC

Conclusions PlanetLab V3 will be easier to maintain In-sync with standard Fedora Linux And have better resource management Decentralised development is the goal –more users contributing infrastructure code Lots of ways to get involved!