Neutron, the Openstack Networking project (formerly named Quantum) is a project aimed at providing a software-defined networking stack. In other words, it implements network provisioning and management on OpenStack clouds. As discussed in previous posts, Neutron exposes networking set-up functionality that was not available to users in the past. Prior to Neutron, virtual machines were, of course, always connected to a network somehow (otherwise, they would not have been accessible to the client creating them or to other VMs) and that networking used to be set up by nova-network, an earlier and more basic service that was originally integrated into Nova Compute.
The involvement of the nova-network service in the process of VM provisioning might come as a surprise to a lot of users. This is because once upon a time, before the introduction of Neutron, networking was actually quite seamless even to users consuming the Nova API. From the user’s point of view there was no need, or possibility, to bother with the network setup. Behind the scenes, Nova Compute used the nova-network service to automatically connect VMs to an existing network, defined by the Openstack administrator.
OpenStack network automation – out of the box. Test it out. Go
White Paper: NFV from ETSI to MANO to YANG. Get it today. Go
Even today, Openstack users can keep on using the basic services provided by nova-network if, for example, they have an existing cloud or don’t need to support complex network topologies. Supporting two different network provisioning services was not the original Openstack plan and the nova-network service was expected to be deprecated, but as it stands, both options are still supported and nova-network will not be deprecated in the upcoming Icehouse release as well. So… let’s take a look at what it has to offer.
Nova network supports three kinds of network topologies (aka “network manager types”) – Flat, Flat DHCP or VLAN. The selection of the used topology is in the hands of the Openstack cloud administrator.
Flat & Flat DHCP
In this set up, all VMs are placed on a single network, using the same subnet and bridge, created earlier by the administrator. This essentially means all VMs share the same network, hence the visual phrasing – Flat. The Flat and Flat DHCP network types are very much alike except for the allocation of IP addresses to VMs is done through DHCP in the thus name Flat DHCP network. Networking-wise – both describe the same topology. There is no network separation between the VMs of different tenants, meaning their VMs can be inter-connected unless limited by other means (such as security groups, which will be explained in detail in my upcoming post).
Another option is to use multiple flat networks (shown below), where VMs are connected to separate networks through multiple interfaces (“multinic”). This might create the appearance of a separate network and subnet per tenant, but the fact remains that all tenants can still access all networks, so although it might be useful for the purposes of high availability, better bandwidth allocation or separation of traffic, it still doesn’t provide much in terms of tenant separation.
VLANs offer a solution to the fully shared and non-secured structure described above by providing a good means of separation. It relies on using a physical switch that supports VLAN tagging to provide each tenant a separate virtual network, employing a dedicated subnet, with a separate IP range and a bridge for each tenant. This effectively creates private networks, accessible to the allowed tenant alone, via VPN. That separation of tenant environments makes VLAN the sensible choice for a multi-tenant environment, and indeed this is the default mode used by Nova-net.
It is also possible to create a mix of flat and private networks, where a VM can access the shared network in addition to a private tenant network. This basically allows the user to create a simple multi-tiered topology, separating different parts of the application according to their security limitations.
So these are the main topologies of Nova network. From the administrator’s point of view, there is a limited selection of possible network types, and network management cannot utilize third party solutions. As I mentioned earlier, from the user’s point of view Nova network is seamless, and therefore makes it easy to manage VMs without the hassle of network considerations. This is simply because all network settings are predefined by the network administrator, for better or worse.
With this new project networking becomes highly customizable. The change in user experience (UX) is dramatic, as users now have the ability to set up even complex topologies through abstractions such as routers, networks, subnets, and ports. All of these enable a huge variety of networking configurations, customizable per tenant, and most importantly – by the tenant.
This makes a dramatic difference from the user’s point of view. Each tenant now has their own (real) playground, in which they have complete control over the network management. This is a new level of control that was not available earlier, and is comprised of different new objects and relationships. It requires that the user gain at least a basic understanding of the network components in order to design a working environment.
Designing complex structures in not a simple matter, and Openstack has risen to the challenge and integrated the new Neutron networking options into Horizon, the Openstack dashboard. This makes network management visual and fairly easy, once you do things in the proper order…. (there is a slight learning curve). On the administrator’s end, Neutron is also backed up by new setup options, such as integrating third party network services. But let’s stay with the user.
Users can now create detailed, specific network architectures, even making it possible to replicate their pre-cloud data center architecture. Each tenant can create one or more routers (up to the account quota limits), as well as create private tenant networks and subnets that connect to those routers. Eventually tenant routers typically connect to the Openstack external network, through which VMs have access to “the world” (VMs are never created directly on the external network).
This configuration enables deployment of multi-tier applications per tenant, where each tier resides on a separate network, behind the tenant’s router. Security wise, the tenant’s router provides good network-level separation. Furthermore, it allows network subnets ranges of different tenants to overlap.
This is the most complex and well defined topology. It provides the highest degree of security due to the enablement of network separation (but that does not in any way replace setting security groups on VMs).
There is, of course, a price to all this freedom of choice, and that is complexity. Creating and managing VMs now forces the user to handle networking as well. First, by initially creating at least a single network for the tenant VMs, then creating a router and connecting it to the cloud’s external network. Then, defining a subnet with an IP range for the tenant’s internal network, connecting it to the router as well, setting up as many networks as needed, and eventually… creating a VM on the selected network.
Managing networks can become even more challenging when setting up a complex, multi-net environment and provisioning VMs on that infrastructure accordingly can be very confusing. Handling VM crashes, failover procedures or scaling out a live system – is very complicated and error prone.
A new dimension was added, and this is exactly where the game changes and the concept of network automation becomes a real necessity.
Cloudify automates the creation of networks, routers, subnets and of course the compute instances on which applications are deployed. By default, Cloudify creates a router for each tenant, connects it to the external network, and creates a network for each tier, i.e. service, of the application.
As mentioned earlier – unless automated, setting up complex network environments can be time consuming and potentially risky. Following the initial setup of the system, it is crucial to perform some routine system checks and respond accordingly. A good definition of the compute properties and network topology allows Cloudify to monitor, execute auto-scaling as required and perform network- aware failover to keep applications highly available. Below is an example for a common network configuration in Cloudify.
The network defined will be created automatically and can later be used by applications that refer to it. Additional settings, such as using existing routers or networks, can also be set on the application network configuration, as shown here:
In my next post, I will dive into security groups, why they matter so much and how to use them with Cloudify to protect your VMs.
Noa is a team leader at GigaSpaces, developing Cloudify. She’s experienced with provisioning automation on different clouds, and knows a thing or two about networking. In her spare time she manages meetups, and other community endeavors, just for the sake of altruism. Find her on Linkedin.