OpenStack Networking and Automation
-
Upload
adam-johnson -
Category
Technology
-
view
455 -
download
7
description
Transcript of OpenStack Networking and Automation
Adam Johnson @adjohnslideshare.com/adjohn
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
What is OpenStack?
3
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
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
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
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
8
OVS Plugin Overview
OVS Open Source Plugin
9
Overlay NetworkingGRE TunnelsUses Open vSwitch Project
Components:• Neutron OVS Agent• Neutron DHCP Agent• Neutron L3 Agent• IPTables
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
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
12
ML2 Plugin Architecture
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)
14
Example 3rd Party Plugin
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
21
Automating the Virtual Network
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.
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" } },
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
25
Create a “Stack” in CLI or Horizon
26
Automate the Physical Network
27
Cumulus Linux on White box Switches
Q&A
28
Thank YouAdam Johnson
@adjohnslideshare.com/adjohn
29