HPE Storage Users Group

Hi all,
seeking some clarification on a couple of ESXi/3PAR configuration settings.

1. SATP Claim rules for 3PAR luns

Customer is now on ESXi 6.7P05 (which is the latest I believe). As of 6.7U2 it looks as though the recommendations around the ESXi SATP rules for the 3PAR have changed.
Please see pages 35/36 of the following document

https://support.hpe.com/hpesc/public/docDisplay?cc=us&docId=emr_na-c03290624&lang=en-us

It now says different options should be used instead of IOPS=1.
I currently have the original pre 6.7U2 rule in place for these ESXi hosts

esxcli storage nmp satp rule add -s "VMW_SATP_ALUA" -P "VMW_PSP_RR" -O iops=1 -c "tpgs_on" -V "3pardata" -M "VV" -e "HP Custom iSCSI/FC/FCoE ALUA Rule”

The guide now indicates I should have the following rule

esxcli storage nmp satp rule add –o "throttle_sll" -s "VMW_SATP_ALUA" -P "VMW_PSP_RR" -O "policy=latency"; -c "tpgs_on" -V "3PARdata" -M "VV" -e "HPE Custom iSCSI/FC/FCoE ALUA Rule"


Assume I will need to remove the existing legacy rule and add the new one followed by a reboot for it to take effect. The odd thing is there now appears to be a NEW system (not user) created rule
Within ESXi which uses the new ‘throttle_sll’ method but also sets the pathing policy to MRU rather than round robin..does anyone know if I add the new USER rule above it will override this system one. (see this post https://communities.vmware.com/t5/VMware-vSphere-Discussions/ESXi-6-7-Update-2-Disk-Path-Policy-Reset-on-3PAR-Disks/td-p/2270015)

2. Customer has quite high saturation on the array during the night (3-5am typically). I believe this relates to VEEAM backup activity. Most nights during this period saturation reports on Infosight show it at 90-102% for the period. This has inadvertently generated alarms in ESXi for luns being briefly unavailable on one or other paths I am guessing due to the fact the system simply cannot service the request quickly enough. I was considering whether it was worth enabling any of the following

queue-full-threshold 4
queue-full-sample-size 32
set via
esxcli storage core device set --device device_name --queue-full-threshold 4 --queue-full-sample-size 32”

which I've seen in various places is recommended on FAN in multiple host type configurations.
I just wondered what impact this would have on workload and if it would lead to throttling of things like the backups. I am wondering if it's simply better to leave the 3PAR getting hammered and live with the transient alerts.

Any advice appreciated.

thanks

1. I'm pretty sure your old rule doesn't work. I'm 99% certain 3PARdata is case sensitive. There was a typo in the implementation guide for one revision.

2. That shouldn't throttle backup.

MammaGutt wrote:1. I'm pretty sure your old rule doesn't work. I'm 99% certain 3PARdata is case sensitive. There was a typo in the implementation guide for one revision.



2. That shouldn't throttle backup.

Ok.

Believe it or not that's taken directly from the PDF so they're still putting the wrong stuff into the best practice guide in 2021..

I guess I was just trying to get more insight on the new rule and how it differs from the old round robin approach. With regard to the queue-full settings it's a similar story. There's not a lot of background information i can find on how setting these might impact performance or when it's appropriate to use them.

I'll plan to change the SATP rules first to the new throttle_ssl and policy=latency and observe the impact via Infosight.

However I can find ZERO information about what throttle_ssl actually does! (there's no mention of it at all in any documentation I've searched so far.


If we are still having issues I'll try setting the queue-full options.


I appreciate this is probably more a VMWARE-centric than 3PAR question.

thanks.
Adam.

adamdb wrote:

MammaGutt wrote:1. I'm pretty sure your old rule doesn't work. I'm 99% certain 3PARdata is case sensitive. There was a typo in the implementation guide for one revision.



2. That shouldn't throttle backup.

Ok.

Believe it or not that's taken directly from the PDF so they're still putting the wrong stuff into the best practice guide in 2021..

I guess I was just trying to get more insight on the new rule and how it differs from the old round robin approach. With regard to the queue-full settings it's a similar story. There's not a lot of background information i can find on how setting these might impact performance or when it's appropriate to use them.

I'll plan to change the SATP rules first to the new throttle_ssl and policy=latency and observe the impact via Infosight.

However I can find ZERO information about what throttle_ssl actually does! (there's no mention of it at all in any documentation I've searched so far.


If we are still having issues I'll try setting the queue-full options.


I appreciate this is probably more a VMWARE-centric than 3PAR question.

thanks.
Adam.

My guess when reading the rules… the old one is simple, change path for every IO. The new one is supposed to push less IO thru paths with higher latency, however I don’t understand the thresholds for that…. In other words I’m still doing iops=1 because if there are some paths with higher latency in my fabrics I want to understand why and don’t have the vmware hosts pushing different traffic thru different paths to make my troubleshooting worse

Exactly. It's not clear at all how this is meant to operate. I'm going to follow up with HPE as I've got a call open with an L2 for another issue. Hopefully they'll be able to shed some light on the way it's meant to operate.

I don't think we are at that level yet on our VMware boxes but I will need to check when they are thinking about it.

Before the rules added the RR iops=1 recommendation there was some card level feature 3PAR suggested that would back off paths if the qlen started to fill. We did consider this at the time for a similar effect but found that on qlogic cards the setting was global for all cards/ports. As we run a mix of storage/vendors the VMware team were concerned that the other targets might not like it so we never used it.

I wonder if this relates to the new active PP feature on Primera as well as a new card agnostic ESX feature similar to the above.

Keep us in the loop on how it goes.