SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: ISID and the New Persistent Reservations Proposals



    David,
    I have spent some time stepping through the issues of Target Generation of
    SSID or ISID along with Persistent Reserves.  I will start with Persistent
    Reserves and then move to the SSID/ISID issue.
    
    I have tried to lay it out persistent reserves so that everyone can follow
    it (may not work out but that is the attempt), I have also reviewed this
    with Jim Hafner, so unless I have some typos I think it is correct.
    
    Persistent Reserves have three new proposed versions: (in each of the
    following assume that the Initiator Node has 2 Ports A, and B, and the
    Target Node has 2 Ports X, and Y. Also the subject LUN is called LU5).  I
    will start with point #0 that represents Persistent Reservations as of
    today, and then step through the 3 new options.
    
    0. Today, Initiator Port A, can create a Persistent Reservation for LU5
    with Target Port X, and then only I/O to LU5 can occur via the path from
    Initiator port A to Target Port X, all other I/Os to LU5 will be blocked.
    That is LU5 I/O via A to Y will be blocked as will B to X and B to Y.
    
    Three New additional proposals for handling Persistent reservations are
    being pushed by folks in T10:
    1. Persistent reservations to LU5 can be made via Port A, and that will
    apply on the A to X path and the A to Y path.   I/O to LU5 from Port B to
    either X or Y will be blocked.
    2. Persistent reservation to LU5 made via Port A  or Port B to Target Port
    X, will permit  I/O to LU5 via Port A or B, if sent to Target Port X.
    However, I/O to LU5 via Initiator Ports A or Port B will be blocked if it
    is sent to Target Port Y.
    3. Persistent reservation to LU5 made via Initiator Port A or Port B to
    Target Ports X or Y may occur, and I/O to LU5 may then occur via any path A
    to X, A to Y, B to X, or B to Y.
    
    In both todays model (#0) or in proposal #1 the Target needs to place the
    Persistent  reservation against the Full iSCSI Initiator Port Name.  This
    is the iSCSI Initiator Node Name Plus the ISID.  In proposal #1 the Full
    iSCSI Initiator Port Name is then made known to all the target ports (in
    the same SCSI Device), and that name is then used to determine the
    Persistent Reservation State for each of the Target Ports relative to the
    subject LU.
    
    In proposal 2 and 3, above,  the name to be used in the Reservations is
    just the iSCSI Initiator Node Name (No ISID).  In proposal #2 the Name is
    not shared with the other Target Ports (in that SCSI Device) so Persistence
    only apples to I/O arriving at that Target Port from any Initiator port on
    the Initiator Node which made the Reservation.  And in proposal 3 the iSCSI
    Initiator Node Name is shared among the Target Ports so that Persistence
    can be applied to any Target Port (in that SCSI Device), which is addressed
    by any Port on the Initiator Node which made the Reservation.
    
    Now, with regards to the issue that has been kicking around about the
    target assigning the SSID,  it does not matter one way or the other with
    today's position #0 or proposal numbers 2 or 3. where the SSID comes from.
    However, proposal #1 needs a unique ISID, and can not use a dynamically
    created SSID generated by each target Port.  There are other reasons why
    folks do not even want the ISID, or the SSID generated by the target, but
    those reasons have nothing to do with these Persistent Reservation
    proposals.
    
    I have been suggesting to the N &D team and others that if we limit the
    Dynamic Target Allocation to only the ISID (and of course the TSID) but not
    a complete SSID, that there may be a workable solution.  I say ISID, since
    I believe it must be assured uniqueness per Initiator Port.  One reason can
    be seen in #0, & #1 above.
    
    Now suppose that one of the Target's Job was to Generate a unique ISID for
    each Initiator Port, within and Initiator Node, which wanted to go into
    session.  If you combine with that, the rule that if the Initiator Port
    sets and sends its own ISID  on the Login the Target will accept it, and
    then use the Full Initiator Port Name to check for Persistent Reserves, I
    think we approach a working solution.
    
    Now you also have to ensure that upon a Target Boot, (which has to remember
    the Persistent Reservation Status), it needs to also remember the high
    water mark of ISIDs given out to each Initiator Node.  With that high water
    mark the Target can continue assigning the ISIDs for that Initiator Node.
    Then I think your words were do not aggressively reused ISIDs.  I think
    that if the Target has not gone down for a day or so, ISIDs not in use
    might be re-used, etc.
    We have 65K valid values per Initiator Node so reuse should not be a
    problem.
    
    OK now lets review what we have said.  There is a way for a very simple
    routine on the Target to assign the ISIDs.  If Sent an ISID in the Login it
    should accept it (if it can), and check on persistent reserves of type #0,
    or #1.  The Initiator can save the ISID, in case it goes down and want to
    come back up, and reclaim the reserves, or it can blow the reserves away
    and start again with a Target assigned ISID.
    
    OK now in one of your last notes, I think you said a similar thing.  This
    is also what I attempted to explain to the N &D team.
    
    So anyway, as good engineers we have been able to come up with something
    that works.  The problem that the N & D team had is, so what.  What we have
    now works, and has a smaller impact on the Target.
    
    So if it works we need to decide if we should do it or NOT, and focus the
    conversation on that.
    
    I had sent a note in previously that explained that if we have a way to set
    the iSCSI Initiator Node Name then we must have a way to set the ISID by
    the Initiator Node.  Therefore, the question goes, why get the Target
    involved.
    
    Here is what I said in another note:
    
    If you accept that HBAs should get the iSCSI Initiator Node Name passed to
    it in some manner from the OS, then we did not see why it can not get the
    ISID at the same time also.  If one were to argue that the HBA can not get
    the iSCSI Initiator Node Name, I think this is a bit strange, since almost
    every thing I install in systems, has to go through some type of Wizard, or
    vendor install routine  that actually installs the support driver, etc.
    (This is all set when the OS is fully up and the Registry etc. is clearly
    available.)  I would expect that with current OSs, this would be a normal
    approach.  In the future, I suppose it might be possible that  the OSs
    might have a more dynamic routine to hand out the iSCSI Initiator Node Name
    and ISID so that Hot Swap HBAs could come up without effort.  However,
    until then, I am not sure it is unreasonable for a vendor to require the
    customer to run an update routine,  even after performing an HBA Hot Swap.
    
    There is of course, the first up boot situation.  I think it should be
    possible to have a default, first time HBA boot Name that uses the iqn form
    of the iSCSI Name, and an ISID of FFFF (not 0 as said previously).  This
    should be enough to bring up a "first time up boot", since after the OS is
    started, the approprate install routine should be kicked off, and the real
    iSCSI Initiator Node Name and real ISID set in the Flash for that, and any
    other iSCSI HBAs.
    
    By the way I have a SCSI HBA in my personal system that runs its own BIOS
    routine and when it comes up, but before it boots, it asks questions if
    needed or just announces it is there.  Configuration value can be entered
    at that time.  So even that approach is possible.
    
    So based on the above, I do not think requiring the HBAs to have an
    install/update routine (which sets its Flash) is even a problem.
    
    This means that a Single iSCSI Initiator Node Name should be easy to obtain
    and will apply for all the iSCSI Initiators, whether HW or SW. And likewise
    it should be straight forward to secure the ISID at the same time.  All
    this following well understood current install processes.
    
    Therefore, additional routines on the Target for handing out ISIDs should
    not be needed.
    
    OK, I tried to bring all the ISID issues together here so we could all
    examine them.  I hope this was useful.
    
    
    
    
    
    
    
    
    .
    .
    .
    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
    
    


Home

Last updated: Tue Oct 09 17:17:26 2001
7165 messages in chronological order