Comparison: EMC PowerPath vs. GNU/Linux dm-multipath
By Julien Gabel on Friday 16 May 2008, 21:10 - GNU/Linux - Permalink
I will present some notes about the use of multipath solutions on Red Hat systems: EMC PowerPath and GNU/Linux dm-multipath. Along those notes, keep in mind that they were based on tests done when pressure was very high to put new systems in production, so lack of time resulted in less complete tests than expected. These tests were done more than a year ago, and so before the release of RHEL4 Update 5 and some of RHBA related to both LVM and dm-multipath technologies.
Keep in mind that without purchasing an appropriate EMC license, PowerPath can only be used in failover mode (active-passive mode). Multiple paths accesses are not supported in this case: no round-robin, and no I/O load balancer for example.
EMC PowerPath
Advantages
- Not specific to the SAN Host Bus Adapter (HBA).
- Support for multiple and heterogeneous SAN storage provider.
- Support for most UNIX and Unix-like platforms.
- Without a valid license, can only work in degraded mode (failover).
- Is not sensible to a change in the SCSI LUN renumbering. Adapt accordingly
the corresponding multiple
sddevices (different paths to a given device) with its multipath definition of theemcpowerdevice. - Provide easily the ID of the SAN storage.
Drawbacks
- Not integrated with the operating system (which generally has its own solution).
- The need to force a RPM re-installation in case of a kernel upgrade on RHEL systems (due to the fact that kernel modules are stored in a path containing the exact major and minor versions of the installed (booted) kernel.
- Non-automatic update procedure.
GNU/Linux device-mapper-multipath
Advantages
- Not specific to the SAN Host Bus Adapter (HBA).
- Support for multiple and heterogeneous SAN storage provider.
- Well integrated with the operating system.
- Automatic update using RHN (you must be a licensed and registered user in this case).
- No additional license cost.
Drawbacks
- Only available on GNU/Linux systems.
- Configuration (files and keywords) very tedious and difficult.
- Without the use of LVM (Logical Volume Management), it has not the ability
to follow SCSI LUN renumbering! Even in this case, be sure not to have
blacklisted the newly discovered SCSI devices (
sd).
Last, please find some interesting documentation on the subject below:
Comments
Nice comparison, thank you.
Is there any way to get Clariion/Symmetrix LUN numbers when using dm-multipath?
To be able to get the SCSI LUN ID--whatever is the SAN storage provider, you must know the appropriate sd devices which compose the multipath device (PowerPath, GNU/Linux dm-multipath, etc.). Then, you can identify the LUN ID using something like this:
# find /sys/devices -name "*block" -print | \
xargs \ls -l | awk -F\/ '$NF ~ /sdo$/ || $NF ~ /sdp$/ \
{print "HBA: "$7"\tscsi#:channel#:id#:lun#: "$9}'
HBA: host0 scsi#:channel#:id#:lun#: 0:0:0:9
HBA: host0 scsi#:channel#:id#:lun#: 0:0:1:9
If you are looking for more information on SCSI devices, you can also use the excellent EMC 'inq' little tool:
http://blog.thilelli.net/post/2007/...
One of the nice things I've found with multipathd is that you can alias devices based on their unique LUN ID (using the "alias" directive, I can end up with a /dev/mapper/SAN_LUN3 etc based on the unique ID of the LUN). This way you can be sure that the same LUN will have the same name across multiple hosts, between boots, after removing or adding LUNS etc. I haven't been able to replicate this using powerpath? Does anyone know if there is a way? It seems it just picks the emcpower<a,b,c,d...> names however it wants? i.e. if I attach 4 LUNS to one host then the same LUNs to another, in each case the LUNs will be different devices?
As for EMC PowerPath, it can update its configuration on LUN name change if used with CLARiiON system. I don't know if it is possible for other storage provider (but this not important from PowerPath point o view). The final aim is to be able to properly discover multipath devices, which generally operate under LVM management: in this case, both solutions are usable nevertheless.
What really matter is that the multipath device follow automatically device name change (whatever the name is), and LUN renumbering. It doesn't really matter how is named the device if the multipath software can't recognize it (unless for human intervention in case of a software failure in order to reconfigure it properly). If the alias capability is the solution to do that with dm-multipath, that is a good news.