Dell EMC PS Series Back End Guide

Red Hat OpenStack Platform 15

A Guide to using Dell EMC PS Series Storage in a Red Hat OpenStack Platform overcloud

OpenStack Documentation Team

Abstract

This document contains information about deploying a single Dell EMC PS Series device as a back end to the Red Hat OpenStack Platform 15 overcloud.

Chapter 1. Introduction to using Dell EMC PS Series back end

This document contains information about configuring Red Hat OpenStack Platform (RHOSP) to use one or more Dell EMC PS Series back ends. It also includes instructions about how to address volume size discrepancies between Dell EMC PS Series devices and the OpenStack Block Storage service.

Prerequisites

  • You intend to use only Dell EMC PS Series devices and drivers for Block Storage back ends.
  • You have deployed your RHOSP overcloud with the RHOSP director with a properly-functional Block Storage service.
  • You have deployed and configured your Dell storage device as a storage repository.
  • You have deployed a Dell EMC PS Series Group and it is accessible through SSH.
  • You have the necessary credentials to connect to the Group manager of the available Dell EMC PS Series Group (the CHAP and Group manager credentials).
  • You have the username and password of an account with elevated privileges. You can use the stack user that you create to deploy the overcloud. For more information, see Preparing the undercloud in the Director Installation and Usage guide.

When you deploy RHOSP with the director, you must also define and orchestrate all major overcloud settings with the director. This ensures that the settings persist through any further overcloud updates. For more information about deploying RHOSP with the director, see the Director Installation and Usage guide.

This document explains how to orchestrate your Dell EqualLogic back end configuration to the Block Storage service on the overcloud. This document does not discuss the different deployment configurations that are possible with the back end. For more information about the different deployment configurations that are available, see the product documentation for your device.

Note

Director has the integrated components to deploy only a single instance of a Dell EqualLogic back end.

Deploying multiple instances of a Dell EqualLogic back end requires a custom back end configuration. For more information, see the Custom Block Storage Back End Deployment Guide.

Chapter 2. Deploying a Dell EMC PS Series back end

To configure the Dell EMC PS Series back ends, complete the following procedures:

  1. Define a single back end. To configure a single Dell device as a back end, edit the default environment file from the core heat template collection and include this file in the overcloud deployment. For more information, see Defining a single back end.
  2. Deploy the configured back end and invoke it through the director. For more information, see Deploying the Dell EMC PS Series back end.
  3. Testing the Dell EMC PS Series back end. For more information, see Testing the Dell EMC PS Series back end.
  4. Address any volume size discrepancies with Dell EqualLogic back ends. For more information, see Address volume size discrepancies with Dell EqualLogic back ends.

Red Hat OpenStack Platform includes the drivers that are required for all Dell devices supported by the Block Storage service. In addition, director also has the puppet manifests, environment files, and Orchestration (heat) templates that are necessary to integrate the device as a back end to the overcloud.

Chapter 3. Defining a single back end

Important

This section describes the deployment of a single back end. Deploying multiple instances of a Dell EqualLogic back end requires a custom back end configuration. For more information, see the Custom Block Storage Back End Deployment Guide.

To define a single Dell EMC PS Series back end, complete the following steps:

  1. Copy the default cinder-dellps-config.yaml file from the core heat template collection:

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-dellps-config.yaml ~/templates/
  2. Edit the values in the parameter_defaults section of the ~/templates/cinder-dellps-config.yaml file to define your Dell EMC PS Series back end. Use the following table to understand how to define each parameter:

Table 3.1. Dell EMC PS Series settings

Parameter/etc/cinder/cinder.conf settingDescription

CinderDellPsBackendName

volume_backend_name

An arbitrary name to identify the volume back end.

CinderDellPsSanIp

san_ip

The IP address used to reach the Dell EMC PS Series Group through SSH.

CinderDellPsSanLogin

san_login

The user name to log in to the Group manager through SSH at the CinderDellPsSanIp IP address. The default user name is grpadmin.

CinderDellPsSanPassword

san_password

The corresponding password of CinderDellPsSanLogin. The default password is password.

CinderDellPsSanThinProvision

san_thin_provision

Enables thin provisioning for SAN volumes. Thin provisioning is required for this setup.

CinderDellPsGroupname

eqlx_group_name

The group that you want to use for a pool where the Block Storage service creates volumes and snapshots. The default group is group-0.

CinderDellPsPool

eqlx_pool

The pool where the Block Storage service creates volumes and snapshots. The Block Storage service cannot use this option for multiple pools on a single Dell EMC PS Series Group. The default pool is default.

CinderDellPsChapLogin

eqlx_chap_login

The CHAP login account for each volume in a pool. The default account name is chapadmin.

CinderDellPsChapPassword

eqlx_chap_password

The corresponding password of CinderDellPsChapLogin. The default password is randomly generated in hexadecimal, so you must set this password manually.

CinderDellPsUseChap

eqlx_use_chap

Enables CHAP authentication. the default value is false.

Chapter 4. Deploying the Dell EMC PS Series back end

To deploy the single back end that you created as part of the procedure in Defining a single back end, complete the following steps:

Procedure

  1. Log in to the undercloud as the stack user.
  2. Run the deploy command:

    $ openstack overcloud deploy --templates -e ~/templates/cinder-dellps-config.yaml
Important

If you passed any extra environment files when you created the overcloud, pass them again here 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.

Chapter 5. Testing the Dell EMC PS Series back end

After you deploy the back end, test that you can successfully create volumes on it.

Procedure

  1. Log in to the undercloud node as the stack user.
  2. Source the overcloudrc credentials file:

    $ source /home/stack/overcloudrc
  3. Create a new volume type that you can use to specify the new back end. Run the following command to create a volume type called dellps, run:

    $ cinder type-create dellps
  4. Map the new volume type to the new back end, tripleo_dellps , as defined through the CinderDellPsBackendName parameter in Chapter 3, Defining a single back end:

    $ cinder type-key dellps set volume_backend_name=tripleo_dellps
  5. Create a new 2GB volume on the new back end:

    $ cinder create --volume-type dellps 2
Note

For more information, see Accessing the Overcloud in the Director Installation and Usage guide.

Chapter 6. Addressing volume size discrepancies with Dell EqualLogic back ends

When Dell EqualLogic (EQL) back ends report volume sizes, they also assess the additional storage that they require for internal volume metadata. This total size is slightly larger than the volume size that the Block Storage services report. However, the volume size that EQL back ends report is the same size that the Image service uses.

As a result, when you create an image-backed volume on an EQL back end, first check the size of the image. If the image was originally volume-backed, then EQL and the Image service report a volume size slightly larger than the Block Storage service reports.

If the image size reported by EQL is slightly larger, then you must accommodate the size discrepancy when you create volumes backed by this image.

6.1. Example Dell EqualLogic volume size discrepancy

To illustrate, when you create a 1GB volume:

# cinder create --display-name vol1 1

+---------------------+--------------------------------------+
|       Property      |                Value                 |
+---------------------+--------------------------------------+
|     attachments     |                  []                  |
|  availability_zone  |                 nova                 |
|       bootable      |                false                 |
|      created_at     |      2014-12-19T03:57:47.730359      |
| display_description |                 None                 |
|     display_name    |                 vol1                 |
|      encrypted      |                False                 |
|          id         | 6bdace69-bd41-42fc-a63a-f834fb65a2e4 |
|       metadata      |                  {}                  |
|         size        |                  1                   |
|     snapshot_id     |                 None                 |
|     source_volid    |                 None                 |
|        status       |               creating               |
|     volume_type     |                 None                 |
+---------------------+--------------------------------------+

The Block Storage service reports a volume size of 1GB, but on the EQL array the size (VolReserve) is slightly bigger:

eql> volume select volume-6bdace69-bd41-42fc-a63a-f834fb65a2e4

eql (volume-6bdace69-bd41-42fc-a63a-f834fb65a2e4)> show

_______________________________ Volume Information ______...
Name: volume-6bdace69-bd41-42fc-a63a-f834fb65a2e4
Size: 1GB
VolReserve: 1.01GB
...

When you create a new image from this volume, the Block Storage service reports the correct volume size of 1GB:

# cinder upload-to-image --disk-format raw --container-format bare vol1 image_vol1

+---------------------+--------------------------------------+
|       Property      |                Value                 |
+---------------------+--------------------------------------+
|   container_format  |                 bare                 |
|     disk_format     |                 raw                  |
| display_description |                 None                 |
|          id         | 6bdace69-bd41-42fc-a63a-f834fb65a2e4 |
|       image_id      | c65f7eae-e2c1-44ba-8af1-e33695897559 |
|      image_name     |              image_vol1              |
|         size        |                  1                   |
|        status       |              uploading               |
|      updated_at     |      2014-12-19T03:57:48.000000      |
|     volume_type     |                 None                 |
+---------------------+--------------------------------------+

However, the Image service reports a slightly larger size:

# glance image-list

...+------------+-------------+------------------+------------+--------+
...| Name       | Disk Format | Container Format | Size       | Status |
...+------------+-------------+------------------+------------+--------+
...| image_vol1 | raw         | bare             | 1085276160 | active |
...+------------+-------------+------------------+------------+--------+

The glance tool reports an image size of approximately 1.01GB. As a result, you cannot create a new 1GB volume backed by this image:

# cinder create --display-name vol2 --image-id c65f7eae-e2c1-44ba-8af1-e33695897559 1

ERROR: Invalid input received: Size of specified image 2 is larger than volume size 1

6.2. Workaround for Dell EqualLogic volume size discrepancy

You must consider the discrepancy between the volume sizes reported by the Image and the Block Storage services when you specify the size of image-backed volumes. This means that when you specify the size of the image-backed volume, you must use the next whole number after the image size reported by the Image service (glance).

In Section 6.1, “Example Dell EqualLogic volume size discrepancy”, the Image service reports an image size of 1.01GB. This means that when you create a volume, you must specify a volume size of 2GB instead of 1GB:

# cinder create --display-name vol2 --image-id c65f7eae-e2c1-44ba-8af1-e33695897559 2

+---------------------+--------------------------------------+
|       Property      |                Value                 |
+---------------------+--------------------------------------+
|     attachments     |                  []                  |
|  availability_zone  |                 nova                 |
|       bootable      |                false                 |
|      created_at     |      2014-12-19T04:54:07.036260      |
| display_description |                 None                 |
|     display_name    |                 vol2                 |
|      encrypted      |                False                 |
|          id         | fcf49715-094d-4bba-9f05-8b7fa6deffce |
|       image_id      | c65f7eae-e2c1-44ba-8af1-e33695897559 |
|       metadata      |                  {}                  |
|         size        |                  2                   |
|     snapshot_id     |                 None                 |
|     source_volid    |                 None                 |
|        status       |               creating               |
|     volume_type     |                 None                 |
+---------------------+--------------------------------------+

Legal Notice

Copyright © 2019 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.