SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Need to Kill Session from Surviving Node



    Somesh,
    
    Please refer to the following URL (and emails around that) for 
    a long discussion on this topic.  Both flavors of resets have value,
    and I agree with Julian that iSCSI should support both.
    
    http://ips.pdl.cs.cmu.edu/mail/msg00740.html
    
    --
    Mallikarjun 
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668	Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    >Do you need both a "warm-reset" and a "cold-reset"?
    >The "warm-reset" seems to be an over-optimization.
    >
    >Somesh
    >
    >> -----Original Message-----
    >> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    >> Mallikarjun C.
    >> Sent: Wednesday, March 14, 2001 12:16 PM
    >> To: ips@ece.cmu.edu
    >> Subject: Re: iSCSI: Need to Kill Session from Surviving Node
    >>
    >>
    >> >There is a related problem that I think we need to address, and
    >> that is --
    >> >the case where the Storage Controller is an Active-Active Fail-Over unit
    >> >with very little state shared between the Storage Controller Nodes.  (I
    >> >think a number of you folks have told me that you are planning such a
    >> >design.)  This would mean that a specific initiator OS (WWUI) would have
    >> >separate sessions between the Nodes.  At fail-over, the
    >> Take-Over Node will
    >> >want to cause the Initiator, to Stop messing around with the Failing node
    >> >ASAP, and start using the existing session, or start a new
    >> session with the
    >> >Take_Over Node.  The Initiator, will normally just time-out the TCP/IP
    >> >connection, and then turn the recovery over to the SCSI Layer. Then, when
    >> >SCSI retries, iSCSI will either use the Session to the Surviving Node or
    >> >Create a New Session to that Surviving Node.  The problem is, that this
    >> >will take a longer time then a system might want.
    >> >
    >> >So the question: is there a way for a surviving Target Node to tell the
    >> >Initiator to "Kill" the Session to the Failing Target Node?
    >> >
    >> >Comments?
    >>
    >> Assuming that the failing Node is still able to execute commands,
    >> a cold target reset from the Initiator to the failing node should "kill"
    >> all the sessions to it.
    >>
    >> The answer to two hosts configured in a failover configuration sharing
    >> a single Storage Controller Node is also the same.
    >>
    >> If it is active-active configuration, it appears to me that there's a
    >> need to somehow prompt the Initiator to doing the reset on a third party
    >> (Async PDU?).
    >>
    >> This is a reason why we'd still need target reset in iSCSI.
    >> --
    >> Mallikarjun
    >>
    >>
    >> Mallikarjun Chadalapaka
    >> Networked Storage Architecture
    >> Network Storage Solutions Organization
    >> MS 5668	Hewlett-Packard, Roseville.
    >> cbm@rose.hp.com
    >>
    >> >
    >> >.
    >> >.
    >> >.
    >> >John L. Hufferd
    >> >Senior Technical Staff Member (STSM)
    >> >IBM/SSG San Jose Ca
    >> >(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    >> >Internet address: hufferd@us.ibm.com
    >> >
    >> >
    >> >Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 03/14/2001 08:31:19 AM
    >> >
    >> >Sent by:  owner-ips@ece.cmu.edu
    >> >
    >> >
    >> >To:   ips@ece.cmu.edu
    >> >cc:
    >> >Subject:  Re: iSCSI: Logout needs ISID
    >> >
    >> >
    >> >
    >> >
    >> >
    >> >Mark,
    >> >
    >> >If you have only one connection you are supposed to use a Login with the
    >> >restart bit one - and achieve a similar effect as a Login/Logout - i.e.
    >> >keep the session alive.  Even this might be a problem for a
    >> target that is
    >> >so poor it has only one socket (even SNMP won't work there).
    >> For this case
    >> >the only way out is to drop the connection and hope the target will hear
    >> >you (it probably won't -:)). The comment is the draft is a memento for
    >> >implementers to keep looking for new connections always (even for a one
    >> >connection target) but probably it does not come through clear enough.
    >> >
    >> >Regards,
    >> >Julo
    >> >
    >> >Mark Bakke <mbakke@cisco.com> on 14/03/2001 18:17:14
    >> >
    >> >Please respond to Mark Bakke <mbakke@cisco.com>
    >> >
    >> >To:   Julian Satran/Haifa/IBM@IBMIL
    >> >cc:   ips@ece.cmu.edu
    >> >Subject:  Re: iSCSI: Logout needs ISID
    >> >
    >> >
    >> >
    >> >
    >> >Julian-
    >> >
    >> >A target that does not support multiple connections per session
    >> >will return "Initiator SID Error" when the login attempt is made.
    >> >In this case, there is no way to log in, so there's no way to
    >> >log out the old connection.  The initiator would be stuck waiting
    >> >until the target's side of the connection times out and goes
    >> >away, which could be a very long time.
    >> >
    >> >There is an open question within the MIB team about whether anyone
    >> >needs to be able to kill connections or sessions from SNMP; however,
    >> >I don't think that anyone will want to use SNMP as part of error
    >> >recovery.
    >> >
    >> >--
    >> >Mark
    >> >
    >> >julian_satran@il.ibm.com wrote:
    >> >>
    >> >> Josh,
    >> >>
    >> >> No command, including logout, can be sent without a login.
    >> >> The complete scenario is:
    >> >>
    >> >> -open a new connection
    >> >> -login in the same session as the old connection (this has the ISID &
    >> >TSID)
    >> >> -logout the old connection
    >> >> -recover commands
    >> >>
    >> >> You are not supposed to be able to kill a session from outside
    >> (at least
    >> >> not an iSCSI defined mode).
    >> >> You will need management support for that (SNMP?)
    >> >>
    >> >> Regards,
    >> >> Julo
    >> >>
    >> >> Joshua Tseng <jtseng@NishanSystems.com> on 14/03/2001 17:09:48
    >> >>
    >> >> Please respond to Joshua Tseng <jtseng@NishanSystems.com>
    >> >>
    >> >> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    >> >> cc:
    >> >> Subject:  RE: iSCSI: Logout needs ISID
    >> >>
    >> >> Julian,
    >> >>
    >> >> In 2.14, you state that a logout command can be
    >> >> sent on a different connection to destroy a single-
    >> >> connection iSCSI session.  If you have multiple
    >> >> sessions ongoing, and the logout command is sent
    >> >> on a different connection than the one used
    >> >> to support the session that is to be killed, then
    >> >> you will need ISID to distinguish the session that
    >> >> you want killed.
    >> >>
    >> >> Regards,
    >> >> Josh
    >> >>
    >> >> > -----Original Message-----
    >> >> > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
    >> >> > Sent: Tuesday, March 13, 2001 9:57 PM
    >> >> > To: ips@ece.cmu.edu
    >> >> > Subject: Re: iSCSI: Logout needs ISID
    >> >> >
    >> >> >
    >> >> >
    >> >> >
    >> >> > Josh,
    >> >> >
    >> >> > There is something I am missing. The Logout can be issued
    >> >> > only after Login
    >> >> > (authentication and the rest).
    >> >> > The session is then implied.
    >> >> >
    >> >> > Regards,
    >> >> > Julo
    >> >> >
    >> >> > Joshua Tseng <jtseng@NishanSystems.com> on 14/03/2001 03:56:45
    >> >> >
    >> >> > Please respond to Joshua Tseng <jtseng@NishanSystems.com>
    >> >> >
    >> >> > To:   Julian Satran/Haifa/IBM@IBMIL
    >> >> > cc:   ips@ece.cmu.edu
    >> >> > Subject:  iSCSI:  Logout needs ISID
    >> >> >
    >> >> >
    >> >> >
    >> >> >
    >> >> > Julian,
    >> >> >
    >> >> > Section 2.14 states that the logout command may
    >> >> > be sent on a second connection to clean up the
    >> >> > a single connection iSCSI session.  If the reason
    >> >> > code is 0 (close the session), then ISID is needed
    >> >> > to identify the iSCSI session to close.
    >> >> >
    >> >> > Josh
    >> >> >
    >> >> >
    >> >> >
    >> >
    >> >--
    >> >Mark A. Bakke
    >> >Cisco Systems
    >> >mbakke@cisco.com
    >> >763.398.1054
    >> >
    >> >
    >> >
    >> >
    >> >
    >> >
    >> >
    >>
    >
    >
    >_________________________________________________________
    >Do You Yahoo!?
    >Get your free @yahoo.com address at http://mail.yahoo.com
    >
    >
    
    
    


Home

Last updated: Tue Sep 04 01:05:20 2001
6315 messages in chronological order