PingDirectory

Replication deployment planning

Consider the following factors before deploying replication in a production environment:

Minimizing Replication Conflicts

If two different clients attempt to create an entry with the same distinguished name (DN) at the same time against different servers, it’s possible that both client requests will succeed. This triggers the server to send a conflict alert. You can minimize these conflicts by understanding the client traffic pattern beforehand. PingDirectory’s Assured Replication feature and the PingDirectoryProxy server can both assist in minimizing conflicts.

Learn more at Configuring assured replication and PingDirectoryProxy.

Replication Purge Delay

Adjust the default one-day replication purge delay to accommodate automatic catchup of changes when a server is offline for an extended period of time. The replication changes database, stored in <server-root>/changelogDb, grows larger with longer replication purge delays.

Define a minimum value for the replication purge delay. Make sure the value is consistent across all servers.

Learn more at Modifying the replication purge delay.

Domains

All servers in a replication topology must have the same domains.

Because the PingDirectory replication topology assumes that all domains are on all servers, it is not suitable for environments with an inconsistent presence of domains across the server topology.

Location

If your deployment incorporates multiple data regions, you should configure the PingDirectory servers with location information.

To set locations, use the dsconfig create-location and dsconfig set-global-configuration-prop commands.

The PingDirectory server cannot determine LAN boundaries automatically, so incorrect location settings can result in undesired WAN communication. By default, replication compresses all traffic between PingDirectory servers in different locations.

Set up the locations before enabling replication. The dsreplication enable command prompts for location information if you have forgotten to define the property.

User-defined LDAP

PingDirectory servers participating in replication must have a uniform user-defined schema.

The dsreplication command-line utility sets up replication for the schema backend the first time replication is enabled to ensure that future schema changes are propagated to all PingDirectory servers.

Disk space

Replication increases the disk space required for the PingDirectory server.

The Replication Changelog backend keeps changes from all PingDirectory servers for 24 hours by default. After this time period, also known as the purge delay, the backend is trimmed automatically.

In addition, within the userRoot and other local DN backends, attribute-level changes are recorded for a short period of time in the ds-sync-hist attribute of the entry targeted by an LDAP Modify operation. This attribute is used to resolve all conflicts resulting from LDAP Modify operations automatically.

The disk space impact of replication is dependent on the rate and size of changes in the replication topology and the Replication Changelog purge delay.

Memory

Replicated PingDirectory server instances require slightly more memory than a standalone server.

All of the items discussed in Disk space have an impact on the amount of memory the PingDirectory server is using. The additional replication overhead is typically less than 5%.

Time synchronization

Even though replication has a built-in mechanism to compensate for the potential clock skew between hosts, you should keep system clocks in sync within the deployment.

Communication ports

The replication server component in each PingDirectory server listens on a TCP/IP port for replication communication.

This replication server port, typically 8989, must be accessible from all PingDirectory servers participating in replication. The server-to-server communication channel is kept alive using a heartbeat, which occurs every 10 seconds. This traffic prevents firewalls from closing connections prematurely.

The replication command-line utility (dsreplication) requires access to all PingDirectory servers participating in replication. This includes the LDAP or LDAPS port of the servers.

When configuring firewalls, keep these communication requirements in mind.

Hardware load balancers

Replication allows write operations to be directed to any PingDirectory server in the topology. Distributing write operations in a round-robin fashion could introduce conflicts. In particular, distributing a series of LDAP add, delete, and modify DN operations targeting the same distinguished name (DN) in quick succession can cause conflicts that require manual intervention.

The Assured Replication feature can help prevent conflicts created by the same client application. For more information, see Configuring assured replication.

Consider using server affinity with the load balancer that either associates a client IP address or a client connection with a single PingDirectory server instance at a time.

For load balancing LDAP traffic, consider using the PingDirectoryProxy server. The Server Affinity feature in PingDirectoryProxy server enables replication-friendly load balancing. For more information, see Configuring server affinity.

PingDirectoryProxy

To facilitate replication-friendly load balancing, consider using PingDirectoryProxy in every replication deployment.

The PingDirectoryProxy server can automatically adapt to conditions in the backend PingDirectory server using health checks and route traffic accordingly.

For example, the PingDirectoryProxy server can re-route traffic from PingDirectory servers with a large backlog of replication updates.

Displaying the server information for a replication deployment

Steps

  • To display the server information for a replication deployment, run the dsreplication status command with the --displayServerTable option.

    $ bin/dsreplication status --displayServerTable

    Result:

              --- Replication Status for dc=example,dc=com: ---
Server                          : Location : Priority (1) : Status
--------------------------------:----------:--------------:----------
austin-01.example.com:8989      : US       : 1 (*)        : Available
austin-02.example.com:8989      : US       : 2            : Available
london-01.example.com:8989      : UK       : 5            : Available
london-02.example.com:8989      : UK       : 5 (*)        : Available
sydney-01.example.com:8989      : AU       : 5 (*)        : Available
sydney-02.example.com:8989      : AU       : 5            : Available

[1] WAN Gateway Priority. WAN gateways are marked with a *. To minimize
WAN utilization, the server with the WAN Gateway role is the only server
in a location that exchanges updates with remote locations.

--- Replication Status for dc=example,dc=com: Enabled ---
Server                          : Location : Entries : Conflict Entries : Backlog : Recent Change Rate
--------------------------------:----------:---------:------------------:---------:-------------------
austin-01.example.com:1389      : US       : 3478174 : 0                : 8       : 333
austin-02.example.com:1389      : US       : 3478174 : 0                : 5       : 345
london-01.example.com:1389      : UK       : 3478174 : 0                : 0       : 349
london-02.example.com:1389      : UK       : 3478174 : 0                : 0       : 5
sydney-01.example.com:1389      : AU       : 3478173 : 0                : 0       : 350
sydney-02.example.com:1389      : AU       : 3478270 : 0                : 30      : 332

Displaying all status information for a replication deployment

Steps

  • To display the status information for a replication deploymnent, run the dsreplication status command with the --showAll option.

    You can also use the --showAll option together with the --displayServerTable option to see the server table information for the replication topology.