Block Storage Cloud
Elizabeth Joseph introduces the concept of block storage and provides example usage. The basics of OpenStack Cinder block storage architecture are explained, and then you are walked through configuration. You then attach a Cinder block storage device to a compute instance, partition it, give it a file system and mount it inside your compute instance so you can add files to it.
This chapter is from the book
This chapter is from the book
This chapter is from the book
The road to the City of Emeralds is paved with yellow brick.
L. Frank Baum, The Wonderful Wizard of Oz
OpenStack provides two popular mechanisms for storage: object and block storage. Block storage is traditionally what you’d mount as a file system on your server. Object storage instead hosts individual files that are then referenced from within your application. In Chapter 9, “Object Storage Cloud,” you learn about why you may want to use object storage with Swift to host files. This chapter covers block storage with Cinder.
Integrated with the rest of OpenStack, Cinder volumes can be created within an OpenStack cloud and then live mounted to a specified instance at the whim of a user. Additionally, you can unmount that volume from one instance and mount it on another with just a few commands.
Uses
One of the strengths of OpenStack is to avoid vendor-lock in, particularly when used in combination with versatile solutions like Cinder. Cinder provides an abstraction layer through the volume manager that hooks in to over 70 different proprietary and open source storage solutions. Additionally, it can be an interface to multiple back ends at once, enabling you to not only diversify your back ends across vendors but also change them out and do a planned migration as your organization sees fit.
Cloud Provider
Whether you’re running a public cloud accessible to customers or a private cloud for use within your organization, offering the capability to extend the given file system requirements in place for the flavors can be a huge benefit.
With the capability to add block storage volumes on the fly, the storage requirements for default compute nodes can be kept small to preserve space for users who want to focus on compute power and give others the flexibility to add the storage they need on the fly. The flexibility to extend storage as needed helps scaling out resources without over-committing beforehand and makes migrations easier if data is kept on a single volume that can be moved to a new compute instance.
Another major benefit is that the compute nodes can be run on throw-away commodity hardware. The data needing to be stored can be either kept on expensive redundant enterprise hardware or on something that has built-in redundancy like Swift. As a result, compute nodes themselves could become independent, throw-away components of your infrastructure, spun up as needed and replaced with identical servers that attach to your storage back ends. Finally, upgrades are also simplified for your customers. If you have a new copy of your system you are testing, you can snapshot the production data from a Cinder volume and then attach it to your test system to see if it works.
Data Processing
Whether you’re a film production company or a research institution, using compute nodes to do data processing and analysis is a common use for cloud-based infrastructures. But where is this data stored and how is it shared in your organization? What do you do when the compute nodes you’re working on run out of space? With Cinder block storage users are able to extend volumes after creation or simply create new volumes as they are needed and attach them to their running instances and mount them in a matter of minutes. Running out of hard drive space on an instance because you have too much data is no longer a problem.
Additionally, if you realize you need more processors or memory, it’s simple to create a new compute instance and move the volume over to the new instance. All your data moves with you to your new server.
Keeping Backups
Making sure your data is backed up and replicated is a common concern, and Cinder offers several options for this. As mentioned earlier, it provides an abstraction layer for dozens of back ends, so you have a lot of options in your environment and on top of that, the different types of backups that Cinder offers.
Many virtualization technologies supported by OpenStack have built in snapshot capabilities, but OpenStack’s block storage also has one. This enables volumes to be backed up as snapshots to other block storage volumes and can be used on its own, using the existing configuration. Whether offered as a backup service by a cloud provider or as an automatic service for users on an OpenStack cloud, this is a valuable service.
You can also clone volumes. Many back ends are smart enough to do a copy-on-write in where zero copying actually happens. The new volume references an existing volume it was cloned from and writes data on top of that. This makes it very fast. Some snapshot features also just do this in the backend, but every vendor solution is implemented differently.
Moving beyond snapshots, Cinder also offers a backup service that enables you to back up your block data to an object store. This helps with the scenario of your entire block storage backend going completely off-line. This backup service more efficient. Differential and incremental backups can be performed and, unlike a snapshot, it is only backing up data that was actually used, not the entire volume and unused bits.
We won’t spend a lot of time on backup scenarios in this chapter. Instead we’ll be focusing on adding volumes in a more instance-focused environment where you’re adding volumes to instances, but they are great options to keep in mind.