バルセロナより: Dockerとは? Containerとは? - その3 : Project Fargo

前回はDockerとCopy-on-Writeの技術を利用することで、アプリケーション･ミドルウェアを含めての開発環境の準備が迅速になり、アプリケーション主体の会社においては大きな無駄を省ける用になるということと、Containerだけでは、HA/vMotionなどのITインフラ管理者にとっては不可欠になっている機能を実装できないので、ContainerをVMの内部で動かすことで、開発者、IT管理者双方にとっての理想的な環境を実現しつつ、さらにパフォーマンスへの影響も殆ど無いということを述べてきました。

そんな中でもまだまだ不合理な部分があります。それはDocker/ContainerはOSの下のレイヤーでの分離を実現するテクノロジーではないため、各OSごとに別々の実装が必要になってしまうということです。OSに依存しないレベルで、Docker/Containerのような俊敏性を提供する方法はないのでしょうか?(この表現は若干微妙では有りますが、後々補足いたします。) VMware社はすでに次の手を打っています。

Project Fargo または Project VMFork

まずはContainerの軽量さを掘り下げてみると、OSを起動しなくて済むということがわかります。Container環境が利用可能になるまでのコストはほぼアプリケーションを起動する時間と等価です。ハイパーバイザーではLinked-Cloneを使ったとしても、VMの起動(BIOS起動)、OSの起動、それからアプリの起動と余計な時間がかかってしまいます。これを凌ぐ俊敏性を実現するための方法としてVMwareはVMFork改Project Fargoというテクノロジーを提唱･開発を行っています。誤解を恐れずに一言で表現するとVMライブクローンとも呼ぶべきテクノロジーです。電源を入れる時間が足を引っ張るなら、電源を入れておいたVMをそのままクローンしてしまえばいいじゃないか!といういかにもVMwareらしい発想の転換です。

VMを生きたままコピーする!? vMotionを足がかりに考える。

VMのライブコピーといえば、みなさんがよく知っているvMotionが挙げられます。vMotion自身の実装は様々なところで解説されていますので、詳しくはそちらをご参照いただきたいのですが、簡単に言ってしまうと、以下の様な動き方をしています。

vMotionソースホスト上のVMのメモリをターゲットホスト上にコピーする
1のコピーが完了後、ソースホストで変更されたメモリデータ差分を再度ターゲットホストにコピーする
2の操作を何度か繰り返し、差分が殆どなくなったらソースホスト上のVMをロックする
最後の差分をターゲットホスト上のVMにコミットする
ターゲットホスト上のVMからディスクアクセスを開始
ソースホスト上のVMのインスタンスを削除する

上記のような手順を実施すればOSが物理ホストを飛び超えて生きたまま移動することができます。ただし、今回やりたいのはホストを超えることではありません。そうなるとこの手順は以下のように変わります、また、移動ではなくコピーなので最後の手順も不要でが、コピー元を削除しないため、2つのVMのインスタンスが同じディスクに対してアクセスを始めてしまうため、このままではうまく行きません。別の排他的なディスクアクセスを生み出すために、新しいVMのディスクアクセスは前回もご紹介したCopy-On-Writeで新たに隔離する必要があります。