Brocade Pitches OpenStack Management Layer

The OpenStack community is a quiet driving force in networking, moving technology forward almost as quickly as vendors can implement APIs and programmability. From their work on the original Quantum plug-in for networking interface through its renaming to Neutron, OpenStack developers have been as much of an advocate for virtualized networking as any vendor. Now, Brocade is poised to add a network management layer to the platform -- something that that could revolutionize cloud and data center networks.

I recently spoke to Kelly Harrell, VP and GM of the software business unit at Brocade. Harrell was formerly the head of Vyatta, a company that specialized in software-only networking devices. He's taken his expertise to Brocade and has been increasing its profile with regard to network function virtualization (NFV). Harrell said his team has focused on OpenStack as a key point due to the flexibility and opportunity it can provide users.

Brocade has already created a plug-in that allows Neutron to talk to Brocade VCS switching fabrics. This gives OpenStack the same kind of visibility into VCS that VMware's NSX enjoys. Harrell told me that creating plug-ins is a great thing for vendors because it allows them to control the code process from end to end, to ensuring maximum compatibility with vendor systems. However, Brocade is ambitious. Its next mission is to integrate a new networking element into Neutron itself.

The Dynamic Network Resource Manager (DNRM) is a blueprint that would allow Neutron to take full advantage of heterogenous NFV devices in a greater cloud environment. Currently, creating clusters of devices such as load balancers or firewalls requires them to be similar or even identical. While homogenous devices have been sufficient in the past for many IT departments, the current trend is away from single-vendor solutions toward a more heterogenous "best of breed" solution set. This creates difficulty when trying to provision clustering or load sharing among the devices.

[Want more background on OpenStack? Check out the Network Computing primer "OpenStack: An Overview."]

Brocade's DNRM proposal seeks to insert a layer of management between Neutron and the end device in much the same way the Nova scheduler sends requests for virtual machines to the correct locations. This would allow DNRM to configure, for example, a virtual IP that serves as a communications point for user configurations. This virtual IP could contain load balancers from Brocade, F5, or any number of vendors. The devices could also be virtual or physical. Neutron doesn't care because it only sees the virtual IP. DNRM is in the background processing the communications between devices, splitting traffic loads according to policies are programmed via the management console.

Inserting DNRM into the main OpenStack networking framework provides significant gains in the networking capabilities of Neutron, and provides developers with DNRM capabilities from the start in every OpenStack build. The issue is similar to the debate of a monolithic Linux kernel versus a modularized one: While the ability to break out certain features as modules is advantageous, some programs should be built into the kernel itself. In much the same way, the inclusion of DNRM in the main OpenStack framework will ensure it is always available.

Brocade is presenting this blueprint at this week's OpenStack Summit in Hong Kong. If approved, DNRM will find its way into the spring 2014 release of OpenStack, code named Icehouse. It won't be easy to meet that aggressive timeframe, but including network resource management will prove to be very important to the future of OpenStack development.

Blurring the lines between physical and virtual devices will be crucial in the coming months. Abstracting that entirely from a user's point of view will be essential to providing the kind of experience needed to move private cloud instantiation away from the quagmire that currently exists and closer to the kind of interface that is needed to satisfy every user in a system.