「ご契約のサーバについて、少し相談させていただきたいことがございます」と言われた日

今日はこのブログが入っている RAID というか HDD が変な壊れ方をして、ホスティングを頼んでいるさくらの担当者といろいろやりとりしながらやっと復旧できたので、その顛末をメモ。金曜日の夜に限って障害が発生するというのは、この業界のマーフィーの法則のようなものですが、仕事用のサーバでなくて、プライベートのサーバでやられてしまうとは思いませんでした。さくらの中のひとにとっては、まさしくそんな感じだったのかも知れないですけど。

こういうことがあるから、RAID 構成だからってバックアップ取らなくても良いわけではないということを身をもって再認識。

† 10:42: port0 に障害発生

/var/log/messages

† 16:56: 事象の認知

午前中からずっと打ち合わせだったこともあり、ゆっくりメールを読んでいたら障害メールが来ていること気づく。

コマンドラインから RAID のステータスチェックを実施。
p0 の HDD に DEVICE-ERROR が出ていることを確認。

以前に RAID の HDD 障害が起きたときのメールを参考にさくらのサポート宛にディスク交換を依頼するメール（なるべく早く作業が行われるように作業希望予定日欄を「指定なし、連絡不要」にしたもの）を送信。

† 18:59: メンテナンス開始

下記のようなメッセージと共に、サーバに張っていた ssh のセッションが切断されたので、メンテナンスが始まったと判断して研究室を出て帰路に。

† 19:37: センターから第１報 （アクシデント発生）

事件の発生はここから。

電車の中だったので出られなかったものの、留守電に担当者から「ご契約のサーバについて、少し相談させていただきたいことがございます」というメッセージ。確認不要で指示を出したにもかかわらず、作業開始後に電話があり、現場から相談させて欲しいと判断を求められる・・・頭に思い浮かぶキーワードは「二重障害（復旧中の事故）」の一言。人的ミスなのか、それ以外の要因なのか・・・・どちらにせよ業界の人ならば、センターからの電話で一番遭遇したくないパターンに変わりありません。

仕方がないので赤羽で電車を降りて、折り返し電話をかけると「DEVICE-ERROR が出ている port0 の HDD を交換したが、port1 の HDD が認識出来ずブートできない。障害については RAID カードを含めたハードウェア障害の可能性が高いと考えているので、筐体の交換を実施させて欲しい」とのこと。筐体交換を行うとすると、復旧までどれくらいかかるのかという質問をすると「３０分前後で」ということだったので、迷わず筐体交換を依頼。

サーバが落ちて、メールが見れないので今後の連絡は時間に関わらず電話で行って欲しいとリクエスト。

† 20:14: センターから第２報 （そして奥の手へ・・・）

担当者から「筐体交換を行ったが、現象は変わらない。」という旨の説明。
この時点で全データの喪失という最悪の事態を覚悟。

再インストールの説明をされるかと思いきや、担当者が「ちょっと気になることがある。port0 は DEVICE-ERROR が出ているにも関わらず、RAID ボリュームのステータスは OK になっており矛盾している。RAID ボリュームのステータスを信じれば、DEVICE-ERROR が出ていた port0 のディスクは動作していた可能性があり、こちらと交換用のディスクをペアにして復旧を試みたいのだが、どう思うか？」という旨の提案が。

予想外の提案にちょっと動揺するが、確かに RAID1 ボリュームで片方のディスクが死ねば、ボリュームのステータスは DEGRADED になる。というか、現に同じマシンのディスクが以前に死んだときにそうなっていた。そう考えると、担当者が言うことも一理ある。他に考えられる手段は「初期化＋バックアップから復旧」というものだけで、短時間で復旧を試みられるような手段も考えつかなかったのでダメ元で作業を依頼。

† 20:31: サーバ起動（復旧）

/var/log/messages

† 20:33: センターから第３報 (復旧報告)

担当者から「ブートに成功し、ping、ssh、http 等のサービスの疎通が確認できたので、そちらからも確認してほしい」という旨の連絡。「これで復旧したと考えられるが、データは最新ではないかも知れないことと、これ以外の復旧方法は再インストールになるので必要があれば連絡して欲しい」旨の説明。

まず、IMAP のメールスプールを確認するとリブートされる直前に送信したメールが残っていたので、このディスクが直近であることは間違いないことがほぼ確定的になり一安心。続いて、Apache のログ、MySQL のレコードを確認してみたところ、リブート直前の 18:59 までのエントリがあることも確認。さらに MySQL についてはテーブルのチェックを行ってみたところ、特にエラーは検出されず。

プライベート用のサーバと言うこともあり、これにて対応終了と判断。

† 22:19: RAID の再構築完了（状況終了）

起動とほぼ同時に RAID のリビルドが始まったので、あとはこれが完了するまで祈る。

/var/log/messages

コマンドラインでもリビルド状況を随時確認。

実際には下記のようなコマンドを流して、ssh で毎分リビルド状況がどうなっているかを確認していました。

22:19 にリビルドが完了し、RAID のステータスが OK に戻ったのでこれで一安心。

ログでも完了を確認。

/var/log/messages

ひとまず大事に至らなかったのと、短時間で復旧できたの良かったのですが、原因が釈然としないのは気になるところです。HDD のSerial を見る限り、port を取り違えてディスクを交換してしまったという人為的なミスでもないようだし。

まぁ障害に対する、定期訓練だと思うことにしようと思います。