ALUA fundamental questions

[Brent Bolin]

Hello All,

Need to educate myself on some basic SAN topology architectures.  ALUA specifically I think?

When is ALUA used?.  Does it set a priority of use for targets that use the same LUN?

For example I have a dual port Qlogic card that I have setup for multipathing on a Solaris box(It's not dead just smells funny:)  -

Driver: qla2x00t

Target: 21:00:00:e0:8b:9e:f7:43

Assigned LUNs:

LUN  Device

------

0    0

1    1

2    2

3    3

4    4

5    5

6    6

7    7

8    8

9    9

Driver: qla2x00t

Target: 21:01:00:e0:8b:be:f7:43

Assigned LUNs:

LUN  Device

------

0    0

1    1

2    2

3    3

4    4

5    5

6    6

7    7

8    8

9    9

By default Solaris uses these in a round robin configuration.  And if I unplug one of the cables the LUN is still available.  In my case I have two FC cards in the Solaris box and dual channel on the target

[Marc Smith]

Hi Brent,

On Tue, Sep 22, 2015 at 10:30 AM, Brent Bolin <brent...@gmail.com> wrote:

Hello All,

Need to educate myself on some basic SAN topology architectures.  ALUA specifically I think?

When is ALUA used?.  Does it set a priority of use for targets that use the same LUN?

I'm definitely not a ALUA or mulitpathing expert, but I'll give it a shot. With SCST (in ESOS) we get "implicit ALUA". With implicit ALUA, SCST merely "advertises" information about the different paths to the initiators. You can setup these device groups and target groups to control which paths are advertised with different states (eg, active, nonoptimized, etc.). Its the up to the initiators to take this target path information and make a decision about where to send I/O. Different initiators handle this in their own sometimes unique way. Many initiators allow you to choose different "path policies" (eg, fixed, round-robin, etc.). They also might handle the ALUA states differently from each other.

For the storage array setups that I've designed and used, I only use ALUA in ESOS when I have a cluster (a dual-head setup). This way I can control the ALUA state for the two different machines through the cluster stack (Pacemaker/Corosync).

For a single-head ESOS storage array, I think in most cases ALUA doesn't make sense or isn't needed. You can always safely round-robin between target interfaces from the same ESOS box since the target interfaces are on the same SCST instance and it handles SCSI reservations, persistent reservations, etc. internally. That being said, there may be reasons to use ALUA for a single-head setup... the first use case that comes to my mind is if you have an ESOS box with a 4 Gb FC HBA and an 8 Gb FC HBA and maybe you only want I/O on the 8 Gb interface. You could set the ALUA configuration so the 8 Gb interface is preferred over the 4 Gb interface.

This should be fine for a single-head solution. You're utilizing multiple paths, and if a FC switch goes does, or you pull a cable, the initiators should receive an RSCN and they will know the paths are down (offline) and only utilize the standing paths.

Hope this helps. Let us know if you have any other questions.

--Marc

--
You received this message because you are subscribed to the Google Groups "esos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esos-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marc Smith]

Oddly enough, I just saw a post on the scst-devel list about ALUA and the behavior is a bit different now (since I educated myself on SCST's ALUA back in 2013): SCST does in fact reject write operations for ports that are in the unavailable/offline states: http://sourceforge.net/p/scst/svn/4848

Kristian and I are working on modifying ESOS's SCST RA to use the offline ALUA state when a node is down (well, SCST). This makes me much more confident in this approach and also explains the results Kristian observed.

--Marc