Skip to main content
Pure Technical Services

Release Notes: Storage Replication Adapter for Site Recovery Manager

Currently viewing public documentation. Please login to access the full scope of documentation.

The Pure Storage® FlashArray™ Storage Replication Adapter (SRA, PureSRA) is a plugin for the VMware® vCenter™ Site Recovery Manager™ (SRM). The Pure Storage SRA ensures the integration of both FlashArray storage and Purity replication with VMware vCenter Site Recovery Manager, with these advantages:

  • FlashArray's unique data reduction (pattern elimination, deduplication, and compression) and ultra-efficient micro-provisioning of physical storage
  • Simple configuration that does not require professional services involvement
  • Flexible, policy-based automation of replication
  • Support for bi-directional protection
  • Support for ActiveCluster synchronous replication (v3.0 and above)
  • Support for asynchronous replication from an ActiveCluster pod (v3.1 and above)
  • Support for ActiveDR replication (v4.0 and above)

SRA Release Timeline

Release Release Date
4.0 August, 2020
3.1 April, 2020
3.0.154 May, 2019
3.0.14 July, 2018
2.0 December, 2016
1.5 December, 2015
1.0 December, 2014

SRA 4.0 Release Notes

Release: August, 2020

SRA 4.0 is  supported for the Linux SRM Server and the Windows-based SRM. This is the last release to be supported with a Windows-based SRM deployment.

New in This Release

  • Adds support for failover and test failover from a pod to a remote pod that are linked via ActiveDR replication.

  • Volume renames are no longer required during failover, Purity tags are used for ActiveDR volumes

  • ActiveDR pods can be renamed at will.

  • Purity 6.0.x or higher is required for ActiveDR

Fixed Issues

SRA pod-to-third site pairs are showing up in array discovery without asynchronous replication protection group.

  • All pods showed up as array pairs to all remote FlashArray connections even if they did not have replication enabled in them to that array. In this release only pods with an enabled asynchronous connection to a FlashArray will show up as valid array pair

"Snapshot limit reached." error during SRM failover/recovery allows process to continue, creating inconsistent failover/failback during SRM activities

  • If the snapshot limit has been reached, there is now a clear error message indicating such

Windows SRA wrong timestamp format in testFailover response

  • Incorrect timestamp format could cause test recovery to fail. This has been fixed.

Certain failure modes could cause the SRA to not be able to failover from a pod to a third site

  • This workflow has been corrected and all situations where failures on the source site array can be tolerated by the SRA.

Known Issues

  1. Pods protected by SRM cannot be renamed. ActiveDR pods can be renamed. Pods in use with ActiveCluster to third site cannot be renamed.
  2. Virtual volumes are not supported in a pod protected by SRM.
  3. 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.
  4. 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
  5. 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.
  6. New volumes cannot be provisioned into a target pod during the test state, nor during the promoted "target"-side pod after a failover and before a reprotect.
  7. Verbose logging can fill up SRM data volumes. This is being investigated with VMware but will also be patched from the SRA side in an upcoming release.
  8. If the ActiveDR replication link is paused, the syncOnce operation will continue indefinitely. This will be fixed in an upcoming release. If Synchronization steps in SRM test recovery, recovery, or reprotection is stalled, ensure the replication link is enabled and if not, enable it.
  9. If locks remain on virtual machine during a failover (meaning the virtual machines cannot be powered down gracefully) a SRM failover will not complete successfully as the source SRM server is down and cannot shut down the source VMs. Therefore the VM locks will still be held by the source ESXi host(s) and failover will not succeed. This can occur if 1) Source SRM server fails 2) Source vCenter fails 3) Network partition to ESXi hosts from vCenter. If the array fails, the SAN fails, or the compute fails entirely this issue does not occur. To resolve this, you will need to manually shut down the VMs on the source site or, if not possible, manually disconnect the storage on the source site on the source FlashArray from the host/host groups (a future release of the SRA will provide a function to attempt the latter of the two). 

SRA 3.1 Release Notes

Release: April, 2020

SRA 3.1 is only supported for the Linux SRM Server

New in This Release

Supports for asynchronous replication together with ActiveCluster synchronous replication
Adds support for asynchronous failover from a pod (either stretched or unstretched) that is protected by Active cluster synchronous replication, including the following operations:
  • Recovering virtual machines using point-in-time snapshots as well as synchronous replication
  • Recovering volumes within a protection group that is within an ActiveCluster pod
Purity 5.2.x or higher is required for asynchronous replication from a pod.
Resolves an error importing certificates
Previously, with plugin version 3.0.154 installed on the Linux SRM Server version 8.2, the error “Unable to load shared library” was seen when importing a signed certificate from an offline Certificate Authority.
Improves device discovery times at scale
 
FlashArray//C support

Known Issues and Best Practices

  1. Pods protected by SRM cannot be renamed.
  2. Virtual volumes are not supported in a pod protected by SRM.
  3. Failback or reprotect into a stretched pod is not supported.

 

SRA 3.0.154 Release Notes

Release: May, 2019

New in This Release

Supports the SRM 8.2 Linux Appliance
SRA 3.0.154 support VMware SRM version 8.2 for Linux.

Known Issues and Best Practices

  1. Volume group names are trimmed in the snapshot source when array replication type is changed or is disconnected.  In the vSphere SRM GUI, planned failover and disaster failover will show the status of partially recovered and throw errors for volumes in vgroups, a test failover will also show warnings.  This is only an issue for datastore volumes in volume groups, all other datastores are not be affected.
  2. When using ActiveCluster with SRM, ensure the personality for all Purity hosts connecting to ESXi servers is set to ‘esxi’.  Failure to do so may cause datastores backed by ActiveCluster stretched pods to become inaccessible after an interruption to the stretched storage connection.
  3. If either FlashArray has been renamed after they have been connected, all test failovers, failovers and reprotects will not execute completely.  The 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.
  4. After upgrading to PureSRA 3.0, it will be necessary to disable and re-enable the array manager used by PureSRA.  PureSRA 3.0 supports stretched storage so all existing array managers will need to be restarted to trigger a discover arrays operation.
  5. Failover and test failovers of volumes inside a volume group may fail if there is a replicated protection group with a host or host group as a member. A future release of Purity will fix this, but for now, a workaround will be to either not use volume groups, or make sure there are no replicated protection groups with hosts and members.
  6. If volumes are in the process of being deleted during a SRM device discovery operation, the discovery can inadvertently fail. This is a known issue and will be resolved. If this occurs re-run the operation within SRM so the device discovery can be retried. This is most likely to occur in dynamic environments with vvols where VMs (and therefore their virtual volumes) are often migrated across arrays.

    The error will look something like:

    ERROR!
    649 com.vmware.vim.binding.dr.storage.fault.CommandFailed: SRA command 'discoverDevices' failed. Array operation failed: "PureRestException: HttpStatusCode = 'BadRequest', RestErrorCode = 'NotExist', Details = '["msg":"Volume does not exist.","ctx":"pod1::sync-vmfs"]', InnerException = 'System.Net.WebException: The remote server returned an error: (400) Bad Request.
    
    
  7. When using ActiveCluster with SRM, if the Stretched Pods are in a state of Resyncing, the device discovery will fail.  You will need to run the device discovery once all stretched pods are in sync.
  8. After installing the SRA to the Linux SRM Server an error that the SRA Upload failed may appear.  There is a issue with the SRM Server that after the SRA has installed the SRM browser session is closed.  The SRA should show up as installed after refreshing the SRM page.

Release Compatibility

  • Supports SRM version 8.2 for Linux.
  • Support REST API version 1.3 or higher for asynchronous (snapshot) replication.  
  • REST API version 1.13 (Purity 5.0) is required for stretched storage support.
  • At this time Pure Storage will not support protecting 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 times 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.
  • With Purity Version 5.2.0 the feature to Async Replicate Volumes in a Stretched Pod was introduced.  With SRA 3.0.154, there is no support for using SRM with volumes in a stretched pod that have an array protection group associated with the pod using async replication to a 3rd site.  The Volumes in that Array Protection group will not show up in the devices discovery page.  Pure Storage is working to support this feature in a future SRA release.

Installation

The installation process has changed for SRM 8.2 Linux

  1. Unzip the Pure Storage SRA package zip file.
  2. Follow the instructions in the VMware SRM 8.2 Quick Start Guide to load the Pure Storage SRA adapter tar file to the SRM appliance manager.

 

SRA 3.0.14 Release Notes

Release: July, 2018

New in this Release

Supports Pure Storage ActiveCluster synchronous replication
SRA 3.0 supports ActiveCluster synchronous replication (a.k.a stretched storage) when used in combination with SRM version 6.1 or later and Purity version 5.0 or later. Users can now create protection groups and recovery plans based on storage policies, and run the full failover/reprotect workflow as well as test failovers.

Known Issues and Best Practices

  1. When configuring your FlashArray Protection Groups to be used with SRM, please ensure that the Retention Policy is configured to retain at minimum 1 snapshot for 1 day.  This is important as the SRA will be leveraging the replication retention policy when taking test, failover and re-protect array based snapshots.
    For Example:
    # purepgroup list --retention
    Name                                         Array   All For  Per Day  Days
    sn1-405-c12-25:sn1-405-25-prod-pgroup-1      source  1d       4        7
                                                 target  2h       1        1
  2. Whenever an array's replication type is changed, or an array loses its connection to replicating arrays, volume group names are trimmed in the snapshot source (as displayed by the CLI purevol list --snap command, for example).
  3. If either FlashArray has been renamed after they have been connected, all test failovers, failovers and reprotects will not execute completely.  The 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.
  4. For volumes in vgroups, planned failover and disaster failover show the status partially recovered in the vSphere SRM GUI, with an error message. A test failover also displays warnings. This is only an issue for datastore volumes in volume groups; all other datastores are not affected. To successfully recover, remove any SRM-controlled volumes from volume groups.
  5. For SRM protection groups configured with FlashArray Volumes in Volume Groups the SRM protection group/recovery plan will no longer work if volumes have been moved out of a volume group, volume group names have changed or volumes were moved to a new volume group.
  6. Device Discovery, DR Failover and test failovers of volumes inside a Volume Group (VG) may fail if there is a replicated Protection Group with a host or host group as a member that is also connected to the volume in the VG. We expect a future release of Purity to fix this issue. Until then, the workaround is either to not use Volume Groups, or to ensure there are no replicated Protection Groups with hosts and host group members.
  7. When using ActiveCluster with SRM, ensure the personality for all Purity hosts connecting to ESXi servers is set to esxi.  Failure to do so may cause datastores backed by ActiveCluster stretched pods to become inaccessible after an interruption to the stretched storage connection.
  8. After upgrading to PureSRA 3.0, it is necessary to disable and re-enable the array manager used by PureSRA.  Because PureSRA 3.0 supports stretched storage, all existing array managers must be restarted to trigger a discover arrays operation.
  9. Test failovers of Volumes, Volume Group Volumes or Pod Volumes are expected to fail if the character length of the volume name exceeds 42 characters.  If the volume name exceeds 42 characters, then during the test failover when the volume is renamed with the "-puresra-testFailover" suffix, the volume name will exceed 63 characters and the test failover will fail.  At this time Pure's recommendations to avoid this from occurring, ensure that your Volume Names do not exceed 42 characters.
  10. If volumes are in the process of being deleted during a vSphere SRM device discovery operation, the discovery can fail. This is a known issue that we expect to resolve in a future release. If this occurs, re-run the operation within vSphere SRM so that the device discovery can be retried. This issue is most likely to occur in dynamic environments with VVols where VMs (and therefore also their virtual volumes) are often migrated across arrays.

    The following is an example error message:

    ERROR!
    649 com.vmware.vim.binding.dr.storage.fault.CommandFailed: SRA command 'discoverDevices' failed. Array operation failed: "PureRestException: HttpStatusCode = 'BadRequest', RestErrorCode = 'NotExist', Details = '["msg":"Volume does not exist.","ctx":"pod1::sync-vmfs"]', InnerException = 'System.Net.WebException: The remote server returned an error: (400) Bad Request.
  11. When using ActiveCluster with SRM, if the Stretched Pods are in a state of Resyncing, the device discovery will fail.  You will need to run the device discovery once all stretched pods are in sync. 
  12. When using ActiveCluster with SRM, when testing a Recovery Plan, the test can fail if the [pod_name::volume_name]-testFailoverStart exceeds 42 characters.  The failure will note that the volume was unable to be created.  

Compatibility

  • SRA 3.0 supports SRM 6.0, 6.1, 6.5, 8.1 and 8.2 on Windows® Servers. (note ActiveCluster is only supported with SRM 6.1 and later).
  • REST API version 1.3 or higher is required for asynchronous (snapshot) replication.  REST API version 1.13 (Purity 5.0) is required for ActiveCluster synchronous replication (stretched storage).
  • At this time Pure Storage will not support protecting 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 times 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.
  • With Purity Version 5.2.0 the feature to Async Replicate Volumes in a Stretched Pod was introduced.  With SRA 3.0.14, there is no support for using SRM with volumes in a stretched pod that have an array protection group associated with the pod using async replication to a 3rd site.  The Volumes in that Array Protection group will not show up in the devices discovery page.  Pure Storage is working to support this feature in a future SRA release.

SRA 2.0 Release Notes

Release: December, 2016

New in this Release

  • Support for IPv6
    Requires Purity 4.9.0 or higher and vSphere 6.0 or higher.
    When an IPv6 IP address is configured in the vROps Management Pack, the address must be entered enclosed in square brackets. For example: [2015:0db8:85a3:0042:1000:8a2e:0360:7334]
  • Ability to configure more than one array on the recovery side
    When configuring multiple arrays on the recovery site, one set of login credentials must be used on those arrays.

Known Issues and Best Practices

  1. When configuring your FlashArray Protection Groups to be used with SRM, please ensure that the Retention Policy is configured to retain at minimum 1 snapshot for 1 day.  This is important as the SRA will be leveraging the replication retention policy when taking test, failover and re-protect array based snapshots.
    For Example:
    # purepgroup list --retention
    Name                                         Array   All For  Per Day  Days
    sn1-405-c12-25:sn1-405-25-prod-pgroup-1      source  1d       4        7
                                                 target  2h       1        1

Compatibility

SRA 2.0 supports SRM 5.5, 5.8, 6.0, 6.1, and 6.5 on Windows® Servers.


SRA 1.5 Release Notes

Release: December, 2015

New in this Release

Compatibility

SRA 1.x supports SRM 5.5, 5.8, 6.0, and 6.1 on Windows® Servers.


SRA 1.0 Release Notes

Release: December, 2016

Compatibility

SRA 1.x supports SRM 5.5, 5.8, 6.0, and 6.1 on Windows® Servers.

General

TLS Support

Any client that communicates with the Purity REST API must support TLS 1.1 or 1.2. Ensure that HTTPS calls to the REST API have TLS 1.1 and 1.2 enabled. For information on how to update your code to work properly with TLS 1.1, see the Knowledge Base article Pure Storage REST API Best Practices.

Compatibility and Requirements

  • Supported versions of VMware SRM vary by Pure Storage SRA release:
    • SRA 2.0 supports SRM 5.5, 5.8, 6.0, 6.1, and 6.5 on Windows® Servers.
    • SRA 1.x supports SRM 5.5, 5.8, 6.0, and 6.1 on Windows® Servers.
  • This release supports Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016.
  • This release has not been tested or verified with Windows Server 2008. Currently the SRA is not officially supported on this server.
  • This release is compatible with FlashArrays with Purity Operating Environment that support REST API 1.2 or higher. We recommend Purity 4.0.14 or higher.
    Note: IPv6 support requires Purity 4.9.0 or higher.
  • Host side connectivity is supported with Fibre Channel and iSCSI.
  • At least two FA-4xx or //m FlashArrays are required.

Installation

  • To install the SRA adapter, extract and run PureSRAInstaller.exe on the Windows Server machines hosting the protected site and recovery site SRM servers.
  • Administrator privilege is required to install.
  • The Pure Storage FlashArray SRA requires .NET Framework 4.5 or later to be installed on the same machine where you run the installer.

Documentation

Please see the Pure Storage FlashArray Storage Replication Adapter Guide SRA Guide on Pure1 Knowledge under Solutions > Virtualization > VMware > Site Recovery Manager (SRM).

Known Issues and Best Practices

Important: Prior to installing and using the Pure Storage FlashArray SRA, read the user guide available in the Site Recovery Manager - SRM section.

  • The SRA uses -puresra-testFailover and -puresra-failover as suffixes for test-failed-over and failed-over volumes. The names of demoted volumes are appended with the suffix -puresrademoted.
  • When protection groups are configured to use hosts or host groups (instead of selected volumes), the SRA may create helper protection groups starting with puresra- during prepareFailover.
  • During SRM operations, do not create, rename, or destroy volumes with those suffixes, or create, rename, or delete protection groups with the puresra- prefix.
  • Do not rename an array, protection group, SRM protection group, host, host group, or volume that is involved in a Protection Plan while the plan is being executed.
  • Names of protection groups cannot exceed 62 characters in length. To allow for the puresra- prefix, do not use a protection group name longer than 54 characters.
  • For protection groups involved in SRM workflows, apply a reasonably short retention policy so that snapshots created during SRM operations are cleaned up in a timely manner.
  • The user should not have two volumes of the same name on the source and target (i.e. the source array has a volume named MyVol, and target array also has a volume named MyVol). Reprotect will not work (and fail with an error message about not being able to rename a volume).
  • If the installer fails to download and the install the required .NET Framework, manually download and install the framework from the Microsoft download site (for example, the .Net framework 4.5 installer download), then re-run the SRA installer.

Log Locations

SRA logs are located in %PROGRAMDATA%\VMware\VMware vCenter Site Recovery Manager\Logs\SRAs\purestorage. Each invocation of the SRA produces one log file. Sort by Date Modified to see the commands executed in chronological order.

SRM logs are located in %PROGRAMDATA%VMware\VMware vCenter Site Recovery Manager\Logs and named vmware-dr-##.log. The file with the largest ## number is the most recent. SRM logs are useful for diagnosing problems in the following cases:

  • The SRA responded correctly, but an SRM operation failed.
  • The SRA operation failed before creating an entry in the SRA logs.

The SRA attaches the REST call transcript at the end of each log file (e.g. testFailoverStart_2014-12-0410-24- 22-0829439-1511666224.log). Look for "Rest Library transcript" in the log file. The SRA logs only the request URL and the response code.

Copyrights and Licenses

© 2018 Pure Storage, Inc. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or stored in a database or retrieval system for any purpose without the express written permission of Pure Storage, Inc.

Pure Storage, Inc., reserves the right to make changes to this document at any time without notice and assumes no responsibility for its use. This document contains the most current information available at the time of publication. When new or revised information becomes available, this entire document will be updated and distributed to all registered users.
This product includes software developed by the JSON.NET Project (https://json.codeplex.com) for high performance JSON framework for .NET, which is distributed under MIT license (https://json.codeplex.com/license) as shown below in Open Source Licenses Section.

All other trademarks, service marks, and company names in this document or website are properties of their respective owners.