Deploying Pure Storage FlashArray Cinder driver in a Red Hat OpenStack Platform 16.2

Overview

This guide shows how to configure and deploy the Pure Storage FlashArray Cinder driver in a Red Hat OpenStack Platform (RHOSP) 16.2 Overcloud, using RHOSP Director. After reading this, you’ll be able to define the proper environment files and deploy single or multiple FlashArray Cinder back ends in RHOSP Overcloud Controller nodes.

Note

For more information about RHOSP, please refer to its documentation pages.

Warning

RHOSP16.2 is based on OpenStack Train release. Features included after Train release are not available in RHOSP16.2.

Requirements

In order to deploy Pure Storage FlashArray Cinder back ends, you should have the following requirements satisfied:

  • Pure Storage FlashArrays deployed and ready to be used as Cinder back ends. See FlashArray Prerequisites for more details.

  • RHOSP Director user credentials to deploy Overcloud.

  • RHOSP Overcloud Controller nodes where Cinder services will be installed.

Deployment Steps

Prepare the environment files

RHOSP makes use of TripleO Heat Templates (THT), which allows you to define the Overcloud resources by creating environment files.

To ensure that your RHOSP environment is correctly configured for using Pure Storage FlashArrays obtain a copy of pure-temp.yaml and cinder-pure-config.yaml and save these in the /home/stack/templates directory. These will be required when deploying the Overcloud.

Multiple back end configuration

Define Pure Storage Cinder back ends using Custom THT Configuration syntax. It’s possible to define all the back ends in a single environment file by modifying the cinder-pure-config.yaml file as follows:

parameter_defaults:
  CinderPureBackendName:
    - tripleo_pure_1
    - tripleo_pure_2
  CinderPureSanIp: '' # Placeholder
  CinderPureAPIToken: '' # Placeholder
  CinderPureStorageProtocol: 'iSCSI' # Default value for all Pure backends
  CinderPureUseChap: false # Default value for the Pure backends
  CinderPureMultiConfig:
    tripleo_pure_1:
      CinderPureSanIp: '10.0.0.1'
      CinderPureAPIToken: 'secret'
    tripleo_pure_2:
      CinderPureSanIp: '10.0.0.2'
      CinderPureAPIToken: 'anothersecret'
      CinderPureUseChap: true # Specific value for this backend

Modify the parameter values according to your Pure Storage back end configuration.

Note

You can define arbitrary Custom THT Configurations using the following syntax:

parameter_defaults:
  ControllerExtraConfig:
    cinder::config::cinder_config:
      <backend_name>/<configuration_name>:
        value: <value>

Each configuration will be rendered in cinder.conf file as:

[backend_name]
configuration_name=value

See Optional Cinder Configuration Attributes (RHOSP16) for a complete list of the available Cinder Configuration Options.

Warning

RHOSP16.2 is based on OpenStack Train release. Features and Configuration Options included after Train release are not available in RHOSP16.2.

Use Certified Pure Storage Cinder Volume Container

Red Hat requires that you utilize the Certified Pure Storage Cinder Volume Container when deploying RHOSP16.1 with a Pure Storage FlashArray backend.

This container can be found in the Red Hat Container Catalog and should be stored in a local registry.

Alternatively, you may build your own version of this container and store it within a local registry.

Follow these steps to build your own version of the Pure Storage Cinder Volume container:

  • Obtain a copy of the Dockerfile

  • Login to the Red Hat registry

sudo buildah login registry.redhat.io

  • Build the podman image

sudo buildah bud . -t "openstack-cinder-volume-pure:latest"

  • Push the new image to a local registry

sudo openstack tripleo container image push --local <registry:port>/<directory>/openstack-cinder-volume-pure:latest

Create a Custom Environment File

Create a new environment file custom_container_pure.yaml in the directory /home/stack/templates with only the custom container parameter.

parameter_defaults:
  ContainerCinderVolumeImage: <registry:port>/<directory>/openstack-cinder-volume-pure:latest

Alternatively, you may edit the container images environment file (usually overcloud_images.yaml, created when the openstack overcloud container image prepare command was executed) and change the appropriate parameter to use the custom container image.

Deploy Overcloud

Now that you have the Cinder back end environment files defined, you can run the command to deploy the RHOSP Overcloud. Run the following command as the stack user in the RHOSP Director command line, specifying the YAML file(s) you defined:

 (undercloud) [stack@rhosp-undercloud ~]$ openstack overcloud deploy \
 --templates \
 -e /home/stack/cinder-pure-config.yaml \
 -e /home/stack/containers-prepare-parameter.yaml \
 -e /home/stack/templates/custom_container_pure.yaml \
 --stack overcloud

If you modified the container images environment file the custom_container_pure.yaml option is not required in the above command.

Note

Alternatively, you can use --environment-directory parameter and specify the whole directory to the deployment command. It will consider all the YAML files within this directory:

 (undercloud) [stack@rhosp-undercloud ~]$ openstack overcloud deploy \
 --templates \
 -e /home/stack/containers-prepare-parameter.yaml \
 --environment-directory /home/stack/templates \
 --stack overcloud

Test the Deployed Back Ends

After RHOSP Overcloud is deployed, run the following command to check if the Cinder services are up:

[stack@rhosp-undercloud ~]$ source ~/overcloudrc
(overcloud) [stack@rhosp-undercloud ~]$ cinder service-list

Run the following commands as stack user in the RHOSP Director command line to create the volume types mapped to the deployed back ends:

[stack@rhosp-undercloud ~]$ source ~/overcloudrc
(overcloud) [stack@rhosp-undercloud ~]$ cinder type-create pure1
(overcloud) [stack@rhosp-undercloud ~]$ cinder type-key pure1 set volume_backend_name=tripleo_pure_1
(overcloud) [stack@rhosp-undercloud ~]$ cinder type-create pure2
(overcloud) [stack@rhosp-undercloud ~]$ cinder type-key pure2 set volume_backend_name=tripleo_pure_2

Make sure that you’re able to create Cinder volumes with the configured volume types:

[stack@rhosp-undercloud ~]$ source ~/overcloudrc
(overcloud) [stack@rhosp-undercloud ~]$ cinder create --volume-type pure1 --name v1 1
(overcloud) [stack@rhosp-undercloud ~]$ cinder create --volume-type pure2 --name v2 1

Special Cases

LUN Count > 255

When the number of LUNs presented to a Nova compute host, or more specifically the LUN ID exceeds 255, the Purity operating system in the FlashArray will switch the LUN ID addressing from peripheral to flat, using the SAM-4 01b method.

Which Red Hat Enterprise Linux can deal with this addressing change and LUN ID of 256 and higher will correctly mount manually, there is an issue in OpenStack that prevents these LUN ID values from being correctly mounted. In this case there will be no indication in the cinder-volume service logs or from the Pure Storage Cinder driver that the mount has failed.

The only indication of the problem will come in the nova-compute log file (when debug=true has been set in the Nova configuration file), where the following example message will be seen:

2023-02-03 18:00:40.439 8 DEBUG os_brick.initiator.linuxscsi [req-2b5c8045-6845-4b92-8f13-2370cf907a8c - default default]
      Searching for a device in session 6 and hctl ('12', '0', '0', 356) yield: None device_name_by_hctl /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:698

Until this issue is resolved in OpenStack, the workaround for Pure Storage is to set the host_personality parameter in the backend array stanza in the configuration file to the following:

host_personality=oracle-vm-server

This parameter instructs the FlashArray to use peripheral LUN ID addressing for all LUN, no matter the LUN ID.