Couple of months ago Oracle announced the support for OpenStack Cinder plugin with ZFS Storage Appliance (aka ZFSSA).  With our recent release of the Icehouse tech preview I thought it is a good opportunity to demonstrate the ZFSSA plugin working with Icehouse.

One thing that helps a lot to get started with ZFSSA is that it has a VirtualBox simulator. This simulator allows users to try out the appliance’s features before getting to a real box. Users can test the functionality and design an environment even before they have a real appliance which makes the deployment process much more efficient. With OpenStack this is especially nice because having a simulator on the other end allows us to test the complete set of the Cinder plugin and check the entire integration on a single server or even a laptop. Let’s see how this works

Installing and Configuring the Simulator

To get started we first need to download the simulator, the simulator is available here, unzip it and it is ready to be imported to VirtualBox. If you do not already have VirtualBox installed you can download it from here according to your platform of choice.

To import the simulator go to VirtualBox console File -> Import Appliance , navigate to the location of the simulator and import the virtual machine.

When opening the virtual machine you will need to make the following changes:

- Network – by default the network is “Host Only” , the user needs to change that to “Bridged” so the VM can connect to the network and be accessible.

- Memory (optional) – the VM comes with a default of 2560MB which may be fine but if you have more memory that could not hurt, in my case I decided to give it 8192

- vCPU (optional) – the default the VM comes with 1 vCPU, I decided to change it to two, you are welcome to do so too.

And here is how the VM looks like:

Start the VM, when the boot process completes we will need to change the root password and the simulator is running and ready to go.

Now that the simulator is up and running we can access simulated appliance using the URL https://<IP or DNS name>:215/, the IP is showing on the virtual machine console. At this stage we will need to configure the appliance, in my case I did not change any of the default (in other words pressed ‘commit’ several times) and the simulated appliance was configured and ready to go.

We will need to enable REST access otherwise Cinder will not be able to call the appliance we do that in Configuration->Services and at the end of the page there is ‘REST’ button, enable it. If you are a more advanced user you can set additional features in the appliance but for the purpose of this demo this is sufficient. One final step will be to create a pool, go to Configuration -> Storage and add a pool as shown below the pool is named “default”:

The simulator is now running, configured and ready for action.

Configuring Cinder

Back to OpenStack, I have a multi node deployment which we created according to the “Getting Started with Oracle VM, Oracle Linux and OpenStack” guide using Icehouse tech preview release. Now we need to install and configure the ZFSSA Cinder plugin using the README file. In short the steps are as follows:

1. Copy the file from here to the control node and place them at: /usr/lib/python2.6/site-packages/cinder/volume/drivers/zfssa

2. Configure the plugin, editing /etc/cinder/cinder.conf

# Driver to use for volume creation (string value)

#volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver

volume_driver=cinder.volume.drivers.zfssa.zfssaiscsi.ZFSSAISCSIDriver

zfssa_host = <HOST IP>

zfssa_auth_user = root

zfssa_auth_password = <ROOT PASSWORD>

zfssa_pool = default

zfssa_target_portal = <HOST IP>:3260

zfssa_project = test

zfssa_initiator_group = default

zfssa_target_interfaces = e1000g0

3. Restart the cinder-volume service: service openstack-cinder-volume restart

4. Look into the log file, this will tell us if everything works well so far. If you see any errors fix them before continuing.

5. Install iscsi-initiator-utils package, this is important since the plugin uses iscsi commands from this package:

yum install -y iscsi-initiator-utils

The installation and configuration are very simple, we do not need to have a “project” in the ZFSSA but we do need to define a pool.

Creating and Using Volumes in OpenStack

We are now ready to work, to get started lets create a volume in OpenStack and see it showing up on the simulator:

#  cinder create 2 --display-name my-volume-1

+---------------------+--------------------------------------+

|       Property      |                Value                 |

+---------------------+--------------------------------------+

|     attachments     |                  []                  |

|  availability_zone  |                 nova                 |

|       bootable      |                false                 |

|      created_at     |      2014-08-12T04:24:37.806752      |

| display_description |                 None                 |

|     display_name    |             my-volume-1              |

|      encrypted      |                False                 |

|          id         | df67c447-9a36-4887-a8ff-74178d5d06ee |

|       metadata      |                  {}                  |

|         size        |                  2                   |

|     snapshot_id     |                 None                 |

|     source_volid    |                 None                 |

|        status       |               creating               |

|     volume_type     |                 None                 |

+---------------------+--------------------------------------+

In the simulator:

Extending the volume to 5G:

# cinder extend df67c447-9a36-4887-a8ff-74178d5d06ee 5

In the simulator:

Creating templates using Cinder Volumes

By default OpenStack supports ephemeral storage where an image is copied into the run area during instance launch and deleted when the instance is terminated. With Cinder we can create persistent storage and launch instances from a Cinder volume. Booting from volume has several advantages, one of the main advantages of booting from volumes is speed. No matter how large the volume is the launch operation is immediate there is no copying of an image to a run areas, an operation which can take a long time when using ephemeral storage (depending on image size).

In this deployment we have a Glance image of Oracle Linux 6.5, I would like to make it into a volume which I can boot from. When creating a volume from an image we actually “download” the image into the volume and making the volume bootable, this process can take some time depending on the image size, during the download we will see the following status:

# cinder create --image-id 487a0731-599a-499e-b0e2-5d9b20201f0f --display-name ol65 2

# cinder list

+--------------------------------------+-------------+--------------+------+-------------+

|                  ID                  |    Status   | Display Name | Size | Volume Type | …

+--------------------------------------+-------------+--------------+------+-------------

| df67c447-9a36-4887-a8ff-74178d5d06ee |  available  | my-volume-1  |  5   |     None    | …

| f61702b6-4204-4f10-8bdf-7da792f15c28 | downloading |     ol65     |  2   |     None    | …

+--------------------------------------+-------------+--------------+------+-------------+

After the download is complete we will see that the volume status changed to “available” and that the bootable state is “true”.

We can use this new volume to boot an instance from or we can use it as a template. Cinder can create a volume from another volume and ZFSSA can replicate volumes instantly in the back end. The result is an efficient template model where users can spawn an instance from a “template” instantly even if the template is very large in size.

Let’s try replicating the bootable volume with the Oracle Linux 6.5 on it creating additional 3 bootable volumes:

# cinder create 2 --source-volid f61702b6-4204-4f10-8bdf-7da792f15c28 --display-name ol65-bootable-1

# cinder create 2 --source-volid f61702b6-4204-4f10-8bdf-7da792f15c28 --display-name ol65-bootable-2

# cinder create 2 --source-volid f61702b6-4204-4f10-8bdf-7da792f15c28 --display-name ol65-bootable-3

# cinder list

+--------------------------------------+-----------+-----------------+------+-------------+----------+-------------+

|                  ID                  |   Status  |   Display Name  | Size | Volume Type | Bootable | Attached to |

+--------------------------------------+-----------+-----------------+------+-------------+----------+-------------+

| 9bfe0deb-b9c7-4d97-8522-1354fc533c26 | available | ol65-bootable-2 |  2   |     None    |   true   |             |

| a311a855-6fb8-472d-b091-4d9703ef6b9a | available | ol65-bootable-1 |  2   |     None    |   true   |             |

| df67c447-9a36-4887-a8ff-74178d5d06ee | available |   my-volume-1   |  5   |     None    |  false   |             |

| e7fbd2eb-e726-452b-9a88-b5eee0736175 | available | ol65-bootable-3 |  2   |     None    |   true   |             |

| f61702b6-4204-4f10-8bdf-7da792f15c28 | available |       ol65      |  2   |     None    |   true   |             |

+--------------------------------------+-----------+-----------------+------+-------------+----------+-------------+

Note that the creation of those 3 volume was almost immediate, no need to download or copy, ZFSSA takes care of the volume copy for us.

Start 3 instances:

# nova boot --boot-volume a311a855-6fb8-472d-b091-4d9703ef6b9a --flavor m1.tiny ol65-instance-1 --nic net-id=25b19746-3aea-4236-8193-4c6284e76eca

# nova boot --boot-volume 9bfe0deb-b9c7-4d97-8522-1354fc533c26 --flavor m1.tiny ol65-instance-2 --nic net-id=25b19746-3aea-4236-8193-4c6284e76eca

# nova boot --boot-volume e7fbd2eb-e726-452b-9a88-b5eee0736175 --flavor m1.tiny ol65-instance-3 --nic net-id=25b19746-3aea-4236-8193-4c6284e76eca

Instantly replicating volumes is a very powerful feature, especially for large templates. The ZFSSA Cinder plugin allows us to take advantage of this feature of ZFSSA. By offloading some of the operations to the array OpenStack create a highly efficient environment where persistent volume can be instantly created from a template.

That’s all for now, with this environment you can continue to test ZFSSA with OpenStack and when you are ready for the real appliance the operations will look the same.

@RonenKofman