RAIDの限界を超えるストレージ仮想化

RAIDの限界を超えるストレージ仮想化

　RAIDによって、単体のHDDドライブの制約や限界を超える柔軟な運用が可能になるが、これだけなら改めて「ストレージ仮想化」というほどのことではなく、それこそ20年ほどの歴史のある古い技術ということになる。

　現在、ストレージ仮想化という言葉でひとまとめにされている中には、さまざまな技術が混在しているのが実情だが、最も基本的な手法となるのはRAIDとよく似たストレージ容量の統合だ。ただし、ストレージ仮想化で扱われる統合技術は、RAIDとはレイヤーが異なる。

　RAIDで複数のHDDを統合する場合、当然ながら統合対象となるHDDはすべてRAIDコントローラーの配下に接続されている。ユーザーの目から見える具体的なシステム・イメージとしては、外部ストレージの筐体（きょうたい）内に収納されたHDD群が1つのRAIDシステムを構成している、と見える。逆に言えば、ストレージが複数台あれば、その数だけのRAIDシステムがあることになり、利用率の不均衡などの無駄が生じる可能性が高い。

　あるストレージには空き容量がふんだんに余っているが、別のストレージはもう空き容量がほとんどなくなっている、という状況になった場合を考えてみれば分かるとおり、RAIDによってHDD単体の物理的制約を回避できても、今度はRAIDシステムの筐体が強固な境界となり、ここで新たな物理的制約が出現するわけだ。ストレージ仮想化では、まずこの新たな物理的制約を回避することが目標となる。

　仮想化されたストレージでは、仮想化システムが配下のRAIDシステムの容量を束ねて仮想的なボリュームを創り出し、これに対するインターフェースをサーバー側に提供する。これにより、ストレージ筐体（＝RAIDシステム）の境界を越えてボリューム容量を拡張できる。現在のエンタープライズ・ストレージでは筐体当たりの最大容量はPBレベルまで達しており、この容量では記録不可能な巨大サイズのファイルを扱うことがあるとは思えないので、筐体をまたがったボリュームの統合は、サイズ的な制約を理由としているわけではない。ここではむしろ、論理的な統合によって運用の効率化や簡素化が実現できることが主たるメリットとなる。

仮想化によって得られるメリット

　ストレージ仮想化のメリットは、単純なボリュームサイズの拡大にはない。では、何がメリットとなるのだろうか。

　ストレージを利用する際の問題点として、容量の活用効率が低くなりがちということが挙げられる。さまざまな調査結果が公表されているが、おおむね50％以下というのが通説のようだ。つまり、ユーザー企業が購入したストレージの総容量の半分以上は空いているということになる。

　とはいえ、空きをなくすことができないのも事実である。稼働中のシステムに接続されているストレージの空き容量が不足すると、データの書き込みに失敗することになり、アプリケーションの停止やシステムダウンといった重大なトラブルに直結する深刻な事態である。こうしたトラブルを避けるためにも、ストレージにはある程度の余裕を持たせ、不足を起こさないようにあらかじめ準備しておくことが必須とされる。

　一方で、余裕はあくまでも余裕であり、通常は使われないことを考えると、余裕容量の確保は利用率低下に直結する。この結果が、半分以上の容量は使われていないまま眠っている、という調査結果につながってくるわけだ。現在の経済環境では、ITシステムにおいても無駄なコストの削減は重要なテーマとなっており、活用率の低いストレージをそのまま放置しておくことは許されなくなってきている。ストレージ仮想化は、この状況を改善するための有効な解決策となり得るものだ。

　システムにある程度の余裕を見込んだストレージ容量を割り当てていくと、どうしても容量がきれいに分割できず、ストレージ・システムごとの利用率がばらついていく。結果として、よく使われているストレージは容量不足に陥る一方、容量が余ったまま放置されるストレージも出てくる。

　ストレージ仮想化では、ストレージ・システムの筐体の境界をまたいだ容量の統合が可能になるため、容量を余らせているストレージ・システムの容量を別のストレージ・システムの容量とつなぎ合わせて活用する、といったことが可能になる。システム全体にわたる大規模なボリュームの整理統合を行うことなく、空き容量を活用することができるようになるため、ストレージ・システムを新たに追加購入しなくても当面の容量不足に対応可能となるわけだ。これは、IT投資の抑制にもつながるし、既存のITシステムの利用率を向上させることで投資効果を高めることにもなる。

　また、ストレージ・システムの境界をまたいだ統合は、物理的なデバイスの詳細をサーバー側から隠ぺいすることと同義でもある。サーバー側では、仮想化システムが提供する仮想ボリュームに対してアクセスしており、仮想ボリュームが実際にどの物理デバイスにマッピングされているかについては全く知らされない。

　この結果、仮想ボリュームの一部が異なるストレージ・システム上に存在していても問題ないわけだが、これをもっと積極的に使うと、マッピング先の動的な切り替えなども可能になる。仮想化システムが物理的なマッピングを切り替えた場合でも、サーバー側で稼働しているアプリケーションにはその変更は全く影響を与えないし、そもそも変更されたことに気づくこともないだろう。

　このため、容量の小さな旧式のストレージ・システムをリプレースした際に新しいストレージ・システムへのデータ移行が容易になるなど、運用管理面での負担も軽減される。

　ストレージ・システムを適切に運用するために、管理者は「どのデバイスがどのような用途に使われているか。どの程度の空き容量が残っているか」を把握しておかなくてはならず、運用管理の負担は増大する。ストレージ・システムの数が増えるとこの負担は等比級数的に増大していくことになり、各システムに確保された空き容量も増大してしまう。場合によっては、使いにくい半端な空き容量が各ストレージ・システムにバラバラと残ってしまい、総計としては広大な空き容量が存在するにも関わらず、有効な使い道が見つからないということも起こり得る。

　ストレージ仮想化では、こうした散在した空き容量を統合することができるため、管理負担の軽減と空き容量の有効活用が同時に実現するわけだ。