Replicas

If you have more than one NDS server on your network, you can keep multiple replicas (copies) of the directory. That way, if one server or a network link to it fails, users can still log in and use the remaining network resources. See Figure 20. For a complete discussion of replicas, see Managing Partitions and Replicas.

Figure 20

We recommend that you keep three replicas for fault-tolerance of NDS (assuming you have three NDS servers to store them on). A single server can hold replicas of multiple partitions.

A replica server is a dedicated server that only stores NDS replicas. This type of server is sometimes referred to as a DSMASTER server. This configuration is popular with some companies that use many single server remote offices. The replica server provides a place for you to store additional replicas for the partition of a remote office location.

NDS replication does not provide fault tolerance for the server file system. Only information about NDS objects is replicated. You can get fault tolerance for file systems by using the Transaction Tracking System^TM (TTS^TM), disk mirroring/duplexing, RAID, or Novell Replication Services^TM (NRS).

A master or read/write replica is required on NetWare servers that provide bindery services.

If users regularly access NDS information across a WAN link, you can decrease access time and WAN traffic by placing a replica containing the needed information on a server that users can access locally.

The same is true to a lesser extent on a LAN. Distributing replicas among servers on the network means information is usually retrieved from the nearest available server.

Replica Types

NDS supports the types of replicas in Figure 21.

Figure 21

Master Replica

By default, the first NDS server on your network holds the master replica. There is only one master replica for each partition at a time. If other replicas are created, they are read/write replicas by default. For more information on partitions, see Partitions.

If you're going to bring down the server holding a master replica for longer than a day or two, you can make one of the read/write replicas the master. The original master replica automatically becomes read/write.

A master replica must be available on the network for NDS to perform operations such as creating a new replica or creating a new partition.

Read/Write Replica

NDS can access and change object information in a read/write replica as well as the master replica. All changes are then automatically propagated to all replicas.

If NDS responds slowly to users because of delays in the network infrastructure (such as slow WAN links or busy routers), you can create a read/write replica closer to the users who need it. You can have as many read/write replicas as you have servers to hold them, although more replicas cause more traffic to keep them synchronized with each other.

Read-Only Replica

Read-only replicas receive synchronization updates from master and read/write replicas but don't receive changes directly from clients.

Filtered Read/Write Replica

Filtered read/write replicas contain a filtered set of objects or object classes along with a filtered set of attributes and values for those objects. The contents are limited to the types of NDS objects and properties specific in the host server's replication filter. Users can read and modify the contents of the replica, and NDS can access and change selected object information. The selected changes are then automatically propagated to all replicas.

With filtered replicas, you can have only one filter per server. This means that any filter defined for a server applies to all filtered replicas on that server. You can, however, have as many filtered replicas as you have servers to hold them, although more replicas cause more traffic to keep them synchronized.

For more information, see Filtered Replicas.

Filtered Read-Only Replica

Filtered read-only replicas contain a filtered set of objects or object classes along with a filtered set of attributes and values for those objects. They receive synchronization updates from master and read/write replicas but don't receive changes directly from clients. Users can read but not modify the contents of the replica. The contents are limited to the types of NDS objects and properties specific in the host server's replication filter.

For more information, see Filtered Replicas.

Subordinate Reference Replica

Subordinate reference replicas are system-generated replicas that don't contain all the object data of a master or a read/write replica. Subordinate reference replicas therefore don't provide fault tolerance. They are internal pointers that are generated to contain enough information for NDS to resolve object names across partition boundaries.

You can't delete a subordinate reference replica; NDS deletes it automatically when it is not needed. Subordinate reference replicas are only created on servers that hold a replica of a parent partition but no replicas of its child partitions.

If a replica of the child partition is copied to a server holding the replica of the parent, the subordinate reference replica is automatically deleted.

Filtered Replicas

Filtered replicas contain a filtered set of objects or object classes along with a filtered set of attributes and values for those objects. For example, you might want to create a set of filtered replicas on a single server that contain only User objects from various partitions in the NDS tree. In addition to this, you can choose to include only a subset of the User objects' data (for example,. Given Name, Surname, and Telephone Number).

A filtered replica can construct a view of NDS data onto a single server. To do this, filtered replicas let you create a scope and a filter. This results in an NDS server that can house a well-defined data set from many partitions in the tree.

The descriptions of the server's scope and data filters are stored in NDS and can be managed through the Server object in ConsoleOne.

A server hosting one of more filtered replicas has only a single replication filter. Therefore, all filtered replicas on the server contain the same subset of information from their respective partitions. The master partition replica of a filtered replica must be hosted on an NDS server running NDS eDirectory 8.5 or later.

Filtered replicas can:

Reduce synchronization traffic to the server by reducing the amount of data that must be replicated from other servers.
Reduce the number of events that must be filtered by DirXML
Reduce the size of the directory database.
Each replica adds to the size of the database. By creating a filtered replica that contains only specific classes (instead of creating a full replica), you can reduce the size of your local database.

For example, if your tree contains ten thousand objects but only a small percentage of those objects are Users, you could create a filtered replica containing only the User objects instead of a full replica containing all ten thousand objects.

Other than the ability to filter data stored in a local database, the filtered replica is like a normal NDS replica and it can be changed back to a full replica at any time. For more information on setting up and managing filtered replicas, see Setting Up and Managing Filtered Replicas.