VVolで憶えていてほしい3つのこと

Virtual Volumes (VVol)の周辺がずいぶんと騒がしくなっているようですね。2015年2月に開催されたPartner Exchange会議の会場で、VMwareがこの統合・管理用フレームワークの利用開始を発表したからなのでしょう。長い道のりでした――。思い起こせば、 VMwareがそのコンセプトを初めて紹介したのは、2011年に開かれたVMworldのときだったのですから。

一方でTintriも、仮想マシンレベルでのその可能性について、推考を重ねていたのです。事実、当社初のVMstoreの提供を開始したのは2011年ですし、これとほぼ同時期にVMwareがVVolの構想を提案したのです。Tintri by DDNでは、設立当初から仮想マシンや仮想環境下に特化した製品を開発してきていて、2005年の当時ではすべてのワークロードの中でわずか2%を占めるに過ぎなかったのに、今やそれが75%までに至っているのです。最新のデータセンターでは、仮想マシン環境を想定して作業するように進化を遂げているので、Tintriによってそれを実現できたことは、大変に幸せな気分です。

ですから、安心してお任せください。Tintriは、VVolへの対応準備ができています。今回は特に、VMware Virtual Volumesに関して、心にとどめておくべき3つのポイントを紹介することにしましょう。

1.VVolを従来のストレージに追加するだけで、仮想化で発生するストレージの問題がすべて解決されるわけではありません。

従来のストレージはLUNやボリュームを主体に管理しています。仮に、あるアプリケーションのパフォーマンスに不具合が発生したとしましょう。従来のストレージでは、仮想レベルでピンポイントにその問題の原因を特定することはできません。――と言うのも、従来のストレージではLUNレベルで作動しているからです。仮想レベルでこの問題を可視化できないと言うことは、問題を特定して解決に導くのに、不可能とは言わないまでも、難しいことでしょう。

VVolに層を重ねる際、ストレージの管理者はストレージのコンテナ(LUNを切り分けるような類です)を設けて、それぞれにある特定のポリシー(パフォーマンスやクローニング、スナップショットフリークエンシ-等)を割り振ることができます。そうすると、この仮想環境管理者は、プロビジョニングを行う各々の仮想マシンのパフォーマンスの特性を選べるようになります。また、 VVolは仲介役の機能を果たし、仮想マシンを適切なストレージ コンテナに連携させ、必要に応じて調整します。

一応、この方法で目的は達したことにはなりますが、Tintriはこのワンランク上を可能にさせます。当社の手に掛かれば、仮想化やストレージ管理者がお望み通りの正確なポリシーを、すべての個々の仮想マシンに実装できるようにします。コンテナ(もしくはLUNやボリューム)ごとにそれらのポリシーを区分けする必要はありませんし、仮想マシンが、まさしくコンテナとなるのです。――これは、最もきめ細やかな対応が可能な状況と言えるでしょう。これこそが、真の仮想マシン・ストレージです。

2.VVolはAPIなのです。

つまり、ストレージ ベンダーが提供するレベル如何によって、 VVolの性能を最大限に引き出せるかどうかが左右されるのです。そう、すべてのVVolにどれも同じように実装ができるわけではないのです。アーキテクチャーの例からも分かるように、従来のストレージプロバイダーのほとんどは、最も基本的なVVolの特性をサポートするにとどまるのです。

大部分のストレージ プロバイダーは、200から1,000のVVolサポートを目標にしていますが、今日のTintri by DDNでは100万ものVVolをサポートしています。大袈裟に聞こえますか?しかし、実際は想像するよりも多くのVVolが必要になります。1台の仮想マシンを構成するためには、(少なくとも)3つのVVolを使いますし、スナップショットが増えるたびに、(少なくとも)さらに2つのVVolが必要となるのです。データセンターのような場所では、何百もの仮想マシンに数ダースのスナップショットが自動的に行われるので、瞬く間にVVolの数が増えていってしまうことでしょう。

従来のストレージアレイでは、たいていが比較的少ない数までのLUNやボリュームを管理するだけなので、この『ユニット』の数分を運用するためには、オペレーティングシステムを書き換える必要があるかも知れません。この点からも、VVolのAPIの活用には、適正な構築能力のあるストレージプロバイダーを選ぶことが重要なのです。

3.VVolだけでは仮想マシンのパフォーマンスを保証できません。

仮想環境の管理者が望むパフォーマンスの特性を選択すると、VVolのAPIは、その要求に最適なストレージコンテナを選びますが、この作業がいつもうまく機能するとは限りません。割り振られたコンテナには、他の仮想マシンに代わって、ノイジーネイバー(うるさい隣人)と呼ばれる、張り切ってパフォーマンスを行うような危険な仮想マシンがいくつか存在するかも知れません。そこでVVolが、仮想マシンを適正化に劣る特性を持つ別のコンテナに再び振り分けてしまう可能性だってあります。言い換えれば、ストレージ管理者がどのようなサービスを望もうとも、これらの問題がすべて発生した場合、可視性やコントロールは非常に限られてしまいます。VVolを備えた仮想マシンであっても、これまで通りLUNとボリュームに翻弄されてしまうのです。

でも、Tintri by DDNではこのようなことは起こりません。それぞれ個別の仮想マシンに、ストレージ管理者の望みどおりのQoSを提供するので、コンテナ間を行き来することなどありません。――こうすることによって初めて、仮想マシンとしてのパフォーマンスを保証できると言えるのです。