I'm looking for feedback from anyone who is using a NETapp filer, with Snap Manager for Exchange. We plan to install one and the consultant has told us that our current virtual server running exchange 2003 can stay virtual, but the drives containing the log files and the exchange information store need to be move outside of vmware, i.e. can't be stored inside an vdmk file.
My understanding is the log and information store will need to be stored on separate LUNs in the filer and the virtual machine will mount these LUNs.
My question: I've looked through all of Netapp's best practices and I haven't found a similar setup. I believe the consultant, but I would be interested in additional confirmation that this is the prefered setup, or a best practices guide.
Thanks
I found this information in the vmware forums:
The simple answer is "yes" you can run Exchange using vmdks stored on NFS storage and usually in small to medium size environments this is the way to go. If you have 2-4 thousand heavy Exchange users on a mailbox server you might want to reconsider.
The more complicated answer is this should be considered carefully in the context of several things.
1.Are there any SAN or backup application that need native access to the LUNs (RDM or iSCSI). Things like Snap Manager for Exchange need to use an iSCSI or FC LUN presented directly to the Exchange VM. If this is the case, you would still run your operating system on a VMDK stored on NFS and then present an iSCSI or FC LUN to the guest for things like Database or Translogs.
2.You should profile your application using perfmon and determine the average (but include spikes) for throughput and I/Os per second and compare this to the throughput that you can get using NFS which will depend on how you set up your networking.
Some other good answers here. I will just answer from personal experience, that for a small exchange / AD deployment SME is a waste of time and money. It's great if you have a large exchange dataset, but for the few 10's of gigabytes I was managing it was just added complexity. It's quite complicated, and requires a whole pile of very specific software revisions to work.
Exchange in a VM will DEFINITELY work, and if you forego SME you can use the native exchange multi-master replication to boot. NetApp obviously would like you to purchase SME, and will most likely not want to take responsibility for data corruption if you don't use it, but simplicity of VM setup, management, and snapshots will probably make up for it.
It just depends on the size of your deployment... if you're under 50-100 users I don't think I'd consider SME.
I work with Netapp but I am not directly familiar with Snapmanager for Exchange so hopefully somebody with direct experience w/ SME and virtualized Exchange can offer better insight. Likewise, apologies if this is just a total rehash of what you've investigated so far. I did a quick look for some documentation that specifically deals with this and I didn't find anything explicit. There are references to physical and virtual resources in the Snapmanager for Exchange admin guide but I believe those are related to Exchange cluster resources and not virtual disks or virtual machines.
Thinking it through, it makes sense that SME requires LUNs rather than vmdks if you take into account what it would be snapshotting. Leveraging an array snapshot against a vmdk is kind of tricky since the disk in question is actually a file sitting in a datastore which is in turn sitting in some pool of array-based storage. To get a proper snap of the filesystem inside the vmdk file, VMware snapshotting would be required. To make this VMware snapshot useful at the array level, there'd need to be some coordination between VMware and the storage array so that a 2nd snapshot (a storage-based snap) actually captures the vmdk filesystem in a state worth snapshotting (buffers flushes, ops quiesced, etc. by the first VMware snapshot). Additionally, since Netapp snapshots are volume-based, to get a snapshot of a vmdk, the entire volume housing the VMware datastore that the vmdk is in would need to be array-snapshotted and you can't easily "drill down" and just snap that part of the volume where the vmdk lives or pluck it out after the whole-hog array snapshot has been taken.
Snapmanager for Virtual Infrastructure does some coordination between VMware snapshots and Netapp array snapshots to streamline all of this but I don't know that Snapmanager for Exchange has that awareness.
SME Admin guide: http://now.netapp.com/NOW/knowledge/docs/SnapManager/relsme50/pdfs/admin.pdf (NOW login required)
I work in an environment in which we use SME with Exchange 2010. I realize this is different from your environment however I thought this might be worth sharing. Unlike your environment, our Exchange servers are physical though the log and information store on on separate physical luns being served out by NetApp via iSCSI which is in line with what the consultant told you.
I cant speak to anything visualization related, however my experience says that is is a good idea to have separate physical luns for the log and information store, especially if you plan to take snaps. We have a medium sized exchange environment however the number of changes written by Exchange 2010 to the log volume in particular is staggering. The amount of storage necessary to keep the snaps around for 2 weeks is amazing. Keep in mind that snaps capture all changes to the volume (the volume contains the lun). This is especially noticeable if you are performing mailbox moves or maintenance within Exchange.
Also worth noting, Exchange is constantly writing to the Netapp so it is good to have the log and information store in separate aggregates (separate disks) for performance reasons.
Anyway, this might be a little outside of the scope of your question but it might be good food for thought if you decide to go the Netapp route.
I work for NetApp Support and do support the SnapManager products and can confirm that any current release of SnapManager for Exchange (SME) does not support VMDK disks of any kind. SnapManager for SQL (SMSQL) does support it but not SME at this time.