test

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

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

負荷分散は、読み取り負荷を複数のサーバーに拡散させることによってパフォーマンスを高めます。負荷分散は、レプリケーション、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 つが無効になり、それに伴ってほかのメインサーバーの受け持つ負荷がかなり上昇すると、スタンバイサーバーに対して負荷の分散が行われます。