On 08/01/2016 10:42 AM, Christophe Varoqui wrote:
On Mon, Aug 1, 2016 at 9:49 AM, Hannes Reinecke <hare@xxxxxxx
<mailto:hare@xxxxxxx>> wrote:
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.
Would something like "prio alua+weightedpath" produce correct priorities
for the path grouping ? where priorities reported by alua would be added
to those reported by weighted path. That syntax extension would reduce
the need to develop more complex prioritizers.
Hmm.
Allowing stacked prioritizers is a nice idea.
But then we need to impose some preference here; if we do not set any
restrictions on the value of the prioritizers we end up with a jumble of
(essentially unreadable) priorities.
EG if your weightedpath returns values of '5' or '0' they'll be readily
obscured by alua information, which uses '5' for the non-optimized path.
So if we were to got that route we need to restrict the values of the
prioritizers to eg 256, and shift the stacked prioritizer values ontop
of each other.
EG with a stacked 'prio_alua+weightedpath' we should end up with a
priority of 0xAAWW.
With that we can allow up to 4 levels of stacking (or 8 if we extend
that to 64 bits), and still keep source-level compability with the
original code.
We could even reduce the permissive values for the prioritzers even
more; 16 is enough even for ALUA, and that would leave us with enough
room of 1024 possible stacking levels :-)
But in general I like the idea.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +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)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
