前へ     目次     索引     DocHome     次へ     
iPlanet Directory Server 5.1 導入ガイド



第 6 章   レプリケーションの設計


ディレクトリの内容を複製すると、ディレクトリの可用性と性能が向上します。第 4 章と第 5 章では、ディレクトリツリーとディレクトリトポロジ (topology) の設計について検討しました。この章では、データの物理的および地理的な場所に焦点を当て、特に、レプリケーション (replication) を使用していつでもどこでも必要なときにデータを使用できるようにする方法について考察します。

またこの章では、複製の使用方法についても説明し、個々のディレクトリ環境に合った複製方法を設計するための指針も示します。この章は、次の節で構成されています。



レプリケーションについて

レプリケーションとは、1 つの Directory Server から別の Directory Server にディレクトリのデータを自動的にコピーするメカニズムのことです。レプリケーションを行うと、それ自身のデータベースに格納しているディレクトリツリーやサブツリーをサーバ間でコピーできます。情報のマスターコピーを保持している Directory Server は、更新内容をすべてのレプリカに自動的にコピーします。

レプリケーションを行うと、可用性の高いディレクトリサービスを提供でき、データを地理的に分散することができます。具体的には、レプリケーションには次のような利点があります。

  • 耐障害性とフェイルオーバ

    ディレクトリツリーを複数のサーバにレプリケーションすると、ハードウェア、ソフトウェア、またはネットワークに障害が発生し、ディレクトリクライアントアプリケーションが特定の Directory Server にアクセスできない場合でも、ディレクトリを利用可能にできます。クライアントは、読み取りや書き込み操作を実行するために、別の Directory Server に転送されます。書き込みフェイルオーバをサポートするには、多重マスター複製環境にする必要があります。

  • 負荷均衡

    ディレクトリツリーを複数のサーバに複製することで、各マシン上のアクセス負荷を軽減し、サーバの応答時間を改善できます。

  • 性能の向上と応答時間の短縮

    ディレクトリのエントリをユーザに近い場所に複製することで、ディレクトリの応答時間を大幅に改善できます。

  • ローカルでのデータの管理

    レプリケーションを行うと、ローカルにデータを所有して管理でき、同時に全社レベルでそのデータをほかの Directory Server と共有できます。

ディレクトリ情報のレプリケーション戦略を決定する前に、レプリケーションの動作を理解しておく必要があります。以下に、次の事項について説明します。


レプリケーションの概念

レプリケーションの導入を計画するときは、常に次の基本事項を決定することから始めます。

これらの事項は、Directory Server がこれらの概念をどのように処理するかを理解していないと効果的に決定できません。たとえば、レプリケーションする情報を決める場合は、Directory Server が処理できる最小のレプリケーション単位を知っておく必要があります。次に、Directory Server で使用される概念を定義します。ここでは、全体的な決定事項について検討するための枠組みを示します。


レプリカ

レプリケーションに関与するデータベースのことを、レプリカと呼びます。レプリカにはいくつかの種類があります。

  • マスターレプリカ : ディレクトリデータのマスターコピーを格納する読み書き可能データベース。マスターレプリカはディレクトリクライアントからの更新要求を処理できる

  • コンシューマレプリカ : マスターレプリカに保持される情報のコピーを格納する読み取り専用データベース。コンシューマレプリカはディレクトリクライアントからの検索要求は処理できるが、更新要求はマスターレプリカに転送する

  • ハブレプリカ : コンシューマレプリカと同じく、読み取り専用データベース。ただし、ハブレプリカはハブサプライヤとして動作する Directory Server に格納される

複数のデータベースを管理するように Directory Server を構成することができます。各データベースはレプリケーションにおける異なる役割を持つことができます。たとえば、マスターレプリカに dc=engineering,dc=siroe,dc=com 接尾辞を格納し、コンシューマレプリカに dc=sales,dc=siroe,dc=com 接尾辞を格納する Directory Server を構成できます。


サプライヤとコンシューマ

ほかのサーバに複製するマスターレプリカを管理するサーバは、サプライヤ (supplier) サーバまたはマスターサーバと呼ばれます。別のサーバによって更新されるコンシューマレプリカを管理するサーバは、コンシューマ (consumer) サーバと呼ばれます。

サーバのサプライヤまたはコンシューマとしての役割について説明します。ただし、サーバはサプライヤとコンシューマのどちらにもなれるため、厳密なものではありません。これは、以下のような場合に当てはまります。

  • Directory Server がマスターレプリカとコンシューマレプリカの組み合わせを管理する場合

  • Directory Server がハブサプライヤ (hub supplier) の役目を果たす場合。つまり、マスターサーバからの更新を受け取り、変更をコンシューマサーバにレプリケートする場合。詳細は、「カスケード型レプリケーション」を参照

  • マルチマスターレプリケーションで、一方の Directory Server が他方の Directory Server のサプライヤおよびコンシューマとして動作する 2 つの Directory Server 上にマスターレプリカが保持される場合。詳細は、「マルチマスターレプリケーション」を参照

iPlanet Directory Server 5.1 では、レプリケーションは常にサプライヤサーバから開始されます。コンシューマサーバから開始されることはありません。この処理は、サプライヤ主導レプリケーション (supplier-initiated replication) と呼ばれます。この処理により、1 つ以上のコンシューマサーバへデータをプッシュするようにサプライヤサーバを構成できます。

iPlanet Directory Server の旧バージョンでは、コンシューマサーバがサプライヤサーバからデータを引き出すコンシューマ主導レプリケーション (consumer-initiated replication) を開始することができました。iPlanet Directory Server 5.1 ではこれが変更され、コンシューマサーバがサプライヤサーバに更新の送信を促すようになりました。

すべての複製に対して、サプライヤサーバは次のような処理を実行する必要があります。

  • ディレクトリクライアントからの読み取り、追加、および変更の要求に応答する

  • 複製の状態情報と更新履歴ログを保持する

  • コンシューマサーバへの複製を開始する

    サプライヤサーバは、管理しているサプライヤレプリカへの変更を常に記録します。そのため、すべての変更がコンシューマサーバにレプリケーションされます。

コンシューマサーバは次のような処理を実行する必要があります。

  • 読み取り要求に応答する

  • 追加要求と変更要求をレプリカのサプライヤサーバに転送する

    コンシューマサーバは、エントリの追加、削除、または変更の要求を受け取った場合、それらの要求を常にレプリカのサプライヤサーバに転送します。サプライヤサーバは要求を実行してから、変更を複製します。

カスケード型レプリケーションの場合、ハブサプライヤ (hub supplier) は次のような処理を実行する必要があります。

  • 読み取り要求に応答する

  • 追加要求と変更要求をレプリカのサプライヤサーバに転送する

  • コンシューマサーバへの複製を開始する

カスケード型レプリケーションについては、「カスケード型レプリケーション」を参照してください。


更新履歴ログ

すべてのサプライヤサーバは、更新履歴ログ (change log) を保持しています。更新履歴ログとは、サプライヤレプリカに対して行われた変更を記述しておく記録のことです。サプライヤサーバは、コンシューマサーバに格納されているレプリカに対して、またはマルチマスターのレプリケーションの場合はほかのマスターに対して、これらの変更を適用します。

エントリの変更、追加、または削除が行われると、実行された LDAP 操作を記述する変更レコードが更新履歴ログに記録されます。

以前のバージョンの Directory Server では、LDAP から更新履歴ログにアクセスできました。最新バージョンでは、サーバによる内部処理専用になりました。使用しているアプリケーションで更新履歴ログを読み取る必要のある場合は、レトロログのプラグインを使用して、下位互換性を保つ必要があります。詳細は、『iPlanet Directory Server 管理者ガイド』を参照してください。


レプリケーションの単位

iPlanet Directory Server 5.1 では、複製の最小単位はデータベースです。つまり、データベース全体を複製することはできますが、データベース内のサブツリーだけを複製することはできません。そのため、ディレクトリツリーを作成するときは、複製計画を考慮に入れる必要があります。ディレクトリツリーの設定方法については、第 5 章「ディレクトリトポロジの設計」を参照してください。

複製メカニズムでは、接尾辞とデータベースが 1 対 1 で対応している必要があります。つまり、カスタム分散論理を使用している 2 つ以上のデータベースにまたがって分散されている接尾辞 (またはネームスペース) は複製できません。


レプリケーションアグリーメント

Directory Server では、レプリケーションアグリーメントを使用してレプリケーションを定義します。レプリケーションアグリーメント (replication agreement) は、1 つのサプライヤ (supplier) と 1 つのコンシューマ (consumer) との間で行われるレプリケーションを記述します。契約はサプライヤサーバ上に設定され、次のものを特定します。複製契約では、次のものを確認します。

  • 複製するデータベース

  • データが複製されるコンシューマサーバ

  • レプリケーションを実行できる時間帯

  • サプライヤサーバがコンシューマサーバにバインドするために使用する必要のある DN と資格 (レプリケーションマネージャエントリ、またはサプライヤバインド DN と呼ばれる。詳細は、「レプリケーションの識別情報」を参照)

  • 接続の安全性を確保するための手段 (SSL、クライアント認証)


レプリケーションの識別情報

2 つのサーバ間でレプリケーションが発生する場合は、サプライヤサーバがレプリケーションの更新を送信するためにコンシューマサーバにバインドすると、コンシューマサーバはそのサプライヤサーバを認証します。この認証処理では、サプライヤサーバがコンシューマサーバにバインドするために使用するエントリが、コンシューマサーバに格納されている必要があります。このエントリはレプリケーションマネージャエントリ、またはサプライヤバインド DN と呼ばれます。

レプリケーションマネージャエントリおよびその役割を遂行するために作成したエントリは、以下の条件を満たしていなくてはなりません。

  • コンシューマレプリカ(またはハブレプリカ) を管理するすべてのサーバに、このエントリが少なくとも 1 つあること

  • セキュリティ上の理由から、このエントリがレプリケーションされたデータの一部ではないこと


    注  

    このエントリには、コンシューマサーバに定義されているアクセス制御規則をすべて無視する特別なユーザプロファイルがあります。  

2 つのサーバ間でレプリケーションを構成する場合は、両方のサーバでレプリケーションマネージャエントリ (サプライヤバインド DN) を特定する必要があります。

  • コンシューマサーバまたはハブサプライヤでは、コンシューマレプリカまたはハブレプリカを構成するときに、このエントリをレプリケーションの更新を実行する権利を持っているエントリとして指定する

  • サプライヤサーバでは、レプリケーションアグリーメントを構成するときに、レプリケーションアグリーメントでこのエントリの DN を指定しておく


    注  

    Directory Server Console では、このレプリケーションマネージャエントリがサプライヤバインド DN と呼ばれるため、このエントリがサプライヤサーバには存在しないという誤解を産むことがあります。サプライヤバインド DN と呼ばれるのは、これが、サプライヤサーバがレプリケーションの更新を送信するためにコンシューマサーバにバインドしたときに、コンシューマサーバがサプライヤサーバを認証できるように、コンシューマサーバに存在していなければならないエントリであるからです。  


データの整合性

整合性とは、複製されたデータベースの内容が、任意の時点でどの程度マッチしているかを示します。2 つのサーバ間で複製を設定する場合は、設定の中で更新をスケジュールします。iPlanet Directory Server 5.1 では、必ずサプライヤサーバがいつコンシューマサーバを更新すべきかを判断し、レプリケーションを開始します。

Directory Server には、常に複製の同期を維持するオプションと、特定の時間または曜日に更新をスケジュールするオプションが用意されています。常に複製の同期を維持する利点は、データの整合性がより確実に保証されるという点です。ただしその場合は、頻繁な更新操作によってネットワークトラフィックが増大します。このソリューションは、次の場合に最適です。

  • サーバ間で信頼性が高く高速な接続を利用できる場合

  • ディレクトリのサービスを受けるクライアント要求が主に検索、読み取り、および比較の操作であり、追加と変更の操作は比較的少ない場合

データの整合性が低くてもかまわない場合は、必要に応じて更新の頻度を選択して、ネットワークトラフィックへの影響を軽減することができます。このソリューションは、次の場合に最適です。

  • ネットワーク接続の信頼性が低いか、あるいは断続的なネットワーク接続を使用している場合 (ダイアルアップ接続を使用して複製の同期をとっている場合など)

  • ディレクトリがサービスするクライアント要求が主に追加と変更の操作である場合

  • 通信コストを削減する必要がある場合

マルチマスターレプリケーションの場合は、一般に、各マスターに格納されているデータ間に違いがある可能性があるため、各マスター上の複製は緩やかな 整合性を保っている状態といえます。これは、常に複製の同期を維持するように選択している場合にも当てはまります。理由は次のとおりです。

  • マスター間のレプリケーションの更新操作の伝達に遅延があるため

  • 追加または変更の操作を実行したマスターは、2 番目のマスターがその更新操作を検証するのを待たずに「操作は正常に完了しました」というメッセージをクライアントに返すため



一般的なレプリケーションの例

レプリケーションの更新情報をサーバ間でやり取りする方法と、更新情報を伝達するときのサーバ間の相互動作の方法を決める必要があります。次の 3 つの基本的な例について説明します。

次に、上記の複製方法について説明し、環境にもっとも適した方法を決定するための指針を示します。これらの基本的な例を組み合わせて、要件にもっとも合ったレプリケーショントポロジを構築することもできます。


単一マスターレプリケーション

レプリケーションのもっとも基本的な構成では、1 つのマスターサーバが 1 つ以上のコンシューマサーバにサプライヤレプリカを直接コピーします。この構成では、ディレクトリの変更はすべてサプライヤサーバ上のサプライヤレプリカ (supplier replica) 上で行われ、コンシューマサーバにはデータの読み取り専用コピーが格納されています。

サプライヤサーバは、マスターレプリカへのすべての変更を記録する更新履歴ログを維持します。また、サプライヤサーバにはレプリケーションアグリーメントも格納されます。

サプライヤサーバがレプリケーションの更新を送信するためにコンシューマサーバにバインドしたときに、コンシューマサーバがサプライヤサーバを認証できるように、コンシューマサーバにはサプライヤバインド DN に対応しているエントリが格納されます。

サプライヤサーバはすべての変更をコンシューマレプリカに伝達する必要があります。図 6-1 に、この簡単な構成を示します。

図 6-1    単一マスター複製

図 6-1 にはコンシューマサーバが 1 つしかありませんが、サプライヤサーバは複数のコンシューマサーバにレプリケーションできます。1 つのサプライヤサーバが管理できるコンシューマサーバの総数は、ネットワークの速度と 1 日当たりのエントリの変更総数によって異なりますが、1 つのサプライヤサーバで複数のコンシューマサーバを管理できると想定して特に問題ありません。


マルチマスターレプリケーション

多重マスター構成には、次の利点があります。

  • 1 つのサプライヤにアクセスできなくなった場合でも、自動的に書き込み処理のフェイルオーバが実行される

  • 地域分散型環境のローカルサプライヤで更新処理を実行できる

マルチマスターレプリケーション (multi-master replication) 環境では、同じ情報のマスターコピーが 2 つのサーバ上に存在します。これは、異なる場所でデータを同時に更新できるということを意味します。一方のサーバ上で行われた変更は他方のサーバに複製されます。つまり、各サーバはサプライヤとコンシューマの両方の役割を果たします。

同じデータが両方のサーバ上で変更された場合は、どちらの変更を格納するか決めるために、競合を解決するための措置がとられます。Directory Server は、最新の変更を有効な変更とみなします。

独立した 2 つのサーバが同じデータのマスターコピーを保持することはできますが、1 つの複製契約においては、1 つのサプライヤサーバと 1 つのコンシューマサーバだけしか存在できません。そのため、同じデータの管理責任を共有する 2 つのサプライヤサーバ間にマルチマスター環境を構築するには、複数のレプリケーションアグリーメントを作成する必要があります。次の図に、この設定を示します。

図 6-2    多重マスター複製の構成 (2 つのマスター)

この図では、サプライヤ A とサプライヤ B がそれぞれ同じデータのサプライヤレプリカを保持します。

保有できるマスターまたはサプライヤの数は、どの複製環境でも 2 つだけです。ただし、コンシューマレプリカを保持するコンシューマサーバの数は制限されていません。図 6-3 に、2 つのマスターサーバと 2 つのコンシューマサーバが存在する環境でのレプリケーショントラフィックを示します。この図は、コンシューマが両方のマスターによって更新されることを示しています。マスターは、変更の競合を調整する措置をとります。

図 6-3    多重マスター環境での複製トラフィック


カスケード型レプリケーション

カスケード型レプリケーションは、以下のような場合に非常に役立ちます。

  • 非常に大きなトラフィック負荷を均等にする必要がある場合。たとえば、サプライヤサーバはすべての更新トラフィックを処理する必要があるため、コンシューマサーバへのすべてのレプリケーショントラフィックをサポートするには、非常に大きな負荷がかかる。多数のコンシューマに対するレプリケーションの更新を処理できるハブサーバにレプリケーショントラフィックの負荷を移すことができる

  • 地域分散型環境でローカルハブサプライヤを使用して、接続コストを削減する場合

  • ディレクトリサービスの性能を向上させる場合。読み取り操作を行うすべてのクライアントアプリケーションをコンシューマへ、更新操作を行うすべてのクライアントアプリケーションをサプライヤへ導くことができるなら、ハブサーバのすべてのインデックス (システムインデックスを除く) を削除できる。これによって、サプライヤとハブサーバとの間のレプリケーション速度が大幅に向上する

カスケード型レプリケーション (cascading replication) では、ハブサプライヤがサプライヤサーバから更新情報を受け取り、コンシューマサーバに更新内容を適用します。ハブサプライヤ (hub supplier) はハイブリッドです。つまり、通常のコンシューマサーバと同様にデータの読み取り専用コピーを保持すると同時に、通常のサプライヤサーバと同様に更新履歴ログも保持しています。

ハブサプライヤは、元のマスターから受け取ったマスターデータのコピーを転送します。同様に、ディレクトリクライアントから追加または変更の要求を受け取ったときは、そのクライアントをマスターサーバに転送します。

このカスケード型複製の例を図 6-4 に示します。

図 6-4    カスケード型レプリケーションの例

同じ例を別の視点から図にすると、図 6-5 のようになります。この図では、サーバの構成を示します (レプリケーションアグリーメント、更新履歴ログ、レフェラル)。

図 6-5    カスケード型レプリケーションでのサーバ構成


混合環境

上記で説明した例を任意に組み合わせて、要件にもっとも合った環境を構築できます。たとえば、マルチマスター構成とカスケード型構成を組み合わせて、図 6-6 に示すような構成も可能です。

図 6-6    マルチマスターレプリケーションとカスケード型レプリケーションの組み合わせ



レプリケーション戦略の定義


使用する複製手法は、提供するサービスによって決まります。

  • 高可用性を最優先する場合は、1 つのサイトに複数の Directory Server を配備したデータセンターを構築する必要がある。読み取りフェイルオーバを提供するには単一マスター複製を、書き込みフェイルオーバを提供するには多重マスター複製を使用できる。高可用性を実現するためのレプリケーションの設定方法については、「高可用性を実現するためのレプリケーションの使用」で説明している

  • ローカルでのデータの利用性を最優先する場合は、複製を使用して、世界中のオフィスに配置されている Directory Server にデータを物理的に分散する必要がある。本社などの単一の場所にすべての情報のマスターコピーを保管するか、あるいはそれぞれのローカルサイトが自分のサイトに関連する DIT 部分を管理するようにするか選択できる。レプリケーションの設定タイプについては、「ローカルでのデータの利用性を高めるためのレプリケーションの使用」で説明している

  • どの場合でも、Directory Server がサービスする要求の負荷を均等にして、ネットワークへの過剰負荷を防ぐ必要がある。Directory Server とネットワークへの負荷を均等にする戦略については、「負荷均衡のためのレプリケーションの使用」で説明している

複製手法を決定するには、ネットワーク、ユーザ、アプリケーション、および提供するディレクトリサービスがユーザやアプリケーションによってどのように使われるかを調査することから始めます。この調査のガイドラインについては、「レプリケーション調査」を参照してください。

複製手法を決定したら、ディレクトリの導入を開始できます。ディレクトリサービスを段階的に導入していくことをお勧めします。ディレクトリを実際の環境に導入する段階に入ると、ディレクトリを全体的に導入した際の負荷をより正確に把握できるようになります。実際に運用されているディレクトリに基づいた負荷分析を行うことができない場合は、ディレクトリの使用状況をよく把握して、ディレクトリを修正するために準備してください。

次に、複製方法の決定に影響する要因について詳しく説明します。


レプリケーション調査

複製手法を決定するときは、調査を通じて次のような情報を収集する必要があります。

  • 異なる建物間やリモートサイト間を接続する LAN および WAN の品質と使用可能な帯域幅の大きさ

  • ユーザの物理的な位置、各サイトのユーザ数、ユーザのアクティビティ

    たとえば、人事データベースや財務情報を管理するサイトは、ディレクトリを単に電話帳として使用する技術スタッフを含むサイトより、ディレクトリに大きな負荷をかけます。

  • ディレクトリにアクセスするアプリケーションの数と、書き込み操作に対する読み取り、検索、および比較の操作の比率

    たとえば、メッセージングサーバがディレクトリを使用する場合は、処理するメールメッセージごとにディレクトリが実行する操作数を知る必要があります。ディレクトリを使用するほかの認証アプリケーションや META Directory アプリケーションなど、典型的な製品です。アプリケーションごとに、ディレクトリで実行される操作のタイプと頻度を調べる必要があります。

  • ディレクトリに格納するエントリの数とサイズ


レプリケーション資源の要件

複製を使用する場合は、さらに資源が必要になります。複製手法を決定するときは、次の資源要件を検討してください。

  • ディスク使用量

    サプライヤサーバでは、各更新操作後に更新履歴ログが書き込まれます。サプライヤサーバが多数の updabhubcon2supplier サーバを受け取ると、サプライヤサーバに複数の複製データベースがある場合は、更新履歴ログがより頻繁に使用され、ディスクの使用量がさらに増大します。

  • サーバスレッド

    複製契約ごとに 1 つのサーバスレッドが消費されます。そのため、クライアントアプリケーションで使用できるスレッドの数が少なくなり、クライアントアプリケーションに対するサーバの性能に影響があります。

  • ファイルディスクリプタ

    サーバで使用できるファイルディスクリプタの数が、更新履歴ログ (1 ファイルディスクリプタが必要) と各複製契約 (契約ごとに 1 ファイルディスクリプタが必要) によって減少します。


高可用性を実現するためのレプリケーションの使用

複製を使用して、単一のサーバの障害によってディレクトリが使用できなくなることを防止します。最低限、ローカルのディレクトリツリーを少なくとも 1 つのバックアップサーバに複製しておきます。

ディレクトリの設計者の中には、データの信頼性を最大限保証するために物理的な場所ごとに 3 回は複製しておく必要があると主張する人もいます。耐障害性を目的とした複製の使用頻度はユーザの決定事項ですが、その決定はディレクトリで使用するハードウェアとネットワークの品質を考慮したものでなければなりません。信頼性の低いハードウェアでは、より多くのバックアップサーバが必要になります。


注  

通常のデータバックアップポリシーの代替として複製を使用してはいけません。ディレクトリデータのバックアップについては、『iPlanet Directory Server 管理者ガイド』を参照してください。  

すべてのディレクトリクライアントに書き込みフェイルオーバを保証する必要がある場合は、マルチマスターレプリケーションの手法を使用する必要があります。読み取りフェイルオーバで充分な可用性が達成できる場合は、単一マスター複製を使用できます。

LDAP クライアントアプリケーションは通常、1 つの LDAP サーバだけを検索するように設定できます。つまり、カスタムクライアントアプリケーションを異なる DNS ホスト名にある LDAP サーバを循環するように作成していないかぎり、LDAP クライアントアプリケーションが Directory Server の単一の DNS ホスト名を検索するように設定するだけで済みます。したがって、バックアップ用の Directory Server にフェイルオーバを提供するには、DNS ラウンドロビンまたはネットワークソートのどちらかを使用する必要があります。DNS ラウンドロビンとネットワークソートの設定方法と使用方法については、DNS のマニュアルを参照してください。

代わりに、iPlanet Directory Access Router 製品を使用することもできます。iPlanet Directory Access Router については、http://www.iplanet.com を参照してください。


ローカルでのデータの利用性を高めるためのレプリケーションの使用

複製を使用して、ローカルでもデータを利用できるようにする必要があるかどうかはネットワークの品質とそのサイトでなにを行うかによって決まります。また、ディレクトリに格納するデータの特性と、データが一時的に使用できなくなった場合の会社への影響について慎重に考慮する必要があります。データの重要性が高ければ、それだけ品質の低いネットワーク接続によって引き起こされる業務停止は、許容できないものになります。

次の理由により、ローカルでもデータを利用するために複製を使用する必要があります。

  • データのローカルマスターコピーが必要である

    これは、特定の国の従業員にだけ重要なディレクトリ情報を管理する必要がある、大規模な国際企業にとって重要な戦略です。また、データのローカルマスターコピーを保有することは、経営方針としてデータを部門レベルまたは組織レベルで管理するようにしている企業にとっても重要です。

  • 信頼性が低いネットワーク接続、または断続的に利用可能なネットワーク接続を使用している

    国際ネットワークでよく見られるように、信頼性の低い WAN 使用している場合はネットワーク接続を断続的に行います。

  • ネットワークに過度な負担が定期的にかかり、ディレクトリの性能が著しく低下する

    たとえば、旧式のネットワークを使用している企業では、通常の営業時間帯にこのような状態が発生します。


負荷均衡のためのレプリケーションの使用

レプリケーションを使用すると、次のような方法で Directory Server にかかる負荷を均等にすることができます。

  • ユーザの検索アクティビティを複数のサーバに分散する

  • 書き込みはサプライヤサーバだけに限定し、その他のサーバは読み取り専用に設定する

  • メールサーバのように、特定のタスクに専用サーバを割り当てる

ディレクトリデータを複製する重要な理由の 1 つとして、ネットワーク負荷の均衡が挙げられます。可能であれば、比較的高速で信頼性の高いネットワーク接続を介してアクセス可能なサーバに、データを移動します。もっとも重要な点は、サーバとディレクトリユーザとの間のネットワーク接続の通信速度と信頼性です。

通常、ディレクトリエントリの平均サイズは約 1K バイトです。したがって、ディレクトリの検索ごとにネットワークの負荷が約 1K バイト増加します。ディレクトリユーザが検索を 1 日当たり約 10 回実行すると、ネットワークの負荷はユーザ 1 人につき 1 日当たり約 10,000 バイト増加します。低速な、負荷が大きい、あるいは信頼性が低い WAN を使用している場合は、ディレクトリツリーをローカルサーバに複製する必要がある場合もあります。

データをローカルに利用できるという利点が、複製を使用したことによるネットワーク負荷の増加という不利益を上回るかどうか慎重に検討してください。たとえば、ディレクトリツリー全体をリモートサイトにレプリケーションする場合は、ユーザのディレクトリの検索によるトラフィックに比べ、はるかに大きな負荷をネットワークに課すことになります。このことは、ディレクトリツリーが頻繁に変更されるのに対して、リモートサイトの少数のユーザが、1 日当たり数回のディレクトリ検索しか実行しない場合は、特に当てはまります。

たとえば、ディレクトリツリーに平均して 1,000,000 件を超えるエントリがあり、毎日 10 % 前後が変更される場合を考えてみます。ディレクトリエントリのサイズが平均して 1K バイトとすると、ネットワークの負荷が 1 日当たり 100M バイト増えることになります。しかし、リモートサイトの従業員がたとえば 100 人と少なく、1 日当たり平均して 10 回のディレクトリ検索を実行している場合は、ディレクトリアクセスによるネットワークの負荷は 1 日当たり 1M バイトにすぎません。

複製による負荷と通常のディレクトリの使用による負荷の違いから、ネットワークの負荷均衡を目的とする複製は好ましくないという結論に達する場合もあります。反対に、ネットワークにかかる負荷を考慮しても、ディレクトリデータをローカルで利用できる利点の方が勝っていると判断する場合もあります。

ネットワークに過度な負荷をかけずにデータをローカルサイトで使用できるようにするには、スケジュールされた複製を使用します。データの整合性とレプリケーションスケジュールについては、「データの整合性」を参照してください。


ネットワークの負荷均衡の例

2 つの都市にオフィスを持つ企業を考えてみます。各オフィスには、次の方法で管理する特定のサブツリーがあります。



各オフィスには高速のネットワークがありますが、2 都市間の通信にはダイヤルアップ接続を使用しています。このような場合は、以下のようにネットワークの負荷を均等にします。

  • オフィスごとに、ローカルで管理するデータのマスターサーバになるサーバを 1 つ選択する

    ローカルで管理するデータを、選択したサーバからリモートオフィスのマスターサーバに複製します。

  • ディレクトリデータの可用性を保証するために、リモートオフィスからのデータも含め、各マスターサーバ上のディレクトリツリーを少なくとも 1 つのローカル Directory Server にレプリケーションする。ローカルで管理する接尾辞にはマルチマスターレプリケーションを使用でき、リモートサーバからデータのマスターコピーを受け取る接尾辞にはカスケード型レプリケーションを使用できる




性能向上のための負荷均衡の例

ディレクトリで 1,500,000 のエントリを格納して 1,000,000 のユーザをサポートする必要があり、各ユーザが 1 日当たり 10 件のディレクトリ検索を実行する場合を考えてみます。また、1 日当たり 25,000,000 通のメールメッセージを処理し、メールメッセージごとに 5 件のディレクトリ検索を実行するメッセージングサーバを使用しているとします。この場合、メール処理に 1 日当たり 125,000,000 件のディレクトリ検索が実行されると予測できます。ディレクトリとメッセージングシステムの合計トラフィックでは 1 日当たり 135,000,000 件のディレクトリ検索が実行されることになります。

1 日の就業時間は 8 時間、1,000,000 人のディレクトリユーザが 4 つの時間帯に分かれているとすると、4 つの時間帯にわたる就業時間 (または、ピーク時の利用率) は 12 時間となります。したがって、1 日 12 時間で 135,000,000 件のディレクトリ検索をサポートする必要があります。これは毎秒 3,125 (135,000,000 / (60×60×12)) 件の検索をサポートするのと同じです。つまり、次のようになります。

1,000,000 人のユーザ

1 ユーザにつき 10 件の検索 =

10.000.000 件の読み取り/日

25,000,000 通のメッセージ

1 メッセージにつき 5 件の検索 =

125,000,000 件の読み取り/日

合計読み取り/日 =

135,000,000

12 時間は 43,200 秒

合計読み取り/秒 =

3,125

ここで、毎秒 500 件の読み取りをサポートできる CPU と RAM の組み合わせを Directory Server で使用しているとします。簡単な割り算で、この負荷をサポートするには 6 〜 7 つの Directory Server が必要であることがわかります。ただし、1,000,000 人のディレクトリユーザを有する企業の場合は、ローカルでデータを利用することも考慮するとさらに Directory Server を追加する必要があります。

これらの計算から、次のような方法で複製します。

  • 1 つの都市に 2 つの Directory Servers をマルチマスター構成で配置し、すべての書き込みトラフィックを処理する

    この構成は、すべてのディレクトリデータを 1 か所で管理することを想定しています。

  • 上記のサプライヤサーバを使用して 1 つ以上のハブサプライヤに複製する

    ディレクトリがサービスする読み取り、検索、および比較の要求はコンシューマサーバで処理されるので、マスターサーバは書き込み要求の処理に専念できます。ハブサプライヤの定義については、「カスケード型レプリケーション」を参照してください。

  • ハブサプライヤを使用して、会社全体のローカルサイトに複製する

    ローカルサイトにレプリケーションすることにより、サーバや WAN の作業負荷を均等にし、ディレクトリデータを高可用性を得るようにすることが可能です。国内の 4 つのサイトにレプリケーションする場合を考えてみます。その場合、各ハブサプライヤに 4 つのコンシューマが存在することになります。

  • 各サイトで、少なくとも 1 回はレプリケーションして高可用性を得るようにする。また、最低でも読み取り操作を実行できることを確認する

    DNS ソートを使用して、ローカルユーザがディレクトリ検索に使用できるローカルの Directory Server を必ず見つけられるようにします。


小規模サイト向けのレプリケーション方法の例

会社全体が 1 つの建物内にある場合を考えてみます。この建物には、毎秒 100M バイトの高速で使いやすいネットワークが装置されています。ネットワークは非常に安定しており、サーバのハードウェアと OS プラットフォームの信頼性も十分に高いものとします。また、1 つのサーバの処理能力でサイトの負荷を容易に処理できるものとします。

このような場合、保守やハードウェアのアップグレードのためにプライマリサーバが停止されたときでも、ディレクトリデータが利用できるようにしておくために、少なくとも 1 回はレプリケーションしておきます。また、Directory Server の 1 つが使用できなくなったときに LDAP 接続の性能を上げるために、DNS ラウンドロビンを設定します。代替方法として、iPlanet Directory Access Router などの LDAP プロキシを使用することもできます。iPlanet Directory Access Router については、http://www.iplanet.com を参照してください。


大規模サイト向けのレプリケーション方法の例

会社が 2 つの建物に分かれている場合を考えてみます。各建物には、毎秒 100M バイトの高速で使いやすいネットワークが装備されています。ネットワークは非常に安定しており、サーバのハードウェアと OS プラットフォームの信頼性も十分に高いものとします。また、1 つのサーバの処理能力で、各建物内のサーバにかかる負荷を容易に処理できるものとします。

建物間は低速接続 (ISDN) で、通常の営業時間中に大きな負荷がかかります。

複製方法は次のようになります。

  • いずれかの建物で、ディレクトリデータのマスターコピーを格納する 1 つのサーバを選択する

    このサーバは、ディレクトリデータのマスターコピーの管理に責任を持つ人がもっとも多くいる建物内に設置するようにします。これを建物 A とします。

  • ディレクトリデータが常に利用できるようにするために、建物 A で少なくとも 1 回は複製する

    書き込みフェイルオーバを保証する必要がある場合は、多重マスター複製構成を使用します。

  • もう一方の建物 (建物 B) 内に 2 つの複製を作成する

  • サプライヤサーバとコンシューマサーバとの間で厳密な整合性が必要ない場合は、ピーク時間外にレプリケーションが行われるようにスケジュールする



レプリケーションとほかのディレクトリ機能との併用

レプリケーションは iPlanet Directory Server のほかの機能と連携して、高度なレプリケーション機能を提供します。次に、最適な複製の設計に役立つ、機能の併用について説明します。


レプリケーションとアクセス制御

ディレクトリは ACI をエントリの属性として格納しています。つまり、ACI はほかのディレクトリ内容と一緒にレプリケーションされます。Directory Server は ACI をローカルに評価するので、このことは重要です。

ディレクトリのアクセス制御の設計方法については、第 7 章の 「安全なディレクトリの設計」を参照してください。


レプリケーションと Directory Server のプラグイン

レプリケーションは、iPlanet Directory Server に付属するほとんどのプラグインと一緒に使用できます。多重マスター複製で次のプラグインを使用する場合には、いくつかの例外と制限があります。

  • 属性一意性検査プラグイン

  • 参照整合性検査プラグイン

マルチマスターレプリケーションと属性一意性検査プラグインは一緒に使用できません。これは、このプラグインが、マルチマスターセット内の両方のサーバではなく、同じサーバ上の属性値しか検証できないためです。

参照整合性検査プラグインが多重マスターセット内の 1 つのマスター上でだけ有効になっている場合は、このプラグインと多重マスター複製を一緒に使用できます。これにより、参照整合性の更新は必ず 1 つのマスターサーバ上だけで行われ、それがほかのサーバに伝達されることが保証されます。


注  

デフォルトでは、これらのプラグインは無効になっています。有効にするには、Directory Server Console またはコマンド行ユーティリティを使用する必要があります。  


レプリケーションとデータベースリンク

連鎖 (chaining) を使用してエントリを分散する場合は、データベースリンク (database link) を含むサーバが、実際のデータがあるリモートサーバを指示します。このような環境では、データベースリンク自体を複製することはできません。ただし、実際のデータを格納しているデータベースは複製できます。

レプリケーションをデータベースリンクのバックアップには使用しないでください。データベースリンクは手動でバックアップする必要があります。連鎖とエントリの分散 (entry distribution) については、「ディレクトリトポロジの設計」を参照してください。

図 6-7    連鎖データベースのレプリケーション


スキーマのレプリケーション

レプリケーション環境で iPlanet Directory Server を使用する場合は、レプリケーションに含まれるすべての Directory Server についてスキーマの一貫性を維持する必要があります。サーバ間でスキーマの一貫性が維持されない場合は、レプリケーションで多くのエラーが発生する可能性があります。

スキーマの一貫性を確保するために、マルチマスターレプリケーション環境の場合でも、1 つのマスターサーバでスキーマの変更を行うことをお勧めします。

スキーマの複製は自動的に行われます。サプライヤとコンシューマ間で複製が設定されている場合は、デフォルトでスキーマが複製されます。

iPlanet Directory Server でスキーマのレプリケーションに使用されるロジックはどのレプリケーションでも同じで、次のように説明できます。

  1. データをコンシューマサーバに送る前に、サプライヤサーバは自身のスキーマがコンシューマサーバ上で保持されているスキーマ (schema) と同期しているかどうかを検査します。

  2. サプライヤとコンシューマ両方のスキーマエントリが同じであれば、複製が実行されます。

  3. サプライヤサーバ上のスキーマがコンシューマに格納されているものよりも新しい場合、サプライヤはデータの複製を実行する前に自身のスキーマをコンシューマに複製します。


    注  

    サプライヤサーバ上のスキーマがコンシューマに格納されているものよりも古い場合は、コンシューマ上のスキーマが新しいデータをサポートできないので、複製中に多数のエラーが発生します。  

マルチマスターセットの 2 つのマスターサーバでスキーマの変更を行う場合、コンシューマには 2 つのマスターからレプリケーションされた、それぞれが異なるスキーマを持つデータが格納されます。最後に更新されたマスターが優先され、そのスキーマがコンシューマに伝達されます。このため、コンシューマ上のスキーマは、常に一方のマスターのスキーマとは異なることになります。これを回避するために、常に 1 つのマスターだけでスキーマの変更を行います。


注  

コンシューマサーバ上のスキーマは絶対に更新しないでください。サプライヤサーバは起こりうる不整合を解決できないので、レプリケーションは失敗します。

スキーマは複製トポロジのマスターサプライヤサーバ上で保持する必要があります。標準の 99user.ldif ファイルを使用している場合は、これらの変更がすべてのコンシューマに複製されます。カスタムのスキーマファイルを使用している場合は、マスターサプライヤ上で変更を行ったら、必ずこれらのファイルをすべてのサーバにコピーしてください。ファイルをコピーしたら、サーバを再起動する必要があります。詳細は、「カスタムスキーマファイルの作成」を参照してください。  

カスタムのスキーマファイルへの変更は、スキーマが LDAP または Directory Server Console を使用して更新されている場合にだけ複製されます。これらのカスタムスキーマファイルは、すべてのサーバ上で情報を同じスキーマファイルに保持するために、各サーバにコピーする必要があります。詳細は、「カスタムスキーマファイルの作成」を参照してください。

スキーマ設計については、第 3 章「スキーマの設計」を参照してください。


前へ     目次     索引     DocHome     次へ     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated March 02, 2002