RE: iSCSI: Need to Kill Session from Surviving Node

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

Target Reset have value, but not as an in-line command.  It is a management
function, not a recovery function from a single initiator, and as such
should be up to the implementation to see how the accomplish the Target
Reset via there own admin facility.

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


"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 03/14/2001 07:31:29 PM

Please respond to cbm@rose.hp.com

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


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