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

[Rob]

Hi List,

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.

We have a rather large multi-tenant infrastructure using PowerPath. Since
this inherently comes with increased maintenance costs (recompiling the
module, requiring extra steps / care when upgrading etc) we are looking at
using dm-multipath as the defacto standard SAN-connection abstraction layer
for installations of RHEL 7+.

After discussions with our SAN Architect team, we were given the below
points to chew over and we were met with stiff resistance to moving away
from Powerpath. Since there was little right-of-reply, I'd like to run
these points past the minds of this list to understand if these are valid
enough to justify a valid business case of keeping Powerpath over Multipath.












*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.
 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
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.*

Many thanks
--
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20140909/9423ad12/attachment.htm>