SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI Naming and Discovery



    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 :-) ).
    
    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.
    
    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.
    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.
    
    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.
    
    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.
    
    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.
    
    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.
    
    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).
    - 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).
    
    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.
    
    --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
    ---------------------------------------------------
    
    


Home

Last updated: Tue Sep 04 01:06:51 2001
6315 messages in chronological order