SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: ISIDs



    
    David and Julian
    
    On second thought, let me qualify what I just said in my last posting about
    recreating the session on a different portal group.
    
    As far as the model is concerned, that still holds, BUT it doesn't prevent
    failover from one HBA to another!  The reason is that all of the properties
    of the failed HBA can be assumed by the back up HBA (this includes,
    ipaddresses, portal group tag, etc.).  So, phyically, the HBA may be a
    different one, but the model view of the portal group is still the same
    (different hw, same 'identity').   Similar things happen with just IP
    addressing today and with FC functions as well.
    
    Jim Hafner
    
    
    Black_David@emc.com@ece.cmu.edu on 09/09/2001 11:16:39 pm
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    cc:
    Subject:  RE: iSCSI: ISIDs
    
    
    
    One more whack at this ...
    
    > The major difference is "control". In the current scheme the initiator
    and
    > target could independently allocate and reuse their parts.
    >
    > The target allocates only scheme leaves this to the target (it has to do
    > garbage collection) under the assumption that the target (unlike the
    > initiator) has a central point of control.
    
    Yes, I'm assuming that targets will have a single vendor in charge
    of all the software on the target and making it work right if there are
    multiple HBAs; I don't see any corresponding vendor who's in a position
    to do the same for the initiator ...
    
    > Aren't targets going to have several HBA and have to carefully allocate
    > their SSIDs?
    
    But they'll have one vendor in charge of making this work.  In contrast,
    for an initiator with HBAs from two different vendors, both of those
    vendors and the vendor of the OS platform have to be involved, and I
    don't see any of them taking full responsibility in the early going.
    I'm worried we risk heading the iSCSI Initiator Name down the same
    path as Fibre Channel, where the FC Node WWN was supposed to be associated
    with the server into which the HBAs were plugged, but got associated
    with the HBA because there was no way to coordinate across HBAs.
    If anything ever goes wrong with ISIDs (and things will), the fastest
    way to fix it will be to require each HBA to have its own iSCSI Initiator
    Name, independent of the intent of the iSCSI naming architecture.
    
    > In the event an initiator wants to rebuild a session does he have to
    > connect to the same HBA and thus a failover to another HBA
    > can't be done.
    
    No, this is controlled by portal groups.  To failover across two HBAs
    on the target, they have to be in the same portal group, and the target
    is responsible for coordinating TSID usage within each portal group.
    If the target can't coordinate TSID usage, it puts the HBAs into different
    portal groups and gives up this failover ability as a consequence, and
    that's the case independent of whether ISIDs exist or not.
    
    > For all the above no to happen we have to add some management somewhere
    and
    > it looks to me that the current scheme is simpler than a target centric
    one
    > as it keeps the allocation and release of numbers at the same end.
    
    I'm sorry, that doesn't parse for me.  It looks like the same sort of
    mechanism is being put into both initiators and targets for symmetry,
    without considering whether two instances of the mechanism are actually
    necessary.  In a target-centric scheme, the target is doing the "allocation
    and release" of numbers.  The target does have to be careful about not
    aggressively reusing TSID values, when there's potentially recoverable
    state around (or the initiators may think that there's state to be
    recovered even though the target's lost it all in a reboot), but recall
    that aggressive reuse of ISIDs is what created the Option A/B/C mess
    (and not aggressively reusing ISIDs would make that easier to solve).
    I don't understand how two instances of similar mechanisms is "simpler"
    than one.
    
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    
    
    


Home

Last updated: Mon Sep 10 12:17:06 2001
6492 messages in chronological order