We have learnt from the previous section that there are different types of arrays not just based on the protocol they support but also the type of load balancing and failover they support.
In a symmetric active/active array, there is no concept of a standby controller.
Design Tip: When designing a storage architecture with a symmetric active/active array, you can choose different preferred paths on different sets of ESXi hosts in a cluster/data center. For instance, if you have a 10 hosts cluster, then you could set five hosts to use a preferred path via controller-1 and a second set of five hosts to use a preferred path via controller-2. This is done to achieve I/O processing load distribution at the controller level.
Active/passive arrays will have active and standby storage controllers. A controller is referred to as active or passive relative to the LUNs they own. In an active/passive array an I/O to a set of LUNs can only be processed by a storage controller that owns them. The controller that owns a set of LUNs is referred to as an active controller for those LUNs:
For instance, there are two LUNs created on an active/passive array with storage controllers SPA and SPB. SPA has been configured to own LUN A and SPB to own LUN B. Here SPA becomes an active and SPB becomes a passive controller for LUNs A. In the same manner, SPB becomes an Active and SPA becomes a passive controller for LUN B.
The Asymmetric Logical Unit Access (ALUA) array is a type of active/active array, which has the ability to concurrently use all its controllers to process I/O and also stand-in as failover partners of each other.
Much like in an active/passive array, a LUN or a set of LUNs can only be owned by a single controller. The owning controller will have symmetric (direct) access to the LUN, hence offering the best performance. The non-owning controller can process the I/O indirectly (asymmetric) for the LUN by transferring the I/O via the interconnect to the owning controller. Hence, there is a performance hit owing to time required to transfer the I/O to the owning controller.
Since the array presents a way to directly and indirectly process I/O for the LUNs presented, there has to be a way to let ESXi know about the direct and indirect paths to the LUN. This is achieved by an array feature called the TPGS (Target Port Groups). TPGS groups direct and indirect paths to a LUN separately. ESXi sees them as Active (Optimized) and Active (non-optimized) paths to the LUN. The active (non-optimized) storage controller ports could be active (optimized) ports for another set of LUN. ESXi will always place the I/O on the Active (optimized) paths:
If you were to have an array configured as shown in the above diagram, then an I/O for LUN-A if issued via the controller CNTL-B, would result in CNTL-B passing the traffic via the interconnect to controller CNTL-A which would then process the I/O. This alternative path will be referred to as an active non-optimized path.
3.143.214.230