60
From Nova Network to Neutron and Beyond: A Look at OpenStack Networking OpenStack Taipei MeetUp January 29 th , 2015

Midokura OpenStack Meetup Taipei

Embed Size (px)

Citation preview

Page 1: Midokura OpenStack Meetup Taipei

From Nova Network to Neutron and Beyond: A Look at OpenStack NetworkingOpenStack Taipei MeetUpJanuary 29th, 2015

Page 2: Midokura OpenStack Meetup Taipei

Agenda

Network Virtualization Requirements

OpenStack and the Evolution of Neutron Networking

Midokura Use Cases and Futures for NV

2

Page 3: Midokura OpenStack Meetup Taipei

3

Network VirtualizationRequirements

Page 4: Midokura OpenStack Meetup Taipei

What is Network Virtualization (NV)?

4

Taking logical (virtual) networks and services, and decoupling them from the underlying network hardware.

Well suited for highly virtualized environments.

Any Application

Virtual Networks

MidoNet Virtualization Platform

Logical L2

Existing Network Hardware

Any Cloud Management Platform

Distributed Firewall service

DistributedLoad Balancer ser

Logical L3

Distributed VPN Service

KVM, ESXi, Xen LXC

Page 5: Midokura OpenStack Meetup Taipei

Requirements for NV

5

Requirements

5

Page 6: Midokura OpenStack Meetup Taipei

Requirements for NV

6

Requirements

6

Isolated tenant networks

(virtual data center)

Page 7: Midokura OpenStack Meetup Taipei

Requirements for NV

7

Requirements

7

L3 Isolation(similar to VPC and VRF)

Page 8: Midokura OpenStack Meetup Taipei

Requirements for NV

8

Requirements

8

Fault-tolerant devices and links

Redundant, optimized, and fault tolerant paths to to/from external networks (e.g. via eBGP)

Page 9: Midokura OpenStack Meetup Taipei

Requirements for NV

99

Fault-tolerant devices and links

Fault tolerant devices and links

Page 10: Midokura OpenStack Meetup Taipei

Requirements for NV

10

Device-agnostic networking services:• Load Balancing• Firewalls• Stateful NAT• VPN

Networks and services must be fault tolerant and scalable

Page 11: Midokura OpenStack Meetup Taipei

Requirements for NV

11

Single pane of glass to manage it all.

Page 12: Midokura OpenStack Meetup Taipei

Bonus Requirements for NV

12

Integration with cloud or virtualization management systems.

Optimize network by exploiting management configuration.

Single virtual hop for networking services

Fully distributed control plane (ARP, DHCP, ICMP)

Page 13: Midokura OpenStack Meetup Taipei

Checklist for Network Virtualization

13

Multi-tenancy Scalable, fault-tolerant

devices (or device-agnostic network services).

L2 isolation L3 routing isolation

• VPC• Like VRF (virtual routing

and fwd-ing) Scalable gateways Scalable control plane

• ARP, DHCP, ICMP Floating/Elastic Ips

Stateful NAT• Port masquerading• DNAT

ACLs Stateful (L4) Firewalls

• Security Groups Load Balancing with health checks Single Pane of Glass (API, CLI, GUI) Integration with management

platforms• OpenStack, CloudStack• vSphere, RHEV, System Center

Decoupled from Physical Network

Page 14: Midokura OpenStack Meetup Taipei

Evolution of Network Virtualization

14

INNOVATION IN NETWORKING AGILITY

VLAN configured on physical switches

• Static• Manual• Complex• Tenant state

maintained in physical network

Manual End-to-End

VLAN APPROACH

14

Page 15: Midokura OpenStack Meetup Taipei

Using VLANs for NV

15

Multi-tenancy Scalable, fault-tolerant

devices (or device-agnostic network services).

L2 isolation L3 routing isolation

• VPC• Like VRF (virtual routing

and fwd-ing) Scalable gateways Scalable control plane

• ARP, DHCP, ICMP Floating/Elastic IPs

Stateful NAT• Port masquerading• DNAT

ACLs Stateful (L4) Firewalls

• Security Groups Load Balancing with health checks Single Pane of Glass (API, CLI, GUI) Integration with management

platforms• OpenStack, CloudStack• vSphere, RHEV, System Center

Decoupled from Physical Network

Page 16: Midokura OpenStack Meetup Taipei

Evolution of Network Virtualization

16

INNOVATION IN NETWORKING AGILITY

Reactive End-to-End

Requires programming of flows

• Limited scalability• Hard to manage• Impact to

performance • Still requires tenant

state in physical network

OPENFLOWREACTIVE APPOACH

VLAN configured on physical switches

• Static• Manual• Complex• Tenant state

maintained in physical network

Manual End-to-End

VLAN APPROACH

16

Page 17: Midokura OpenStack Meetup Taipei

What is OpenFlow?

17

A communication protocol that gives access to the forwarding plane of a network switch over the network.

Page 18: Midokura OpenStack Meetup Taipei

What is OpenFlow?

18

A centralized remote controller decides the path of packets through the switches

Page 19: Midokura OpenStack Meetup Taipei

Using OpenFlow for NV

19

Multi-tenancy Scalable, fault-tolerant

devices (or device-agnostic network services).

L2 isolation△ L3 routing isolation

• VPC• Like VRF (virtual routing

and fwd-ing) Scalable gateways Scalable control plane

• ARP, DHCP, ICMP Floating/Elastic IPs

Stateful NAT• Port masquerading• DNAT

ACLs Stateful (L4) Firewalls

• Security Groups Load Balancing with health checks△ Single Pane of Glass (API, CLI, GUI)△ Integration with management

platforms• OpenStack, CloudStack• vSphere, RHEV, System Center

Decoupled from Physical Network

Page 20: Midokura OpenStack Meetup Taipei

Evolution of Network Virtualization

20

Virtual Network Overlays

Decoupling hardware and software• Cloud-ready agility• Unlimited scalability• Open, standards-based• No impact to physical

network

PROACTIVE SOFTWARE OVERLAY

INNOVATION IN NETWORKING AGILITY

Reactive End-to-End

Requires programming of flows

• Limited scalability• Hard to manage• Impact to

performance • Still requires tenant

state in physical network

OPENFLOWREACTIVE APPOACH

VLAN configured on physical switches

• Static• Manual• Complex• Tenant state

maintained in physical network

Manual End-to-End

VLAN APPROACH

20

Page 21: Midokura OpenStack Meetup Taipei

21

How do overlays achieve real network

virtualization?

Page 22: Midokura OpenStack Meetup Taipei

22

Encapsulation and TunnelingProvides isolation

Page 23: Midokura OpenStack Meetup Taipei

23

Stateless core. Stateful edge.

Page 24: Midokura OpenStack Meetup Taipei

24

Network processing at the edge

Decoupled from the physical network

Page 25: Midokura OpenStack Meetup Taipei

25

Virtual network changes don’t affect the physical network

Page 26: Midokura OpenStack Meetup Taipei

26

Single virtual hop network services avoid “traffic

trombones”

Page 27: Midokura OpenStack Meetup Taipei

27

Centralized state and control for maximum agility

Page 28: Midokura OpenStack Meetup Taipei

28

Scalable, fault tolerant gateways to external networks

Page 29: Midokura OpenStack Meetup Taipei

Using Overlays for NV

29

Multi-tenancy Scalable, fault-tolerant

devices (or device-agnostic network services).

L2 isolation L3 routing isolation

• VPC• Like VRF (virtual routing

and fwd-ing) Scalable Gateways Scalable control plane

• ARP, DHCP, ICMP Floating/Elastic IPs

Stateful NAT• Port masquerading• DNAT

ACLs Stateful (L4) Firewalls

• Security Groups Load Balancing with health checks Single Pane of Glass (API, CLI, GUI) Integration with management

platforms• OpenStack, CloudStack• vSphere, RHEV, System Center

Decoupled from Physical Network

Page 30: Midokura OpenStack Meetup Taipei

30

Sounds great, but when will it be a

reality?

Page 31: Midokura OpenStack Meetup Taipei

Network Virtualization Overlays Today

31

Page 32: Midokura OpenStack Meetup Taipei

OpenStack

32

Page 33: Midokura OpenStack Meetup Taipei

What is OpenStack?

33

Page 34: Midokura OpenStack Meetup Taipei

OpenStack Releases

34

Release schedule: time-based scheme with major release ~ every 6 monthsCodenames are alphabetical:

• Austin: The first design summit took place in Austin, TX• Bexar: The second design summit took place in San Antonio, TX (Bexar county).• Cactus: Cactus is a city in Texas• Diablo: Diablo is a city in the bay area near Santa Clara, CA• Essex: Essex is a city near Boston, MA• Folsom: Folsom is a city near San Francisco, CA• Grizzly: Grizzly is an element of the state flag of California (design summit takes

place in San Diego, CA)• Havana: Havana is an unincorporated community in Oregon• Icehouse: Ice House is a street in Hong Kong• Juno: Juno is a locality in Georgia• Kilo: Paris (Sèvres, actually, but that's close enough) is home to the Kilogram,

the only remaining SI unit tied to an artifact

Page 35: Midokura OpenStack Meetup Taipei

35

Before Neutron: Nova Networking

• Nova-Networking was the only option in OpenStack prior to Quantum/Neutron• Original method from A release• No IPv6 in first release but eventually introduced• Still available today as an alternative to Neutron, but will be phased out

Options Available within nova-networking initially:• Only Flat• Flat DHCP

Limitations• No flexibility with topologies (no 3-tier)• Tenants can’t create/manage L3 Routers• Scaling limitations (L2 domain)• No 3rd party vendors supported• Complex HA model

Page 36: Midokura OpenStack Meetup Taipei

36

Nova-network slightly evolves

Introduced VLAN DHCP mode Improvements:• L2 Isolation – each project gets a

VLAN assigned to it

Limitations• Need to pre-configure VLANs on

physical network• Scaling Limitations - VLANs• No L3

• No 3-tier topologies• No 3rd party vendors

Page 37: Midokura OpenStack Meetup Taipei

37

Nova-network slightly evolves

C & D Releases had two general categories:• Flat Networking• VLAN Networking

Limitations• Need to pre-configure VLANs on physical network• Scaling Limitations - VLANs• No L3• No 3-tier topologies• No 3rd party vendors

Page 38: Midokura OpenStack Meetup Taipei

Quantum

38

OpenStack Networking branches out of the Nova project

• Tech Preview of Quantum appeared in D release

• Brought ability to have a multi-tiered network, with isolated network segments for various applications or customers

• Quantum-server allowed for Python daemon to expose the OpenStack Networking API and passes requests to 3rd party plugins

• Officially released in Folsom Release

Page 39: Midokura OpenStack Meetup Taipei

Introducing Neutron

39

• Pluggable Architecture• Standard API• Many choices

Plugins Available

• MidoNet• OVS Plugin• Linux Bridges• Flat DHCP• VLAN DHCP• ML2

• Supports Overlay Technology• More Services (LBaaS, VPNaaS)

• Flexible network topologies

• NSX• Plumgrid• Nuage• Contrail• Ryu

• Name Change from Quantum to Neutron was announced in April 2013

• Legal Agreement to phase out code name “Quantum” due to trademark of Quantum Corporation

OpenStack Networking as a First Class Service

Page 40: Midokura OpenStack Meetup Taipei

Evolution of Neutron

40

Release Name Release Date Included Components

Austin 21 October 2010 Nova, Swift

Bexar 3 February 2011 Nova, Glance, Swift

Cactus 15 April 2011 Nova, Glance, Swift

Diablo 22 September 2011 Nova, Glance, Swift

Essex 5 April 2012 Nova, Glance, Swift, Horizon, Keystone

Folsom 27 September 2012 Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder

Grizzly 4 April 2013 Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder

Havana 17 October 2013 Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder

Icehouse April 2014 Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder

Page 41: Midokura OpenStack Meetup Taipei

Latest Neutron Features

41

Havana Release Brought:• LBaaS: shipped an updated API and HAProxy driver support• VPNaaS: VPN API supports IPSec and L3 agent ships with an

OpenSwan driver• FWaaS: enables tenant to configure security at the edge via the

firewall API and on the VIF via the security group API• New plug-in Modular Layer 2 (ML2): ML2 plugin supports local, flat,

VLAN, GRE and VXLAN network types via a type drivers and different mechanism drivers

Icehouse Release:• New vendor plugins, LBaaS drivers and VPNaaS drivers• OVS plugin and Linux Bridge plugin are deprecated: The ML2 plugin

combines OVS and Linux Bridge support into one plugin• Neutron team has extended support for legacy Quantum configuration

file options for one more release

Page 42: Midokura OpenStack Meetup Taipei

Upcoming Neutron Features

42

Expectations for Juno:

• Provide Distributed Virtual Routing (DVR) functionality: Define API to create and deploy DVRs to improve the performance

• Group-based Policy Abstractions for Neutron: API extensions for easier consumption of the networking resources by separate organizations and management systems

• IPv6 advancements: • Add RADVD to namespace to handle RAs, • Stateful and stateless DHCP for IPv6

• LBaaS new API driver and object model improvement for complex cases

• Quotas extension support in MidoNet plugin

• Incubator system: • Instead of only using the summit for developing new features,

features can be developed and gestate over time

Page 43: Midokura OpenStack Meetup Taipei

43

MidoNet Overview

Page 44: Midokura OpenStack Meetup Taipei

44

MidoNet Network Virtualization Platform

Logical L2 Switching - L2 isolation and path optimization with distributed virtual switchingInterconnect with VLAN enabled network via L2 Gateway

Logical L3 Routing – L3 isolation and routing between virtual networksNo need to exit the software container - no hardware required

Distributed Firewall – Provides ACLs, high performance kernel integrated firewall via a flexible rule chain system

Logical Layer 4 Load Balancer – Provides application load balancing in software form - no need for hardware based firewalls

VxLAN/GRE – Provides VxLAN and GRE tunnelingProvides L2 connectivity across L3 transport. This is useful when L2 fabric doesn’t reach all the way from the racks hosting the VMs to the physical L2 segment of interest.

MidoNet/Neutron API– Alignment with OpenStack Neutron’s API for integration into compatible cloud management software

v

Any Application

MidoNet Network Virtualization Platform

Any Network Hardware

OpenStack/Cloud Management System

Distributed Firewall

Layer 4Load Balancer VxLAN/GRE

Any Hypervisor

Logical L2 Logical L3 NAT

MidoNet/

Neutron API

NAT – Provides Dynamic NAT, Port masquerading

Page 45: Midokura OpenStack Meetup Taipei

OpenStack Integration

5

Easy integration with OpenStack:MidoNet provides a plugin for Neutron.

MidoNet Plugin

Page 46: Midokura OpenStack Meetup Taipei

Architecture Overview

Page 47: Midokura OpenStack Meetup Taipei

Do it BiggerDo it Faster

Va

lue Agility

Provide rapid provisioning of isolated

network infrastructure for labs and devops.

Logical Network Provisioning

Automated Provisioning

Isolated Sandboxes

ControlNetwork admins can

better secure, control & view network traffic.

Single Pane of Glass OpsTools

Enhanced Security

Enable Compliance

Do it Better

IaaS Cloud

Build multi-tenant clouds with visibility

into usage.

Tenant Control

Metering

AutomatedSelf Service

PerformanceImprove network

performance using edge overlay & complementary

technologies.

Single Hop Virtual Networking

VXLAN Hardware Gateway

Massive performance

with 40Gb Support

ScaleAdd virtual network infra

& services simply & resiliently without

hardware & bottlenecks.

Distributed Logical

NetworkingFW, LB, L2/3, NAT

Limitless “VLANs”

Scale out L3 Gateway

Bridge legacy VLANs

IPv6

Solution for OpenStack NetworkingUse MN to overcome

limitations of Neutron for OpenStack users.

Replaces OVS Plugin

Use Cases

Page 48: Midokura OpenStack Meetup Taipei

48

So what’s next for Network

Virtualization?

Page 49: Midokura OpenStack Meetup Taipei

49

Get more out of the physical network.

Page 50: Midokura OpenStack Meetup Taipei

50

Network Virtualization decouples the logical

network from the physical network.

Page 51: Midokura OpenStack Meetup Taipei

NVOs can’t ignore the physical network

51

Dynamic changes to logical network are not dependent on the physical network configuration.

Sharing state to and from the physical network can be supplementary.

- Monitoring- Traffic Engineering

Page 52: Midokura OpenStack Meetup Taipei

52

Get more intelligence out of your network

Page 53: Midokura OpenStack Meetup Taipei

NVOs provide a wealth of information

53

NVOs centralize information on your network

We can start taking advantage of this information

- Security- Compliance- Optimizing Networks

Page 54: Midokura OpenStack Meetup Taipei

54

Bridge physical and virtual networks more efficiently

Page 55: Midokura OpenStack Meetup Taipei

Midokura VTEP Solution

55

MidoNet MidoNet

Virt

ual

Any Cloud Management Platform

MidoNet Network State Database

VM VM VM VM VM VM

IP Fabric

Server Storage ServicesP

hysi

cal

VM VM

VTEP

OVSDBc

VxLAN Tunnel

Physical Connection

OVSDB

TCP/IP

Key

OVSDBs

Page 56: Midokura OpenStack Meetup Taipei

56

Break through performance barriers of software networking

Page 57: Midokura OpenStack Meetup Taipei

40Gb VxLAN Offloading: virtualized environments require high throughput infrastructure

• Integration with Mellanox provides 40 Gbps saturation

• VxLAN offloading improves CPU utilization levels• Scale with performance through HW interconnect• Increase throughput with offloading where no

offloading would otherwise have flat results• High bandwidth can now be achieved in software

Performance

Page 58: Midokura OpenStack Meetup Taipei

58

Q&A

Page 60: Midokura OpenStack Meetup Taipei

Thank You

60