SnapMirror with VMware for Disaster Recovery

Dear All,

I would like to use SnapMirror for DRC Solution. Here is the scenario:

Production site:

Using 3 Blade server BL460c with 2 socket processor, 48 Gb of RAM and 8 port of network (Management 2x, Vmotion 2x, VMnetwork 2x and iSCSI 2x).

Storage=FAS2040. VMware license will used is Enterprise one + VCenter standard

For the recovery site:

Using 3 DL Server, 2 socket processor, 48 GB of RAM and 6 port of network (Management 2x, VMnetwork 2x and iSCSI 2x).

Storage=FAS2040. VMware License will used is Essential  (3 host + VCenter, the cheapest VMware license ). Replication will occur every 15 minutes.

In the production site: Storage needed at 4.2 TB and per day growth is 1.6 GB. (with total 24 server). We are planning to replicate all VM (4.2 TB LUn with 1.6 GB growth / day)

My question is : Can snapmirror protect the VM in the Production site? We intend not to use VMware SRM. So, just relying on NetApp replication.

Then when disaster came, I just power on all the VM on the DRC site..

I had a doubt about the replication, what happen if the replication failed in the middle of replication process..Can this failed replication, affect the targeted LUN at the DRC site (I don't know, maybe failed LUN, bad block or data corrupt)


Re: SnapMirror with VMware for Disaster Recovery

Hi Garibaldi,

To answer you question, Yes, snapmirror will protected the VM data that is stored on the volume.

We use a similar setup for some of our more critical VMs, the only difference is that we use the MultiStore DR feature to manage the replication and failover. It works great and we've never really had any problems during our tests. I would actually suggest using the MultiStore DR feature if you have the MultiStore license. It keeps configurations simple and migrates a lot more than just the volumes. MultiStore DR actually uses snapmirror to mirror the volumes, but it mirrors the vfiler's /etc volume in addition to all the data volumes. This way it mirrors the configurations(Networking, security, CIFS domain, NFS exports, iSCSI LUN settings,etc etc) for the vfiler along with all the data. Once they're synced we can bring up the vfiler with a single command and don't have to worry about readding all the iSCSI/NFS/CIFS settings back in. Using just snapmirror works, but then you may have worry about all the configurations being correct or having to correct them once you failover.

For your second question regarding data security. In most cases, you have nothing to worry about (This is not a warranty ). ASync Snapmirror works by taking a snapshot at the source and then syncing the source snapshot to the destination filer, based on a schedule you specify in /etc/snapmirror.conf. Once the Destination filer has the full snapshot it applies it to the volume. Should a transfer be interrupted midstream the filer will store the partial snapshot and try to resume, if it cannot then ultimately the snapshot will never be applied and will be discarded. This feature protects against interrupted data transfer.  Also keep in mind that async snapmirror only syncs every X minutes based on your configuration, so if your Production site dies your DR site will have data that is *at most* X minutes old (small pittance if a plane crashes into your DC, or its gone dark due to a semi backing into a transformer). However, having said that... there is always the slight possibility of minor VM filesystem problems (not necessarily corruption) due to the fact that a VM may not fully write to disk and only write a partial update of some part of data, but with most modern filesystems this isn't a problem thanks to journalling and commit logs. As the saying goes: "Nothing's perfect".

Does this answer your questions?

Best Regards,

Adam S.

Re: SnapMirror with VMware for Disaster Recovery

Hello Adam,

Thanks .

So, for failback, is as easy as reversing the replication proses (from DR site to production site) ?

Re: SnapMirror with VMware for Disaster Recovery

Hi Garibaldi,

Essentially yes, but what you should do first is to not allow the Primary site filer to boot, instead use the special boot menu to boot without /etc/rc (without networking). You'll then need to turn off external filer access (iscsi/CIFS/NFS) and then do a snapmirror failback before turning down the DR site and back on the Prod site.

I think this guide will answer alot of your questions:

Let me know if you have any more questions.

Best Regards,

Adam S.