2007/01/16
過去最大の障害ｷﾀｺﾚ
里ワンオフ眠ミミの購入権獲得後も特に大きな反動もなく今回は大丈夫かな？と思ってた矢先に来ましたよ。
まずは昼過ぎにウイルス発生。
しかし何時もと様子は違い、最終的な作業終了時刻はなんと翌日早朝 4時。
# ウイルス拡散防止のため特定のファイルの拡張子は隔離、対応パターンが出た時点でウイルスチェックしながら放流。
これだけでも十分地雷だが、その間にサーバー障害発生。
こっちは 20時20分頃から 26時過ぎ頃までだったが、障害内容が痛すぎる。
なんと 4,000通ほどのメールキューを抱えたままクラッシュしてダウン。
ping も飛びませんよえぇ。
しかも SDS (SunDiskSuite) でミラーしてるディスクは、シリアル繋いで最後に吐いていたコンソールログを見る限りではどっちも死んでるみたい。
最悪朝日を見る可能性もあったが、最終的にはバックプレーンの交換でリストア作業は回避。
どっちも死んでいたと思われたのは、バックプレーンの故障により両方のディスクのオンライン・オフラインが繰り返されたことにより双方でエラーが発生したため。
d5 は d15/d25 = Maintenance/Last errer になっていたので、
しかし Last Erred の方はちょっと面倒で、Maintenance 側を切断・接続して再構築した後、今度は Last Erred 側を切断・接続して再構築を行わないと、ミラーセットがいつまで経っても Needs Maintenance になったままになる。
ちなみにサブミラーのステータスは、
# 概要だけなら他の Solaris でも同じ。
胃が痛かった一番の原因は、なんといってもメールキュー 4,000通が配送されないまま残っていたこと。
こいつらが消えたらメールロストとなり、ごめんなさいじゃ済まない大事になる可能性も。
# メールシステムというのは「遅延はあるが、サーバー管理者のポリシーを除けば必ず (送信者か受信者に) 届くシステム」なので、届かないのは大問題です。
メールキューそのものは FC で接続された外部ディスクにあるから消えることはないと思うが、リストア作業が発生したときにオペミスで消えてしまうことも考えられるので安心は出来ない。
最終的には問題なく再処理も出来たので良かったが、過去数年における仕事の中でも第 1位の胃が痛くなる障害ですた。
幸福と不幸の等価交換、恐るべし。((((;ﾟДﾟ))))
まずは昼過ぎにウイルス発生。
しかし何時もと様子は違い、最終的な作業終了時刻はなんと翌日早朝 4時。
# ウイルス拡散防止のため特定のファイルの拡張子は隔離、対応パターンが出た時点でウイルスチェックしながら放流。
これだけでも十分地雷だが、その間にサーバー障害発生。
こっちは 20時20分頃から 26時過ぎ頃までだったが、障害内容が痛すぎる。
なんと 4,000通ほどのメールキューを抱えたままクラッシュしてダウン。
ping も飛びませんよえぇ。
しかも SDS (SunDiskSuite) でミラーしてるディスクは、シリアル繋いで最後に吐いていたコンソールログを見る限りではどっちも死んでるみたい。
最悪朝日を見る可能性もあったが、最終的にはバックプレーンの交換でリストア作業は回避。
どっちも死んでいたと思われたのは、バックプレーンの故障により両方のディスクのオンライン・オフラインが繰り返されたことにより双方でエラーが発生したため。
d5 は d15/d25 = Maintenance/Last errer になっていたので、
# d5 ミラーセット (個々のディスクを合わせた RAID 構成のこと) から d15 サブミラー (早い話、個々のディスク) を切断接続したら勝手に再構築を始めるので、metastat [ミラーセット名] で進捗状況を確認。
# metadetach -f d5 d15
# d5 ミラーセットに新しい d15 サブミラーを接続
# metattach d5 d15
しかし Last Erred の方はちょっと面倒で、Maintenance 側を切断・接続して再構築した後、今度は Last Erred 側を切断・接続して再構築を行わないと、ミラーセットがいつまで経っても Needs Maintenance になったままになる。
ちなみにサブミラーのステータスは、
- Okay：
問題なし。
- Maintenance：
真っ先に交換すべき対象。
- Last Erred：
エラーが発生しながらも I/O 処理が続いている状態。
複数の (RAID-1 では全ての、かも) ディスクで障害が発生している時にこのステータスになる。
# 同時に複数 (全て？) のディスクで障害が発生するとどっちも Maintenance になるのかも。
この場合は Last Erred のディスクで I/O 処理が続いているので、先に Maintenance のディスクを交換してミラーを再構築した後、Last Erred のディスクを交換してミラーを再構築を行うこと。
でないと Last Erred のディスクで I/O 処理が続いていたので、その間のデータが失われる。
# 概要だけなら他の Solaris でも同じ。
胃が痛かった一番の原因は、なんといってもメールキュー 4,000通が配送されないまま残っていたこと。
こいつらが消えたらメールロストとなり、ごめんなさいじゃ済まない大事になる可能性も。
# メールシステムというのは「遅延はあるが、サーバー管理者のポリシーを除けば必ず (送信者か受信者に) 届くシステム」なので、届かないのは大問題です。
メールキューそのものは FC で接続された外部ディスクにあるから消えることはないと思うが、リストア作業が発生したときにオペミスで消えてしまうことも考えられるので安心は出来ない。
最終的には問題なく再処理も出来たので良かったが、過去数年における仕事の中でも第 1位の胃が痛くなる障害ですた。
幸福と不幸の等価交換、恐るべし。((((;ﾟДﾟ))))
- tsh：ウイルスはどうしようもないにしても（そもそも作成する人間が悪いので）
未配送メールをロストはサービスの信用性問題に発展してしまいますものね、、、（鬱
復旧お疲れ様でした。 - 窓枠：ドクロうさまでした・・・。
OSはDS使ってるって事はSol8かなんかですか。
（9以降はSVMがあるので）
キューが外部にあるって事はミラー（？）してたのはシステム部ですか。
#止まってたのならFC切り離し（umount？）してから作業すれば
#もちっと（気は）楽だったのかなーとか他人事風味に思ったり。
まぁ障害の当事者の苦労は良く分かってるつもりですがw
#去年末から障害対応ばっか・・・昨日も・・・ - Ｇ兄：OSはSol.8、ミラーしてるのはシステム部。
そういやリストアするときに FC のケーブル引っこ抜いておけばいいんですな。
その手があったか・・・・。
# どうせ FC のエリアにはメールキューしか入ってないし。 - Ｇ兄：あ、ちなみにメールサーバー群は複数台でミラーしてるので、サービスの影響はありませんでした。
- あぞっち：ぬお〜、当事者ではないが、読んでる方も胃が痛くなる虎舞竜ですな；；
RSS 1.0
1行板
Web日記帳 "さくら" for MySQL
presented by K.O.T.B.GRIFFON (GRIFFON Works)
presented by K.O.T.B.GRIFFON (GRIFFON Works)
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ 山銀
└ Ｇ兄