Well here we are together again, my fourth post in under a month. I’m way past my quota at this point and working on fumes! When the news is good, though, it must be spread… Today we have another great release, the EMC Storage Replication Adapter (SRA) for SRDF version 5.6 and the companion software Virtual Storage Integrator (VSI) SRA-Utilities 5.7. These two software releases are the first to support the VMAX3 platform in conjunction with VMware Site Recovery Manager (SRM). For those who may not know or need a refresher, the EMC SRDF Adapter is an SRA that enables VMware SRM to interact with an EMC Symmetrix storage environment. It allows SRM to automate storage-based disaster restart operations on Symmetrix arrays in a SRDF configuration. Last month we saw the release of the HYPERMAX OS 5977 release that supports SRDF (https://drewtonnesen.wordpress.com/2014/11/26/vmax3-q4-ga-rdfsnapvxxcopy/) so now with the SRA 5.6 release we are ready to implement SRM/SRDF VMAX3 environments or migrate existing VMAX2 environments to VMAX3.
Let’s briefly (warning I usually fail at that) go through the new features and support. Starting with the SRA for SRDF 5.6 here are the requirements:
- Site Recovery Manager 5.1, 5.5.x or 5.8
- Solutions Enabler (SE) 8.0.1 or later
If you used the SRA for SRDF in the past you know that it required 32-bit SE, not 64-bit. Starting with SE 8.x there is no 32-bit version of the software, everything is 64-bit so at least you can’t make a mistake ;-). As far as SRDF support, the SRA obviously must follow the VMAX3 support on that platform which mean SRDF/S, SRDF/A, and the only 3-site configuration supported is Concurrent SRDF. For the VMAX2 the support is the same as before.
Now for new/deprecated support/features. Note in particular here I am talking about VMAX3, VMAX2 support is the same as before:
- VMAX3 support
- Device pacing is deprecated
- TimeFinder pacing (R2 snap) is deprecated
- No DMX support
- VMAX2 to VMAX3 support including meta to non-meta
- TimeFinder SnapVX replaces Mirror/Clone/VP Snap/Snap on the VMAX3
- Emulations of former TF commands (e.g. Clone) are still supported but TF/Snap is deprecated on VMAX3
TimeFinder SnapVX is a real leap in the snap technology on the VMAX3. It creates snapshots by storing changed tracks (deltas) directly in the Storage Resource Pool (SRP) of the source device. With SnapVX, you do not need to specify a target device and source/target pairs when you create a snapshot. If there is ever a need for the application to use the point-in-time data, you can create links from the snapshot to one or more target devices. The SRA is able to use this new technology now, though of course in order to test we do need a target for the snapshot. Here is what the new XML stanza looks like for SnapVX:
I will also make a quick comment about VMAX2 to VMAX3 SRDF configurations. If you are going to setup SRDF between VMAX2 and VMAX3 just a word of warning that because of the architecture changes between VMAX2 and VMAX3, you can run into an issue where the two devices are not the same size, despite being created that way. For instance a 400 GB, 8-way meta on a VMAX2 is not the same size as a 400 GB device on VMAX3 (created with the same basic CLI command using 400 GB). It is not a huge difference but the device on VMAX3 is a little bit smaller and as such trying to setup a pair between them will fail. The way to avoid this problem is to use the cylinder size instead of the GB size when creating devices. Let’s assume you already have the 400 GB device on the VMAX2 which you want to pair with a device on the VMAX3. Through SYMCLI you can run a simple command to find out how many cylinders the device has:
For the 400 GB 8-way meta the cylinder size is 436912. Now since VMAX3 has a 128 KB track size which is double the 64 KB track size of the VMAX2, we need to 1/2 the cylinder size to get our VMAX3 device size, or 218456. Then you can run the SYMCLI command to create the device on the VMAX3:
symconfigure -sid 56 -cmd “create dev count=1,size=218456 cyl,emulation=fba,config=tdev;” commit -nop
Now your devices are the same size (look at MegaBytes):
Note that if your device on the VMAX2 has an odd cylinder size, the 1/2 rule doesn’t work all that well. Therefore HYPERMAX OS introduced a new device attribute, Geometry Compatible Mode (GCM). A device with GCM set is treated as half a cylinder (960K) smaller than its true configured size, thereby making the devices the same.
Now a further word on migrations. In the VMware world we always have the option of using Storage vMotion to do migrations but sometimes due to the size of the environment, SRDF with SRM makes much more sense for a migration. One suggestion I have is that if you anticipate the data on the device that you are replicating to grow beyond the current device size, SRDF supports smaller to larger device replication. I advise taking advantage of that if your data will expand, particularly as we do not yet support device expansion on the VMAX3. If you are not migrating (i.e. failover after completion of sync), then you’ll want the devices on the VMAX3 to be the same as the VMAX2 to support things like swap and restore, so follow the previous directions on cylinder size.
OK with that out of the way, moving on to the VSI SRA-Utilities 5.7 (yes, one day the versions of this and the SRA will match 🙂 ), let’s again start with requirements:
- vSphere Client (thick client required as SRA-U does not support vSphere Web Client)
- SRA 5.6 – note the SRA-U 5.7 only supports the SRA 5.6 and vice-versa
- No DMX support
- Cannot run multiple SRA-U versions on the same host (modify same files very messy and not supported)
And new features (mirrors SRA 5.6):
- SnapVX support for VMAX3 along with the emulation support for TF/Clone/Mirror/VP Snap
- SMI-S Provider 8.0.1, no dependency on local SE
- Device ID updated from a size of 4 to 5 e.g. 061B to 0061B – in support of more front-end devices (future)
- Better user experience, better performance
The big change in architecture is really that the SRA-U uses the SMI-S Provider to run all its commands rather than SE commands. When you install the SRA-U there is a new icon name in the Home screen.
And here are the new screens once in the plug-in, starting with the SMI-S Provider configuration, then the Symmetrix arrays screen (VSI Storage Viewer anyone?), and Global Options:
Lastly, here is the failover test screen which should be familiar, save the new drop-down option of SnapVX:
A few final thoughts to close this out. First, remember the SRA-U is not a required software. If you prefer to manually edit the XML files of the SRA for SRDF you may feel free to do so. The SRA-U, though, takes the guesswork out of pairing and alleviates formatting errors. Second, SRA-U is still a thick-based plug-in. If you are using SRM 5.8 you know that is only web-based. This is not a problem, however. You install the SRA-U on the SRM/SRA host and then run it in the thick client to the Recovery vCenter, modify the XML files, save them, and then run SRM 5.8 in the browser and it will use those XML files. I know it is not ideal but the VSI SRA-U web-based plug-in is coming.
Documentation links below (the SRA/SRM TechBook has not been updated but is forthcoming in January):
SRA for SRDF docs:
* Note that SRM 5.8 is not listed in the RN but it is listed on VMware Compatibility Matrices (https://www.vmware.com/support/srm/srm-compat-matrix-5-8.html). I’ll try to get our RN updated soon as well as the software link which implies it is not supported.
VSI SRA-U docs: