| Oracle® Fusion Middleware Administrator's Guide for Oracle Internet Directory 11g Release 1 (11.1.1) Part Number E10029-05 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Internet Directory 11g Release 1 (11.1.1) Part Number E10029-05 |
|
|
PDF · Mobi · ePub |
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.
Figure 6-1 shows a replicated directory.
This chapter contains the following topics:
See Also:
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.
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.
This section briefly introduces some basic concepts.
This section contains the following topics:
Section 6.2.2, "Direction: One-Way, Two-Way, or Peer to Peer"
Section 6.2.3, "Transport Mechanism: LDAP or Oracle Database Advanced Replication"
Section 6.2.4, "Directory Replication Group (DRG) Type: Single-master, Multimaster, or Fan-out"
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 |
|---|---|
|
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.
Figure 6-2 shows an example of partial replication.
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 Section 6.2.4, "Directory Replication Group (DRG) Type: Single-master, Multimaster, or Fan-out."
Oracle Internet Directory supports two protocols you can use for replicating data from one node to another. The protocols are:
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. |
|
Oracle Database Advanced Replication |
Uses the replication feature of Oracle Database. Also called Advanced Replication. This replication protocol is currently required for Oracle Single Sign-On replication. |
LDAP replication can be configured as peer-to-peer, one-way or two-way. Advanced Replication is usually peer-to-peer.
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. |
|
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. |
|
|
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. |
Figure 6-3, "Example of Single-Master Replication" shows a single-master replication environment.
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.
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
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.
Figure 6-5 shows a fan-out replication environment.
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.
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.
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. |
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.
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
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 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 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 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.
|
 Copyright © 1999, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
