test

Sun OpenSSO Enterprise 8.0 Deployment Planning Guide

Replication Structure

Replication is entirely handled by OpenSSO Enterprise. The OpenSSO Enterprise embedded configuration data store replication model supports multi-master network architecture. The embedded configuration data store separates actual data from replication metadata. In this model, the server that stores the configuration data is called the directory server. The server that stores the replication metadata is called the replication server.

Even the smallest deployment must include two replication server instances, to ensure availability when the replication server instances fails. Replication servers perform the following functions:

Each replication server contains a list of all the other replication servers in the replication topology. Replication servers are also responsible for providing other servers information with information about the replication topology.

Directory servers perform the following functions:

Each directory server contains a list of the suffix DNs to be synchronized. For each suffix DN to be synchronized, each directory server contains a list of replication servers to connect to. When a change is made on a directory server, that directory server forwards the change to the local replication server. The replication server then relays the change to other replication servers in the topology, which in turn relay the change to all other directory servers in the topology.

Applications should typically perform reads and writes on the same directory server instance. This reduces the likelihood of consistency problems due to replication.

Every replication server instance maintains a message queue which is used to store pending changes. When one of the directory servers is down, all the changes applied to other servers will be stored in the corresponding message queue in the server instance which receives the requests. Once the directory server instance is back online, the replication servers relay all the changes to maintain data consistency. However, the size of the message queue and purge delay time are limited. By default, the size of the message queue is 10000 changes. The purge delay time is 24 hours. If one of the servers is down longer than the purge delay time, or if the changes applied to a particular directory server exceeds the size of message queue, the replication system will lose synchronization.

You can change the value of the purge delay and the size of message queue by adding the entries ds-cfg-replication-purge-delay and ds-cfg-queue-size attributes to the file config.ldif. The config.ldif file is under the directory OpenSSO base directory/opends/config directory. The unit of ds-cfg-replication-purge-delay is seconds, and the unit of ds-cfg-queue-size is integer. Once the embedded configuration data store instance loses synchronization, the only way to bring the system back to synchronization is to reconfigure OpenSSO Enterprise with the embedded configuration data.

To determine whether embedded configuration data store instances are synchronized, OpenSSO Enterprise CLI tools ssoadm provides a command embedded-status to check the status of embedded configuration data store instances. SeeChapter 1, ssoadm Command Line Interface Reference, in Sun OpenSSO Enterprise 8.0 Administration Reference Alternatively, you can check the embedded configuration data store logs when you suspect a problem with configuration data store inconsistencies. The logs are under the directory OpenSSO base directory/opends/logs. Current OpenSSO Enterprise embedded configuration data store replication implementation is recommended for use with the server instances located within the same geographical region.