Alan Frayer, CNE, CNI, CIW CI, Net+, MCP

Vote for us at the sites below:

Q. I feel like an idiot.  I understand and can explain a bindery database structure as used in the NetWare 3.12 and Windows NT worlds.  How do I understand/explain directory services other than the fact they are distributed databases? Maybe that’s the problem...what the hell is a distributed database? Why does NetWare kick ass?

A. What you’re getting here isn’t the official answer or the marketing answer. What you’re getting is my personal opinion mixed with my understanding.

Novell Directory Services (NDS) does so well because it has done it for so long. Novell has had nearly ten years to tweak the service. Why does NDS perform better than Active Directory (AD)? I would have to refer you to Novell’s software design engineers. What I can do is try to explain what makes NDS better than a bindery.

The bindery approach was very appropriate for the server-centric environment of ten years ago. Clients needed to access resources on a specific server, and commonly they needed to reach only one server. Resources were server-centric as well, dependent on and accessible only from the server on which they were installed. On the rare occasion when resources were needed from more than one server, NetWare 3.x allowed a user to attach to as many as eight at once, but with a catch: the user had to exist on each server.

This is what the bindery required of us. For a user to use a server, the user had to have an account on that server. As our work grew more complex, the need to access multiple servers grew, as did the need to do so without having to maintain multiple user accounts. Further, users needed to reach resources independent of their locations. Along with all of this came the administrator’s need to reduce the work necessary to maintain those users and resources across a wide area network (WAN).

NDS was Novell’s answer, delivered to us with NetWare 4.0 somewhere around 1992. Rather than keep one database with the various bindery objects, a second with the properties of those objects, and a third with the values to match those properties, all on every server, independent of every other server, NDS provided us with a distributed database containing the resources for the entire network. For the purposes of this discussion, a distributed database refers to a database that allows portions of the whole to exist on various servers, to be treated by the system as if they were all in one place. This gives the administrator the means to maintain one object representing a user or other resource across multiple servers, all to be administered from a single, variable location (virtually any workstation on the network), without concern over where the resource physically resides.

Part of what makes NDS perform so well is the distributed nature. It wasn’t long after the telephone network was created before someone realized a phone directory was needed. Imagine a printed phone directory that included every telephone in the United States. Pretty big, wouldn’t you figure? Now, picture that directory sitting next to every phone in the country. Impractical, right? Besides, what are the odds of anyone in any particular locale needing to call someone in a different locale? Not great, since most phone calls are to numbers in the same local calling area as the originator. This inspired the phone company to produce local phone directories, which people could use to look up local numbers. Long distance needs could still be addressed by directory assistance.

NDS is a lot like that. Why keep a copy of the entire NDS database on every server, when users typically need to only reach resources local to them? Keeping the entire database on every server would not only increase storage requirements, but they would increase traffic, since a change made to a user account (such as logging the date and time a user logged in) would have to be distributed to every copy of the database (the way some directory services presently behave). By breaking the NDS database into pieces, and distributing those pieces to the servers near the users of those servers, the amount of storage space is smaller (servers only hold pieces, or replicas, of the NDS tree, not the whole tree) and the traffic to maintain the database is less (changes to objects only need to be written to servers hosting replicas holding the objects, rather than every server). For fault tolerance, additional copies of replicas may be placed on other servers, but at no point would every server be required to hold every replica. When a change does occur, only the changes are distributed, and only between servers holding the object in question.

So now, with NDS, we have a flexible, fast, and easily managed solution for the entire enterprise, as opposed to a system that required significant maintenance on every server in the network.

[Home] [PDA Applications] [Contract CNI] [Q & A] [Calc. Sub. Ref.] [Host-Host] [Mappings] [NDS vs Bindery] [Merging Trees] [Configuration] [NetWare Tips] [Bookstore] [PC Life] [Links] [Novell News] [Shopping Mall]