SIGMABLADE＋SigmaSystemCenterによる障害自動復旧システムの構築
最後に障害発生時に自動復旧が行われるかどうか動作テストを行います。今回は「マシンアクセス不可能障害」イベントを発生させるため、System-Aのネットワークケーブルを引っこ抜いてみることにしました。
障害発生時の「オペレーションウィンドウ」の画面です。「オペレーションウィンドウ」はExpress5800シリーズに標準添付されている管理ソフトウェア、ESMPRO/ServerManagerの付属ツールで、これを使うと障害がどこで発生しているのか視覚的に把握することができます。この画面では、障害が発生したSystem-Aが警告色の赤で表示されています。
こちらは復旧処理が開始された段階でのSSCの「運用」ビュー（グループの詳細情報）の画面です。「ホスト一覧」でリソースに待機サーバのSlot3が割り当てられ、復旧処理が実行中であることがわかります。
同じく復旧処理中のSSCの「監視」ビュー（ダッシュボード）の画面です。この画面では、管理対象サーバで発生したイベントとアクションの履歴（および進捗状況）が確認できます。これを見ると、15時05分20秒にサーバアクセス不能障害が検出され、通報およびマシンステータスの変更、マシン置換が実行され、マシン置換の進捗状況が56％まで進んでいることがわかります。
復旧処理完了後の「オペレーションウィンドウ」の画面です。障害が発生したスロット1のサーバに代わり、スロット3にあった待機サーバがSystem-Aとして稼働していることがわかります。
以上で障害発生時に正常に待機サーバに切り替わることが確認できました。
今回のサーバ（System-A）の場合、障害発生から復旧までに約7分30秒かかりました。System-Aのローカルディスクにはシステム用の12GBのパーティションのみが存在し、そのうち約3GBが使用済みという状態です。ディスクイメージはディスク全体を対象にして作成しましたが、DPMはディスクの未使用領域をスキップしてイメージを作成するため、その分高速にリストアすることが可能になっています。
もっともサーバの用途／重要度によっては、数分単位のダウンタイムが許容できないケースも多々あります。そのような場合は、クラスタリングソフトウェアのCLUSTERPROと連携させることで、ダウンタイムを大幅に短縮することが可能です。たとえば、2台のブレードをCLUSTERPROでアクティブ／スタンバイ型のHAクラスタに構成します。この場合、障害発生時に短時間で待機サーバに切り替えることが可能ですが、待機サーバがいなくなるのでシステムの可用性は低下します。そこでSSCのデプロイメント機能を使って、空きサーバをクラスタの待機サーバとしてセットアップするように設定しておくのです。クラスタ側で複数台の待機サーバを用意すると待機サーバはそのシステム専用になってしまいますが、空きサーバはシステムに依存しない第2の待機サーバとしてシステム間で共有することができます。クラスタとSSCを組み合わせることで、リソースの無駄を省きつつ高度な可用性を実現することが可能になるわけです。
[PageInfo]
LastUpdate: 2008-07-08 14:38:46, ModifiedBy: morihide
[Permissions]
view:all, edit:all, delete/config:members
edit
