高可用性および災害復旧
高可用性 (HA) を有効にするには、2 次ディレクトリー同期プロセスは実行されている必要がないという点を除き、1 次と同じ構成で 2 次ディレクトリー同期のインストール済み環境をセットアップします。
2 次ディレクトリー同期プロセスには、cookie.bin ファイルの最新のコピーへのアクセス権限が必要です。 このファイルは、ディレクトリー同期が Active Directory または LDAP をクラウド・ディレクトリーと同期する際に、定期的に保存する同期状態です。
IBM® VerifyDirectory Syncは、一連の更新データの送信を完了した後、 Active Directory または LDAP から同期された最新の更新情報を特定する情報をCookieファイルに書き込みます。
一連の変更の同期中に 1 次ディレクトリー同期がダウンした場合は、2 次を開始する必要があります。 2 次は、手動で開始することも、何らかの自動モニター・システムによって開始することもできます。 2 次は、Cookie 内の情報に基づいて、Active Directory または LDAP に対して更新がないか照会します。 また、1 次サーバーが処理していたのと同じ一連の変更の同期を試みます。 既に Verify に送信された更新に関するエラーがログに記録される場合があります。
1 次プロセスと 2 次プロセスの間で cookie.bin ファイルの同期状態を保持する方法はいくつかあります。 共有ファイル・システムに Cookie を保管することは、以下の例で説明されている 1 つの可能な解決策です。 もう一つの解決策として、スクリプト OpenSSH scp とWindows™のスケジュールされたタスク機能（Schtasks）を利用する方法があります。
共有ファイル・システムを使用して cookie.bin ファイルを共有するには、セキュアなネットワーク・ファイル・システムまたはドライブ上で cookie.bin ファイルを構成します。 1 次ディレクトリー同期プロセスと 2 次ディレクトリー同期プロセスの両方が、共有ドライブにアクセスできる必要があります。
例として、セキュアなネットワーク・ファイル・システムまたはドライブ上で cookie.bin ファイルを構成します。 1 次ディレクトリー同期プロセスと 2 次ディレクトリー同期プロセスの両方が、共有ドライブにアクセスでき、その共有ドライブを使用するように構成されている必要があります。 op_log の整合性のために、共有ドライブ上に op_log ファイルも構成します。 以下の例では、1 次ディレクトリー同期プロセスの名前が sharehost、共有ドライブが shared であり、ファイルは共有上の dirsync という名前のディレクトリーに配置されます。 \\sharehost\shared\dirsync共有ディレクトリへのUNCパスは. です。
cookie-file オプションを使用して、cookie.bin ファイルの場所を構成します。 これらのオプションの詳細については、 「cloud-bridge JSON オブジェクト」を参照してください。"cloud-bridge": {
"cookie-file":
"\\\\sharehost\\shared\\dirsync\\cookie.bin",
…op-log-file オプションを使用して、op_log ファイルの場所を構成します。"cloud-bridge": {
"op-log-file": "\\\\sharehost\\shared\\dirsync\\op_log\\op_log.csv",
…管理者は、手動で 1 次の障害を検出して 2 次を開始するか、自動モニター・システムを開発する必要があります。 IBM では、自動監視およびフェイルオーバー機能は提供されていません。 前述のように、自動モニターおよびフェイルオーバーのセットアップでは、1 次プロセスと 2 次プロセスの両方を同時に実行できないようにする必要があります。