てんこ

ブログ名は愛猫(てん)の愛称です。中身は個人のIT系学習記録です。

ARPロックタイムで発生した障害

まあよくあるARP関連のお話。

トポロジは大体こんな感じ。実際はもうちょい複雑。draw.io便利ですね。 f:id:tatematsu_san:20190703211117j:plain

障害の概要

  • ある冗長化されている機器のメンテナンス作業で発生
  • ダウンタイムを減らすために手動フェイルオーバーさせながら作業
  • テスト環境での事前試験は問題なくクリア
  • 手動フェイルオーバーを実施した時点でシステムがアクセス不能
  • 最終的にロールバック

障害時の症状

  • その機器で提供されているIPのうち、大多数はアクセス不可
  • ごく一部がアクセス可能

周辺機器とのARP関連かなあと想像はつきましたが、差分が出るのがよくわからず追加調査実施。

障害時のキャプチャデータ解析結果

  • システムで必要なIPは「機器の物理MACで提供する」設定となっている
  • フェイルオーバーさせた機器からのGARPは問題なく出ている
  • GARPは届いていたものの、対向機器はフェイルオーバー前のMAC(前機器)へ通信
  • 前機器としてはフェイルオーバーしたつもりでいるためアクセスできてもサービス提供はしていない(Active/Standby構成)

予想通り、ARP関連だと判明。ただ、GARP出てたのでそこが解せない点。

根本原因

  • 対向機器側の仕様と作業タイミングの問題

    • 対向側機器は、「自発的にARPエントリされたものをARPリクエストする」動作仕様
    • 対向機器は「ARPテーブル更新後1秒はロックタイムで更新されない」という動作仕様
    • 対向機器のロックタイム以内に作業対象機器のフェイルオーバーによるGARPが来たが、仕様によりARP情報を更新できず
    • このため、ARPで差分が発生しシステム停止につながった
  • ほぼ全IPでARPエントリが崩れたのは、その前のフェイルオーバーで同じように全IPのGARPが流れていて、エージングタイムが揃っていたため

    • 難を逃れたARPは、対向機器が自発的に通信にいくアドレスだった
    • 自発的に通信に行った結果、エージングタイムがずれて難を逃れた

反省

  • やはり冗長化関連はフェイルオーバーの挙動を完全に抑えた上で設計するべき
  • 今回の障害は仮想MAC使えば発生しなかったが、このあたりも取捨選択
  • ARPの自発更新は予想外

悩ましい点

こういうのって、Ansible、特にTower/AWXとかで自動化しても起こるんですよね。設計時点で可能な限りリスク潰すしかないんですが、やっぱり唐突にこれが起こるとAnsible頼みではどうしようもないので、基本と応用力、判断力は大事。

このへんは、効率化系ツールの弊害で、育たなくなるところだよなあ。どうすればいいんだろうか。