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

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

    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:
    "Pittman, Joseph" <> on 10/04/2001
    05:32:02 PM
    Sent by:
    To:   "''" <>
    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
    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


Last updated: Thu Oct 04 22:17:29 2001
7058 messages in chronological order