A replica is a copy or an instance of a user-defined partition that is distributed to an eDirectory server. If you have more than one eDirectory 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 1-18).
Figure 1-18 eDirectory Replicas
Each server can store more than 65,000 eDirectory replicas. However, only one replica of the same user-defined partition can exist on the same server. For a complete discussion of replicas, see Section 6.0, Managing Partitions and Replicas.
We recommend that you keep three replicas for fault tolerance of eDirectory (assuming you have three eDirectory servers to store them on). A single server can hold replicas of multiple partitions.
A replica server is a dedicated server that stores only eDirectory 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.
It can also be a part of your disaster recovery planning, as described in Using DSMASTER Servers as Part of Disaster Recovery Planning.
eDirectory replication does not provide fault tolerance for the server file system. Only information about eDirectory objects is replicated. You can get fault tolerance for file systems by using the Transaction Tracking System™ (TTS™), disk mirroring/duplexing, RAID, or NetIQ Replication Services (NRS).
A master or read/write replica is required on servers that provide bindery services.
If users regularly access eDirectory 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.
eDirectory supports the types of replicas shown in the following figure:
Figure 1-19 Replica Types
The master replica is a writable replica type used to initiate changes to an object or partition. The master replica manages the following types of eDirectory partition operations:
Adding replicas to servers
Removing replicas from servers
Creating new partitions in the eDirectory tree
Removing existing partitions from the eDirectory tree
Relocating a partition in the eDirectory tree
The master replica is also used to perform the following types of eDirectory object operations:
Adding new objects to the eDirectory tree
Removing, renaming, or relocating existing objects in the eDirectory tree
Authenticating objects to the eDirectory tree
Adding new object attributes to the eDirectory tree
Modifying or removing existing attributes
By default, the first eDirectory 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.
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 eDirectory to perform operations, such as creating a new replica or creating a new partition.
eDirectory 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 eDirectory responds slowly to users because of delays in the network infrastructure, like 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.
The read-only replica is a readable replica type used to read information about all objects in a partition’s boundaries. Read-only replicas receive synchronization updates from master and read/write replicas but don’t receive changes directly from clients. If login update is enabled then login to read only replica fails as it involves attribute updates.
This replica type is not able to provide bindery emulation, but it does provide eDirectory tree fault tolerance. If the master replica and all read/write replicas are destroyed or damaged, the read-only replica can be promoted to become the new master replica.
It also provides NDS Object Reads, Fault Tolerance (contains all objects within the Partition boundaries), and NDS Directory Tree Connectivity (contains the Partition Root object).
A read-only replica should never be used to establish a security policy within a tree to restrict the modification of objects, because the client can always access a read/write replica and still make modifications. There are other mechanisms that exist in the directory for this purpose, such as using an Inherited Rights Filter. For more information, see Inherited Rights Filter (IRF).
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 eDirectory objects and properties specific in the host server's replication filter. Users can read and modify the contents of the replica, and eDirectory 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 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 eDirectory objects and properties specific in the host server's replication filter.
For more information, see Filtered Replicas.
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 eDirectory to resolve object names across partition boundaries.
You can’t delete a subordinate reference replica. eDirectory deletes it automatically when it is not needed. Subordinate reference replicas are created only 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 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 contains only User objects from various partitions in the eDirectory 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 eDirectory data onto a single server. To do this, filtered replicas let you create a scope and a filter. This results in an eDirectory 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 eDirectory and can be managed through the Server object in iManager.
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 eDirectory server running 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 NetIQ Identity Manager.
For more information on NetIQ Identity Manager, see the NetIQ Identity Manager Administration Guide.
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 10,000 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 10,000 objects.
Other than the ability to filter data stored in a local database, the filtered replica is like a normal eDirectory replica and it can be changed back to a full replica at any time.
NOTE:Filtered replicas by default will have the Organization and the Organizational Unit as mandatory filters.
For more information on setting up and managing filtered replicas, see Setting Up and Managing Filtered Replicas.
In addition to selecting theoption in iManager, to allow local logins to a Filtered Replica, you should also add the class ndsLoginProperties to the filter.
Before logging into the filtered replica, you must set the following attributes:
Intruder Attempt Reset Interval
Last Login Time
Locked By Intruder
Lockout After Detection
Login Allowed Time Map
Login Expiration Time
Login Grace Limit
Login Grace Remaining
Login Intruder Address
Login Intruder Attempts
Login Intruder Limit
Login Intruder Reset Time
Login Maximum Simultaneous
Network Address Restriction
Password Expiration Interval
Password Expiration Time
NOTE:The above attributes can be set on the user object, parent container or login policy.