A brief write up of ALUA support for EMC VNX storage arrays being virtualized behind a Hitachi Data System enterprise platform.
Storage Management Partner Communities Software
Chris, I would really like to see this across 4 SP (storage processor ports) per configuration rather than 2. ALUA (failover mode 4) is the only mode where a VNX will accept I/O across non-owning SP ports, 2 is purely failover and 1 is just a SCSI not ready from the passive SP.. With the default queue used in UVM there is no way we would stress the link that providers the upper redirector. Without this stressed, all I/O will still be served from optimal paths (the owning SP) regardless of the frontent port. I've been working on EMC performance for a long and the distributions of optimal and sub-optimal paths can have a considerable impact. With some workloads ALUA can decrease performance particularly to storage pool LUNs.
Great points Cris! also in agreement that a 4 SP configuration would be the optimal approach to configuring external storage behind our arrays. The majority of POC's we do for customers aren't using the VNX as a performance tier so usually 2 paths have been sufficient to complete migration objectives while the other 2 paths are still being used by hosts.
The focus on this paper was to demonstrate that ALUA support was available now in the software and will look to expanding or creating additional documentation incorporating your request in the future.
Good point about customers not using VNX in the performance tier, but I'd imagine if engineering have made UVM ALUA compliant, the VNX is just one of many use case I understand this is probably a bigger picture item (scale-out UVM for distributed external LDEVs?), but ALUA support would affect previous and current generations of HDS block storage from midrange (AMS/HUS) and enterprise (HUSVM-Gx (until the SVOS merge)). More insight into into ALUA vs non-ALUA UVM performance would be useful.
Retrieving data ...