技術評論社から出版されている「24時間365日サーバ/インフラを支える技術」をみていて、 LVSとkeepalivedが紹介されていました。 debian系のパッケージにはkeepalivedは登録されていますし、手軽に使えそうです。
今回はkeepalivedを使ったHAクラスタを構成してみます。
VMWare Workstation 6.5上にDebian lennyのインスタンスを3つ立ち上げて、 keepalivedの挙動をみてみました。
サーバー構成
VMWare WorkstationではTeamを組む事でネットワークカードとハブを仮想的に追加できるので、 この手のテストには向いています。
特にネットワークセグメントは分離せずに独立した一つのサブネットワークの中に、2台のサーバ(10.0.0.2, 10.0.0.3)と1台のクライアント(10.0.0.x)を作成しました。 サーバで共有するVirtual_IPは10.0.0.1にしています。
keepalivedの設定
まずはapt-getでパッケージが導入しました。
$ sudo apt-get install keepalived
設定ファイルを配置する/etc/keepalivedディレクトリが作成されますが、中身は空です。 本に書かれているように、keepalived.confファイルを準備してみます。
vmweb01mの/etc/keepalived/keepalived.confファイル
vrrp_instance VI {
state MASTER
interface eth1
garp_master_delay 5
virtual_router_id 200
priority 101
advert_int 1
authentication {
auth_type PASS
auth_pass XXXXXX
}
virtual_ipaddress {
10.0.0.1/24 dev eth1
}
}片側のvmweb02mにファイルをコピーして、priority 100にだけ変更しておきます。
keepalivedの起動
keepalived.confファイルを配置するとリブートすると起動するようになります。 今回は手動で起動します。
$ sudo /etc/init.d/keepalived start
挙動の確認
keepalivedが起動してからnetstatやifconfigなどで調べても、VIPの10.0.0.1はサーバー上に設定されていません。 ipvsadmの設定も空です。
$ sudo /usr/sbin/ipvsadm -L
ipvsadm -Lコマンドの出力
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConnMACアドレスを変更しているのだろうとあたりをつけて、 クライアント側からインタフェースがどのように変更されるのか確認してみました。
$ sudo apt-get install arp-scan
arpコマンドでも良いのですが、動的に変更されるとは限らないのでarp-scanを準備しました。 同一サブネット(10.0.0.0/24)に所属しているクライアントからコマンドを実行します。
$ sudo arp-scan -I eth1 10.0.0.1 10.0.0.2 10.0.0.3
arp-scanコマンド出力
10.0.0.1 00:0c:29:c1:7b:47 VMware, Inc.
10.0.0.2 00:0c:29:c1:7b:47 VMware, Inc.
10.0.0.3 00:0c:29:71:34:69 VMware, Inc.この出力からIPアドレス10.0.0.1が、10.0.0.2のMACアドレスに属している事がわかります。 10.0.0.2, 10.0.0.3は両サーバのeth1に定義されています。
プライマリ側のkeepalivedを停止
再起動しても良いのですが、ここではkeepalivedを停止する事で接続断を演出してみます。
$ sudo /etc/init.d/keepalived stop
10.0.0.2でのkeepalived停止後のarp-scan出力
10.0.0.1 00:0c:29:71:34:69 VMware, Inc.
10.0.0.2 00:0c:29:c1:7b:47 VMware, Inc.
10.0.0.3 00:0c:29:71:34:69 VMware, Inc.次に10.0.0.2のkeepalivedを起動して、10.0.0.1がどちら側に移動するか確認します。
$ sudo /etc/init.d/keepalived start
10.0.0.2でのkeepalived起動後のarp-scan出力
10.0.0.1 00:0c:29:c1:7b:47 VMware, Inc.
10.0.0.3 00:0c:29:71:34:69 VMware, Inc.
10.0.0.2 00:0c:29:c1:7b:47 VMware, Inc.この設定だとpriorityの高い側に自動的に寄るようですね。
pingを使ったパケットロスの確認
keepalivedの切り替えが発生するタイミングでpingを10.0.0.1に送っていると次のようになりました。
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.200 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.226 ms
64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=3.93 ms
64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=0.411 ms
64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=0.213 ms
64 bytes from 10.0.0.1: icmp_seq=9 ttl=64 time=0.275 ms
64 bytes from 10.0.0.1: icmp_seq=11 ttl=64 time=0.377 ms
64 bytes from 10.0.0.1: icmp_seq=12 ttl=64 time=0.457 ms
...
--- 10.0.0.1 ping statistics ---
13 packets transmitted, 11 received, 15% packet loss, time 12048ms
...結果としてicmp_seq=5, icmp_seq=10の2つのパケットが取りこぼされています。 仮想MACアドレスが使えれば、パケットの取りこぼしはなくなると思うんですけどね…。
Apacheを使った挙動の確認
準備作業
とりあえず10.0.0.2と10.0.0.3の両方にapacheをインストールします。
$ sudo apt-get install apache2-mpm-worker
導入した直後にプロセスが起動して、80番ポートで通信を受け付けるはずです。
HTTPサーバのモニター
再送とかタイムアウトの設定とかなしで、かなり乱暴ですが、telnetコマンドを使って80番ポートにアクセスしてみます。 ここでkeepalivedを片側だけ停止しておきます。
$ telnet 10.0.0.1 80
Trying 10.0.0.1...
Connected to vmwebcl01.example.org.
Escape character is '^]'.次にkeepalivedを停止してから、telnetコマンドを同じように実行します。
$ telnet 10.0.0.1 80
Trying 10.0.0.1...
しばらく停止しているので、ここで最初から停止していたkeepalivedを起動します。 するとプロンプトが表われるので、HTTPプロトコルを送信します。
Trying 10.0.0.1...
Connected to vmwebcl01.example.org.
Escape character is '^]'.
HEAD / HTTP/1.0
...2回目のtelnetコマンドを実行してすぐに通信が途切れないのはTCPレベルで再送が行なわれているからですが、telnetコマンドを実行した時点では直近で起動していたkeepalivedのホストのMACアドレスを覚えています。
最後にkeepalivedを起動した時には、新しく10.0.0.1のMACアドレスとして通知された側に接続しています。 表面上は少し待たされたものの、何事もなかったのかのように処理が進みます。
まとめ
keepalivedを上げ下げする時には、途中でarp-scanを実行したり、tcpdumpの"-w"オプションで経過をファイルに保存しておいて、別マシンのwiresharkで表示してみるとSYNパケットが繰り返し送信されている様子をみる事ができると思います。 現場ではarpかarp-scanぐらいしか使えないかもしれないですが、 学習目的ではtcpdumpとwiresharkは使えると便利ですし楽になるはずです。
ICMPパケットはロストしますが、TCP/IPは再送で救われる場面がありそうです。 現場での疎通確認をpingだけに頼っていると、ちょっと見誤ることはあるかもしれません。 もっともこの構成だと救われるのは新規のコネクションに限定した話しで、既存のコネクションは切れてしまうのが悩みどころです。
keepalivedは簡単にVirtual-IPを設定できるという点では便利だと思います。 冗長化するためのツールとしてはheatbeatも有名で豊富な機能を提供していますが、ちょっと面倒なようです。
0 件のコメント:
コメントを投稿