SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    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
    


Home

Last updated: Fri Oct 05 14:17:24 2001
7076 messages in chronological order