Array Performance and Data Protection
cancel
Showing results for 
Search instead for 
Did you mean: 

Choosing Performance Policies for ESX Datastores

SOLVED
Go to solution
crw64
Occasional Advisor

Choosing Performance Policies for ESX Datastores

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

11 REPLIES
ndyer39
Honored Contributor
Solution

Re: Choosing Performance Policies for ESX Datastores

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
Valued Contributor

Re: Choosing Performance Policies for ESX Datastores

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
Occasional Advisor

Re: Choosing Performance Policies for ESX Datastores

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?

ndyer39
Honored Contributor

Re: Choosing Performance Policies for ESX Datastores

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
Occasional Advisor

Re: Choosing Performance Policies for ESX Datastores

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
Valued Contributor

Re: Choosing Performance Policies for ESX Datastores

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. 


ndyer39
Honored Contributor

Re: Choosing Performance Policies for ESX Datastores

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

marktheblue45
Valued Contributor

Re: Choosing Performance Policies for ESX Datastores

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
Occasional Advisor

Re: Choosing Performance Policies for ESX Datastores

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.

DJ6
Occasional Visitor

Re: Choosing Performance Policies for ESX Datastores

Anyone know what happened to the Wen Yu "Top Three Myths" article after the HPE purchase?  

Thanks. 

MattLand
Occasional Visitor

Re: Choosing Performance Policies for ESX Datastores