Files

Jay S. Bryant 0395353c4b Move config-reference to configuration

It was discovered today that the 'config-reference' directory
was supposed to have been renamed to 'configuration'.  The doc
team was expecting it to be at that location so that they could
automatically link to it from contributor/index.html .

This patch just moves the directory.  I am going to be submitting
a subsequent patch that properly sets out the framework for the
additional directories so that we don't have addition problems
in the future.

Change-Id: I6729aaf4593a0b089277f6d7d0aa50fee3ca340f

2017-07-18 13:10:25 -05:00

5.1 KiB

Raw Blame History

ZTE volume drivers

The ZTE volume drivers allow ZTE KS3200 or KU5200 arrays to be used for Block Storage in OpenStack deployments.

System requirements

To use the ZTE drivers, the following prerequisites:

ZTE KS3200 or KU5200 array with:
- iSCSI or FC interfaces
- 30B2 firmware or later
Network connectivity between the OpenStack host and the array management interfaces
HTTPS or HTTP must be enabled on the array

Supported operations

Create, delete, attach, and detach volumes.
Create, list, and delete volume snapshots.
Create a volume from a snapshot.
Copy an image to a volume.
Copy a volume to an image.
Clone a volume.
Extend a volume.
Migrate a volume with back-end assistance.
Retype a volume.
Manage and unmanage a volume.

Configuring the array

Verify that the array can be managed using an HTTPS connection. HTTP can also be used if zte_api_protocol=http is placed into the appropriate sections of the cinder.conf file.

Confirm that virtual pools A and B are present if you plan to use virtual pools for OpenStack storage.
Edit the cinder.conf file to define a storage back-end entry for each storage pool on the array that will be managed by OpenStack. Each entry consists of a unique section name, surrounded by square brackets, followed by options specified in key=value format.
- The zte_backend_name value specifies the name of the storage pool on the array.
- The volume_backend_name option value can be a unique value, if you wish to be able to assign volumes to a specific storage pool on the array, or a name that is shared among multiple storage pools to let the volume scheduler choose where new volumes are allocated.
- The rest of the options will be repeated for each storage pool in a given array: the appropriate cinder driver name, IP address or host name of the array management interface; the username and password of an array user account with manage privileges; and the iSCSI IP addresses for the array if using the iSCSI transport protocol.
In the examples below, two back ends are defined, one for pool A and one for pool B, and a common volume_backend_name. Use this for a single volume type definition can be used to allocate volumes from both pools.

Example: iSCSI back-end entries
```
[pool-a]
zte_backend_name = A
volume_backend_name = zte-array
volume_driver = cinder.volume.drivers.zte.zte_iscsi.ZTEISCSIDriver
san_ip = 10.1.2.3
san_login = manage
san_password = !manage
zte_iscsi_ips = 10.2.3.4,10.2.3.5

[pool-b]
zte_backend_name = B
volume_backend_name = zte-array
volume_driver = cinder.volume.drivers.zte.zte_iscsi.ZTEISCSIDriver
san_ip = 10.1.2.3
san_login = manage
san_password = !manage
zte_iscsi_ips = 10.2.3.4,10.2.3.5
```
Example: Fibre Channel back end entries
```
[pool-a]
zte_backend_name = A
volume_backend_name = zte-array
volume_driver = cinder.volume.drivers.zte.zte_fc.ZTEFCDriver
san_ip = 10.1.2.3
san_login = manage
san_password = !manage

[pool-b]
zte_backend_name = B
volume_backend_name = zte-array
volume_driver = cinder.volume.drivers.zte.zte_fc.ZTEFCDriver
san_ip = 10.1.2.3
san_login = manage
san_password = !manage
```
If HTTPS is not enabled in the array, include zte_api_protocol = http in each of the back-end definitions.
If HTTPS is enabled, you can enable certificate verification with the option zte_verify_certificate=True. You may also use the zte_verify_certificate_path parameter to specify the path to a CA_BUNDLE file containing CAs other than those in the default list.
Modify the [DEFAULT] section of the cinder.conf file to add an enabled_backends parameter specifying the back-end entries you added, and a default_volume_type parameter specifying the name of a volume type that you will create in the next step.

Example: [DEFAULT] section changes
```
[DEFAULT]
# ...
enabled_backends = pool-a,pool-b
default_volume_type = zte
```
Create a new volume type for each distinct volume_backend_name value that you added to the cinder.conf file. The example below assumes that the same volume_backend_name=zte-array option was specified in all of the entries, and specifies that the volume type zte can be used to allocate volumes from any of them.

Example: Creating a volume type
```
$ openstack volume type create zte
$ openstack volume type set --property volume_backend_name=zte-array zte
```
After modifying the cinder.conf file, restart the cinder-volume service.

Driver-specific options

The following table contains the configuration options that are specific to the ZTE drivers.

5.1 KiB Raw Blame History