|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: ISID issue
David,
We spent a lot of time yesterday at the end of the Naming and Discovery
Team (NDT) meeting, trying to rectify everything that you and Jim had been
sending notes about. We tried to see if we could fully understand the
various positions. I even argued your position regarding the Target
handling out the ISID but the group beat me back with their logic. And
that Logic was included in Jim's latest Note. Sorry I could not do a
better Job of representing your position.
However, there were some other things that we batted around that I will
cover here. First, the Name which you want to work with in the iSCSI ACLs
is the iSCSI Initiator Node Name. That should be the same for ALL iSCSI
Initiators in a Host Node. If vendors attempt to use anything else, I
think they are not following the spec. And should be sent to Singapore for
Caning :-)
If you accept that HBAs should get the iSCSI Initiator Node Name passed to
it in some manner from the OS, then we did not see why it can not get the
ISID at the same time also. If one were to argue that the HBA can not get
the iSCSI Initiator Node Name, I think this is a bit strange, since almost
every thing I install in systems, has to go through some type of Wizard, or
vendor install routine that actually installs the support driver, etc.
(This is all set when the OS is fully up and the Registry etc. is clearly
available.) I would expect that with current OSs, this would be a normal
approach. In the future, I suppose it might be possible that the OSs
might have a more dynamic routine to hand out the iSCSI Initiator Node Name
and ISID so that Hot Swap HBAs could come up without effort. However,
until then, I am not sure it is unreasonable for a vendor to require the
customer to run an update routine, even after performing an HBA Hot Swap.
There is of course, the first up boot situation. I think it should be
possible to have a default, first time HBA boot Name that uses the iqn form
of the iSCSI Name, and an ISID of 0. This should be enough to bring up a
"first time up boot", since after the OS is started, the approprate install
routine should be kicked off, and the real iSCSI Initiator Node Name and
real ISID set in the Flash for that, and any other iSCSI HBAs.
So based on the above, I do not think requiring the HBAs to have an
install/update routine (which sets its Flash) is even a problem.
This means that a Single iSCSI Initiator Node Name should be easy to obtain
and will apply for all the iSCSI Initiators, whether HW or SW.
When Jim talked about the new SCSI idea that would have Persistent Reserves
being tied to the Initiator Node, it seemed clear to me, and I think to
the others on the team, that the iSCSI Initiator Node Name was ideal to be
used for that purpose. Jim pointed out, again to us, that this name was
NOT part of any other Nexus meaning, it is only to be used with Persistent
Reserves. All other Nexus meanings are against the iSCSI Initiator's FULL
NAME which is the iSCSI initiator Node Name and the ISID.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Black_David@emc.com@ece.cmu.edu on 10/03/2001 12:23:42 PM
Sent by: owner-ips@ece.cmu.edu
To: Jim Hafner/Almaden/IBM@IBMUS
cc: ips@ece.cmu.edu
Subject: RE: iSCSI: ISID issue
I'm getting ready to give up on this due to lack of interest on the list.
As near as I can tell the arguments in favor of ISIDs are:
(1) They've been in the spec for a long time.
(2) Provide symmetry in session identification and a clean mapping to SAM-2
concepts.
(3) Accommodates possible future persistent reserve functionality.
Of these, I regard (1) and (2) as weak, and will explain in a moment
why (3) is incorrect as things currently stand.
The arguments against are:
(4) ISID existence is the direct cause of the Option A/Option B issue
about whether setting up a connection with an existing ISID is
supposed to blow away an existing connection with the same ISID.
(5) The ISID rule does not appear to be uniformly implementable in practice
on common OS platforms via means other than (error-prone) manual
configuration. The whole notion that OS vendors will address this
sort of allocation issue just because we think they should is an
exercise in wishful thinking.
(6) Argument (3) above is incorrect, as the possible future persistent
reserve functionality will not work as expected when different
ISID values are used by the same Initiator to access Targets or
Target Portal Groups for which sharing of persistent reserves is
desired.
To correct the problem with (3), we would have to require that the same
ISID values be used across all Targets that may share an LU, which in
practice probably means all Targets as the LU sharing structure across
Targets is unlikely to be visible to iSCSI. I hesitate to write such
a rule into iSCSI now to anticipate functionality that is still in a
"to be defined" state at T10, because it will impact implementations.
Julian and Jim's comments on specification of LU mapping miss the point.
The point is that really simple consistent rules for how things work at
this basic level are necessary to get management that scales decently.
To be specific, suppose I have a reasonable sized SMP machine that has
5 Ethernet ports that support iSCSI spread across 3 HBAs and two drivers
- how many iSCSI Initiator Names have to be configured into a Target LUN
masking implementation to give that machine access to its storage from
all 5 ports?
The iSCSI answer is a long version of "it depends" that starts with "find
the iSCSI documentation for your host and each of the HBAs to see how each
of them deal with iSCSI Initiator Names". The possible values probably
range from 1-3. In contrast, the corresponding Fibre Channel answer of 5
(Port WWN for each FC port) is superior even though it's a larger number
because it's the only possible answer and all the HBAs have to work the
same way. The reason it's superior is that neither the management software
programmers nor the system administrators have to spend any mental cycles
having to think about instances of the same protocol that have to be
administered differently.
For iSCSI, the ideal answer to the above question is 1. IMHO, removing
ISIDs
visibly increases the likelihood of that actually being the case all the
time
in practice. Alternatively, if we leave ISIDs in, I'd want to see a hard
look at how to toughen the current ISID rule to prevent the problem
identified
in (6), and even then, I think the result is still less likely to lead to
the desired goal.
I think part of the difference I have with Jim Hafner is that I think he
wants to make it possible for the future target-spanning persistent
reservation functionality to work without requiring that it work (i.e.,
it'd be ok to have initiators behave in a way that reservations never
span targets, even when targets implement the new functionality). I
don't think that's good enough - if we go to the trouble of enabling
this, we should do so in a fashion that is guaranteed to work in
the presence of target support for the feature.
As I said, I'm getting ready to give up on this, because I don't see much
in the way of appreciation of the importance of scalable management and
the role of simplicity (in the extreme) in enabling it on the list.
--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
---------------------------------------------------
> Let me just reiterate more strongly Julo's comment "we may request the LU
> mapping - for iSCSI - be defined only by the InitiatorName".
> T10 has approved use of the iSCSI InitiatorName as the "TransportID" for
> SCSI access controls (lu mapping). The portnames have no direct function
> in this context for iSCSI (though they do have an indirect affect that
> isn't worth discussing here).
>
> Whether this standardized approach to lu mapping is adopted by vendors is
a
> different question, but the standard is there.
>
> The issue of port name/identity is primarily an issue for persistent
> reservations (in all its current and future forms).
>
> Jim Hafner
>
>
> Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/03/2001 10:20:53 am
>
> Sent by: owner-ips@ece.cmu.edu
>
>
> To: "ERICKSON,SHAWN (HP-Roseville,ex1)" <shawn_erickson@hp.com>
> cc: "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu,
> owner-ips@ece.cmu.edu, santoshr@cup.hp.com
> Subject: RE: iSCSI: ISID issue
>
>
>
>
> I agree that LU mapping might be tricky but topology mapping is not
> affected by ISID allocation. You have to get a consistent
> mapping of target
> ports (and the model does that) and Initiators that know how to reach
> targets. Initiators have to know the physical identity of the
> portal when
> they open the connection (or they can get it through a local
> service) and
> the ISID has no role in topology mapping.
>
> I would also say that for any practical purpose we may request the LU
> mapping - for iSCSI - be defined only by the InitiatorName
> part of the
> InitiatorPortName.
>
> Julo
>
>
>
>
> "ERICKSON,SHAWN
>
> (HP-Roseville,ex1)"
> To:
> <shawn_erickson@hp.com>
> santoshr@cup.hp.com,
> Sent by:
> ips@ece.cmu.edu
> owner-ips@ece.cmu.edu
> cc:
>
> "'Black_David@emc.com'"
> 02-10-01 19:25
> <Black_David@emc.com>
> Please respond to
> Subject:
> "ERICKSON,SHAWN RE:
> iSCSI: ISID issue
> (HP-Roseville,ex1)"
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Monday, October 01, 2001 3:11 PM
> > To: santoshr@cup.hp.com; ips@ece.cmu.edu
> > Subject: RE: iSCSI: ISID issue
> >
> >
> > Santosh Rao wrote:
> >
> > > I think comparisions to FC's mess-up of the node WWN are
> > not fair to the
> > > current ISID rule, since, unlike in FC, the worst case
> > scenario with the
> > > ISID rule, is that each iscsi driver on the system will take up a
> > > different iscsi initiator name.
> >
> > At least FC had the Port WWN to fall back on. This is headed for a
> > situation
> > where the iSCSI Initiator Name is unusable for access control
> > configuration
> > because whether it corresponds to the network interface, the
> > HBA (e.g.,
> > suppose
> > there are two interfaces on the HBA), the driver, or the OS image is
> > implementation-dependent. In FC it is completely
> unambiguous what the
> > Port WWN corresponds to, and that's why it's usually used for
> > LUN masking
> > and mapping solutions. We're at risk of screwing that up, e.g. ...
>
> I would like to second David's concern about not leaving
> targets with a
> deterministic way of knowing who/what the initiators
> identifier relates to.
> This is not only bad for access control mechanisms but it
> make topology
> mapping (and related concepts) more difficult for management software
> developers.
>
> -Shawn
>
> -------------------------------------------------------
> Shawn Carl Erickson (805) 883-4319 [Telnet]
> Hewlett Packard Company OV NSSO Joint Venture
> Storage Resource Management R&D Lab (Santa Barbara)
> -------------------------------------------------------
> <http://ecardfile.com/id/shawnce>
> -------------------------------------------------------
>
>
>
>
>
>
Home Last updated: Thu Oct 04 13:17:42 2001 7034 messages in chronological order |