Re: iSCSI: Questions about naming, multi-pathing, multi-port targets

["John Hufferd" <hufferd@us.ibm.com>]

Joe,
Unless there is an important reason to keep the Ports Separate, the most
useful thing to do is to include them all in a single Portal Group.  Some
of the discussions that you may  have seen have been mostly focused on the
Initiator side, where there could be several different vendors' HBAs
installed.  But it was generally expected that if you create a Target, that
you would have the same vendor HBAs in your Target.

So when you select a vendor (assuming it is not your own companies), you
would want them to be able to handle Multiple Connections per Session,
across the Multiple Vendor HBAs.  If you chose an HBA vendor that can not
do that, then you might have 4 Portal groups each with one portal.

Some vendors will also put more then one Ethernet Connection on their HBA
and will be able to have Multiple Connections per Session within the HBAs.
Some of these vendors will be able to gang several of those HBAs gather for
an even larger Portal Group.  Other vendors will not  be able to group with
other of their own HBAs, and you will again have a Portal Group per HBA.
However, in this case the individual Portal Groups will contain the
Multiple Ethernet Portals on each HBA.

If on the other hand if you are making your own SW iSCSI implementation,
and working with 4 NIC cards, you should be the one that creates the
Multiple Connections per Sessions across all your NIC cards.

If you plan on using a vendors HBA that knows how to Gang the HBAs into
Portal Groups, your problem will be porting or having the vendor port their
Device Driver into your NetApp operating environment.

My PERSONAL opinion is that Bigger is Better.  That is, the Larger the
Portal Group the better.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Pittman, Joseph" <Joseph.Pittman@netapp.com>@ece.cmu.edu on 10/04/2001
05:32:02 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: Questions about naming, multi-pathing, multi-port targets




I am fairly new to the iSCSI effort, and this is my first question
to the IPS mailing list.  But I have been following the mailing list
for awhile now, particularly the recent system identification
discussions.  And I am now working in earnest on an iSCSI target
implementation, which has brought into focus the need for me to get
a more complete understanding of the concepts.

What is the expected naming and access model for a target with
multiple physical ports/IP addresses?  I understand from the iSCSI
Naming and Discovery document that a target node presents one or
more Portal Groups, and that an iSCSI session is conducted over
exactly one portal group.

Is it expected that a target with 4 ports will have a single
"portal group"?  Or 4 separate portal groups?  Would operating
system SCSI initiator code prefer to see 4 independent paths into
the target, or a single session-layer path with multiple lower-level
paths of connectivity?  And how is the OS supposed to discover the
association between target portals and their portal groups?

In the FCP-SCSI world, each FC port on a multi-ported target device
(e.g. SAN-connected disk array) is an independent communicating
entity, with its own FC port and WWN.  There is no concept of a
networking session which spans multiple physical connections.  As I
understand it, the existence of multiple paths to the same
underlying set of LUNs is detected by examining SCSI inquiry data
from the detected devices.  A driver (or a "wedge layer") within an
operating system examines all available LUNs through all FCP HBAs
under its control, and uses SCSI inquiry to detect the existence of
multiple paths to the same LUN.  The driver or wedge layer then
advertises to the higher layers of the SCSI block storage stack
only the set of unique target devices.  The driver routes incoming
SCSI requests from above to to one of the available paths, based
on some algorithm which may take into account availability and
relative performance of the paths.

Now consider the case of adding support for iSCSI connectivity
into an existing OS SCSI request stack.  The most straightforward
way for an iSCSI driver to drop into an existing infrastructure
would be for a 4-port target to appear as 4 distinct DEVICES.
The driver or "wedge layer", using IP address as the fundamental
identifier for its notion of target identifier, would detect the
presence of 4 separate "targets", use inquiries to detect multiple
paths to the LUNs through these separate devices, etc.

An approach which is more iSCSI-aware could take advantage of
available config info (via static configuration? SLP? iSNS?) to
recognize that all 4 IP addresses map to the same iSCSI Target
Node.

The ISID rule states that there can be only one session with a
given ISID between an iSCSI Initiator and an iSCSI Target Portal
Group.  So how does the initiator discover the relationship
between portals and groups on the target?  And what would the
OS implementors rather do, establish a separate session to each
IP address, or establish a single session over each portal group?

Impact on the target-mode implementer: should a target
implementation endeavor to present a single portal group?  Or a
different group for each portal?  Or a different group for each
HBA (which may have one or more ports)?  One factor in deciding
this is the diversity of the possible approaches to handling
iSCSI processing:

  - onboard a single-port HBA
  - onboard a multi-port HBA
  - within a driver in an embedded OS which uses a per-instance
    driver architecture
  - within a driver in an embedded OS which uses a per-device class
    driver architecture
  - within an overarching iSCSI management layer

Any thoughts or guidance would be greatly appreciated.
--
Joe Pittman
jpittman@netapp.com