Asymmetric Logical Unit Access (ALUA) routes I/O of the LUN directed to non-active/failed storage processor to the active storage processor without changing the ownership of the LUN.
Each LUN has two types of paths:
Active/optimized paths are direct paths to the storage processor that owns the LUN.
Active/optimized paths are usually the optimal path and provide higher bandwidth than active/non-optimized paths.
Active/non-optimized paths are indirect paths to the storage processor that does not own the LUN through an interconnect bus.
I/Os that traverse through the active/non-optimized paths must be transferred to the storage processor that owns the LUN. This transfer increases latency and has an impact on the array.
Metro node detects the different path types and performs round robin load balancing across the active/optimized paths.
Metro node supports all three flavors of ALUA on backend arrays:
Explicit ALUA - The storage processor changes the state of paths in response to commands (for example, the Set Target Port Groups command) from the host (the metro node backend).
The storage processor must be explicitly instructed to change a path’s state.
If the active/optimized path fails, metro node issues the instruction to transition the active/non-optimized path to active/optimized.
There is no need to failover the LUN.
The storage processor can change the state of a path without any command from the host (the metro node back end).
If the controller that owns the LUN fails, the array changes the state of the active/non-optimized path to active/optimized and fails over the LUN from the failed controller.
On the next I/O, after changing the path’s state, the storage processor returns a Unit Attention “Asymmetric Access State Changed” to the host (the metro node backend).
Metro node then re-discovers all the paths to get the updated access states.
- Implicit/explicit ALUA - Either the host or the array can initiate the access state change.
Storage processors support implicit only, explicit only, or both.