Primary Storage

 View Only

Demystifying Asymmetric Logical Unit Access with IBM FlashSystem

By Mangesh Shirke posted Mon April 19, 2021 12:05 PM

  

Asymmetric Logical Unit Access (ALUA) framework enables storage systems to allow the host multipath driver to understand the preferred paths, and thereby reduce the I/O latency.

 

People sometimes mistakenly see ALUA as an active-passive storage behavior. IBM FlashSystem® built using IBM Spectrum® Virtualize, however, uses ALUA algorithm and is an active-active storage system.

 

Working with IBM Spectrum Virtualize active-active architecture, I’ve found enabling or disabling ALUA does not change the inherent active-active storage architecture. What’s more, it shows the way the read/write IO is processed for both ALUA and non-ALUA configuration. The workload and the performance numbers shown below showcase the performance difference between ALUA and non-ALUA configuration. Actual performance number may vary according to storage configuration and other environmental variables.

 

A single IBM FlashSystem control enclosure consists of two identical node canisters, that form an I/O group. The FlashSystem allows access to a volume from any of these nodes in the I/O group. When a volume is created, however, one of the nodes is defined as the preferred node for that specific volume. The host then uses ALUA-based multipathing to direct the I/O to the preferred node. Preferred node setting in IBM Spectrum Virtualize storage defines the optimized path for a particular LUN/volume. Optimized path indicates that this path can give optimal performance for the LUN/volume by referencing the cache of the preferred node.

 

Any write IO to a volume is mirrored across the cache of the two nodes, before the host receives a write completion acknowledgment. On the other hand, read IO is processed by referencing the cache in the node that serves the I/O. If the data is not found in the cache, the same is fetched from the disk to the cache. The read cache therefore can provide better performance if the same node is chosen to service I/O to a particular volume. This is where the benefits of the ALUA algorithm come into play. ALUA always redirects IOPS to the node that holds cache for that volume. Data available in cache will thus be returned from cache. If ALUA is not used or is disabled, then the host can send IOPS to any node. If the request is received by the node that does not have the requested data in cache, it will have to fetch the data from the underlying disk and thus will increase the response time. This can be avoided by routing the request to a node that is more likely to have the data in cache. The preferred node and optimized path thus help enhance the cache availability for the read IOs, and in turn enhances the overall performance.

 

Below is the illustration of the IO path when ALUA is used and when it is not used:

 

The performance benefit in the response time can be seen from the statistics I captured while testing the workload with ALUA enabled and later with ALUA disabled.

 

ALUA Status

ALUA=Enable

ALUA=Disable

Performance Test Case

IOPS=300000
Read/Write ratio=85/15
Transfer Size=16K
Random=100%

IOPS=300000
Read/Write ratio=95/5
Transfer Size=16K
Random=100%

IOPS=300000
Read/Write ratio=85/15
Transfer Size=16K
Random=100%

IOPS=300000
Read/Write ratio=95/5
Transfer Size=16K
Random=100%

Average Storage CPU Utilization

36%

22%

39%

39%

Average Read Response time

0.5 ms

0.55 ms

0.85 ms

0.85 ms

Average Write Response time

0.52 ms

0.52 ms

0.52 ms

0.52 ms

 

Note:

  • This performance numbers are only for representation and showcasing performance difference between ALUA and non-ALUA configuration.
  • These tests were carried out in controlled environment with limited resources. Actual performance number may vary depending on available resources and other environmental variables.

 

Read response time clearly increases when ALUA is disabled.

 

IBM FlashSystem is ALUA complaint and ALUA is by default enabled. Various operating systems provides the capability to disable ALUA in case of a special need. Disabling ALUA on the host is however not recommended. Below is a depiction of how it can be disabled on various operating systems to meet any special requirements:  

 

  1. Solaris hosts:
  • Edit “/etc/driver/drv/scsi_vhci.conf” file and add line as shown in below snapshot.

  • On Solaris 9, reboot the host.
  • On Solaris 10, run “stmsboot -u”

  1. Linux hosts:
  • Edit “/etc/multipath.conf” file.
  • Replace `prio “alua”` with `prio “const”`.
  • Restart server or multipath deamon.

 

  1. VMware hosts:
  • Run command as shown in below snapshot and reboot the ESXi host.

 

 

Overall, ALUA provides a framework to understand the preferred paths and optimize the IO response time. This does not change the inherent active-active architecture of the storage in any way. Using ALUA wherever the host operating system supports it clearly enhances the performance of IBM FlashSystem.

 

Reach out to us for questions and support

Additional information about IBM FlashSystem can be found in the IBM Documentation link. To learn more about IBM Storage offerings and solutions support, reach out to Lab Services Storage team. The Lab Services Storage team has helped clients around the world efficiently capture, deliver, manage and protect data with superior performance.

0 comments
594 views

Permalink