ITインフラ技術の実験室ITインフラ技術の実験室Linuxを中心に、仮想化やネットワーク、Windowsまで、ITインフラ技術に関するノウハウを幅広く紹介します。Flash)はじめに前回の記事「IPVSでopenblocks600をロードバランサ化」ではリアルサーバのサービス監視、および、リアルサーバの障害検知時にロードバランス先からはずすことができなかったので、keepalivedを導入します。導入するkeepadlivedはIPVSおよびipvsadmのバージョン(1.2.1)と揃えるようにします。1.1.15-1でした。ipvsadmと同じ1.2.1が入れたいので、ipvsadmと同様に別途ソースからビルトします。!!!SSLのエラーが出ました。package」とありました。アーカイブを取得する必要があります。ディスク領域が新たに消費されます。librariesが無いと言われました。コマンドラインパラメータ解析用ライブラリlibpopt-devを入れてみます。アーカイブを取得する必要があります。ディスク領域が新たに消費されます。No三度目の正直で最後まで行きました。IPVSもYesになっています。InActConnipvsadmコマンドでバーチャルサーバ、リアルサーバを設定している場合は、keepadlived.confの設定とかぶってしまわないように一度クリアします。VIPの確認keepalivedのvrrp設定と被ってしまうため、/etc/network/interfaceに設定しているVIPを削除して再起動します。192.168.0.151OBS-ACT:~#設定ファイルの作成keepalived.confを作成します。本環境の場合、以下のパスに作成されていました。'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)が作成されます。メールサーバは11.11.11.11で、送付されるメールの件名には「LVS_DEVEL」が付与されます。ロードバランサの外側のIF(bond0.2)にVIP(192.168.0.151)を割り当てます。現段階ではVRRPはVIPの設定のためだけに使用するため、その他はデフォルト設定のままとします。VIP(192.168.0.151)の80番ポートへのアクセスをリアルサーバ1(172.16.0.2)とリアルサーバ2(172.16.0.3)に割り振るための設定です。パラメータについては別途、表で解説します。}}virtual_server設定のパラメータについて補足します。ヘルスチェック間隔(秒)。試験のため、少し大きめの値を指定。ヘルスチェックに失敗した際にweightを0にする。-Lnした際にリストから消える。1.2.1では動作しないようです(間違えていたらご指摘下さい)。[172.16.0.3:80]設定した値で反映されていることを確認します。0バーチャルサーバ、リアルサーバ、weightが設定通りであることを確認します。省略VIPがkeepalivedにより設定されたことを確認します。15秒間隔でリアルサーバに対してサービス監視を行っています。※delay_before_retryを指定しない場合、デフォルトの0秒となり、上記サービス監視間隔も10秒になっていました。障害試験(リアルサーバ1)リアルサーバ1のapacheを落とした際のロードバランサのサービス監視の動作について調べてみました。図で表すと以下のような動作をしていました。以下では、リアルサーバの障害発生時における、ロードバランサでのログや確認コマンドの見え方を紹介します。実施されるサービス監視パケットの周期で障害検知されます。同時に、notification_emailで指定した宛先に障害検知のメールが送出されました。実施されるサービス監視パケットの周期で障害検知され(17:13:07)、そのタイミングでリアルサーバ1(172.16.0.2)のWeightが0になり、リアルサーバ2(172.16.0.3)に切り替わりました。NGになっていました。0障害発生によりアクセスできなくなったリアルサーバ1に対しては、delay_before_retryで指定した5秒間隔でサービス監視が行われていました。サービス監視が行われていました。※delay_before_retryを指定しなかった場合、デフォルトの0になりますが、その場合、リアルサーバ1のDownを検知した後、リアルサーバ1と秒間1400発強のサービス監視パケットのやり取りが行われていました。delay_before_retryは必ず指定するようにした方がよさそうです。192.168.0.151Hitachiリアルサーバ2の方にアクセスが寄っています。復旧試験(リアルサーバ1)リアルサーバ1のapacheを起動した際のロードバランサのサービス監視の動作について調べてみました。以下では、ログや確認コマンドの見え方を紹介します。sent.リアルサーバ1に対するサービス監視周期(17:35:43)で復旧を検知しますが、ロードバランス対象に組み込まれるのはリアルサーバ2のサービス監視周期(17:35:53)でした。同時に、notification_emailで指定した宛先に障害復旧のメールが送出されました。017:35:53以降、リアルサーバ1(172.16.0.2)のWeightが1に戻りました。サービス監視が行われていました。192.168.0.151Hitachiリアルサーバ2の方にアクセスが寄っています。192.168.0.151Dellバランスしました。書いてあるとおり、keepalivedのような落ちた際の影響が大きいサービスはdaemontoolsでデーモンの稼動管理を行うことで、異常終了した際に自動的にデーモンを再起動できるようにした方がより良いと思います。keepalivedをdaemontoolsから起動するようにすることで、サーバ再起動時にも自動で立ち上がるようになります。daemontoolsについては次回の記事(daemontoolsでkeepalivedデーモンの稼動管理)で紹介します。コメントをキャンセルメールアドレスが公開されることはありません。