RE: iSCSI: ISIDs

["Jim Hafner" <hafner@almaden.ibm.com>]

Julo,

I think you're interpretation isn't quite correct (at least as I've
proposed the model).  Your definition of the Target Portal Groups is
correct with respect to the iSCSI model except that they are not
necessarily physical entities - e.g., I could have one or more target
portal groups which are strictly software constructs.  In the mapping to
SAM-2, the Target Portal Groups are associated to the SCSI target ports and
an I_T nexus then must have a relationship to a named Target Portal Group
(the T).  It only be "recreated" with the same "I" and the same "T".
However, as I indicated in the other note, Target Portal Groups are still
only logical entities (as are the nics that hold ipaddresses).   So, the
tight relationship to a physical component need not be rigid and
fundamentally, the recovery you want is possible, though it isn't trivial.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/11/2001 01:14:34 am

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


To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   "ips" <ips@ece.cmu.edu>
Subject:  RE: iSCSI: ISIDs




Jim,

For reason that must be evident by now we are then attacking the wrong
issue.
Multi HBA targets are/will be common and not I was under the impression
that the persistent items are related to the initiator-name+ISID (the draft
states it in more than one place) and we can recapture them at any target
port.
If that is not so HA will have another hurdle to handle and an ugly one at
that.

My impression when reading the model was that portal groups are (the
physical entity) are there to let us know which HBA elements are there that
are willing to coordinate between then things that have to be coordinated
within a session and that the target will create  an I_T nexus that
logically inherits everything based on IName+ISID regardless of the TSID it
assigns for local uniqueness.

As an I_T nexus is a logical entity we can still map it to a session and
the SAM model is preserved.

Julo

Jim Hafner@IBMUS
10-09-2001 18:35

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
From: Jim Hafner/Almaden/IBM@IBMUS
Subject:  RE: iSCSI: ISIDs  (Document link: Julian Satran - Mail)

Julo,

Unfortunately, the way things are modeled now, it is impossible to recreate
a session on a different target portal group and inherit all the same
properties.  The reason is that at least some of the properties are bound
to the I_T nexus and the "T" is the portal group.  If you request a change
to a different portal group, you've changed the "T" and so an equivalent
nexus cannot be built.

With what we have today, I can claim to a different target portal group
that I'm the same "I" in a previous I_T nexus, but that's about all.  (And
there-in lies the root of the "reservations kicker"!).



Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/10/2001 02:05:33 am

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


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: ISIDs




David,

This relatively complicated and hard to discuss on the mailing list. During
a flight I made a summaryY.
allocating to vendors is not a good idea and failover of an entire session
should be possible between portl groups.

Portal groups are meant to delimit connections that cooperate within a
session.

If a session on PGa goes away you may want to reinstate a session on PG b
ineriting the same properties.

There is nothing to prevent you now to do it (and that is good). The ID
splitting can get a bit skewed.

The same will happend whatever sheme you choose and vendors certianly don't
have to get involved.

Julo

Black_David@emc.com on 10-09-2001 09:16:39

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: ISIDs



One more whack at this ...

> The major difference is "control". In the current scheme the initiator
and
> target could independently allocate and reuse their parts.
>
> The target allocates only scheme leaves this to the target (it has to do
> garbage collection) under the assumption that the target (unlike the
> initiator) has a central point of control.

Yes, I'm assuming that targets will have a single vendor in charge
of all the software on the target and making it work right if there are
multiple HBAs; I don't see any corresponding vendor who's in a position
to do the same for the initiator ...

> Aren't targets going to have several HBA and have to carefully allocate
> their SSIDs?

But they'll have one vendor in charge of making this work.  In contrast,
for an initiator with HBAs from two different vendors, both of those
vendors and the vendor of the OS platform have to be involved, and I
don't see any of them taking full responsibility in the early going.
I'm worried we risk heading the iSCSI Initiator Name down the same
path as Fibre Channel, where the FC Node WWN was supposed to be associated
with the server into which the HBAs were plugged, but got associated
with the HBA because there was no way to coordinate across HBAs.
If anything ever goes wrong with ISIDs (and things will), the fastest
way to fix it will be to require each HBA to have its own iSCSI Initiator
Name, independent of the intent of the iSCSI naming architecture.

> In the event an initiator wants to rebuild a session does he have to
> connect to the same HBA and thus a failover to another HBA
> can't be done.

No, this is controlled by portal groups.  To failover across two HBAs
on the target, they have to be in the same portal group, and the target
is responsible for coordinating TSID usage within each portal group.
If the target can't coordinate TSID usage, it puts the HBAs into different
portal groups and gives up this failover ability as a consequence, and
that's the case independent of whether ISIDs exist or not.

> For all the above no to happen we have to add some management somewhere
and
> it looks to me that the current scheme is simpler than a target centric
one
> as it keeps the allocation and release of numbers at the same end.

I'm sorry, that doesn't parse for me.  It looks like the same sort of
mechanism is being put into both initiators and targets for symmetry,
without considering whether two instances of the mechanism are actually
necessary.  In a target-centric scheme, the target is doing the "allocation
and release" of numbers.  The target does have to be careful about not
aggressively reusing TSID values, when there's potentially recoverable
state around (or the initiators may think that there's state to be
recovered even though the target's lost it all in a reboot), but recall
that aggressive reuse of ISIDs is what created the Option A/B/C mess
(and not aggressively reusing ISIDs would make that easier to solve).
I don't understand how two instances of similar mechanisms is "simpler"
than one.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------