PingDirectory

Data synchronization process

PingDataSync performs point-to-point synchronization between a source endpoint and a destination endpoint. An endpoint is defined as any source or destination topology of directory or database servers.

PingDataSync synchronizes data in one direction or bidirectionally between endpoints. For example, in a migration phase from Sun Directory server to a PingDirectory server, synchronization can occur in one direction from the source server to a staging server. With one-way synchronization, the source server is the authoritative endpoint for changes in the system. Bidirectional synchronization allows for parallel active installations between the source and the destination endpoints. With bidirectional synchronization, both endpoints are authoritative for the same set of attributes or for different sets of data.

PingDataSync also contains no single point of failure, either for detecting changes or for applying changes. PingDataSync instances themselves are redundant. There can be multiple instances running at a time, but only the server with the highest priority is actively synchronizing changes. The stand-by servers are constantly polling the active server instance to update their persistent state. This state contains the minimum amount of information needed to begin synchronization where the primary server left off, which logically is the last processed change number for the source server. In the case of a network partition, multiple servers can synchronize simultaneously without causing problems, because they each verify the full entry before making changes.

Synchronization architecture

PingDataSync uses a virtualized, dataless approach that does not store directory data locally. The log files, administrator entries, configuration, and sync state information are stored as flat files (LDIF format) within the system. No additional database is required.

A diagram illustrating synchronization architecture.

Change tracking, monitoring, and logging

PingDataSync tracks and manages processes and server health with the following tools:

Change Tracking

Each directory instance stores a separate entry under cn=changelog for every modification made to the directory. PingDataSync provides full control over the synchronization process by determining which entries are synchronized, how they are correlated to the entries at the destination endpoint, and how they are transformed into the destination schema.

  • For the PingDirectory server or Nokia 8661 Directory Server topologies, PingDataSync uses the server’s LDAP Change Log for modification detection.

  • For Oracle/Sun Directory Server, OpenDJ, Oracle Unified Directory, and generic LDAP directory topologies, PingDataSync uses the server’s Retro Change Log, which provides a detailed summary of each change.

  • For Active Directory (AD), PingDataSync uses the DirSync control, which polls for object attribute changes.

  • For RDBMS systems, PingDataSync uses a Ping Identity Server SDK plugin to interface with a customized RDBMS change log table. The database triggers on each table record all INSERT, UPDATE, and DELETE operations to the change log table.

Monitoring, Alerts, and Alarms

PingDataSync supports several industry-standard administrative protocols for monitoring alarms and alerts. System alarms and gauges can be configured to determine healthy performance thresholds and the server actions taken when performance values are outside the threshold. All administrative alarms are exposed over LDAP as entries under base DN cn=alarms. An administrative alert framework sends warnings, errors, or other server events through log messages, email, or JMX notifications. Administrative alerts are also exposed over LDAP as entries below base DN cn=alerts. Typical alert events are startup or shutdown, applied configuration changes, or synchronized resources unavailable.

Logging

PingDataSync provides standard logs (sync, access, error, failed-operations, config-audit.log, and debug). The server can also be configured for multiple active sync logs. For example, each detected change, each dropped change, each applied change, or each failed change can be logged.