Dell PowerMax iSCSI and FC drivers¶

PowerMax¶

There are two licenses for the PowerMax 2000 and 8000:

• Essentials software package

• Pro software package

The Dell PowerMax cinder driver requires the Pro software package.

All Flash¶

For full functionality including SRDF for the VMAX All Flash, the FX package, or the F package plus the SRDF a la carte add on is required.

Hybrid¶

There are five Dell Software Suites sold with the VMAX-Hybrid arrays:

• Base Suite

• Advanced Suite

• Local Replication Suite

• Remote Replication Suite

• Total Productivity Pack

The Dell PowerMax Cinder driver requires the Advanced Suite and the Local Replication Suite or the Total Productivity Pack (it includes the Advanced Suite and the Local Replication Suite) for the VMAX Hybrid.

Using PowerMax Remote Replication functionality will also require the Remote Replication Suite.

Assumptions, restrictions and prerequisites¶

1. The host initiator IQN is required along with the credentials the host initiator will use to log into the storage array with. The same credentials should be used in a multi node system if connecting to the same array.

2. Enable one-way CHAP authentication for the iSCSI initiator on the storage array using SYMCLI. Template and example shown below. For the purpose of this setup, the credential/secret used would be my_username/my_password with iSCSI initiator of iqn.1991-05.com.company.lcseb130

   # symaccess -sid <SymmID> -iscsi <iscsi> \
               {enable chap | disable chap | set chap} \
                -cred <Credential> -secret <Secret>
   
   # symaccess -sid 128 \
               -iscsi iqn.1991-05.com.company.lcseb130 \
               set chap -cred my_username -secret my_password
   

Settings and configuration¶

1. Set the configuration in the PowerMax backend group in cinder.conf using the following parameters and restart cinder.

   Configuration options	Value required for CHAP	Required for CHAP
   use_chap_auth	True	Yes
   chap_username	my_username	Yes
   chap_password	my_password	Yes

   [POWERMAX_ISCSI]
   volume_driver = cinder.volume.drivers.dell_emc.powermax.iscsi.PowerMaxISCSIDriver
   volume_backend_name = POWERMAX_ISCSI
   san_ip = 10.10.10.10
   san_login = my_u4v_username
   san_password = my_u4v_password
   powermax_srp = SRP_1
   powermax_array = 000123456789
   powermax_port_groups = [OS-ISCSI-PG]
   use_chap_auth = True
   chap_username = my_username
   chap_password = my_password
   

Usage¶

1. Using SYMCLI, enable CHAP authentication for a host initiator as described above, but do not set use_chap_auth, chap_username or chap_password in cinder.conf. Create a bootable volume.

   openstack volume create --size 1 \
                           --image <image_name> \
                           --type <volume_type> \
                           test
   

2. Boot instance named test_server using the volume created above:

   openstack server create --volume test \
                           --flavor m1.small \
                           --nic net-id=private \
                           test_server
   

3. Verify the volume operation succeeds but the boot instance fails as CHAP authentication fails.

4. Update cinder.conf with use_chap_auth set to true and chap_username and chap_password set with the correct credentials.

5. Rerun openstack server create

6. Verify that the boot instance operation ran correctly and the volume is accessible.

7. Verify that both the volume and boot instance operations ran successfully and the user is able to access the volume.

USE CASE 1 - Default values¶

Prerequisites - PowerMax

• Host I/O Limit (MB/Sec) - No Limit

• Host I/O Limit (IO/Sec) - No Limit

• Set Dynamic Distribution - N/A

1. Create QoS Specs with the prerequisite values above:

   $ openstack volume qos create --consumer back-end \
                                 --property total_iops_sec=500 \
                                 --property total_bytes_sec=104857600 \
                                 --property DistributionType=Always \
                                 my_qos
   

2. Associate QoS specs with specified volume type:

   $ openstack volume qos associate my_qos my_volume_type
   

3. Create volume with the volume type indicated above:

   $ openstack volume create --size 1 --type my_volume_type my_volume
   

Outcome - PowerMax (storage group)

• Host I/O Limit (MB/Sec) - 100

• Host I/O Limit (IO/Sec) - 500

• Set Dynamic Distribution - Always

Outcome - Block Storage (Cinder)

Volume is created against volume type and QoS is enforced with the parameters above.

USE CASE 2 - Pre-set limits¶

Prerequisites - PowerMax

• Host I/O Limit (MB/Sec) - 2000

• Host I/O Limit (IO/Sec) - 2000

• Set Dynamic Distribution - Never

1. Create QoS specifications with the prerequisite values above. The consumer in this use case is both for front-end and back-end:

   $ openstack volume qos create --consumer back-end \
                                 --property total_iops_sec=500 \
                                 --property total_bytes_sec=104857600 \
                                 --property DistributionType=Always \
                                 my_qos
   

2. Associate QoS specifications with specified volume type:

   $ openstack volume qos associate my_qos my_volume_type
   

3. Create volume with the volume type indicated above:

   $ openstack volume create --size 1 --type my_volume_type my_volume
   

4. Attach the volume created in step 3 to an instance

   $ openstack server add volume my_instance my_volume
   

Outcome - PowerMax (storage group)

• Host I/O Limit (MB/Sec) - 100

• Host I/O Limit (IO/Sec) - 500

• Set Dynamic Distribution - Always

Outcome - Block Storage (Cinder)

Volume is created against volume type and QoS is enforced with the parameters above.

Outcome - Hypervisor (Nova)

Libvirt includes an extra xml flag within the <disk> section called iotune that is responsible for rate limitation. To confirm that, first get the OS-EXT-SRV-ATTR:instance_name value of the server instance, for example instance-00000003.

$ openstack server show <serverid>

+-------------------------------------+-----------------------------------------------------------------+
| Field                               | Value                                                           |
+-------------------------------------+-----------------------------------------------------------------+
| OS-DCF:diskConfig                   | AUTO                                                            |
| OS-EXT-AZ:availability_zone         | nova                                                            |
| OS-EXT-SRV-ATTR:host                | myhost                                                          |
| OS-EXT-SRV-ATTR:hypervisor_hostname | myhost                                                          |
| OS-EXT-SRV-ATTR:instance_name       | instance-00000003                                               |
| OS-EXT-STS:power_state              | Running                                                         |
| OS-EXT-STS:task_state               | None                                                            |
| OS-EXT-STS:vm_state                 | active                                                          |
| OS-SRV-USG:launched_at              | 2017-11-02T08:15:42.000000                                      |
| OS-SRV-USG:terminated_at            | None                                                            |
| accessIPv4                          |                                                                 |
| accessIPv6                          |                                                                 |
| addresses                           | private=fd21:99c2:73f3:0:f816:3eff:febe:30ed, 10.0.0.3          |
| config_drive                        |                                                                 |
| created                             | 2017-11-02T08:15:34Z                                            |
| flavor                              | m1.tiny (1)                                                     |
| hostId                              | e7b8312581f9fbb8508587d45c0b6fb4dc86102c632ed1f3a6a49d42        |
| id                                  | 0ef0ff4c-dbda-4dc7-b8ed-45d2fc2f31db                            |
| image                               | cirros-0.3.5-x86_64-disk (b7c220f5-2408-4296-9e58-fc5a41cb7e9d) |
| key_name                            | myhostname                                                      |
| name                                | myhosthame                                                      |
| progress                            | 0                                                               |
| project_id                          | bae4b97a0d8b42c28a5add483981e5db                                |
| properties                          |                                                                 |
| security_groups                     | name='default'                                                  |
| status                              | ACTIVE                                                          |
| updated                             | 2017-11-02T08:15:42Z                                            |
| user_id                             | 7bccf456740546799a7e20457f13c38b                                |
| volumes_attached                    |                                                                 |
+-------------------------------------+-----------------------------------------------------------------+

We then run the following command using the OS-EXT-SRV-ATTR:instance_name retrieved above.

$ virsh dumpxml instance-00000003 | grep -1 "total_bytes_sec\|total_iops_sec"

The output of the command contains the XML below. It is found between the <disk> start and end tag.

<iotune>
   <total_bytes_sec>104857600</total_bytes_sec>
   <total_iops_sec>500</total_iops_sec>
</iotune>

USE CASE 3 - Pre-set limits¶

Prerequisites - PowerMax

• Host I/O Limit (MB/Sec) - 100

• Host I/O Limit (IO/Sec) - 500

• Set Dynamic Distribution - Always

1. Create QoS specifications with the prerequisite values above:

   $ openstack volume qos create --consumer back-end \
                                 --property total_iops_sec=500 \
                                 --property total_bytes_sec=104857600 \
                                 --property DistributionType=OnFailure \
                                 my_qos
   

2. Associate QoS specifications with specified volume type:

   $ openstack volume qos associate my_qos my_volume_type
   

3. Create volume with the volume type indicated above:

   $ openstack volume create --size 1 --type my_volume_type my_volume
   

Outcome - PowerMax (storage group)

• Host I/O Limit (MB/Sec) - 100

• Host I/O Limit (IO/Sec) - 500

• Set Dynamic Distribution - OnFailure

Outcome - Block Storage (Cinder)

Volume is created against volume type and QOS is enforced with the parameters above.

USE CASE 4 - Default values¶

Prerequisites - PowerMax

• Host I/O Limit (MB/Sec) - No Limit

• Host I/O Limit (IO/Sec) - No Limit

• Set Dynamic Distribution - N/A

1. Create QoS specifications with the prerequisite values above:

   $ openstack volume qos create --consumer back-end \
                                 --property DistributionType=Always \
                                 my_qos
   

2. Associate QoS specifications with specified volume type:

   $ openstack volume qos associate my_qos my_volume_type
   

3. Create volume with the volume type indicated above:

   $ openstack volume create --size 1 --type my_volume_type my_volume
   

Outcome - PowerMax (storage group)

• Host I/O Limit (MB/Sec) - No Limit

• Host I/O Limit (IO/Sec) - No Limit

• Set Dynamic Distribution - N/A

Outcome - Block Storage (Cinder)

Volume is created against volume type and there is no QoS change.

Multipath configuration file¶

The multi-path configuration file may be edited for better management and performance. Log in as a privileged user and make the following changes to /etc/multipath.conf on the Compute (Nova) node(s).

devices {
# Device attributed for EMC PowerMax
    device {
            vendor "EMC"
            product "SYMMETRIX"
            path_grouping_policy multibus
            getuid_callout "/lib/udev/scsi_id --page=pre-spc3-83 --whitelisted --device=/dev/%n"
            path_selector "round-robin 0"
            path_checker tur
            features "0"
            hardware_handler "0"
            prio const
            rr_weight uniform
            no_path_retry 6
            rr_min_io 1000
            rr_min_io_rq 1
    }
}

You may need to reboot the host after installing the MPIO tools or restart iSCSI and multi-path services.

On Ubuntu iSCSI:

# service open-iscsi restart
# service multipath-tools restart

On Ubuntu FC

# service multipath-tools restart

On openSUSE, SUSE Linux Enterprise Server, Red Hat Enterprise Linux, and CentOS iSCSI:

# systemctl restart open-iscsi
# systemctl restart multipath-tools

On openSUSE, SUSE Linux Enterprise Server, Red Hat Enterprise Linux, and CentOS FC:

# systemctl restart multipath-tools

$ lsblk
NAME                                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                          8:0    0     1G  0 disk
..360000970000196701868533030303235 (dm-6) 252:6    0     1G  0 mpath
sdb                                          8:16   0     1G  0 disk
..360000970000196701868533030303235 (dm-6) 252:6    0     1G  0 mpath
vda                                        253:0    0     1T  0 disk

OpenStack configurations¶

On Compute (Nova) node, add the following flag in the [libvirt] section of nova.conf and nova-cpu.conf:

volume_use_multipath = True

On Cinder controller node, multi-path for image transfer can be enabled in cinder.conf for each backend section or in [backend_defaults] section as a common configuration for all backends.

use_multipath_for_image_xfer = True

Restart nova-compute and cinder-volume services after the change.

Verify you have multiple initiators available on the compute node for I/O¶

1. Create a 3GB PowerMax volume.

2. Create an instance from image out of native LVM storage or from PowerMax storage, for example, from a bootable volume

3. Attach the 3GB volume to the new instance:

   # multipath -ll
   mpath102 (360000970000196700531533030383039) dm-3 EMC,SYMMETRIX
   size=3G features='1 queue_if_no_path' hwhandler='0' wp=rw
   '-+- policy='round-robin 0' prio=1 status=active
   33:0:0:1 sdb 8:16 active ready running
   '- 34:0:0:1 sdc 8:32 active ready running
   

4. Use the lsblk command to see the multi-path device:

   # lsblk
   NAME                                       MAJ:MIN RM   SIZE RO TYPE
   sdb                                          8:0    0     3G  0 disk
   ..360000970000196700531533030383039 (dm-6) 252:6    0     3G  0 mpath
   sdc                                          8:16   0     3G  0 disk
   ..360000970000196700531533030383039 (dm-6) 252:6    0     3G  0 mpath
   vda
   

Use case 1 - Compression disabled create, attach, detach, and delete volume¶

1. Create a new volume type called POWERMAX_COMPRESSION_DISABLED.

2. Set an extra spec volume_backend_name.

3. Set a new extra spec storagetype:disablecompression = True.

4. Create a new volume.

5. Check in Unisphere or SYMCLI to see if the volume exists in storage group OS-<srp>-<servicelevel>-<workload>-CD-SG, and compression is disabled on that storage group.

6. Attach the volume to an instance. Check in Unisphere or SYMCLI to see if the volume exists in storage group OS-<shorthostname>-<srp>-<servicelevel/workload>-<portgroup>-CD, and compression is disabled on that storage group.

7. Detach volume from instance. Check in Unisphere or symcli to see if the volume exists in storage group OS-<srp>-<servicelevel>-<workload>-CD-SG, and compression is disabled on that storage group.

8. Delete the volume. If this was the last volume in the OS-<srp>-<servicelevel>-<workload>-CD-SG storage group, it should also be deleted.

Use case 2 - Retype from compression disabled to compression enabled¶

1. Repeat steps 1-4 of Use case 1.

2. Create a new volume type. For example POWERMAX_COMPRESSION_ENABLED.

3. Set extra spec volume_backend_name as before.

4. Set the new extra spec’s compression as storagetype:disablecompression = False or DO NOT set this extra spec.

5. Retype from volume type POWERMAX_COMPRESSION_DISABLED to POWERMAX_COMPRESSION_ENABLED.

6. Check in Unisphere or symcli to see if the volume exists in storage group OS-<srp>-<servicelevel>-<workload>-SG, and compression is enabled on that storage group.

Architecture¶

In PowerMax, A volume cannot belong to two or more FAST storage groups at the same time. To get around this limitation we leverage both cascaded storage groups and a temporary non-FAST storage group.

A volume can remain ‘live’ if moved between masking views that have the same initiator group and port groups which preserves the host path.

During live migration, the following steps are performed by the PowerMax driver on the volume:

1. Within the originating masking view, the volume is moved from the FAST storage group to the non-FAST storage group within the parent storage group.

2. The volume is added to the FAST storage group within the destination parent storage group of the destination masking view. At this point the volume belongs to two storage groups.

3. One of two things happen:

   • If the connection to the destination instance is successful, the volume is removed from the non-FAST storage group in the originating masking view, deleting the storage group if it contains no other volumes.

   • If the connection to the destination instance fails, the volume is removed from the destination storage group, deleting the storage group, if empty. The volume is reverted back to the original storage group.

Live migration configuration¶

Please refer to the official OpenStack documentation on configuring migrations and live migration usage for more information.

System configuration¶

NOVA-INST-DIR/instances/ (for example, /opt/stack/data/nova/instances) has to be mounted by shared storage. Ensure that NOVA-INST-DIR (set with state_path in the nova.conf file) is the same on all hosts.

1. Configure your DNS or /etc/hosts and ensure it is consistent across all hosts. Make sure that the three hosts can perform name resolution with each other. As a test, use the ping command to ping each host from one another.

   $ ping HostA
   $ ping HostB
   $ ping HostC
   

2. Export NOVA-INST-DIR/instances from HostA, and ensure it is readable and writable by the Compute user on HostB and HostC. Please refer to the relevant OS documentation for further details, for example Ubuntu NFS Documentation

3. On all compute nodes, enable the execute/search bit on your shared directory to allow qemu to be able to use the images within the directories. On all hosts, run the following command:

   $ chmod o+x NOVA-INST-DIR/instances
   

Use case¶

For our use case shown below, we have three hosts with host names HostA, HostB and HostC. HostA is the controller node while HostB and HostC are the compute nodes. The following were also used in live migration.

• 2GB bootable volume using the CirrOS image.

• Instance created using the 2GB volume above with a flavor m1.small using 2048 RAM, 20GB of Disk and 1 VCPU.

1. Create a bootable volume.

   $ openstack volume create --size 2 \
                             --image cirros-0.3.5-x86_64-disk \
                             --volume_lm_1
   

2. Launch an instance using the volume created above on HostB.

   $ openstack server create --volume volume_lm_1 \
                             --flavor m1.small \
                             --nic net-id=private \
                             --security-group default \
                             --availability-zone nova:HostB \
                             server_lm_1
   

3. Confirm on HostB has the instance created by running:

   $ openstack server show server_lm_1 | grep "hypervisor_hostname\|instance_name"
     | OS-EXT-SRV-ATTR:hypervisor_hostname | HostB
     | OS-EXT-SRV-ATTR:instance_name | instance-00000006
   

4. Confirm, through virsh using the instance_name returned in step 3 (instance-00000006), on HostB that the instance is created using:

   $ virsh list --all
   
   Id   Name                  State
   --------------------------------
   1    instance-00000006     Running
   

5. Migrate the instance from HostB to HostA with:

   $ openstack server migrate --os-compute-api-version 2.30 \
                              --live-migration --host HostA \
                              server_lm_1
   

6. Run the command on step 3 above when the instance is back in available status. The hypervisor should be on Host A.

7. Run the command on Step 4 on Host A to confirm that the instance is created through virsh.

Multi-attach architecture¶

In PowerMax, a volume cannot belong to two or more FAST storage groups at the same time. This can cause issues when we are attaching a volume to multiple instances on different hosts. To get around this limitation, we leverage both cascaded storage groups and non-FAST storage groups (i.e. a storage group with no service level, workload, or SRP specified).

Example use case¶

Volume Multi-attach-Vol-1 (with a multi-attach capable volume type, and associated with a Diamond Service Level) is attached to Instance Multi-attach-Instance-A on HostA. We then issue the command to attach Multi-attach-Vol-1 to Multi-attach-Instance-B on HostB:

1. In the HostA masking view, the volume is moved from the FAST managed storage group to the non-FAST managed storage group within the parent storage group.

2. The volume is attached as normal on HostB – i.e., it is added to a FAST managed storage group within the parent storage group of the HostB masking view. The volume now belongs to two masking views, and is exposed to both HostA and HostB.

We then decide to detach the volume from Multi-attach-Instance-B on HostB:

1. The volume is detached as normal from HostB – i.e., it is removed from the FAST managed storage group within the parent storage group of the HostB masking view – this includes cleanup of the associated elements if required. The volume now belongs to one masking view, and is no longer exposed to HostB.

2. In the HostA masking view, the volume is returned to the FAST managed storage group from the non-FAST managed storage group within the parent storage group. The non-FAST managed storage group is cleaned up, if required.

16.1 Volume metadata in logs¶

If debug is enabled in the default section of cinder.conf, PowerMax Cinder driver will log additional volume information in the Cinder volume log, on each successful operation. The facilitates bridging the gap between OpenStack and the Array by tracing and describing the volume from a VMAX/ PowerMax view point.

+------------------------------------+---------------------------------------------------------+
| Key                                | Value                                                   |
+------------------------------------+---------------------------------------------------------+
| service_level                      | Gold                                                    |
| is_compression_disabled            | no                                                      |
| powermax_cinder_driver_version     | 3.2.0                                                   |
| identifier_name                    | OS-819470ab-a6d4-49cc-b4db-6f85e82822b7                 |
| openstack_release                  | 13.0.0.0b3.dev3                                         |
| volume_id                          | 819470ab-a6d4-49cc-b4db-6f85e82822b7                    |
| storage_model                      | PowerMax_8000                                           |
| successful_operation               | delete                                                  |
| default_sg_name                    | OS-DEFAULT_SRP-Gold-NONE-SG                             |
| device_id                          | 01C03                                                   |
| unisphere_for_powermax_version     | V9.0.0.9                                                |
| workload                           | NONE                                                    |
| openstack_version                  | 13.0.0                                                  |
| volume_updated_time                | 2018-08-03 03:13:53                                     |
| platform                           | Linux-4.4.0-127-generic-x86_64-with-Ubuntu-16.04-xenial |
| python_version                     | 2.7.12                                                  |
| volume_size                        | 20                                                      |
| srp                                | DEFAULT_SRP                                             |
| openstack_name                     | 90_Test_Vol56                                           |
| storage_firmware_version           | 5978.143.144                                            |
| serial_number                      | 000123456789                                            |
+------------------------------------+---------------------------------------------------------+

16.2 Metadata in the UI and CLI¶

By default metadata will be set on all volume and snapshot objects created in Cinder. This information represents the state of the object on the backend PowerMax and will change when volume attributes are changed by performing actions on them such as re-type or attaching to an instance.

demo@openstack-controller:~$ cinder show powermax-volume

+--------------------------------+------------------------------------------------------------+
| Property                       | Value                                                      |
+--------------------------------+------------------------------------------------------------+
| metadata                       | ArrayID : 000123456789                                     |
|                                | ArrayModel : PowerMax_8000                                 |
|                                | CompressionDisabled : False                                |
|                                | Configuration : TDEV                                       |
|                                | DeviceID : 0012F                                           |
|                                | DeviceLabel : OS-d87edb98-60fd-49dd-bb0f-cc388cf6f3f4      |
|                                | Emulation : FBA                                            |
|                                | ReplicationEnabled : False                                 |
|                                | ServiceLevel : Diamond                                     |
|                                | Workload : None                                            |
| name                           | powermax-volume                                            |
+--------------------------------+------------------------------------------------------------+

Requirements¶

• All required instances of Unisphere for PowerMax are set up and configured for the array(s)

• Array(s) are locally registered with the instance of Unisphere that will be used as a failover instance. There are two failover types, local and remote:

  • Local failover - Primary Unisphere is unreachable, failover to secondary local instance of Unisphere to resume normal operations at primary site.

  • Remote failover - Complete loss of primary site so primary instance of Unisphere is unreachable, failover to secondary instance of Unisphere at remote site to resume operations with the R2 array.

Configuration¶

The following configuration changes need to be made in cinder.conf under the PowerMax backend stanza in order to support the failover to secondary Unisphere. Cinder services will need to be restarted for changes to take effect.

[POWERMAX_1]
...

u4p_failover_timeout = 30
u4p_failover_retries = 3
u4p_failover_backoff_factor = 1
u4p_failover_autofailback = True
u4p_failover_target = san_ip:10.10.10.12,
                      san_api_port: 8443,
                      san_login:my_username,
                      san_password:my_password,
                      driver_ssl_cert_verify: False,
u4p_failover_target = san_ip:10.10.10.13,
                      san_api_port: 8443
                      san_login:my_username,
                      san_password:my_password,
                      driver_ssl_cert_verify: True,
                      driver_ssl_cert_path: /path/to/my_unisphere_host.pem

Assumptions, restrictions and prerequisites¶

• ODE in the context of this document refers to extending a volume where it is in-use, that is, attached to an instance.

• The allow_extend is only applicable on VMAX-Hybrid arrays or All Flash arrays with HyperMax OS. If included elsewhere, it is ignored.

• Where one array is a lower uCode than the other, the environment is limited to functionality of that of the lowest uCode level, i.e. if R1 is 5978.444 and R2 is 5978.221, expanding a metro volume is not supported, both R1 and R2 need to be on 5978.444 uCode at a minimum.

Assumptions, restrictions and prerequisites¶

• The storage group tag(s) is associated with a volume type extra spec key storagetype:storagegrouptags.

• The array tag is associated with the backend stanza using key powermax_array_tag_list. It expects a list of one or more comma separated values, for example powermax_array_tag_list=[value1,value2, value3]

• They can be one or more values in a comma separated list.

• There is a 64 characters limit of letters, numbers, - and _.

• 8 tags are allowed per storage group and array.

• Tags cannot be modified once a volume has been created with that volume type. This is an OpenStack constraint.

• Tags can be modified on the backend stanza, but none will ever be removed, only added.

• There is no restriction on creating or deleting tags of OpenStack storage groups or arrays outside of OpenStack, for example Unisphere for PowerMax UI. The max number of 8 tags will apply however, as this is a Unisphere for PowerMax limit.

Set a storage group tag on a volume type:

$ openstack volume type set --property storagetype:storagegrouptags=myStorageGroupTag1,myStorageGroupTag2

Set an array tag on the PowerMax backend:

[POWERMAX_ISCSI]
volume_driver = cinder.volume.drivers.dell_emc.powermax.iscsi.PowerMaxISCSIDriver
volume_backend_name = POWERMAX_ISCSI
san_ip = 10.10.10.10
san_login = my_u4v_username
san_password = my_u4v_password
powermax_srp = SRP_1
powermax_array = 000123456789
powermax_port_groups = [OS-ISCSI-PG]
powermax_array_tag_list = [openstack1, openstack2]

Assumptions, restrictions, and prerequisites¶

• Backward compatibility with old format is preserved.

• cinder.conf will have 2 new configuration options, short_host_name_template and port_group_name_template.

• If a storage group, masking view or initiator group in the old naming convention already exists, this remains and any new attaches will use the new naming convention where the label for the short host name and/or port group has been customized by the user.

• Only the short host name and port group name components can be renamed within the storage group, initiator group and masking view names.

• If the powermax_short_host_name_template and powermax_port_group_name_template do not adhere to the rules, then the operation will fail early and gracefully with a clear description as to the problem.

• The templates cannot be changed once volumes have been attached using the new configuration.

• If only one of the templates are configured, then the other will revert to the default option.

• The UUID is generated from the MD5 hash of the full short host name and port group name

• If userdef is used, the onus is on the user to make sure it will be unique among all short host names (controller and compute nodes) and unique among port groups.

Configure a single replication target¶

1. Configure an SRDF group between the chosen source and target arrays for the PowerMax Cinder driver to use. The source array must correspond with the powermax_array entry in cinder.conf.

2. Select both the director and the ports for the SRDF emulation to use on both sides. Bear in mind that network topology is important when choosing director endpoints. Supported modes are Synchronous, Asynchronous, and Metro.

   Note

   If the source and target arrays are not managed by the same Unisphere server (that is, the target array is remotely connected to server - for example, if you are using embedded management), in the event of a full disaster scenario (i.e. the primary array is completely lost and all connectivity to it is gone), the Unisphere server would no longer be able to contact the target array. In this scenario, the volumes would be automatically failed over to the target array, but administrator intervention would be required to either; configure the target (remote) array as local to the current Unisphere server (if it is a stand-alone server), or enter the details of a second Unisphere server to the cinder.conf, which is locally connected to the target array (for example, the embedded management Unisphere server of the target array), and restart the Cinder volume service.

   Note

   If you are setting up an SRDF/Metro configuration, it is recommended that you configure a Witness or vWitness for bias management. Please see the SRDF Metro Overview & Best Practices guide for more information.

   Note

   The PowerMax Cinder drivers do not support Cascaded SRDF.

   Note

   The transmit idle functionality must be disabled on the R2 array for Asynchronous rdf groups. If this is not disabled it will prevent failover promotion in the event of access to the R1 array being lost.

   # symrdf -sid <sid> -rdfg <rdfg> set rdfa -transmit_idle off
   

   Note

   When creating RDF enabled volumes, if there are existing volumes in the target storage group, all rdf pairs related to that storage group must have the same rdf state i.e. rdf pair states must be consistent across all volumes in a storage group when attempting to create a new replication enabled volume. If mixed rdf pair states are found during a volume creation attempt, an error will be raised by the rdf state validation checks. In this event, please wait until all volumes in the storage group have reached a consistent state.

3. Enable replication in /etc/cinder/cinder.conf. To enable the replication functionality in PowerMax Cinder driver, it is necessary to create a replication volume-type. The corresponding back-end stanza in cinder.conf for this volume-type must then include a replication_device parameter. This parameter defines a single replication target array and takes the form of a list of key value pairs.

   enabled_backends = POWERMAX_FC_REPLICATION
   [POWERMAX_FC_REPLICATION]
   volume_driver = cinder.volume.drivers.dell_emc.powermax.fc.PowerMaxFCDriver
   san_ip = 10.10.10.10
   san_login = my_u4v_username
   san_password = my_u4v_password
   powermax_srp = SRP_1
   powermax_array = 000123456789
   powermax_port_groups = [OS-FC-PG]
   volume_backend_name = POWERMAX_FC_REPLICATION
   replication_device = target_device_id:000197811111,
                        remote_port_group:os-failover-pg,
                        remote_pool:SRP_1,
                        rdf_group_label: 28_11_07,
                        mode:Metro,
                        metro_use_bias:False,
                        sync_interval:3,
                        sync_retries:200
   

   Note

   replication_device key value pairs will need to be on the same line (separated by commas) in cinder.conf. They are displayed here on separate lines above for improved readability.

   • target_device_id The unique PowerMax array serial number of the target array. For full failover functionality, the source and target PowerMax arrays must be discovered and managed by the same U4V server.

   • remote_port_group The name of a PowerMax port group that has been pre-configured to expose volumes managed by this backend in the event of a failover. Make sure that this port group contains either all FC or all iSCSI port groups (for a given back end), as appropriate for the configured driver (iSCSI or FC).

   • remote_pool The unique pool name for the given target array.

   • rdf_group_label The name of a PowerMax SRDF group that has been pre-configured between the source and target arrays.

   • mode The SRDF replication mode. Options are Synchronous, Asynchronous, and Metro. This defaults to Synchronous if not set.

   • metro_use_bias Flag to indicate if ‘bias’ protection should be used instead of Witness. This defaults to False.

   • sync_interval How long in seconds to wait between intervals for SRDF sync checks during Cinder PowerMax SRDF operations. Default is 3 seconds.

   • sync_retries How many times to retry RDF sync checks during Cinder PowerMax SRDF operations. Default is 200 retries.

   • allow_extend Only applicable to VMAX-Hybrid arrays or All Flash arrays running HyperMax OS (5977). It is a flag for allowing the extension of replicated volumes. To extend a volume in an SRDF relationship, this relationship must first be broken, the R1 device extended, and a new device pair established. If not explicitly set, this flag defaults to False.

     Note

     As the SRDF link must be severed, due caution should be exercised when performing this operation. If absolutely necessary, only one source and target pair should be extended at a time (only only applicable to VMAX-Hybrid arrays or All Flash arrays with HyperMax OS).

4. Create a replication-enabled volume type. Once the replication_device parameter has been entered in the PowerMax backend entry in the cinder.conf, a corresponding volume type needs to be created replication_enabled property set. See above Create volume types for details.

   # openstack volume type set --property replication_enabled="<is> True" \
                         POWERMAX_FC_REPLICATION
   

   Note

   Service Level and Workload: An attempt will be made to create a storage group on the target array with the same service level and workload combination as the primary. However, if this combination is unavailable on the target (for example, in a situation where the source array is a VMAX-Hybrid, the target array is an All Flash, and an All Flash incompatible service level like Bronze is configured), no service level will be applied.

Configure multiple replication targets¶

Setting multiple replication devices in cinder.conf allows the use of all the supported replication modes simultaneously. Up to three replication devices can be set, one for each of the replication modes available. An additional volume type extra spec (storagetype:replication_device_backend_id) is then used to determine which replication device should be utilized when attempting to perform an operation on a volume which is replication enabled. All details, guidelines and recommendations set out in the Configure a single replication target section also apply in a multiple replication device scenario.

Multiple replication targets limitations and restrictions:

1. There can only be one of each replication mode present across all of the replication devices set in cinder.conf.

2. Details for target_device_id, remote_port_group and remote_pool should be identical across replication devices.

3. The backend_id and rdf_group_label values must be unique across all replication devices.

Adding additional replication_device to cinder.conf:

1. Open cinder.conf for editing

2. If a replication device is already present, add the backend_id key with a value of backend_id_legacy_rep. If this key is already defined, it’s value must be updated to backend_id_legacy_rep.

3. Add the additional replication devices to the backend stanza. Any additional replication devices must have a backend_id key set. The value of these must not be backend_id_legacy_rep.

Example existing backend stanza pre-multiple replication:

enabled_backends = POWERMAX_FC_REPLICATION

[POWERMAX_FC_REPLICATION]
volume_driver = cinder.volume.drivers.dell_emc.powermax.fc.PowerMaxFCDriver
san_ip = 10.10.10.10
san_login = my_u4v_username
san_password = my_u4v_password
powermax_srp = SRP_1
powermax_array = 000123456789
powermax_port_groups = [OS-FC-PG]
volume_backend_name = POWERMAX_FC_REPLICATION
replication_device = backend_id:id,
                     target_device_id:000197811111,
                     remote_port_group:os-failover-pg,
                     remote_pool:SRP_1,
                     rdf_group_label: 28_11_07,
                     mode:Metro,
                     metro_use_bias:False,
                     sync_interval:3,
                     sync_retries:200

Example updated backend stanza:

enabled_backends = POWERMAX_FC_REPLICATION

[POWERMAX_FC_REPLICATION]
volume_driver = cinder.volume.drivers.dell_emc.powermax.fc.PowerMaxFCDriver
san_ip = 10.10.10.10
san_login = my_u4v_username
san_password = my_u4v_password
powermax_srp = SRP_1
powermax_array = 000123456789
powermax_port_groups = [OS-FC-PG]
volume_backend_name = POWERMAX_FC_REPLICATION
replication_device = backend_id:backend_id_legacy_rep
                     target_device_id:000197811111,
                     remote_port_group:os-failover-pg,
                     remote_pool:SRP_1,
                     rdf_group_label: 28_11_07,
                     mode:Metro,
                     metro_use_bias:False,
                     sync_interval:3,
                     sync_retries:200
replication_device = backend_id:sync-rep-id
                     target_device_id:000197811111,
                     remote_port_group:os-failover-pg,
                     remote_pool:SRP_1,
                     rdf_group_label: 29_12_08,
                     mode:Synchronous,
                     sync_interval:3,
                     sync_retries:200
replication_device = backend_id:async-rep-id
                     target_device_id:000197811111,
                     remote_port_group:os-failover-pg,
                     remote_pool:SRP_1,
                     rdf_group_label: 30_13_09,
                     mode:Asynchronous,
                     sync_interval:3,
                     sync_retries:200

The additional replication devices defined in cinder.conf will be detected after restarting the cinder volume service.

To specify which replication_device a volume type should use an additional property named storagetype:replication_device_backend_id must be added to the extra specs of the volume type. The id value assigned to the storagetype:replication_device_backend_id key in the volume type must match the backend_id assigned to the replication_device in cinder.conf.

# openstack volume type set \
--property storagetype:replication_device_backend_id="<id>" \
<VOLUME_TYPE>

Volume replication interoperability with other features¶

Most features are supported, except for the following:

• Replication Group operations are available for volumes in Synchronous mode only.

• The Ussuri release of OpenStack supports retyping in-use volumes to and from replication enabled volume types with limited exception of volumes with Metro replication enabled. To retype to a volume-type that is Metro enabled the volume must first be detached then retyped. The reason for this is so the paths from the Nova instance to the Metro R1 & R2 volumes must be initialised, this is not possible on the R2 device whilst a volume is attached.

• The image volume cache functionality is supported (enabled by setting image_volume_cache_enabled = True), but one of two actions must be taken when creating the cached volume:

  • The first boot volume created on a backend (which will trigger the cached volume to be created) should be the smallest necessary size. For example, if the minimum size disk to hold an image is 5GB, create the first boot volume as 5GB. All subsequent boot volumes are extended to the user specific size.

  • Alternatively, ensure that the allow_extend option in the replication_device parameter is set to True. This is only applicable to VMAX-Hybrid arrays or All Flash array with HyperMax OS.

Failover host¶

In the event of a disaster, or where there is required downtime, upgrade of the primary array for example, the administrator can issue the failover host command to failover to the configured target:

# cinder failover-host cinder_host@POWERMAX_FC_REPLICATION

After issuing cinder failover-host Cinder will set the R2 array as the target array for Cinder, however, to get existing instances to use this new array and paths to volumes it is necessary to first shelve Nova instances and then unshelve them, this will effectively restart the Nova instance and re-establish data paths between Nova instances and the volumes on the R2 array.

# nova shelve <server>
# nova unshelve [--availability-zone <availability_zone>] <server>

When a host is in failover mode performing normal volume or snapshot provisioning will not be possible, failover host mode simply provides access to replicated volumes to minimise environment down-time. The primary objective whilst in failover mode should be to get the R1 array back online. When the primary array becomes available again, you can initiate a fail-back using the same failover command and specifying --backend_id default:

# cinder failover-host cinder_host@POWERMAX_FC_REPLICATION --backend_id default

After issuing the failover command to revert to the default backend host it is necessary to re-issue the Nova shelve and unshelve commands to restore the data paths between Nova instances and their corresponding back end volumes. Once reverted to the default backend volume and snapshot provisioning operations can continue as normal.

Failover promotion¶

Failover promotion can be used to transfer all existing RDF enabled volumes to the R2 array and overwrite any references to the original R1 array. This can be used in the event of total R1 array failure or in other cases where an array transfer is warranted. If the R1 array is online and working and the RDF links are still enabled the failover promotion will automatically delete rdf pairs as necessary. If the R1 array or the link to the R1 array is down, a half deletepair must be issued manually for those volumes during the failover promotion.

1. Issue failover command:

# cinder failover-host <host>

2. Enable array promotion:

# cinder failover-host --backend_id=pmax_failover_start_array_promotion <host>

3. View and re-enable the cinder service

# cinder service-list
# cinder service-enable <host> <binary>

4. Remove all volumes from volume groups

# cinder --os-volume-api-version 3.13 group-update --remove-volumes <Vol1ID, etc..> <volume_group_name>

5. Detach all volumes that are attached to instances

# openstack server remove volume <instance_id> <volume_id>

# cinder --os-volume-api-version 3.50 attachment-delete <attachment_id>

6. Delete all remaining instances

# nova delete <instance_id>

7. Create new volume types

New volume types must be created with references to the remote array. All new volume types must adhere to the following guidelines:

1. Uses the same workload, SLO & compression setting as the previous R1 volume type.
2. Uses the remote array instead of the primary for its pool name.
3. Uses the same volume_backend_name as the previous volume type.
4. Must not have replication enabled.

Example existing volume type extra specs.

pool_name='Gold+None+SRP_1+000297900330', replication_enabled='<is> True',
storagetype:replication_device_backend_id='async-rep-1', volume_backend_name='POWERMAX_ISCSI_NONE'

Example new volume type extra specs.

pool_name='Gold+None+SRP_1+000197900049', volume_backend_name='POWERMAX_ISCSI_NONE'

8. Retype volumes to new volume types

Additional checks will be performed during failover promotion retype to ensure workload, compression and slo settings meet the criteria specified above when creating the new volume types.

# cinder retype --migration-policy on-demand <volume> <volume_type>

8.a. Retype and RDF half deletepair

In instances where the rdf links are offline and rdf pairs have been set to partitioned state there are additional requirements. In that scenario the following order should be adhered to:

1. Retype all Synchronous volumes.
2. Half_deletepair all Synchronous volumes using the default storage group.
3. Retype all Asynchronous volumes.
4. Half_deletepair all Asynchronous volumes using their management storage group.
5. Retype all Metro volumes.
6. Half_deletepair all Metro volumes using their management storage group.
7. Delete the Asynchronous and Metro management storage groups.

# symrdf -sid <sid> -sg <sg> -rdfg <rdfg> -force -symforce half_deletepair

9. Issue failback

Issuing the failback command will disable both the failover and promotion flags. Please ensure all volumes have been retyped and all replication pairs have been deleted before issuing this command.

# cinder failover-host --backend_id default <host>

10. Update cinder.conf

Update the cinder.conf file to include details for the new primary array. For more information please see the Configure block storage in cinder.conf section of this documentation.

11. Restart the cinder services

Restart the cinder volume service to allow it to detect the changes made to the cinder.conf file.

12. Set Metro volumes to ready state

Metro volumes will be set to a Not Ready state after performing rdf pair cleanup. Set these volumes back to Ready state to allow them to be attached to instances. The U4P instance must be restarted for this change to be detected.

# symdev -sid <sid> ready -devs <dev_id1, dev_id2>

Asynchronous and metro replication management groups¶

Asynchronous and metro volumes in an RDF session, i.e. belonging to an SRDF group, must be managed together for RDF operations (although there is a consistency exempt option for creating and deleting pairs in an Async group). To facilitate this management, we create an internal RDF management storage group on the backend. This RDF management storage group will use the following naming convention:

OS-[rdf_group_label]-[replication_mode]-rdf-sg

It is crucial for correct management that the volumes in this storage group directly correspond to the volumes in the RDF group. For this reason, it is imperative that the RDF group specified in the cinder.conf is for the exclusive use by this Cinder backend. If there are any issues with the state of your RDF enabled volumes prior to performing additional operations in Cinder you will be notified in the Cinder volume logs.

Metro support¶

SRDF/Metro is a high availability solution. It works by masking both sides of the RDF relationship to the host, and presenting all paths to the host, appearing that they all point to the one device. In order to do this, there needs to be multi-path software running to manage writing to the multiple paths.

Consistent group snapshot¶

To create a consistent group snapshot, set a group-spec, having the key consistent_group_snapshot_enabled set to <is> True on the group.

# cinder --os-volume-api-version 3.11 group-type-key GROUP_TYPE set consistent_group_snapshot_enabled="<is> True"

Similarly the same key should be set on any volume type which is specified while creating the group.

# openstack volume type set --property consistent_group_snapshot_enabled="<is> True" POWERMAX_GROUP

If this key is not set on the group-spec or volume type, then the generic volume group will be created/managed by Cinder (not the PowerMax driver).

Replication groups¶

As with Consistent group snapshot consistent_group_snapshot_enabled should be set to true on the group and the volume type for replication groups. Only Synchronous replication is supported for use with Replication Groups. When a volume is created into a replication group, replication is on by default. The disable_replication api suspends I/O traffic on the devices, but does NOT remove replication for the group. The enable_replication api resumes I/O traffic on the RDF links. The failover_group api allows a group to be failed over and back without failing over the entire host. See below for usage.

Storage group names¶

Storage groups are created on the PowerMax as a result of creation of generic volume groups. These storage groups follow a different naming convention and are of the following format depending upon whether the groups have a name.

TruncatedGroupName_GroupUUID or GroupUUID

Group type, group, and group snapshot operations¶

Please refer to the official OpenStack block-storage groups documentation for the most up to date group operations

Group replication operations¶

Generic volume group operations no longer require the user to specify the Cinder CLI version, however, performing generic volume group replication operations still require this setting. When running generic volume group commands set the value --os-volume-api-version to 3.38. These commands are not listed in the latest Cinder CLI documentation so will remain here until added to the latest Cinder CLI version or deprecated from Cinder.

This is how to create a replication group. Please refer to the official OpenStack block-storage groups documentation for the most up to date group operations.

• Make sure there is a replication_device for Synchronous in cinder.conf

replication_device = backend_id:backend_id_legacy_rep,target_device_id:0001234567890,remote_port_group:PG1,remote_pool:SRP_1,rdf_group_label:os-sync,mode:Synchronous

• Create a volume type with property replication_enabled=’<is> True’.

$ openstack volume type create --property replication_enabled='<is> True' SYNC_REP_VT

• Create a Generic group type with extra specs consistent_group_snapshot_enabled=’<is> True’ and consistent_group_replication_enabled=’<is> True’.

$ cinder --os-volume-api-version 3.38 group-type-create GROUP_REP_VT
$ cinder --os-volume-api-version 3.38 group-type-key GROUP_REP_VT set \
  consistent_group_snapshot_enabled='<is> True' \
  consistent_group_replication_enabled='<is> True'

• Create a Generic group with synchronous volume type SYNC_REP_VT

$ cinder --os-volume-api-version 3.13 group-create --name GROUP_REP GROUP_REP_VT GROUP_REP_VT

• Create a volume in the Generic group

$ cinder --os-volume-api-version 3.38 create --volume-type SYNC_REP_VT --group-id GROUP_REP \
  --name VOL_REP_GROUP 1

• Enable group replication

$ cinder --os-volume-api-version 3.38 group-enable-replication GROUP_REP

• Disable group replication

$ cinder --os-volume-api-version 3.38 group-disable-replication GROUP_REP

• Failover group

$ cinder --os-volume-api-version 3.38 group-failover-replication GROUP_REP

• Failback group

$ cinder --os-volume-api-version 3.38 group-failover-replication GROUP_REP \
     --secondary-backend-id default

Manage volumes¶

With your pool name defined you can now manage the volume into OpenStack, this is possible with the CLI command cinder manage. The bootable parameter is optional in the command, if the volume to be managed into OpenStack is not bootable leave this parameter out. OpenStack will also determine the size of the value when it is managed so there is no need to specify the volume size.

Command format:

$ cinder manage --name <new_volume_name> --volume-type <powermax_vol_type> \
  --availability-zone <av_zone> <--bootable> <host> <identifier>

Command Example:

$ cinder manage --name powermax_managed_volume --volume-type POWERMAX_ISCSI_DIAMOND \
  --availability-zone nova demo@POWERMAX_ISCSI_DIAMOND#Diamond+SRP_1+111111111111 031D8

After the above command has been run, the volume will be available for use in the same way as any other OpenStack PowerMax volume.

Managing volumes with replication enabled¶

Whilst it is not possible to manage volumes into OpenStack that are part of a SRDF relationship, it is possible to manage a volume into OpenStack and enable replication at the same time. This is done by having a replication enabled PowerMax volume type (for more information see section Volume Replication) during the manage volume process you specify the replication volume type as the chosen volume type. Once managed, replication will be enabled for that volume.

Unmanage volume¶

Unmanaging a volume is not the same as deleting a volume. When a volume is deleted from OpenStack, it is also deleted from the PowerMax at the same time. Unmanaging a volume is the process whereby a volume is removed from OpenStack but it remains for further use on the PowerMax. The volume can also be managed back into OpenStack at a later date using the process discussed in the previous section. Unmanaging volume is carried out using the Cinder unmanage CLI command:

Command format:

$ cinder unmanage <volume_name/volume_id>

Command example:

$ cinder unmanage powermax_test_vol

Once unmanaged from OpenStack, the volume can still be retrieved using its device ID or OpenStack volume ID. Within Unisphere you will also notice that the OS- prefix has been removed, this is another visual indication that the volume is no longer managed by OpenStack.

Manage SnapVX snapshot¶

It is possible to manage PowerMax SnapVX snapshots into OpenStack, where the source volume from which the snapshot is taken already exists in, and is managed by OpenStack Cinder. The source volume may have been created in OpenStack Cinder, or it may have been managed in to OpenStack Cinder also. With the support of managing SnapVX snapshots included in OpenStack Queens, the restriction around managing SnapVX source volumes has been removed.

Requirements/restrictions:

1. The SnapVX source volume must be present in and managed by Cinder.

2. The SnapVX snapshot name must not begin with OS-.

3. The SnapVX snapshot source volume must not be in a failed-over state.

4. Managing a SnapVX snapshot will only be allowed if the snapshot has no linked target volumes.

Command structure:

1. Identify your SnapVX snapshot for management on the PowerMax, note the name.

2. Ensure the source volume is already managed into OpenStack Cinder, note the device ID.

3. Using the Cinder CLI, use the following command structure to manage a Snapshot into OpenStack Cinder:

$ cinder snapshot-manage --id-type source-name
                         [--name <name>]
                         [--description <description>]
                         [--metadata [<key=value> [<key=value> ...]]]
                         <volume name/id> <identifier>

Positional arguments:

• <volume name/id> Source OpenStack volume name

• <identifier> Name of existing snapshot on PowerMax backend

Optional arguments:

• --name <name> Snapshot name (Default=``None``)

• --description <description> Snapshot description (Default=``None``)

• --metadata [<key=value> [<key=value> ...]] Metadata key=value pairs (Default=``None``)

Example:

$ cinder snapshot-manage --name SnapshotManaged \
                         --description "Managed Queens Feb18" \
                         powermax-vol-1 PowerMaxSnapshot

Where:

• The name in OpenStack after managing the SnapVX snapshot will be SnapshotManaged.

• The snapshot will have the description Managed Queens Feb18.

• The Cinder volume name is powermax-vol-1.

• The name of the SnapVX snapshot on the PowerMax backend is PowerMaxSnapshot.

Outcome:

After the process of managing the Snapshot has completed, the SnapVX snapshot on the PowerMax backend will be prefixed by the letters OS-, leaving the snapshot in this example named OS-PowerMaxSnapshot. The associated snapshot managed by Cinder will be present for use under the name SnapshotManaged.

Unmanage cinder snapshot¶

Unmanaging a snapshot in Cinder is the process whereby the snapshot is removed from and no longer managed by Cinder, but it still exists on the storage backend. Unmanaging a SnapVX snapshot in OpenStack Cinder follows this behaviour, whereby after unmanaging a PowerMax SnapVX snapshot from Cinder, the snapshot is removed from OpenStack but is still present for use on the PowerMax backend.

Requirements/Restrictions:

• The SnapVX source volume must not be in a failed over state.

Command Structure:

Identify the SnapVX snapshot you want to unmanage from OpenStack Cinder, note the snapshot name or ID as specified by Cinder. Using the Cinder CLI use the following command structure to unmanage the SnapVX snapshot from Cinder:

$ cinder snapshot-unmanage <snapshot>

Positional arguments:

• <snapshot> Cinder snapshot name or ID.

Example:

$ cinder snapshot-unmanage SnapshotManaged

Where:

• The SnapVX snapshot name in OpenStack Cinder is SnapshotManaged.

After the process of unmanaging the SnapVX snapshot in Cinder, the snapshot on the PowerMax backend will have the OS- prefix removed to indicate it is no longer OpenStack managed. In the example above, the snapshot after unmanaging from OpenStack will be named PowerMaxSnapshot on the storage backend.

Manageable volumes¶

Volumes that can be managed by and imported into Openstack.

List manageable volume is filtered by:

• Volume size should be 1026MB or greater (1GB PowerMax Cinder Vol = 1026 MB)

• Volume size should be a whole integer GB capacity

• Volume should not be a part of masking view.

• Volume status should be Ready

• Volume service state should be Normal

• Volume emulation type should be FBA

• Volume configuration should be TDEV

• Volume should not be a system resource.

• Volume should not be private

• Volume should not be encapsulated

• Volume should not be reserved

• Volume should not be a part of an RDF session

• Volume should not be a SnapVX Target

• Volume identifier should not begin with OS-.

• Volume should not be in more than one storage group.

Manageable snaphots¶

Snapshots that can be managed by and imported into Openstack

List manageable snapshots is filtered by:

• The source volume should be marked as SnapVX source.

• The source volume should be 1026MB or greater

• The source volume should be a whole integer GB capacity.

• The source volume emulation type should be FBA.

• The source volume configuration should be TDEV.

• The source volume should not be private.

• The source volume should be not be a system resource.

• The snapshot identifier should not start with OS- or temp-.

• The snapshot should not be expired.

• The snapshot generation number should npt be greater than 0.

Calculating load¶

The process by which Port Group or Port load is calculated is the same for both. The user specifies the look back window which determines how many performance intervals to measure, 60 minutes will give 12 intervals of 5 minutes each for example. If no lookback window is specified or is set to 0 only the most recent performance metric will be analysed. This will give a slight performance improvement but with the improvements made to the performance REST endpoints for load this improvement is negligible. For real-time stats a minimum of 1 minute is required.

Once a call is made to the performance REST endpoints, the performance data for that PG or port is extracted. Then the metric values are summed and divided by the count of intervals to get the average for the look back window.

The performance metric average value for each asset is added to a Python heap. Once all assets have been measured the lowest value will always be at position 0 in the heap so there is no extra time penalty requirement for search.

Pre-requisites¶

Before load balancing can be enabled in the PowerMax for Cinder driver performance metrics collection must be enabled in Unisphere. Real-time performance metrics collection is enabled separately from diagnostic metrics collection. Performance metric collection is only available for local arrays in Unisphere.

After performance metrics registration there is a time delay before Unisphere records performance metrics, adequate time must be given before enabling load balancing in Cinder else default random selection method will be used. It is recommended to wait 4 hours after performance registration before enabling load balancing in Cinder.

Configuration¶

A number of configuration options are available for users so load balancing can be set to better suit the needs of the environment. These configuration options are detailed in the table below.

Port-Group Metrics¶

Port Metrics¶