This chapter provides a methodology to select a transition strategy. Be aware that the selection of the strategy may be an iterative process. The following topics are included in this chapter:
The transition process must be aligned with your architectural and operational requirements. The selection of the right transition strategy is a key factor for a smooth transition to OUD. The following are important factors to consider when selecting a transition strategy:
Using a coexisting approach provides an incremental transition process where the (O)DSEE and OUD deployments coexist and are kept in sync in a production environment while client applications are redirected progressively to OUD. This approach also allows applications to revert back to (O)DSEE without any interruption of service.
It is important to be aware that some added-value services/features provided by OUD cannot be deployed until the end of the coexistence so it is recommended to use this strategy for a specific period of time only. Similarly, the topology will not be able to deliver improved write performance made possible by OUD until changes are no longer replicated back to (O)DSEE.
Keeping two environments in production requires additional system resources because the two infrastructures must be managed separately. Furthermore, keeping the two environments in sync also adds complexity to the system so it is recommended to evaluate whether coexistence is a key requirement or not for your transition project.
During replication all data is copied and is in sync and kept up-to-date across servers. However, each server does not necessarily contain identical data, especially metadata. If you choose to have ODSEE and OUD topologies coexist in production, then follow these guidelines:
Evaluate the level of data consistency you expect between the two environments.
Decide if you require strong consistency with global replication conflict management to ensure that every change is applied in a coherent and ordered manner.
Determine how you prefer to handle temporary data consistency by choosing to accommodate synchronization latency or to require near real time data consistency between (O)DSEE and OUD topologies.
Establish if you require full synchronization of password policy-related state, ensuring consistent account locking across the entire typology.
Note:
Projects that require coexistence for a very short period of time may not require fully-featured global password policy support. A conflict may occur when the same entry is modified simultaneously on different servers. In this specific situation, full conflict management guarantees that the entry will be identical on both servers.In some specific cases, limited changes to the (O)DSEE infrastructure may greatly simplify the transition process and make support of specific features possible. For example, such modifications to (O)DSEE may include addition of LDAP schema extensions, modification of password policy mode or deployment of retro changelog.
Determine whether or not well-identified changes to (ODSEE) are acceptable as part of your transition strategy selection.
The ability to redirect client traffic from (O)DSEE to OUD without interruption of service is an important factor to consider. Administrators should be aware of the built-in automatic mechanisms that ensure write service during transition. For other projects, the interruption of updates is unacceptable.
Some transition strategies proposed in this guide provide full-write high-availability during transition. Other transition strategies would require deployment of additional components such as proxies able to duplicate traffic.
Before transitioning the directory service, you may want to take the opportunity to evaluate the existing directory services architecture and user data structure. Or, you might be fine with the existing architecture, but want to revisit only a subset of the user data.
This guide does not address transitions that involve redesigning the user data structure. Contact your Oracle Support representative if your transition requires changes to the user data structure.
This section describes the strategies that Oracle supports for your transition, and a decision matrix to assist you in choosing the transition strategy that best fits your technological needs. Choose one of the following strategies:
With this strategy, (O)DSEE and OUD topologies are kept in sync at the native replication protocol level by using the Replication Gateway. Replication through the Gateway has very low latency because it does not involve any polling mechanism.
The Replication Gateway is installed and managed like any other OUD component and performs the required adaptation of replication protocols between (O)DSEE and OUD. The Replication Gateway provides strong data consistency between the two types of directories and fully leverages conflict management. As full directory metadata are replicated, the Replication Gateway also synchronizes internal password policy states, ensuring proper account locking.
The Replication Gateway offers a true two-way replication between (O)DSEE and OUD. It is a high-performance conduit that propagates the updates between heterogeneous replicated topologies without being stored at the gateway level. A unit of replication is the suffix as defined on the (O)DSEE side. You can also run the Replication Gateway in one-way mode so that changes from your directory server are replicated to OUD while changes from OUD will not be reflected on (O)DSEE.
For high availability, at least two Replication Gateway servers are deployed between two (O)DSEE masters and two OUD replication servers in every scenario. This eliminates the risk of a single point of failure.
Oracle Directory Integration Platform (DIP) is a multi-purpose synchronization tool used among various repositories and it enables you to do the following:
Synchronize (O)DSEE and OUD topologies.
Run your directory server with OUD as you transition over time with no downtime.
Use the changelogs configured on (O)DSEE and OUD to detect changes and replay them back and forth.
Synchronization triggers periodically and processes a configurable maximum number of changes at each run. DIP synchronizes user data only.
For more information about DIP, refer to the Oracle Directory Integration Platform (DIP) Administrator's Guide. You can access that document in the Oracle Fusion Middleware 11g Release 1 (11.1.1.7) library located at http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.html
This strategy uses export and import methods with standard directory administrative commands. The user data and configuration are exported from (O)DSEE, and adapted if necessary, using tools and procedures described in this guide. The user data and configuration are then imported into OUD.
The Direct Transition Strategy is a singular transition, and it is simple and quick. It can be used when interruptions on write capabilities are acceptable. Directory Administrators typically use a load balancer or an LDAP proxy to put the infrastructure in read-only mode, export data from (O)DSEE, import the data to OUD, then redirect the traffic to OUD.
The following decision matrix summarizes the key decisions factors in choosing a transition strategy:
Table 2-1 Decision Factors for Transition Strategies
| Decision Factors | Coexistence Using Replication Gateway | Coexistence Using DIP | Direct Transition |
|---|---|---|---|
|
Coexistence |
Yes |
Yes |
No |
|
Data Consistency Level |
Strong Low Latency |
Loose Latency Depends on DIP Configuration |
N/A |
|
Performance |
High |
Medium |
N/A |
|
Impact on (O)DSEE |
Depends on (O)DSEE release and setting (Chapter 3, "Validating Your Transition Strategy") |
Enable retro changelog |
No |
|
Write service availability |
Built-in support |
Built-in support |
Requires additional components (*) |
|
Data adaptation/ Structure changes |
No |
Yes (limitations apply) |
Yes (can be performed at will) |
|
High Availability |
Built-in Support |
Deployment Specific |
N/A |
(*) not covered in this guide