物理と仮想の混在環境もバックアップする方法：IT導入完全ガイド（2/2 ページ）

[西山 毅，レッドオウル]

DRサイトの仮想環境へのバックアップニーズも増えている

　2011年の東日本大震災以降、遠隔地にDRサイトを作って複製を置き、万一の際にはそこから瞬時にリストアをかけたいというニーズが非常に高いという。しかしこうした環境を構築するためには、高額な投資が必要だ。

　そこでRTO（Recovery Time Objective：目標復旧時間）がそこまで短くなくてもいいという企業のために、DRサイトに仮想マシンを立て、そこに本番サイトのバックアップサーバからレプリケーションによって複製を取り、万一の障害発生時にはDRサイトの仮想マシンを稼働させる「バーチャルスタンバイ」という機能を提供しているベンダーがある。

　実際の動作としては、バックアップ状況をバーチャルスタンバイ機能が常にモニタリングしており、バックアップが行われたタイミングでDRサイトの仮想マシン上にも複製を作り、何かトラブルが起こったときには、自動で仮想マシン上のバックアップデータを利用可能な状態にしてくれる。これによってユーザーは万一のときにも、DRサイトにアクセスすれば、ある一定時間前と同じシステムとデータを使うことが可能となる。

図4 DRサイトの仮想マシンを活用したバックアップの動作例（出典：日本CA）

図5 DRサイトの仮想マシンを活用した復旧の動作例（出典：日本CA）

仮想化環境と連携してバックアップできるか

　そもそもの話だが、上で紹介した2パターンの混在環境のバックアップ方法のうち、1つ目の物理サーバ上の仮想マシンの構成が変わらない場合には、この項目は特に意識する必要はない。物理サーバ内に仮想マシンが存在していても、バックアップツールは従来通り、物理サーバだけを見ていればいいからだ。

　しかし、2つ目の仮想環境が増えたり、移行したりする場合には、バックアップツールが仮想環境をきちんと認識できなければならない。

　自社がどちらの構成の混在環境をバックアップしたいのかで、バックアップツールが仮想化環境と連携する必要があるかどうかも違ってくる。

物理環境と仮想環境を同じ操作性でバックアップできるか

　この項目はつまり、直感的で使いやすく、操作もシンプルなユーザーインタフェースが提供されているかどうかということだ。また、物理環境と仮想環境を1つの統合コンソールで一元的に管理できるかも、管理者の業務効率を考える上では非常に大きなポイントだ。

　実際に生のユーザーの声として、幾つもの管理画面を開いて、あちこちのステータスを見たくないという要望は本当に多いという。確かに朝会社に来て、ジョブが終わったかどうかをチェックするときに物理サーバごとに管理画面を立ち上げなければならないというのでは、管理者のモチベーションも大きく低下するだろう。

　物理／仮想混在環境がかなり普及してきた現在でも、2つの環境を全く同じ操作性で管理できないバックアップツールはまだあり、さらに1つのツールでも、物理は物理、仮想は仮想でしか管理できない製品もあれば、LinuxとWindowsといったOSの違いによって管理画面が異なる製品もあるという。製品選定時には、十分に留意すべき点だ。

仮想マシンが増えたときのバックアップ時間は問題ないか

　これまでのように物理サーバとテープ装置間を直結したバックアップ方法なら、バックアップ時間はそれほど気にならなかったかもしれないが、社内ネットワーク上にバックアップサーバを置いて混在環境のバックアップを行うという場合には、上でも述べたようにLANを経由するバックアップ方法では多大な時間を要する可能性がある。

　バックアップ時間の短縮を図りたいのであれば、LANとは別のネットワークを経由してバックアップを行うシステム構成を採る必要があるだろう。

　また最近では、仮想マシンを構築する物理サーバには必要以上の負荷をかけたくないという企業のニーズも高まっており、「エージェントレスで動作するバックアップツール」というのも、選定基準の1つの挙げられることが多いようだ。

仮想マシンの数によってライセンスフィーが高額にならないか

　ビジネス側の変化に柔軟に対応できるシステム環境を実現するためには、物理サーバ上の仮想マシンを状況に応じて、増やしていく必要がある。しかし、例えばバックアップツールのライセンスフィーが仮想マシン単位に発生するというのでは、管理者は自由に仮想環境を追加していくこともままならないだろう。

　現在提供されている製品の中には、ハイパーバイザー単位でのライセンスフィーを設定しているものがあり、これならハイパーバイザー上で仮想マシンがどれだけ増えても、追加のライセンスフィーは一切発生しない。製品選定時には、コスト面からも将来のバックアップ対象を考慮した拡張性をチェックしておく必要がある。

コラム：ベンダーにさじを投げられた、機能だけでの選定では大きなトラブルに

　今回取材したベンダーの1社で聞いた話だが、あるユーザー企業ではバックアップツールの選定時に、機能比較やPOC（Proof Of Concept：概念実証）などもきちんと行い、自社ニーズを満たす製品を導入した。

　しかし、いざ実運用に載せてみると、バックアップ対象となるデータ容量に対してバックアップ時間があまりにもかかり過ぎてしまい、本来止めてはいけないシステムが停止してしまう不具合が起こったという。

　当然この企業では製品ベンダーに障害内容を伝え、対応を依頼したが、とことん原因を突き止めることなく、結局「分かりません」といわれて、最後まで対応してもらえなかったとのことだ。

　原因は、バックアップのために、ある時点でのデータを切り出したスナップショットを取っていたが、本来順次消えていかなければならないはずのスナップショットがどんどんたまっていき、膨大なデータ量になってしまったこと。しかしながら、原因が何かの切り分けもしてもらえないまま、製品ベンダーにはさじを投げられ、結果、別の製品を一から導入し直すハメになったのである。

　製品選定時に機能比較やPOC（Proof Of Concept：概念実証）を行うことは大切だが、それ以上にサポートがしっかりしているベンダー、あるいはしっかりしたSIパートナーがいるベンダーを見極めることが重要だ。