So, you have your XtremIO installed, configured, and ready for use. Now what? If you’re like most I’ve worked with, you have probably already started creating volumes, presented them to your ESXi hosts, and have created datastores. Often times, I am finding myself working with customers who express some performance concerns post-migration to XtremIO and it is usually due to a commonly overlooked item in the EMC Host Configuration Guide.
The most overlooked item is in regards to VMware Native Multipathing. If you’re familiar with the EMC VNX arrays, you probably noticed that the VNX devices presented in vCenter defaulted to a Round Robin path policy. This is because VMware had a rule in place that identified CX/VNX arrays to accommodate for ALUA (active/active) and would assign that policy (VMW_SATP_ALUA_CX) to those devices which set them to Round Robin instead of Fixed Path.
With the XtremIO, there is no such in rule in place. By default, the XtremIO devices will identify with policy VMW_SATP_DEFAULT_AA and I have noticed that the path selection policy is set to Fixed (Default).
To overcome this, it is recommended to create a new Storage Array Type policy per the EMC XtremIO Host Configuration Guide.
esxcli storage nmp satp rule add -c tpgs_off -e “XtremIO
Active/Active” -M XtremApp -P VMW_PSP_RR -O iops=1 -s
VMW_SATP_DEFAULT_AA -t vendor -V XtremIO
This creates a custom rule for XtremIO devices, sets the path selection policy to Round Robin, and then sets the path switching frequency from a default of 1000 I/O packets to 1. This ensures optimal distribution and availability of load between I/O paths to the XtremIO storage.
As you may see in the Host Configuration Guide, it is noted below:
Note: With NMP in vSphere versions below 5.5, clustering is not supported when the
path policy is set to Round Robin. For details, see vSphere MSCS Setup Limitations in
the Setup for Failover Clustering and Microsoft Cluster Service guide for ESXi
5.0 or ESXi/ESX 4.x. In vSphere 5.5, Round Robin PSP (PSP_RR) support is introduced.
For details, see MSCS support enhancements in vSphere 5.5 (VMware KB 2052238).
Note: Use this method when no XtremIO volume is presented to the host. XtremIO volumes already presented to the host are not affected by this procedure (unless they are unmapped from the host).
If you find yourself in the situation above with volumes already mapped and datastores created, you can simply storage vMotion your VMs over to new XtremIO volume datastores with this new rule in place.