Exchange 2013 NTFS Mount Points on VMware Performance Policy?

[julez66]

We are in the process of rolling out Exchange 2013 SP1 on Server 2012 R2 in a VMware environment.

The plan is to use NTFS mount points for all the database and log volumes, mainly we don't want to deal with looking at 15+ drive letters and in general is a lot cleaner.

The question really comes down to is would we be better off creating small Nimble iSCSI volumes and using those for the mount point drive letters? (seems like a waste to me).

Or should we use a small VMDK to contain the NTFS mount points? (seems cleaner to me)

The only real gotcha here is that the NTFS mount points will be using the Microsoft Exchange 2013 best practice of 64K allocation units where as the VMDK will of course be using the 1MB block size, both with different Nimble performance policies of course.

I guess the next question should be, do I use the Exchange 2010 performance policy for Exchange 2013?

[boerlowie42]

The blocksize of VMFS is indeed 1MB, but this is only for file operations done directly on the VMFS volume (= done by ESXi).  Things like creating VMDK files, growing thin VMDK files, creating vmware.log files, ...  So if you grow a VMDK file, it will be done in 1 MB blocks. (you have sub-blocks on VMFS-5 for small files though).

But ANY guest IO will be untouched and independant of the VMFS-5 blocksize.  So if you Exchange VM send 32K blocks, that's what the Nimble will see, no matter what blocksize you use on VMFS (even on VMFS-3 with those different blocksizes).

Bottomline: if you VMFS contains only VMDKs with exchange databases then yes, chose the Exchange performance policies on the Nimble for those OS-es and NOT the VMware one.  Same applies for SQL or Oracle running on VMs.

[ndyer39]

Hey Sammy,

I believe even in VMFS 5, VMware will still use 4k blocks to send and receive IO to the storage array regardless of the IO being sent from the VM layer. Therefore regardless of the application type being stored in the VMFS, the ESX 5 performance policy should be used on the array for all VMFS volumes. Otherwise this could cause unnecessary block misalignment and/or fragmentation and wasted space.

EDIT: Above is incorrect - VMware doesn't divvy up the blocks to 4k increments (as pointed out by Sammy).

The SQL/Exchange performance policies should only be used if doing direct connect iSCSI volumes to Windows VMs through the VM iSCSI Initiator & using Nimble Connection Manager for Windows.

[boerlowie42]

Hi Nick,

that's not true.  VMware will NOT break IOs from the Guest VMs in smaller pieces.  Check out the blog below by one of the Nimble engineers:

Myth Buster: Top three myths in block size

He also confirmed to me that you can and should use the SQL/Exchange performance policies when you use VMFS/VMDK but only when you limit that VMFS datastore to those disks.  So one VMFS for Exchange DB, one VMFS for Exchange Logs, one VMFS for SQL DB, ...  each with the correct perf policy set.

The vSphere 5 policy will be valid for your general VMs and the systems drives of those SQL, Exchange, ... VMs.

[ndyer39]

Ah yes, I forgot about that post. Well referenced!

You're right in the respect that if and ONLY if that VMFS will store Exchange volumes then the Exchange perf policy can be used. However if Storage DRS is in place, or the VMFS may be shared by other applications then the ESXi 5 policy should be used instead.

[boerlowie42]

True indeed.

We use this method for our SQL & Exchange VMs because our policy is VMDK only and not in guest iSCSI.  So then we set up dedicated VMFS volumes for those applications.  Works fine, but you have to pay attention to those things you mentioned like Storage DRS etc.

Blocksizes, NTFS allocation units, ...  it's always a fun thing to discuss and lead to may interesting discussions :-)

[julez66]

So I guess the real question here then is since we're using mount points instead of drive letters.  The mount points have a performance policy based on what is on them, in this case Exchange DB and logs.

The question was really since we are using mount points, would the performance policy need to be for Exchange or for VMware for the VMDK holding the guest initiated mount points.

I would assume the VMDK could have whatever performance policy (preferably the VMFS5 one) and the mount points would actually need the performance policy of the data on them.

[jmonger96 · Accepted solution]

Hi Julez

The performance policy bit of this question has been answered above i.e. if iscsi direct connect to guest then exchange, if vmdk's to host exchange data then either ESX if shared datastore or exchange if dedicated datastore.

In terms of the policy for Exchange 2013 yes use the Exchange 2010 which sets the block size to 32KB (which is the same for Exchange 2013 anyhow).

In terms of the mount point root i.e. the disk which holds the mount points to the actual Exchange disks I would go with a small VMDK that is hosted on the same datastore as your Exchange server C:\ VMDK - mount points are just a reference to another disk and using a VMDK saves you a separate Nimble volume as you suggest.

Jason

[julez66]

Thanks Jason, that was the route I was thinking about going with and just hearing it from a third party helps to solidify our data-store architecture for the new exchange deployment.

Now I just need to figure out why our third party consultant seems to think the new Microsoft best practice for Exchange 2013 is to keep the database and logs for that database on the same volume...which is contradictory to everything I've ever been taught up to this point, we're still waiting on the documentation that states that.

But in case anyone was interested in what we're doing, I've attached a PDF from the Visio diagram for the architecture we're proposing.

[jmonger96]

Hi Julez

Thanks for sharing the architecture. My first thought in reviewing this is how are you intending on backing up Exchange? If you intend to use Nimble VSS snapshots I'd suggest you might want to have a single database per volume. Having only a single db per volume means that recovery of that volume doesn't impact the other replica db on the same volume (which of course would be restored as well). If however you are using another backup/recovery mechanism having more than one per volume would work fine.

I guess the other thing is that its only with Exchange 2013 that you can have more than one db per volume, but this change was primarily to support JBOD solutions to improve reseed times. Again you could always leverage Nimble VSS to help with reseeds anyhow - or at least to allow incremental rather than full reseeds, again this is dependent on your intended backup method.

I haven't seen the recommendation to store logs with dbs on the same volume, typically I've always kept them on separate volumes.

Jason

[julez66]

So yeah the goal is to use Nimble VSS snapshots and then we would also want to push a replica to tape located at our HQ site. We thought about doing a volume for each database and DAG copy, but the sheer number of volumes we weren't very keen on doing.  The idea was to spread workload of the inactive with the active.  I'm less concerned about the recovery since we probably wouldn't recover the volume we'd just use a zero copy clone and then restore an individual database.  I know just looking at it and thinking about it, it absolutely looks like overkill... we were pretty shocked of the outcome of all the storage used there not to mention there's essentially 6 copies of an individual email when you factor in journaling.  I wish all the email was single instanced as that would help our cause a pretty great deal... I feel there's a good bit of waste just because of the journal, so we're trying to figure out a way to take care of our 3 yr mail retention and legal hold polices without a journal.

Still haven't heard back from the large 3rd party consultant with the supplied Microsoft best practices on that log/database volume nonsense.  I think there's going to be an inherent problem with Nimble if this is the case anyway due to the separate performance policies.

[jmonger96]

Hi Julez

Yep that makes sense. Zero Copy Clone will work for recovies as you say, and with 300GB databases the recovery time should be about an hour over a 1GbE link presuming they are full 300GB databases.

If you are using a combination of Nimble VSS and a tape based backup solution just be aware that you only want one of them to truncate logs. In Nimble VSS this is done if you select the "Verify" option in the protection policy, which then clones/mounts/verifies/dismounts and then calls in to the Exchange VSS writer to truncate logs (which in turn truncates on all copies via the Exchange replication service). So either don't enable this option on Nimble VSS backups or configure the tape backup solution to be a copy backup so only one is truncating.

In terms of Nimble performance policies if databases and logs are shared, I'd just use the db policy - it won't be fully optimised but it shouldn't cause a problem either.

Good luck with the deployment !

Jason

[julez66]

We would rely on the Nimble VSS for log truncation, the hope is that the tape would either mount a replicated volume or would do a backup of a lagged database copy.

Also just got he response from the large 3rd party consultant about the logs and databases.  I for one don't exactly care for the wording in the Microsoft guide about how it says "Supported: Isolation of logs and databases isn't required." in that section.  Now I'm being dramatic but, basically what I'm reading in the end is 'use 1 volume for all databases and logs and we'll support it just fine.'

"1. Storage best practices: http://technet.microsoft.com/en-us/library/ee832792(v=exchg.150).aspx - Note the section titled "Mailbox Database and Log Volume Co-Location".  It describes the colocation support for highly available configurations (i.e. Database Availability Groups).  Separation of database files and logs is still recommended for standalone databases."

[julez66]

Thanks again for the help, I've branched off into another thread on what our configuration actually looked like in the end.
https://connect.nimblestorage.com/thread/1618