OpenStack Networking and Automation

29
Adam Johnson @adjohn slideshare.com/adjohn OpenStack Networking and Automation

description

Overview of OpenStack nova-networking evolution towards Neutron. Architecture overview of OVS plugin, ML2, and MidoNet Overlay product. Overview and example of Heat templates, along with automation of physical switches using Cumulus

Transcript of OpenStack Networking and Automation

Page 1: OpenStack Networking and Automation

Adam Johnson @adjohnslideshare.com/adjohn

OpenStack Networking and Automation

Page 2: OpenStack Networking and Automation

Outline

2

• OpenStack Intro• Network Virtualization Evolution• OS Networking History• OVS Overview• ML2• MidoNet Overview• Automate Virtual Network with Heat• Automate Physical Networks• Q&A

Page 3: OpenStack Networking and Automation

What is OpenStack?

3

Page 4: OpenStack Networking and Automation

Evolution of Network Virtualization

4

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

4

Page 5: OpenStack Networking and Automation

5

Before Neutron: Nova NetworkingNova-Networking was the only networking option in OpenStack prior to Quantum/Neutron Still available today as an alternative to Neutron, but will likely 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 6: OpenStack Networking and Automation

6

Nova-network slightly evolvesIntroduced 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 7: OpenStack Networking and Automation

Introducing Neutron

7

OpenStack Networking as a first class Service

• Pluggable Architecture• Standard API• Many choices

Plugins Available• OVS Plugin• Linux Bridges• Flat DHCP• VLAN DHCP• ML2• MidoNet• NSX• PlumGRID• Nuage• Contrail• Ryu• …

• Supports Overlay Technology• More Services (LBaaS, VPNaaS)• Flexible network topologies

Page 8: OpenStack Networking and Automation

8

OVS Plugin Overview

Page 9: OpenStack Networking and Automation

OVS Open Source Plugin

9

Overlay NetworkingGRE TunnelsUses Open vSwitch Project

Components:• Neutron OVS Agent• Neutron DHCP Agent• Neutron L3 Agent• IPTables

Page 10: OpenStack Networking and Automation

OVS Open Source Plugin

10

OVS Agent - receives tunnel/flow setup info from OVS Plugin, and programs Open vSwitch to setup tunnels and send traffic through the tunnel

DHCP Agent - Sets up dnsmasq in a namespace per network/subnet and enters mac/ip into dhcp lease file

L3 Agent – OVS Plugin orchestrates to set up IPTables, Routing, NAT tables

Page 11: OpenStack Networking and Automation

Challenges with OVS Plugin

11

Neutron Network Node is a SPOFNeed to use corosync, etc for active/standby failover.

Challenging at ScaleSince there’s a single network node, this becomes a bottleneck fairly quickly.

Inefficient NetworkingIPTables, L3 Agent, multiple hops for single flow are causing unnecessary traffic and added latency on your physical network

Page 12: OpenStack Networking and Automation

12

ML2 Plugin Architecture

Page 13: OpenStack Networking and Automation

Modular Layer 2 (ML2)

13

Mix and Match Networking PluginsPreviously, plugins were monolithic

Driver ModelImplement network types and mechanismsMultiple mechanisms can be used simultaneously to access different ports across the network.

LimitationsNot everything is pluggable yet (started with just L2)

Page 14: OpenStack Networking and Automation

14

Example 3rd Party Plugin

Page 15: OpenStack Networking and Automation

15

v

Any Application

MidoNet Network Virtualization Platform

Logical L2

Any Network Hardware

Any Cloud Management Platform

LogicalFirewall

Logical Layer 4Load Balancer

Logical L3

LogicalNAT

Any Hypervisor

Logical Switching – Layer 2 over Layer 3, decoupled from the physical network

Logical Routing – Routing between virtual networks without exiting the software container

Logical Firewall – Distributed Firewall, Kernel Integrated, High Performance

Logical Layer 4 Load Balancer – Application Load Balancing in software

Logical Network Address Translation – Powerful chains/rules for more control

MidoNet API – RESTful API for integration into any Cloud Management Platform

MidoNet Network Virtualization Platform

Page 16: OpenStack Networking and Automation
Page 17: OpenStack Networking and Automation
Page 18: OpenStack Networking and Automation
Page 19: OpenStack Networking and Automation
Page 20: OpenStack Networking and Automation
Page 21: OpenStack Networking and Automation

21

Automating the Virtual Network

Page 22: OpenStack Networking and Automation

Heat Orchestration

22

Introduced in Grizzly, usable in Havana

What is it?Allows you to pre-define a set of compute, network, storage requirements to provide a specific service and deploy it with ease.

Compatible with CloudFormations

How it works:• Template describes the infrastructure of a cloud app• Can be version controlled, diffed• Human Readable• Can Describe

• Servers, FIPs, Volumes, Sec Groups, Users, Networks, etc• Can Specify Relationships: volume connects to server• Heat turns template into API calls• Integrates easily with config management like Chef, Puppet, etc.

Page 23: OpenStack Networking and Automation

23

{ "AWSTemplateFormatVersion" : "2010-09-09", "Description" : "Sample Heat template that spins up multiple instances and a private network (JSON)", "Resources" : { "heat_network_01" : { "Type" : "OS::Neutron::Net", "Properties" : { "name" : "heat-network-01" } }, "heat_subnet_01" : { "Type" : "OS::Neutron::Subnet", "Properties" : { "name" : "heat-subnet-01", "cidr" : "10.10.10.0/24", "dns_nameservers" : ["172.16.1.11", "172.16.1.6"], "enable_dhcp" : "True", "gateway_ip" : "10.10.10.254", "network_id" : { "Ref" : "heat_network_01" } } },

Example Snippet (Cloud Formation Template) "heat_router_01" : { "Type" : "OS::Neutron::Router", "Properties" : { "admin_state_up" : "True", "name" : "heat-router-01" } },

Page 24: OpenStack Networking and Automation

24

HOT (Heat Orchestration Template) Example

heat_template_version: 2013-05-23

description: Simple template to deploy a single compute instance

resources: my_instance: type: OS::Nova::Server properties: key_name: my_key image: F18-x86_64-cfntools flavor: m1.small

Page 25: OpenStack Networking and Automation

25

Create a “Stack” in CLI or Horizon

Page 26: OpenStack Networking and Automation

26

Automate the Physical Network

Page 27: OpenStack Networking and Automation

27

Cumulus Linux on White box Switches

Page 28: OpenStack Networking and Automation

Q&A

28

Page 29: OpenStack Networking and Automation

Thank YouAdam Johnson

@adjohnslideshare.com/adjohn

29