Re: iSCSI: Need to Kill Session from Surviving Node

["Mallikarjun C." <cbm@rose.hp.com>]

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