次に、ハイパーバイザ型で仮想化した場合について述べる。
この場合、ホストOSが介在しないため、仮想マシン側のOSが提供するファイルシステムは、“ほぼ”物理マシン上に構成されたOSの場合と同じように考えることができる。従って、ホストOS型のような考慮は必要がない。ただし、ただし、ハイパーバイザ型の仮想化ソリューションの種類によって若干事情が異なるので、その点に絞って説明する。「“ほぼ”物理マシン上に構成されたOSの場合と同じ」と記述したのはそのためだ。
まず、物理マシン上に構成されたOSと同じように考えてよいケースについて説明する。
最も一般的な例は、ゲストOSから物理的なハードディスクを直接扱えるようにするVMware ESX のRaw Device Mappingを使用した環境である。
この構成の場合、ゲストOSから見えるハードディスクには「細工」がされていない。前述のホストOS型仮想化の場合は、ゲストOSから見えるハードディスクの実態は「ホストOS上のファイルシステム上に配置されたファイル」であったが、ハイパーバイザ型仮想化の場合、ゲストOSから見えるファイルシステムは、ハードディスク上に直接置かれたファイルシステムと考えてよい。
従って、例えばゲストOSがWindows XPであれば、第2回で説明したNTFSのデフラグを設定するだけで、ファイルシステムのフラグメントによるパフォーマンス劣化は防げる。ただし、VMware ESXのユーザーにおけるRaw Device Mappingの使用例は少数である。
次は、物理マシン上に構成されたOSと同じとは言えない場合について説明する。最も一般的な例は、VMware ESXのVMFSを使用した環境である。この場合、VMFSと呼ばれるVMware ESX独自のファイルシステム上に、ゲストOSに提供する仮想ハードディスクとして「VMDK」という形式のファイルを配置する。
一見、ホストOS型と同じように感じるかもしれないが大きな違いがある。前述したホストOS型の例では、VMware WorkstationはWindows 2008のアプリケーションの1つとして動作するので、VMwareと並行してほかのさまざまなアプリケーションがWindows 2008のNTFS上でファイルの作成と削除を繰り返し、ファイルシステムのフラグメントを引き起こす可能性がある。このため、ホストOSとゲストOSの両方の考慮が必要となる。一方、VMware ESXのVMFSをフラグメントさせる要因はそれほど多くはない。特に、ゲストOSに提供する仮想ハードディスクのサイズをあらかじめ決めておく固定VMDKを使用していれば、VMDKファイルのサイズに変動がないので、VMFSにフラグメントは発生しない。また、ユーザーがVMFS上に自由にファイルの作成と削除を行えないのもホストOS型との大きな違いだ。
例外は、固定VMDKを採用しておらず、ゲストOSが使用する仮想ハードディスクの容量が大きく変化する(=VMDKのサイズが大きく変化する)ケースである。この場合は、ホストOS型ほどの頻度は必要ないものの、VMDKファイルの最適化を意識する必要がある。
第3回では、仮想化環境特有のファイルシステムに関する留意点について述べた。前回までに述べた内容を仮想化環境でどのように応用すべきかがご理解いただけたと思う。
「ビッグデータ」という言葉が一般的になって久しい今日、大容量のストレージや専用のデータ解析アプリケーションなどの高度な技術に目が行きがちである。しかし、ファイルシステムこそが、データを扱うソリューションの根幹であり、3回の連載で述べたポイントを抑えて初めて、最新の技術が生きてくると筆者は確信している。今回の連載が、ビッグデータ活用のヒントとして役立てられることを祈りつつ、連載を終了する。
星野隆義
株式会社シマンテック
セールスエンジニアリング本部
ストレージ&クラスター製品担当 主幹技師
Copyright © ITmedia, Inc. All Rights Reserved.