Choosing Performance Policies for ESX Datastores

[crw64]

Is there any performance benefits of choosing a particular performance policy other then ESX 5, such as SQL Server 2012 for example, if that VMFS volume is going to host a few SQL Server 2012 Data vmdk's for example?

I am trying to ascertain the performance versus administrative overhead of simply creating for example, 20 generic vmfs data stores, choosing ESX 5 performance policy, and using them for a combination of VM's as well as larger data volumes (file servers, sql servers {ms sql, oracle and mysql}). Currently we have 68 volumes ranging from 600gb to 5.5tb, we have dedicated volumes for ms sql data, ms sql logs, exchange logs, exchange data, file servers, vdi, vm os's, etc. More or less to utilize the performance policies. However I am not sure it makes a huge difference and I think the noticeable performance improvements would likely come from having those volumes as in-guest attached iscsi versus vmdk's on vmfs data stores.

Thanks

[Nick_Dyer · Accepted solution]

Hi there,

The legend that is Wen Yu tackled this very subject on a great blog post, which is available here: Myth Buster: Top three myths in block size. In my opinion, standardising on the VMware ESX 5 Perf Policy makes overall management a lot easier, although it does increase the potential size of volume/snapshot metadata used to store the different block sizes the various applications require.

Let us know if you have any further questions. For now i'll mark this question as answered!

[marktheblue45]

If you are presenting the volumes as VMware datastores don't use anything with more than a 4k block on the Nimble Array else it will lead to block misalignment. 

[crw64]

So in essence then, the performance policies such as say, exchange data, sql logs, etc. would be more for external iscsi attached volumes from either in-guest or physical servers? A vmfs volume dedicated to handling just SQL log vmdk's for example, would still be better configured with the ESX 5 policy, since the underlying structure is VMFS - even though that vmfs data store is holding several different vmdk's that are dedicated to sql log volumes from different sql vm's.

Is that correct?

[Nick_Dyer]

No, that's what Wen's blog tackles. It's the biggest myth of VMware block sizes.

You can use the VMware performance policy and throw pretty much any workload inside it as it makes management easier. However if you put things such as log files inside those datastores, they will end up being cached, which will lead to cache pollution, as log files don't require cache as they're rarely read back.

You CAN use Exchange/SQL performance policies for datastores provisioned to VMware, but you must ensure that you only store the correct type of data inside it, otherwise you'll end up with misaligned IO and it's not a pretty sight.

An example here is creating a VMware datastore for Exchange 2013 using the Exchange performance policy, but ONLY storing the Exchange datastore volumes inside it (ie no OS drives, log drives etc etc).

After all of the above, i still revert to using the VMware ESX 5 Perf Policy as it makes things simple. What I would encourage you to do is create yourself a new non-cached VMware ESX 5 Perf Policy (4k, compression on, caching off), and use that for when you need to provision log file volumes to remove the cache pollution issue I spoke of above.

HTH

[crw64]

Okay perfect, that makes sense and the impression I have been under since instituting our original configuration. I was coming across somewhat conflicting information that was making me question our current setup, as well as the validity of continuing to go down that road. The clarity and confirmation is appreciated.

Thanks

[marktheblue45]

Surely the rule that the array block size should be equal or smaller than the layer presenting to it applies? ESXi writes in 4K blocks. 

[Nick_Dyer]

Hey Mark, that's the myth - it doesnt. Check out Wen's blog post. Myth Buster: Top three myths in block size

[marktheblue45]

I did Nick.... Months ago but was told by support to avoid it..indeed I converted our exchange DB and Logs using disk director to 64k and 32k (NTFS) after moving them to in-guest iSCSI. NOW I HAVE BLOCK MISALINGMENT. Disk director the culprit. I'm with you and Wen but have to off support. 

[rlabarre65]

One other point to make here as well.  I am not nearly as technical as Nick, Wen, or Mark, but I have had a customer with misalignment issues in the past.  The issue in that case was that they were misaligned before they were vmotioned over to the Nimble array.  In that case the only fix was to create new Nimble volumes, and migrate the data over.  Kind of the ole "garbage in , garbage out" mentality still does persist.