test

Sun Java System Directory Server Enterprise Edition 6.2 配備計画ガイド

パート III 論理設計

論理アーキテクチャーは、Directory Server Enterprise Edition 配備のコンポーネントを識別し、コンポーネント間の相互関係を示します。配備で必要なコンポーネントは通常、技術要件フェーズの間に作成されるユースケースによって示されます。ただし、必要なコンポーネントをビジネス要件から直接特定できる場合も数多くあります。

この第 3 部では、Directory Server Enterprise Edition の一般的な配備シナリオをベースにしたサンプルの論理アーキテクチャーを示します。この第 3 部では、基本的な単一サーバー配備から、複数のデータセンターにまたがる複雑な配備に至るまでの広範な情報を扱います。この部の各章で説明するアーキテクチャーは、以前の章で説明した単純なアーキテクチャーが基礎になっています。

次の章で構成されています。

第 9 章 基本的な配備の設計

もっとも単純な Directory Server Enterprise Edition 配備では、1 つのデータセンター内にある、1 台のマシンにインストールされた単一の Directory Server でディレクトリサービスの要件を満たすことができます。組織が小規模な場合や、Directory Server をデモや評価のために実行している場合には、このシナリオが成り立つ可能性があります。前の章で説明されている技術的な要件は、すべての配備に等しく適用されることに注意してください。

この章では、1 台の Directory Server で構成される基本的な配備について説明します。この章で説明する内容は次のとおりです。

基本的な配備のアーキテクチャー

基本的な Directory Server Enterprise Edition 配備には、次の要素が含まれます。

これらの要素をすべて、1 台のマシンにインストールできます。次の図は、基本的な Directory Server Enterprise Edition 配備の高レベルのアーキテクチャーを示しています。

図 9–1 1 台のマシン上の基本的な Directory Server Enterprise Edition のアーキテクチャー

図は、すべての要素が 1 つのサーバーにインストールされた基本的な配備を示しています。

このシナリオでは、内部の LDAP および DSML クライアントを、Directory Server に直接アクセスするように設定できます。外部の HTML クライアントは、ファイアウォールを介して DSCC にアクセスするように設定できます。

先に説明したコンポーネントをすべて 1 台のマシンにインストールすることは可能ですが、それは実際の配備では現実的でありません。より標準的なシナリオでは、DSCC と dsconf コマンド行ユーティリティーを別のリモートマシンにインストールします。それによって、すべての Directory Server ホストを、これらのマシンからリモートに設定することも可能になります。次の図は、この、より標準的なシナリオを示しています。

図 9–2 Directory Service Control Center がリモートにインストールされた基本的な Directory Server Enterprise Edition のアーキテクチャー

図は、Directory Service Control Center と dsconf がリモートサーバーにインストールされた基本的な配備を示しています。

Directory Server インスタンスには、サーバーとアプリケーションの設定や、ユーザー情報が格納されます。一般に、サーバーとアプリケーションの設定情報は Directory Server の 1 つのサフィックスに格納され、ユーザーとグループのエントリは別のサフィックスに格納されます。サフィックスはディレクトリツリー内のエントリの名前で、データはその下に格納されます。

Directory Service Control Center (DSCC) は、すべてのサーバーを集中管理する Web ベースのユーザーインタフェースであり、また Java Web コンソールのディレクトリコンポーネントです。DSCC に登録されているすべてのサーバーとアプリケーションは、グラフィカルユーザーインタフェース上で表示され、そこでサーバーを管理したり設定したりできます。コマンド行インタフェースを通してすべての機能が提供されるため、小規模な配備では Directory Service Control Center が必要ない場合もあります。

以降の章では、Directory Service Control Center が別のマシンにインストールされていることを前提としています。この前提については、各章であらためて言及しません。

基本的な配備の設定

完全なインストール情報は、『Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide 』で提供されています。この節の目的は、基本的な配備を構成する各要素を明確に示し、これらの要素が連携して動作するようすを説明することにあります。

この節では、前の節で説明した基本的な配備を設定するためのメインタスクを示します。

基本的な配備でのパフォーマンスの向上

もっとも基本的な配備でも、特定の領域のパフォーマンスを向上させるために Directory Server の調整が必要になる場合があります。以降の節では、単純な単一サーバー配備に適用できる、基本的なチューニング戦略について説明します。これらの戦略は、トポロジ全体のパフォーマンスを向上させるために、より大規模で、より複雑な配備内の各サーバーにも適用できます。

検索を高速化するためのインデックスの使用

インデックスを使用すると、検索で一致するものを見つけるためにチェックする必要のあるエントリの数が実質的に削減されるため、検索が高速化されます。インデックスには、値のリストが含まれています。各値は、エントリ識別子のリストに関連付けられています。Directory Server は、インデックス内のエントリ識別子のリストを使用して、各エントリをすばやく検索できます。Directory Server が、インデックスのない状態でエントリのリストを管理するには、検索で一致するものを見つけるためにサフィックス内のすべてのエントリをチェックする必要があります。

    Directory Server は、各検索要求を次のように処理します。

  1. Directory Server がクライアントから検索要求を受信します。

  2. Directory Server は要求を検査して、その検索を処理できることを確認します。

    Directory Server が検索を実行できない場合は、クライアントにエラーを返します。また、その検索を Directory Server の別のインスタンスに任せる場合もあります。

  3. Directory Server は、その検索に対応する 1 つ以上のインデックスを管理しているかどうかを判定します。

    • Directory Server がその検索に対応するインデックスを管理している場合、サーバーは、対応するすべてのインデックスを検索して候補エントリを見つけます。候補エントリとは、検索要求に一致する可能性のあるエントリです。

    • Directory Server がその検索に対応するインデックスを管理していない場合、サーバーは、データベース内のすべてのエントリをチェックすることによって候補エントリのセットを生成します。

      Directory Server がインデックスを使用できない場合は、この処理で消費される時間とシステムリソースが増えます。

  4. Directory Server は各候補エントリを検査して、そのエントリが検索条件に一致するかどうかを判定します。

  5. Directory Server は、一致するエントリを見つけると、そのエントリをクライアントアプリケーションに返します。

次のことを行うことによって、検索のパフォーマンスを最適化できます。

インデックスの動作の包括的な概要については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 6 章「Directory Server Indexing」を参照してください。インデックスの定義については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の第 12 章「Directory Server のインデックス」を参照してください。

検索のパフォーマンス向上のためのキャッシュの最適化

検索のパフォーマンスを向上させるには、メモリー内にできるだけ多くのディレクトリデータをキャッシュします。ディレクトリサーバーがディスクから情報を読み取る回数を減らすことで、ディスクの I/O ボトルネックが軽減されます。これを実行するための方法は、ディレクトリツリーのサイズ、使用可能なメモリーの量、および使用されているハードウェアによって異なります。配備によっては、検索のパフォーマンスを最適化するために、エントリキャッシュやデータベースキャッシュに割り当てるメモリーを増やしたり減らしたりすることを選択する場合があります。あるいは、異なるサーバー上の Directory Server コンシューマに検索を分散させることを選択する場合もあります。

次のシナリオを検討してみます。

すべてのエントリとインデックスがメモリーに収まる

最適な場合は、データベースキャッシュとエントリキャッシュが使用可能な物理メモリーに収まります。エントリキャッシュは、ディレクトリ内のすべてのエントリを保持するための十分な大きさがあります。データベースキャッシュは、すべてのインデックスとエントリを保持するための十分な大きさがあります。この場合、検索対象はすべてキャッシュ内で見つかります。Directory Server は、エントリを取得するために、ファイルシステムキャッシュまたはディスクにアクセスする必要がまったくありません。

更新や拡張のあとも、データベースキャッシュにすべてのデータベースインデックスが含まれている必要があります。データベースキャッシュ内のインデックスの領域が不足すると、検索を行うたびに、Directory Server がディスクからインデックスを読み取らなければならなくなり、スループットが大幅に低下します。ページングやキャッシュのアクティビティーは、DSCC またはコマンド行を使用して監視できます。

適切なキャッシュサイズは、代表的なデータでの実験的なテストを通して決定してください。一般に、データベースキャッシュサイズは、(データベースファイルの合計サイズ) x 1.2 として計算できます。最初は、キャッシュに大量のメモリーを割り当ててください。次に、Directory Server を実行して監視し、その結果を観察します。この処理を、必要に応じて繰り返します。エントリキャッシュは特に、これらのキャッシュに割り当てた分よりはるかに多くのメモリーを使用する可能性があります。

32 ビット Directory Server のための十分なメモリーがある

エントリキャッシュとデータベースキャッシュ内のすべてのデータを保持するための十分なメモリーを備えているが、64 ビット Directory Server プロセスをサポートしていないシステムを考えてみます。ハードウェアの制約によって、64 ビットをサポートする Solaris システム上に Directory Server を配備できない場合は、32 ビットプロセスのメモリー制限を考慮してキャッシュサイズを適切に決定してください。次に、残りのメモリーをファイルシステムキャッシュに割り当てます。

パフォーマンスベンチマークの出発点として、エントリキャッシュのサイズを、できるだけ多数のエントリを保持するように決定します。データベースキャッシュのサイズは、完全に最小化せずに 100M バイト程度に比較的小さくしますが、ファイルシステムキャッシュにはデータベースページが保持されるようにします。

注 –

ファイルシステムキャッシュは、システム上のほかのプロセス、特にファイルベースの操作と共有されます。そのため、特に Directory Server 専用のシステムでない場合、ファイルシステムキャッシュの制御はほかのキャッシュの制御より困難です。

システムがファイルシステムキャッシュをほかのプロセスに再割り当てする可能性があります。

インポートキャッシュは Directory Server プロセスに関連付けられているため、この状況でのオンラインインポートは避けてください。

メモリー不足

エントリキャッシュとデータベースキャッシュ内のすべてのデータを保持するにはメモリーが不足しているシステムを考えてみます。この場合は、エントリキャッシュとデータベースキャッシュの合計サイズが使用可能な物理メモリーを超えることのないようにしてください。もし超えてしまうと、仮想記憶のページングが大量に発生し、システムが事実上停止してしまう可能性があります。

小規模なシステムのベンチマークでは、最初、使用可能なメモリーをすべてエントリキャッシュとデータベースキャッシュに割り当てください (サイズはそれぞれ 100M バイト以上)。mount_ufs コマンドの -o forcedirectio オプションを使用して Solaris UFS ファイルシステムをマウントすることによって、ファイルシステムキャッシュの無効化を試みてください。詳細については、mount_ufs(1M) のマニュアルページを参照してください。ファイルシステムキャッシュを無効にすると、Directory Server に必要なメモリーがファイルシステムキャッシュでは使用されないようにすることができます。

大規模なマシン上で実行されている大規模な Directory Server では、ファイルシステムキャッシュを最大化し、データベースキャッシュを減らします。実験的なテストを通してこの前提を確認し、修正してください。

書き込みのパフォーマンス向上のためのキャッシュの最適化

配備に書き込みのスケーラビリティーを持たせるように最初から計画することに加えて、データベースキャッシュがメモリー内の更新を処理できるだけの十分なメモリーを用意してください。また、ディスクアクティビティーも最小限に抑えてください。データベースキャッシュの有効性は、Directory Service Control Center でヒット率を読み取ることによって監視できます。

Directory Server がしばらく実行されたあとは、キャッシュ内に、それ以上ディスク読み取りが必要ないほど十分なエントリとインデックスが含まれているようにしてください。更新の結果は、メモリー内の大規模なデータベースキャッシュにあるデータに反映され、データベースキャッシュはたまにしかフラッシュされないはずです。

チェックポイント中のディスクへのデータのフラッシュは、ボトルネックになる場合があります。データベースキャッシュサイズが大きければ大きいほど、このボトルネックは大きくなります。Sun StorEdgeTM ディスクアレイなどの別の RAID システムにデータベースを格納すると、更新のパフォーマンス向上に役立つ場合があります。潜在的な I/O ボトルネックを分離するには、Solaris システムにおける iostat などのユーティリティーを使用できます。詳細については、iostat(1M) のマニュアルページを参照してください。

次の表は、2、3、および 4 つのディスクを備えたシステムでのデータベースとログの配置方法に関する推奨事項を示しています。

表 9–1 別のディスクへのデータベースとログの分離

使用可能なディスクの数 

推奨事項 

2 

  • Directory Server データベースを 1 番目のディスクに配置します。

  • トランザクションログ、アクセスログ、監査ログ、エラーログ、および旧バージョン対応更新履歴ログを 2 番目のディスクに 配置します。

3 

  • Directory Server データベースを 1 番目のディスクに配置します。

  • トランザクションログを 2 番目のディスクに配置します。

  • アクセスログ、監査ログ、エラーログ、および旧バージョン対応更新履歴ログを 3 番目のディスクに配置します。

4 

  • Directory Server データベースを 1 番目のディスクに配置します。

  • トランザクションログを 2 番目のディスクに配置します。

  • アクセスログ、監査ログ、エラーログを 3 番目のディスクに配置します。

  • 旧バージョン対応更新履歴ログを 4 番目のディスクに配置します。

第 10 章 拡張配備の設計

第 9 章「基本的な配備の設計」で説明した基本的な配備では、1 つの Directory Server で、組織の読み取り要件および書き込み要件を十分に満たせることを前提としています。読み取りまたは書き込み要件がそれよりも厳しい (多数のクライアントがディレクトリデータに同時アクセスを試みる) 組織では、拡張配備を使用する必要があります。

一般に、すべてのデータをキャッシュするための十分なメモリーが搭載されているという仮定のもとで、Directory Server インスタンスが 1 秒あたりに実行できる検索の件数は、サーバーの CPU の数および速度と直接関係します。水平的な読み取りの拡張容易性は、2 台以上のサーバーに負荷を分散させることによって達成できます。これは通常、データの追加コピーを用意して、クライアントが複数のソースからデータを読み取れるようにすることを意味します。

書き込み操作は水平的には拡張しません。それは、マスターサーバーへの書き込み操作の結果として、すべてのレプリカへの書き込み操作が発生するためです。書き込み操作を水平的に拡張する唯一の方法は、ディレクトリデータを複数のデータベースに分割し、それらのデータベースを複数の異なるサーバーに配置することです。

この章では、読み取りおよび書き込みの処理可能件数を増やすために Directory Server Enterprise Edition 配備を拡張する各種の方法について説明します。この章で説明する内容は次のとおりです。

読み取りの拡張容易性のための負荷分散の使用

負荷分散は、読み取り負荷を複数のサーバーに拡散させることによってパフォーマンスを高めます。負荷分散は、レプリケーション、Directory Proxy Server、またはこの両者の組み合わせを使用して実現できます。

負荷分散のためのレプリケーションの使用

レプリケーションは、ディレクトリデータをコピーし、あるディレクトリサーバーから別のディレクトリサーバーに切り替える処理を自動的に行う機構です。レプリケーションを使用することで、ディレクトリツリー、またはそのツリーに固有のサフィックスに格納されるサブツリーをサーバー間でコピーできます。

注 –

設定または監視情報のサブツリーはコピーできません。

ディレクトリデータをサーバー間でレプリケートすることにより、1 台のマシンにかかるアクセス負荷を軽減して、サーバーの応答時間を短縮し、読み取りの拡張容易性を提供することができます。ディレクトリのエントリをユーザーに近い場所にレプリケートすることで、ディレクトリの応答時間を短縮することもできます。レプリケーションは一般的に、書き込みの拡張容易性のためのソリューションではありません。

レプリケーションの基本概念

レプリケーション機構については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 4 章「Directory Server Replication」で詳しく説明しています。次の節では、この章の後半で説明するサンプルトポロジを検討する前に理解しておく必要がある基本的な情報を示します。

マスターレプリカ、コンシューマレプリカ、ハブレプリカ

レプリケーションに関与するデータベースを「レプリカ」と呼びます。

Directory Server では、3 種類のレプリカを区別しています。

次の図は、レプリケーショントポロジ内でのこれらの各レプリカのロールを示したものです。

図 10–1 レプリケーショントポロジ内でのレプリカのロール

この図では、レプリケーショントラフィックと LDAP トラフィックの流れを示します。

注 –

この図は例示のみを目的としたものであり、必ずしも推奨されるトポロジではありません。マルチマスタートポロジで、Directory Server 6.x がサポートするマスター数は無制限です。ほとんどの場合、マスターのみのトポロジが推奨されます。

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

ほかのサーバーにレプリケートする Directory Server のことを「サプライヤ」と呼びます。また、ほかのサーバーによって更新される Directory Server のことを「コンシューマ」と呼びます。サプライヤは、特別に設計された LDAP v3 拡張処理により、コンシューマ上のすべての更新を再現します。このためサプライヤは、パフォーマンスの面ではコンシューマに対する要件の多いクライアントアプリケーションに似ています。

次のような状況で、サーバーはサプライヤとコンシューマの両方になることができます。

コンシューマのロールのみを果たすサーバーのことを「専用コンシューマ」と呼びます。

「マスターレプリカ」の役割をするサーバーは次のことを行う必要があります。

マスターレプリカを含むサーバーは、マスターレプリカに対して行われたすべての変更を記録する処理と、これらの変更をコンシューマにレプリケートする処理を受け持ちます。

「ハブレプリカ」の役割をするサーバーは次のことを行う必要があります。

「コンシューマレプリカ」の役割をするサーバーは次のことを行う必要があります。

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

マルチマスターレプリケーション設定では、データは異なる場所で同時に更新することができます。各マスターは、そのレプリカの変更履歴ログを維持します。各マスター上で発生した変更は、ほかのサーバーにレプリケートされます。

マルチマスター設定には、次の利点があります。

マルチマスターレプリケーションでは、疎整合レプリケーションモデルを使用します。これは、同じエントリが異なるサーバー上で同時に変更される可能性があることを意味します。2 つのサーバー間で更新が送信された場合、更新の競合を解決する必要があります。待ち時間などの WAN の各種特性により、レプリケーション競合の可能性が高まる可能性があります。競合の解決は通常、自動的に行われます。どの変更が優先されるかは、競合規則によって決定されます。競合を手動で解決しなければならない場合もあります。詳細は、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「よく発生するレプリケーションの競合の解決」を参照してください。

マルチマスタートポロジでサポートされるマスターの数は、理論上は無制限です。同様に、コンシューマとハブの数も理論上は無制限です。ただし、1 つのサプライヤから何個のコンシューマにレプリケーションを実行できるかは、サプライヤサーバーの能力に依存します。サプライヤサーバーの能力を評価するために、SLAMD 分散負荷生成エンジン (SLAMD) を使用できます。SLAMD の詳細および SLAMD ソフトウェアのダウンロードについては、http://www.slamd.com を参照してください。

レプリケーションの単位

レプリケーションの最小単位はサフィックスです。レプリケーション機構では、サフィックスとデータベースが 1 対 1 で対応している必要があります。カスタム分散ロジックを使用している 2 つ以上のデータベースにまたがって分散されているサフィックス (またはネームスペース) はレプリケートできません。レプリケーション単位は、コンシューマとサプライヤの両方に適用されます。つまり、1 つのサフィックスだけを保持するコンシューマに 2 つのサフィックスをレプリケートすることはできません。

更新履歴ログ

サプライヤとして機能するすべてのサーバーは更新履歴ログを維持します。「更新履歴ログ」は、マスターレプリカに対して行われた変更を記述した記録です。サプライヤは、この変更をコンシューマ上で再現します。エントリの変更、名称変更、追加、または削除が行われると、LDAP 操作を記述する変更レコードが更新履歴ログに記録されます。

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

Directory Server では、レプリケーションアグリーメントを使用して、2 つのサーバー間でレプリケーションがどのように行われるかを定義します。「レプリケーションアグリーメント」は、1 つのサプライヤと 1 つのコンシューマの間のレプリケーションを定義します。

レプリケーションアグリーメントは次のものを識別します。

レプリケーション優先度

Directory Server 6.x よりも前のバージョンの Directory Server では、更新は時系列順にレプリケートされていました。本バージョンでは、更新のレプリケーションに優先順位を付けることができます。優先度はブール型の機能であり、オンまたはオフを選択できます。優先度のレベルはありません。レプリケーションを待機している更新のキュー内で、優先度がオンの更新は、優先度がオフの更新よりも先にレプリケートされます。レプリケーションを待機している更新のキュー内で、優先度がオンの更新は、優先度がオフの更新よりも先にレプリケートされます。

優先度規則は、次のパラメータに従って設定されます。

詳細は、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の「Prioritized Replication」を参照してください。

初期レプリケーション要件の評価

ディレクトリサービスのレプリケーションを成功させるには、本稼働環境での徹底的なテストおよび分析が必要です。ただし、次の基本的な計算を使用して、レプリケートされるトポロジの設計を開始することができます。以降の節では、レプリケートされるトポロジ設計の基礎として、この計算の結果を使用します。

Procedure初期レプリケーション要件を決定するには

  1. 使用状況がピークに達する時間帯で、1 秒あたり最大何件の検索を処理できる必要があるかを見積もります。

    この見積もり値を「総検索数」とします。

  2. 単一のホストで処理できる 1 秒あたりの検索数をテストします。

    この見積もり値を「ホストあたりの検索数」とします。このテストは「レプリケーションを有効にした」状態で行う必要があります。

    ホストが処理できる検索数は、さまざまな変動要因の影響を受けます。特に影響が大きいのは、エントリのサイズ、ホストの容量、およびネットワークの速度です。これらのテスト作業に役立つパフォーマンステストツールが、サードパーティーから多数提供されています。SLAMD 分散負荷生成エンジン (SLAMD) は、ネットワークベースアプリケーションの負荷テストおよびパフォーマンス分析の用途向けに設計された、オープンソースの Java アプリケーションです。SLAMD を利用することで、レプリケーション評価のこの段階の作業を効率的に実行できます。SLAMD の詳細および SLAMD ソフトウェアのダウンロードについては、http://www.slamd.com を参照してください。

  3. 必要なホスト数を計算します。

    ホスト数 = 総検索数/ホストあたりの検索数

単一データセンターでのマルチマスターレプリケーションを利用した負荷分散

レプリケーションにより、Directory Server への負荷を次のように分散させることができます。

一般に、完全接続型トポロジにおいて、「初期レプリケーション要件の評価」で計算した「ホスト数」が 16 前後であるか、それよりも極端に大きくなければ、トポロジにはマスターサーバーのみを含めることをお勧めします。完全接続型とは、すべてのマスターが、トポロジ内のほかのマスターすべてにレプリケートするという意味です。

注 –

計算で得られた「ホスト数」は概算値であり、ハードウェア構成や、配備のその他の詳細条件によって変動します。

次の図では、「ホスト数」が 2 であると仮定しています。クライアントアプリケーションのタイプに基づいて、LDAP 操作が 2 つのマスターサーバーに分割されます。この方針により、各サーバーにかかる負荷が減少し、配備全体で処理できる合計の操作数は増加します。

図 10–2 負荷分散のためのマルチマスターレプリケーションの使用

この図では、2 種類のクライアントアプリケーションと、それらのアプリケーションの要求が 2 つの独立したマスターに送られるようすを示しています。

グローバル配備における類似のシナリオについては、「WAN を介したマルチマスターレプリケーションの使用」を参照してください。

大規模配備でのレプリケーションによる負荷分散

対象の配備で必要な「ホスト数」が 16 を大きく超える場合、専用コンシューマをトポロジに追加しなければならない場合があります。

次の図では「ホスト数」が 24 であると仮定し、簡略化のためにトポロジの一部のみを示しています。残り 10 台のサーバーも同一の構成であり、合計で 8 個のマスターと 16 個のコンシューマが存在します。

図 10–3 大規模配備でのマルチマスターレプリケーションを使用した負荷分散

図では、4 個のマスターと 8 個のコンシューマが存在するマルチマスターレプリケーションを示しています。

次のことを行う必要がある場合、該当する任意のコンシューマに対して更新履歴ログを有効にできます。

「ホスト数」が数百に達する場合は、トポロジにハブを追加することを検討してください。そのような場合、ハブの数はマスターの数よりも多くしてください。具体的には、マスター 1 個あたり最大で 10 個のハブを使用し、各ハブでは 20 個程度までのコンシューマへのレプリケーションを処理するようにします。

どのようなトポロジでも、ハブ数とマスター数、またはハブ数とコンシューマ数が同じになるような構成は避けてください。

マルチマスタートポロジを簡素化するためのサーバーグループの使用

「ホスト数」が大きい場合、「サーバーグループ」を使用してトポロジを簡素化し、リソースの使用効率を改善することができます。16 個のマスターが存在するトポロジで、4 つのサーバーグループを使用してそれぞれに 4 つのマスターを配置すると、16 個のマスターを完全メッシュ構成にする場合よりも管理が容易になります。

そのようなトポロジを設定するために必要な手順は、次のとおりです。

次の図に最終的なトポロジを示します。

図 10–4 マルチマスタートポロジでのサーバーグループ

図では、それぞれが 4 つのマスターを含む 4 つのサーバーグループを示しています。

Directory Proxy Server を使用した負荷分散

Directory Proxy Server では、複数のサーバーを使用することにより、単一データソースの負荷を分散させることができます。また Directory Proxy Server は、サーバーのうち 1 台が停止した場合でもデータの継続的な可用性を保証できます。Directory Proxy Server はデータの分散だけでなく、操作のタイプに基づいた負荷分散機能も提供します。この機能では、サーバーは操作の「タイプ」に基づいて、クライアント操作を特定の Directory Server に経路指定できます。

Directory Proxy Server は操作のタイプに基づいた負荷分散に加えて、作業負荷が Directory Server 間でどのように共有されるかを決定する各種の負荷分散アルゴリズムをサポートします。これらの各アルゴリズムの詳細は、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 16 章「Directory Proxy Server Load Balancing and Client Affinity」を参照してください。

次の図は、比例アルゴリズムを使用して 2 つのサーバー間で読み取り負荷を分散させる方法を例示しています。操作のタイプに基づいた負荷分散では、マスター 1 のサーバーで障害が発生しないかぎり、すべての書き込みがマスター 1 に経路指定されます。マスター 1 のサーバーで障害が発生すると、すべての読み取りと書き込みはマスター 2 に経路指定されます。

図 10–5 拡張配備での比例および操作ベース負荷分散の使用

図では、Directory Proxy Server を使用した比例および操作のタイプに基づいた負荷分散を示しています。

1 つのサーバーインスタンスで障害が発生しても、負荷分散の設定は再計算されません。比例型の負荷分散を使用し、サーバーの負荷分散ウェイトを 0 に設定しても、「ホットスタンバイ」サーバーを作成することはできません。

たとえば、3 つのサーバー A、B、および C が存在するとします。また、サーバー A と B がそれぞれ 50% の負荷を受け持つように比例型負荷分散が設定されています。サーバー C は、スタンバイ専用のサーバーとして、0% の負荷を受け持つように設定されています。サーバー A で障害が発生すると、負荷の 100% が自動的にサーバー B に振り分けられます。サーバー B でも障害が発生した場合にはじめて、サーバー C に負荷が分散されます。そのため、負荷分散に常時参加しているインスタンスが、常に負荷を受け持ち、それらのインスタンスすべてで障害が発生した場合にかぎり、スタンバイ状態のサーバーに負荷が振り分けられることになります。

飽和負荷分散アルゴリズムを使用し、スタンバイサーバーに低いウェイトを適用することにより、ホットスタンバイと同様の効果を達成できます。そのようなサーバーは本来の意味のスタンバイサーバーではありませんが、メインのサーバーの負荷が極端に高まった場合にのみこのサーバーに要求が分散されるように、アルゴリズムを設定することができます。メインサーバーの 1 つが無効になり、それに伴ってほかのメインサーバーの受け持つ負荷がかなり上昇すると、スタンバイサーバーに対して負荷の分散が行われます。

書き込みの拡張容易性のための分散の使用

書き込み操作はリソースの消費が大きい操作です。クライアントが書き込み操作を要求すると、データベース上で次の一連のイベントが発生します。

このような複雑な手順により書き込み操作が行われるため、書き込み数が増加するとパフォーマンスも著しく影響を受けます。

企業の規模が拡大すると、より多くのクライアントアプリケーションがディレクトリへの高速な書き込みアクセスを要求するようになります。また、単一の Directory Server に格納される情報が増加すればするほど、ディレクトリデータベースのエントリを追加または変更するためのコストも上昇します。これは、インデックスが肥大化して、インデックスに含まれる情報の操作にかかる時間が長くなることが原因です。

サービスレベル契約を達成するために、すべてのデータをメモリー上にキャッシュとして保持しなければならない場合もあります。ただしその場合、データが大きすぎて 1 台のマシンのメモリーに収まりきれないことも考えられます。

ディレクトリデータの分量がこのレベルにまで増加した時点で、複数のサーバーに格納できるようにデータを分割する必要が生じます。1 つのアプローチは、階層を使用して情報を分割するというものです。何らかの基準に従って情報を複数の分岐に分離することにより、各分岐を別個のサーバーに格納できます。その後、連鎖またはリフェラルを使用して各サーバーを設定し、クライアントが単一点からすべての情報にアクセスできるようにします。

この種の分割では、各サーバーはディレクトリツリーの一部分にのみ責任を持ちます。分散ディレクトリサービスは、ドメインネームサービス (DNS) に似た方法で機能します。DNS では、DNS ネームスペースの個々の部分を特定の DNS サーバーに割り当てます。同様に、ディレクトリのネームスペースを複数のサーバーに分散し、クライアント側からは単一のディレクトリツリーとして見えるように管理することができます。

階層ベースの分散機構には、いくつかの短所があります。主な問題は、この機構では、情報が存在する場所をクライアントの側で正確に把握している必要があるということです。そうでない場合、クライアントは広範な検索を実行してデータを見つけ出す必要があります。もう 1 つの問題は、一部のディレクトリ対応アプリケーションで、複数の分岐に分割された情報を適切に処理できないというものです。

Directory Server では、連鎖機構およびリフェラル機構との組み合わせで階層ベースの分散をサポートします。ただし、分散機能はスマートルーティングをサポートする Directory Proxy Server でも提供されます。この機能により、企業ごとに最適な分散機構を決定することができます。

複数のデータベースの使用

Directory Server では、パフォーマンスの高いディスクベースの LDBM データベースにデータを格納します。各データベースは 1 つのファイルセットで構成され、ファイルセットには、このセットに割り当てられたすべてのデータが含まれます。ディレクトリツリーの異なる部分を別々のデータベースに格納できます。たとえば、次の図に示すように、ディレクトリツリーに 3 つのサブサフィックスが含まれていると仮定します。

図 10–6 3 つのサブサフィックスを持つディレクトリツリー

図では、1 つのサフィックスと 3 つのサブサフィックスを含むディレクトリツリーを示します。

次の図に示すように、3 つのサブサフィックスのデータを 3 つの独立したデータベースに格納できます。

図 10–7 3 つの異なるデータベースに格納された 3 つのサブサフィックス

図では、3 つの独立したデータベースに格納される 3 つのサブサフィックスを示しています。

複数のデータベースにディレクトリツリーを分割するとき、複数のサーバー間にデータベースを分散させることができます。またパフォーマンス改善のために、複数の物理マシンに分散することができます。前の例で示した 3 つのデータベースを、次の図に示すように 2 つのサーバーに格納することができます。

図 10–8 2 つの独立したサーバーに格納される 3 つのデータベース

図では、あるサーバー (A) に格納される 2 つのデータベースと、別のサーバー (B) に格納される 1 つのデータベースを示しています。

データベースを複数のサーバーに分散させると、各サーバーで処理しなければならない作業量は減ります。そのため、ディレクトリを拡張して、1 つのサーバーで保持できる数よりはるかに多くのエントリを保持できるようにすることができます。Directory Server はデータベースの動的追加をサポートするため、ディレクトリ全体を停止させることなく、必要に応じて新しいデータベースを追加できます。

Directory Proxy Server を使用した分散

Directory Proxy Server はディレクトリ情報を複数のサーバーに分割しますが、その際にデータの階層を変更する必要はありません。データ分散にとって重要なことは、データセットを論理的な方法で分割することです。ただし、あるクライアントアプリケーションに対して適切に機能する分散ロジックが、別のクライアントアプリケーションに対しても同じように機能するとはかぎりません。

この理由から、Directory Proxy Server では、データがどのように分散されるか、またディレクトリ要求がどのように経路指定されるべきかをユーザーが指定できます。たとえば、ディレクトリ情報ツリー (DIT) の階層に基づいて、LDAP 操作を複数の異なるディレクトリサーバーに経路指定することができます。操作タイプやカスタムの分散アルゴリズムに基づいて操作を経路指定することもできます。

Directory Proxy Server は、分散の詳細をクライアントアプリケーションから実質的に隠蔽します。クライアントの側からは、発行したディレクトリクエリーは 1 つのディレクトリによって処理されるように見えます。クライアント要求は、特定の分散方法に従って分散されます。以降の節で説明するように、DIT の部分ごとに異なるルーティング方針を各部分に関連付けることができます。

DIT に基づくルーティング

この方針は、DIT の構造に基づいてディレクトリエントリを分散させるために使用できます。たとえば、サブツリー「o=sales,dc=example,dc=com」内のエントリを、Directory Server A に、サブツリー「o=hr,dc=example,dc=com」内のエントリを Directory Server B にそれぞれ経路指定できます。

カスタムアルゴリズムに基づくルーティング

DIT に基づくルーティング以外の方法でエントリを複数のディレクトリサーバーに分散させたい場合もあるでしょう。たとえば、あるサービスプロバイダで、登録者を表すエントリを「ou=subscribers,dc=example,dc=com」内に格納するとします。登録者の数が増えるにつれ、登録者 ID の範囲に基づいて登録者を複数のサーバーに分散させることが必要になる場合があります。カスタムのルーティングアルゴリズムを使用して、ID が 1〜10000 の範囲の登録者エントリを Directory Server A に、ID が 10001 以降の範囲の登録者エントリを Directory Server B に配置できます。サーバー B 上のデータが増えすぎた場合、分散アルゴリズムを変更して、ID が 20001 以降のエントリを新しいサーバー C に配置することができます。

Directory Proxy Server の DistributionAlgorithm インタフェースを使用し、独自のルーティングアルゴリズムを実装することができます。

Directory Proxy Server を使用したバインド DN ベースの要求分散

このシナリオでは、企業は地理的な位置を基準にして、3 つのマスターサーバーに顧客データを分散させます。イギリスに在住する顧客のデータを、ロンドンにあるマスターサーバーに格納します。フランスの顧客のデータはパリにあるマスターサーバーに格納します。日本の顧客のデータは東京にあるマスターサーバーに格納します。顧客は自分自身のデータを、Web ベースの統一されたインタフェースを通して更新できます。

ユーザーはディレクトリ内の自分自身の情報を、Web ベースのアプリケーションを使用して更新できます。認証フェーズの間、ユーザーは電子メールアドレスを入力します。イギリスの顧客の電子メールアドレスは *@uk.example.com という形式です。フランスの顧客の形式は *@fr.example.com であり、日本の顧客は *@ja.example.com です。Directory Proxy Server は、LDAP 対応のクライアントアプリケーション経由でこれらの要求を受信します。Directory Proxy Server はその後、認証時に入力された電子メールアドレスに基づいて、適切なマスターサーバーに要求を経路指定します。

次の図はこのシナリオを例示したものです。

図 10–9 Directory Proxy Server を使用したバインド DN ベースの要求ルーティング

図では、電子メールアドレスに基づいて Directory Proxy Server が要求を分散するしくみを示しています。

DIT の下位方向へのデータ分散

多くの場合、DIT の頂点でのデータ分散は必要ありません。ただし、ツリーの上位にあるエントリが、ツリーの分散済み部分にあるエントリによって必要とされる場合があります。この節では、サンプルのシナリオを通して、このようなケースでの分散方針を設計する方法を示します。

分散されるデータの論理ビュー

Example.com には、グループに対応する 1 つのサブツリーと、人に対応する 1 つの独立したサブツリーがあります。グループ定義の数は少なくあまり変化しませんが、人を表すエントリの数は多く、増加し続けます。そのため Example.com では、人のエントリだけを 3 つのサーバーに分散させる必要があります。ただし、people サブツリー下のすべてのエントリにアクセスするには、グループ定義、グループ定義の ACI、およびネーミングコンテキストの最上位に位置する ACI が必要です。

次の図は、データ分散要件の論理ビューを示したものです

図 10–10 分散されるデータの論理ビュー

図では、ou=people 分岐をどのように分散させる必要があるかを示しています。

データ記憶領域の物理ビュー

ou=people サブツリーは、各エントリの sn 属性の先頭文字に従って、3 つのサーバーに分散されます。ネーミングコンテキスト (dc=example,dc=com) および ou=groups コンテナは、各サーバー上の 1 つのデータベースに格納されます。ou=people 下のエントリがこのデータベースにアクセスできます。ou=people コンテナは、このコンテナ専用のデータベースに格納されます。

次の図は、個々の Directory Server 上にデータがどのように格納されるかを示したものです。

図 10–11 データ記憶領域の物理ビュー

図では、分散されるデータの物理記憶領域を示しています。

ou=people コンテナはトップコンテナのサブサフィックスではありません。

サンプル配備シナリオ用の Directory Server 設定

これまでに説明した各サーバーは、分散チャンク (chunk) として理解することができます。ネーミングコンテキストおよび ou=groups 下のエントリを含むサフィックスは、各チャンク上で同じです。したがって、3 つのチャンクのそれぞれにまたがって、このサフィックスに対してマルチマスターレプリケーションアグリーメントを設定します。

また、可用性のために各チャンクはレプリケートされています。したがって、各チャンクに対して少なくとも 2 つのマスターレプリカが定義されています。

次の図は、各チャンクに対して 3 つのレプリカが定義された Directory Server 設定を示しています。簡略化のため、1 つのチャンクに対するレプリケーションアグリーメントのみを示していますが、ほかの 2 つのチャンクに対しても同じアグリーメントが定義されています。

図 10–12 Directory Server 設定

図では、分散されるデータのレプリケーショントポロジを示しています。

サンプル配備シナリオ用の Directory Proxy Server 設定

クライアントによる Directory Proxy Server 経由でのディレクトリデータへのアクセスは「データビュー」を通して提供されます。データビューの詳細は、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 17 章「Directory Proxy Server Distribution」を参照してください。

このシナリオでは、分散される各サフィックスに対して 1 つのデータビューが必要であり、ネーミングコンテキスト (dc=example,dc=com) および ou=groups サブツリーに対して 1 つのデータビューが必要です。

次の図では、分散データへのアクセスを提供するための Directory Proxy Server データビューの設定を示しています。

図 10–13 Directory Proxy Server 設定

図では、分散データ用のデータビュー設定を示しています。

データ増加に関する考慮事項

分散されるデータは、分散アルゴリズムに従って分割されます。使用する分散アルゴリズムを決定するときは、データの分量が変化する可能性があることと、分散方針は拡張性のあるものでなければならないことに留意してください。データの完全な再分散を必要とするようなアルゴリズムを使用しないでください。

たとえば、uid などの数値に基づく分散アルゴリズムは、比較的簡単に拡張できます。uid=0-999 および uid=1000–1999 の 2 つのデータセグメントから開始する場合、uid=2000–2999 という 3 番目のセグメントをあとから追加することは容易です。

リフェラルを使用した分散

リフェラルはサーバーによって返される情報であり、操作要求を進めるためにどのサーバーと通信すればよいかをクライアントアプリケーションに通知します。分散ロジックの管理に Directory Proxy Server を使用しない場合、分散されるデータ間の関係を別の方法で定義する必要があります。関係を定義する 1 つの方法は「リフェラル」の使用です。

Directory Server では、リフェラル返送の形式とタイミングを 3 つの方法で設定できます。

次の図は、リフェラルを使用して、グローバルトポロジ内の適切なサーバーにイギリスの顧客を誘導する方法を例示したものです。このシナリオでは、クライアントアプリケーションがリフェラルに従うためには、クライアントアプリケーションがトポロジ内のすべてのサーバーに (TCP/IP レベルで) 接続できる必要があります。

図 10–14 リフェラルを使用した特定サーバーへのクライアントの誘導

次の図は、コンシューマの Directory Server に要求を送信しているクライアントを示します。この Directory Server は、クライアントにトポロジ内の別のサーバーを参照させます。

Directory Proxy Server でのリフェラルの使用

Directory Proxy Server とリフェラル機構を組み合わせて使用することにより、同じ結果を達成することができます。この目的のために Directory Proxy Server を使用することの利点は、クライアントアプリケーションの負荷および複雑さが軽減されることです。クライアントアプリケーションは Directory Proxy Server の URL のみを認識します。何らかの理由で分散ロジックが変更された場合でも、この変更はクライアントアプリケーションに対して透過的です。

次の図は、前に説明したシナリオを、Directory Proxy Server を使用することによって簡略化する方法を例示しています。クライアントアプリケーションは常に Proxy Server と通信し、リフェラル自体は Proxy Server によって処理されます。

図 10–15 Directory Proxy Server でのリフェラルの使用

図では、すべてのリフェラルを処理する Directory Proxy Server に要求を送信しているクライアントを示しています。

第 11 章 グローバル配備の設計

グローバル配備では、1 つ以上の地域にあるデータセンターのディレクトリサービスへのアクセスが必要になります。この章では、複数のデータセンターにわたって Directory Server Enterprise Edition を効率的に配備するための戦略について説明します。これらの戦略によって、第 5 章「サービスレベル契約の定義」で説明されているサービスの品質に対する要件は満足されることが保証されます。

この章で説明する内容は次のとおりです。

複数のデータセンターにわたるレプリケーションの使用

レプリケーションの 1 つの目標は、LDAP サービスの地理的な分散を可能にすることです。レプリケーションを使用すると、複数のサーバー上や、複数のデータセンターにわたって情報の同一のコピーを保持することができます。レプリケーションの概念については、このガイドの第 10 章「拡張配備の設計」でその概要が、さらに『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 4 章「Directory Server Replication」でその詳細が説明されています。この章では、グローバル配備で使用されるレプリケーション機能に焦点を絞ります。

WAN を介したマルチマスターレプリケーションの使用

Directory Server では、WAN を介したマルチマスターレプリケーションをサポートしています。この機能により、マルチマスターレプリケーション設定を地理的に離れた場所にある複数のデータセンターに国際的に配備できます。

一般に、「初期レプリケーション要件の評価」で計算されるホストの数が 16 より小さいか、またはそれより大幅に大きくはない場合、トポロジを、完全に接続されたトポロジ内にマスターサーバーのみが含まれる、つまり、すべてのマスターがトポロジ内のほかのすべてのマスターにレプリケートする状態にしてください。WAN 構成を介したマルチマスターレプリケーションでは、WAN で分離されたすべての Directory Server インスタンスが、Directory Server 5.2 より前のバージョンを実行していないようにしてください。4 つを超えるマスターを含むマルチマスタートポロジの場合は、Directory Server 6.x が必要です。

レプリケーションプロトコルでは、完全な非同期サポートのほか、ウィンドウ、グループ化、および圧縮のメカニズムが提供されます。これらの機能によって、WAN を介したマルチマスターレプリケーションが実行可能になります。レプリケーションのデータ転送速度は、帯域幅の点から見て、使用可能な物理媒体で可能になる速度を常に下回ります。レプリカ間の更新の量が、物理的に、使用可能な帯域幅に収まりきらない場合は、チューニングを行っても、更新の重い負荷の下でのレプリカの発散を避けることはできません。レプリケーションの遅延や更新のパフォーマンスは、変更の頻度、エントリサイズ、サーバーハードウェア、平均待ち時間、平均帯域幅など (ただし、これらには限定されない) を含む多くの要因に依存します。

レプリケーションメカニズムの内部のパラメータは、WAN に対してデフォルトで最適化されます。ただし、上で述べた要因のためにレプリケーションの速度低下が発生している場合は、ウィンドウサイズやグループサイズのパラメータを実験的に調整することをお勧めします。また、ネットワークのピーク時間帯を避けるようにレプリケーションをスケジュールして、全体的なネットワーク使用率を向上させることができる可能性もあります。最後に、Directory Server は、帯域幅使用率を最適化するためのレプリケーションデータの圧縮をサポートしています。

WAN リンクを介してデータをレプリケートする場合は、データの完全性と機密性を保証する何らかの形式のセキュリティーを確保することをお勧めします。Directory Server で使用可能なセキュリティー手段の詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 2 章「Directory Server Security」を参照してください。

グループとウィンドウのメカニズム

Directory Server は、レプリケーションの流れを最適化するためのグループとウィンドウのメカニズムを提供しています。グループのメカニズムを使用すると、変更を個別にではなく、グループで送信するように指定できます。グループサイズは、1 つの更新メッセージにまとめることのできるデータ変更の最大数を表します。ネットワーク接続がレプリケーションのボトルネックになっているように見える場合は、グループサイズを増やし、レプリケーションのパフォーマンスをもう一度チェックしてください。グループサイズの設定については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「グループサイズの設定」を参照してください。

ウィンドウのメカニズムは、サプライヤが処理継続のためのコンシューマからの受信通知を待つことなく、コンシューマに特定の数の更新要求を送信するように指定します。ウィンドウサイズは、コンシューマからの即座の受信通知がなくても送信できる更新メッセージの最大数を表します。メッセージごとに受信通知を待つのではなく、多数のメッセージをすばやく連続して送信する方がより効率的です。適切なウィンドウサイズを使用することにより、レプリカがレプリケーションの更新または受信通知の到着を待つために費やす時間を削除できます。コンシューマレプリカがサプライヤから遅延している場合は、ウィンドウサイズをデフォルトより大きい値 (たとえば 100) に増やし、それ以上の調整を行う前にレプリケーションのパフォーマンスをもう一度チェックしてください。レプリケーションの更新頻度が高く、そのため更新の間隔が短い場合は、LAN で接続されているレプリカでもウィンドウサイズを大きくすると利点が得られます。ウィンドウサイズの設定については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「ウィンドウサイズの設定」を参照してください。

グループとウィンドウのメカニズムはどちらも、変更のサイズに基づいています。そのため、変更のサイズが大幅に変動する場合、これらのメカニズムを使用してレプリケーションのパフォーマンスを最適化することは実用的でない場合があります。変更のサイズが比較的均一である場合は、グループとウィンドウのメカニズムを使用して、差分更新と完全更新を最適化することができます。

レプリケーションの圧縮

グループ化とウィンドウのメカニズムに加えて、Solaris および Linux プラットフォームではレプリケーションの圧縮も設定できます。レプリケーションの圧縮は、レプリケーションの流れを効率化します。それによって、WAN を介したレプリケーションでのボトルネックの発生率が大幅に削減されます。レプリケートされるデータを圧縮すると、CPU 性能は十分だが帯域幅が狭いネットワークや、一括変更をレプリケートする場合など、特定の場合でのレプリケーションのパフォーマンスを向上させることができます。また、大きなエントリを含むリモートレプリカを初期化する場合も、レプリケーションの圧縮によって利点が得られます。広いネットワーク帯域幅が存在する LAN (ローカルエリアネットワーク) ではこのパラメータを設定しないでください。圧縮と圧縮解除の計算によってレプリケーションの速度が低下するためです。

レプリケーションメカニズムは、Zlib 圧縮ライブラリを使用します。予測されるレプリケーション使用率に対して WAN 環境で最高の結果が得られる圧縮レベルを実験的にテストし、選択してください。

レプリケーションの圧縮を設定する方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「レプリケーションの圧縮の設定」を参照してください。

部分レプリケーションの使用

グローバルなトポロジ (データセンターが各国に存在する) には、セキュリティーまたは遵守の理由から、レプリケーションの制限が必要になる場合があります。たとえば、法律上の規制で、特定の従業員情報を米国外にはコピーできないと規定されている可能性があります。または、オーストラリア内のサイトにはオーストラリアの従業員の詳細情報のみが必要になる可能性があります。

部分レプリケーション機能を使用すると、エントリ内に存在する属性のサブセットのみをレプリケートできます。属性リストは、レプリケートできる属性とレプリケートできない属性を判定するために使用されます。部分レプリケーションは、読み取り専用のコンシューマに対してのみ適用できます。

部分レプリケーションの動作の詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の「Fractional Replication」を参照してください。部分レプリケーションを設定する方法については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「部分レプリケーション」を参照してください。

優先順位付きレプリケーションの使用

優先順位付きレプリケーションは、特定の属性に関してレプリケートされるデータのより厳密な一貫性を確保する、強いビジネス要件が存在する場合に使用できます。5.x バージョンの Directory Server の場合、更新は、受信された順序でレプリケートされていました。優先順位付きレプリケーションでは、トポロジ内のほかのサーバーにレプリケートするときに、特定の属性に対する更新を優先させるように指定できます。

優先順位付きレプリケーションには、次の利点があります。

国際的な企業のレプリケーション戦略のサンプル

このシナリオでは、ある企業の 2 つの主要なデータセンターがロンドンとニューヨークに 1 つずつあり、WAN で分離されています。ここでは、通常業務時間内はネットワークが非常に混み合っていることを前提にしています。

このシナリオでは、ホストの数が 8 と計算されています。2 つのデータセンターのそれぞれに、完全に接続された 4 方向のマルチマスタートポロジが配備されています。これらの 2 つのトポロジもまた、相互に完全に接続されています。簡単のために、次の図には 2 つのデータセンター間のすべてのレプリケーションアグリーメントは示されていません。

このシナリオでのレプリケーション戦略には、次の内容が含まれます。

図 11–1 2 つのデータセンターでの負荷分散のためのマルチマスターレプリケーションの使用

図は、2 つのデータセンター (各データセンター内に 4 つのマスター) にわたるマルチマスターレプリケーションを示しています。

グローバル配備での Directory Proxy Server の使用

グローバル企業では、集中管理データモデルのために、スケーラビリティーとパフォーマンスの問題が発生する場合があります。このような状況で Directory Proxy Server を使用すると、データを効率的に分散させ、検索要求や更新要求を適切に経路指定することができます。

グローバル企業のための分散戦略のサンプル

ここに示されているアーキテクチャーでは、大きな金融機関の本社がロンドンに存在します。この組織は、ロンドン、ニューヨーク、および香港にデータセンターを保有しています。現在、従業員が使用可能なデータの大部分は、ロンドンにある旧バージョンの RDBMS リポジトリに集中して格納されています。この金融機関のクライアントコミュニティーからのこのデータへのすべてのアクセスが WAN を介して行われます。

この組織は、この集中管理モデルでスケーラビリティーとパフォーマンスの問題を経験しており、分散データモデルに移行することに決定しました。この組織はまた、同時に LDAP ディレクトリインフラストラクチャーも配備することに決定しました。問題のデータは「ミッションクリティカル」であると見なされるため、可用性の高い、フォールトトレラントなインフラストラクチャーに配備する必要があります。

クライアントアプリケーションのプロファイル分析によって、データが顧客ベースのものであることがわかりました。そのため、地域のクライアントコミュニティーによってアクセスされるデータの 95 パーセントは、そのコミュニティーに固有のデータです。アジアのクライアントが北米の顧客のデータにアクセスすることもありますが、この状況はまれにしか発生しません。また、クライアントコミュニティーはときどき、顧客情報の更新も行う必要があります。

次の図は、分散ソリューションの論理的なアーキテクチャーを示しています。

図 11–2 分散したディレクトリインフラストラクチャー

Directory Proxy Server を使用した分散アーキテクチャー

95 パーセントがローカルデータへのアクセスであるというプロファイル結果から、この組織は、ディレクトリインフラストラクチャーを地理的に分散することに決定しました。香港、ニューヨーク、およびロンドンのそれぞれに、複数のディレクトリコンシューマが配備されます。簡単のために、この図にはロンドンのコンシューマは示されていません。これらの各コンシューマは、各地域固有の顧客データを保持するように設定されます。ヨーロッパと中近東の顧客のデータは、ロンドンのコンシューマに保持されます。北アメリカと南アメリカの顧客データは、ニューヨークのコンシューマに保持されます。アジアと環太平洋地域の顧客のデータは、香港のコンシューマに保持されます。

この配備では、コミュニティーのデータ要求のほとんどがローカルのコミュニティーに対するものです。そのため、集中管理モデルを大幅に上回るパフォーマンスが実現されます。クライアント要求がローカルに処理されるため、ネットワークのオーバーヘッドが軽減されます。ローカルのディレクトリサーバーがディレクトリインフラストラクチャーを効率的に区分化するため、ディレクトリサーバーのパフォーマンスとスケーラビリティーが向上します。コンシューマディレクトリサーバーの各セットは、クライアントが更新要求を送信した場合はリフェラルを返すように設定されます。また、クライアントが、どこか別の場所に格納されているデータに対する検索要求を送信した場合にもリフェラルが返されます。

クライアントの LDAP 要求は、ハードウェアロードバランサを介して Directory Proxy Server に送信されます。このハードウェアロードバランサによって、クライアントが常に、少なくとも 1 つの Directory Proxy Server にアクセスできることが保証されます。ローカルに配備された Directory Proxy Server は最初に、すべての要求を、ローカルの顧客データを保持するローカルのディレクトリサーバーの配列に経路指定します。Directory Proxy Server のインスタンスは、ディレクトリサーバーの配列全体にわたって負荷分散するように設定されます。この負荷分散によって、自動フェイルオーバーおよびフェイルバックが実現されます。

ローカルの顧客情報に対するクライアントの検索要求は、ローカルディレクトリによって満足されます。Directory Proxy Server を介して、クライアントに適切な応答が返されます。地理的に「外部にある」顧客情報に対するクライアントの検索要求は、最初に、Directory Proxy Server にリフェラルを戻すことによって、ローカルのディレクトリサーバーによって満足されます。

このリフェラルには、地理的に分散した対応する Directory Proxy Server インスタンスをポイントする LDAP URL が含まれています。ローカルの Directory Proxy Server は、このリフェラルを、ローカルクライアントの代わりに処理します。ローカルの Directory Proxy Server は次に、この検索要求を Directory Proxy Server の対応する分散インスタンスに送信します。分散した Directory Proxy Server は、この検索要求を分散した Directory Server に転送し、適切な応答を受信します。次に、この応答が、Directory Proxy Server の分散インスタンスとローカルインスタンスを介してローカルクライアントに返されます。

ローカルの Directory Proxy Server が受け取った更新要求に対して、最初に、ローカルの Directory Server がリフェラルを返します。Directory Proxy Server は、このリフェラルを、ローカルクライアントの代わりに処理します。ただし、この場合、プロキシはこの更新要求をロンドンに配置されているサプライヤディレクトリサーバーに転送します。サプライヤ Directory Server は、この更新をサプライヤデータベース適用し、その応答をローカルの Directory Proxy Server を介してローカルクライアントに戻します。その後、サプライヤ Directory Server は、この更新を適切なコンシューマ Directory Server に伝えます。

第 12 章 高可用性配備の設計

高可用性とは、ディレクトリサービスに関して同意された最小の「稼働時間」とパフォーマンスのレベルを示しています。同意されたサービスレベルは、組織ごとに異なります。サービスレベルは、システムがアクセスされる 1 日の中の時間帯、システムを保守のために停止できるかどうか、組織にとっての停止時間のコストなどの要因によって異なる可能性があります。ここでは、ディレクトリサービスがこの最小レベルのサービスを提供できなくなるあらゆる要因を障害と定義します。

この章で説明する内容は次のとおりです。

可用性とシングルポイント障害

高可用性を提供する Directory Server Enterprise Edition 配備は、障害からすばやく回復できます。高可用性配備では、コンポーネント障害が個別のディレクトリクエリーに影響する可能性はありますが、完全なシステム障害には陥りません。シングルポイント障害 (SPOF) のシングルポイントとは、システム内でそのコンポーネントに障害が発生すると、システム全体が使用不可になるか、または信頼できなくなってしまうようなコンポーネントを意味します。高可用性配備を設計する場合は、潜在的な SPOF を識別し、どのようにしたらこれらの SPOF を軽減できるかを調査します。

SPOF は、次の 3 つのカテゴリに分類できます。

SPOF の軽減

「冗長性」を使用することにより、単一コンポーネントの障害によってディレクトリサービス全体が障害に陥ることのないように保証できます。冗長性には、冗長性のあるソフトウェアコンポーネント、ハードウェアコンポーネント、またはその両方の提供が含まれます。この例には、個別のホストへの Directory Server の複数のレプリケートされたインスタンスの配備や、Directory Server データベースのストレージでの RAID (Redundant Arrays of Independent Disks) の使用などがあります。レプリケートされた Directory Server による冗長性は、高可用性を実現するためのもっとも効率的な方法です。

また、クラスタリングを使用して高可用性サービスを提供することもできます。クラスタリングには、パッケージ化済みの高可用性ハードウェアおよびソフトウェアの提供が含まれます。この例として、Sun Cluster ハードウェアおよびソフトウェアの配備があります。

冗長性とクラスタリングのどちらを使用するかの決定

この章の残りでは、高可用性を確保するための冗長性とクラスタリングの使用についてさらに詳細に説明します。この節では、各ソリューションの利点と欠点の概要について説明します。

冗長性の利点と欠点

高可用性ディレクトリサービスを提供するためのより一般的なアプローチは、冗長性のあるサーバーコンポーネントとレプリケーションの使用です。冗長ソリューションは通常、クラスタリングソリューションより安価であり、実装もより簡単です。また、これらのソリューションは一般に、管理も容易です。冗長ソリューションの一部としてのレプリケーションには、可用性以外にも多くの機能があることに注意してください。レプリケーションの主な利点は読み取り負荷を複数のサーバーにわたって分割できることですが、サーバー管理の点から見ると、この利点のためにオーバーヘッドが増えます。レプリケーションではまた、読み取り操作に関するスケーラビリティーと、正しく設計されている場合は、一定の制限内で書き込み操作に関するスケーラビリティーも提供されます。レプリケーションの概念の概要については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 4 章「Directory Server Replication」を参照してください。

障害の間に冗長システムが提供する可用性は、クラスタリングソリューションより劣る可能性があります。たとえば、負荷が 2 つの冗長性のあるサーバーコンポーネント間で共有されている環境を考えてみます。1 つのサーバーコンポーネントの障害によってもう一方のサーバーに過剰な負荷がかかり、それによって、クライアント要求へのこのサーバーの応答が遅くなることがあります。応答の遅さは、すばやい応答時間に依存しているクライアントには障害と見られる場合があります。つまり、サービスの可用性が (そのサービスが運用に入っているにもかかわらず)、クライアントの可用性の要件を満足しない可能性があります。

クラスタリングの利点と欠点

クラスタ化されたソリューションの主な利点は、障害からの自動復旧、つまりユーザーの介入を必要としない復旧です。クラスタリングの欠点は、複雑さと、データベース破壊からは回復できない点です。

クラスタ化された環境では、どのクラスタノードが実際にサービスを実行しているかには関係なく、クラスタは Directory Server と Directory Proxy Server に同じ IP アドレスを使用します。つまり、IP アドレスは、クライアントアプリケーションには影響がありません。レプリケートされた環境では、トポロジ内の各マシンに独自の IP アドレスが割り当てられます。この場合は、Directory Proxy Server を使用して、ディレクトリトポロジへのシングルポイントアクセスを提供できます。したがって、レプリケーショントポロジは、クライアントアプリケーションからは実質的に隠されます。この透過性を向上させるために、Directory Proxy Server を、リフェラルと検索参照を自動的に処理するように設定できます。Directory Proxy Server ではまた、負荷分散や、1 台に障害が発生した場合に別のマシンに切り替える機能も提供されます。

冗長性とクラスタリングでの SPOF の処理方法

この章の最初に説明した SPOF の点から見ると、冗長性とクラスタリングは、障害を次の方法で処理します。

ハードウェアレベルでの冗長性

ここでは、ハードウェア冗長性に関する基本的な情報について説明します。多くの刊行物が、高可用性を実現するためのハードウェア冗長性の使用に関する包括的な情報を提供しています。特に、John Wiley & Sons, Inc. によって発行された『Blueprints for High Availability』を参照してください。

ハードウェア SPOF は、次のように広範囲に分類できます。

ネットワークレベルでの障害は、冗長性のあるネットワークコンポーネントを配置することによって軽減できます。配備を設計する場合は、次の冗長性のあるコンポーネントを配置することを検討してください。

冗長性のあるロードバランサをアーキテクチャーに追加することによって、SPOF としてのロードバランサを軽減できます。

データベース破壊の発生については、可用性を確保するためのデータベースフェイルオーバー手法を確立するようにしてください。冗長性のあるサーバーコントローラを使用することにより、ストレージサブシステム内の SPOF を軽減できます。また、コントローラとストレージサブシステムの間の冗長性のある配線、冗長性のあるストレージサブシステムコントローラ、または RAID を使用することもできます。

電源装置が 1 つしかない場合は、この電源がなくなるとサービス全体が使用不可になる可能性があります。この状況を回避するには、ハードウェアへの冗長電源装置の供給 (可能な場合) や、電源の分散化を考慮してください。電源装置内の SPOF を軽減するためのその他の方法には、サージプロテクタ、複数の電源供給元、およびローカルバッテリバックアップの使用や、ローカルでの電源の生成などがあります。

データセンター全体の障害は、たとえば、自然災害が特定の地域を襲った場合に発生します。この場合は、適切に設計された複数データセンターレプリケーショントポロジにより、分散ディレクトリサービス全体が使用不可になることを回避できます。詳細については、「高可用性を実現するためのレプリケーションと冗長性の使用」を参照してください。

ソフトウェアレベルでの冗長性

Directory Server または Directory Proxy Server の障害には、次のものが含まれる可能性があります。

これらの SPOF は、Directory Server と Directory Proxy Server の冗長性のあるインスタンスを配置することによって軽減できます。ソフトウェアレベルでの冗長性には、レプリケーションの使用が含まれます。レプリケーションによって、冗長性のあるサーバーの同期が維持されること、および要求を停止時間なく再経路指定できることが保証されます。詳細については、「高可用性を実現するためのレプリケーションと冗長性の使用」を参照してください。

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

レプリケーションを使用すると、1 つのサーバーの停止により、ディレクトリサービスが使用不可になることを回避できます。信頼できるレプリケーショントポロジを構築することで、サーバー障害が発生した場合でも、データセンターにアクセスするすべてのクライアントは最新のデータに確実にアクセスできます。最低でも、ローカルのディレクトリツリーは、少なくとも 1 つのバックアップサーバーにレプリケートする必要があります。ディレクトリの設計者の中には、データの信頼性を最大限保証するために物理的な場所ごとに 3 回はレプリケートしておく必要があると言う人もいます。フォールトトレランスのためにレプリケーションをどれだけ使用するかを決定する場合は、ディレクトリで使用されているハードウェアとネットワークの品質を考慮してください。信頼性の低いハードウェアでは、より多くのバックアップサーバーが必要になります。

通常のデータバックアップポリシー代わりにレプリケーションを使用しないでください。ディレクトリデータのバックアップについては、「バックアップと復元のポリシーの設計」および『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の第 8 章「Directory Server のバックアップと復元」を参照してください。

LDAP クライアントアプリケーションは通常、1 つの LDAP サーバーだけを検索するように設定します。異なる DNS ホスト名に配置されている LDAP サーバーを循環するように、カスタムクライアントアプリケーションを作成することができます。それ以外の場合、LDAP クライアントアプリケーションは、Directory Server の単一の DNS ホスト名を検索するようにしか設定できません。バックアップ用の Directory Server へのフェイルオーバーを実現するには、Directory Proxy Server、DNS ラウンドロビン、またはネットワークソートを使用できます。DNS ラウンドロビンまたはネットワークソートの設定と使用については、DNS のマニュアルを参照してください。このコンテキストで Directory Proxy Server がどのように使用されるかについては、「冗長ソリューションの一部としての Directory Proxy Server の使用」を参照してください。

ディレクトリ内のデータを読み取る機能を維持するには、適切な負荷分散戦略を配備する必要があります。読み取りの負荷を複数のレプリカに分散するには、ソフトウェアとハードウェアの両方の負荷分散ソリューションを利用できます。また、これらの各ソリューションは、各レプリカの状態を判定し、それらの負荷分散トポロジへの参加を管理することもできます。これらのソリューションは、総合性や精度の点ではそれぞれ異なっている可能性があります。

地理的に離れた場所にまたがって書き込みフェイルオーバーを維持するには、WAN を介した複数データセンターレプリケーションを使用します。それには、各データセンターに少なくとも 2 つのマスターサーバーを設定し、WAN を介して完全にメッシュ化されるようにそれらのサーバーを設定することが必要です。この戦略によって、トポロジ内のどのマスターに障害が発生してもサービスが失われることはありません。書き込み可能なサーバーが使用不可になった場合は、書き込み操作を代替のサーバーに経路指定する必要があります。書き込み操作の経路を再指定するには、Directory Proxy Server を使用するなど、さまざまな方法があります。

以降の節では、高可用性を確保するためにレプリケーションと冗長性がどのように使用されるかについて説明します。

冗長性のあるレプリケーションアグリーメントの使用

冗長レプリケーションアグリーメントを使用すると、障害発生時の迅速な復旧が可能になります。レプリケーションアグリーメントを有効にしたり無効にしたりできるということは、元のレプリケーショントポロジに障害が発生した場合にのみ使用されるレプリケーションアグリーメントを設定できることを意味します。有効/無効の切り替えは手動で行う必要がありますが、この方法は、レプリケーションアグリーメントが必要になった時点ではじめて設定する場合に比べて、費やす時間がはるかに短くて済みます。冗長レプリケーションアグリーメントの使用は、「高可用性を実現するために冗長性を使用したサンプルのトポロジ」で図を使用して説明されています。

レプリカの昇格と降格

レプリカの昇格または降格によって、レプリケーショントポロジでのそのロールが変更されます。専用のコンシューマとハブを含む非常に大規模なトポロジでは、レプリカのオンライン昇格および降格によって、高可用性戦略の一部が形成される場合があります。たとえば、負荷分散とフェイルオーバーのために 2 つのハブが設定されたマルチマスターのレプリケーション環境を例に考えてみます。1 つのマスターがオフラインになった場合は、読み取り/書き込みの最適な可用性を維持するために、いずれかのハブをマスターに昇格できます。マスターレプリカがオンラインに復帰したときは、ハブレプリカに降格させるだけで元のトポロジを回復できます。

詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「レプリカの昇格と降格」を参照してください。

冗長ソリューションの一部としての Directory Proxy Server の使用

Directory Proxy Server は、高可用性ディレクトリ配備をサポートするように設計されています。このプロキシによって、レプリケートされた一連の Directory Server 間での自動負荷分散や、自動フェイルオーバーおよびフェイルバックが実現されます。トポロジ内の 1 つ以上の Directory Server が使用不可になった場合は、その負荷が残りのサーバー間で比例的に再分散されます。

Directory Proxy Server は、Directory Server をアクティブに監視して、これらのサーバーが常にオンラインになっていることを保証します。このプロキシはまた、実行されている各操作の状態も検査します。すべてのサーバーが、スループットやパフォーマンスの点で同等であるとはかぎりません。主サーバーが使用不可になった場合、副サーバーに一時的にリダイレクトされたトラフィックは、主サーバーが使用可能になるとすぐにふたたび主サーバーに送信されるようになります。

データを分散する場合は、切り離された複数のレプリケーショントポロジを管理する必要があり、それによって管理が複雑になることに注意してください。さらに、Directory Proxy Server は、ユーザー承認の管理をプロキシ認証制御に大きく依存しています。この分散に関与している各 Directory Server で、特定の管理ユーザーを作成する必要があります。これらの管理ユーザーには、プロキシアクセス制御の権限を許可する必要があります。

アプリケーション分離による高可用性の実現

Directory Proxy Server を使用すると、レプリケートされたディレクトリサービスを問題のあるクライアントアプリケーションによる障害から保護することもできます。可用性を向上させるために、各アプリケーションには、マスターまたはレプリカのセットをいくつか限定して割り当てられます。

問題のあるアプリケーションが特定のアクションを実行して、サーバーの停止を引き起したとします。そのアプリケーションが各レプリカに次々とフェイルオーバーした場合に、1 つのアプリケーションでの単一の問題によって、レプリケートされるトポロジ全体が障害に陥る可能性があります。このような状況を回避するために、各アプリケーションのフェイルオーバーや負荷分散を、制限された数のレプリカに限定することができます。起こりうる障害の影響範囲が割り当てられたレプリカのセットにのみ限定されるため、ほかのアプリケーションへの障害の影響は軽減されます。

高可用性を実現するために冗長性を使用したサンプルのトポロジ

次のサンプルトポロジは、障害が発生した場合も継続的なサービスを提供するために冗長性をどのように使用するかを示しています。

1 つのデータセンターでの可用性向上のためのレプリケーションの使用

次の図に示されているデータセンターには、3 つのマスターを含むマルチマスタートポロジが存在します。このシナリオの場合、3 番目のマスターは、障害が発生した場合の可用性のためにのみ使用されます。読み取りおよび書き込み操作は、問題が発生しないかぎり、Directory Proxy Server によってマスター 1 とマスター 2 に経路指定されます。復旧を高速化し、レプリケーションアグリーメントの数を最小限に抑えるために、復旧レプリケーションアグリーメントが作成されています。これらのアグリーメントは、デフォルトでは無効になっていますが、障害が発生した場合にはすぐに有効にできます。

図 12–1 1 つのデータセンターでのマルチマスターレプリケーション

図は、3 つのマスター Directory Server と 1 つの Directory Proxy Server を含む 1 つのデータセンターを示しています。

1 つのデータセンターの障害マトリックス

図 12–1 に示されているシナリオでは、さまざまなコンポーネントが使用不可になる可能性があります。これらの可能性のある障害の場所と、それに対応する復旧のアクションを次の表に示します。

表 12–1 1 つのデータセンターの障害マトリックス

障害が発生したコンポーネント 

アクション 

マスター 1 

読み取りおよび書き込み操作は、マスター 1 が修復されている間、Directory Proxy Server を介してマスター 2 とマスター 3 に再経路指定されます。マスター 3 への更新がマスター 2 にレプリケートされるように、マスター 2 とマスター 3 の間の復旧レプリケーションアグリーメントが有効になります。 

マスター 2 

読み取りおよび書き込み操作は、マスター 2 が修復されている間、マスター 1 とマスター 3 に再経路指定されます。マスター 3 への更新がマスター 1 にレプリケートされるように、マスター 1 とマスター 3 の間の復旧レプリケーションアグリーメントが有効になります。 

マスター 3 

マスター 3 はバックアップサーバーでしかないため、このマスターに障害が発生しても、ディレクトリサービスは影響を受けません。サービスを中断することなく、マスター 3 をオフラインにしたり、修復したりできます。 

Directory Proxy Server 

Directory Proxy Server の障害は、重大なサービス中断を引き起します。このトポロジでは、Directory Proxy Server の冗長性のあるインスタンスを作成することをお勧めします。このようなトポロジの例については、「複数の Directory Proxy Server の使用」を参照してください。

1 つのデータセンターでの復旧手順

1 つのデータセンターに 3 つのマスターが含まれている場合は、1 つのマスターに障害が発生しても、読み取りおよび書き込み機能が維持されます。ここでは、障害が発生したコンポーネントの復旧に適用できる復旧戦略の例について説明します。

次のフローチャートと手順では、マスター 1 という 1 つのコンポーネントに障害が発生したと仮定しています。2 つのマスターに同時に障害が発生した場合は、その問題を修正している間、読み取りおよび書き込み操作を残りのマスターに経路指定する必要があります。

図 12–2 1 つのデータセンターでのサンプルの復旧手順

1 つのコンポーネントに障害が発生した場合の復旧手順を示すフローチャート

Procedure1 つのコンポーネントの障害から回復するには

  1. マスター 1 がまだ停止されていない場合は、停止します。

  2. 障害の原因を特定します。

    • 障害が容易に (たとえば、ネットワークケーブルの置き換えなどにより) 修復される場合は、修復を行い、手順 3 に進みます。

    • より重大な問題の場合は、障害の修正にさらに多くの時間がかかる可能性があります。

    1. マスター 1 にアクセスするすべてのアプリケーションが、Directory Proxy Server を介して、マスター 2 またはマスター 3 をポイントするようにリダイレクトされる必要があります。

    2. 最新のバックアップが使用できることを確認します。

      • 最新のバックアップが使用できる場合は、そのバックアップからマスター 1 を再初期化し、手順 3 に進みます。

      • 最新のバックアップが使用「できない」場合は、次のいずれかの操作を行います

  3. マスター 1 がまだ起動されていない場合は、起動します。

  4. マスター 1 が読み取り専用モードになっている場合は、読み取り/書き込みモードに設定します。

  5. レプリケーションが正しく機能していることを確認します。

    レプリケーションの確認には、DSCC の dsccmon view-suffixes または insync コマンドを使用できます。

    詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「レプリケーションの状態の取得」、dsccmon(1M)、および insync(1) を参照してください。

2 つのデータセンターにわたる可用性向上のためのレプリケーションの使用

一般に、2 つのデータセンターを含む配備では、1 つのデータセンターについて説明したのと同じ復旧戦略を適用できます。1 つ以上のマスターが使用不可になった場合は、Directory Proxy Server が、ローカルの読み取りおよび書き込みを残りのマスターに自動的に再経路指定します。

先に説明した 1 つのデータセンターのシナリオの場合と同様に、復旧レプリケーションアグリーメントを有効にすることができます。これらのアグリーメントによって、障害が発生した場合も、レプリケートされた更新を両方のデータセンターが引き続き受信できることが保証されます。この復旧戦略は、図 12–3 に示されています。

復旧レプリケーションアグリーメントを使用する代わりに、すべてのマスターが変更をほかのすべてのマスターにレプリケートする、完全にメッシュ化されたトポロジを使用する方法があります。レプリケーションアグリーメントは少ない方が管理しやすくなる可能性はありますが、完全にメッシュ化されたトポロジは使用しない方がよいという技術的な理由は何もありません。

このシナリオでの唯一の SPOF は、各データセンター内の Directory Proxy Server になります。図 12–4 に示すように、この問題を解消するために、冗長性のある Directory Proxy Server を配備することができます。

図 12–3 2 つのデータセンターのための復旧レプリケーションアグリーメント

冗長性のある復旧レプリケーションアグリーメントを示す 2 つのデータセンター内のマルチマスターレプリケーショントポロジ

復旧戦略は、どのような組み合わせでコンポーネントに障害が発生するかによって異なります。しかし、複数の障害に対する基本的な戦略を準備しておけば、その他のコンポーネントに障害が発生した場合にもそれを適用できます。

図 12–3 に示されているサンプルトポロジでは、ニューヨークのデータセンター内のマスター 1 とマスター 3 に障害が発生したと仮定しています。

このシナリオでは、Directory Proxy Server が、ニューヨークのデータセンター内の読み取りおよび書き込みをマスター 2 とマスター 4 に自動的に再経路指定します。これにより、ニューヨークのサイトのローカルの読み取りおよび書き込み機能が維持されることが保証されます。

複数の Directory Proxy Server の使用

次の図に示されている配備には、内部の LDAP サービスへの外部からのアクセスを拒否する企業ファイアウォールが含まれています。内部で開始されたクライアントの LDAP 要求は、ネットワークロードバランサを経由して Directory Proxy Server に転送されるため、IP レベルでの高可用性が確保されます。Directory Proxy Server を実行しているホストを除き、Directory Server への直接アクセスは阻止されます。プロキシが SPOF になるのを回避するために、2 つの Directory Proxy Server が配備されています。

完全にメッシュ化されたマルチマスタートポロジによって、ほかのどのマスターに障害が発生した場合でも、常にすべてのマスターを使用できることが保証されます。簡単のために、この図にはすべてのレプリケーションアグリーメントは示されていません。

図 12–4 ファイアウォール内での高可用性設定

4 つの Directory Server レプリカと 2 つの Directory Proxy Server を含む高可用性アーキテクチャー

アプリケーション分離の使用

次の図に示されているシナリオでは、アプリケーション 1 のバグによって Directory Server に障害が発生しています。このプロキシ設定によって、アプリケーション 1 からの LDAP 要求がマスター 1 とマスター 3 にしか送信されないことが保証されます。このバグが発生すると、マスター 1 とマスター 3 に障害が発生します。ただし、アプリケーション 2、3、および 4 は、機能している Directory Server に引き続きアクセスできるため無効になりません。

図 12–5 拡張配備でのアプリケーション分離の使用

図は、Directory Proxy Server がクライアントアプリケーションに基づいて要求を分散しているようすを示しています。

高可用性を実現するためのクラスタリングの使用

物理的な観点から見ると、クラスタは、1 つのエンティティーとして連携して動作する 1 〜 8 個のサーバーで構成されます。これらのサーバーは、アプリケーション、システムリソース、およびデータへの高可用性アクセスを提供するために連携して動作します。各サーバーを、複数の CPU を備えた対称型マルチプロセッサにすることができます。

クラスタリングソリューションは、次のコンポーネントに対して高可用性を提供できます。

クラスタリングによって、ディレクトリアーキテクチャー内のすべての SPOF が軽減されるわけではありません。外部ネットワーク、電源生成、およびデータセンターでの障害は、クラスタリングソリューション以外の手法で軽減するようにしてください。

現在、Directory Server でサポートされている唯一のクラスタリングテクノロジは Sun Cluster 3.1 です。ディレクトリサービスの可用性向上のために Sun Cluster 3.1 を使用するには、Sun Cluster HA for Directory Server データサービスをフェイルオーバーデータサービスとしてインストールおよび設定する必要があります。この戦略を使用すると、Sun Cluster 3.1 環境で Directory Server を安全にフェイルオーバーさせることができます。

次の図は、Sun Cluster 3.1 アーキテクチャー内の Sun Cluster HA for Directory Server データサービスの位置付けを示しています。

図 12–6 Sun Cluster 3.1 アーキテクチャー

図は、Sun Cluster 3.1 アーキテクチャーを使用した高可用性配備を示しています。

ハードウェア冗長性

Sun Cluster ハードウェアシステムのアーキテクチャーは、SPOF によってクラスタが使用不可にならないように設計されています。冗長性のある高速インターコネクト、ストレージシステム接続、およびパブリックネットワークによって、クラスタ接続に単一障害が発生しないことが保証されます。

クライアントは、パブリックネットワークインタフェースを介してクラスタに接続します。ネットワークアダプタカードに複数のハードウェアインタフェースがある場合、そのカードは 1 つ以上のパブリックネットワークに接続できます。複数のネットワークインタフェースカードを含むようにノードを設定できます。これらのカードは、1 枚のカードがアクティブであり、もう 1 枚のカードがバックアップとして機能するように設定されます。

クラスタファイルシステムは、1 つ以上のノード上のカーネルと、配下のファイルシステムおよびボリュームマネージャーの間のプロキシです。クラスタファイルシステムは、ディスクへの物理的な接続が存在するノード上で実行されます。クラスタファイルシステムの可用性を向上させるには、ディスクを複数のノードに接続してください。ローカルファイルシステムで構成したクラスタファイルシステムの可用性は高くありません。ローカルファイルシステムとは、ノードのローカルディスクに格納されているファイルシステムを指します。

ボリュームマネージャーによって、多重ホストディスクのデータ冗長性を向上させるためのミラー化構成または RAID 5 構成が可能になります。多重ホストディスクをディスクのミラー化およびストライプ化と組み合わせることにより、ノード障害と個別のディスク障害の両方から保護できます。

クラスタインターコネクトは、クラスタノード間のクラスタプライベート通信やデータサービス通信を転送するプライベートネットワークです。冗長性のある NIC、接続中継点、およびケーブルによって、ネットワーク障害から保護されます。

クラスタ化されたソリューションでの監視

クラスタでは、すべてのメンバーが継続的に監視されます。障害の発生したノードがクラスタに参加しないようにブロックされるため、破壊されたデータの交換が回避されます。また、クラスタはアプリケーションも監視し、障害が発生した場合は、そのアプリケーションをフェイルオーバーまたは再起動します。

Sun Cluster ソフトウェアのサブシステムである Public Network Management は、アクティブなインタフェースを監視します。アクティブなアダプタに障害が発生した場合は、そのインタフェースをいずれかのバックアップアダプタにフェイルオーバーするために Network Adapter Failover ソフトウェアが呼び出されます。

Cluster Membership Monitor (CMM) は、クラスタメンバーまたはノードごとに 1 セットが割り当てられた、エージェントの分散されたセットです。これらのエージェントは、クラスタインターコネクトを介してメッセージを交換することにより、すべてのノード間の完全な接続を保証します。CMM がノード障害などによるクラスタメンバーシップの変更を検出した場合は、CMM によってクラスタが再構成されます。CMM がノードに関する重大な問題を検出した場合、CMM はクラスタフレームワークに連絡します。次に、クラスタフレームワークがそのノードを強制的に停止し、クラスタメンバーシップからそのノードを削除します。

システム保守

保守が必要なデータやアプリケーションを現在のコンポーネントからシステム上の別のコンポーネントに移動することによって、システム保守の計画的な停止時間を最小限に抑えることができます。保守が完了したら、そのデータやアプリケーションを元のコンポーネントに戻すことができます。

Directory Server Failover Data Service

Directory Server Failover Data Service は、クラスタ内の 1 つのノード上で実行されます。ただし、ノードには、スケーラビリティー向上のために複数の CPU を実装できます。障害モニターが、このフェイルオーバーサービスを定期的に監視します。

Resource Group Manager (RGM) は、データサービスをリソースとして管理します。CMM がクラスタのメンバーシップを変更した場合は、RGM がそのクラスタのオンラインまたはオフラインリソースへの変更を要求する可能性があります。RGM は、フェイルオーバーデータサービスを開始および停止します。

障害回復

以降の節では、Directory Server Data Service に障害が発生した場合や、サーバーに障害が発生した場合にサービスがどのように回復されるかについて説明します。

アプリケーション障害が発生した場合の復旧

障害モニターが Directory Server Data Service に障害が発生したと判定した場合、モニターはそのサービスを再開するためのアクションを開始します。実行されるアクションは、そのサービスの設定によって異なります。

フェイルオーバーデータサービスを、障害の発生したサービスの、同じノード上での再開を試みるように設定できます。あるいは、障害の発生したサービスを別のノード上でただちに開始するようにデータサービスを設定することもできます。データサービスが、同じノード上での再開を試みるように設定されている場合、障害モニターはローカルの RGM に連絡します。ローカルの RGM は次に、障害の発生したサービスの再開を試みます。このアクションに失敗すると、ローカルの RGM は、別のノード上でのサービスの開始を試みます。

障害の発生したデータサービスを同じノード上で再開できない場合、ローカルノードの RGM は、別のノードにあるサービスのバージョンの検索を試みます。このアクションは、そのデータサービスが、障害のあと別のノード上で開始するように設定されている場合にも実行されます。ローカルの RGM がそのサービスのバージョンを見つけると、ローカルの RGM はローカルの CMM に連絡して、クラスタインターコネクトを介してリモートノードに連絡するよう要求します。リモートの CMM は次に、そこのローカルの RGM に連絡して、サービスを開始するよう指示します。

次の図は、アプリケーション障害が発生した場合の復旧を示しています。

図 12–7 Sun Cluster 3.1 アーキテクチャーでのアプリケーション障害と復旧

図は、Sun Cluster 3.1 アーキテクチャーでのアプリケーション障害のあとの復旧を示しています。

サーバー障害が発生した場合の復旧

Directory Server Data Service が実行されているサーバーまたはノードに障害が発生した場合、サービスは機能している別のノードに移行されます。ユーザーの介入は必要ありません。このサービスは、フェイルオーバーリソースグループ、Directory Server インスタンスを定義しているコンテナ、およびフェイルオーバーの要件をサポートしているホストを使用します。

次の図は、サーバー障害が発生した場合の復旧を示しています。

図 12–8 Sun Cluster 3.1 アーキテクチャーでのサーバー障害と復旧

図は、Sun Cluster 3.1 アーキテクチャーでのサーバー障害のあとの復旧を示しています。