Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Midokura @ OpenStack Seattle

609 Aufrufe

Veröffentlicht am

Neutron: Past, Present, and Future
Midokura presents at the OpenStack Seattle MeetUp
March 2nd, 2015
Hosted by Blue Box Group

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Midokura @ OpenStack Seattle

  1. 1. Neutron:  Past,  Present,  &  Future   OpenStack  Sea5le  MeetUp   March  2015  
  2. 2. Agenda   ▪  Network  VirtualizaEon  Requirements   ▪  EvoluEon  of  Neutron  Networking   ▪  Open  Source  Network  SoluEons   ▪  Quiz!   1  
  3. 3. 2   Network Virtualization
 Requirements
  4. 4. What is Network Virtualization (NV)? 3   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  VirtualizaEon  PlaNorm   Logical  L2   Existing Network Hardware Any Cloud Management Platform Distributed  Firewall   service   Distributed   Load  Balancer  ser   Logical  L3   Distributed  VPN   Service   KVM, ESXi, Xen LXC
  5. 5. Requirements for NV 4   Requirements 4 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network
  6. 6. Requirements for NV 5   Requirements 5 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network Isolated tenant networks (virtual data center)
  7. 7. Requirements for NV 6   Requirements 6 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network L3 Isolation (similar to VPC and VRF)
  8. 8. Requirements for NV 7   Requirements 7 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network Fault-tolerant devices and links Redundant, optimized, and fault tolerant paths to to/ from external networks (e.g. via eBGP)
  9. 9. Requirements for NV 8   8 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network Fault-tolerant devices and links Fault tolerant devices and links
  10. 10. Requirements for NV 9   Device-agnostic networking services: •  Load Balancing •  Firewalls •  Stateful NAT •  VPN Networks and services must be fault tolerant and scalable
  11. 11. Requirements for NV 10   Single pane of glass to manage it all.
  12. 12. Bonus Requirements for NV 11   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)
  13. 13. Checklist for Network Virtualization 12   q  Multi-tenancy q  Scalable, fault-tolerant devices (or device-agnostic network services). q  L2 isolation q  L3 routing isolation •  VPC •  Like VRF (virtual routing and fwd-ing) q  Scalable gateways q  Scalable control plane •  ARP, DHCP, ICMP q  Floating/Elastic Ips q  Stateful NAT •  Port masquerading •  DNAT q  ACLs q  Stateful (L4) Firewalls •  Security Groups q  Load Balancing with health checks q  Single Pane of Glass (API, CLI, GUI) q  Integration with management platforms •  OpenStack, CloudStack •  vSphere, RHEV, System Center q  Decoupled from Physical Network
  14. 14. Evolution of Network Virtualization 13   INNOVATION  IN  NETWORKING  AGILITY   VLAN configured on physical switches •  Static •  Manual •  Complex •  Tenant state maintained in physical network Manual End-to-End VLAN APPROACH 13
  15. 15. Using VLANs for NV 14   q  Multi-tenancy q  Scalable, fault-tolerant devices (or device-agnostic network services). ü  L2 isolation q  L3 routing isolation •  VPC •  Like VRF (virtual routing and fwd-ing) q  Scalable gateways q  Scalable control plane •  ARP, DHCP, ICMP q  Floating/Elastic IPs q  Stateful NAT •  Port masquerading •  DNAT q  ACLs q  Stateful (L4) Firewalls •  Security Groups q  Load Balancing with health checks q  Single Pane of Glass (API, CLI, GUI) q  Integration with management platforms •  OpenStack, CloudStack •  vSphere, RHEV, System Center q  Decoupled from Physical Network
  16. 16. Evolution of Network Virtualization 15   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 15
  17. 17. What is OpenFlow? 16   A communication protocol that gives access to the forwarding plane of a network switch over the network.
  18. 18. What is OpenFlow? 17   A centralized remote controller decides the path of packets through the switches
  19. 19. Using OpenFlow for NV 18   ü  Multi-tenancy q  Scalable, fault-tolerant devices (or device-agnostic network services). ü  L2 isolation △  L3 routing isolation •  VPC •  Like VRF (virtual routing and fwd-ing) q  Scalable gateways q  Scalable control plane •  ARP, DHCP, ICMP q  Floating/Elastic IPs q  Stateful NAT •  Port masquerading •  DNAT q  ACLs q  Stateful (L4) Firewalls •  Security Groups q  Load Balancing with health checks △  Single Pane of Glass (API, CLI, GUI) △  Integration with management platforms •  OpenStack, CloudStack •  vSphere, RHEV, System Center q  Decoupled from Physical Network
  20. 20. Evolution of Network Virtualization 19   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 19
  21. 21. 20   How do overlays achieve real network virtualization?
  22. 22. 21   Encapsulation and Tunneling Provides isolation
  23. 23. 22   Stateless core. Stateful edge.
  24. 24. 23   Network processing at the edge Decoupled from the physical network
  25. 25. 24   Virtual network changes don’t affect the physical network
  26. 26. 25   Single virtual hop network services avoid “traffic trombones”
  27. 27. 26   Centralized state and control for maximum agility
  28. 28. 27   Scalable, fault tolerant gateways to external networks
  29. 29. Using Overlays for NV 28   ü  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
  30. 30. 29   Sounds great, but when will it be a reality?
  31. 31. Network Virtualization Overlays Today 30  
  32. 32. OpenStack   31  
  33. 33. What  is  OpenStack?   32  
  34. 34. OpenStack  Releases   33   Release schedule: time-based scheme with major release ~ every 6 months Codenames 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
  35. 35. 34   Before  Neutron:  Nova  Networking   •  Nova-Networking was the only option in OpenStack prior to Quantum/Neutron •  Original project 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
  36. 36. 35   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
  37. 37. 36   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
  38. 38. Quantum   37   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
  39. 39. Introducing Neutron   38   •  Pluggable Architecture •  Standard API •  Many choices Plugins Available •  MidoNet •  OVS Plugin •  Linux Bridges •  Flat DHCP •  VLAN DHCP •  ML2 •  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
  40. 40. Evolution of Neutron   39   Release  Name     Release  Date   Included  Components   AusEn   21  October  2010   Nova,  Swi]   Bexar   3  February  2011   Nova,  Glance,  Swi]   Cactus   15  April  2011   Nova,  Glance,  Swi]   Diablo   22  September  2011   Nova,  Glance,  Swi]   Essex   5  April  2012   Nova,  Glance,  Swi],  Horizon,   Keystone   Folsom   27  September  2012     Nova,  Glance,  Swi],  Horizon,   Keystone,  Quantum,  Cinder   Grizzly   4  April  2013   Nova,  Glance,  Swi],  Horizon,   Keystone,  Quantum,  Cinder   Havana   17  October  2013   Nova,  Glance,  Swi],  Horizon,   Keystone,  Neutron,  Cinder   Icehouse   April  2014   Nova,  Glance,  Swi],  Horizon,   Keystone,  Neutron,  Cinder   Juno   October  2014   Nova,  Glance,  Swi],  Horizon,   Keystone,  Neutron,  Cinder,  Heat,   Trove,  Sahara  
  41. 41. Latest  Neutron  Features   40   Havana Release Brought: •  LBaaS: shipped an updated API and HAProxy driver support •  VPNaaS: supports IPSec and L3 agent ships with an OpenSwan driver •  FWaaS: enables tenant to configure security at the edge and on VIFs •  New 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
  42. 42. Latest  Neutron  Features   41   Juno Features: •  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 •  SLAAC •  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
  43. 43. Upcoming  Neutron  Features   42   Expectations for Kilo: •  Neutron Core and Vendor Code decompositions •  Remove bottlenecks from contribution process •  Allows vendors to develop and control their own code at their own pace •  Allows different levels of engagement in Neutron community •  Promotes lightweight plugins and drivers with external libraries for backend implementations •  Allow Floating IP to be specified •  Agent child process status •  ARP spoof filtering using ebtables •  Conntrack Zones support •  DHCP Service LoadBalancing Support and Options for IPv4 and IPv6 •  New Iptables driver to improve performance of IptablesManager and reduce complexity of IptablesFirewall and IptablesManager relations •  LBaaS Layer 7 Rules and TLS Specification •  MTU Selection and advertisement
  44. 44. 43   OVS Plugin Overview
  45. 45. 44   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 OVS  Open  Source  Plugin
  46. 46. 45   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 Challenges  with  OVS  Plugin
  47. 47. 46   MidoNet Overview
  48. 48. 47   MidoNet  Network  VirtualizaEon  PlaNorm   Logical  L2  Switching  -­‐  L2  isolaEon  and  path  opEmizaEon  with  distributed   virtual  switching   Interconnect  with  VLAN  enabled  network  via  L2  Gateway     Logical  L3  RouEng  –  L3  isolaEon  and  rouEng  between  virtual  networks   No  need  to  exit  the  so]ware  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  applicaEon  load  balancing  in   so]ware  form  -­‐  no  need  for  hardware  based  firewalls   VxLAN/GRE  –  Provides  VxLAN  and  GRE  tunneling   Provides  L2  connecEvity  across  L3  transport.  This  is  useful  when  L2  fabric   doesn’t  reach  all  the  way  from  the  racks  hosEng  the  VMs  to  the    physical    L2   segment  of  interest.       MidoNet/Neutron  API–  Alignment  with  OpenStack  Neutron’s  API  for   integraEon  into  compaEble  cloud  management  so]ware   v Any Application MidoNet  Network  VirtualizaEon  PlaNorm   Any Network Hardware OpenStack/Cloud Management System Distributed   Firewall   Layer  4   Load  Balancer   VxLAN/GRE   Any Hypervisor Logical  L2   Logical  L3   NAT   MidoNet /   Neutron   API   NAT  –  Provides  Dynamic  NAT,  Port  masquerading  
  49. 49. OpenStack  IntegraEon       5 Easy  integraEon  with  OpenStack:   MidoNet  provides  a  plugin  for  Neutron.     Neutron MidoNet Plugin
  50. 50. Architecture  Overview
  51. 51. 50   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 Challenges  with  OVS  Plugin
  52. 52. 51   MidoNet  Distributed  Model
  53. 53. 52   Centralized  Controller  Model
  54. 54. 53   MidoNet  Distributed  Model
  55. 55. 54   AcEve/Standby  GW  Model
  56. 56. 55   Fully  Distributed  GW  Model
  57. 57. 56   So what’s next for Network Virtualization?
  58. 58. 57   Get more out of the physical network.
  59. 59. 58   Network Virtualization decouples the logical network from the physical network.
  60. 60. NVOs can’t ignore the physical network 59   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 -  Coordination -  Traffic Engineering
  61. 61. 60   Get more intelligence out of your network
  62. 62. NVOs provide a wealth of information 61   NVOs centralize information on your network We can start taking advantage of this information -  Security -  Compliance -  Optimizing Networks
  63. 63. 62   Bridge physical and virtual networks more efficiently
  64. 64. Midokura VTEP Solution 63   MidoNet MidoNet   Virtual Any  Cloud  Management  PlaLorm   MidoNet  Network  State  Database   VM VM VM VM VM VM IP Fabric     Server   Storage   Services   Physical VM VM VTEP   OVSDBc   VxLAN Tunnel Physical Connection OVSDB TCP/IP Key OVSDBs  
  65. 65. 64   Break through performance barriers of software networking
  66. 66. 40Gb  VxLAN  Offloading:  virtualized  environments  require  high   throughput  infrastructure     •  IntegraEon  with  Mellanox  provides  40  Gbps   saturaEon     •  VxLAN  offloading  improves  CPU  uElizaEon  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  so]ware   Performance
  67. 67. Open  Source  So]ware     66  
  68. 68. MidoNet Unleashed • Apache 2 Licensed • Build a truly open and neutral community of users and vendors • Heavily focused on providing a networking solution that functions well for production environments • Available since OpenStack Paris at midonet.org 67  
  69. 69. Who are the members?
  70. 70. How can you contribute to MidoNet? 69   • Check out the website: www.midonet.org • Join the MidoNet community! Wiki, Jenkins, Gerrit, Ask, IRC, ML, Github • Packages are available; easy to install with MidoStack • Sign Legal to Contribute • Midokurians on hand to support community
  71. 71. Thank You Midokura Enterprise MidoNet www.midokura.com Follow us on Twitter: @midokura @_techcet_ MidoNet www.midonet.org @midonet        

×