Skip to main content
Pure1 Support Portal

Release Notes: Storage Replication Adapter for Site Recovery Manager

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)

Upgrading SRA

For information on upgrading existing SRA version, refer to the Upgrading SRA KB.


SRA Release Timeline

Release Release Date
3.0.154 May, 2019
3.0.14 July, 2018
2.0 December, 2016
1.5 December, 2015
1.0 December, 2014

SRA 3.0.154 Release Notes

Release: May, 2019

New In This Release

Support for 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

Support for 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.