1 / 74

Global Overlay Network : PlanetLab

Global Overlay Network : PlanetLab. Claudio E.Righetti October, 2006 (some slides taken from Larry Peterson).

isabel
Download Presentation

Global Overlay Network : PlanetLab

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. Global Overlay Network : PlanetLab Claudio E.Righetti October, 2006 (some slides taken from Larry Peterson)

  2. “PlanetLab: An Overlay Testbed for Broad-Coverage Services “ Bavier, Bowman, Chun, Culler, Peterson, Roscoe, Wawrzoniak . ACM SIGCOMM Computer Communications Review . Volume 33 Number 3 : July 2003 • “ Overcoming the Internet Impasse through Virtualization “ Anderson , Peterson , Shenker , Turner . IEEE Computer. April 2005 • “Towards a Comprehensive PlanetLab Architecture”, Larry Peterson, Andy Bavier, Marc Fiuczynski, Steve Muir, and Timothy Roscoe, June 2005 http://www.planet-lab.org/PDN/PDN-05-030

  3. Overview • What is PlanetLab? • Architecture • Local: Nodes • Global: Network • Details • Virtual Machines • Maintenance

  4. What Is PlanetLab? • Geographically distributed overlay network • Testbed for broad-coverage network services

  5. PlanetLab Goal “…to support seamless migration of an application from an early prototype, through multiple design iterations, to a popular service that continues to evolve.”

  6. PlanetLab Goal “…support distributed virtualization – allocating a widely distributed set of virtual machines to a user or application, with the goal of supporting broad-coverage services that benefit from having multiple points-of-presence on the network. This is exactly the purpose the PlanetLab slice abstraction .”

  7. Slices

  8. Slices

  9. Slices

  10. User Opt-in Client Server NAT

  11. Challenge of PlanetLab “ The central of challenge PlanetLab is ti provide decentralized control of distributed virtualization.”

  12. Long-Running Services • Content Distribution • CoDeeN: Princeton • Coral: NYU • Cobweb: Cornell • Storage & Large File Transfer • LOCI: Tennessee • CoBlitz: Princeton • Anomaly Detection & Fault Diagnosis • PIER: Berkeley, Intel • PlanetSeer: Princeton • DHT • Bamboo (OpenDHT): Berkeley, Intel • Chord (DHash): MIT

  13. Services (cont) • Routing / Mobile Access • i3: Berkeley • DHARMA: UIUC • VINI: Princeton • DNS • CoDNS: Princeton • CoDoNs: Cornell • Multicast • End System Multicast: CMU • Tmesh: Michigan • Anycast / Location Service • Meridian: Cornell • Oasis: NYU

  14. Services (cont) • Internet Measurement • ScriptRoute: Washington, Maryland • Pub-Sub • Corona: Cornell • Email • ePost: Rice • Management Services • Stork (environment service): Arizona • Emulab (provisioning service): Utah • Sirius (brokerage service): Georgia • CoMon (monitoring service): Princeton • PlanetFlow (auditing service): Princeton • SWORD (discovery service): Berkeley, UCSD

  15. PlanetLab Today www.planet-lab.org

  16. PlanetLab Today • Global distributed systems infrastructure • platform for long-running services • testbed for network experiments • 583 nodes around the world • 30 countries • 250+ institutions (universities, research labs, gov’t) • Standard PC servers • 150–200 users per server • 30–40 active per hour, 5–10 at any given time • memory, CPU both heavily over-utilised

  17. Usage Stats • Slices: 600+ • Users: 2500+ • Bytes-per-day: 3 - 4 TB • IP-flows-per-day: 190M • Unique IP-addrs-per-day: 1M

  18. Priorities • Diversity of Network • Geographic • Links • Edge-sites, co-location and routing centers, homes (DSL, cable-modem) • Flexibility • Allow experimenters maximal control over PlanetLab nodes • Securely and fairly

  19. Key Architectural Ideas • Distributed virtualization • slice = set of virtual machines • Unbundled management • infrastructure services run in their own slice • Chain of responsibility • account for behavior of third-party software • manage trust relationships

  20. Architecture Overview • Slice : horizontal cut of global PlanetLab resources • Service : set of distributed and cooperating programs delivering some higher-level functionality • Each service runs in a slice of PlanetLab’s global resources • Multiple slices run concurrently “ … slices act network-wide containers that isolate services from each other. “

  21. Architecture Overview (main principals) • Owner: is an organization that hosts ( owns ) one or more PlanetLab nodes • User : is a researcher that deploys a service on a set of PL nodes • PlanetLab Consortium (PLC) : trusted intermediary that manages nodes on behalf a set owners, and creates sliceson those nodes on behalf of a set of users

  22. Princeton Berkeley Washington MIT Brown CMU NYU EPFL Harvard HP Labs Intel NEC Labs Purdue UCSD SICS Cambridge Cornell … princeton_codeen nyu_d cornell_beehive att_mcash cmu_esm harvard_ice hplabs_donutlab idsl_psepr irb_phi paris6_landmarks mit_dht mcgill_card huji_ender arizona_stork ucb_bamboo ucsd_share umd_scriptroute … Trust Relationships Trusted Intermediary (PLC) N x N

  23. 2 4 3 1 Trust Relationships (cont) Service Developer (User) Node Owner PLC PLC expresses trust in a user by issuing it credentials to access a slice 2) Users trust PLC to create slices on their behalf and inspect credentials 3) Owner trusts PLC to vet users and map network activity to right user 4) PLC trusts owner to keep nodes physically secure

  24. Principals ( PLC = MA + SA ) • Node Owners • host one or more nodes (retain ultimate control) • selects an MA and approves of one or more SAs • Service Providers (Developers) • implements and deploys network services • responsible for the service’s behavior • Management Authority (MA) • installs an maintains software on nodes • creates VMs and monitors their behavior • Slice Authority (SA) • registers service providers • creates slices and binds them to responsible provider

  25. 1 4 2 3 Trust Relationships ( PLC decoupling) MA (1) Owner trusts MA to map network activity to responsible slice (2) Owner trusts SA to map slice to responsible providers 6 (3) Provider trusts SA to create VMs on its behalf Owner Provider (4) Provider trusts MA to provide working VMs & not falsely accuse it (5) SA trusts provider to deploy responsible services (6) MA trusts owner to keep nodes physically secure 5 SA SA is analogous to a virtual organization

  26. node database MA Owner VM NM + VMM Node Owner Service Provider VM SCS slice database SA Architectural Elements

  27. Services Run in Slices PlanetLab Nodes

  28. Services Run in Slices PlanetLab Nodes Virtual Machines Service / Slice A

  29. Services Run in Slices PlanetLab Nodes Virtual Machines Service / Slice A Service / Slice B

  30. Services Run in Slices PlanetLab Nodes Virtual Machines Service / Slice A Service / Slice B Service / Slice C

  31. “… to view slice as a network of Virtual Machines, with a set of local resources bound to each VM .”

  32. Architectural Components • Node • Virtual Machine (VM) • Node Manager (NM) • Slice • Slice Creation Service (SCS) • Auditing Service (AS) • Slice Authority (SA) • Management Authority (MA) • Owner Script • Resource Specification (Rspec)

  33. Per-Node View Node Mgr Local Admin VM1 VM2 VMn … Virtual Machine Monitor (VMM)

  34. Node Architecture Goals • Provide a virtual machine for each service running on a node • Isolate virtual machines • Allow maximal control over virtual machines • Fair allocation of resources • Network, CPU, memory, disk

  35. … … … Global View PLC

  36. Node Machine capable of hosting one or more VM • Unique node_id ( is bound set of attributes ) • Must have at least one non shared IP address

  37. Virtual Machine ( VM) Execution environment in which slice runs on a particular node. VMs are tipically implemented by Virtual Machine Monitor (VMM). • Multiple VMs run on each PlanetLab node • VMM arbitrates the nodes’s resources among them • VM is speficied by a set of attributes ( resource specification , RSpec) • RSpec defines how much of the node’s resources are allocated to the VM ; it also specifices the VM’s type

  38. Virtual Machine ( cont) • PlanetLab currently supports a single Linux-based VMM • Defines a single the VM’s type (linux-vserver-x86) • Most important properties today is that VMs are homogeneous

  39. Node Manager (NM) Program running on each node that creates VMs on that node, and controls the resources allocated to those VMs • All operations that manipulate VMs on a node are made through the NM • Provides an interface by which infraestructure services running on the node create VMs and bind the resources them

  40. Slice Set of VMs , with each element of the set running on a unique node • The individual VMs that make up a slice contain no information about the other VMs in the set, except as managed by the service running in the slice • Are uniquely identified by name • Interpretation depends on the context ( is no single name resolution service) • Slices names are hierarchical • Each level denoting the slice authority

  41. Slice Creation Service (SCS) SCS is a an infrastructure service running on each node • Typically responsible , on behalf of PLC , for creation of the local instantiation of a slice , which it accomplishes by calling the local NM to create a VM on the node • Users may also contact the SCS directly if they wish to synchronously create a slice on a particular node • To do so the user presents a cryptographically-signed ticket ( essentially RPsec’s )

  42. Auditing Service (AS) PLC audits behaovir of slices , and to aida in this process, each node runs an AS. The AS records information about packet transmitted from the node , and is responsible for mapping network activity to the slice generates it. • Trustworthy audit chain : packet signature--> slice name --> users • packet signature ( # source, # destination , time) • AS offers a public, web-based interface on each node

  43. Slice Authority (SA) PLC, acting as a SA, maintains state for the set of system-wide slices for which it is responsible • There may be multiple SA but this section focuses on the one managed by PLC. • SA to refer to both the principal and the server that implements it

  44. Management Authority (MA)

  45. Owner Script

  46. Resource Specification (Rspec)

  47. PlanetLab’s design philosophy • Application Programming Interface used by tipical services • Protection Interface implemented by the VMM PlanetLab node virtualization mechanisms are characterized by the these two interfaces are drawn

  48. PlanetLab Architecture • Node-level • Several virtual machines on each node, each running a different service • Resources distributed fairly • Services are isolated from each other • Network-level • Node managers, agents, brokers, and service managers provide interface and maintain PlanetLab

  49. One Extreme: Software Runtimes (e.g., Java Virtual Machine, MS CLR) • Very High level API • Depend on OS to provide protection and resource allocation • Not flexible

  50. Other Extreme: Complete Virtual Machine (e.g., VMware) • Very Low level API (hardware) • Maximum flexibility • Excellent protection • High CPU/Memory overhead • Cannot share common resources among virtual machines • OS, common filesystem • High-end commercial server , 10s VM

More Related