Apache HTTP サーバ バージョン 2.5
Apache HTTP サーバ バージョン 2.5
| 説明: | 負荷分散のための mod_proxy 拡張 |
|---|---|
| ステータス: | Extension |
| モジュール識別子: | proxy_balancer_module |
| ソースファイル: | mod_proxy_balancer.c |
| 互換性: | 2.1 以降 |
本モジュールには mod_proxy が必要です。
HTTP, FTP と AJP13
プロトコルのロードバランス機能を持っています。
ですから、 ロードバランスを有効にする場合 mod_proxy
と mod_proxy_balancer がサーバに組み込まれて
いなければいけません。
安全なサーバにするまでプロクシ機能は有効にしないでください。 オープンプロキシサーバはあなた自身のネットワークにとっても、 インターネット全体にとっても危険です。
このモジュールにディレクティブはありません。
現時点では 2 種類のロードバランサスケジューラアルゴリズムから選べます。
リクエスト回数によるもの (訳注: Request Counting)
と、トラフィック量によるもの (訳注: Weighted Traffic Counting)
があります。バランサの設定 lbmethod 値で、どちらを使うか指定します。
詳細は Proxy ディレクティブを
参照してください。
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 回でまばらに選ばれます。
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
のページ経由で、ウェブブラウザからロードバランサマネージャに
アクセスできるようになります。