Pure Storage iSCSI, Fibre Channel and NVMe volume drivers¶

Limitations and known issues¶

If you do not set up the nodes hosting instances to use multipathing, all network connectivity will use a single physical port on the array. In addition to significantly limiting the available bandwidth, this means you do not have the high-availability and non-disruptive upgrade benefits provided by FlashArray. Multipathing must be used to take advantage of these benefits.

Supported operations¶

• Create, delete, attach, detach, retype, clone, and extend volumes.

• Create a volume from snapshot.

• Create, list, and delete volume snapshots.

• Create, list, update, and delete consistency groups.

• Create, list, and delete consistency group snapshots.

• Revert a volume to a snapshot.

• Manage and unmanage a volume.

• Manage and unmanage a snapshot.

• Get volume statistics.

• Create a thin provisioned volume.

• Replicate volumes to remote Pure Storage array(s)

QoS support for the Pure Storage drivers include the ability to set the following capabilities in the OpenStack Block Storage API cinder.api.contrib.qos_spec_manage qos specs extension module:

• maxIOPS - Maximum number of IOPs allowed for volume. Range: 100 - 100M

• maxBWS - Maximum bandwidth limit in MB/s. Range: 1 - 524288 (512GB/s)

The qos keys above must be created and asscoiated to a volume type. For information on how to set the key-value pairs and associate them with a volume type see the volume qos section in the OpenStack Client command list.

Configure OpenStack and Purity¶

You need to configure both your Purity array and your OpenStack cluster.

Volume auto-eradication¶

To enable auto-eradication of deleted volumes, snapshots, and consistency groups on deletion, modify the following option in the cinder.conf file:

pure_eradicate_on_delete = true

By default, auto-eradication is disabled and all deleted volumes, snapshots, and consistency groups are retained on the Pure Storage array in a recoverable state for 24 hours from time of deletion.

Setting host personality¶

The host personality determines how the Purity system tunes the protocol used between the array and the initiator. To ensure the array works optimally with the host, set the personality to the name of the host operating or virtual memory system. Valid values are aix, esxi, hitachi-vsp, hpux, oracle-vm-server, solaris, and vms. If your system is not listed as one of the valid host personalities, do not set the option. By default, the host personality is not set.

To set the host personality, modify the following option in the cinder.conf file:

pure_host_personality = <personality>

SSL certification¶

To enable SSL certificate validation, modify the following option in the cinder.conf file:

driver_ssl_cert_verify = true

By default, SSL certificate validation is disabled.

To specify a non-default path to CA_Bundle file or directory with certificates of trusted CAs:

driver_ssl_cert_path = Certificate path

Replication configuration¶

Add the following to the back-end specification to specify another Flash Array to replicate to:

[puredriver-1]
replication_device = backend_id:PURE2_NAME,san_ip:IP_PURE2_MGMT,api_token:PURE2_API_TOKEN,type:REPLICATION_TYPE

Where PURE2_NAME is the name of the remote Pure Storage system, IP_PURE2_MGMT is the management IP address of the remote array, and PURE2_API_TOKEN is the Purity Authorization token of the remote array.

The REPLICATION_TYPE value for the type key can be either sync or async

If the type is sync volumes will be created in a stretched Pod. This requires two arrays pre-configured with Active Cluster enabled. You can optionally specify uniform as true or false, this will instruct the driver that data paths are uniform between arrays in the cluster and data connections should be made to both upon attaching.

Note that more than one replication_device line can be added to allow for multi-target device replication.

A volume is only replicated if the volume is of a volume-type that has the extra spec replication_enabled set to <is> True. You can optionally specify the replication_type key to specify <in> sync or <in> async to choose the type of replication for that volume. If not specified it will default to async.

To create a volume type that specifies replication to remote back ends with async replication:

$ openstack volume type create ReplicationType
$ openstack volume type set --property replication_enabled='<is> True' ReplicationType
$ openstack volume type set --property replication_type='<in> async' ReplicationType

The following table contains the optional configuration parameters available for async replication configuration with the Pure Storage array.

Automatic thin-provisioning/oversubscription ratio¶

This feature allows the driver to calculate the array oversubscription ratio as (total provisioned/actual used). By default this feature is enabled.

To disable this feature and honor the hard-coded configuration option max_over_subscription_ratio add the following option in the cinder.conf file:

[puredriver-1]
pure_automatic_max_oversubscription_ratio = False

Scheduling metrics¶

A large number of metrics are reported by the volume driver which can be useful in implementing more control over volume placement in multi-backend environments using the driver filter and weighter methods.

Metrics reported include, but are not limited to:

total_capacity_gb
free_capacity_gb
provisioned_capacity
total_volumes
total_snapshots
total_hosts
total_pgroups
writes_per_sec
reads_per_sec
input_per_sec
output_per_sec
usec_per_read_op
usec_per_read_op
queue_depth
replication_type

In conjunction with QOS extra-specs, you can create very complex algorithms to manage volume placement. More detailed documentation on this is available in other external documentation.

Configuration Options¶

The following list all Pure driver specific configuration options that can be set in cinder.conf: