ITインフラ技術の実験室ITインフラ技術の実験室Linuxを中心に、仮想化やネットワーク、Windowsまで、ITインフラ技術に関するノウハウを幅広く紹介します。Flash)はじめに前回の記事「keepalived(1.2.1)の導入」ではリアルサーバのサービス監視、および、リアルサーバの障害検知時にロードバランス先からはずす設定の確認を行いました。今回は、keepalivedでvrrpを動かし、ロードバランサを二重化します。MASTER/BACKUPが頻繁に切り替わったりダブルMASTERになったりと、非常に不安定な状態が続きましたが、最終的にはうまく動きましたので以下に設定及び確認内容を紹介します。不安定になった原因については、本記事の末尾に載せています。冗長化設定ネットワーク構成について下図の構成で検証しました。bondingやvlan多重しても動くことを見たいので、若干無理やりですがこのような構成にしています。冗長構成試験のため、Openblocks600はOBS-ACTとOBS-SBYの二台を用意しました。L2SWについてもc2940-ACTとc2940-SBYの二台を用意しました。OBS-ACTとc2940-ACT、OBS-SBYとc2940-SBYの間は二本のケーブルで接続し、OBSのeth0,1でbond0を構成しています。bond0をクライアント側とリアルサーバ側で論理的に分けるため、bond0.2(赤線:192.168.0.0/24)とbond0.10(青線:172.16.0.0/24)を作成しています。そのため、OBS~c2940間は4本接続しているように見えますが実際は二本になります。OBS-ACTとOBS-SBYは、各サブインタフェース(bond0.2、bond0.10)でVRRPを動作させており、MASTER側のOBSがVIPに対するARPに返答を行います。リアルサーバのARPテーブル上はVIP(172.16.0.3)のMACアドレスがOBS-ACTのMACアドレスになっており、クライアント端末のARPテーブルでもVIP(192.168.0.153)のMACアドレスもOBS-ACTのMACアドレスになっています。前回の記事「keepalived(1.2.1)の導入」の構成から変更をかけますので、一度keepalivedを止めます。/etc/service/keepalived本環境ではdaemontoolsを使用しておりますので、上記コマンドで停止させてから修正をかけます。}}ピンクの箇所がACT/SBYで異なる設定になります。ロードバランサの外側のIF(bond0.2)または内側のIF(bond0.10)のどちらかがダウンしたら、両側のIFがダウンするようにしています(vrrp_sync_group)。stateはOBS-ACTをMASTER、OBS-SBYをBACKUPとし、priorityはOBS-ACT>OBS-SBYとしています。preemptはデフォルトで有効のため、OBS-ACTがダウンしたらOBS-SBYに切り替わり、OBS-ACTがアップしたらOBS-ACTが再度MASTERになる動きをします。※こちらで紹介されているように、両系BACKUPにしてnopreemptにするとACT/SBY系で同じ設定にできるので、実際の運用ではMASTER/BACKUPはあまり使われていないかもしれません。real_serverの設定については前回の記事「keepalived(1.2.1)の導入」で取り上げていますので本記事では割愛します。上記設定をOBS-ACT/SBYで行った後、以下のコマンドでkeepalivedを立ち上げます。/etc/service/keepalivedクライアント端末からロードバランスの試験を行います。192.168.0.153Dellバランスしました。動作確認VRRPについて以下の右図のようなイメージで動作しています。上図の動きをtcpdumpにて確認します。150の224.0.0.18宛VRRPマルチキャストパケットを送出しています。OBS-SBY(BACKUP)は自分のpriority(100)よりも高いpriorityが聞こえてきているため黙っています。bytesオプションでvlan指定すると自発パケットは見えないようなので、以下のサブインタフェース指定を利用します。kernelACTから聞こえてくるVRRPパケットのpriorityの方が高いため、SBYからはパケット送出していません。kernelACTから聞こえてくるVRRPパケットのpriorityの方が高いため、SBYからはパケット送出していません。ARPについて数分観察した結果です。省略OBS-ACT(MASTER)は自分のIFアドレスに対するARPに加え、VIP(92.168.0.153)に対するARPにもreplyを返します。省略OBS-SBY(BACKUP)はVIPに対するARPには黙っています。障害試験OBS-ACTのbond0.10を落とします。投入時刻は21:31:30です。kernelbond0.10を閉塞した21:31:30を最後に、vrrpの送出がbond0.2、bond0.10の両系で止まりました(vrrp_sync_groupの効果が確認できました)。3回来なかったのを契機に)にOBS-SBYのbond0.2からvrrpの送出が開始されています。3回来なかったのを契機に)にOBS-SBYのbond0.10からvrrpの送出が開始されています。kernel自IFへのARPに対してしか反応していません。kernelOBS-ACTのbond0.10がダウンしてから3秒後(21:31:33)にGARPを送出し、その5秒後(21:31:38)に再度GARPを送出してL2SWのMACテーブルの書き換えを行っています。5秒遅れで送出しているのはkeepalived.confのgarp_master_delay設定を行っていないため、defaultの5秒がきいているからです。REACHABLEVIPのMACがOBS-SBYに変更されました。REACHABLEVIPのMACがOBS-SBYに変更されました。動的VIPのMACがOBS-SBYに変更されました。192.168.0.153DellOBS-SBY経由で正常動作しています。VRRPが不安定になった原因VRRPを最初に試した時、ロードバランス動作がうまくいったりいかなかったりというのが継続して発生していました。showを確認すると、VIPのMACが頻繁に切り替わっていました(ロードバランサのMASTER/BACKUPが頻繁に切り替わっているのが原因でした。)まず疑ったのはkeepalived.confの設定です。/usr/local/etc/keepalived/keepalived.confokOBS-SBY:~#残念ながら(?)、特に問題無しでした。相性が悪い?O’REILLYのサイトにはsub-ifはいけそうなことが書いてありますし、よかろうもん!さんのサイトのようにbondインタフェース使っている方もいるので、別問題な気がしますが...試しにeth0とeth1の構成にしてみましたが、やはり不安定なままでした。その後、1.2.1特有のバグかもしれないと思い、1.2.0に落としてみても事象は変わりませんでした。tcpdumpをしてみると、OBS-ACT/SBYともにVRRPを送出しており、SBY側がACTからのVRRPパケットを受け取れているにもかかわらず無視しているように見えました。ログを見てみると以下のようになっていました。advertで気付きBACKUPに戻るのですが、またMASTERになるというのを繰り返しています。マルチキャスト(2)にも類似事象が書かれていましたが少し様子が異なるようです。mode)、SBY側がBACKUPに推移していることに気付きました。mode)、なぜかMASTERに戻ってしまう。modeに推移するはずなのかもしれません。modeにしてしまえば正常動作しそうです。modeにして再度/var/log/messagesを確認したところ、正常動作になりました。リロードしても反映されるように設定します。modeに推移するのでしょうか?であれば、なぜ動かなかったのか?今度、時間ができた時にじっくりネットワークプログラミングの勉強をしてからソース読んで考えてみようと思います。コメントをキャンセルメールアドレスが公開されることはありません。