連載
» 2008年09月30日 00時00分 UPDATE

仮想サーバのバックアップをどうするか(3):仮想マシン単位のバックアップの課題 (1/2)

サーバ仮想化では各仮想マシンをファイルとして扱える。これは障害の発生したシステムを復旧する場合に非常に便利だ。しかし、仮想マシンをファイルとしてバックアップすることにはいくつかのデメリットもある

[浅野百絵果,株式会社シマンテック]

 前回は、通常のアプリケーションと同じようにゲストOS上にバックアップソフトウェアをインストールし、バックアップする方法について解説した。今回は、仮想化環境ならではの特性を考えながらバックアップする方法を考察する。

システムリカバリにおけるサーバ仮想化のメリット

 通常の物理環境では、OSに求められるハードウェアドライバについて意識する必要がある。つまり、サーバを追加する際には、使用予定のOSが対応しているハードウェアかどうかを確認しなくてはいけないし、OSのイメージをそのまま別のマシンにコピーしても、ハードウェア構成が異なっていれば正常に動作しない。場合によっては、アプリケーションが特定のハードウェアに対応していないということもある。

図1 サーバ仮想化環境では、ハードウェア(CPU、メモリ、NICなど)は仮想マシン上でエミュレーションされている 図1 サーバ仮想化環境では、ハードウェア(CPU、メモリ、NICなど)は仮想マシン上でエミュレーションされている

 仮想化技術の実現には、ホストOS、ハイパーバイザなどの方式があるが、いずれの場合でも、仮想マシンそのものをファイルとして取り扱えることが多い。VMware ESXの場合に、仮想マシンをVMDKファイルとして認識可能であるのは前回述べた通りだ。これを利用すると、この仮想マシンそのもののファイル(VMware ESXであればVMDKファイルなど)を別の環境にコピーする作業で、この仮想マシンを移動することができる。つまり、移動先となる物理マシンのハードウェアの構成が異なっていても、仮想マシンはハードウェアエミュレーション機能によって認識されるので、実際の物理的なハードウェアの違いを意識する必要がない。この特性を利用すると、この仮想マシン本体となるファイルを定期的にバックアップしておけば、万が一のためのディザスタリカバリ対策が実現することになるのだ。

 重要な業務の中で追加・更新されるデータは、バックアップツールを使ったバックアップにより最優先で保護されるべきものだ。では、データのバックアップは万全だと仮定しよう。それでもハードウェアの障害や災害のために、新規のサーバで業務を復旧しなくてはいけない場合、データのリストア以前に、OSのインストールや設定、場合によってはハードウェアドライバのインストール、アプリケーションのインストールや設定が必要になる。これには多大な労力や時間が必要となることは容易に想像できるだろう。また、その作業の間は業務が停止してしまうことになる。

 このシステム復旧の時間を短縮するために、イメージングツールをバックアップツールとは別に使用する場合や、バックアップのリカバリの際にシステムのリカバリも可能にするツールを使用する場合がある。いずれにせよ、日々のバックアップだけではシステムの復旧は手作業で行う必要があるため、いかにこの復旧時間を短縮するかは管理者にとって頭の痛い問題だと言える。

 サーバ仮想化環境では、前述の通り、仮想マシンそのものをファイルとしてバックアップ可能なため、新規にサーバを設置してデータを移行する場合でも、仮想化環境さえ整えてやれば、ファイルをリストアする作業だけでシステム復旧が可能である。OSのインストールや設定は必要ないばかりか、ハードウェアの構成が異なることすら意識する必要がないのだ。もっといえば、正常稼働しているサーバ仮想化環境が障害の起きたサーバとは別にあれば、そこに仮想マシンイメージをコピーする作業で業務を復旧することすらできる。この場合のダウンタイムは、ファイルをコピー(および多少の設定作業)のための時間だけだ。ディザスタリカバリの観点では、これはサーバ仮想化環境の大きなメリットだといえる。

       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。