株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

バルセロナより: Dockerとは? Containerとは? - その4 : CloudVolumes 改 AppVolumes

前回の記事ではVMwareが提唱・開発しているProject Fargoをご紹介しました。その目指すところはDockerよりもさらに高速なVMの配備です。前回の記事の中で伏線を張ったのですが、今回はこの伏線を回収しに行きます。Project FargoによってVMの作成、BIOS起動、VMのブートは瞬時にライブテンプレート(起動したテンプレート仮想マシン)のコピーが行われるため、不要になりました。しかしながらこのコピーされた仮想マシンたちはすべて金太郎飴のように同じ構成、同じアプリケーションがインストールされている状態です。技術的には大きな飛躍なのですが、ユーザー側からはまだ、取り回しが難しいと言わざるを得ません。

ここで、登場してくるのがVMwareが買収したCloudVolumesという会社です。この会社はハイパーバイザーのテクノロジーを利用しながら、OSに対して瞬時にアプリケーションの配信を行うテクノロジーを保持しています。Project FargoはOSに依存しないテクノロジーとして実装されますが、OSに対してアプリケーションの配信を行うためにはそれぞれのOSごとのマナーに従う必要があります。DockerではLinuxファイルシステムに対してCopy-On-Writeを提供するテクノロジーでコレを実装していますが、Windowsに対してはこの技術は利用できません。

LinuxのアプリケーションはUNIXの哲学に従っており、基本的に実行バイナリはステートレスである場合がほとんどです。Windowsの場合、ADやレジストリその他様々な要因がからみあってきてアプリケーションをステートフルに配布する場合も多いため、Linuxの技術をそのまま輸入してくるだけではそう簡単には行きません。

CloudVolumes(VMware社に買収後はAppVolumesと名前を変えたようです)はどのようにしてこれを解決しているのでしょうか?

cvagentは何をしているのか?

残念ながら、ここからはOSのマナーにしたがう必要があります。CloudVolumesを利用するためにはcvagentと呼ばれるWindows OS内にインストールするエージェントが必要です。

Fig154

このエージェントはWindows OSに対して2つのドライブをマウントして、隠し属性に設定します。ここではオフィスアプリケーションの配信を例に取りましたが、Windowsにオフィスがインストールされたドライブ(オフィスドライブ)とWritableボリュームの2つをマウントします。その次にエージェントはオフィスドライブの中身をCドライブと重ねあわせる処理を行います。本来は別ドライブとして構成されているドライブの中身があたかもCドライブにあるかのようにOSに振る舞わせるのです。このドライブ(オフィスドライブ)はRead Only属性になっており、別の仮想マシンへも同時にマウントさせることが可能です。また、このオフィスに対する設定ファイルなどの書き込みについては自動的にWriteableボリューム側へリダイレクトされます。このWriteableボリューム内のファイルもCドライブにあるかのようにOSから見えるようになっており、WindowsのOSマナーに従いながらも、アプリケーションを瞬時にWindows OSにアプリケーションを配布可能です。

これによってWindowsでも以前ご紹介したような、アプリケーションが自由自在に配布可能なインフラを実現することが可能です。Windowsを利用する場合にはCloudVolumesを利用すればよく、Linuxの場合は既存のテクノロジーを利用すればよいのです。

Fig155

アプリケーション用のヴォリュームは1つだけあればよく、VMごとにアプリケーションのためのWriteableボリュームが作られます。Linked Cloneのようにも見えますが、「OSに依存しない」という制限を取り去って実装されているため、リアルタイムに配信可能で、Writeableボリュームにそれぞれの差分がリダイレクトされるので、たまってしまうゴミを掃除する(コンポーザーのアップデート)のような処理も必要ありません。ストレージの節約にもなる上に、仮想化ならではの運用の不便さも解決しています。

Project Meteor/Just-in-time VM

これでWindowsVMに瞬時にアプリケーションを追加する方法が実現しました。Project Fargoを利用してライブクローンしたVMにアプリケーションをヴォリュームとして追加することが可能です。ブートやクローンという煩わしいプロセスは一切ありません。ここでとどまらないのがVMwareという会社のすごいところだと思います。

仮想マシンの使い方も変えてしまおうというプロジェクトが始まっています。Project Meteorと呼ばれています。VMworldではJust-in-time VMという言い方で紹介されていました。

Fig156

VMは構成やアプリケーションまで含めてすべて瞬間的に作れてしまうので、必要になったタイミングで作成し、不要になったら消してしまおうという考え方です。使ってもいないVMがリソースを利用しているケース(例えばVDI環境などは顕著です)にこの考え方を利用すれば、驚くほどリソースを削減できる可能性があります。例えば1000名の社員の会社だが、VMの同時利用は400程度というケースが出てくる場合、ハードウェアを40%だけで済ませられる可能性があります。今までもVMwareはHorizon View Standardで「最大同時接続数分のライセンス」という先進的な考え方のライセンスを持っていましたが、これが実現すると「ハードウェアも最大同時接続数分のみ」購入するだけで済むようになります。もしかするとvSphereのライセンスもハードウェアの呪縛から解き放たれて「最大同時VM起動数」でライセンスされるようになるかもしれませんね。

もちろん、Project Fargoで生成したVMをvMotionしたり、要らなくなったVMはリソースを全く利用しなくなりますので、DRS、DPMなどがより効力を発揮してきます。ハイパーバイザーはアプリケーションを利用している間だけリソースを利用しますので、リソースをプールとして活用するインフラがより重要になってきます。この技術が登場し、世に普及していく将来がとても楽しみです。

RUN DRS

ちょっと脱線しますが、上記のようなことを考えていましたので、今年のvForumでは今更!?と言われながらもDRSを動かそう!というプレゼンテーションをvExpertの皆様と一緒にミニシアターでやらせていただきました。ハードもソフトも「最大同時VM起動数」になるかどうかはさておき、DRSを活用するというのは来るべきJust-in-timeな時代に備えるという意味では非常に重要です。

是非DRSをOnにして、よどみに浮かぶ泡沫のように、生まれ、かつ消えていく仮想マシンが一時的に身をおく場所であるバケツ(DRSクラスタに割り当てられているリソース)を大きくしましょう!

Fig157

さて、本シリーズですが、次回が最終回です。間があかないように更新していきたいです。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)