9 Replies Latest reply: Aug 13, 2014 10:46 AM by Ryan LaBarre RSS

    Choosing Performance Policies for ESX Datastores

    crw Wayfarer

      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

        • Re: Choosing Performance Policies for ESX Datastores
          Nick Dyer Navigator

          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!

            • Re: Choosing Performance Policies for ESX Datastores
              Mark Harrison Adventurer

              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. 

                • Re: Choosing Performance Policies for ESX Datastores
                  crw Wayfarer

                  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?

                    • Re: Choosing Performance Policies for ESX Datastores
                      Nick Dyer Navigator

                      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