From: James Smart <James.Smart@Emulex.Com>
To: "Philip R. Auld" <pauld@egenera.com>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: multipath and san fabric
Date: Mon, 13 Nov 2006 14:54:15 -0500 [thread overview]
Message-ID: <4558CD67.6000104@emulex.com> (raw)
In-Reply-To: <20061113195227.GE13788@vienna.egenera.com>
Yep - Ed caught my typo.... :)
-- james
Philip R. Auld wrote:
> Rumor has it that on Mon, Nov 13, 2006 at 02:39:08PM -0500 Edward Goggin said:
>> You may want to also cross connect across the 2 target
>> controllers (A,B) in case 2. Doing so provides more
>> redundancy for asymmetric arrays and better resource
>> utilization in case of a failure of either an HBA or
>> target controller which would otherwise prevent
>> utilization of the other HBA or target controller
>> for that LU when load sharing I/O across multiple
>> paths.
>>
>> So the I_T nexus's for the 4 paths are:
>>
>> HBA1_TargetPort1
>> HBA1_TargetPort3
>> HBA2_TargetPort2
>> HBA2_TargetPort4
>>
>
> That's exactly what James's example 2 describes. It's just
> typo'd in the DM paths list.
>
>
>
>>> -----Original Message-----
>>> From: dm-devel-bounces@redhat.com
>>> [mailto:dm-devel-bounces@redhat.com] On Behalf Of James Smart
>>> Sent: Monday, November 13, 2006 2:18 PM
>>> To: jslittl@hendricks.org; device-mapper development
>>> Subject: Re: [dm-devel] multipath and san fabric
>>>
>>> If the hba's are on different fabrics - why would you ever put an hba
>>> that is not in the fabric in a zone in that fabric ? (e.g.
>>> your second
>>> option makes no sense).
>>>
>>> If you are stating that the 2hba's are on different fabrics
>>> (and in zones
>>> within those fabric) - but they are seeing the same Storage
>>> device on both
>>> fabrics - then the dm config (note: I'm not talking about
>>> zoning anymore)
>>> would have a path per I_T nexus. I state it this way to
>>> account for dual-ported
>>> controllers, which may appear as separate targets, may exist
>>> within the fabric.
>>>
>>> Example 1:
>>> Fabric A contains HBA1 and TargetPort1. Typically a zone
>>> would exist
>>> within Fabric A that contains these 2 ports.
>>> Fabric B contains HBA2 and TargetPort2. Typically a zone
>>> would exist
>>> within Fabric B that contains these 2 ports.
>>> The storage array contains 2 controllers with 1 port per
>>> controller, or
>>> is a single controller with 2 ports. Either way, the two
>>> ports are
>>> TargetPort1 and TargetPort2, are on the same array, and
>>> all storage
>>> can be seen from any port.
>>> --
>>> This would have 2 DM paths.
>>> The I_T nexus's are:
>>> HBA1_TargetPort1
>>> HBA2_TargetPort2
>>>
>>> Example 2:
>>> Fabric A contains HBA1, TargetPort1, and TargetPort3.
>>> Typically a zone
>>> would exist within Fabric A that contains these 3 ports.
>>> Fabric B contains HBA2, TargetPort2, and TargetPort4.
>>> Typically a zone
>>> would exist within Fabric B that contains these 3 ports.
>>> The storage array contains 2 controllers, with 2 ports per
>>> controller.
>>> Meaning TargetPort1 and TargetPort2 are on controller A,
>>> and TargetPort3
>>> and TargetPort4 are on controller B. The ports are cross
>>> connected on
>>> the fabrics for redundancy. All storage can be seen from
>>> any port.
>>> --
>>> This would ahve 4 DM paths
>>> The I_T nexus's are:
>>> HBA1_TargetPort1
>>> HBA1_TargetPort2
>>> HBA2_TargetPort3
>>> HBA2_TargetPort4
>>>
>>> -- james
>>>
>>> John Little wrote:
>>>> Hi all
>>>>
>>>> Admittedly this is not the correct forum for this question
>>> but I have googled
>>>> this and the only people I have to ask around here are
>>> people who won't touch
>>>> it because it is Linux.
>>>>
>>>> My question is this: I'm using SLES10 with two emulex
>>> hbas, one connected to
>>>> fabric a and one to fabric b. When zoning the switch for
>>> the hbas do I put
>>>> in only one path to the fabric per hba or do I put in two,
>>> one to each of the
>>>> separate fabrics?
>>>>
>>>> Again I realize this is not exactly the correct forum but
>>> since I couldn't
>>>> find an answer anywhere else I figured you guys would be the most
>>>> knowledgeable. If there are some docs somewhere that you
>>> could point me to I
>>>> would appreciate it.
>>>>
>>>> John
>>>>
>>>> --
>>>> dm-devel mailing list
>>>> dm-devel@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/dm-devel
>>>>
>>> --
>>> dm-devel mailing list
>>> dm-devel@redhat.com
>>> https://www.redhat.com/mailman/listinfo/dm-devel
>>>
>>>
>> --
>> dm-devel mailing list
>> dm-devel@redhat.com
>> https://www.redhat.com/mailman/listinfo/dm-devel
>
next prev parent reply other threads:[~2006-11-13 19:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-13 16:35 multipath and san fabric John Little
2006-11-13 19:18 ` James Smart
2006-11-13 19:39 ` Edward Goggin
2006-11-13 19:52 ` Philip R. Auld
2006-11-13 19:54 ` James Smart [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-11-14 13:09 John Little
2006-11-14 20:41 ` Edward Goggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4558CD67.6000104@emulex.com \
--to=james.smart@emulex.com \
--cc=dm-devel@redhat.com \
--cc=pauld@egenera.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.