[2]障害発生時の調査---複数の運用管理ソフトを活用
仮想サーバーの運用における二つ目の問題は，障害が発生したときの調査である。先述の通り，仮想サーバーでは，物理サーバーのリソース使用率を平準化するために，仮想マシンを物理サーバー間で再配置することがしばしばある。加えて物理サーバーのメンテナンスのため，仮想マシンを別の物理サーバーに移動させることも少なくない。それだけに，どこの物理サーバーに仮想マシンがあるのかすぐには分からない場合がある。さらに，どのアプリケーション・サーバーとどのDBサーバーがつながっているか，といった仮想マシン同士のトポロジーも，仮想サーバーでは分かりにくい。そのため障害が発生したとき，その原因や影響範囲を調べるのに手間取りかねない。
この問題を解決する最もシンプルな方法は，構成管理を徹底することだろう。15台の物理サーバーで約290台の仮想マシンを稼働させているカシオ計算機では，仮想マシンを再配置するたびに，構成管理ソフトに配置の状態を必ず記録している。
ただし取材した運用の現場では，構成管理を徹底するケースは例外的だった。多くの現場では，必要になるたびに「VMware vCenter Server」「Citrix XenCenter」など仮想化ソフトの標準運用管理ソフトを使い，物理サーバーに対する仮想マシンの配置やそれぞれの状態をその都度，確認している。
標準の運用管理ソフトでは足りない
では，仮想化ソフトの標準運用管理ソフトだけで十分かというと，そんなことはない。ハードウエア（物理サーバー，ディスク装置，ネットワーク機器など）の障害までは管理できないからだ。そのため，障害発生時の調査を本格的に行うには，統合運用管理ソフトやハードウエアに付属の運用管理ソフトを別途使う必要がある。例えばJTBグループのネット販売会社であるi.JTBは，仮想サーバーの運用にvCenterと米Dellの運用管理ソフト「OpenManage」を併用している。
最近は統合運用管理ソフトの仮想化対応が進み，障害発生時のシステム全体の状況を，一つの画面で一覧できるようになってきている。日立製作所の統合運用管理ソフト「JP1」では，VMwareの仮想マシンと物理サーバーの関係をツリー構造で表示し，障害発生の状態も表す。その際，仮想マシンや物理サーバーを「受注管理システム」「生産管理システム」のようにあらかじめグルーピングしておけるので，障害が発生したとき何のシステムに影響するのかを把握できる。
仮想サーバーの運用に特化した専用ソフトも注目に値する。その一つ，米Akorriの「BalancePoint」では，SAN（Storage Area Network）におけるIDであるWWN（World Wide Name）を解析し，仮想マシン，物理サーバー，ディスク装置がどうひも付いているのかというシステムのトポロジーを表示できる（図3）。性能が劣化している個所を赤色（致命的）や黄色（警告）で表す機能も備える。
近鉄エクスプレスが利用している仮想化ソフトは「VMware ESX Server 2.5」。2009年第2四半期に登場予定の最新バージョン「VMware vSphere 4」から数えると，3世代前の製品である。
同社の計良長雄氏（情報システム部 部長）は，「バージョンアップによって性能向上を図れるかもしれないが，当面はしない方針」と語る。仮想化ソフトをバージョンアップしないのは，テストの負担を避けるためだ。
「そもそも仮想サーバーを導入した目的の一つは，Windows OSのバージョンアップに伴うテストとアプリケーション改修を避けるためだった。それなのに，仮想化ソフトをバージョンアップすることでテストが発生しては本末転倒」と計良氏は言う。同じ理由で，同社は仮想化ソフトのパッチの適用も必要最小限にとどめている。
近鉄エクスプレスの例はやや極端だが，取材したユーザー企業は総じて，バージョンアップに慎重姿勢でパッチ適用は必要最小限という方針だった。実際に，バージョンアップやパッチ適用で大きな問題が起こったわけではない。しかし，いずれの現場もテストの負担を重く見ている。加えて，仮想化ソフトを正式にはサポートしていないアプリケーションやミドルウエアがあるので，バージョンアップやパッチ適用による不具合の発生をできる限り回避したい，という意向も背景にある。
ただしパッチについては，セキュリティ脆弱性（主としてハイパーバイザーのサービス・コンソールの脆弱性）を解消するものもあるので，まったく適用しないわけにはいかない。この点は，注意が必要だ。
