After completing this section, you should be able to describe the purpose, use cases and storage choices when selecting ephemeral disks for instances.

A cloud environment application should take advantage of cloud environment benefits, such as using the scalability of compute and storage resources in Red Hat OpenStack Platform (RHOSP). By default, RHOSP uses Ceph as the back end for the Block Storage service, but it also supports integration with existing enterprise-level storage systems such as Storage Area Networking (SAN), Network Attached Storage (NAS), and Direct Attached Storage (DAS).

In a physical enterprise environment, servers are typically installed with direct attached storage drives, and use external storage for scaling and resource sharing. In cloud-based instances, virtual disks can be directly attached, and external shared storage is provided as a way to scale the local storage. In a self-service cloud environment, storage is a key resource to be managed so that the maximum number of users can take advantage of it.

Without the Block Storage service, all instance disks are ephemeral, meaning that any storage resources are discarded when the instance is terminated. Ephemeral storage includes block disk devices and swap devices used in a deployed instance.

As a Domain Operator, you should understand the features of persistent and ephemeral storage so that you can advise your OpenStack users.

To scale an instance's storage, provision additional virtual disks using the Block Storage service, Object Storage service, or the Shared File Systems service. Storage resources provided by these services may be persistent; they remain after the instance is terminated. RHOSP supports different storage resources providing persistent storage, including volumes, object containers, and shares.

Block storage uses volumes as its storage unit, which requires that the volume be attached to an instance in order to be accessed. Object storage uses object containers, composed of files and folders, as its storage unit. All objects can be accessed using an API. Object storage does not require an instance to be accessible, but objects can be accessed from inside instances.

The use of block storage in OpenStack depends on the back-end storage infrastructure. Depending on back-end storage performance, the block storage service can be suitable for high throughput use cases. Currently, the OpenStack Block Storage service supports both Red Hat Ceph Storage and NFS as back ends, and provides drivers allowing native interaction with many common SAN vendors. Volumes are directly served from those infrastructures.

Generically, block storage is well suited to the following use cases:

In general, Red Hat recommends the following practices for block storage in OpenStack:

Ephemeral storage resources for an instance are defined by the flavor used to create the instance. OpenStack flavors currently support the definition of three resources, providing non-persistent storage inside of an instance. Those resources are a root disk, an ephemeral disk, and a swap disk. Each of these resources are mapped as devices to the instances, which the cloud-init process configures during the boot process, according to flavor specifications. To properly configure those resources, instances must have access to the metadata service provided by the Compute service.

The back-end Ceph RBD images for the different ephemeral storage resources are created on Ceph when instances are deployed. These RBD images use the instance ID as a prefix to their name. The following RBD images are created when an instance is deployed and its associated flavor has a root disk, an ephemeral disk, and swap memory defined.

Ceph has several pools to support various OpenStack services and their functions.

When an instance is terminated, the back-end RBD images for associated ephemeral storage resources are deleted. This behavior, which is common in cloud computing environments, contrasts markedly with physical servers, where associated local storage is persistent. This supports the cloud computing concept of self-service access to hardware resources, so that unused hardware resources are freed up when they are no longer needed. Instances are designed for use as on-demand processing, with ephemeral storage as a dynamic workspace to facilitate immediate processing. When the processing has finished, the instances and their workspace are no longer needed and the ephemeral storage resources are removed.

Ephemeral storage resources for an instance are defined in the flavor used to create that instance. The size of the root disk, ephemeral disk, and swap disk are defined by a flavor. Although defining a root disk size is mandatory, the ephemeral disk and swap disk are optional. If either disk is defined with a size greater than zero, that disk is created during the instance deployment. Using unnecessarily large ephemeral or swap disks affects the availability of resources on the compute node where an instance is deployed and the optimal usage of cloud resources.

Reviewing an Ephemeral Storage Use Case

Cassandra is an Eventually Consistent database, ideal for distributed architectures. Given that Cassandra is flexible about node loss, each application instance could also be a database node using ephemeral disks. When launched, the instance would join the Cassandra cluster, and replicate data from the existing nodes. This design removes the need for centralized persistent storage, potentially using fast solid state drives on the compute nodes.

The benefits of this design might include:

• No dependency on the performance of, or network bandwidth to a centralized database.

• In the event of a node failure, only the current transaction would be lost.

• Using ephemeral volumes means that there is no requirement to back up the instance, or to attempt recovery if it fails. A monitoring system could delete the failed instance and launch a replacement without human interaction.

Figure 5.1: Cassandra on ephemeral storage