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+.
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.
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
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
