この章では、高度な Linux ルーティングとトラフィックの帯域制限に 関連のあるプロジェクトを紹介します。 このうちのいくつかは、これまでの章で既に紹介していたかもしれません。 あるいは他に HOWTO を必要としないくらい、 自前で非常に良く文書化されているものもあります。
VLAN はネットワークを物理的ではなく仮想的に集合させる、 非常に賢いやり方です。VLAN に関する優れた情報は こちら にあります。この実装を使うと、Linux に VLAN をしゃべらせ、 Cisco Catalyst, 3Com: {Corebuilder, Netbuilder II, SuperStack II switch 630}, Extreme Ntwks Summit 48, Foundry: {ServerIronXL, FastIron} などと会話させることができます。
VLAN に関する素晴らしい HOWTO が こちら にあります。
更新: 2.4.14 (多分 13) ではカーネルに含まれています。
Linux 用 VLAN の別の実装です。 このプロジェクトは「権威ある」VLAN プロジェクトのアーキテクチャや コーディングスタイルに対する意見の相違からスタートし、 より全体の設計を見通し良くすることを狙ったものです。
この人たちは最高です。Linux Virtual Server は、 本物のサーバのクラスタ上に、 Linux OS で動作するロードバランサを使って構築する、 非常にスケーラブルかつ高品位なサーバです。 クラスタのアーキテクチャはエンドユーザに対して透過的で、 エンドユーザは単に一台の仮想サーバを見ることになります。
要するに、何か負荷分散したいものがあったら、 それがどんなレベルのトラフィックでも、LVS にはそれを行う能力があるのです。 彼らのテクニックは良い意味で邪悪です! 例えば、複数のマシンにあるセグメント内で同じ IP アドレスを持たせ、 それらに対する ARP を無効にするのです。LVS マシンだけが ARP を行い - そして到着パケットの処理をどのバックエンドホストが行うかを決め、 直接そのバックエンドサーバの MAC アドレスへとパケットを送るのです。 外向きのトラフィックは直接ルータへ流れ、LVS マシンは経由しません。 よって LVS マシンは世界へ向けた 5Gbit/s のコンテンツのフローを 見る必要はなく、よってボトルネックにもなりません。
LVS は Linux 2.0, 2.2 ではカーネルパッチとして実装されていますが、 2.4/2.5 では netfilter のモジュールになっていますので、 カーネルパッチ必要はありません。 2.4 サポートはまだ開発の初期段階ですので、是非いじくり回して、 フィードバックやパッチを送ってください。
CBQ の設定は、ちょっとやる気をくじかれるところがあります。 特に、やりたいことが単にルータの背後のコンピュータをいくつか絞りたいだけ、 というような場合にはなおさらです。 CBQ.init は、Linux の設定をより単純な文法で可能にしてくれます。
例えば、(10mbit eth1 につながった) 192.168.1.0/24 サブネットの すべてのコンピュータに対し、ダウンロードの速度を 28kbit/s に制限したければ、 次の内容を CBQ.init の設定ファイルに書くだけです:
DEVICE=eth1,10Mbit,1Mbit RATE=28Kbit WEIGHT=2Kbit PRIO=5 RULE=192.168.1.0/24 |
「なぜ、どのように」という内容に興味がなければ、 絶対にこのプログラムを使うべきです。私たちは製品で CBQ.init を使っていますが、 非常にうまく動作しています。 時刻に依存した帯域制限といったような、より高度な設定も可能です。 文書はスクリプトに埋め込まれており、これが README が見つからない理由です。
Stephan Mueller (smueller@chronox.de) は 2 つの便利なスクリプトを書きました。 'limit.conn' と 'shaper' です。'limit.conn' を使うと、 あるひとつのダウンロードセッションを手軽に絞れます。 こんな感じです:
# limit.conn -s SERVERIP -p SERVERPORT -l LIMIT |
Linux 2.2 と 2.4/2.5 で動作します。
'shaper' の方はより複雑で、 たくさんの異なるキューを、iptables のルールをもとにして作れます。 iptables は絞りたいパケットに印を付けるのに使います。
これは純粋に冗長性 (redundancy) のためのものです。 IP アドレスと MAC アドレスが同じ 2 台のマシンを用いて、 さらに別の IP アドレスと MAC アドレスを持った、仮想的なマシンを作ります。 もともとは (常に同じ MAC アドレスを必要とする) ルータ向けのものだったのですが、他のサーバでも使えます。
このアプローチの美点は、信じられないくらい設定が簡単なことです。 カーネルのコンパイルもパッチ当ても必要なく、すべてはユーザ空間です。
次のコマンドを、サービスに参加するすべてのマシンで実行するだけです:
# vrrpd -i eth0 -v 50 10.0.0.22 |
これで出来上がり! この時点で 10.0.0.22 はどれかひとつのサーバ (多分最初に vrrp デーモンを実行したやつ) が保有します。 ここでそのコンピュータをネットワークから切り離すと、 非常にすばやく他のコンピュータが 10.0.0.22 と その MAC アドレスとを引き継ぎます。
私は手元で試してみて、1 分で動作させることができました。 何かおかしな理由で、デフォルトゲートウェイの情報が消えてしまったのですが、 -n フラグを付ければこれは回避できました。
これはフェイルオーバーの「ライブ画像」です:
64 bytes from 10.0.0.22: icmp_seq=3 ttl=255 time=0.2 ms 64 bytes from 10.0.0.22: icmp_seq=4 ttl=255 time=0.2 ms 64 bytes from 10.0.0.22: icmp_seq=5 ttl=255 time=16.8 ms 64 bytes from 10.0.0.22: icmp_seq=6 ttl=255 time=1.8 ms 64 bytes from 10.0.0.22: icmp_seq=7 ttl=255 time=1.7 ms |
ping パケットはひとつも失われていません! 4 番目のパケットの後、私は P200 をネットワークから切り離したのですが、 486 が引き継ぎました。よって遅延が大きくなっていることがわかります。
tc_config は linux 2.4 以降でのトラフィック制御を RedHat システム と (おそらく) その派生システムで行うためのスクリプト集です (linux 2.2.X と ipchains とでのものは古くなっています)。 ルートには cbq qdisc を、葉には sfq qdisc を使っています。
snmp でトラフィック制御の統計を取るため、 snmp_pass ユーティリティが含まれています。