The OpenStack cloud platform is hot these days. Anyone can set up and run their own private cloud without too much difficulty.
Relatively speaking. You do need a huge chunk of RAM and a respectable amount of disk space, even for a minimal cloud. Also a x64-bit hardware VM capable CPU. But considering what you get, it’s not a bad payoff.
An openstack cloud has 3 types of nodes: control, compute, and storage. You need at least one of each, but a single OS instance can host any combination of them, so the simplest cloud would be an all-in-one server.
First Step
There are quite a number of components that make up these nodes – including some that are plug-replaceable, so the easiest way to get started is to use a springboard. One popular route uses a Vagrant VM to launch the DevStack ready-to-run server. This is a good way to get familiar with OpenStack, since everything’s already pretty much set up and running and you can launch it via VirtualBox on your desktop. Assuming you have at least 8GB RAM to spare, since the DevStack VM is going to eat up about half of that.
Second Step
Running a cloud on your desktop is pretty cool, but if you have aspirations on running a real cloud, you need real servers. Since I didn’t have that many spare servers with sufficient capabilities, the next step I did was again launch OpenStack in a VM, but using a KVM under CentOS 5.11. Why not 6 or 7? Primarily because I have legacy Xen VMs on its siblings and I’m not yet ready to migrate them to an OS that can’t host Dom0.
If you do not allocate sufficient RAM or disk space for the OpenStack VM, it may not install properly and almost certainly won’t work properly, and for the most part you’re not going to get much in the way of helpful messages. OpenStack is comprised of a whole raft of component products and there’s not much in the way of centralized detection and reporting of broken components.
Here’s what I used to create the basic OpenStack VM:
#!/bin/sh VM=icehouse IMAGES=/var/lib/libvirt/images virt-install --name $VM \ --hvm --ram 4096 --cpus 4 \ --disk path=$IMAGES/$VM.img,size=6 \ --network bridge:br0 \ --os-type=linux --os-variant=rhel6 \ --accelerate --vnc -v \ --location=http://10.0.1.3/cobbler/ks_mirror/Centos6.5_x86-64/ \ -x "ks=http://10.0.1.3/cobbler/pub/$VM.ks"
Note that this VM runs the IceHouse release of RDO under Centos 6.5. I tried Juno and CentOS 7, but it kept whining about running out of memory, at least up to about 3GB or so. The network bridge is my VM host’s bridge to the VMs the number of CPUs isn’t important, but I had a few to spare. The kickstart file is nothing special, but it does install and enable ntp and format the disks into a /boot (about 300M) and an LVM partition (everything else), containing a single Logical Volume for the OS.
caution:
A production all-in-one node needs a LOT more disk. You’ll want storage for the client disk images and working permanent storage,
Using PackStack
The PackStack package makes the job of setting up an OpenStack node a lot easier. It fetches the various component packages and uses Puppet to install and configure them. It also creates an “answers” file so you can replay the installation, if needed.
Under CentOS, the easiest way to get things going is to run packstack. My Kickstart had a post-install command to install the Icehouse Yum repository:
rpm -ivh https://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-4.noarch.rpm
So the sequence once the VM came up post-install went like this:
- Install YUM plugin to enforce precedence on repo search/fetch
yum -y install yum-plugin-priorities
- Upgrade the OS
yum -y upgrade
- Reboot to get the latest kernel
reboot
- Install PackStack
yum -y install openstack-packstack
- Run PackStack
packstack --allinone --provision-demo=n
Once all that’s done, with luck, you can open up a web browser on the Openstack console.
Things that can go horribly wrong
The single biggest headache I’ve found with OpenStack is networking. Networking a collection of VMs is a major pain even without clouds. OpenStack raises the ante considerably, since you have 2 options for network stacks (legacy nova network or neutron), and all sorts of real and virtual device/network options. Which, if you’re not already well-read on the subject, you’ll have no clue which ones you should be using or how to set them up.
Beyond that, the most critical functions for OpenStack are the security/identity manager (keystone) and the messaging agent (defaults to rabbitmq, but replaceable). Without the identity manager, nothing can be accessed, without the messaging system, components cannot notify each other about important events. Fortunately, these two are less likely to screw up and appear to be easier to diagnose/repair.
