Operation Troubles

Planning for Lead Time

Another obvious advantage of a complete hardware specification is that orders for the procurement of new hardware can be submitted quickly to suppliers. Planning for lead time is very important: In clouds it is quite possible for a provider to require far more hardware from one day to the next (e.g., because a large customer has joined the platform). Even if the hardware supplier has all the components in stock, delivery and installation can take some time, which makes it all the more important that you can at least know what kind of hardware you need.

No Cloud Without a Net

Once the topics of hardware and infrastructure have been dealt with successfully, OpenStack planners then face the first really unappetizing topic: SDN. In traditional setups in which virtualization is the focus, vendors have hitherto worked with pretty ugly hacks, such as messing around with virtual LANs (VLANs) at the hardware level and then connecting VMs with bridges to the corresponding interfaces at the host level.

This principle no longer works in clouds and is painfully apparent in public clouds, where it is inconceivable for you to create VLANs provider-side on customer request and then use your own virtual network in the cloud. The magic word for clouds is "decoupling," wherein the network hardware of the setup is decoupled from its software. The physical network setup is completely flat; look for VLANs and similar mechanisms in vain. The setup described earlier with Layer 3 routing is a move in the same direction.

The hardware functions are replaced by software: SDN solutions are part of the setup and, in the background, configure virtual extensible LANs (VxLANs) or generic routing encapsulation (GRE) tunnels so that VMs from different customers can run on the same servers without ever seeing each others' traffic. Cloud users click together their entire virtual network topology as they need it. After configuring the setup for the first time, there is no additional overhead for the vendor.

Open vSwitch Default

In the first two articles of the series [1] [4], SDN was not mentioned explicitly because it comes as part of the package with the Juju-MaaS setup. OpenStack Neutron, which manages SDN networks on the OpenStack side, uses Open vSwitch in the default configuration. Because the typical Open vSwitch setup does not have a central switching point, a good deal of overhead traffic takes place between the individual network nodes (e.g., for the ARP protocol). The approach is adequate for small setups, like the one in the second article of the series, but it can create a problem for large environments with more than 20 nodes.

Various vendors from the OpenStack community have recognized the problem and now offer alternatives. The existing solutions are divided into two categories: Most approaches rely on Open vSwitch, but they add additional components to compensate for its deficits. The other camp counters with completely independent solutions – first and foremost OpenContrail [5] by Juniper.