1 / 15

PlanetLab V3 and beyond

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

lighty
Download Presentation

PlanetLab V3 and beyond

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. PlanetLab V3 and beyond Steve Muir Princeton University September 17, 2004

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related