- Evolution of Solaris Naming Services
- NIS and Files Coexistence
- NIS and DNS Coexistence
- Solaris Naming Service Switch
- Solaris Naming Service Switch Architecture
- NIS Architecture Overview
- NIS Client Server Architecture
- How NIS Clients Bind to the NIS Server
- NIS Maps
- NIS High Availability Architecture Features
- NIS+ Architecture Overview
- NIS+ Client Server Architecture
- How NIS+ Clients Bind to the NIS+ Server
- NIS+ Tables
- NIS+ Interaction with DNS
- NIS+ High Availability Architecture Features
- Solaris DNS Architecture Overview
- DNS Client Architecture
- DNS Server Architecture
- DNS High Availability Features
- LDAP Architecture Overview
- LDAP Information Model
- LDAP Naming Model
- LDAP Functional Model
- LDAP Security Model
- LDAP Replication
- Comparison with Legacy Naming Services
Replication is the mechanism by which directory data is automatically copied from one directory server to another. Using replication, you can copy anything from entire directory trees to individual directory entries between servers. Beside providing high data availability, some additional benefits include:
Higher performance By replicating directory entries to a location close to your users, you can vastly improve directory response times.
Load balancing By replicating your directory tree across multiple servers, you can reduce the access time load on any given machine, thereby improving server response time.
Local data management Replication allows you to own data locally and share it with other directory servers across your company.
To understand how replication works, you must first understand the roles LDAP servers play. To begin, every directory object must be mastered by one and only one directory server. The mastering directory server is called the Supplier server because it supplies the objects to other servers. Servers that receive directory objects from supplier servers are called Consumer servers.
Any given directory server can be both a supplier of directory objects as well as a consumer of objects supplied to it from other servers. In future releases of iPlanet Directory Server, multi-master replication is supported which allows directory data to be updated by more than one server.
A Supplier server is responsible for the following:
Managing any requests for changes to the replicated directory data. That is, whenever a request to add, delete, or change an entry in a replicated tree is received by a Consumer server, the request is referred to the Supplier server where the request is actually performed.
Tracking the changes to the objects that it masters so that those changes can be replicated to Consumer servers.
You can configure the Supplier server to initiate replication, or you can configure your Consumer server(s) to initiate the replication process.
Consumer servers contain at least one directory entry that has been copied to it by a supplier server. Consumer servers can contain the following:
The Supplier server's entire tree.
A subsection, or subtree, of the Supplier server's directory tree.
Only read operations occur on the Consumer server. All other operations are handled on the Supplier server. Whenever an LDAP client tries to modify entries in a replicated tree, the Consumer server automatically refers the LDAP client's request to the supplying server.
FIGURE 2-9 Full Tree Replication
FIGURE 2-10 Subtree Replication
You choose which form of synchronization is used for each replication agreement. Replication synchronization can be initiated by either the Supplier or the Consumer server. A replication agreement indicates which directory entries will be replicated, which servers are participating in the replication, and when the replication can occur.
To decide on a synchronization method, follow these guidelines:
If you want your consumer servers to be updated instantly, use Supplier-initiated replication.
If you are using a dial-up connection to update your Consumer servers, use Consumer-initiated replication.