本章では、ロード・バランシング・パラメーターの構成方法、および Load Balancer の manager、advisor、および Metric Server 機能のセットアップ方法について説明します。
タスク | 説明 | 関連情報 |
---|---|---|
オプションでロード・バランシングの設定値を変更する |
以下のロード・バランシング設定値を変更することができます。
|
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 の manager 機能は、以下の設定を基にしてロード・バランシングを実行します。
これらの設定を変更して、ネットワークのロード・バランシングを最適化することができます。
manager は、その重みの判断で、以下の外的要因の一部またはすべてを使用できます。
あるいは -
CPU: ロード・バランシングされた各サーバー・マシンで使用中の CPU のパーセンテージ (Metric Server エージェントからの入力)。Site Selector の場合に限り、この割合は活動中の接続割合欄に表示されます。
あるいは -
メモリー: ロード・バランシングされた各サーバーで使用中のメモリーのパーセンテージ (Metric Server エージェントからの入力)。Site Selector の場合に限り、この割合は新規接続割合欄に表示されます。
manager は、各サーバーごとの現行の重みと、その計算に必要なその他の何らかの情報とともに、executor から最初の 2 つの値 (活動中の接続および新規接続) を得ます。これらの値は、executor の内部で生成および保管された情報に基づいています。
クラスター (またはサイト名) ごとの基準に基づいて 4 つの値の相対的な重要性の割合を変更できます。この割合をパーセントで考えると、相対的な割合の合計は 100% でなければなりません。 デフォルトの割合は 50/50/0/0 で、これは advisor およびシステム情報を無視しています。使用環境によっては、最良のパフォーマンスが得られる組み合わせを見つけるために、別の割合を試すことが必要な場合があります。
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 がなければ、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 reset が活動化されている場合、Dispatcher は、重みが 0 であるサーバーにクライアントが接続されている場合に、そのクライアントに TCP reset を送信します。 サーバーの重みは、それが 0 に構成されている場合か、または advisor がダウンさせた場合に 0 になる可能性があります。 TCP リセットにより、接続は即時にクローズします。 この機能は、長時間存続する接続の場合に有用であり、失敗した接続を再折衝するためのクライアントの機能を促進します。 TCP リセットを活動化するには、dscontrol port add|set port reset yes コマンドを使用します。 reset のデフォルト値は no です。
TCP リセットとともに構成のために便利な機能は、advisor retry です。この機能によって、advisor は、サーバーにダウンのマークを付ける前に接続を再試行することができます。これは、advisor が早まってサーバーにダウンのマークを付けてしまい、 結果として接続リセット問題が起こるのを防止するのに役立ちます。 すなわち、advisor が最初の試行に失敗したからといって、既存の接続にも障害が起こっているということには必ずしもならないことを意味します。 詳しくは、advisor 再試行を参照してください。
全体パフォーマンスを最適化するために、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 は 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 システムの場合のバインド固有のサーバー・アプリケーションを使用する上での制限: ifconfig alias コマンドの代わりに arp publish を使用する場合、バインド固有のサーバー・アプリケーション (CBR または Site Selector など他の Load Balancer コンポーネントを含む) をクラスター IP アドレスとバインドしようとするときに、それらとサーバーのロード・バランシング時に Load Balancer は、advisor の使用をサポートします。 ただし、バインド固有のサーバー・アプリケーションに対して advisor を使用するときは、同じマシン上の Load Balancer をサーバー・アプリケーションに連結しないでください。
-DLB_ADV_SRC_ADDR=IP_address
advisor は、定期的に各サーバーとの TCP 接続をオープンして、サーバーに要求メッセージを送信します。メッセージの内容は、サーバーで実行されるプロトコルに固有のものです。例えば、HTTP advisor は HTTP "HEAD" 要求をサーバーに送信します。
advisor は、サーバーからの応答を listen します。advisor は、応答を受け取るとサーバーの評価を行います。この『負荷』値を計算するため、advisor のほとんどは、サーバーが応答するまでの時間を測定して、負荷としてこの値 (ミリ秒単位) を使用します。
次に advisor は、負荷値を manager 機能に報告します。この値は、manager 報告書の「Port」列に出力されます。manager は、その割合に応じて全送信元からの重み値を集計して、これらの重み値を executor 機能に設定します。executor は、これらの重みを使用して、新規の着信クライアント接続のロード・バランシングを行います。
サーバーが正常に機能していると advisor が判断した場合は、正で非ゼロの負荷値を manager に報告します。サーバーが活動状態でないと advisor が判断した場合は、特別な負荷値である -1 を戻します。 Manager および Executor は、サーバーが稼働状態に戻るまで、それ以上そのサーバーに接続を転送しなくなります。
advisor は、すべてのクラスター (グループ advisor) 間の特定ポート用に開始できます。あるいは、同一ポートで、別のクラスター (クラスター/サイト固有の advisor) ではなくて、別の advisor を実行することを選択できます。例えば、Load Balancer がそれぞれがポート 80 になっている 3 つのクラスター (clusterA、clusterB、clusterC) で定義されていると、以下が実行できます。
dscontrol advisor start http clusterA:80このコマンドは、HTTP advisor をポート 80 で clusterA 用に開始します。この HTTP advisor は、ポート 80 で clusterA 用に接続されているすべてのサーバーでアドバイスされることになります。
dscontrol advisor start ADV_custom 80このコマンドは、ADV_custom advisor をポート 80 で clusterB および clusterC 用に開始します。カスタム advisor は、clusterB および clusterC 用にポート 80 に接続されているすべてのサーバーでアドバイスされることになります。(カスタム advisor の詳細については、カスタム (カスタマイズ可能) advisor の作成 を参照してください。)
グループ advisor の前述の構成例を使用して、クラスターの一方または 両方 (clusterB および clusterC) で、 ポート 80 のカスタム advisor ADV_custom を停止できます。
dscontrol advisor stop ADV_custom clusterB:80
dscontrol advisor stop ADV_custom 80
advisor 間隔は、advisor がモニターして、その結果を manager に報告するポートのサーバーから 状況を求める頻度を設定します。advisor 間隔が短過ぎると、advisor が絶えずサーバーに割り込むことになり、パフォーマンスの低下を生じることになります。advisor 間隔が長過ぎると、manager の重みに関する決定が、正確な最新情報に基づいていないことを意味します。
例えば、ポート 80 の HTTP advisor の場合に、間隔を 3 秒に設定するには、以下のコマンドを入力します。
dscontrol advisor interval http 80 3
manager 間隔より小さい advisor 間隔を指定することは無意味です。デフォルトの advisor 間隔は 7 秒です。
タイムアウト日付がロード・バランシングの判断で manager によって使用されないことを確実にするために、manager は、タイム・スタンプが advisor 報告タイムアウトで設定されている時刻より古い、advisor からの情報を使用しないことになります。advisor 報告タイムアウトは、advisor ポーリング間隔よりも大きくなっている必要があります。タイムアウトが小さいと、manager は、論理的には使用すべき報告を無視します。デフォルトでは、advisor 報告はタイムアウトにはなりません — デフォルト値は無制限です。
例えば、ポート 80 の HTTP advisor のために、advisor 報告タイムアウトを 30 秒に設定するには、次のコマンドを入力してください。
dscontrol advisor timeout http 80 30
advisor 報告タイムアウトの設定の詳細については、dscontrol advisor — advisor の制御 を参照してください。
Load Balancer の場合は、advisor のタイムアウト値を設定することができ、advisor はそのタイムアウト値の時点でサーバー (サービス) 上の特定のポートが失敗したことを検出します。 失敗したサーバー・タイムアウト値 (connecttimeout および receivetimeout) によって、advisor が接続または受信のいずれかの失敗を報告する前に待つ時間が決定されます。
最速に失敗したサーバーの検出を得るために、advisor 接続タイムアウトおよび受信タイムアウトを最小値 (1 秒) に設定し、advisor および manager 間隔時間を最小値 (1 秒) に設定します。
例えば、ポート 80 で HTTP advisor の connecttimeout および receivetimeout を 9 秒に設定するには、次のコマンドを入力します。
dscontrol advisor connecttimeout http 80 9 dscontrol advisor receivetimeout http 80 9
接続タイムアウトと受信タイムアウトのデフォルトは、advisor 間隔に指定されている値の 3 倍です。
advisor は、サーバーをダウンとしてマーク付けする前に、接続を再試行する機能を持っています。 advisor は、再試行回数 + 1 回だけサーバー照会が失敗するまでは、サーバーを ダウンとしてマーク付けしません。retry 値は 3 以下にしてください。 以下のコマンドは、ポート 389 の LDAP advisor に 2 の retry 値を設定します。
dscontrol advisor retry ldap 389 2
SSL advisor がサーバーにダウンのマークを付けようとしているが分かり、サーバーがまだ稼働していることを知っており、かつ、「暗号が見つからなかった」ことを示すメッセージを受け取った場合は、TLS 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 ストリングに含まれている場合は、次の通りです。
server set cluster:port:server advisorrequest "head / http/1.0" server set cluster:port:server advisorresponse "HTTP 200 OK"
dscontrol server set cluster:port:server advisorrequest "\"head / http/1.0\"" dscontrol server set cluster:port:server advisorresponse "\"HTTP 200 OK\""
バックエンド・サーバーが機能しているかどうかを確認するために 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
詳しくは、dscontrol server — サーバーの構成を参照してください。
self advisor は Dispatcher コンポーネントで使用可能です。
2 層 WAN (広域ネットワーク) 構成内の Load Balancer の場合は、Dispatcher は、バックエンド・サーバーで負荷状況情報を収集する self advisor を提供します。
この例では、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 は、基本コードによって呼び出される小規模な 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 が追加 の Java クラスを 参照する場合は、Load Balancer 開始スクリプト・ファイル中のクラスパス (dsserver、cbrserver、ssserver) が その場所を含むように更新してください。
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 を開始する前に、クラス・ファイルを次のディレクトリーにコピーしてください。
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 から戻された新しい負荷で既存の負荷が上書きされます。
基本クラスのメソッドを以下に示します。
Load Balancer は、最初に、提供されているネイティブ advisor のリストを参照します。指定された advisor がそこに見つからないと、Load Balancer はカスタマイズされた advisor のお客様のリストを参照します。
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
<install_root>ibm¥edge¥lb¥servers¥lib¥CustomAdvisors
サンプル advisor のプログラム・リストは、サンプル advisorに入っています。インストール後、このサンプル advisor は次のディレクトリーに入っています。
この機能は、すべての Load Balancer コンポーネントに使用可能です。
Metric Server はシステム固有のメトリックの形式でサーバーの負荷情報を Load Balancer に提供し、サーバーの状態について報告します。 Load Balancer manager は、各サーバーに常駐している Metric Server エージェントに照会し、エージェントから収集したメトリックを使用してロード・バランシング処理に重みを割り当てます。 その結果も manager 報告書に入れられます。
Metric Server の操作 (始動および停止) と Metric Server ログの使用方法については、Metric Server コンポーネントの使用 を参照してください。
構成の例については、図 5 を参照してください。
WLM advisor と同様に、Metric Server は、個々のプロトコル固有のサーバー・デーモンではなく、サーバー・システム全体について報告します。 WLM および Metric Server は、両方とも manager 報告書の system 列に結果を入れます。結果として、WLM advisor および Metric Server の両方を同時に実行することはできません。
Metric Server エージェントは、ロード・バランシングされているサーバーすべてにインストールされていて、そのサーバーで実行中でなければなりません。
以下は、Dispatcher の Metric Server を構成するためのステップです。Load Balancer のその他のコンポーネントの Metric Server を構成する場合も、同様のステップを使用してください。
port は、実行するためにすべての Metric Server エージェント用に選択する RMI ポートです。metricserver.cmd ファイル中で設定されているデフォルト RMI ポートは 10004 です。
systemMetric は、指定されたクラスター (またはサイト名) の下の構成でサーバーのそれぞれで実行される (バックエンド・サーバーに存在している) スクリプトの名前です。2 つのスクリプト cpuload および memload がお客様提供されます。あるいは、カスタム・システム・メトリック・スクリプトを作成できます。スクリプトには、0 から 100 までの範囲の数値か、サーバーがダウンしている場合は -1 の値を戻すコマンドが含まれています。この数値は、アベイラビリティー値ではなくロード測定値を表します。
制限: Windows プラットフォームの場合は、システム・メトリック・スクリプトの名前の拡張子が ".exe" になっているときには、ファイルのフルネーム (例えば、"mysystemscript.bat") を指定しなければなりません。これは Java の制限によるものです。
オプションで、Metric Server がサーバー・マシンで出すコマンドを定義したユーザー独自のカスタマイズ済みメトリック・スクリプト・ファイルを作成できます。カスタム・スクリプトが実行可能であり、かつ次のディレクトリーに入っていることを確認してください。
カスタム・スクリプトは、範囲が 0 から 100 の数字の負荷の値を戻さなければなりません。
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 を戻さない可能性があるので必要とされます。
WLM は、MVS メインフレームで実行されるコードです。これは、MVS マシンの負荷を確認するために照会できます。
OS/390 システムで MVS 作業負荷管理が構成されている場合、Dispatcher は、WLM からの容量情報を受け取り、ロード・バランシング処理で使用します。 WLM advisor を使用して、Dispatcher は、定期的に Dispatcher ホスト・テーブルにある 各サーバーの WLM ポートを介して接続をオープンし、戻された容量を表す整数を受け取ります。これらの整数は その時点で使用可能な容量を表しますが、Dispatcher は各マシン の負荷を表す値を想定しているので、容量を表す整数は advisor によって反転され、負荷値に正規化されます (すなわち、 容量を表す整数が大きくて負荷値が小さいことは、サーバーの状態が良いことを 表します)。結果として得られる負荷は、manager 報告書の System 列に入ります。
WLM advisor と他の Dispatcher advisor の間には、重要な違いがいくつかあります。
Metric Server エージェントと同様に、WLM エージェントは、個々のプロトコル固有のサーバー・デーモンではなく、サーバー・システム全体について報告します。 Metric Server および WLM は、manager 報告書の system 列に結果を入れます。 結果として、WLM advisor および Metric Server の両方を同時に実行することはできません。