mod_proxy_balancer - Apache HTTP サーバ バージョン 2.4

Apache Server 2.4

<-

Apache モジュール mod_proxy_balancer

この日本語訳はすでに古くなっている 可能性があります。 最近更新された内容を見るには英語版をご覧下さい。
説明:負荷分散のための mod_proxy 拡張
ステータス:Extension
モジュール識別子:proxy_balancer_module
ソースファイル:mod_proxy_balancer.c
互換性:2.1 以降

概要

本モジュールには mod_proxy必要ですHTTP, FTPAJP13 プロトコルのロードバランス機能を持っています。

ですから、 ロードバランスを有効にする場合 mod_proxymod_proxy_balancer がサーバに組み込まれて いなければいけません。

警告

安全なサーバにするまでプロクシ機能は有効にしないでください。 オープンプロキシサーバはあなた自身のネットワークにとっても、 インターネット全体にとっても危険です。

top

ロードバランサのスケジューラのアルゴリズム

現時点では 2 種類のロードバランサスケジューラアルゴリズムから選べます。 リクエスト回数によるもの (訳注: Request Counting) と、トラフィック量によるもの (訳注: Weighted Traffic Counting) があります。バランサの設定 lbmethod 値で、どちらを使うか指定します。 詳細は Proxy ディレクティブを 参照してください。

top

Request Counting アルゴリズム

lbmethod=byrequests で有効になります。 このスケジューラの背景にある考え方は、様々なワーカーがそれぞれ、 設定されている分担リクエスト数をきちんと受け取れるように、 リクエストを扱うという考え方です。次のように動作します:

lbfactor は、どの程度ワーカーに仕事を振るか つまりワーカーのクオータを指します。この値は "分担" 量を表す正規化された値です。

lbstatus は、ワーカーのクオータを満たすために どのぐらい急ぎで働かなければならないかを指します。

ワーカーはロードバランサのメンバで、通常は、 サポートされるプロトコルのうちの一つを提供しているリモートホストです。

まず個々のワーカーにワーカークオータを割り振り、どのワーカーが最も急ぎで 働かなければならないか (lbstatus が最大のもの) を調べます。 次に仕事をするようにこのワーカーを選択し、選択したワーカーの lbstatus を全体に割り振ったぶんだけ差し引きます。ですから、lbstatus の総量は 結果的に変化しません(*)し、リクエストは期待通りに分散されます。

あるワーカーが無効になっても、他のものは正常にスケジュールされ続けます。

for each worker in workers
    worker lbstatus += worker lbfactor
    total factor    += worker lbfactor
    if worker lbstatus > candidate lbstatus
        candidate = worker

candidate lbstatus -= total factor

バランサを次のように設定した場合:

worker a b c d
lbfactor 25 25 25 25
lbstatus 0 0 0 0

そして b が無効になった場合、次のようなスケジュールが 行われます。

worker a b c d
lbstatus -50 0 25 25
lbstatus -25 0 -25 50
lbstatus 0 0 0 0
(repeat)

つまりこのようにスケジュールされます: a c d a c d a c d ... 次の点に注意してください:

worker a b c d
lbfactor 25 25 25 25

この挙動は、次の設定と全く同じになります:

worker a b c d
lbfactor 1 1 1 1

This is because all values of lbfactor are normalized with respect to the others. For:

lbfactor は全て正規化されたもので、 他との相対値だからです。次の設定では:

worker a b c
lbfactor 1 4 1

ワーカー b は、平均して、ac の 4 倍の数のリクエストを受け持つことになります。

次のような非対称な設定では、こうなると予想されるでしょう:

worker a b
lbfactor 70 30
 
lbstatus -30 30
lbstatus 40 -40
lbstatus 10 -10
lbstatus -20 20
lbstatus -50 50
lbstatus 20 -20
lbstatus -10 10
lbstatus -40 40
lbstatus 30 -30
lbstatus 0 0
(repeat)

スケジュールは 10 スケジュール後に繰り返され、a 7 回と b 3 回でまばらに選ばれます。

top

Weighted Traffic Counting アルゴリズム

lbmethod=bytraffic で有効になります。 このスケジューラの背景にある考え方は、Request Counting と非常に似ていますが、次の違いがあります:

lbfactorどれだけのバイト数のトラフィック量を、 このワーカーに処理してもらいたいか を表します。 この値も同様に正規化された値で、ワーカー全体のうちでの "分担" 量を表現しています。リクエスト数を単純に数える代わりに、 どれだけの転送量を処理したかを数えます。

次のようにバランサを設定した場合:

worker a b c
lbfactor 1 2 1

b には ac の 2 倍 処理してほしいということになります。 b は 2 倍の I/O を処理するという意味になり、 2 倍のリクエスト数を処理するということにはなりません。 ですからリクエストとレスポンスのサイズが、 重み付けと振り分けのアルゴリズムに効いています。

top

バランサマネージャのサポートを有効にする

このモジュールは mod_status のサービスを 必要とします。 バランサマネージャを使うと、バランサのメンバーの動的な更新が できます。バランサマネージャを使って、バランス係数 (lbfactor) を変更したり、メンバーを変更したり、特定のメンバーを オフラインモードにしたりできます。

ですから、ロードバランサ管理機能を使いたければ、 mod_statusmod_proxy_balancer をサーバに組み込まなければなりません。

foo.com ドメインのブラウザからロードバランサ管理機能を 使えるようにするには、次のようなコードを httpd.conf に追加します。

<Location /balancer-manager>
SetHandler balancer-manager

Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>

こうすると、http://your.server.name/balancer-manager のページ経由で、ウェブブラウザからロードバランサマネージャに アクセスできるようになります。