ある夜起こったどこかの会社の話
夜も更けた午前3時半ごろの思い出。
オンプレミスでの仮想基盤。いくつものシステムが動いていたのですが突然、この時間に複数のシステムエラーを感知。
電話で連絡が来るようになっていたのですが、あっちもこっちもそっちもどっちもアラートなので何が何だかわからなくなります。
運用設計なんて、特定のシステムがエラーとなったときのことしか考えられていないので、十も二十も同時にアラートになったら破綻します。電話連絡ったって電話は１つしかないので、担当者にはつながらなくなります。
私は運用の場面ではリーダーだったので、メンバーからエスカレーションを受けます。あっちも、こっちも、そっちもエラーですと。何が起こってるの？、わかりません。
眠気なんて一気に吹っ飛ぶのですが、一方で世の中の終わりを悟ります。
例え、この窮地を切り抜けたところで、たくさんの恒久対応までの道のりと、謝罪行脚が待っている。
もうやだ・・とは言えないので、とにかく現場へGOです。
タクシーをなんとか捕まえて、会社に向かいます。
こんなとき、パソコンを開いてリモートで切り分け・・なんてやってたら時間がいくらあっても足りません。
とにかくメンバーも会社に向かえ。
そもそも、このときはまだガラケー端末だったのですが、メールでアラートを受け取るようにしていたその端末は大量にアラートメールを受け取りどんどん電池が減っていくし、メールを受け取りすぎて新着メールが見られない状態になっていました。
とにかく現象をつかみたいのでタクシーの中でノートパソコンを開こうとするも、電話・電話・電話。複数のシステムがダウンしているということは、それに紐づいて利用者がいるということで、おい、どうなってるんだという電話が五月雨に着信。
いや、今向かってるんで・・。いつ治るか？、わかりません。わからないことはないだろう、いやわかりません。そもそもこんな会話しているより調査を進めさせてください・・。
利用者からの電話だけではなく、部下、上司、経営層、営業、いろんな人から電話がありますが、いやタクシーで向かってますから。
そっとガラケー端末の電源を切って、まずは会社に到着します。
調査開始
どうも、仮想基盤上のOSにはログインはできるらしい。
じゃあ何でエラーなんだ？。しかもなぜ複数のシステムが同時に・・。
OSにログインしてみるも、ちゃんとボリュームはマウントされているし、空き容量もある。でも結果としてアプリケーションはエラーになっている。
とりあえずログでも見ようとしたら違和感を感じます。ログがあるタイミングで止まってしまっている。しかも複数のOSで同じ時間にログが止まっています。
もしかして・・。/tmpディレクトリにファイルをtouchコマンドで作ってみたら、エラーになるではないですか。「read only filesystem」だと・・！？。結局何が起こったかと言うと、OSがマウントしていた領域がことごとく読み取り専用になっていたという事態です。
さて、とりあえず再起動するしかないので、OSでリブートをかけました。しかしリブート作業が全然終わらない。終わらないのは読み取り専用になってしまっているからです。終了処理ができないのです。
しょうがないので、OSの電源を落とします。プチン。で起動します。起動すると何が起こったか。起動が失敗する！。ファイルシステムが異常です。どうもfsckが起動時にかかるも失敗する。
ここで途方にくれます。この障害、時間がかかるぞ。
どうやってOSを起動するか
どうもインターネットで調べていると、この状態、シングルユーザーモードになってfsckをあるオプション付きで実行すれば何とかなるらしい。どうもこんな感じの障害だ。
で、上記に書いてある「修行」を行ったところ、fsckが進むもこれにまた時間がかかる。何せ、今回障害となったOSはやたらたくさんある。
なぜたくさんあるか。同じストレージサーバーを使っていたからです。仮想環境にありがちなのが、ハイパーバイザーとなる物理サーバーはたくさんあるけれど、ストレージサーバーは１つないしは２～３個と言うパターン。
とにかく復旧のめどはつき始めたけれども、なぜこんなに急に読み取り専用になったのかの根本原因を追究する必要があります。しかも、同一のストレージ上にあるOSばかりが影響を受けたので、間違いなくストレージ起因であるということは間違いない。
まずは一次復旧が完了しとにかくシステム自体は回復しました。
ここまでに3時間くらいはかかっています。
地獄はここから
さて、一次復旧は終わりましたと。
もう朝日が昇りオフィスは一日の始まりを告げているのですが、私の中の心はまだ深夜です。オフィスにはたくさんのメンバーが集まっています。複数のシステムが落ちるというのはそういうことです。
復旧したものの、根本原因がわからないということは、また今にでも再発する可能性があるということです。
ストレージに問題があるようだ。でもなぜかはわからない。
こんな状況でまずやることは、「第一報の報告書」作成です。影響、およびこれまでやったことを時系列にまとめ、今後のアクションを書きます。
報告書なんて書いてる場合か、根本原因調べたいよ、と思うんですが必要なステップです。
また、影響に関してはアプリケーション側の調査も必要なので、状況は開発者が調査します。そこから得た情報も報告書に記載していきます。
そして営業が報告書を顧客に配布。
・・・いや、私は午前3時半からずっとかかりっきりで、がんばって復旧までこぎつけて、この時点のメンタリティーは、もはやボロボロですが、しかも報告書まですぐ書かないといけない。営業は待っている。
根本原因を見つけなければいけない。
ベンダー調査
まぁ、とにかくストレージに依存した形で障害が起きているので、ストレージのベンダーに連絡。ストレージのベンダーは仮想基盤のソフトウェアとは関連がないけれど、とにかく現象を正確に伝えました。
資料取りもまた時間がかかる。ストレージの資料収集コマンドを叩くのは恐怖です。それがトリガーでまた何か起こったら目も当てられぬ。でも調査を進めるためにはやらなければいけません。
無事取得でき、送付するも、時間はどんどん経っていきます。
一次復旧しても、実は仕事はこれからなのです。
だんだんと会社は落ち着いていき、ここからは持久戦になります。
さて、ベンダーは良い回答をしてくれるか。
衝撃の事実
ストレージベンダーから衝撃の回答があります。
「ストレージのファームウェアにバグがありました。
特定の仮想基盤ソフトウェアから特定のプロトコルで接続したときに、特定の条件にて読み取り専用となる障害があります。
現在の最新のファームウェアバージョンでは修正が完了しています。」
・・やられた、と。
特定の・・特定の・・、限られた場面しか起きない障害に当選してしまった模様です。
ファームウェアを最新にしていないからと言われればそれまで。しかしまだ出たばかりのバージョンでした。そもそも仮想基盤自体、導入後1年くらいしか経っていない。
報告書には「四半期ごとにファームウェアの確認を行い、常に最新化します」なんて書きましたけれど、本当にストレージのファームウェアってこわい。
一昨日に発生してニュースとなっている、
12月4日に発生した東京都中野区など約50の自治体のシステム障害で、12月5日も住民票の発行やホームページの閲覧などができない状態が続いている。原因は各自治体が利用している日本電子計算のIaaS「Jip-Base」にシステム障害が発生したため。現状で復旧のメドは立っていない。
この件もストレージのファームウェア絡みのようですし、
Hewlett Packard Enterprise(HPE)が11月29日に公開したサポート文書によれば、同社のサーバーやストレージ製品に使われている特定のSAS SSDにおいて、稼働時間が32,768時間を超えると、復旧が不可になる深刻な不具合が発生するとした。
（中略）
【12月5日更新】なお、日本電子計算株式会社が5日に発表した自治体専用IaaSサービス「Jip-Base」の障害について、「ストレージのファームウェアが原因」としているが、同社広報によると本件とは無関係としている。
これもファームウェア絡み。
ただし、両者は関係ないらしい。
ストレージはこわいよ。
この件だけではなく、まだほかにも「ストレージはこわいよ」系を知っています。
こわくなって、パブリッククラウドに来たのですが、リスクは無くなったわけではなく移転しただけ。こういうことが起こる前提で、いろいろとバックアップ設計をするべきだと強く思います。
思い返すと、よく今生きてるなぁと思う今日この頃です。