Replication architecture

Replication is based on an eventual-consistency model where the updates propagated through a connected network of servers will eventually be consistent on all servers over a short period of time.

In a typical update operation, a client application updates an entry or group of entries on a PingDirectory server with an ADD, DELETE, MODIFY, or MODIFY DN operation. After processing the operation, the PingDirectory server returns an LDAP response while simultaneously propagating the update to the other servers in the replicated topology. This simultaneous processing model allows the client to continue submitting update requests without waiting for a replication completion response from the server.

To support this processing model, replication never locks the targeted entries at the other PingDirectory server instances before an update can be made locally. This means that the replicated servers might have an inconsistent view of the targeted entry for a short period of time, but will catch up as the propagated changes are applied.

The eventual-consistency model also allows clients to complete update operations faster because clients can propagate a change without having to wait for replication. The rate of update operations remains the same no matter how many PingDirectory servers participate in replication.

Alternatively, you can configure assured replication for specific write requests to require local or global consistency, across data center locations, before a response is returned to the client. For more information, see Configuring assured replication.

Each PingDirectory server has an embedded replication server that is responsible for transmitting updates to other replication servers. Each replicating base distinguished name (DN), such as cn=schema, dc=example,dc=com, has a separate component called a replica. Each replica connects to the embedded replication server running within the PingDirectory server Java virtual machine (JVM) process.

When a client application updates an entry on the PingDirectory server, the replica sends an update message to its embedded replication server. The replication server applies the change to the replicationChangelog backend repository and then sends an update message to the connected replication server on another PingDirectory server. The replication server on other PingDirectory servers then passes the change to the appropriate replica, which in turn applies the change to its backend after performing conflict resolution.

The following figure shows the standard setup.

The PingDirectory server uses a simple authentication model to authorize replication servers.

After it is authenticated, the remote PingDirectory server is fully authorized to exchange replication messages with the local PingDirectory server. There is no other access control in place.

Authentication in the replication protocol is based on public key cryptography using TLS client certificate authentication. The certificate used for authentication is stored in the ads-truststore backend of the PingDirectory server.

During replication setup, the command-line utility distributes public keys to all PingDirectory servers to establish trust between the servers and to enable TLS client authentication.

The access log messages in the PingDirectory server indicate if the update was received by replication and includes the corresponding change number. This allows the administrator to track which server the update originated from.