まだ仮想環境がなかった時代のストレージは、物理サーバと1対1の関係にありました。I/Oは物理サーバごとに管理され、「LUN」と呼ばれるストレージ内の論理区画と物理サーバは1対1でマッピングされていたのです。

>>仮想化専用フラッシュ・ストレージTintri<<

しかし、仮想環境の台頭で、この関係性は崩れました。仮想環境では、物理サーバの中にある、さまざまな仮想マシンが、ランダムにI/O要求を行います。前回紹介したように、従来型ストレージ(SANストレージ)ではワークロードの優先度にかかわらず、順次I/Oを処理します。そのため、例えば1台の仮想マシンが過大なI/O要求をした場合にはI/O渋滞が発生し、他の仮想マシンの性能が低下してしまいます。

この問題を解決するのが、仮想環境に最適化されたNAS(NFS/SMB接続)ストレージ「Tintri VMstore」です。従来型ストレージとはアーキテクチャが根本的に異なり、I/O渋滞を発生させることがありません。

従来型ストレージ(上)と「Tintri VMstore」(下)のアーキテクチャの違い。「Tintri VMstore」では「ストレージが持つファイルシステム」および「仮想マシン管理データベース」によってI/O要求を仮想マシンおよび仮想ディスクごとに直接マッピングして管理し、最適なストレージ性能を割り当てる

従来型ストレージは、LUNやボリューム単位でストレージ領域を切り分けて管理しなければなりません。I/O処理は仮想マシン単位ではなく、SCSIベースのブロックデータの塊での単位で行います。そのためストレージ側が、「どの仮想マシンが、どのようなデータを出力しているのか」といった、仮想マシンごとの状況を把握することはできません。その結果、データ処理の優先順位をつけることができず、I/O渋滞が発生してしまうのです。

一方、「Tintri VMstore」は、ストレージ側が個々の仮想マシンや仮想ディスクを認識したうえで、I/O処理を直接管理します。Tintri VMstoreのオペレーティングシステムである「TintriOS」に備わっているファイルシステムは、I/O要求を仮想マシンごとに直接マッピングしてデータベースとして管理し、それぞれのアクセス分析を行ったうえでストレージ容量を仮想マシン単位に割り当てます。これにより、仮想マシンが互いに影響を及ぼすことなくパフォーマンスを発揮できるのです。

そしてTintri VMstoreは独自アーキテクチャとして、仮想マシン単位で「専用I/Oデータレーン」を設けています。それぞれのアプリケーションのワークロードを専用レーンで分離してI/O渋滞を回避し、パフォーマンスを最適化することで、システム全体を安定稼働させているのです。仮想マシンの動きを理解し、個々の要求に応じて柔軟に処理する性能を備えるストレージは、Tintri VMstoreだけと言ってよいでしょう。

「Tintri VMstore」は仮想マシン単位で「専用I/Oデータレーン」を設けているので、他のVMのワークロードに影響されることがない

最近ではオールフラッシュの高速ストレージも数多く登場しており、「処理能力が高速であれば、I/O処理をチューニングする必要がない」と安易に考えがちですが、それは早計でしょう。将来的にオールフラッシュのストレージが普及すれば、アプリケーション自体がそのストレージ性能に合わせて設計されます。そこでの評価ポイントは、「ストレージが各仮想マシンの動きを理解し、制御できる機能を備えているか」なのです。

>>仮想化専用フラッシュ・ストレージTintri 詳細資料はこちら<<

[PR]提供:Tintri