Contents

Synopsis

This article provides instructions for setting up the OpenStack Cinder Service in your Rackspace Private Cloud (RPC) lab environment using the LVM driver.

It also provides some basic commands to verify that your newly installed Cinder service and components are configured and running correctly.

This is specifically for sandbox and testing / development environments – configurations described here, such as: compute and cinder running on the controller, using a loopback device for cinder-volumes and so on are not supported and should not be used in production.

Environment Overview

While this post does not cover RPC installation in detail there are some high level configuration notes provided here to describe the test environment (a link to the full RPC installation documentation is listed in the references section).

You will see that I have a single dedicated chef server and a single controller / compute host in my environment. The hardware is two Rackspace General Purpose Cloud Servers, a 1 GB and an 8 GB flavor respectively. The operating system is Ubuntu 12.04.4 LTS 64-bit server edition and the RPC version is 4.2.2rc. This same process works on 4.x, 4.1x and has a reasonable expectation of continuing to work on future releases with minor adjustments. I’m using a single NIC / network configuration for all services.

You may also notice that instead of using the “all-in-one” role I specify roles individually. The reason I do this is because the “all-in-one” role defaults to nova-network, does not contain heat, and only installs the cinder-scheduler and cinder-api components (not cinder-volume). In my case I want to also run cinder-volume on this node and I am specifying neutron, heat and other components as well just for demonstration purposes.

It’s not quite time to run this command yet however; let’s continue on to complete all of the necessary tasks to prepare for the node deployment.

Environment Preparation – Operating System

The following configuration tasks in this section are to be completed on both chef-1 and controller-1 unless otherwise indicated.

Install the OS

Install the operating system (manually or with an image, snapshot, template, etc.)

Accept all of the installation defaults and once complete run update / upgrade and reboot on both hosts. The git package (required for the initial cookbook and package downloads) should be the only additional package that needs to be installed by hand; the remaining dependencies are installed automatically by the deployment process.

apt-get update
apt-get upgrade
apt-get -y install git
reboot

SSH keys

Chef is capable of handling the ssh key distribution for us; however, as a personal preference, I typically perform this step manually and ensure it’s all working before I install chef. The only requirement is for chef-1 to have ssh pass-thru authentication to controller-1 but there is no harm in having bi-directional pass-thru authentication if that’s preferable.

Some distributions or packaging of openssh do not include the ssh-copy-id command. In this case it’s likely faster and easier to copy the keys by hand vs. installing a modified or recompiled version of openssh. To accomplish this manually you can use these example steps:

If everything worked correctly you should now be able to ssh, as root, from chef-1 to controller-1 without any authentication prompts.

Other settings

Also be sure to setup all of your other basic services and settings. Some of your considerations may include:

Configuring (or disabling) iptables
-If leaving iptables enabled you’ll need to open several ports for RPC to function properly. You can find most of these ports listed in the “api settings” tab for the “security and access” menu on the project tab. They are also listed in the /root/openrc file automatically created during the installation process.TIP: I recommend installing with iptables off to ensure you have a good working deployment and then going back afterwards to lock the ports down.

Ensure name resolution works correctly for both long (FQDN) and short name (hostname -s) references
-/etc/hosts file tends to be the fastest / easiest
-Place the long host names first then any aliases, for example 10.0.20.51 chef-1.yourdomain.local chef-1

Ensure time zones are set correctly and NTP is synchronized on both hosts (particularly important when deploying on top of virtual machines due to hardware clock drift)

Environment Preparation – cinder-volumes

The following configuration tasks are to be completed on controller-1.

We’ll be using the native Linux Volume Manager to provide block storage backing for our environment.

Likewise the cinder LVM driver will be used to connect to this storage.

By design, and due to the custom storage configuration nature – the “cinder-volumes” volume group is not setup by the chef cinder-volume role and must be completed beforehand.

Here are a couple of convenient tips I’ve found for setting up this volume group.

You may have noticed that the default behavior of the Ubuntu server installation (as well as most templates) is to use LVM; however, it typically creates only a single physical volume, a single volume group and also consumes all space on the device.

You can still create the cinder-volumes volume group but you’ll need to either:

Add another disk (which may not be readily available) to be used by cinder-volumes, or:

Reconfigure LVM (which can be tedious):

Resize the logical volumes (typically root and swap) in the existing volume group

Resize the volume group itself

Resize the underlying physical volume

Create a new partition in the newly available space on the disk

Run pvcreate to create a new physical volume for LVM to manage

Run vgcreate cinder-volumes on this newly available physical volume

Optionally I have found that a third method for creating the cinder-volumes group using a loopback device is much faster and easier. This is not optimal for performance but is perfectly suitable for basic, functional testing. You can accomplish this quickly and easily with the following commands which creates a 5 GB cinder-volumes volume group (adjust block size, count, etc. to suit your needs).

TIP: Ensure you have sufficient free space on your /root mount before running this command; accidentally filling up the /root mount will certainly cause issues.

TIP: If creating larger volumes you may want to use the seek option with dd or the fallocate command vs. waiting for each block of data to write out. The cinder service zeros out all blocks regardless when it initializes so there should be no security or stale data concerns.

If everything executed correctly your final output should look similar to this:

Now that our ssh keys are in place, chef server is installed and our cookbooks are downloaded and installed it is time to create an environment file.

Creating the environment file

Your specific environment file will vary but there are a few sections of interest to our installation. The entire environment file is shown in pieces below for your reference; the relevant sections are highlighted.

Create / edit the environment file.

# Open / create the environment file in a text editor, for example
vi rpc422rc.json

Change the header to match what you want the name of the environment to be, for convenience I match the environment name and the file name to the version number. Basic glance settings are also shown here.

Since I’m installing OpenStack on top of a hypervisor that doesn’t support VT acceleration I have to set my virtualization type to qemu; also not suitable for production but sufficient for functional testing. If you have a hypervisor that supports VT acceleration you can leave this stanza out altogether as the cookbook defaults to kvm or you can manually specify it if you like.

Additionally, you may opt to specify your cinder configuration options. The parameters listed here are actually the default settings in the cookbook which works well for this environment; however, I generally specify them regardless in case the defaults change. It is also handy as a placeholder if I reuse the environment file or need to make modifications to the settings later on.

TIP: JSON is very sensitive to white space in formatting so I would recommend pasting this into a text editor first and removing any special characters or, better yet, just type it in manually to avoid parsing errors due to formatting.

TIP: I usually create this file with a text editor and when complete use the “knife environment from file” creation process vs. the “knife environment edit” command (as some documentation refers to). The “knife environment edit” approach will not retain your environment edits if there are issues with syntax or definitions. Instead your edits are lost each time it fails and there is no debug information displayed either.

Environment Deployment

All the tedious work is over, now we push our roles to our controller / compute node with the following command.

TIP: Neutron uses net namespaces, if this is not preferred you can remove neutron and put in nova-network. Everything in this article works the same except for the sections on setting up networking and SSH’ing to your instances .

Conclusion

In this article we covered the basics of a cinder-enabled environment creation and deployment from prerequisites all the way through validation testing.

Hopefully it has provided a good primer for quickly setting up or adding cinder to your lab environment.

Look for future cinder related posts with more advanced topics such as using NetApp, EMC or SolidFire cinder drivers, providing Cinder HA to your instances and using multiple cinder devices to provide workload separation and performance tiering for your instances.

Reference Material

You may also find the following references helpful as you explore cinder functionality further.