| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
前 |
次 |
クライアント・リクエストに応答するために複数のデータ・ソースを使用するデプロイメントでは、ワーク・ロードを分散するためにロード・バランシングが使用されます。クライアント・アフィニティを使用すると、ロード・バランシングされたデプロイメントでの伝播遅延のリスクを低減できます。
ロード・バランシングとクライアント・アフィニティの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第20章「Directory Proxy Serverのロード・バランシングおよびクライアント・アフィニティ」を参照してください。
Directory Proxy Serverがロード・バランシングとクライアント・アフィニティを実行する方法の詳細は、次の項を参照してください。
クライアントからのリクエストはLDAPデータ・ソース・プールに分散されます。データ・ソース・プールには1つ以上のデータ・ソースがアタッチされます。データ・ソース・プールのプロパティは、プールにアタッチされる様々なLDAPデータ・ソースにクライアント・リクエストがルーティングされる方法を決定します。LDAPデータ・ソース・プールには次のプロパティを構成できます。
client-affinity-policyクライアント・リクエストが単一のLDAPデータ・ソースにアフィニティを示すときを決定するために使用されるアルゴリズム
client-affinity-timeoutクライアント・アフィニティのタイムアウト時間
descriptionLDAPデータ・ソース・プールの説明
enable-client-affinity同じクライアントからの連続したリクエストを同じLDAPデータ・ソースに送るかどうかを示すフラグ
load-balancing-algorithmロード・バランシングされたLDAPデータ・ソースに対して操作を分散するために使用されるアルゴリズム
LDAPデータ・ソース・プールの作成および構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDAPデータ・ソース・プールの作成と構成に関する説明を参照してください。
複数のデータ・ソースがプールにアタッチされている場合、ロード・バランシングはプールのどのデータ・ソースがリクエストに応答するかを決定します。ロード・バランシングの詳細は次の項を参照してください。
Directory Proxy Serverはロード・バランシング・アルゴリズムに従ってリクエストを分散します。次のロード・バランシング・アルゴリズムを構成できます。
データ・ソースの重みおよびDirectory Proxy Serverが最後に起動されてからのデータ・ソースの累積負荷に従って、リクエストが分散されます。
データ・ソースの重みおよびデータ・ソースで使用可能な接続の数に従って、リクエストが分散されます。
ハッシュ値に従ってリクエストが分散されます。アタッチ済データ・ソースに割り当てられるハッシュ値の数は、そのデータ・ソースの重みに比例します。
その操作に対して重みが最大のアタッチ済データ・ソースのみに、リクエストが分散されます。
最小限必要な重みの合計になるよう、十分に重みが追加されたデータ・ソース・セットにリクエストが分散されます。
操作のタイプに応じて、レスポンス時間が最も短いアタッチ済データ・ソースにのみ、リクエストが分散されます。
最速サーバー・アルゴリズムを除くすべてのロード・バランシング・アルゴリズムで、アタッチ済の各データ・ソースを、次の各操作タイプに応じた個別の重みを付けて構成できます。
追加
バインド
比較
削除
DNの変更
変更
検索
複数のアタッチ済データ・ソースが、あるタイプの操作について同じ重みを付けて構成されている場合、リクエストはDirectory Proxy Serverによって各データ・ソースに均等に分散されます。特定タイプの操作に対してあるデータ・ソースの重みがdisabledの場合、そのタイプのリクエストがDirectory Proxy Serverによってそのデータ・ソースに分散されることはありません。データ・ソースの重みが0(ゼロ)の場合、リクエストはそのデータ・ソースに分散されません。
次の場合は、アタッチ済データ・ソースをロード・バランシング・アルゴリズムによって選択することはできません。
エラーが発生したためにデータ・ソースが使用不可である
Directory Proxy Serverとデータ・ソース間のすべての接続が使用中である
データ・ソースが読取り専用で構成されている場合、そのデータ・ソースは追加リクエスト、削除リクエストまたは変更リクエストを受け取ることができません。ただし、検索リクエストは受け取ることができます。
ロード・バランシング・アルゴリズムはベスト・エフォートを基準に機能します。ロード・バランシング・アルゴリズムが重みを考慮してリクエストを分散するための十分なリソースがない場合、重みは無効になります。たとえば、データ・ソースに対する同時リクエストの数がそのデータ・ソースの最大接続数を超えた場合、リクエストは他のデータ・ソースに分散されます。
クライアント・アフィニティ機能が有効な場合は、ロード・バランシング・アルゴリズムを使用するかわりにクライアント・アフィニティ機能を使用して、リクエストがDirectory Proxy Serverにより分散されます。クライアント・アフィニティの詳細は、「クライアント・アフィニティ」を参照してください。
比例アルゴリズムでは、次の基準に従ってアタッチ済データ・ソースにリクエストが分散されます。
リクエストのタイプ
プールの他のデータ・ソースの重みの合計の比率としてのデータ・ソースの重み
Directory Proxy Serverを最後に起動してからの累積負荷
その操作に対して重みが最大のアタッチ済データ・ソースのみに、リクエストが分散されます。リクエストはDirectory Proxy Serverにより、そのタイプのリクエストに対する各データ・ソースの重みに比例して引き続き分散されます。
あるデータ・ソースが使用不可になると、リクエストはDirectory Proxy Serverにより、残りのデータ・ソースにその重みに比例して分散されます。
次の図では、最初の8つの検索リクエストがDirectory Proxy Serverにより、異なる重みを持つデータ・ソースのプールに分散される方法を示します。重み2のデータ・ソースは、重み1のデータ・ソースの2倍のリクエストを処理します。
比例アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングの比例アルゴリズムの構成に関する説明を参照してください。
飽和アルゴリズムでは、データ・ソースの重みおよび使用可能な接続の数に従って、リクエストが分散されます。
特定タイプのすべてのリクエストは、重みが最大のデータ・ソースに、その飽和レベルに達するまで分散されます。このレベルに達すると、リクエストはこのデータ・ソースと重みが2番目のデータ・ソースに分散されます。飽和レベルは、データ・ソースの重みに接続数の合計を掛けて取得できます。
次の図では、Directory Proxy Serverにより、10の接続とそれぞれ異なる重みを持つデータ・ソースのプールにリクエストが分散される方法を示します。括弧内は使用可能な接続数に重みを掛けた結果です。
デプロイメントに大きく異なる容量のデータ・ソースが含まれている場合、飽和アルゴリズムを使用してデータ・ソースの容量に応じてリクエストを分散できます。
飽和アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングの飽和アルゴリズムの構成に関する説明を参照してください。
ロード・バランシングの操作アフィニティ・アルゴリズムでは、リクエストのタイプとリクエストのプロパティに従って、すべてのリクエストがハッシュ値に割り当てられます。各ハッシュ値はアタッチ済データ・ソースに割り当てられます。データ・ソースに割り当てられるハッシュ値の数は、そのデータ・ソースの重みに比例します。
リクエストが受信されると、ハッシュ表がDirectory Proxy Serverにより検査され、そのハッシュ値を持つリクエストがすでに分散されているかどうかを判別します。ハッシュ値がすでに存在している場合、リクエストはDirectory Proxy Serverによりそのハッシュ値を持つデータ・ソースに送信されます。ハッシュ値がハッシュ表に存在していない場合、リクエストはロード・バランシングの比例アルゴリズムを使用して分散されます。
図16-3は、アタッチ済データ・ソースが3つある事例です。データ・ソースAは検索操作に対して重み3を持ち、他の2つのデータ・ソースは検索操作に対して重み1を持っています。ハッシュ表は、ハッシュ値の3/5をデータ・ソースAに割り当て、1/5をデータ・ソースBに、1/5をデータ・ソースCに割当てます。
リクエストが正常な多様性範囲である場合、データ・ソースAはデータ・ソースBまたはデータ・ソースCの3倍のリクエストを受信することになります。同じプロパティを持つ不均衡な数のリクエストがある場合、3つのデータ・ソース間のリクエストの比率は崩れます。たとえば、クライアントが同じDNに対してバインド・リクエストを繰り返した場合、バインドは常に同じデータ・ソースによって処理される必要があります。
ロード・バランシングの操作アフィニティ・アルゴリズムの使用は、次の機能にとって有益です。
グローバル・アカウントのロックアウト
Directory Serverのキャッシュの最適化
ロード・バランシングの操作アフィニティ・アルゴリズムは、複数のデータ・ソース間でのワークロードの均等分散を保証するものではありません。
ハッシュ値はリクエストのタイプおよびリクエストのプロパティに従って、リクエストに割り当てられます。ハッシュ値の範囲は、関連のないリクエストの任意のグループを表します。あるハッシュ値の範囲が、別のハッシュ値の範囲よりもずっと多くの操作を表すこともあります。ある範囲のハッシュ値が頻繁に行われるリクエストを表し、別の範囲のハッシュ値がほとんど行われないリクエストを表す場合があります。
ロード・バランシングの操作アフィニティ・アルゴリズムを使用することにより、特定クライアントからのバインド・リクエストに対して同じデータ・ソースが常に応答するようにできます。このようにして、最大回数のバインド試行が失敗すると、クライアントがロックアウトされるようにできます。同じデータ・ソースが特定クライアントからのバインド・リクエストに応答しない場合、クライアントは最大回数を超えてバインド試行を行うことができます。
クライアントがバインドすると、そのリクエストのハッシュ値がバインド資格証明に従って割り当てられます。Directory Proxy Serverはハッシュ表を参照し、そのハッシュ値のデータ・ソースにリクエストを分散します。クライアントのバインド回数にかかわらず、このハッシュ値は常に同じです。リクエストは常に同じデータ・ソースに分散されます。
クライアントが適切な資格証明のないバインド・リクエストを出した場合、データ・ソースはそのバインド・リクエストを拒否します。クライアントが2回目または3回目のバインド・リクエストを行った場合、同じデータ・ソースがバインド・リクエストを拒否します。クライアントが最大回数のバインド試行を超えると、そのクライアントはDirectory Serverによりロックアウトされます。
グローバル・アカウントのロックアウトに対する操作アフィニティ・アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のグローバル・アカウントのロックアウトに対する操作アフィニティ・アルゴリズムの構成に関する説明を参照してください。
ロード・バランシングの操作アフィニティ・アルゴリズムを使用することにより、同じクライアントから同じエントリへの検索を、常に同じデータ・ソースに分散できます。データ・ソースがリクエストに応答すると、ターゲット・エントリはキャッシュに格納されます。同じデータ・ソースが同じリクエストに繰り返し応答する場合、そのデータ・ソースはキャッシュ・データを使用できるという利点があります。
キャッシュの最適化に対する操作アフィニティ・アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のキャッシュの最適化に対する操作アフィニティ・アルゴリズムの構成に関する説明を参照してください。
フェイルオーバー・アルゴリズムでは、特定タイプのリクエストはその操作に対して重みが最大のアタッチ済データ・ソースにのみ分散されます。そのアタッチ済データ・ソースが失敗した場合、その操作に対して2番目の重みのアタッチ済データ・ソースにのみ、リクエストが分散されます。重みが最大のデータ・ソースが再びオンラインになると、リクエストはそのデータ・ソースに分散されます。
フェイルオーバー・アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングのフェイルオーバー・アルゴリズムの構成に関する説明を参照してください。
このアルゴリズムは、フェイルオーバー・アルゴリズムが使用されているときに起こりうる状況を救済するために作成されました。フェイルオーバー・アルゴリズムでは、同じ重みのデータ・ソースはグループを表します。リクエストは常に、重みが最大のグループにのみ送信されます。一般的なデプロイメントではローカル・グループ(すべてのデータ・ソースが同じ高い重みを共有する)およびリモート・グループ(すべてのデータ・ソースが同じ低い重みを共有する)が使用されます。リモート・データ・ソースは、ローカル・データ・ソースがダウンするか使用不可になるまで使用されません。フェイルオーバー・アルゴリズムを使用すると、ほとんどの場合にグループが最大限ロードされます。データ・ソースが使用できない場合、グループ全体のスループットが低下します。
適応フェイルオーバー・アルゴリズムは、最小限必要な重み合計を定義することにより、この状況を救済します。データ・ソースは2つのグループに分けられます。アクティブ・グループは、希望する最小限の重み合計に追加の重みが達するデータ・ソース・セットです。残りのすべてのデータ・ソースは、スタンバイ・グループに分類されます。
アクティブ・グループは、最小限の重み合計(各データ・ソースの重みの合計)に達するまで、重みが最大のn個のデータ・ソースを選択することにより、作成されます。アクティブ・グループの各データ・ソースは、その重みに比例してリクエストを取得します。スタンバイ・グループのデータ・ソースには、リクエストは送信されません。
データ・ソースが使用可能になったり使用不可になった場合、または重みが変更された場合、グループのメンバーは動的に再評価されます。
デフォルトの最小限の重み合計は100で、次のコマンドを使用して変更できます。
$ dpconf set-ldap-data-source-pool-prop -host host -p port pool-name \ minimum-total-weight:2
詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングの適応フェイルオーバー・アルゴリズムの構成に関する説明を参照してください。
最速サーバー・アルゴリズムでは、次の基準に従ってアタッチ済データ・ソースにリクエストが分散されます。
リクエストのタイプ
そのタイプのリクエストに対するレスポンス時間
リクエストを送信するためのサーバーを選択する必要があるときに、このアルゴリズムは最も短いレスポンス時間のサーバーをアタッチ済データ・ソースのリストから選択します。レスポンス時間は各データ・ソースおよび各操作タイプについて別々に測定されます。
サーバーのレスポンス時間は、実際は固定サイズのサンプルの値を意味します。最新のn回のレスポンス時間がこのサンプルに格納され、新しい測定が追加されるたびに(おそらく一番古い測定と置き換えられて)平均値が再計算されます。サンプル(最新のn回のレスポンス時間のセット)は、各サーバーの各操作タイプと関連付けられます。サンプルのサイズ(n)のデフォルト値は100ですが、次のコマンドを使用して構成できます。
$ dpconf set-ldap-data-source-pool-prop -host host -p port pool-name \ sample-size:300
サンプル・サイズが小さいほど、データ・ソースのレスポンス時間の変化に対するアルゴリズムの反応性が高くなります。ただし、サンプル・サイズが小さすぎると悪影響を及ぼす場合があります。同じクライアントからの操作が異なるデータ・ソースに送信される場合があります。サイレント・バインド操作が必要となることがありますが、クライアント側から見るとこれにより、レスポンス時間が長くなります。
この方式の問題点は、最も短い平均レスポンス時間のサーバーが常に選択されることです。より長い平均レスポンス時間の他のサーバーは選択されないため、それらのサンプルおよび平均レスポンス時間は更新されません。そのため、平均レスポンス時間の長いサーバーが、実際には現在の最速サーバーよりも短いレスポンス時間を提供できるという状況が起こりえます。しかし、平均レスポンス時間が長いサーバーにはリクエストが送信されないため、その平均レスポンス時間は更新されず、そのサーバーがDirectory Proxy Serverの観点から最適の選択肢となることはありません。このため、システム全体のスループットが実際に可能であるよりも低くなる場合があるのです。
この状況を解決するために、2番目の属性が存在します。proportionプロパティは、いずれかのproportion操作が、最速サーバーに送信されるかわりにランダム選択されたサーバーに送信されることを示します。この値は次のコマンドを使用して構成できます。
$ dpconf set-ldap-data-source-pool-prop -host host -p port pool-name \ proportion:100
proportionのデフォルト値は100です。これは、99の操作が最速サーバーに送信され、1つの操作がランダム選択されたサーバーに送信されることを意味します。ランダム選択は一様分布に従います。すべてのアタッチ済データ・ソースは、最も短いレスポンス時間のものでも、考慮されます。このため、ランダム選択のサーバーが最速サーバーになることもあります。
proportionを0に設定するということは、常にレスポンス時間に基づいて選択を行う必要があることを意味します。
選択したサーバーへの接続がなんらかの理由で取得できない場合、他のサーバーがランダムに試行されます。
詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングの最速サーバー・アルゴリズムの構成に関する説明を参照してください。
クライアント・アフィニティは、クライアント接続とデータ・ソース間で定義されます。クライアント・アフィニティが定義されると、指定されたクライアント接続からのリクエストはデータ・ソース・プール内の指定されたデータ・ソースに分散されます。
クライアント・アフィニティ機能は、ロード・バランシングを使用するデプロイメントにおける伝播遅延のリスクを低減します。伝播遅延は、クライアントが同じエントリをターゲットとしたリクエストを連続して行ったとき、それらのリクエストが同じデータ・ソースにより処理されない場合に発生します。たとえば、クライアントがエントリを変更するあるリクエストを行い、変更されたエントリを使用する2番目のリクエストを行う場合があります。最初のリクエストにより更新されなかったデータ・ソースにより、2番目のリクエストが処理された場合、エラーが発生します。
クライアント・アフィニティは次の方法で構成できます。
有効化または無効化
最初の書込みリクエスト後のすべての書込みリクエストに対して構成
最初の書込みリクエスト後のすべてのリクエストに対して構成
最初の読取りリクエストまたは書込みリクエスト後のすべてのリクエストに対して構成
書込みリクエスト後の最初の読取りリクエストに対して構成
指定した時間後に期限切れになるように構成
クライアント・アフィニティはロード・バランシング・アルゴリズムよりも優先されます。Directory Proxy Serverは、ロード・バランシング・アルゴリズムにかかわらず、指定された接続からのリクエストを指定されたデータ・ソースへ分散します。
クライアント・アフィニティが定義され、有効化されている場合、次の状況下ではロード・バランシング・アルゴリズムの方が優先されます。
クライアント・アフィニティを開始するリクエストが発生していない
クライアント・アフィニティを終了するリクエストが発生した
クライアント・アフィニティのタイムアウトが期限切れになった
指定されたデータ・ソースがリクエストに対して使用できない、または指定されたデータ・ソースでエラーが発生した
次の場合、データ・ソースはリクエストに対して使用できません。
オフラインである。
リクエストされている操作を実行するように構成されていない。たとえば、読取りリクエストに対して構成されているデータ・ソースは、書込みリクエストに応答できません。
クライアント・アフィニティの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のクライアント・アフィニティの構成に関する説明を参照してください。
Directory Proxy Serverをシンプルな接続ベースのルーターとして構成するには、クライアント・アフィニティ機能を使用する必要があります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の接続ベースのルーターとしてのDirectory Proxy Serverの構成に関する説明を参照してください。
