As I wrote about in a recent post the 5.1 version of the SRDF Storage Replication Adapter was updated in a service release. Similar fixes and a few other changes have been also added to the SRDF SRA version 5.5. If you are running VMware Site Recovery Manager version 5.1 or 5.5 this is the SRA you should be using. SRM 5.0 users can only use the 5.1 SRA (while the 5.1 SRA supports SRM 5.0 and 5.1 I recommend SRM 5.1 users use the 5.5 SRA).
So what’s new in the latest SR for SRDF SRA (18.104.22.168)?
***UPDATE: The SRDF/SRM techbook has been updated to include these changes/enhancements http://www.emc.com/collateral/software/technical-documentation/h10553-sra-vmware-5-0-tb.pdf ***
A bunch of fixes:
- Two-site and three-site SRDF mixtures: When global option FilterNonVMwareDevices is set to No, Discover devices operation may fail in SRM environment protecting two site SRDF configurations. This can happen only when there are three site Cascaded SRDF(not visible to ESX environment) and two site SRDF configurations on the same Symmetrix array.
- SRDF/Star manipulation during discovery: See below for more info.
- Failover to Cascaded Non-Star Async site: In the 5.5 first release there was some issues with failing over to and discovering the third site (async) of a non-Star Cascaded SRDF configuration. This has been fixed. Customers that want to do this MUST upgrade to this version.
- Non-default directory installation of SRM: If you installed SRM in a non-default directory (c:) the SRA won’t work by default. This was supposedly fixed in the initial 5.5 release but there were still some problems. It is completely fixed now.
There are two new features in this SR, the second I see really more of as a fix:
- Automatic device/composite group creation by the SRA has a new, more granular, naming convention
- A new advanced option for SRDF/Star environments called IgnoreDisconnectedStar
Group Naming Convention Change
When an administrator has not pre-created their consistency groups on the protected and recovery site Solutions Enabler servers and then initiates a failover or a test failover the SRA will notice their absence and create them itself. It used to use a naming convention with the time and date preceded by dg_. This release adds more details to the naming convention to include milliseconds and the process ID of the SRA that created it. This will be able to tell you what and exactly when the group was created.
That being said, I always insist that customers ALWAYS pre-create their consistency groups. There are a variety of reasons for this and mainly doing so helps make sure you have created the protection groups correctly. Without the consistency groups it can be harder to tell you did it right and you may not find out until a test of recovery.
The new advanced option IgnoreDisconnectedStar has been introduced in these releases. For environments that don’t use SRDF/Star this will not affect them in any way. But for those that do–listen up!
Prior to this release during a discovery operation, if a Star configuration was found that had at least one leg in the disconnected state, the SRA would automatically connect, protect and enable that entire Star configuration–whether it was intended for SRM protection or not. Any other configuration that didn’t have a leg in the disconnected state though would be skipped (protected, enabled, isolated, tripped etc.). This new option (disabled by default) will prevent this behavior when enabled. If you enable IgnoreDisconnectedStar (do it on both SRAs) it will no longer attempt these operations during discovery.
This is important as many times there is a good reason that Star is disconnected and administrators may not want it reconnected by the SRA prematurely. So I HIGHLY recommend anyone with Star environments that use SRM to upgrade to this build and enable this new option.
Note that VSI has not been simultaneously updated for this release so this new option will not appear in the Global Options Editor in the VSI Symmetrix SRA Utilities. I presume this will be added in a later release. So in the meantime edit the SRA XML file manually. The file is here:
You can find the download and release notes on support.emc.com or zipped together to download on VMware’s SRM download page.
Release notes here: