Mirantis OpenStack

  • Download

    Mirantis OpenStack is the zero lock-in distro that makes deploying your cloud easier, and more flexible, and more reliable.

  • On-Demand

    Mirantis OpenStack Express is on demand Private-Cloud-as-a-Service. Fire up your own cloud and deploy your workloads immediately.

Solutions Engineering

Services offerings for all phases of the OpenStack lifecycle, from green-field to migration to scale-out optimization, including Migration, Self-service IT as a Service (ITaaS), CI/CD. Learn More

Deployment and Operations

The deep bench of OpenStack infrrastructure experts has the proven experience across scores of deployments and uses cases, to ensure you get OpenStack running fast and delivering continuous ROI.

Driver Testing and Certification

Mirantis provides coding, testing and maintenance for OpenStack drivers to help infrastructure companies integrate with OpenStack and deliver innovation to cloud customers and operators. Learn More

Certification Exam

Know OpenStack? Prove it. An IT professional who has earned the Mirantis® Certificate of Expertise in OpenStack has demonstrated the skills, knowledge, and abilities needed to create, configure, and manage OpenStack environments.

OpenStack Bootcamp

New to OpenStack and need the skills to run an OpenStack cluster yourself? Our bestselling 3 day course gives you the hands-on knowledge you need.

OpenStack: Now

Your one stop for the latest news and technical updates from across OpenStack ecosystem and marketplace, for all the information you need stay on top of rapid the pace innovation.

Read the Latest

The #1 Pure Play OpenStack Company

Some vendors choose to “improve” OpenStack by salting it with their own exclusive technology. At Mirantis, we’re totally committed to keeping production open source clouds free of proprietary hooks or opaque packaging. When you choose to work with us, you stay in full control of your infrastructure roadmap.

Learn about Our Philosophy

Making sense of SDN with–and without–
HW-based networking in OpenStack Cloud

on December 11, 2012

There’s a tremendous amount of talk about the shift in the networking business from hardware-bound networking to SDN. I worry when I hear that SDN is the next ‘big data’ or ‘cloud’ trend. It makes me think that just as every application and infrastructure company is now offers ‘cloud’ and every data technology company is making things for ‘big data’, soon every networking company will be leading the charge into SDN.

See Mirantis

Senior Technical Director

Greg Elkinbard

in a free on-demand Webcast,

Building out Storage as a Service
with OpenStack Cloud

In this post, I want to talk about how to apply SDN, so I think it makes sense to start with a definition: Software-Defined Networking (SDN) is an approach to networking in which control is decoupled from hardware and given to a software application called a controller.

At Mirantis, we’ve done a bunch of work in this space. This is not the place to go into all those details, as some of the technology we’ve helped to build is not released yet, and some of it is in production at customers who don’t want their stories told in public. One thing I should mention is that we’ve invested a lot in the open source side too, most meaningfully in OpenStack Equilibrium,  a project where we are leading the implementation of LBaaS, aka Load Balancing as a Service.

Putting SDN to work

One way to think about life before SDN was “Hardware Defined Networking”: routers, firewalls, switches, NICs, etc., all imposed control on network traffic flows based on what they knew about the traffic. So to move beyond that, let’s look at two use cases for adding SDNs in the data center. The first relies on creating an overlay purely in software; and second addresses participation by  switch and router elements

  • Software overlay networks: These networks create tunnels which overlay on top of heterogenous hardware infrastructure. Tunneling protocols can be GRE, STT, CAPWAP, VxLan. Interfacing with hardware appliances for L3-L7 services usually require a bridge device. Network policy controls such as QOS are implemented in the software edge devices (Open vSwitch and similar). For OpenStack these types of SDN networks are provided by Nicira and Midokura.
  • Mixed hardware and software networks: In this network type while creation and modification of the network is done by the software controller, infrastructure switches and routers understand and participate in the network flow. These network types can use a protocol that hardware devices can understand and participate in. Older network architectures used VLAN tags, newer ones use either the OpenFlow standard or eventually VxLan standard. Network policy controls such as QOS can be implemented either at the edge or in the hardware network fabric, given that the hardware understand the virtual network scheme. Two providers in this camp are BigSwitch and Cisco. Of course, for any implementation that is not a green field, this ability to leverage existing resources into the networking mix is quite attractive.

Network Service Elements in OpenStack

Whether a network is deployed in software alone, or a combined software-hardware approach, there a some important network service elements to manage. These network service elements can be either hardware boxes or virtual appliances; each offers a different SDN integration strategy that I will define below.

Virtual Service Insertion

Virtual appliances usually ride on top of the cloud SDN infrastructure; they are isolated from the underlying implementation of the cloud itself. These types of services are usually managed by the cloud infrastructure via an API; being purely software, they are instantiated on demand. Examples include the Quantum L3 router in Folsom and CloudPipe in Essex. Mirantis is working with the OpenStack community on standardizing the service insertion APIs and logic for Grizzly; in the meantime, Mirantis has architected the service insertion solution for the Folsom code base.

This approach involves extending the L3 APIs offered by the L3 agent used in Quantum plugins such as OVS, and replacing the agent service code with equivalent functionality offered by the virtual appliance.  This first approach also involves one-for-one replacement of the Network Node in Quantum with a VM. This VM would offer services to multiple cloud tenants through linux namespaces providing tenant segregation. This approach is demonstrated in Figure 1, below.

Integrating Network Appliance VM as a Network Node

Figure 1. Integrating Network Appliance VM as a Network Node

A second approach involves creating on demand network elements for each tenant using nova compute guests; this is done when tenant evokes the appropriate API to create an element such as router, firewall, or VPN. This approach is demonstrated in the Figure 2.

Integrating Advanced Network VM as a Quantum router

Figure 2. Integrating Advanced Network VM as a Quantum router

What this means is this: once you can create discrete, standalone virtual network service elements on-demand, it helps make it much easier to create multi-tenant network services in the SDN infrastructure.

Hardware-based Service Insertion into OpenStack

Now that we’ve seen the straightforward case of inserting virtual network service elements, let’s look at adding a hardware appliance to an SDN. This is something of a challenge. First of all, hardware appliances usually do not understand the virtual network topology of the software overlay networks and require a bridge device. The bridge device can be a dedicated general purpose compute host or a VM. The bridge flattens out the virtual network, presenting a plain segment to the hardware appliance, which can either: offer single tenant services and be provisioned on the fly from a pool; or, can offer multi-tenant services, but without network segregation on its network segment.

For mixed SDNs inserting a hardware network appliance is easier. For example, older style VLAN infrastructure hardware can directly participate in the network scheme, so that appliances which offer internal virtualization capabilities can be “split” between multiple tenants while still offering traffic and control segregation. We built out a deployment using this strategy for one of our clients, where we integrated the Juniper SSL VPN into each discrete tenant network.

For newer OpenFlow networks, Mirantis has worked with BigSwitch in developing an approach where a particular flow will get translated into a VLAN by using a OpenFlow compatible switch operating in the mixed OpenFlow/Legacy mode, such as Arista 7050. In this way, the HW appliance can internally segregate network traffic via VLAN tags, and partition its services  on a tenant-by-tenant basis.

OpenFlow/Vlan Integration

Figure 3. OpenFlow/Vlan Integration

I want to close with an interesting edge case: VxLAN, the tunneling protocol developed by Cisco and VMware originally for use in VMware environments.  Currently, VxLAN it is primarily available as a part the of Cisco Nexus 1000V virtual switch product line. However both Cisco and other hardware vendors are working on integrating VxLAN into their hardware switch line,  with the stated goal of offering mixed mode SDNs (i.e., combining both software- and hardware-originated services. As it turns out, Arista has already released its 7150, capable of translating VLAN into VxLAN, and allowing the same ability to insert HW-appliance-originated services and still preserving multi-tenant segregation. Arista currently does not have an Quantum controller, however developing one would not be a difficult exercise.

One final thought: I’ve seen some discussions of SDN as a choice between hardware-controlled network services and SDN network services. As OpenStack capabilities have improved, this oversimplification is no longer a constraint.

References:

Arista: http://www.aristanetworks.com/en/solutions/network-virtualization

Cisco: https://communities.cisco.com/docs/DOC-31704

Nicira: http://nicira.com/sites/default/files/docs/NVP%20-%20The%20Network%20for%20OpenStack.pdf

BigSwitch: http://www.bigswitch.com/products/big-virtual-switch

OpenStack: http://wiki.openstack.org/Quantum/ServiceInsertion

https://blueprints.launchpad.net/quantum/+spec/services-insertion-wrapper

1 comment

One Response

Continuing the Discussion

  1. Making sense of SDN with–and without–<br/>HW-based networking in OpenStack Cloud | OpenStack news | Scoop.it

    [...] There’s a tremendous amount of talk about the shift in the networking business from hardware-bound networking to SDN. I worry when I hear that SDN is the next ‘big data’ or ‘cloud’ trend. It makes …  [...]

    December 14, 201201:26

Some HTML is OK


or, reply to this post via trackback.