Midokura Gluecon 2014 - Level up your OpenStack Neutron Networking
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Midokura Gluecon 2014 - Level up your OpenStack Neutron Networking

on

  • 587 views

OpenStack Neutron Networking OVS Plugin Overview. Improve networking scale and performance with a third party distributed overlay solution, such as MidoNet.

OpenStack Neutron Networking OVS Plugin Overview. Improve networking scale and performance with a third party distributed overlay solution, such as MidoNet.

Statistics

Views

Total Views
587
Views on SlideShare
541
Embed Views
46

Actions

Likes
1
Downloads
25
Comments
0

2 Embeds 46

https://twitter.com 44
http://www.slideee.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Midokura Gluecon 2014 - Level up your OpenStack Neutron Networking Presentation Transcript

  • 1. Gluecon 2014 Adam Johnson @adjohn Level up your OpenStack Cloud with MidoNet Network Virtualization
  • 2. Outline 2   •  OpenStack Intro •  Neutron Overview •  Networking Evolution •  OVS Plugin •  MidoNet Overview •  Q&A
  • 3. What is OpenStack? 3  
  • 4. 4  
  • 5. Neutron 5   OpenStack Networking •  Pluggable Architecture •  Standard API •  Many choices Plugins Available •  OVS Plugin •  Linux Bridges •  Flat DHCP •  VLAN DHCP •  ML2 •  MidoNet •  NSX •  PlumGRID •  Nuage •  Contrail •  Ryu •  …
  • 6. Evolution of Network Virtualization 6   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 6
  • 7. OVS Open Source Plugin 7   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
  • 8. Challenges with OVS Plugin 8   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
  • 9. Level  up  Neutron  with  MidoNet   9  
  • 10. 10   v Any Application MidoNet  Network  Virtualiza6on  Pla8orm   Logical  L2   Any Network Hardware Any Cloud Management Platform Logical   Firewall   Logical  Layer  4   Load  Balancer   Logical  L3   Logical   VPN   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 VPN – Site-to-Site & Remote Access VPN in software MidoNet API – RESTful API for integration into any Cloud Management Platform MidoNet  Network  Virtualiza6on  Pla8orm  
  • 11. Architecture  Overview Kernel   Kernel   Kernel  
  • 12. Logical  Topology  –  Overlay  Networks
  • 13. How  does  MidoNet  Work?   13  
  • 14. YourExisting Infrastructure YourExisting Infrastructure 14   Load    Balancer   MidoNet Gateway Networkstate database Initial Setup Then We Add MidoNet Storage and MidoNet Border Nodes Then we Install the MidoNet Agent on all the Hypervsior Nodes Overlay needs underlay devices connected over IP
  • 15. Now  we  can  build  your   Logical  Network   15  
  • 16. 16   Provider     Router   Tenant   Router   Tenant   Network   192.168.5.2   192.168.5.3   Let’s Spin up two VMs for a Single Tenant Subnet  192.168.5.0/24   Address:  192.168.5.1   Allow  incoming  tcp/22   NAT  192.168.5.2  <-­‐>  112.140.32.94   MidoNet  creates  a  Provider   Router  which  connects  to  the  External  Network  
  • 17. 17   Provider     Router   Tenant   Router   Tenant   Network   192.168.5.2   192.168.5.3   Let’s Spin up two VMs for a Single Tenant Subnet  192.168.5.0/24   Address:  192.168.5.1   Allow  incoming  tcp/22   NAT  192.168.5.2  <-­‐>  112.140.32.94   Each  Tenant  can  create  their  own  virtual   Tenant  Router  
  • 18. 18   Provider     Router   Tenant   Router   Tenant   Network   192.168.5.2   192.168.5.3   Let’s Spin up two VMs for a Single Tenant Subnet  192.168.5.0/24   Address:  192.168.5.1   Allow  incoming  tcp/22   NAT  192.168.5.2  <-­‐>  112.140.32.94   Then  the  tenant  can  create  VMs  and  Networks   then  aach  those  to  the  Tenant  Router  
  • 19. 19   Provider     Router   Tenant   Router   Tenant   Network   192.168.5.2   192.168.5.3   Various  rules  and  subnets  can  be  applied   to  the  virtual  infrastructure   Let’s Spin up two VMs for a Single Tenant Subnet  192.168.5.0/24   Address:  192.168.5.1   Allow  incoming  tcp/22   NAT  192.168.5.2  <-­‐>  112.140.32.94  
  • 20. All  of  the  logical  topology  is  stored  in   MidoNet’s  Storage  Nodes   20   Provider     Router   Tenant   Router   Tenant   Network   192.168.5.2   192.168.5.3   Subnet  192.168.5.0/24   Address:  192.168.5.1   Allow  incoming  tcp/22   NAT  192.168.5.2  <-­‐>  112.140.32.94   YourExisting Infrastructure MidoNet Gateway YourExisting Infrastructure Networkstate database
  • 21. Now  let’s  talk  about  what     happens  when  we  send  traffic   between  the  two  VMs   21  
  • 22. First  the  outbound  packet  from  VM1  is  intercepted   by  the  MidoNet  agent  on  the  Hypervisor     22   MidoNet Gateway YourExisting Infrastructure Networkstate database YourExisting Infrastructure Provider     Router   Tenant   Router   Tenant   Network   192.168.5.2   192.168.5.3   Subnet   192.168.5.0/24   Address:  192.168.5.1   Allow  incoming  tcp/22   NAT  192.168.5.2  <-­‐>   112.140.32.94  
  • 23. 23   MidoNet Gateway YourExisting Infrastructure Networkstate database YourExisting Infrastructure Provider     Router   Tenant   Router   Tenant   Network   192.168.5.2   192.168.5.3   Subnet   192.168.5.0/24   Address:  192.168.5.1   Allow  incoming  tcp/22   NAT  192.168.5.2  <-­‐>   112.140.32.94   Next,  the  MidoNet  Agent  queries  Network  state   database  for  the  virtual  topology  
  • 24. 24   MidoNet Gateway YourExisting Infrastructure Networkstate database YourExisting Infrastructure Provider     Router   Tenant   Router   Tenant   Network   192.168.5.2   192.168.5.3   Subnet   192.168.5.0/24   Address:  192.168.5.1   Allow  incoming  tcp/22   NAT  192.168.5.2  <-­‐>   112.140.32.94   Then  the  MidoNet  agent  simulates  the  packet   moving  through  the  virtual  topology  and  ac6ons   that  need  to  be  performed  on  the  packet  
  • 25. MidoNet GatewayYourExisting Infrastructure Networkstate database YourExisting Infrastructure Now  MidoNet  can  create  a  GRE  tunnel  between  the     required  nodes,  and  send  the  packet  on  its  way     25   GRE Tunnel
  • 26. MidoNet GatewayYourExisting Infrastructure Networkstate database YourExisting Infrastructure 26   GRE Tunnel Finally,  the  packet  is  received  by  the  target   node  and  delivered  to  the  VM.  
  • 27. MidoNet GatewayYourExisting Infrastructure Networkstate database YourExisting Infrastructure 27   GRE Tunnel Subsequent  packets  follow  the  already  established  path,     and  can  travel  at  near-­‐line-­‐speed.  
  • 28. 28   Why MidoNet? Single Virtual Hop = Better Performance No SPOF = Production Grade Fully Distributed = Massive Scale
  • 29. 29   Q&A
  • 30. Thank You Adam Johnson @adjohn 30