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

　2. 接続要件

　接続要件は、まず、SANを利用するか、NASを利用するかを検討します。自身で明確に戦略を決定できない場合は、ベンダの提案を評価する方法を選択することも可能です。

　一般的には、複数サーバ間で、ファイルレベルでの共有を実施したい場合は、NASを選択することになります。複数サーバ間でのデータ共有が必要ない場合、もしくはボリュームレベルでの共有で十分な場合は、SANでも、NASでもアーキテクチャとしては採用可能です。

　システム／ツール用、データベース用はSAN、ファイル用はNASと区別している場合もあれば、基幹業務系、対外業務系はSAN、社内業務系はNASとしている場合もあり、一概にどちらが良いとはいい難いのですが、可用性を優先する場合はSAN、柔軟性を優先する場合はNASという側面はあります。

　最近は、SCSIプロトコル（SAN接続で利用するプロトコル）をイーサーネット上で実現するiSCSIというインターフェイスも存在しており、より選択肢が広がっています。

　SAN/NASの検討に加えて、統合ストレージ基盤を利用するサーバの種類（OSの種類）も調査しておく必要があります。メインフレーム、UNIX（HP-UX、AIX、Solaris）、Linux（RedHat、SUSE）、Windows、VMWareなどの種類があり、ストレージ基盤調達の際には、重要な要件となります。その際は、少なくともバージョン（VRM）までの把握は実施します。

　また、SAN接続の場合には、データベースの種類（Oracle, DB2など）や、ボリュームマネージャーの種類、クラスターソフトウェアの種類とそれらのバージョンなども、接続性（ベンダの接続保証が得られるかどうか）の確認が必要になります。このような調査には、ベンダ所有のワークシートを利用することも可能です。

　SAN接続の場合には、接続するFCパスの数の検討も重要です。冗長性を確保するためには、最低2本のFCパスが必要となりますが、サーバの制限でHBA（ファイバケーブルを接続するためのアダプタ）が1つしか搭載できないものもあります。また、非常に多量のデータ転送を実施するために、2パス超の接続が必要な場合もあります。ブレードサーバの場合、ブレードの筐体にSANスイッチ（もしくはそれに準じた機能）が搭載されている場合が多く、この場合は、スイッチ間接続などが必要になる場合もあります。

　3. バックアップ／アーカイブ要件

　バックアップの論理要件は、まず、RPO（Recovery Point Objective）とRTO（Recovery Time Objective）です。

　RPOとは、バックアップ・データが必要な状態になったとき、どの時点でのバックアップ・データが必要か、という要件です。1日前、1週間前、もしくは、数時間前の状態にデータを戻せることが必要となるかということです。一般的には、1日の中の特定の時間（オンライン業務完了後等）にバックアップを取得し、必要な場合はその時点までデータを戻すという方法が取られます。但し、業務の特徴によっては、1日に複数のチェックポイントがあり、その時点までのデータの戻しが必要な場合、もしくは、1週間前のデータでも実質的に問題がない場合なども考えられます。

　RTOは、バックアップ・データが必要な状態になったとき、データ回復までに許容できる時間の要件です。1時間以内なのか、翌日でも構わないのかという検討になります。

　このRPOとRTOの要件により、バックアップ単位や、バックアップ手法が変わってきます。勿論、RPOとRTOの組み合わせは、複数存在することが一般的です。

　次は、バックアップにかかる時間の要件です。統合ストレージ環境では、ストレージの機能を利用した、瞬時（数秒）のバックアップが可能です。瞬時のバックアップ取得要件があるか否かを明確にしておくことは必要です。

　もし、可能であれば、日々のデータ変更度合いを把握しておくことも有効です。バックアップは、その取得時間の短縮化のために、差分バックアップを適用することが一般的となっています。極端な例ですが、毎日、データベースを再編成しているような場合は、差分バックアップによる時間短縮化のメリットがほとんど生かせません。逆に、ほとんど変更のないデータであれば、ストレージ機能を利用せず、バックアップ・ツールの差分バックアップ機能で、非常に短時間でバックアップを完了させることが可能となります。

　もう1つの論理要件として、バックアップ世代数、保管日数があります。最新のバックアップが完全に取得された後は、古いバックアップ世代は無用となることが一般的です。ただし、特殊な要件で、複数世代のバックアップが必要となる場合もあります。例えば、製造業のCADデータなどで、数十世代のバックアップを要求する場合もあります。

　保存日数が長期にわたる場合は、バックアップではなく、アーカイブとして取り扱われるべきです。物理的な障害や論理的な障害（誤ったデータ消去）などにより、必要なデータにアクセスできなくなった場合に備えるのがバックアップであり、過去のデータを利用するために保存するためのものがアーカイブです。

　アーカイブ要件には、業種によっては、行政により保管期間が定められているものもあります。金融機関の取引データは長期保管が義務付けられている1つの例です。J-SOXの対象業務システムなどは、業務データ以外にも、アクセスログなどのシステムデータに関しても、一定期間の保管が必要となっています。

RFI の利用

ここで、若干本筋とはずれますが、RFI（Request For Information: 情報提供依頼）について触れます。RFIは、ITの調達にかかわるプロセスのRFP（提案依頼）の前段階として位置付けられます。IT計画策定に際し、自社のみの情報では不十分な場合、各ベンダに必要な情報提供を求めるプロセスです。全体容量、接続要件、バックアップ／アーカイブ要件がある程度まとまった段階で、RFIを提出し、次のステップに必要な情報などを入手することも有効な手段です。また、この論理要件の抽出段階からコンサルティング・サービスを受けることも検討可能です。

2/3

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