Midokura OpenStack Meetup Taipei
•Download as PPTX, PDF•
0 likes•590 views
The document provides an overview of network virtualization requirements and the evolution of network virtualization in OpenStack. It discusses early approaches using VLANs and OpenFlow that had limitations and outlines how network overlays using encapsulation and tunneling address these by providing scalable, isolated tenant networks decoupled from physical network hardware. It then focuses on OpenStack Neutron and how it has evolved from Nova networking to support network virtualization using plugins like Midokura that provide distributed virtual network functions without relying on physical devices.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Midokura OpenStack Meetup Taipei
Similar to Midokura OpenStack Meetup Taipei (20)
Recently uploaded
Recently uploaded (20)
Midokura OpenStack Meetup Taipei
- 1. From Nova Network to Neutron and Beyond: A Look at OpenStack Networking OpenStack Taipei MeetUp January 29th, 2015
- 2. Agenda Network Virtualization Requirements OpenStack and the Evolution of Neutron Networking Midokura Use Cases and Futures for NV 1
- 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 Virtualization Platform 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. 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. 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. 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. 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. 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. Requirements for NV 9 Device-agnostic networking services: • Load Balancing • Firewalls • Stateful NAT • VPN Networks and services must be fault tolerant and scalable
- 11. Requirements for NV 10 Single pane of glass to manage it all.
- 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. Checklist for Network Virtualization 12 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
- 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. Using VLANs for NV 14 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
- 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. What is OpenFlow? 16 A communication protocol that gives access to the forwarding plane of a network switch over the network.
- 18. What is OpenFlow? 17 A centralized remote controller decides the path of packets through the switches
- 19. Using OpenFlow for NV 18 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
- 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. 20 How do overlays achieve real network virtualization?
- 22. 21 Encapsulation and Tunneling Provides isolation
- 23. 22 Stateless core. Stateful edge.
- 24. 23 Network processing at the edge Decoupled from the physical network
- 25. 24 Virtual network changes don’t affect the physical network
- 26. 25 Single virtual hop network services avoid “traffic trombones”
- 27. 26 Centralized state and control for maximum agility
- 28. 27 Scalable, fault tolerant gateways to external networks
- 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. 29 Sounds great, but when will it be a reality?
- 31. Network Virtualization Overlays Today 30
- 32. OpenStack 31
- 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. 34 Before Neutron: Nova Networking • Nova-Networking was the only option in OpenStack prior to Quantum/Neutron • Original method 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. 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. 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. 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. 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. Evolution of Neutron 39 Release Name Release Date Included Components Austin 21 October 2010 Nova, Swift Bexar 3 February 2011 Nova, Glance, Swift Cactus 15 April 2011 Nova, Glance, Swift Diablo 22 September 2011 Nova, Glance, Swift Essex 5 April 2012 Nova, Glance, Swift, Horizon, Keystone Folsom 27 September 2012 Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder Grizzly 4 April 2013 Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder Havana 17 October 2013 Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder Icehouse April 2014 Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder
- 41. Latest Neutron Features 40 Havana Release Brought: • LBaaS: shipped an updated API and HAProxy driver support • VPNaaS: VPN API supports IPSec and L3 agent ships with an OpenSwan driver • FWaaS: enables tenant to configure security at the edge via the firewall API and on the VIF via the security group API • New plug-in Modular Layer 2 (ML2): 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. Upcoming Neutron Features 41 Expectations for Juno: • Provide Distributed Virtual Routing (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, • 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
- 44. 43 MidoNet Network Virtualization Platform Logical L2 Switching - L2 isolation and path optimization with distributed virtual switching Interconnect with VLAN enabled network via L2 Gateway Logical L3 Routing – L3 isolation and routing between virtual networks No need to exit the software 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 application load balancing in software form - no need for hardware based firewalls VxLAN/GRE – Provides VxLAN and GRE tunneling Provides L2 connectivity across L3 transport. This is useful when L2 fabric doesn’t reach all the way from the racks hosting the VMs to the physical L2 segment of interest. MidoNet/Neutron API– Alignment with OpenStack Neutron’s API for integration into compatible cloud management software v Any Application MidoNet Network Virtualization Platform Any Network Hardware OpenStack/Cloud Management System Distributed Firewall Layer 4 Load Balancer VxLAN/GRE Any Hypervisor Logical L2 Logical L3 NAT MidoNe t/ Neutron API NAT – Provides Dynamic NAT, Port masquerading
- 45. OpenStack Integration 5 Easy integration with OpenStack: MidoNet provides a plugin for Neutron. MidoNet Plugin
- 47. Do it BiggerDo it Faster Value Agility Provide rapid provisioning of isolated network infrastructure for labs and devops. Logical Network Provisioning Automated Provisioning Isolated Sandboxes Control Network admins can better secure, control & view network traffic. Single Pane of Glass OpsTools Enhanced Security Enable Compliance Do it Better IaaS Cloud Build multi-tenant clouds with visibility into usage. Tenant Control Metering Automated Self Service Performance Improve network performance using edge overlay & complementary technologies. Single Hop Virtual Networking VXLAN Hardware Gateway Massive performance with 40Gb Support Scale Add virtual network infra & services simply & resiliently without hardware & bottlenecks. Distributed Logical Networking FW, LB, L2/3, NAT Limitless “VLANs” Scale out L3 Gateway Bridge legacy VLANs IPv6 Solution for OpenStack Networking Use MN to overcome limitations of Neutron for OpenStack users. Replaces OVS Plugin Use Cases
- 48. 47 So what’s next for Network Virtualization?
- 49. 48 Get more out of the physical network.
- 50. 49 Network Virtualization decouples the logical network from the physical network.
- 51. NVOs can’t ignore the physical network 50 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 - Traffic Engineering
- 52. 51 Get more intelligence out of your network
- 53. NVOs provide a wealth of information 52 NVOs centralize information on your network We can start taking advantage of this information - Security - Compliance - Optimizing Networks
- 54. 53 Bridge physical and virtual networks more efficiently
- 55. Midokura VTEP Solution 54 MidoNet MidoNet Virtual Any Cloud Management Platform 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
- 56. 55 Break through performance barriers of software networking
- 57. 40Gb VxLAN Offloading: virtualized environments require high throughput infrastructure • Integration with Mellanox provides 40 Gbps saturation • VxLAN offloading improves CPU utilization 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 software Performance
- 58. 57 Q&A
- 59. 58 MidoNet Advantages Check out our blog: http://blog.midokura.com/ http://blog.midonet.org Follow us on Twitter: @midokura @midonet
- 60. Thank You 59
Editor's Notes
- In this talk, we will talk a stroll down memory lane from a networking perspective. We will recall the early stages of Nova-Networking, how it evolved to Neutron today, and look at what to expect in the future of OpenStack networking. We will discuss the network functionality and its shortcomings over the evolution of Neutron. Let’s network!
- So what does it take to pull off Network Virtualization?
- Here’s an example logical (or virtual) network. Much of this was and is still being defined by AWS.
- No need to re-invent the wheel when connecting to external networks, let’s use standards.
- Devices: We’re decoupling the physical from the virtual, this must include services too.
- We don’t want to have to manage our networks with a bunch of different tools. RESTful API, CLI, GUI If we have all of these things, we’re doing great, but let’s add some more requirements for kicks
- Integrate with systems like OpenStack, Cloudstack, vSphere, System Center Reduce need for ARP Broadcast since we already have the information on most of the MACs in a virtualized system. Single Virtual Hop – we want to make sure that we’re not needlessly sending virtual traffic over the physical network for efficiency and performance
- To sum it up
- VLANs were the original network virtualization – you configure your switches for VLANs, and you get several isolated layer 2 networks across your network. So let’s look at the checklist to see how VLANs do for NV
- VLANs only really solves the L2 Isolation part of the equation. Difficult to configure (no single pane of glass) Doesn’t scale past 4096 VLANs If you want any of the other network services, you have to rely on tying together virtual or physical appliances Not decoupled from the physical network
- The next innovation that came out was OpenFlow
- Openflow came out of the Stanford clean slate program
- Some Controllers available: ODP, Big Network Controller, Ryu Controller, NEC ProgrammableFlow Requires the physical (or virtual) switches to support OpenFlow
- OpenFlow was a good first attempt You can check off some of the boxes with OpenFlow While you can’t get multi-tenancy from the protocol itself, many controllers will offer this L2 Isolation – removes the vlan limitation for you, makes it more “standard” across multi-vendor networks Routing, you can partially do routing, but it’s only pseudo-routing. Since it doesn’t handle control protocols such as ARP Doesn’t really handle NAT well either, since you don’t have an L3 stack to handle things like ARP You do get centralized control over what OF can provide to you, but you’re left with other solutions for the networking services that OF can’t provide. Same thing goes for integration of management platforms, it does solve the ease of L2 isolation for these platforms, but you’re relying on other solutions for the other networking services like NAT, load balancing, routing, etc. Still requires state in the physical network. This is very dynamic state, and openflow hardware can not easily keep up. In fact, most OF hardware does not handle all of OF in HW itself, instead it relies on SW for those functions. TCAMs are also small and can’t really handle the number of entries needed in a virtualized environment
- Our next innovation in this space brings us to Overlay networks
- And let’s zoom in a bit to see what makes overlay networks so great
- Isolation not using VLANs IP encapsulation, use standards like GRE, VXLAN Decouple from physical network Tunneling and encapsulation are not Provisioning VM doesn’t change underlay state ########################################################## Inspired by VL2 from MSR
- Key tenants for NV is Stateless Core, Stateful Edge. Underlay delivers to destination host IP only The idea is similar to Forwarding equivalence classes (FEC) in MPLS This allows you to use a scalable IGP (iBGP, OSPF) (or perhaps OpenFlow) to build out a multi-path underlay Removes complexity and requirements from the physical network Can use merchant silicon gear to lower costs, can mix and match vendors since you only configure your physical network once Physical network doesn’t need to scale to the number of VMs, but to the number of hypervisors, so we don’t run into mac table size limitations
- Virtual network processing at ingress host, decoupled from physical network. This edge processing can handle the control protocols (ARP, ICMP) Networking services such as L2 switching, L3 routing, NAT, firewalls, load balancing
- By handling all of the networking services at the ingress host at the edge, in software, we can avoid making any changes to the physical network. This allows us to have very dynamic, dense virtual networks without bogging down physical networking equipment
- If you don’t provide as many networking services at the ingress host (edge) as possible, you have to send the traffic mid flow to a service node, or appliance to handle things like NAT, FW, LB or ARP broadcasts. This causes traffic trombones to happen, where you “weave” virtual traffic through the physical network, and lose that decoupling from the physical network.
- API, CLI, GUI provides the single pane of glass that we require. In addition, we are acquiring a massive amount of information about your network that can be used to our advantage: Traffic engineering Analytics Compliance Security
- L3 scalable gateways using multi-homed eBGP can provide multiple uplinks for scalability and fault tolerance from virtual network to external networks – like the internet. Scalable L2 gateways should provide VLAN tagging and translation to bridge non-virtualized networks into virtual. (Sakura use case)
- So where does this leave us now?
- First I'll introduce OpenStack to help give context around virtual environments and drivers behind network virtualization.
- Cloud platform launched 4 years ago by NASA and Rackspace It’s an open source cloud orchestration tool, with the main pillars being compute, storage, and networking (called Nova, Swift or Cinder, and Neutron for networking) - Used to deploy large-scale private or public clouds while leveraging the support of the open source community - Today we’ll be focusing on Neutron networking solutions
- So focusing on networking within OpenStack, OpenStack networking has evolved since its original release. - It was originally just a flat network: no VLANs nor IP routing. Just a big broadcast domain.
- Then Nova-networking slightly evolved by providing isolated L2 networks with DHCP, but it still required VLANs configured on the physical network.
- Then Nova-networking slightly evolved by providing isolated L2 networks with DHCP, but it still required VLANs configured on the physical network.
- Neutron was a re-architecture to a more modular design - became a core project in Folsom release, we’re now on the Icehouse release. OVS is the most deployed plugin according to the latest user survey, so we’ll cover this one along with MidoNet
- Neutron was a re-architecture to a more modular design - became a core project in Folsom release, we’re now on the Icehouse release. OVS is the most deployed plugin according to the latest user survey, so we’ll cover this one along with MidoNet
- Neutron was a re-architecture to a more modular design - became a core project in Folsom release, we’re now on the Icehouse release. OVS is the most deployed plugin according to the latest user survey, so we’ll cover this one along with MidoNet
- Neutron was a re-architecture to a more modular design - became a core project in Folsom release, we’re now on the Icehouse release. OVS is the most deployed plugin according to the latest user survey, so we’ll cover this one along with MidoNet
- - neutron database schema is dependent on the neutron configuration. It differs depending on core plugin and services configured. This makes DB migrations not idempotent, as configurations can change between versions - Groups based policy: the application administrator can then deal with a higher level abstraction that does not concern itself with networking specifics like networks/routers/etc IPv6: V6: - Router Advertisements - IPAM Algorithms: ○ SLAAC § RA Auto config § IPv6 Address gen from EUI-64 address § no DHCP ○ Sequential - RA secured with security groups DHCP v6 Stateful and Stateless modes In SIngle stack mode: no v6 metadata service yet Config drive is a workaround
- FIX ANIMATION. Since we are a network overlay, we are truly decoupled from the physical network. Our motto is to fit in as seamlessly as possible, and not rely on any specific hardware, just IP connectivity - working to integrate with any hypervisor (find KVM most predominant) provide a network overlay solution allowing you to do several things, including: L2 isolation without vlan limitations L3 routing Stateful and Stateless NAT L4 load balancing firewall/security groups: brings more importance to single virtual hop Elastic IPs work with several cloud management platforms, including as a plugin for OpenStack - Midokura involved in OpenStack early on since the B release (Bexar) have a GUI, CLI, API, or programmability through scripts for various configuration options and integration into any cloud management platform ----- Meeting Notes (7/23/14 23:45) ----- MidoNet/Neutron API: using Neutron API as a pass-through to provide all this extra functionality. We have been involved with OpenStack since the B release, thus have tight integration and been providing these features for a while now.
- MidoNet provides a plug-in for the Neutron networking component of OpenStack MidoNet replaces the OVS plug-in (open source plug-in) to fix many of the issues with Neutron and provide advanced features like Layer 4 Load Balancing and Security Groups MidoNet/Neutron API: using Neutron API as a pass-through to provide all this extra functionality. We have been involved with OpenStack since the B release, thus have tight integration and been providing these features for a while now.
- Here we depict an overview of our architecture. The Key idea is that it’s components are completely distributed, and all active. Our MidoNet Agent resides on each host in the network in a distributed fashion. The agent programs the kernels to handle flows from its respective VMs. Gateways: Several options: L3, L2, and VxLAN Mention that they are fully distributed: no need for active/standby. Dynamically add/remove gateways to scale up or down Could run thousands if you needed, but a single gateway easily saturates 10G, and 40G with Mellanox option - Since the Midolman Agent is identical on the gateway as the host, the same behavior and functionality can be applied to incoming packets, like security groups, etc. ----- Meeting Notes (7/24/14 00:07) ----- L3 GW, L2 GW or VLAN-aware bridge, and VXLAN GW.
- I’d like to change this phrase slightly because traditionally, overlays have been ignoring the physical network. This is fine initially, but it’s not enough as we move forward.
- <slide> For operations, it’s important that we know what’s going on in the physical network, so when a problem occurs, you immediately know if it’s a virtual or physical problem. For an example: We can start doing things like DSCP tagging to mark flows with particular classes of traffic that the physical network can understand and react to. Treating Mice vs. Elephant flows differently. Advances in hardware are making this more and more interesting – Plexxi
- We can collect a lot of information about the entire network, centralize it, and run analytics on it. Security – looking at historical data to get more visibility into an attack that’s occurred. Or look at near realtime data to raise security triggers, and reacting to them with our NVO is near instantaneous Tons of room for innovation with all of this data and power we’ve been given
- I mentioned before the Layer 3 eBGP gateway, as well as the Layer 2 vlan aware gateways, let’s add one more option.
- Cumulus Linux Intro, merchant silicon MidoNet can control CL ToR to bring non-virtualized workloads into management as well. Wire speed and high port density on cost effective merchant silicon hardware.
- increase number of VM pairs increases with VxLAN offloading, flat for non-offloading
- So overlay is obviously a winner for this use case, but OF can be seen as a complimentary technology to use in your network: Fabrics, traffic engineering We just need to make sure to keep as little state out of the core of the network as possible, to keep up with highly dense, dynamic virtualized networks.
- Stop by our booth