Today EMC posted the updated SRDF Storage Replication Adapter (SRA) 5.5 for Symmetrix VMAX arrays to their website:
https://download.emc.com/downloads/DL49914_EMCSRDFSRA_5.5.0.0.exe.exe
It will be on VMware’s site shortly:
https://my.vmware.com/web/vmware/details?downloadGroup=SRM_SRA&productId=357&rPId=4220
This adapter includes support for VMware vCenter Site Recovery Manager 5.5 (as well as “legacy” support for SRM 5.1).
In order to use this SRA you will need Solutions Enabler 7.6.1 which came out in early September. Get it here:
https://support.emc.com/downloads/2071_Solutions-Enabler
This release was a little bit late to the game since SRM 5.5 came out a few weeks ago, but we had so much we wanted to include in this release we had to delay a bit to make sure we got everything right. So what’s new? Here is a quick list of the main enhancements:
- Support for SRM 5.5
- Ability to automatically mask and unmask RDF and/or TimeFinder devices during test recovery or recovery operations. This is something a lot of customers have asked for and we made a it a priority for this release.
- Widened support for Concurrent/Cascaded RDF. Previously we had a very limited scope in our support for Concurrent/Cascaded SRDF (non-Star), we now support almost every conceivable configuration.
- Reprotect/Failback is now supported with non-Star Concurrent or Cascaded SRDF. Previously it was only supported with two-site SRDF and SRDF/Star.
- Recovery configured for any site of non-Star three-site SRDF. Previous versions only allowed recovery to the asynchronous site of these configurations (Star allowed any site though). As long as the site is not replicated to via Adaptive Copy we can recover to it.
- Ability to reverse replication during the SRM recovery operation.
So a little more detail on these. I plan a series of posts to go into all of this in even more detail, so stay tuned for those.
Support for SRM 5.5
Not much to say here, other than the SRA is qualified for SRM 5.5 and SRM 5.1. We did enhance some logging mechanisms that is somewhat under this umbrella but other than that just official support.
Automated Masking Control
This is one of the biggest features of this release in terms of what customers have asked for. As many of you are aware, ESX has certain SCSI limits that can be somewhat limiting when environments start to get rather large. 256 devices or 1,024 logical paths. In SRM environments, that many of which have active-active datacenters instead of an active-passive protected site/recovery site these limits were often reached due to SRA requirements. In their “recovery” site they would have production volumes being used as well as the RDF2 devices and any TimeFinder devices they needed to use for test recovery operations. Having all of these devices types presented at once hit those limits quickly. Since the SRDF SRA required these devices already be presented prior to recovery or test recovery customers had to create custom scripts to mask/unmask these devices at the appropriate times.
The SRDF SRA 5.5 now has the ability to present or unpresent devices during these SRM operations, so the VMware or storage admin does not have to manage this themselves. For instance, during a test recovery, the SRA will automatically add the given set of devices to a masking view and then remove them during the cleanup operation. During a recovery the SRA will remove the R1 devices from the protected site and also add the R2 to the recovery site.
All the SRM admin needs to do is configure storage group/device pairings once and the SRA will reference that pairings to add the devices (or remove them) from the proper storage group. These pairings are stored in a new XML file called EmcSrdfSraDeviceMaskingControl.xml, which can of course be configured manually, but the VSI Symmetrix SRA Utilities has been updated in version 5.6 to help do this in a very easy manner. Definitely will have a in-depth post on this later.
Enhanced Support for non-Star Three-Site SRDF configurations
The last version of the SRDF SRA introduced support (while somewhat limited) for Concurrent and Cascaded SRDF. The 5.0 release introduced support for Concurrent and Cascaded Star only and was full realized in the 5.1 release. So in the 5.5 release we fully realized support for non-Star three site scenarios.
While Symmetrix Enginuity supports a wide variety of configurations the SRA did not at first. The SRA only supported the following two configurations for non-Star Concurrent or Cascaded:
So as the pictures note, we only supported Concurrent or Cascaded when one leg/hop was Synchronous and the other was Asynchronous. Enginuity supports, especially for Concurrent a wide mixture of Synchronous, Asynchronous and Adaptive Copy replications modes.
For Concurrent we now support all of them with SRM:
- Asynchronous/Asynchronous
- Synchronous/Synchronous
- Synchronous/Asynchronous
- Adaptive Copy Disk Mode/ Synchronous
- Adaptive Copy Write Pending Mode/ Synchronous
- Adaptive Copy Disk Mode/ Asynchronous
- Adaptive Copy Write Pending Mode/ Asynchronous
Plus we can now reprotect and failback ALL of these configurations. Note though that after reprotect they will all be converted into Cascaded RDF.
Cascaded RDF is inherently more restrictive but we have enhanced the SRA to support the following:
- 1st Hop Synchronous 2nd Hop Asynchronous
- 1st Hop Asynchronous 2nd Hop Adaptive Copy Disk Mode
- 1st Hop Synchronous 2nd Hop Adaptive Copy Disk Mode
Note that adaptive copy write pending mode is not supported for Cascaded SRDF.
Furthermore, we now support recovering to any site of these three site configurations as long as that target site is not replicated to via adaptive copy. Previously only the asynchronous site was supported for recovery.
Reverse Replication During Recovery
Prior to SRM 5.x our SRA would automatically swap RDF personalities and re-establish replication in the reverse direction. This behavior helped with failback and also reduce the gap in which the data ran in production without protection. In SRM 5.x failover and reprotection were separated into two discrete operations in SRM (recovery and reprotect) so RDF personality swaps and replication was not reversed until the admin ran a reprotect operation. For a few customers this was not ideal as they wanted to have their environments’ data protected by SRDF as soon as possible after recovery and didn’t want to expose themselves to the risk of having to wait for such until a reprotect could be run. We introduced a new non-default behavior that will run the SRDF reprotection operations at the end of the recovery operation instead of during the actual reprotect operation. If that is enabled, the SRA will still ensure SRDF is reprotected during the reprotect operation (whenever it is eventually run) but if it is it will be tolerated and the steps skipped.
Lastly, the Virtual Storage Integrator Symmetrix SRA Utilities have been enhanced in version 5.6 to support all of this. Look for a more in-depth update to come. As always VSI can be downloaded from support.emc.com here:
https://download.emc.com/downloads/DL50054_VSI-SRA-Utilities-5.6.zip
Hi Cody
Excellent article.
Assuming I have the necessary EMC RPQ for support, would you expect the new VMware SRA to work against a DMX4 array? I have SRM 5.1 working with Solutions enabler 7.6 Appliance, 7.6 Sol enabler for windows, and looking ahead to the future.
Noting I am not taking this as an official answer in any way.
Thanks
David
Thanks!! I doubt we will officially support DMX anymore with a SRA. It was decided that the 5.0.1 release would be the last one for DMX. That being said you can put in a RFQ (request for qualification) to get specific best-effort support for DMX and newer SRAs. I don’t know the exact circumstances but others have gotten RFQ approval for DMX.
Hi Cody
Yes I have the RPQ already for SRM 5.1 for best effort support. So far all ok :). I will log another query.
Thanks
David
Hi Cody. When I read that the SRA5.5 supports automated masking control, I jumped for joy. However, after upgrading to it, I found that the symmetrix utilites used to configure the mappings will wipe out previous edits to the masking control xml file and it also does not read in current mappings from the file. I opened a support case and they told me this is by design. Is this true? I have over 250 replicated devices with more to be added.
Hmm if support said that is how it works it must be. But I doubt it was meant to be that way, probably just didn’t have time to code the behavior or something. I’d ask you SR owner to open an enhancement request/bug ticket to see if this can be changed in the future. The rest of the VSI SRA Util functions read the current file, so it would make sense that this does too. In the meantime, you might just want to edit the XML file manually. Sorry I dont have a better answer for you.
No problem. Wanted to hear what you had to say on the matter. I have already requested an enhancement request to be opened. I noticed on your blog that a service release for SRA5.5 is upcoming. Perhaps it will be fixed in that. I also have a case opened in that when I try to edit the masking file, the SRA utilities is not returning all of my R2 devices. It is only returning devices that are datastores, not RDMs. Engineering has duplicated the issue and I am waiting for a fix on that one.
Cool. Unfortunately the SRA 5.5 SR is only for the SRA, as far as I am aware there is no associated SR for VSI to come out at that time, but I would presume one would be forthcoming at some point in the near future. If you want to give me your SR number(s) and any bug number I can track this internally myself too.
Sure, SR # is SR – 59829384. I don’t have a number for the enhancement request