Designed for IT professionals looking to expand their OpenStack Networking knowledge, “Navigating OpenStack Networking” is a comprehensive and fast-paced session which provides an overview of OpenStack Networking, its history, its predecessor (Nova Networks), its components and then dives deep into the architecture, its features and plugin model and its role in building an OpenStack Cloud.
2. • OpenStack Community Member
• Work with OpenStack users deploying
OpenStack Clouds @scale
• OpenStack Networking education &
evangelization
• How to contact and follow me
v@plumgrid.com
@valealaria
About Me
2
3. OpenStack
• Controls large pools of compute, storage, and networking resources
• Managed through API & dashboard that give administrators control
and empower users to provision their own resources
4. Road to Cloud Networking
#1
DEPLOYMENT
ROADBLOCK
75
Open
Tickets
4
Months
Delay
#1
DEPLOYMENT
ENABLER
0
Open
Tickets
0
Weeks
Delay
5. 5
Production
Pilot
Proof of Concept
• Provable Isolation
• Performance & Scale
• High Availability
• Extensibility
• Hardened Code
• Operational Tools
Choose the Right Architecture
7. • Networking functionality embedded within Nova
(Compute)
• Development lessen after introduction of Neutron
• Still no clear migration path from nova-networks to
Neutron
Where it all started: Nova-networks
8. • VM interfaces are bridged - Ok for “full-trust” or single-tenant
• No multi-tenancy, L2 isolation, overlapping IP address spaces support
• L3 first-hop routing is either provided by physical networking devices (flat model) or
by OpenStack L3 Service (flat-DHCP model)
“flat” networking model (nova-networks)
8
9. • VLAN/tenant network to provide multi-tenancy, L2 isolation, overlapping IP Address
spaces support
• Configuration of VLAN via Neutron where available
• L3 first-hop routing is either provided by physical networking devices or by
OpenStack L3 Service
“VLAN-based” networking model
(nova-networks/Neutron)
9
10. • A staggering 24% of production deployments still use
nova-networks
• Looking for a clear migration path and simplification
From nova-networks to Neutron
10
http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
11. • Started with the Folsom release
• Provide Network as a Service
• Provide Operator & Tenants ability to
create and offer rich network topologies
and configure advanced policies
• Offer a technology agnostic layer while
enabling vendor extensions
• Support for advanced services
Why Neutron?
Compute Storage
Network
12. • REST APIs to manage network connections for
resources managed by other OpenStack Services (e.g.
Nova)
• Technology Agnostic (framework based on “plug-ins”)
• Multi-tenancy: Isolation, Abstraction, full control over
virtual networks
• Modular Design: API specifies service, vendor provides
its implementation. Extensions for vendor-specific
features.
What is Neutron?
12
15. What Neutron is NOT
• Neutron does NOT implement the networks, but rather
is the front-end to the component that does create and
implement the rich network functionalities
– When integrated with an SDN solution, it will “pass through”
OpenStack Networking API calls to the SDN Controller. The SDN
solution will then “build the actual networks”.
– When integrated with OVS and a Network node solution*….
*this is what many people call “running Neutron” (inaccurately)
16. What can users do with Neutron?
Create multi-tenant
networks with private IP
space
Connect workloads to
each network
Interconnect networks
with routers
Provide external
connectivity (e.g.
Internet) to workloads
17. • Multi-tenancy achieved by “overlaying” MAC-in-IP ‘Tunnels’ onto the physical switch
fabric
• Encapsulation header convey tenant network ID for isolation and overlapping IP
Address
• Software layers to implement routing / switching operations within and across tenant
networks
“overlay-based” networking model (Neutron only)
17
22. Neutron Reference Implementation (2)
Neutron
ML2/OVS
plugin
VM
Network Nodes
VM VM
VM
VM VM VM
VM VM
VM VM VM
VM VM
VM
VMVM VM
Nova Glance Swift Cinde
r
L3 Agent
FWaaS
Agent
LBaaS
Agent
Agent
Agent
Agent
Agent
Agent
Agent
DHCP
Agent
Services
Neutron
Framework
Placement of these
components is critical;
They are in data path
and become bottlenecks
Advanced Services run
on dedicated nodes.
Limited HA.
Creation of new tenants
requires careful sizing of
components to maintain
performance level
VM traffic flow can be handled in
kernel, in local user space or in
network nodes with different
performance level
24. Neutron
Plugin
VM
Tenant Networks
Distributed Data Plane
Controller
VM VM
VM
VM VM VM
VM VM
VM VM VM
VM VM
VM
VMVM VM
Nova Glance Swift Cinde
r
3rd party
Virtual Network Functions
Control Plane
No Traffic Bottlenecks
VM to VM optimized packet
flow due to distributed VNFs –
Eliminating bottlenecks
Scale out Performance
automatically scale out as more
servers are deployed
No Single Point of Failure
All VNF control planes are
fully redundant
Robust Control Plane
Controller Cluster is deployed
in management rack –
stronger security & optimal
performance
Agents-less Implementation (2)
27. Highly Available Networks for OpenStack
• Must Operate in Active/Active configuration
• Self Healing
• Scalable
SELF HEALING
NETWORK
CONTROLLER
• Data plane should continue to function in the event of a complete
control plane outage
• In Service Software Upgrade of new or existing Network Functions
NON-STOP
FORWARDING
• Gateways should be deployed in Active/Active mode
• No manual intervention should be required in the event of failure
ACTIVE/ACTIVE
VTEP GATEWAY
• Handled by CMS but Network layer needs to integrate seamlessly
• Network state should be recreated upon failure or migration event
• Rapid Detection and Convergence
CMS FAILURE
MODEL
INTEGRATION
1
2
3
4
PERFORMANCE
Distributed or Centralized
HW Offload
SCALE
Single or Multi-rack
Multi-cell
HIGH AVAILABILITY
CP and DP resiliency
Interaction with CMS/Compute
EXTENSIBILITY
Services portfolio growth
Competitive edge
Openstack networking started with nova-network: a very basic way of using VLANs to interconnect VMs. Very limited.