* 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"
}
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?
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.
Regards,
--
Tore Anderson
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
