Network Virtualization Model - Planet Lab

Transcription

1 CoreLab: An Emerging Network Testbed towards Network Virtualization Network Virtualization Research Lab Akihiro NAKAO Associate Professor University of Tokyo NICT

2 PlanetLab The largest and most popular overlay network test-bed Currently consists of 900+ nodes at 450+ sites 800+ Projects/ Researchers 180+ high-level academic publications enabled 2

3 Brief History of PlanetLab PlanetLab 1.0 (2002-3) UNIX account slivers PlanetLab 2.0 (2003-4) Vserver slivers PlanetLab 3.0 ( ) PLCAPI 1.0 PlanetLab 4.0 (2007-) MyPLC1.0 Federation Idea PlanetLab 4.2 (2008-9) We are here Federation (PLE, PLJ, (PLK, PLC,=>PLA?)) New Development using Private PlanetLab (RSpec/GENI-wrapper, New Node Type, Monitoring, QA,VINI)

4 What have we learned from PlanetLab? Concept Slice-based experimental facility Slice Mechanism Resource Isolation through Virtualization Management Framework Node : Physical Machine Sliver : Virtual Machine Slice : A collection of Virtual Machines RSpec: Resource Description PLC: Central Management Servers

5 Slivers Sliver Sliver Sliver Sliver Node Mgr Owner VM VM 1 VM 2 VM n Auditing service Monitoring services Brokerage services Provisioning services Virtual Machine Monitor (VMM) Linux kernel (Fedora Core) + Vservers (namespace isolation) + Schedulers (performance isolation) + VNET (network virtualization) - From

6 PlanetLab Architecture Slice1 Slice2 Sliver Sliver PLC Node Sliver Sliver Node

7 Limitations in PlanetLab Flexibility is sacrificed over Scalability/Performance Sliver : Container-based Resource Isolation Shares crucial resources Single kernel (Linux with VServer patch) Network stack and modules (NAT, Firewall, etc) Network resources (IP address and ports) Vnet (virtual network device ; need work for multi-homing) Cannot run arbitrary kernel/network stack & modules Software Engineering Issue Cannot keep up with the latest kernel (VServer) The latest VServer patch (PlanetLab ) Misses out support for new devices/chip features

8 Design Principle for a New Test-bed Performance Network I/O Scalability The number of slices Isolation Resource must be isolated per slice Flexibility Arbitrary kernel/network stacks/resources Code-Reusability Catch up with the latest technology Minimize software engineering effort Largely Disregarded

9 VEE Candidate for Sliver Implementation Manager Apps apps Apps Apps Apps Apps MngOS GuestOS GuestOS GuestOS GuestOS Apps VE VE VM VM VM Apps VM VM HostOS VMM HostOS Hardware Hardware Hardware Resource Container Hypervisor-Based Host-Based Design Principles Performance Scalability Security Isolation Performance Isolation Flexibility Code Reusability Resource Container Hypervisor advantageous disadvantageous Hosted- VMM?? +? + + room for improvement

10 CoreLab Design Sliver VEE : Hosted Virtual Machine Monitor VM Disk Image Transfer : Multipath & Caching Network Configuration : Multihoming Management Tools: Reuse PlanetLab s design (GENI-wrapper/Federation possible) Comparison Chart PlanetLab CoreLab Sliver Resource Container Hosted VMM Kernel Shared Separated Guest OS Various Linux Distros Any OSes IP & Port Shared Shared (managed) Privileged System Calls Shared Isolated

11 CoreLab Prototype Implementation Sliver VEE : KVM + QEMU on Kernel VM Disk Image Transfer : BitTorrent Network Configuration : TunTap / Managed IP/Port Management Tools: MyPLC Optimizations Compression of VM Image Increase Sharable Buffers Decrease Influence of VM Boots Misc. SSH Login (permitopen, authorized_key) and VNC Compatibility with PlanetLab (PLCAPI + CoreLab APIs)

12 KVM Hosted Virtualization Full/Para Virtualization (Virtio)

13 Network Configuration PlanetLab Model CoreLab Model

14 VM Image Dissemination Introduce helper nodes BT Node Master BT Node Slave Introduce components BTManager BTSeed

15 Scalability Check (1/2) pkt-size=64b Total packet receive rate (Kpps) Probably our system is CPU bound QEMUs nicely schedule by Linux Kernel Max at 48kpps (slightly worse than Xen by Trellis) Little overhead in term of # of VMs ( VMs) Great resource fairness among VMs (~1.8% deviation) Offered Load via pktgen (Kpps)

16 CoreLab Deployment (on-going) Phase1 : 12 Sites over JGN2Plus + SINET + others 10 in operation Phase2 : Asian Region HP DL 580 (4U) Intel Xeon 16-core (quad 4-core) 128GB (Max 256GB) memory 300GB RAID5 (accommodate up to 254 slices)

17 CoreLab : In Action

18 Conclusions Contributions Identify design principles for alternative test-beds Performance, Scalability, Isolation Flexibility, Code-Reusability Implement prototype test-bed CoreLab Hosted VMM as sliver to achieve Report various optimization and preliminary evaluations Throughput 30-70% of Vanilla Linux and PlanetLab OS Future Work Build Full-Fledged CoreLab Optimize performance and scalability Virtual Router via Hosted VMM

19 More Future Directions CoreLab Enhancement Geographically (Japan to Asia) Public PlanetLab J-Lab as a regional Public PlanetLab Federation Federate CoreLab, J-Lab with PlanetLab, OneLab2 GENI Spiral 1 Solicitation 2 Virtual Router Project Extreme Enhancement to CoreLab OpenFlow / NetFPGA UTokyo, NICT, NEC, Hitachi, NTT, Fujitsu

20 Overlay to Network Virtualization Virtualize not only edges but also network core PC Server switch A Slice of Computation Resources Mgmt S/W VM(Slice) VM(Slice) VMM/Hypervisor VM(Slice) PlanetLab to GENI Similar efforts in several countries

21 Planetary-Scale Network Virtualization Internet-Wide / ISP-Wide Virtual Links Virtual Core Routers Virtual End System Virtual Edge Routers Substrate Link (could be any exisiting technology)

22 Roadmap Nov. Research PlanetLab Private PlanetLab Public PlanetLab Deploy(1 st Phase) CoreLab: PlanetLab Enhancement + VR Deploy Federation Federate J-lab : Private PlanetLab (JGN2+SINET+ ) Public PlanetLab (Federation; Migration) Fiscal Year Network Virtualization Lab (CoE on Network Virtualization) AKARI Architecture Project 2 nd Phase Service Platform Advanced Research Center JGN2 JGN2plus New Testbed

23 Contact Information Network Virtualization / Overlay is one of the key technologies for proceeding further in defining NwGN architecture(s) Test-bed designs are crucial part of this research Net-Virtualization Research Lab Contact: nv-lab@ml.nict.go.jp 23