そういえばHyper-V VMのバックアップ連携エージェントであるAgent for Microsoft Virtual Server（AMVS）を使用する際、これをHA構成（MSFCのQuick/Live Migration)とした場合はどうすればいいんだろう・・・・？と気になったもんで、以下の通り対応してみた。

現状、Hyper-V VMは2台構成していて、共にLive Migration構成。片方はWindowsサーバで片方はLinuxサーバ。もちろんリソースグループは別々に構成してる。

この状況下で、各リソースグループに1つずつクライアントアクセスポイント（ネットワーク名リソース＋IPリソース）を構成してみる。どうやらHyper-VのVMリソースグループにもクライアントアクセスポイントは構成できるようで。そうした状況下で参照させてみた結果は以下。

うぬぬぬぬ・・・・どうやらHyper-Vをバックアップするにはローカルノードを経由してバックアップしなければならないようだ。

画面のところにある「RAIMUGI」というのが物理ノード。現状このノードにすべて片寄しているのだけど、ここ経由ならば「Microsoft Hyper-V」カテゴリが参照できる。

しかし、「VMHA_CentOS」と「VMHA_Windows」を見てわかるように、クライアントアクセスポイント経由だと、特に今回はLive Migrationだったので特殊なデバイス構成として見えてしまい、そもそも選択ができない状態となった。こりゃぁ難しいのぅ・・・。

というわけで、原則ローカルノード接続としておいて、定常運転状態であることを大前提として、そんでもってシステムバックアップとしての手動実行とした方がどうやらよさそう。んで、一般的なデータバックアップに関してはVM上にRemote Agentをインストールしてバックアップ・・・という風にした方がよいようで。

VMwareではDRSという機能によってVMの動的再配置がおこなわれる可能性があるため、どこのノードで何のVMが動いているか分からないが、少なくともHyper-Vの場合は基本的にクラスタの考え方に沿っている状態なので、確かにローカルノードでOKかもしれない。N+1構成とか、そういう構成にしておくと、安心して運用設計もできるかもしれないなぁと。

いろんな意味でいい勉強になりました。

2009/09/13追記：

どうやら、Hyper-Vで使用するCluster Shared Volumeはかなり特殊な制御がかけられているようで、Windows Server Backupをもってしてもバックアップが不可能な領域みたいです。

よって、Live Migration構成のHyper-Vにおいて対応できるシステムバックアップ手順って実は「エクスポート・インポート」しかないみたいです・・・・・Orz

となると、今後Symantec Backup ExecだったりCA ARCServeだったりBakbone Netvaultだったり・・・仮想製品に対する対応ってどのようにかじ取りをするのでしょうかねー。

気になる今日この頃です。

2009/9/18追記：

SymantecのTechnoteにも記載がありました。

An “Access is denied” error occurs when attempting to backup Cluster Shared Volumes (CSVs) from a Windows 2008 R2 Server

http://seer.entsupport.symantec.com/docs/326843.htm

以下の通り記載されています。

Clustered Shared Volume (CSV) Backups are not possible with the current shipping version of Backup Exec for Windows Servers.  Because of this, an attempt should not be made to backup the CSV through the namespace or an access denied error will occur.

うーん、このブログでも書いたのですが、やっぱり名前空間経由してもAccess Deniedされちゃうようです。難しいのぅ・・・・