Running OpenStack Icehouse with ZFS Storage Appliance
- by Ronen Kofman
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
