The Q4 release of VMAX3/HYPERMAX OS is here. As Less Grossman would say “Welcome to the goody room!” This release has the features we have been waiting for since the VMAX3 went GA (yes I know barely 2 months ago) – Local/Remote replication and the return of the VAAI primitive Full Copy (or XCOPY) among many others. Starting with local replication, TimeFinder has been completely re-architected into a new technology called SnapVX. This single command is all you need to make local replicas of your devices; fear not though as TimeFinder will support the legacy commands of TF/Clone, TF/Mirror and TF/VP Snap (no TF/Snap- believe me you don’t need it). SnapVX 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. This is obviously huge – and awesome. I can take multiple snaps (symsnapvx) without ever having to create another device. I did a quick video of this in Unisphere to demonstrate the simplicity. Note my Home screen with multiple arrays demonstrating that Unisphere now supports older Symmetrix arrays:
BTW that was real-time – no fancy editing on the video. It’s just fast, really fast. I even applied a life to the snapshot to be sure it is removed since I’m bound to forget about it in my development environment. SnapVX will support 256 copies per source with 1024 linked targets. I borrowed this slide from a colleague to show how you might setup a relationship with a snapshot:
This is great for us VMware people because we still have the dreaded 256 device limit on ESXi hosts and the less devices we can use the better. With SnapVX I can take multiple copies throughout the day of various storage groups/devices and use them with a single set of devices I have presented to my VMware environment by simply linking, unlinking, and/or relinking them from the various snapshots. I’ll leave it at that and direct you to this paper (http://www.emc.com/collateral/technical-documentation/h13697-emc-vmax3-local-replication.pdf) which has all the detail before I re-write it here. Note that the presentation to VMware of a copy made by SnapVX is no different than the legacy commands like TF/Clone therefore the TechBook does not go into detail about using the symsnapvx command.
Closely related to our local replication product is the VAAI primitive Full Copy or XCOPY. This is because Full Copy utilizes the TF architecture to replicate the data VMware passes off to us when the primitive is in use. And that is why Full Copy was not available at GA because TF/SnapVX was not ready. But it is here now, and frankly better than ever. There is nothing new you need to know to use it – on by default, switches to software copy when it can’t use Full Copy, etc. We still recommend changing the transfer size from 4 MB to 16 MB for all-Symmetrix environments (or with VNX). Details are in the WP included below. Why is it better though? Well it is faster. In fact, the default of 4 MB transfer size is about the same as 16 MB on the VMAX. The faster Full Copy works, the faster those clones/SvMotions get done and the more of them you can do.
Finally we’ll round things out with remote replication – SRDF. RDF is available for replication between VMAX3 arrays or VMAX2 and VMAX3 arrays. 3-site replication is currently limited to Concurrent RDF – so no Star yet. You can have 250 RDF groups per port, 250 groups per system, 32 ports per engine. Expect all the numbers for TF/SnapVX and RDF to increase in upcoming releases – think vVol numbers. When we think SRDF in the VMware world we think SRM so what about the SRA you ask? Well the SRA and VSI SRA-U that support VMAX3 should arrive shortly. It will support TF/SnapVX and VMAX to VMAX3 replication so if you are looking to move to the VMAX3 you can use SRM and SRDF to do it.
I thought I’d also make a small mention here about the VASA Provider for those who currently use it with VMAX. The VASA Provider does NOT support the VMAX3. To be honest it wouldn’t be of much use because of the SLO paradigm in VMAX3. What I mean by that is that all datastores would be classified as auto-tier so distinguishing between different SLOs like Silver and Bronze would not be possible without custom storage capabilities which you can do without VASA. I mention all this because even though it is not supported, if you try to register the Provider with Solutions Enabler 8.0.1 you will get regular errors, nothing telling you it is not supported (as of course VMware drives those error messages). So before you open SRs and drive yourself crazy, don’t try this at home.
Updated collateral – TechBook (Version 10.1) and whitepaper (November 2014) – make sure the version or date matches the ones on the left as the links may not update at the same time.
Using EMC Symmetrix Storage in VMware vSphere Environments
Using VMware vStorage APIs for Array Integration with EMC Symmetrix VMAX
A Happy Thanksgiving to all who celebrate.