ストレージ仮想化 2008年度版（後編）

　仮想化の目的とその本質を踏まえ，ストレージに対する代表的な要件がストレージ仮想化とどう関連するかを見ていこう。仮想化に関する代表的な要件として以下を取り上げる。

（1）ストレージ領域の有効活用
（2）最小ダウンタイムでの領域拡張
（3）複数ストレージの利用
（4）実容量以上の領域の割り当て

（1）ストレージ領域の有効活用

　ストレージ領域の有効活用は，SAN環境でストレージ統合することにより得られる効果である。これだけが目的であるなら，仮想化は不要だ。

（2）最小ダウンタイムでの領域拡張

　最近のデータ容量の増加ペースは急激で，ストレージの追加・増設に追われている管理者諸氏も少なからずいるであろう。

　まず，単純な領域拡張はサーバーが使用しているストレージに空き容量があれば，最近のOSであれば簡単に拡張できるのはご存じであろう。Windows Server であればダイナミック・ディスク機能，各種UNIX/LinuxであればLVMやその他ボリューム管理機能を使用することで，オンラインのままファイル・システムを拡張することは容易である。追加するストレージ領域が元の領域とは異なるストレージにある場合でも，サーバーOSから見た場合は単なるLUNであるから操作に違いはない。

　また仮想化のメリットとして，仮想化装置によるデータ・コピーとそれによるストレージ領域の移動をあげることもあるが，ボリューム管理機能で実現できることである（図）。

図●ダイナミック・ディスク機能によるデータ・ボリュームの移動

　とはいえこの方式も万全ではない。いくつかの条件を満たす場合に実行できる方法である。その条件とは，

である。逆に言うと，上記が満たせない場合が仮想化の出番であるといえる。つまり，

というケースでは，ストレージの仮想化を導入すべきである。

（3）複数ストレージの利用

　複数ストレージの領域を「ストレージ・プール」としてあらかじめ準備しておき，必要に応じて利用する，というのは仮想化のメリットとしてよく言われることだ。ここで考慮すべきは，技術的に可能というだけでなく，運用できるか，とくに変更管理や障害対応のプロセスが対応できるか，ということである。

　例えば，あるストレージでドライブ障害が発生したとする。ミラーであれば一方のディスクだけで稼働し，RAID5やRAID6ではパリティ喪失の状態である。この状態でもデータ・ロスはないがミラー再同期やパリティ再計算をする際に処理性能の劣化があるので，該当RAIDセットを使用するアプリケーション管理者に一報するという運用プロセスを取る。

　また，ストレージのFCインタフェースに障害があったりメンテナンスのために停止したりすることもある。この場合もデュアルSANファブリック構成を取っていれば，もう一方のSANファブリック経由でのアクセスは継続できるので，サーバーからストレージへのアクセスが停止することはない。しかしこのとき，同時にサーバー側でFC HBAのメンテナンスなどをしてしまうと，場合によっては両方のFCパスを切断してしまうことになる。ストレージ側FCインタフェースで障害が起きたりメンテナンスをしたりする場合は，そのストレージを使用する全アプリケーション管理者に一報する必要がある。

　このようにストレージの障害あるいはメンテナンスの際に関係するアプリケーション管理者への連絡をする必要がでてくるが，サーバーが複数のストレージを使用している場合には，連絡すべき対象が増えることになり運用負荷の増大を招いてしまう。

　同程度の可用性を持つストレージを2台使用しているサーバーは，1台のストレージを使用するサーバーに比べストレージ障害の影響を受ける確率は2倍になる。一般的に高機能・高性能なハイエンド・ストレージの可用性は高く，小機能・低速で安価なストレージの可用性はハイエンド・ストレージと比較して低いことが多い。仮にハイエンド・ストレージと安価なストレージの故障率が5倍違うとすると，単純に両方を使用するサーバーはハイエンド・ストレージだけを使う場合に比べて6倍，安価なストレージだけを使う場合と比べても1.2倍影響を受けることになる。

　ストレージの仮想化を利用するに当たっては，効率的な運用が可能なのかどうかを考える必要がある。

（4）実容量以上の領域の割り当て

　ストレージの実容量以上の領域があるようにサーバーに見せておき，必要に応じて実領域を追加する，というのはストレージ仮想化がなければ実現できない機能である。このような要望がある場合には，ストレージ仮想化を導入すべきである。

　こうしたケースでの問題は，（3）複数ストレージの利用と同様に，実際に運用していけるか，ということであろう。サーバーに実容量以上を割り当てるというのは，サーバーごとに容量管理をするのではなく，ストレージ・システム全体で“総量管理”をするということである。アプリケーションが実容量以上にデータ書き込みを行った場合にプール領域を自動的にアサインし，ボリューム拡張できる機能が必須だ。これはストレージ管理者からすると，ある日突然プール領域が使用され減っているのを発見することになる，ということである。これに備えなければならない。まとめると，

といったことをクリアしておく必要がある。

　実用量以上の領域を割り当てる機能を採用すると，空き容量の管理はサーバー／アプリケーション担当者からストレージ担当者に移る。サーバー／アプリケーション担当者からは実容量以上の“仮想サイズ”と，実際の使用量しかわからなくなるからだ。仮想サイズは概して大きく設定されるため，ディスク使用率は低くなる。まだまだディスクがあると思ってDBをダンプしたら実容量以上になってプールが枯渇した，ということが起きないようにしなければいけない。それはストレージ管理者側の責任ということになる。

　上記を満たすことが可能な場合，この機能は運用効率化に役立つであろう。