|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Need to Kill Session from Surviving NodeSomesh, 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 |