Directory Primer: What Is a Replica?
Articles and Tips: article
Senior Editor
DeveloperNet University
nmclain@novell.com
01 Sep 2000
Discusses the purposes of replication in Novell Directory Services, explains the different types of replicas, and provides guidelines for placing replicas in your NDS tree.
In Novell Directory Services (NDS), a partition is a logical structure. The physical copy of a partition is called a replica. If your network has more than one NDS server, you can replicate the NDS directory. Replication simply means that your network has more than one copy of the directory data. NDS automatically keeps all the copies up-to-date, or synchronized.
Keeping multiple copies of the directory lets users continue to log into the network and use the remaining network resources if particular servers or network links fail. A partition can have multiple replicas; but only one replica of a particular partition can exist on a server. Servers can hold more than one replica, as long as each replica is of a different partition. The group of replicas that each server holds is called a replica list or replica ring.
NDS replication is not a backup solution for your data. The replication and synchronization processes only replicate information about NDS objects. NDS doesn't replicate any information except that which is stored in the directory. You will need to back up your data files in order to protect information that isn't associated with NDS objects, such as files and documents.
Why Use Replicas?
Replicating your data serves three purposes:
Fault tolerance. If a server holding a replica goes down, users can use another replica on another server. Their network access is not interrupted.
Performance. Placing replicas local to the users that require the information increases the network performance. Local replicas decrease the time needed to authenticate, update, search and extract NDS information.
Name resolution. When a user requests NDS information, NDS must first locate the server that contains the information. This process is called name resolution or tree walking. If the information is not located on a server that the user is already connected to, NDS will walk the tree to locate the information and connect the user to the proper server.
For fault tolerance purposes, the NetWare 5 installation program helps you replicate the NDS partitions when you install a server. When you install additional servers, the installation program tries to place three replicas of the partition where the server object is being installed (this is performed for the first three servers that you install into a tree).
Types of Replicas
A replica can be one of four types: master, read/write, read-only, and subordinate reference.
Master Replica. A partition's master replica is always the first replica created. Each partition can have only one master replica. A master replica has these features:
Accepts updates to the NDS object and attributes. Clients can use the master replica to add, delete, and modify a partition's objects. The master replica passes these changes to the other replicas during the synchronization process. Other read/write replicas also accept changes from clients and pass them on to the other replicas during replications.
Controls all partitioning operations. Clients use the master replica to split and join partitions, move objects and subtrees, add and remove replicas and repair the replicas. The master replica locks the partition during any partition operation so that clients can do only one partition operation at a time. The master replica then updates the other replicas to complete the operation.
Conformity to the X.500 specification. The specification requires that clients use only the master replica to update the directory database.
When you create another replica, you can change the type of the previous master replica if you want to make the new replica the master.
Read/Write Replica. Read/write replicas are sometimes called "secondary" replicas. The read/write replica distributes the NDS partition information across the NetWare servers on the network for fault toleration and performance purposes. A read/write replica has the following features:
Accepts client updates to the NDS objects and properties. Read/write replicas accept changes such as, adding, deleting, and modifying a partition's objects. They also pass these changes to the other replicas during the synchronization process.
Provides fault tolerance for the partition. If a server holding a replica goes down, clients can access other read/write replicas for the information.
Increases NDS performance. You can place read/write replicas local to any users who must regularly access the partition's information.
Usually, only large networks with many servers use read/write replicas. Although you have no limit to the number of read/write replicas you can create, Novell recommends that you keep the number small and create read/write replicas only where you need them.
Read-only Replica. A read-only replica doesn't accept changes from clients. The synchronization process is the only way a read-only replica can be changed. The read-only replica has these features:
Provides access to the partition's data. Read-only replicas accepts read requests from clients. Clients can use the read-only replica to access any data that they only need to read. Clients can't modify the data that is held on a read-only replica.
Provides fault tolerance for the partition. This means that if a replica is not available to clients, they can still use the read-only replica access to any data they only need to read.
Increases NDS performance. You can place these replicas on servers that are local to the users who need to access the information.
Because read-only replicas can't be updated, they don't support login or authentication requests. The login process updates three properties on the user object: Network Address, Login Time, and Last Login time. The read-only replica won't allow any property on any object to be updated, so it won't accept login requests. It also won't accept logout requests because the logout process changes the user object's Network Address property. Read-only replicas are seldom used in production trees.
A possible use for a read-only replica would be as an off-site disaster recovery center. You could place read-only replicas of the network information on an off-site server. The read-only replica would keep itself current through the synchronization process.
Subordinate References. A subordinate reference contains only one object: the partition root object. The partition root object is the top-most object in the partition and contains information that links together the partitions in a tree. NDS places subordinate references on servers that hold a parent partition, but not that partition's child partition. The subordinate reference holds the child partition's partition root object so that NDS can locate the child partition.
Subordinate references hold no NDS object information, so users can't log in through them.
NDS creates and manages subordinate reference replicas.
How Do I Place Replicas in the NDS Tree?
Replicating the NDS database helps you distribute your NDS data throughout the servers on your tree. This means that you can provide fault tolerance for the NDS data and improve network performance by keeping the data local to the users who access it the most often. So, correctly distributing and placing the replicas on specific network servers is an extremely important responsibility.
Correct replica distribution provides fault tolerance of the network data and network efficiency. The following rules govern replica placement:
Partitions can have multiple replicas, stored on separate servers across the network.
Each partition can have only one master replica. The other replicas will usually be read/write replicas. You might occasionally have use for read-only replicas.
Servers can store multiple replicas. But, they can only store one replica of each partition. In other words, they can't store two replicas of the same partition on a server.
All replicas, regardless of type, are synchronized together.
When you place replicas in your tree, you have to keep in mind the synchronization traffic they generate. You will want to avoid synchronization over WAN links. As a quick definition, synchronization is the process by which the replicas are updated with any changes to the information they hold. During synchronization, master and read/write replicas send their updated information across the network to each of that partition's other replicas, so that eventually each replica of the partition will hold exactly the same information. By default, a replica triggers synchronization 10 seconds after it receives its first update.
Use the following guidelines to help distribute the replicas across the NDS tree:
Create replicas for fault tolerance.
Place replicas locally to the users who use the information.
Create replicas to support bindery services.
Create replicas to improve name resolution.
Create Replicas for Fault Tolerance. Creating more than one replica for each partition eliminates having a single point of failure for the partition. Putting replicas of the same partition on more than one server preserves the availability of the information if one of the servers goes down. This means that users will still be able to authenticate, log in and access the network information if one of the servers becomes unavailable. NDS will respond with the information from one of the other servers.
The NetWare 5 installation program automatically creates up to three NDS replicas for fault tolerance. When you install additional servers into the tree, the installation program creates up to three replicas of the partition the server is being installed in. If that partition has fewer than three replicas, the installation program will place a read/write replica on the new server. If that partition already has three replicas, the installation program won't automatically place a replica on the new server.
If the server being installed has an existing bindery, the installation program automatically converts the bindery to an NDS replica of the partition the server is being installed in. For example, if you're upgrading a NetWare 3.12 server, it will receive at least a read/write replica of the partition if three other replicas already exist for that partition.
This automatic replication applies only to the partition where the new server object is being installed; it doesn't affect other partitions in the tree. Automatic replication supports fault tolerance of the NDS database. If you like where the installation program places the three automatic replicas, you don't need to change the replicas for fault tolerance.
Novell recommends that you always have a master and two read/write replicas for every partition. Three read/write replicas are even better. If you place more than one replica locally to the users, you ensure that should a server fail, the users won't be forced to cross WAN links to authenticate or access their network data.
Also, be careful that you don't replicate the [ROOT] partition more than three times. Remember that every server that has a copy of a parent partition, but not its child. Partitions holds a subordinate reference replica for each of the partition's child partitions. For example, if you have five child partitions directly below [Root] and you place [ROOT] on three different servers, these servers will have a total of 15 subordinate references.
Each time you add a replica, you add five more subordinate references. So, if you have five replicas, you have 25 subordinate references. The fewer subordinate references your tree has, the easier it is to maintain. This is one of the reasons you want to have fewer partitions at the top of your tree, than at the bottom. It's easier to limit the number of subordinate references this way. If you partition heavily on the top of the tree, servers carry more subordinate references than if you partition heavily at the bottom.
Place Replicas Locally Near the Users Who Use the Information. Placing replicas on servers that are local to the users who access the information always guarantees better network efficiency. Don't place a replica across a WAN link if you have servers on the same side of the WAN link as the people who need that information. If the users access multiple partitions, place each partition on the same side of the WAN link as they are. This guarantees that they will always retrieve their network information from the nearest available server.
Whenever possible, you should also place the replica that contains the users' information on the same server that stores their home directory. This improves their access to NDS objects and properties. For example, during login, users map drives to volumes, capture print queues and access several of the user objects and properties. NDS processes each request, regardless of which server stores the replica. If NDS can find the requested information on the users' preferred server, the login speed is faster.
Although, Novell recommends that you create three replicas of each partition, you might not always find this to be the best solution. For example, Novell recommends that you place replicas on different servers in the same physical location as the master replica, which should be placed locally to the users who access it. If you must place a third replica across a WAN link because you don't have a third server at the site, Novell recommends you don't create that third replica. If you have users on the other side of the WAN link who must access that replica, then you might place it with them. Otherwise, placing a replica on the other side of a WAN link generates syncrhonization traffic that you don't really want on your network. This choice depends upon the level of fault tolerance you must maintain.
If you have a remote site with only one server, you would still partition for the local site and place the master replica on that server. You could then place a second replica at the nearest location so that you maintain fault tolerance. This can work well because a remote site with only one server usually contains only a small number of user objects. So, in this case it's better to synchronize your replicas across a WAN link than lose the information if the server goes down.
Create Replicas to Support Bindery Services. Bindery services requires a read/write or master replica on the server that sets the server bindery context. Bindery services provides backwards compatibility for bindery applications and users. Bindery services enables both NDS client and bindery-based clients to access the objects in a container. The server bindery context is also referred to as the bindery path. Once you set the bindery context, bindery-based clients and servers can access the object that is subordinate to the containers where the bindery context is set. You must set a bindery context for each container object that you want bindery-based clients and servers to be able to access. You don't have to set a bindery context for containers held by the container you've set a context for.
Bindery services enables NetWare 4 and 5 servers to respond to the bindery calls made by bindery-based utilities and applications. So, when you are upgrading a NetWare 3 server to NetWare 5, NDS creates a read/write replica of the partition and places it on the upgraded NetWare 5 server, regardless of whether the partition already has three replicas. NDS assumes that because the server is being upgraded from NetWare 3, it will need bindery services.
Create Replicas to Improve Name Resolution. In order to find an object's location, NDS walks the tree to the container where that object resides. This is called name resolution. If the object is not stored on a local server, NDS searches the directory tree to find the servers that have the object. Every replica has a set of pointers to all the other replicas of that partition. NDS uses these pointers to locate the partitions that are above and below that partition in the directory tree.
To speed up the name resolution process, and to speed access to the appropriate server, you can place replicas closer to that server. For example, if users will try to access information on the opposite side of the tree, NDS must access the [ROOT] partition in order to go back down the tree. In this case, you can replicate [ROOT] partition to your company's major hub site.
Novell recommends replicating the [ROOT] partition only if it is a small partition, and you replicate it only a few times. The [ROOT] partition should include just the [ROOT] object and the topmost object. Remember that you get subordinate references to everyone of [ROOT]'s child partitions on any server that you place the [ROOT] replica. For this reason, you also shouldn't replicate [ROOT] more than three times.
You can place [ROOT] partition replicas across WAN links because it is usually static and doesn't generate much synchronization traffic. So, placing a replica of the [ROOT] partition at key hub sites in your network infrastructure assists name resolution and doesn't generate unnecessary synchronization traffic across the WAN link.
If your company has many single server remote offices, you might find a "DSMaster" server useful. This is a server that just stores NDS replicas. The DSMaster server gives you a place to store additional replicas for the partitions of remote offices.
The ultimate determining factor in determining the number of replicas to place on a server is the time it will take that server to synchronize the replicas on it. You want the replicas to synchronize in less than 30 minutes. The following factors affect the syncrhonization time on a server:
Server's CPU speed
Number of replicas
Number of objects in each replica
Size of each replica ring
Location of the replicas (local or remote)
WAN links speed
Amount of RAM on server
Frequency of inbound replica synchronizations
Summary
One of the main keys to an efficient directory operation is the placement of the partition replicas. Remembering to keep the information close to the users so that they don't have to cross WAN links to access it, and remembering to prevent as much synchronization traffic from going across the WAN links as possible helps you keep your directory operating efficiently.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.