Understanding and configuring the physical connections of a host in a CloudStack deployment can at first be very confusing. While Software Defined Networking (SDN) is set to greatly simplify some aspects, its integration within CloudStack is not fully mature yet and it won’t be the right solution for everyone.
In this article, Paul Angus, Cloud Architect at ShapeBlue, the cloud specialists, unravels some of the areas which can cause confusion in CloudStack’s physical networking architecture.
Let’s Get Physical: Physical vs. Logical Hosts
One source of confusion is that when people refer to a ‘host’ in the CloudStack world they could be referring to two different things – the physical host and the ‘host’ that CloudStack communicates with. The physical host is understandably the physical box with processors, memory and network interfaces etc. The host CloudStack communicates with (over the management network) is the hypervisor within that physical host. So as an example, public traffic needs to be connected to the physical host (so the system VMs can connect out) but not to the logical host (the hypervisor).
The first determining factor in your physical network topology will be the type of zone you will be implementing. Let’s consider CloudStack’s ‘basic’ and ‘advanced’ zones from a physical networking point of view.
Basic Zones
In a basic zone you only have one ‘physical network’ because you have no VLAN separation, however you can still split traffic across multiple physical NICs (more on this later)
Basic zones can also only have one guest network and no public network.
Advanced Zones
In an advanced zone CloudStack allows for a public network and the creation of multiple guest networks, both physically and logically (usually using tagged VLANs).
Use cases for additional physical guest networks could be to create physically separate links from the hosts to a non-CloudStack network segment in a datacentre – for instance an MPLS network
Other use cases could be to enable dedicated guest networks which are only used by certain domains or accounts, or to provide higher performing guest networks, for example 10Gb links vs 1Gb links.
Network Labels
The most important part of this configuration are the network labels. For an ESXi host they refer to the names of the vSwitches on the hosts, for KVM hosts they refer to the bridges which you will have created and for XenServer hosts they simply refer to the network labels on the host for each of the interfaces or bonds.
The network labels tell CloudStack which physical network interfaces in the host to connect the various virtual interfaces on the guest and system instances to. The SSVM for instance has interfaces on the public, private, storage and management networks and it’s important that these are connected to the correct virtual networks within the hosts, which in turn connect to the physical networks. The actual names/labels can be anything you like – but it’s always good practice to call them something which reminds you which one is which.
Storage Traffic
Of the different CloudStack traffic types, storage traffic always causes the most confusion. The terms ‘storage traffic’ and ‘storage network’ are referring to secondary storage traffic, snapshots (backups), ISOs and templates are all transferred to/from secondary storage over this network.
By default, CloudStack primary and secondary storage traffic travels over the management network. Secondary storage traffic can be configured to travel over a separate network (the storage network) to the management network (there are ways to separate primary storage traffic at the hypervisor level – but that’s another blog).
The main benefits in separating secondary storage and management traffic (and therefore primary storage from secondary storage traffic) are seen when creating a guest instance, as the template is copied from secondary storage to primary storage and when taking a snapshot, as the disk image is copied from primary storage to secondary storage.
Basic Network Traffic
In a ‘basic’ network all of the traffic would go over the same interface(s) and each traffic type would have the same network label. This is not recommended.
The management, storage and guest traffic can be separated by having separate physical interfaces for them on the hosts and referencing them with different labels. You could now either have them connected to the same switch, different switches or the same switch but on different untagged VLANs. Connecting them to the same switch gives additional throughput to/from the hosts.
Connecting the interfaces to different VLANs (configured at the switch level) [figure 6] gives additional throughput and security as the guest traffic can be kept separated from the management and storage traffic. It’s considered best practice to have the guest traffic going through a separate interface on the hosts to the management traffic in a basic zone configuration – requiring a minimum of two interfaces per host.
Advanced Network Traffic
In an advanced network CloudStack can separate traffic logically through the use of VLAN tagging. In some ways separation is easier to configure than in basic networking, as you simply need to set the ports on your switches to trunk all of the VLANs you are using, en-masse.
However you would still want to separate traffic physically for increased throughput and potentially increased security. Again this is done through mapping the network label for each physical interface you will be using to the traffic type you wish to travel through that interface.
Inside the Host
Bringing this all together, a combined logical and physical diagram of the networking of an advanced zone host, which has two network interfaces, would look like this:
Summary
This article has explained the key concepts and terminology, essential to configuring physical networking within a CloudStack deployment for both ‘basic’ and ‘advanced’ zones. In particular this article has demonstrated how the various CloudStack traffic types travel within the physical network.
Look out for a future accompanying article covering the separation of primary storage traffic from other CloudStack traffic.
About the author
Paul Angus is a Senior Consultant & Cloud Architect at ShapeBlue, The Cloud Specialists. He has designed numerous CloudStack environments for customers across 4 continents, based on Apache Cloudstack and Citrix Cloudplatform.
When not building Clouds, Paul likes to create scripts that build clouds……..and he very occasionally can be seen trying to hit a golf ball.
Steve is ShapeBlue’s COO and is responsible for all day-to-day administrative and operational functions of the business, including the consulting, programme management, and support functions.
Involved with CloudStack since 2012, Steve has led several large customer engagements including a number of major public and private cloud deployments; co-ordinated and developed worldwide teams and helped implement and deliver an enterprise grade support product.
Prior to ShapeBlue, Steve held senior technical, project and account management roles in enterprise IT outsourcing companies where he gained domain experience in the finance, professional services and defence markets.
Away from work, Steve is a father, keen guitarist, snowboarder and singer (not necessarily in that order).
Away from work, Steve is a music lover and semi-professional musician. Although he doesn’t speak at many technology conferences, he can sometimes be heard providing the evening entertainment.
ShapeBlue
