対象サーバについて
製品名 | OpenBlockS 600 |
OS(kernel ver) | Debian lenny(2.6.29) |
CPU | 600MHz(AMCC PowerPC 405EX) |
メモリ | 1GB(DDR2 SDRAM) |
ストレージ | 8GB(Compact Flash) |
はじめに
前回の記事「IPVSでopenblocks600をロードバランサ化」ではリアルサーバのサービス監視、および、リアルサーバの障害検知時にロードバランス先からはずすことができなかったので、keepalivedを導入します。
導入するkeepadlivedはIPVSおよびipvsadmのバージョン(1.2.1)と揃えるようにします。
OBS-ACT:~# aptitude show keepalived パッケージ: keepalived 状態: インストールされていません バージョン: 1.1.15-1 優先度: 特別 セクション: admin メンテナ: Alexander Wirt展開サイズ: 459k 依存: iproute, ipvsadm, libc6 (>= 2.7-1), libpopt0 (>= 1.10), libssl0.9.8 (>= 0.9.8f-1) 説明: Failover and monitoring daemon for LVS clusters keepalived is used for monitoring real servers within a Linux Virtual Server (LVS) cluster. keepalived can be configured to remove real servers from the cluster pool if it stops responding, as well as send a notification email to make the admin aware of the service failure. In addition, keepalived implements an independent Virtual Router Redundancy Protocol (VRRPv2; see rfc2338 for additional info) framework for director failover. You need a kernel >= 2.4.28 or >= 2.6.11 for keepalived. See README.Debian for more informations.
バージョン: 1.1.15-1でした。ipvsadmと同じ1.2.1が入れたいので、ipvsadmと同様に別途ソースからビルトします。
keepadlivedのインストール
ファイルのダウンロード
OBS-ACT:~# cd /usr/src/ OBS-ACT:/usr/src# ls ipvsadm-1.24 ipvsadm-1.24.tar.gz linux linux-source-2.6.26 linux-source-2.6.26.tar.bz2 OBS-ACT:/usr/src# wget http://www.keepalived.org/software/keepalived-1.2.1.tar.gz --2011-05-11 22:01:11-- http://www.keepalived.org/software/keepalived-1.2.1.tar.gz www.keepalived.org をDNSに問いあわせています... 188.165.36.82 www.keepalived.org|188.165.36.82|:80 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 239438 (234K) [application/x-gzip] `keepalived-1.2.1.tar.gz' に保存中 100%[===============================================================================>] 239,438 124K/s 時間 1.9s 2011-05-11 22:01:14 (124 KB/s) - `keepalived-1.2.1.tar.gz' へ保存完了 [239438/239438] OBS-ACT:/usr/src# tar xvf keepalived-1.2.1.tar.gz keepalived-1.2.1/ keepalived-1.2.1/configure.in keepalived-1.2.1/VERSION keepalived-1.2.1/AUTHOR keepalived-1.2.1/Makefile.in keepalived-1.2.1/configure keepalived-1.2.1/COPYING ... keepalived-1.2.1/doc/man/man8/ keepalived-1.2.1/doc/man/man8/keepalived.8 keepalived-1.2.1/doc/man/man5/ keepalived-1.2.1/doc/man/man5/keepalived.conf.5
Makeファイルの生成(1回目)
OBS-ACT:/usr/src# cd keepalived-1.2.1 OBS-ACT:/usr/src/keepalived-1.2.1# ./configure ... checking openssl/ssl.h usability... no checking openssl/ssl.h presence... no checking for openssl/ssl.h... no configure: error: !!! OpenSSL is not properly installed on your system. !!! !!! Can not include OpenSSL headers files. !!!
SSLのエラーが出ました。
こちらを参照したところ「You need to install the libssl-dev package」とありました。
依存関係で必要なパッケージのインストール
OBS-ACT:/usr/src/keepalived-1.2.1# aptitude install libssl-dev ... 以下の新規パッケージがインストールされます: libssl-dev zlib1g-dev{a} 更新: 0 個、新規インストール: 2 個、削除: 0 個、保留: 0 個。 2413kB のアーカイブを取得する必要があります。展開後に 6676kB のディスク領域が新たに消費されます。 先に進みますか? [Y/n/?] Y ...
Makeファイルの生成(2回目)
OBS-ACT:/usr/src/keepalived-1.2.1# ./configure ... checking for poptGetContext in -lpopt... no configure: error: Popt libraries is required
Opensslはクリアできましたが、今度はPopt librariesが無いと言われました。
依存関係で必要なパッケージのインストール
OBS-ACT:/usr/src/keepalived-1.2.1# aptitude search popt p libpopt-dev - コマンドラインパラメータ解釈用ライブラリ - 開発用ファイル i libpopt0 - コマンドラインパラメータ解析用ライブラリ
libpopt-devを入れてみます。
OBS-ACT:/usr/src/keepalived-1.2.1# aptitude install libpopt-dev ... 以下の新規パッケージがインストールされます: libpopt-dev 更新: 0 個、新規インストール: 1 個、削除: 0 個、保留: 0 個。 46.8kB のアーカイブを取得する必要があります。展開後に 147kB のディスク領域が新たに消費されます。
Makeファイルの生成(3回目)
OBS-ACT:/usr/src/keepalived-1.2.1# ./configure ... Keepalived configuration ------------------------ Keepalived version : 1.2.1 Compiler : gcc Compiler flags : -g -O2 Extra Lib : -lpopt -lssl -lcrypto Use IPVS Framework : Yes IPVS sync daemon support : Yes Use VRRP Framework : Yes Use Debug flags : No
三度目の正直で最後まで行きました。IPVSもYesになっています。
OBS-ACT:/usr/src/keepalived-1.2.1# make OBS-ACT:/usr/src/keepalived-1.2.1# make install
起動準備
ipvsadm の設定クリア
OBS-ACT:~# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.0.151:80 rr -> 172.16.0.3:80 Masq 1 0 0 -> 172.16.0.2:80 Masq 1 0 0 OBS-ACT:~# ipvsadm -C OBS-ACT:~# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn
ipvsadmコマンドでバーチャルサーバ、リアルサーバを設定している場合は、keepadlived.confの設定とかぶってしまわないように一度クリアします。
VIPの確認
keepalivedのvrrp設定と被ってしまうため、/etc/network/interfaceに設定しているVIPを削除して再起動します。
再起動前
OBS-ACT:~# ip addr show | grep 192.168.0.151 inet 192.168.0.151/24 brd 192.168.0.255 scope global secondary bond0.2:100
再起動後
OBS-ACT:~# ip addr show | grep 192.168.0.151 OBS-ACT:~#
設定ファイルの作成
keepalived.confを作成します。本環境の場合、以下のパスに作成されていました。
OBS-ACT:~# locate keepalived | grep 'keepalived$' /usr/local/etc/keepalived /usr/local/etc/rc.d/init.d/keepalived /usr/local/etc/sysconfig/keepalived /usr/local/sbin/keepalived /usr/src/keepalived-1.2.1/bin/keepalived /usr/src/keepalived-1.2.1/keepalived /usr/src/keepalived-1.2.1/keepalived/etc/keepalived
まだロードバランサは冗長化させていませんが、VIP設定のためだけにvrrpを動かします。
vrrpの詳細については別記事にまとめますのでここでは割愛します。
前回の記事「IPVSでopenblocks600をロードバランサ化」で構築したネットワークと同じ構成になりますので、再度構成図を載せておきます(唯一の差分は、前回はbond0.2:100を使用していましたが、今回はbond0.2に2つアドレスが設定されています)。
下記設定でbond0.2にVIP(192.168.0.151)が作成されます。
OBS-ACT:~vi /usr/local/etc/keepalived/keepalived.conf ! Configuration File for keepalived # 障害発生、復旧時にuser001@infra.jp宛にメールを送付するための設定 # メールサーバは11.11.11.11で、送付されるメールの件名には「LVS_DEVEL」が付与されます。 global_defs { notification_email { user001@infra.jp } notification_email_from user001@example.jp smtp_server 11.11.11.11 smtp_connect_timeout 30 router_id LVS_DEVEL } # ロードバランサの外側のIF(bond0.2)にVIP(192.168.0.151)を割り当てます。 # 現段階ではVRRPはVIPの設定のためだけに使用するため、その他はデフォルト設定のままとします。 vrrp_instance VI_1 { state MASTER interface bond0.2 virtual_router_id 1 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.0.151 dev bond0.2 } } # VIP(192.168.0.151)の80番ポートへのアクセスをリアルサーバ1(172.16.0.2)とリアルサーバ2(172.16.0.3)に割り振るための設定です。 # パラメータについては別途、表で解説します。 virtual_server 192.168.0.151 80 { delay_loop 10 lb_algo rr lb_kind NAT protocol TCP real_server 172.16.0.2 80 { weight 1 inhibit_on_failure HTTP_GET { url { path /index.html status_code 200 } connect_timeout 5 nb_get_retry 10 delay_before_retry 5 } } real_server 172.16.0.3 80 { weight 1 inhibit_on_failure HTTP_GET { url { path /index.html status_code 200 } connect_timeout 5 nb_get_retry 10 delay_before_retry 5 } } }
virtual_server設定のパラメータについて補足します。
delay_loop | ヘルスチェック間隔(秒)。試験のため、少し大きめの値を指定。 |
inhibit_on_failure | ヘルスチェックに失敗した際にweightを0にする。指定しない場合は設定から削除され、ipvsadm -Lnした際にリストから消える。 |
connect_timeout | リアルサーバからの応答が帰ってこない場合にタイムアウトするまでの時間 |
nb_get_retry | 本環境で試した限りでは、keepalived 1.2.1では動作しないようです(間違えていたらご指摘下さい)。 |
delay_before_retry | 後述 |
keepalivedの起動
OBS-ACT:~# /usr/local/sbin/keepalived -n -S 1 -f /usr/local/etc/keepalived/keepalived.conf --check --vrrp -d
-n | フォアグラウンドで動作 |
-S 1 | local 1でsyslogを送出 |
-f | 設定ファイルの指定 |
–check | IPVSとヘルスチェック機能を使用 |
–vrrp | VRRP機能を使用 |
-d | 起動ログをsyslogに含む |
起動ログの確認
OBS-ACT:~# tail -f /var/log/messages ... May 29 17:10:21 OBS-ACT Keepalived: Starting Keepalived v1.2.1 (05/11,2011) May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Registering Kernel netlink reflector May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Registering Kernel netlink command channel May 29 17:10:21 OBS-ACT Keepalived: Starting Healthcheck child process, pid=3775 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Opening file '/usr/local/etc/keepalived/keepalived.conf'. May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Configuration is using : 14764 Bytes May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: ------< Global definitions >------ May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Router ID = LVS_DEVEL May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Smtp server = 11.11.11.11 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Smtp server connection timeout = 30 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Email notification from = user001@example.jp May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Email notification = user001@infra.jp May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: ------< SSL definitions >------ May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Using autogen SSL context May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: ------< LVS Topology >------ May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: System is compiled with LVS v1.2.1 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: VIP = 192.168.0.151, VPORT = 80 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: delay_loop = 10, lb_algo = rr May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: protocol = TCP May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: alpha is OFF, omega is OFF May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: quorum = 1, hysteresis = 0 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: lb_kind = NAT May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: RIP = 172.16.0.2, RPORT = 80, WEIGHT = 1 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: -> Inhibit service on failure May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: RIP = 172.16.0.3, RPORT = 80, WEIGHT = 1 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: -> Inhibit service on failure May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: ------< Health checkers >------ May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: 172.16.0.2:80 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Keepalive method = HTTP_GET May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Connection timeout = 5 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Nb get retry = 10 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Delay before retry = 5 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Checked url = /index.html May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: HTTP Status Code = 200 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: 172.16.0.3:80 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Keepalive method = HTTP_GET May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Connection timeout = 5 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Nb get retry = 10 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Delay before retry = 5 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Checked url = /index.html May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: HTTP Status Code = 200 May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Using LinkWatch kernel netlink reflector... May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Activating healtchecker for service [172.16.0.2:80] May 29 17:10:21 OBS-ACT Keepalived_healthcheckers: Activating healtchecker for service [172.16.0.3:80]
設定した値で反映されていることを確認します。
※オプション指定しない場合、デフォルト値はNb get retry = 1、Delay before retry = 0になっていました。
IPVSの確認
OBS-ACT:~# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.0.151:80 rr -> 172.16.0.3:80 Masq 1 0 0 -> 172.16.0.2:80 Masq 1 0 0
バーチャルサーバ、リアルサーバ、weightが設定通りであることを確認します。
OBS-ACT:~# ip addr show 省略 5: bond0.2@bond0:mtu 1500 qdisc noqueue state UP link/ether 00:0a:85:04:02:ff brd ff:ff:ff:ff:ff:ff inet 192.168.0.150/24 brd 192.168.0.255 scope global bond0.2 inet 192.168.0.151/32 scope global bond0.2 inet6 fe80::20a:85ff:fe04:2ff/64 scope link valid_lft forever preferred_lft forever 省略
VIPがkeepalivedにより設定されたことを確認します。
監視パケットの確認
OBS-ACT:~# tcpdump -i bond0.10 ... 17:11:07.303166 IP 172.16.0.1.42242 > 172.16.0.2.www: S 261450665:261450665(0) win 584017:11:07.303367 IP 172.16.0.2.www > 172.16.0.1.42242: S 1394388730:1394388730(0) ack 261450666 win 5792 17:11:07.303496 IP 172.16.0.1.42242 > 172.16.0.2.www: . ack 1 win 183 17:11:07.303676 IP 172.16.0.1.43071 > 172.16.0.3.www: S 263912869:263912869(0) win 5840 17:11:07.303882 IP 172.16.0.3.www > 172.16.0.1.43071: S 3272694544:3272694544(0) ack 263912870 win 5792 17:11:07.304009 IP 172.16.0.1.43071 > 172.16.0.3.www: . ack 1 win 183 17:11:07.304294 IP 172.16.0.1.42242 > 172.16.0.2.www: P 1:78(77) ack 1 win 183 17:11:07.304473 IP 172.16.0.2.www > 172.16.0.1.42242: . ack 78 win 91 17:11:07.304733 IP 172.16.0.1.43071 > 172.16.0.3.www: P 1:78(77) ack 1 win 183 17:11:07.304931 IP 172.16.0.3.www > 172.16.0.1.43071: . ack 78 win 181 17:11:07.305260 IP 172.16.0.2.www > 172.16.0.1.42242: P 1:290(289) ack 78 win 91 17:11:07.305369 IP 172.16.0.1.42242 > 172.16.0.2.www: . ack 290 win 216 17:11:07.305466 IP 172.16.0.2.www > 172.16.0.1.42242: F 290:290(0) ack 78 win 91 17:11:07.305742 IP 172.16.0.3.www > 172.16.0.1.43071: P 1:281(280) ack 78 win 181 17:11:07.305872 IP 172.16.0.1.43071 > 172.16.0.3.www: . ack 281 win 216 17:11:07.305954 IP 172.16.0.3.www > 172.16.0.1.43071: F 281:281(0) ack 78 win 181 17:11:07.306668 IP 172.16.0.1.42242 > 172.16.0.2.www: R 78:78(0) ack 291 win 216 17:11:07.306907 IP 172.16.0.1.43071 > 172.16.0.3.www: R 78:78(0) ack 282 win 216 17:11:22.319157 IP 172.16.0.1.42244 > 172.16.0.2.www: S 504977370:504977370(0) win 5840 17:11:22.319341 IP 172.16.0.2.www > 172.16.0.1.42244: S 1633784292:1633784292(0) ack 504977371 win 5792 17:11:22.319466 IP 172.16.0.1.42244 > 172.16.0.2.www: . ack 1 win 183 17:11:22.319679 IP 172.16.0.1.43073 > 172.16.0.3.www: S 499279026:499279026(0) win 5840 17:11:22.319881 IP 172.16.0.3.www > 172.16.0.1.43073: S 3499732359:3499732359(0) ack 499279027 win 5792 17:11:22.320008 IP 172.16.0.1.43073 > 172.16.0.3.www: . ack 1 win 183 17:11:22.320293 IP 172.16.0.1.42244 > 172.16.0.2.www: P 1:78(77) ack 1 win 183 17:11:22.320454 IP 172.16.0.2.www > 172.16.0.1.42244: . ack 78 win 91 17:11:22.320716 IP 172.16.0.1.43073 > 172.16.0.3.www: P 1:78(77) ack 1 win 183 17:11:22.320913 IP 172.16.0.3.www > 172.16.0.1.43073: . ack 78 win 181 17:11:22.321231 IP 172.16.0.2.www > 172.16.0.1.42244: P 1:290(289) ack 78 win 91 17:11:22.321337 IP 172.16.0.1.42244 > 172.16.0.2.www: . ack 290 win 216 17:11:22.321440 IP 172.16.0.2.www > 172.16.0.1.42244: F 290:290(0) ack 78 win 91 17:11:22.321661 IP 172.16.0.3.www > 172.16.0.1.43073: P 1:281(280) ack 78 win 181 17:11:22.321779 IP 172.16.0.1.43073 > 172.16.0.3.www: . ack 281 win 216 17:11:22.321849 IP 172.16.0.3.www > 172.16.0.1.43073: F 281:281(0) ack 78 win 181 17:11:22.322306 IP 172.16.0.1.42244 > 172.16.0.2.www: R 78:78(0) ack 291 win 216 17:11:22.322590 IP 172.16.0.1.43073 > 172.16.0.3.www: R 78:78(0) ack 282 win 216 ...
delay_loop(10秒) + delay_before_retry(5秒) = 15秒間隔でリアルサーバに対してサービス監視を行っています。
※delay_before_retryを指定しない場合、デフォルトの0秒となり、上記サービス監視間隔も10秒になっていました。
障害試験(リアルサーバ1)
リアルサーバ1のapacheを落とした際のロードバランサのサービス監視の動作について調べてみました。
図で表すと以下のような動作をしていました。
以下では、リアルサーバの障害発生時における、ロードバランサでのログや確認コマンドの見え方を紹介します。
リアルサーバ1(Dell)で発生させた障害内容
障害を発生させた時刻:17:12:56
dell:/var/www/priv# /etc/init.d/apache2 stop dell:~# cat /var/log/apache2/error.log | grep "May 29 17" [Sun May 29 17:12:56 2011] [notice] caught SIGTERM, shutting down
ロードバランサ(Openblocks600)での見え方
【syslog確認】
OBS-ACT:~# tail -f /var/log/messages ... May 29 17:13:07 OBS-ACT Keepalived_healthcheckers: Error connecting server [172.16.0.2:80]. May 29 17:13:07 OBS-ACT Keepalived_healthcheckers: Disabling service [172.16.0.2:80] from VS [192.168.0.151:80] May 29 17:13:07 OBS-ACT Keepalived_healthcheckers: Remote SMTP server [11.11.11.11:25] connected. May 29 17:13:07 OBS-ACT Keepalived_healthcheckers: SMTP alert successfully sent.
障害発生後、最初に実施されるサービス監視パケットの周期で障害検知されます。
同時に、notification_emailで指定した宛先に障害検知のメールが送出されました。
------------------------------------------------------ 件名:[LVS_DEVEL] Realserver 172.16.0.2:80 - DOWN 本文:=> CHECK failed on service : connection error <= ------------------------------------------------------
【状態確認】
確認した時間(1回目):17:13:00
OBS-ACT:~# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.0.151:80 rr -> 172.16.0.3:80 Masq 1 0 0 -> 172.16.0.2:80 Masq 1 0 0
確認した時間(2回目):17:13:10
OBS-ACT:~# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.0.151:80 rr -> 172.16.0.3:80 Masq 1 0 0 -> 172.16.0.2:80 Masq 0 0 0
障害発生後、最初に実施されるサービス監視パケットの周期で障害検知され(17:13:07)、そのタイミングでリアルサーバ1(172.16.0.2)のWeightが0になり、リアルサーバ2(172.16.0.3)に切り替わりました。
つまり、リアルサーバ1の障害発生からweightが0になるまでの11秒間(17:12:56~17:13:07)、Webアクセスが50% NGになっていました。
【監視パケットの確認(リアルサーバ1に対するサービス監視)】
OBS-ACT:~# tcpdump -i bond0.10 | grep 172.16.0.2 17:13:12.431150 IP 172.16.0.1.42261 > 172.16.0.2.www: S 2222793298:2222793298(0) win 584017:13:12.431315 IP 172.16.0.2.www > 172.16.0.1.42261: R 0:0(0) ack 2222793299 win 0 17:13:17.435175 IP 172.16.0.1.42262 > 172.16.0.2.www: S 2305325799:2305325799(0) win 5840 17:13:17.435345 IP 172.16.0.2.www > 172.16.0.1.42262: R 0:0(0) ack 2305325800 win 0 17:13:22.439695 IP 172.16.0.1.42264 > 172.16.0.2.www: S 2383819599:2383819599(0) win 5840 17:13:22.439825 IP 172.16.0.2.www > 172.16.0.1.42264: R 0:0(0) ack 2383819600 win 0
障害発生によりアクセスできなくなったリアルサーバ1に対しては、delay_before_retryで指定した5秒間隔でサービス監視が行われていました。
【監視パケットの確認(リアルサーバ2に対するサービス監視)】
OBS-ACT:~# tcpdump -i bond0.10 17:13:22.439151 IP 172.16.0.1.43091 > 172.16.0.3.www: S 2384705350:2384705350(0) win 584017:13:22.439387 IP 172.16.0.3.www > 172.16.0.1.43091: S 1097309304:1097309304(0) ack 2384705351 win 5792 17:13:22.439513 IP 172.16.0.1.43091 > 172.16.0.3.www: . ack 1 win 183 17:13:22.440234 IP 172.16.0.1.43091 > 172.16.0.3.www: P 1:78(77) ack 1 win 183 17:13:22.440449 IP 172.16.0.3.www > 172.16.0.1.43091: . ack 78 win 181 17:13:22.441182 IP 172.16.0.3.www > 172.16.0.1.43091: P 1:281(280) ack 78 win 181 17:13:22.441322 IP 172.16.0.1.43091 > 172.16.0.3.www: . ack 281 win 216 17:13:22.441389 IP 172.16.0.3.www > 172.16.0.1.43091: F 281:281(0) ack 78 win 181 17:13:22.441843 IP 172.16.0.1.43091 > 172.16.0.3.www: R 78:78(0) ack 282 win 216 17:13:37.455145 IP 172.16.0.1.43095 > 172.16.0.3.www: S 2622664537:2622664537(0) win 5840 17:13:37.455370 IP 172.16.0.3.www > 172.16.0.1.43095: S 1342340126:1342340126(0) ack 2622664538 win 5792 17:13:37.455499 IP 172.16.0.1.43095 > 172.16.0.3.www: . ack 1 win 183 17:13:37.456207 IP 172.16.0.1.43095 > 172.16.0.3.www: P 1:78(77) ack 1 win 183 17:13:37.456428 IP 172.16.0.3.www > 172.16.0.1.43095: . ack 78 win 181 17:13:37.457149 IP 172.16.0.3.www > 172.16.0.1.43095: P 1:281(280) ack 78 win 181 17:13:37.457287 IP 172.16.0.1.43095 > 172.16.0.3.www: . ack 281 win 216 17:13:37.457372 IP 172.16.0.3.www > 172.16.0.1.43095: F 281:281(0) ack 78 win 181 17:13:37.457827 IP 172.16.0.1.43095 > 172.16.0.3.www: R 78:78(0) ack 282 win 216
サービス稼働中のリアルサーバ2に対しては、通常時と同じ delay_loop(10秒) + delay_before_retry(5秒) = 15秒間隔 でサービス監視が行われていました。
※delay_before_retryを指定しなかった場合、デフォルトの0になりますが、その場合、リアルサーバ1のDownを検知した後、リアルサーバ1と秒間1400発強のサービス監視パケットのやり取りが行われていました。
delay_before_retryは必ず指定するようにした方がよさそうです。
クライアントからのcurlの見え方
障害発生前
C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Dell C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Dell
障害発生後
C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Hitachi
リアルサーバ2の方にアクセスが寄っています。
復旧試験(リアルサーバ1)
リアルサーバ1のapacheを起動した際のロードバランサのサービス監視の動作について調べてみました。
以下では、ログや確認コマンドの見え方を紹介します。
リアルサーバ1(Dell)で復旧させた際の手順
障害を復旧させた時刻:17:35:42
dell:/var/www/priv# /etc/init.d/apache2 start dell:~# cat /var/log/apache2/error.log | grep "May 29 17" [Sun May 29 17:35:42 2011] [notice] Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny10 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g configured -- resuming normal operations
ロードバランサ(Openblocks600)での見え方
【syslog確認】
OBS-ACT:~# tail -f /var/log/messages ... May 29 17:35:43 OBS-ACT Keepalived_healthcheckers: HTTP status code success to [172.16.0.2:80] url(1). May 29 17:35:53 OBS-ACT Keepalived_healthcheckers: Remote Web server [172.16.0.2:80] succeed on service. May 29 17:35:53 OBS-ACT Keepalived_healthcheckers: Enabling service [172.16.0.2:80] to VS [192.168.0.151:80] May 29 17:35:53 OBS-ACT Keepalived_healthcheckers: Remote SMTP server [11.11.11.11:25] connected. May 29 17:35:54 OBS-ACT Keepalived_healthcheckers: SMTP alert successfully sent.
リアルサーバ1に対するサービス監視周期(17:35:43)で復旧を検知しますが、ロードバランス対象に組み込まれるのはリアルサーバ2のサービス監視周期(17:35:53)でした。
同時に、notification_emailで指定した宛先に障害復旧のメールが送出されました。
------------------------------------------------------ 件名:[LVS_DEVEL] Realserver 172.16.0.2:80 - UP 本文:=> CHECK succeed on service <= ------------------------------------------------------
【状態確認】
確認した時間(1回目):17:35:48
OBS-ACT:~# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.0.151:80 rr -> 172.16.0.3:80 Masq 1 0 0 -> 172.16.0.2:80 Masq 0 0 0
確認した時間(2回目):17:35:57
OBS-ACT:~# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.0.151:80 rr -> 172.16.0.3:80 Masq 1 0 0 -> 172.16.0.2:80 Masq 1 0 0
17:35:53以降、リアルサーバ1(172.16.0.2)のWeightが1に戻りました。
【監視パケットの確認(リアルサーバ1 に対するサービス監視)】
OBS-ACT:~# tcpdump -i bond0.10 | grep 172.16.0.2 17:35:33.731146 IP 172.16.0.1.48258 > 172.16.0.2.www: S 1788441283:1788441283(0) win 584017:35:33.731310 IP 172.16.0.2.www > 172.16.0.1.48258: R 0:0(0) ack 1788441284 win 0 17:35:38.735673 IP 172.16.0.1.48260 > 172.16.0.2.www: S 1876230320:1876230320(0) win 5840 17:35:38.735819 IP 172.16.0.2.www > 172.16.0.1.48260: R 0:0(0) ack 1876230321 win 0 17:35:43.743132 IP 172.16.0.1.48261 > 172.16.0.2.www: S 1953143528:1953143528(0) win 5840 17:35:43.743330 IP 172.16.0.2.www > 172.16.0.1.48261: S 3081547033:3081547033(0) ack 1953143529 win 5792 17:35:43.743469 IP 172.16.0.1.48261 > 172.16.0.2.www: . ack 1 win 183 17:35:43.743813 IP 172.16.0.1.48261 > 172.16.0.2.www: P 1:78(77) ack 1 win 183 17:35:43.743975 IP 172.16.0.2.www > 172.16.0.1.48261: . ack 78 win 91 17:35:43.744754 IP 172.16.0.2.www > 172.16.0.1.48261: P 1:290(289) ack 78 win 91 17:35:43.744867 IP 172.16.0.1.48261 > 172.16.0.2.www: . ack 290 win 216 17:35:43.744968 IP 172.16.0.2.www > 172.16.0.1.48261: F 290:290(0) ack 78 win 91 17:35:43.745726 IP 172.16.0.1.48261 > 172.16.0.2.www: R 78:78(0) ack 291 win 216 17:35:58.755144 IP 172.16.0.1.48264 > 172.16.0.2.www: S 2185129138:2185129138(0) win 5840 17:35:58.755348 IP 172.16.0.2.www > 172.16.0.1.48264: S 3319760435:3319760435(0) ack 2185129139 win 5792 17:35:58.755490 IP 172.16.0.1.48264 > 172.16.0.2.www: . ack 1 win 183 17:35:58.756899 IP 172.16.0.1.48264 > 172.16.0.2.www: P 1:78(77) ack 1 win 183 17:35:58.757113 IP 172.16.0.2.www > 172.16.0.1.48264: . ack 78 win 91 17:35:58.757883 IP 172.16.0.2.www > 172.16.0.1.48264: P 1:290(289) ack 78 win 91 17:35:58.758014 IP 172.16.0.1.48264 > 172.16.0.2.www: . ack 290 win 216 17:35:58.758115 IP 172.16.0.2.www > 172.16.0.1.48264: F 290:290(0) ack 78 win 91 17:35:58.758610 IP 172.16.0.1.48264 > 172.16.0.2.www: R 78:78(0) ack 291 win 216
障害中はdelay_before_retryで指定した5秒間隔でサービス監視が行われていましたが、復旧後はdelay_loop(10秒) + delay_before_retry(5秒) = 15秒間隔 に戻りました。
【監視パケットの確認(リアルサーバ2に対するサービス監視)】
OBS-ACT:~# tcpdump -i bond0.10 17:35:38.735130 IP 172.16.0.1.52199 > 172.16.0.3.www: S 1869725881:1869725881(0) win 584017:35:38.735412 IP 172.16.0.3.www > 172.16.0.1.52199: S 577662942:577662942(0) ack 1869725882 win 5792 17:35:38.735547 IP 172.16.0.1.52199 > 172.16.0.3.www: . ack 1 win 183 17:35:38.736226 IP 172.16.0.1.52199 > 172.16.0.3.www: P 1:78(77) ack 1 win 183 17:35:38.736442 IP 172.16.0.3.www > 172.16.0.1.52199: . ack 78 win 181 17:35:38.737160 IP 172.16.0.3.www > 172.16.0.1.52199: P 1:281(280) ack 78 win 181 17:35:38.737299 IP 172.16.0.1.52199 > 172.16.0.3.www: . ack 281 win 216 17:35:38.737372 IP 172.16.0.3.www > 172.16.0.1.52199: F 281:281(0) ack 78 win 181 17:35:38.737822 IP 172.16.0.1.52199 > 172.16.0.3.www: R 78:78(0) ack 282 win 216 17:35:53.747142 IP 172.16.0.1.52202 > 172.16.0.3.www: S 2104206084:2104206084(0) win 5840 17:35:53.747379 IP 172.16.0.3.www > 172.16.0.1.52202: S 810728531:810728531(0) ack 2104206085 win 5792 17:35:53.747515 IP 172.16.0.1.52202 > 172.16.0.3.www: . ack 1 win 183 17:35:53.749093 IP 172.16.0.1.52202 > 172.16.0.3.www: P 1:78(77) ack 1 win 183 17:35:53.749297 IP 172.16.0.3.www > 172.16.0.1.52202: . ack 78 win 181 17:35:53.750033 IP 172.16.0.3.www > 172.16.0.1.52202: P 1:281(280) ack 78 win 181 17:35:53.750170 IP 172.16.0.1.52202 > 172.16.0.3.www: . ack 281 win 216 17:35:53.750257 IP 172.16.0.3.www > 172.16.0.1.52202: F 281:281(0) ack 78 win 181 17:35:53.750734 IP 172.16.0.1.52202 > 172.16.0.3.www: R 78:78(0) ack 282 win 216 17:36:08.767166 IP 172.16.0.1.52205 > 172.16.0.3.www: S 2332610470:2332610470(0) win 5840 17:36:08.767397 IP 172.16.0.3.www > 172.16.0.1.52205: S 1044166212:1044166212(0) ack 2332610471 win 5792 17:36:08.767529 IP 172.16.0.1.52205 > 172.16.0.3.www: . ack 1 win 183 17:36:08.769315 IP 172.16.0.1.52205 > 172.16.0.3.www: P 1:78(77) ack 1 win 183 17:36:08.769547 IP 172.16.0.3.www > 172.16.0.1.52205: . ack 78 win 181 17:36:08.770229 IP 172.16.0.3.www > 172.16.0.1.52205: P 1:281(280) ack 78 win 181 17:36:08.770383 IP 172.16.0.1.52205 > 172.16.0.3.www: . ack 281 win 216 17:36:08.770455 IP 172.16.0.3.www > 172.16.0.1.52205: F 281:281(0) ack 78 win 181 17:36:08.771678 IP 172.16.0.1.52205 > 172.16.0.3.www: R 78:78(0) ack 282 win 216
サービス稼働中のリアルサーバ2に対しては、通常時と同じ delay_loop(10秒) + delay_before_retry(5秒) = 15秒間隔 でサービス監視が行われていました。
クライアントからのcurlの見え方
復旧前
C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Hitachi
リアルサーバ2の方にアクセスが寄っています。
復旧後
C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Dell C:\Users\abc>curl 192.168.0.151 Hitachi C:\Users\abc>curl 192.168.0.151 Dell
バランスしました。
keepalivedの起動シェルについて
今回、keepalivedをソースからビルトしたため、サーバ起動時にサービス開始させるためには別途起動シェル(/etc/init.d/keepalived)を作成する必要がありますが、[24時間365日] サーバ/インフラを支える技術やこんなに簡単! Linuxでロードバランサ (1) でも書いてあるとおり、keepalivedのような落ちた際の影響が大きいサービスはdaemontoolsでデーモンの稼動管理を行うことで、異常終了した際に自動的にデーモンを再起動できるようにした方がより良いと思います。
keepalivedをdaemontoolsから起動するようにすることで、サーバ再起動時にも自動で立ち上がるようになります。
daemontoolsについては次回の記事(daemontoolsでkeepalivedデーモンの稼動管理)で紹介します。