High availability and disaster recovery

To enable high availability (HA), set up a secondary Directory sync installation with the same configuration as the primary, except that the secondary Directory Sync process must not be running.

The secondary Directory Sync process must have access to an up-to-date copy of the cookie.bin file. This file is the synchronization state that is regularly saved by Directory Sync as it synchronizes Active Directory or LDAP with Cloud Directory.

After Directory Sync completes sending each series of updates to IBM® Security Verify, it updates the cookie file with information that identifies the last update that was synchronized from Active Directory or LDAP.

If the primary Directory Sync goes down while synchronizing a batch of changes, the secondary must be started. The secondary can be started either manually or by some automated monitoring system. It queries Active Directory or LDAP for any updates based on the information in the cookie. It attempts to synchronize the same series of changes that the primary was processing. Errors might be logged for those updates that were already sent to Verify.

Several ways exist to keep the cookie.bin file synchronized between the primary and secondary processes. Storing the cookie on a shared file system is one possible solution that is described in the following example. Another possible solution is to use a scripted OpenSSH scp and the Windows scheduled task option (Schtasks).

To share the cookie.bin file by using a shared file system, configure the cookie.bin file on a secure Network File System or drive. Both the primary and secondary Dir Sync processes must have access to the shared drive.

As an example, configure the cookie.bin file on a secure Network File System or drive. Both the primary and secondary Dir Sync processes must have access to the shared drive, and be configured to use it. For op_log consistency, also configure the op_log file on the shared drive. In the following examples the primary Dir Sync process is named sharehost, the shared drive is shared, and the files are placed in a directory on the share called dirsync. The UNC path to the shared directory is \\sharehost\shared\dirsync.

Use the cookie-file option to configure the cookie.bin file location. For more information about these options, see The cloud-bridge JSON object.

"cloud-bridge": {
    "cookie-file": 
"\\\\sharehost\\shared\\dirsync\\cookie.bin",
    …

Use the op-log-file option to configure the op_log file location.

"cloud-bridge": {
    "op-log-file": "\\\\sharehost\\shared\\dirsync\\op_log\\op_log.csv",    
…

Note: In the preceding examples, the \\sharehost\shared\dirsync and \\sharehost\shared\dirsync\op_log directories must exist. The Directory Sync service must be run under a real user account that has permission to access the share.

The administrator must either manually detect the primary failure and start the secondary, or develop an automatic monitoring system. An automatic monitoring and failover system is not provided by IBM. As noted previously, any automatic monitoring and failover setup must not allow both primary and secondary processes to run at the same time.