今までも何度か触れてきた、IDCFクラウド環境のネットワーク問題。CentOS7インスタンスにLXCコンテナを作成して、そのコンテナを仮想ブリッジ経由でネットワークに繋げている。しかし、この仮想ブリッジ内のLXCコンテナがネットワーク的に不安定。例えばリモートのs3fsをマウントしようとするとコンテナが応答不能になってしまったり、別ノードのLXCコンテナとkeepalivedによるvrrp通信をさせようとすると応答不能になってしまったり。また、コンテナ再起動すると、しばらく外部と通信出来なくなるので、コンテナで複雑なことをやるのは二の足を踏んでいた。

しかし、なるべく自宅環境側と同じ構造を取らないと、chefのrecipeが複雑化してしまう。自宅のホストOSは最低限の仕事のみで、ほとんどのミドルウェアはLXCコンテナ上で動いている。この辺りの自宅環境とクラウド環境の違いがネックになり、作業効率が落ちてきたので本腰入れてクラウド環境のネットワーク問題を調べることに。不可思議な事象の中でも最も再現性の高い問題は再起動後のネットワーク不通問題。早い時はすぐに通信できるようになるが、遅いと数時間通信出来なかったりする。

この手の問題はとにかくarpから調べるのが経験則。LXCコンテナ再起動してホストOSからlxc-attachを使ってコンテナに接続する。そのコンテナから外のサーバに対してpingを打ってみるが届かない。ホストOS上でarpをtcpdumpするとarp requestはちゃんと聞こえてくる。ホストOSはそのmacアドレス情報を持っているので、LXCコンテナに対してarp replyを返している。しかし、そのarp replyが仮想ブリッジの内側にいるLXCコンテナには届かない。

LXCコンテナのネットワーク問題はarpが返ってこないためにmacアドレスを知ることが出来ず、いつまでも通信が出来ないというもの。うーん、arpの問題はGMOクラウドでも苦労した覚えがあるな。。。クラウド環境で仮想ブリッジを用意して、内側にノード作ったりするのはNGなのかな。しかし、IDCFクラウドの場合はしばらく放っておくと、arp replyが聞こえることもあるみたいで、いつの間にかmacアドレスを学習して、その後は安定した通信を行えるようになる。

ともあれ、何らかの回避方法を見つけないと運用しづら過ぎる。unicastのarp replyが聞こえないというのは、おそらくホストOSが仮想ブリッジの先に通信相手がいないと考えて、本来流すべきパケットを流していないだけ。全てのパケットを仮想ブリッジの内側に垂れ流せば、当然arp replyも届くはず。という訳で、仮想ブリッジのageing timeをゼロにしてみました。これで仮想ブリッジはポートの先にいるmacアドレスをキャッシュ出来なくなるので、全パケットを内側のノード全てに垂れ流すことになる。以下のコマンドをホストOS側で実行。

brctl setageing br0 0

この設定を入れることで仮想ブリッジの内側にもarp replyが届くようになって、コンテナ再起動後も速やかにmacアドレスを覚えてくれるようになった。s3fsの利用もkeepalivedのvrrpも問題なくなり、万々歳。とはいえ、この設定は内側のノード全てにパケットを垂れ流すことになるので、その意味はきちんと理解すること。うちの環境は1インスタンス当たり2コンテナで通信量もたかが知れているので、まあいいやというレベル。macアドレスを学習しきったら元の300秒設定に戻してもいいんだけど、忘れた頃に再起動したら障害状態になったので、もうゼロのままで放置。

vmware使ってると仮想ブリッジをarpが越えられないとか、他の人からも聞いたことあるんだけど、vmwareも何らかのホストOSに乗っているはずで、そもそもゲストOSとしてのvmwareの問題なのか、ホストOSとしてのvmwareの問題なのか判然としない。多分、前者な気がするけどね。同じ事情でぐぐってみてもゲストOSとしてのvmwareの問題ばかりで、ホストOSとしてのvmwareの仮想ブリッジ問題をどのように調べればよいやら。根本解決ではないんだけど、とりあえず回避できるようになったので、しばらくはageing timeゼロ設定で運用してみよう。