Datera and OpenStack – Part 3

Previously on Datera and OpenStack:

Last time we went over the basics for using OpenStack, snapshots and Datera’s Elastic Data Fabric (EDF). In this post we will cover the concept of Datera’s storage template system.

Templates

So far we’ve been using very vanilla features that any storage solution would have. If a storage product didn’t offer volume creation and snapshots, it would not be a very useful product. Now we’ll get into some of the meat of the EDF system, which is the built-in template engine.

Before we touch on how they integrate into OpenStack, we need to understand what a Datera template is and what we can accomplish by using one.

First lets go make a template. Select “Templates” from the drop-down menu.

_images/template1.pngThen click on “Create New”

_images/template2.png

 

Now we’ll fill out the snapshot policies, QoS, volumes and replicas for the template. In this case we’re creating a template with a single target and a single volume with a 24-hour snapshot policy with 15 snapshot retention, and 3-way replica on the volume. For QoS we’ll set 10 MiB/s bandwidth limitation. Click “Create” when done.

_images/template3.pngThis application template (AT) exists as a top-level object within the EDF. There is no storage or snapshot policies or QoS within the template, it just describes much like a YAML file, what we want when we ask for a “my-new-template” application. You could substitute “Postgres” or “Kafka Cluster” for “my-new-template” to better represent what we’re getting at here. A template is a description of storage rather than the storage itself.

Now a description of storage is useless if we never do something with it. Lets instantiate the template. We can do this by clicking “Provision”.

_images/template4.pngFilling out the name field and clicking “Provision” again

_images/template5.pngThis gets us a new application instance (AI). We describe this instance as “bound” because it is a child of an AT. Conversely, if we were to create an AI without first creating an AT that would be “unbound” since it has no AT parent. If we navigate to the new AI we can see that it posseses all the attributes that we described in the parent AT.

_images/template6.pngOK, so we can do some fancy stuff through our custom UI, how does this relate to OpenStack?

Templates and OpenStack

Let’s go to our devstack cluster we set up in the first blog post. If everything was set up correctly we should have a volume type named datera when we run cinder type-list

$ cinder type-list
+--------------------------------------+--------+-------------+-----------+
| ID                                   | Name   | Description | Is_Public |
+--------------------------------------+--------+-------------+-----------+
| f55c5f90-bb20-4e92-b578-2a8117c03483 | datera | -           | True      |
+--------------------------------------+--------+-------------+-----------+

We can see the contents of this volume-type by running cinder type-show datera

$ cinder type-show datera
+---------------------------------+---------------------------------------------------------------------------------------------------+
| Property                        | Value                                                                                             |
+---------------------------------+---------------------------------------------------------------------------------------------------+
| description                     | None                                                                                              |
| extra_specs                     | {u'volume_backend_name': u'datera'} |
| id                              | f55c5f90-bb20-4e92-b578-2a8117c03483                                                              |
| is_public                       | True                                                                                              |
| name                            | datera                                                                                            |
| os-volume-type-access:is_public | True                                                                                              |
| qos_specs_id                    | None                                                                                              |
+---------------------------------+---------------------------------------------------------------------------------------------------+

We want this volume-type to point at our newly created template. The current Datera EDF cinder driver is configured with an extra-spec key DF:template. We can set this with the following command:

$ cinder type-key datera set DF:template=my-new-template

$ cinder type-show datera
+---------------------------------+---------------------------------------------------------------------------------------------------+
| Property                        | Value                                                                                             |
+---------------------------------+---------------------------------------------------------------------------------------------------+
| description                     | None                                                                                              |
| extra_specs                     | {u'volume_backend_name': u'datera', u'DF:template': u'barcelona_demo'} |
| id                              | f55c5f90-bb20-4e92-b578-2a8117c03483                                                              |
| is_public                       | True                                                                                              |
| name                            | datera                                                                                            |
| os-volume-type-access:is_public | True                                                                                              |
| qos_specs_id                    | None                                                                                              |
+---------------------------------+---------------------------------------------------------------------------------------------------+

Now any cinder volume provisioned with this volume-type will create application instances bound to the my-new-template template.

We can see this in action by creating a cinder volume

$ cinder create 500
+--------------------------------+--------------------------------------+
| Property                       | Value                                |
+--------------------------------+--------------------------------------+
| attachments                    | []                                   |
| availability_zone              | nova                                 |
| bootable                       | false                                |
| consistencygroup_id            | None                                 |
| created_at                     | 2016-10-26T07:41:58.000000           |
| description                    | None                                 |
| encrypted                      | False                                |
| id                             | 61e93d89-2eeb-470b-b58d-d138b119cea7 |
| metadata                       | {}                                   |
| migration_status               | None                                 |
| multiattach                    | False                                |
| name                           | None                                 |
| os-vol-host-attr:host          | None                                 |
| os-vol-mig-status-attr:migstat | None                                 |
| os-vol-mig-status-attr:name_id | None                                 |
| os-vol-tenant-attr:tenant_id   | b92cebb3bdcd491ab9f214355183005c     |
| replication_status             | disabled                             |
| size                           | 500                                  |
| snapshot_id                    | None                                 |
| source_volid                   | None                                 |
| status                         | creating                             |
| updated_at                     | None                                 |
| user_id                        | 52b9edf64cb74da099da5e7afce5a811     |
| volume_type                    | datera                               |
+--------------------------------+--------------------------------------+

$ cinder list
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| ID                                   | Status    | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| 61e93d89-2eeb-470b-b58d-d138b119cea7 | available | -    | 500  | datera      | false    |             |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+

Now we can go over to the EDF UI and see what happened. Firstly our new cinder volume is represented on the backend as a new AI that is bound to my-new-template. We can see this under the template:

_images/template7.pngNow lets attach this AI to a VM and run some data against the block device

$ nova boot testvm --image cfdefc79-e5d3-4ebf-aa40-cc21a0ae376e --flavor 42
+--------------------------------------+----------------------------------------------------------------+
| Property                             | Value                                                          |
+--------------------------------------+----------------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                         |
| OS-EXT-AZ:availability_zone          |                                                                |
| OS-EXT-SRV-ATTR:host                 | -                                                              |
| OS-EXT-SRV-ATTR:hosme                | testvm                                                         |
| OS-EXT-SRV-ATTR:hypervisor_hosme     | -                                                              |
| OS-EXT-SRV-ATTR:instance_name        |                                                                |
| OS-EXT-SRV-ATTR:kernel_id            | f6d6b0a9-775b-4470-bf96-eb165b2a3ff6                           |
| OS-EXT-SRV-ATTR:launch_index         | 0                                                              |
| OS-EXT-SRV-ATTR:ramdisk_id           | 432e9136-3466-40ec-a528-fc9cfbc61d59                           |
| OS-EXT-SRV-ATTR:reservation_id       | r-4o1kkq78                                                     |
| OS-EXT-SRV-ATTR:root_device_name     | -                                                              |
| OS-EXT-SRV-ATTR:user_data            | -                                                              |
| OS-EXT-STS:power_state               | 0                                                              |
| OS-EXT-STS:task_state                | scheduling                                                     |
| OS-EXT-STS:vm_state                  | building                                                       |
| OS-SRV-USG:launched_at               | -                                                              |
| OS-SRV-USG:terminated_at             | -                                                              |
| accessIPv4                           |                                                                |
| accessIPv6                           |                                                                |
| adminPass                            | F3YE6kMkr3s9                                                   |
| config_drive                         |                                                                |
| created                              | 2016-10-26T13:23:19Z                                           |
| description                          | -                                                              |
| flavor                               | m1.nano (42)                                                   |
| hostId                               |                                                                |
| host_status                          |                                                                |
| id                                   | fd7d116d-b594-433b-b30d-51de76b07858                           |
| image                                | cirros-0.3.4-x86_64-uec (cfdefc79-e5d3-4ebf-aa40-cc21a0ae376e) |
| key_name                             | -                                                              |
| locked                               | False                                                          |
| metadata                             | {}                                                             |
| name                                 | testvm                                                         |
| os-extended-volumes:volumes_attached | []                                                             |
| progress                             | 0                                                              |
| security_groups                      | default                                                        |
| status                               | BUILD                                                          |
| tags                                 | []                                                             |
| tenant_id                            | b92cebb3bdcd491ab9f214355183005c                               |
| updated                              | 2016-10-26T13:23:19Z                                           |
| user_id                              | 52b9edf64cb74da099da5e7afce5a811                               |
+--------------------------------------+----------------------------------------------------------------+

$ nova volume-attach testvm 61e93d89-2eeb-470b-b58d-d138b119cea7
+----------+--------------------------------------+
| Property | Value                                |
+----------+--------------------------------------+
| device   | /dev/vdb                             |
| id       | 61e93d89-2eeb-470b-b58d-d138b119cea7 |
| serverId | fd7d116d-b594-433b-b30d-51de76b07858 |
| volumeId | 61e93d89-2eeb-470b-b58d-d138b119cea7 |
+----------+--------------------------------------+

$ ssh cirros@10.24.50.185
cirros@10.24.50.185's password:

$ sudo dd if=/dev/zero of=/dev/vdb bs=1M count=10000

Now lets look at the performance graphs. We can see that we’re getting about 10 MB/s write speed with 12 IOPS with this tiny VM at a 1M block size. Very high latency, but we’re just using dd without direct writes, so that’s expected.

_images/template8.pngLets decrease the bandwith QoS to 2 MB/s in the parent template

_images/template9.pngNow we see a decrease in the performance for the child volume. This is the magic of templates! Every bound AI is affected by changes to the parent template!

_images/template10.png