A few DR questions - SnapMirror, SnapVault, SMVI & SnapManagers

[davidrnexon]

Hey,

I've just got a few questions in regards to the technologies and setup above, just so I assure myself i've got it right

In a scenario where the company has the following:

Primary Site:

Netapp 2040

5 esxi servers all booting from local disks of physical blade servers

Windows AD VM - Located in an NFS Qtree named \vol\servers_nfs\qtree_servers_nfs

Windows Exchange - System disk in NFS Qtree named \vol\servers_nfs\qtree_servers_nfs. SnapDrive installed, with individual iscsi luns (using Microsoft Initiator) for each mailbox database as follows - \vol\exchange_db\qtree_accounts_db, \vol\exchange_db\qtree_management_db, etc and one lun/qtree for logs \vol\exchange_logs\qtree_logs

Disaster Recovery Site:

Netapp 2040

5 esxi servers all booting from local disks of physical blade servers

I'd like to cover off separate areas.

1. Virtual Machine Backups

     - Using SMVI within vcenter

     - SnapVault Primary to SnapVault Secondary (which is on \vol\sv_sec\qtree_sv_sec on the primary site filer) - for archiving 6 monthly backups

     - qtree snapmirror to destination (Disaster Recovery Site filer)

2. Exchange Backups

     - Using SnapManager for Exchange and SnapDrive

     - SnapVault Primary to SnapVault Secondary (which is on \vol\sv_sec\qtree_sv_sec on the primary site filer) - For archiving 1 year of backups in weekly intervals

     - qtree snapmirror to destination (Disaster Recovery Site filer)

3. Vmware Site Recovery Manager

     - Between Primary Site and Disaster Recovery Site.

My questions are. Is 1 and 2 correct or are there better ways ? I have most of this setup in the lab so it's a good time to break things I also read in the documentation that SnapDrive does not support qtree SnapMirror Replication, but the only way to use SnapVault it with qtree's ?

With Site Recovery Manager - if we simulate a failover to an isolated environment how will exchange repoint the iscsi target to the dr filer ?

[larryet]

I suggest you give TR-3822 a read, it describes recovery of SME and SMSQL VMs using SRM.  It describes an environment similar to what you want but does not include snapvault, there are also a couple new things we can do that are not in that TR yet.  TR-3785 is a good read as well, as the environmen used in TR-3822 was the one built for TR-3785.

A couple comments:

I would steer you away from putting your data into qtrees.  You can perform vaulting without using qtrees.  If you configure the source of the vaulting relationship with a /- following the volume name then this directs snapvault to place all NON-qtree data in the source volume into a qtree on the destination.  Example:  source_filer:/vol/volume/-  dest_filer:/vol/volume/qtree

One effect of doing this is that the directory structure which currenly  exists in the root of the volume on the vault source will be recreated  in the root of a qtree at the destination.  However this is of little  consiquence, as restores from the vault are unlikely, and even when they  are performed the will generally be full copy back restores anyway,  which does not require a copy back into a qtree at the destination.

Doing this would require that you not keep any data in qtrees in the source.  This would allow you to do volume level snapmirror for your SRM replication, which enables storage efficient replication on the wire (i.e. if you dedupe the source volume snapmirror does not inflate the data on the wire or the destination.  And you can still do vaulting to another local location from that source using the method mentioned above or vaulting from the volume snapmirror destination to a remote snapvault source (but restores from a remote vault would come back over the WAN).  Volume level snapmirror updates can be triggered by the snapmanager products running inside the guests.

While using the MS iSCSI initiator in the quest may provide a little more simplicity in vmware side management (basically because LUN management of such LUNs cannot be done from VMware you are basically moving these administation tasks to some other interface) these cannot be automatically recovered by SRM as the VC environment has no awareness of guest connected storage.

Software iSCSI RDMs have a little more administratrive requirements (this is a matter of opinion, more management or management moved into vcenter?  if the storage admin and vmware admin are the same person then the managent is moved not eliminated) but these will be automatically discovered and recovered by SRM (this is what TR-3822 describes).

SnapDrive 6.3 allows the use of VMDK's for SQL data with SnapManager for SQL.  So you could eliminate the need for iscsi RDM's or iscsi guest connected storage altogether for your SQL VMs.

SnapManager for Exchange cannot use VMDK yet, but most environments typically have fewer exchange servers than SQL servers, making the deployment of iSCSI RDMs for only the exchange VMs a much more managable number.

Hope this helps, Larry.