ストレージ・アーキテクトはどう要件をまとめるか

　4. サービスレベルの検討

　統合ストレージ基盤の利用に当たり、一番期待されている要件は高い可用性だと思います。企業の重要な“情報”の保管庫であるストレージに対する可用性の要件なので、多くの方が100％を求めていますが、実際にはこの“100%”を達成することはきわめて難しい挑戦です。もし、100％の可用性を求めることが必至である場合は、現在の技術では、筐体レベルでの冗長性を持たせることが必要となり、投資額は2倍超となります。

　統合ストレージを利用する業務に対するBIA（ビジネス影響分析）を実施し、投資の妥当性を図るのが最も良いアプローチとなります。

　もう1つ多くの情報システム部門で実施している方法に、サービスレベルに差をつけた、階層化の定義があります。Aクラス、Bクラス、Cクラスや、松竹梅のように、可用性に3〜４段階程度の差を設けたメニューを作成する方法です。この場合、まず検討すべきは、ミッドレンジクラスの統合ストレージの可用性が、自社の業務要件に照らし合わせて適切かどうかを判断することです。最近のミッドレンジクラスのストレージ基盤は、性能、可用性の面でさまざまな機能強化が実装されています。ミッドレンジクラスの統合ストレージの可用性が自社要件を完全に満足しない場合、ハイエンドクラスを検討することになります。単純にクラス分けを実施すると、1. ハイエンドの冗長化、2. ハイエンド単体、3. ミッドレンジの冗長化、4. ミッドレンジ単体、という区分になります。

　次に性能と共有レベルに関するサービスレベルを検討します。性能要件は、I/O応答時間とデータ転送量で表すことができます。本来であれば、業務システム側の要件から、この2つの指標を導き出せれば良いのですが、なかなか難しい場合が多いです。良くある取り組み方としては、ストレージのシリーズや、搭載する磁気ディスクの種類などにより、3〜4段階位の差を設け、利用者に選択させる方法です。例えば、最高速(数ミリ程度のI/O応答時間)、高速（10ミリ程度のI/O応答時間）、中速（10ミリ超のI/O応答時間）などです。

　共有レベルは、他システムとのホストポートの共有の有無、物理ディスクの共有の有無の検討が必要です。この共有レベルの考え方は、第1回目に説明した“利用者”に依存する部分が最も大きいのですが、結果としては、競合発生時の性能への影響という形で現れますので、性能に関する要件とともに考慮することをお勧めします。

　もう1つ、サービスレベルとして重要な観点で、提供までのリードタイム（納期）があります。これは要件としては非機能要件に分類されますが、サービスレベルの重要な項目であるため、今回説明します。

　ある業務システムが統合ストレージを利用したいと思ってから、利用できるまでに容認できる時間（日数）を検討します。新規にサーバを接続する場合や既存サーバに対し追加容量を提供する場合など、要求の種類に応じたリードタイム要件を決定します。このリードタイムの要求が、同日や数日なのか、数週間なのかによって、結果的には調達すべき容量やソリューション、運用体制に大きく変化が生じることになります。

　5. 災害対策に関する要件

　これはオフサイト・バックアップ要件、リモート・バックアップ要件といい換えることも可能です。通常業務が稼働している主データセンターに対し、何かしらの災害が発生した場合、もしくは、統合ストレージが筐体レベルで使用が不可能になるような障害が発生した場合（通常利用であれば発生しない）の対策として検討すべき項目です。

　主データセンターとは別の場所にバックアップ・イメージを配送し保管しておくこと、有事の際にそのバックアップ・イメージからのデータ回復が可能なようにすること、もしくは、バックアップ・イメージの取得を主データセンター以外（リモート）で実施して、主データセンターへの有事に備えること、を検討します。容易なソリューションとして、テープメディアへのバックアップを地理的に離れた保管センターに配送しておくことが多くのISで実施されています。この場合は、バックアップメディアとしてテープ媒体が要件となります。それにより、日常的なテープ操作（搬出、搬入）とその運用管理が必要となってきます。

　この要件の検討に関しても、バックアップと同様、有事の際のRPO、RTOを（可能であれば、業務システム毎に）検討し、安易なソリューションの採用や、不要に高価なソリューションを採用すること避け、自社にとって適切なレベルでのソリューションを構築、運用を採択することをお勧めします。

　ここまで、論理要件に関する検討が進むと、サービス・カタログのドラフトの作成が可能となります。

1. 接続性の区分
2. 可用性の区分
3. 性能と共有レベルの区分
4. バックアップ／アーカイブの区分
5. 災害対策機能の区分

　これらについて、基本メニュー、オプション・メニューのような形式でグルーピングとクラス分けを実施し、サービス・カタログのドラフトを作成していきます。3〜5程度にまとめられると良いと思います。

　6. セキュリティ要件

　論理要件として重要な項目に、セキュリティに関する要件があります。内容は、第1回の“セキュリティ要件”に重なりますので詳細は割愛しますが、論理要件をまとめる際には必ず含めるようにします。

　以上、統合ストレージ基盤の調達の前提となる、“論理要件”（機能要件）に関して述べてきました。次のステップとしては、物理要件を明確にし、実現可能なソリューションへマッピングし、統合ストレージ基盤のサービス・カタログを完成させることになります。その過程の中で、物理的な制約、機能的な制約、運用上の制約、予算的な制約などのさまざまな制約から、論理要件を見直さざるを得ない場合が少なからず発生します。その場合に備えて、論理要件整備の過程で、必須条件と推奨条件、容認可能な範囲など、ある程度幅を持たせた要件整備を実施しておくことをお勧めします。

3/3

Index
ストレージ・アーキテクトはどう要件をまとめるか
	Page1 統合ストレージの利用計画 1. 利用業務と全体容量の把握
	Page2 2. 接続要件 3. バックアップ／アーカイブ要件
	Page3 4. サービスレベルの検討 　　　 可用性 　　　 性能と共有レベル 　　　 サービス提供までのリードタイム 5. 災害対策に関する要件 6. セキュリティ要件