From the VMware Field: Mike D's Virtualization Blogという、VMwareでシステムエンジニアを務めるMike DiPetrilloさんのBlogがなかなか興味深い。で、このBlogにこれまたなかなか読み応えのあるPart I: Quick Migration vs VMware VMotion and Live Migration - Why Things Fail with Quick Migrationという記事が投稿されたのだけれども、メインテーマはBlogそのものをお読みいただくものとして、ここではこのエントリーの中に含まれているVMotion時のネットワーク接続の維持方法についての解説の部分を英語の勉強を兼ねて訳してみることにする。ご指摘・誤り訂正など大歓迎。
How VMotion Keeps the Network Alive
During a VMotion or even a live migration from other Xen based vendors the network failover happens relatively quick (generally less than 1 second). The VM is never suspended and resumed during the process. Here’s a simplified flow of what happens during a VMotion process.
- The VM configuration is created on the destination node.
- A memory map is created on the first node of active pages of memory and the map is sent to the destination node.
- Upon receiving the memory map the destination node demand pages the memory being used from the first node and places it in the new VM’s memory pages on the destination node.
- Clients are still connected to the source node and changing memory and so a new memory map is created of just the changed pages. This list is shorter and it is sent to the destination node.
- The destination node again demand pages the memory over to the destination node. This process takes a shorter amount of time than the first process and so less memory changes on the source node while this occurs.
- This back and forth recursive memory copy continues until we get to a point where we think we can grab the last bit of memory in 1 second or less of downtime.
- At this point we actually stop processing on the source node, grab the last little bit of memory that has changed, and start processing on the destination node.
- Immediately when the destination node takes over the VM reverse ARP’s out to the network to help with network convergence. This lets all of the new frames come to the correct ESX host and to the new VM location.
- All of this happens well under the TCP session abort time and so no client connections are interrupted.
VMotionではどのようにネットワークの接続状態を維持しているのか？
VMotionや、他のXenベース製品におけるライブマイグレーションを実行している間、ネットワークの継続的な切り替えは非常に素早く実行される(一般的に1秒未満)。仮想マシンはこれらのプロセスを実行している間にサスペンドやレジュームすることはない。ここでは、非常に簡単にVMotionプロセスの実行中に何が起きているのかについて解説しよう。
- 仮想マシンの構成情報が移行先ノードにおいて作成されます。
- 移行元ノードにおいて使用中のメモリのアクティブページを含むメモリマップが作成され、移行先ノードに送信されます。
- そして、移行先ノードはメモリマップを受け取ると、移行元ノードにおいて使用されているメモリページを要求し、それを移行先ノードに用意した新しい仮想マシン用メモリページに配置します。
- クライアントはまだこの時点では移行元ノード側に対して接続しており、最初の送信後に変更されたり新規に作成されたりしたメモリマップを再度作成する。これは非常に小さく、再度移行先ノードに送信されます。
- 移行先ノードでは、再度メモリのページの更新が行われる。この処理は最初のメモリマップの転送時と比較して非常に短時間で実施されるため、移行元ノードとメモリ状態に違いは生じません。
- この再帰的なメモリのコピー処理は、私たちが最後の1ビットのメモリデータを1秒以下のダウンタイムで送信を完了できる状態となるまで続けて実行されます。
- この段階で、私たちはついに移行元ノード側のプロセスを停止させ、非常に小さなメモリデータの転送が行われた後、移行先ノードでのプロセスの実行を開始します。
- プロセス実行の移動が行われると、移行先ノードはすぐさま移動させた仮想マシンからのリバースARPをネットワークに送出し、ネットワークに対する接続構成に変更が生じたことを通知します。これにより、全ての新しい通信フレームは移行先ノードとなったESXに対して送られ、新しい仮想マシンの配置パスに届けられます。
- これらの動作はTCPセッションよりも下の階層で処理されるため、クライアントの接続が切断されたり問題が発生することはありません。
んー、もうちょっとスマートに訳せそうだな。
