Because of the diversity of cloud systems on the markets right now, choosing the right system for your needs can be rather difficult. Often, however, the suffering only really starts once you've left this step behind and chosen OpenStack. After all, OpenStack does not exactly enjoy the reputation of being the best-documented project on the open source scene. The documentation has become a whole lot better recently, not least because of the tenacity of Anne Gentle, the head of the documentation team; however, it still is lacking in some places. For example, it is still missing a document that explains the installation of an OpenStack cloud from installing the packages through setting up the first VM. In this article, I'll take a step-by-step look at setting up an OpenStack cloud.

Don't Panic!

OpenStack might look frightening, but you can use most of its components in the factory default configuration. In this article, I deal with the question of which OpenStack components are necessary for a basic OpenStack installation and how their configuration works. The goal is an OpenStack reference implementation consisting of three nodes: One node is used as the cloud controller, another acts as a node for the OpenStack network service, Quantum, and the third node is a classic hypervisor that houses the virtual machines in the environment.

Required Packages

Also in this article I assume you are using Ubuntu 12.04. But, if you are looking to deploy OpenStack Folsom, the default package source in Ubuntu 12.04 is not very useful because it only gives you packages for the previous version, Essex. Fortunately, the Ubuntu Cloud Team for Precise Pangolin has its own repository with packages for Folsom, which you can install in the usual way. For the installation to work, you need the ubuntu-cloud-keyring package, which contains the Cloud Team's GPG key. Then, add the following entry to /etc/apt/sources.list.d/cloud.list:

deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/folsom main

This step ensures that the required package lists are actually transferred to the system's package manager. The installation of individual packages then follows the usual steps, using tools such as apt-get or aptitude (see the "Prerequisites" box).

The Cloud Network

OpenStack Folsom includes Quantum as the central component for the network. This component helps virtualize networks. For it to fulfill this role, you need some basic understanding of how Quantum works and what conditions must exist on the individual nodes to support the Quantum principle.

In general, the following definition applies: Quantum gives you a collection of networks that supports communication between the nodes themselves and also with the virtual machines. The Quantum developers distinguish between four different network types (Figure 1).

Figure 1: An OpenStack standard setup uses at least four networks, each of which has a special role to play.

The management network is the network that the physical servers in the OpenStack installation use to communicate with one other. This network handles, for example, internal requests to the Keystone service, which is responsible for authentication within the setup. In this example, the management network is 192.168.122.0/24, and all three nodes have a direct connection to this network via their eth0 network interfaces. Here, "Alice" has the IP address 192.168.122.111, "Bob" has 192.168.122.112, and "Charlie" is 192.168.122.113. Additionally, this example assumes that the default route to the outside world for all three machines also resides on this network, and that the default gateway in all cases is 192.168.122.1 (Figure 2).

Figure 2: After creating the networks in Quantum, you have two networks and a router.

On top of this is the data network, which is used by the virtual machines on the compute host (Bob) to talk to the network services on Charlie. Here, the data network is 192.168.133.0/24; Bob has an IP address of 192.168.133.112 on this network and Charlie has 192.168.133.113 – both hosts use their eth1 interfaces to connect to the network. The interfaces also act as bridges for the virtual machines (which will use IP addresses on the private network 10.5.5.0/24 to talk to one another).

Next is the external network: The virtual machines will later draw their public IP addresses from this network. In the absence of genuine public IPs, this example uses 192.168.144.0/25. Because in Quantum, public IP addresses are not directly assigned to the individual VMs (instead, they use the network node and its iptables DNAT rules for access to it), the host for Quantum (i.e., Charlie) needs an interface on this network. Quantum automatically assigns an IP, so Charlie only needs to have an eth2 interface for this. Later in the configuration, Quantum will learn that this is the interface it should use for the public network.

Finally, you have the API network: This network is not mandatory, but it does make the APIs of the OpenStack services available to the outside world via a public interface. The network can reside in the same segment as the external network (e.g., you might have all of the 192.168.144.0/24 network available; at the Quantum level, the public network is then defined as 192.168.144.0/25, and the 192.168.144.129/25 network is available as the API network). If you need the OpenStack APIs to be accessible from the outside, Alice must have an interface with a matching IP on this network.