7.4. 他の Directory Server 機能でのレプリケーションの使用
レプリケーションは、その他の Directory Server 機能に対応して、高度なレプリケーション機能を提供します。次のセクションでは、レプリケーションストラテジーをより適切に設計するための機能の連携について説明します。
7.4.1. レプリケーションおよびアクセス制御 リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
ディレクトリーサービスは ACI をエントリーの属性として保存します。つまり、ACI は他のディレクトリー内容とともに複製されます。Directory Server は ACI をローカルで評価するため、これは重要になります。
ディレクトリーのアクセス制御の設計に関する詳細は、9章セキュアなディレクトリーの設計 を参照してください。
7.4.2. レプリケーションおよび Directory Server プラグイン リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
レプリケーションは、Directory Server に同梱されるほとんどのプラグインと連携します。次のプラグインを使用したマルチサプライヤーレプリケーションの場合、いくつかの例外と制限があります。
- Attribute Uniqueness プラグインAttribute Uniqueness プラグインは、ローカルエントリーに追加された属性値を検証し、すべての値が一意であることを確認します。ただし、このチェックはサーバー上で直接行われ、他のサプライヤーから複製されることはありません。たとえば、Example Corp. では、
mail属性が一意でなければなりませんが、同じmail属性を持つ 2 人のユーザーが 2 つの異なるサプライヤーサーバーに同時に追加されます。命名の競合がない限り、レプリケーションの競合はありませんが、mail属性は一意ではありません。 - 参照整合性プラグイン参照整合性は、このプラグインがマルチサプライヤーセットの 1 つのサプライヤーでのみ有効になっている場合に、マルチサプライヤーレプリケーションで機能します。これにより、参照整合性の更新が 1 つのサプライヤーサーバーのみで行われ、他のサーバーに伝播されます。
注記
デフォルトでは、これらのプラグインは無効になっており、手動で有効にする必要があります。
7.4.3. レプリケーションおよびデータベースのリンク リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
ディレクトリーエントリーを配布するためにチェーンを使用すると、データベースリンクが含まれるサーバーは、実際のデータが含まれるリモートサーバーを参照します。この環境では、データベースリンク自体を複製できません。ただし、リモートサーバーの実際のデータが含まれるデータベースを複製 できます。
レプリケーションプロセスは、データベースリンクのバックアップとして使用しないでください。データベースリンクは手動でバックアップする必要があります。チェーンとエントリーの配布の詳細は、6章ディレクトリートポロジーの設計 を参照してください。
図7.10 チェーンされたデータベースの複製
7.4.4. スキーマレプリケーション リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
標準スキーマでは、コンシューマーサーバーにデータを複製する前に、サプライヤーサーバーは、独自のバージョンのスキーマがコンシューマーサーバーに保存されているスキーマのバージョンと同期されているかどうかを確認します。以下の条件が適用されます。
- サプライヤーとコンシューマーの両方のスキーマエントリーが同じである場合、レプリケーション操作が続行されます。
- サプライヤーサーバー上のスキーマのバージョンがコンシューマーに保存されているバージョンより新しい場合、サプライヤーサーバーはそのスキーマをコンシューマーに複製してからデータの複製を続行します。
- サプライヤーサーバーのスキーマがコンシューマーに保存されているバージョンよりも古い場合、コンシューマーのスキーマが新しいデータをサポートできないため、サーバーはレプリケーション中に多くのエラーを返すことがあります。
注記
サプライヤーとレプリカ間のスキーマが一致しない場合でも、スキーマレプリケーションは実行されます。
複製可能な変更には、Web コンソールを介して行われたスキーマへの変更、ldapmodify を介して行われた変更、および
99user.ldif ファイルに直接行われた変更が含まれます。カスタムスキーマファイル、およびカスタムスキーマファイルに追加された変更は複製されません。
コンシューマーには、スキーマが異なる 2 つのサプライヤーからの複製データが含まれる場合があります。どのサプライヤーが更新されても最後が優先され、そのスキーマがコンシューマーに伝播されます。
警告
サプライヤーサーバーは競合を解決できず、レプリケーションは失敗するため、コンシューマーサーバーでスキーマを更新しないでください。スキーマは、複製されたトポロジーのサプライヤーサーバーで維持する必要があります。
同じ Directory Server は、サプライヤーとしてのロールを果たす読み取り/書き込みレプリカと、コンシューマーとしてのロールを果たす読み取り専用レプリカを保持することができます。そのため、スキーマのサプライヤーとして機能するサーバーを常に特定し、このサプライヤーと、スキーマ情報のコンシューマーとして機能するレプリケーション環境の他のサーバーとの間にレプリケーションアグリーメントを設定します。
スキーマを複製するために特別なレプリケーションアグリーメントは必要ありません。サプライヤーとコンシューマーの間でレプリケーションが設定されていると、スキーマレプリケーションがデフォルトで実行されます。
スキーマ設計の詳細は、3章ディレクトリースキーマの設計 を参照してください。
カスタムスキーマ
標準の 99user.ldif ファイルがカスタムスキーマに使用される場合、これらの変更はすべてのコンシューマーに複製されます。
すべてのサーバーで同じスキーマファイルの情報を維持するには、カスタムスキーマファイルを各サーバーにコピーする必要があります。カスタムスキーマファイル、およびこれらのファイルへの変更は、Web コンソールまたは ldapmodify を介して加えられても複製されません。
カスタムスキーマファイルがある場合は、サプライヤーでの変更後にこれらのファイルがすべてのサーバーにコピーされていることを確認します。すべてのファイルがコピーされたら、サーバーを再起動します。
カスタムスキーマファイルの詳細は、「カスタムスキーマファイルの作成」 を参照してください。
7.4.5. レプリケーションおよび同期 リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
Directory Server 全体で、同期された Windows エントリーを伝播するには、マルチサプライヤー環境内で同期を使用します。同期アグリーメントは、可能な限り最小限に抑える必要があり、できればデプロイメントごとに 1 つにします。マルチサプライヤーレプリケーションにより、データアクセスポイントを単一のディレクトリーサーバーに制限しながら、Windows 情報をネットワーク全体で利用できるようになります。