[dm-devel] Powerpath vs dm-multipath - two points of FUD?

[Bryn M. Reeves]

On Tue, Sep 09, 2014 at 05:50:49PM +0100, Rob wrote:
> Firstly, apologies if this is a common topic and my intentions are not to
> start a flame war. I've googled extensively but haven't found specific
> information to address my queries, so I thought I would turn here.

Dr. Freeman, I presume? ;)
 
> *Here’s a couple of reasons to stick with powerpath:* Load
> Balancing: Whilst dm-multipath can make use of more than one of the paths
> to an array, .i.e with round-robin, this isn’t true load-balancing.

Hasn't been true since RHEL5. RHEL6's kernel has request-based
device-mapper and the SCSI device_handler infrastructure which allows
the dm-multipath target to make better decisions in response to device
utilisation and error conditions. In addition to the simple round-robin
path selector RHEL6 (and later) device-mapper-multipath supports the
queue-length and service-time path selectors. These route IO to the
device with the shortest queue or best service time (shortest queue
relative to the device's throughput). It's relatively easy to add a new
path selector - the difficult part is to define generally useful
selection algorithms.

One thing to bear in mind is that all of the Linux multipath solutions
sit on top of the same SCSI infrastructure; I've seen situations where
hosts using multipath-tools, PowerPath and Veritas VxDMP all suffered
a similar failure due to a hardware fualt condition that was not handled
well by the Linux midlayer at the time.

>  Powerpath is able to examine the paths down to the array and balance
> workload based on how busy the storage controller / ports are.  AFAIK Rhel6
> has added functionality to make path choices based on queue depth and
> service time, which does add some improvement over vanilla round-robin. For
> VMAX and CX/VNX, powerpath uses the following parameters to balance the
> paths out: Pending I/Os on the path, Size of I/Os, Types of I/Os, and Paths

PowerPath does support various modes of optimisation that are specific
to EMC arrays (iirc separate policies exist for Symmetrix and other
product lines). These are based on an understanding of the device
internals and rely on information that is not publicly available - e.g.
I've seen cases where PowerPath decides to route all IO to a single port
of a Symmetrix presumably because this gives improved cache behaviour.

> most recently used. * Flakey Path Detection: The latest versions of
> powerpath can proactively take paths out of service should it observe
> intermittent IO failures (remember any IO failure can hold a thread for
> 30-60 seconds whilst the SCSI command further up the stack times out, and a
> retry is sent).  dm-multipath doesn’t have functionality to remove a flakey
> path, paths can only be marked out of service on hard failure.*

This is something I've discussed a few times. It's a useful feature but
one that mainly comes into play when dealing with failing or marginal
hardware.

Regards,
Bryn.