Phew, now that we got through the sections on AQDA and SIOC we can talk a little bit about the FlashArray and why those distinctions above were necessary!
Before we go into discussions about this I want to make a quick clarification about the two different types of QoS that are available on the FlashArray:
- QoS Fairness (Always on QoS) – Array wide setting that ensures the FlashArray itself is not overrun by all attached hosts / initiators. This isn’t configured by end-users and is simply “Always On” as the name indicates.
- QoS Rate Limiting – This is configurable by end-users and is enabled on individual volumes or volume groups. Depending on the version of Purity these restrictions can be set based on bandwidth or IOPs limits.
We will be specifically referring to QoS Rate Limiting here but some of the concepts will apply to both. If you are new to this QoS rate limiting, and want to learn more, you can read Quality of Service Rate Limiting FAQ for additional information.
When a bandwidth or IOPs limitation is set on a FlashArray volume or volume group, it is up to the FlashArray to enforce and inform the connected host(s) that a limitation has been reached.
So how does the FlashArray do that? Well, it does it the way we discussed up above in the adaptive queue depth section, by sending SCSI code 0x28 (TASK_SET_FULL) responses to the host(s) to inform it that a limitation has been reached. The FlashArray continues to send these responses as long as the host(s) attempting to send I/O are surpassing the desired limitation.
One of the challenges here, specifically for VMFS datastores, is that the FlashArray has absolutely no way to specify which VMs or I/O requests should be prioritized over another. This is because the FlashArray has no real insight into that VMFS datastore and thus no way to make an educated decision on what should have priority. In this sense, the I/O is going to be processed in the “first come, first serve” mind set and simply process what it can and reject the rest with the TASK_SET_FULL response so the host can retry the request. This means it would be up to the initiator (host) sending the data to determine what should be processed first and send that data accordingly.
With vVols, QoS on the FlashArray is more granular and simplistic in theory. Since each VMDK is a standalone volume on the FlashArray, you can not only determine which VMs should be throttled, but you can even determine which VMDK(s) you want throttled for specific VMs. This can be done by setting the individual volume restrictions (VMDK level) or setting vgroup restrictions (VM level) depending on the level of granularity you need.