Best Practices

I have a number of posts and various documents that cover the best practices on the PowerMax but as this topic generates the most questions, I figured I’d create this page to include some high-level information.

PowerMax BP doc

First, there is a PowerMax best practices guide in the Documentation Library

Other BP docs

If there is a specific topic that requires more detail, for example on vVols or vMSC, I create a separate whitepaper. Easy enough.

Common questions

Though in general these questions are all addressed in detail in the best practices doc and various blog posts, here are some of the more common ones.

Q: What is the recommended size for a datastore on a PowerMax?

A: We make no recommendation as to the size of a datastore. The most important aspect of sizing a datastore is VM-density, and in particular how many of those VMs on that datastore will be actively servicing IO at any one time. The PowerMax uses the same amount of cache regardless of size, so that is not a factor you need to worry about. You should size your datastores so they can maintain whatever SLA is needed for the VMs occupying said datastore. A single device has a single queue so at some point continuing to add active VMs to a datastore will diminish performance (unless something like Storage IO Control or Host IO Limits is employed). I’ve seen 100 GB datastores and 62 TB datastores (those are comprised of very large SQL VMs so there aren’t many); however most customers tend to standardize on one or a few sizes – small, med, large. So do what is right for your environment.

Q: Thick or thin vmdks?

A: To be or not to be? It doesn’t matter honestly. Throw out all the performance implications you remember about this discussion, they do not apply. So the only difference you need be concerned about is space management. VMware will happily allow you to exceed the space of the datastore when you use thin vmdks. The PowerMax, having no idea what you have provisioned, will keep giving you space until you exhaust the device. So if you use thin, just pay attention to what is allocated on the array. As you approach full, you can always expand the device online (yes, even if it is replicated).

Q: How many HBAs/ports/paths are needed for my ESXi host?

A: Use 2 HBAs and a minimum of 4 ports across directors for FC (or FC-NVMe). That will be 8 paths. Some customers will use less, some more. When I say across directors, that means “go wide before deep”. If you only have 2 directors, then obviously each director will have 2 ports. But if you have 4 directors, it’s best to use a port on each rather than stacking them on a subset of directors. We also generally recommend 1:1 zoning (HBA to port) but leave that to your discretion. iSCSI or NVMe/TCP would follow similarly.

Q: Do I have to enable or tune VAAI?

A: VAAI is enabled by default, but we do recommend tuning XCOPY. By default XCOPY will only use a 4 MB extent which means cloning and SvMotion are more time consuming. You can adjust that to 240 MB with claim rules (though SvMotion will only ever use 64 MB per VMware). The best practices doc above (or the one on VAAI) has detail. Note we do not recommend changing any UNMAP settings. Use the default.

Q: PowerPath/VE or NMP?

A: Well you can’t expect me to answer this any way but PowerPath/VE, but I’ll give you the most unbiased answer I can. In an optimal environment with no network issues, performance differences are corner cases mostly. The benefit of PP/VE is that it is really good about congestion and error management. NMP isn’t. So when you start having some problems on the network, you want your software to find the path of least resistance (pardon the pun) and avoid those paths generating errors. NMP is a dumb terminal. You tell it to switch paths every 1 IOPS (default is 1000 so be sure to change it), somewhat for performance, but mostly so it catches errors more quickly since it does not have PP/VE intelligence. How about the latency option with NMP? Yes, you can try that one out but it really is most effective only with cross-connect SRDF/Metro.

Q: Should I tune VMware parameters or queues?

A: In most cases, no. The PowerMax works really well with the default settings of VMware parameters (yes, save for NMP IOPS to RoundRobin 1). Some of our arrays, e.g., XtremIO, have very specific needs in this area but we do not. So leave well enough alone unless otherwise instructed by VMware or Dell (due to an SR say).

I’m going to close it with that one. If there is a burning question you have that you think others may want to hear about, leave me a comment and I’ll add it. Thanks.