サーバでブルースクリーン。

　午前、普段通り出勤してしばらく立った頃、別部門からシステムの動作がいつもより重いとの連絡があった。ほぼ同時に、妻の属する部門からもまたもやバッチ処理の途中経過がおかしいとの通報。
　昨日のサーバ再起動では解決できない何らかの不具合がバッチ用サーバ上で起きている可能性がある。
　昨日の現象はメモリ上で走っていたアプリケーションの不具合だろうと考えていたが、再現性があるなら最も可能性が高いのはディスクの障害だろう。
　サーバ自体は二重化されているので１台が死んでも業務の継続性は保たれる。しかしメーカ保守期限を過ぎても更新予算がついていない古いサーバなので、ディスクはともかくもしM/B障害となればかなりまずい。
　サーバ室内で当該サーバを調べるが、Windows上のイベントビューアにはやはりdiskのエラーが記録されている。
　しまった…。昨日の時点で、実際に自分でチェックすべきだったのだ。
　ディスクの読み書き自体は問題なく行われている様子だ。Oracleで構築されたDBにも大きな問題は見当たらない。どういうことだ。メーカー標準の障害検出ユーティリティでも特に問題はないように見える。
　しばらく調べていて、このサーバと連携している別のアプリケーション用サーバ上で、Oracleがインストールされたディスクの空き容量が0Byteになっていることに気がついた。テーブルは共有ディスク上に作成されるはずで、インストール先ディスクはバックアップのダンプやアーカイブログの保存先になっている。
　昔管理していた病院のシステムでは、サーバ向けのディスクがバックアップ失敗に寄るアーカイブログの削除漏れで一杯になり、翌日の業務で障害が起きる事例が毎月の様に起きていた。今から考えればディスク容量やバックアップデバイスの選択などハードウェア見積もりの甘さが根幹の原因となった問題だったが、今の職場ではその頃より格段に余裕を持ったハードウェア構成だったのでそういったトラブルに出くわしたことはなかった。
　しかしこのアプリケーションサーバのディスク容量の不具合が、バッチ用サーバの障害につながるようには思えないが…。動作しているアプリケーションがどのサーバのどのディスクを見ながら走っているか、正確なところは開発者にしかわからないのだから、こちらにできることは不具合の通報と、とりあえずの復旧作業しかない。
　とにかく、空き領域を作る必要がある。このインストール先ディスクD:には、クライアント間の共有ディスクであるバッチ用サーバ上のディスクのバックアップも投入されていた。これは俺も今日まで知らなかったが、保守業者が毎日単純コピーを取るバッチをスケジュール化しているそうだ。このバックアップには我々ユーザ側で作成したものとは異なる用途不明のディレクトリも多数含まれていたので、削除するわけにはいかない。どこか他に移動する必要がある。ディレクトリ内のファイルサイズを調べると、150GB以上あった。困ったことにこれだけの空きがあるディスクは他にない。
　ネットワーク上でディスクを共有している他サーバもあたってみるが、やはり空きは心もとない。どうしたものか…。考えていたところ、システム保守業者が別サーバ用に設置したTeraStationがネットワーク上で1TB程度共有化されていると聞いたことを思い出した。
　本来は別業務用途のため、普段は使うことはなく気にも留めていなかったのだ。アプリケーション用サーバ上にマウントされていないか調べると、やはり今まで気づいていなかったディスクがあった。しかも600GB以上の空き容量があって、手付かずだ。
　カレントドライブをそのディスクに移動し、移動先となるディレクトリを作ろうとした瞬間、画面が暗転して…ブルースクリーンエラーが発生した。
　マジかよ。
　アプリケーションサーバがメモリダンプの書き出しを始めた。このまま再起動がかかったとしても、次にサービスが起動できるところまでは10分以上かかるだろう。
　手元の内線電話でサーバが止まったことを各部門に案内して対応を考えるが、何せ再起動し終わるのを待つしかない。再起動してくれれば…だが。
　エラーを発生させたモジュールを記録するためIS11TのEvernoteで画像メモを撮る。
　エラーモジュールの名称は「ocfs.sys」。
　直感的にOracle関連のファイルではないかと思ったが、ググってみるとその通りだった。Oracle Cluster File Systemを駆動させるためのドライバだ。とすると、先ほど操作しようとしたディスクはOCFSでフォーマットされていたOracle専用のディスクだったのか。そんなディスクがあるとは聞いていなかったが…。
　幸いにしてアプリケーションサーバは正常に起動して、Windowsデスクトップへのログインも成功した。各部門からも障害の報告はない。
　ここで一安心し、ようやく保守業者に通報。作業着手前、できれば発生直後に通報すべきだが、異なる作業は並行してできない自分はいつもそういう連絡を後回しにしてしまう。とりあえず、昨夜の障害の件もあり、本日中に保守員を差し向けるとのこと。
　午後になって顔なじみの保守員氏と、営業主任がやってきた。三人でサーバ室にこもりサーバ上のログを調べてもらう。小一時間ばかり調査をしてもらったが、メモリかM/Bの不具合の可能性があるが断言できないという。というわけで当面の間再現性がないか監視することになった。
　問題だったアプリケーションサーバのディスク容量の不足は、移動先に別途保有していたUSB接続のHDDを使用することにして一時的に解決とした。ディスク圧迫の要因のひとつである共有ディスクのバックアップは一時的に停止し、別途大容量の外付けHDDを発注し納品され次第そのHDDをバックアップ先として再開することにする。