これまでに、Backup Execの仮想サーババックアップ機能の内、Hyper-V向けの機能であるAgent for Microsoft Virtual Serversの動作確認だったり、検証だったりしてみたのだけど、今回はQuick MigrationとLive Migrationでの動きの違いについて比較をしてみたくなったのでやってみた。

ちなみに過去のネタはこんなところ。

[Windows][Backup Exec] Agent for Microsoft Virtual Serverの選択

[BackupExec][Windows] Agent for Microsoft Virtual Server(AMVS)を試す

今回の検証構成は以下のような感じとしました。FC-SAN上に通常のクラスタディスクを配置し、iSCSI-SAN上にCluster Shared Volumeのディスクを配置しています。実は、FCディスクは年式が古すぎてCluster Shared Volumeを制御するのに必要なSCSIコマンドセットが備わってなかったようで・・・・CSV領域はWindows Storage Server 2008のiSCSI-Target機能を使用して構成しています。

MSFCで構成されたところへ上記のように、通常のクラスタボリュームを使用し、Quick Migrationが可能な構成としたVM（以降、Quick VMと呼ぶ）1台とCluster Shared Volumeを使用してLive Migrationが可能な構成としたVMを（以降、Live VMと呼ぶ)1台構成しています。この状態で、AMVSを使用してそれぞれのバックアップを取得しました。

まず、Quick Migrationが可能なVMに対してバックアップを実行しました。

見え方としては以下のとおりとなります。

AMVSの色眼鏡をかけてみてみると、ローカルノードの下にノード上のVM構成情報を蓄えるInitial StoreとVMが見え、それを展開するとLive MigrationやQuick Migrationとかとは関係なしにVMが参照できる事が分かります。Quick VMを展開すると上図の通り実質のデータ保管場所であるTドライブへのリンクが見えます。この状態でバックアップを実行した結果が以下です。

上記を見ると分かる通り無事にバックアップが行えました。また、このジョブログの他の個所を眺めると、おそらくはAgent for Microsoft Virtual Serversは以下の動作をしているように見えます。

1. VMバックアップジョブを実行。AMVSに対して実行指令を展開
2. Initial Storeに対しては通常通りのバックアップを実施する。（場合によってはAdvanced Open File Optionを使ってるかもしれんけど）
3. Hyper-V管理サービスはVirtual Machineに対してVMとしてのスナップショット作成を指示。状態凍結を実施する。
4. Backup ExecはAdvanced Open File Optionの機能（VSSリクエスタ・プロバイダ）を使用してVSSへスナップショット作成を指示
5. VSSライタはこれを受けてVM構成データが格納されているボリュームに対してSnapshot（CopyOnWrite方式）作成を実施する。
6. スナップショットを使用してRemote Agent経由でデータのバックアップが行われる。

これに対してLive VMに対してはどうでしょうか？

上図を見て分かる通り、見え方は途中まで同じです。が、C:\Cluster Storageの下にある「Volume2」と言う所のアイコンがフォルダでなく、ディスクであることが分かります。実はこのVolume2というのがCluster Shared Volumeそのものであり、C:\Cluster Storage\Volume2のフォルダに対してディスクがマウントされていることが分かります。前述した資料全体から見ても分かるように、AMVSはHyper-Vとして見える論理層だけでなく、実際にデータが格納されているボリューム・ファイル・フォルダに対してもアクセスを行っていると言えます。

なお、事前にアクセス権のテストを行いましたが、無事承認される事を確認しています。

これでバックアップを試みたところ、以下のとおりとなりました。

上記のとおり、見事にジョブは失敗しています。VSSを使用してスナップショット作成を試みた際にどうやらライタステータスの照会に失敗しているようです。この結果から、以下の状況になったのではないかと推測されます。

順序は同じなのですが、恐らくはVSSライタがスナップショットを切ろうとした際に、VSS処理がうまくいかなかったのではないかと考えられます。加えて言えば、Cluster Shared Volumeの制御機構が通常のディスクと異なっており、これに対応するVSS上のAPIが提供されていないのではないのかなぁ・・・・・と推測をしています。

Cluster Shared Volumeは複数ボリュームからのアクセスを許可しており、恐らくは底辺のレイヤーにおいては通常のディスク制御と変わりはなく、底辺のディスク制御レイヤーと上位のOSレベルでのアクセス制御の中間地帯として、ディスク排他制御に関してごまかすための処理が入り込んでいるのではないかなぁと。

通常のクラスタディスクの場合は、OS⇔ストレージHBAドライバの間に「クラスタディスクドライバ」と言うものが存在しており、これがノード間のディスク排他制御を担っていました。同様にCluster Shared Volumeに対してもそれに近いディスクアクセス制御をおこなうドライバが存在するのかなぁ・・・と。ただ、VSSに対してそれがきちんと機能する仕組みがまだ備わっていないのではないでしょうか。

となると、VSSでうまく活性状態でVMをバックアップするAMVSはLive Migration構成のVMバックアップは不可能と言うことになりますね＾＾；BE12.5の段階で、対応させる気がない・・・というSymantecの姿勢も致し方ないのかなぁ・・・と言う気はします。時期的にもそろそろBEは新版が出そうですしね。この構造に対してSymantecがどう対応しようと言うのかがとっても気になる今日この頃です。