[dm-devel] [PATCH v4 0/1] multipath-tools: Prioritizer based on a latency algorithm

[Hannes Reinecke]

On 06/06/2017 04:43 AM, Yang Feng wrote:
> This patch value is in the following: 
> 1. In the Storage-Backup environment of HyperCluster, includes
> one storage array near to the host and one remote storage array,
> and the two storage arrays have the same hardware.The same LUN is
> writed or readed by the two storage arrays. However, usually, the
> average latency of the paths of the remote storage array is much 
> higher than the near storage array's. Apparently, the prioritizer
> can be a good automatic solution. And the current selectors don't
> solve it, IOs will send to the paths of the remote storage array,
> IOPS will be influenced unavoidably.
> 
Actually, you're not alone here; several other storage array setups
suffer from the same problem.

Eg if you have a site-failover setup with two storage arrays at
different locations the problem is more-or-less the same;
both arrays potentially will be displaying identical priority
information, despite one array being remote.

Similarly, if you have a failover scenario where the individual paths
are accessed via different protocols you're facing the same problem.

The underlying reason for this difficulty is the two-stage topology of
the current multipath implementation:

- Each path is grouped into a path group
- Priorities are attached to a path group
- Each path group belongs to a multipath device

And as we only have a _single_ prioritizer per path we cannot easily
handle this situation.

Ideally we should be able to 'stack' prioritizers, which would work by
combining the priority numbers from the stacked/combined prioritizers.

But that would be requiring quite some rework, of course.

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)