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@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
