|
| Sun ONE Directory Server 5.2 配備ガイド |
ディレクトリの内容をレプリケートすると、ディレクトリの可用性とパフォーマンスが向上します。第 4 章と第 5 章では、ディレクトリツリーとディレクトリトポロジの設計について検討しました。この章では、データの物理的および地理的な場所に焦点を当て、特に、レプリケーションを使用していつでもどこでも必要なときにデータを使用できるようにする方法について考察します。
またこの章では、レプリケーションの使用方法についても説明し、個々のディレクトリ環境に合ったレプリケーション方法を設計するための指針も示します。この章は、次の節で構成されています。
レプリケーションについて
レプリケーションとは、1 つの Directory Server から別の Directory Server にディレクトリのデータを自動的にコピーするメカニズムのことです。レプリケーションを行うと、それ自身のデータベースに格納しているディレクトリツリーやサブツリーをサーバー間でコピーできます。ただし、設定や監視の情報サブツリーはコピーされません。
レプリケーションを行うと、可用性の高いディレクトリサービスを提供でき、データを地理的に分散することができます。具体的には、レプリケーションには次のような利点があります。
- 耐障害性とフェイルオーバー
ディレクトリツリーを複数のサーバーにレプリケーションすると、ハードウェア、ソフトウェア、またはネットワークに障害が発生し、ディレクトリクライアントアプリケーションが特定の Directory Server にアクセスできない場合でも、ディレクトリを利用可能にできます。読み取りや書き込み操作を実行するために、クライアントを別のディレクトリに転送することができます。書き込みフェイルオーバーに対応するには、レプリケーション環境にデータのマスターコピーが複数必要であることに注意してください。
- ロードバランス
ディレクトリツリーを複数のサーバーにレプリケートすることで、各マシン上のアクセス負荷を軽減し、サーバーの応答時間を改善できます。
- パフォーマンスの向上と応答時間の短縮
ディレクトリのエントリをユーザーに近い場所にレプリケートすることで、ディレクトリの応答時間を大幅に改善できます。
- ローカルでのデータの管理
レプリケーションを行うと、ローカルにデータを所有して管理でき、同時に全社レベルでそのデータをほかの Directory Server と共有できます。
ディレクトリ情報のレプリケーション戦略を決定する前に、レプリケーションの動作を理解しておく必要があります。以下に、次の事項について説明します。
レプリケーションの概念
レプリケーションの配備を計画するときは、常に次の基本事項を決定することから始めます。
- レプリケートする情報
- 情報のマスターコピーを保持するサーバー (複数も可)
- 情報の読み取り専用コピーを保持するサーバー (複数も可)
- コンシューマレプリカを保持するマシンがクライアントアプリケーションから変更要求を受け取ったときに、その要求を転送する転送先サーバー
これらの事項は、Directory Server がこれらの概念をどのように処理するかを理解していないと効率的に決定できません。たとえば、レプリケーションする情報を決める場合は、Directory Server が処理できる最小のレプリケーション単位を知っておく必要があります。
レプリケーションのプロセスと、Directory Server の配備で利用できる可能性について理解を深めるために、次に Directory Server で使用されるレプリケーションの概念について説明します。ここでは、全体的な決定事項について検討するための安定した枠組みを示します。
レプリカ
レプリケーションに関与するデータベースを、レプリカと呼びます。レプリカには、いくつかの種類があります。
- マスターレプリカ (読み書き可能レプリカ) : ディレクトリデータのマスターコピーを格納する読み書き可能データベース。マスターレプリカは、ディレクトリクライアントからの更新要求を処理できる
- コンシューマレプリカ : マスターレプリカに保持される情報のコピーを格納する読み取り専用データベース。コンシューマレプリカは、ディレクトリクライアントからの検索要求を処理できるが、更新要求はマスターレプリカを照会する
- ハブレプリカ : コンシューマレプリカと同じく、読み取り専用データベース。ただしハブレプリカは、1 つまたは複数のコンシューマのサプライヤとして動作する Directory Server に格納される
Directory Server は、複数のレプリカを管理するように設定できます。各レプリカには、レプリケーションにおいて異なる役割を持たせることができます。たとえば、マスターレプリカに dc=engineering,dc=example,dc=com サフィックス、コンシューマレプリカに dc=sales,dc=example,dc=com サフィックスを格納する 1 つの Directory Server を持つことができます。
レプリケーションの単位
Directory Server では、レプリケーションの最小単位はデータベースです。レプリケーションメカニズムでは、サフィックスとデータベースが 1 対 1 で対応している必要があります。つまり、カスタム分散ロジックを使用している 2 つ以上のデータベースにまたがって分散されているサフィックス (またはネームスペース) はレプリケーションできません。レプリケーション単位の概念は、コンシューマとサプライヤの両方に適用されます。つまり、1 つのデータベースだけを保持するコンシューマに 2 つのデータベースをレプリケートすることはできません。また、その反対も同様です。
レプリカ ID
マスターレプリカは一意のレプリカ識別子 (ID) を必要とし、すべてのコンシューマは同じレプリカ ID を持ちます。マスターのレプリカ ID は 1 〜 65534 の間の任意の 16 ビット整数で、すべてのコンシューマレプリカのレプリカ ID は 65535 です。レプリカ ID は、どのレプリカで変更が発生したかを識別し、これによってレプリケーションが正しく行われます。このため、レプリカ ID はレプリケーションメカニズムで中心的な役割を果たします。
注 サーバーが複数のレプリカをホスティングする場合、1 つのレプリケートされた命名コンテキストまたはサフィックスを持つ複数のマスターの間でレプリカ ID が一意であれば、それぞれのレプリカが同じレプリカ ID を持つことができます。
サプライヤとコンシューマ
別のサーバーにレプリケートされるサーバーをサプライヤと呼びます。別のサーバーによって更新されるサーバーをコンシューマと呼びます。
サーバーは、場合によってはサプライヤとコンシューマの両方の機能を持ちます。これは、次の場合に当てはまります。
- Directory Server がマスターレプリカとコンシューマレプリカの組み合わせを管理する場合
- Directory Server がハブレプリカを含む場合。つまり、サプライヤから更新を受け取り、変更内容をコンシューマにレプリケートする場合。詳細については、「カスケード型レプリケーション」を参照
- マルチマスターレプリケーションで、一方の Directory Server が他方の Directory Server のサプライヤおよびコンシューマとして動作する 2 つの Directory Server がマスターレプリカを保持する場合。詳細については、「マルチマスターレプリケーション」を参照
サーバーがコンシューマとしてだけ機能する場合、このサーバーにはコンシューマレプリカだけが保持されます。このようなサーバーを専用コンシューマと呼びます。
Directory Server では、レプリケーションは常にサプライヤサーバーから開始されます。コンシューマサーバーから開始されることはありません。サプライヤがコンシューマにデータをプッシュすることから、これをサプライヤ主導レプリケーションと呼びます。
Directory Server の初期のバージョンでは、サプライヤからのデータの送信に関して、コンシューマ側に設定するコンシューマ主導のレプリケーションも許されていました。Directory Server 5.0 移行のリリースでは、コンシューマが更新の送信をサプライヤに要求する手順に切り替えられました。
マスターレプリカでは、サーバーは次のように機能する必要があります。
- ディレクトリクライアントからの更新要求 (追加、削除、変更) に応答する
- レプリカの履歴情報と更新履歴ログを保持する
- コンシューマへのレプリケーションを開始する
マスターレプリカを保持するサーバーは、管理するマスターレプリカに対して行われる変更を常に記録する必要があります。これにより、すべての変更がコンシューマにレプリケーションされます。
ハブレプリカでは、サーバーは次のように機能する必要があります。
- 読み取り要求に応答する
- マスターレプリカを保持するサーバーに更新要求を送信する
- レプリカの履歴情報を維持する
- コンシューマへのレプリケーションを開始する
カスケード型レプリケーションについては、「カスケード型レプリケーション」を参照してください。
コンシューマレプリカでは、サーバーは次のように機能する必要があります。
- 読み取り要求に応答する
- レプリカの履歴情報を維持する
- マスターレプリカを保持するサーバーに更新要求を送信する
コンシューマは、エントリの追加、削除、変更の要求を受け取ると、その要求はマスターレプリカを保持するサーバーにクライアント経由で送信されます。つまり、レプリケーションの流れの中で、サーバーがサプライヤとして機能します。サプライヤは要求を実行し、変更をレプリケートします。
セキュリティまたはパフォーマンス上の理由から、リフェラルではなく、エラーを返すようにコンシューマレプリカまたはハブレプリカを設定することもできます。詳細は、注を参照してください。
レプリカのオンライン昇格とオンライン降格
Sun ONE Directory Server 5.2 には、レプリカのオンライン昇格とオンライン降格の機能が用意されています。オンライン昇格またはオンライン降格が完了すると、サーバーは更新の受け入れを直ちに開始または停止します。コンシューマレプリカをマスターレプリカに昇格させるには、まず、ハブレプリカに昇格させ、それからマスターレプリカに昇格させます。オンライン降格にもこれと同じ段階的なアプローチが適用されます。
オンライン昇格および降格によって柔軟性が向上するだけでなく、フェイルオーバー機能も向上します。ロードバランスとフェイルオーバーのために 2 つのハブが設定された双方向のマルチマスター環境を例に考えてみます。いずれかのマスターがオフラインになった場合は、いずれかのハブを昇格させるだけで読み取り、書き込みの最適な可用性を維持できます。マスターレプリカがオンラインに復帰したときは、ハブレプリカに降格させるだけで元の状態を回復できます。
注 ハブをコンシューマに降格する前に、そのハブが他のサーバーと同期していることを確認する必要があります。コンシューマレプリカは更新履歴ログを持たないため、このレプリカは変更を伝達できなくなります。ハブの同期を確認するには、レプリケーション監視ツール insync を使用します。このツールについては、「レプリケーションの監視」を参照してください。
更新履歴ログ
サプライヤとして機能するすべてのサーバー (マスターレプリカ、ハブレプリカ) は、更新履歴ログを維持します。更新履歴ログは、マスターレプリカに対して行われた変更を記述した記録です。サプライヤとして機能するサーバーは、この変更をコンシューマ上で再現します。
エントリの変更、名称変更、追加、または削除が行われると、実行された LDAP 操作を記述する変更レコードが更新履歴ログに記録されます。
Directory Server の従来のバージョンでは、LDAP から更新履歴ログにアクセスできました。しかし現在では、更新履歴ログはサーバーが内部的に使用するだけで、専用データベースに格納され、LDAP 経由でアクセスできなくなりました。使用しているアプリケーションで更新履歴ログを読み取る必要がある場合は、レトロログのプラグインを使用して、下位互換性を保つことができます。レトロログのプラグインについては、『Sun ONE Directory Server 管理ガイド』の「Using the Retro Change Log Plug-In」を参照してください。
注 更新履歴ログからエントリが削除されると、その更新はレプリケートされなくなります。更新履歴ログのサイズは慎重に設定してください。必要となるディスク容量は変更の種類によって異なるため、予定されているトラフィックの種類を検討し、更新履歴ログ用に十分なディスク容量を確保する必要があります。
レプリケーションの識別情報
2 つのサーバーの間でレプリケーションが行われると、サプライヤとして機能するサーバーがコンシューマとして機能するサーバーにバインドしてレプリケーション更新を送信するときに、コンシューマがサプライヤを認証します。この認証処理を実行するには、サプライヤがコンシューマにバインドする際に使用するエントリがコンシューマサーバーに格納されている必要があります。このエントリをレプリケーションマネージャエントリと呼びます。レプリケーション時に Directory Server コンソールが DN またはバインド DN を参照する場合、レプリケーションマネージャエントリのバインド DN が参照されます。
レプリケーションマネージャエントリあるいはその役割を果たすために作成したエントリは、次のような条件を満たしている必要があります。
- コンシューマとして機能するレプリカが少なくとも 1 つすべてのサーバーに存在する (マルチマスター環境における専用コンシューマ、ハブ、マスターもこれに該当する)
- セキュリティ上の理由および初期化の問題から、このエントリをレプリケートされたデータの一部にしないこと
注 このエントリは、コンシューマサーバーに定義されたすべてのアクセス制御規則を迂回する、特別なユーザープロファイルとなります。ただし、この特別ユーザープロファイルはレプリケーションだけで有効です。
2 つのサーバー間でレプリケーションを設定する場合は、両方のサーバーでレプリケーションマネージャエントリを識別する必要があります。
- コンシューマとして機能するサーバーでは、レプリケーショントポロジにコンシューマレプリカ、ハブレプリカ、またはマスターレプリカ (マルチマスターレプリケーションの場合) を設定するときに、レプリケーション更新の実行が承認されたエントリとしてこれを指定する必要があります。
- サプライヤとして機能するサーバー、つまりすべてのマスターレプリカとハブレプリカでは、レプリケーションアグリーメントを設定するときに、このエントリのバインド DN をレプリケーションアグリーメントに指定する必要があります。
注 Directory Server コンソールでは、レプリケーションマネージャエントリはデフォルトで作成されます。ただし必要に応じて、Directory Server コンソールを使用してこのエントリを独自に作成することもできます。
SSL とレプリケーションを使用している場合、認証を行うには次の 2 つの方法があります。
レプリケーションアグリーメント
Directory Server では、レプリケーションアグリーメントを使用してレプリケーションを定義します。レプリケーションアグリーメントは、1 つのサプライヤと 1 つのコンシューマの間のレプリケーションを定義します。アグリーメントは、サプライヤ上に設定されます。レプリケーションが機能するには、レプリケーションアグリーメントが有効化されている必要があります。レプリケーションアグリーメントには、次の内容が定義されます。
- レプリケートするデータベース
- データがレプリケートされるコンシューマサーバー
- 部分レプリケーションを設定する場合は、レプリケート対象からデータを外す、または含めるための属性セットへのポインタ
- レプリケーションを実行できる時間帯
- サプライヤがコンシューマへのバインドに使用するバインド DN と証明情報 (レプリケーションマネージャエントリ、詳細は、「レプリケーションの識別情報」を参照)
- 接続をセキュリティ保護する方法 (SSL、クライアント認証)
- 1 つの要求にグループ化できる変更の数と、コンシューマからの受信通知が必要となるまでに送信できる要求の数を設定するグループサイズとウィンドウサイズ
- レプリケーションアグリーメントの状態情報
- Solaris および Linux システムでは、レプリケーション時に使用する圧縮のレベル情報
注 Sun ONE Directory Server 5.2 では、既存のレプリケーションアグリーメントを無効にするか、有効にするかを選択できます。これは、特定のレプリケーションアグリーメントの使用が一時的に必要ないが、将来の必要性を考えて保持しておきたい場合に便利です。
コンシューマの初期化 (完全更新)
コンシューマの初期化は、サプライヤとして機能するサーバーからコンシューマとして機能するサーバーにすべてのデータを物理的にコピーする完全更新プロセスです。レプリケーションアグリーメントを作成したら、アグリーメントに指定されているコンシューマを初期化する必要があります。サプライヤが更新操作をコンシューマ上で再現 (レプリケート) できるのは、コンシューマの初期化が完了した後だけです。通常の動作環境では、それ以後のコンシューマの初期化は必要ありません。ただし、何らかの理由でサプライヤ上のデータをバックアップから復元した場合は、そのサプライヤに合わせて一部のコンシューマを初期化し直さなければならない可能性があります。たとえば、復元されたサプライヤが、トポロジ内でそのコンシューマの唯一のサプライヤである場合、このコンシューマを初期化し直す必要があります。コンシューマは、オンラインとオフライン (手動) の両方で初期化できます。コンシューマの初期化手順については、『Sun ONE Directory Server 管理ガイド』の「Initializing Replicas」を参照してください。Directory Server 5.2 には、高度なバイナリコピー機能も用意されています。この機能を利用することで、1 つのサーバーのバイナリバックアップファイルからマスターレプリカまたはコンシューマレプリカをクローン化し、同じディレクトリ内用を別のサーバー上で復元することができます。特定の制限が適用されるため、この機能が実用的で時間の節約となるのは、大規模なデータベースファイルのレプリカを対象とする場合だけです。バイナリバックアップ手順とこの機能の詳しい制限については、「バイナリバックアップ (db2bak)」を参照してください。
マルチマスターレプリケーショントポロジでは、バックアップファイルまたは ldif ファイルからオンラインまたはオフラインで再初期化された読み書き可能レプリカは、デフォルトではクライアントからの更新要求を拒否します。これは、Directory Server の従来のバージョンとは対照的です。レプリカはデフォルトで永続的に読み取り専用モードになり、更新操作の要求についてはトポロジ内の他のサプライヤを参照します。この場合、管理者は次の 2 つの方法で更新の受け入れをレプリカに再設定することができます。
- Directory Server コンソールを使用するか、ds5BeginReplicaAcceptUpdates 属性に start を設定することで、読み書き可能モードを手動で有効化します。これにより、管理者はレプリケーション監視ツール insync を使用して、レプリカがトポロジ内のその他のサプライヤに完全に合流したことを確認できます。更新操作の受け入れを開始する前に管理者がレプリカの同期を確認できるので、この手順が推奨されます。
- レプリカ固有の ds5referralDelayAfterInit 属性に指定した遅延時間後に読み書き可能モードへの自動変更が行われるようにレプリカを設定します。この手順では、レプリカが完全に他のマスターレプリカと同期する前に更新操作が受け入れられ、予期せぬエラーが発生する危険があります。
これらの手順については、『Sun ONE Directory Server 管理ガイド』の「Initializing Replicas」を参照してください。レプリケーション設定属性については、『Sun ONE Directory Server Reference Manual』の「Core Server Configuration Attributes」に記載されているレプリケーション属性リストを参照してください。
差分更新
差分更新は、コンシューマの初期化または完全更新後にサプライヤからコンシューマに更新をレプリケートするプロセスです。Directory Server の従来のリリースとは異なり、Sun ONE Directory Server 5.2 では、それぞれの更新が異なるレプリカ ID に由来する場合は、複数のサプライヤが同時にコンシューマを差分更新することができます。複数のサプライヤ (ただし異なるレプリカ ID を持つ) が同時に差分更新できるようになったことで、差分更新プロセスのパフォーマンスが向上します。
データの整合性
整合性とは、レプリケートされたデータベースの内容が、任意の時点でどの程度一致しているかを示します。2 つのサーバー間でレプリケーションを設定する場合、設定の一部として更新のスケジュールが含まれます。Directory Server では、いつコンシューマを更新すべきかを判断し、レプリケーションを開始するのは、常にサプライヤとして機能するサーバーです。レプリケーションを行えるのは、コンシューマの初期化が完了してからだけです。
Directory Server には、レプリカの同期を常に維持するオプションと、特定の時間または曜日に更新をスケジュールするオプションが用意されています。レプリカの同期を常に維持する利点は、データの整合性がより確実に保証されるという点です。ただしその場合は、頻繁な更新操作によってネットワークトラフィックが増大します。このソリューションは、次の場合に最適です。
- サーバー間で信頼性が高く高速な接続を利用できる場合
- ディレクトリのサービスを受けるクライアント要求が主に検索、読み取り、および比較の操作であり、追加と変更の操作は比較的少ない場合
データの整合性が低くてもかまわない場合は、必要に応じて更新の頻度を選択して、ネットワークトラフィックへの影響を軽減することができます。このソリューションは、次の場合に最適です。
- ネットワーク接続の信頼性が低いか、あるいは断続的なネットワーク接続を使用している場合 (ダイヤルアップ接続を使用してレプリカの同期をとっている場合など)
- ディレクトリがサービスするクライアント要求が主に追加と変更の操作である場合
- 通信コストを削減する必要がある場合
マルチマスターレプリケーションの場合は、一般に、各マスターに格納されているデータ間に違いがある可能性があるため、各マスター上のレプリカは緩やかな整合性を保っている状態といえます。これは、常にレプリカの同期を維持するように選択している場合にも当てはまります。理由は次のとおりです。
- マスター間のレプリケーションの更新操作の伝達に遅延があるため
- 追加または変更の操作を実行したマスターは、2 番目のマスターがその更新操作を検証するのを待たずに「操作は正常に完了しました」というメッセージをクライアントに返すため
一般的なレプリケーションの例
レプリケーション要件に適したレプリケーション戦略を構築するために、レプリケーションの更新情報をサーバー間でやり取りする方法と、更新情報を伝達するときのサーバー間の相互動作の方法を決める必要があります。次の 5 つの基本的な例について説明します。
次に、上記の例について説明し、環境に最も適した方法を決定するための指針を示します。これらの基本的な例を組み合わせて、要件に最も合ったレプリケーショントポロジを構築することもできます。
注 どのレプリケーションモデルを選択した場合でも、スキーマのレプリケーションを考慮するようにしてください。詳細は、「スキーマのレプリケーション」を参照してください。
シングルマスターレプリケーション
レプリケーションの最も基本的な設定では、サプライヤとして機能するサーバーが 1 つまたは複数のコンシューマサーバーにマスターレプリカを直接コピーします。この設定では、マスターレプリカに対するすべてのディレクトリ変更はサプライヤに格納され、コンシューマには読み取り専用のデータコピーが維持されます。
サプライヤは、マスターレプリカに対するすべての更新を記録した更新履歴ログを管理します。サプライヤには、レプリケーションアグリーメントも格納されます。
サプライヤがレプリケーションの更新を送信するためにコンシューマにバインドしたときに、コンシューマがサプライヤを認証できるように、コンシューマにはレプリケーションマネージャエントリに対応したエントリが格納されます。
サプライヤサーバーはすべての変更をコンシューマレプリカに伝達する必要があります。図 6-1 に、この設定の簡単な例を示しています。
図 6-1 シングルマスターレプリケーション
図 6-1 の例では、ou=people,dc=example,dc=com サフィックスが、クライアントから多数の検索要求と更新要求を受け取ります。したがって、負荷を分散するために、サーバー A 上にマスターのあるこのサフィックスは、サーバー B 上にあるコンシューマレプリカにレプリケートされます。
サーバー B は、クライアントからの検索要求を処理できますが、ディレクトリエントリの変更要求は処理できません。サーバー B は、クライアントにサーバー A に対するリフェラルを返すことによって、クライアントから受け取った変更要求を処理します。
注 レプリケーションでは、コンシューマとして機能するサーバーにサプライヤとして機能するサーバーのリフェラル情報が格納されますが、変更要求はクライアントからサプライヤに転送されません。クライアントは、コンシューマによって返されたリフェラルを実行する必要があります。
図 6-1 では、1 つのサーバーだけがコンシューマとして機能していますが、サプライヤは複数のコンシューマにレプリケートすることができます。1 つのサプライヤが管理できるコンシューマの総数は、ネットワークの速度と 1 日当たりのエントリの変更総数によって異なりますが、1 つのサプライヤサーバーで複数のコンシューマサーバーを管理できると想定して特に問題ありません。
マルチマスターレプリケーション
マルチマスターレプリケーション環境では、同じ情報を持つマスターレプリカが複数のサーバー上に存在します。ここでは、マルチマスターレプリケーションについて次の内容を説明します。
- マルチマスターレプリケーションの基本概念
- マルチマスターレプリケーションの機能
- 完全に接続された 4 方向のマルチマスタートポロジ
- 広域ネットワーク (WAN) を介したマルチマスターレプリケーション
マルチマスターレプリケーションの基本概念
同じ情報を持つマスターレプリカが複数のサーバー上に存在するマルチマスター構成では、複数の異なる場所でデータを同時に更新することができます。つまり、レプリケーショントポロジに関与するマスターレプリカの更新履歴ログを各サーバーが管理しています。各サーバー上で行われた変更は、そのトポロジの別のサーバーにレプリケートされます。つまり、各サーバーはサプライヤとコンシューマの両方の役割を果たします。マルチマスター設定には、次の利点があります。
- 1 つのサプライヤにアクセスできなくなった場合でも、自動的に書き込み処理のフェイルオーバーが実行される
- 地域分散型環境のローカルサプライヤで更新処理を実行できる
両方のサーバーでほとんど同時に同じデータが変更された場合は、頂点手順が適用され、最も新しい変更が優先されます。ただし、競合する一部の変更が LDAP モデルを破損した場合は、そのエントリは競合エントリとしてマークされます。これらの「競合エントリ」を解決するには、管理者がこれらのエントリの処理を決定し、手動で更新する必要があります。
注 マルチマスターレプリケーション環境で属性の一意性が重要となる配備では、属性値一意性検査プラグインを使用して、名前の競合を減らすことを強くお勧めします。属性値一意性検査プラグインについては、「一般的なレプリケーションの例」を参照してください。
独立した 2 つのサーバーが同じデータのマスターコピーを保持することはできますが、1 つのレプリケーションアグリーメントにおいては、1 つのサプライヤと 1 つのコンシューマだけしか存在できません。このため、同じデータの管理責任を共有する 2 つのサプライヤ間にマルチマスター環境を構築するには、2 つのレプリケーションアグリーメントを作成する必要があります。図 6-1 は、この設定を示しています。
図 6-2 マルチマスターレプリケーションの設定 (2 つのマスター)
サプライヤ A とサプライヤ B は、それぞれが同じデータを持つマスターレプリカを保持し、マルチマスター設定のレプリケーションの流れを制御する 2 つのレプリケーションアグリーメントが存在します。
Directory Server 5.2 は、マルチマスターレプリケーショントポロジで最大 4 つのマスターをサポートします。コンシューマとハブの数は、理論的には無制限です。ただし、1 つのサプライヤがレプリケートできるコンシューマの数は、サプライヤサーバーの性能によって異なります。
マルチマスターレプリケーションの機能
レプリケーション要件やパフォーマンス要件に配備を簡単に適応させられるように、Sun ONE Directory Server 5.2 はより効率的で柔軟なプロトコルを提供します。Sun ONE Directory Server 5.2 では、次の処理が可能です。
- レプリカ ID に基づいて更新をレプリケートします。レプリカ ID ベースの更新により、複数のサプライヤがコンシューマを同時に更新できるようになるため、パフォーマンスが向上します (それぞれの更新が異なるレプリカ ID に由来する必要があります)。
- 指定したコンシューマのレプリケーションアグリーメントを有効化または無効化することができます。これにより、配備でのレプリケーション設定の柔軟性が向上します。トポロジを後日変更することを前提に特定のトポロジを設定し、後から簡単に変更することができます。
完全に接続された 4 方向のマルチマスタートポロジ
図 6-3 は、完全に接続された 4 方向のマスタートポロジを示しています。4 方向のマスターフェイルオーバー設定により、完全に接続されたこのトポロジは高い可用性を提供し、データの整合性を保証します。これは、読み書き対応フェイルオーバー機能の面では最も安全ですが、パフォーマンスの面ではこのフェイルオーバー機能によってオーバーヘッドが生じることに注意が必要です。完全に接続されたマルチマスター構成の配備が必要かどうかは、高可用性の要件によって異なります。高可用性が比較的重要でない場合、またはパフォーマンス上の理由からレプリケーショントラフィックを削減する場合は、読み書き可能フェイルオーバーの面でより「軽量」の配備が適しています。
図 6-3 完全に接続された 4 方向のマルチマスターレプリケーション構成
図 6-3 では、4 つのマスターで ou=people,dc=example,dc=com サフィックスが維持され、変更要求に常に対応できるようにしています。各マスターは、自身の更新履歴ログを管理します。いずれかのマスターがクライアントからの変更要求を処理すると、そのマスターは操作を更新履歴ログに記録します。次に、その他のサーバーにレプリケーション更新を送信し、そこからその他のコンシューマに伝達されます。このためマスターは、マスター間のレプリケーションアグリーメントだけでなく、コンシューマとのレプリケーションアグリーメントも保持する必要があります。また各マスターには、レプリケーション更新を送信するために他のマスターにバインドできるように、他のマスターの認証に使用するレプリケーションマネージャエントリも格納されます。
図 6-3 では、各コンシューマはレプリケーションマネージャエントリに対応する 2 つのエントリを保持しています。これにより、コンシューマはレプリケーション要求を送信する際にマスターにバインドするときに、マスターを認証できます。各コンシューマが 1 つのレプリケーションマネージャエントリだけを保持し、すべてのマスターが同じレプリケーションエントリを認証に使用するように設定することもできます。
デフォルトでは、コンシューマはトポロジ内のすべてのマスターに対するリフェラルを保持します。クライアントから変更要求を受け取ると、コンシューマはマスターへのリフェラルをクライアントに返します。
注 レプリケーション環境では、コンシューマはクライアントからの変更要求をサプライヤとして機能するサーバーに転送しません。変更要求を受け取ったコンシューマは、クライアントからの変更要求を正しく実行できる可能性のあるマスターの URL リストを返します。
Sun ONE Directory Server 5.2 では、サーバーによって自動的に設定されるリフェラルを独自のリフェラルに書き換えることで、これらのリフェラルを制御できます。
リフェラルを制御できることで、配備のセキュリティとパフォーマンスを次のように最適化できます。
- リフェラルがセキュリティ保護されたポートだけをポイントするようにする
- ロードバランスのために Sun ONE Directory Proxy Server をポイントできる
- WAN によって隔てられた複数サーバーへの配備に限定し、ローカルサーバーにリダイレクトすることができる
- 4 方向のマルチマスタートポロジのサブセットだけにリフェラルを限定することができる
リフェラルの設定については、『Sun ONE Directory Server 管理ガイド』の「Setting Referrals」を参照してください。
レプリケーションの要素を理解いただくために、完全に接続された 4 方向のマルチマスターレプリケーションの設定と配備について説明します。図 6-4 は、マスター A で設定する必要があるレプリケーションアグリーメント、変更履歴ログ、レプリケーションマネージャを示しています。図 6-5 は、コンシューマ E で設定する必要がある同じ要素を示しています。
図 6-4 完全に接続された 4 方向のマルチマスターレプリケーションのマスター A のレプリケーション設定
図 6-4 に示されるように、マスター A は、マスターレプリカ、更新履歴ログ、マスター B、C、D 用のレプリケーションマネージャエントリまたはバインド DN (4 つすべてのマスターでは、必ずしも同じレプリケーションマネージャエントリを使用しない場合) を必要とします。更新履歴ログとレプリケーションマネージャエントリのほかに、マスター A は、3 つの他のマスター B、C、D、およびコンシューマ E、F とのレプリケーションアグリーメントも必要とします。
図 6-5 完全に接続された 4 方向のマルチマスターレプリケーションのコンシューマサーバー E のレプリケーション設定
図 6-5 は、コンシューマ E のレプリケーション設定の詳細を示しています。コンシューマ E は、コンシューマレプリカ、およびレプリケーション更新の送信時にマスター A、B とのバインドで認証に使用されるレプリケーションマネージャエントリを必要とします。
広域ネットワーク (WAN) を介したマルチマスターレプリケーション
広域ネットワーク (WAN) を介したマルチマスターレプリケーション (MMR) は、Sun ONE Directory Server 5.2 の新機能です。この機能を利用することで、地理的に離れた国際的な配備や複数のデータセンター配備にまたがって MMR を構成できます。従来の Directory Server で、MMR を完全にサポートするためには、高速で待ち時間の少ない、100M バイト / 秒以上の転送スピードのネットワークにマスター Directory Server を接続することが必要でした。この制限のため、WAN を介した MMR は、実現できませんでした。しかし、この制限がなくなります。現在、Sun ONE Directory Server では、WAN を介した MMR をサポートしています。地理的に離れていることは、マルチマスターレプリケーションの障壁とはならなくなりました。この新機能の柔軟性は、大規模な配備に大きく貢献します。
注 プロトコルが異なるため、WAN を介したマルチマスターレプリケーションは、Directory Server の従来のリリースとの互換性はありません。このため、WAN を介したマルチマスターアプリケーションの設定では、WAN によって分散されるすべての Directory Server インスタンスは、5.2 インスタンスである必要があります。
WAN を介した MMR (MMR over WAN) の配備を実現するために、Sun ONE Directory Server 5.2 の新しいレプリケーションプロトコルは、非同期を完全にサポートし、ウィンドウとグループ化のメカニズムを提供します。次に、これらのメカニズムについて詳しく説明します。
注 MMR over WAN はプロトコルの改善によって実現しましたが、この改善は、ローカルエリアネットワーク (LAN) を介した配備にも同様に有効です。
グループ化とウィンドウのメカニズム
レプリケーションの流れを最適化するために、Directory Server では変更を個別に送信する代わりにグループ化して送信することができます。また、サプライヤが処理継続のためのコンシューマからの受信通知を待たずにコンシューマに送信できる要求の数を指定することもできます。1 つの更新要求にグループ化できる変更の数を指定するときは ds5ReplicaTransportGroupSize 属性を使用し、コンシューマからの受信通知が必要になる前に送信できる sendUpdate 要求の数を指定するときは ds5ReplicaTransportWindowSize 属性を使用します。デフォルトのグループサイズは 1 で、デフォルトのウィンドウサイズは 10 です。つまり、別の値を指定しない場合、デフォルトのレプリケーションは要求のグループ化を行いませんが、コンシューマからの受信通知が必要になるまでに 10 の sendUpdate 要求を送信できます。
カスケード型レプリケーション
カスケード型レプリケーションでは、ハブとして機能するサーバーがサプライヤとして機能するサーバーから更新を受け取り、その更新をコンシューマ上で再現します。ハブはコンシューマとサプライヤの、両者の機能を合わせ持っています。つまり、通常のコンシューマと同様にデータの読み取り専用コピーを保持すると同時に、通常のサプライヤと同様に更新履歴ログも保持しています。
ハブは、元のマスターから受け取ったマスターデータのコピーを渡し、ディレクトリクライアントからの更新要求についてマスターを参照します。
図 6-6 は、このカスケード型レプリケーションの例を示しています。
図 6-6 カスケード型レプリケーションの例
カスケード型レプリケーションは、次の場合に便利です。
- 非常に大きなトラフィック負荷を均等にする必要がある場合 : たとえば、マスターはすべての更新トラフィックを処理する必要があるため、コンシューマへのすべてのレプリケーショントラフィックをサポートするには、非常に大きな負荷がかかります。多数のコンシューマに対するレプリケーション更新を実行できるハブにレプリケーショントラフィックを任せることで、負荷を軽減できます。
- 地域分散型環境でローカルハブサプライヤを使用することで、接続費用を削減したい場合
- ディレクトリサービスのパフォーマンスを向上させる場合 : 読み取り操作を行うすべてのクライアントアプリケーションをコンシューマへ、更新操作を行うすべてのクライアントアプリケーションをマスターへ導くことができる場合は、ハブのすべてのインデックス (システムインデックスを除く) を削除できます。これにより、マスターとして機能するサーバーとハブとして機能するサーバーの間のレプリケーション速度が飛躍的に向上します。
同じ例を別の視点から図にすると、図 6-7 のようになります。この図は、レプリケーションアグリーメント、履歴変更ログ、デフォルトリテラルの面からサーバーがどのように設定されるかを示しています。
図 6-7 カスケード型レプリケーションのサーバー設定
図 6-7 の例では、マスタとして機能するサーバーとハブとして機能するサーバーの間でハブを共有することで、レプリケーション更新の負荷をバランスしています。
マスターとハブは、どちらも更新履歴ログを維持します。ただし、クライアントからの変更要求を直接処理できるのは、マスターだけです。ハブにはマスター A のレプリケーションマネージャエントリが含まれるので、マスター A はハブにバインドし、レプリケーション更新を送信できます。コンシューマ C、D にはハブ B のレプリケーションマネージャエントリが含まれ、コンシューマへの更新の送信時の認証にはこれらのエントリが使用されます。
コンシューマとハブは、クライアントからの検索要求を処理できますが、変更要求の場合は、マスターへのリフェラルをクライアントに送信します。図 6-7 は、コンシューマ C、D がマスター A へのリフェラルを保持していることを示しています。これは、ハブとコンシューマの間のレプリケーションアグリーメントを作成するときに自動的に作成されるリフェラルです。ただしすでに指摘したように、パフォーマンスまたはセキュリティ上の理由で必要となる場合は、これらのリフェラルを書き換えることもできます。詳細は、注を参照してください。
注 マルチマスターレプリケーションとカスケード型レプリケーションを組み合わせることができます。たとえば、図 6-8 のマルチマスターの例では、サーバー C とサーバー D を、ハブとして設定することにより、これらのハブから任意の数のコンシューマにレプリケーションを実行できます。
混合環境
上で説明した例を自由に組み合わせて、要件に最も合った環境を構築できます。たとえば、マルチマスター設定とカスケード型設定を組み合わせて、図 6-8 に示すようなトポロジを構築できます。
図 6-8 マルチマスターレプリケーションとカスケード型レプリケーションの組み合わせ
図 6-8 の例では、2 つのマスターと 2 つのハブが 4 つのコンシューマにデータをレプリケートしています。マスターとハブの間でハブを共有することで、レプリケーション更新の負荷をバランスします。このような設定は、管理するレプリケーション更新の負荷が非常に大きい場合に効果的です。
図 6-7 の例では、ハブ、マスター A、B が更新履歴ログを維持します。ただし、クライアントからの変更要求を直接処理できるのは、マスターだけです。クライアントからの変更要求をハブまたはコンシューマが受信すると、要求を処理するためにマスターへのリフェラルがクライアントに送信されます。図 6-8 にはリフェラルは示されていませんが、4 つのコンシューマと 2 つのマスターの間、および各ハブとマスターの間にリフェラルが存在します。これらのリフェラルは、トポロジの定義時に自動的に作成されます。
図 6-8 の例に示される点線は、無効化されたレプリケーションアグリーメントを示しています。これらのレプリケーションアグリーメントを有効化しない場合、いずれかのハブがオフラインになった場合にこのトポロジにはシングルポイント障害が発生します。レプリケーションアグリーメントを有効化して完全な読み書き対応フェイルオーバーを提供するかどうかは、そのトポロジの高可用性要件によって異なります。ただし、アグリーメントを有効化しない場合に、シングルポイント障害の危険が生じる可能性があることには注意が必要です。
部分レプリケーション
Directory Server の前回のリリースでは、レプリケーションの最小単位はデータベースで、特定のデータベース内の情報のサブセットだけをレプリケートすることはできませんでした。レプリケーションの最小単位がデータベースであることに変わりはありませんが、Sun ONE Directory Server 5.2 では、部分レプリケーションという新機能を提供することで、レプリケーションの細分化要件に対応しています。ここで説明する内容は次のとおりです。
部分レプリケーションとは
部分レプリケーションでは、指定したデータベースのすべてのエントリの属性の中から、そのサブセットをサプライヤからコンシューマにレプリケートできます。部分レプリケーションが便利な機能であることを理解するために、2 つの簡単な例を紹介します。
- イントラネットサーバーとエクストラネットサーバーの間で同期が必要で、セキュリティ上の理由から一部のコンテンツをフィルタリングしなければならない場合に、部分レプリケーションがフィルタリング機能を提供します。
- レプリケーションによるリソースの消費を削減しなければならない場合、部分レプリケーションによってレプリケートする内容を選択できます。すべての場所で特定の属性を利用できるようにすることだけが必要な配備では、すべての属性をレプリケートする代わりに、部分レプリケーション機能を使用して必要な属性だけをレプリケートできます。たとえば、電子メールアドレスと電話番号の属性だけをレプリケートし、それ以外の属性をレプリケートしない場合、その他の属性が頻繁に変更されるようであれば、その結果として生じるトラフィックの負荷は非常に大きくなります。部分レプリケーションを使用することで、必要な属性をフィルタリングし、トラフィックを最小限に抑えることができます。このフィルタリング機能は、Directory Server が WAN によって分散しているレプリケーション環境で特に効果的です。
警告
Sun ONE Directory Server 5.2 の部分レプリケーション機能は、Directory Server の従来のバージョンとの逆互換性を持ちません。部分レプリケーションを使用する場合は、Directory Server のすべてのインスタンスが 5.2 インスタンスである必要があります。
部分レプリケーションの設定
部分レプリケーションを設定するには、レプリケートの対象から除外する、または対象に含める属性を選択します。これは、コンソールから簡単に設定できます。ただし、部分レプリケーションの設定を後から変更するには、変更を加える前に、アプリケーションアグリーメントを無効化する必要があります。変更が完了したら、レプリケーションアグリーメントを有効化し、新しい設定が適用されるようにコンシューマを初期化します。
警告
部分レプリケーションを設定するときは、次の 2 点に注意してください。
一般には、スキーマ違反を回避するために、スキーマに定義されている各エントリのすべての必須属性をレプリケートします。ただし、部分レプリケーション機能を使用して一部の必須属性をフィルタリングする場合は、スキーマ検査を無効にする必要があります。必須属性をフィルタリングすると ldif ファイルをロードできなくなるため、部分レプリケーションでスキーマ検査を有効にした場合、ldif ファイルからオフラインで初期化できなくなる可能性があります。スキーマ検査を無効にすると、パフォーマンスを向上できることがあります。また、部分コンシューマレプリカでスキーマ検査を無効にした場合、その部分コンシューマレプリカが存在するサーバーインスタンス全体にスキーマが適用されなくなります。このため、同じサーバーインスタンスでは、別の情報ディレクトリツリーのサプライヤ (読み書き可能) レプリカを設定しないようにする必要があります。
部分レプリケーションの設定ではサプライヤがスキーマをプッシュするため、部分コンシューマレプリカのスキーマは、マスターレプリカのスキーマのコピーとなり、適用される部分レプリケーション設定に対応しないことにも注意してください。
レプリケーション戦略の定義
使用するレプリケーション手法は、提供するサービスによって異なります。
- 高可用性を最優先する場合は、1 つのサイトに複数のディレクトリサーバーを配備したデータセンターを構築する必要があります。読み取りフェイルオーバーを提供するにはシングルマスターレプリケーションを、書き込みフェイルオーバーを提供するにはマルチマスターレプリケーションを使用できます。高可用性を実現するためのレプリケーションの設定方法については、「高可用性を実現するためのレプリケーションの使用」を参照してください。
- 障害回復を最優先する場合は、2 つの地理的に異なる場所に独立したデータセンターを作成し、WAN を使用して分散させます。各データセンターは、フェイルオーバーのために 2 つのマスターをホスティングします。データセンターを二重化することで、1 つの場所で災害が発生した場合でも、もう一方は保護されます。地理的に離れた場所にまたがって書き込みフェイルオーバーの高い可用性を維持するには、WAN を介した 4 方向のマルチマスターレプリケーションを使用します。
- ローカルでのデータの可用性を最優先する場合は、レプリケーションを使用して、世界中の事務所に配置されているディレクトリサーバーにデータを物理的に分散する必要があります。本社などの単一の場所にすべての情報のマスターコピーを保管するか、あるいはそれぞれのローカルサイトが自身のサイトに関連する DIT 部分を管理するようにするかを選択できます。レプリケーションの設定タイプについては、「ローカルでのデータの可用性を高めるためのレプリケーションの使用」を参照してください。
- どの場合でも、ディレクトリサーバーがサービスする要求の負荷をバランスして、ネットワークへの過剰負荷を防ぐ必要があります。ディレクトリサーバーとネットワークへの負荷をバランスする戦略については、「ロードバランスのためのレプリケーションの使用」を参照してください。
レプリケーション手法を決定するには、ネットワーク、ユーザー、アプリケーション、および提供するディレクトリサービスがユーザーやアプリケーションによってどのように使われるかを調査することから始めます。この調査のガイドラインについては、「レプリケーション調査」を参照してください。
レプリケーション手法を決定したら、ディレクトリの配備を開始できます。ディレクトリサービスを段階的に配備していくことをお勧めします。ディレクトリを実際の環境に配備する段階に入ると、ディレクトリを全体的に配備した際の負荷をより正確に把握できるようになります。実際に運用されているディレクトリに基づいた負荷分析を行うことができない場合は、ディレクトリの使用状況をよく把握して、ディレクトリを修正するために準備してください。
次に、レプリケーション方法の決定に影響する要因について詳しく説明します。
- レプリケーションの逆互換性
- レプリケーション調査
- レプリケーションリソースの要件
- 高可用性を実現するためのレプリケーションの使用
- ローカルでのデータの可用性を高めるためのレプリケーションの使用
- ロードバランスのためのレプリケーションの使用
- 小規模サイト向けのレプリケーション方法の例
- 大規模サイト向けのレプリケーション方法の例
レプリケーションの逆互換性
最初に決定しなければならない事項の 1 つは、レプリケーションの設定に使用する Directory Server のバージョンです。レプリケーション設定が正しく機能させることができるように、表 6-1 の情報を参照してください。これは、Directory Server の異なるバージョンの間で考えられるマスターとコンシューマの組み合わせ、および関連する制限を示しています。
レプリケーション調査
レプリケーション手法を決定するときは、調査を通じて次のような情報を収集する必要があります。
- 異なる建物間やリモートサイト間を接続するネットワークの品質と使用可能な帯域幅
- ユーザーの物理的な位置、各サイトのユーザー数、ユーザーのアクティビティ
たとえば、人事データベースや財務情報を管理するサイトは、ディレクトリを単に電話帳として使用する技術スタッフを含むサイトより、ディレクトリに大きな負荷をかけます。
- ディレクトリにアクセスするアプリケーションの数と、書き込み操作に対する読み取り、検索、および比較の操作の比率
たとえば、メッセージングサーバーがディレクトリを使用する場合は、処理するメールメッセージごとにディレクトリが実行する操作数を調べる必要があります。ディレクトリを使用するその他の認証アプリケーションには、META Directory アプリケーションなどがあります。アプリケーションごとに、ディレクトリで実行される操作のタイプと頻度を調べる必要があります。
- ディレクトリに格納するエントリの数とサイズ
次に、これらの問題について検討し、レプリケーショントポロジを配備する上で考慮すべき重要な問題について説明します。
レプリケーションリソースの要件
レプリケーションを使用する場合は、リソースがさらに必要になります。レプリケーション手法を決定するときは、次のリソース要件を検討してください。
- ディスク使用量
サプライヤでは、各更新操作後に更新履歴ログが書き込まれます。レプリケートされた複数のデータベースを保持するサプライヤでは、更新履歴ログはより頻繁に使用されるため、ディスク使用量はさらに増えます。
警告
ボトルネックを回避するため、コンシューマのマシンの規模は、少なくともサプライヤと同等である必要があります。
- サーバースレッド
各レプリケーションアグリーメントは、2 つの追加スレッドを作成します。レプリケーションアグリーメントのスレッドは、操作スレッドとは分けられます。このため、いくつかのレプリケーションアグリーメントが存在する場合、クライアントアプリケーションで使用できるスレッドの数が少なくなり、クライアントアプリケーションに対するサーバーのパフォーマンスに影響が生じる可能性があります。
- ファイルディスクリプタ
サーバーで使用できるファイルディスクリプタの数が、更新履歴ログ (1 ファイルディスクリプタが必要) と各レプリケーションアグリーメント (契約ごとに 1 ファイルディスクリプタが必要) によって減少します。
高可用性を実現するためのレプリケーションの使用
レプリケーションを使用して、単一のサーバーの障害によってディレクトリが使用できなくなることを防止します。最低限、ローカルのディレクトリツリーを少なくとも 1 つのバックアップサーバーにレプリケートしておきます。
ディレクトリの設計者の中には、データの信頼性を最大限保証するために物理的な場所ごとに 3 回はレプリケートしておく必要があると主張する人もいます。しかし、耐障害性を目的としたレプリケーションの使用頻度はユーザーの決定事項ですが、その決定はディレクトリで使用するハードウェアとネットワークの品質を考慮したものでなければなりません。信頼性の低いハードウェアでは、より多くのバックアップサーバーが必要になります。
注 通常のデータバックアップポリシー代わりにレプリケーションを使用することはできません。ディレクトリデータのバックアップについては、『Sun ONE Directory Server 管理ガイド』の「Backing Up Data」および「バックアップ方法の選択」を参照してください。
すべてのディレクトリクライアントに書き込みフェイルオーバーを保証する必要がある場合は、マルチマスターレプリケーションの手法を使用する必要があります。マルチマスターレプリケーションのフローで利用できるグループ化とウィンドウのメカニズムによって、レプリケーションのパフォーマンスが最適化されるようにレプリケーションアグリーメントを設定することができます。ただし、読み取りフェイルオーバーで充分な可用性が達成できる場合は、シングルマスターレプリケーションを使用できます。
LDAP クライアントアプリケーションは通常、1 つの LDAP サーバーだけを検索するように設定できます。つまり、カスタムクライアントアプリケーションを異なる DNS ホスト名にある LDAP サーバーを循環するように作成していないかぎり、LDAP クライアントアプリケーションが Directory Server の単一の DNS ホスト名を検索するように設定するだけで済みます。したがって、バックアップ用の Directory Server にフェイルオーバーを提供するには、DNS ラウンドロビンまたはネットワークソートのどちらかを使用する必要があります。DNS ラウンドロビンとネットワークソートの設定方法と使用方法については、DNS のマニュアルを参照してください。
地理的に離れた場所にまたがって書き込みフェイルオーバーの高い可用性を維持するには、WAN を介した 4 方向のマルチマスターレプリケーションを使用します。1 つの場所で 2 つのマスターを設定し、別の場所にも 2 つのマスターを設定します。これらのマスターを WAN 経由で完全に接続 することで、1 つのマスターがオフラインになった場合の安全対策とします。LAN 経由のマルチマスターレプリケーションと同様に、グループ化とウィンドウのメカニズムを利用して、レプリケーションのパフォーマンスを最適化することができます。
Sun ONE Directory Proxy Server 製品を代わりに使用することもできます。Sun ONE Directory Proxy Server については、http://jp.sun.com/software/ を参照してください。
ローカルでのデータの可用性を高めるためのレプリケーションの使用
レプリケーションを使用して、ローカルでもデータを利用できるようにする必要があるかどうかはネットワークの品質とそのサイトで何を行うかによって決まります。また、ディレクトリに格納するデータの特性と、データが一時的に使用できなくなった場合の会社への影響について慎重に考慮する必要があります。データの重要性が高ければ、それだけ品質の低いネットワーク接続によって引き起こされる業務停滞は、許容できないものになります。
次の理由により、ローカルでもデータを利用するためにレプリケーションを使用する必要があります。
- データのローカルマスターコピーが必要である
これは、特定の国の従業員だけにとって重要なディレクトリ情報を管理する必要がある、大規模な国際企業にとって重要な戦略です。また、データのローカルマスターコピーを保有することは、経営方針としてデータを部門レベルまたは組織レベルで管理するようにしている企業にとっても重要です。
- 信頼性が低いネットワーク接続、または断続的に利用可能なネットワーク接続を使用している
国際ネットワークでよく見られるように、信頼性の低い WAN 使用している場合はネットワーク接続が断続的になることがあります。
- ネットワークに過度な負担が定期的にかかり、ディレクトリのパフォーマンスが著しく低下する
たとえば、旧式のネットワークを使用している企業では、通常の営業時間帯にこのような状態が発生します。
- マスターレプリカでのネットワーク負荷と作業負荷を軽減する
ネットワークの信頼性と可用性に問題がない場合でも、それに関係なくネットワーク使用量の削減が求められることがあります。
ロードバランスのためのレプリケーションの使用
レプリケーションを使用すると、次のような方法で Directory Server にかかる負荷をバランスすることができます。
- ユーザーの検索アクティビティを複数のサーバーに分散する
- 書き込みはマスターレプリカを保持するサーバーだけに限定し、その他のサーバーは読み取り専用に設定する
- メールサーバーのように、特定のタスクに専用サーバーを割り当てる
図 6-9 ロードバランスのためのマルチマスターレプリケーションの使用
ディレクトリデータをレプリケートする重要な理由の 1 つとして、ネットワーク負荷のバランスが挙げられます。可能であれば、比較的高速で信頼性の高いネットワーク接続を介してアクセス可能なサーバーにデータを移動します。最も重要な点は、サーバーとディレクトリユーザーとの間のネットワーク接続の通信速度と信頼性です。
通常、ディレクトリエントリの平均サイズは約 1K バイトです。したがって、ディレクトリの検索ごとにネットワークの負荷が約 1K バイト増加します。ディレクトリユーザーが 1 日当たり約 10 回検索を実行すると、ネットワークの負荷はユーザー 1 人につき 1 日当たり約 10,000 バイト増加します。低速な、負荷が大きい、あるいは信頼性が低い WAN を使用している場合は、ディレクトリツリーをローカルサーバーにレプリケートする必要がある場合もあります。
データをローカルに利用できるという利点が、レプリケーションを使用したことによるネットワーク負荷の増加という不利益を上回るかどうか慎重に検討してください。たとえば、ディレクトリツリー全体をリモートサイトにレプリケーションする場合は、ユーザーのディレクトリの検索によるトラフィックに比べ、はるかに大きな負荷をネットワークに課すことになります。このことは、ディレクトリツリーが頻繁に変更されるのに対して、リモートサイトの少数のユーザーが、1 日当たり数回のディレクトリ検索しか実行しない場合は、特に当てはまります。
たとえば、ディレクトリツリーに平均して 1,000,000 件を超えるエントリがあり、毎日 10 % 前後が変更される場合を考えてみます。ディレクトリエントリのサイズが平均して 1K バイトとすると、ネットワークの負荷が 1 日当たり 100M バイト増えることになります。しかし、リモートサイトの従業員がたとえば 100 人と少なく、1 日当たり平均して 10 回のディレクトリ検索を実行している場合は、ディレクトリアクセスによるネットワークの負荷は 1 日当たり 1M バイトにすぎません。
レプリケーションによる負荷と通常のディレクトリの使用による負荷の違いから、ネットワークのロードバランスを目的とするレプリケーションは好ましくないという結論に達する場合もあります。反対に、ネットワークにかかる負荷を考慮しても、ディレクトリデータをローカルで利用できる利点の方が勝っていると判断する場合もあります。
ネットワークに過度な負荷をかけずにデータをローカルサイトで使用できるようにするには、スケジュールされたレプリケーションを使用します。データの整合性とレプリケーションスケジュールについては、「データの整合性」を参照してください。
ネットワークのロードバランスの例
2 つの都市に事務所を持つ企業を考えてみます。各事務所には、図 6-10 のような方法で管理する特定のサブツリーがあります。
図 6-10 ニューヨークとロサンゼルスでそれぞれ管理されるサブツリー
各事務所には高速のネットワークがありますが、2 都市間の通信にはダイヤルアップ接続を使用しています。このような場合は、以下のようにネットワークの負荷をバランスします。
- 事務所ごとに、ローカルで管理するデータのマスターサーバーとなるサーバーを 1 つ選択する
ローカルで管理するデータを、選択したサーバーからリモートオフィスのマスターにレプリケートします。それぞれの地域でマスターコピーを保持することで、ユーザーはダイヤルアップ接続経由で更新と検索を行う必要がなくなり、パフォーマンスを最適化できます。
- ディレクトリデータの可用性を保証するために、リモートオフィスからのデータも含め、各マスター上のディレクトリツリーを少なくとも 1 つのローカル Directory Server にレプリケーションする
- それぞれの地域でカスケード型レプリケーションを設定し、ローカルデータに対する検索に特化したコンシューマの数を増やすことで、ロードバランスをさらに進める
ニューヨーク事務所では、ロサンジェルスに関する検索よりもニューヨークに関する検索のほうが多く行われるため、この例では、ニューヨーク事務所に 3 つのニューヨークデータコンシューマと、1 つのロサンジェルスデータコンシューマが設定されています。同様に、ロサンジェルス事務所には 3 つのロサンジェルスデータコンシューマと 1 つのニューヨークデータコンシューマがあります。
図 6-11 は、このネットワークロードバランスの設定を示しています。
図 6-11 マルチマスターレプリケーションとカスケード型レプリケーションによるロードバランス
パフォーマンス向上のためのロードバランスの例
ディレクトリで 15,000,000 のエントリを格納して 10,000,000 のユーザーをサポートする必要があり、各ユーザーが 1 日当たり 10 件のディレクトリ検索を実行する場合を考えてみます。また、1 日当たり 250,000,000 通のメールメッセージを処理し、メールメッセージごとに 5 件のディレクトリ検索を実行するメッセージングサーバーを使用しているとします。この場合、メール処理に 1 日当たり 1,250,000,000 件のディレクトリ検索が実行されると予測できます。ディレクトリとメッセージングシステムの合計トラフィックでは 1 日当たり 1,350,000,000 件のディレクトリ検索が実行されることになります。
1 日の就業時間は 8 時間、10,000,000 人のディレクトリユーザーが 4 つの時間帯に分かれているとすると、4 つの時間帯にわたる就業時間 (または、ピーク時の利用率) は 12 時間となります。したがって、1 日 12 時間で 1,350,000,000 件のディレクトリ検索をサポートする必要があります。これは毎秒 31,250 (1,350,000,000 / (60×60×12)) 件の検索をサポートするのと同じです。つまり、次のようになります。
10,000,000 人のユーザー
1 ユーザーにつき 10 件の検索 =
100,000,000 件の読み取り/日
250,000,000 通のメッセージ
1 メッセージにつき 5 件の検索 =
1,250,000,000 件の読み取り/日
合計読み取り/日 =
1,350,000,000
12 時間は 43,200 秒
合計読み取り/秒 =
31,250
ここで、毎秒 5,000 件の読み取りをサポートできる CPU と RAM の組み合わせを Directory Server で使用しているとします。簡単な割り算で、この負荷をサポートするには 6 〜 7 つの Directory Server が必要であることがわかります。ただし、10,000,000 人のディレクトリユーザーを有する企業の場合は、ローカルでデータを利用することも考慮するとさらに Directory Server を追加する必要があります。
注 Directory Server 5.2 では、適切なハードウェアと設定により、1 台のサーバーで、1 秒あたり 5,000 回を超える読み取り処理の継続が可能になります。
これらの計算から、次のような方法でレプリケートします。
- 1 つの都市に 2 つの Directory Servers をマルチマスター設定で配置し、すべての書き込みトラフィックを処理する
この設定は、すべてのディレクトリデータを 1 か所で管理することを想定しています。
- 上記のマスターを使用して 1 つまたは複数のハブにレプリケートする
ディレクトリがサービスする読み取り、検索、および比較の要求はコンシューマで処理されるので、マスターは書き込み要求の処理に専念できます。ハブの定義については、「カスケード型レプリケーション」を参照してください。
- ハブを使用して、会社全体のローカルサイトにレプリケートする
ローカルサイトにレプリケートすることにより、サーバーや WAN の作業負荷をバランスし、ディレクトリデータの可用性を高めることができます。国内の 4 つのサイトにレプリケーションする場合を考えてみます。この場合、各ハブに 4 つのコンシューマが存在することになります。
- 各サイトで、少なくとも 1 回はレプリケートして可用性を高める。また、最低でも読み取り操作を実行できることを確認する
DNS ソートを使用して、ローカルユーザーがディレクトリ検索に使用できるローカルの Directory Server を必ず見つけられるようにします。
小規模サイト向けのレプリケーション方法の例
会社全体が 1 つの建物内にある場合を考えてみます。この建物には、毎秒 100M バイトの高速で使いやすいネットワークが装備されています。ネットワークは非常に安定しており、サーバーのハードウェアと OS プラットフォームの信頼性も十分に高いものとします。また、1 つのサーバーの処理能力でサイトの負荷を容易に処理できるものとします。
このような場合、保守やハードウェアのアップグレードのためにプライマリサーバーが停止されたときでも、ディレクトリデータが利用できるようにしておくために、少なくとも 1 回はレプリケートしておきます。また、Directory Server の 1 つが使用できなくなったときに LDAP 接続のパフォーマンスを上げるために、DNS ラウンドロビンを設定します。代替方法として、Sun ONE Directory Proxy Server などの LDAP プロキシを使用することもできます。Sun ONE Directory Proxy Server については、 http://www.sun.com/software を参照してください。
大規模サイト向けのレプリケーション方法の例
会社が 2 つの建物に分かれている場合を考えてみます。各建物には、毎秒 100M バイトの高速で使いやすいネットワークが装備されています。ネットワークは非常に安定しており、サーバーのハードウェアと OS プラットフォームの信頼性も十分に高いものとします。また、1 つのサーバーの処理能力で、各建物内のサーバーにかかる負荷を容易に処理できるものとします。
建物間は低速接続 (ISDN) で、通常の営業時間中に大きな負荷がかかります。
レプリケーション方法は次のようになります。
- いずれかの建物で、ディレクトリデータのマスターコピーを格納する 1 つのサーバーを選択する
このサーバーは、ディレクトリデータのマスターコピーの管理に責任を持つ人が最も多くいる建物内に設置するようにします。これを建物 A とします。
- ディレクトリデータが常に利用できるようにするために、建物 A で少なくとも 1 回はレプリケートする
書き込みフェイルオーバーを保証する必要がある場合は、マルチマスターレプリケーション設定を使用します。
- もう一方の建物 (建物 B) 内に 2 つのレプリカを作成する
- データのマスターコピーとレプリケートされたコピーの間で厳密な整合性が必要ない場合は、ピーク時間外にレプリケーションが行われるようにスケジュールする
大規模な国際企業のレプリケーション戦略
企業の 2 つの主要サイトがフランスと米国にあり、WAN によって分割されていると仮定します。WAN 経由によるレプリケーションが必要なだけでなく、パートナー企業にすべてのデータを開示しないために、一部のデータをフィルタリングしなければなりません。通常業務時間内は、使用する接続はとても混み合っています。
レプリケーション方法は次のようになります。
- ディレクトリデータのマスターコピーを、両方の地域のそれぞれのサーバーで保持する
- フランスサイト内と米国サイト内の書き込みフェイルオーバーのために、それぞれの地域の第 2 のマスターにデータをレプリケートする
- フランスと米国の間に完全に接続された 4 方向のマルチマスターレプリケーショントポロジを配備し、企業の配備全体で完全な高可用性と書き込みフェイルオーバーを実現する
- 各地域で必要なだけのコンシューマを配備し、検索によるマスターへの負荷をできるだけ軽減する
- 両地域のマスターとコンシューマの間に部分レプリケーションを設定し、パートナー企業にアクセスさせたくないデータをフィルタリングする
- 帯域幅の性能を最適化できるように、混雑していない時間帯に実行されるようにレプリケーションをスケジュールする
レプリケーションとほかのディレクトリ機能との併用
レプリケーションは Directory Server のほかの機能と連携して、高度なレプリケーション機能を提供します。次に、最適なレプリケーションの設計に役立つ、機能の併用について説明します。
レプリケーションとアクセス制御
ディレクトリはエントリの属性として ACI を格納しています。つまり、ACI はほかのディレクトリ内容と一緒にレプリケートされます。Directory Server は ACI をローカルに評価するため、これは重要です。
ディレクトリのアクセス制御の設計方法については、第 7 章に記載されている「安全なディレクトリの設計」を参照してください。
レプリケーションと Directory Server のプラグイン
レプリケーションは、Directory Server に付属するほとんどのプラグインと一緒に使用できます。次に、いくつかの例外と制限について説明します。
レプリケーションと旧バージョン形式の更新履歴ログプラグイン
旧バージョン形式の更新履歴ログプラグインは、Directory Server リリース 4.x との逆互換性のためにサポートされていますが、マルチマスターレプリケーション環境で機能するようには設計されていません。旧バージョン形式の更新履歴ログプラグインは、ローカルサーバーに現れる順に変更を行い、これらの変更がシステムに適用された順では変更を行いません。旧バージョン形式の更新履歴ログプラグインを 2 つのサーバーに設定した場合、変更が同じ順序、および同じ変更番号でログに記録されるとは限りません。レプリケーションプロセスでは変更の順序が重要であるため、マルチマスターレプリケーションで旧バージョン形式の更新履歴ログプラグインを使用した場合、どのような変更がログに記録されたのかを確認することはできますが、実際に変更された内容を適用する上では信頼することができません。
レプリケーションと参照整合性プラグイン
参照整合性プラグインがすべてのマスターレプリカで有効になっている場合は、このプラグインとマルチマスターレプリケーションを一緒に使用できます。
注 デフォルトでは、参照整合性プラグインは無効化されているので、Directory Server コンソールまたはコマンド行から有効化する必要があります。
整合性チェックにはメモリと CPU が多大に消費されるので、変更要求を送信するサーバーで参照整合性プラグインを有効化する前に、パフォーマンスリソース、時間、整合性の必要性を分析してください。
レプリケーションと操作前、操作後プラグイン
操作前プラグインと操作後プラグインをレプリケーションで使用する場合は、レプリケーションがこれらの操作前プラグインと操作後プラグインを検出できる必要があります。これらのレプリケーション操作に対して変更を加えるかどうかを決定することができますが、操作がレプリケートされた操作である場合は、変更によって予期せぬ動作が生じる可能性があるので注意してください。操作前プラグインと操作後プラグインについては、『Sun ONE Directory Server Plug-In API Programming Guide』の「Extending Client Request Handling」を参照してください。
レプリケーションと連鎖サフィックス
連鎖を使用してエントリを分散する場合は、連鎖サフィックスを保持するサーバーが、実際のデータを含むリモートサーバー (ファームサーバー) をポイントします。このような環境では、連鎖サフィックス自体を複製することはできません。ただし、実際のデータを格納しているデータベースのレプリケートは可能です。
注 マルチプレクサ上ではなく、ファームサーバー上のレプリケーションアグリーメントを設定する必要があります。
レプリケーションを連鎖サフィックスのバックアップに使用しないでください。連鎖サフィックスは手動でバックアップする必要があります。連鎖とエントリの分散については、第 5 章を参照してください。
スキーマのレプリケーション
レプリケーション環境で Directory Server を使用する場合は、レプリケーションに含まれるすべてのディレクトリサーバーについてスキーマの一貫性を維持する必要があります。サーバー間でスキーマの一貫性が維持されない場合は、レプリケーションで多くのエラーが発生する可能性があります。
スキーマの一貫性を確保するために、マルチマスターレプリケーション環境の場合でも、1 つのマスターサーバーでスキーマの変更を行うことをお勧めします。
スキーマのレプリケーションは自動的に行われます。サプライヤとコンシューマ間でレプリケーションが設定されている場合は、デフォルトでスキーマがレプリケートされます。
Directory Server でスキーマのレプリケーションに使用されるロジックはどのレプリケーションでも同じで、次のように説明できます。
- データをコンシューマにプッシュする前に、サプライヤは自身のスキーマが、コンシューマ上で保持されているバージョンのスキーマと同期しているかどうかを検査します。
- サプライヤとコンシューマ両方のスキーマエントリが同じであれば、レプリケーションが実行されます。
- サプライヤ上のスキーマがコンシューマに格納されているものよりも新しい場合、サプライヤはデータのレプリケーションを実行する前に自身のスキーマをコンシューマにレプリケートします。
マルチマスターセットの 2 つのマスターサーバーでスキーマに変更を加えた場合、最後に変更されたマスターの変更内容が優先され、そのスキーマがコンシューマに伝達されます。つまり、後から加えた変更が、もう一方のマスターに加えた変更と異なる場合は、その内容が失われる危険があります。変更の喪失を回避するために、常に 1 つのマスターだけでスキーマの変更を行うようにしてください。
注 コンシューマ上のスキーマは絶対に更新しないでください。サプライヤは起こりうる不整合を解決できないので、レプリケーションは失敗します。コンシューマ上のスキーマを更新し、その結果としてサプライヤ上のスキーマのバージョンがコンシューマ上のスキーマのバージョンより古くなった場合は、コンシューマを検索したとき、またはサプライヤ上で更新操作を試みたときにエラーが発生します。
スキーマは、マルチマスターレプリケーショントポロジの単一のマスターで保持する必要があります。標準の 99user.ldif ファイルを使用している場合、これらの変更はすべてのコンシューマにレプリケートされます。カスタムスキーマファイルを使用している場合は、マスター上で変更を行ったら、必ずこれらのファイルをすべてのサーバーにコピーしてください。ファイルをコピーした後に、サーバーを再起動する必要があります。詳細は、「カスタムスキーマファイルの作成 - 最良の事例と落とし穴」を参照してください。
カスタムスキーマファイルへの変更は、スキーマが LDAP または Directory Server コンソールを使用して更新されている場合にだけレプリケートされます。これらのカスタムスキーマファイルは、すべてのサーバー上で情報を同じスキーマファイルに保持するために、各サーバーにコピーする必要があります。詳細については、「カスタムスキーマファイルの作成 - 最良の事例と落とし穴」を参照してください。
スキーマの設計については、第 3 章「スキーマの設計」を参照してください。
レプリケーションと複数パスワードポリシー
複数パスワードポリシーを使用する環境では、レプリケートされたエントリに適用するポリシーの定義を含む LDAP サブエントリをレプリケートする必要があります。レプリケートしない場合、デフォルトのパスワードポリシーが適用されますが、デフォルト以外のパスワードポリシーが設定されているエントリに対しては機能しません。これらのエントリを 5.0/5.1 サーバーにレプリケートした場合、レプリケーションは正常に機能しますが、Directory Server 5.2 に固有の複数のパスワードポリシーが設定されていたとしても、5.0/5.1 サーバーではパスワードポリシーは強制されません。
レプリケーションの監視
Sun ONE Directory Server 5.2 には、サーバー間のレプリケーションを監視するためのレプリケーション監視ツールが用意されています。レプリケーションアクティビティを監視できることは、レプリケーションに関する問題を特定したり、トラブルシューティングを行う上で役立ちます。Directory Server のすべてのレプリケーション監視ツールは、LDAP が有効な場合にだけ使用できます。次の 3 種類のレプリケーション監視ツールがあります。
これらのレプリケーション監視ツールについては、『Sun ONE Directory Server Reference Manual』の「Replication Monitoring Tools」を参照してください。特定のレプリケーション属性による監視については、『Sun ONE Directory Server Reference Manual』の「Core Server Configuration Attributes」の章を参照してください。
注 これらのツールが LDAP クライアントを構成するため、サーバーへの認証と、cn=config に対する読み取りアクセス権を持つバインド DN が必要となることに注意してください。
insync
insync ツールは、マスターレプリカと 1 つまたは複数のコンシューマレプリカの間の同期状態を示します。競合の可能性を管理する場合は、同期の度合いに注意する必要があります。
entrycmp
entrycmp ツールを使用することで、複数のサーバー上の同一エントリを比較することができます。マスターレプリカからエントリが取得され、エントリの nsuniqueid を使用して指定コンシューマから同じエントリを取得します。エントリのすべての属性と値が比較され、すべてが同じであれば、エントリは同一であると見なされます。
注 insync または entrycmp を実行するマシンが、ファイアウォール、VPN、またはその他のネットワーク設定 (たとえば、トポロジ内のハブなど) によって照会先のホストに接続できない場合、insync ツールと entrycmp ツールを使用することは困難になります。
repldisc
repldisc ツールを使用することで、レプリケーショントポロジを推測することができます。トポロジの推測は、1 つのサーバーから始まり、トポロジ内のすべての既知のサーバーをグラフ化することで行われます。次に、repldisc ツールはトポロジを示す隣接マトリクスを出力します。このレプリケーショントポロジ推測ツールは、配備したグローバルトポロジを思い出すことが難しい、大規模で複雑な配備で便利です。
注 レプリケーション監視ツールを使用するときは、次の 2 つの点に注意してください。