本記事は全三回の連載になっています。本記事は全三回の連載になっています。興味のある方は他の回のコンテンツもご覧ください。
第1回: Nutanix Xtract for VMsは使えるのか？
http://blogs.networld.co.jp/main/2017/12/nutanix-xtract--61ff.html
第2回: Nutanix Xtract for VMs Deep Dive ～データ転送の裏側～
http://blogs.networld.co.jp/main/2017/12/nutanix-xtract--342e.html
第3回: Nutanix Xtract for VMs Deep Dive ～ハイパーバイザー変更を吸収する仕組みとは～
http://blogs.networld.co.jp/main/2017/12/nutanix-xtract--ae65.html
AHV移行時の課題
既存のHypervisorからAHVへ移行する場合、前回お話したように「ダウンタイムをいかに最小限にするか？」「何かあったときに容易に切り戻り（ロールバック）できるか？」という点が重要になってきます。この2点をどのようにXtract for VMsで解決しているのが、データの転送の観点からみていきたいと思います。
Xtract for VMsの移行の流れ
Xtract for VMsの移行はシンプルな移行ジョブとして作成されますが、当然裏側では様々なタスクが実行されています。スムーズな移行を実現するためにタスクを分類すると、「ダウンタイムを最小限にするためのデータ転送のタスク」と「移行元、移行先のギャップを埋めるための仮想マシン設定のタスク」にわけることができます。
今回はこのうち「ダウンタイムを最小限にするためのデータ転送のタスク」について掘り下げていきたいと思います。来週執筆予定の「Xtract for VMs Deep Dive第2回」では「移行元、移行先のギャップを埋めるための仮想マシン設定のタスク」について掘り下げる予定です。
ソースとなるvSphere環境から仮想マシン1台（Xt-02-w2k12r2）をAHV環境へ移行する流れは以下になります。今回はデータ転送が行われるフェーズの①～③について出力されるログをベースにどんな処理が実行されているのか見ていきましょう。
Migration Planの作成
↓
Migration Planの実行
↓①
CutOverの待機
↓②
CutOverの実行
↓③
Migration Planの完了
Xtract for VMsのデータ転送の仕組み(Migration Planの実行編)
Xtract for VMsでは「Migration Plan」の実行時に「Data Seeding」と呼ばれる移行元仮想マシンの全データの転送が行われます。このとき、仮想マシンはもちろんゲストOSの中で動作するアプリケーションは動作していて問題ありません。
この「Data Seeding」時は、以下のようなデータ転送処理が行われます。他にもゲストOS内で様々な処理が実行されますが、データ転送に関わる部分だけを取り上げています。仮想マシンがもつすべてのスナップショットが削除される点だけ注意が必要です。
これらのスナップショットの取得は、ソースとなる仮想マシンのvmware.logファイルにログが出力されます。「XTRACT-VMSnap-0」というスナップショットを取得していることがわかります。
|
2017-12-18T02:35:05.900Z| vmx| I125: SnapshotVMX_TakeSnapshot start: 'XTRACT-VMSnap-0', deviceState=0, lazy=0, logging=0, quiesced=0, force Native=0, tryNative=1, saveAllocMaps=0 cb=466AA50, cbData=32400020 2017-12-18T02:35:05.912Z| vmx| I125: DISKLIB-LIB_CREATE : DiskLibCreateCreateParam: vmfsSparse grain size is set to 1 for '/vmfs/volumes/ 32fae0e3-f1ee21fa/Xt-02-w2k12r2/Xt-02-w2k12r2-000001.vmdk' 2017-12-18T02:35:05.915Z| vmx| I125: DISKLIB-LIB_CREATE : DiskLibCreateCreateParam: vmfsSparse grain size is set to 1 for '/vmfs/volumes/ 32fae0e3-f1ee21fa/Xt-02-w2k12r2/Xt-02-w2k12r2_1-000001.vmdk' 2017-12-18T02:35:05.915Z| vmx| I125: SNAPSHOT: SnapshotPrepareTakeDoneCB: Prepare phase complete (The operation completed successfully). |
では次に気になるデータ転送の経路についてみていきましょう。
Xtract for VMsでは通常移行先のAHVクラスタ上にXtract for VMsの仮想アプライアンスを展開します。この仮想アプライアンスを中心にどういったデータ転送が発生するのでしょうか。
まずソースVMのデータのやりとりは、通常のvSphere環境でバックアップするときに用いられるVADP(vStorage API for Data Protection)と呼ばれるAPIを利用しています。ソースの仮想マシンに対してスナップショットを実行して、仮想ハードディスクに対して読み取り専用でアクセスすることができます。
そしてターゲットVMのデータのやりとりは、AHVクラスタ上の「Storage Container（データストア）」をXtract for VMsのゲストOSがNFSマウントすることで、直接AHVクラスタへデータを書き込みます。一度Xtract for VMsにデータを保存して、それをもう一度AHVクラスタへ書き込むようなことはしていません。そのため、データ転送自体最短で完了することができますし、移行元のデータサイズによってXtract for VMsにローカルディスクを追加する必要もありません。
図としてあらわすと以下のようになります。
これらの一連のタスクのログは、Xtract for VMsのサポートログの中に、xtract-vm-diskreader.log,xtract-vm-diskwriter.logのログとして保存されています。
Data Seedingフェーズではこのような動作で、Xtract for VMsを介して移行元仮想マシンのデータを移行先のAHVクラスタへデータを転送しているようです。
Xtract for VMsのデータ転送の仕組み(Cutoverの待機編)
先ほどのData Seedingフェーズで全データを転送しましたが、アプリケーションは起動状態だったため最後にデータ整合性を担保したデータで上書きする必要があります。
しかし、仮想マシンの移行時にData Seeding後にすぐに移行（Cutover）をするとは限りません。動作確認等を入念に行ったり、短時間とはいえシステム停止が必要なためメンテナンス時間の調整で、一ヵ月先になったりすることも当然考えられます。
例えばData Seedingを行ってから一ヵ月後に移行する場合、一ヵ月の差分データを移行直前にすべて転送完了する必要があります。アプリケーションやデータ構造によっては大部分のデータを再転送することも考えられます。その場合、データサイズによってはシステム停止の時間が長時間になってしまいます。
システム停止時間を最小に抑えるためにXtract for VMsではData Seeding完了後からCutoverが実行されるまでの間は10分間隔で移行元仮想マシンのデータを移行先AHVクラスタへ差分転送が実行されるアーキテクチャになっています。
こうすることで、アプリケーションやデータ構造によるデータ変更量の多少、Data SeedingからCutoverの期間に長さに関わらず、Cutover時には最長でも10分前のデータが担保された状態を維持することができるのです。
10分間隔と非常に短い間隔で実行されていますが、差分データの取得にはData Seeding時と同じVADPのCBT(Change Block Tracking)の機能を利用しているため、すべてのデータの差分チェックを行う必要はありません。既に変更があったブロックを認識しているため、変更ブロックだけを速やかに差分転送することが可能なアーキテクチャを採用しています。
Data Seeding時と同様に移行元仮想マシンのvmware.logファイルにCBTを利用した差分データの取得のログが出力されます。
|
２017-12-18T06:29:22.324Z| vcpu-0| I125: DISKLIB-LIB_BLOCKTRACK : Resuming change tracking. 2017-12-18T06:29:22.326Z| vcpu-0| I125: DISKLIB-CBT : Initializing ESX kernel change tracking for fid 1327949945. 2017-12-18T06:29:22.326Z| vcpu-0| I125: DISKLIB-CBT : Successfuly created cbt node 4f26e879-cbt. 2017-12-18T06:29:22.326Z| vcpu-0| I125: DISKLIB-CBT : Opening cbt node /vmfs/devices/cbt/4f26e879-cbt 2017-12-18T06:29:22.326Z| vcpu-0| I125: DISKLIB-LIB : Opened "/vmfs/volumes/32fae0e3-f1ee21fa/Xt-02-w2k12r2/Xt-02-w2k12r2-000001.vmdk" (flags 0x8, type vmfsSparse). 2017-12-18T06:29:22.327Z| vcpu-0| I125: DISKLIB-CBT : Shutting down change tracking for untracked fid 1257695343. 2017-12-18T06:29:22.327Z| vcpu-0| I125: DISKLIB-CBT : Successfully disconnected CBT node. 2017-12-18T06:29:22.328Z| vcpu-0| I125: DISKLIB-CBT : Shutting down change tracking for untracked fid 1327949945. 2017-12-18T06:29:22.328Z| vcpu-0| I125: DISKLIB-CBT : Successfully disconnected CBT node. |
Xtract for VMsのデータ転送の仕組み(Cutoverの実行編)
さて最後になりました。実際にvSphere上で動いている仮想マシンを停止して、AHVクラスタ上で仮想マシンを起動する「Cutover」フェーズの動作をみていきましょう。
まずソースとなるvSphere上の仮想マシンでは以下のようなタスクが実行されます。
- Guest OSの停止
- スナップショットの取得
- （データ整合性が担保される、差分データ転送）
- スナップショットの削除
- 仮想マシンのNICの接続を解除
- Migrate Plan実行時に取得したスナップショットの削除
先ほどCutoverの待機編で説明したように、直近10分前のデータ同期が完了しているためこの3の最後の差分データ転送が短時間で完了するため、まるでOSのパッチ適用をするぐらいのメンテナンス時間で容易に移行できるのがXtract for VMsの最大の特徴ということができます。
そして移行先となるAHVクラスタ上ではPrismを確認すると以下のようなタスクが実行されます。今回の移行元仮想マシンが仮想HDDを2つ持っているためImageが2つ作成されています。
今回はXtract for VMsを使ったvSphereからAHVへの仮想マシンの移行の際のデータの転送の仕組みについて掘り下げて紹介してみました。次回はどうやってハイパーバイザーの違いを吸収しているのか、ゲストOSで実行されているXtract for VMの移行タスクについて掘り下げて紹介してみたいと思います。
ではまた来週。
