6 Understanding Oracle Internet Directory Replication

This chapter provides an introduction to Oracle Internet Directory replication. Replication is the process of copying and maintaining the same naming contexts on multiple directory servers. It can improve performance by providing more servers to handle queries and by bringing the data closer to the client. It improves reliability by eliminating risks associated with a single point of failure.

6.1 Why Use Replication?

There are many reasons to implement replication, including the following:

Local accessibility and performance requirements

Most corporations have operations in many regions in the world, and those operations need a common directory. Suppose that the regions were interconnected with low bandwidth links involving multiple intermediate routers. A client accessing a directory server from outside the region could experience a very high latency, and even inadequate throughput. In such cases, a regional replica is essential.

Load balancing

When directory access exceeds the capacity of an existing server, an additional server can share the load. Even if the deployment meets the load, it can be less costly to maintain two relatively low-end systems than one high-end system.

Failure tolerance and higher overall system availability

One of the most important reasons to implement directory replication is to increase overall system availability. When one server is unavailable, the traffic can be routed to other available servers. This can be transparent to clients.

6.2.1 Content to be Replicated: Full or Partial

One decision you must make when setting up replication is how much of the DIT to replicate from one node to another. The choices are:

Table 6-1 Full or Partial Replication

Content to Replicate

Description

Full

Propagates the entire DIT to another node.

Partial

Propagates one or more subtrees, rather than the entire DIT, to another node.

Full replication involves propagating the entire DIT to another node. This type of replication ensures the high availability of the entire directory. You can also use it to distribute operations on the entire directory among different nodes. Full replication can be based on either LDAP or Oracle Database Advanced Replication.

Partial replication enables you to propagate one or more subtrees, rather than the entire DIT, to another node. Decentralizing a directory in this way enables you to balance the workload between servers and build a highly available distributed directory, complete with fault tolerance and failover. You can set up partial replication by using command-line tools or the Replication Wizard in Oracle Enterprise Manager. Partial replication is most often LDAP-based.

6.2.2 Direction: One-Way, Two-Way, or Peer to Peer

One node is configured as the supplier and the other as the consumer. The consumer is read-only.

Two-Way

Both nodes are both supplier and consumer. They are both read/write, or updatable.

Peer-to-Peer

All nodes in a replication group are both supplier and consumer to all other nodes

Sometimes the terms read-only and read/write are used to describe direction of replication. In a one-way replication agreement, the consumer node is said to be read-only. That is, you cannot propagate changes to other nodes by writing to that node. In a two-way replication agreement, both nodes are considered to be read/write. Another term for read/write is updatable.

The directory servers that participate in the replication of a given naming context form a directory replication group (DRG). The relationship among the directory servers in a DRG is represented on each node by a special directory entry called a replication agreement. A replication agreement can be either one-way or two-way.

Each copy of a naming context contained within a server is called a replica. A server that sends the updates made to it to other servers is known as a supplier. A server that accepts those changes is called a consumer. A server can be both a supplier and a consumer.

A directory replication group can be single-master, multimaster, or fan-out as described in Table 6-4.

Table 6-4 Types of Directory Replication Groups

Group

Description

Single-master

Has only one supplier replicating changes to one or more consumers. Clients can update only the master node, and can only read data on any of the consumers. This type of group typically uses LDAP. It is also possible to configure Advanced Replication as single-master, by switching all nodes in a group except one to read-only mode.

Multimaster

Enables multiple sites, acting as equals, to manage groups of replicated data. In a multimaster replication environment, each node is both a supplier and a consumer node. Multimaster replication can use either LDAP or Advanced Replication as its transport mechanism. The full DIT is replicated on each node. Replication is always peer-to-peer.

Fan-out

Also called a point-to-point replication group, has a supplier replicating directly to a consumer. That consumer can then replicate to one or more other consumers. Fan-out uses LDAP as its transport mechanism. The replication can be either full or partial. It can be either one-way or two-way.

In Figure 6-3, each bullet represents a node of Oracle Internet Directory. Node A is a supplier that replicates consumer nodes B and C. Node A is read/write, and Nodes B and C are read-only. The data transfer protocol is LDAP.

6.2.4.2 Multimaster Replication Example

The example in Figure 6-4 shows three nodes—A, B, and C—that update each other in a multimaster replication group. Replication between nodes is two-way.

Multimaster replication is the only replication mechanism supported in Oracle Single Sign-On, as described in the section "Configuring Oracle Single Sign-On for Replication" in the chapter on high availability in the Oracle Application Server Single Sign-On Administrator's Guide in the 10g (10.1.4.0.1) library.

6.2.4.3 Fan-out Replication Example

In Figure 6-5, supplier A replicates to two consumers, B and C. Consumer node B contains a partial replica of A, whereas consumer node C contains a full replica of A.

Each of these nodes, in turn, serves as a supplier that replicates data to two other consumers: Node B partially replicates to nodes D and E, and node C fully replicates to nodes F and G. Nodes D and F are read-only.

In fan-out replication, nodes transfer data by using LDAP.

6.2.5 Loose Consistency Model

Directory replication architecture is based on a loose consistency model: Two replicated nodes in a replication agreement are not guaranteed to be consistent in real time. This increases the overall flexibility and availability of the directory network, because a client can modify data without all interconnected nodes being available. Suppose, for example, that one node is unavailable or heavily loaded. With multimaster replication, the operation can be performed on an alternate node, and all interconnected nodes synchronize in due course.

6.2.6 How the Replication Concepts Fit Together

Table 6-5 shows each of the two transport mechanisms, LDAP and Oracle Database Advanced Replication, and describes how each type can be combined with other replication concepts.

Table 6-5 Types of Data Transfer Between Nodes in a Directory Replication Group

Concept

LDAP-Based Replication

Oracle Database Advanced Replication-Based Replication

Content replicated

Full replica

Partial replica

Full replica (usually)

Direction of replication

Peer-to-peer

One-way

Two-way

Peer-to-peer

DRG Type

Multimaster replication

Single-master replication

Fan-out replication

Multimaster replication

Single-master replication, by switching all masters in a multimaster configuration except one to read-only mode.

6.2.7Multimaster Replication with Fan-Out

Oracle Internet Directory enables any node in a multimaster replication group to also participate in a fan-out replication agreement. Within the multimaster replication agreement, data transfer between the nodes occurs by way of Oracle Database Advanced Replication or LDAP. Within the fan-out replication agreement, data transfer from supplier to consumer occurs by way of LDAP and can be either one-way or two-way.

Figure 6-6 shows an example of multimaster replication used with fan-out replication.

Figure 6-6 Example of Multimaster Replication with Fan-Out

In the example in Figure 6-6, nodes A, B, and C form a multimaster replication group. They transfer data among them by using either LDAP or Advanced Replication.

Node B supplies changes to Node D, a replica of the entire directory. Node D, in turn, supplies changes to Nodes F and G by using LDAP-based replication. Both Nodes F and G are replicas of the entire directory. Similarly, Node E is a full replica of Node C. Node E, in turn supplies changes to Node H, a replica of the entire directory, and Node I, a partial replica, by using LDAP-based replication. Nodes F and H are read-only.

See Also:

"LDAP-Based Replication" on page 29-23 for more information about fan-out replication

6.3 What Kind of Replication Do You Need?

The type of replication you need depends on the features that are important in your enterprise. This section discusses the types of replication to use to achieve three features: local availability, load balancing, and high availability

Local Availability

Local availability is important in the following situations:

You need a local copy of the master data that is specific to the local site. This might be the entire DIT or a partial DIT.

You need the increased scalability and performance that you can get by distributing the work load among multiple servers.

You want to reduce the network dependency and network load caused by users from local sites connecting to the master site.

If the local site does not update the data, use one-way replication from master node to local nodes

If the local site does need to update the data and the updates must be replicated back to the master site, use two-way replication between master node and local nodes.

Load Balancing

Load Balancing is important in the following situations:

You want to increase scalability and performance by distributing work load among multiple servers

You want to dedicate specific servers to certain applications, such as single sign-on or e-mail applications

You require network load balancing.

You can use LDAP multi-master replication to replicate the data between two or more nodes. If Oracle Single Sign-On10g (10.1.4.3.0) or later is also installed and Oracle Single Sign-On schema must be replicated for load balancing, use Oracle Database Advanced Replication-based multimaster replication. Otherwise, you can use LDAP-based multimaster replication.

Note:

When you configure a load balancer for use with replication, use sticky routing and not round-robin routing. Replication is asynchronous in nature, so changes made on one node are not available immediately on the other nodes.

High Availability

High availability is important in the following situations:

You require a high availability solution with at least one backup server to prevent loss from single server failure

You need a disaster recovery solution that uses geographically distributed deployments to protect applications from disasters.

Usually, you can use LDAP-based multimaster replication to replicate the data between two or more nodes. If Oracle Single Sign-On 10g (10.1.4.3.0) or later is also installed along with Oracle Internet Directory, however, then use Oracle Database Advanced Replication-based multimaster replication.

Scripting on this page enhances content navigation, but does not change the content in any way.