Dell Storage Center Back End Guide
A Guide to Using Dell Storage Center Storage in a Red Hat OpenStack Platform Overcloud
Abstract
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Chapter 1. Introduction
This document describes how to configure OpenStack to use one or more Dell Storage Center back ends. The following sections assume that:
- You intend to use only Dell Storage Center devices and drivers for Block Storage back ends
- The OpenStack Overcloud has already been deployed through Director, with a properly-functional Block Storage service
- The Dell storage device has already been deployed and configured as a storage repository
- You have the necessary credentials for connecting to the Enterprise Manager and Dell Storage Center Group
-
You have the username and password of an account with elevated privileges. You can use the same account that was created to deploy the Overcloud; in Creating the stack user, we create and use the
stack
user for this purpose.
When you deploy Red Hat OpenStack Platform (RHOSP) through director, you must also define and orchestrate all major overcloud settings through director, in particular, the Block Storage service back end. This ensures that the settings persist through any further overcloud updates. For more information about deploying OpenStack through the Director, see Director Installation and Usage.
The purpose of this document is to explain how to orchestrate your Dell Storage Center back end configuration to the overcloud Block Storage service. This document does not discuss the different deployment configurations that are possible with the back end. To learn more about the different available deployment configurations, see the product documentation of your device.
When you are familiar with the resulting back end configuration you want to deploy, and its corresponding settings, see this document for instructions about how to orchestrate it through director.
At present, the Director only has the integrated components to deploy a single instance of a Dell Storage Center back end. As such, this document only describes the deployment of a single back end.
Deploying multiple instances of a Dell Storage Center back end requires a custom back end configuration. See the Custom Block Storage Back End Deployment Guide for instructions.
Before deploying Red Hat OpenStack Platform (RHOSP) with a Dell Storage Center back end, review the following limitations:
- For Dell EMC SC Series, snapshots of empty non-attached volumes are not supported. You must populate the volume or attach the volume before proceeding with snapshots. For more information, see https://bugs.launchpad.net/cinder/+bug/1616630.
- For Dell EMC SC Series, cinder backup is not supported.
Chapter 2. Process Description
Red Hat OpenStack Platform (RHOSP) includes the drivers required for all Dell devices supported by the Block Storage service. In addition, director also has the puppet manifests, environment files, and Orchestration templates necessary for integrating the device as a back end to the overcloud.
Configuring a single Dell device as a back end involves editing the default environment file and including it in the overcloud deployment. This file is available locally on the undercloud, and can be edited to suit your environment.
After you edit this file, invoke it through director. Doing so ensures that it persists through future overcloud updates. The following sections describe this process in greater detail. In addition, the default environment file already contains enough information to call the necessary puppet manifests and Orchestration (heat) templates that configure the rest of the required Block Storage settings.
Chapter 3. Define a Single Back End
This section describes the deployment of a single back end. Deploying multiple instances of a Dell Storage Center back end requires a custom back end configuration. See the Custom Block Storage Back End Deployment Guide for instructions.
With a Director deployment, the easiest way to define a single Dell Storage Center back end is through the integrated environment file. This file is located in the following path of the Undercloud node:
/usr/share/openstack-tripleo-heat-templates/environments/cinder-dellsc-config.yaml
Copy this file to a local path where you can edit and invoke it later. For example, to copy it to ~/templates/
:
$ cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-dellsc-config.yaml ~/templates/
Afterwards, open the copy (~/templates/cinder-dellsc-config.yaml
) and edit it as you see fit. The following snippet displays the default contents of this file:
# A Heat environment file which can be used to enable a # a Cinder Dell Storage Center ISCSI backend, configured via puppet resource_registry: OS::TripleO::Services::CinderBackendDellSc: ../puppet/services/cinder-backend-dellsc.yaml # 1 parameter_defaults: # 2 CinderEnableDellScBackend: true # 3 CinderDellScBackendName: 'tripleo_dellsc' CinderDellScSanIp: '' CinderDellScSanLogin: 'Admin' CinderDellScSanPassword: '' CinderDellScSsn: '64702' CinderDellScIscsiIpAddress: '' CinderDellScIscsiPort: '3260' CinderDellScApiPort: '3033' CinderDellScServerFolder: 'dellsc_server' CinderDellScVolumeFolder: 'dellsc_volume'
- 1
- The OS::TripleO::Services::CinderBackendDellSc parameter in the
resource_registry
section refers to a composable service template namedcinder-backend-dellsc.yaml
. The director uses this template to load the necessary resources for configuring the back end. By default, the parameter specifies the path tocinder-backend-dellsc.yaml
relatively. As such, update this parameter with the absolute path to the file:resource_registry: OS::TripleO::Services::CinderBackendDellSc: /usr/share/openstack-tripleo-heat-templates/puppet/services/cinder-backend-dellsc.yaml
- 2
- The parameter_defaults section contains your back end definition. Specifically, it contains the parameters that the Director should pass to the resources defined in
cinder-dellsc.yaml
. - 3
- The CinderEnableDellScBackend: true line instructs the Director to use the puppet manifests necessary for the default configuration of a Dell Storage Center back end. This includes defining the volume driver that the Block Storage service should use (specifically,
cinder.volume.drivers.dell_emc.sc.dell_storagecenter_iscsi.SCISCSIDriver
).
To define your Dell Storage Center back end, edit the settings in the parameter_defaults section as you see fit. The following table explains each parameter, and also lists its corresponding /etc/cinder/cinder.conf
setting.
Parameter | /etc/cinder/cinder.conf setting | Description |
---|---|---|
CinderDellScBackendName | volume_backend_name | (Required) An arbitrary name to identify the volume back end. |
CinderDellScSanIp | san_ip | (Optional) The IP address used to reach the Dell Enterprise Manager. |
CinderDellScSanLogin | san_login |
(Required) The user name to login to the Dell Enterprise Manager at the CinderDellScSanIp. The default user name is |
CinderDellScSanPassword | san_password | (Optional) The corresponding password of CinderDellScSanLogin. |
CinderDellScSsn | dell_sc_ssn | (Required) The Dell Storage Center serial number to use. |
CinderDellScIscsiIpAddress | iscsi_ip_address | (Optional) The Dell Storage Center ISCSI IP address to be used for creating volumes and snapshots. |
CinderDellScIscsiPort | iscsi_port | (Optional) The ISCSI port of the Dell Storage Center array. |
CinderDellScApiPort | dell_sc_api_port | (Optional) The Dell Enterprise Manager API port. |
CinderDellScServerFolder | dell_sc_server_folder |
(Required) The |
CinderDellScVolumeFolder | dell_sc_volume_folder |
(Required) The |
Chapter 4. Deploy the Configured Back End
The Director installation uses a non-root user to execute commands, which includes orchestrating the deployment of the Block Storage back end. In Creating a Director Installation User, a user named stack
is created for this purpose. This user is configured with elevated privileges.
To deploy the lone back end configured in Chapter 3, Define a Single Back End, first log in as the stack
user to the Undercloud. Then, deploy the back end (defined in the edited ~/templates/cinder-dellsc-config.yaml
) by running the following:
$ openstack overcloud deploy --templates -e ~/templates/cinder-dellsc-config.yaml
If you passed any extra environment files when you created the overcloud, pass them again here by using the -e
option to avoid making undesired changes to the overcloud. For more information, see Modifying the Overcloud Environment in the Director Installation and Usage guide.
Test the back end after director orchestration is complete. See Chapter 5, Test the Configured Back End.
Chapter 5. Test the Configured Back End
After deploying the back end, test whether you can successfully create volumes on it. 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
For more information, see Accessing the Overcloud.
You should now be logged in to the Controller node. From there, you can create a volume type, which can be used to specify the back end you want to use (in this case, the newly-defined back end in Chapter 3, Define a Single Back End). This is required in an OpenStack deployment where you have other back ends enabled (preferably, also through Director).
To create a volume type named dellsc
, run:
$ cinder type-create dellsc
Next, map this volume type to the back end defined in ]. Given the back end name tripleo_dellsc
(as defined through the CinderDellScBackendName
parameter, in xref:edityaml[), run:
$ cinder type-key dellsc set volume_backend_name=tripleo_dellsc
You should now be able to create a 2GB volume on the newly defined back end by invoking its volume type. To do so, run:
$ cinder create --volume-type dellsc 2