連載：ストレージ・アーキテクトになろう（1）

ストレージ・アーキテクトはどう戦略を構築するか

EMCジャパン株式会社
グローバル・サービス統括本部
マネージド・サービス部 部長
森山 輝彦
2008/10/22

---

　4. 異なる利用者間での競合の容認度合い

　これは、キャパシティに関する検討項目の性能に関する検討項目です。この課題も統合ストレージ基盤の戦略を検討する際には、認識しておくべきでしょう。

　統合ストレージは、数十Gbytes〜数百Gbytesの物理ディスクを、論理ディスクという形式で分割し、各業務サーバへ提供する方法が一般的です。同一物理ディスク上に複数（10程度から数十の単位）の論理ディスクが形成されることも珍しくありません。この論理ディスクは、同一業務サーバに割り振ることも可能ですし、別のサーバに割り振ることも可能です。（実際は、RAID 1／5／6などを形成することとなりますが、複雑になるので、この場では割愛します）。ハイエンド・ストレージは、大容量キャッシュを搭載していることが多く、物理的ディスクへの同期的アクセス（物理的なディスクへのアクセスが完了することで、サーバのI/Oが完了する）は必ずしも必要ありませんが、キャッシュヒット率の高くないリード要求や、大容量の書き込み要求が発生する場合は、物理ディスクへの同期的アクセスが発生します。

　当然、異なる論理デバイスでも、同一の物理ディスクを利用していますので、物理ディスク上の同期アクセスが多くなることで、その分、サーバからのI/O応答時間にも影響を及ぼします。この状態を、競合（ディスク競合）といいます。

　このディスク競合が、異なるサーバに割り振られた、同一物理ディスク上の論理デバイス間で発生するということも、決して珍しくありません。　問題は、この異なるサーバが、別組織、別企業用のものであった場合の影響です。

　競合は、物理ディスクでの発生が最も典型的ですが、FCポートでも発生しえます。

　サーバからのI/O要求の量を制限することは、現実的には不可能ですので、この競合は避けることのできない事象です。

　最近は、異なるサーバ間のI/Oに優先順位をつけて処理するような機能が搭載されているストレージ基盤もあり、若干競合緩和に寄与しますが、根本的な解決は難しい状況です。

　この異なる利用者間の競合発生を避けるには、性能管理レベルの強化や、資源割り振りの分割単位のコントロールが必要となります。リアルタイムや、短いサイクルでの性能管理の実装、あるいは、論理デバイス単位ではなく、物理ディスク単位、FCポート単位での分割も有効な手段です。

　ストレージ・アーキテクトは、想定される性能要件と、利用者間の競合緩和をどのように実装していくかを決定していく役割を担います。

　5. 変更管理などの情報伝達方法

　統合ストレージ基盤の利用に当たり、念頭に置いておくべき項目の1つに、“変更作業の伝達”があります。　これは、ストレージ基盤のみならず、共有IT基盤サービス全体に関わる問題ですが、共有基盤に何かしらの変更を施す場合の情報共有をどのように実施していくかという点です。

　一般的に統合ストレージ基盤構築後も、適宜、業務サーバの接続や、追加容量の提供などが実施されます。その度に、何かしらの変更作業が実施されることになります。変更作業の依頼元には、変更内容、スケジュールなどは当然知らされると思いますが、共用基盤として利用しているほかの利用者へ　1. 変更作業の有無を知らせる必要があるか？　2. 変更作業の承認を得る必要があるか？ などを取り決めておくことが必要です。また、その方法や、必要なリードタイムなどを想定しておくことも重要です。　その内容により、統合ストレージ基盤に必要となる機能要件や、設計要件が変更となる可能性があります。

　6. 停止、移行調整の難易度

　統合ストレージ基盤のライフサイクル全般を計画する際、一定時間のサービス停止が許容できるか、もし、許容可能だったとしても、そのスケジュール調整が現実的かどうかを把握しておくことが肝要です。特定の業務システムであれば、サービス停止に関する調整は比較的現実的な課題ですが、利用者が多岐にわたる場合は、現実的にはかなり困難となる可能性があります。　“無停止で、ライフサイクルの５年間稼動できること”　というような項目をRFPに盛り込むことは簡単ですが、それを確実に実施するためには、1. 無停止で変更を実施するための入念な変更管理プロセスの構築、2. 筐体レベルの二重化（もしくは仮想化ソリューションの二重化）の投資対効果の見極め、3. 入念な業務の利用計画　（サーバのバージョンとストレージのマイクロコードの親和性の見極め）の策定が必要となります。

　実際に起こりやすい悪い例としては、調達時には、無停止を前提とし、マイクロコードのバージョンアップなどを実施しない計画としていたが、3年経過後に、特定の業務システムへのサービス提供のため、やむを得ず、マイクロコードのバージョンアップを計画することになったが、最初に利用を始めていた業務システム基盤のバージョンが古く、ベンダサポート上の問題が浮上してしまった。ストレージの筐体レベルでの停止が可能であれば、事前にテストなどを実施し、リスクを評価することができたが、全利用者の停止調整ができず、リスクの評価が曖昧なまま、作業の実施を決断せざるを得なくなった。というような事態を招くことです。

　統合ストレージ基盤のライフサイクルの最後に発生するイベントとして、ストレージの移行があります。この場合も、予め意識しておかない限り、その時期に検討を開始し、利用者との調整を実施しながら、計画を進めていことになります。その場合、利用者が同一企業内であれば、協力体制は得られやすいと思いますが、企業を跨る場合は、非常に困難な課題となる場合が多いです。ストレージの仮想化技術は、このストレージ筐体移行の透過性を確保するソリューションとなりますが、現在の技術では、対象が同一ベンダに限られることを全体戦略として容認できるかどうかがポイントです。

　仮想化技術の検討においても、それ自身のライフサイクルを見極めることが極めて重要な検討項目となります。

　7. 他の共用サービス（ネットワークなど）との整合性

　共有IT基盤として位置づけされる統合ストレージ基盤の計画、調達の際の検討課題について、述べてきましたが、先行して共用ＩＴ基盤として運用されている、ネットワークサービス等が、どのような点に留意して構築され、運用されているかを把握しておくことも重要です。そのサービス提供母体が同一であれば、利用者の範囲も類似になると思われます。技術的な観点での相違はありますが、利用者の特徴によるライフサイクルを通じた検討項目は参考になる部分が多いはずです。自社内での経験を生かすことも重要です。

　8. 利用側と基盤側のライフサイクルの整合性

　優れたIT基盤サービスの条件は、1. 提供者が利用者の期待を理解していること、2. 利用者が提供サービスレベルを理解していること、です。　一言でいえば、「サービスレベルの合意」（SLA）となります。さまざまな項目がありますが、忘れがちなのがライフサイクルです。業務のライフサイクル、サーバ（OS、ミドルウェアを含む）、ストレージ基盤のライフサイクルが意識されており、相互に可能な限りの整合性が取られていることが、望ましい状態です。したがって、ある程度の規模があれば、統合ストレージ基盤を、共用基盤ではなく、特定の業務システムに占有させることも有効な手段です。

●●●

　“統合ストレージ基盤の検討と戦略”というと、一般的には、全体容量の把握と、バックアップソリューション、災害対策ソリューションの選定、最適化を図るための階層化の適用などが掲げられると思います。もちろん、これらの項目も基盤を検討する際には重要な項目であり、次章以降では触れることになります。しかし、その前提として、まずは利用者と提供者（自部門、あるいは自社）の関係を確実にし、その利害関係を整理し、サービス提供のライフサイクルに渡って、利用者側に負担を強いること、不利益になるようなことの発生状況を想定し、可能な限り計画に盛り込むことが、重要となります。情報システムのユーザー企業に属するITアーキテクト（ストレージ・アーキテクト）にとっては、特に重要な項目です。

　次回は、IT投資により、具体的にどのような統合ストレージ基盤サービスを提供するのかという点について述べたいと思います。

4/4

Index
ストレージ・アーキテクトはどう戦略を構築するか
	Page1 ストレージ・アーキテクトという職業 統合ストレージの検討と戦略
	Page2 1. 予算化、決済方法、課金方法
	Page3 2. 筐体戦略 3. セキュリティ要件
	Page4 4. 異なる利用者間での競合の容認度合い 5. 変更管理などの情報伝達方法 6. 停止、移行調整の難易度 7. 他の共用サービス（ネットワークなど）との整合性 8. 利用側と基盤側のライフサイクルの整合性

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）