みなさん、こんにちわ。またも一週間が経ってしまいました。
さて、伏線を張りっぱなしの記事は以下です。
今回の記事は前回のCloud Native Appsについての記事の続編です。
前回はVMwareはCloud Native Appsの受け皿として従来からのvSphereプラットフォームの拡張(vSphere Integrated Container)と全く新しいPhotonプラットフォームの2つで対応していくというビジョンを発表したというところまでお伝えしております。こちらの例えですね。
この喩えが優れているのは仮想マシン(乗客)とコンテナ(貨物)の両方をホストできる飛行機として、vSphere、コンテナ(貨物)専用としてPhotonプラットフォームを上げている点はもちろんですが、いずれも飛行機としての基盤は同じ、すなわち、vSphereもPhotonプラットフォームもいずれも共通の基盤をベースとしており、NSX、VSANなどVMwareの優れたイノベーションはいずれのプラットフォームでも利用できるということです。それぞれを詳しく見ていきましょう。
vSphere Integrated Container(VIC)
VICを利用すると変わることは何でしょうか? VICはContainerとVMの垣根をなくす技術の連合軍だと思うのが良いと思います。では、ContainerとVMの垣根とは?前回の記事にもありますが、以下のとおりです。
- ワークロードの起動が遅い
- ワークロードの統合率が良くない
- ワークロードの構成が不便
- 管理者が手軽にワークロードを作り出しにくい
起動が遅い点についてはInstant Clone(旧Project Fargo)によって克服ができました。統合率が良くないという点についてはPhoton OSという非常に軽量なOSを利用することでこれを克服しています。Photon OSは25MBしかないOSで、これがインスタントクローンで瞬時に複製されますので、統合率にも優れ、さらに起動のスピードも後押しします。これで、1と2がカバーされています。
ワークロードの構成が不便という点はVirtual Container Host(VCH)というものを用意しています。これはDockerエンジンと同じコマンドセットを理解するLinuxベースの仮想マシンです。開発者はLinux上でDockerエンジンを実行して様々なコマンドセットを利用してワークロードを自動的に構成しますが、VCH上で全く同じコマンドを実行することが出来るようになっています。
開発者から見ると今までと同じフレームワークで開発環境を展開できるようになっているので、3つ目の問題が完全に解決するだけでなく、4の問題は消滅します。つまり管理者はワークロードの構成にタッチする必要がなくなり、従来通りVMとしてContainerを管理できるようになるわけです。
Photonプラットフォーム
さて、もう一つのPhotonプラットフォームについては貨物専用機なのですから、ESXをベースとしながらも、不要なものを削ぎ落としたものです。飛行機で言うと客室のシートやギャレット、手荷物用格納スペースなどに当たりますが、ESXからマイクロサービスで冗長化されているCloud Native Appsには不要なHAやFT、それからVDP、SRMなどの可用性機能、マイクロサービス内で負荷分散されているため、不要になるvMotion、Storage vMotion(もちろんDRS/SDRSも)なども削ぎ落とされています。共通してみえるのはAuto Deployなどぐらいでしょうか。ここまで徹底的にダイエットした上に、更に上で動作するのは先にも出てきたPhotonOSをベースとしたワークロードです。vCenterでは10000VMまでの仮想マシンを管理できますが、Photon Platformではそれを遥かに超える数のワークロードを管理することができるそうです。
APIについても幅広くサポートされており、開発者は様々なフレームワークを通して開発を行えるようになっています。(上の図ではCloud Foundry、Kubernetesのコマンドでアクセスしている例が出ています。Kubernetesについてはこちらもご参照ください。)
vSphere Integrated Container/Photon Platformはいずれもプライベートベータからスタートしていくとのことですので、ご興味のある方は是非お問い合わせください。
ようやくVMworld 1日目の伏線を回収し終わりました。。。さて、2日目の伏線も回収しに行きます。(来週にでも･･･。)
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
