NetApp の Virtual Storage Console (VSC) の挙動-AOZAI

バックアップの取得時間の速さについては各ベンダしのぎを削っていますが、仮想基盤上の仮想マシンのイメージバックアップに関しては、やはりストレージのスナップショットがダントツに速いです。中でも NetApp の Snapshot はバックアップとして保持し続けてもパフォーマンス劣化がほぼ無いのですんごくイイと思っています。Virtual Storage Console (VSC) というソフトを vCenter Server のプラグインとしてインストールして使います。専用のバックアップサーバとか Virtual Appliance を立てる必要が無いってのもイイですね。難点としては、バージョン 5.0 からファイルレベルでのリストアができなくなったこと。グローバルではそんなに需要無いのか知りませんが、日本では「ファイルレベルのリストアができること」は仕様書でしばられていることが非常に多いので、是非復活して欲しいです。ファイルレベルリストアが可能な 4.X も、最新の ONTAP に対応し続けているので、一部で(?)需要があるってことはわかってると思うんですけどね。

で、今回はとある案件で VSC が採用になり、VSC でのバックアップ・リストア設計と手順の確立を行わないといけなくなったのでお勉強中です。検証してわかったことをメモしておきます。申し訳ないですが初心者向け記事ではないので NetApp 用語とか VMware 用語とかいちいち説明しません。

前提条件は以下の通り。

NFS ボリューム1に仮想マシンが複数台ある。
ある特定の1仮想マシンは VSC バックアップ対象外。(vCenter Server。別途 Windows Server Backup でバックアップ)
バックアップ対象の仮想マシンは全台同時にバックアップする。
バックアップ前後でミドルウェアの停止・起動が必要なサーバがある。
バックアップ取得後、NFS ボリューム2に SnapMirror する。

検証環境はちょっと古くて vSphere はバージョン 5.1、VSC は 4.2.1、ONTAP は 8.2.1(c-mode) です。前述した条件を満たすように以下の設定にしました。

NFS ボリューム1,2 の SnapMirror 関係を予め設定しておく。スケジューリングはしない。
VSC のジョブは1つで、対象としてデータストアではなく特定の1台を除いた仮想マシン全台を選択する。
VSC のジョブで、Initiate SnapMirror update と Perform VMware consistency snapshot にチェックを入れる。
ミドルウェアの停止・起動は VADP のカスタム静止スクリプトを使う。
VSC にもバックアップ前後にスクリプトを実行する機能はありますが、その場合のスクリプトは VSC サーバ上に配置する必要があるので、対象サーバにリモート接続して処理を実行させるというのをバッチファイル内に実装する必要があります。一方 VADP のカスタム静止スクリプトは、それぞれのゲストOSの中に置くので、リモート接続する部分のコーディングをする必要がなくシンプルに実装できます。尚、VADP のカスタム静止スクリプトの実行タイミングは VMware snapshot の前後ですが、VSC のジョブでスクリプトを設定した場合の実行タイミングは VSC バックアップジョブの前後となります。

検証してわかったこと。

バックアップ処理の詳細なフロー。
1. バックアップ対象全台の VMware snapshot の作成が一斉(数台ずつらしいが検証環境では少数だったので)に開始。VMware のタスクの Create snapshot の開始時刻。
  このとき、バックアップ対象になっていない仮想マシンは同じデータストア上にあっても VMware snapshot は作成開始されない。
2. カスタム静止スクリプト(c:\windows\pre-freeze-script.bat)がある場合、実行。
3. VMware snapshot が作成される。
4. カスタム静止スクリプト(c:\windows\post-thaw-script.bat)がある場合、実行。
  このスクリプトによる状態の変化は VMware snapshot ファイルに書き込まれる。
5. VMware snapshot 作成完了。VMware のタスクの Create snapshot の完了時刻。
  バックアップ対象全台の VMware snapshot 作成が完了状態になるまで、次のフェーズには進まない。
6. NetApp Snapshot 作成。
  Snapshot はその仕様上ボリューム単位での取得なので、バックアップ対象であるか否かに関わらずボリューム上の全てが Snapshot に含まれる。
7. VMware snapshot の削除開始→完了。
  VMware snapshot が存在していた間の変化が反映される。
8. SnapMirror 用の Snapshot が作成される。
9. SnapMirror。
つまり当たり前ですが VSC によるバックアップ取得時点の NetApp Snapshot 内のバックアップ対象仮想マシンは、VMware snapshot がある状態です。ただし、仮想マシンの電源が落ちていた場合は VMware snapshot の作成自体が行われないのでバックアップ対象仮想マシンであっても VMware snapshot はありません。SnapMirror は VMware snapshot の削除後に行われるので、SnapMirror 時点の NetApp Snapshot 内には、バックアップ対象であるかどうかに関わらず VMware snapshot はありません。
NetApp の代理店サイトの説明ページなどで、SnapMirror が VMware snapshot 削除の前に行われるように記載されているものがありますが、それは間違っています。
VSC による NetApp Snapshot の名前は、直近のものが『smvi__ジョブ名_recent』で、それ以外は『smvi__ジョブ名_YYYYMMDDhhmmss』。
SnapMirror 時に作成される NetApp Snapshot の名前は、『snapmirror.』から始まる。
VMware snapshot の作成に失敗した場合でも NetApp Snapshot は取得され、VSC 的には成功とみなされる。
バックアップに関するログは vCenter Server のイベントログ(Application) にソース SMVI ででる。ログの内容に関わらずイベントIDは全て4096。バックアップの開始は出ない。完了は VMware snapshot の削除完了後に Info で出る。SnapMirror に関するログは出ない。VMware snapshot に失敗したログは Warn で出る。リストアも開始は出ないが完了は Info で出る。
バックアップジョブを削除しても既に取得済みのバックアップデータには影響ない。
VSC によるリストア処理の詳細なフロー。
1. 仮想マシンのパワーオフ。
2. VSC 取得時点の NetApp Snapshot からのリストア。
3. VMware snapshot を取得した時点に移動(Revert)する。※VMware snapshot の削除ではない。つまり、post-thaw-script.bat による変化や、その他 VMware snapshot が存在していた間に起きた更新を破棄して、pre-freeze-script.bat 終了時点に戻る。
4. VMware shapshot を削除。直前で更新部分を破棄しているので反映されるものは何も無い。
5. リストア実行時に、リストア完了後仮想マシンを再起動するチェックボックスにチェックを入れていた場合は仮想マシンのパワーオンが行われる。
バックアップもリストアも、NetApp Snapshot 関連の処理は容量に関わらず数秒で終わるので、所要時間は、カスタム静止スクリプト(バックアップ時のみ)、VMware snapshot 関連の処理、SnapMirror(バックアップ時のみ)、電源OFF/ON(リストア時のみ)の所要時間に依存して決まる。尚、リストアが高速化したのは cDOT になってから。よって、7-Mode 時代に書かれた VSC の説明記事ではリストアには容量に応じた時間がかかると書いてある。cDOT であれば VSC のバージョンは 4.X でも OK。

バックアップもリストアも、簡単に直感的に操作でき、しかも速いのですが、問題は SnapMirror の Source が死んだ場合にどうやってリストアするかですね。これについて明確に説明してある情報が公式にも非公式にも見当たりません。
Tech OnTap のこちらの記事では、SnapMirror 関係を break して、ミラー先ボリュームをデータストアとしてマウントして、そこから仮想マシンを起動しているようですが、これだと静止点のデータでは無いはずです。そもそも仮想マシンがサーバではなくてデスクトップですし、システム領域の VSC バックアップしていないですし、静止点の確保については完全に無視なんですね。
今回検証している構成では、わざわざ VSC で VADP 連携して静止点をとったバックアップを SnapMirror しているのに、SnapMirror 先から起動する際に静止点ではないデータから起動していたら意味がないので、静止点まで戻る方法として以下の手順を考えました。

平常時に予め仮想マシンの名前(ホスト名ではなくインベントリ上に表示される名前)と配置を記録しておく。
切替時に仮想マシンの登録しなおしが発生しますが、その際にウイザード中でデフォルトで設定される仮想マシン名は vmx ファイルのファイル名になります。後から仮想マシン名を変更した場合などはファイル名と仮想マシン名が異なっている場合があるので仮想マシン名をメモっておきましょう。メモっておかなかった場合や、メモが信用できない場合は、vmx ファイルの中の displayName が仮想マシン名なのでそれを確認しながら作業することになります。
SnapMirror 関係を break する。
NFS ボリューム2 を最後に VSC バックアップを行ったときの Snapshot(smvi__ジョブ名_recent) に SnapRestore する。
NFS ボリューム1 にある仮想マシンを全てインベントリから削除。
このとき、電源が入ったままの仮想マシンはインベントリから削除できません。 vCenter Server が生きていて、かつ普通に vSphere Client から電源を落とすことができれば落として削除してください。既にかつてのデータストアとの接続が失われている場合は、vSphere Client や vim-cmd ではシャットダウンもパワーオフもエラーになってできないので、ESXi に ssh かコンソールでログインし、以下の方法でコマンドラインから落としてください。-t の引数は検証では soft でいけましたが、もし失敗したら hard、それも失敗したら force で実行してください。
vCenter Server を復旧させる。※vCenter Server も同じボリュームにあって死んでいる前提です。生きている場合はスキップ。
1. vSphere Client で vCenter Server が配置されていた ESXi サーバに接続。
  尚、ESXi をロックダウンモードにしている場合は、一度コンソールまたは SSH で接続してロックダウンモードを解除しないと接続できませんので注意してください。以下がロックダウンモードの操作系コマンドです。
```
vim-cmd -U dcui vimsvc/auth/lockdown_is_enabled ※確認コマンド
vim-cmd -U dcui vimsvc/auth/lockdown_mode_exit ※無効にする
vim-cmd -U dcui vimsvc/auth/lockdown_mode_enter ※有効にする
```
2. NFS ボリューム2 のデータストアブラウザで vCenter Server の vmx ファイルを右クリックしてインベントリに登録。
  このとき、ウイザード中で聞かれる仮想マシン名は平常時に記録しておいたものを参照して違っていれば修正すること。
3. vCenter Server を Windows Server Backup からリストア(手順省略)。
4. vCenter Server を再起動。ロックダウンモードを解除した場合は元に戻す。
vSphere Client で vCenter Server に接続。
NFS ボリューム2 のデータストアブラウザを開き、各サーバの vmx ファイルを右クリックして、平常時に記録しておいた仮想マシン名で適切な ESXi サーバ(またはDCやリソースプール)を指定してインベントリに登録していく。
各仮想マシンのスナップショットマネージャを開き、snapshot 作成時点に『移動(Revert)』し、完了したら snapshot を削除する。
各仮想マシンを起動する。

上記の手順は実際検証してみてうまくいっています。が、本番もこれを全部手でやるか、もしくはスクリプトを自力で作成しておかないといけないんでしょうか・・・。何かもっと簡単な方法は無いんだろうか。しかも上記の手順は全台を1つのバックアップジョブでバックアップしている場合です。複数のジョブに分けていた場合は、静止点がある Snapshot が1つでないので、SnapRestore で一気に戻すということができません。とりあえず一番最後に実行されたジョブの Snapshot に SnapRestore して、それより古い Snapshot にしか静止点が無いサーバは、Snapshot からファイル単位の SnapRestore または FlexClone ですかね・・・？どなたかアドバイスあればお願いします。m(_ _)m

NetApp の Virtual Storage Console (VSC) の挙動

0 件のコメント:

コメントを投稿

自己紹介

このブログを検索

ブログアーカイブ