107
26

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 2019

Day 22

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

Last updated at Posted at 2019-12-21

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

これは 本番環境でやらかしちゃった人 Advent Calendar 2019 22日目です。昨日は rluisr さんによる遠い目になってしまう四コマ漫画でした。

tl;dr 兼 原因と対策

機器交換する際にはファームウェアバージョンを揃えましょう。
現在値だけでなくキャパシティも計測管理しましょう。

経過

予兆

10年以上前のお話です。たぶんフィクションです。
木曜日にお客様から「週末ちょっとトラフィック増えるかも」というご連絡がありました。

発生

何事も無く始まった土曜日... 昼過ぎになって出かけていた私の携帯電話が鳴りました。
「第2セグメントのサーバー2台の監視が断続的にエラーになっています。」

確かに接続しにくい状態になっていたのでオンサイトの準備を始めた時に再び電話が鳴ります。
「第1セグメントのサーバーすべての監視が通りません!」

調査

急いで駆けつけたもののとにかくネットワーク通信が重く調査が捗りません。状況的にネットワークトラブルだろうと目星は付くのですが...
管理運用に用いる内部セグメントは使用できたので、予告のあったお客様のサーバー群でHTTP/HTTPS通信が急増して影響していることまでは特定できました。

原因特定

セグメントが全断するほどの通信量ではないような。しかし現実にFirewallはリスタート後しばらくすると反応が無くなります。
ん、Firewall?
ログを調べたところ数週間前にFirewallを1台ずつ機器交換した際に、古いファームウェアバージョンのまま投入してしまい最大接続数のキャパシティが激減していたことが原因でした。

ないわーー

対応

予備機を持ってきてファームウェアアップデートを確認した上で投入し、第1セグメントの通信は復旧しました。

できていなかった対策、行った対策

そもそも数週間前のFirewall交換作業が失敗していたと言えます。
Firewallルールだけでなくファームウェアバージョンも確認しましょう。
また、設計値に余裕を持たせてあっても現在のセッション使用量だけでなくキャパシティ最大量も確認ないしモニタリングしましょう。この時のFirewallは、帯域やメモリにセッション数といった項目について最大数を示すEnterprise mibsが提供されていたのでSNMP経由で監視を行いました。
最大値というメトリクスを取得可能になっていますか?

加えるなら、普段そういうことを伝えてこないお客様が「"ちょっと"トラフィック増えるかも」とわざわざ伝えてくださった場合には話を大きめに受け止めて備えておきましょう。

補足

発生 のところでお気づきの方もいらっしゃると思いますが、この日最初のエスカレーション対象である「監視が不安定な2台」はこのFirewallとは異なる第2セグメントに存在していてこの時点でまだ復旧していません。

そう、この日はあと2つのセグメントが全断していくのですが
それを記すには余白とSAN値が足りません――

107
26
1

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
107
26

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?