Neutron’s role evolves in OpenStack networks

Networking in OpenStack

OpenStack comprises multiple projects responsible for various core functions. Some projects are more heavily adopted and more mature than others.

Due to variations in networking architecture, dependency on immature technology such as software-defined networks (SDNs) and network function virtualisation (NFV), and very simplistic early OpenStack implementations, networking functions received less attention in the beginning and have been trying to catch up ever since.

OpenStack’s networking module automates NFV but does not configure or virtualise the physical network infrastructure that application traffic traverses. Although this can fundamentally be problematic when trying to connect and fully automate provisioning, it is consistent with the SDN and NFV immaturity that currently exists in the market.

As OpenStack and the market have matured, OpenStack’s networking module has, similarly, gone through different phases, each requiring teams to completely throw out any previous work done to create virtual networks and start again.

Ultimately, Neutron’s success is tied to the success of the larger OpenStack platform. OpenStack has established itself as a standard in the private cloud marketplace. For the 50-plus Fortune 100 firms that are already using OpenStack, Neutron has not been a barrier to adoption.

Given the support and recognition for Neutron by the OpenStack Foundation, its forecast is optimistic. If you are an OpenStack user or hopeful, it should be an obvious step to use its core networking technology, while acknowledging that it is still a work in progress.

The OpenStack community is large and has provided ample resources, but much Neutron information is outdated, limited to basic designs, and scattered. Production instances of Neutron are small in relation to traditional networks, and there has been little documentation. Teams will have to spend a lot of time combing the internet for information or waiting for answers on community sites.

Neutron meets simple networking requirements. Forrester recommends keeping your networking architecture simple so you can stick with the basic Neutron set-up, which will make your life far less complicated. IT professionals should scope the project so that Neutron does not need to support multiple hypervisors and orchestrators across compute vehicles – bare-metal servers, virtual machines (VMs), or namespaces and containers; across racks in a datacentre; across multiple datacentres; or across private and public clouds and legacy environments.

Keeping it simple

But keeping it simple is easier said than done. Your organisation is likely to have requirements that exceed Neutron’s current maturity. Assess your requirements. If Neutron falls short, consider third-party enhancements from commercial providers such as Nuage Networks.

This will add complexity, but if it makes or breaks your use case, use the commercial marketplace.

Google specifically hired software developers to create a network because it understood software developers would not want to manage a network in a traditional way. Similarly, although networking professionals will be able to take on building out OpenStack’s network capabilities, organisations that have succeeded with Neutron have turned to software developers with networking skillsets.

Although the fundamentals of the network are the same in hardware as in the virtual world, virtual networking requires a completely different skillset to design, deploy and manage. The control points and components, such as switch operating system and network management, break down into many more components, such as agents, modules and servers.

You must dedicate specific team members with software and networking skills to OpenStack networking. It can’t be a side gig for a datacentre networking professional. The new network administrator is actually a specialised software developer.

Third-party help

Forrester says that organisations looking to deploy Neutron should expect to get third-party help. OpenStack is not known for a slick and sophisticated user interface. IT teams will find holes in basic functions.

For example, Neutron uses an internal internet protocol (IP) address manager and has the capability to assign, report on IP addresses, or provide permissions on IP. All these are common requirements in an automated datacentre, but organisations will need more. IT teams will have to build capabilities or use outside systems, such as BlueCat or Infoblox.

Neutron development has mostly been around Layer 2 and Layer 3 aspects of networking. Layer 4 to Layer 7 services will need third-party systems and a Neutron plug-in so that technology management teams can spin up firewalls, load-balancers, front-end optimisers and other services.

To overcome some of this complexity, employ third-party consulting from experienced OpenStack services companies. Unless your own people are as experienced, this will prove a good investment.

Forrester recommends doing some self-reflection. Are you building a greenfield deployment? What level of interaction do you expect with your existing network? What types of application will be running in the OpenStack environment? Do you require self-service? Who are the users? What level of isolation and security do you need? What level of quality of service do you expect? Are you building multiple clouds/datacentres or a hybrid deployment?

Answers to these questions will dictate how best to approach Neutron and its surrounding tools. Following common practice will rarely be the best way to proceed because many of these answers will vary substantially.

The is an extract of the Forrester report Pulling the curtain back on Neutron, OpenStack’s cloud networking module by Andre Kindness and Lauren E Nelson.