• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Quantum diablo summary
 

Quantum diablo summary

on

  • 55,400 views

Slides from OpenStack Design Summit presentation on the Quantum, a virtual network service.

Slides from OpenStack Design Summit presentation on the Quantum, a virtual network service.

Statistics

Views

Total Views
55,400
Views on SlideShare
12,658
Embed Views
42,742

Actions

Likes
19
Downloads
828
Comments
0

26 Embeds 42,742

http://openvswitch.org 42355
http://www.ibenit.com 151
http://www.hillos.org 47
http://translate.googleusercontent.com 36
http://localhost:8888 35
http://webcache.googleusercontent.com 25
http://openvswitch.com 24
http://rm-fr.kr 20
http://10.34.225.20 14
http://www.openvswitch.org 7
http://paper.li 4
http://twitter.com 3
http://honyaku.yahoofs.jp 3
http://joearnold.com 2
http://localhost 2
http://172.17.240.61:8888 2
url_unknown 2
http://openvswitch.org.sixxs.org 2
http://posterous.com 1
http://translate.yandex.net 1
http://cache.baiducontent.com 1
http://207.46.192.232 1
https://twitter.com 1
https://www.google.com 1
http://baidu.proxywhy.com 1
http://xianguo.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Quantum diablo summary Quantum diablo summary Presentation Transcript

    • Openstack Quantum:Virtual Networks for OpenStack
      Dan Wendlandt – dan@nicira.com
    • Outline
      What?
      Why?
      How?
    • What is Quantum?
      Astandalone Openstackservice
      Provides network connectivity between a set of network “interfaces” from other service (e.g., vNICs from compute service, interfaces on a load-balancer service).
      Exposes API of logical abstractions for describing network connectivity + policy between interfaces.
      Uses a “plug-in” architecture, so multiple technologies can implement the logical abstractions.
      Provides a “building block” for sophisticated cloud network topologies.
    • What is Quantum NOT?
      Something that provides all network-related processing behavior.
      Initial focus is on connectivity.
      Other advanced services like load-balancers, firewalls, etc can “plug” into a network offered by Quantum.
      IP address management (see next talk on IPAM)
      Orchestration of multiple network-related building blocks to provide higher-level abstractions to tenants (see talk on Donabe)
    • Example Architecture: Single Service
      Openstack Dashboard
      Tenant API
      Tenant API
      Quantum Service
      Nova Service
      Admin API
      nova-api
      nova-scheduler
      Quantum Plugin
      Internal nova
      Communication
      XenServer #1
      Hypervisor
      nova-compute
      vswitch
      Internal Plugin
      Communication
    • Example Architecture: Two Services
      Tenant API
      Quantum Service
      Network Edge:
      Point at which a service “plugs” into the network.
      Quantum Plugin
      Internal Plugin
      Communication
      vswitch
      vswitch
      physical
      switch
      VM
      VM
      VM
      VM
      FW
      FW
      FW
      Firewall Service
      Compute Service
      Tenant API
      Tenant API
    • Virtual Network Abstractions (1)
      Services (e.g., nova, atlas) expose interface-IDs via their own tenant APIs to represent any device from that service that can be “plugged” into a virtual network.
      Example: nova.foo.com/<tenant-id>/server/<server-id>/eth0
      Tenants use Quantum API to create networks, get back UUID:
      Example: quantum.foo.com/<tenant-id>/network/<network-id>
      Tenants can create ports on a network, get a UUID, and associate config with those ports (APIs for advanced port config are TBD, initially ports give L2 connectivity):
      Example: quantum.foo.com/<tenant-id>/network/<network-id>/port/<port-id>
      Tenants can “plug” an interface into a port by setting the attachment of a port to be the appropriate interface-id.
      Example: set quantum.foo.com/<tenant-id>/network/<network-id>/port/<port-id>/attach to value “nova.foo.com/<tenant-id>/server/<server-id>/eth0” .
    • Virtual Network Abstractions (2)
      Note: At no time does the customer see details of how a network is implemented (e.g., VLANs).
      Association of interfaces with network is an explicit step.
      Plugins can expose API extensions to introduce more complex functionality (e.g., QoS). Extension support is queriable, so a customer can “discover” capabilities.
      API extensions that represent common functionality across many plug-ins can become part of the core API.
      Core API for diablo is simple, focused on connectivity. Core API will evolve.
    • Example Scenario:
      Nova i-24
      10.0.0.24
      Nova i-26
      10.0.0.26
      Nova i-22
      10.0.0.22
      Nova i-23
      10.0.0.23
      GW Instance-1
      10.0.0.1
      Private Net #2
      Private Net #1
      Tenant
      View
      Provider View
      Nova i-24
      10.0.0.24
      Nova i-26
      10.0.0.26
      Nova i-26
      10.0.0.26
      Data Center
      Network
      GW Instance-1
      10.0.0.1
      Nova i-24
      10.0.0.24
      NAT Gateway Service
      Compute Service
    • Live Demo…
    • Why Quantum?
      API gives ability to create interesting network topologies.
      Example: create multi-tier applications
      Provide way to connect interconnect multiple Openstack services (*-aaS).
      Example: Nova VM + Atlas LB on same private network.
      Open the floodgates to let anyone build services (open or closed) that plug into Openstack networks.
      Examples: VPN-aaS, firewall-aaS, IDS-aaS.
      Allows innovation plugins that overcomes common cloud networking problems
      Example: avoid VLAN limits, provide strong QoS
    • How? Quantum Design Goals
      Decoupled from nova and other services
      Communication between quantum and another service should happen via well-defined Rest API (not direct python calls, no nova RPC, not shared understanding of database schemas)
      Be able to run without nova.
      Flexible enough to support plugins for many different “network edges”:
      Bridge / Open vSwitch on Linux
      Vmware DVS / Nexus 1000V
      Physical switches
      Physical switches with VEPA / VNtag
    • How? Inside Quantum
      Plugin interface maps to “core” tenant API + admin API.
      “Network agents” running on nova hypervisor fit within this model.
      Plugin might manage just the network edge (e.g., a vswitch), or all network devices.
      Tenant API
      Admin API
      Auth (talk to Keystone)
      API Limits
      Plugin
      Communicate with external devices in a plugin-specific way to implement logical abstractions from the tenant API.
    • Edge Bindings
      Services that expose interface-IDs must tell quantum where that interface is currently “plugged” into the network.
      We call this an “edge binding”
      Impl still fuzzy: Quantum may support an admin API that allows other services to register <interface-id, interface-location> pairs with Quantum.
      Many different “types” of interface-location data:
      XenServer: VIF-UUID
      Cisco 1000v: veth0 device
      Physical Hosting: physical switch ID + port number
      Openstackdeployers must make sure all services able to “speak” a interface-location type supported by the switch.
      There will be a “default” type supported by an open source plugin (VLAN based, like nova today?)
    • Simple Plug-in Example with VLANs
      Similar to what Nova does for private networks:
      One VLAN per “network”.
      Hypervisor NIC is VLAN trunk, all switches are trunked.
      When an interface-ID is associated is associated with a network, plugin uses the edge binding to find the interface-location (a port on a vswitch) and puts that port on the correct VLAN.
    • Plans for Diablo timeframe
      “experimental” Quantum plug-in
      Plug-in Agnostic:
      Create API, including way for plugin to register extensions.
      Store “ownership” + integrate with keystone for auth.
      Implement “edge bindings” database + API.
      Plugins:
      At least one (hopefully more!) open-source plugin that anyone can use to experiment with Quantum.
      Services:
      Perform “edge bindings” integration with nova and at least one other service.
    • This is Just the Beginning….
      Our goals within Diablo time frame are well scoped.
      Quantum is a building block, not the entire solution for all networking problems.
      Goal is to make sure Quantum design for Diablo does not preclude doing things we will likely consider important in the future.
    • Many important questions remain:
      How should knowledge of the network topology and resources/capacity be used to influence workload placement decisions by the scheduler?
      What should be included in a broader set of core APIs (QoS, packet stats, ACLs, etc) in future iterations?
      Is L2 VPN (e.g., to customer site) a part of this core API, ok something the “plugs” into a virtual network?
      How to expose attributes of the physical network (e.g., redundant NICs) via the logical model?
      <Insert your question here…>