manager 報告書

Load Balancer の manager 機能では各サーバーの重みを計算します。サーバーが同じクラスターおよびポート構成内の他のサーバーと比較して、いくつの接続を受け取るかを判別するために、これらの重みを使用します。manager 報告書を理解することは、ネットワーク・トラフィックがどのように分散されるかを理解するうえで重要です。

manager 報告書には、その cluster:port 組み合わせに定義されている、各クラスター、ポート、およびサーバーのリストが含まれています。各サーバーは、 2 つの重み、NOW および NEW を示し、また重みを計算するために使用される 4 つの列を示します。 4 つの列それぞれに、サーバーの重みを計算するために使用されるパーセンテージが割り当てられます。 これらのパーセンテージは、クラスター比率設定コマンドを使用して設定されます。 Dispatcher および CBR の場合、デフォルトでは、サーバーの重みを計算する際に活動中の接続数 および新規接続数のみが考慮されます。これらの値は、executor の内部で生成および保管された情報に基づいています。 Site Selector の場合は、manager は Metric Server から最初の 2 つの値 (CPU およびメモリー) を得ます。
advisor が開始されると、ポート負荷の比率は 1% に設定され、そのポート負荷が重み計算で使用されます。 同様に、メトリックが加算されるとき、システム負荷の比率は 1% に設定されます。manager 関数は、各サーバーごとに次の値を戻します。
活動中の接続数 (ACTV)
活動中の接続数は、manager サイクルの開始時にクローズされる TCP 接続です。
新規接続数 (NEWC)
新規接続数は、manager サイクルの開始から最終 manager サイクルの開始までの、合計接続数の増加を表します。
ポート負荷 (PORT)
ポート負荷は、この cluster:port 組み合わせに定義されている advisor から取得される値です。advisor が開始していない場合、ポート負荷は常にゼロです。 advisor が定義済みの場合、ポート負荷は、 advisor がサーバーからの応答を受信するためのミリ秒を標準的に表します。
ポート負荷が -1 と示された場合、advisor はその照会に対して成功した応答を受け取りませんでした。 サーバーが応答しなかった理由を 調べられるように、advisor のロギング・レベルおよびログ・サイズを大きくしてください。サーバーが接続要求に まったく応答しない場合は、以下の手順を実行します。
  1. Load Balancer マシンからサーバーを正常に ping できることを確認します。
  2. サーバー・アプリケーションが始動済みであること、および定義されているポートで listen していることを検証します。 サーバーが、advisor 要求に正常に応答するには、ワイルドカード・アドレス (0.0.0.0) か、またはクラスター IP アドレスとリアル・サーバー IP アドレスの両方を listen していなければなりません。
サーバーは、接続に応答する場合、Load Balancer が予期しているものとは異なった仕方で 照会に応答する可能性があります。 定義されている advisorresponse ストリングをチェックして、サーバーが送信した内容に一致するか確認してください。 このシナリオは http および https の両方の advisor に適用されます。
システム負荷 (SYS)
システム負荷は、Metric Server から返された値を表します。 この cluster:port 組み合わせのメトリックがまだ加算されていない場合、システム負荷は ゼロ (0) です。 メトリックが定義されている場合は、システム負荷は、サーバーの状況を表す、 -1 から 100 の値です。 100 は、きわめてビジーな状態を表し、ゼロ (0) はアイドル状態を表します。
システム負荷が -1 を示す場合、Load Balancer は、バックエンド・マシンの Metric Server と連絡できていません。 Load Balancer の鍵がサーバーに正しく配布されていること、 Load Balancer からサーバーに ping できること、およびマシン上で Metric Server が始動済みであることを確認してください。 問題が続くときは、以下の手順を実行します。
  1. バックエンド・マシンの Metric Server のスクリプトを編集し、ログ・レベルとログ・サイズの両方とも、 値を大きくします。
  2. Metric Server を再始動します。
  3. Load Balancer でメトリック・モニターのログ・サイズとロギング・レベルの値を大きくします。
  4. Load Balancer マシンとバックエンド・マシンの両方でログ・ファイルを調べて、通信が失敗している理由を判別します。
CPU およびメモリー (Site Selector コンポーネント)
CPU およびメモリーは、Metric Server から戻された値を 表します。cpuload メトリックおよび memload メトリック は Site Selector 構成に対して自動的に追加されます。CPU およびメモリー は、サーバーの状況を表す -1 から 100 までの値です。100 は、きわめてビジーな状態を表し、ゼロ (0) はアイドル状態を表します。これらのメトリックが -1 を示す場合、Load Balancer は バックエンド・マシン上の Metric Server と連絡できていません。Load Balancer の鍵がサーバーに正しく配布されていること、 Load Balancer からサーバーに ping できること、およびマシン上で Metric Server が始動済みであることを確認してください。 問題が続くときは、以下の手順を実行します。
  1. バックエンド・マシンの Metric Server のスクリプトを編集し、ログ・レベルとログ・サイズの両方とも、 値を大きくします。
  2. Metric Server を再始動します。
  3. Load Balancer でメトリック・モニターのログ・サイズとロギング・レベルの値を大きくします。
  4. Load Balancer マシンとバックエンド・マシンの両方でログ・ファイルを調べて、通信が失敗している理由を判別します。

活動中の接続数および新規接続数は、executor が、最後の manager 関数の最終サイクル内で送った接続の数を基にして判別されます。manager サイクルは、デフォルトで 2 秒です。

サーバーの重みの構成

通常の環境では、Load Balancer は、ゼロ以外の比率をもつ すべての値を使用して、新規の重みを計算します。 例えば、割合が 40 40 20 0 である場合、活動中の接続数および新規接続数は、それぞれ重み計算の 40% で、ポート負荷が 20% です。

一例として、manager 関数から以下の値が戻されたとします。
             ACTV      NEWC       PORT      SYS
Server1       50        200        25        0
Server2       25        100        50        0
初期の重み計算は次のようになります。 初期の重みは、cluster:port の重み限界に合うような比率でスケーリングされます。 デフォルトでは、重み限界は 10 です。 したがって、先の例では、最終の重みは、一番近い整数に丸められ、以下のようになります。 計算された重みは、manager 報告書で NEW 重みとして示されます。 この重みは、この cluster:port 組み合わせに構成されている重要度レベルを超えた場合にのみ、executor 関数にプッシュされます。NOW 重みは、この manager サイクルの開始時に executor から取得した重みを表します。

ポート負荷またはシステム負荷が -1 であり、 かつポートまたはシステムの列のそれぞれの比率が 0 より大きい場合、 計算される重みはゼロ (0) となります。 ゼロ (0) は、サーバーが非アクティブであり、新規の要求がサーバーに送信されないことを示します。

サーバーを静止すると、その重みもゼロ (0) と表示されますが、サーバーがまだオンラインであればポート負荷は正であることが分かります。静止されたサーバーが オフラインになると、ポート負荷は -1 になります。

Load Balancer がサーバーへ要求を送信しないように、そのサーバーでユーザーが「サーバー・ダウン」関数を 実行した場合、ポート負荷およびシステム負荷の値に関わらず、重みは -1 となります。

Concept topic    

Terms and conditions for information centers | Feedback

Last updated: May 28, 2013 08:30 AM EDT
File name: cprf_manager.html