ストレージ・リソース管理（SRM）ソフトは使い物になるか？！

有用なチャージバック・モデル開発など、課題が山積

（2007年01月31日）

ストレージ・リソース管理（SRM）ソフトウェアは、ユーザーに多大なメリットをもたらす。例えば、どのアプリケーションがどのストレージを使っているのかといったことを管理者側でチェックすることを可能にするし、アプリケーションとバックエンド・システムとのマッピングを行えるようになれば、ITマネジャーの側でより優れた「費用と価値の（cost-to-value）マトリクス」を作成したり、正確で有効性の高いチャージバック・モデルを開発したりすることもできる。だが、そうしたメリットを享受できるSRMソフトは、実際にはまだほとんど提供されていないのである。

ブルース・ホード
Computerworld オンライン米国版

　先ごろ開催されたコンファレンス「ストレージ・ネットワーキング・ワールド」では参加者へのアンケート調査が実施されたが、その中で、現在、ストレージ・ネットワークの分野で何が重要課題となっているかについての質問がなされた。

　その結果によると、回答者の27％（最多）が「ストレージ・リソース管理（SRM）」を重要課題として挙げ、さらに21％（3番目に多かった）が「他の管理ツールとの統合」を挙げたという。つまり、インフラストラクチャを管理するための機能を求める声が大勢を占めたのである。

　しかしながら、残念なことに、こうしたビジョンはまだ実現されているわけではない。そして、SRMベンダー各社が、いまだに重要な機能を装備した包括的な製品を提供できないため、ユーザーは、ベストプラクティス・ソリューションを自前で開発せざるをえないのである。

　そして、こうした単発ソリューションでは、チャージバック・モデルを開発する際に、市販SRM製品との互換性を確保することが難しい。というのも、チャージバック・モデルは、依然としてアロケーション機能に大きく依存しているからである。

　そのうえ、これらの機能はインプリメントするのが大変なこともあって、多くのベンダーが、この種のリソース・マッピング機能を、必須のものではなく「あれば便利」という程度のものと見なしているのである。

　さらに、新たに登場したストレージ管理標準である「SMI-S」も、ユーザー、ベンダーの双方からその潜在能力を高く評価されてはいるものの、これによって、異機種マッピング・アプリケーションを実行するのに必要な、洗練されたシステムの構築が今すぐ可能になるわけではない。

自前のベストプラクティス・ソリューション

　イーベイの研究所に勤務する著名な研究員であるポール・ストロング氏は、「前に進むためには、リソースの利用とそれによってもたらされるビジネス上の価値とをマッピングすることができなければならない」と語る。

　さらに同氏は、この目標を達成するためには、ビジネス・プロセス、ワークフロー、ユーザー・インタラクションの価値を、サービスやアプリケーションのセットと結び付ける必要があるとも指摘する。でありながら同氏は、市販のSRMソフトでこれらの機能を実行することができるかどうかについては、「現在のところは不可能だ」と見る。

　では、どうすればいいのか。例えば、ストロング氏が籍を置くイーベイは、既存のベンダー・ツールを統合することで自前のSRMベストプラクティスを開発し、これによって、欠落部分を埋めようとしている。

　その結果、同社では、大規模アレイ上で、クラスタ化されたサーバ環境の中にある個々のデータベースに一部のアプリケーションをマッピングすることができるようになった。しかし、ストロング氏も認めているように、この手法で可能になるのは、限られた範囲での「費用と価値の比較対照」だけだ。

　しかしながら、アレイやプロセス、プロビジョニングLUN、ボリューム、OSなど「必要最低限の」コンポーネントしか導入しないというITインフラストラクチャ・アプローチをとっているイーベイにとってみれば、たとえ「限られた」機能であっても大きな意味を持つことになる。ストロング氏によれば、それは次のようなことだ。

　「環境を拡張できるようにするため、きちんと理解されている標準プロセスの小さなセットを社内標準とし、その関連性の中で強みを発揮できるようにしている。そうしておけば、何か問題が発生しても、簡単に解決することができる。気を配らなければならないコンポーネントが少なければ、少数の洗練された管理ツールで事足りるわけだ」

　アプリケーションをバックエンドのストレージ・システムにマッピングするためにイーベイが採用したアプローチは、テクノロジー・ソリューションというよりもプロセスに近い（例えば、新たなプロジェクトがサイトに追加される場合、このプロセスが各種のデータベースにどのような変更を加えればよいかを判断する）。

　これらの変更は、可能な限り特定のオラクル・インスタンスに対応した論理的なグループに分けられ、ハンドルが与えられる。論理ホストと物理インスタンスを分離し、リソース集約度の高いデータベースに拡張できるような柔軟性を確保するというのが、同社の基本的な考え方なのである。

　ストロング氏は、「当社にとって重要なのは、拡張性を確保し、会社の成長に対応することができる能力であり、どうしてもこうしたプロセスをインプリメントする必要があった。つまり、このプロセスは、どの企業にとっても意味があるというわけではない。しかしながら、管理可能なやり方で会社を急成長させることができるという点で、当社にとってはきわめて重要だったのだ」と証言する。

　なお、イーベイでは、まだチャージバックは実現されていない（実際にコスト負担をビジネス部門に割り振るには至っていない）が、これに関しては、すでにストロング氏のグループが、論理グルーピング・モデルを活用することで、特定の機能を定量化し、拡張するところまでは実現している。

　イーベイにおけるリソース・マッピングへの取り組みは、IT部門の管理者からもビジネス部門の管理者からも支持されている。それはもちろん、この手法が会社全体に付加価値をもたらすからである。

　ストロング氏によると、同氏のITチームは、SMI-Sは「最小公分母レベル」で異機種を管理するような環境においては非常に有効だが、細かな統合作業が必要となるような特殊な環境においてはあまり効果を発揮することができないのではないかと見ているという。

｜1｜2｜3｜ > 次のページへ