…I shoot on Twitter: Can anyone cite me an Active/Active storage array that supports ALUA?
An important information is missing from my question. Precisely I’m talking about symmetric storage arrays. So let me rephrase my question to: Can anyone cite me a symmetric Active/Active storage array that supports ALUA?
No need to say that I’ve been flamed down with harsh tweets and DM’s.
Do you know what the A stands for in ALUA?… Your question is plain wrong… It is not necessary with symmetric arrays… It has nothing to do with symmetric arrays… You don’t understand the basics… Etc.
OK guys maybe my question is dumb but once again…are you sure it *really* is?
You can read on or jump at the end of this article to immediately find out if I was soooo wrong with my dumb question 🙂
When I wrote VMware PSA, MPP, NMP, PSP, MRU, … And Tutti Quanti! and Aloha ALUA I did a lot of research, read a lot of documents and more I was digging in more questions popped out than answers. There is so much to learn about SCSI protocol, storage arrays in general and ALUA in particular.
So people let’s go back to the SPC-3 standards draft, The latest draft known at T10.org is the spc3r23.pdf but is not available for free unfortunately. Hopefully you can find a copy at 13thmonkey.org.
Let’s have a look at chapters 5.7 up to 5.8.3 for the rest of this post. I’ll be doing here a lot of copy/paste because I want to stick to the SPC-3 standards draft as much as I can. I’ll be pasting diagrams as well and sometime I have added in red my own annotations. I’m not assuming anything, the information given here are written black and white in the latest SPC-3 standards draft.
5.7 Multiple target port and initiator port behavior
SAM-3 specifies the behavior of logical units being accessed by application clients through more than one initiator port and/or through more than one target port…
If one target port is being used by an initiator port, accesses attempted through other target port(s) may:
a) Receive a status of BUSY; or
b) Be accepted as if the other target port(s) were not in use.
5.8.1 Target port group access overview
Logical units may be connected to the service delivery subsystem via multiple target ports (see SAM-3). The access to logical units through the multiple target ports may be symmetrical (see 5.8.3) or asymmetrical (see 5.8.2).
5.8.2.1 Introduction to asymmetric logical unit access
Asymmetric logical unit access occurs when the access characteristics of one port may differ from those of another port. SCSI target devices with target ports implemented in separate physical units may need to designate differing levels of access for the target ports associated with each logical unit.
5.8.2.3 Discovery of asymmetric logical unit access behavior
SCSI logical units with asymmetric logical unit access may be identified using the INQUIRY command. The value in the target port group support (TPGS) field (see 6.4.2) indicates whether or not the logical unit supports asymmetric logical unit access and if so whether implicit or explicit management is supported.
5.8.2.4.1 Target port asymmetric access states overview
For all SCSI target devices that report in the INQUIRY data that they support asymmetric logical unit access, all of the target ports in a target port group shall be in the same target port asymmetric access state with respect to the ability to route information to a logical unit. The target port asymmetric access states are:
a) Active/optimized;
b) Active/non-optimized;
c) Standby; and
d) Unavailable.
5.8.2.6 Preference Indicator
A device server may indicate one or more target port groups is a preferred target port group for accessing a logical unit by setting the PREF bit to one in the target port group descriptor (see 6.25). The preference indication is independent of the asymmetric access state. An application client may use the PREF bit value in the target port group descriptor to influence the path selected to a logical unit (e.g., a target port group in the standby target port asymmetric access state with the PREF bit set to one may be chosen over a target port group in the active/optimized target port asymmetric access state with the PREF bit set to zero). The value of the PREF bit for a target port group may change whenever an asymmetric access state changes.
5.8.2.7 Implicit asymmetric logical units access management
SCSI target devices with implicit asymmetric logical units access management are capable of setting the target port group asymmetric access state of each target port group using mechanisms other than the SET TARGET PORT GROUPS command.
All logical units that report in the standard INQUIRY data (see 6.4.2) that they support asymmetric logical units access and support implicit asymmetric logical unit access (i.e., the TPGS field contains 01b or 11b) shall:
a) Implement the INQUIRY command Device Identification VPD page identifier types 4h (see 7.6.3.7) and 5h (see 7.6.3.8); and
b) Support the REPORT TARGET PORT GROUPS command as described in 6.25.
5.8.2.8 Explicit asymmetric logical units access management
All logical units that report in the standard INQUIRY data (see 6.4.2) that they support asymmetric logical units access and support explicit asymmetric logical unit access (i.e., the TPGS field contains 10b or 11b) shall:
a) Implement the INQUIRY command Device Identification VPD page (see 7.6.3) identifier types 4h and 5h;
b) Support the REPORT TARGET PORT GROUPS command as described in 6.25; and
c) Support the SET TARGET PORT GROUPS command as described in 6.31.
I kept the best part for the end, hoping you’re still reading 🙂
5.8.3 Symmetric logical unit access
A device server that provides symmetrical access to a logical unit may use a subset of the asymmetrical logical access features (see 5.8.2) to indicate this ability to an application client, providing an application client a common set of commands to determine how to manage target port access to a logical unit. Symmetrical logical unit access should be represented as follows:
a) The TPGS field in the standard INQUIRY data (see 6.4.2) indicates that implicit asymmetric access is supported;
b) The REPORT TARGET PORT GROUPS command is supported; and
c) The REPORT TARGET PORT GROUPS parameter data indicates that the same state (e.g., active/optimized state) is in effect for all target port groups.
SO YES A SYMMETRIC ACTIVE/ACTIVE STORAGE ARRAY MAY USE A SUBSET OF THE ASYMMETRICAL LOGICAL ACCESS FEATURES!
This statement written in the latest draft of the SPC-3 standards document surprised me as well and that’s why I shoot this question: Can anyone cite me a symmetric Active/Active storage array that supports ALUA?
3PAR does apparently! Thx for the info @mcowger. Who else does?
But this statement raises others questions as well:
-What’s the benefit of ALUA with symmetric arrays?
-What are those ‘application clients’ the document is referring to?
-How does a real life implementation of a symmetric array using ALUA’ subset commands look like?
If you have some answers for me to these questions please comment! I’m dying to know 🙂
DeinosCloud 
Just guessing here but I think ALUA functionality on symmetric arrays is used to load balance san clients that do not support load balancing accross paths themselves. For example: If ESX where set to use the MRU policy on a symmetric array then all ESX servers in the cluster would use the first availeble port on the array which could cause overloading the port. If the array sets the preffered field on a different port for each client that would create some sort of load balancing accross the ports.
Hi Chris and thx for your comment,
Interesting point. As the draft says: an application client may use the PREF bit value in the target port group descriptor to influence the path selected to a logical unit…
BTW I like your article about ‘Routing your storage traffic?’. Very interesting.
You’re still not getting the point.
If something is implemented doesn’t necessarily mean that it’s useful, as I said on twitter if you’re advertising all the paths as optimized there’s no point in using ALUA that, as the name implies, was intended for asymmetric arrays.
You said that you were not sharing my opinion, and when I asked you to share yours you simply neglected to do so and this post shows that you still haven’t one.
You refer to yourself as being ‘wise’, while others are ‘fools’ but in your wisdom you’re asking yourself the wrong questions and not accepting the logical answers, this is like putting a bandaid on a wooden leg.
Hi Fabio and thx for your comment.
>If something is implemented doesn’t necessarily mean that it’s useful
True and this statement can be applied to many situation. Does it apply here?, not sure…
>if you’re advertising all the paths as optimized there’s no point
>in using ALUA that,as the name implies, was intended for asymmetric
>arrays.
The draft says: “to indicate this ability to an application client, providing an application client a common set of commands to determine how to manage target port access to a logical unit.”
It’s all about the application clients that need this ability and to somehow manage it.
>You said that you were not sharing my opinion, and when I asked you to
>share yours you simply neglected to do so and this post shows that you
>still haven’t one.
As I told you I don’t share your opinion on ‘there’s no point in using that IMO’.
My opinion is if that feature exists there must be a use case…
Apparently one of the use cases would be in mixed environments where you have both symmetric and asymmetric arrays. (dixit @mcowger)
But I haven’t experienced that myself. Is there another use case? Personally I don’t know, does anyone else know?
And again don’t focus on my last sentence, just overlook it.
Rgds,
This is my last comment on this, I’m not sure if you’re not understanding this on purpose or my english is really that bad.
1st point –
If something is useful you don’t have to dig the abyss to find what it is useful for, hence in this case ALUA is not useful.
2nd point –
You’re focusing on what the paper says about this feature, try to focus on what the feature does and how can be applicable in the real world.
3rd point –
Matt (@mcowger) said “it’s unneeded, but useful in mixed envs where you have both symm and asymmetric arrays.”
I don’t know what he was referring to, because this was his last reply on the topic, can you justify his claim?
By the way, John (@vTrooper) who initially backed your claims, in the end, reached the same conclusion, that using ALUA with a true symmetric A/A array is pointless, this is his tweet: http://twitter.com/#!/vTrooper/status/87601046746177536
I can give you another example of pointless stuff implemented in the storage world:
On the HDS’ old AMS line (200,500,1000) there was an option to modify the PID (product ID) of the storage system, which was by default set to ‘DF600F’ (codename of the old Thunder 95xx line) you could have changed it to ‘DF700’ (codename of the old AMS line) but all the multipath software (both HDLM and those bundled with the OS) would stop working because they recognized DF600F as their only supported string.
Was that implemented? Yes.
Was that useful? Nope.
Was that a pointless feature? Yes it was.
By the way, ALUA is not a pointless feature per se, it is actually a HUGE feature for Asymmetric A/A arrays, and definitely one of my favorite. Is it useful in the symmetric A/A world? I don’t think so.
Hi Diedier,
Based on Fabio’s reply and I agree with him, what is it that you are actually looking for and not getting? As he clearly said: “If something is implemented doesn’t necessarily mean that it’s useful” and I strongly believe he’s right with that.
Didier, first of all, if you are asking people to just overlook your last sentence, you shouldn’t have put it there in the first place, but that is an entirely different story.
I also commented on Twitter this morning and pointed to the standard. Now, after reading what you wrote, and looking at the final draft, I have a couple of scenarios that go through my mind which might give you an idea of what a use case might look like.
Disclaimer: None of this is real (as far as I know), but I’m just playing along to give you some food for thought.
First of all, the idea comes to mind that this might allow you to for example use ports with different speeds, and put a QoS on the aggregated links. If you would do this for the individual links, you would not have the guarantee that if a link drops, the remaning link(s) would have enough capacity/bandwidth available.
A second idea would be to find an active/active array that can scale out via nodes, and that perhaps might be able to offer multiple tiers within the array. So perhaps still be an active/active array, but have individual nodes boot in an active/passive mode so that I am able to offer tiers within an array type.
The main question is if you want to do things like that. I’m sure there are some ways in which you can leverage this technology. The same can be said about a Bugatti Veyron. It has technology on board that is designed to allow you to go 430 km/h, but which no-one ever uses in everyday life.
The comparison with the Bugatti limps, but it’s the same idea. I’m sure there are possible theoretical uses, and I can come up with models like the ones I mentioned. But sometimes, a technology is there just because it suits the model. In this case, the model is having a standard to communicate differences in port and line specs, but most active/active array vendors just chose to use the same specs for all interfaces to their array.
And I hope this answer is respectful enough to you, even though I might still be the fool. 😉
Hi Bas and thx for your comment,
Great brainstorming here. I appreciate that you went on, read the paper, and came back with food for thought, that’s great 😉
Regarding you main question, indeed I guess that 99,9% of the use cases don’t need this. I don’t want to do something like that. I would prefer to stick with a simple setup. Now as this possibility exists, I just wanted to know more about it and your two ideas are very interesting, thx for that.
Oh my god, i’m so focused on your last sentence…….
Pingback: Seeing a High Number of Trespasses from a CLARiiON Array with ESX Hosts | | VirtualaholicsVirtualaholics
Pingback: VMW_PSP_FIXED vs. VMW_PSP_FIXED_AP | VirtuallyHyperVirtuallyHyper
Hi didier.
Sorry for the lateness, but I discovered this post a few days ago.
I’m dealing with documenting how a new virtualization feature works for a Symmetric Active/Active array works (Hitachi VSP G1000)
I was given a procedure that in inspite of being somewhat sketchy , worked.
Nevertheless the pieces didn’t seem to make any sense.
Why should one must activate ALUA in a Symmetric Active/Active Array.
What if I tell you that if you virtualize both of those VSP G1000 and show two of their disks (each belonging to a different array) as they were just one, the client software (a MULTIPATH) would
like to know which of the ports lead to the array which lies in the same data center as the client host and which ones lead you to the array which belongs to the remote site…
Yet the question is not as simle as that…more on that later, as soon as (hopefully) I finish the documentantio.
But Fabio has been >edited<.
You were righ, do you imagine a set of engineers imlplementing features and standards documenting them just out of fun?
"Hey lets implement some wacko feature so some computer nerds feels both amazement and frustration on equal amounts!!! … No way!!!
Take a peep to your linkedin.
Hi Gorka,
Thank you for your comment.
Sounds like you have a ‘use case’ there !
Now that you’ve teased me I want to know more 🙂
Come back as soon you’ve finished your documentation.
Cheers,
Didier