システムのストレージ環境は,個々のプロジェクトごとに構築する「プロジェクト型」から,個々のプロジェクト内では構築せずにサービスとして提供する「サービス型」への移行が検討されています。これは,システム構築における効率化の流れの一環で,サービスとして標準化していくことで,ストレージ環境の品質を向上させることも期待されています。

 プロジェクト型では,ある程度の大枠のポリシーはあるにしても,ストレージ環境の作り方や利用方法はそのプロジェクトに任されます。一方のサービス型の場合,サービス提供側のポリシーに従って変更管理されることになります。そのため,システム個々に見れば使いづらい場面も出てきます。

 例えば,

  • バックアップ・サーバーを統合した結果テープ・ドライブの使用時間帯が限られ,「いつでもテープにバックアップを取る」といったことができなくなった
  • 論理ボリュームのサイズを10Gバイト単位に統一した結果,クラスタのクォーラム・ボリュームにも10Gバイトを割り当てなければならず無駄が生じた
  • プロジェクトごとにストレージ環境を構築していた場合,既存サーバーへの増設は必要になったらその場で実施していたが,サービス型では申請書を提出してから実際に作業されるまでリードタイムが必要となった

といったことです。

 サービス型に移行することで品質向上を図ることは可能ですが,個々に見れば上記のような問題があり,ストレージ・アーキテクトは,できるだけ問題が起こらないようにサービス内容を検討しなければなりません。

 そこで以下では,ストレージ・サービスの内容をどのような考えに基づいて決めればいいのかを解説します。ストレージ・サービスを利用する側の品質としては,「キャパシティ(容量/性能)」「可用性」「作業を申請してから作業までのリードタイム」がありますので,この順に説明します。

キャパシティの検討

 ストレージ・サービスのキャパシティで代表的なものは,各サーバーに対して割り当てる論理ボリュームのサイズになります。論理ボリュームのサイズが小さいほど割り当てる自由度は上がりますが,その分物理ディスク内でのフラグメントが発生し,ディスクの競合が発生しやすくなります。

 論理ボリュームのサイズを決める際には,「物理ディスクを無駄なく使うにはどのくらいのサイズが適切か」という面と,「物理ディスクの競合を抑えるにはどのくらいのサイズが適切か」という二つの面から判断します。また,論理ボリュームは,グループを作成したり,ストレージ側でメタボリュームを作成したりできますので,そうした点も併せて考えます。

 理想は,同一筐体のボリューム・サイズは1種類とすることです。例えば,一つの筐体に6Gバイトと8Gバイトの2種類のボリュームを作ったとします。8Gバイトのボリュームがいっぱいになり,6Gバイトを使う状況に至ったとき,サーバーから見て同じ筐体なのにサイズの違うボリュームが混在することになり,管理上混乱を招きかねません。複数種類のサイズが必要なサーバーがある場合,筐体や物理ディスクを分けることも一つの選択です。