【序章】仮想サーバへの移行までの裏話

最近の仮想サーバと言えば、オープンソースから商用まで自分達の必要機能・環境に合わせて選択することが出来るようになってきました。特にWindowsServer2008では、OSの機能として仮想環境がサポートされたことにより、仮想環境化におけるサーバの導入も非常に敷居が下がった感があります。

当社でもお客様へご提案する際には必ず仮想・リアルの両環境を検討し、最良の構成をご提案するようにしています。このような事から、これから仮想サーバ環境の導入・移行を検討されている方へ少しでも情報提供が出来ればと思い今回のテーマにしてみました。

それでは、複数台のサーバを仮想サーバへ移行するまでのエピソードを実例を交えながらご紹介させて頂きます。

ある日、お取引先のご担当者様から携帯電話へ連絡がありました。

「池田さん、データベースのサーバが朝出社したらブルースクリーンになっていて立ち上がらないんだよ・・・」

ブルースクリーン懐かしい響きの言葉と思いながら、「〇〇さん、それは困りましたね。念のためですが、データベースのバックアップはありますか？」と携帯電話越しに質問させて頂きましたが、相当パニックに陥っている様子。状況把握は後にして、取り急ぎシステム系エンジニア必須のツールを準備してお客様先に急行することに・・・

お客様先に到着したら最初に行うことは現場の保存です。（刑事ドラマみたいですが・・・）この時点で焦ってリセットしたり電源を切断したりすると、更に悲惨な状況に陥る事があります。

ブルースクリーン画面のメッセージを携帯電話を使用して画像として保管します。昔は手帳に手書きでエラーメッセージを書いたりしていたのですが、最近では便利なツールが身近にあります。
エラーメッセージの解析は頼れる相棒へ先ほどの画像を添付してメールで送信しておきます。次の作業はお客様業務への影響度の把握です。ご担当者の方へ業務への影響度を確認したところ、全社へはアナウンスをしており１日程度の停止であればリカバリーが可能とのこと。（この時点で復旧までの猶予時間が逆算出来ます。）

これからは本格的な復旧作業へ向けての第一歩です。とても気合いが入る瞬間ですね。
なにはともあれ、サーバハードウェアの仕様確認です。当社が導入させて頂いたサーバであればハードウェア構成も把握出来るのですが、今の世の中サーバですらインターネットで簡単に構成も組めて注文出来ますから、お客様でサーバを導入する事も多々あります。今回は、数年前に導入されたサーバでしたので仕様の把握も比較的短時間で済みました。

ハードウェアが原因で今回の障害が発生したことを想定して、ハードウェアの保守契約状況を確認します。担当者にハードウェアの保守状況を確認したところ、標準でのサービスが切れてからは更新していないとの事です・・・・・
この状況では、サーバメーカの迅速な対応は期待出来ませんが、念のためサポート窓口に連絡をしておきます。ご担当者の方にサポート窓口に連絡をして頂きましたが、案の定冷たい対応で「契約切れにつき翌日以降の対応」になるとのこと。

ご担当者の方は落胆していましたがこんなことは想定内です。そうこうしている間にエラー画面の解析結果が頼れる相棒からメールで送られて来ました。解析結果によるとRAIDカードの不具合らしいです。
RAIDカードの不具合は少しやっかいですが、保守契約が切れたサーバのメインボードとかCPUの不具合で無かっただけラッキーと思わなければフィールドSEは務まりません。

先ずは、ハードディスクのアクセスランプの目視で確認するために、サーバのフロントカバー及びサイドカバーを慎重にオープンします。通常、ディスクへのアクセスランプは、サーバフロントパネル付近にLED等での表示箇所がありますが、RAIDカード不具合の場合、この表示も信用出来ません。
ハードディスクのアクセスランプが消えていることが確認出来れば、ここ一番の勇気を出してサーバの電源を切断します。

電源切断後は、RAIDカードを切り離してRAIDカード以外のハードウェアに異常が無いか確認します。確認の結果、どうやら問題は無さそうです。

ここからが今回の山場です。RAIDカードは通常RAIDレベルの構成情報をカード上に保持しています。Adaptec、Mylex等のRAIDカードでは、カードとハードディスクの両方に構成情報を保持するタイプもあります。しかし今回のRAIDカードはサーバメーカ独自のRAIDカードのため、前者・後者どちらの仕様かは見た目だけでは判断できません。ここで登場するのが「システム系エンジニア必須ツール」です。少し、裏ワザを使用してゴニュゴニュと呪文をとなえると、どうやらRAIDカード上にしか構成情報を保存しないタイプだったと判明しました。

ここまでの状況を整理する意味でお客様とホワイトボードに状況を書き出します。
・データベースのバックアップは1週間前のフルバックアップがある
・ハードウェアの保守契約は切れおり、ハードウェアオンサイトは翌日以降
・RAIDカード以外のハードウェアに問題は無さそう
・エラー画面解析の結果、RAIDカードの不具合と思われる

以上のことから通常であればメーカのオンサイト保守を待つのですが、翌日以降の対応だとお客様業務に多大な影響が出てしまいます。「なんとかしてあげたい」と思いながらサーバルームを物色していると朽ち果てたサーバを一台発見しました。見た目は同型のサーバですが、明らかにお役御免状態の廃棄待ちです。担当の方に確認したところ、リースアップとなったサーバで回収待ちとのことです。
早速、カバーをオープンし中身を確認したところCPUスペックこそ低いですが、ほぼ同等の仕様でありませんか。これは使えると判断した私は、転がっていたハードディスクを集めて不具合が発生しているRAIDカードと同じ構成でRAIDを組みました。後は、RAIDの初期化が終わるまで祈るだけです。

RAIDの初期化が終わったカードを慎重に引き抜き、不具合が起きているカードと入れ替えます。ここでも祈りながらデータベースサーバの電源を投入します。
メモリチェックの後、各種BIOSの読み込みが完了するとOSの起動画面へ・・・・。ハードディスクのアクセスランプが激しく点滅しています。しばらくすると見慣れたログイン画面が表示され無事OSが起動されました。

「やった！」担当者の方と抱き合いたぐらいの気持ちで喜びました。

まだ不安はありますが、担当者の方にログインして頂き状況を確認します。流石に、イベントログは赤丸が沢山表示されていますが、ここでも「システム系エンジニア必須ツール」の使い、エラーに対応していきます。数回の再起動の後、データベースのサービスも無事起動されひと安心です。

ここまで来たら残るのは、お客様の業務確認です。業務確認の間に、担当者の方と今後の対応を含め打ち合わせを行い、本日の障害対応は完了です。

続きは次回のブログをお楽しみに。