Apache モジュール mod_proxy_balancer

翻訳済み言語: en | + fr | + ja

この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +

+ + + + +

説明:	負荷分散のための `mod_proxy` 拡張
ステータス:	Extension
モジュール識別子:	proxy_balancer_module
ソースファイル:	mod_proxy_balancer.c
互換性:	2.1 以降

概要

+ +

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

+ +

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

+ +

警告

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

ディレクティブ

このモジュールにディレクティブはありません。

Bugfix checklist

参照

mod_proxy
コメント

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

+ +

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

+ +

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 は、平均して、a と c + の 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 回でまばらに選ばれます。

Weighted Traffic Counting アルゴリズム

+ +

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

+ +

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

+ +

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

+ + + + + + + + + +

worker	a	b	c
lbfactor	1	2	1

+ +

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

+ +

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

+ +

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

+ +

ですから、ロードバランサ管理機能を使いたければ、 + mod_status と mod_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 + のページ経由で、ウェブブラウザからロードバランサマネージャに + アクセスできるようになります。