OpenStack Networking and Automation

2,319 views

Published on

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

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,319
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
169
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide
  • Show of hands: Show of hands for who knows about OpenStack?
    Who is running OpenStack Now?
  • So what does it take to pull off Network Virtualization?
  • Cloud platform Launched in 2010 by NASA and Rackspace
    Apache License
    Has a modular architecture (codenames: Swift, Horizon, Nova, Keystone, Cinder… Neutron)
    We’ll be focusing on Neutron networking

  • VLANs require changing configuration of physical hardware
    - Runs into scaling issues at 4096 VLANs, some cheaper networking gear runs into problems at 100 vlans
    - Lose mobility
    OpenFlow proved difficult to scale, since virtual workloads are very dynamic, it required reprogramming physical boxes
    Overlays are software only, no changes made to the physical network required, fully decoupling the virtual from the physical
  • DHCP and default gateway is provided by dnsmasq(DHCP) and IPTables+routing stack for floating ips/security groups
  • Neutron is beautiful and scary at the same time
    Started out with Nova-networking, it was not flexible at all. Very rigid. Had problems
    Neutron was a re-architecture to a more modular design
    became a core project in Folsom release, we’re now on the Icehouse release.

    Now there are tons of choices in Neutron, it can be daunting.

    OVS is the most deployed plugin according to the latest user survey, so we’ll cover this one along with MidoNet (since I work for Midokura)
  • GRE Tunnels between hosts
  • HA is not available out of the box, this is something you need to get via a third party distro, or build it yourself. Proposals for the next couple of releases (Juno/K) around making the L3 agent more HA.



  • HA is not available out of the box, this is something you need to get via a third party distro, or build it yourself. Proposals for the next couple of releases (Juno/K) around making the L3 agent more HA.



  • L4 Load Balancing
  • Replacing OVS user space agent, IPTables, Neutron Server L3 Agent, and Linux Routing Stack with MidoNet Agent.
    Added Capabilities, l2-4 distributed.
  • Back to this diagram for review, many hops for east/west traffic
  • MidoNet Agent reduces complexity, adding performance and efficiency
  • L4 Load Balancing Highlight

    Many choices for plugins, happy to talk after this in more detail if you’d like
  • JSON based
    Compat with AWS CloudForms



  • New Template format will become the native format over time.
    YAML based
    Replaces previous Cloud Formations format
    Will offer more functionality over CloudFormations over time
  • Stop by our booth , I’ll post this on slideshare and tweet the link after this.

  • Stop by our booth , I’ll post this on slideshare and tweet the link after this.

  • HA is not available out of the box, this is something you need to get via a third party distro, or build it yourself. Proposals for the next couple of releases (Juno/K) around making the L3 agent more HA.



  • OpenStack Networking and Automation

    1. 1. Adam Johnson @adjohn slideshare.com/adjohn OpenStack Networking and Automation
    2. 2. Outline 1 • OpenStack Intro • Network Virtualization Evolution • OS Networking History • OVS Overview • ML2 • MidoNet Overview • Automate Virtual Network with Heat • Automate Physical Networks • Q&A
    3. 3. What is OpenStack? 2
    4. 4. Evolution of Network Virtualization 3 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 OPENFLOW REACTIVE APPOACH VLAN configured on physical switches • Static • Manual • Complex • Tenant state maintained in physical network Manual End-to-End VLAN APPROACH 3
    5. 5. 4 Before Neutron: Nova Networking Nova-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. 6. 5 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
    7. 7. Introducing Neutron 6 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. 8. 7 OVS Plugin Overview
    9. 9. OVS Open Source Plugin 8 Overlay Networking GRE Tunnels Uses Open vSwitch Project Components: • Neutron OVS Agent • Neutron DHCP Agent • Neutron L3 Agent • IPTables Neutron Network Node Neutron-Server + OVS Plugin L3 Agent DHCP Agent OVS Agent NAT / Floating IPs IP Tables / Routing dnsmasq ovsdb/ vswitchd Linux Kernel / IP Stack Compute Node nova compute OVS Agent KVM VM VM Linux Kernel / IP Stack ovsdb/ vswitchd IP Tables Compute Node nova compute OVS Agent KVM VM VM Linux Kernel / IP Stack ovsdb/ vswitchd IP Tables GRE Tunnels IP Underlay WAN security groups security groups
    10. 10. OVS Open Source Plugin 9 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 Neutron Network Node Neutron-Server + OVS Plugin L3 Agent DHCP Agent OVS Agent NAT / Floating IPs IP Tables / Routing dnsmasq ovsdb/ vswitchd Linux Kernel / IP Stack Compute Node nova compute OVS Agent KVM VM VM Linux Kernel / IP Stack ovsdb/ vswitchd IP Tables Compute Node nova compute OVS Agent KVM VM VM Linux Kernel / IP Stack ovsdb/ vswitchd IP Tables GRE Tunnels IP Underlay WAN security groups security groups
    11. 11. Challenges with OVS Plugin 10 Neutron Network Node is a SPOF Need to use corosync, etc for active/standby failover. Challenging at Scale Since there’s a single network node, this becomes a bottleneck fairly quickly. Inefficient Networking IPTables, L3 Agent, multiple hops for single flow are causing unnecessary traffic and added latency on your physical network Private IP Network Neutron Server Neutron Server centrally responsible network services like NAT, routing, Load balancing Linux Kernel Open vSwitch Agent VM IP Tables VM VM
    12. 12. 11 ML2 Plugin Architecture
    13. 13. Modular Layer 2 (ML2) 12 Mix and Match Networking Plugins Previously, plugins were monolithic Driver Model Implement network types and mechanisms Multiple mechanisms can be used simultaneously to access different ports across the network. Limitations Not everything is pluggable yet (started with just L2)
    14. 14. 13 Example 3rd Party Plugin
    15. 15. 14 v Any Application MidoNet Network Virtualization Platform Logical L2 Any Network Hardware Any Cloud Management Platform Logical Firewall Logical Layer 4 Load Balancer Logical L3 Logical NAT 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
    16. 16. Private IP Network Network State Database Internet MidoNet Agents act as distributed controller MidoNet Distributed Model Network State Database Network State Database Linux Kernel MidoNet Agent VMVM VM Linux Kernel MidoNet Agent VMVM VM Active Gateway Active Gateway Active Gateways Distributed scale out Gateways Logical Network topology stored in distributed database MidoNet Agent removes need for Service Nodes and IPTables
    17. 17. Private IP Network Neutron Server Neutron Server centrally responsible network services like NAT, routing, Load balancing Linux Kernel Open vSwitch Agent VM IP Tables VM VM
    18. 18. Private IP Network Network State Database MidoNet Agent programs the Kernel to provide services like security groups, routing, load balancing, and floating IPs Linux Kernel VMVM VM MidoNet’s Distributed Edge Model MidoNet Agent
    19. 19. Private IP Network SDN Controller Active Gateway Standby Gateway Internet Linux Kernel Open vSwitch Agent VM IP Tables All outgoing flows travel through the active gateway node. VM VM Linux Kernel Open vSwitch Agent VM IP Tables VM VM Active/Standby GW Model
    20. 20. Private IP Network Active Gateway 1 Active Gateway 2 Internet Linux Kernel Open vSwitch Agent VM IP Tables Outgoing and Incoming flows balanced across MidoNet Distributed Gateways VM VM Linux Kernel Open vSwitch Agent VM IP Tables VM VM Active Gateway 3 Network State Database Network State Database Network State Database Fully Distributed GW Model
    21. 21. 20 Automating the Virtual Network
    22. 22. Heat Orchestration 21 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. 23. 22 { "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. 24. 23 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. 25. 24 Create a “Stack” in CLI or Horizon
    26. 26. 25 Automate the Physical Network
    27. 27. 26 Cumulus Linux on White box Switches
    28. 28. Q&A 27
    29. 29. Thank You Adam Johnson @adjohn slideshare.com/adjohn 28

    ×