Akanda virtual router for virtual networks in Openstack

The Openstack virtual network, aka Neutron (old name Quantum) is responsible to deliver networking services for other cloud infrastructure projects. There is already quite a lot about it on the Internet and we reviewed couple of  possible deployment scenarios and use cases here (Emerging of the virtual network aka Quantum in Openstack) as well. Going further this route and discussing virtual networking opportunities it is a time to ask another question:

Does Openstack Virtual Network/Quantum/Neutron support virtual routers?

I don't have yet a very clear answer to this but found today this interesting project: https://github.com/dreamhost/akanda.

Looking at DreamHost wiki we can see that they use it to solve a problem of distributing and redirecting traffic in multi tenancy environment to secure, extend and control the networking traffic. As they claim it is being implemented with a help of virtual router, aka akanda.

http://wiki.dreamhost.com/DreamCompute_Overview

Network

Networking services for DreamCompute are delivered through OpenStack's Quantum service, coupled with Nicira's NVP (Network Virtualization Platform), and DreamHost's own Akanda project.

Nicira initiated and leads the Networking project team within the OpenStack community. Nicira's NVP, in concert with the OpenStack Quantum project, provides the ability to create private networks per tenant with high availability and network hardware independence. Nicira's NVP virtualizes the network; the software does for networks what hypervisors do for servers.

Another component to DreamCompute networking is the open source Akanda project developed by DreamHost. Akanda serves as a network traffic router (OSI Layer 3) for virtual networks created in DreamCompute. Akanda allows virtual networks to be configured to talk to each other, to LANs, to WANs or to the Internet.

The combination of OpenStack, Nicira and Akanda bring a level of network flexibility and security that sets DreamCompute apart from the competition.

What your Dev, Engineering and sales teams can achieve by using Openstack cloud and Quantum network

Nicira NVP controller can be used together with Quantum as a plugin to enable extend virtual networking capabilities in Openstack. With NVP help the providers, operators and users can start building Software Defined Network (SDN) networks to interconnect the virtual machines.

It was predicted and by many it is seen as a natural evolution and a step forward for Openstack and cloud network in general.

We are no longer tight to static, unchangeable set of switches and routers when it comes to building and designing networks. The more flexible networking allow us to build more agile cloud infrastructures that will allow us to meet changing demands of rapidly evolving applications.

As a real business example of cloud flexibility this is a video of how Nicira is using Quantum to solve its internal infrastructure challenges for the Dev, Engineering and Sales teams: Running Quantum on Quantum @ Nicira's Multi-tenant OpenStack.

For these who don't like videos I have copied some of the key point from the presentation:

• In a physical word it is difficult to achieve full automation and implement provisioning process that can build new configuration in a few minutes only 
• This is a challenge for the operational team to deliver results in a rapidly changing environment and keep the some quality of work when your company grows fast
• There is always a risk of a human error that can potentially bring your production network down
• Most network are designed to meet only the requirements that are known initially; It is difficult to plan ahead and new changes can be impossible to implement later on
• Developers need to have a flexibility to test without a risk of bringing a company network down
• You can easily provision new isolated environments for new projects or new hires
• For better resource utilization you want to have an automation in place that allows you to tier down and spin up whole environments (cloud servers + networking) as easy as possible during a day
• Not only a compute resources have to be easy to provision but as well as interconnecting and isolating them to achieve infrastructure resources agility; This is important especially for tier application typologies where we have web, db and application servers. 
• Quickly building POC for new projects and customers demonstration
• Flexible network infrastructure allows collaboration between different development teams; breaking the network isolation boundaries in a statically built network may be impossible
• Within minutes or second you can create and build new networks as well as to decommission them
• You can add new resources and boost capacity when you need it; More flexible handling of cloud bursting; You don't have to oversubscribe resource only to meet the pick application requirements

And at the end copies of the interesting slides from the above presentation.

What network topologies can I build with Openstack Quantum server

The Folsom Openstack release brings many enhancements to networking stack in the Openstack version of the cloud. The features have been encapsulated with in a new core project called Quantum. But even looking at the documentation it can be very difficult at the beginning to understand what are the differences to old nova-network solution and how an example Quantum virtual network can be configured.

Fortunately there is an easy to follow video introduction to Quantum from last Summit [1]. The slides to it can be found here as well [2].

Below are example slides from the presentation of how a virtual network can be build and how it can look like in cloud powered by Openstack, examples: single flat network, multiple flat networks, mixed flat plus private networks, single provider network, multiple per tenant private networks plus single provider network.

References

1. OpenStack Networking (Quantum) Project Update 
2. http://www.slideshare.net/danwent/quantum-grizzly-summit 
3. More slides about Quantum from Dan Wendlandt at slideshare

Understanding network architecture in Openstack

With the new Folsom Openstack release we have now access to new networking architectures called Quantum. Even more, network is no longer only an internal part of nova but rather become a new core component [1].

It is going to take some time before Quantum become the main single option for network configuration. Many small to medium deployments will probably never require such a complicated mechanism to manage network creation, ports assignments or IPs allocation.

Problem

• How many network configuration options do we have in Folsom.
• How does the old nova-network work.

Solution

In Folsom we have a choice and we can use either nova-network [1] or quantum [3] service for our  cloud infrastructure.

Depending on the complexity and flexibility we can use the the following configurations in nova-network [2]:

Configuring Flat Networking

Configuring Flat DHCP Networking

Configuring VLAN Networking

This picture shows an example interaction between 2 VMs. More in depth description of how the network flows look like and what role plays the hypervisor in routing or restricting the traffic can be found in [4].

References

1. http://docs.openstack.org/trunk/openstack-compute/admin/content/networking-options.html
2. http://docs.openstack.org/trunk/openstack-compute/admin/content/ch_networking.html
3. http://wiki.openstack.org/Quantum
4. Mirrantis 
http://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/
http://www.mirantis.com/blog/openstack-networking-single-host-flatdhcpmanager/"
http://www.mirantis.com/blog/vlanmanager-network-flow-analysis/ 
http://www.mirantis.com/blog/openstack-networking-vlanmanager/
5. IBM OpenStack

High level Openstack software architecture

This is an overwhelming task of tracking code changes for Openstack projects as well as to maintain an up to date view of current software architecture model. As the number of core Openstack projects increase it drives as well as the overall complexity and communication patters between the them.

Below is a nice diagram that through visualization helps to represent the complexities and simplify the communications view between all components in Folscom Openstack release.

Sources

1. http://ken.pepple.info/openstack/2012/09/25/openstack-folsom-architecture/
2. http://ken.pepple.info/openstack/2012/02/21/revisit-openstack-architecture-diablo/

Emerging of the virtual network aka Quantum in Openstack

Since Essex the Quantum has become a core Openstack project that promises to deliver a network as a service in the cloud world that is dominated by the virtual technologies. In practice this should mean that you are able to design and create your own network topology for the VMs you run. Another example is the flexibility of defining virtual interfaces your VM's have and elasticity of configuring what VM's can communicate together.

The virtual network idea is sometimes mentioned together with a Software Defined Network (SDN) concept. Although both technologies promise similar benefits they are not the same. In short the promises they do is an ability to:

• Securely partitioning the network 
• Defining virtual network topologies 
• Automating network provisioning

In this presentation we can see some high as well as low level design slides that present the theory in a more understandable, graphical way: http://www.slideshare.net/danwent/openstack-quantum-intro-os-meetup-32612 .

This document has an excellent slide that shows the power of virtual networks by comparing the end user view with a hardware one: http://qconlondon.com/dl/qcon-london-2012/slides/SalvatoreOrlando_QuantumVirtualNetworksForOpenStackClouds.pdf

Taking a step further this is a list of currently supported plugins for quantum in Essex/Folsom Openstack release. Behind almost every plugin we can see a vendor that is needed to be able to create a salable virtual network infrastructure that supports your VMs: http://wiki.openstack.org/Quantum

• Big Switch Networks Plugin
• Cisco UCS/Nexus Plugin 
• Floodlight OpenFlow Controller Plugin
• Linux Bridge Plugin 
• MidoNet Plugin 
• NEC OpenFlow Plugin 
• Nicira Network Virtualization Platform (NVP) Plugin 
• Open vSwitch Plugin 
• Ryu OpenFlow Controller Plugin