NetWare Directory Services, Part Two

team lib

In "NetWare Directory Services, Part One," the Tutorial began to explore Novell's NetWare Directory Services (NDS). That tutorial covered much of the basic NDS terminology and examined NDS' hierarchical structure, which resembles an inverted tree. This chapter explores the information in the NDS directory tree, which is distributed and replicated across the network.

The NDS directory is distributed for two major reasons: security and performance. Just as with the NetWare bindery, used in NetWare 3.x and earlier versions, the directory is the repository of all the information NetWare has about users, and it uses that information to control access to NetWare resources. If the directory were lost, no one, including the network supervisor, would be able to log in to the network. Thus, it's important to have more than one copy of the directory, just in case something happens to the original.

Performance, too, is improved by replicating the directory, particularly in wide area networks. If someone were to log in on a network segment that didn't hold the directory, it could take some time to authenticate the user . Having a copy of the directory reside in each LAN segment eliminates the performance issues.

Break It Up

For large networks, which have a correspondingly large directory, it could be unwieldy to simply have replicas of the entire directory database stored in many different places. Instead, NDS uses a distributed approach, in which the overall database is broken into portions known as partitions. (Don't confuse directory partitions with disk drive partitions, however.)

Directory partitioning lets NDS distribute portions of the NDS directory database among the various NetWare 4.x file servers in the internetwork. This arrangement means each file server isn't burdened with storing the entire directory database; a given file server might have only a single image of a directory partition, known as a replica of the partition.

Figure 1 is an example of how a directory tree might be partitioned, and how partitions are created by default, during the installation of NetWare 4.x file servers. In this figure, the partitions are the areas with a white background. Each partition consists of a container object and all objects contained within it.

click to expand
Figure 1: Here is an NDS directory tree with two partitions. The first NetWare 4.x server to be installed is the one on the left, so the installation creates the partition on the left. When a second server is installed later, a new partition is created.

It's Automatic

When the first NetWare 4.x file server is installed, the NetWare installation program will automatically create the first partition. The Root object is always included in the first partition.

Whenever an additional NetWare 4.x server is installed in a new container object, the installation program will, by default, create a new partition. This step is also illustrated in Figure 1.

As mentioned earlier, a partition replica is a copy, or image, of a partition. Only one master replica can exist for each partition, but you can also have other types of replicas, known as read/write replicas and read-only replicas. You can have as many of these replicas as you want.

You can view, but not modify, directory information in a read-only replica. Thus, NDS could consult a read-only replica to authenticate a user logging in to the network. Read/write replicas can be updated, so a network manager could add or delete objects within a partition using a read/write replica. Changes to a partition itself, however, can only be made by operating on the partition's master replica. A network supervisor would use the NetWare administrator graphical (Windows-based) utility or the text-based partition manager utility (for DOS-based workstations) to manage partitions and replicas.

The installation program places a master replica of the partition on the first server installed in a container object. If additional servers are installed in the same container object, the installation program places a read/write replica on those servers. By putting two or more servers into a container object, you automatically provide fault tolerance for that directory partition.

When you install a NetWare 4.x server, the installation program checks the network segments to which the server is connected. If it detects existing NDS directory trees, it accumulates the names of these trees. Then you have the option to make the new server part of whichever trees you select.

Once you've told the installation program which directory tree you want the server installed in, you then specify what the server's context, or location, in the directory structure, should be. You can specify a context that's within an existing directory partition or choose a new context. In the latter case, the installation program will create a new container object matching the new context, create a new partition, place the container object into the partition, create the new server object (the NetWare 4.x file server you're installing), and place the server object into the newly created container object. It will also create a master replica of the new partition, placing it on the new file server.

Is It Consistent?

To ensure that read/write replicas and read-only replicas are up to date with respect to their master replicas, servers holding NDS partition replicas frequently compare notes to check for inconsistencies. Any replica that is out of date gets updated from the master replica.

How does a server know if a replica is out of date, compared to its master? Apparently, replicas get time and date stamps, just as conventional files do, and any replica with a time stamp older than its corresponding master replica gets updated.

What Time Is It?

It's therefore crucial that all NDS servers be synchronized with each other. In fact, this task is so important that Novell offers several different strategies you can pick from to keep all your servers in sync.

In the single-reference time server model, only one server in the entire directory tree is designated as the time server. If you elect to use this model, you designate all other servers as s econdary time servers. Secondary time servers periodically synchronize themselves with the single-reference time server. When network clients log in, they will have their clocks synchronized to the "nearest" secondary server (or to the single-reference time server, if that happens to be the nearest server).

Servers can use either Novell's Service Advertising Protocol (SAP) to share time information, or servers can be custom-configured to contact specific servers for time updates. The simplest approach (and the default) is to use SAP. For large networks, where frequent SAP broadcasts would be a nuisance, Novell recommends the custom-configured method.

Without going into all the details related to time synchronization, assume that if yours is a small network with only a handful of servers, the single-reference time server with SAP communications should probably be your choicethat's the default. For large networks, particularly those with WAN connections, you'll want to carefully study the NetWare documentation to plot your time synchronization strategy.

Deja Vu?

Now for a short digression: Some years ago, a Macintosh networking product named DataClub came to market. DataClub was a "virtual server" that could substitute for an AppleShare server. It represented a clever blending of the peer-to-peer and client-server conceptual models, as data files resided on individual users' Macs throughout the network, yet the DataClub server appeared as an icon on the Macintosh desktop as if it were a single disk volume.

The tough technical problem that DataClub's designers had to tackle was how to build and maintain a distributed directory that could keep track of all those files. The solution: Each Mac that participated in the data "club" had a copy of the directory for the DataClub volume.

This solution presented a problem of its own, however, as any time you distribute a copy of something throughout a network you run the risk that some of the copies aren't in sync with the original. One way to make sure everything is in sync is to immediately update all copies the moment the original changes. But this approach could really slow file access to a crawl. Moreover, Macs that happen to be turned off during a directory update would miss the update and be left with old information.

It's A Little Fuzzy

The DataClub designers' solution was to design a system where individual Macs on the network would periodically exchange directory information to get copies of the directory in sync again. The designers referred to this technique as "fuzzy consistency." In other words, at any given moment, one or more copies of the directory might be inconsistent, but over time the system tended toward consistency. It was a clever and technically innovative solution to a messy problem.

It wasn't long before the company that developed DataClub was acquired by Novell. Novell still sells DataClub for the Macintosh. [Editor's note: as of 1994not in 2003.]

There are some differences between DataClub's directory of files and the NDS directory of network resource objects. For one thing, each Mac running DataClub has an entire copy of the DataClub volume directory, whereas with NDS the total NDS directory tree is broken up into partitions, so each server need not maintain a copy of the entire directory tree. This approach is probably appropriate, as the DataClub method is best for small networks, while NDS can work with very large networks.

Still, the way that replicas of NDS partitions periodically get updated from master replicas is eerily similar to the way DataClub directory copies get updated. Is DataClub's "fuzzy consistency" one of the enabling technologies behind Novell's NetWare Directory Services? I wonder .

This tutorial, number 68, by Alan Frank, was originally published in the April 1994 issue of LAN Magazine/Network Magazine.

 
team lib


Network Tutorial
Lan Tutorial With Glossary of Terms: A Complete Introduction to Local Area Networks (Lan Networking Library)
ISBN: 0879303794
EAN: 2147483647
Year: 2003
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net