SRA 5.1.0 Release Notes

New in this Release

• A new feature to set a preferred array protection group for volumes that are in multiple array protection groups is added to SRA 5.1.0. Setting preferred array protection groups for array volumes requires setting a tag on the volumes specifying the preferred array protection group.

  • Using the preferred protection group and the workflow with the FlashArray PowerShell SDK can be found here. There is work to integrate this feature with the vSphere Plugin, once this work is complete a link will be provided.

Fixed Issues

• TMAN-19987: Fixed an issue where the re-protect operation would fail when volumes were part of ratcheted default protection groups. This issue is fixed in SRA 5.1.0

Known Issues

1. ActiveDR:

   • If there are volumes in an ActiveDR pod that are presented to the VMware environment but not in use as an RDM or a VMFS, a recovery will succeed but a subsequent reprotect will fail. To complete the reprotect, the volumes should be removed or manually tagged.

   • If a source pod is already demoted when a planned migration recovery is attempted, the process will fail and a disaster recovery is required or the source pod must be manually promoted before the recovery can be re-attempted.

   • Non-VMware volumes cannot be in an ActiveDR pod controlled by SRM. All volumes in the pod must be present and in use as an RDM or VMFS in the VMware environment connected to the SRM pair.

2. ActiveCluster:

   • Pods protected by SRM cannot be renamed. ActiveDR pods can be renamed. Pods in use with ActiveCluster to third site cannot be renamed.

   • Failback or reprotect from an asynchronous target into a stretched pod is not supported. Pods much be first unstretched before a failback from an asynchronous distance target.

3. General

   • Volume names must be less than 42 characters in length except for ActiveDR volumes--these can be up to full supported length of the FlashArray.

   • At it's current release SRA depends on the volumes source name to identify which volumes are recovered during test failover and failover workflows. This is being changed in a future release, however this does expose a problem when volumes have a source name that does not match where the volume's current source name is. In Purity the volume name is constructed as either "volumeName" , "vgroupName/volumeName" , "podName::volumeName" or "podName::vgroupName/volumeName". A protection group volume snapshot has fields for a name "pgroupName.snapPrefix.volName" and a source "volName" with the "volName having any combination of the previous volume name constructions just covered.

     When volumes are moved between Pods, volume groups or both, the volume snapshot source name does not change. However, the SRA depends on the source name to correctly identify the recovered objects in the test failover and failover workflows. In the event that the volume name and the source name do not have matching "volName" strings, an error will appear in SRM that the recovered volume could not be found. With the release of SRA 5.0.3, a workaround is available in case this situation occurs, but a larger fix for this will be coming in a future release of SRA.

   • At this time Everpure will not support protecting non-vVol FlashArray Volumes that are in Volume Groups. Any support offered by Pure will be best effort. The reason for this is that there are several caveats when using vgroups with SRM that could lead to DR failovers failing. There has not been enough testing in each of these edge case situations, and getting back into a good state often requires removing both the Array and SRM protection groups to start from a clean start. This can be both time consuming and leave VMs in an unprotected state, thus the decision not to recommend the use of vgroups with SRM. This will be resolved in a future SRA release.

   • Best practice and recommendation from Everpure is to place volumes in protection groups for use with SRM protection groups and recovery plans. Using Hosts or Host Groups as placement for volumes to be protected by SRM has inconsistent behavior and support for this would be best effort. Everpure is working to improve these workflows for a future release of the SRA when using host or host groups, but at this time Everpure would recommend to avoid using Host or Host Group placement for FlashArray protection groups.

   • Volumes that are in multiple protection groups (added explicitly as volumes or implicitly by hosts/host groups) on a source array will very likely have issues when running SRM workflows. The recommendation is to only have the volume be a member of a single protection group. Because of the point above, adding a host or host group to a protection group for SRM is not currently supported. This is something Everpure is working to improve in a future release of the Storage Replication Adapter (SRA) for Site Recovery Manager (SRM).

   • If either FlashArray has been renamed after they have been connected, all test failovers, failovers and reprotects will not execute completely. This is due to the array pair naming not getting updated if either array is renamed (if purearray list --connect is ran from the CLI, the previous names will show). Should an array be renamed, the recommend remediation if using only async replication is to disconnect the FlashArrays and reconnect them. Should ActiveCluster be enabled, the recommended remediation is to run through the purearray connect process from the array that had the connection initiated from initially.