We discussed vSphere 6 VVOLs (Virtual Volumes) on this month’s GreyBeardsonStorage (GBoS) podcast with Howard Marks (@DeepStorageNet) and Satyam Vaghani (@SatyamVaghani, “Father of VVOLs”, CoFounder & CTO of PernixData).
VVOLs queue depth problem?
One performance problem from my perspective is that all VVOL FC IO is now funeled through a single Protocol Endpoint (PE) LUN for a single storage system. There may be some potential queue depth issues, but Satyam and Howard both said that queue depths have been greatly increased over the last decade or so and this shouldn’t be a problem, as long as you’re configured properly.
What about VVOL PEs on ALUA storage?
In an ALUA (Asymmetrical Logical Unit Access) Active/Passive, dual controller storage system, a set of LUNs is assigned to one controller, the “active” side of an Active/Passive ALUA storage system. Many ALUA vendors now support “Active/Active” configurations such that 1/2 the LUNs are assigned to one side and the other 1/2 assigned to the other sider, for an Active/Passive & Passive/Active pair or Active/Active configuration.
So, ALUA storage systems have a LUN “allegiance” to a controller. If this continues to be the case under VVOLs, then a PE would only be processed by one side of an ALUA dual controller system, effectively reducing the horse power to process VVOL IO to 1/2 of an ALUA storage system.
Now just because there is a LUN allegiance in ALUA storage doesn’t necessarily mean that all internal IO processing for a LUN is done on only one controller. But historically that has been the case. For instance, during an ALUA system non-disruptive code update, an “active” ALUA side must “failover” its LUNs to the other side to provide continuous IO activity, while the formerly active ALUA side taken down and updated with new code.
Potential solutions to ALUA PE performance?
One way to get around the VVOL ALUA performance problem is to have multiple PEs in a single storage system for the same vSphere Cluster VVOLs. I don’t know anything that would inhibit a storage system from supporting multiple PEs today, they already need to support multiple PEs for multiple vSphere clusters. Also, a VMware vSphere cluster must support multiple PEs for multiple storage systems.
I am also not aware of any VASA 2.0 requirement that restricts the number of PEs for a storage system’s support of a single vSphere cluster. But I could be mistaken here. So there should be nothing to inhibit multiple PEs from the same ALUA storage system to the same vSphere cluster.
Of course, this means an ALUA storage VVOLs would need to be divided across ALUA PEs.
Another solution is to eliminate any LUN allegiance for ALUA controllers. This requires shared memory between controllers to hold IO state and this is what non-ALUA storage does already.
~~~~
It’s just like Howard said on the GBoS podcast, “there’s going to be good and bad implementations of VVOLs” and telling the difference between the two will need to be done.
Comments?
Photo Credit(s): Passport Please by Oren Levine
Ray
My assumption was always that VVOLs were implemented at dependent LUNs within the existing SCSI protocol. I asked the question on bottlenecks 2.5 years ago on a VMware blog post from Cormac Hogan (see here http://blogs.vmware.com/vsphere/2012/10/virtual-v… however I was told quite explicitly that “I/O doesn’t flow through the PE”. Seems that was wrong and certain VMware folks were giving out false information.
So, the issue here is not really one of queue depths; it’s one of queue management. Today we know that enterprise arrays will optimise the data stream on a shared FEP to clear off I/Os as fast as possible. In the future this will need to be done for QoS purposes, which conflicts with keeping the queues optimised. This is where I see the most important part of VVOL implementations, efficiency FEP queue management.
Cheers
Chris
Chris,
Thanks for the comment. Yes the queue management issues for VVOLS is sort of an internal storage subsystem problem but could present some interesting impacts to the unwary. Rgds, Ray