Dispatcher、CBR、および Site Selector のための Manager、Advisor、および Metric Server 機能

本章では、ロード・バランシング・パラメーターの構成方法、および Load Balancer の manager、advisor、および Metric Server 機能のセットアップ方法について説明します。

注:
本章を読むとき、Dispatcher コンポーネントを使用中では ない 場合は、"dscontrol" を以下によって置換してください。
表 10. Load Balancer の拡張構成タスク
タスク 説明 関連情報
オプションでロード・バランシングの設定値を変更する

以下のロード・バランシング設定値を変更することができます。

  • 状況情報に与えられる重要性の割合

    デフォルトの割合は 50-50-0-0 です。デフォルトを使用すると、advisor からの情報、Metric Server、および WLM の情報は使用されません。

  • 重み
  • manager 固定重み
  • manager 間隔
  • 重要度しきい値
  • 平滑化索引
Load Balancer で提供されるロード・バランシングの最適化
スクリプトを使用して、manager がサーバーにダウンまたはアップのマークを付けるときに アラートまたはレコード・サーバー障害を生成する Load Balancer は、manager がサーバーにダウンまたはアップのマークを付ける時点をカスタマイズできるスクリプトを起動するユーザー出口を提供します。 アラートまたはレコード・サーバー障害を生成するスクリプトの使用
advisor を使用する サーバーの特定の状況について報告する advisor を説明およびリストします。 Advisor
HTTP または HTTPS advisor の要求および応答 (URL) オプションを使用する マシンで照会したいサービスに固有の一意的なクライアント HTTP URL ストリングを定義します。 要求および応答 (URL) オプションによる HTTP または HTTPS advisor の構成
self advisor を使用する Load Balancer 2 層構成 WAN 構成におけるバックエンド・サーバー負荷状況を提供します。 2 層 WAN 構成内の self advisor の使用
カスタム advisor を作成する 独自のカスタム advisor の書き込み方法を説明します。 カスタム (カスタマイズ可能) advisor の作成
Metric Server エージェントを使用する Metric Server はシステム負荷情報 Load Balancer に提供します。 Metric Server
作業負荷管理機能 advisor (WLM) を使用する WLM advisor は、システム負荷情報を Load Balancer に提供します。 作業負荷管理機能 advisor

Load Balancer で提供されるロード・バランシングの最適化

Load Balancer の manager 機能は、以下の設定を基にしてロード・バランシングを実行します。

これらの設定を変更して、ネットワークのロード・バランシングを最適化することができます。

状況情報に与えられる重要性の割合

manager は、その重みの判断で、以下の外的要因の一部またはすべてを使用できます。

manager は、各サーバーごとの現行の重みと、その計算に必要なその他の何らかの情報とともに、executor から最初の 2 つの値 (活動中の接続および新規接続) を得ます。これらの値は、executor の内部で生成および保管された情報に基づいています。

注:
Site Selector の場合は、manager は Metric Server から最初の 2 つの値 (CPU およびメモリー) を得ます。

クラスター (またはサイト名) ごとの基準に基づいて 4 つの値の相対的な重要性の割合を変更できます。この割合をパーセントで考えると、相対的な割合の合計は 100% でなければなりません。 デフォルトの割合は 50/50/0/0 で、これは advisor およびシステム情報を無視しています。使用環境によっては、最良のパフォーマンスが得られる組み合わせを見つけるために、別の割合を試すことが必要な場合があります。

注:
(WLM 以外の) advisor を追加するときに、ポートの割合がゼロになっていると、manager はこの値を 1 に増加します。相対的な割合の合計は 100 でなければならないので、最大値は 1 だけ減らされます。

WLM advisor を追加するときに、システム・メトリックの割合がゼロになっていると、manager はこの値を 1 に増加します。相対的な割合の合計は 100 でなければならないので、最大値は 1 だけ減らされます。

活動状態の接続の数は、クライアントの数によって異なるだけでなく、ロード・バランシング対象のサーバー・マシンが提供するサービスを使用するために必要な時間の長さによっても異なります。クライアント接続が高速 (HTTP GET を使用して提供される小さな Web ページのように) であれば、活動状態の接続の数はかなり低くなります。クライアントの接続が低速 (データベース照会のように) であれば、活動状態の接続の数は高くなります。

活動中の接続と新規接続の割合を低く設定しすぎることは避ける必要があります。これらの最初の 2 つの値を少なくともそれぞれ 20 に設定しておかない限り、ロード・バランシングおよび平滑化は使用不可になります。

重要性の値の割合を設定するには、dscontrol cluster set cluster proportions コマンドを使用してください。詳しくは、dscontrol cluster — クラスターの構成を参照してください。

重み

重みは、executor の内部カウンター、advisor からのフィードバック、および Metric Server などのシステム・モニター・プログラムからのフィードバックに基づいて、manager 機能によって設定されます。manager の実行中に重みを手作業で設定したい場合は、fixedweight オプションを dscontrol サーバー・コマンドに指定してください。fixedweight オプションの説明については、manager 固定重み を参照してください。

重みは、サーバー上のすべてのポートに適用されます。特定ポートについて、要求は相互に相対的な重みに基づいてサーバー間で分散されます。例えば、一方のサーバーが重み 10 に設定され、他方が 5 に設定されると、10 に設定されたサーバーは 5 に設定されたサーバーの 2 倍の要求を得るはずです。

すべてのサーバーに指定できる最大の重み境界を指定するには、dscontrol port set port weightbound weight コマンドを入力してください。 このコマンドは、各サーバーが受け取る要求数の間で生じる差の大きさに影響します。 最大 weightbound を 1 に設定すると、すべてのサーバーが 1、停止ならば 0、あるいはマーク・ダウンならば -1 の重みを持つことができます。 この数を増加すると、サーバーに掛かる重みの差は増加します。最大 weightbound が 2 の 場合、1 つのサーバーが受ける要求の数は他の 2 倍になります。 最大 weightbound が 10 の場合、 1 つのサーバーが、他の 10 倍の要求を受けることができます。デフォルトでは、最大 weightbound は 20 です。

advisor は、サーバーが停止したことを検出すると manager に通知し、これを受けてサーバーの重みは 0 に設定されます。この結果として、executor は、重みが 0 のままである限り、追加の接続をそのサーバーに送信しません。重みが変更になる前に、そのサーバーに活動状態の接続があった場合は、そのまま正常に完了します。

すべてのサーバーがダウンしている場合は、マネージャーは重みを weightbound の半分に設定します。

manager 固定重み

manager がなければ、advisor は実行されず、サーバーがダウンしているかどうかを検出することができません。advisor を実行することを選択するが、特定のサーバー用に設定した重みを manager に更新させたく ない 場合には、dscontrol server コマンドで fixedweight オプションを使用します。例えば、以下のようになります。

dscontrol server set cluster:port:server fixedweight yes

fixedweight を yes に設定した後で、dscontrol server set weight コマンドを使用して、重みを所要の値に設定します。固定重みが no に設定された別の dscontrol server コマンドが発行されるまで、manager が実行されている間はサーバー重み値は固定されたままです。詳細については、dscontrol server — サーバーの構成 を参照してください。

ダウンしているサーバーへの TCP リセットの送信 (Dispatcher コンポーネントのみ)

TCP reset が活動化されている場合、Dispatcher は、重みが 0 であるサーバーにクライアントが接続されている場合に、そのクライアントに TCP reset を送信します。 サーバーの重みは、それが 0 に構成されている場合か、または advisor がダウンさせた場合に 0 になる可能性があります。 TCP リセットにより、接続は即時にクローズします。 この機能は、長時間存続する接続の場合に有用であり、失敗した接続を再折衝するためのクライアントの機能を促進します。 TCP リセットを活動化するには、dscontrol port add|set port reset yes コマンドを使用します。 reset のデフォルト値は no です。

注:
TCP リセットは、Dispatcher の転送方式すべてに適用されます。 ただし、TCP リセット機能を使用するには、clientgateway on the dscontrol executor コマンドがルーター・アドレスに設定されている必要があります。

TCP リセットとともに構成のために便利な機能は、advisor retry です。この機能によって、advisor は、サーバーにダウンのマークを付ける前に接続を再試行することができます。これは、advisor が早まってサーバーにダウンのマークを付けてしまい、 結果として接続リセット問題が起こるのを防止するのに役立ちます。 すなわち、advisor が最初の試行に失敗したからといって、既存の接続にも障害が起こっているということには必ずしもならないことを意味します。 詳しくは、advisor 再試行を参照してください。

manager 間隔

全体パフォーマンスを最適化するために、manager が executor と対話する頻度が制限されます。この間隔は、dscontrol manager interval および dscontrol manager refresh コマンドを入力することで変更できます。

manager 間隔は、executor が接続の経路指定の際に使用するサーバーの重みを更新する頻度を指定します。manager 間隔が短過ぎると、manager が絶えず executor に割り込むことになり、パフォーマンスの低下が生じることになります。manager 間隔が長過ぎる場合は、executor の要求経路指定が正確な最新情報に基づいていないことを意味します。

例えば、manager 間隔を 1 秒に設定するには、以下のコマンドを入力します。

 dscontrol manager interval 1

manager のリフレッシュ・サイクルは、manager が executor に状況情報を求める頻度を指定します。リフレッシュ・サイクルは、時間間隔に基づいています。

例えば、manager のリフレッシュ・サイクルを 3 に設定するには、以下のコマンドを入力します。

  dscontrol manager refresh 3

これで、manager は 3 間隔待ってから executor に状況を要求することになります。

重要度しきい値

他の方法を使用して、サーバーのロード・バランシングを最適化することができます。 最高速で働くために、サーバーの重みが大幅に変わった場合にだけそれが更新されます。サーバー状況にほとんど変更がないのに、絶えず重みを更新すると、無用なオーバーヘッドを生むことになります。 ポートのすべてのサーバーに対する重みの合計の変化の割合が重要度しきい値より大きい場合、manager は executor が使用する重みを更新して、接続を分散させます。例えば、重みの合計が 100 から 105 に変化したとします。変化は 5% です。デフォルトの重要度しきい値の 5 では、変化率がしきい値を超えていないので、manager は executor が使用する重みを更新しません。しかし、重みの合計が 100 から 106 に変化すると、manager は重みを更新します。manager の重要度しきい値をデフォルト以外の値 (6 など) に設定するには、以下のコマンドを入力します。

  dscontrol manager sensitivity 6

ほとんどの場合に、この値を変更する必要はありません。

平滑化索引

manager は、サーバーの重みを動的に計算します。この結果として、更新された重みが前の重みより相当に異なる場合もあります。ほとんどの状況では、これが問題になることはありません。ただし、時には、要求のロード・バランシングの方法に対する影響が変動する場合があります。例えば、重みが高いために、1 つのサーバーが要求の大部分を受信してしまうこともあります。manager は、サーバーが高い数の活動状態の接続を持ち、サーバーが応答が遅いことを調べます。そこで、manager は重み過剰を空きサーバーに移し、そこでも同じ影響が生じて、リソースの非効率使用が作りだされます。

この問題を緩和するために、manager は平滑化索引を使用します。平滑化索引は、サーバーの重みが変われる量を制限し、要求の分散における変更を効率的に平滑化します。平滑化索引が高いと、サーバーの重みの変更頻度が減少します。索引が低いと、サーバーの重みの変更頻度が増大します。平滑化索引のデフォルト値は 1.5 です。1.5 では、サーバーの重みがかなり動的になります。索引が 4 または 5 では、重みはより安定します。例えば、平滑化索引を 4 に設定するには、以下のコマンドを入力します。

  dscontrol manager smoothing 4

ほとんどの場合に、この値を変更する必要はありません。

アラートまたはレコード・サーバー障害を生成するスクリプトの使用

Load Balancer は、カスタマイズできるスクリプトを起動するユーザー出口を提供します。 自動化された (サーバーがダウンとマークされると管理者にアラートを通知するか、単に障害のイベントを記録するなどの) アクションを実行するスクリプトを作成できます。カスタマイズ可能なサンプル・スクリプトが次のディレクトリーに入っています。

これらのファイルを実行するためには、ファイルを次のディレクトリーに移動して、「.sample」ファイル拡張子を除去する必要があります。

以下のサンプル・スクリプトが提供されています。

クラスターのすべてのサーバーに、(ユーザーまたは advisor によって) ダウンのマークが付けられている場合は、 managerAlert (構成されている場合) が開始し、Load Balancer は、ラウ ンドロビン手法で トラフィックをサーバーに経路指定しようとします。クラスターの最後のサーバーがオフラインであることが検出されたときは、serverDown スクリプトは実行されません。

Load Balancer は設計上、サーバーがオンラインに復帰して要求に応答する場合のために、 トラフィックのルーティングを継続します。もし Load Balancer がすべてのトラフィックを破棄したなら、 クライアントは応答を受けなくなってしまいます。

Load Balancer が、クラスターの最初のサーバーがオンラインに復帰していることを 検出すると、managerClear スクリプト (構成済みの場合) が実行されますが、 serverUp スクリプト (構成済みの場合) は追加のサーバーがオンラインに復帰するまで実行されません。

serverUp および serverDown スクリプトを使用するときの考慮事項:

Advisor

advisor は Load Balancer 内のエージェントです。これは、サーバー・マシンの状態および負荷の状態を評価することを目的としています。これは、サーバーとの事前の対策を講じたクライアント式交換で行われます。advisor は、アプリケーション・サーバーの lightweight クライアントと見なすことができます。

当製品は、最も一般的なプロトコルに対して、いくつかのプロトコル特有の advisor を提供します。しかし、Load Balancer のすべてのコンポーネントで提供されたすべての advisor を使用しても意味がありません。(例えば、CBR コンポーネントでは Telnet advisor を使用することにはなりません。) また、Load Balancer は、ユーザーが独自の advisor を作成できる「カスタム advisor」の概念もサポートします。

バインド固有のサーバー・アプリケーションを使用する場合の制限: バインド固有サーバー上で advisor を使用するためには、サーバーの 2 つのインスタンスを開始します。1 つは cluster:port 上でバインドするためのインスタンスで、もう 1 つは server:port 上でバインドするためのインスタンスです。 サーバーがバインド固有のものかどうかを判別するには、netstat -an コマンドを発行して server:port を検索します。サーバーが バインド固有でない場合、このコマンドの結果は 0.0.0.0:80 です。サーバーがバインド固有の場合、192.168.15.103:80 のようなアドレスが表示されます。

HP-UX および Solaris システムで、バインド固有の サーバー・アプリケーションを使用する場合の制限: バインド固有のサーバー・アプリケーション (CBR または Site Selector など他の Load Balancer コンポーネントを含む) を使用してサーバーのロード・バランシングを行う場合に ifconfig alias コマンドの代わりに arp publish を使用する場合、 Load Balancer は、サーバーをクラスター IP アドレスにバインドする際に advisor の使用をサポートします。ただし、バインド固有のサーバー・アプリケーションに対して advisor を使用している場合は、同じマシン上の Load Balancer をサーバー・アプリケーションに連結しないでください。

注:
複数のネットワーク・アダプター・カードを持つコンピューターで Load Balancer を実行していて、advisor トラフィックが特定のアダプターを通るようにしたい場合、強制的にパケットの送信元 IP アドレスを特定のアドレスにすることができます。 advisor パケット送信元アドレスを強制的に特定のアドレスにするには、該当する Load Balancer start スクリプト・ファイル (dsserver、cbrserver、または ssserver) の java...SRV_XXXConfigServer... 行に、以下を追加してください。
-DLB_ADV_SRC_ADDR=IP_address

advisor の機能

advisor は、定期的に各サーバーとの TCP 接続をオープンして、サーバーに要求メッセージを送信します。メッセージの内容は、サーバーで実行されるプロトコルに固有のものです。例えば、HTTP advisor は HTTP 『HEAD』 要求をサーバーに送信します。

advisor は、サーバーからの応答を listen します。advisor は、応答を受け取るとサーバーの評価を行います。この『負荷』値を 計算するため、advisor のほとんどは、サーバーが応答するまでの時間を測定して、負荷としてこの値 (ミリ秒単位) を使用します。

次に advisor は、負荷値を manager 機能に報告します。この値は、manager 報告書の「Port」列に出力されます。manager は、その割合に応じて全送信元からの重み値を集計して、これらの重み値を executor 機能に設定します。executor は、これらの重みを使用して、新規の着信クライアント接続のロード・バランシングを行います。

サーバーが正常に機能していると advisor が判断した場合は、正で非ゼロの負荷値を manager に報告します。サーバーが活動状態でないと advisor が判断した場合は、特別な負荷値である -1 を戻します。 manager および executor は、サーバーが稼働状態に戻るまで、それ以上そのサーバーに接続を転送しなくなります。

注:
初期の要求メッセージを送信する前に、advisor はサーバーを ping します。 これは、マシンがオンラインであるかどうかを判別する簡単な状況確認を提供することを意図しています。 サーバーが ping に応答すると、それ以上の ping は送信されません。 ping を使用不可に設定するには、Load Balancer 開始スクリプト・ファイルに -DLB_ADV_NO_PING を追加してください。

advisor の開始および停止

advisor は、すべてのクラスター間の特定ポート用に開始できます (グループ advisor)。 あるいは、同一ポートで、別のクラスター (クラスター/サイト固有の advisor) ではなくて、別の advisor を実行することを選択できます。例えば、Load Balancer をそれぞれがポート 80 になっている 3 つのクラスター (clusterA、clusterB、clusterC) で定義している場合は、以下を実行できます。

グループ advisor の前述の構成例を使用して、クラスターの一方または 両方 (clusterB および clusterC) で、 ポート 80 のカスタム advisor ADV_custom を停止できます。

advisor 間隔

注:
advisor のデフォルトは、ほとんどの場合に効率的であると考えられます。デフォルト以外の値を入力する場合は注意してください。

advisor 間隔は、advisor がモニターして、その結果を manager に報告するポートのサーバーから 状況を求める頻度を設定します。advisor 間隔が短過ぎると、advisor が絶えずサーバーに割り込むことになり、パフォーマンスの低下を生じることになります。advisor 間隔が長過ぎると、manager の重みに関する決定が、正確な最新情報に基づいていないことを意味します。

例えば、ポート 80 の HTTP advisor の場合に、間隔を 3 秒に設定するには、以下のコマンドを入力します。

  dscontrol advisor interval http 80 3

manager 間隔より小さい advisor 間隔を指定することは無意味です。デフォルトの advisor 間隔は 7 秒です。

advisor 報告タイムアウト

タイムアウト日付がロード・バランシングの判断で manager によって使用されないことを確実にするために、manager は、タイム・スタンプが advisor 報告タイムアウトで設定されている時刻より古い、advisor からの情報を使用しないことになります。advisor 報告タイムアウトは、advisor ポーリング間隔よりも大きくなっている必要があります。タイムアウトが小さいと、manager は、論理的には使用すべき報告を無視します。デフォルトでは、advisor 報告はタイムアウトにはなりません — デフォルト値は無制限です。

例えば、ポート 80 の HTTP advisor のために、advisor 報告タイムアウトを 30 秒に設定するには、次のコマンドを入力してください。

dscontrol advisor timeout http 80 30 

advisor 報告タイムアウトの設定の詳細については、dscontrol advisor — advisor の制御 を参照してください。

サーバーの advisor 接続タイムアウトおよび受信タイムアウト

Load Balancer の場合は、advisor のタイムアウト値を設定することができ、advisor はそのタイムアウト値の時点でサーバー (サービス) 上の特定のポートが失敗したことを検出します。 失敗したサーバー・タイムアウト値 (connecttimeout および receivetimeout) によって、advisor が接続または受信のいずれかの失敗を報告する前に待つ時間が決定されます。

障害が発生したサーバー を最短時間で検出するには、advisor 接続タイムアウトおよび受信タイムアウトを最小値 (1 秒) に設定し、advisor および manager 間隔時間も最小値 (1 秒) に設定します。

注:
サーバーの応答時間が増加するような、通常より多くのトラフィック量が発生している環境の場合は、connecttimeout および receivetimeout の値を小さく設定しすぎないように注意してください。そうしないと、advisor によって、ビジーのサーバーが障害発生としてマークされるのが早すぎる事態になることがあります。

例えば、ポート 80 で HTTP advisor の connecttimeout および receivetimeout を 9 秒に設定するには、次のコマンドを入力します。

dscontrol advisor connecttimeout http 80 9
dscontrol advisor receivetimeout http 80 9  

接続タイムアウトと受信タイムアウトのデフォルトは、advisor 間隔に指定されている値の 3 倍です。

advisor 再試行

advisor は、サーバーをダウンとしてマーク付けする前に、接続を再試行する機能を持っています。 advisor は、再試行回数 + 1 回だけサーバー照会が失敗するまでは、サーバーを ダウンとしてマーク付けしません。retry 値は 3 以下にしてください。 以下のコマンドは、ポート 389 の LDAP advisor に 2 の retry 値を設定します。

dscontrol advisor retry ldap 389 2

advisor のリスト

要求および応答 (URL) オプションによる HTTP または HTTPS advisor の構成

HTTP または HTTPS advisor の URL オプションは Dispatcher および CBR コンポーネントに使用可能です。

HTTP または HTTPS advisor を開始した後で、サーバーで照会したいサービスに固有の一意なクライアント HTTP URL ストリングを定義できます。 これにより、advisor は、サーバー内の個々のサービスの状態を評価できます。 これは、同一物理 IP アドレスをもつ論理サーバーを一意的なサーバー名を付けて定義することによって実行できます。 詳しくは、サーバーの区分化: 1 つのサーバー (IP アドレス) に対して構成された論理サーバーを参照してください。

HTTP ポートの下に定義済みの論理サーバーごとに、サーバーで照会したいサービスに固有の一意的なクライアント HTTP URL ストリングを指定できます。HTTP または HTTPS advisor は advisorrequest ストリングを使用して、サーバーの正常性を照会します。 デフォルト値は HEAD / HTTP/1.0 です。 advisorresponse ストリングは、advisor が HTTP 応答でスキャンする 応答です。advisor は advisorresponse ストリ ングを使用して、サーバーから受信した実際の応答と比較します。デフォルト値は null です。

重要: ブランクが HTTP URL ストリングに含まれている場合は、次の通りです。

バックエンド・サーバーが機能しているかどうかを確認するために HTTP または HTTPS advisor がバックエンド・サーバーに送信する要求を作成するときは、HTTP 要求の開始部分を入力します。要求の終了部分は Load Balancer が次のものを使用して完成させます。

¥r¥nAccept:
*/*\r\nUser-Agent:IBM_Load_Balanacer_HTTP_Advisor\r\n\r\n 

Load Balancer がこのストリングを要求の最後に追加する前に、他の HTTP ヘッダー・フィールドを追加したい場合、独自の ¥r¥n ストリングを要求に組み込むことによってこれを行うことができます。 以下は、HTTP ホスト・ヘッダー・フィールドを要求に追加するために入力する内容の例です。

GET /pub/WWW/TheProject.html HTTP/1.0 ¥r¥nHost: www.w3.org
注:
指定された HTTP ポート番号の HTTP または HTTPS advisor の開始後に、 advisor の要求および応答値はその HTTP ポートの下のサーバーで使用可能になります。

詳しくは、dscontrol server — サーバーの構成を参照してください。

2 層 WAN 構成内の self advisor の使用

self advisor は Dispatcher コンポーネントで使用可能です。

2 層 WAN (広域ネットワーク) 構成内の Load Balancer の場合は、Dispatcher は、バックエンド・サーバーで負荷状況情報を収集する self advisor を提供します。

図 31. self advisor を使用する 2 層 WAN 構成の例
self advisor を使用する 2 層 WAN 構成

この例では、self advisor は Metric Server と一緒に、最上層 Load Balancer によってロード・バランシングされている 2 つの Dispatcher マシンにあります。 self advisor は、特に Dispatcher のバックエンド・サーバーで秒当たりの接続数の率を executor レベルで計測します。

self advisor は、結果を dsloadstat ファイルに書き込みます。 また、Load Balancer は dsload と呼ばれる外部メトリックも提供します。Metric Server エージェントは各 Dispatcher マシンで、外部メトリック dsload を呼び出すその構成を実行します。 dsload スクリプトは、dsloadstat ファイルからストリングを抽出し、それを Metric Server エージェントに戻します。 その後、(各 Dispatcher の) 各 Metric Server エージェントは、最上層 Load Balancer に負荷状況値を戻します。この値は、クライアント要求を転送する Dispatcher の判別に使用されます

dsload 実行可能ファイルは次のディレクトリーにあります。

WAN 構成で Dispatcher を使用する際の詳細については、広域 Dispatcher サポートの構成を参照してください。 Metric Server の詳細については、Metric Server を参照してください。

カスタム (カスタマイズ可能) advisor の作成

カスタム (カスタマイズ可能) advisor は、基本コードによって呼び出される小規模な Java コードであり、ユーザーによりクラス・ファイルとして提供されます。基本コードは、カスタム advisor のインスタンスの開始と停止、状況と報告書の提供、およびヒストリー情報のログ・ファイルへの記録などのあらゆる管理サービスを提供します。また、結果を manager コンポーネントに報告します。基本コードは advisor サイクルを定期的に実行し、各サイクルで構成内のサーバーをすべて評価します。これは、サーバー・マシンとの接続を オープンすることによって開始されます。ソケットがオープンすると、基本コードは、カスタム advisor の "getLoad" メソッド (関数) を呼び出します。その後、カスタム advisor は、サーバーの状態を評価するために必要なステップをすべて実行します。一般的には、ユーザー定義のメッセージをサーバーに送信してから応答を待機します。(オープンしたソケットへのアクセスがカスタム advisor に提供されます。) その後、基本コードは、サーバーとのソケットをクローズして、manager に負荷情報を報告します。

基本コードおよびカスタム advisor は、通常モードおよび置換モードのいずれでも機能します。動作モードの選択は、カスタム advisor ファイルでコンストラクター・メソッドのパラメーターとして指定します。

通常モードでは、カスタム advisor がサーバーとデータを交換し、基本 advisor コードが交換の時間を測定して負荷値を計算します。基本コードは、この負荷値を manager に 報告します。カスタム advisor は、0 (正常) または負の値 (エラー) を戻す必要があるのみです。通常モードを指定するには、コンストラクターの代替フラグを false に設定します。

置換モードでは、基本コードはいかなる時間測定も行いません。カスタム advisor コードは、固有の要件に必要な操作をすべて実行して、実際の負荷値を戻します。基本コードは、その数値を受け入れて manager に報告します。最善の結果を得るためには、負荷値を 10 から 1000 までの間に正規化し、10 で高速なサーバーを表し、1000 で低速なサーバーを表してください。置換モードを指定するには、コンストラクターの代替フラグを true に設定します。

この機能によって、ユーザー自身の advisor を作成し、ユーザーが必要とするサーバーに関する正確な情報を得ることができます。 サンプルのカスタム advisor (ADV_sample.java) は Load Balancer に添付されています。

Load Balancer をインストールすると、サンプル・コードが次のディレクトリーに入ります。

注:
カスタム advisor を Dispatcher、または適用できる他の Load Balancer コンポーネントに追加する場合、新しいカスタム advisor クラス・ファイルを読み取る Java プロセスを使用可能にするため、dsserver を停止してから再始動 (Windows システムの場合「サービス」を使用) しなければなりません。 カスタム advisor クラス・ファイルは、始動時にのみロードされます。 executor を停止する必要はありません。 executor は、dsserver またはサービスが停止したときでも、継続して稼働します。

カスタム advisor が追加 の Java クラスを 参照する場合は、Load Balancer 開始スクリプト・ファイル中のクラスパス (dsserver、cbrserver、ssserver) が その場所を含むように更新してください。

WAS advisor

WebSphere Application Server (WAS) advisor 専用のサンプル・カスタム advisor ファイルが Load Balancer インストール・ディレクトリーにあります。

WebSphere Application Server advisor サンプル・ファイルは、ADV_sample.java ファイルと同じサンプル・ディレクトリーに入っています。

命名規則

カスタム advisor のファイル名は "ADV_myadvisor.java" の形式でなければなりません。すなわち、大文字の接頭部 "ADV_" で始まらなければなりません。それ以後の文字は、すべて小文字でなければなりません。

Java の規則に従い、ファイルで定義されたクラスの名前は、ファイルの名前と一致していなければなりません。サンプル・コードをコピーする場合は、ファイル内の "ADV_sample" のインスタンスをすべて 新しいクラス名に変更してください。

コンパイル

カスタム advisor は、Java 言語で作成します。Load Balancer と同時にインストールされた Java コンパイラーを使用してください。以下のファイルは、コンパイル中に参照されます。

クラスパスは、コンパイル時にカスタム advisor ファイルと基本クラス・ファイルの両方を指していなければなりません。

Windows システムの場合、サンプル・コンパイル・コマンドは次のとおりです。

install_dir/java/bin/javac -classpath 
    install_dir¥lb¥servers¥lib¥ibmlb.jar ADV_fred.java

ここで、

コンパイルの出力は以下のようなクラス・ファイルです。

ADV_fred.class

advisor を開始する前に、クラス・ファイルを次のディレクトリーにコピーしてください。

注:
必要な場合は、カスタム advisor をあるオペレーティング・システムで コンパイルして、別のオペレーティング・システムで実行することができます。例えば、Windows システムで advisor をコンパイルし、(バイナリーの) クラス・ファイルを AIX マシンにコピーして、そこでカスタム advisor を実行することができます。

AIX、HP-UX、 Linux、 および Solaris システムでの構文は似ています。

実行

カスタム advisor を実行するには、次のように、最初にクラス・ファイルを正しいインストール・ディレクトリーに コピーしなければなりません。

コンポーネントを構成し、その manager 機能を開始して、カスタム advisor を開始するためのコマンドを出します。

dscontrol advisor start fred 123

ここで、

カスタム advisor が追加 の Java クラスを 参照する場合は、Load Balancer 開始スクリプト・ファイル中のクラスパス (dsserver、cbrserver、ssserver) が その場所を含むように更新してください。

必須ルーチン

すべての advisor と同様に、カスタム advisor は、ADV_Base という advisor ベースの機能を拡張します。これは、manager の重みのアルゴリズムで 使用するために manager に負荷を報告する などの advisor の機能のほとんどを実際に実行する advisor ベースです。また、advisor ベースは、ソケット接続とクローズ操作も実行し、advisor が使用するための send および receive メソッドを提供します。advisor 自体は、アドバイスされるサーバーのポートとの間で データを送受信するためにのみ使用されます。advisor ベースの TCP メソッドは時間が測定され、負荷が計算されます。必要な場合は、ADV_base のコンストラクターにあるフラグによって、advisor から戻された新しい負荷で既存の負荷が上書きされます。

注:
コンストラクターで設定された値に基づいて、advisor ベースは、指定された時間間隔で重みのアルゴリズムに負荷を提供します。実際の advisor が完了していないために有効な負荷を戻すことができない場合は、advisor ベースは直前の負荷を使用します。

基本クラスのメソッドを以下に示します。

検索順序

Load Balancer は、最初に、提供されているネイティブ advisor のリストを参照します。指定された advisor がそこに見つからないと、Load Balancer はカスタマイズされた advisor のお客様のリストを参照します。

命名およびパス

サンプル advisor

サンプル advisor のプログラム・リストは、サンプル advisorに入っています。インストール後、このサンプル advisor は次のディレクトリーに入っています。

Metric Server

この機能は、すべての Load Balancer コンポーネントに使用可能です。

Metric Server はシステム固有のメトリックの形式でサーバーの負荷情報を Load Balancer に提供し、サーバーの状態について報告します。 Load Balancer manager は、各サーバーに常駐している Metric Server エージェントに照会し、エージェントから収集したメトリックを使用してロード・バランシング処理に重みを割り当てます。 その結果も manager 報告書に入れられます。

注:
複数のメトリックを単一システム負荷値に収集して正規化するときには、丸め誤差が起こる場合があります。

Metric Server の操作 (始動および停止) と Metric Server ログの使用方法については、Metric Server コンポーネントの使用 を参照してください。

構成の例については、図 5 を参照してください。

WLM の制約事項

WLM advisor と同様に、Metric Server は、個々のプロトコル固有のサーバー・デーモンではなく、サーバー・システム全体について報告します。 WLM および Metric Server は、両方とも manager 報告書の system 列に結果を入れます。結果として、WLM advisor および Metric Server の両方を同時に実行することはできません。

前提条件

Metric Server エージェントは、ロード・バランシングされているサーバーすべてにインストールされていて、そのサーバーで実行中でなければなりません。

Metric Server の使用法

以下は、Dispatcher の Metric Server を構成するためのステップです。Load Balancer のその他のコンポーネントの Metric Server を構成する場合も、同様のステップを使用してください。

Metric Server がローカル・ホスト以外のアドレスで実行されるようにするには、ロード・バランスされるサーバー・マシン上の metricserver ファイルを編集する必要があります。 metricserver ファイル中の "java" のオカレンスの後に、以下を挿入します。

-Djava.rmi.server.hostname=OTHER_ADDRESS

さらに、metricserver ファイル中の "if" ステートメントの前に、次の行を追加します: hostname OTHER_ADDRESS

Windows プラットフォームの場合: Metric Server マシンの Microsoft スタックで OTHER_ADDRESS に別名を割り当てることも必要です。 以下に例を示します。

call netsh interface ip add address "Local Area Connection" 
   addr=9.37.51.28 mask=255.255.240.0

さまざまなドメイン間でメトリックを収集するときは、サーバー・スクリプト (dsserver、cbrserver 等) で java.rmi.server.hostname をメトリックを要求するマシンの完全修飾ドメイン名に明確に設定しなければなりません。 これは、使用するセットアップおよびオペレーティング・システムによっては、InetAddress.getLocalHost.getHostName() が FQDN を戻さない可能性があるので必要とされます。

作業負荷管理機能 advisor

WLM は、MVS メインフレームで実行されるコードです。これは、MVS マシンの負荷を確認するために照会できます。

OS/390 システムで MVS 作業負荷管理が構成されている場合、Dispatcher は、WLM からの容量情報を受け取り、ロード・バランシング処理で使用します。 WLM advisor を使用して、Dispatcher は、定期的に Dispatcher ホスト・テーブルにある 各サーバーの WLM ポートを介して接続をオープンし、戻された容量を表す整数を受け取ります。これらの整数は その時点で使用可能な容量を表しますが、Dispatcher は各マシン の負荷を表す値を想定しているので、容量を表す整数は advisor によって反転され、負荷値に正規化されます (すなわち、 容量を表す整数が大きくて負荷値が小さいことは、サーバーの状態が良いことを 表します)。結果として得られる負荷は、manager 報告書の System 列に入ります。

WLM advisor と他の Dispatcher advisor の間には、重要な違いがいくつかあります。

  1. 他の advisor は、通常のクライアント・トラフィックを流すポートと同じポートを使用して サーバーへの接続をオープンします。WLM advisor は、通常のトラフィックとは異なるポートを使用して サーバーへの接続をオープンします。各サーバー・マシンの WLM エージェントは、Dispatcher WLM advisor が開始するポートと同じポートで listen するように 構成されていなければなりません。デフォルトの WLM ポートは 10007 です。
  2. 他の advisor は、サーバーのポートが advisor のポートと一致する Dispatcher cluster:port:server 構成で 定義されたサーバーを評価するだけです。WLM advisor は、 cluster:port に関わらず、Dispatcher 構成中の すべてのサーバーに対してアドバイザー機能を持ちます。 したがって、WLM advisor を使用している場合は、WLM 以外のサーバーを定義してはなりません。
  3. 他の advisor は、manager 報告書の 『Port』 列に負荷情報を入れます。 WLM advisor は、manager 報告書の system 列に負荷情報を入れます。
  4. プロトコル固有の両方の advisor を WLM advisor とともに 使用することができます。プロトコル固有の advisor は通常のトラフィック・ポートでサーバーをポーリングし、WLM advisor は WLM ポートを使用してシステム負荷をポーリングします。

Metric Server の制約事項

Metric Server エージェントと同様に、WLM エージェントは、個々のプロトコル固有のサーバー・デーモンではなく、サーバー・システム全体について報告します。 Metric Server および WLM は、manager 報告書の system 列に結果を入れます。 結果として、WLM advisor および Metric Server の両方を同時に実行することはできません。