仮想化技術の最新動向、デスクトップ仮想化とストレージについて～仮想化エバンジェリストのタカハシ氏に聞く（後編）

2010年8月20日

最近の仮想化の動向について、仮想化エバンジェリストのタカハシ氏にインタビューをしています。前編では、VMwareが先月リリースしたvSphere 4.1への評価を中心にお話を聞きました。

今回の後編では、最近注目度が高まってきている「デスクトップ仮想化」および仮想化の最新技術動向について聞きました。

クライアント環境の最適解は1つではない

―― 国内では、デスクトップ仮想化の話題も増えはじめていますが、実際に現場でデスクトップ仮想化に対する顧客の反応はどうでしょう。また、製品の成熟度などはどう見ていますか？

話題が増えているのはおっしゃるとおりです。また製品面でも、たとえばVMwareもVDIからViewになってずいぶん進歩しましたし、シトリックスの製品群は昔から今日に至るまで大変すばらしいソリューションを提供してくれています。

お客様からもデスクトップ仮想化というご要望での相談は増えています。でも、実際にコンサルトしてコストや運用体力などを勘案すると、仮想デスクトップが最適解になるケースばかりではないんですよね。

例えば、Windows Terminalや専用端末によるシンクライアントが最適解になるようなお客様もいらっしゃいます。アプリケーション仮想化やアプリケーションストリーミング、あるいは、これらいずれでもなく、物理デスクトップをライフサイクルマネジメントして使うのが最適解になるケースや、これらの混在環境など、お客様の環境によって、最適解というのは本当に異なっていて、ばらつきも大きいです。

だから、クライアント環境の最適化は仮想デスクトップ一本で考えてはいけないと思っています。

―― なるほど。必ずしもデスクトップ仮想化がベストというわけでもないのですね。

仮想デスクトップは、物理的なデスクトップに次いでエンドユーザに最大限の自由度を提供するソリューションです。しかし、その自由度に対して運用や導入のコストなどの点でトレードオフがあります。

そこで、エンドユーザの自由度が欲しいケースでは物理デスクトップと仮想デスクトップのどちらにするかで悩むことが多くなります。

もちろん、物理デスクトップの管理が大変だから、ということでそれ以外のソリューションを検討されるわけですが、情報システム部門の皆さんは、物理環境については長年の運用経験があるので、大変ではあるけどノウハウもある。

それに対して、仮想デスクトップにはノウハウを持たない顧客が大半です。ここが選択のポイントになる場合もあります。

また、CADなどのハイパフォーマンスデスクトップ分野では、グラフィックスアクセラレータハードウェアの存在が重要になるケースもあります。仮想デスクトップでこの問題を解決するのは簡単ではありません。

仮想デスクトップにばかりネガティブなことを並べましたが、これは他のソリューションでも同じで、それぞれ長所と短所があります。

部門ごとに異なるデスクトップに対する要求をどうさばくか、モバイルはどうするか、印刷やローカルUSBデバイスをどうするか、認証やセキュリティをどうするか、など、いろいろ検討した結果、複数のソリューションを混在して利用するケースは珍しくありません。

クライアント問題を解決するには顧客ごとの処方箋が必要です。仮想デスクトップは話題ではありますが、それ以外にもさまざまなソリューションを並べて、いちばんいいとこどりをしていただきたいと思っています。

手前味噌ですが、私どもユニアデックスなら、どんな組み合わせでも提案させていただくことが可能ですので、ぜひ一度ご相談いただきたいです。

ストレージの動向、デデュープはエンタープライズストレージの標準に

―― 最近、vSphere 4.1 API対応やデデュープ（重複排除）機能の広がりなど、ストレージでの仮想化対応が進んでいるように思います。タカハシさんがいま気しているストレージの動向があれば教えてください。

ストレージのデデュープやリアルタイム圧縮はやはりホットな領域ですね。これまで、物理環境で1Uサーバがスプロール（増殖）していても、それぞれのサーバでローカルなDAS（Direct Attached Storage、つまり内蔵ディスク）が使われている限りは、みんなあまり気にしていませんでした。

しかしサーバ仮想化のためにSAN（Storage Area Network）環境でストレージを共有した場合、VMスプロールが発生すると共有ストレージ上に作成した各VMで共通するファイル、たとえばWindowsのntoskrnl.exeとか、Linuxの/sbin/initとかがVMの数の分だけコピーされて重複しているのが容量的にバカにならなくなってきたんですね。

VMはどんどん増やせるので、VMスプロールのほうが物理サーバのスプロールより気軽にできて、それだけストレージのムダが深刻になる場合が多いのです。

最近流行のデデュープの利用シーンは、大規模VMware環境で、ESXサーバのSANブート用のシステムディスクをデデュープして、数十～数百台のブートイメージを1台分かそれに近い実使用容量でまかなう、なんてのがあります。

デデュープされたストレージは、Readに対しては若干のパフォーマンスペナルティがあるのですが、ESXのブート用途なら起動後はそれほどアクセスされるわけでもないので問題にはなりません。デデュープのよさが最大限に活きる使い方だと思います。

デスクトップクライアントの仮想化でもデデュープは効きますね。ただ、これにはちょっと注意が必要で、Windows UpdateやOfficeソフトウェアのバージョンアップが行われることに対して仕組みや手順をどうするか考慮しておかないとハマることがあります。

というのも、リアルタイムにデデュープしてくれる製品だと、利用者がさみだれ式にWindowsやOfficeをアップデートすると、その最中にはパフォーマンスの問題が起こる場合があるのです。逆に、後からバッチ処理でデデュープするような製品だと、バッチが走るまでの間、通常運用の時の何十～何千倍もの実容量が必要になったりします。

クライアント仮想化製品のテンプレート機能をどう使うかとか、ソフトウェアのアップデートをどうやってやらせるかとか、予備ストレージをどのくらい持つかとか、色々考慮しなければならないので、かなり注意が必要ですね。もちろん、うまく使うことでストレージコストをぐっと抑えられる技術ではありますが。

業界的にも、この領域はホットです。某「D」サーバベンダも、先日デデュープとリアルタイム圧縮の会社を買収しましたし、他の某「I」サーバベンダも先日、噂どおりにリアルタイム圧縮会社を買収しました。

デデュープと圧縮は、多くのエンタープライズストレージの標準機能になっていく可能性があるのではないでしょうか。

サーバの統合率が上がっている

―― そのほか、最近タカハシさんが気になっている仮想化での動向があれば教えてください。

さっきのvMotionが10Gbpsで同時に8つできる、という話で思い出しましたが、サーバ統合が進んで、Gigabit Ethernetの速度飽和が問題になるケースが増え、10Gbps Ethernetの導入が進んできています。

以前よりもサーバの統合率が上がってきてるんです。

仮想化をはじめた顧客は、最初は「1物理CPUコアあたり1仮想サーバ」というようなコンサバティブな設定値でスタートしますが、だんだん統合率を上げていくのが一般的です。かなり統合率が上がってきている背景には、VMスプロールの発生、新規のハードウェア投資抑制でGOSを増やさざるを得ない、などのネガティブな要因と、ハードウェアやハイパーバイザの進歩というポジティブな要因、それに運用してみたら意外と大丈夫でユーザが自信を持った、などの複合的な要因がからんでいると思います。

こうした高い統合率に対して、最近のCPUは能力が高いので結構持ちこたえてくれるのですが、しかしメモリ容量の不足や、ストレージI/OとネットワークI/Oの能力不足など、別の部分にしわ寄せがくるケースが徐々に増えてきています。

メモリ容量の不足に対してハイパーバイザベンダからのアプローチは、VMwareは昔からあるメモリオーバーコミット機能に加えてメモリ圧縮機能を出してきていますし、Hyper-Vではダイナミックメモリでこの課題に対処しようとしています。

一方でハードウェアベンダからは、シスコを皮切りに、DELL、IBMとメモリ容量の増加機能を強化したサーバが続々出てきています。

I/Oについても、DCB 10Gbps Ethernetを標準装備としてFCoEで統合を加速したいシスコや、Virtual Connect FlexFabricで対応するヒューレット・パッカードなどのサーバベンダ、16GbpsのFC（Fibre Channel）をリリースを急ぐ各ファイバーチャネルベンダなど、それぞれの取り組みも進んでいます。

こうした高速I/Oを仮想化環境で十分に活かすために、Intel VT-dやSR-IOVレベルの局所最適化技術は実装が進んでいますが、いかんせんこれだけでは柔軟なデータセンタ構成をしようとしても制約がいっぱい残るので、MR-IOV（Multi Root I/O Virtualization）や、あるいはRDMA/iWARP（Remote Direct Memory Access/Internet Wide Area RDMA Protocol）みたいなモノも早く実装が進んで、使えるようにならないかと思っています。

もうこの辺まで来ると、I/O channelなメインフレームとどこが違うんだという気がしてきますが（笑）

―― ありがとうございました。