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.

[Nick_Dyer]

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.

[Nick_Dyer]

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