ken@gvax.cs.cornell.edu (Ken Birman) (11/21/89)
This posting is a followup on the yellow pages redesign "homework problem" I posted 10 days ago. Based on the comments I've seen and the two posting from readers on this subject, there seems to be a consensus on a few issues: 1) The YP architecture as SUN designed it doesn't scale well, and people are seeing this as a problem. 2) Something capable of supporting faster updates is needed. I see this as arguing for the following architecture: The "YP service" should be hierarchical at several levels: 1) Multi-enterprise. At this level the YP services for places like Cornell, MIT, IBM, DEC talk to each other. It isn't clear what they would "export", but obviously this will be a small subset of what YP manages internally to each site. 2) Multi-LAN. At this level, one envisions multiple smaller YP service groups concerned with providing services local to a small number of machines. 3) Single YP server group. Any given client is supposed to be "bound" to a particular YP server in the SUN architecture; rebinding is only done if that server crashes and restarts. In our architecture we would want this server to be the main repository for information used almost exclusively by these clients, and to cache information imported from other YP server groups. On the positive side, YP has a nice organization for the information it manages -- I like the idea of saying that it works with what seem to be "files" with a query interface on each file. Some comments suggest that other people see this as overly restrictive, but I need to understand what alternatives are proposed... So, getting concrete, we now want to design a YP server group with the following characteristics: 1) It uses the YP protocols to talk to clients. 2) There are normally 3 or 4 YP servers in a group; they maintain some "part" of the global YP database. 3) The YP servers at the mult-LAN level know about each other and cache data for one another; jointly they have a location name like "cs.cornell.edu" that covers them as a set. 4) YP servers can interact at the mutli-enterprise level for queries that explicitly reference remote data, e.g. "/etc/services/isis/bcast@cs.cornell.edu" the default for a given client is to search within his local area... Does this sound like a promising architecture? What limitations do people see if we pursue this? Note that the idea is to extend the current YP name interface to "hide" the locality of a reference in the name, so that the current name structure won't need much redesign. -- Ken
sylvain@burden.chorus.fr (Sylvain Langlois) (11/25/89)
In article <34463@cornell.UUCP> ken@gvax.cs.cornell.edu (Ken Birman) writes:
KB> Based on the comments I've seen and the two posting from readers on this
KB> subject, there seems to be a consensus on a few issues:
KB> 1) The YP architecture as SUN designed it doesn't scale well, and people
KB> are seeing this as a problem.
KB> [... stuff deleted]
KB> The "YP service" should be hierarchical at several levels:
KB> 1) Multi-enterprise. At this level the YP services for places like
KB> Cornell, MIT, IBM, DEC talk to each other. It isn't clear what they
KB> would "export", but obviously this will be a small subset of what YP
KB> manages internally to each site.
KB> 2) Multi-LAN. At this level, one envisions multiple smaller YP service
KB> groups concerned with providing services local to a small number of
KB> machines.
Let me throw a stupid idea here. I've been looking at improving a
Yellow Pages service using ISIS reliable and fast protocols a while
ago (job has currently returned to its ashes now :-(, sorry Ken). I
personnaly think that a faster service than Sun YP could be
implemented using ISIS. But I'm not sure about you mean with "scalability"
It seems to me that YP-like service is not suited at all for wide area
networks. Work has been done with X500, or X500-like, service. I admit
that X500 it far too complicated for handling "small" databases, but
it may be more accurate for huge volume of entries. I am not promoting
the use of X500 for solving all problems, but one may want someday to
use an ISIS-YP-based service for implementing kind of directory
services, collecting zillions (well, let say hundreds...) of entries
to implement a "domain name server".
My deep question is: do you think a YP-like service covering a campus
wide domain HAS to be the same as one covering a US wide area (this is
what I understand from your "Multi-Enterprise" environment -- unless
the Enterprise covers a galactic-wide domain, in which case you may
require some help from Spock:-)? I doubt. X500-like techniques seem to
be a better move in this latter direction (cf. NYSERnet experiments
with White Pages).
KB> Does this sound like a promising architecture? What
KB> limitations do people see if we pursue this? Note that the
KB> idea is to extend the current YP name interface to "hide" the
KB> locality of a reference in the name, so that the current name
KB> structure won't need much redesign.
I clearly a performance problem if the area covered by the service
goes to wide. The nature of the information which may be used by
wide areas services may also be of very different types (not only
/etc/passwd or /etc/services, but more sophisticated records): I don't
the YP is able to handle that correctly.
Sylvain
--
----------------
Sylvain Langlois "Dogmatic attachement to the supposed merits
(sylvain@chorus.fr) of a particular structure hinders the search
(sylvain%chorus.fr@mcsun.EU.net) of an appropriate structure" (Robert Fripp)