ストレージは「仮想化」と親和性が高い。サーバー機などが個々のコンピュータとして扱われてきたのとは異なり，ストレージはそもそもがコンピュータから「論理的なビュー」として扱われてきた。現実の製品実装において，ストレージとはディスク・ドライブの集合体であり，ユーザーやOS/アプリケーションから見たストレージ領域（ボリューム容量）は，「使っているディスク・ドライブは何か？」「そのディスク・ドライブの中の，どの記憶領域を使っているのか？」といった物理的な構成とは独立している。
このようにストレージは，歴史的に見て古くから「論理ビュー」と「物理実装」を分離する仮想化の考え方を採用してきた製品分野である。物理実装はブラックボックスであり，論理ビュー，すなわちボリュームだけを見ていれば，それでよかった。エンタープライズ向けストレージ技術としてよく知られるRAID（Redundant Arrays of Inexpensive Disks）も，性能や可用性の向上を目的に，複数のディスク・ドライブを論理的に1個のボリュームとして使えるようにしたものだ。
こうしたストレージの仮想化をさらに一歩進めるアイデア/技術として注目され，最新トレンドとなっているのが，ストレージ・ベンダー各社がこぞって実装を進める「シン・プロビジョニング」（Thin Provisioning）である。この仮想化機能を使うと，ストレージを構成する物理実装であるディスク・ドライブの数を，大幅に減らせる。ディスク・ドライブの数が減るのに伴い，消費電力や設置コストも削減できる。
“容量”を仮想化して稼働率を向上
シン・プロビジョニングとは，ボリュームの“容量”を仮想化して，キャパシティ・プランニング（容量設計）を不要とする技術である（図1）。例えば，実際には全体で容量1Tバイト分のディスク・ドライブしか用意していなくても，それとは無関係に，10Tバイトのボリュームを設定して運用することができるようになる。OS/アプリケーションからも，当然ながら10Tバイトのボリュームとして認識される。これは，シン・プロビジョニングが登場する以前には，無かった考え方である。
まずはボリュームについて，基本的なことを押さえておこう。ボリュームとは，いわば仮想化された論理ビューである。ボリュームにアクセスするOSやアプリケーションは，そのボリュームに，どのようなディスクが割り当てられているのかを知る必要はない。一方で，物理ディスクは，この論理ビューに対して実際のデータ記憶領域を提供するリソース（資源）となる。物理ディスクの集合体がリソース・プールとなり，このリソース・プールから個々のボリュームに，「ディスク・ドライブ」という単位よりも，さらに細かい単位で，データ記憶領域が割り当てられる。
このように，論理的な存在である「ボリューム」と，「ディスク」という物理実装は，互いに独立している。1台のディスクに複数のボリュームを設定することもできるし，複数のディスクを1つのボリュームとして使うこともできる。複数のディスクを複数のボリュームとして使う場合において，どのディスクのどの記憶領域が，どのボリュームに割り当てられているのか，という細かい物理実装を，全く意識する必要がない。ただ単に，ボリュームという単位でのみ，管理していればよいのである。
ただし，RAIDという従来の仮想化手法において，物理リソースの構成とボリュームは独立していたものの，「ボリューム容量」に関しては，完全に物理構成に依存していた。つまり，RAIDの種類と，ボリュームを構成する物理リソースの容量に応じて定まっていた。例えば，1Tバイトのディスクを2台のディスクでストライピングしたセットをさらにミラーリングしたRAID1+0構成では，使っているディスク4台の物理容量の合計が4Tバイトに対して，ボリューム容量は最大2Tバイトとなる。この物理容量を超えたサイズのボリュームを定義することはできず，容量10Tバイトといった仮想的なボリュームが得られるわけではなかったのである。
