This content is part of the Essential Guide: Where does the enterprise stand with open source cloud computing?
Problem solve Get help with specific problems with your technologies, process and projects.

A cloud admin's guide to OpenStack Neutron networking

As Neutron evolves, it could shape the advancement of Network as a Service, allowing cloud admins to build clouds without the aid of networking pros.

Little has changed with the basic process of deploying an application in the cloud since the inception of cloud computing -- deploy app components and database elements then connect them with each other and users through the network. What has changed, however, are the specifics of how to connect those applications. And that’s because of changes in the way cloud "Network as a Service" is defined.

OpenStack, which has always had a very explicit NaaS model in Quantum (now Neutron), is a good example of NaaS evolution -- and it shows that we're not done evolving.

To avoid becoming perpetual go-betweens when setting up connection services for cloud apps, cloud administrators without high-level networking skills need to understand OpenStack Neutron, and that means working with it more often. If cloud admins can stay up-to-date on OpenStack Neutron's evolution, the more likely Network as a Service will be a real framework to build clouds without technical support from the network professionals or vendors.

Understanding the NaaS architecture model 
OpenStack networking is a model-and-plugin process, and both are changing in important ways. OpenStack follows the general principle of virtualization for its NaaS architecture: abstraction and instantiation.

Abstraction means NaaS defines a number of "models" that represent abstract network elements. Nearly all cloud application, for example, will be deployed on an IP subnet, and this is represented by the network or subnet model in OpenStack Neutron. Networks are virtual local area networks (LANs), and you can add DHCP and domain name system (DNS) services to them to provide addressing and define ports/gateways that will then connect your subnet to users.

The "instantiation" part of virtualization and NaaS is the process of turning Neutron abstractions, or models, into real network behavior. This is done through a plugin designed to issue a set of commands to a device or management system that will, when executed, create the desired network behavior.

At the model level, the early experiences in cloud computing have exposed the fact that Neutron's basic models used to build NaaS (networks, ports and interfaces) aren't sufficient. As a result, as OpenStack is updated, the foundation likely will add several new abstraction models o Neutron with each release.

Advances in OpenStack networking will make it possible to create NaaS models for cloud applications without diving down into network management systems and involving network professionals for each step. With the latest Neutron abstractions and up-to-date plugins,administrators can define and deploy fully connected cloud applications or systems of applications using only OpenStack tools. If admins add DevOps tools, such as Chef, Puppet or Juju, they can deploy and redeploy cloud applications based on scripts, with no special networking skills.

The struggle to keep OpenStack plug-ins updated
Despite the benefits for cloud admins, the question remains of whether enterprises with complex cloud environments can keep plugins up to date. Because OpenStack presumes there is one Neutron server and plugin per OpenStack domain, there's a major risk in multi-vendor networks that the plugin won't be customized for the entire cloud management environment. The use of a standard network control framework, such as OpenFlow or OpenDaylight, can alleviate some of this problem, but a large enterprise will have difficulty finding a plugin that will control their range of vendors and devices.

That's a problem not easily solved -- but the OpenStack Foundation is working on it. One project underway will support multiple plugins per Neutron implementation, which could solve the problem of getting a multi-vendor network to provide standardized Neutron NaaS abstractions. Other plugin projects could make it possible to send parameters to virtual elements when Neutron activates them, enabling the correct set up of a port or interface or device. That should also help cloud administrators, who now have to get such setup parameters from the network organization and often rely on them to configure the virtual elements once they're deployed.

Data shows most cloud administrators don't review OpenStack's Neutron projects, which can be a bad decision. Some of these projects have broad impact, such as those that add models/abstractions or support multiple plugins simultaneously. Other projects refine current plugins or abstractions to improve performance or add features. Sites like OpenStack Code Review provide cloud administrators with a current view of OpenStack Neutron projects that are ready for testing. It's a good idea look for projects that may affect your cloud implementation or plans.

About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.

Next Steps

Make OpenStack management easier 

Dig Deeper on Cloud application monitoring and performance

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.