[dm-devel] [RFC] [PATCH] add serial keyword to the weightedpath prioritizer
Hannes Reinecke
hare at suse.de
Mon Aug 1 07:49:32 UTC 2016
On 07/31/2016 09:26 PM, Christophe Varoqui wrote:
> Ben, Hannes,
>
> Can you review this patch, adding a new 'serial' keyword to the
> weightedpath prioritizer.
>
> I compile-tested it only, as I have no testing environment at hand at
> the moment.
>
> I commited it in a separate 'weightedpath-serial' branch for now.
>
> http://git.opensvc.com/?p=multipath-tools/.git;a=commitdiff;h=4dd16d99281104fc3504ad73626894a5c3702fb3
>
> Thanks,
> Christophe Varoqui
> OpenSVC
>
Well.
In general, sure, fine, I don't have any issues with that.
If the customer wants to diddle with his array that way...
The more general problem I'm seeing is that our current two-layered
priority setup (path groups with distinct priorities and paths within
them) might not be leading to issues with larger and more complex scenarios.
ATM we already have the problem that clustered scenarios like this:
Storage node 1(active):
Path 1 (optimal):
LUN 1, LUN2
Path 2 (non-optimal):
LUN 1, LUN2
Storage node 2(passive):
Path 1(optimal):
LUN 1, LUN2
Path 2(non-optimal):
LUN 1, LUN2
can not be represented properly with multipath tools.
We are forced to either
a) set 'storage node 2' to 'failed', which would kill
any cluster instance accessing only 'storage node 2'
or
b) map all priorities from 'storage node 2' to '0',
thereby losing all priority information
Things become even more convoluted if both storage nodes are in fact
accessible, or if someone would be using different transports.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare at suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
More information about the dm-devel
mailing list