Operating System - Linux
1747997 Members
4523 Online
108756 Solutions
New Discussion юеВ

Re: Linux Device Mapper Multipath vs Veritas DMP.on RHEL5

 
SOLVED
Go to solution
joe_91
Super Advisor

Linux Device Mapper Multipath vs Veritas DMP.on RHEL5

Good Day!

In our company we are trying to understand the confugurations/limitations of various Multipathing alternatives. There is a general pushback on the Linux Multipath (device-mapper) and people prefer Veritas DMP. Could anyone point out general pros/cons of using Linux DMM vs Veritas DMP. I have configured quite a few RHEL servers on DMM and generally found it to be OK. Please, i am waiting for all the comments..

Cheers

Joe.
6 REPLIES 6
Matti_Kurkela
Honored Contributor
Solution

Re: Linux Device Mapper Multipath vs Veritas DMP.on RHEL5

I have no experience with Veritas DMP, but plenty with dm-multipath and EMC PowerPath.

In RHEL 4, the dm-multipath was originally rather immature and fragile, but developed rapidly. In RHEL 5, I'd say it's essentially useable, although rather sparse of features. In RHEL 6, dm-multipath has gained new load balancing algorithms and the configuration has been streamlined. Still, it is a keep-it-simple solution at an unbeatable price (= free).

EMC PowerPath is more feature-rich and its load-balancing algorithms and other central features have been in use for a good time on platforms other than Linux too. The extra features in newer versions allow more storage migration strategies.

On the other hand, an external multipath solution like Veritas DMP or EMC PowerPath is an extra cost item (unless you already have appropriate licensing). Because a multipath solution needs to have kernel components, in the worst case you might have to delay your kernel upgrades until a matching multipath upgrade is released. This may be inconvenient if you're running a publicly-accessible service and need to apply a kernel upgrade in response to a security exploit as fast as possible.

MK
MK
Alzhy
Honored Contributor

Re: Linux Device Mapper Multipath vs Veritas DMP.on RHEL5

Greetings Joe!

If you've deep pockets** and your enterprise has standardised on Veritas Products (notably VxVM/VxFS combo - aka Veritas Foundation Suite) - then you're better off with VxVM - its DMP mechanism is bullet-proof and scales way better than device-mapper multipath.

IF your resources are lacking, go with the built in device-mapper multipath + LVM2 combo (and possibly even MD/software RAID for JBODs and LVM2).

The good thing is they can co-exist on the same RHEL system.

VxVM-DMP:
- generally aware of needed multipathing and load balancing for the Storage Array
- automatically set up
- scale to thousands of LUNs without tweaks to the kernel, to multipath.conf, etc.
- expensive
- not "easy" to become familiar


Linux Device-Mapper Multipath:
- tweaks needed in kernel
- EEBs even for out of this world situations
- need to insure your multipath.conf is correct
- can suffer some issues with large numbers of disks
- free, generally performs well with smaller number of disks
- support? (Google)


** Storage FOundation BASIC appears to be free (no license) but yu are restricted to 1 Diskgroup and 4 volumes/filesystems.


Hakuna Matata.
Alzhy
Honored Contributor

Re: Linux Device Mapper Multipath vs Veritas DMP.on RHEL5

Here's a comparison on an ACTUAL RHEL 5.5 System running both device-mapper multipath AND VxVMhappily coexisting.

VXVM (en EVA8400 on dual FC-HBA conections)

root@goofy# vxdisk list sdn
Device: sdn
devicetag: sdn
type: auto
hostid: flpi021.ffdc.sbc.com
disk: name=EV8FCfloat1vol01 id=1269462339.86.fhprod20
group: name=vxfloater1 id=1269462351.88.fhprod20
info: format=cdsdisk,privoffset=256,pubslice=3,privslice=3
flags: online ready private autoconfig autoimport imported
pubpaths: block=/dev/vx/dmp/sdn3 char=/dev/vx/rdmp/sdn3
guid: {698152fe-1dd2-11b2-8f4f-0022649470df}
udid: HP%5FHSV450%5FALUAdisk%5F600508B4000CE3E70000D00004050000
site: -
version: 3.1
iosize: min=512 (bytes) max=1024 (blocks)
public: slice=3 offset=65792 len=4194107136 disk_offset=0
private: slice=3 offset=256 len=65536 disk_offset=0
update: time=1292377143 seqno=0.232
ssb: actual_seqno=0.0
headers: 0 240
configs: count=1 len=48144
logs: count=1 len=7296
Defined regions:
config priv 000048-000239[000192]: copy=01 offset=000000 enabled
config priv 000256-048207[047952]: copy=01 offset=000192 enabled
log priv 048208-055503[007296]: copy=01 offset=000000 enabled
lockrgn priv 055504-055647[000144]: part=00 offset=000000
Multipathing information:
numpaths: 16
sdbo state=enabled type=primary
sdbr state=enabled type=primary
sdbw state=enabled type=secondary
sdbt state=enabled type=secondary
sdce state=enabled type=primary
sdcb state=enabled type=primary
sdcg state=enabled type=secondary
sdcj state=enabled type=secondary
sdbe state=enabled type=primary
sdae state=enabled type=primary
sdbk state=enabled type=secondary
sdbg state=enabled type=secondary
sdy state=enabled type=primary
sdn state=enabled type=primary
sdaa state=enabled type=secondary
sdac state=enabled type=secondary

Device Mapper Multipath: Same LUN
root@goofy# multipath -ll
mpath268 (3600508b4000ce3e70000d00004050000) dm-27 HP,HSV450
[size=2.0T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=80][enabled]
\_ 7:0:2:2 sdaa 65:160 [active][ready]
\_ 7:0:3:2 sdac 65:192 [active][ready]
\_ 9:0:2:2 sdbg 67:160 [active][ready]
\_ 9:0:3:2 sdbk 67:224 [active][ready]
\_ 3:0:2:2 sdbt 68:112 [active][ready]
\_ 3:0:3:2 sdbw 68:160 [active][ready]
\_ 5:0:2:2 sdcg 69:64 [active][ready]
\_ 5:0:3:2 sdcj 69:112 [active][ready]
\_ round-robin 0 [prio=400][enabled]
\_ 7:0:0:2 sdn 8:208 [active][ready]
\_ 7:0:1:2 sdy 65:128 [active][ready]
\_ 9:0:0:2 sdae 65:224 [active][ready]
\_ 9:0:1:2 sdbe 67:128 [active][ready]
\_ 3:0:0:2 sdbo 68:32 [active][ready]
\_ 3:0:1:2 sdbr 68:80 [active][ready]
\_ 5:0:0:2 sdcb 68:240 [active][ready]
\_ 5:0:1:2 sdce 69:32 [active][ready]


I have not noticed a clash between DMP and DM as you can see. DM still multipaths it alright BUT VxVM still uses its own.

Hakuna Matata.
dirk dierickx
Honored Contributor

Re: Linux Device Mapper Multipath vs Veritas DMP.on RHEL5

I have no issues with linux multipath, depending on your needs it could deliver well what you need. the main advantage of it is that it is an official part of the RH distro and this will ensure you won't run into issues with kernel versions etc. and that you have one contact address (RH) for support issues. ofcourse it's also 'free'.

what i have seen from symantec/veritas is that the stability of their kernel modules leaves a lot to be desired. we're using their clusterfs on some nodes and these are clearly less stable then all the 'regular' linux installs and when they panic it's always on said kernel module - stuff like that makes me mad.

if those other people in the org are against it, do they have actual arguments? or it is more in the line of - but we use it on solaris/hpux/aix/... so we are used to it and don't want to learn something new.
joe_91
Super Advisor

Re: Linux Device Mapper Multipath vs Veritas DMP.on RHEL5

if those other people in the org are against it, do they have actual arguments? or it is more in the line of - but we use it on solaris/hpux/aix/...

Yes exactly True..They have made this standard across the board. Quite honestly i have found the DMM simple to use.

Cheers

Joe.
Alzhy
Honored Contributor

Re: Linux Device Mapper Multipath vs Veritas DMP.on RHEL5

No matter how simple -- Corporates are for Standards, standards, standards.

And we should understand this -- and actually it will have its long list of benefits in such an enterprise.

I personally would pick VxVM/VxFS/VCS over any OS built in LVM, FS or Clusering Solution - not for the mere fact of standardisation or I hold SYMC stock or have above average expertise with Vx Products - BUT Vx Products are just simply better, stabler and available accross the board. I can sleep better with knowing my systems are protected with VxVM/VxFS/VCS.

(oops.. I thought someone whispered --- "'tis the reason HP maintained VxVM/VxFS/CVM/VCS well beyond HP-UX 11.31"
Hakuna Matata.