4 Replies Latest reply: May 12, 2016 5:14 AM by John Nurden RSS

    Exchange 2016 Performance Policy

    John Nurden Newbie
    Visibility: Open to anyone

      Hi,

       

      I am planning out a migration from 2010 to 2016, moving from a HP 3PAR SAN to the Nimble. Is there a performance policy or recommendation for Exchange DB and Logs for 2016? I know there is 2010 plans built in but these are set with a 32kb block size and a 16kb block size respectively. I believe the recommendation for 2016 is 64kb?

       

      Can anybody advise?

        • Re: Exchange 2016 Performance Policy
          Nick Dyer Pioneer

          Hi John,

           

          you can use either the Exchange 2010 or 2013 performance policies. Ultimately, the maximum block size on the Nimble array can be configured to is 32kb so as long as you're using those best practices you're fine.

           

          Or, if like me you're a tad OCD, create yourself a new policy called Exchange 2016 with the same block/cache/compress settings for ease of organisation and reporting within the UI/Infosight.

            • Re: Exchange 2016 Performance Policy
              John Nurden Newbie

              Thanks for the quick reply Nick. A few questions on this...

               

              Firstly, my nimble CS7000 only has an exchange 2010 policy. There is no 2013 policy. Does this appear in a later version of the software perhaps?

               

              Secondly, all the recommendations I have seen for exchange from an NTFS perspective state to use 64k block size. Will there be any performance hits or issues using a larger block size in windows on the VMDK than the block size of the underlying storage itself?

                • Re: Exchange 2016 Performance Policy
                  Nick Dyer Pioneer

                  D'oh. You're right, I knew there was a 2xx3 policy but turns out it's 2003! Here's a screenshot from my system (on NimbleOS 3).

                   

                  Screen Shot 2016-05-12 at 13.03.51.png

                   

                  You're fine with using 32k on the array itself. You can still configure it for 64k on the host, it just means that every block will be divided into 2x 32k blocks. This won't cause any overhead on performance as the metadata is still relatively small. However, if you were to use a 16k, or even 4k block size then there could be issues, as the amount of metadata needed could be considerate - which is why we recommend using the nearest appropriate block size possible.