Understanding Oracle Internet Directory Replication

6 Understanding Oracle Internet Directory Replication

This chapter provides an introduction to Oracle Internet Directory replication, Replication concepts and various replication methods that can be used based on your organization's requirement.

6.1 What is Oracle Internet Directory Replication?

Replication is the process of copying and maintaining the same naming contexts on multiple directory servers. Replication can improve performance by providing more servers to handle queries and by bringing the data closer to the client. Replication can also improve reliability by eliminating risks associated with a single point of failure.

Figure 6-1 shows a replicated directory.

Figure 6-1 A Replicated Directory

This illustration is described in the text.

6.2 Why Use Oracle Internet Directory Replication?

Understand the use of Oracle Internet Directory 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.3 Understanding Basic Concepts of Internet Directory Replication

Get introduced to some of the basic concepts of Internet Directory Replication.

This section contains the following topics:

6.3.1 How to Decide Full or Partial Content Replication?

When setting up replication, you must decide 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 is based on LDAP.

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. Partial replication is based on LDAP-based protocol.

Figure 6-2 shows an example of partial replication.

Figure 6-2 Example of Partial Replication

6.3.2 Replication Direction: One-Way, Two-Way, or Peer to Peer

Understand about the different replication directions.

The direction of replication can be one-way, two-way or peer-to-peer:

Table 6-2 Direction of Replication

Direction	Description
One-Way	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.

Sometimes the term multimaster is used instead of peer-to-peer. Multimaster actually refers to the type of replication group, as described in Example for Single-master, Multimaster, or Fan-out Directory Replication Group Type.

6.3.3 Transport Mechanism: LDAP

Oracle Internet Directory supports LDAP protocol that can be used for replicating data from one node to another.

Table 6-3 Transport Protocols

Transport Mechanism	Description
LDAP	Uses the industry-standard Lightweight Directory Access Protocol Version 3. This is the recommended protocol to use for replication, unless you are also performing Oracle Single Sign-On replication.

LDAP replication can be configured as peer-to-peer, one-way or two-way.

Note:

Oracle Database Advanced Replication is deprecated from 12.2.1.3.0 and is no longer in use.

6.3.4 Directory Replication Group (DRG) Type: Single-master, Multimaster, or Fan-out

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.
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 LDAP 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.

6.3.5 Example for Single-master, Multimaster, or Fan-out Directory Replication Group Type

Understand about Single-master, Multimaster, or Fan-out Directory Replication group types from examples provided in the following sections.

This section has the following topics:

6.3.5.1 Single-Master Replication Example

Figure 6-3 shows a single-master replication environment.

Figure 6-3 Example of Single-Master Replication

Description of "Figure 6-3 Example of Single-Master Replication"

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.3.5.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.

Figure 6-4 Example of Multimaster Replication

Description of "Figure 6-4 Example of Multimaster Replication"

In Figure 6-4, all replication is two-way.

Note:

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.3.5.3 Fan-out Replication Example

Figure 6-5 shows a fan-out replication environment.

Figure 6-5 Example of Fan-Out Replication

Description of "Figure 6-5 Example of Fan-Out Replication"

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.3.6 Loose Consistency Model in Directory Replication Architecture

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.3.7 Multimaster 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 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 LDAP.

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 LDAP-based replication.

6.4 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.

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.