merging planetlab and the cloud - ieice the institute of ...nv/2nd-andy.pdf · openstack,...

Merging PlanetLab and the Cloud

Andy Bavier Princeton University

NV Symposium, Kyoto Japan 24 August, 2012

PlanetLab �  Begun in 2002, used by thousands of researchers

�  Fundamental idea: stronger science �  Demonstrate that research really works

�  Scalability, robustness, real workloads

24 August, 2012 NV Symposium, Kyoto Japan 2

A Distributed “Cloud” �  PlanetLab: distributed virtualization of compute

and network resources

�  Slices �  Service “sandbox” �  Programming environment

�  Network overlays �  Transport, topology

�  Network substrate


Software: MyPLC �  Anyone can create a private PlanetLab

�  PlanetLab node software

�  PLC management framework + API �  Image, configure physical nodes

�  Create / delete VMs

�  Monitoring tools

�  Examples �  VINI (virtual networks)

�  MeasurementLab (network measurement) �  VICCI (Cloud research)


Issues… �  PlanetLab is a decade old – it looks dated

�  Overlap with IaaS Cloud management platforms �  OpenStack, Eucalyptus, CloudStack, OpenNebula, etc.

�  Virtualization: Linux Vserver �  In 2002 was most mature technology

�  Small developer base, requires custom-built kernel

�  Newer virtualization technologies: Xen, KVM, LXC, etc.

�  PlanetLab is designed for overlay networks �  Widespread research interest in SDN (e.g., OpenFlow) �  Does not offer deep network programmability


Retiring MyPLC �  PlanetLab platform is still useful for research

�  PlanetLab architecture remains sound �  Slices and overlays are still useful abstractions �  The GENI architecture is based on PlanetLab �  At a high level most Clouds resemble PlanetLab

�  Problem: stale implementation �  Open-source IaaS Cloud stacks can also manage VMs �  Decreasing value in maintaining MyPLC

�  Solution: merge MyPLC and OpenStack �  MyPLC becomes a collection of software add-ons to the

OpenStack toolset


Goals �  Modest:

�  Keep PlanetLab relevant for research (e.g., GENI)

�  Reduce our maintenance burden �  Target our development towards creating real value

�  Leverage the OpenStack developer community �  Donate core PlanetLab technologies to the Cloud

�  Ambitious: �  Establish a tech transfer path for the PlanetLab

community’s research innovations

�  Participate in the SDN + Cloud revolution


Strategy �  Management: merge PLC => OpenStack ecosystem

�  SDN: adopt Open vSwitch and Quantum for virtualizing the network

�  Compute virtualization: Linux Containers (LXC)


Management: OpenStack �  Open source Cloud software

�  Infrastructure as a Service (IaaS) => provision VMs

�  Collection of “cloud services” �  Tenant-facing API: logical abstractions �  Backend implementations of API

�  Components: �  Nova – Compute as a Service

�  Swift, Glance – Storage as a Service �  Quantum – Network as a Service


Conceptual Cloud Arch


Nova Coverage

quantum


Merging PlanetLab �  Map PlanetLab to OpenStack concepts

�  E.g., slice => tenant, site => availability zone

�  Identify critical gaps in Nova coverage that are filled by PlanetLab modules �  Security, robustness in a distributed environment

�  Imaging and configuring physical nodes �  User-facing dashboard, PLCAPI

�  Logging and monitoring

�  Package PlanetLab modules as OpenStack projects


SDN: Quantum �  Where will SDN play out in the Cloud?

�  Network as a Service (NaaS)

�  Quantum: OpenStack core project (Folsom) �  Tenants can create virtual networks, control addressing �  Quantum API + pluggable controllers => many backends

�  Can leverage Open vSwitch (Linux software bridge) �  OpenFlow, tunneling, QoS, monitoring, …

�  PlanetLab goals: �  Provide per-slice virtual topologies �  Allow experimentation with SDN inside a PlanetLab slice


Virtualization: LXC �  PlanetLab uses lightweight OS containers

�  Scalability: 100’s of slices on a single node

�  Historically: Linux VServers �  Custom kernel, few developers

�  Now: Linux Containers �  Similar to VServers �  Already in mainline Linux kernel

�  Better hardware support, security fixes, etc.

�  Contribute our expertise to making LXC more robust


PlanetLab Networking �  VServer has minimal network virtualization

�  All slices have same IP address, share port space

�  Single shared stack, per-slice traffic isolated only

�  LXC allows customization of network stack �  Each slice has its own network namespace �  Can customize at L2 and above: per-slice virtual

devices, routing table, firewall, bridging, TCP parms

�  Leverage Open vSwitch �  Flexibly supports connecting VMs to the network


PlanetLab Classic �  Single public IP address

�  Each slice has a private IP address (10.0.0.0/8)

�  Connect to external network via NAT

�  BUT can also bind directly to external ports

�  Everything that used to work still works…

NIC

Slice 1 Slice 2 Slice 3

vSwitch

NAT

IP routing


Measurement Lab �  Gather data on ISP

performance

�  Joint project with Google and New America Foundation

�  Each slice has a public IP address

�  Virtual interfaces bridged at L2 to external NIC

NIC


vSwitch


VINI �  Virtual L2 topology inside

a slice

�  Tunnel L2 over L3 (EGRE)

�  vSwitch binds virtual interfaces in slices to specific EGRE tunnels �  Show up as virtual

interfaces in Linux

�  Multiple virtual interfaces per slice

�  SIGCOMM 2006 NIC


vSwitch

EGRE 4

EGRE5

EGRE6


InstaGENI �  Virtual L2 topology inside

a slice

�  Use VLANs for L2 sandbox

�  vSwitch binds virtual interfaces in slices to specific VLANs �  Show up as virtual

interfaces in Linux

�  Multiple virtual interfaces per slice

NIC


vSwitch

VLAN4 VLAN5 VLAN6


Summary �  Our mission: continue to provide value to the

networking research community �  SDN, GENI, NV, FI, etc.

�  Next step: align PlanetLab and the Cloud �  Management: OpenStack + Quantum

�  Virtualization: LXC + Open vSwitch

�  Create a robust, scalable, wide-area IaaS Cloud based on OS containers and virtual switches


merging planetlab and the cloud - ieice the institute of ...nv/2nd-andy.pdf · openstack,...

Documents