Any naming context held in the data store, including replica naming contexts, can be replicated to another server. The slapd daemon can be configured to provide replicated service for a data store using slurpd, the directory server update replication daemon. See Chapter 2, "Commands Reference" in the section entitled "slurpd" for command-line descriptions about replication.
The load of processing requests generated by directory service clients for the same can be shared between several directory servers. This is done by defining a replica, or slave, server to provide an alternative access point to the directory service for clients. A master naming context can have more than one replica naming context. FIGURE 4-2 shows a master server with two replica servers.
Replication is the process by which changes in the master data store are propagated to all the replica naming contexts. You can replicate an entire naming context, a subtree, or a particular entry. You can replicate the entire content of an entry or you can specify a subset of attributes to be replicated.
Using replication has the following advantages:
|
|
The load on the master server can be reduced by diverting traffic to other servers. |
|
|
Copies of data can be stored where it is mostly frequently used to reduce network traffic. |
|
|
Multiple copies of the data can be stored, but the data is maintained from a central location. |
|
|
Replication can be timed to happen when the network is least busy. |
|
|
Only the data that is required by clients of the replica server needs to be copied, if you know the requirements of those clients specifically enough. You may be able to tailor a replica exactly to the needs of a specific client. By reducing the number of entries replicated, network traffic caused by replication updates can be reduced. |
|
|
A "public" replica server containing information that is not confidential could be maintained, allowing greater access to this information than you usually allow for other servers. For example, you could create a server containing the email addresses for the sales and support staff who deal with current products but not the research staff working on future products, and make it available to the sales staff of a partner company. |
Note - You could provide the same partial view of directory information with appropriate access controls. However, using a partial replica on a dedicated machine ensures that you are not providing access to your entire network. For extra security, you could connect the replica server to your network only while the replication update is in progress.
The negative impacts of using replication are:
|
|
Additional network traffic caused by replication of data. However, though there may be an overall increase in traffic, more of the traffic will be local, so you can avoid known network bottlenecks for inquiry traffic. Also, you can time replication updates for when the network is least busy. |
|
|
Information retrieved from replicas may be out of date if replication has not happened since an update, so certain applications may always need to query the master data store. |
|
|
You cannot modify a replica. All updates must be performed on the master copy of an entry. |
Information from a master naming context is propagated to a replica by the slurpd daemon. The slurpd daemon can run permanently, so that updates to directory information are propagated immediately, or you can define a synchronization schedule. You can override the schedule at any time and trigger an immediate synchronization. This is useful if you change a large number of entries and do not want to wait for the next scheduled synchronization.
The slurpd daemon uses the LDAP protocol to update a replica naming context. A master naming context for which a replica is defined maintains a replication log. Each time the master naming context is updated, the transaction is recorded in the replication log. When the slurpd daemon next runs, it reads the replication log and sends the change to the slapd server that holds the replica naming context.
The slapd server handles update requests from slurpd in the same way that it handles all requests, using the information supplied in the bind request to set the access level granted to slurpd requests. To guarantee that all replication updates are completed, slurpd must bind with the DN defined when the replica naming context was configured. If a different DN is used, write access for all entries may not be granted.
A replica data store always has a referral pointing to the master data store. If a replica server receives a request to modify an entry, it returns a referral to the client, indicating the master server to be contacted. In some cases, the client software handles the referral automatically and the user need not resubmit the query. Once the modification has been made in the master naming context, the change is sent to the replica naming context the next time the slurpd daemon runs.
TABLE 4-3 lists the naming contexts in the XYZ Corporation DIT and the servers that store them. In addition, the network management team decide to establish several replica naming contexts:
|
|
All servers will contain a replica of ou=Boston, o=XYZ, c=US, for fast access to entries concerning the headquarters of the corporation. Only ussales, eursales, and rowsales get their replicas directly from the boston server. The other servers get a replica of the replica from the server that is closest in the network. |
|
|
A second server, eursale2, will hold a complete replica of ou=Euro-Sales, o=XYZ, c=US, to share the load on the existing eursales server. |
|
|
Each of the servers at the distribution centers will hold complete or partial replicas of the other distribution center naming contexts. For example, the atlanta server will hold a complete replica of ou=London-Dist, o=XYZ, c=US, and a partial replica of ou=Tokyo, o=XYZ, c=US, containing the information about the distribution center but not about the sales office. |
TABLE 4-1 shows the replication strategy for each server in the XYZ Corporation directory service.
TABLE 4-1 Replication Strategy for the XYZ Corporation