RE: iSCSI: Need to Kill Session from Surviving Node

["John Hufferd" <hufferd@us.ibm.com>]

Wait a minute, I did not expect my Surviving Node question to somehow
trigger the discussion of whether the Target Reset should be issued by
iSCSI Initiators.   That is a completely different Pit.

My question was, when the Storage Controller fails over to a surviving
NODE, how do we tell the Initiator that is waiting peacefully for the
TCP/IP connection to time-out.  To quickly give-up and let the initiator's
SCSI layer, retry the operations, so that the iSCSI layer can start either
sending the SCSI cmds to the Surviving Node, or starts a new Session with
the Surviving Node.

This has nothing to do with the Initiator issuing Target Resets.



.
.
.
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


"Somesh Gupta" <someshg@yahoo.com>@ece.cmu.edu on 03/14/2001 08:25:58 PM

Please respond to <someshg@yahoo.com>

Sent by:  owner-ips@ece.cmu.edu


To:   <cbm@rose.hp.com>, <someshg@yahoo.com>
cc:   <ips@ece.cmu.edu>
Subject:  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