)
At one of the most widely attended sessions of the Paris Summit, Mark McClain and Salvatore Orlando, two core-team members of Neutron gave a broad overview of Neutron and its architecture.
Mark started off the presentation with a brief history of Neutron, the Networking component of OpenStack. The project has been around for 3.5 years and was started in response to the need from the OpenStack community for a networking project with rich topologies that is technology agnostic, extensible, and provided advance services support like load balancing, VPN, and Firewall.
Neutron was also created to solve specific problems in the cloud. For instance, how do you do high density multi-tenancy? There are a limited number of VLANs, so they have trouble scaling. On-demand provisioning was also a problem — traditional solutions required manual configuration, while operators today are looking to build and migrate workloads around the datacenter. Finally, many operators need to place/move workloads because they have legacy applications that are tired to static IPs.
Neutron, Mark explained, addresses each of those challenges with specific approaches including software defined networking, an L2 Fabric solution, and overlay tunneling.
The Basics
A typical user sees the same API regardless of whether the backend is KVM, a proprietary plug-in, or a different storage technology. The Neutron team wanted to provide the same generic API that you would find in Nova or Cinder, so they created several basic abstractions.
Essentially, Neutron has a very small core, but by using very basic constructs you can create richer topologies.
Mark explained that the design goals of the project are as follows:
- A unified API
- A small core so that it could cover the broadest range of offerings from vendors
- A pluggable open architecture so that deployers have a choice in which vendors they use
- Extensible so that operators can gain access to new features
To reach those goals, the Neutron team implemented the following common features: support for overlapping IPs, configuration of metadata with DHCP or config drive, floating IPs, and support for security groups.
Neutron Architecture
After the high-level introduction, Salvatore Orlando took the stage to describe the architecture of Neutron. He started by joking about how easy Neutron is — “just a set of colorful boxes.”
As you can see from the diagram, the basic deployment has the Neutron server (rest-API) on one side and agents on the other, all connected with a message queue.
Then, the server runs a plug-in, either a monolithic plug-in or an extension. There are two kinds of a monolithic plug-ins — a proxy towards a 3rd party system or a direct control. If you don’t want to use the monolithic plugin, you can use the Modular Layer 2 Plugin which is a full control plugin that can run several drivers — type driver or mechanism driver. Having either option gives users more flexibility.
Salvatore also explained how plug-in extensions work with Neutron.
Then, he went into the “tunnels, bridges and roundabouts” that help Neutron control traffic. One such mechanism is the L2 agent, which essentially watches and notifies you when devices are added and removed. The L2 agent is extremely scalable, fast, and secure.
Another mechanism is isolation. Neutron supports different kinds of isolation including VLAN and GRE/VxLAN.
Salvatore also explained how tunneling works with Neutron. Suppose that VM "A" wants to communicate with VM "D." To do so, VM "A" would traditionally send a broadcast across all tunnels to find where the receiver is. The problem is that when you go to large networks, there is a very high volume of broadcasts sent over the tunnel and the network becomes crowded and inefficient.
Neutron uses L2 Population, which allows operators to know exactly where the destination host is sitting in the tunnel. It also uses L3 agents, which forward east/west and north/south traffic.
What’s New In Juno
Mark finished the last third of the presentation by walking through what’s new with Neutron in Juno and what to expect in the upcoming Kilo release.
One of the biggest improvements to Neutron in the Juno release is the enablement of IPv6 support. It includes router advertisement support, IPAM algorithms (SLAAC and Sequential), and RA secured with security groups.
“[IPv6] is the future.”
Distributed Virtual Routing is another important addition. DVR essentially allows you to route directly from a hypervisor to a core without having to go through a networking node. This circumvents the problem of a noisy hypervisor that generates lots of noise and saturates the network node (and eventually the core link).
Other improvements in the Juno version include the fact that security groups have improved tremendously. They are now far more efficient using IPsets, which speeds up the ability to process security group rules. Neutron also includes L3 Agent HA via Namespace pairs. This allows other networks to take over and seamlessly transition your traffic if a network were to die.
Looking Ahead to Kilo
In Kilo, the focus will be on paying down the team’s technical debt. In the 3.5 years that Neutron has been around, the project has grown substantially. Some of the choices made in the early days were right at the time, but are longer the best ways to push the project forward. Specifically, the team be working on:
- Continuing to refine IPv6 and adding in the ability to prefix delegation and add metadata service
- Improving IPAM service
- Facilitating dynamic routing (Neuron currently does static routing)
To learn more about Neutron, check out the full session here:
- Musings and Predictions from Superuser’s Editorial Advisors - January 29, 2015
- Kilo Update: Trove - January 9, 2015
- Kilo Update: Ceilometer - December 19, 2014
