NetAppスナップミラーでレプリケーションされていた仮想マシンを起動した場合の整合性は?VSSの静止点は?

NetApp&VMwareを使用して、仮想マシンが配置されているデータストアをNetApp間のスナップミラー(SnapMirror)機能を利用して一日一回レプリケーションしている環境(VSC利用)で、
一時的にSnapMirrorを解除しレプリケーション先のNetAppから仮想マシンを起動した場合、仮想マシンの整合性はどのようになっているのでしょうか?

SnapMirrorを解除しレプリケーション先のNetAppから仮想マシンを起動した場合、仮想マシンの整合性は?

image

結論から言いますと、仮想マシンの整合性は担保されていません。

NetAppのVMware連携のBackupではVMwareのスナップショットを取得し、VMwareがゲストOSのWindowsの静止点VSSと連携してくれる仕組みをとっています。
なので、ゲストOSの静止点を担保してくれそうなのですが、スナップミラー先の仮想マシンではそのままでは静止点が担保されていない状態となっているのです。
tot-blog7-jp-4
ネットアップ - Tech OnTap - 第七回:最強のvCenterプラグイン:「Virtual Storage Console(VSC)4.0」

SnapMirrorを解除しレプリケーション先のNetAppから仮想マシンを起動した場合を検証

環境

  • VMware vSphere 5.1 (ESX 5.1)
  • NetApp (2台でスナップミラー)
  • VSC 4.0
  • ゲストOSとしてWindows Server 2008 R2使用

まず、NetAppのSnapMirrorを解除します
image

次に、スナップミラーされていたNetApp上のデータストアから仮想マシンvmxファイルをインベントリに追加します
image
この時、「.snapsphot」フォルダ内の仮想マシンではなく、スナップミラーされているトップディレクトリの仮想マシンをインベントリに追加しています

仮想マシン(Windows)を起動しますと、「Windowsエラー回復処理」が表示されます。
image
これはつまり、VSSといったWindowsの整合性が担保されていないことがわかります。

実際に仮想マシンを起動し、VMwareのカスタムスクリプトの実行ログを見ていますと、ポストスクリプト(post-thaw-script.bat)が実行された後の状態であることがわかりました
image

VMwareと連携したNetAppスナップミラーの仕組み。VSC4.0利用

VMwareと連携したNetAppスナップミラーの仕組みとしましては、
NetAppのバックアップジョブが実行されると、以下のような順序で動作しています

  1. NetAppバックアップジョブ実行開始
    →VMwareスナップショット実行開始
      →ゲストOSであるWindowsがVSSで静止点を作成
    →VMwareスナップショットが作成完了
  2. NetAppスナップショット①が作成完了
    →VMwareスナップショット削除
  3. NetAppバックアップジョブ成功のメール通知
  4. NetAppスナップショット②を作成
  5. NetAppスナップショット②をNetAppスナップショット①ごと(データストアの.snapshotフォルダ)スナップミラーで転送

という流れになっています。
つまり、仮想マシンの整合性が担保された仮想マシンは、データストア内の「.snapshot」フォルダに入っており、このフォルダ内の仮想マシンにはVMwareスナップショットが入った状態となっています。
このVMwareスナップショットマネージャから、VMwareスナップショットをリストアした状態が仮想マシンのゲストOSとしての整合性が担保された常態と言えるわけです。
NetAppのスナップミラーから仮想マシンの整合性を担保した状態のゲストOSを取り出すのは、ちょっと面倒なんです

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です