シン・プロビジョニング徹底解説

シン・プロビジョニングは、ディスク容量の効率的に使用する上で大いに役立つ技術だが、自社の環境でシン・プロビジョニングがどのように動くのか、その内部の仕組みを知っておく必要がある。

誰だって、使っていないものにお金を払いたくないものだが、企業のデータ・ストレージ・マネージャーたちはいつもそれをしている。ディスク・ストレージの購入とその提供形態がもつどうしようもない融通の利かなさが、驚くほど低レベルの容量利用の原因となっている。ストレージの効率向上は、この業界が一貫して取り組んできたテーマであり、ここ10年の間、ほとんどのストレージの専門家にとっての目標でもあった。その中で、シン・プロビジョニング技術だけが、現実世界に具体的なメリットをもたらしたのだ。

シン・プロビジョニングの概念は容易に理解できるものかもしれないが、効果的に使いこなすには複雑な技術である。ストレージ・アレイがデータを含む容量だけをアロケートすると、残りの（不要な）「空き領域（ホワイト・スペース）」付きでアロケートしたときよりも、ずっと多くのデータを保存できる。しかし、ストレージ・アレイはデータを保存したり使ったりするアプリケーションから数段階隔絶したところにあり、どのデータが使用中でどのデータが使われていないかをストレージに知らせる、標準化されたコミュニケーション機構も存在しない。

ストレージ・ベンダーはこの問題を解決するために様々なアプローチを行って来た。しかし、もっとも効果的な仕組みを、既存のストレージに適用するのは困難だ。これが、たいていの場合、小さめのベンダーから出される次世代ストレージ・システムには、これまでのところ効果的なシン・プロビジョニング技術が入っており、業界の保守的大手ベンダーは、この機能をやっと付け加えただけ、という状況を生み出している。

シン・アロケーション・オン・ライト

従来のストレージ・プロビジョニングは、内蔵ディスクとサーバーで使用されている容量の間で、1対1のマップを持ち、それを更新している。ブロック・ストレージの世界では、サーバーは、固定サイズのドライブやボリューム、LUN、その容量分の全てのビットが、ストレージ・アレイ内に納まったハードディスクに存在していると「見なす」。例えば、Windowsサーバーの100GBのC:ドライブは、ストレージ・アレイ内の数台のディスク・ドライブ上の、RAIDによって保護され確保された100GB の容量にアクセスする。

シン・プロビジョニングの最も単純な仕組みは、このやり方を直線的に進化させたものだ。ストレージの容量は、同じサイズのページの「プール」に貯め込まれる。プールは最初の作成時ではなく、要求があったときにサーバーに初めてアロケートされる。前述の例でいうと、100GBのC:ドライブには10GB のファイルしか入って無いかもしれない。その場合、この領域だけが、10GB の容量としてストレージ・アレイにマッピングされることになる。次に新しいファイルが書き込まれたとき、ストレージ・アレイはプールの空き領域から追加の容量を持ってきて、それをサーバーに割り当てる。

この「アロケート・オン・ライト」型のシン・プロビジョニングは今日、かなり広範に使われている。ほとんどのミッドレンジおよびエンタープライズのストレージ・アレイやそれより小さなデバイスが、この機能を標準、または有償オプションとして持っている。しかし、この方法にはいくつかの問題がある。

まず、ひとつ明らかな落とし穴は、このシステムが「薄い」（シン）なのは、一時の間だけ、ということだ。ほとんどのファイル・システムは、断片化（フラグメンテーション）を避けるために、新規ファイルのために「クリア」な領域を使用する。削除された内容は、ファイル・システム上では単に未使用のマークがつけられるだけであり、ゼロ・アウト（完全消去）またはストレージ・アレイ上で解放される訳ではない。その結果、これらのシステムでは、たいして追加データが書かれていないにもかかわらず、アロケーション可能領域を全て使い果たしてしまう、という事が起こってしまう。これはシステムの効率を落とすだけでなく、ストレージ・アレイはアロケーションをコミットできなくなり、書き込み処理が停止してしまう、という「オーバー・コミット」問題の危険さえ孕んでいる。

とはいえ、このことをもって、シン・リクラメーション機能がないシン・プロビジョニングは役に立たない、と言っている訳ではなく（下欄「シンの敵」参照）、シン・プロビジョニング技術による長期的なメリットが薄れる、ということを言っているのだ。さらに、ほとんどのストレージ・マネージャーが、シン・ストレージというものは、シンのままでいるだろうと思っている以上、未使用領域をリクレームすることは、喫緊の要件となってくる。

シン・リクラメーションの難問

シン・プロビジョニング技術で難しいのは、未使用の領域をアロケートすることよりも、それをリクレームする部分だ。もはや使っていない容量をフリー・プールに戻すところは、シン・プロビジョニングの実装における重要な差別化要因になっており、業界の中でもその手法はまだ定まっていない。

シン・リクラメーションが抱える難問の根本原因は、アプリケーションとデータストレージ・システム間のコミュニケーションの欠如にある。先に述べたように、ファイル・システムは一般的にシン・プロビジョニングを意識しておらず、ある容量が不要になったとき、それをレポートする仕組みが存在していないのだ。効果的なシン・プロビジョニングの鍵は、いかに未使用の容量をリクレームするチャンスを見つけられるか、というところにかかっている。これを実現する方法は基本的に二つに分けられる。

最初のオプションは、実現は難しいものの非常に効果的だ。OSベンダーが、ファイル・システムにシン・プロビジョニングの機能を追加するのに、あまり熱心には見えないからだ。Data Robotics社のDroboストレージ・システムは、特定のパーティションやファイル・システムを隅々まで調べ、どのブロックが使われていないかを判定し、将来の使用に備えてリクレームを行う。しかし、この方法は、OS、アプリケーション、ボリューム管理ソフトの膨大な数を考えると、実践していくのは極めて難しい。

そのため、企業におけるシン・プロビジョニングの主要なトピックは、サーバーとストレージ・システム間のコミュニケーション機構を改善していく、という後者のアプローチに関するものとなる。

ゼロ・ページ・リクレーム

シン・プロビジョニング技術で、おそらく最もよく知られているのが、ゼロ・ページ・リクレームだろう。ゼロ・ページ・リクレームの動作は次のようなものだ。ストレージ・アレイはストレージの容量をいくつかの「ページ」に分割し、データを保存する際、必要に応じてそれらのページをアロケートする。あるページがゼロしか含んでいない場合、そのページはフリーの容量プールにリクレームされる。後々の読み込み要求には、単純にゼロが返され、書き込み要求があった場合は、他のページがアロケートされる。もちろん、実際の技術はこれほど簡単なものではない。

例えば、全てをゼロにする書き込みも問題になることがある。0を書き込むのには1を書くのと同じ位、CPUとI/Oのパワーを使う。サーバーとストレージ・システムにとっては、この処理における効率の悪さは、ストレージ容量の問題と同じくらい、悩ましい問題なのだ。SCSIストレージ・インターフェースに関するT10技術委員会は、このI/Oにおける「重複排除」を可能にするSCSIコマンド（WRITE_SAME）を規定した。このコマンドにたいしては、ゼロになったものは保存する必要なし、とストレージ・アレイに通知する所謂「ディスカード・ビット（廃棄ビット）」の機能拡張も行われている。

ほとんどのストレージ・アレイは未だに、書き込みの時に、全てのゼロ・ページを検知する機能を持っていない。その替わり、ストレージ・アレイはディスクにゼロを書き込み、後で「スクラブ（ごしごし洗う）」処理によって、これらゼロ・ページを検知して廃棄する。したがって、スクラブ処理が行われ、廃棄されるまでは、当該領域は使用中として見えている。この処理は、自動化スケジュールで走らせる事もできるし、管理者によって手動で起動することもできる。また、いくつかのストレージ・アレイでは、ミラーかマイグレーション中にしかゼロ・ページを検知できないため、容量効率はさらに落ちる。

サーバーとストレージに橋を架ける

ストレージ・アレイが完全なゼロ・ページ・リクレーム機能を備えていたとしても、ゼロが実際に書かれてはじめて機能する。サーバーは容量を必要としないところにゼロを書き込むように指示されなければならないが、これは通常は、デフォルトの動きではない。ほとんどのOSでは、この動きをさせるために、コマンドを必要とする。Windowsの「sdelete –c」のようなものや、NetAppのSnapDriveの命令のようなものだが、これらはたまに実行されるに過ぎない。

VMware ESXのボリュームを含め、いくつかのアプリケーションは、本当にゼロ・アウトして、新しいスペースを確保する。ESXの「eagerzeroedthick」コマンドはゼロで埋めたスペースを作成する。VMotionを初め、いくつかの製品で互換性問題が残っているものの、ESXはますます、シン・プロビジョニングを意識した製品作りをしている。ESX 4.1で追加されたvStorage APIs for Array Integration (VAAI)には、特定のストレージ・システムに対応した「ブロック・ゼロイング」を標準でサポートしている。ESXは、ストレージ・アレイに対してVMFSの容量が不要になったというシグナルを送るために、特定用途向けに作られたプラグインか、出来合いのT10 WRITE_SAMEを使っている。

シマンテック社も、シン・プロビジョニング対応に関して、先頭グループを走っているベンダーだ。Veritas Storage Foundation製品に入っているVeritas Thin Reclamation APIは、ほとんどの主要なストレージ・アレイに対応している。このAPIは、不要な容量を解放するために、様々なコミュニケーションの仕組みを使い、VxFSファイル・システムおよびボリューム・マネージャーと完全に統合されている。Storage Foundationには、データが入っているブロックのみを転送する、シン・ストレージ・アレイをサポートするSmartMoveというマイグレーションの製品も入っている。

他のシステムにおいては、シン・プロビジョニングに対する意識はまだ低い。もうひとつの標準的コマンドATA TRIMは半導体ストレージをサポートするために作られたものだが、SCSIの親類のコマンドUNMAP同様、シン・リクラメーションのシグナルを送ることもできる。MicrosoftとLinuxは、最近TRIMをサポートするようになったので、将来、シン・プロビジョニングのサポートも始めるかも知れない。MicrosoftとLinuxが、ファイル・システムにおける、ストレージのアロケートおよびリリース方法を修正する可能性もある。

もっともっと「薄く」（シン）に

シン・プロビジョニングには難しい課題もあるが、メリットはすこぶる多い。シン・プロビジョニングは、問題の核心が技術に関連していない時でも、実世界のストレージ利用を改善できる数少ない技術である。実は、私を含め多くのユーザーは、ストレージ予測やアロケーション処理のお粗末さのせいで、シン・プロビジョニングに対して否定的なイメージを抱いていた。しかし、技術が改善され、リクラメーションがさらに自動化されるようになるにつれて、この技術は、企業のストレージ・システムにとって必須のコンポーネントとなっていくだろう。

著者略歴：Stephen Foskettは独立のコンサルタントで、エンタープライズ・ストレージとクラウド・コンピューティングを専門とした著述活動を行っている。バックアップ＆リカバリソフトウェア、レプリケーション・ソリューションを専門とするシニア・アナリスト。

All Rights Reserved, Copyright 2000 - 2011, TechTarget | Read our Privacy Statement

*この翻訳記事の翻訳著作権はJDSFが所有しています。
このページに掲載されている記事・写真・図表などの無断転載を禁じます。