Subject: [Ips] Reservations, multiple sessions and ISID usage

From: "Alan Warwick" <[email-masked]>
Date: Fri, 12 Mar 2004 10:03:08 -0800

>From my understanding of the specifications there are these rules for
managing multiple sessions to a target

1.	Each session from the same initiator to the same target must
have a different ISID if the two sessions login to portals that belong
to the same portal group.
2.	If the sessions are logged into portals that belong to different
portal groups then the sessions may have the same ISID.
3.	When establishing a session to a target the initiator should
reuse the ISID that was previously used for a session to that target.

Given this I have a few questions

How do these rules affect the implementation of SCSI reserve and release
in a load balancing environment where there are multiple sessions to a
target ? What criteria does the target use to determine that all of the
sessions are from the same initiator for the purposes of reserve so as
to  allow load balancing to occur over the multiple sessions ?  Is it
the Initiator name plus ISID, just the initiator name, something else or
it depends ?  I would think that just using the initiator name would
make the most sense - what would be the usage scenario for using the
initiator name plus ISID ?

Lets say I have 2 sessions to different portals in different portal
groups and am using the same ISID when the target decides to merge the 2
portal groups into a single portal group. At this point my initiator is
breaking rule #1 above. How are the targets and initiators supposed to
handle this ?

Thanks,

Alan

---

From: John Hufferd <[email-masked]>
Date: Fri, 12 Mar 2004 14:39:41 -0800

Comments in line marked with /Huff/ and \Huff\
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: [email-masked]

"Alan Warwick" <[email-masked]> 
Sent by: [email-masked]
03/12/2004 10:03 AM

To
<[email-masked]>
cc

Subject
[Ips] Reservations, multiple sessions and ISID usage

1.      Each session from the same initiator to the same target must have 
a different ISID if the two sessions login to portals that belong to the 
same portal group.
2.      If the sessions are logged into portals that belong to different 
portal groups then the sessions may have the same ISID.
3.      When establishing a session to a target the initiator should reuse 
the ISID that was previously used for a session to that target.

/Huff/ 
That is correct.
 \Huff\

How do these rules affect the implementation of SCSI reserve and release 
in a load balancing environment where there are multiple sessions to a 
target ? What criteria does the target use to determine that all of the 
sessions are from the same initiator for the purposes of reserve so as to 
allow load balancing to occur over the multiple sessions ?  Is it the 
Initiator name plus ISID, just the initiator name, something else or it 
depends ?  I would think that just using the initiator name would make the 
most sense – what would be the usage scenario for using the initiator name 
plus ISID ?

/Huff/

The iSCSI specification in section 3.4.2 defines the I_T nexus identifier 
to be the tuple (iSCSI Initiator Name + 'i' + ISID,iSCSI Target Name + 't' 
+ Portal Group Tag)

 I guess the problem that I have with this question, is that you expect 
the Target to do something special.  It can not tell the difference 
between the Sessions as being from different initiators on the same host 
or from different host.  Remember all the reservations are done at the 
SCSI level, not the iSCSI level.  These different session have different 
I-T-L nexus.  These are the areas that are to be handled by the Host 
software, usually in what we call the "Wedge Drivers"  (aka MPIO, DPO, 
etc.).  We attempted to try to avoid the issues with Wedge Drivers by 
supporting the concept of Multiple Connections per Session (MP/S).  This 
was very important in environments that had several different vendor's 
Storage Controllers.  The need was to avoid the potential conflicts in 
different vendor's Wedge Drivers.  But in any event, Wedge Drivers still 
work in an iSCSI environment as they do in FC. 

In many of these Wedge Drivers, they make sure that all the I/O for a 
specific logical Unit occur on a single Logical SCSI Bus (FC WWN or iSCSI 
Session), so the issue of having the Reservations for an LU across 
different logical SCSI buses just doesn't occur.  But to the extent that a 
wedge driver attempts to "Balance" the LU I/O across these logical SCSI 
buses (e.g. iSCSI Sessions), then it (the host Wedge Driver SW) must 
handle the issues of Reserves (Not the Target).

It is best to use MC/S and avoid all those problems.
\Huff\ 
 
Lets say I have 2 sessions to different portals in different portal groups 
and am using the same ISID when the target decides to merge the 2 portal 
groups into a single portal group. At this point my initiator is breaking 
rule #1 above. How are the targets and initiators supposed to handle this 
?

/Huff/
I would strongly recommend that you stop your connections in some way 
before you do this joining of target portal groups, then update your 
discovery information, and then permit the host to rediscover the paths, 
connections and portal groups. 
\Huff\

Thanks,
Alan

---

From: [email-masked]
Date: Mon, 15 Mar 2004 11:20:07 -0800 (PST)

> initiator name plus ISID ?

As John said, the I_T nexus ID contains both the initiator name and the
ISID. The multiple connections per session route he suggested will help
here.

An alternative is to use Persistent Reservations. My understanding is the
Registrants Only reservation types will permit you to also do what you
want. You have the different sessions each register with the same
registration key, and then have one of them grab a Registrants Only
reservation (either write exclusive or exclusive access as needed).

> breaking rule #1 above. How are the targets and initiators supposed to

That's not covered in the spec. The target should only be changing the
portal group tag of a port at the request of an administrator, so issues
such as the one you describe should be avoidable in normal usage.

My guess would be that a target should log out the session (or the
connections) on the portal that is changing portal group. But that's a
guess about behavior that I expect should be vendor-defined.

Take care,

Bill

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips