Summary: How is Veritas DMP working when interfaces are not the s ame s peed ?

Sorry for the late reply, I waited to gather as many replies as possible.
However, in the end only 2 were relevant to the subject. Thanks to everybody
who took time to respond:

First Reply:
As far as I know, it is just round-robin between the paths to a disk.

I don't think there is any risk (eg data corruption), but I also highly
doubt that Veritas will be clever regarding the speed of interfaces.  In
fact, I doubt that Veritas even has got a way of finding out the speed of
interfaces!

I am using those same HBAs with Solaris 2.6 - I can not say without
problems, but I can say most of my problems are with the dual-port
FCE2-1063s and my setup is configured as a fabric!  Before you buy 2Gb
GBICs, make sure that the HDS interface cards support 1Gb/sec, otherwise you
are wasting your money.

Note: On a SAN you could see multiple instances of a single LUN on a single
HBA, and so you would (in theory) be able to disable some of the paths to
the LUN on the slower interface to make sure it gets used less often.

  _Johan
The second reply said that as far as the sender was aware, starting from
VxVM 3.0 the DMP algorithm is smart enough to consider the bandwidth of the
pipe as well. No further information was supplied.


I decided to go and try anyway. Personally I suspect that there is a simple
round robin, without taking into account the fatness of every individual
pipe. But again, is just a personal hunch, with no hard facts to sustain it
yet.
I'll send an additional Summary if more information will became available.

Original Post:
Dear Friends,
I am using Veritas DMP with Solaris 2.6 (VxVM 3.2). The storage is XP512, an
oem of Hitach Lightning 9660 in direct attach mode. So far, I used Jaycor
FCE-1063 adapters (1GB/sec). However, I plan to add more HBA's and I'm
thinking at FCE-1473, 2 GB/sec, also to be used direct attached. Most likely
the final setul will have 4 HBA's of 1GB/sec and 2HBA's of 2GB/sec The
questions are the following: 1. How will VxVM 3.2 handle DMP over
controllers of different bandwidth ? Will send disk blocks over each
interface in a round robin fashion, therefore wasting extra bandwidth of
FCE-1473, or will adapt itself to use more bandwidth of FCE-1473 ? 2. Did
anyone used such setup without problems, are data corruption risks
associated with it ? 3. The FCE-1473 interface salesman (which is from HP)
insist only Solaris 7 and 8 are supported, in which case my setup won't work
because I'm stuck for the moment with Solaris 2.6, but on FCE-1473 datasheet
from Jaycor website, Solaris 2.6 is supported along with Solaris 8 and
Solaris 7. What is your experience with this card ?





Best Regards,
George Done
Senior Unix Administrator
> Dutchtone TechD Department  room SG03
Spaarneplein 2, 2515VK, Den Haag
Phone	+31 - (070) - 778 4267
Mobile	+31 - (0)6 - 28 026216



===========================================================
De verzonden informatie is uitsluitend bestemd voor de geadresseerde
natuurlijke persoon of rechtspersoon en bevat mogelijk vertrouwelijke en/of
geprivilegeerde gegevens. Met uitzondering van de geadresseerde persoon is
het niet toegestaan de informatie openbaar te maken, te kopikren, te
verspreiden of anderszins actie te ondernemen op basis van de informatie.
Indien u de informatie abusievelijk heeft ontvangen, neem dan contact op met
de afzender en verwijder de informatie uit alle computers. Dutchtone staat
niet in voor de juiste en complete verzending van de informatie, noch is zij
aansprakelijk voor de vertraagde ontvangst hiervan.

The information transmitted is intended exclusively for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any disclosure, copying, distribution or other action  based upon
the information by persons or entities other than the intended recipient is
prohibited. If you receive this information in error, please contact the
sender and delete the material from any and all computers. Dutchtone does
not warrant a proper and complete transmission of this information, nor does
it accept liability for any delays.
===========================================================
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers