Site Recovery Manager & NetApp Site Recovery Adapter

As most of you are already aware VMware's Site Recovery Manager v1.0 (SRM) went GA last week. An 60 day trial can be downloaded from here as well as the appropriate Storage Recover Adapter (SRA) for your array vendor. As always, check VMware's SRM compatibility matrix before you proceed because the supported storage vendor list can fit in the back of your business card right now, although that will change.

SRM, to date, represents the most elegant DR/BC solution that tackles a very difficult and costly problem, Disaster Recovery. Doing Physical DR does not only require identical HW at both sites but it's also a process that's prone to errors and with very little automation. Furthermore, DR Testing in these type of situations takes a significant amount of time and so it typically occurs infrequently. The worst thing about infrequent testing is that you have no idea how/if even the smallest change in your production will affect your DR processes.

Leveraging Virtual Machine portability, and Hardware independence, SRM automates the DR workflow process by allowing Administrators to quickly and efficiently Implement and easily Test, Disaster Recovery plans quickly and efficiently with no service disruption to the production site. Furthermore,it reduces the need for idle Hardware at the Recovery site (you could run Production VMs there as well) thereby lowering costs while raising the quality of service.

Storage Array Integration with SRM

While, conceptually, SRM provides the same capabilities regardless of the Storage Array, the manner within which these capabilities are implemented vary depending upon the storage vendor, storage vendor platform and replication SW used.

The SRM requirements presented by VMware to their Storage vendor partners for integrating with SRM  were that, Storage Vendors had to develop a Site Recovery Adapter(s) (SRA) capable of:

1. Discovering storage vendor arrays
2. Discovering replicated LUN(s)
3. Initiating an SRM simulated failover
4. Initiating an actual SRM failover

Flexibility, Simplicity & Efficiency

Continuing our theme of Flexibility and SW commonality, we've provide:

• A single SRA adapter for all of our VMware supported HW platforms using our native Array Replication (i.e SnapMirror).
• Support for Sync, Async and Semi Sync SnapMirror
• An SRA that does not require like-to-like configurations (i.e like-to-like NetApp disk arrays, disk types, or disk capacities).
• Multi-protocol support...You can leverage Fibre Channel at the Production site, and iSCSI at the Recovery Site or vice versa.
• Integration with our space efficient FlexCloning capability for DR Testing, thereby reducing the cost of storage at the DR site. This is significant, in that you don't need to split any full blown clones off the destination replica, which  can take time, require space and add costs. That means you can test your Recovery Plan(s) all day long, if you want, while keeping the replication intact
• Integration with the upcoming SnapManager for VI Release. The NetApp SRA will leverage SMVI induced replicated Snapshots and will create FlexClones based on these.

Update: Integration with SMVI did not make it in with the current SMVI/SRA releases.

Frankly, whether you're dealing with Replication technologies and SRAs or juggling balls in a circus...fewer is always easier, so we only have one SRA that works with every platform.

Now, take the above, plus get a Free Deduplication license from Netapp and get an even bigger bang for your buck...You see, Dedup for us is a feature that's part of the array, not an added cost...

Future capability

As it stands right now, SRM provides support for 1:1 Replication-Test-Failover scenarios. Failback is not automated in the SRM v1.0 release although it's very simple. You basically do everything in reverse.

Having said that, wouldn't it be great if VMware were to provide multi-to-one site failover and testing capability? Being able to replicate multiple sites to a single one, would be an absolute killer approach for VMware and would help them to distance themselves even further.

Secondly, in the near term, I'd like to see NFS support as we have a ton of customers running on NFS who love the protocol's flexibility and operational efficiencies and would like to take advantage of SRM's elegant approach to DR/BC.

Comments

[Das]

Hi Nick, Good to see your post - where can I download the SRA from? Many thanks,

Das

[Nick Tiantos]

Hi Das,

The SRA needs to be downloaded from VMware...http://www.vmware.com/download/srm/

You can sign up for an evaluation of SRM and you'll also have access to the SRA.

Cheers

[yfeefy]

Yeesh! Now how will we know when we are talking about site recovery manager or the alphaserver console firmware, thanks a lot vmware! :-)

[Joe Kelly]

We're thinking about synchronous replication but worried about the WAN link. Can I use a WAN optimization device from Cisco with synchronous replication? I heard from a colleague that WAN optimization doesn't work with synchronous replication because it adds too much latency. Thanks...

[Das]

Hey Nick,

Thanks for the update - we did get the stuff. Incidentally, does the SRA support FC yet? We were setting up SRM up in out lab, and the demos out there are all iSCSI. We have FC, and we noticed something in the readme that says that FC wasn't supported in the BETa version... Is that still true?

Also, any roadmap updates yet on NFS support for SRM? Gracias!

Thanks for any assistance you can provide,
Das

[Das]

Hey Nick,

Thanks for the update - we did get the stuff. Incidentally, does the SRA support FC yet? We were setting up SRM up in out lab, and the demos out there are all iSCSI. We have FC, and we noticed something in the readme that says that FC wasn't supported in the BETa version... Is that still true?

Also, any roadmap updates yet on NFS support for SRM? Gracias!

Thanks for any assistance you can provide,
Das

[Nick Triantos]

Hi Das,

It supports FC. The Beta supported FC too although a beta doc stated otherwise.
SRM support for NFS is VMware roadmap discussion and not appropriate for a blog discussion.

Even if we could supply an SRA for NFS today without VMware's support it would be a moot point.

[S]

Hi Nick,
I hope it's not too late to ask this:
If using snapmirror for replication we'll be using "snapshots" right?
It was my understanding that snapshots, if the VM was not quiesced, were NOT consistent...
So the question is, how can we be sure that the replicated VM will be consistent on the DR site? Who assures the consistency?
If it is indeed consistent, then why we quiesce the VM before taking snapshots? (SMVI/tr3428).
If it is not, aren't we supposed to take a consistent snapshot, beside the one that snapmirror does?
Thanks!

[Nick Triantos]

Hi S,

Correct, *any* HW based snapshots that have been taken without any quescing are not consistent. These are referred to as crash consistent snapshots.

if you want the replicated image to be in a consistent state not only from an OS standpoint but also from an application perspective steps must be taken to ensure that *both* are quiesced prior to obtaining a HW snapshot.