赤きLEDの明滅とビープ音
とある20世紀末の夏。
「データセンタ」を謳う19インチラック7台ほどのサーバルームの中で、DELLやCompaqのLEDが明け方の空に瞬く星々のように明滅を繰り返していた。
そろそろメジャーになりつつあった青色LEDが、緑やオレンジの輝きの中に混ざり、冷涼な室内をさらに涼しく彩る。
しかし、赤色LED。お前はダメだ。
サーバ機器、ネットワーク機器に光る赤色LEDは、ハードウエアの不具合を示す。
俺はクライアントから、顧客管理システムでエラーが出ている、との連絡を受けた。
クライアントのシステムが収められた「データセンタ」に入室すると、甲高いビープ音が室内に鳴り響いているのに気づく。「データセンタ」は稼働したばかりで運用経験が浅く、俺にはどの機器が泣いているのか、音だけで聞き分けることはできなかった。が、幸い、ラック7台に過ぎない小さな「データセンタ」は、程よく全体への見通しが良いため、すぐに赤いLEDが明滅する機器に目が行く。
DELL PowerVault、3.5インチのHDDが多数搭載されたストレージ機器だ。
そうだ、こいつだ。こいつは今回連絡を頂いたクライアントが保持する大容量データの為に最近購入し、最新鋭のMicrosoft SQL Server 7.0 用のストレージとしてセットアップしたヤツだ。
Raid5は最強
ディスクの故障だろうか。
しかし心配無用。ディスクの故障に備え、こいつはRaid5とRaid1で組んである。Raid5なら、ディスクが1台や2台故障しても、故障したディスクを交換すれば問題なく復帰できる。おまけにこいつはホットスワップ対応、電源を落とさずにディスクの交換をすることができる。予備のディスクも用意してある。
ディスクの故障は初めての経験だった。本当に復帰するんだろうか、という心配も多少あったが、DELL PowerVaultのRaid5は最強、と、根拠のない安心感が心配を払拭し始める。俺は赤く光るディスクを引き抜き、予備のディスクを挿し込んだ。
ビープ音再び
新しいディスクを挿し込むと、直ぐに挿し込んだ新品のディスク以外も含め、全ディスクの緑色LEDが瞬きはじめた。
再構築が始まる。再構築が終わるまで、いかほどの時間が必要なのだろう。
外は暑い。俺は再構築完了まで、「データセンタ」の中でのんびり涼むことにした。
数分後、再びビープ音が鳴り響いた。
交換したディスクも壊れていたのか。俺は別の予備ディスクを手に取り、つい数分前に交換したディスクを抜き、差し替える。
しかし、ストレージが復旧することはなかった。
バックアップからの復旧
涼しいはずのデータセンタが少しも涼しくない。
額からは汗が吹き出し、手のひらは湿り気を増す。
相変わらずSQL Server から、ストレージへのアクセスは復帰しない。幸い、リアルタイムのアクセスを要求されるシステムではなかった為、クライアントからの催促はまだない。数時間のうちに復旧し、「直りました。ディスクにエラーが出てましたよ。幸い、交換可能な構成にしといたので、大事には至りませんでした。」と報告すればいいはずだ。
そうだ、DBデータはD:ドライブ、バックアップをE:ドライブに取るよう設定していた筈だ。
まずはバックアップデータをサルベージの上、PowerVaultを切り離してPowerEdgeサーバにディスクを足して単体でSQL Server を稼働させよう。PowerVaultの問題解決は後回しだ。
バックアップの保存先
さて、E:ドライブからDBバックアップファイルをサルベージしようか、というところで俺は思い出した。
Raid5で構成された仮想ディスクをパーティションでD:ドライブとE:ドライブに分けていた事実を。
いや、本当は最初から気づいていたのだろう。
Raid5で組まれたディスクにアクセスできなかった時から、DBデータは永久に失われていた事を。
土下座による再構築
クライアントへは何をどのように報告したか、記憶が定かではない。
数千件の顧客情報を含むDBが破壊され、「ハードウエアのトラブル」によりデータが永遠に失われてしまった事実を伝えたことは確かだ。
憶えているのは、クライアントが大変寛大であり、全く怒ることも、騒ぐこともなく、冷静に聞いてくれた事だ。
後日、DBサーバは別の機器で再構築され、バックアップはDATドライブへ取るよう、再構築。
データは「クライアント自ら」「紙情報から再入力」することにより復旧を遂げた。
俺は、このクライアントの為ならたとえ深夜2時だろうが駆けつけて対応しよう、と、心に誓った。
後日譚
後日、調査により、ディスクではなく、「Raidコントローラ」が故障していたことが判明した。
どのような挙動があったのか不明だが、全てのディスクに「正しくない」情報が書き込まれ、ストレージとして機能していなかった、との事。
Raid1で組まれていた別ドライブも、使い物にならなくなっていた。確かRaid1のドライブにも、時折バックアップファイルをコピーしていた筈だが、それも失われていた…ことはあとになって気づいた。
この物語に教訓なんてものは何も無い。単に、何も考えずにシステム構成を考えたクソなエンジニアが、寛大なクライアントに心を救われた、というだけの話だ。
…それだけではクソすぎるので教訓じみた事を書き殴ろう。
惨劇の根本的原因
- リスク分析が十分ではなかった。Raidコントローラーだって壊れる。壊れた際の影響度は計り知れない。
- raid に対する本質的理解が足りなかった。Raid5のパリティによる冗長化を、データが消えない魔法の呪文と思っていた。
- システム設計のレビューが十分ではなかった。同じ環境・デバイスへのバックアップは無意味。
教訓
- 万物は壊れる
- すべての構成要素は必ず不具合を生じる前提で物事に当たれ。
- 自分を信じるな
- いい感じで設計できた、実装できたと思っても、必ず自分以外にレビューをしてもらうべきだ。
- クライアントとは常にいい関係を維持しろ
- もしクライアントが普段から嫌な思いをしていたら、と思うとゾッとする。人間関係は良好に保とう。
- 真実は友達
- 不都合な事実であろうとも、誠意を持って伝えよう。伝える深度は調整してもいいかもしれない…
※このポエムはほぼ100%の事実をもとにしたフィクションです。製品名、製品仕様については20年以上前ということもあり、曖昧で適当です。