RE: iSCSI Naming and Discovery

["Douglas Otis" <dotis@sanlight.net>]

David,

> All of this is with my WG co-chair hat off:
>
> At a high level, my concern about DNS and LDAP is based
> on Leslie Lamport's infamous (in jest) definition of
> a distributed system -- one on which he can't get
> work done because a computer he's never heard of is
> down :-).  While the sort of infrastructure services
> that run on "a computer he's never heard of" have been
> getting more and more reliable, the moral I take away
> from this is to be cautious about introducing
> dependencies on services.  Every introduced dependency
> provides new ways for things to fail, and this needs
> to be balanced against the new ways in which things
> work because of the dependency.  IMHO, NATs and IPv4/v6
> transparency don't tip the balance far enough to favor
> DNS or LDAP (but I always reserve the right to change
> my opinion :-) ).

If your system is fully dependent upon the network to even boot, then your
system is using either a BOOTP/DHCP server.  It is often the same system
that provides IP leases also handles the NIS affairs via LDAP.  You would
want a database if you wished to scale a to a large enterprise.  It is also
common to have more than two such servers visible to this booting machine
together with assists from the routers for this purpose.  If you can not
trust the network to assign your network settings and to provide you with
the requisite services, then you should install a local drive so that you
can continue to work in the dark so to speak.

> For current block storage, a host's access to its storage
> either does not depend on any external service (parallel
> SCSI, FC-AL) or a depends on the Fibre Channel fabric
> nameserver (FC-SW).  The fabric nameserver is usually
> embedded in the Fibre Channel switches, so that if the
> nameserver's not working, the switch probably isn't working
> either (e.g., in practice, if the nameserver isn't responding
> to the HBAs, the switch gets replaced).
>
> In contrast, both DNS and LDAP are external services, probably
> located on general purpose servers, on which block storage
> access currently does not depend.  LDAP in particular can be
> rather complex, as some of its leading implementations sit
> on top of full-fledged relational databases.  FWIW, the
> original design of the FC fabric nameserver was LDAP-based,
> but this was discovered to be infeasible -- an LDAP server
> doesn't embed into a switch very well, or at least didn't
> at the time.  The characterization of LDAP as "very simple"
> is significantly off the mark, IMHO.

LDAP is continuing to improve and I doubt that starting from scratch with an
alternate scheme will improve upon the present features offered.  At least
you will not need to develop additional tools.

> The discussions of DNS and LDAP on this list have had the
> flavor of these being ubiquitous completely reliable and
> available services on which dependencies are no big deal.

I have never touted DNS.  If fact, perhaps we should forbid the use of DNS
for any activity associated with SCSI.  At least DNS does not become a point
of weakness in the system then.

> When everything is working right, that may be the case, but
> everything doesn't always work right; disasters happen
> taking down entire facilities and requiring them to be
> brought up from scratch.  An example of what could go
> wrong is that two DNS servers could be configured in a
> way that each depends on the other for its storage.  If
> each server is rebooted individually to test the
> configuration, things work, but if both go down, neither
> will come back up.  This is one more problem for overworked
> system and network administrators - having to determine
> which servers must use IP names for storage vs. DNS names,
> with nasty consequences of getting it wrong.  This isn't a
> fatal problem, but every time management becomes more
> complicated, it's one more barrier to adoption.  This is
> why I don't put much weight on the argument that IP URLs
> can be used where DNS or LDAP won't work - there are too
> many opportunities to screw this up if DNS is allowed in
> general.

These few IT managers are handling hundreds and perhaps thousands of
systems.  Do not give them damaged goods when it comes to tools.  You will
short change them by providing only the tools you understand.  Maintaining a
server or router can bring down an entire company and on occasion it
happens.  Most often this happens with system patches being applied
incorrectly following a logon.  The OS is damage and is no longer accessible
to the IT manager via the network.  They then run around like mice from
cubical to cubical restoring the system.  At least with a network accessible
drive, they can make repairs from their workstation.  Most of these fellows
can bring up any system or server in minutes if you provide them the tools.
The tools that let them leverage their abilities.  And yes, that might mean
a leveraged mistake at times.

> Boot is a specific concern, because if DNS or LDAP is
> involved in locating the boot volume, then the HBA card
> BIOS has to be able to access DNS or LDAP.  There's nothing
> inherently difficult or infeasible about this, it's just
> more code in yet another place ... making it harder to
> deploy/adopt this.

Not at all.  You make it sound difficult.  It is not.  Again, the servers at
play would be DHCP and LDAP.  DNS would be an option.  Most systems within
an enterprise environment will not have access to the network without the
DHCP, LDAP or a proprietary MS scheme running.  You would not even see your
desktop unless the IT manager permitted a local account.  You will then find
most of your files missing, even the ones on the local drive, until these
servers are back up.   Don't kid yourself about not needing other servers.
As I said, most places use two of them for the reason indicated.

> Beyond this, I need to toss in a few important scattered comments.
>
> Most systems don't boot via BOOTP today; demanding that everything
> boot via BOOTP in order to avoid problems created by an entirely too
> clever naming structure sounds like a bad tradeoff.  This will lead
> to iSCSI repeating the Fibre Channel experience of boot not working
> for a long period of time after deployment of the technology.
> Customer reactions to that Fibre Channel experience have been
> negative to the point of just barely printable in some instances.

BOOTP and DHCP should be thought of as the same service with different
options.  Most in fact use DHCP. The newer and better BOOTP.  If we
standardized the class objects for SCSI under LDAP, there would not be any
confusion.  By pretending we can do better than LDAP, we will never finish
this job.

> The LDAP vs. nameserver discussion misses the point.  The Fibre
> Channel experience makes it clear that iSCSI is going to need
> some sort of central repository of configuration information to
> get the sort of discovery functionality that is expected.  That
> repository is at least a nameserver, and possibly more - the
> approach of defining LDAP schemas is the result of deciding
> to use LDAP as the communication protocol for accessing
> iSCSI nameservers.

I do not like the idea of inventing a new name server.  Let Le Gato or
Veritas send their configurations to LDAP or let the IT managers handle it
using their own set of tools.  Why make yet another server that can fail?
You worry about reliability and yet you add another server that must be
invented and therefore likely to fail for years to come.

> The [3] discussion of NATs at the end of my previous message was
> rather verbose.  The bottom line is that if IP addresses are stored
> in and distributed by a central iSCSI config repository, then NATs
> cause a problem, and a brute force solution that is likely to work
> in many cases is not to put NATs between the repository and its users.
> Alternate solutions based on application level gateways and storing
> addresses with respect to users of the repository rather than the
> repository server are workable, but more complex.

We do not need to re-invent this.  LDAP provides a solution for
communication.

> On [4], I see the following advantages of IP addresses over DNS URLs.
> - IP addresses are much better for booting, and in some cases have
> 	to be used (see above).  DNS hostnames are then an additional
> 	mechanism that adds implementation work and complicates
> 	management (see above).

Agreed.  DNS is not needed.

> - Scanning a range of possible locations of Targets has some attractive
> 	properties, because it removes the obligation of a new target
> 	to proactively make itself known to some iSCSI configuration
> 	repository (such mechanisms do work, Fibre Channel is an example,
> 	but the FC solution doesn't directly apply to iSCSI).  It seems
> 	to me that wildcarding an IP address via a mask or range works
> 	better than wildcarding some portion of a URL (e.g., if the
> 	wildcard is xyz*.abc.com, there's a fair amount of work involved
> 	in finding xyzf, xyz01, and xyz17a in the abc.com domain,
> 	by comparison to finding things that match 192.48.27.128-191 or
> 	equivalently 192.48.27.128/27).

Nonsense.  If you use just DHCP, which I will bet you dollars to donuts your
machine understands and likely uses,  these setting can be made at that time
whether there is a local drive or not.  You do not need anything more
complex.  What will do wildcarding you suggest?  Why?  You would need to map
to a boot drive that supported your architecture for one, you would need to
know what OS you wanted to run, second.  Nothing that scans through a
default list of drives will give you the results you desire.  These server
are in place and they work.  You are making this much to difficult.  Even a
simple flat file could replace an LDAP server if desired for the simple
case.  The simple case is easy to handle.  I was concerned about the
enterprise solution.

> One more note on NATs:
>
> > FTP must use the passive mode to get past the NAT.
>
> That's not correct.  There are NATs deployed that detect FTP
> traffic and rewrite the IP addresses in the FTP payloads
> to make everything work right.  The official name for
> this feature/kludge is an Application Level Gateway (ALG),
> and the FTP features that require it are generally regarded
> as an example not to be emulated.

If you don't have the kludged NAT, you can set the passive flag for FTP. No
big deal.

Doug

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