Understanding the Failover Process

The goal of the failover process is to avoid losing any changes that occurred between the time the primary system went down and the failover system was brought up. If changes are lost, then Identity Synchronization for Windows should at least report the changes that are lost.

Once synchronization is started for the first time, an Identity Synchronization for Windows Connector can continue to detect changes that occur:

• When synchronization is stopped.

• When the connector process is not running, for example, during a system restart.

• When the network connection between the connector and the directory source is down.

• During a idsync resync operation.

  The Directory Server and Active Directory connectors use similar mechanisms to achieve this goal.

Directory Server Connector

The Directory Server Connector persistently stores the changenumber of the last retro changelog entry that it has processed. When the connector begins detecting changes again, it can process all changes that occurred when it was not running, by starting with the last changenumber that it processed. This changenumber is stored in the connector's persist directory, for example, /var/opt/SUNWisw/persist/ADP100/accessor.state. If this file does not exist, then the connector will detect only new changes in Directory Server.

This way of processing the changes has an effect on the failover process. If synchronization is never started for the failover installation, then the file will not exist, and the Directory Server Connector will only detect new changes. Changes that occurred during the failover process are lost. However, initializing the accessor.state file presents its own problems. If synchronization is started immediately after installation to produce the accessor.state file, and then stopped, when synchronization is started after failing over, the Directory Server Connector will try to process all Retro changelog entries. To strike a balance between these two options, the Retro changelog Plugin on the failover installation's preferred master (master3-eu.gt.com) is configured to only store changes for one day (this limit is increased during the failover process). Once synchronization is started for the failover installation, the Directory Server Connector only processes one day's worth of changes in the directory server.

The Sun Java System Directory Server Administration Guide contains instructions on how to enable trimming of the retro changelog. Essentially, the nsslapd-changelogmaxage attribute on the cn=Retro Changelog Plugin, cn=plugins,cn=config entry is modified and Directory Server is restarted. Setting this value to 1d trims entries that are older than one day. The value can be modified from the command line using ldapmodify or by directly editing the Directory Server's dse.ldif file while Directory Server is not running.

Active Directory Connector

To allow Active Directory to detect changes that occurred while it was stopped, the Active Directory Connector persistently stores the usnchanged value of the last change that it processed. When it begins processing changes again, it only needs to examine entries with an usnchanged value larger than the previous one that it has processed. Like the Directory Server Connector, the Active Directory Connector first stores this usnchanged high-water mark when synchronization is started for the first time. Therefore, as part of preparing the failover installation, synchronization is started to allow the Active Directory connector to checkpoint.

When failing over and synchronization is restarted for the failover installation, the Active Directory Connector will process all entries that were modified because it was last started. Even though this will be thousands of entries, the processing will be fast because the Active Directory's object cache database is up-to-date with most of the changes. Only the changes made since the last time that idsync resync command was run will be processed.