The Greased Turkey Document [1]
or
How to set up a load-sharing server

Release History: 0.01alpha - Rob Thomas - rob@rpi.net.au [Bootstrap of the documentation]

This document was written with [homepage link] ippvs version 0.5 and Linux Kernel [kernel.org link] 2.0.35 in mind.

1: Overview

このドキュメントは ippvs が何をするか、どのように動作するか、どのようにセットアップするかの基礎をカバーしています。私はこれがわかりやすい man や FAQ になって広まることを期待しています。

2: 何をするのですか?

ippvs は複数のバーチャルサーバーに NAT のようなスタイルで負荷分散を提供するカーネル修正です。 例をあげれば、"listening" 状態になっているサーバーが、クライアントからの接続要求を他のサーバーに向けることです。これの利点は冗長性のある負荷分散サーバーを提供することです。
これの良い例はとても低いコストで、クラスタリング負荷分散プロキシサーバーをセットアップすることです。クラスタリング負荷分散プロキシサーバーは普通のWEB トラフィックや TCP や UDP を使ったほとんどのサービスに適しています。ですが唯一使えないのがFTP サービスです。FTPサービスは、どのIPとPORT番号をクライアントが使っているかなどが関係してきて、NATシステムを使っているクラスタリング負荷分散プロキシサーバーの場合、不都合が生じてしまうからです。

3: どのように動くのか?

このドキュメントにあるとおり、私たちはクライアントに物理的に1つのマシンとして見える冗長性のあるプロキシサーバーをセットアップしようとしています。 最初にあなたはどのようなネットワーク構成になっているかを理解するべきです。 [2]

                                    [ ---  HUB  --- ]
   [proxy server 1]<-eth0------------+ | | | | | | +--------eth0->[proxy server 4]
   [proxy server 2]<-eth0--------------+ | | | | +----------eth0->[proxy server 5]
   [proxy server 3]<-eth0----------------+ | | +------------eth0->[proxy server 6]
                                           | |
                                           | |
                                           | +--eth1->[ippvs server 0]<-eth0-------...local network...
                                           +----eth1->[ippvs server 1]<-eth0-------...local network...


[I realise that I use a -very- wide screen, so that'll probably look like crap on a 80x24 display - looks good on a 128x24 8)]

このネットワーク図を見てください。いくつかのことに気づくと思います。

1: プロキシサーバーは LAN として接続されていません。それらはひとつひとつ LAN から離れています。
2: ippvs サーバーを経由したネットワークの残りのマシン同士は接続されています。このようにしてデフォルトルートを確認します。

この場合のマシンのIPアドレスは以下のとおりです:
ippvs server 0:
   eth0:  203.1.1.2  [マシンのIPアドレス]
   eth0:0 203.1.1.10 [負荷分散のIPアドレス]
   eth0:1 203.1.1.11 [ippvs1 が落ちているときだけ使う - 普段は使わない]
   eth1:  10.1.1.254 [プライベートIPアドレス - ルーティングではなく、プロキシサーバーが見るためだけに使う]
   eth1:0 10.1.1.253 [ippvs1 が落ちているときだけ使う - 普段は使わない]
ippvs server 1:
   eth0:  203.1.1.3  [マシンのIPアドレス]
   eth0:0 203.1.1.11 [負荷分散のIPアドレス]
   eth0:1 203.1.1.10 [ippvs0 が落ちているときだけ使う - 普段は使わない]
   eth1:  10.1.1.253 [プライベートIPアドレス - ルーティングではなく、プロキシサーバーが見るためだけに使う]
   eth1:0 10.1.1.254 [ippvs0 が落ちているときだけ使う - 普段は使わない]
proxy server 1:
   eth0: 10.1.1.1 
   default route to 10.1.1.254
proxy server 2:
   eth0: 10.1.1.2 
   default route to 10.1.1.254
proxy server 3:
   eth0: 10.1.1.3 
   default route to 10.1.1.254
proxy server 4:
   eth0: 10.1.1.4 
   default route to 10.1.1.253
proxy server 5:
   eth0: 10.1.1.5 
   default route to 10.1.1.253
proxy server 6:
   eth0: 10.1.1.6 
   default route to 10.1.1.253
これは少し複雑そうに思える。だが、もしあなたが冗長性のあるネットワークに興味を持ってなかったら、2つ目の ippvs は必要ないし、プロキシサーバーも半分にすることができる。



IPアドレス 203.1.1.10 でポート番号8080 のクライアントマシンからくるパケットを追跡しましょう Lets track a packet that's coming from a client machine, to port 8080 on 203.1.1.10.

Header: Request connection to port 8080 on 203.1.1.10 from 203.2.3.4 port 9999

最初に起こることは、IPアドレス 203.1.1.10 がヘッダをロックして、負荷分散しているポートを知る。ippvs0 は送るマシンを選び、ヘッダに記憶しておき、パケットの行き先アドレス(送り先アドレスは変換しない)を変換させる。

Header: Request connection to port 8080 on 10.1.1.2 from 203.2.3.4 port 9999

IPアドレス10.1.1.2 のマシンはコネクションを許可し、データを送り返す:

Header: Connection accept, 203.2.3.4 port 9999, and here's the data, love from 10.1.1.2 port 8080.

デフォルトルートと逆に向かったアドレスは ippvs0 です。そして元のヘッダを戻してパケットを送る。

Header: Connection accept, 203.2.3.4 port 9999, and here's the data, love from 203.1.1.10 port 8080.

クライアントは舞台裏で魔法が使われていないかのように普通にIPアドレス 203.1.1.10 、ポート番号8080でコネクションを張る。


4: どのようにセットアップしますか?

唯一のセットアップ方法は実際の ippvs サーバーを作ることです。 あなたはプライベートLANのためにIPアドレスを選ぶ必要があります。 このドキュメントは先ほど指定したIPアドレスを使って設定の真似をしています だからあなたがこれを真似する理由はまったくありません だから IPアドレスで 10.x.x.x の変わりに 192.168.x.x でもまったく同じです。
On ippvs0:
  ipfwadm -F -a m 10.1.2.0/24 -D 0.0.0.0/0 (?? No descrption of '-a m' in man ipfwadm?)
  ippfvsadm -A -t 203.1.1.10:8080 -R 10.1.1.1:8080  - Redirect _T_CP connections to 203.1.1.10:8080 to 10.1.1.1:8080
  ippfvsadm -A -t 203.1.1.10:8080 -R 10.1.1.2:8080  - and 10.1.1.2:8080
  ippfvsadm -A -t 203.1.1.10:8080 -R 10.1.1.3:8080  - and 10.1.1.3:8080

On ippvs1:
  ipfwadm -F -a m 10.1.2.0/24 -D 0.0.0.0/0 (?? No descrption of '-a m' in man ipfwadm?)
  ippfvsadm -A -t 203.1.1.11:8080 -R 10.1.1.1:8080  - Redirect _T_CP connections to 203.1.1.11:8080 to 10.1.1.4:8080
  ippfvsadm -A -t 203.1.1.11:8080 -R 10.1.1.2:8080  - and 10.1.1.5:8080
  ippfvsadm -A -t 203.1.1.11:8080 -R 10.1.1.3:8080  - and 10.1.1.6:8080

あなたがやらなければいけないことはこれだけです。あなたが IPアドレス 203.1.1.10 か 203.1.1.11 のポート番号 8080 にコネクションを張った時、それは機械的に誰にも気づかれないうちに、ランダムなマシンにリダイレクトされているでしょう。 負荷を分散するために使われるアルゴリズムはいろいろあります。 ここでアルゴリズムについて述べるのはこのドキュメントの範囲外でしょう。

5: ケアレスミスしないための注意事項

ippvs サーバーへのクライアントマシンのデフォルトルートをいつも確認しなさい これだけは忘れないで!

6: どのように動作するのか?

高い有効性を得ることはそんなには難しくない。何度か試した時、私はひと組のスクリプトとマシンの消息を知っているデータベースを自動的にリダイレクションリストから削除してみた。そして他のマシンが(例えば ippvs1)が失敗した他のippvs から仕事を引き継ぐのである。それはマニュアルどおりやれば簡単だ。 ippvs0 が使えなくなったら他のマシンで'ifup eth0:1' と 'ifup eth1:0'を実行すればよい。 また他のマシンでもやっているように ippfvsadm コマンドを実行しなさい。 そうすれば気がつかないうちに仕事を引き継いでいるでしょう。 私が何をいっているかわからなくなったら、上のIPアドレス表をみなさい。

このドキュメントについて質問、コメント、提案がありましたら rob@rpi.net.au まで送ってください
バーチャルサーバーメーリングリストは現在linux-virtualserver@iinchina.net で運営されています。 メーリングリストを購読したかったらメールの本文(サブジェクトではありませんよ)に'subscribe'と書いて 'majordomo@iinchina.net' に送ってください。 以上、細心の注意を払いましょう。

--Robert Thomas - 28/11/98

[1] - Kernel versions 2.1.129 and 2.1.130 have earned themselves the names of 'Greased Weasel' and 'Basted Turkey', due to some light-hearted banter of Linus Torvalds in the kernel release notes. This document was prepared over these two kernel revisions!
[2] - This is an 'optimal' diagram. There's no -physical- reason why the ippvs server, the clustered machines, and the clients can't be on the same segment. It's just nicer this way. Go buy a $50 hub. Trust us. It's better.