Open Source Backends for OpenStack Neutron

26
An overview of Open Source Backends for Openstack Neutron

description

An overview of the Open Source Backends for the OpenStack Neutron API. This was presented at the OpenStack Juno Summit in Atlanta, May 2014.

Transcript of Open Source Backends for OpenStack Neutron

An overview of

Open Source Backends for Openstack Neutron

Summary

● Neutron plugins recap● Neutron’s built-in solution● Open source alternatives

○ Open DayLight○ Ryu Network OS○ Open Contrail

What this talk is NOT about● Competitive analysis of open source backends

● Telling you which backend would be right for your deployment

● The holy grail of the infinitely scalable open source backend

What this talk is about● Enumerating open source alternative for Neutron

backend

● Providing an overview of such backends and how they integrated with Openstack Neutron

● Proving that Neutron’s “agents” are not the only alternative to commercial backends

Neutron plugins recap● Modular (ML2) Plugin

○ A common layer for DB management and resource allocation; transport/technology specific drivers

● Standalone Core Plugin○ Implementation of one or more interfaces to serve a particular

backend technology or platform● Both ML2 drivers or standalone plugins can either be

commercial or open-source● Both commercial and open source plugin/drivers are

required to pass integration testing

Neutron’s built-in solution● L2/L3 connectivity● IPAM● East/West routing● External gateway & floating IPs● Implemented by:

○ ML2 plugin with OVS agent mech driver○ OVS Layer-2 agent○ Layer-3 agent + DHCP agent

● Load Balancing, VPN, and firewall served by distinct “service plugins”

Neutron’s built-in solution

Neutron Server

ML2 with Open vSwitch Mechanism Driver and GRE transport

ML2 L3 base plugin

OVS Mech Driver

AMQP bus

RPC RPC

REST

OVS Agent

OVS Agent

OVS Agent

LB Agent

L3Agent

L3Agent

LB Agent

Neutron’s built-in solution

Installation via devstacklocal.conf

○ enable_service neutron q-l3 q-agt q-svc q-dhcp q-meta

./stack.sh

Neutron’s built-in solution: limitsCareful messaging needed here.● Point to scalability limits of the L2 agent● Point to limit of the L3 agents only if the OSS backends

discussed here have viable alternatives● Neutron’s developer community is a mix of web app

developers, distributed systems experts and network programmers.○ Focus is not exclusively on networking

L2Population ML2 Driver● An overlay MechanismDriver for ML2

○ Optimized by pre-populating forwarding tables of both OVS and Linuxbridge forwarding planes to decrease broadcast traffic

○ Utilizes both VXLAN and GRE tunnels● Two main implementation details

○ Local ARP responder on each host■ Linuxbridge support in Havana, OVS support in Juno

○ Forwarding table population on each host● More information:

○ https://wiki.openstack.org/wiki/L2population

BeforeML2 L2 Population MechanismDriver

Host 1

Host 2

Host 3Host 4

Host 1

VM A

VM G VM E VM D

VM B

VM C

VM F

VM H

VM I

“VM A” wants to talk to “VM G.” “VM A” sends a broadcast packet, which is replicated to the entire tunnel mesh.

WithML2 L2 Population MechanismDriver

Host 1

Host 2

Host 3Host 4

Host 1

VM A

VM G VM E VM D

VM B

VM C

VM F

VM H

VM I

The ARP request from “VM A” for “VM G” is intercepted and answered using a pre-populated neighbor entry.

Proxy Arp

Traffic from “VM A” to “VM G” is encapsulated and sent to “Host 4” according to the bridge forwarding table entry.

Try L2Population with devstack● Setup your local.conf to use L2Population with LB

Q_PLUGIN=ml2Q_AGENT=linuxbridgeQ_SERVICE_PLUGIN_CLASSES=neutron.services.l3_router.l3_router_plugin.L3RouterPluginQ_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,linuxbridge,l2populationQ_ML2_TENANT_NETWORK_TYPE=vxlan,gre...[[post-config|/$Q_PLUGIN_CONF_FILE]][vxlan]enable_vxlan=truelocal_ip=$HOST_IPl2_population=True

● More information (including OVS setup with L2Population)○ https://wiki.openstack.org/wiki/L2population

OpenContrail● OpenContrail is an extensible networking system

covering two primary use cases:○ Cloud Networking○ Network Function Virtualization

● Consists of two components:○ OpenContrail Controller

■ Configuration, Control, and Analytics nodes○ OpenContrail vRouter

● http://opencontrail.org/

Open Contrail:Openstack integration● VM bringup with OpenContrail:

○ Nova instructs the Nova Agent on the compute node to create the VM○ Nova Agent gets network attributes from OpenContrail Plugin○ Once VM is created, Nova Agent communicates to vRouter○ vRouter configures the virtual network for the VM

Neutron with Open Contrail diagramOpenStack

Nova Contrail Neutron Plugin

Compute Node

OpenStack Nova Agent

vRouter Agent (user

space)

Configuration Node

Contrail Node

Try OpenContrail with devstack● Pull the devstack with OpenContrail support

○ git clone https://github.com/dsetia/devstack● Setup your local.conf

○ ENABLE_CONTRAIL=yes○ Q_PLUGIN=contrail○ PHYSICAL_INTERFACE=eth0

● This will enable a single node OpenContrail setup with devstack

● For more information:○ http://pedrormarques.wordpress.com/2013/11/14/using-

devstack-plus-opencontrail/

OpenDaylight● OpenDaylight is an Open Source Software Project under the Linux

Foundation with the goal of furthering the adoption of SDN○ Three pillars: Code, Acceptance, and Community

● OpenDaylight is building an evolvable SDN platform capable of handling a diverse set of use cases○ IaaS network orchestration is an important use case

● Releases:○ Hydrogen: February 2014○ Helium: Tentatively slated for September 2014○ Three release types:

■ Base, Virtualization, and Service Provider● Eclipse Public License – v 1.0 (EPL)● http://www.opendaylight.org/

Open DayLightOpenstack integration● OpenStack Neutron ML2 MechanismDriver upstreamed

in Icehouse● REST proxy, passes API calls into OpenDaylight● Utilized by any provider’s southbound in ODL

○ Examples: VTN, OVSDB Plugin, OpenDove● Solution still requires Neutron DHCP and L3 agents

○ Support for this planned for Helium release

Neutron with Open DayLight diagram

Neutron Node

Neutron Server

ML2 Plugin w/ODL Driver

Network Node

L3 Agent

OVS

DHCP Agent

Compute Node

OVS

OpenDaylight Node

ODL ServerREST API

RPCs

OpenFlow and OVSDB

Neutron API Service

OVSDB Plugin

Try OpenDaylight With devstack● Setup your local.conf

○ Q_ML2_PLUGIN_MECHANISM_DRIVERS=opendaylight○ enable_service odl-server odl-compute

● This will enable a single-node OpenDaylight devstack setup○ Additional compute nodes only need “enable_service odl-compute” set

● Checkout lib/opendaylight for more configuration options

Ryu Network OS● Ryu is a component-based SDN framework

○ Supports OpenFlow 1.0, 1.2, 1.3, 1.4, and Nicira extensions○ Apache 2.0 license○ Written in Python

● Supports a variety of protocols for managing network devices○ OpenFlow, Netconf, OF-config, SNMP

● http://osrg.github.io/ryu/

Ryu Openstack integration● Ryu is integrated into OpenStack in two ways:

○ A standalone plugin○ An ML2 MechanismDriver (ofagent)

● Multi tenant network support○ Mac address based○ VLAN○ GRE tunnel

● Ryu supports port-binding○ Ryu agent or ofagent must be running on the host

Neutron with Ryu diagram

Neutron Node

Neutron DB(network ID, key)

Neutron Server

RYU Plugin

Ryu Node

Ryu Server

Network Node

L3 Agent Ryu Agent

Compute Node

Ryu Agent OVS

OVS

Try Ryu with devstack● Setup your local.conf

○ Q_ML2_PLUGIN_MECHANISM_DRIVERS=ofagent,l2population○ Q_AGENT=ofagent○ ENABLE_TENANT_TUNNELS=True○ Q_ML2_TENANT_NETWORK_TYPE=gre○ [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]○ [agent]○ l2_population=True

● This enables a single-node ofagent setup with Ryu

● More information:○ https://github.com/osrg/ryu/wiki/OFAgent-Openstack-

IceHouse-environment-HOWTO

Summary

● Many options in the Open Source Arena for Neutron Plugins○ Innovation is ongoing in this area

● No “one size fits all”