Custom Block Storage Back End Deployment Guide

The Red Hat OpenStack Platform Director is a toolset for installing and managing a complete OpenStack environment. It is based primarily on the upstream TripleO (OpenStack-on-OpenStack) project. The Director’s primary objective is to fully orchestrate a functional, Enterprise-grade OpenStack deployment with minimal manual configuration. It helps address many of the issues inherent in manually configuring individual OpenStack components.

The end-result OpenStack deployment provided by the Director is called the Overcloud. The Overcloud houses all the components that provide services to end users, including Block Storage. This document provides guidance on how to deploy custom back ends to the Overcloud’s Block Storage service.

This document presumes existing knowledge of concepts relating to manual Block Storage configuration. In a test deployment of OpenStack (for example, through Packstack), configuring this service involves editing its host node’s /etc/cinder/cinder.conf. Most of the Block Storage settings in that file are documented in better detail elsewhere; this document describes how to apply those same settings to the Overcloud in order to attach a custom back end.

The Block Storage service’s settings are stored in /etc/cinder/cinder.conf; these settings include back end definitions. Most third-party back ends usable with (or even supported by) the Block Storage service provide setup instructions that involve editing /etc/cinder/cinder.conf settings. As mentioned in Section 1, “Introduction”, doing so will configure the Block Storage service; however, those settings will get overwritten in future Overcloud updates.

Regardless, any documentation relating to manual configuration through /etc/cinder/cinder.conf is still useful for Overcloud deployments. The Director, after all, applies the same configuration to /etc/cinder/cinder.conf, albeit through heat. As such, planning the back end configuration requires that you:

Once you map out the resulting /etc/cinder/cinder.conf file, create the environment file that will orchestrate the back end settings. environment file describes this step in greater detail, using the sample file /home/stack/templates/custom-env.yaml. Having the environment file handy will help ensure that the back end settings persist through future Overcloud updates.

The environment file contains the settings for each back end you want to define. It also contains other settings relevant to the deployment of a custom back end. For more information about environment files, see Environment Files (in the Advanced Overcloud Customization guide).

The following sample environment file defines two NetApp back ends, namely netapp1 and netapp2:

parameter_defaults: # 1
  CinderEnableIscsiBackend: false
  CinderEnableRbdBackend: false
  CinderEnableNfsBackend: false
  NovaEnableRbdBackend: false
  GlanceBackend: file # 2

parameter_defaults:
  ControllerExtraConfig: # 3
    cinder::config::cinder_config:
        netapp1/volume_driver: # 4
            value: cinder.volume.drivers.netapp.common.NetAppDriver
        netapp1/netapp_storage_family:
            value: ontap_7mode
        netapp1/netapp_storage_protocol:
            value: iscsi
        netapp1/netapp_server_hostname:
            value: 10.35.64.11
        netapp1/netapp_server_port:
            value: 80
        netapp1/netapp_login:
            value: root
        netapp1/netapp_password:
            value: p@$$w0rd
        netapp1/volume_backend_name:
            value: netapp1
        netapp2/volume_driver: # 5
            value: cinder.volume.drivers.netapp.common.NetAppDriver # 6
        netapp2/netapp_storage_family:
            value: ontap_7mode
        netapp2/netapp_storage_protocol:
            value: iscsi
        netapp2/netapp_server_hostname:
            value: 10.35.64.11
        netapp2/netapp_server_port:
            value: 80
        netapp2/netapp_login:
            value: root
        netapp2/netapp_password:
            value: p@$$w0rd
        netapp2/volume_backend_name:
            value: netapp2
    cinder_user_enabled_backends: ['netapp1','netapp2'] # 7

] describes how to use the environment file xref:envfile[/home/stack/templates/custom-env.yaml to orchestrate the custom back end’s deployment. To see the resulting /etc/cinder/cinder.conf settings from /home/stack/templates/custom-env.yaml, see Section A.2, “Resulting Configuration from Sample Environment File”.

Once you have created the custom-env.yaml file in /home/stack/templates/, log in as the stack user. Then, deploy the custom back end configuration by running:

$ openstack overcloud deploy --templates -e /home/stack/templates/custom-env.yaml

Once the Director completes the orchestration, test the back end. See Section 5, “Test the Configured Back End” for instructions.

After deploying the back ends to the Overcloud, test whether you can successfully create volumes on them. Doing so will require loading the necessary environment variables first. These variables are defined in /home/stack/overcloudrc by default.

To load these variables, run the following command as the stack user:

$ source /home/stack/overcloudrc

Next, create a volume type for each back end. Log in to the Controller node of the Overcloud as the stack user and run the following:

$ cinder type-create backend1
$ cinder type-create backend2

These commands will create the volume types backend1 and backend2, one for each back end defined through the cinder::config::cinder_config class of xref:envfile.

Finally, map each volume type to the volume_backend_name of a back end enabled through the cinder_user_enabled_backends class of xref:envfile. The following commands will map the volume type backend1 to netapp1 and backend2 to netapp2:

$ cinder type-key backend1 set volume_backend_name=netapp1
$ cinder type-key backend2 set volume_backend_name=netapp2

At this point, you should now be ready to test each back end. To do start, create a 1GB volume named netapp_volume_1 on the netapp1 back end by invoking the backend1 volume type:

$ cinder create --volume-type backend1 --display_name netappvolume_1 1

Likewise, create a similar volume on the netapp2 back end by invoking the backend2 volume type:

$ cinder create --volume-type backend2 --display_name netappvolume_2 1