Rackspace has developed a set of OpenStack Block Storage (Cinder) chef recipes, combined into a cookbook, that can be used to configure a Cinder node or group of nodes. This section discusses the concepts and architecture behind Cinder and describes the procedures for configuring Cinder nodes.

Block Storage Overview

The Cinder project provides "block storage as a service" functionality in OpenStack. Beginning in the Folsom release and going forward, it is designed to replace the nova-volumes service.

The Cinder architecture includes the following components:

• API service: Responsible for receiving and handling requests and placing them in the message queue. OpenStack clusters deployed with Rackspace Private Cloud Software will use rabbitmq.
• Scheduler service: Assigns tasks in the queue and determines the volume server to which provisioning requests are sent.
• Volume service: Runs on the storage node and manages the storage space. The volume service can run on multiple nodes, each constituting part of the block storage "pool"; the scheduler service will distribute requests across all nodes that are running the volume service.

With the Rackspace Private Cloud Cinder recipes, you can install the services across multiple nodes or all together on a single node. The Rackspace Private Cloud cookbooks provide convenient chef roles to assist in installing services on nodes. The cinder-api, cinder-scheduler, and cinder-volume roles, when applied to a node, will install the respective services by running the relevant recipes. The cinder-all meta-role includes all three cinder roles.

Adding Volume Storage Nodes

Rackspace Private Cloud Software installs cinder-api and cinder-scheduler on the controller node by default. You will need to add additional cinder-volume nodes to use OpenStack Block Storage on your cluster.

Node Prerequisites

Rackspace recommends that the physical server that will become a Cinder volume node or a Cinder all-in-one node meet the following criteria.

• 1 core per 3TB capacity
• At least 6 SATA or SAS drives of at least 1TB capacity each.
• At least 2GB RAM, plus an additional 250MB RAM per TB of drive.
• RAID Controller with battery backup in RAID5 or RAID10 configuration.

Your environment must meet the following criteria.

• An OpenStack controller node is running Nova controller components and APIs, Glance, Horizon, Keystone, rabbitmq, and MySQL, installed with Rackspace Private Cloud Software.
• At least one node is running nova-compute, and was installed with Rackspace Private Cloud Software.
• A Chef server is available on the cluster. Rackspace Private Cloud Software installs the Chef server on the controller node by default.
• You have the means to install Ubuntu 12.04 on the server where the Cinder node will exist.
• You DO NOT already have a node running nova-volumes in the OpenStack cluster.

Volume Storage Installation

1. Install Ubuntu 12.04 on the server that will become the Cinder volume node.

2. Install and configure chef-client on the new server. The following commands will ensure that the chef-client points to the Chef server on the controller node.

   $ curl -L http://opscode.com/chef/install.sh | bash
   $ mkdir -p /etc/chef
   $ export chef=your_controller_ip
   $ cat > /etc/chef/client.rb <<EOF
       chef_server_url "http://${chef}:4000"
       environment "rpcs"
     EOF
                           

3. On the controller node, locate /etc/chef/validation.pem.

4. Copy this file to /etc/chef/ on the new server.

5. Run chef-client on the new server to register the new server.

   $ rm -fr /etc/chef/client.pem ; chef-client
                           

6. Log into the controller node and switch to root access with sudo -i. Update the cookbooks and roles with the procedure documented in "Update the Cookbooks".

7. Create an LVM volume group on the new server. In this example, the server has a disk that appears as /dev/sdb, and a volume group called cinder-volumes will be created on this disk.

   $ ssh server_ip_address
   $ sudo pvcreate /dev/sdb
   $ sudo vgcreate cinder-volumes /dev/sdb
                           

8. On the controller node, execute the following knife command to add the cinder-volume role to the server. For server_name, substitute the fully qualified domain name of the server, such as cindervolume1.mydomain.com.

   $ knife node run_list add server_name 'role[cinder-volume]'
                           

9. Run chef-client on the server to complete the process.

   $ ssh my.new.server
   $ sudo chef-client
                 

When the procedure is complete, you should receive output similar to the following:

[2012-10-30T10:32:02+00:00] INFO: *** Chef 10.14.2 ***
[2012-10-30T10:32:04+00:00] INFO: Run List is [role[cinder-volume]]
--output truncated--
[2012-10-29T16:23:34+00:00] INFO: Running report handlers
[2012-10-29T16:23:34+00:00] INFO: Report handlers complete
        

When the process is complete, the new Cinder volume node will be ready to use.

Create a Volume

Volumes can be created through the Dashboard or with python-cinderclient. The client is installed by default on the cinder node, but you can install it on your local workstation with the following command:

$ sudo apt-get install python-cinderclient
            

You should also ensure that your workstation's environment variables have been set correctly, as described in Viewing and Setting Environment Variables.

In this example, a volume called myvolume with a size of 1 is created and attached to an instance with python-cinderclient.

$ cinder create --display-name myvolume 1
+---------------------+--------------------------------------+
|       Property      |                Value                 |
+---------------------+--------------------------------------+
|     attachments     |                  []                  |
|  availability_zone  |                 nova                 |
|      created_at     |      2012-10-29T17:16:23.260483      |
| display_description |                 None                 |
|     display_name    |               myvolume               |
|          id         | 845514f9-8fff-44bb-b82a-27d4e32b9939 |
|       metadata      |                  {}                  |
|         size        |                  1                   |
|     snapshot_id     |                 None                 |
|        status       |               creating               |
|     volume_type     |                 None                 |
+---------------------+--------------------------------------+

$ cinder list
+------------------------+-----------+---------+------+--------+---------+
|          ID            |   Status  | Display | Size | Volume | Attached|
|                        |           | Name    |      | Type   | to      |
+------------------------+-----------+---------+------+--------+---------+
| 845514f9[id truncated] | available |myvolume |  1   | None   |         |
+------------------------+-----------+---------+------+--------+---------+

This volume is now available to be attached to a nova instance. For this example, myvolume will be attached to an instance called myserver with the nova volume-attach command. The auto argument allows the Block Storage API to determine how the disk will appear when its information is viewed from within the virtual machine. In this case, Cinder assigns a block device named /dev/vdb to the volume.

$ nova list
+------------------------+----------+--------+----------------------+
| ID                     | Name     | Status | Networks             |
+------------------------+----------+--------+----------------------+
| f947896e[id truncated] | myserver | ACTIVE | public=192.168.100.4 |
+------------------------+----------+--------+----------------------+

$ cinder list
+------------------------+-----------+---------+------+--------+---------+
|          ID            |   Status  | Display | Size | Volume | Attached|
|                        |           | Name    |      | Type   | to      |
+------------------------+-----------+---------+------+--------+---------+
| 845514f9[id truncated] | available |myvolume |  1   | None   |         |
+------------------------+-----------+---------+------+--------+---------+

$ nova volume-attach f947896e-600a-4600-a27a-3f372146b6e9 \
  845514f9-8fff-44bb-b82a-27d4e32b9939 auto
+----------+--------------------------------------+
| Property | Value                                |
+----------+--------------------------------------+
| device   | /dev/vdb                             |
| id       | 0501bc27-5ebd-44f2-8a4a-bb1595ee7e42 |
| serverId | f947896e-600a-4600-a27a-3f372146b6e9 |
| volumeId | 0501bc27-5ebd-44f2-8a4a-bb1595ee7e42 |
+----------+--------------------------------------+
            

The Cinder volume is now attached to myserver.

$ cinder list
+------------------------+-----------+---------+------+--------+------------+
|          ID            |   Status  | Display | Size | Volume | Attached   |
|                        |           | Name    |      | Type   | to         |
+------------------------+-----------+---------+------+--------+------------+
| 845514f9[id truncated] | available |myvolume |  1   | None   | f947896e...|
+------------------------+-----------+---------+------+--------+------------+
            

When you ssh to the instance to which the volume was attached and look up the disk information, you will see the disk information for the block device. In this example, the instance has an IP address of 192.168.100.4.

$ ssh cirros@192.168.100.4
$ sudo fdisk -l /dev/vdb
 
Disk /dev/vdb: 1073 MB, 1073741824 bytes
16 heads, 63 sectors/track, 2080 cylinders, total 2097152 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/vdb doesn't contain a valid partition table    
       

Building a Block Storage All-In-One Node

If you did not use the Rackspace Private Cloud Software installer to create your cluster, and if you did not use the Rackspace single-controller role in a manual configuration, you will need to create a Block Storage node with the cinder-all role. This will create a node with the cinder-api, cinder-scheduler, and cinder-volume roles.

You can also create a block storage all-in-one node following the steps outlined in Adding Volume Storage Nodes, with one change.

In step 8, you will specify the cinder-all role instead of cinder-volume. For server_name, substitute the fully qualified domain name of the server, such as cinder1.mydomain.com.

$ knife node run_list add server_name 'role[cinder-volume]'
                        

When the procedure is complete, you should receive output similar to the following:

[2012-10-30T10:32:02+00:00] INFO: *** Chef 10.14.2 ***
[2012-10-30T10:32:04+00:00] INFO: Run List is [role[cinder-all]]
[2012-10-30T10:32:04+00:00] INFO: Run List expands to [osops-utils::packages, openssh, ntp, sosreport, rsyslog::default, hardware, osops-utils::default, cinder::cinder-api, cinder::cinder-scheduler, cinder::cinder-volume]
--output truncated--
[2012-10-29T16:23:34+00:00] INFO: Running report handlers
[2012-10-29T16:23:34+00:00] INFO: Report handlers complete
            

When the process is complete, the new Cinder all-in-one node will be ready to use.