19.1 Understanding the Multi-Data Center Synchronization

The Multi-Data Center (MDC) infrastructure can be configured to keep Access Manager data synchronized across multiple data centers. The Automated Policy Synchronization (APS), a replication mechanism introduced in 11g removes administrator and manual intervention from the data synchronization process.

Policy, system configuration, and partner metadata are all synchronized with APS.

Note:

T2P tooling is required for creating a Clone (also referred to as a Consumer) from a Master (also referred to as a Supplier). Once the MDC infrastructure is deployed, APS can be enabled to automatically sync any changes from the Master to the Clones.

See Before Setting Up a Multi-Data Center.

APS (also referred to as the Replication Service) is a set of REST API. The binaries are installed as part of the Access Manager application and deployed in the AdminServer. It is disabled by default but can be enabled by setting the oracle.oam.EnableMDCReplication property to true. After enabling the service, create a pull model Replication Agreement between the Clone data center and the Master. The Clone polls for changes from the Master as long as the Replication Agreement is valid for it. Conversely, the Master will respond to the Clone's request as long as it finds a valid replication agreement. The Clone applies the changes locally.

Note:

APS is optional; administrator-initiated import and export based replication is still available using the T2P tooling and WLST command procedure used previous to this release.

When setting up the Replication Service, the following may occur:

• Establishment of a Replication Agreement with the registration of one data center as a replication Clone and another in a separate geographical location as its Master; the changes are pulled from the Master and applied to the Clone.

• Definition of data center specific configurations which may not be replicated across data centers.

• Tracking of Access Manager configuration changes in each data center and querying the current replication state in any of the data centers.

• Generation of a changelog which can be applied in the context of a similar setup running in another data center.

• Trigger of a pull from the Master data center if there is a need; for example, if automated replication fails.

• Replication of Access Manager configuration artifacts in the Master-Clone model.

  Note:

  APS does not sync IDS Profiles, OAM Keystores, and Oracle Platform Security Services artifacts (jps-config.xml changes, credential store configuration and the like).

The following sections contain additional details.

• How Replication Works

• Understanding the Replication Agreement

• About Synchronizing Data Manually in a Multi-Data Center

19.1.1 How Replication Works

Replication works in a Master-Clone topology. In this topology, multiple Clones pull changes from a single Master. One Data Center is defined by the administrator as the Master and one or more other Data Centers are Clones.

The administrator makes changes to the Master that are replicated to the Clones. Only Master to Clone replication is supported; changes to Clones are not replicated back to the Master.

Note:

Multi-master replication is not supported.

To partake in replication, the Master data center (initiator of the replication) and the Clone data center (receiver of the changes) must have a Replication Agreement stored in the Access Manager data store. Table 19-1 documents the states in which replication can be deployed.

Table 19-1 Replication States

State	Definition
Active	An Access Manager domain (including Admin and managed servers) is setup to serve access requests. In an active state, the Access Manager server provides the web access management functionality without additional MDC features.
Bootstrapping	This state is optional for some Data Centers; for example, the first one in an MDC topology. A Data Center goes through this intermediate state when added to an existing MDC topology. The new DC contacts the master and bootstraps itself to the same state. The bootstrap includes synchronizing the server keys, policy artifacts, partners, and system configuration. After completion of bootstrapping, the DC will be Replication Ready.
Replication Ready	In this state, MDC is enabled, the DC is made part of the topology, and the replication service is enabled. Once enabled, a clone can be registered with the master via a Replication Agreement. Once established, clone DCs can query and start pulling changelogs from the master.

Figure 19-1 illustrates the replication flow.

Figure 19-1 Replication Flow

Description of "Figure 19-1 Replication Flow"

Each Clone pulls changes from the Master. A replication thread runs on the Clone after the pre-configured interval of time and fetches changes from the Replication Service (REST endpoint) running on the Master environment.

For every cloned environment, the Master keeps track of a change sequence number indicating when it was last synced. The Master also keeps track of the list of changes (Create/Update/Delete) that have been pulled by the Clones in a changelog using specific change sequence numbers. When updating configuration metadata, the Clone can also change environment specific parameter values depending on transformation rules.

See Customizing Transformation Rules.

19.1.2 Understanding the Replication Agreement

Configuration changes (defined as journals) are replicated from a Master node to Clone nodes. On receiving the journals, each node updates it's configuration to match the journal and remain in a synchronized state. The nodes, though, need to enter a Replication Agreement to receive change journals.

When a new data center is added to an existing MDC topology, it has to bootstrap itself to be in sync with the existing data centers. This bootstrap operation will get the current Access Manager policies, system configuration, partner metadata and server keys for the existing MDC topology. After the bootstrap operation, the new data center captures the last change sequence number from the topology's Master so that during replication it can be used to determine the current state.

Note:

Automated bootstrap is the ideal scenario but you can execute T2P tooling first to ensure the Master and Clones are in the same state.

To establish a Replication Agreement, the Clone data center must know the Master's changelog sequence number. If the data center is added to the topology on 'day 0' and the Replication Agreement was created on 'day 1', there is a need to bootstrap again. To avoid this and to keep the flow simple, creating a Replication Agreement should take care of the bootstrap and actual replication agreement creation. The steps to create the Replication Agreement.

See Setting Up a Multi-Data Center.

19.1.3 About Synchronizing Data Manually in a Multi-Data Center

Data in an MDC topology can also be synced manually. The manual option uses WLST export and import calls to migrate the data from one data center to another. Partner profiles and policies should both be exported and imported using WLST.

See Access Manager WLST Commands in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for Identity and Access Management.