(57)【要約】【課題】複数のファイルサーバにおけるファイルの保管に関し、ファイルの増加によるストレージコストの増大を抑える。また、既存ファイルサーバ上のすべてのファイルを一元管理する。【解決手段】  ネットワーク接続された複数のファイルサーバと利用者端末の間に、ファイルサーバ上のファイルを管理するためのプロキシサーバを設置。ファイルサーバ上のすべてのファイルについての管理テーブルを保持し、同一データ内容のファイルについては、同じ実体ファイルにリンクさせたエントリを登録し、管理テーブル上は論理的に別ファイルとして扱うことで、重複データ分のデータサイズ節約を実現する。また、ファイルアクセスログの一元管理を行い、アクセス頻度に応じて利用者へのファイル整理を促す。【選択図】図１
2009237979.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク接続された複数のファイルサーバを管理する情報処理装置であって、
異なるファイル名を有する複数のリンクファイルであって、それぞれが前記ファイルサーバに保存された一のファイル実体にアクセスするためのリンクファイルを管理するファイル管理手段と、
前記複数のリンクファイルのそれぞれに利用者端末からアクセスがあったとき、前記ファイルサーバから前記一のファイル実体を取得し、前記利用者端末に提供するファイルアクセス管理手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記ファイル管理手段は、前記ファイルサーバに保存された全てのファイルの登録情報として、前記リンクファイルとしての論理的アドレスと、各ファイルのファイル実体の格納場所を示す実アドレスと、各ファイルのファイル実体のハッシュ値と、各ファイルのファイル実体の重複数を管理することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記ファイルアクセス管理手段は、前記利用者端末からのファイル操作要求に対応して、ファイルオープン機能、読み込み機能、書き込み機能、保存機能、及び削除機能を提供することを特徴とする請求項１記載の情報処理装置。
【請求項４】
前記ファイルアクセス管理手段は、前記利用者端末からのファイル保存要求の際に、当該保存要求されたファイルのハッシュ値を取得し、当該ハッシュ値に基づいて同一ファイルの有無を確認し、
前記ファイル管理手段は、前記保存要求されたファイルと同一ファイルがあれば前記保存要求されたファイルの登録情報のみを管理し、前記保存要求されたファイルと同一ファイルがなければ、前記保存要求されたファイルの登録情報とファイルデータを管理することを特徴とする請求項１記載の情報処理装置。
【請求項５】
前記ファイル管理手段は、前記利用者端末からのファイルコピー要求の際に、コピー先ファイルに対応する新規ファイル情報の登録を行うことを特徴とする請求項１記載の情報処理装置。
【請求項６】
前記ファイル管理手段は、定期的にファイルの利用頻度を最終アクセス日時より監視し、所定利用回数よりも利用頻度の低いファイルについては、当該ファイルを作成した利用者の利用者端末に利用頻度が少ない旨を通知を行うことを特徴とする請求項１記載の情報処理装置。
【請求項７】
ネットワーク接続された複数のファイルサーバを管理する情報処理装置であって、
利用者端末からのファイル保存要求に対して、前記複数のファイルサーバの何れかに保存対象のファイルと同一ファイルが既に保存されているか否かを判定する手段と、
前記保存対象の同一ファイルが存在する場合には、別の利用者端末からの前記同一ファイルに対する第１のファイルリンクとは異なる第２のファイルリンクであって、前記同一ファイルへのファイルパスである第２のファイルリンクを管理する手段と、
を備えることを特徴とする情報処理装置。
【請求項８】
ネットワーク接続された複数のファイルサーバを管理する情報処理方法であって、
ファイル管理手段が、異なるファイル名を有する複数のリンクファイルであって、それぞれが前記ファイルサーバに保存された一のファイル実体にアクセスするためのリンクファイルを管理し、
ファイルアクセス管理手段が、前記複数のリンクファイルのそれぞれに利用者端末からアクセスがあったとき、前記ファイルサーバから前記一のファイル実体を取得し、前記利用者端末に提供する、ことを特徴とする情報処理方法。
【請求項９】
ネットワーク接続された複数のファイルサーバを管理する情報処理方法であって、
ファイル管理手段が、利用者端末からのファイル保存要求に対して、前記複数のファイルサーバの何れかに保存対象のファイルと同一ファイルが既に保存されているか否かを判定し、前記保存対象の同一ファイルが存在する場合には、別の利用者端末からの前記同一ファイルに対する第１のファイルリンクとは異なる第２のファイルリンクであって、前記同一ファイルへのファイルパスである第２のファイルリンクを管理することを特徴とする情報処理方法。
【請求項１０】
コンピュータに請求項８又は９に記載の情報処理方法を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及び方法、並びにプログラムに関し、例えば、複数のファイルサーバに保存されたデータの増加量を低減し、ファイル保管のためのストレージコストを削減する構成に関する。
【背景技術】
【０００２】
情報爆発時代の到来とともに、データセンターや企業の情報システム部門等、組織内や企業内における電子データを保管、管理している組織・部門にとって、データ量の増加に伴うストレージコストの増大は、大きな問題となりつつある。
【０００３】
電子データの増大を軽減させるための方式として、以前より様々な方式が考えられている。例えば、限られたストレージリソースに対して、効率的にデータを保存する方法として、ＺＩＰやＬＺＡ等のデータ圧縮技術を用いて圧縮保存する方法がある。なお、データ圧縮については、ＺＩＰやＬＺＡの他に、例えばＣＡＢ、ｇｚｉｐ、ＳｔｕｆｆＩｔ等、多くのアルゴリズムがある。
【０００４】
また、データセンター等ではデータのバックアップが必要となってくる。そのバックアップ方式としては、例えば特許文献１に記載されているように、対象データをすべてバックアップするフルバックアップに加え、そのフルバックアップからの差分データを保存する、差分バックアップ方式がある。
【０００５】
【特許文献１】特開２００６−９２５５３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、ストレージを複数人で共有している関係上、同一ファイルが同じストレージ内に複数保存して、データ重複している無駄が発生するケースがある。このようなファイルの重複排除については、上述のファイル圧縮方式や差分バックアップでは対応できない。
【０００７】
一方、重複ファイル排除機能を持ったストレージもある。しかし、わざわざ重複ファイル排除機能をファイルサーバに持たせると既存のファイルサーバが再利用できなくなるため、導入コストの面で考えた場合、必ずしも現実的な選択肢とは言えない。つまり、コストを考慮すると、既存のファイルサーバをそのまま再利用して重複ファイルの排除を可能とする方式が求められている。
【０００８】
本発明はこのような状況に鑑みてなされたものであり、既存のファイルサーバに変更を加えずにファイルサーバ内で重複ファイルの発生を排除することのできる構成を提供するものである。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明では、複数の既存のファイルサーバが並立する環境において、これらのファイルサーバ群を中継する位置にファイルサーバ管理用のプロキシサーバ（情報処理装置）を設置する。このプロキシサーバは、統括するファイルサーバに格納されたファイルの中で、重複するファイルがあった場合、利用者端末からは複数個のファイルに見せるが、保管されたファイルの実態は１つとすることで、重複ファイルの削減を図る。更に、定期的にファイルのアクセスログをチェックし、一定期間アクセスのないファイルについては、利用者にファイル整理を促すメールを出し、ファイル整理を促す、ないしは強制する仕組みを提供する。
【００１０】
即ち、本発明による情報処理装置は、異なるファイル名を有する複数のリンクファイルであって、それぞれがファイルサーバに保存された一のファイル（ファイルＦ００１という）実体にアクセスするためのリンクファイルを管理するファイル管理手段と、複数のリンクファイルのそれぞれに利用者端末からアクセスがあったとき、ファイルサーバから一のファイル（ファイルＦ００１）実体を取得し、利用者端末に提供するファイルアクセス管理手段と、を備える。
【００１１】
ファイル管理手段は、ファイルサーバに保存された全てのファイルの登録情報として、リンクファイルとしての論理的アドレスと、各ファイルのファイル実体の格納場所を示す実アドレスと、各ファイルのファイル実体のハッシュ値と、各ファイルのファイル実体の重複数を管理する。
【００１２】
ファイルアクセス管理手段は、利用者端末からのファイル操作要求に対応して、ファイルオープン機能、読み込み機能、書き込み機能、保存機能、及び削除機能を提供する。
【００１３】
また、ファイルアクセス管理手段は、利用者端末からのファイル保存要求の際に、当該保存要求されたファイルのハッシュ値を取得し、当該ハッシュ値に基づいて同一ファイルの有無を確認し、ファイル管理手段は、保存要求されたファイルと同一ファイルがあれば保存要求されたファイルの登録情報のみを管理し、保存要求されたファイルと同一ファイルがなければ、保存要求されたファイルの登録情報とファイルデータを管理する。
【００１４】
さらに、ファイル管理手段は、利用者端末からのファイルコピー要求の際に、コピー先ファイルに対応する新規ファイル情報の登録を行う。
【００１５】
他の形態による本発明の情報処理装置は、利用者端末からのファイル保存要求に対して、複数のファイルサーバの何れかに保存対象のファイルと同一ファイル（ファイルＦ００１）が既に保存されているか否かを判定する手段と、保存対象の同一ファイルが存在する場合には、別の利用者端末からの同一ファイルに対する第１のファイルリンク（ａａａ．ｔｘｔ）とは異なる第２のファイルリンクであって、同一ファイルへのファイルパスである第２のファイルリンク（ｂｂｂ．ｔｘｔ）を管理する手段と、を備える。
【００１６】
さらなる本発明の特徴は、以下本発明を実施するための最良の形態および添付図面によって明らかになるものである。
【発明の効果】
【００１７】
本発明によれば、既存のファイルサーバに変更を加えずにファイルサーバ内で重複ファイルの発生を排除することができる。よって、既存のファイルサーバを流用でき、システム構築におけるコストを低く抑えることができる。
【発明を実施するための最良の形態】
【００１８】
以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。
【００１９】
＜ファイル管理システムの構成＞
図１は、本発明の実施形態によるファイル管理（情報処理）システムの概略構成を示す図である。システムは利用者端末１０１と、複数台のファイルサーバ１０２と、ファイル管理プロキシ１０３とを備え、これらがネットワーク１０４で接続された構成となっている。
【００２０】
利用者端末１０１には、一般のアプリケーション１０５と、ファイルブラウザ１０６がインストールされている。ファイルブラウザ１０６は、利用者端末１０１のローカルディスクにアクセスする機能を有するとともに、ファイル管理プロキシ１０３にアクセスする機能も持つ。例えば、Ｗｉｎｄｏｗｓの場合、標準で組み込まれたエクスプローラにファイル管理プロキシ１０３へのアクセス機能を提供するシェルプラグインを組み合わせた、専用ファイルブラウザとして実装することが可能である。
【００２１】
接続された複数台のファイルサーバ１０２には、利用者端末からアクセスして利用するファイル群が格納されている。ただし、利用者端末１０１から各ファイルサーバ１０２には直接アクセスできないネットワーク構成となっている。唯一アクセスできるのは、ファイル管理プロキシ１０３である。このようなネットワーク構成は、例えばルータによる適切なルーティング設定で実現可能である。
【００２２】
ファイル管理プロキシ１０３には、これらのファイルサーバ１０２を統括管理するサービスであるファイル管理サービス１０７と、これらのファイルサーバに格納されたファイル群を管理するためのデータベースである管理ＤＢ１０８が稼動している。
【００２３】
＜ファイルサーバでのファイル管理＞
図２は、ファイル管理プロキシ１０３におけるファイルサーバ管理方式の概念図を示している。ファイル管理プロキシ１０３は、ａａａ．ｔｘｔ、ｂｂｂ．ｔｘｔ、ｃｃｃ．ｔｘｔ他、複数のファイルをディレクトリ構造で管理している。
【００２４】
図２では、ａａａ．ｔｘｔは￥ｄｏｃフォルダ直下、ｂｂｂ．ｔｘｔとｃｃｃ．ｔｘｔは￥ｄｏｃ￥ｔｍｐフォルダ直下に格納されているディレクトリ構成が示されている。また、ａａａ．ｔｘｔとｂｂｂ．ｔｘｔは全く同じバイナリの重複ファイルであり、その実体ファイルＦ００１はファイルサーバＡ２０２に格納されている。つまり、ａａａ．ｔｘｔ及びｂｂｂ．ｔｘｔは、ファイル名は異なるが、共にＦ００１という実体ファイルへのポインタとして作用している。ｃｃｃ．ｔｘｔの実体ファイルＦ００２は、ファイルサーバＢ２０３に格納されている。
【００２５】
ファイル管理プロキシ１０３が管理している論理的なディレクトリ構成では、ａａａ．ｔｘｔとｂｂｂ．ｔｘｔは別ファイルとして扱われるが、実質的にはファイルサーバＡ２０２に格納されたファイルＦ００１にリンクしている。このように重複ファイルを実質的には１つの実体ファイルに集約することで、複数のファイルサーバ全体で格納されたファイル群の格納サイズの削減を図ることができる。
【００２６】
＜ファイル管理テーブル＞
図３は、ファイル管理プロキシ１０３の管理ＤＢ１０８に格納されたファイル管理テーブルの構成を示す図である。ファイル管理テーブルのタプル（一行）は、ファイル管理サービス１０７が管理する論理的ファイル群の１ファイルに対応しており、６つの属性で構成されている。
【００２７】
仮想ファイルパス３０１は、ファイル管理サービス内で管理する論理的なファイルパスであり、ファイルサーバ群のすべてのファイルに対してユニークに設定される。
【００２８】
実ファイルパス３０２は、実際にファイルサーバ内に格納されているファイルの実ファイルパスである。ファイル管理サービスは、この実ファイルパスを利用して、ファイルサーバ上のファイルにアクセスすることができる。
【００２９】
重複カウント３０３は、当該ファイル以外に重複するファイルの総数を表す属性である。例えば、重複カウントが０の場合は重複ファイルが無いことを意味し、重複カウントがｎ（＞０）の場合は、当該ファイルを含め、重複するファイルの総数はｎ＋１であることを意味する。
【００３０】
ハッシュ値３０４は、ファイルのハッシュ値を示している。重複するファイルの場合は、ハッシュ値は同じ値になる。作成日時３０５はファイルの作成日時を示す属性であり、最終アクセス日時３０６は、最後にアクセスのあった日時を示す属性である。
【００３１】
＜オープンファイル管理テーブル＞
オープンファイル管理テーブルは、利用者端末１０１からファイルアクセスがあった場合、ファイルアクセスに必要なファイルＩＤ、及びファイルのオープン状況・条件を管理するためのテーブルである。図４は、ファイル管理サービスが保持するオープンファイル管理テーブルの構成を示す図である。
【００３２】
一般に、利用者端末とファイルサーバのＯＳがＷｉｎｄｏｗｓの場合、ファイルサーバへのアクセスにＣＩＦＳプロトコルが利用される。この場合、ファイルにアクセスするために、ファイルオープンすると、オープンされたファイルを特定するための識別子であるファイルＩＤが取得される。そのファイルＩＤを基に、ファイルの先頭からのオフセット値と読み取り、書き込みサイズを指定することで、利用者端末上のアプリケーションは、ファイルサーバ上のファイルの読み書きができる。本実施形態では、このＣＩＦＳプロトコルによるファイルサーバアクセスを前提し、以下にオープンファイル管理テーブルを定義するが、この仮定が本発明を限定するものではない。
【００３３】
図４に示されるように、オープンファイル管理テーブルでは、例えば、各タプルは６つの属性で構成されている。仮想ファイルパス４０１は、利用者端末１０１から見える論理的なファイルパスである。仮想ファイルＩＤ４０２は、利用者端末１０１上のアプリケーション１０５に返すファイルＩＤである。実ファイルＩＤ４０３は、ファイルサーバ１０２上のファイルを開いたときに、ファイルサーバ１０２より送られてくるファイルＩＤである。アクセスモード４０４は、ファイルを開いたときのアクセスモードを示す属性値であり、ＲＥＡＤ＿ＷＲＩＴＥ、ＲＥＡＤ＿ＯＮＬＹ、ＡＰＰＥＮＤ等の値をとる。共有モード４０５は、ファイルをオープン中に他のプロセスによるオープンを許可するか否かを定める属性である。ＳＨＡＲＥ＿ＲＥＡＤ、ＳＨＡＲＥ＿ＷＲＩＴＥ、ＮＯＮ＿ＳＨＡＲＥの属性値をとり、順に「共有読み込み許可」、「共有書き込み許可」、「共有禁止」を意味する。更新有無４０６は、現在ファイルが更新されたかどうかを意味するフラグであり、ＴＲＵＥだと「更新有り」、ＦＡＬＳＥだと「更新無し」を示す。
【００３４】
＜ファイル管理システムの動作＞
図５は、ファイルオープン時の処理を説明するためのフローチャートである。まず、利用者がファイルブラウザ１０６を使って、あるファイルを開こうとすると、ファイルブラウザ１０６は、当該ファイルオープン要求をファイル管理プロキシ１０３で稼動しているファイル管理サービス１０７に送信する（ステップＳ５０１）。ファイル管理サービス１０７は、この要求を受信後、要求内に含まれるファイルへの仮想ファイルパス４０１をキーとしてオープンファイル管理テーブル（図４参照）を検索し、対象ファイルのタプル値を取得する（ステップＳ５０２）。もし、タプル値が存在しない場合は、ファイルはまだオープンされておらず、ファイルオープンすることは可能である。また、すでにオープンされていた場合でも、共有モードの属性値がＳＨＡＲＥ＿ＲＥＡＤやＳＨＡＲＥ＿ＷＲＩＴＥなど、共有オープンできる値となっていた場合も、ファイルオープンすることが可能である。ファイル管理サービス１０７は、このように対象ファイルがオープン可能かどうかをチェックする（ステップＳ５０３）。
【００３５】
オープンできない場合は、ファイル管理サービス１０７は、ファイルオープンエラーをファイルブラウザ１０６に返す（ステップＳ５０９）。オープンできる場合、ファイル管理サービス１０７は、仮想ファイルパス３０１をキーとして管理ＤＢ１０８にあるファイル管理テーブル（図３参照）を検索し、実ファイルパス３０２の取得を試みる（ステップＳ５０４）。
【００３６】
そして、ファイル管理サービス１０７は、この検索を実行し、対応するタプルが存在するか否かに基づいて実ファイルが存在するかどうかをチェックする（ステップＳ５０５）。実ファイルが存在しない場合、対応するタプルが存在せず、実ファイルパスは取得できない。その場合、ファイルオープンエラーをファイルブラウザに返して処理を終了する（ステップＳ５０６）。
【００３７】
ステップＳ５０５で実ファイルが存在すると判断された場合、ファイル管理サービス１０７は、取得した実ファイルパス３０２を基に、ファイルサーバ１０２上のファイルをオープンする（ステップＳ５０７）。そして、ファイル管理サービス１０７は、オープンしたファイルの実ファイルＩＤ４０３と、ファイル管理プロキシ１０３で保持している仮想ディレクトリに対応した管理用のファイルＩＤである仮想ファイルＩＤ４０２、アクセスモード４０４や共有モード４０５、更新有無といった属性４０６をオープンファイル管理テーブル（図４参照）に登録し、仮想ファイルＩＤ４０２と共に、ファイルオープンの成功をファイルブラウザ１０６に返す（ステップＳ５０８）。なお、仮想ファイルＩＤ４０２については、ファイル管理サービス１０７が、オープンファイル管理テーブル内でユニークになるように任意に付与する。なお、オープンファイル管理テーブルに仮想ファイルＩＤの領域を設けず、登録されたタプル番号（行番号）をそのまま仮想ファイルＩＤとして管理するようにしても良い。
【００３８】
図６は、ファイルオープン後の読み込み時の処理を説明するためのフローチャートである。ファイルオープン後はアイル管理サービス１０７からアプリケーション１０５に仮想ファイルＩＤ４０２が渡される（ステップＳ６０１）。アプリケーション１０５は、仮想ファイルＩＤ４０２を引数としてファイルの読み込み要求を生成し、ファイル管理サービス１０７に送信する（ステップＳ６０２）。
【００３９】
読み込み要求を受け取ったファイル管理サービス１０７は、仮想ファイルＩＤ４０２に対応する実ファイルＩＤ４０３を利用し、ファイルサーバ１０２からファイルデータを読み込んでキャッシュする（ステップＳ６０３）。そして、ファイル管理サービス１０７は、随時、読み込み処理が発生したタイミングで、キャッシュデータをアプリケーション１０５に返す（ステップ６０４）。なお、キャッシュのアルゴリズムについては、利用者端末からの要求通りのまま、必要なデータだけをキャッシュする方式や、すべてのファイルをキャッシュする方式、要求領域の適当な近傍のファイル領域をキャッシュする方式など、様々な方式が考えられるが、本実施形態では特に規定しない。一般にプロキシサーバが行う既存のアルゴリズムを利用するものとする。以上のように、ファイル管理プロキシ１０３が仲介する形で、ファイル実体がアプリケーション１０５に引き渡される。
【００４０】
図７は、ファイルクローズ時の処理を説明するためのフローチャートである。アプリケーション１０５が、オープンしているファイルをクローズすると、クローズ要求がファイル管理サービス１０７に送信される（ステップＳ７０１）。クローズ要求を受信したファイル管理サービス１０７は、対応するファイルのキャッシュをフラッシュ（ファイルが更新されていたときにメモリ中の更新されたファイルをファイルサーバに格納）し、クローズ処理を行う（ステップＳ７０２）。最後に、ファイル管理サービス１０７はオープンファイル管理テーブル（図４参照）から、対応するエントリを削除する（ステップＳ７０３）。
【００４１】
図８は、ファイル保存時の処理を説明するためのフローチャートである。ファイルブラウザ１０６がファイル保存要求をファイル管理プロキシ１０３に送信すると（ステップＳ８０１）、ファイル管理サービス１０７は保存するファイルのハッシュを計算する（ステップＳ８０２）。
【００４２】
次に、ファイル管理サービス１０７は、計算したハッシュ値をキーとして、ファイル管理テーブル（図３参照）を検索し（ステップＳ８０３）、検索により同一ファイルが存在するかどうかをチェックする（ステップＳ８０４）。
【００４３】
同一ハッシュ値のファイルが存在する場合、ファイル管理サービス１０７は、ファイルサーバ１０２に保存された既存のファイルのパスを実ファイルパス属性として持つ新規エントリを生成して、ファイル管理テーブルに登録し、重複するすべてのファイルの重複カウント属性を１つ増やす（ステップＳ８０５）。存在しない場合、ファイル管理サービス１０７は、ファイル管理テーブルに新規登録するとともに、空き領域のあるファイルサーバ１０２にファイルを保存する（ステップＳ８０６）。
【００４４】
図９は、ファイルコピー時の処理を説明するためのフローチャートである。ファイルブラウザ１０６がファイル管理サービス１０７にファイルコピー要求を送信する（ステップＳ９０１）と、コピー要求を受信したファイル管理サービス１０７は、ファイルサーバ１０２に保存されたコピー対象のファイルの実ファイルパスを属性に持つ、新規エントリを作成して、ファイル管理テーブルに登録する。そして、ファイル管理サービス１０７は、重複するすべてのファイルの重複カウント属性を１つ増やす（ステップＳ９０２）。実際のファイルに関しては、コピー処理は実行されない。
【００４５】
図１０は、ファイル削除時の処理を説明するためのフローチャートである。ファイルブラウザ１０６がファイル管理サービス１０７にファイル削除要求を送信する（ステップＳ１００１）。削除要求を受信したファイル管理サービス１０７は、ファイル管理テーブルを検索し（ステップＳ１００２）、削除対象ファイルが重複しているかどうかをチェックする（ステップＳ１００３）。
【００４６】
重複ファイルの場合、ファイル管理サービス１０７は、削除すべきファイルに対応するファイル管理テーブルのエントリを削除し、他の重複ファイルの重複カウント属性を１つ減らす（ステップＳ１００４）。重複ファイルでない場合、ファイル管理サービス１０７は、削除すべきファイルに対応するファイル管理テーブルのエントリとファイルサーバ１０２上のファイルを削除する（ステップＳ１００５）。
【００４７】
図１１は、ファイルアクセス監査処理を説明するためのフローチャートである。ファイル管理サービス１０７は、定期的にファイル管理テーブルの最終アクセス日時属性をチェックしている（ステップＳ１１０１）。ここで、ファイル管理サービス１０７は、一定期間アクセスのないファイルが存在するかどうかをチェックする（ステップＳ１１０２）。存在する場合、ファイル管理サービス１０７は、そのファイル群をアクセス頻度が低いファイルとしてリストアップし、利用者に整理を促すメールを送信する（ステップＳ１１０３）。存在しなければ、そのまま処理は終了する。このように定期的に利用頻度のファイル整理を利用者に促すことで、定期的なデータの棚卸しを行うことができ、ファイルサーバの効率的な利用を実現することができる。
【００４８】
＜まとめ＞
以上に説明したように、本発明によれば、既存の複数のファイルサーバを一元的にプロキシで管理し、ファイルサーバ間のファイルの重複を排除し、かつ利用者からは透過的なファイルアクセスの仕組みを提供する。よって、ファイルサーバにおけるストレージ領域の節約ができるとともに、利用者からは複数のファイルサーバが１台のファイルサーバに見え、複数のファイルサーバにおけるファイルの位置透過性を実現することができる。なお、従来から利用されているデータ圧縮を併用すれば、更なるファイルサーバのストレージ領域の効率的な利用が可能となる。
【００４９】
また、本発明によれば、ファイルサーバの構成を変更する必要はないので、既存のファイルサーバをそのまま利用できる。よって、導入コストを抑えられる点が大きなメリットとなる。
【００５０】
さらに、セキュリティの面からも、プロキシでアクセスログを一括管理することができ、アクセス権制御機能を追加することも可能である。これにより、従来では個別のファイルサーバごとにアクセス権設定をしなければいけなかったが、プロキシで一括管理できることで、管理コストの削減も期待できる。
【００５１】
また、プロキシで集中管理するため、管理コストの低減が見込めるだけでなく、アクセスログ収集やファイルアクセス制御の一極集中化を行うことができ、セキュリティの向上にも繋がる。更に、既存のファイルサーバをそのまま利用できるため、低コストで導入することが可能である。
【００５２】
なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フロッピィ（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【００５３】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
【００５４】
また、実施の形態の機能を実現するソフトウェアのプログラムコードをネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
【図面の簡単な説明】
【００５５】
【図１】本発明の実施形態におけるファイル管理システムの概略構成を示す図である。
【図２】ファイル管理プロキシにおけるファイルサーバ管理方式の概念図である。
【図３】管理ＤＢに格納されたファイル管理テーブルの構成図である。
【図４】ファイル管理サービスが保持するオープンファイル管理テーブルの構成図である。
【図５】ファイルオープン時の処理を説明するためのフローチャートである。
【図６】ファイルオープン後の読み込み時の処理を説明するためのフローチャートである。
【図７】ファイルクローズ時の処理を説明するためのフローチャートである。
【図８】ファイル保存時の処理を説明するためのフローチャートである。
【図９】ファイルコピー時の処理を説明するためのフローチャートである。
【図１０】ファイル削除時の処理を説明するためのフローチャートである。
【図１１】ファイルアクセス監査処理を説明するためのフローチャートである。
【符号の説明】
【００５６】
１０１…利用者端末
１０２…ファイルサーバ
１０３…ファイル管理プロキシ
１０４…ネットワーク
１０５…アプリケーション
１０６…ファイルブラウザ
１０７…ファイル管理サービス
１０８…管理ＤＢ
３０１…仮想ファイルパス
３０２…実ファイルパス
３０３…重複カウント
３０４…ハッシュ値
３０５…作成日時
３０６…最終アクセス日時
４０１…仮想ファイルパス
４０２…仮想ファイルＩＤ
４０３…実ファイルＩＤ
４０４…アクセスモード
４０５…共有モード
４０６…更新有無
【図１】
2009237979.tif 000003
【図２】
2009237979.tif 000004
【図３】
2009237979.tif 000005
【図４】
2009237979.tif 000006
【図５】
2009237979.tif 000007
【図６】
2009237979.tif 000008
【図７】
2009237979.tif 000009
【図８】
2009237979.tif 000010
【図９】
2009237979.tif 000011
【図１０】
2009237979.tif 000012
【図１１】
2009237979.tif 000013