VMware vSphere 4のストレージ機構（2）：VMware vSphere 4徹底解剖（4）（1/4 ページ）

ストレージ容量拡張などの新機能

　前回はvSphere 4 のストレージ機構の前編ということで、デバイス名やパス名の命名規則、PSAと呼ばれるマルチパス機構、iSCSI ストレージ利用時のポート・バインディング機能について説明した。今回は引き続き、vSphere 4で強化されたさまざまなストレージ機能を紹介する。

シン・プロビジョニング

　一般的なITインフラ環境においては、マシンに接続されているディスクが常にデータで一杯という状況は考えにくい。起動ディスク、データディスクともに、何割かは空き領域がある状況で運用していることだろう。

図1　多くのシステムはある程度ディスクの空き領域を残したまま運用されている

　仮想マシン環境においても同様で、例えばOS用領域として1つの仮想マシン当たり20GBの仮想ディスクを構成して運用している環境であっても、実際に消費している容量は約8GB程度で、残り12GBは未使用という状況も珍しくないはずだ。仮想マシンの台数が少ないうちはそれほど大きな問題にはならないが、例えば同様の構成の仮想マシンが100台存在するような環境では、約1.2TBものストレージ資源が「割り当て済みではあるものの、実際にはデータは格納されていない領域」という形で消費されてしまうことになる。

図2　マシンの数が増えると、未使用のまま使用されないストレージ資源が増える

　これを解決するため、vSphere 4 では「シン・プロビジョニング」と呼ばれる仮想ディスクの構成方法がサポートされるようになった。シン・プロビジョニングを利用して仮想ディスクを作成すると、その時点で指定したサイズの仮想ディスクが作成されるものの、「領域の割り当て処理」はその時点では行わないという動作をする。しかし仮想マシン側からの視点では、定義したサイズのディスクがあたかもそこにあるかのように認識される。実際の領域の割り当て処理は、該当ブロックへの最初の書き込みが仮想マシンから発生したときに、都度行なわれる。このため、「本当に使用している領域にのみストレージ資源を割り当てる」ことが可能になる。シン・プロビジョニングで用いる形式の仮想ディスクのことをシン・ディスク（Thin Disk）と呼ぶ。

　シン・プロビジョニングを行うと、実際にはデータが格納されていない領域、つまり未割り当ての領域は通常のディスク資源として開放されている状況になるため、実際に存在している以上の容量のストレージ資源をプロビジョニングすることが可能になる。例えば、20GBの仮想ディスクで構成した仮想マシンを5個作成する場合、従来方式のディスク形式（Thick Disk）で構成すると、単純に100GB以上のデータストアが必要になるが、シン・プロビジョニングを用いると100GBよりも小さなサイズのデータストア、例えば40GBのデータストア上に作成してしまうことが可能になる。もちろん実際に格納できるデータ容量はデータストアのサイズを超えることはできないが、設計次第ではこのようにオーバーアロケーションを伴う運用も可能になるということである。

　それでは実際にシン・プロビジョニングを利用してみよう。仮想マシンの作成、仮想ディスクの追加、テンプレートからの展開など、仮想ディスクの新規作成を伴う操作の際に、シン・プロビジョニングの有効・無効を指定することができる。

図3　シン・プロビジョニングを有効化してディスクを作成

　このチェックボックスを有効化して仮想ディスクを作成すると、シン・ディスクとしてその仮想ディスクは作成される。シン・ディスクであっても仮想マシン側からの視点、つまりゲストOSにとっては通常のディスクとなんら変わりはなく、あたかもそこに定義したサイズのディスクがあるかのように認識される。

図4　シン・プロビジョニングされた仮想ディスクであっても、ゲストOSからは定義したサイズのディスクがそこにあるかのように認識される

　それではこの仮想マシンを、40GBのデータストア上に5個作成してみよう。以下は作成後のデータストアの情報である。

図5　シン・プロビジョニングを用いて、40GBのデータストア上に20GBの仮想マシンを5個作成

　使用済み領域は実データが格納されている約11GBで、未割り当ての約28GBは空き領域として計上されていることが分かる。

　次にインベントリビューをストレージに切り替えて、同じデータストアのサマリ情報を確認してみる。今回の例では約100GBがプロビジョニングした領域としてレポートされている。

図6　実際のデータストアの容量以上の領域がプロビジョニングされている

　このように、シン・プロビジョニング機能を利用することで、実際のデータストアの容量を超えるサイズの仮想ディスクをプロビジョニングすることも可能となる。

　ところで、このようなオーバーアロケーションを伴ったシステムを運用する場合は、空き容量の監視、オーバーアロケーション率の監視などについても適切に行う必要が出てくる。このためvCenter Server 4.0ではデータストアに対する監視機構・アラーム機構も強化され、データストアのオーバーアロケーション率に対してしきい値を設定し、それを超えた場合に警告やアラートを発行することができるようになった。

図7　オーバーアロケーションに対するアラームの設定例。この例では100％を超えたら警告を、200％を超えたらアラートを発行するよう設定している

　それでは次に、実際に作成されたファイルがファイルシステム上ではどのように構築されているのかを見てみよう。まずは従来方式の仮想ディスクの例である。サービスコンソール上のコマンドで20GBの仮想ディスクの情報を確認してみる。

≪# ls -l≫
total 21250304
-rw------- 1 root root   268435456 Oct 30 13:57 thick w2k3r2 01-b12e09b6.vswp
-rw------- 1 root root 21474836480 Oct 30 17:54 thick w2k3r2 01-flat.vmdk
-rw------- 1 root root        8684 Oct 30 13:59 thick w2k3r2 01.nvram
-rw------- 1 root root         503 Oct 30 13:57 thick w2k3r2 01.vmdk
-rw------- 1 root root           0 Oct 30 13:57 thick w2k3r2 01.vmsd
-rwxr-xr-x 1 root root        3155 Oct 30 14:02 thick w2k3r2 01.vmx
-rw------- 1 root root         270 Oct 30 14:02 thick w2k3r2 01.vmxf
-rw-r--r-- 1 root root      146163 Oct 30 13:56 vmware-1.log
-rw-r--r-- 1 root root      111469 Oct 30 14:02 vmware.log
≪# stat "thick w2k3r2 01-flat.vmdk"≫
File: `thick w2k3r2 01-flat.vmdk'
Size: 21474836480     Blocks: 41943040   IO Block: 4096   regular file
Device: 12h/18d Inode: 480         Links: 1
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-10-30 17:53:41.000000000 +0900
Modify: 2009-10-30 17:54:27.000000000 +0900
Change: 2009-10-30 13:59:06.000000000 +0900
≪#≫

　statコマンドで出力されるブロック数に512をかけた値が実際にこのファイルに割り当てられている領域のサイズとなる。この例では41943040×512=20GBが実際にこのファイルに割り当てられているということが分かる。

　続いてシン・プロビジョニングされた仮想ディスクに対しても同様に確認してみる。

≪# ls -l≫
total 2277632
-rw------- 1 root root 268435456 Oct 30 13:37 thin w2k3r2 05-0ce6351d.vswp
-rw------- 1 root root 21474836480 Oct 30 17:59 thin w2k3r2 05-flat.vmdk
-rw------- 1 root root 8684 Oct 30 13:39 thin w2k3r2 05.nvram
-rw------- 1 root root 528 Oct 30 13:37 thin w2k3r2 05.vmdk
-rw------- 1 root root 0 Oct 30 13:37 thin w2k3r2 05.vmsd
-rwxr-xr-x 1 root root 3149 Oct 30 13:40 thin w2k3r2 05.vmx
-rw------- 1 root root 269 Oct 30 13:40 thin w2k3r2 05.vmxf
-rw-r--r-- 1 root root 146163 Oct 30 13:38 vmware-1.log
-rw-r--r-- 1 root root 111858 Oct 30 13:40 vmware.log
≪# stat "thin w2k3r2 05-flat.vmdk"≫
File: `thin w2k3r2 05-flat.vmdk'
Size: 21474836480 Blocks: 3997696 IO Block: 4096 regular file
Device: 12h/18d Inode: 467 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2009-10-30 15:34:27.000000000 +0900
Modify: 2009-10-30 18:00:11.000000000 +0900
Change: 2009-10-30 13:39:17.000000000 +0900
≪#≫

　lsコマンドで出力されるファイルサイズは20GBであるが、statコマンドで確認できる割り当て済み領域は3997696×512で約2GBであることが分かる。このように、vSphere 4におけるシン・プロビジョニングでは、実際のファイルサイズは事前にフルサイズで作成し、内部的なブロックのアロケーション処理のみをオン・デマンドで行うという実装になっていることが分かる。

　シン・プロビジョニング機能は、VMware WorkstationなどのHosted型仮想化製品では以前より提供されていた機能である。一方でVMware ESXは共有ストレージの利用を前提とした製品であり、オン・デマンドなブロックアロケーション処理は都度ディスクに対するロックの獲得・解放を伴うことからシン・プロビジョニング機能のサポートを見合わせていた。しかしVMFSのロック処理、ディスクリザベーションのハンドリング機構はバージョンを重ねるごとに最適化され、スケーラビリティも向上した。このためvSphere 4により正式サポートという扱いとなった。

　なおNFSデータストアでは、ブロックのアロケーション処理はストレージ装置側の実装に委ねられているため、vSphere 4側からはコントロールすることはできない。多くのNAS装置はシン・プロビジョニング機構を保有しており、同様にスペースの効率的な利用を可能としている。

図8　NFSデータストアでは、シン・プロビジョニングの有効・無効はNFSサーバ側の実装に依存するため、vSphere Clientの該当設定箇所はグレーアウトされる