[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] /dev/dm-N and Veritas?



Brian,
We have a substantial investment in Veritas as well as people who know Veritas and multiple platforms to support which all run Veritas. There are three reasons driving my device mapper analysis: 1). We've had major problems with DMP on EMC Clariion arrays with Linux running Veritas Storage Foundation for Oracle Real Application Clusters, I still do not have resolution from Symantec (formally Veritas). 2). We use 3PAR storage and they say they will not support DMP on RHEL4 but will only be supporting DM. 3). I would really like to remove the storage vendor dependency on the Array Support Library (ASL) which is required by most storage vendors to use DMP. With DM the storage need only to provide the LU(s) on multiple paths with the same SCSI serial number. It also allows you to have persistent device names when adding or removing LUs and rebooting. At some point we may be looking at LVM but not until it can perform such functions as point in time snap shots which can be deported and then mounted on another host for database replication and other functions that we use it for. For consistency which is key to reducing labor costs it would also need to run on Solaris, HPUX and Windows. I'm still trying to find a way to use /dev/mapper/<name> devices with Veritas.
Thanks.
   -Mark

Brian Long wrote:

On Mon, 2005-10-31 at 14:27 -0500, Bruen, Mark wrote:
Anyone using Veritas to manage their /dev/dm-N devices?

Mark,

There is no point in using device-mapper multipathing since Veritas has
their own multi-pathing software built-in.  What would be the point?
Veritas won't support you unless you use DMP (Dynamic Multi Pathing).

If you're going the Veritas route instead of using LVM2, you should use
their stuff solely.

We did an in-house Veritas vs. LVM2 show-down on Linux and LVM2 provides
enough functionality for our needs.  It doesn't provide functionality
for some of our "wants", but we've decided to go with LVM2 as we deploy
RHEL 4.

/Brian/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]