ARP変動?初めて聞く言葉。Flux」と呼ばれる現象であるらしい。1台のマシンに同一セグメントのIPが振られている複数のNICがあると、ARP取得用のブロードキャストの応答が変になってARPテーブルのMACアドレスがおかしくなる現象、らしい。仮想マシンを構成する場合1物理サーバ内に同一セグメントの仮想NICが(仮想ブリッジ含めて)複数生成されることもあるため、表面化する可能性が高まるっぽい。ARPテーブルがおかしくなるとゆーことは、すなわち通信対象となるMACアドレスが変な方に向いているとゆーこと。仮に発生すればそりゃTCPパケットが行方不明ぽくなっても不思議ではない。ARPテーブルはNIC毎に保持されるので障害発生時に特定のNIC側に発生するのも説明できる。こんな現象であればより頻発してても不思議ではないが、ARPテーブルならば定期的にクリアされるだろうしおかしければ再要求もされるだろうから状況によっては自動復旧されてたのだろうと推察。対処としては「arp_filter」を有効にすること。ARP要求に対してより厳密に確認するためのパラメータぽい。=1」を/etc/sysctl.confに記述)。念の為にcronで1分毎にARPテーブルをログ保存するよう仕掛ける。発生orzしかしこれはむしろ「設定が生きたから」ではないかと推察。これまでが変な状態だったのだろうと。それがARPテーブルの更新のタイミングでより厳密に処理されるようになった結果、エラーとして顕在化したのではないかと。三度仮想ルータを再起動→通信復旧した後、前述のARPログを見てみると、ちょうど障害が発生したタイミングでいくつかの通信対象が「Incomplete」となっており、復旧していない事を確認。「Incomplete」はarpコマンドで強制的にテーブルから削除した場合に瞬間的に発生しうる状態だが、普通はその後(接続時に)再要求が行われてすぐ復旧する。数分に渡ってIncompleteの状態になるのはさすがに異常。元々の障害時も似たような状態だったのだろうと推察。その後数十日間上記の状態で稼働を続けたが、通信周りの障害発生なし。念のためARPテーブルも確認し続けているがIncompleteは発生していない。これで多分収束したものと思われる。まー仮想ルータやら仮想ブリッジやら半自動でゴテゴテ作るCloudStackなので、いずれこーゆー「1物理サーバ(というか物理NIC)に割り当てられた複数の仮想NIC」的なところで問題が発生しても不思議じゃないかなぁとぼんやりと推察していたところもある。Flux」という特定問題のヒントがあったのである程度絞れたが、ホントに1物理サーバ内で論理ネットワークを無視した変な通信し始められたら正直お手上げだよなぁ、とか漠然とオモタ。CloudStack、KVMに限らずあらゆる仮想基盤で言えることだと思うが。追記:残念ながらその後もarp消失に伴う事例が発生中。上記arp_filterを設定しきれてない物理NICもあるので(※でも運用中なのでヘタに設定できない)とりあえずarp_filterの設定に一定の効果はあるものと思う。最近CloudStackのシステムVMのバージョンが2014.06頃に上がった事を確認。取り急ぎ検証環境でシステムVMの入れ替え→仮想ルータの初期化を実行。数日経過したけどとりあえず目に見えた異常はなし。見たとこサービスのアップデートはそれほど顕著ではないが、ベースとなるOSが32bitの他64bitも選択できるようになった。前回までは32bit一択だった気がするので例えばメモリ的な処理限界に起因するものだとしたらこれでだいぶ改善される可能性もある。名前から想像されるもの。