9
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

本番環境でやらかしちゃった人Advent Calendar 2021

Day 19

1セグメント全断の土曜日(Part3)

Last updated at Posted at 2021-12-19

これは 本番環境でやらかしちゃった人 Advent Calendar 2021 19日目です。昨日は debu-despot さんによる要件スコープとブラウザ環境に苦しむお話でした。

個人的には6日目の kaizen_nagoya さんによる「配電盤の電源を切る」を読んでから何かを思い出してしまい安眠と心の平穏が失われています。いえ、絶対書きません。もう忘れるんだ..僕決めたんだ..

tl;dr 兼 原因と対策

Outboundの通信のsource IP addressは確認しましょう
トリッキーな回避策を行う場合は影響(副作用)をしっかり洗い出しましょう
冷静な判断ができるように障害対応の体制は整えましょう

前回までのあらすじ

本投稿は 本番環境でやらかしちゃった人 Advent Calendar 2019 2020 からの連作となっております。2019では一つ目のセグメントが機器交換後の確認漏れにより、2020ではCDN経由でもオリジンサーバーが気を失うほどのアクセス過多により二つ目のセグメントが全断に至りました。しかし終わりではありません。

経過

第一セグメントが落ちた後、原因となったサーバーを切り離して調査していた段階では第一セグメントの復旧にはFirewallのエンジニアを呼び出す必要がありそうだと判断していました(並行して調査も行っていたので、2019で書いた通り最大同時接続数が縮退していたと後に判明したので結果的にFirewallに詳しいエンジニアを待たずに対処はできました)

そこで回線帯域もFirewall性能も当時一番ハイスペックな構成だった第三セグメントに該当サーバーを移設することで復旧を試みました。サーバーのIPアドレスとDNS Aレコードは第三セグメントのIPアドレスに変更します。さらに監視やシステム連携のために旧IPアドレス宛ての通信も残るのでコアスイッチ以下に/32でスタティックルートを第三セグメント宛てに向けてFirewallでNATさせることで旧IPアドレスでのアクセスも第三セグメントに流します。

セグメント移行作業は該当の全サーバーで完了し、動作確認も取れました。ウェブのアクセスを解放する前にいったんお客様へ連絡して動作確認をお願いします。

やれやれと一息ついたのもつかの間、お客様からは「途中から反応が無くなった」との連絡が入り、ほぼ同時に第三セグメントのサーバーすべての監視からアラートが飛んできまたのですっ

詳しい原因

トラフィックがループしていました...
・ホスティングサービスということでWebminのようなコンパネを提供していましたが、コンパネが旧アドレスにbindされた状態で起動していました

・お客様の複数のサーバーにまたがる操作をコンパネから行うと、サーバーから自発的に送信されるOutbound通信が発生します
 src:第一セグメント → dst:第三セグメント という通信が第三セグメントに移設したサーバーから発生
 L2レベルでdstへ到達した後、
 応答をsrcである第一セグメントのアドレスへ替えそうとするので当ホスティングサービスのセグメント間通信用のルートへ向かい、
 リクエストが無いのにリプライが来たと判定されて非対称通信がdenyされ、
 denyメッセージ(再送リクエストだったかもです。記憶が曖昧です)が追加した/32のルーティングで移設したサーバーへ返り、
 サーバーからは再送が行われ... という状況でした

復旧

第三セグメントはFirewallは落ちずにスイッチ配下の機器のみ監視が落ちている状態でした。現地ラックへ行き、まずは移設したサーバー達のケーブルをいったん抜き、次にLEDが真っ赤なL2スイッチ達を再起動してひとまず復旧しました。
スイッチは再起動してしまったので直近のログは見られなかったのですが、移設したサーバーを調べるとコンパネのログが異常に肥大化していました。内容を確認してbindアドレスを第三セグメントのものに変更して完全復旧しました。

反省点

grep "第一セグメントのプレフィックス" -r /etc

でIPアドレス変更作業後の確認を行ったため、/usr 以下にあったコンパネの設定ファイルを見落としたのが敗因でした。
また、作業後にも netstat を一度見ていれば気付けたと思います。
第一、第二セグメントの障害を捌きながら並行しての対応だったので漏れてしまいましたね...

さらなる反省点

土曜日だったとは言え私がインシデントコマンダーとアラートの通知受けと作業者を兼ねて捌いていたのも敗因でした。第三セグメントについては完全に作業の不備です。
第一セグメントのFirewallの復旧見込みが分からなかったので復旧を優先するとしても、コアスイッチに/32のルーティングを追加してまで行うこの対処はおそらくベストではなかったと思います。

補足

いろいろありましたが障害自体は復旧しました。
しかし山のようなアラートとお客様からのお問い合わせ(クレーム)が残っています。。。

次回、最終話「Leyer8の死闘、一斉連絡と一斉監視再開が招いたアラート倍増の怪」
できればもうカキタクナイデス

9
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?