Exchange 2010, VMDKs on NFS, Snapmanager for Exchange support?

[HendersonD]

Our SQL 2008 R2 server runs under VMWare with VMDKs residing on an NFS datastore for the SQL database and log files. We use Snapmanager for SQL 5.1 in conjunction with Snapdrive 6.3 and VSC 2.0.1 to backup the SQL databases.

I am running Exchange 2007 under VMWare and have two luns presented to Exchange using the Microsoft's iSCSI initiator. These luns are used for the Exchange database and Exchange log files. We use Snapmanger for Exchange to backup the Exchange database.

We want to make the jump to Exchange 2010 and desire a similar setup to SQL. I want to have VMDKs residing on an NFS datastore for the Exchange database and log files. This setup will run Exchange 2010 just fine. The question is when will Netapp support Snapmanager for Exchange in this setup?

[vmsjaak13]

All SMEX versions require your exchange stores to be on a LUN.

Regards,

Niek

[HendersonD]

I realize that now all versions require luns. When Snapdrive 6.3 and VSC 2.0.1 were released they provided for snapshots of VMDKs on NFS datastores using SMSQL. At that time, Netapp said that at some point in the future this same functionality will come to SMEX. I am wondering if a timeframe when this will be supported has been established.

[MarcTeiwes]

Hey,

Might there be any news about this Topic? Is there anything about this on the Roadmap?

Regards,

Marc

[simmuteit]

it's a pity. i hope i will be possible soon.

[whamilton]

I am planning for the implementation of VSC 2.0.1 and happened upon this post. I am pretty sure NetApp supports Exchange running in NFS data stores using SnapDrive created LUNs with Snap Manager for Exchange and SQL. I have never had any problems when calling support about a rare SME issue. We run Exchange and SQL in VMware using NFS mounted data stores. The LUNs are created through Snap Drive (v. 6.3) and reside inside the NFS data store and SME or SMSQL back the various databases up. The install/setup/admin guides and best practice guides walk through this configuration pretty well. One thing they suggest in SQL anyways is to use a separate flexvol for each instance or database. Of course there are limitations in VMware as to the number of NFS data stores (8) that can be used by a single host. I stray from this best practice in SQL since we have 8 NFS datastores on each of our VM clusters so SQL only gets one NFS volume with multiple LUNS inside that volume for each instance/database. The system databases reside in their own LUN as do the transaction logs.

We are using VMware ESX 3.5

Exchange 2003 with SDW 6.3.0.4601 and SME 6.0.0.706 in one NFS datastore with 4 LUNs.

SQL 2008 Standard on Windows 2008R2 with SDW 6.3.0.4601 and SMSQL 5.0R1 in one NFS datastore with 6 LUNs.

We also use SMO for all of our Oracle database running on either Solaris Sparc or Oracle/Linux in VMware.

I am looking for info on VSC 2.0 in ESX 3.5 if anyone has any tips or horror stories. Trying to decide if we should implement VSC now or wait until we upgrade our VM infrastructure and move to Vsphere 5.

Thanks!

[klass]

This configuration is only supported for SQL and SnapManager for SQL at the moment. This configuration is not supported with SnapManager for Exchange currently.

Mike Klass

Manager, Microsoft Solutions Sales and Technical Enablement

NetApp

+1.919.476.5280 Direct

+1.919.749.3765 Mobile

www.netapp.com<http://www.netapp.com/us/?REF_SOURCE=emmbonrunnersignaturehp-us>

<http://www.netapp.com/us/?REF_SOURCE=emmbonrunnersignaturehp-us

[ZEBEDY]

This is something that is currently making me nervous about moving to a NetApp solution, is there any news / roadmap of when Exchange on vmdk is going to be supported?

Regards,

Mark

[dimitrik]

Hi Mark,

It's not as if Exchange won't work on NetApp gear on NFS or VMFS - but you just won't be able to do certain things regarding app-aware snaps.

Why would lack of support for this make you nervous about going to a NetApp solution in general?

No other vendor supports the NetApp-type snaps of Exchange with Exchange on NFS or VMFS anyway.

No other vendor has the depth of NetApp/Exchange integration in general, either.

If you deploy Exchange with RDMs (very easy) then you can do everything.

[ZEBEDY]

Hi Dimitris,

Thanks for your response.

The issue is that I had previously been told (not by NetApp) we could do stuff with Exchange on VMDKs, then I was told they had to be direct iSCSI mappings from the windows initiator. Which is all very well messing around with in a lab, but a real issue when it's a production system!

Deploying with RDM's would be easy but again this is a current production environment with Exchange on VMDKs.

Do you think that the Exchange on VMDK snapmanager support is likely?

Regards,

Mark

[dimitrik]

Hi Mark,

Let me clarify my response:

You can of course theoretically run Exchange on VMFS or whatever you want (though some things like cluster quorum disks actually need to be on RDMs to function AFAIK). You just won't be able to use SME - but Exchange will run, just as it does for you today on VMFS.

The short answer is that certain features (such as snaps) are simply not supported by Microsoft in the VMFS/NFS case. Check out TR-4033, virtualization section in page 20.

It follows that by just virtualizing Exchange you lose certain valuable VMware features like VMotion, even if you use RDMs.

We will not violate what Microsoft supports - since if we do and you have a problem and you call MS, it could cause support headaches for your organization. It's not necessarily a matter of technology.

Once Microsoft blesses running Exchange on more things like SMB, NFS and VMFS and supports taking snaps in those environments, we will of course enable SME support for those.

Also see here.

D

[peter_eicher]

You could protect this environment using NetApp Syncsort Integrated Backup (NSB).  It will allow you to make use of NetApp snapshots (on secondary storage) for recovery of files, volumes (datastore), individual Exchange items or even the entire application (via fast V2V restore).

In this scenario, NSB would use an agent inside the VM, so it doesn't make any difference if the VMDK is hosted within NFS. The Agent sees it as a Windows file system. You want to use an Agent anyway so you have full Exchange awareness.

Regards,

Peter Eicher

Syncsort

[abhisek]

For SMSQL please refer TR-3941 for vmdk implementation.

Regards,

Abhishek

[edgel]

It drives me crazy that people think this is a NetApp limitation, or dismiss very mature (7-8 year old!) iSCSI technology that powers mission critical systems worldwide as "suitable for a lab but not for production".  It also drives me crazy how many perfectly supported alternatives NetApp provides on VMWare and Hyper-V that folks overlook/dismiss.  These solutions provide all the benefits of virtualization plus the benefits of NetApp snapshots through SnapDrive (iSCSI guest presentation, FCP/iSCSI RDM, etc) while future-proofing your investment.  

I have set up some very large customers in the defense, energy and education industries (think 12K-150K mailbox sites) with supported, tested, and Microsoft ESRP approved solutions using NFS datastores for the Exchange OS drive, and guest presented iSCSI LUNs using the MS initiator (no messy RDM issues and works GREAT with storage VMotion since Exchange 2010 SP1).  As further insurance/future proofing, NetApp even offers a free API and PowerShell to convert iSCSI/FCP/FCoE LUNs to VHDX or VMDK files once this becomes supported by Microsoft (which is right around the corner I suspect).   Now that SMB 3.0 on Server 2012/Hyper-V is here, MS cannot really make a claim that their brand new SMB 3.0/NAS approach on Hyper-V is more mature than NFS/NAS on VMWare!).  Meanwhile, show me a another storage vendor who does SAN (FCP/FCoE/iSCSI) and NAS (NFS/SMB 3) on the same unified OS, and can even assist you with an in-place conversion tool to get from FCP or iSCSI block back to VMDK/VHDX over NAS when the time comes (check out cmdlets listed below that ship as part of the free PowerShell toolkit).  Remember that LUNs are just files to NetApp, and we have the expertise and tools to massage those files into just about any desired format.  So, we play the LUN game as long as we have to and convert you to native files just as soon as our various partners get their brains wrapped around the greatness of this concept and decide to support it.  Already there with SQL and Exchange seems imminent. 

Bottom line here is that I personally have overseen the implementation of iSCSI guest presented mailbox database LUNs on NFS hosted Windows OS for over 350K mailboxes, and I see no reason not to deploy this way today.   These solutions are now several years old and still going strong.  These solutions leverage SMVI and SME for backup of OS/Databases respectively, and take full advantage of MS DAG multi-site architecture and all NetApp efficiency technologies.   Oh yeah, did I mention 15-25% de-dupe saving on the databases and near total elimination of reseeds over the WAN?  Talk to your NetApp Professional Services team about how you can implement these fully supported and jointly tested LUN based solutions today and (once support restrictions are released) easily convert them to simple VHDX or VMDK files on native NFS exports or SMB 3.0 shares when the time comes. 

Kind regards and happy virtualizing!

- Todd

Cmdlet: ConvertTo-NaVhd

NAME
    ConvertTo-NaVhd
    
SYNOPSIS
    Convert a VMDK file, a VHDX file, a dynamic VHD file, or a Data ONTAP LUN in
    to a VHD file.

Cmdlet: ConvertTo-NaVmdk

NAME
    ConvertTo-NaVmdk
    
SYNOPSIS
    Convert a VHD or VHDX file into a VMDK file.
    

Cmdlet: ConvertTo-NaVhdx

NAME
    ConvertTo-NaVhdx
    
SYNOPSIS
    Convert a VMDK file, a fixed VHD file, or a Data ONTAP LUN into a VHDX file.

Cmdlet: ConvertTo-NaLun

NAME
    ConvertTo-NaLun
    
SYNOPSIS
    Create a LUN from a virtual hard disk (VHD or VHDX).

[HENRYPAN2]

Ha-ha edgel,

I'm with you & also feel the misleading rumor from you know whom:>)

Thanks

Henry

[edgel]

Hi Henrypan2,

I hope the key point of my post came through (that only NetApp allows you to deploy over hybrid NFS/iSCSI today with all the same advantages of native NFS/NAS, and in leading the way with support of SMB 3.0 on Server 2012/Hyper-V we are likely opening additional avenues of support for NAS/NFS on VMWare).  

I am really excited about SMB 3 on Server 2012/Hyper-V (as well as our implementation of SMB 3.0 and ODX) for several reasons, many of which indirectly benefit VMWare/VAAI on NFS shops - read on:

1) It helps to legitimize NAS as an alternative to SAN for VMs containing all types of data (including SQL, Exchange, VM OS Drives) as all will be supported by Microsoft on their Server 2012/Hyper-V product over SMB 3.0.

2) It finally closes the main feature gap between Hyper-V and VMWare; namely, the operational simplicity of deploying/copying/backing up/restoring files in a NAS datastore with full native storage offload support (what Microsoft calls ODX).

...and most importantly...

3) It will open the door a bit wider for support of other file/NAS technologies that have also proven perfectly capable of virtualizing block devices for years, and can do everything listed above using VMWare VAAI on NetApp NFS (but have not been officially supported with certain applications). 

So, I hope it is clear that I was not being snarky or trying to start a rumor.   Fact is, this is really mature stuff and now we have generations old hypervisors from several large players exploiting our full capabilities natively over NAS.   I am truly looking forward to retiring many of my iSCSI SAN setups (already doing this for some SQL customers) in favor of VMDKs/VHDXs, but I am also really glad I have such a flexible and mature toolkit to draw from when an application or hypervisor vendor decides that one protocol or the other is the only option they can support today.  

Finally, I want to mention that SMB 3.0 exists in clustered Data ONTAP only, so our 7-Mode customers running Hyper-V and wanting NAS goodness will need to consider a transition in the very near future (another service NetApp Professional Services currently provides) to leverage that new feature.   Of course, existing VMWare customers using NFS will have much more time to consider that move since our NFS implementations are extremely mature in both 7-Mode and clustered Data ONTAP and the VAAI for NFS will be available in both modes (versus SMB 3 + ODX which will be clustered Data ONTAP only).    

Kind regards and happy virtualizing!

- Todd

[HENRYPAN2]

Saluting edgel for such a good news:>)

Once more reason to swap to C-mode soon.

Henry PAN