Apache HTTP サーバ バージョン 2.4

Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.4 > モジュール

# Apache モジュール mod_proxy_balancer

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

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

### 概要

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

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

### 警告

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

### トピック

- ロードバランサのスケジューラのアルゴリズム
- Request Counting アルゴリズム
- Weighted Traffic Counting アルゴリズム
- バランサマネージャのサポートを有効にする

### ディレクティブ

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

### Bugfix checklist

- httpd changelog
- Known issues
- Report a bug

### 参照

- `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` のページ経由で、ウェブブラウザからロードバランサマネージャに アクセスできるようになります。