2012年8月の終わり、カナダ アルバータ州のある大学はそのインフラを OpenStack クラウドに移行した。幸か不幸か、サービスインから1～2日間に、彼らのサーバーの1台がネットワークから消失した。ビッ。いなくなった。
インスタンスの再起動後、全ては元通りに動くようになった。我々はログを見直し、問題の箇所（ネットワーク通信が止まり、全ては待機状態になった）を見た。我々はランダムな事象の原因はこのインスタンスだと判断した。
数日後、それは再び起こった。
我々はログのセットを両方見直した。頻発したログの１つは DHCP だった。OpenStack は（デフォルトで）DHCP リース期間を１分に設定する。これは、各インスタンスが固定 IP アドレスを更新するためにクラウドコントローラー（DHCP サーバー）に接続することを意味する。幾つかの理由で、このインスタンスはその IP アドレスを更新できなかった。インスタンスのログとクラウドコントローラー上のログを突き合わせ、並べてやりとりにしてみた。
インスタンスはIPアドレスを更新しようとする。
クラウドコントローラーは更新リクエストを受信し、レスポンスを返す。
インスタンスはそのレスポンスを「無視」して、更新リクエストを再送する。
クラウドコントローラーは２度めのリクエストを受信し、新しいレスポンスを返す。
インスタンスはクラウドコントローラーからのレスポンスを受信しなかったため、更新リクエストを
255.255.255.255に送信し始める。クラウドコントローラーは
255.255.255.255宛のリクエストを受信し、３番めのレスポンスを返す。最終的に、インスタンスはIPアドレス取得を諦める。
この情報により、我々は問題が DHCP 実行に起因するものと確信した。何らかの理由でインスタンスが新しいIPアドレスを取得できず、その結果IPアドレスがなくなり、インスタンスは自分自身をネットワークから切り離した、と考えた。
ちょっと Google 検索した結果、これを見つけた。VLAN モードでの DHCPリースエラー (https://lists.launchpad.net/openstack/msg11696.html) 。この情報はその後の我々の DHCP 方針の支えになった。
最初のアイデアは、単にリース時間を増やすことだった。もしインスタンスが毎週１回だけIPアドレスを更新するのであれば、毎分更新する場合よりこの問題が起こる可能性は極端に低くなるだろう。これはこの問題を解決しないが、問題を単に取り繕うことはできる。
我々は、このインスタンス上で tcpdump を実行して、操作で再びこの現象に遭遇するか見てみることにした。実際、我々はやってみた。
tcpdump の結果は非常に奇妙だった。一言で言えば、インスタンスが IP アドレスを更新しようとする前に、まるでネットワーク通信が停止しているように見えた。１分間のリース期間で大量の DHCP ネゴシエーションがあるため、確認作業は困難を極めた。しかし、パケット間のたった数ミリ秒の違いであれ、あるパケットが最初に到着する際、そのパケットが最初に到着し、そのパケットがネットワーク障害を報告した場合、DHCP より前にネットワーク障害が発生していることになる。
加えて、問題のインスタンスは毎晩非常に長いバックアップジョブを担っていた。「あの問題」（今では我々はこの障害をこう呼んでいる）はバックアップが行われている最中には起こらなかったが、（数時間たっていて）「あの問題」が起こるまであと少しのところだった。
それから何日か過ぎ、我々は「あの問題」に度々遭遇した。我々は「あの問題」の発生後、dhclient が実行されていないことを発見した。今、我々は、それが DHCP の問題であるという考えに立ち戻った。/etc/init.d/networking restart を実行すると、全ては元通りに実行されるようになった。
探し続けてきた Google の検索結果が突然得られたという事態をお分かりだろうか？えっと、それがここで起こったことだ。私は dhclient の情報と、何故 dhclient がそのリースを更新できない場合に死ぬのかを探していて、我々が遭遇したのと同じ問題についての OpenStack と dnsmasq の議論の束を突然発見した。
高負荷ネットワークと Dnsmasq における問題 (http://www.gossamer-threads.com/lists/openstack/operators/18197)
DHCPOFFER が無いために起動中のインスタンスが IP アドレスを失う問題 (http://www.gossamer-threads.com/lists/openstack/dev/14696)
マジ？Google。
このバグ報告は全ての鍵だった。
KVMイメージがブリッジネットワークで接続を失う (https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978)
レポートを読むのは楽しかった。同じ奇妙なネットワーク問題にあった人々であふれていたが、全く同じ説明はなかった。
つまり、これは qemu/kvm のバグである。
バグ報告を発見すると同時に、同僚が「あの問題」を再現することに成功した！どうやって？彼は iperf を使用して、インスタンス上で膨大なネットワーク負荷をかけた。30分後、インスタンスはネットワークから姿を消した。
パッチを当てた qemu と再現方法を携えて、我々は「あの問題」を最終的に解決したかを確認する作業に着手した。インスタンスにネットワーク負荷をかけてから丸48時間後、我々は確信していた。その後のことは知っての通りだ。あなたは、joe へのバグ報告を検索し、私のコメントと実際のテストを見つけることができる。
