Upload
mestery
View
3.088
Download
0
Embed Size (px)
Citation preview
Networking PTLIRC: mestery
@mestery
What’s New In Kilo anda Look Toward Liberty
OpenStack Networking
Kyle Mestery
Networking L3 LeadIRC: carl_baldwin
Carl Baldwin
What Is OpenStack Neutron?
Neutron’s Mission:
To implement services and associated libraries to provide on-demand, scalable, and technology-agnostic network abstraction.
Neutron: A bit of Quantum History
● April 2011: Interested parties converge to create a common networking API for OpenStack with the moniker Quantum
● September 2012: Quantum a part of Folsom Release● October 2013: Quantum renamed to Neutron● May 2015: Neutron rankings for Kilo release
● #1 for reviews● #1 for resolved bugs● #2 for patchsets● #2 in email volume● #3 in commits● #4 in lines of code
Neutron Deployments
● According to the spring 2015 user survey results:● 76% of production installations are on Neutron vs. nova-network● OVS at 46% of production installs (up 3%)● Linuxbridge at 19% of production installs (up 4%)● nova-network production usage dropped from 30% to 24%
Neutron Kilo Release: By the Numbers
● 45 blueprints completed● 544 bugs closed● Advanced services split into separate git repositories and
release tarballs● Plugin decomposition effort started resulting in 10+
plugin/driver decomposition efforts
A Plethora of Drivers and Plugins in Kilo
● Plugins● -------● bigswitch● brocade● cisco● embrane● hyperv● ibm● metaplugin● ml2● midonet● nec● nuage● oneconvergence● opencontrail● plumgrid● sriovnicagent● vmware
● ML2 Drivers● -----------● arista● brocade● cisco apic● cisco n1kv● cisco ncs● cisco nexus● cisco ucsm/● freescale● hyperv● ibm● l2pop● linuxbridge● mech_nuage● mlnx● ovsvapp● opendaylight● openvswitch● ofagent● sriov
● Out of Tree● -----------● Dragonflow● Octavia● networking-bgpvpn● networking-cisco● networking-l2gw● networking-midonet● networking-odl● networking-ofagent● networking-ovn● networking-sfc● VMware NSX
● Service Plugins● ---------------● A10 LBaaS● Brocade LBaaS● Freescale FWaaS● Cisco FWaaS● Cisco VPNaaS● Freeswan VPNaaS● HA Proxy LBaaS● iptables FWaaS● KEMP Technologies
LBaaS● Citrix Netscaler
LBaaS● Radware LBaaS● StrongSwan VPNaaS● Varmour FWaaS● Vyatta FWaaS● Vyatta VPNaaS
Plugin Decomposition
● Addresses pain points: review time, iteration speed, easier to use vendor specific modules
● Move to thin in-tree plugins and drivers, with plugin and driver functionality maintained outside of Neutron
● Allows for fast iteration for both core Neutron as well as plugins and drivers
Advanced Services Split
● Migrate out LBaaS, VPNaaS, and FWaaS into separate git repositories
● Allow operators the flexibility of running the services they want to offer their tenants
● Allow the services teams the chance to iterate quickly outside the scope of core neutron
● Reduce gate testing complexity● Optimize core parts of Neutron into a library
Testing
● Full-stack testing● Functional testing of OVS, LB, DHCP and metadata
agents● Retargetable functional tests
Agent Refactoring
● L2 Agent● Scalability● Agent functional testing● RPC improvements● OVSDB monitoring improvements
● L3 Agent● Scalability● Paying down technical debt● Abstracting out service agents
● DHCP Agent● Scalability● Restart improvements● Load based scheduling● Dead agent rescheduling● Functional Tests
Speed and Reliability Improvements
● Agent Child Process Status: Monitors agents and restarts them when they exit
● Rootwrap Daemon Mode: High performance access to root for commands run by Neutron agents
IPv6
● IPv6 networks are well-supported● No distributed routing for IPv6● No floating IPs for IPv6
● Creates a bit of a problem for “bring your own address”
Subnet Pools
● Solution to “bring your own addresses”● Manages allocation of addresses to tenants● Prevents duplication of addresses
Neutron Liberty Release: By the Numbers
● 35 blueprints targeted● 522 bugs targeted● Plugin decomposition effort continuing resulting in most
drivers and plugins being out of tree now
Neutron Stadium
● In accordance with the “Big Tent” OpenStack governance model, Neutron has also changed its governance model
● Allowing plugin backends to re-enter Neutron via the Stadium as their own gerrit repositories
● Growing the ecosystem under Neutron as a platform
Neutron Governance Changes
● New Lieutenant Model allows scaling core reviewers● New process for defining work (Request For
Enhancement or RFE) allows for streamlining the way work is proposed
Plugin Decomposition: Phase 2
● Phase 1 completed during Kilo● Phase 2 will completely remove all third-party code from
the main Neutron repository● Split out the reference implementation plugin into it’s own
repository● Advanced services decomposition as well● With governance changes, most repositories are now
being added into the Neutron Stadium
Neutron and nova-network
● Lots of time spent cross pollinating between Neutron and Nova teams● Many shared sessions in Vancouver● PTL sync points
● Neutron has supported the same deployment models as nova-network for many years● These are documented now
● Installation guide removed references to nova-network● New installs are now pointed to Neutron at installation time
● Neutron part of tag “starter-kit:compute”● https://review.openstack.org/#/c/196438/
DefCore and Networking
● DefCore taking on networking this cycle● Neutron will be the networking choice for DefCore
Neutron QoS
● Liberty focus is to enable bandwidth limiting● We will also layout the QoS models for future API and
model extensions introducing additional QoS concepts● QoS policies apply either per-port or per-network● Feature branch entered merge queue to master moments
ago!
Neutron LBaaS V2
● Support for Layer-7 switching (e.g. content based routing)● Support Octavia as the default reference implementation
● Service-VM based implementation using haproxy
Flavor Framework
● Way for operators to offer network services to their clients● Allows separation of driver functionality and configuration
from consumers of services● Operators can configure additional vendor features in an
end-user agnostic way
NFV Work
● Working with the NFV sub-team in OpenStack to integrate features relevant in this space
● More seamlessly connect hardware and neutron L2 segments (e.g. with Ironic)
● Unaddressed port (e.g. port without an l3-address and subnet attachment)
● Trunk ports to virtual machines
Role Based Access Controlfor Networks
● Currently, the shared network concept is not granular● This work will allow for a more granular approach and
allow tenants to share network resources with other tenants
● Allows an operator to define a network with limited access, but also covers the case where operators pre-create networks for tenants to connect to
Pluggable IPAM
● Create a pluggable IPAM system inside of Neutron● Allows the use of third-party and vendor IPAM system● Separates IPAM from Neutron core DB model● Liberty
● Reference implementation available as alternative● Enables third-party systems
● Mitaka● Migration provided to new reference● Old reference will be removed
Prefix Delegation
● Assignment of tenant IPv6 subnets from PD server● Alternative to IPAM for IPv6● Handles the routing next hop
DNS Names
● DNS name set on a port● It will be used for local DNS lookups with dnsmasq● In Mitaka, it can be given to an external DNS system
Address Scopes
● Subnet pools are assigned to a scope● No Duplicate addresses● Routing will not traverse scopes without NAT● No NAT for routing in the same scope, even “externally”
Routed Networks
● Bound the L2 domain● e.g. route to the top-of-rack
● Not solved by overlays● For large shared and external networks● Both “static” and “dynamic” routing● Schedule instances where IPs are available● Neutron API and model changes are likely
BGP Announcements
● Neutron to speak BGP to the datacenter● Next hop for subnets in the same address scope
● Floating IPs● Tenant networks
Service Function Chaining
● The idea is simple:● Service VMs need to be attached at points in the network● Traffic needs to be steered into these ports
● Create a traffic steering model for chaining which uses Neutron ports
● Work is being done in a Neutron Stadium project● networking-sfc project● “release:independent”● Expect a release later this fall
Container Networking in OpenStack
● Container networking and VM networking working in harmony: Enter Kuryr
● Kuryr is a generic Docker remote driver which connects containers to Neutron APIs● Provides containerized images of common Neutron plugins● Works as a translator between the Container Network Model and the
Neutron API● A small snippet of code for “plugging” containers in is required
● Focus is to satisfy Magnum project’s networking requirements for containers
● Being developed in Neutron stadium!
OVN
● OVN is Open Source virtual networking for Open vSwitch● Provides L2/L3 virtual networking● SGs● L2/L3/L4 ACLs● Multiple tunnel overlays (STT and Geneve)● ToR and software-based logical to physical gateways
● Code is being developed in Neutron Stadium!● OVN itself in OVS repo● Neutron plugin in networking-ovn repo
● How is OVN different?● No agents for simplified deployment● SGs utilize in-kernel connection tracker support● DPDK-based and HW accelerated gateways