VMware, XtremIO, and Native Multipathing
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: 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.
Please note that with vSphere version below 5.5, clustering is not supported when the path policy is set to Round Robin. This is a limitation for Microsoft Clustering services. Those disks or RDMs should be set to a fixed path policy or an planned upgrade to vSphere 5.5 should be considered.
Great write up! Thank you.
Yep those are always the "fun" environments haha.
Very true, Joel! I honestly didn't think about that. I will add that as a note. I've been dealing with VMs that have scsi bus sharing a lot lately and that has prevented a lot of easy tasks like vmotion and maintenance mode. It was a pain to correct it for those as RDMs had to be unmounted and mounted back.
The easiest way in my opinion to correct already presented volumes is to simply maintenance mode and reboot each host after the rule has been put in place. On reboot the host will rediscover even existing storage using the new rules. Unless there is something preventing you from easily rebooting the hosts it can probably be done much faster than storage vmotioning all the vms to new data stores.