[dm-devel] Active/backup multipath configuration for iSCSI paths
Alexander Murashkin
AlexanderMurashkin at msn.com
Wed Mar 28 08:52:09 UTC 2012
On 03/23/2012 02:41 PM, Hart, Brian R. wrote:
(https://www.redhat.com/archives/dm-devel/2012-March/msg00155.html)
> We have a couple of Dell MD storage arrays that when installed
> setup multipath.conf to use this line: prio_callout
> "/sbin/mpath_prio_rdac /dev/%n"
On 03/23/2012 02:41 PM, Bryn M. Reeves wrote:
(https://www.redhat.com/archives/dm-devel/2012-March/msg00155.html)
>Callouts make life difficult when file systems go away so like the
>path checkers before them they were merged into the libmultipath
>shared library. This means that the daemon can lock them into memory
>via mlock(2)/mlockall(2) and not have to worry about being able to
>load a binary from disk when the paths to that storage have failed -
>this is very useful if your root file system is on multipath and you
>need to recover from a failure.
>
>In RHEL5 this is dealt with using a complex and fragile private
>namespace and RAM-backed file system - the required binaries are
>copied into this ramfs at daemon startup and the daemon unmounts
>unnecessary file systems to avoid blocking when failures occur.
>
>For this reason the parameter is now just "prio", e.g.:
>
>device {
.
> prio rdac
>}
I can see that using shared libraries to handle priorities makes handling
failed paths easier in many situations. But how to configure active/backup
multipath in the following case, for example
- 1st path uses iSCSI over Infiniband
- 2nd path used iSCSI over Gigabit Ethernet
- iSCSI target does not support ALUA
- we want Infiniband path to have higher priority
Will it be enough to set path_grouping_policy = multibus and path_selector
= "service-time 0"? Will Gigabit Ethernet path be never used as long as
Infiniband path is working?
I appreciate your help,
Alexander Murashkin
Email: AlexanderMurashkin at msn.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20120328/4a98fe85/attachment.htm>
More information about the dm-devel
mailing list