Volumes

Block Storage Volumes on Wavestack

Similar to compute instances, volumes in Wavestack have specific types. However, there are not as many different volume types as there are instance flavours. Volume types you allow to create volumes with different properties and abilities.

Volume Types on Wavestack

Execute the following openstackclient command to list all currently available volume types:

❯ openstack volume type list

Currently, these types are:

Volume Type	Description
rbd_fast	rbd_fast is our storage class for full flash block storage, based on Ceph RBD. It is a generally usable volume that is specially designed for applications with high input/output requirements. Thanks to the full flash architecture, it enables extremely fast data processing and has very low latencies. For data security and reliability, the data is replicated three times, providing high data redundancy.
LUKS	Similar to rbd_fast, but with automated encryption added on top for enhanced data security.

Volume Type

Description

rbd_fast

rbd_fast is our storage class for full flash block storage, based on Ceph RBD. It is a generally usable volume that is specially designed for applications with high input/output requirements. Thanks to the full flash architecture, it enables extremely fast data processing and has very low latencies. For data security and reliability, the data is replicated three times, providing high data redundancy.

LUKS

Similar to rbd_fast, but with automated encryption added on top for enhanced data security.

Local SSD/NVMe Storage

For quick and low-latency workloads, local SSD/NVMe backed storage is recommended. Choose an SCS-standard flavor with ‘p’ (NVMe) or ’s’ (SSD) at the end of its name. For example, SCS-2V-8-20s signifies 20GB local SSD storage. Be aware that local storage is ephemeral, meaning data gets lost if the instance is deleted. Information on the instances offered can be found here: Instance types

Storage Types / IOPS

Performance attributes differ between storage/disk types, which are summarised in the table below:

Volume Type	Average IOPS	Burst IOPS	Average Throughput	Burst Throughput
rdb_fast	1500	10000	0.25	0.5
ssd	10000	10000	0.75	0.75

Note: With sufficient retrieval size, we can provide more than 15,000 IOPS on volumes. Please contact our support team for more information.

Managing volumes

OpenStack enables the user to manage their data volumes via the Cinder block storage service. Wavestack utilizes one Ceph RBD Cluster in each availability zone to provide decoupled and fast storage for instances.

Creating a volume

Volumes are created by running the following openstackclient command:

❯ openstack create volume --size <size-in-GB> <volume-name>

Omitting the name will create a volume with the same name as its UUID.

If you wish to prevent forensic recovery of your data you must use the encrypted volume type (LUKS) for volume creation.

You can also add further parameters to the cinder volume create command. The following ones are commonly used:

--image specifies which machine image to replicate the volume from
--snapshot specifies which volume snapshot to replicate the volume from
--source specifies which machine image to replicate the volume from

Creating an encrypted volume

To secure user data, volumes can be created with LUKS encryption. OpenStack Barbican makes it easy to automatically create encrypted volumes by utilizing the LUKS volume type:

❯ openstack volume create --size <size-in-GB> --type LUKS <volume-name>

All of the above options and parameters for volume creation still apply.

Deleting a volume

If a volume is no longer needed, simply run openstack volume delete:

❯ openstack delete volume <volume>

To delete the volume. You can also add the --purge parameter to the command to delete all snapshots of the volume.

Extending a volume

Volumes can be easily extended by setting a higher image size:

❯ openstack volume set --size <new-size-in-GB>

Managing volume data

It is quite essential to create snapshots and backups of your volumes to be able to revert data to a previous state.

OpenStack Cinder addresses this by providing the user with the possibility to snapshot and/or backup volumes:

Creating/deleting volume snapshot

It is easy to create a quick snapshot of a volume on the command line. These snapshots can be used to quickly restore a volume to a previous state.

❯ openstack volume snapshot create --volume <volume> <snapshot-name>

A snapshot can even be created of a volume that is currently in use by a running machine.

In some cases creating a snapshot from an attached volume can result in a corrupted snapshot!

Thus, if you want to create such a snapshot, it is required to provide the --force flag to the command.

Creating/deleting volume backup

Volumes as well as volume snapshots can be backed up by utilizing the capabilities of the Cinder-Backup Service. Cinder-Backup saves backups to a pool inside another storage cluster which spans over all 3 availability zones. This way Wavestack ensures backup data high availability.

To create a volume backup, simply run:

❯ openstack volume backup create --name --volume <volume>

Similar to snapshots, you have to provide the --force flag when creating a backup from an in-use volume (i.e. one that is attached to an instance).

For further information on backup options view the OpenStack Docs.

Transferring a volume

It is also possible to transfer your volumes between projects, which allows the user to copy and share data between subprojects within their own organization.

First, a volume transfer request is created:

❯ openstack volume transfer request create <volume-uuid>

This creates a transfer request with an auth-key (printed to your stdout).

You can then get a list of currently pending transfer requests by running:

❯ openstack volume transfer request list

and get the auth-key for a request by running:

❯ openstack volume transfer request show <transfer-id>

This transfer request needs to be accepted by a user authenticated within the other project, providing the transfer request ID and the auth-key:

❯ openstack volume transfer request accept --auth-key <key>  <transfer-request-id>