keepalived(1.2.1)の導入

投稿者: | 2011年5月29日
Pocket

対象サーバについて

製品名 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つアドレスが設定されています)。

openblocks600でロードバランサ

下記設定で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 5840 
17: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を落とした際のロードバランサのサービス監視の動作について調べてみました。

図で表すと以下のような動作をしていました。

障害発生時のkeepalivedサービス監視の仕組み

以下では、リアルサーバの障害発生時における、ロードバランサでのログや確認コマンドの見え方を紹介します。

リアルサーバ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 5840 
17: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 5840 
17: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を起動した際のロードバランサのサービス監視の動作について調べてみました。

障害復旧時のkeepalivedサービス監視の仕組み

以下では、ログや確認コマンドの見え方を紹介します。

リアルサーバ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 5840 
17: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 5840 
17: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デーモンの稼動管理)で紹介します。

参考文献

[24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

Ubuntu Forum

こんなに簡単! Linuxでロードバランサ (1)

こんなに簡単! Linuxでロードバランサ (2)

Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です