JP2006079274A - ファイル管理装置、ネットワークシステム、ファイル管理方法及びプログラム - 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