JP2006079273A - ファイル管理装置、ネットワークシステム、ファイル管理方法及びプログラム - Google Patents

Abstract

【課題】階層型のストレージ管理手法を採用したシステムにおいて期待通りのパフォーマンスが得られていない。
【解決手段】物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムを、仮想的に単一のストレージとして管理するファイル管理装置として、（ａ）ストレージシステムを構成する各ストレージメディアと、ネットワーク経由で接続されたアプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する階層管理部と、（ｂ）予め定めた移動条件に従って、階層区分間でデータを移動する移動管理部とを有するものを提案する。
【選択図】図４

Description

発明の一つの形態は、ストレージシステムのファイル管理装置に関する。発明の他の形態は、同システムの管理方法に関する。また、発明の他の形態は、同ストレージシステムを採用するネットワークシステムに関する。また、発明の他の形態は、同技術を実現するプログラムに関する。

ネットワークの発達した今日、複数台のコンピュータでデータを共有する機会が増えている。かかるデータの共有を実現するコンピュータを、アプリケーションサーバーという。
アプリケーションサーバーを運用するには、ストレージ装置の故障等を考慮する必要がある。一般には、データを冗長化（バックアップ）し、ストレージ装置の故障等に備えている。
通常、データのバックアップは、アプリケーションサーバーを使用しない時間帯に行う。例えば、夜間に行われる。確かに、蓄積するデータが少ないうちは十分な時間である。しかし、近年、データは加速度的に増加している。また、記録領域の高密度化と大容量化も顕著に進んでいる。

その一方で、データの転送速度は、容量等の増加に比べそれほど向上していない。このため昨今、バックアップに要する時間が大幅に長くなっている。この結果、バックアップ作業が、運用停止時間内に終了しない可能性が懸念されている。
この問題の回避には、より転送速度の速いディスク装置やテープ装置の採用が必要である。例えば、ＲＡＩＤ（Redundant Arrays of Independent
Disks ）装置の使用が必要である。
しかし、ＲＡＩＤ装置への全面的な移行には、多額の費用を必要とする。また昨今では、ストレージ装置の並列化に技術的な限界が指摘されている。

加えて、管理データ量の増大の問題もある。これは、近年における情報の電子化に起因する。情報の電子化の影響で、現在、アプリケーションサーバー上に多量のデータが蓄積されている。
アプリケーションサーバーに蓄積されるデータは、おおよそ２種類のデータに分類される。“使用中のデータ”と“使われていないデータ”との２種類である。
図１は、この様子を表している。図１に示すように、ディスク装置には、“使用中のデータ”と“使われていないデータ”の両方が存在する。この“使われていないデータ”の存在が、アプリケーションサーバーの記憶容量を圧迫している。また、この“使われていないデータ”の存在が、バックアップ時間の増大とコスト負荷の増大の要因になっている。
特開２０００−１４８５４７号公報

かかる問題を解決するため、階層型ストレージマネジメント（ＨＳＭ：Hierachical
Storage Management）という概念が提案されている。
図２に概念構成を示す。ＨＳＭは、２種類のデータを物理的特性が異なる２種類のストレージ装置で管理することを特徴とする。例えば、“使用中のデータ”をアクセス性に優れたディスク装置で管理し、“使われていないデータ”を大容量でコストパフォーマンスに優れたテープ装置で管理する手法を採用する。
なお、ＨＳＭでは、“使われていないデータ”も論理的にはディスク装置上に存在するように扱われる。

ＨＳＭは、全てのデータをディスク装置で管理する従来の手法に比べ、ストレージシステムを低コストで構築できる利点がある。加えて、ＨＳＭは、バックアップ時間を短縮できる利点がある。これは、図２に示すように、バックアップ対象となるディスク装置上のデータ量が少なくなるためである。
もっとも、テープ装置上に存在するデータへのアクセス性は悪くなる。これは、テープ装置が、ランダムアクセス性を有しないためである。しかし、仮に時間が掛かっても、“使われていないデータ”であれば、実用上あまり問題にならない。
このように、ＨＳＭは、理想的な管理手法と言える。

しかし、実際には、ディスク装置の記憶容量を確定することが難しいという問題がある。その理由は、“使用中のデータ”のデータ容量は非常にあいまいで、最初から確定するのが難しいためである。また、“使用中のデータ”のデータ容量は、使用中に変化するためである。
また、既存のＨＳＭは、外部システムからストレージシステムに移動された後のデータだけを管理する。すなわち、既存のＨＳＭは、ストレージシステム内のデータだけを管理する。これは、ストレージシステムに対するデータの書き込みを外部システム（例えばアプリケーションサーバー）に依存するためである。
このように、既存の管理手法には、外部システム側のデータ管理とストレージシステム側のデータ管理との連携に問題があった。

発明者は、以上の事実認識に基づき、以下のファイル管理技術を提案する。
（Ａ）ファイル管理技術１
発明者は、物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムを、仮想的に単一のストレージとして管理するファイル管理装置に、以下の機能ａ及び機能ｂを搭載するものを提案する。
（機能ａ）
ストレージシステムを構成する各ストレージメディアと、ネットワーク経由で接続されたアプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する階層管理機能
（機能ｂ）
予め定めた移動条件に従って、階層区分間でデータを移動する移動管理機能

（Ｂ）ファイル管理技術２
また、発明者は、物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムを、仮想的に単一のストレージとして管理するファイル管理装置に、以下の機能ａ及び機能ｂ’を搭載するものを提案する。
（機能ａ）
ストレージシステムを構成する各ストレージメディアと、ネットワーク経由で接続されたアプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する階層管理機能
（機能ｂ’）
予め定めた複製条件に従って、階層区分間でデータを複製する複製管理機能

以上のように、このファイル管理装置は、ストレージシステム内だけでなく、ネットワーク経由で接続されたアプリケーションサーバーも論理的な階層区分で一元的に管理し、階層区分間のデータ移動又は複製を管理する。
従って、ファイル管理装置は、アプリケーションサーバー上のデータもストレージシステムのデータと同様に、自律的に移動又は複製できる。このため、アプリケーションサーバーの制御やユーザーの操作とは関係なく、予め定めた条件に従ってデータを移動又は複製することができる。
なお、アプリケーションサーバーが複数の場合、ファイル管理装置は、アプリケーションサーバー単位で論理的な階層区分を管理することが望ましい。この場合、アプリケーションサーバー毎に管理ポリシーを定めることができる。

因みに、アプリケーションサーバーのストレージメディアは、論理的な階層区分の最上位に位置し、ストレージシステムを構成する各ストレージメディアは、論理的な階層区分においてアプリケーションサーバーのストレージメディアよりも下位の階層区分に位置することが望ましい。
ここで、ストレージシステムは、少なくとも論理的に３つの階層区分で構成され、その最上位の階層区分には、信頼性と高速アクセス性に優れるストレージメディアが対応し、２番目の階層区分には、高速アクセス性と経済性に優れるストレージメディアが対応し、最下位の階層区分には、信頼性と大容量性に優れるストレージメディアが対応するのが望ましい。

なお、各ストレージメディアには、例えば、ハードディスク、磁気テープその他の磁気記憶媒体、光学的にデータを記録可能な光記憶媒体、半導体メモリを使用する。なお、ストレージメディアの外観形状は問わない。例えば、ディスク形状、テープ形状、カード形状等、各記録方式として適用可能なものを採用する。
また、各ストレージメディアの種類は同じでも良いし、異なっても良い。また、各ストレージメディアの信頼性やアクセス性能（ランダムアクセス性能を含む）は同じでも良いし、異なっても良い。一般に、使用頻度の高い区分に対応するストレージには、高速アクセス性が要求される。また、使用頻度が低い区分に対応するストレージには、大容量であることが要求される。
また、ストレージシステムを構成する各ストレージの格納形態は任意である。例えば、各ストレージは同一筐体に内蔵されていても良い。その反対に、それぞれ個別の筐体に格納されても良い。

同様に、ストレージシステムを構成する各ストレージの配置形態は任意である。例えば、いずれのストレージも同一の場所又は同一の空間に配置されていても良い。その反対に、それぞれ別の場所又は別の空間に配置されていても良い。
また、各ストレージ間の接続形態も任意である。有線接続であっても、無線接続でも良い。また、ネットワーク経由で接続しても、専用線経由で接続しても良い。各ストレージ間における通信手順についても同様である。
前述した様々な要素は、ストレージシステムを構築する使用環境に応じて最適なものを選択すれば良い。
また、以上の管理機能は、ハードウェアとしてもソフトウェアとしても実現できる。なお、ソフトウェアには、アプリケーションソフトウェアの他、オペレーションシステムやファームウェアを含む。

発明に係るファイル管理技術の採用により、運用中のデータ量の増加にもバックアップ時間の増加を招くことなく対応できる低コストのストレージ管理システムを実現できる。また、アプリケーションサーバー上のデータをストレージシステムに自律的に移動又は複製することができる。

以下、本発明をＮＡＳ（Network Attached Storage）システムに応用する場合について説明する。なお、明細書で特に図示又は記載しない技術は、当該技術分野において周知の技術を適用する。
（Ａ）管理ポリシー
図３に、実施形態で採用する管理ポリシーを示す。図３は、以下に示す３つの管理ポリシー（ａ）〜（ｃ）の具体例である。
（ａ）４種類のストレージメディアを５つの階層区分に分けて管理する。各ファイルは、使用状況に応じて階層区分間を移動する。
（ｂ）バックアップ（複製）に使用するストレージメディアと、バックアップ（複製）のタイミングを適切に選択する。
（ｃ）ファイル（実データ）がどの階層区分に移行しても、ファイルシステム上の位置は不動である。

（Ａ−１）ポリシー（ａ）
アプリケーションサーバーとストレージシステムを構成する計４種類のストレージを、５つの階層区分に分類する。各階層区分は、使用頻度に応じた階層区分に対応する。
階層区分は、使用頻度の高い方から順に、「非常によく使うファイル群」、「よく使うファイル群」、「たまに使うファイル群」、「ほとんど使わないファイル群」、「使わないが保存が必要なファイル群」の５つである。
使用頻度の区分は、システム全体から見た使用頻度で判断する。すなわち、階層区分毎に判断しない。ファイルシステムに記録されている前回のアクセス時からの経過時間を区分移動の判断材料とする。ここでのファイルシステムは、アプリケーションサーバー側のファイルシステムと、ストレージシステム側のファイルシステムとの２つである。
具体的には、各階層区分間に設定した閾値との比較結果に応じて判断する。ファイルへのアクセスが発生した時点で経過時間はリセットされ、論理上の階層区分は最上位に移動する。

運用開始から長期間が経過したファイルシステムでは、下位区分のデータ比率が多くなる。図３は、オンラインでファイル（実データ）へのアクセスが可能な上位４区分の合計容量を１００％として表した場合の一例である。
因みに、図３の場合、１番目の階層に対応する「非常によく使うファイル群」のデータ比率は全体の３％、２番目の階層に対応する「よく使うファイル群」のデータ比率は全体の７％である。
同様に、３番目の階層に対応する「たまに使うファイル群」のデータ比率は全体の３０％、４番目の階層に対応する「たまに使うファイル群」のデータ比率は全体の６０％である。

各階層区分には、以下のメインストレージをそれぞれ対応付ける。まず、使用頻度が最も高い「非常によく使うファイル群」には、可用性（availability）が確保されたディスク装置を対応付ける。例えば、ＲＡＩＤ構成のハードディスクや半導体記憶装置を対応付ける。
使用頻度が２番目に高い「よく使うファイル群」には、信頼性の高いディスクデバイスを対応付ける。例えば、ＲＡＩＤ構成のハードディスクを対応付ける。
使用頻度が３番目に高い「たまに使うファイル群」には、コストパフォーマンスに優れたディスクデバイスを対応付ける。例えば、ＩＤＥハードディスクを対応付ける。図３の場合、上位３階層部分の全データ量のうち７５％（４０％のうちの３０％）を安価なディスクデバイスに対応付ける。
このため、同データ量を最上位階層のディスクデバイスで構成する場合に比してコストの大幅な低減を実現できる。なお、ファイルへのアクセス速度は、「よく使うファイル群」に対応するディスクデバイスと同等である。従って、外部からはディスクデバイスの違いは認識されない。

使用頻度が４番目に高い「ほとんど使わないファイル群」には、テープメディアを対応付ける。このテープメディアは、伝送路を通じて電気的にアクセス可能である。すなわち、オンライン状態にある。
テープメディアは信頼性が高く、データ当たりの単価がディスクデバイスに比して格段に安い。また、大容量のデータを蓄積するのに適している。従って、オンラインで管理する必要のあるファイルのうち大部分を占めるこの種のファイルの蓄積には最適である。すなわち、上位４階層部分の全データ量のうち６０％を安価で信頼性の高いテープメディアに蓄積する。
なお、「使わないが保存が必要なファイル群」には、テープメディアを対応付ける。ただし、このテープメディアは、電気的には直接アクセスできない状態で管理される。すなわち、オフライン状態で管理される。例えば、テープメディアは、棚や箱などに物理的に保管される。

（Ａ−２）ポリシー（ｂ）
上位３階層に対応するファイルのバックアップ（冗長化）には、メインストレージとは物理特性の異なるテープデバイスを選択する。これは、以下の理由による。
理由の１つは、テープは静的メディアで壊れないためである。一方、ディスクデバイスは、地震等の外力によって物理的に壊れ、データの読み出しが不可能になる可能性がある。
他の理由の１つは、ディスクデバイスは、同じロットのハードディスクが同時に壊れる可能性があることである。これに対し、複数のテープメディアが同時に壊れる事態は限定される。
また、テープメディアの場合は、後から容量を増やすことが容易なためである。また、テープメディアは、オフライン管理ができることもバックアップ用のストレージに使用する理由である。

なお、冗長化は、上位３階層の区分について行う。
このうち最上位の区分に属するファイルのバックアップは、例えば毎夜、運用の終了後に行う。例えば、夜１時から行う。これにより、使用頻度が高く、経済的損失が高いファイルが保護される。
また、上位から２番目の区分に属するファイルのバックアップは、例えば月に１回実行する。また、上位から３番目の階層区分に属するファイルのバックアップは、２番目の階層区分から３番目の階層区分にファイルが移動される時点に実行される。このように、上位３階層区分のファイルへのアクセス性と保存の安全性を確保する。

（Ａ−３）ポリシー（ｃ）
ファイルは、データ本体であるビットデータと、その管理データとに分けて管理する。管理データは、ビットデータにアクセスするための識別子（ＩＤ）、ファイル名、その他の管理情報である。管理データは、最上位階層のストレージメディアにあるファイルシステムにリンクする。
ここで、ストレージ上のファイル又は実データへは次のようにしてアクセスする。まず、上位２階層の区分に属するファイルへは、上位２階層のファイルシステムを通じてアクセスする。
すなわち、アプリケーションサーバーのファイルシステムとストレージシステムのファイルシステムを通じてアクセスする。
なお、バックアップファイルに対しては、当該ファイルシステムにリンクされたフルパス名を通じて行う。フルパス名は、データーベースで管理する。

また、「たまに使うファイル群」その他の下位区分へは、ファイルシステムにリンクされている固有の識別子を使用してアクセスする。これにより、ビットデータの実際の格納位置が下位の区分に移動しても、ファイルシステム上の論理位置に影響しない。
なお、このバックアップファイルには、固有の識別情報とリンクされているテープメディア上の物理位置情報を用いてアクセスする。リンク情報は、データーベースで管理する。

（Ｂ）ネットワークシステム
（Ｂ−１）全体構成
図４に、ＮＡＳシステムの概念構成を示す。本システムは、ネットワーク１にストレージサーバー３、アプリケーションサーバー５、クライアント端末７が接続された構成を有する。
ストレージサーバー３は、ストレージシステム３１と、そのファイル管理装置３３とで構成される。ストレージシステム３１は、物理的特性を異にする複数種類のストレージメディアによる複合システムである。図４の場合、１次ストレージ３１Ａ、２次ストレージ３１Ｂ、３次ストレージ３１Ｃの複合システムとして構成される。

ファイル管理装置３３は、ストレージシステム３１を仮想的に単一のストレージメディアとして管理する制御装置である。このファイル管理装置３３には、３つの機能が搭載されている。階層管理部３３Ａと、移動管理部３３Ｂと、複製管理部３３Ｃとの３つである。
階層管理部３３Ａは、ストレージシステム３１を構成する３つのストレージメディアと、アプリケーションサーバー５のストレージメディアを論理的な階層区分により管理する処理デバイスである。前述したように、階層管理部３３Ａは、アプリケーションサーバー５のストレージ５Ａを最上位の階層区分として管理し、ストレージシステム３１をその下位の階層区分として管理する。因みに、１次ストレージ３１Ａは２番目の階層区分として、２次ストレージ３１Ｂは３番目の階層区分として、３次ストレージ３１Ｃは４番目の階層区分として扱う。
移動管理部３３Ｂは、前述したポリシー（ａ）により階層区分間のデータ移動を管理する処理デバイスである。なお、データ移動により移動元のデータは削除される。
複製管理部３３Ｃは、前述したポリシー（ｂ）により階層区分間のバックアップを管理する処理デバイスである。

アプリケーションサーバー５は、複数台のクライアント端末７で共用する共用ファイルの保持機能と業務システムへの処理を橋渡しする機能とを実現するサーバである。新規のデータはアプリケーションサーバー５で発生され、そのストレージ５Ａに記憶される。このアプリケーションサーバー５のストレージ５Ａが、論理階層区分の最上位階層に対応する。すなわち、“非常によく使うファイル”が記憶される。
クライアント端末７は、ネットワーク１経由でストレージサーバー３とアプリケーションサーバー５に接続されるネットワーク端末である。クライアント端末７は、コンピュータ構成であり、固有のストレージデバイスを有している。なお、このストレージデバイスは、アプリケーションの作業領域として用いられ、作業終了後のデータはアプリケーションサーバー５上に格納される。

（Ｂ−２）ファイル管理装置の実施例
図５に、ストレージサーバーの実施例を示す。因みに、ネットワーク１には、例えばＬＡＮ（Local Area Network）を使用する。ＬＡＮのインタフェースには、例えばイーサネット（登録商標）、ＦＤＤＩ（Fiber Distributed Data Interface）を使用する。
ネットワークプロトコルには、ＮＦＳ（Network File System） やＣＩＦＳ（Common Internet File System） その他を使用する。
仮想的に単一のストレージとして動作するストレージサーバー３は、メインサーバー３１１と、キャッシュサーバー３１３と、テープライブラリ３１５とで構成されている。物理的には、メインサーバー３１１がネットワークと接続される。従って、クライアント端末７とストレージサーバー３との通信は、メインサーバー３１１経由で行われる。ここで、メインサーバー３１１とキャッシュサーバー３１３は、それぞれ独立した制御プログラムによって制御される。

メインサーバー３１１は、ネットワークシステム上のファイルを管理する機能と、論理階層区分の第２階層に当たる“よく使うファイル”を蓄積するストレージ機能とを有する。なお、メインサーバー３１１が有するストレージデバイスは、論理上、階層が最も高い区分に対応する。
メインサーバー３１１は、中央処理装置（ＣＰＵ）３１１Ａと、主記憶装置３１１Ｂと、副記憶装置３１１Ｃと、ＲＡＩＤストレージ３１１Ｄと、接続ポート３１１Ｅ１〜３１１Ｅ３とで構成される。
このうち、接続ポート３１１Ｅ１は、ネットワークとの接続用である。接続ポート３１１Ｅ２は、キャッシュサーバー３１３との接続用である。接続ポート３１１Ｅ３は、テープライブラリ３１５との接続用である。
因みに、ＲＡＩＤストレージ３１１Ｄが、図４の１次ストレージ３１Ａに対応する。また、キャッシュサーバー３１３が、図４の２次ストレージ３１Ｂに対応する。また、テープライブラリ３１５が、図４の３次ストレージ３１Ｃに対応する。

ＣＰＵ３１１Ａは、コンピュータの制御と命令の取り込み、実行を担当する。主記憶装置３１１Ｂは、処理手順を記述したプログラムやデータの一時的な記憶を担当する。例えば、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）でなる。
主記憶装置３１１Ｂには、例えば基本入出力システム、ファームウェア、制御ソフトウェアが記憶される。
副記憶装置３１１Ｃは、プログラムや処理データの保存を担当する。例えば、ハードディスク装置その他の記憶媒体（例えばＣＤ−ＲＯＭ）の駆動装置でなる。副記憶装置３１１Ｃには、例えばファイル管理装置３３（３３Ａ、３３Ｂ、３３Ｃ）としての機能を実現する制御プログラムが記録される。

ＲＡＩＤストレージ３１１Ｄには、例えばＲＡＩＤレベル０＋１でハードディスクアレイを並列接続したものを適用する。すなわち、ストライピング（ＲＡＩＤ
０）構成のディスク装置をミラーリング(ＲＡＩＤ １)するものを使用する。
この構成により、ＲＡＩＤストレージ３１１Ｄは、高信頼性とランダムアクセス性を保持する。ＲＡＩＤストレージ３１１Ｄには、“よく使うファイル”の実データを蓄積するストレージ領域として機能する。
このＲＡＩＤストレージ３１１Ｄに、ファイルシステムと各ファイルに固有の識別子をリンクするデーターベースを記録する。なお、各ファイルの実データの物理的な記録位置も記録する。

キャッシュサーバー３１３は、最上位から３番目の階調区分に対応する。すなわち、“たまに使うファイル”を記録するのに使用される。
キャッシュサーバー３１３には、例えばＲＡＩＤレベル５でハードディスクアレイを並列接続したものを適用する。すなわち、パリティデータを各ハードディスクに分散するものを使用する。
この構成により、キャッシュサーバー３１３は、高信頼性とランダムアクセス性を有する。なお、キャッシュサーバー３１３を構成するハードディスクには、例えば低価格かつ大容量のＩＤＥハードディスクを使用する。
ＩＤＥハードディスクは、ＲＡＩＤストレージ３１１Ｄを構成するハードディスクに比して容量当たりの単価が安い。このため、同じ容量をＲＡＩＤストレージ３１１Ｄだけで用意する場合に比してコストを安くできる。

キャッシュサーバー３１３には、ＲＡＩＤストレージ３１１Ｄから使用頻度が低下したファイルの実データが移動される。なお、移動の際、移動対象の実データは、ＲＡＩＤストレージ３１１Ｄから削除される。また、移動の際、移動対象の実データは、テープライブラリ３１３にも重畳的に記録される。すなわち、移動と同時にバックアップも実行される。
ここで、キャッシュサーバー３１３は、テープライブラリ３１５のキャッシュとしての機能も果たす。従って、キャッシュサーバー３１３とテープライブラリ３１５の両方に存在する実データは、キャッシュサーバー３１３から読み出される。
なお、キャッシュサーバー３１３とメインサーバー３１１は、例えばイーサネット（登録商標）経由で接続する。

テープライブラリ３１５は、最上位から４番目の階調区分に対応する。すなわち、“ほとんど使わないファイル”を記録するのに使用される。
また、テープライブラリ３１５は、アプリケーションサーバー５と、ＲＡＩＤストレージ３１１Ｄと、キャッシュサーバー３１３のバックアップストレージとして機能する。
テープライブラリ３１５には、例えばカートリッジ型の磁気テープを複数格納するものを適用する。カートリッジの数を増やすことで蓄積するデータ容量を増加できる。もっとも、単一のテープカートリッジを装填できるテープ記録装置を使用しても良い。
なお、使用されないことが明らかなデータを記憶したカートリッジは、オフラインで保管することもできる。

テープライブラリ３１５は、キャッシュサーバー３１３に蓄積されている実データのうち使用間隔が所定の閾値を越えたものが移動される。なお、この移動は論理的なものである。ＲＡＩＤストレージ３１１Ｄからキャッシュサーバー３１３へのファイルの移動時に既に複製されているからである。
従って、ファイルの移動時に実行される動作は、キャッシュサーバー３１３からファイルの実データを削除する動作だけである。
また、テープライブラリ３１５には、ＲＡＩＤストレージ３１１Ｄから定期的にファイルがバックアップされる。このように、定期的なバックアップで移動されるのは、オンラインでアクセス可能な全ストレージ容量の１０％程度である。従って、バックアップに要する時間は、格段に短縮される。

なお、テープライブラリ３１５へのバックアップでは、”ファイル”の実データ部分だけでなく、管理データやデーターベース情報も複製するのが望ましい。この際、テープライブラリ３１５とメインサーバー３１１は、例えばＳＣＳＩ（Small Computer System Interface ）経由で接続する。
因みに、テープ媒体として、書き込みが１回に限定されるもの用いれば、情報の信頼性を高めることができる。この種のテープ媒体は、ＷＯＲＭ（Write Once Read Many）と呼ばれる。
特に、信頼性が要求される応用例では、この種のテープ媒体を使用する。勿論、何度も書き換え可能なものを用いることもできる。

（Ｃ）ファイル管理動作
以下、ストレージサーバー３内で実行されるファイル管理動作を説明する。なお、本動作は、ストレージサーバー３を管理する制御ソフトウェアにより実行される。

（Ｃ−１）領域の定義
まず、以下の説明で使用する表記を説明する。図６に、５つの領域Ａ〜Ｅとストレージとの論理的な対応関係を示す。また図７に、領域Ａ〜Ｅとストレージとの物理的な対応関係を示す。
この５つの領域は、前述した階調区分に対応する。
まず、領域Ａ−１は、使用頻度が最も高い論理上の階層区分のメインストレージに対応する。この領域Ａ−１は、アプリケーションサーバー５のストレージ５Ａに対応する。また、領域Ａ−２は、領域Ａ−１の冗長化に使用するストレージに対応する。領域Ａ−２は、テープライブラリ３１５の記憶領域の一部として確保される。例えば、１つ又は複数の磁気カートリッジに確保される。
次に、領域Ｂ−１は、使用頻度が２番目に高い階調区分のメインストレージに対応する。領域Ｂ−１は、メインサーバー３１１のＲＡＩＤストレージ３１１Ｄの記録領域に確保される。また、領域Ｂ−２は、領域Ｂ−１の冗長化に使用するストレージに対応する。この領域Ｂ−２も、テープライブラリ３１５の記憶領域の一部として確保される。例えば、１つ又は複数の磁気カートリッジに確保される。

領域Ｃ−１は、使用頻度が３番目に高い階調区分のメインストレージに対応する。領域Ｃ−１は、キャシュサーバー３１３の記録領域に確保される。領域Ｃ−２は、領域Ｃ−１の冗長化に使用するストレージである。この領域Ｃ−２も、テープライブラリ３１５の記憶領域の一部として確保される。例えば、１つ又は複数の磁気カートリッジに確保される。
領域Ｄ−１は、オンラインで管理できる中でも最も使用頻度が低い階調区分のメインストレージに対応する。領域Ｄ−１は、テープライブラリ３１５の記憶領域の一部として確保される。例えば、１つ又は複数の磁気カートリッジに確保される。なお、領域Ｄ−１は、信頼性の高いテープライブラリ３１５上に確保されるため、冗長化用のストレージは用いない。
領域Ｅ−１は、オフラインで管理される階調区分のメインストレージに対応する。領域Ｅ−１は、倉庫や棚に物理的に保存されている磁気カートリッジに対応する。

（Ｃ−２）区分間移行と冗長化処理
領域間の移行は、下位層へ向かう流れ（Ａ→Ｂ→Ｃ→Ｄ→Ｅ）と、上位層へ向かう流れ（Ｅ→Ｄ→Ｃ→Ｂ→Ａ）の２つに分けられる。
（ａ）制御ソフトウェアの処理動作
（ａ−１）使用頻度を移動条件とする場合
図８に、メインサーバー３１１の制御ソフトウェアによるファイルの自律的な移動処理を実現する処理例を示す。この処理は、例えば定期的又は新たに書き込むべきファイルが発生した時点で実行される。実行タイミングは、事前の設定による。図８は、使用頻度を判断条件とする。また、この判断処理は、各階層区分について実行される。
ここでは、最上位の階層区分について移動の有無を判断するものとして説明する。
まず、制御ソフトウェアは、アプリケーションサーバー５のストレージ５Ａに使用頻度が閾値Ｔｈ以下のデータがあるか否か判定する（ＳＰ１）。否定結果が得られた場合（全て“非常によく使うデータ”の場合）、制御ソフトウェアは判定処理をひとまず終了し、他の階層区分の処理に移る。

これに対し、肯定結果が得られた場合（“よく使うデータ”が見つかった場合）、制御ソフトウェアは、移動対象とするファイルを決定する（ＳＰ２）。
移動するファイルが決定されると、制御ソフトウェアは、下位階層であるメインサーバー３１１へのファイルの移動が可能か否か判定する（ＳＰ３）。否定結果が得られた場合（記録領域が不足する場合）、制御ソフトウェアは、例えば使用頻度が所定の閾値以下のものを“たまに使うデータ”としてメインサーバー３１１から削除する（ＳＰ４）。
ステップＳＰ３で肯定結果が得られた場合又は空容量が確保された場合、制御ソフトウェアは、“よく使うデータ”をメインサーバー３１１に移動する（ＳＰ５）。なお、移動後、同ファイルは、アプリケーションサーバー５のストレージ５Ａから削除される。
かかる後、制御ソフトウェアは、ファイルの移動先情報をデーターベースに登録し、後の読み出しに備える（ＳＰ６）。

（ａ−２）空き容量を移動条件とする場合
図９に、メインサーバー３１１の制御ソフトウェアによるファイルの自律的な移動処理を実現する処理例を示す。この処理も、例えば定期的又は新たに書き込むべきファイルが発生した時点で実行される。実行タイミングは、事前の設定による。図９は、空き容量を判断条件とする。また、この判断処理は、各階層区分について実行される。
ここでは、最上位の階層区分について移動の有無を判断するものとして説明する。
まず、制御ソフトウェアは、アプリケーションサーバー５のストレージ５Ａの空き容量が閾値Ｔｈ以下のデータがあるか否か判定する（ＳＰ１１）。否定結果が得られた場合（十分な空き容量がある場合）、制御ソフトウェアは判定処理をひとまず終了し、他の階層区分の処理に移る。

これに対し、肯定結果が得られた場合（空き容量が少ない場合）、制御ソフトウェアは、移動対象とするファイルを決定する（ＳＰ１２）。例えば、サイズの大きいファイルを選択する。
移動するファイルが決定されると、制御ソフトウェアは、下位階層であるメインサーバー３１１へのファイルの移動が可能か否か判定する（ＳＰ１３）。否定結果が得られた場合（記録領域が不足する場合）、制御ソフトウェアは、例えばファイルサイズの大きいものをメインサーバー３１１から削除する（ＳＰ１４）。
ステップＳＰ１３で肯定結果が得られた場合又は空容量が確保された場合、制御ソフトウェアは、移動対象に決定したファイルをメインサーバー３１１に移動する（ＳＰ１５）。なお、移動後、同ファイルは、アプリケーションサーバー５のストレージ５Ａから削除される。
かかる後、制御ソフトウェアは、ファイルの移動先情報をデーターベースに登録し、後の読み出しに備える（ＳＰ１６）。

（ｂ）階層区分間の移動動作
（ｂ−１）制御ソフトウェアによる自動処理
図１０に、制御ソフトウェアによるファイルの自動移動経路を示す。
下位層（Ａ→Ｂ→Ｃ→Ｄ→Ｅ）への流れは、ファイルが、クライアント端末７からアクセスされなかった時間により制御される。ファイルがクライアント端末７からアクセスされなかった時間が長い程、ファイルは下位の階層に順に移行する。
一方、上位層（Ｅ→Ｄ→Ｃ→Ｂ→Ａ）への流れは、クライアント端末７からアクセスがあった時点に生じる。まず、各領域から領域Ａに該当ファイル（実データ）が移行される。その後、領域Ａからクライアント端末７にファイルが読み出される。
以上が、各方向への流れの概略である。以下、個々のプロセスについて説明する。なお図中、実線は移動を表し、点線はバックアップ（複製）を示す。

(1)
制御ソフトウェアが定期的にアプリケーションサーバー５にアクセスし、そのストレージ５Ａ（領域Ａ−１）からテープライブラリ３１５（領域Ａ−２）にファイルを複製する。
(2)
制御ソフトウェアが定期的にアプリケーションサーバー５のファイルシステムにアクセスし、使用頻度が閾値Ｔｈ以下のデータをメインサーバー３１１（領域Ｂ−１）に移動する。これにより、アプリケーションサーバー５のストレージ５Ａは、常に適切な空き容量が確保される。
(3)
制御ソフトウェアは、更に定期的に領域Ｂ−１のデータを領域Ｂ−２に複製（バックアップ）する。実行時刻は、ユーザーから事前に設定された時刻である。なお、この時刻は、運用後も変更できる。

(4)
制御ソフトウェアは、定期的に又は領域Ｂ−１へのアクセスのたび、領域Ｂ−１の残容量が閾値以下か否か判定する。閾値は、初期設定値又はユーザインタフェースを通じて事前に設定された値である。
ここでのアクセスは、書き込み時も読み出し時も含む。メインサーバー３１１に蓄積される実データは、長年の運用により増加する。やがて、蓄積される実データは、メインサーバー３１１に用意したＲＡＩＤストレージ３１１Ｄの蓄積容量の上限に近づく。
制御ソフトウェアは、領域Ｂ−１の残容量が閾値以下になると、設定した残容量が得られるまで、超過量に相当するデータ量の実データを領域Ｃ−１に移動させる。例えば、クライアント端末７からのアクセス間隔が長いファイルから順番に移動する。また例えば、ファイルが領域Ｂ−１に置かれるとすぐに移動する。

(5)
制御ソフトウェアは、領域Ｃ−１への実データの移動と同時に、同じ実データを領域Ｃ−２に複製（バックアップ）する。すなわち、実データは、キャッシュサーバー３１３とテープライブラリ３１５に二重化される。
(6)
制御ソフトウェアは、領域Ｃ−１についても定期的に又は領域Ｃ−１へのアクセスのたび、領域Ｃ−１の残容量が閾値以下か否か判定する。制御ソフトウェアは、領域Ｃ−１の残容量が閾値以下になると、アクセス間隔が長いファイルから消去する。
この消去により、同領域Ｃ−２は、論理上、領域Ｄ−１に変わる。このように、領域Ｄ−１は積極的に作成されるものではなく、バックアップ領域である領域Ｃ−２が消去法的に領域Ｄ−１に変化する。

(7)
なお、領域Ｄ−１に対応するファイル（実データ）の使用状況は、ユーザーによって判断される。ユーザーが「使用しない」と判断した場合、該当するファイル（実データ）を含むテープメディアは、制御ソフトウェアを使用してテープライブラリ３１５から排出される。
排出されたテープメディアは、例えば外部の棚に移動させる。このように、テープライブラリ３１５から排出した時点で、テープメディアに保存されているファイルは、領域Ｅ−１に移行する。この移動は、物理的な移動により実行される。

(8)
次に、クライアント端末７からファイルへのアクセスがあった場合について説明する。アクセスされたファイルがアプリケーションサーバー５にある場合、該当するファイルはネットワーク１を経由して要求したクライアント端末７に転送する。
ここで、アプリケーションサーバー５にない場合、アプリケーションサーバー５はストレージシステム３の制御ソフトウェアにファイルの移動を命じる。
この際、該当するファイルがメインサーバー３１１上にあれば、該当するファイルをネットワーク１経由でアプリケーションサーバー５に移動する。なお、このファイルは、更にネットワーク１経由でクライアント端末７に転送される。
(9)
これに対し、アクセスされたファイルがキャッシュサーバー３１３上にある場合、制御ソフトウェアは、ファイル（実データ）を領域Ｃ−１から領域Ｂ−１へ移行する。かかる後、同ファイルを領域Ｂ−１からアプリケーションサーバー５に該当するファイルを転送する。

(10)また、アクセスされたファイルがテープライブラリ３１５上にある場合、制御ソフトウェアは、ファイル（実データ）を領域Ｄ−１から領域Ｂ−１へ移動する。かかる後、同ファイルを領域Ｂ−１からアプリケーションサーバー５へ該当するファイルを転送する。
(11)なお、アクセスされたファイルがオフライン管理されている場合、制御ソフトウェアは、外部棚に保管されているテープメディアをテープライブラリ３１５に装填するようにユーザーに促がす画面を作表示装置上に表示させる。
ユーザーが該当するテープメディアを外部棚からテープライブラリ３１５に装填すると、領域Ｅ−１として管理されていたテープメディアはＤ−１領域に移行する。この後、前述したように領域Ｂ−１にファイル（実データ）が移行される。

（ｂ−２）自動処理と外部制御との混在使用
図１１に、メインサーバー３１１に搭載された制御ソフトウェアとアプリケーションサーバー５に搭載された外部アプリケーションを混在使用する場合のファイルの移動経路を示す。
すなわち、図１１は、各領域間でファイル（実データ）を移動させるＡＰＩ（アプリケーションインターフェース）を、アプリケーションサーバー５上で動作するアプリケーションプログラムが制御する場合の例である。

なお、アプリケーションサーバー５からアクセスがあった場合には、ファイル（実データ）がどの領域に存在しても、まず領域Ｂ−１に移行される。
アプリケーションサーバー５からファイルの移行を管理する機能を使用すれば、以下のような使い方ができる。例えば、予め所定の日時に読み出しが予想されるファイル（実データ）がある場合、必要なファイルを事前に領域Ｂに移行させることができる。
また例えば、アプリケーションのバージョンが更新された場合、ほとんど使用されないと予想される旧バージョンのファイル（実データ）を下位層の領域に移行させるといった使い方ができる。
以下、個々のプロセスについて説明する。なお図中、実線は移動を表し、点線は冗長化（複製）を示す。

(1)
アプリケーションサーバー５がテープライブラリ３１５（領域Ａ−２）にファイルを複製する。
(2)
アプリケーションサーバー５が移動条件を満たすファイルを領域Ｂ−１に格納する。
(3)
制御ソフトウェアは、アプリケーションサーバー５から指定された日時に、定期的に領域Ｂ−１のデータを領域Ｂ−２に複製（バックアップ）する。実行時刻は、ユーザーから事前に設定された時刻である。なお、この時刻は、運用後もアプリケーションサーバー５上で変更できる。
(4)
アプリケーションサーバー５は、ＡＰＩを使用して、領域Ｂ−１の特定のファイル（実データ）を領域Ｃ−１に移行する。
(5)
制御ソフトウェアは、領域Ｃ−１への実データの移動と同時に、同じ実データを領域Ｃ−２に複製（コピー）する。すなわち、実データは、キャッシュサーバー３１３とテープライブラリ３１５に二重化される。

(6)
制御ソフトウェアは、領域Ｃ−１についても定期的に又は領域Ｃ−１へのアクセスのたび、領域Ｃ−１の残容量が閾値以下か否か判定する。制御ソフトウェアは、領域Ｃ−１の残容量が閾値以下になると、アクセス間隔が長いファイルから消去するこの消去により、同領域Ｃ−２は、論理上、領域Ｄ−１に変わる。
(7)
領域Ｄ−１のファイル（実データ）の使用状況は、ユーザーによって判断される。ユーザーが「使用しない」と判断した場合、該当するファイル（実データ）を含むテープメディアは、制御ソフトウェアを使用してテープライブラリ３１５から排出される。
排出されたテープメディアは、例えば外部の棚に移動させる。このように、テープライブラリ３１５から排出した時点で、テープメディアに保存されているファイルは、領域Ｅ−１に移行する。この移動は、物理的な移動により実行される。
(8)
アプリケーションサーバー５が、ストレージサーバー３内のファイルにアクセスした場合は、いずれも制御ソフトウェアによる自動移動の説明（(9) 〜(11)）と同じである。
すなわち、アクセスされたファイル（実データ）がどの階層区分に属する場合にも、メインサーバー３１１に複製された後、アプリケーションサーバー５に送出される。

（Ｄ）ストレージ領域の復旧動作
ここでは、ディスクメディアで構成される領域Ｂ−１及びＣ−１の一方又は両方が壊れた場合を考える。このデータの復旧のために冗長化が行なわれている。
図１２に、領域Ｂ−１が壊れた場合を示す。この場合、アプリケーションサーバー５からアクセスのあったファイル（実データ）は、領域Ｂ−１（ＲＡＩＤストレージ３１１Ｄ）から読み出すことができない。
制御ソフトウェアは、データーベースが保持するバックアップデータへのフルパス名を読み出してテープライブラリ３１５にアクセスする。かくして、所定のテープメディアからバックアップデータが読み出される。
ただし、テープメディアからの読み出しのため、一般には読み出し時間が長くなる。しかし、システムの運用を停止することなく対応できる。

このとき、制御ソフトウェアは、領域Ｂ−１に対応するＲＡＩＤストレージ３１１Ｄの交換をユーザーに通知する。この後、制御ソフトウェアは、ＲＡＩＤストレージ３１１Ｄの交換を検出すると、領域Ｂ−２の実データを領域Ｂ−１に複製（復元）する。これにより、故障前の状態が復旧される。
ここで、制御ソフトウェアは、ＲＡＩＤストレージ３１１Ｄが新たなものに交換されるまで、システムの運用を停止する運用手法もある。この他、制御ソフトウェアは、正常動作中のキャッシュサーバー３１３（領域Ｃ−１）を領域Ｂ−１とみなす運用手法もある。
ただし、この場合にはキャッシュサーバー３１３の信頼性に若干の問題があるため、キャッシュサーバー３１３への書き込みと同時にテープライブラリ３１５にバックアップする。
図１３に、領域Ｃ−１が壊れた場合を示す。この事象は、失われるデータ量の規模に違いがあるものの、領域Ｃ−１のファイルが領域Ｄ−１に移行する場合と同じである。従って、領域Ｃ−１が壊れた場合、領域Ｃ−２は論理的に領域Ｄ−１に切り替わる。
このように、論理的な領域変更だけでストレージサーバー３の運用は停止することなく継続される。

（Ｅ）実施例の効果
通常、ディスクストレージ上にはファイルシステムが存在する。このため、ファイルシステムの構築後、運用中にストレージ領域を拡張することは難しい。本実施例の場合、領域Ｂ−１が対応する。
そこで、本実施例では、領域Ｃ−１、Ｄ−１、Ｅ−１に記録したファイル（実データ）の識別子を領域Ｂ−１のファイルシステムにリンクさせて管理する。これにより、領域Ｃ−１、Ｄ−１、Ｅ−１の拡張や比率の変更を柔軟に行うことができる。
また、本実施例では、ストレージメディアを使用頻度に応じて複数の区分に分割し、それぞれを冗長化する。これにより、ストレージ領域のうち物理的な衝撃に弱い部分や使用頻度の高い部分に、最適なタイミングで最適なメディアにファイル（実データ）を冗長化できる。

因みに、使用頻度の高い領域は壊れる可能性が高い。また、使用頻度の高い領域は、ファイルが更新される度にデータを冗長化していては、パフォーマンスが出ない可能性がある。そこで、「非常によく使う領域」や「よく使う領域」は、定期的なバックアップを選択する。
一方、「たまに使う領域」は、区分の移動時に冗長化しても問題ない。このように本実施例では、使用頻度に応じて最適なタイミングを選択する。
また、本実施例では、使用頻度を基準にストレージを領域分割し、使用頻度に応じて最適な物理的特性を有するストレージデバイスを割り当てる。これにより、コストとパフォーマンスとの最適化を実現できる。

また、本実施例では、外部のアプリケーションプログラムに対して、ＡＰＩを公開することにより、各ファイルに対するアプリケーション側の意味付けを反映することができる。
例えば、制御ソフトウェアとしては同等であっても、アプリケーションから見ると、必要があるデータと必要がないデータとに分類できる。従って、ＡＰＩの公開により、アプリケーション側からの重要性を区分間移行に反映させることができる。
また、本実施例では、ストレージサーバー３側の制御ソフトウェアが、ネットワーク経由で接続されたアプリケーションサーバー５のファイルも含めて管理する。このため、アプリケーションサーバー５も含めた階層型のストレージシステムを構築できる。
結果として、管理者によるメンテナンス操作を必要としなくても、アプリケーションサーバー５からストレージサーバー３にファイルを自動的に移動できる。従って、長年の運用時にも、アプリケーションサーバー５のストレージ５Ａに適切な空容量を確保することができる。
勿論、アプリケーションサーバー５から自動的に移動されたファイルは、その使用頻度に応じた階調区分のストレージメディアで蓄積され、必要に応じて読み出すことができる。

（Ｆ）他の実施例
（ａ）前述の実施例では、ネットワーク上にアプリケーションサーバー５が１つ接続されている場合について説明した。しかし、複数台のアプリケーションサーバー５がネットワークに接続されていても良い。
この場合も、前述の実施例と同様、アプリケーションサーバー５の各ストレージメディアを最上位の階層区分として扱うことができる。図１４に、その概念構成を示す。図１４は、アプリケーションサーバー５が３つの場合である。もっとも、ストレージサーバー側の階層区分は前述した実施例と同じである。従って、ファイルがどのアプリケーションサーバー５の管理下にあるとしても同じ管理ポリシーに従い、ファイルの移動やバックアップを管理できる。

なお、他の管理手法を適用することもできる。図１５に、その概念構成を示す。図１５は、アプリケーションサーバー単位で論理的な階層区分を管理する場合について表している。勿論、ストレージサーバー３をアプリケーションサーバー５別に用意することもできるが、ここではストレージサーバー３が１台の場合について表している。
この場合、ストレージサーバー３の制御ソフトウェア（ファイル管理装置）は、ストレージサーバー３を構成する各ストレージメディアの領域を各アプリケーションサーバーに対応付けて管理する。領域の管理手法には、各ストレージメディアの記憶領域をアプリケーションサーバーに対応付けて論理分割しておく方法、記憶領域は全てのアプリケーションサーバーに共通であるが、アプリケーションサーバー別に容量指定しておく方法がある。後者の場合には、指定容量を超えないようにファイルの移動を管理する。
またこの場合、制御ソフトウェアの管理ポリシーは、アプリケーションサーバー別に定めることもできる。複数台のアプリケーションサーバー５を監視対象とする場合、その用途や目的に応じてファイルの使用頻度や保存期間が異なると考えられる。従って、アプリケーションサーバー別に管理ポリシーを設定することができれば、アプリケーションサーバー５に応じた管理を実現することができる。

（ｂ）前述の実施例では、アプリケーションサーバー５の直接の管理下にあるストレージ５Ａが１台の場合について説明した。しかし、アプリケーションサーバー５の直接の管理下にあるストレージ５Ａは複数台でも良い。ここで、複数台のストレージ５Ａは、ネットワーク１を経由してアプリケーションサーバー５と接続されていても良い。図１６に一例を示す。図１６は、アプリケーションサーバー５と３台のストレージ５Ａがネットワーク経由で接続される場合を示す。ここで、領域Ａ、Ａ’、Ａ”は、アプリケーションサーバー５からは仮想的に１つのストレージとして管理される。
図１６は、領域Ａ、Ａ’、Ａ”別にファイルが階層管理される場合を表している。ここで、領域Ａ、Ａ’、Ａ”は、物理的に独立したストレージ５Ａに関連付けられている。もっとも、領域Ａ、Ａ’、Ａ”は、アプリケーションサーバー５上で動作する個々のアプリケーションソフトウェアやプロジェクトに関連付けられていても良い。この場合は、アプリケーションソフトウェア単位やプロジェクト単位でファイルを管理できる。

また、図１７に示すシステム形態を考えることもできる。図１７は、ネットワーク経由で接続された単一のストレージ５Ａを３つの領域Ａ、Ａ’、Ａ”に論理分割する場合、又は３つの領域Ａ、Ａ’、Ａ”として容量管理する場合について表している。
この場合も、ストレージサーバー３の制御ソフトウェア（ファイル管理装置）は、ストレージサーバー３を構成する各ストレージメディアの領域を、最上階層の各領域Ａ、Ａ’、Ａ”に対応付けて管理する。
この場合も、制御ソフトウェアの管理ポリシーは、個々の領域Ａ、Ａ’、Ａ”別に定めることもできる。また、個々の領域Ａ、Ａ’、Ａ”が個々のアプリケーションソフトウェアやプロジェクトに関連付けられている場合、その用途や目的に応じてファイルの使用頻度や保存期間が異なると考えられる。従って、個々の領域Ａ、Ａ’、Ａ”別に管理ポリシーを設定することができれば、領域別の管理を徹底することができる。

（ｃ）前述の実施例では、アプリケーションサーバーからストレージシステムにファイルを完全に移動する際の移動条件については説明しなかったが、例えばプロジェクトが閉じたとき、大きなファイルだけ、データーベース以外のファイルなどの条件を満たすことを要求すれば良い。
（ｄ）前述の実施例には、発明の趣旨の範囲内で様々な変形例が考えられる。また、本明細書の記載に基づいて創作される各種の変形例及び応用例も考えられる。

発明に係るファイル管理技術は、各種用途に応じたデジタル資産を管理するのに応用できる。例えば、デジタル映像データの蓄積に使用できる。映像ビジネスに係わる全ての事業分野（家庭内システムも含む。）に適用できる。
また例えば、金融データの蓄積に使用できる。例えば帳票データ、伝票データ、金融取引データの蓄積に使用できる。
また例えば、ネットワーク経由で送受されるデータの蓄積に使用できる。例えば、電子メール、Ｗｅｂページ、通信記録の蓄積に使用できる。
また例えば、出版関連データの蓄積に使用できる。例えば版下データ、地図データその他のデジタルコンテンツの蓄積に使用できる。
また例えば、医療データの蓄積に使用できる。例えばレントゲン画像、ＭＲＩ（Magnetic resonance imaging ）画像、カルテデータ、予約データその他の蓄積に使用できる。
また例えば、各種団体・機関の文書の蓄積に使用できる。例えば行政機関、司法機関、立法機関その他の公的文書の蓄積に使用できる。また、社内文書の蓄積にも使用できる。なお個人文書の蓄積にも使用できる。
また例えば、製図データの蓄積にも使用できる。例えばＣＡＤ（Computer Aided Design）データ、ＣＡＭ（Computer Aided Manufacturing） データ、ＣＡＥ（Computer-Aided
Engineering ）データの蓄積にも使用できる。

従来型の管理手法を示す図である。 階層型の管理手法を示す図である。 管理ポリシーの実施例を示す図表である。 ネットワークシステムの機能構成例を示す図である。 ストレージサーバーの実施例を示す図である。 領域の定義を示す図表である。 ストレージシステムと各領域との対応関係を示す図である。 データの移動処理手順例を示すフローチャートである。 データの複製処理手順例を示すフローチャートである。 制御ソフトウェアによるデバイス区間の自動移行動作を示す図である。 アプリケーションサーバーとストレージサーバー（制御ソフトウェア）の協働によるデバイス区間の移行動作を示す図である。 使用頻度が２番目に高いストレージが故障した場合の復旧動作を示す図である。 使用頻度が３番目に高いストレージデバイスが故障した場合の復旧動作を示す図である。 アプリケーションサーバーが複数の場合の階層区分とその対応関係の例を示す図である。 アプリケーションサーバーが複数の場合の階層区分とその対応関係の例を示す図である。 アプリケーションサーバーの直接の管理下にある複数のストレージがネットワーク経由でアプリケーションサーバーと接続されている場合の階層区分とその対応関係の例を示す図である。 アプリケーションサーバーの直接の管理下にある１つのストレージがネットワーク経由でアプリケーションサーバーと接続されている場合において、ストレージ内の領域が複数の論理区分又は管理領域として管理されているときの階層区分とその対応関係の例を示す図である。

符号の説明

１ ネットワーク
３ ストレージサーバー
３１ ストレージシステム
３３ ファイル管理装置
３３Ａ 階層管理部
３３Ｂ 移動管理部
３３Ｃ 複製管理部
３１１ メインサーバー
３１３ キャッシュサーバー
３１５ テープライブラリ
５ アプリケーションサーバー
７ クライアント端末

Claims (12)

1. 物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムを、仮想的に単一のストレージとして管理するファイル管理装置であって、
   前記ストレージシステムを構成する各ストレージメディアと、ネットワーク経由で接続されたアプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する階層管理部と、
   予め定めた移動条件に従って、階層区分間でデータを移動する移動管理部と
   を有することを特徴とするファイル管理装置。
2. 物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムを、仮想的に単一のストレージとして管理するファイル管理装置であって、
   前記ストレージシステムを構成する各ストレージメディアと、ネットワーク経由で接続されたアプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する階層管理部と、
   予め定めた複製条件に従って、階層区分間でデータを複製する複製管理部と
   を有することを特徴とするファイル管理装置。
3. 請求項１又は２に記載のファイル管理装置において、
   前記ストレージシステムは、少なくとも論理的に３つの階層区分で構成され、
   その最上位の階層区分には、信頼性と高速アクセス性に優れるストレージメディアが対応し、
   ２番目の階層区分には、高速アクセス性と経済性に優れるストレージメディアが対応し、
   最下位の階層区分には、信頼性と大容量性に優れるストレージメディアが対応する
   ことを特徴とするファイル管理装置。
4. 請求項１又は２に記載のファイル管理装置において、
   前記アプリケーションサーバーのストレージメディアは、論理的な階層区分の最上位に位置し、
   前記ストレージシステムを構成する各ストレージメディアは、論理的な階層区分における前記アプリケーションサーバーのストレージメディアよりも下位の階層区分に位置する
   ことを特徴とするファイル管理装置。
5. 請求項１又は２に記載のファイル管理装置は、
   前記アプリケーションサーバーが複数台の場合、
   アプリケーションサーバー単位で前記論理的な階層区分を管理する
   ことを特徴とするファイル管理装置。
6. アプリケーションサーバーと、物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムとで構成されるネットワークシステムにおいて、
   前記ストレージシステムのファイル管理装置に、
   前記ストレージシステムを構成する各ストレージメディアと、前記アプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する階層管理部と、
   予め定めた移動条件に従って、階層区分間でデータを移動する移動管理部と
   を有することを特徴とするネットワークシステム。
7. アプリケーションサーバーと、物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムとで構成されるネットワークシステムにおいて、
   前記ストレージシステムのファイル管理装置に、
   前記ストレージシステムを構成する各ストレージメディアと、前記アプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する階層管理部と、
   予め定めた複製条件に従って、階層区分間で複製する複製管理部と
   を有することを特徴とするネットワークシステム。
8. 請求項６又は７に記載のネットワークシステムにおいて、
   前記アプリケーションサーバーが複数台の場合、
   前記ファイル管理装置は、アプリケーションサーバー単位で前記論理的な階層区分を管理する
   ことを特徴とするネットワークシステム。
9. 物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムを、仮想的に単一のストレージとして管理するファイル管理方法であって、
   前記ストレージシステムを構成する各ストレージメディアと、ネットワーク経由で接続されたアプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する処理と、
   予め定めた移動条件に従って、階層区分間でデータを移動する処理と
   を有することを特徴とするファイル管理方法。
10. 物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムを、仮想的に単一のストレージとして管理するファイル管理方法であって、
    前記ストレージシステムを構成する各ストレージメディアとネットワーク経由で接続されたアプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する処理と、
    予め定めた複製条件に従って、階層区分間でデータを複製する処理と
    を有することを特徴とするファイル管理方法。
11. 物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムを、仮想的に単一のストレージとして管理するコンピュータに、
    前記ストレージシステムを構成する各ストレージメディアと、ネットワーク経由で接続されたアプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する処理と、
    予め定めた移動条件に従って、階層区分間でデータを移動する処理と
    を実行させることを特徴とするプログラム。
12. 物理的特性を異にする複数種類のストレージメディアを組み合わせて構築したストレージシステムを、仮想的に単一のストレージとして管理するコンピュータに、
    前記ストレージシステムを構成する各ストレージメディアとネットワーク経由で接続されたアプリケーションサーバーのストレージメディアとを、論理的な階層区分で一元的に管理する処理と、
    予め定めた複製条件に従って、階層区分間でデータを複製する処理と
    を実行させることを特徴とするプログラム。
    

Images