Hi Tore,
On Fri, May 23, 2008 at 10:00:15AM +0200, Tore Anderson wrote:
> * Hannes Reinecke
>
> > No. Alua is completely different. You have to use
> >
> > prio_callout "/sbin/mpath_prio_alua /dev/%n"
> >
> > for this.
> > Although the normal EMC configuration continues to work, too.
> > And also note that you have to change the failover mode
> > to '4' to enable ALUA on the Clariion.
>
> Hmm, interesting. Apologies if I've been spreading misinformation!
>
> Now you made me curious. How does using an array (in ALUA failover mode
> 4) with my configuration:
>
> device {
> vendor DGC
> product *
> product_blacklist LUNZ
> path_grouping_policy group_by_prio
> path_checker tur
> no_path_retry queue
> prio_callout "/sbin/mpath_prio_emc /dev/%n"
> failback immediate
> }
>
> differ from using the ALUA specific code in multipath-tools? I believe
> it would look something like this?
>
> device {
> vendor DGC
> product *
> product_blacklist LUNZ
> path_grouping_policy group_by_prio
> path_checker tur
> no_path_retry queue
> prio_callout "/sbin/mpath_prio_alua /dev/%n"
> failback immediate
> hardware_handler "1 alua"
> }
>
Yes, this looks about okay.
> I assume the ALUA bits are able to explicitly tell the CLARiiON to
> transfer volume ownership from one controller to another (something I
> don't think is desired in clustered environments anyway - the array
> should have a better understanding of the optimal location of the volume
> than the hosts, who could be in disagreement and end up moving the
> volume back and forth), but what other differences are there?
>
In moving the assignment to another controller you will have a more
efficient I/O throughput, as in general the internal link between those
two controller isn't the fastest. So you really want to move the
LUN to that controller which should handle the I/O.
(Remember, the original EMC failover couldn't even handle I/O on
the non-active controller ...)
And for ALUA support in general this is just a standardized method of
signalling the required failover/multipath support mode to the initiator.
You can map just about any existing failover method on ALUA modes,
so in principle every IHV can update their firmware to support ALUA.
And most vendors already did so. Funnily enough, none of those chose
to implement the _exact_ modes the original firmware supported.
With EMC we suddenly can do I/O on the secondary path, the active/active
HP boxes suddenly have optimal and non/optimal paths, the old HP
MSA firmware starts do do I/O on their standby path, too, etc.
Bit of a shame, really. I was really curious how ALUA paths in 'standby'
mode would be reacting ...
> I'm speaking strictly from a user's point of view here - the differences
> "under the hood" isn't that interesting to me as long as it ends up
> working the same way and in an equally reliable manner.
>
Well, the big advantage of the ALUA support in the EMC is that even the
secondary path will function, albeit slower. Hence you wouldn't get
the I/O errors during boot anymore.
HTH,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N�g
GF: Markus Rex, HRB 16746 (AG N�g)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
