Red Hat OpenStack Administration I: Core Operations for Domain Operators

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

As the domain operator, you may be asked to advise cloud users about application use cases for legacy server deployments. Cloud users can create system and data volumes as if they are installing bare metal enterprise systems. Those volumes can then be used to launch an instance or be attached to a running instance.

Red Hat OpenStack Platform (RHOSP) supports three types of persistent storage: block, object, and shared. Block storage is based on volumes, which are provided by the Block Storage service. Object storage is based on object containers provided by the Object Storage service. These containers can include folder and file objects, which are managed using the Object Storage service API. Self-service network storage is provided by the Shared File Systems service (Manila). Object Storage is explained in more detail in a later chapter.

The classroom setup uses Ceph for persistent storage. The storage services in OpenStack, such as Cinder, Glance, and Swift, can support various back-end choices, such as hardware storage arrays, local devices, and NAS and SAN solutions. In Ceph, persistent storage is allocated in chunks, called volumes, which are stored in a pool. Ceph stripes block device images across the entire Ceph cluster. The volumes continue to be managed by the Cinder service even when stored on the Ceph cluster.

In OpenStack, the volumes pool is created during overcloud deployment to support the Cinder service.

Block storage, sometimes referred to as volume storage, provides persistent block storage to OpenStack instances. You can create volume-based system boot disks from images and use them to launch instances. Alternatively, you can create data volumes and attach them to running instances.

You can format data volumes with whichever file system is required, to provide persistent storage for an instance. You can also detach data volumes from one instance and attach to another. Data remains intact during this process. For example, if a compute node crashes, you can launch a new instance on another compute node and attach the block storage volume to it, data intact.

You can also attach a volume to several instances using the multiattach volume type. Alternatively, you can add multiple volumes to an instance, extending storage as required.

In RHOSP, block storage, provided by the Block Storage service, supports multiple back ends in the form of drivers. RHOSP provides volume drivers for several supported block storage types, including iSCSI, NFS, and Red Hat Ceph Storage.

The most common use cases for persistent storage include databases and file systems. It would not be effective to use ephemeral storage for either one of those use cases, because the data in a database, for example, must typically be persistent. Block storage is used to store persistent data on devices accessed in the same way as hard drives. Storage persists until it is deleted by a user, unlike ephemeral storage. A block storage volume can also be used to launch a cloud instance, for example when migrating a legacy server.

When migrating legacy applications to a cloud-based platform, two common methods are available. The first method involves moving an application from one environment to another without changing the architecture. This method is often chosen to reduce costs, delaying the need to redesign the application immediately.

The alternative, at one time considered more costly, is to refactor the application before moving it to a cloud environment. After the architecture has been changed to take full advantage of a cloud environment it is then redeployed.

Opinions have changed, however, and companies find that using the first method is more expensive and less efficient. The better approach is to redesign the application before moving it to a cloud environment. Forward planning before moving any non-native cloud application to a cloud environment is essential. If a move starts without sufficient operational design then the resulting move will likely be unsuccessful and more costly in the long run.

The openstack volume command is used to manage volumes using the CLI. The command is followed by arguments, for example create, delete, and show.

[user@demo ~(user)]$ openstack volume create --size 1 demo-volume1

[user@demo ~(user)]$ openstack volume delete demo-volume1

[user@demo ~(user)]$ openstack server add volume demo-server1 demo-volume1

You can create, manage, and delete volumes using the Dashboard.

To create a volume, navigate to Project → Volumes → Volumes and then click Create Volume. In the Volume Name field, enter the name of the volume. Select No source,empty volume, Image, or Volume from the Volume Source list. The Type field defaults to tripleo because TripleO is used to deploy the overcloud. In the Size (GiB) field, enter the size of the volume. The Availability Zone and Group can be left as default. Click Create Volume.

Figure 5.2: Creating a volume in the Dashboard

To manage the volume, navigate to Project → Volumes → Volumes. Several management options are available.

Figure 5.3: Managing a volume in the Dashboard

To attach a volume to an instance, click Manage Attachments to open the Manage Volume Attachments window. In the Attach To Instance field, select the required instance. You can either keep the default Device Name, or choose one. Notice that the status of the volume changes to Reserved, and then In-use.

To remove a volume from an instance, click Manage Attachments. Click Detach Volume and then click Detach Volume to confirm. Notice the status of the volume changes to Available.

Figure 5.4: Detaching a volume in the Dashboard