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, Identity Synchronization for Windows should at least report the changes that are lost.

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

• 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 processes all changes that occurred when it was not running, 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, the connector detects 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, 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 Plug-in 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). When synchronization is started for the failover installation, the Directory Server Connector only processes one day's changes in the directory server.

The Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide contains instructions on how to enable trimming of the retro changelog. Essentially, the nsslapd-changelogmaxage attribute in the cn=Retro Changelog Plugin, cn=plugins,cn=config entry is modified and Directory Server is restarted. Setting the value of this attribute to 1d trims entries that are older than one day. The value can be modified from the command line by 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 Active Directory 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 check-point its state.

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