2. Directory Serverのインスタンスと接尾辞
7. Directory Serverのパスワード・ポリシー
8. Directory Serverのバックアップとリストア
9. Directory Serverのグループ、ロールおよびCoS
16. Directory Proxy Serverのツール
17. Directory Proxy Serverのインスタンス
19. Directory Proxy Serverの証明書
20. Directory Proxy Serverのロード・バランシングとクライアント・アフィニティ
22. Directory Proxy Serverによる仮想化
24. Directory Proxy ServerとバックエンドLDAPサーバーの接続
25. クライアントとDirectory Proxy Serverの接続
26. Directory Proxy Serverのクライアント認証
27. Directory Proxy Serverのロギング
28. Directory Proxy Serverの監視とアラート
第3部 Directory Service Control Centerの管理
サプライヤ・サーバーとコンシューマ・サーバー間でレプリケートされた接尾辞では、リストアする前に特別な考慮が必要です。可能な場合、バックアップからのリストアではなく、レプリケーション・メカニズムにより接尾辞を更新するようにしてください。
サプライヤまたはハブ・インスタンスをリストアする際は、サーバーの構成をバックアップを実行したときと同じにする必要があります。これを確実に行うには、Directory Serverデータのリストア前にdse.ldifファイルをリストアします。サーバーの起動中に、--safeオプションを使用します。詳細は、「Directory Serverを起動、停止および再起動するには:」を参照してください。
この項では、レプリカをリストアする場合とその方法、およびその操作後に他のレプリカとの同期を確保する方法について説明します。レプリカを初期化するには「レプリカの初期化」を参照してください。
レプリケートされた大規模な接尾辞に多くのエントリを追加して、レプリケーションの更新が正常に追加されるようにするには、「大規模なレプリケートされた接尾辞への多数のエントリの増分追加」を参照してください。
この項の内容は、次のとおりです。
シングルマスター・サプライヤである接尾辞には、レプリケーション・トポロジ全体に対して信頼できるデータが含まれます。したがって、接尾辞のリストアはトポロジ全体のデータすべてを初期化すしなおすことに相当します。シングルマスターをリストアするのは、リストアするバックアップの内容で全データを初期化しなおす場合のみとします。
エラーによりシングルマスター・データのリカバリが不可能な場合、コンシューマにはバックアップよりも新しい更新を含まれていることがあるので、いずれかのコンシューマのデータを使用することを検討してください。この場合、データをコンシューマ・レプリカからLDIFファイルにエクスポートしてから、そのLDIFファイルよりマスターを初期化しなおす必要があります。
バックアップのリストアでも、マスター・レプリカでのLDIFファイルのインポートでも、後でこのレプリカから更新を受信するすべてのハブおよびコンシューマ・レプリカを初期化しなおす必要があります。サプライヤ・サーバーのログ・ファイルには、コンシューマの再初期化が必要であることを示すメッセージが記録されます。
マルチマスターのレプリケーションでは、他の各マスターにはレプリケートされたデータの信頼できるコピーが含まれています。古いバックアップでは、最新のレプリカの内容より古い場合があるので、リストアできません。可能であれば、レプリケーション・メカニズムにより、他のマスターの内容を使用してマスターを最新にするようにしてください。
それが不可能な場合、次のいずれかの方法でマルチマスターをリストアします。
最も簡単な方法は、バックアップをリストアせずに、他のマスターのいずれかより目的のマスターを初期化しなおすことです。これにより、最新データが目的のマスターへ送られ、データのレプリケーション準備が整います。「LDIFからのレプリカの初期化」を参照してください。
非常に多くのエントリを持つレプリカの場合、バイナリ・コピーを作成して、他のマスターのいずれかの最新のバックアップをリストアすれば、高速化できます。「バイナリ・コピーを使用したレプリケートされた接尾辞の初期化」を参照してください。
他のどのマスターに対しても変更ログ・コンテンツ最大経過時間を超えていないマスターのバックアップがあれば、そのバックアップをこのマスターのリストアに使用できます。変更ログ経過時間の詳細は、「マスター・レプリカの変更ログ設定を変更するには:」を参照してください。古いバックアップをリストアする場合、他のマスターはそれぞれの変更ログを使用して、そのバックアップの保存以降に処理されたすべての変更により、このマスターを更新します。
リストアまたは再初期化の方法にかかわらず、マスター・レプリカでは初期化後も読取り専用モードが維持されます。この動作により、レプリカの他のマスターとの同期が可能になり、これ以後は、「マルチマスター・シナリオでのマスターのリストア」の説明どおりに、書込み操作を行うこともできます。
リストアまたは再初期化したマスターでの書込み操作を許可する前に、すべてのレプリカを収束させることの利点は、ハブまたはコンシューマ・サーバーを初期化しなおす必要がなくなることです。
この項は、レプリケーション・メカニズムでハブ・レプリカを自動的に最新の状態にできない状況でのみ適用されます。このような状況には、データベース・ファイルの破損、または長期にわたるレプリケーションの中断が含まれます。これらの場合、次の方法のいずれかによりハブ・レプリカをリストアまたは初期化しなおす必要があります。
最も簡単な方法は、バックアップをリストアせずに、マスター・レプリカのいずれかよりハブを初期化しなおすことです。これにより、最新データがそのハブへ送られ、データのレプリケーション準備が整います。「接尾辞の初期化」を参照してください。
非常に多くのエントリを持つレプリカの場合、バイナリ・コピーを作成して、別のハブのレプリケートされた接尾辞からの最新のバックアップをリストアすれば、高速化できます。「バイナリ・コピーを使用したレプリケートされた接尾辞の初期化」を参照してください。コピーするハブのレプリカが他にない場合、前項での説明のようにハブを初期化しなおすか、次項での説明のようにハブをリストアします(可能な場合)。
どのサプライヤ(ハブまたはマスター・レプリカ)に対しても変更ログ・コンテンツ最大経過時間も超えていないハブのバックアップがあれば、そのバックアップをこのハブのリストアに使用できます。ハブをリストアする場合、そのサプライヤは各自の変更ログを使用して、そのバックアップの保存以降に処理されたすべての変更により、このハブを更新します。
注意: ハブ・レプリカのリストアまたは初期化の方法にかかわらず、他のあらゆるレベルのハブを含め、このハブのコンシューマをすべて初期化しなおす必要があります。
この項は、レプリケーション・メカニズムで専用コンシューマ・レプリカを自動的に最新の状態にできない状況でのみ適用されます。このような状況には、データベース・ファイルの破損、または長期にわたるレプリケーションの中断が含まれます。これらの場合、次の方法のいずれかによりコンシューマをリストアまたは初期化しなおす必要があります。
最も簡単な方法は、バックアップをリストアせずに、サプライヤ(マスターまたはハブ・レプリカ)のいずれかよりコンシューマを初期化しなおすことです。これにより、最新データがそのコンシューマへ送られ、データのレプリケーション準備が整います。「LDIFからのレプリカの初期化」を参照してください。
非常に多くのエントリを持つレプリカの場合、バイナリ・コピーを作成して、別のコンシューマのレプリケートされた接尾辞からの最新のバックアップをリストアすれば、高速化できます。「バイナリ・コピーを使用したレプリケートされた接尾辞の初期化」を参照してください。コピーするコンシューマのレプリカが他にない場合、前項での説明のようにレプリカを初期化しなおすか、次項での説明のようにレプリカをリストアします(可能な場合)。
どのサプライヤ(ハブまたはマスター・レプリカ)に対しても変更ログ・コンテンツ最大経過時間も超えていないコンシューマのバックアップがあれば、そのバックアップをこのコンシューマのリストアに使用できます。コンシューマをリストアする場合、そのサプライヤは各自の変更ログを使用して、そのバックアップの保存以降に処理されたすべての変更により、このコンシューマを更新します。
マルチマスターのレプリケーションの場合、あるマスターのリストア中に、他のマスターが変更を処理することもあります。したがって、リストア完了時に、新しいマスターは、リストア・データには含まれていなかった新しい更新を受け取る必要があります。マスターのリストアには莫大に時間がかかる場合があるので、保留中の更新数もまた莫大になることがあります。
それらの保留中の更新を収束させるために、新たにリストアされたマスターはリストア後、クライアント操作に対して自動的に読取り専用モードに設定されます。これは、コマンドラインでLDIFファイルからデータをインポートするか、バックアップを使用してバイナリ・コピーを実行することでマスターをリストアする場合にのみ当てはまります。
したがってリストア後は、マルチマスター構成のマスターは、レプリケーション更新を処理して読取り操作を許可しますが、クライアントからの書込み操作すべてに対してはリフェラルを返します。
更新が許可される前に、新しいマスターが他のマスターと完全に同期していることを確認するには、初期化されたマスターで手動により更新を有効にします。
注意: この新しい動作によってリフェラルを送信するマスター・レプリカでは、書込み操作を実行するクライアントが構成されたホップ制限に達する場合があります。この場合、クライアントのホップ制限の構成を増やして、クライアントが使用可能なマスターへアクセスできるようにする必要があります。すべてのマスター・レプリカが初期化または再初期化されている場合、クライアント更新を受け付けるレプリカがないので、書込み操作はすべて失敗します。
いずれにしても、初期化されたマスターを注意して監視し、リフェラル属性を適切に設定してサーバーのレスポンスを最大にしてください。
このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。
次のコマンドをマルチマスター・レプリカの初期化プロセスを自動化するスクリプトで使用できます。
全サーバーにおける変更の遅延がゼロの場合、またはレプリカにレプリケートする変更がない場合(-1の遅延)、レプリカは同期状態にあります。詳細は、insync(1)のマニュアル・ページを参照してください。
$ dsconf set-suffix-prop -h host -p port suffix-DN repl-accept-client-update-enabled:on
このコマンドにより、読み書きモードが自動的に設定されます。