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



    Mallikarjun,
    
    I am not disagreeing with the desire to do a graceful
    termination. However, when recovery states at the TCP
    level, and at the iSCSI level get intertwined with this,
    it is probably better to focus on a clean (possibly graceful)
    termination and a clean bringup.
    
    Somesh
    
    > -----Original Message-----
    > From: cbm@core.rose.hp.com [mailto:cbm@core.rose.hp.com]On Behalf Of
    > Mallikarjun C.
    > Sent: Wednesday, March 14, 2001 7:31 PM
    > To: someshg@yahoo.com
    > Cc: ips@ece.cmu.edu
    > Subject: 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
    > >
    > >
    >
    
    
    _________________________________________________________
    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