In early April, OpenStack released the Essex version of its stack software. Citrix, two days prior, announced their release of the CloudStack project under the Apache2 license, creating a genuinely competitive market for open-sourced stack software. We here at Skytap are excited to see this, since it represents a growing maturity and adoption of cloud infrastructure technology.
In this post, I will examine the differentiators between these two technologies on the networking side.
Networking as an Afterthought
OpenStack, prior to Essex, seemed to treat networking as an afterthought of their Nova compute service. In the Nova service, the networking is pretty basic, with your choices in network connectivity being one of the following:
- A Flat LAN model where all guests in all projects are on the same flat layer 2 network. Address management and gateway services are provided outside of the stack.
- A Flat DHCP model where all guests in all projects are on the same flat LAN. The network node acts as a DHCP server and NAT gateway to the rest of the world.
- A Simple VLAN model where each project gets a single VLAN. The network node acts as a DHCP server and NAT gateway to the rest of the world.
For VPN connectivity, a project called CloudPipe provides for a per-project SSL VPN endpoint that can be connected to a remote network like a corporate office or datacenter.
In the Flat networking models, host-based “security groups” are the mechanism for network isolation—a concept that should be familiar to anyone who has used Amazon Web Services. In this case, hosts from multiple tenants are on the same broadcast domain and security groups are required to provide isolation.
Essex and Quantum
With Essex, a new project was released called Quantum. Quantum elevates the network into a service that is a peer with compute and storage. It defines a set of APIs for configuring the layer 2 space, and uses a plug-in architecture to drive the back end implementation. With the Essex release, they support plugins for Cisco’s UCS, the Ryu open source OpenFlow controller, Nicira’s Open vSwitch and Nicira’s NVP controller. This is definitely a step in the right direction as it tends toward what Skytap considers three core tenets of cloud networking:
- Clouds are inherently multi-tenant, and network definition and provisioning should be completely self-service for all users.
- The network should be a service that is independent of the compute service and the underlying hypervisor technology.
- The cloud edge should be a highly dynamic and scalable software controlled service; running on a largely static core network infrastructure.
Unfortunately, Essex didn’t do anything to address the gateway issue. The Quantum software still calls back to Nova to use the network node for the gateway services. The network node is a singleton instance that doesn’t scale in either the control plane or the data plane and is a single point of failure. The Cloudpipe VPN is still largely useless for enterprise class hybrid clouds. We fully expect the Folsom release of OpenStack to address these issues, because this is the part that CloudStack got (almost) right on the money.
Cloudstack’s Layer 2
Let’s first talk about CloudStack’s layer 2 networking. It is fairly underwhelming in that it doesn’t offer much more than what OpenStack did pre-Essex. It doesn’t bother with the Flat LAN model, but implements something similar to the Flat DHCP called “Basic Networking” and a VLAN model called “Advanced Virtual Networking.” There is also an “Advanced Direct” mode for legacy hosting provider integration that we won’t cover here. For the guest networks, you can define, for a given zone, networks that are either “shared” or “isolated.” A shared network is like the OpenStack Flat DHCP model. Like OpenStack, isolation through host-based security groups is necessary for security. An isolated network is one where the guests are separated by VLANs, much like the OpenStack VLAN model.
Advanced networking in CloudStack has some other significant limitations. Networks are generally defined and provisioned by administrators and not available to users as dynamic resources. Generally each account has one large network with a potentially large broadcast domain.
Significant Foresight
Where CloudStack showed some significant foresight was in treating the per-network gateway as a virtual resource that can be scaled out in the data and control plane. In the Advanced Virtual Networking model, CloudStack has a concept of a virtual router per network.This is simply a virtual machine controlled by the cloud management software that implements the gateway services. This is a marked improvement over OpenStack’s Nova network node both in scalability and reliability. Each virtual router is controlled independently and any failures are limited to the network serviced by that router. Having a separate virtual router also enables high availability in the gateway. Openstack also provides additional network services such as load balancing and port forwarding through the virtual routers. For a VPN, CloudStack virtual routers provide an L2TP/IPSec VPN per gateway, which is a small improvement over the CloudPipe VPN in that it’s integrated into the gateway itself. However, since it is per-gateway only, it still does not handle the enterprise-class VPN requirements for site-to-site IPSec connectivity.
Great Strides
Cloud infrastructure is maturing and being adopted at a rapid pace. The announcements of the OpenStack and CloudStack releases are evidence of this. Both of these releases are great strides forward and ones that we are keenly interested in here at Skytap.
In my next blog post, I will discuss the Skytap network solution and how it compares to the OpenStack and CloudStack implementations (a little foreshadowing: we have virtual routers, inter-network routing, and layer2 resource pools).
Feel free to leave comments or questions below if you’d like to open up a discussion.
