Selecting the right storage backend for your OpenStack cloud.

Embracing OpenStack or any other Infrastructure-As-A-Service (IaaS) platform should not be the only decision to take on the road to building your private cloud. Selecting the right cloud components like server hardware, network (architecture and topology), and storage backend is crucial to creating an OpenStack cloud architecture that will meet your needs.
In this article, I will discuss what are the considerations to take when choosing the storage backend for your OpenStack cloud.

What could go wrong

First, let's discuss what could be the pitfalls of selecting the wrong storage backend for your OpenStack cluster:

1. Performance problems: You will most likely have performance issues if your storage does not provide the necessary IO for your cluster workload. This will impact your application directly.

2. Operational issues: If your storage selection can increase the workload of your operations team. Particularly if this storage backend is difficult to maintain, backup and repair.

3. Non-reliable storage: This directly translates to not having a reliable cluster. Data reliability should be a TOP priority while architecting your private cloud.

4. High costs: Cost is and always should be a key factor in any IT decision. If you select a storage platform that increases your total cost of ownership and does not suit the workloads and SLAs of your private cloud you are most likely wasting valuable resources.

Storage on OpenStack

Now that we now what could go wrong if you take the wrong decision while selecting the storage backend, let's dive in how storage works on OpenStack.
There are 3 common storage functions in OpenStack, and each one is performed by a different service, these are:

• Image storage
• Volume storage
• Ephemeral storage

Image storage:

The Image service (Glance) is responsible to for storing virtual machine disk images and maintaining a registry of metadata about those images. Nova (Compute) makes use of this service during instance provisioning by retrieving this image in order to launch the instances.The most common storage backends for Glance are:

• File system backend (usually a file system mount on /var/lib/glance/images/).
• NFS share
• Swift (it’s a common use case to use the object storage service as a Glance backend)
• Ceph RBD

Volume storage:

The Volume service (Cinder) is responsible for providing persistent block storage to running instances. By design, Cinder’s pluggable driver architecture facilitates the creation and management of block storage devices using multiple backends. Here are the most common storage backends for Cinder:

• NFS
• Ceph RBD
• Local Disk (LVM)
• and multiple other vendor drivers to use SAN/NAS with Cinder, for a complete list of current supported drivers, go to https://wiki.openstack.org/wiki/CinderSupportMatrix

Ephemeral storage:

The Compute service (Nova) uses ephemeral storage by default for the instances data, what means is that if your data is not backed by a Cinder volume, it will reside on the compute node’s ephemeral storage pool. Here are the most common storage backends for Nova:

• NFS
• Ceph RBD
• Local file system

Choosing the right storage for OpenStack

At this point, we know some of the implications of choosing the wrong backend for your OpenStack cloud and also how the different OpenStack services handle storage. The task of selecting the right backend for your cloud will be comprised of multiple decision points. Here are a few of the things to consider in this process:

1. Use case: Don’t get lost on the technology, remember that everything should be around the use cases that you are trying to resolve with your OpenStack cluster.

2. Cost: When evaluating the cost of the storage backend you could consider evaluating multiple vendors and what will be that cost per IOPS, per GB and the operational cost for each solution. Cost is not a simple thing and everything matters, from acquisition costs to TCO (total cost of ownership). A low TCO will impact how quickly the business could get the return on investment (ROI).

3. Performance: When talking performance on a storage system, we must consider two main things:

• IOPS: This metric determines the Input/Output Operations per Second that the storage can sustain. In a nutshell, measures the total number of transactions being processed through a system every second. One important thing to know is that IOPS is not the only metric to consider while evaluating the system performance. However, along with total capacity, the amount of IOPS that you will get from your storage solution will be the largest factor in the price of the solution.
• Latency: In my opinion storage latency nowadays is an even more important metric when selecting a storage backend than IOPS. Latency is a measure of the time required for a sub-system or a component in that sub-system to process a single storage transaction or data request. This metric is not only related to the time to process the transaction on the disk, but also the time that will take the transaction navigate through the connectivity layer (SCSI, FIBRE, iSCSI, TCP, PCIe, etc.).

4. Protocol and connectivity type: Selecting the right protocol for your storage will not only directly influence cost but also performance.

5. Capacity: There’s not much to say about capacity; this is probably the simplest factor to consider. At the end, the decision should be taken considering two things: how much capacity is needed to accommodate your solution and grow and what is the cost per GB or TB.

6. Scalability: How scalable is your system and how easy is to expand it to respond not only to capacity requirements but also to performance requirements.

7. Software requirements: Just because it is the last on the list doesn’t mean that is the least important. Understanding your OpenStack software requirements is essential to select the right storage backend. Here are some questions that you could ask yourself to help you get to the right decision:

• Are we deploying a high available control plane? If the answer to this question is yes, then you will need shared storage for your deployment. Most common share storage for OpenStack is Ceph RBD and NFS.

• Is instance live migration a requirement? If you answer yes to this question, you will need share storage for ephemeral storage in order to allow you migrate workloads between the nova compute nodes.

• Is my SAN/NAS compatible with OpenStack? If you are trying to re-use a SAN/NAS with OpenStack you need to check compatibility of the storage device with Cider.

• Is high performance a requirement of my application? If you have a storage intensive application, then you need to look to a backend for Cinder and/or Nova that match the IOPS and latency requirements. Besides that, you may need to look that the storage protocol and connectivity match the high-performance requirements.

It’s important to remember that every OpenStack cluster, use case and application are different. There is not an universal answer to the storage question in OpenStack clouds.

If you have any advice or opinion about this topic, please feel free to add your comment to start a conversation and thank you for reading!