When you set up an open source virtual infrastructure -- based on Xen or KVM -- your network cannot be the single point of failure. Luckily, there are several options for configuring
When setting up network redundancy, consider bond devices and virtual bridge devices. Bond devices allow you to place different network interfaces into one big trunk, creating basic network redundancy. But in virtual environments, bond devices aren't enough. Configuring a virtual bridge is mandatory for all open source virtual infrastructures.
How a virtual bridge creates network redundancy
A virtual bridge works like an embedded switch that is present virtually on that virtual machine (VM) host. All the VMs, and the host itself, are connected to the virtual bridge, which is connected to a physical Ethernet device.
When setting up a virtual bridge, you have several options. On the surface, the easiest scenario is when your host machine has only one network card. In this case, set up the bridge to connect to that single network card, then connect all VMs to the virtual bridge. It is an easy-to-understand configuration, but it poses one major problem: You have a single point of failure. If the network card goes down, everything goes down.
Fortunately, most -- if not all -- host servers are configured with more than one network card. In these cases, you have two decisions to make. First, you need to choose between using a bond device with one virtual bridge and combining a bond device with multiple virtual bridges. Second, decide where you want to create network redundancy: in VMs or on a host.
Network redundancy options
If you just want bandwidth and don't need to make distinctions between different VMs, creating a bond device and connecting it to one virtual bridge is the easiest approach. You'll first create a new network interface using the bond driver and put all network cards on your system into this new device. The device, in turn, uses these various network cards to increase bandwidth and network redundancy.
For even greater redundancy and better management, create a virtual bridge and attach it to all VMs. But the disadvantage of this approach is that there is no way to distinguish different VMs' bandwidth needs.
To solve this problem, the best approach is to use several bridges. When setting up a VM, decide which virtual bridge to connect it to. If you have more than one bridge on your host, you can group VMs on specific bridges.
For instance, if you have eight different VMs running on a host, and one or two VMs have high bandwidth needs, you can create a dedicated virtual bridge for these VMs and put all other VMs on another bridge. This approach ensures that the bandwidth of a specific bridge is accessible by only certain VMs.
As in the other scenarios, you can choose between using a normal network card or a bonding device to set up the bridges in this configuration. But for redundancy purposes, it's best to use a bond device for your bridges at all times.
If you want to create network redundancy in VMs themselves, you can connect a VM to two bridges at the same time and put the virtual network cards in the VMs in a bonding device. This situation works, but it's not an easy-to-manage solution. If your infrastructure grows to dozens of VMs, it becomes increasingly difficult to keep track of where you have done what. It's better to apply the redundancy to hosts instead.
Sander van Vugt is an independent trainer and consultant based in the Netherlands. Van Vugt is an expert in Linux high availability, virtualization and performance and has completed several projects that implement all three. He is also the writer of various Linux-related books, such as Beginning the Linux Command Line, Beginning Ubuntu Server Administration and Pro Ubuntu Server Administration.
This was first published in June 2010