On Mon, Aug 1, 2016 at 9:49 AM, Hannes Reinecke <hare@xxxxxxx> wrote:
On 07/31/2016 09:26 PM, Christophe Varoqui wrote:
Ben, Hannes,Well.
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
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.
The prio_args to prio mapping, wouldn't be nice though.
Concerning transports, we can also extend the weightedpath prioritizer, and if the multi-prioritizer setup is implemented we could even weight on serial+transport with a "prio weighedpath+weightedpath" setup.
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel