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

著者:Stephen Foskett
Storage Magazine 2011年4号より


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

 

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

 

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

 

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

 

 

シン・プロビジョニング機能をもつストレージを評価する際、この課題に対する幅広いレンジでの取り組み方を反映させた、以下の質問を検討してもらいたい。全ての状況で、これらの機能が全て必要、ということではない事に留意されたい。

 

シン・プロビジョニングは購入価格に含まれているのか、追加費用がかかるオプションなのか?
そのストレージはゼロ・ページ・リクレーム(zero page reclaim)機能をサポートしているか?リクラメーション処理が起動する頻度は?
ページサイズ、プロビジョニング増分はどのくらいあるか?
シン・プロビジョニングが、スナップショットやミラーリング、レプリケーションと連携できるか?シック・トゥー・シン・レプリケーションはサポートされているか?
ストレージに空き領域がなくなったら、どういう動作をするのか?アラート処理、空き容量確保、書き込み停止は行われるのか?
ストレージはWRITE_SAMEをサポートしているか?SCSI UNMAP、ATA TRIMはどうか?
VMware VStorage APIs for Array Integration (VAAI)の「ブロック・ゼロイング」用プラグインは用意されているのか?基本的なT10プラグインなのか、そのストレージ用の特別なプラグインか?

 

 

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

 

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

 

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

 

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

 

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

 

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

 

 

「薄さ」(シン)の敵

 

「このアプリケーションには500GBかそれ以上必要になるかも知れないわ」とDBA(データベース管理者)は考える。余裕を見て、彼女はストレージ管理者に1TBを依頼する。ストレージ管理者も同じように考える。あとでDBAにガタガタ文句を言われないように、2TBを割り当てる。これは、ストレージ容量の悲惨な使用状況を作る原因として語られる、おなじみのストーリーだが、本当にこれで良いのだろうか?

 

ほとんどの企業のストレージ環境において、ディスク使用率の低さには多くの原因があると思われる。

 

絶対使わない位の容量を買いすぎてしまうきっかけを作っている年間予算あるいはプロジェクトごとの購入サイクル。
非効率的なリソース・モニタリングや容量要件が曖昧になるようなキャパシティ・プランニング処理。
容量を必要としているシステムが、容量のあるところに到達できないように作られている、不完全なストレージ・ネットワーク。
割り当てられているにもかかわらず、決して使われることのないストレージ容量を生み出す、バラバラなアロケーション処理
ストレージ要求の変化に応じて簡単に伸縮できない、融通の利かないOSやファイル/システム

 

 

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

 

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

 

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

 

ストレージ・アレイが、受け取り、保存したデータを隅々まで調べ、容量のリクレームを行うチャンスがあるかどうかを判断する。
ある容量がもう使われなくなった時に、ストレージ・アレイにシグナルを送るように、 サーバー側を改良する。

 

最初のオプションは、実現は難しいものの非常に効果的だ。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が、ファイル・システムにおける、ストレージのアロケートおよびリリース方法を修正する可能性もある。

 

 

シン・プロビジョニングとTCO

 

企業のストレージ・ソリューションのTCOを、ストレージ・ベンダーが自分の都合の良いように作った不完全なモデルや基準を使って比較するのは、何かと問題がある。シン・プロビジョニングのような、コストを節約し、効率を改善する技術に投資する前に、ベンダーの前提や保証を検証するために、自社のモデルを作っておくのが賢明だろう。

 

TCOを詳細に見れば、そこに含まれているのは、単にハードウェアとソフトウェアの費用だけではない事がわかる。運用と保守、データセンター・コスト、機器の購入によって発生する諸費用、すなわち、移行や既存ストレージの廃棄のコスト、なども考えなければならない。非効率的なアロケーションがもたらす様々な影響について考えてみるのも良いことだ。一つのディスクに1GBずつ未使用領域を残すことは、ストレージコストを倍にする。エンド・ツー・エンドの平均ストレージ利用率が25%をきると、もたらす影響はますます大きくなる可能性がある。

 

このコスト・モデルは往々にして、ハードディスク(あるいはSSD)のストレージ容量がTCOに占める割合は小さい、多くの場合、全体の15%未満、という驚くべき事実を明らかにしてくれることがある。しかし、だからといって、容量の利用効率の改善が無駄な努力だというわけではない。ストレージ容量の非効率的な利用による悪影響を無くすことは、ディスク上のビットを単に圧縮するよりはるかにTCOに対する影響度は大きい。

 

シン・プロビジョニングが運用に与える影響とその仕組みがストレージの密度に与える影響を考慮えてほしい。シン・プロビジョニングは、容量のアロケートが従来のような制約無しに行えるため、管理業務を減らすことができるかもしれないが、管理業務を減らすと、今度は、ストレージ・アレイがオーバーアロケートされて容量不足になり、アプリケーションが停止する、という悪夢のシナリオに至る可能性がでてくる。最良のシン・プロビジョニングはまた、高度に仮想化され、柔軟で、ハードウェアと密接に連携しており、運用の効率化と高度な使用効率を可能にしている。

 

 

もっともっと「薄く」(シン)に

 

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

 

 

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

 

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

 

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