JP5046863B2 - 情報処理システム及びデータ管理方法 - Google Patents

情報処理システム及びデータ管理方法 Download PDF

Info

Publication number
JP5046863B2
JP5046863B2 JP2007285524A JP2007285524A JP5046863B2 JP 5046863 B2 JP5046863 B2 JP 5046863B2 JP 2007285524 A JP2007285524 A JP 2007285524A JP 2007285524 A JP2007285524 A JP 2007285524A JP 5046863 B2 JP5046863 B2 JP 5046863B2
Authority
JP
Japan
Prior art keywords
data
application
identifier
access
update
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007285524A
Other languages
English (en)
Other versions
JP2009116414A (ja
Inventor
昇司 児玉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2007285524A priority Critical patent/JP5046863B2/ja
Priority to US12/068,320 priority patent/US8473636B2/en
Publication of JP2009116414A publication Critical patent/JP2009116414A/ja
Application granted granted Critical
Publication of JP5046863B2 publication Critical patent/JP5046863B2/ja
Priority to US13/924,761 priority patent/US9609045B2/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H04L51/046—Interoperability with other network applications or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、異なる複数のアプリケーション装置が稼動するシステムにおいて、クライアント装置に対して全アプリケーション装置のデータに統一的なアクセス手段を提供する技術分野に関する。
異なる複数のアプリケーション装置のデータに統一的な手段でアクセスするための従来技術としては、例えば、エンタープライズ・サーチ（Enterprise Search）技術、ＳＲＢ（Storage Resource Broker）技術、ＧＮＳ（Global Name Space）技術、ＸＭＬ（Extensible Markup Language）技術、Ｇｍａｉｌファイル・システム（G mail File System）技術及びＷｅｂサービス（Web Services）技術がある。
エンタープライズ・サーチ技術は、システム内に存在するデータを、アプリケーション装置を横断して検索可能にする技術である。エンタープライズ・サーチ技術は、各アプリケーション装置からデータを参照し、データ内容に含まれるキーワードからインデックスを作成し、クライアント装置からのデータ検索要求に対して、検索に該当するデータの格納先をリストにして返す技術である。
この技術では、実際のデータにアクセスする場合は、そのデータを管理するアプリケーション装置が提供するインタフェースを利用するため、統一的なアクセス方法は提供していない。しかしながら、この技術では、データをテキストに変換し、テキスト化したデータを検索サーバ側にキャッシュしておくことで、クライアント装置はテキスト・データをテキスト表示ツール等など統一的な方法で参照することができる（非特許文献１参照）。
ＳＲＢ技術及びＧＮＳ技術は、地理的な分散したストレージ内のデータに統一的にアクセスする手段を提供する。ストレージ装置は、インターネットに接続しており、任意の場所からデータの検索やアクセスを実現する。ストレージ装置は、主にファイル・サーバを対象としている（非特許文献２及び非特許文献３参照）。
ＸＭＬ技術は、データ・フォーマットをＸＭＬで統一し、全アプリケーションがＸＭＬインタフェースを提供することで、クライアント装置が全アプリケーション装置に対して統一的なＸＭＬ形式でデータにアクセスすることを実現する（非特許文献４参照）。ＸＭＬ技術と同様にＷｅｂサービス技術は、アプリケーション装置がＨＴＴＰをベースとしたデータにアクセスするためのインタフェースを提供することで、クライアント装置がアプリケーション装置に統一的なＷｅｂサービスインタフェースでデータにアクセスすることを実現する（非特許文献５参照）。
Ｇｍａｉｌファイル・システム技術は、メール・サーバをファイル・システムとして利用するための技術である。メール・サーバ内のメッセージとして、ファイル・システムを管理するための管理情報やファイル自体を格納する（非特許文献６参照）。
エンタープライズ・サーチ技術http://www.fastsearch.com/thesolution.aspx?m=376 ＳＲＢ技術http://www.sdsc.edu/srb/Pappres/SRB-overview.ppt ＧＮＳ技術http://www.onstor.com/global_namespace.php ＸＭＬ技術http://www.w3.org/TR/xml11/ Ｗｅｂサービス技術http://www.w3.org/TR/ws-arch/ Ｇｍａｉｌファイル・システム技術http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html[非特許文献１〜６ 平成１９年１０月３１日ＵＲＬ検索]
しかしながら、従来技術であるエンタープライズ・サーチ技術やＧｍａｉｌファイル・システム技術では、変換後のテキスト・データへの参照は統一的な方法で行う事ができるが、データの更新が出来ないという問題がある。
また、従来技術であるＳＲＢ技術やＧＮＳ技術は、ファイル・サーバのようなデータ・アクセスのためのインタフェースが予め決まっているストレージ装置が対象であり、インタフェースが異なるアプリケーション装置を対象にはできないという問題がある。例えば、ネットワーク・ファイル・システム（Network File System :NFS）と呼ぶファイル共有プロトコルがデータ・アクセスのためのインタフェースとして使用されている。
従来技術であるＸＭＬ技術は、アプリケーション装置をＸＭＬに対応させる必要があり、既存のＸＭＬをサポートしていないアプリケーション装置には対応できないという問題がある。Ｗｅｂサービス技術についても、同様に、サポートしていないアプリケーション装置には対応することができない。
このように、従来技術では、異なる複数のアプリケーション装置のデータに対して、データを利用するクライアント装置に対して統一的な方法でデータを参照・更新することができず、クライアント装置のユーザにとって使い勝手が悪いという問題がある。
本発明は以上の点を考慮してなされたもので、ユーザの使い勝手を格段的に向上させ得る情報処理システム及びデータ管理方法を提案するものである。
上述の課題を解決するために本発明においては、所定のフォーマットで記録される第１のデータをストレージ装置のボリュームにおいて管理する第１のアプリケーション装置と、前記第１のデータとは異なるフォーマットで記録される第２のデータを前記ストレージ装置の前記ボリュームにおいて管理する第２のアプリケーション装置と、前記第１のデータ及び前記第２のデータにアクセスするサーバ装置と、前記サーバ装置にアクセスして、前記第１のデータ及び前記第２のデータを使用するクライアント装置とを備え、前記サーバ装置は、前記第１のデータ及び前記第２のデータのそれぞれに固有の識別子を割り当てる割当て部と、前記識別子と前記識別子で識別される前記第１のデータ又は前記第２のデータにアクセスするためのアクセス方法との対応関係を管理する管理部と、前記管理部により管理される前記識別子を、前記クライアント装置に対して提示する提示部と、前記クライアント装置から前記識別子を指定して要求された前記第１のデータ又は前記第２のデータへのアクセス要求を、前記管理部により前記識別子に対応づけられた前記アクセス方法により、前記識別子に対応する前記第１のデータ又は前記第２のデータにアクセスするためのアクセス要求に変換する変換部と、前記変換部により変換された前記アクセス方法により、前記第１のデータ又は前記第２のデータへのアクセス要求を行って、アクセス結果を、前記クライアント装置に送信するデータアクセス部とを備える。
また、本発明においては、所定のフォーマットで記録される第１のデータをストレージ装置のボリュームにおいて管理する第１のアプリケーション装置と、前記第１のデータとは異なるフォーマットで記録される第２のデータを前記ストレージ装置の前記ボリュームにおいて管理する第２のアプリケーション装置と、前記第１のデータ及び前記第２のデータにアクセスするサーバ装置と、前記サーバ装置にアクセスして、前記第１のデータ及び前記第２のデータを使用するクライアント装置とを有する情報処理システムのデータアクセス方法であって、前記サーバ装置の割当て部が、前記第１のデータ及び前記第２のデータのそれぞれに固有の識別子を割り当てる第１のステップと、前記サーバ装置の管理部が、前記識別子と前記識別子で識別される前記第１のデータ又は前記第２のデータにアクセスするためのアクセス方法との対応関係を管理する第２のステップと、前記サーバ装置の提示部が、前記第２のステップにおいて管理した前記識別子を、前記クライアント装置に対して提示する第３のステップと、前記サーバ装置の変換部が、前記クライアント装置から前記識別子を指定して要求された前記第１のデータ又は前記第２のデータへのアクセス要求を、前記第２のステップにおいて前記識別子に対応づけた前記アクセス方法により、前記識別子に対応する前記第１のデータ又は前記第２のデータにアクセスするためのアクセス要求に変換する第４のステップと、前記サーバ装置のデータアクセス部が、前記第４のステップにおいて変換した前記アクセス方法により、前記第１のデータ又は前記第２のデータへのアクセス要求を行って、アクセス結果を、前記クライアント装置に送信する第５のステップとを備える。
さらに、本発明においては、所定のフォーマットで記録される第１のデータをストレージ装置のボリュームにおいて管理する第１のアプリケーション装置と、前記第１のデータとは異なるフォーマットで記録される第２のデータを前記ストレージ装置の前記ボリュームにおいて管理する第２のアプリケーション装置と、前記第１のデータ及び前記第２のデータが格納されるストレージ装置にアクセスするサーバ装置と、前記サーバ装置にアクセスして、前記第１のデータ及び前記第２のデータを使用するクライアント装置とを備え、前記サーバ装置は、前記第１のデータ及び前記第２のデータのコピーデータを作成するコピーデータ作成部と、前記第１のデータ及び前記第２のデータのコピーデータのそれぞれに固有の識別子を割り当てる割当て部と、前記識別子と前記識別子で識別される前記第１のデータ又は前記第２のデータのコピーデータのフォーマットを共有のフォーマットに変換するための方法との対応関係を管理する管理部と、前記管理部により管理される前記識別子を、前記クライアント装置に対して提示する提示部と、前記クライアント装置から前記識別子を指定して前記第１のデータ又は前記第２のデータのコピーデータを参照する参照要求が受信されたときに、指定された識別子に対応する前記第１のデータ又は前記第２のデータのコピーデータを前記ストレージ装置から読み出して、前記第１のデータ又は前記第２のデータのコピーデータのフォーマットを、前記管理部により前記識別子に対応づけられた前記共有のフォーマットに変換する変換部と、前記変換部により共有フォーマットに変換された前記第１のデータ又は前記第２のデータのコピーデータを、前記クライアント装置に送信するデータ送信部とを備える。
従って、クライアント装置のデータ利用者がアプリケーション装置毎のアクセス手段の違いを気にすることなく、統一的な方法で複数のアプリケーション装置をまたがってデータにアクセスすることができるため、データの再利用性を高めることができる。
本発明によれば、ユーザの使い勝手を格段的に向上させ得る情報処理システム及びデータ管理方法を実現できる。
以下、本発明の実施の形態を、図面を参照して詳細に説明する。
（１）実施例１
図１は、アプリ・データ仮想化システム１の構成について示している。アプリ・データ仮想化システム１は、１台以上のクライアント装置２、アプリ・データ（アプリケーション装置４が管理しているデータ、以下同じ）仮想化ファイル・サーバ３、１台以上のアプリケーション装置４（アプリとも呼ぶ）及び１台以上のストレージ装置５から構成される。
クライアント装置２は、アプリ・データ仮想化ファイル・サーバ３経由でアプリケーション・データ（アプリケーション装置４が管理しているデータ、以下同じ）に統一的な方法でデータのアクセスを行うコンピュータであり、統一ファイル・システム・クライアントプログラム１１を有する。
図２に、クライアント装置２のハード構成を示す。クライアント装置２は、ＣＰＵ（Central Processing Unit）１２、メモリ１３、ＨＤＤ（Hard Disk Drive）１４、ネットワーク・インタフェース１５を内部構成要素として有し、それらが内部バス１６で接続されている。さらに、クライアント装置２には、ユーザ・インタフェースとして、ディスプレイ１７、キーボード１８及びマウス１９が接続されている。
クライアント装置２は、ネットワーク・インタフェース１５を介してネットワークに接続され、アプリ・データ仮想化ファイル・サーバ３と通信を行う。例えば、ネットワークは、イーサネット（登録商標）を使い、通信プロトコルとしてＴＣＰ／ＴＰ（Transmission Control Protocol/Internet Protocol）を利用することができる。なお、統一ファイル・システム・クライアントプログラム１１は、ＨＤＤ１４に格納されている。
アプリ・データ仮想化ファイル・サーバ３は、複数のアプリケーション・データを仮想化し、クライアント装置２に対して統一的なデータへのアクセス方法を提供するサーバであり、データ・ディスカバリプログラム２１、データ関連情報入手プログラム２２、統一ファイル・サーバプログラム２３、ストレージ制御プログラム２４及び変換プログラム２５を有する。また、アプリ・データ仮想化ファイル・サーバ３は、管理情報として、データ管理テーブル２６、アプリ登録・管理テーブル２７、アプリ用ＬＵ管理テーブル２８、データ関連情報テーブル２９及びインデックス３０を有する。
図３に、アプリ・データ仮想化ファイル・サーバ３のハード構成を示す。アプリ・データ仮想化ファイル・サーバ３は、ＣＰＵ３１、メモリ３２、ＨＤＤ３３、ネットワーク・インタフェース３４を内部構成要素として有し、それらが内部バス３５で接続されている。
アプリ・データ仮想化ファイル・サーバ３は、ネットワーク・インタフェース３４を介してネットワークに接続され、クライアント装置２、アプリケーション装置４及びストレージ装置５と通信を行う。
なお、データ・ディスカバリプログラム２１、データ関連情報入手プログラム２２、統一ファイル・サーバプログラム２３、ストレージ制御プログラム２４、変換プログラム２５、データ管理テーブル２６、アプリ登録・管理テーブル２７、アプリ用ＬＵ管理テーブル２８、データ関連情報テーブル２９及びインデックス３０は、ＨＤＤ３３に格納されている。
アプリケーション装置４は、アプリケーション・データを使って業務を行うサーバである。例えば、アプリケーション装置４には、メール・サーバや、ＷＥＢサーバ、ファイル・サーバ(Network Attached Storage :NAS)などがある。本特許では、各アプリケーション装置４の業務内容の詳細やその実現方式の詳細については説明しない。本特許を実現するに当たって、アプリケーション装置４は、データ・アクセスプログラム４１の実行し、データ・アクセス機能を提供する。このデータ・アクセス機能は、アプリ・データ仮想化ファイル・サーバ３に対して、アプリケーション装置４毎に特有な方法で、ネットワーク経由で、それぞれ所定のフォーマットで記録されているアプリ・データにアクセスさせるためのプログラムである。例えば、アプリケーション装置４は、メール・サーバの場合、ＩＭＡＰ４(Internet Message Access Protocol v4)プロトコルを使って、外部のコンピュータがメール・サーバ内のメールにアクセスすることができる。
アプリケーション装置４のハード構成は、そのアプリケーション装置４に依存するが、例えば、図３に示したアプリ・データ仮想化ファイル・サーバ３と同様のＰＣサーバ構成がある。
アプリケーション装置４は、ネットワーク・インタフェースを介してネットワークに接続し、アプリ・データ仮想化ファイル・サーバ３及びストレージ装置５と通信を行う。なお、データ・アクセスプログラム４１は、アプリケーション装置４のＨＤＤに格納されている。
図１には示していないが、アプリケーション装置４には、当該アプリケーション装置４を直接使うユーザやクライアント装置が存在する。アプリケーション装置４を直接使うユーザやクライアント装置は、アプリケーション・データを更新する。例えば、アプリケーション装置４を直接使うユーザやクライアント装置は、メール・サーバの場合、メーラーがクライアント装置側ソフトウェアに対応し、アプリケーション装置４と直接メールの読み書きを行うことで、アプリケーション・データの内容を更新する。
ストレージ装置５は、アプリケーション・データと、アプリ・データ仮想化ファイル・サーバ３の更新データをボリューム（Logical Unit :LU）５３、５４に格納する。ストレージ装置５は、データ・アクセスプログラム５１を実行し、ボリューム５３、５４内のデータにアクセスするためにデータ・アクセス機能を提供する。例えば、ストレージ装置５は、ＳＣＳＩ(Small Computer System Interface)や、ＮＦＳ(Network File System)などのデータ・アクセス用のプロトコルを使って、アプリ・データ仮想化ファイル・サーバ３及びアプリケーション装置４に対してデータへのアクセス手段を提供する。
また、ストレージ装置５は、ストレージ制御プログラム５２を実行し、当該ストレージ装置５の構成を変更したり、ボリューム５３、５４のコピーを取得したりするためのストレージ制御機能をアプリ・データ仮想化ファイル・サーバ３に提供する。アプリ・データ仮想化ファイル・サーバ３は、ストレージ制御プログラム２４を実行し、ストレージ装置５の構成情報参照や変更の要求、ボリューム５３、５４のコピー作成要求などをストレージ装置５に要求する。ストレージ制御機能は、要求内容に基づいて処理を行う。データ・アクセス機能や、ストレージ制御機能の実現方式は、既に公知の技術で実現できるため、本実施例では説明を省略する。
図４に、ストレージ装置５のハード構成を示す。ストレージ装置５は、ネットワーク・インタフェース５５、コントローラ５６、キャッシュメモリ５７、ディスク・インタフェース５８、ＨＤＤ５９から構成され、ＨＤＤ５９以外は内部バス６０で接続されている。ＨＤＤ５９は、ディスク・インタフェース５８に接続されている。
ストレージ装置５は、ネットワーク・インタフェース５５を介してネットワークに接続され、アプリ・データ仮想化ファイル・サーバ３及びアプリケーション装置４と通信を行う。なお、データ・アクセスプログラム５１及びストレージ制御プログラム５２は、アプリケーション装置４のＨＤＤ５９に格納されている。
図５に、データ管理テーブル２６の例を示す。データ管理テーブル２６は、アプリ・データ仮想化ファイル・サーバ３がディスカバリした全アプリケーション・データを管理するための管理情報である。データ管理テーブル２６は、仮想識別子２６Ａ、オリジナル格納位置２６Ｂ、オリジナル更新時刻２６Ｃ、アカウント情報２６Ｄ、コピー数２６Ｅ及び更新先格納位置２６Ｆから構成される。
仮想識別子２６Ａは、アプリ・データ仮想化ファイル・サーバ３が、後述する方法でアプリケーション・データをディスカバリした後に、データ各々にユニークに割り当てる識別子である。クライアント装置２は、この仮想識別子を指定してデータ・アクセスをアプリ・データ仮想化ファイル・サーバ３に要求する。
オリジナル格納位置２６Ｂは、特定した各々のデータのアクセス先を示す情報である。オリジナル格納位置２６Ｂは、アプリ・データ仮想化ファイル・サーバ３が、アプリケーション装置４内のデータにアクセスするときには、データを格納するアプリケーション装置４のＩＰアドレス２６Ｇ、アプリケーション装置４の種別であるアプリ種別２６Ｈ、そのアプリケーション装置４内でデータを識別するための識別子であるアプリ内識別子２６Ｉを指定する。ＩＰアドレス２６Ｇにより、アプリケーション装置４への通信先が分かり、アプリ種別２６Ｈによりデータ・アクセスのためにどのプロトコルやインタフェースを使うのかが分かり、アプリ内識別子２６Ｉによってアプリケーション装置４内のデータを特定する。例えば、アプリケーション装置４がメール・サーバの場合には、プロトコルはＩＭＡＰ４となり、アプリ内識別子２６ＩはＩＭＡＰ４が規定するＵＩＤ(Unique Identifier)となる。
オリジナル更新時刻２６Ｃは、アプリケーション・データがいつ更新されたかを示す情報である。オリジナル更新時刻２６Ｃは、アプリ・データ仮想化ファイル・サーバ３がアプリケーション・データをディスカバリする際に、前回のディスカバリ時からデータが更新されたかどうかを調べるために利用する。詳細は後述するが、クライアント装置２がアプリ・データ仮想化ファイル・サーバ３経由でライト更新不可のデータを更新した場合、更新データは、当該更新データを格納するボリューム５４に格納される。一方、アプリケーション装置４のユーザは、アプリ・データ仮想化ファイル・サーバ３を経由せずに、直接同データを更新する状況がある。この状況を検知するために、アプリ・データ仮想化ファイル・サーバ３は、オリジナル更新時刻２６Ｃを利用する。
アカウント情報２６Ｄは、そのデータにアクセスするためのアカウント名とパスワード、及びデータのアクセス権を示す情報である。詳細は後述するが、アプリ・データ仮想化ファイル・サーバ３は、クライアント装置２からデータへのアクセス要求があったとき、このアカウント情報２６Ｄを使って、クライアント装置２が該データにアクセスする権利があるかを判定し、権利があれば、アカウント情報２６Ｄに記載したアカウント名とパスワードを使ってデータへのアクセスを行う。
コピー数２６Ｅは、アプリケーション・データへの統一アクセスを実現する目的においては必要のない情報である。コピー数２６Ｅは、本発明のもう一つの目的である、データ間の依存関係情報を使って、クライアント装置２がデータにアクセスする際の効率を向上させるために利用する。
本実施例では、データの関係情報としてデータ間のコピー関係情報を例に説明する。ストレージ装置５がデータのコピー機能を使ってデータの複製を別のボリューム５３に作成したり、バックアップ・ソフトがデータのバックアップを別のボリューム５３に行うと、ストレージ装置５は、オリジナルのデータのコピーを作成する。データ間のコピー関係情報とは、どのデータとどのデータがコピー関係にあるかを示す情報である。さらに、データ管理テーブル２６で管理するコピー数とは、そのデータが複数回コピーされている場合、そのコピーの合計数を示す情報である。本実施例では、重要な情報ほどデータ・ロスが発生しないようコピー数が増えるため、データの重要度とコピー数には関連性があると仮定している。
アプリ・データ仮想化ファイル・サーバ３は、ストレージ装置５や、データをバックアップするためのバックアップ・サーバ（図示せず）からコピー関係情報を入手する。アプリ・データ仮想化ファイル・サーバ３は、データの検索時には、検索結果にデータを並べる順序をコピー数の高い順に行うことで、重要なデータが検索結果の先頭に並ぶ為、ユーザにとって重要なデータを見つけやすいというメリットが出てくる。
更新先格納位置２６Ｆには、更新不可能なデータを更新する場合に、更新データをアプリケーション・データとは別のボリューム５４に格納する。この際、アプリ・データ仮想化ファイル・サーバ３は、更新データの格納位置を管理するために更新先格納位置２６Ｆの情報を使う。
図６に、アプリ登録・管理テーブル２７の例を示す。アプリ登録・管理テーブル２７は、アプリ・データ仮想化ファイル・サーバ３が管理対象とするアプリケーション装置４のリストを管理することと、アプリケーション・データにアクセスするための方法を特定するために利用する。アプリ登録・管理テーブル２７は、アプリケーション装置４のＩＰアドレス２７Ａ、アプリ種別２７Ｂ、アカウント情報リスト２７Ｃ、更新可否２７Ｄ及び変換プログラム２７Ｅから構成される。
アプリ登録・管理テーブル２７の内容は、アプリ・データ仮想化ファイル・サーバ３の管理者が、予めシステム起動前に管理端末経由で設定する。仮想化するアプリケーション装置４の増減など、内容に変更が必要になった場合は、管理者は、アプリ登録・管理テーブル２７の内容を変更し、必要があればアプリ・データ仮想化ファイル・サーバ３への通知もしくは再起動を行う。
ＩＰアドレス２７Ａとアプリ種別２７Ｂは、アプリケーション装置４を特定するために利用する。
アカウント情報リスト２７Ｃは、アプリケーション・データを利用するユーザが複数存在し、かつアプリケーション・データがユーザ毎に分離していた場合に、アプリ・データ仮想化ファイル・サーバ３が全アプリケーション・データにアクセスするために必要なアカウント名とパスワードを示す情報のリストである。全アプリ・データに一つのアカウントでアクセスできるルート権限を持つアカウントがあれば、必要なアカウントは、ルート・アカウントのみになる。もし、全アプリ・データにアクセスするために複数のアカウントを使ってデータにアクセスしなければならない場合、複数のアカウント情報が必要になり、必要なアカウントは、リストとして管理する。例えば、メール・サーバの場合、ユーザ毎に個別のアカウント名を有し、ユーザ毎にアクセスできるメールは異なるため、クライアント装置４のユーザは、全メールにアクセスするためには全ユーザのアカウント名が必要になる。
更新可否２７Ｄは、アプリケーション・データをアプリ・データ仮想化ファイル・サーバ３経由で更新しても良いかどうかを示す情報である。更新可否２７Ｄは、更新しても良い場合は可となり、更新できない場合は不可となる。例えば、メール・サーバの場合、通常時は、ユーザがメーラー経由でメールの送受信を行っているため、第三者であるアプリ・データ仮想化ファイル・サーバ３がメールを書き換えてしまうとデータ内容の一貫性が保てず問題が発生する。そのため、更新可否２７Ｄは、不可となる。また別の例では、ＷＥＢサーバの場合、そもそもデータの更新手段が存在しないため、更新可否２７Ｄは、不可となる。ファイル・サーバ（ＮＡＳ）の場合、権限があれば誰がデータの更新を行っても運用上問題は発生せず、またデータを更新する手段を提供しているため、更新可否２７Ｄは、可となる。
変換プログラム情報２７Ｅは、統一アクセスを行う手段とアプリケーション装置４固有のデータ・アクセス手段を変換する変換プログラム２５の所在を示すために用いる。例えば、統一アクセス手段でデータの参照要求をクライアント装置２が行った場合、アプリ・データ仮想化ファイル・サーバ３は、要求データを有するアプリケーション装置４を特定し、そのアプリケーション装置４が提供するアクセス手段でデータ参照要求を、当該アプリケーション装置４に行うために、そのアプリケーション装置４に対応する変換プログラム２５を起動もしくはコールする。そして、アプリ・データ仮想化ファイル・サーバ３は、統一アクセス手段のデータ参照要求を、そのアプリケーション装置４固有のデータ参照要求に変換した上で、その変換したデータ参照要求をアプリケーション装置４に送信する。変換プログラム情報２７Ｅは、どの変換プログラム２５を使うのかを指定する。
変換プログラム２５は、統一アクセス手段とアプリ固有のアクセス手段の違いによって様々な実施例が考えられる。本実施例では、すべての統一アクセス手段とすべてのアプリ固有のアクセス手段の組み合わせすべてについて変換プログラム２５の実施例を記述することはできないため、統一アクセス手段がネットワーク・ファイル・システム（ＮＦＳ）、アプリ固有アクセス手段がＩＭＡＰ４の場合について簡単に説明する。
図７は、変換プログラム２５による変換の一例として、ＮＦＳとＩＭＡＰ４の変換の例の場合に使用するテーブルである変換テーブル６１を示している。この変換テーブル６１は、ＩＭＡＰ４をアプリ独自のアクセス手段６１Ａ、ＮＦＳを統一アクセス手段６１Ｂとして構成される。以下、両アクセス手段間の変換方式について説明する。
変換方式を検討する場合、大きく２点を決定する必要がある。一つがデータの対応関係であるデータ対応関係６１Ｃ、もう一つがコマンドの対応関係であるコマンド対応関係６１Ｄである。このため、変換テーブル６１は、データ対応関係６１Ｃ及びコマンド対応関係６１Ｄを有する。
データ対応関係６１Ｃは、アプリ種別６１Ｅ、データ単位６１Ｆ、データ名６１Ｇ、データ識別子６１Ｈ、属性情報６１Ｉ、アプリ拡張情報６１Ｊ、ユーザ名６１Ｋ、パスワード６１Ｌ、アクセス権６１Ｍに関する対応関係を決定する情報を有する。
アプリ種別６１Ｅは、各々のアクセス手段を区別する名称である。
データ単位６１Ｆは、クライアント装置２が一つのデータとして扱う単位である。この変換テーブル６１では、データ単位６１Ｆは、ＩＭＡＰ４が管理するメッセージを一つのデータとして扱い、それをＮＦＳ側の一つのファイルに対応付けている。例えば、ファイルの参照要求は、メッセージの参照要求として解釈する。
データ名６１Ｇは、ユーザが可読できるデータに付与する名称である。この変換テーブル６１では、データ名６１Ｇは、メッセージ内のサブジェクトをデータ名とし、それをＮＦＳ側のファイル名に対応付けている。例えば、ＮＦＳ側（クライアント装置２）でファイルのリスティングを行うと、メッセージのサブジェクト名のリストが出力される。
データ識別子６１Ｈは、データを識別するための情報である。この変換テーブル６１では、データ名６１Ｇは、メッセージを識別するためにＩＭＡＰがメッセージにＵＩＤを付与しているので、それを識別子とし、それをＮＦＳ側のデータへのパス名を識別子として使う。例えば、ＮＦＳ側でパス名を指定してデータ・アクセス要求があった場合、アプリ・データ仮想化ファイル・サーバ３は、対応するメッセージのＵＩＤを使ってメッセージにアクセスする。
属性情報６１Ｉは、データに付属する情報である。この変換テーブル６１では、属性情報６１Ｉは、メッセージの場合、メッセージのサイズが属性情報になり、これをＮＦＳ側のファイル・サイズに対応させる。例えば、ＮＦＳ側でファイルの属性情報を表示する場合、対応するメッセージの属性情報を表示する。ＮＦＳ側では、メッセージにはない作成時刻や最終アクセス時刻なども情報をクライアント装置２に提示する必要がある。クライアント装置２がそれらの情報提供を求めてきた場合は、常に無効な情報を返すか、データ管理テーブル２６にエントリを増やしてアプリ・データ仮想化ファイル・サーバ３内で情報を管理する。
アプリ拡張情報６１Ｊは、ＮＦＳ側にはないが、ＩＭＡＰ４側には存在する属性情報を指す。例えば、ＩＭＡＰ４側には存在する属性情報は、メッセージの未読フラグや返信済みフラグなどがある。これら情報は、クライアント装置２がＮＦＳ経由でデータにアクセスする際には不要な情報であり、基本的には考慮する必要がない。なお、本発明は、これに限らず、ＮＦＳをこれらアプリケーション装置４に特化した属性情報もクライアント装置２が参照・更新できるよう拡張しても良い。
ユーザ名６１Ｋは、データへアクセスする前の認証に使うアカウント名（アカウント情報）を指す。ＮＦＳ側のアカウント名と、ＩＭＡＰ４側のアカウント名が異なる場合、両者の対応関係を変換テーブル６１で管理する必要がある。例えば、ＮＦＳ側のアカウント名（User A）は、ＩＭＡＰ４側のアカウント名（Account X）に対応させる。この変換テーブル６１のユーザ名６１Ｋにより対応関係を管理することで、クライアント装置２のアカウント名（User A）を使ってデータへのアクセス要求があった場合、アプリ・データ仮想化ファイル・サーバ３は、ＩＭＡＰ４側のアカウント名（Account X）を使ってＩＭＡＰ４のメッセージにアクセスすることになる。
パスワード６１Ｌについても、ユーザ名と同様６１Ｋに、対応関係を変換テーブル６１で管理しておく。
アクセス権６１Ｍは、データへのアクセス権を示している。ＮＦＳ側では、データ毎に誰がどういう権限でデータにアクセスできるかを判定する必要がある。その際、アプリ・データ仮想化ファイル・サーバ３は、ＩＭＡＰ４側のメッセージへのアクセス権６１Ｍを参照し、判定を行う。例えば、ＩＭＡＰ４の場合、メッセージの所有者しかそのメッセージへのアクセス権がないため、ＮＦＳ経由で、メッセージの所有者ではないユーザからそのメッセージへのアクセス要求があった場合、アプリ・データ仮想化ファイル・サーバ３は、アクセスを拒否する処理になる。
コマンド対応関係６１Ｄは、ＮＦＳ側でサポートするデータ・アクセス時のコマンドがＩＭＡＰ４側ではどのコマンドに対応させるかを決定する。具体的に、コマンド対応関係６１Ｄは、ログイン６１Ｎ、リスティング６１Ｏ、属性参照６１Ｐ、属性更新６１Ｑ、作成６１Ｒ、リード６１Ｓ、ライト６１Ｔ、削除６１Ｕがコマンドとして存在しており、それぞれについてＮＦＳ側のコマンドにＩＭＡＰ４側のコマンドを対応させる。
ログイン６１Ｎは、ＩＭＡＰ４を利用する際にログインするためのコマンドである。ログイン６１Ｎは、ＮＦＳ側には存在しない。アプリ・データ仮想化ファイル・サーバ３は、ＩＭＡＰ４側のデータにアクセスする場合、ＩＭＡＰ４のログイン・コマンドとアカウント情報を使って、まずログインを行う。また、アプリ・データ仮想化ファイル・サーバ３は、データ・アクセスが完了した場合、ＩＭＡＰ４からログオフ処理を行う。以降、データ・アクセスの前後でログイン、ログオフ処理を行うことは、説明が冗長になるため省略する。
リスティング６１Ｏは、存在するデータのリストを得るためのコマンドである。リスティング６１Ｏは、ＮＦＳ側では、検索によってアクセスするデータを決定するユースケースが考えられるため、ルックアップ・コマンド（LOOKUP）が対応する。また、リスティング６１Ｏは、ＩＭＡＰ４側では、データのディスカバリをする際にメッセージのリスティングを行うため、サーチ・コマンド（SEARCH）が対応する。
属性参照６１Ｐは、ファイルの属性情報を参照するコマンドである。属性参照６１Ｐは、ＮＦＳ側ではゲットアトリビュート・コマンド（GETATTR）、ＩＭＡＰ４側ではストア・コマンド（STORE）が対応する。アプリ・データ仮想化ファイル・サーバ３がクライアント装置２からゲットアトリビュート・コマンド（GETATTR）で属性参照の要求を受けた場合、アプリ・データ仮想化ファイル・サーバ３は、ＩＭＡＰ４のストア・コマンド（STORE）を使ってメール・サーバ（アプリケーション装置４）からメッセージの属性情報を参照する。
属性更新６１Ｑは、ファイルの属性情報を更新するコマンドである。属性参照６１Ｐは、ＮＦＳ側ではセットアトリビュート・コマンド（SETATTR）が対応するが、ＩＭＡＰ４側では属性情報の更新コマンドが存在しない。そこで、アプリ・データ仮想化ファイル・サーバ３は、クライアント装置２からセットアトリビュート・コマンド（SETATTR）で属性更新の要求を受けた場合、メッセージを更新データ格納用のボリューム５４にコピーした後、そのコピーしたメッセージの属性情報を直接更新する。
作成６１Ｒは、ファイルを新規に作成するコマンドである。作成６１Ｒは、ＮＦＳ側ではクリエイト・コマンド（CREATE）が対応し、ＩＭＡＰ４側ではアペンド・コマンド（APPEND）が対応する。しかし、ＮＦＳ側は内容のない空のファイルを作成するのに対して、ＩＭＡＰ４側は内容が確定したメッセージを作成するため、同じ作成コマンドでも仕様が異なる。仕様が異なる場合、アプリ・データ仮想化ファイル・サーバ３は、ファイルの追加をメール・サーバ（アプリケーション装置４）に対して行うのではなく、更新データ格納用のボリューム５４に行う。ただし、統一インタフェース側（ＮＦＳ側）でファイルのクローズ・コマンドがあれば、作成コマンドの仕様が異なっていても、そのタイミングでファイルの内容が確定するため、確定ファイルをメッセージとしてメール・サーバ側に書き込む実装も考えられる。
リード６１Ｓは、ファイルを参照するコマンドである。リード６１Ｓは、ＮＦＳ側ではリード・コマンド（READ）が対応し、ＩＭＡＰ４側ではフェッチ・コマンド（FETCH）が対応する。アプリ・データ仮想化ファイル・サーバ３は、クライアント装置２からファイルの参照要求（リード・コマンド（READ））を受け取った場合、ＩＭＡＰ４のフェッチ・コマンド（FETCH）を使ってメッセージを読み、その結果をクライアント装置２に返す。
ライト６１Ｔは、ファイルを更新するコマンドである。ライト６１Ｔは、ＮＦＳ側ではライト・コマンド（WRITE）が対応するが、ＩＭＡＰ４側ではメッセージを更新するコマンドがない。そこで、アプリ・データ仮想化ファイル・サーバ３は、クライアント装置２からファイルの更新要求（ライト・コマンド（WRITE））を受け取った場合、対応するメッセージを一度更新データ格納用のボリューム５４にコピーした後に、そのメッセージを更新する処理を行う。
削除６１Ｕは、ファイルを削除するコマンドである。削除６１Ｕは、ＮＦＳ側ではリムーブ・コマンド（REMOVE）が対応し、ＩＭＡＰ４側ではエクスパンジ・コマンド（EXPUNGE）が対応する。アプリ・データ仮想化ファイル・サーバ３は、クライアント装置２からファイルの削除要求（リムーブ・コマンド（REMOVE））を受け取った場合、アプリ・データ仮想化ファイル・サーバ３は対応するメッセージを、エクスパンジ・コマンド（EXPUNGE）を使って削除する。
図８に、アプリ用ＬＵ管理テーブル２８の例を示す。アプリ用ＬＵ管理テーブル２８は、アプリ毎にストレージ装置５内のどのボリューム５３、５４にアプリ・データを格納しているかをアプリ・データ仮想化ファイル・サーバ３が参照するためのものである。アプリ用ＬＵ管理テーブル２８は、アプリケーション装置４のＩＰアドレス２８Ａと、アプリ種別２８Ｂでアプリケーション装置４を特定し、利用ＬＵＮ２８Ｃにアプリ・データが入ったＬＵＮが示されている。アプリ用ＬＵ管理テーブル２８は、管理者の操作により手動で入力するか、データを格納するボリューム５３を設定するストレージ管理サーバ（図示せず）がストレージ装置５を管理するサーバに問い合わせて、アプリケーション装置４とボリューム５３、５４の対応関係情報を解析することで自動的に作成しても良い。
図９に、データ関連情報テーブル２９の例を示す。データ関連情報テーブル２９は、アプリケーション装置４からは入手できないデータに関する情報を入手し、管理するためのテーブルである。アプリケーション装置４から入手できない情報としては、ストレージ装置５のコピー機能を使ったデータの複製関係、バックアップ管理ソフトによるデータのバックアップ情報、データが格納されているストレージ装置５の信頼性や性能に関する情報などがある。ストレージ装置５の信頼性に関する情報としては、アプリ・データが格納されているボリューム５３のＲＡＩＤレベルが例として挙げられる。ストレージ装置５の信頼性に関する情報としては、同ボリューム５３のドライブ種別がファイバチャネル（Fibre Channel）ドライブかＳＡＴＡ（Serial AT Attachment）ドライブかの違いなどが例として挙げられる。
対象とする関連情報によってデータ関連情報テーブル２９の内容は異なる。図９の例では、ストレージ装置５によるボリューム５３のコピーと、バックアップ管理サーバ（図示せず）のバックアップ管理ソフトによるアプリケーション・データのバックアップを対象にした。以下、この前提で説明を続ける。
データ関連情報テーブル２９は、データ管理ソフトのＩＰアドレス２９Ａ、データ管理ソフト種別２９Ｂ、データ関連情報入手方法２９Ｃ、コピー元ＬＵＮ２９Ｄ、コピー先ＬＵＮ２９Ｅから構成される。
データ管理ソフトとは、アプリケーション装置４以外にアプリケーション・データを管理するソフトウェアのことであり、ストレージ装置５上でボリューム５３のコピーを作成するプログラムや、バックアップ管理ソフトなどを指す。
アプリ・データ仮想化ファイル・サーバ３は、ＩＰアドレス２９Ａによってデータ管理ソフトのアクセス先が分かり、データ管理ソフト種別２９Ｂによりデータ管理ソフトを特定する。データ関連情報入手方法２９Ｃは、データ管理ソフトからデータ関連情報を参照するための方法について示している。例えば、アプリ・データ仮想化ファイル・サーバ３は、データ関連情報入手方法２９Ｃがストレージ制御プログラム２４の場合、アプリ・データ仮想化ファイル・サーバ３上で該プログラムを動作させることでストレージ装置５からデータ関連情報を取得することができる。コピー元ＬＵＮ２９Ｄとは、データコピーやバックアップの対象となるデータが入ったストレージ装置５内でのＬＵＮを指す。例えば、バックアップの場合、アプリケーション・データが格納されたボリューム５３がコピー元ＬＵＮ２９Ｄになる。コピー先ＬＵＮ２９Ｅとは、コピー先やバックアップ・データが格納されたストレージ装置５内のＬＵＮを指す。
図１０、図１１に、アプリ・データ仮想化ファイル・サーバ３のＣＰＵ３１がデータ・ディスカバリプログラム２１を実行することにより実現するデータ・ディスカバリ機能の処理フローについて説明する。このデータ・ディスカバリ機能により、データ管理テーブル２６が作成・更新され、インデックスが作成・更新される。
アプリ・データ仮想化ファイル・サーバ３は、例えば、１時間ごとに、アプリ登録・管理テーブル２７のエントリの先頭から順に、ＩＰアドレス２７Ａに対応する各アプリケーション装置４に対してステップＳＰ２以下の処理を行う（ステップＳＰ１）。
アプリ・データ仮想化ファイル・サーバ３は、アプリ登録・管理テーブル２７内のすべてのエントリについて処理を完了したか否かをチェックする（ステップＳＰ２）。アプリ・データ仮想化ファイル・サーバ３は、もし、アプリ登録・管理テーブル２７内のすべてのエントリについて処理を完了した場合（ステップＳＰ２：ＹＥＳ）、データ・ディスカバリ機能の処理を完了する。
アプリ・データ仮想化ファイル・サーバ３は、アプリ登録・管理テーブル２７内のすべてのエントリについて処理を完了していない場合（ステップＳＰ２：ＮＯ）、アプリ登録・管理テーブル２７のアカウント情報リスト２７Ｃを参照し、当該アカウント情報リスト２７Ｃの先頭から順に、アカウント情報を使ってステップＳＰ４以下の処理を行う（ステップＳＰ３）。
アプリ・データ仮想化ファイル・サーバ３は、アカウント情報リスト２７Ｃ内のすべてのアカウントで処理を終えたか否かをチェックする（ステップＳＰ４）。アプリ・データ仮想化ファイル・サーバ３は、もし、アカウント情報リスト２７Ｃ内のすべてのアカウントで処理を終えた場合（ステップＳＰ４：ＹＥＳ）、ステップＳＰ２に戻る。
アプリ・データ仮想化ファイル・サーバ３は、アカウント情報リスト２７Ｃ内のすべてのアカウントで処理を終えていない場合（ステップＳＰ４：ＮＯ）、ステップＳＰ３で選択したアカウント情報リスト２７Ｃのアカウント情報を使って、アプリケーション装置４にログインを行う（ステップＳＰ５）。
アプリ・データ仮想化ファイル・サーバ３は、アプリケーション装置４のリスティング６１Ｏ（例えば、サーチ・コマンド）を使って、利用しているアカウント（クライアント装置２）がアクセス可能な全データのリストを得る（ステップＳＰ６）。
アプリ・データ仮想化ファイル・サーバ３は、リスト内の各データについてステップＳＰ８以下の処理を行う（ステップＳＰ７）。
アプリ・データ仮想化ファイル・サーバ３は、リスト内の全てのデータについて処理が終わったか否かをチェックする（ステップＳＰ８）。アプリ・データ仮想化ファイル・サーバ３は、もし、リスト内の全てのデータについて処理が終わった場合（ステップＳＰ８：ＹＥＳ）、ステップＳＰ１５に進む。
アプリ・データ仮想化ファイル・サーバ３は、リスト内の全てのデータについて処理が終わっていない場合（ステップＳＰ８：ＮＯ）、データ管理テーブル２６のエントリを検索し、該データがエントリとして登録されているかどうかをチェックする（ステップＳＰ９）。チェックには、オリジナル格納位置の情報が一致するかで判断する。アプリ・データ仮想化ファイル・サーバ３は、もし、検索したデータがエントリとして登録されていない、すなわち、新規データであった場合（ステップＳＰ９：ＹＥＳ）、ステップＳＰ１０に進む。アプリ・データ仮想化ファイル・サーバ３は、もし、既に登録済みであった、すなわち、新規データでない場合（ステップＳＰ９：ＮＯ）、ステップＳＰ１１に進む。
アプリ・データ仮想化ファイル・サーバ３は、新規データであった場合（ステップＳＰ９：ＹＥＳ）、該データをデータ管理テーブル２６に新規登録する（ステップＳＰ１０）。その際、アプリ・データ仮想化ファイル・サーバ３は、オリジナル格納位置２６Ｂに、該データの格納位置情報を入れる。アプリ・データ仮想化ファイル・サーバ３は、該データの更新時刻をアプリケーション装置４の属性参照６１Ｐ（例えば、ストア・コマンド）を使って入手し、オリジナル更新時刻２６Ｃに入れる。アプリ・データ仮想化ファイル・サーバ３は、現在アプリケーション装置４にログインしているアカウント情報２６Ｄとする。また、アプリ・データ仮想化ファイル・サーバ３は、アプリの属性参照６１Ｐを使ってデータへのアクセス権情報を入手し、それもアカウント情報２６Ｄとする。アプリ・データ仮想化ファイル・サーバ３は、コピー数２６Ｅをゼロ、更新先格納位置２６Ｆをクリアする。その後、アプリ・データ仮想化ファイル・サーバ３は、ステップＳＰ１４に進む。
アプリ・データ仮想化ファイル・サーバ３は、登録済みデータの場合（ステップＳＰ９：ＮＯ）、そのデータが前回のディスカバリ時から更新されたかどうかをチェックする（ステップＳＰ１１）。アプリ・データ仮想化ファイル・サーバ３は、現時点でのデータの更新時刻を、アプリケーション装置４の属性参照６１Ｐを使って得る。アプリ・データ仮想化ファイル・サーバ３は、前回の更新時刻を、データ管理テーブル２６のオリジナル更新時刻２６Ｃを参照する。アプリ・データ仮想化ファイル・サーバ３は、両者を比較して、一致していなければ更新されたと判断する。アプリ・データ仮想化ファイル・サーバ３は、更新されていた場合（ステップＳＰ１２：ＹＥＳ）、ステップＳＰ１３に進む。アプリ・データ仮想化ファイル・サーバ３は、更新されていなかった場合（ステップＳＰ１２：ＮＯ）、ステップＳＰ８に戻る。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６の更新先格納位置２６Ｆを参照し、そのデータの更新データが更新データ用のボリューム５３に存在しているかどうかをチェックする（ステップＳＰ１２）。アプリ・データ仮想化ファイル・サーバ３は、更新データが更新データ用のボリューム５３に存在している場合（ステップＳＰ１３：ＹＥＳ）、ステップＳＰ１３に進む。アプリ・データ仮想化ファイル・サーバ３は、更新データが更新データ用のボリューム５３に存在していない場合（ステップＳＰ１３：ＮＯ）、データ管理テーブル２６のオリジナル更新時刻２６Ｃを最近の更新時刻で更新し、ステップＳＰ１４に進む。
アプリ・データ仮想化ファイル・サーバ３は、更新されたオリジナル・データを新規データとして、データ管理テーブル２６に登録する（ステップＳＰ１３）。登録処理内容は、ステップＳＰ１０と同じである。
アプリ・データ仮想化ファイル・サーバ３は、アプリケーション装置４のリード６１Ｓを使って該データの内容を参照し、検索用のインデックスを作成・更新する（ステップＳＰ１４）。その後、アプリ・データ仮想化ファイル・サーバ３は、ステップＳＰ８に戻る。インデックスのデータ構造やインデックスの作成方法は、従来の検索技術と同じであるため、説明を省略する。
アプリ・データ仮想化ファイル・サーバ３は、全データについて処理を終えた場合（ステップＳＰ８：ＹＥＳ）、データのリストとデータ管理テーブル２６のエントリを比較し、データ管理テーブル２６には存在するがデータ・リストには存在しない、削除されたデータがあるかをチェックする（ステップＳＰ１５）。アプリ・データ仮想化ファイル・サーバ３は、もし、削除されたデータがない場合（ステップＳＰ１５：ＮＯ）、ステップＳＰ４に戻る。アプリ・データ仮想化ファイル・サーバ３は、もし、削除されたデータがある場合（ステップＳＰ１５：ＹＥＳ）、ステップＳＰ１６に進む。
アプリ・データ仮想化ファイル・サーバ３は、削除されたデータに関し、データ管理テーブル２６の更新先格納位置２６Ｆを参照し、そのデータの更新データが更新データ用のボリューム５４に存在するかどうかをチェックする（ステップＳＰ１６）。アプリ・データ仮想化ファイル・サーバ３は、もし、更新データが更新データ用のボリューム５４に存在する場合（ステップＳＰ１５：ＹＥＳ）、データをそのまま残すため、ステップＳＰ４に戻る。アプリ・データ仮想化ファイル・サーバ３は、もし、更新データが更新データ用のボリューム５４に存在しない場合（ステップＳＰ１５：ＮＯ）、ステップＳＰ１７に進む。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６から削除されたデータのエントリを削除し（ステップＳＰ１６）、その後、ステップＳＰ４に戻る。
図１２に、アプリ・データ仮想化ファイル・サーバ３のＣＰＵ３１がデータ関連情報入手プログラム２２を実行することにより実現するデータ関連情報入手機能の処理フローについて説明する。このデータ関連情報入手機能により、データ関連情報テーブル２９が作成・更新される。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６の全エントリにつき、コピー数の欄をゼロでクリアされると（初期化されると）、データ関連情報テーブル２９にあるエントリの先頭から順番に、各データ管理ソフトに対して、ステップＳＰ２２以下の処理を実行する（ステップＳＰ２１）。
アプリ・データ仮想化ファイル・サーバ３は、全てのデータ管理ソフトについて処理が完了した場合（ステップＳＰ２２：ＹＥＳ）、ステップＳＰ２７に進む。
アプリ・データ仮想化ファイル・サーバ３は、全てのデータ管理ソフトについて処理が完了していない場合（ステップＳＰ２２：ＮＯ）、データ関連情報テーブル２９のデータ関連情報入手方法２９Ｃの手段を使って、データ管理ソフトからその管理ソフトが管理している全ボリューム５３、５４のリストを取得する（ステップＳＰ２３）。ここで、アプリ・データ仮想化ファイル・サーバ３は、データ管理ソフトがストレージ制御プログラム５２の場合、直接ボリューム５３、５４の情報を入手することができる。しかし、アプリ・データ仮想化ファイル・サーバ３は、データ管理ソフトがバックアップ管理ソフトの場合、通常データのバックアップを、ファイル・システムやアプリケーション装置４をバックアップ元として指定するため、それらデータが格納されるＬＵＮが特定できない。そこで、アプリ・データ仮想化ファイル・サーバ３は、バックアップの定義ファイルを元に、バックアップ対象データが格納されたＬＵＮをストレージ制御ソフトなどを使って決定する。この決定方法は、従来技術で実施可能である。
アプリ・データ仮想化ファイル・サーバ３は、得られたボリューム５３、５４のリストを元に、個々のボリューム５３、５４についてコピー関係情報を取得する（ステップＳＰ２４）。アプリ・データ仮想化ファイル・サーバ３は、データ管理ソフトがストレージ装置５の場合、コピー元ＬＵＮとコピー先ＬＵＮを得ることができる。アプリ・データ仮想化ファイル・サーバ３は、データ管理ソフトがバックアップ管理ソフトの場合、バックアップ先がテープ装置のときにはコピー先ＬＵＮを決定できないため、コピー元ＬＵＮだけ決定する。
アプリ・データ仮想化ファイル・サーバ３は、得られたコピー元ＬＵＮとコピー先ＬＵＮの関連情報をデータ関連情報テーブルに、コピー元ＬＵＮ２９Ｄとコピー先ＬＵＮ２９Ｅとして記録する（ステップＳＰ２５）。
アプリ・データ仮想化ファイル・サーバ３は、全てのボリューム５３、５４について関連情報を取得したか否かをチェックする（ステップＳＰ２６）。アプリ・データ仮想化ファイル・サーバ３は、全てのボリューム５３、５４についてコピー関係情報を取得した場合（ステップＳＰ２６：ＹＥＳ）、ステップＳＰ２２に戻る。アプリ・データ仮想化ファイル・サーバ３は、まだ、全てのボリューム５３、５４についてコピー関係情報を取得していない場合（ステップＳＰ２６：ＮＯ）、ステップＳＰ２４に戻る。
アプリ・データ仮想化ファイル・サーバ３は、データ関連情報テーブル２９内のコピー元ＬＵＮ２９Ｄとコピー先ＬＵＮ２９Ｅ、及びアプリ用ＬＵ管理テーブル２８内の利用ＬＵＮ２８Ｃを比較し、利用ＬＵＮ２８Ｃがコピー元ＬＵＮ２９Ｄもしくはコピー先ＬＵＮ２９Ｅのどちらかに一致しているかをチェックする（ステップＳＰ２７）。
アプリ・データ仮想化ファイル・サーバ３は、コピー元ＬＵＮ２９Ｄと一致していた場合（ステップＳＰ２６：ＹＥＳ）、データ管理テーブル２６の該アプリケーション装置４が持つ全データのコピー数２６Ｅを１加算すること等により、データ関連情報テーブル２９を更新する（ステップＳＰ２８）。例えば、利用ＬＵＮ２８Ｃがストレージ制御プログラム５２によってコピーされ、さらに、バックアップ管理ソフトによってバックアップされていた場合、コピー数は、２となる。
アプリ・データ仮想化ファイル・サーバ３は、全利用ＬＵＮ２８Ｃについてデータ関連情報テーブル２９との一致性をチェックした場合（ステップＳＰ２９：ＹＥＳ）、データ関連情報入手処理を完了する。アプリ・データ仮想化ファイル・サーバ３は、まだ、全利用ＬＵＮ２８Ｃについてデータ関連情報テーブル２９との一致性をチェックしていない場合（ステップＳＰ２９：ＮＯ）、ステップＳＰ２７に戻る。
図１３に、アプリ・データ仮想化ファイル・サーバ３のＣＰＵ３１が統一ファイル・サーバプログラム２３を実行することにより実現する統一ファイル・サーバ機能の処理フローを説明する。統一ファイル・サーバ機能では、クライアント装置２から統一アクセス手段でデータへのアクセス要求を受領し、その要求を下位のアプリケーション装置４に特化したアクセス手段に変換して転送することで、アクセス要求を処理する機能を実現する。
アプリ・データ仮想化ファイル・サーバ３は、クライアント装置２から統一アクセス手段（図７の例ではＮＦＳ）によってデータへのアクセス要求を受領する（ステップＳＰ３１）。アクセス要求のフォーマットは、アクセス内容によって異なるため、アクセス内容毎の処理の説明時に説明する。
アプリ・データ仮想化ファイル・サーバ３は、アクセス要求内のコマンド種別を参照し、コールする処理ルーチンを決定する（ステップＳＰ３２）。コマンド種別としては、検索、作成、ライト、リード、削除、属性参照、属性更新がある。アプリ・データ仮想化ファイル・サーバ３は、それぞれのコマンド種別に対応した処理ルーチン（ステップＳＰ３３〜ＳＰ３９）を呼び出して実行する。アプリ・データ仮想化ファイル・サーバ３は、コマンド毎の処理が完了した場合、統一ファイル・サーバ機能の処理を終える。
図１４に、クライアント装置２からのアクセス要求が、データの検索だった場合の要求フォーマットである検索要求７１を示す。検索要求７１では、アクセス要求内のコマンド種別を省略している。検索要求７１では、検索キーワード７１Ａが指定され、検索対象を絞りこみたいときには、検索するアプリケーション装置４を絞りこむためのアプリ７１Ｂがさらに指定される。アプリ・データ仮想化ファイル・サーバ３は、検索キーワードを含むデータのリストをクライアント装置２に返す。アプリ７１Ｂ指定時は、そのアプリケーション装置４が持つデータのみを検索対象とする。検索対象データの絞込みかたは、アプリケーション装置４だけに限らず、アプリケーション装置４独自の属性情報を指定したりする実施例も考えられる。
図１５に、検索処理であるステップＳＰ３３の処理フローを示す。本処理は、統一ファイル・サーバ機能のサブ・ルーチンとして呼び出される。
アプリ・データ仮想化ファイル・サーバ３は、検索要求７１内に、アプリ７１Ｂが指定されているかどうかをチェックする（ステップＳＰ４１）。アプリ・データ仮想化ファイル・サーバ３は、アプリ７１Ｂが指定されている場合（ステップＳＰ４１：ＹＥＳ）、ステップＳＰ４３に進む。アプリ・データ仮想化ファイル・サーバ３は、アプリ７１Ｂが指定されていない場合（ステップＳＰ４１：ＮＯ）、ステップＳＰ４２に進む。
アプリ・データ仮想化ファイル・サーバ３は、ユーザ（クライアント装置２）がアクセス権を持つデータ群を対象に、インデックスから検索キーワードにマッチするデータ群を検索する（ステップＳＰ４２）。ユーザがアクセス権を持つかどうかは、データ管理テーブル２６のアカウント情報２６Ｄを参照する。
アプリ・データ仮想化ファイル・サーバ３は、ユーザがアクセス権を持ち、かつ、指定されたアプリ７１Ｂのデータ群を対象に、インデックスから検索キーワードにマッチするデータ群を検索する（ステップＳＰ４３）。ユーザがアクセス権を持つかどうかは、データ管理テーブル２６のアカウント情報２６Ｄの欄を参照する。指定されたアプリ７１Ｂのデータかどうかは、データ管理テーブル２６のＩＰアドレス２６Ｇとアプリ種別２６Ｈを参照する。
アプリ・データ仮想化ファイル・サーバ３は、マッチした（検索された）データ群に対して、データ管理テーブル２６からデータに対応する仮想識別子２６Ａをリードする（ステップＳＰ４４）。アプリ・データ仮想化ファイル・サーバ３は、検索結果に仮想識別子２６Ａを含め、続くデータの参照・更新時にはクライアント装置２に仮想識別子２６Ａを指定させるためである。
アプリ・データ仮想化ファイル・サーバ３は、アプリ用ＬＵ管理テーブル２８とデータ関連情報テーブル２９を参照し、そのデータが格納されているボリューム５３、５４がコピー先のボリューム５３、５４かどうかをチェックし、もしコピー先のボリューム５３、５４であれば、検索結果に含めない（ステップＳＰ４５）。これにより、検索結果のリストが短くなり、ユーザは、必要なデータを探しやすくなる。
次に、アプリ・データ仮想化ファイル・サーバ３は、ステップＳＰ４５を実行した後の残った検索結果のデータを、図１６の並び替え結果８１に示すように、データ管理テーブル２６のコピー数２６Ｅが多い順に並べ替える（ステップＳＰ４６）。
アプリ・データ仮想化ファイル・サーバ３は、データ名とその仮想識別子２６Ａをセットにし、これを検索処理結果としてクライアント装置２に返す。その後、アプリ・データ仮想化ファイル・サーバ３は、検索処理であるステップＳＰ３３を完了する。
なお、ステップＳＰ４５とステップＳＰ４６の別の実施例として、図１６の並び替え結果８２に示すように、コピー関係にあるデータの親子関係を元に、検索処理結果でオリジナル・データをトップに、コピー・データをオリジナル・データから段下げして表示することも考えられる。これにより、ユーザは、データの親子関係を視覚的に理解しやすくなる。
さらに、ステップＳＰ４５とステップＳＰ４６の別の実施例として、図１６の並び替え結果８３に示すように、先に述べた信頼性や性能の情報を、検索処理結果やデータのリスティング結果に合わせて表示することも考えられる。これにより、ユーザは、データが格納されているボリューム５３、５４の信頼性や性能の情報を視覚的に理解しやすくなる。
図１７に、新規データ作成時の要求フォーマットである新規データ作成要求７２の例を示す。新規データ作成要求７２では、アプリケーション・データ内か更新データ用のボリューム５４内に新しいデータを作成する。新規データ作成要求７２は、ファイル名７２Ａが指定され、必要であれば新規データを作成するアプリケーション装置４であるアプリ７２Ｂが指定される。
図１８に、データの作成処理であるステップＳＰ３４の処理フローを示す。本処理は、統一ファイル・サーバ機能のサブ・ルーチンとして呼び出される。
アプリ・データ仮想化ファイル・サーバ３は、新規データ作成要求７２内に、アプリ７２Ｂが指定されているかどうかをチェックする（ステップＳＰ５１）。アプリ・データ仮想化ファイル・サーバ３は、アプリ７２Ｂが指定されている場合（ステップＳＰ５１：ＹＥＳ）、ステップＳＰ５３に進む。アプリ・データ仮想化ファイル・サーバ３は、アプリ７２Ｂが指定されていない場合（ステップＳＰ５１：ＮＯ）、ステップＳＰ５２に進む。
アプリ・データ仮想化ファイル・サーバ３は、更新データ用のボリューム５４に指定されたファイル名でデータを作成する（ステップＳＰ５２）。更新データ用のボリューム５４には、ファイル単位でデータが書き込めるようファイル・システムやＮＡＳを利用する。
アプリ・データ仮想化ファイル・サーバ３は、アプリ７２Ｂ指定がある場合（ステップＳＰ５１：ＹＥＳ）、アプリ登録・管理テーブル２７の更新可否２７Ｄを参照し、そのアプリケーション装置４がデータ更新可能かどうかを判定する（ステップＳＰ５３）。アプリ・データ仮想化ファイル・サーバ３は、更新不可のアプリケーション装置４である場合（ステップＳＰ５３：ＮＯ）、そのアプリケーション装置４内にはデータを作成できないので、ステップＳＰ５２に進む。
アプリ・データ仮想化ファイル・サーバ３は、更新可能なアプリケーション装置４の場合（ステップＳＰ５３：ＹＥＳ）、そのアプリケーション装置４のデータ作成コマンドを使ってデータを作成するために、新規データ作成要求７２を指定して変換プログラム２５を呼び出す。アプリ・データ仮想化ファイル・サーバ３は、変換プログラム２５内で、実際そのアプリケーション装置４用のデータ作成用コマンドを使って、アプリケーション装置４内にデータを作成する（ステップＳＰ５４）。
アプリ・データ仮想化ファイル・サーバ３は、作成したデータをデータ管理テーブル２６に新規登録する。その際、アプリ・データ仮想化ファイル・サーバ３は、新しい仮想識別子２６Ａをそのデータに割り当てる。アプリ・データ仮想化ファイル・サーバ３は、必要があれば、データ関連情報テーブル２９を使って、そのデータのコピー数を計算する。
アプリ・データ仮想化ファイル・サーバ３は、仮想識別子２６Ａをクライアント装置２に返す。この仮想識別子２６Ａは、クライアント装置２が継続して作成したファイルにデータを書き込む際に利用する。その後、アプリ・データ仮想化ファイル・サーバ３は、データの作成処理であるステップＳＰ３４を完了する。
図１９に、データ・ライト時の要求フォーマットであるライト要求７３の例を示す。データ・ライト時は、アプリ・データ自体を更新可能な場合はアプリ・データを更新し、アプリ・データが更新不可能な場合は、更新対象のデータを一旦更新データ用のボリューム５４にコピーし、そのコピーしたデータを更新する。ライト要求７３では、データ・ライトを行うデータを特定する仮想識別子７３Ａ、データを更新する位置（ファイルの先頭位置からのオフセット）７３Ｂ、更新データのデータ長７３Ｃ、及びデータ７３Ｄ自体が指定される。
図２０に、データ・ライト処理であるステップＳＰ３５の処理フローを示す。本処理は、統一ファイル・サーバ機能のサブ・ルーチンとして呼び出される。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のオリジナル格納位置２６ＢのＩＰアドレス２６Ｇとアプリ種別２６Ｈを参照し、指定された仮想識別子２６Ａに対応するアプリケーション装置４を特定する（ステップＳＰ６１）。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のアカウント情報２６Ｄを参照し、ライト要求７３をしたクライアント装置２にそのデータのアクセス権限があるかどうかをチェックする（ステップＳＰ６２）。アプリ・データ仮想化ファイル・サーバ３は、もし、ライト要求７３をしたクライアント装置２にそのデータのアクセス権限がない場合（ステップＳＰ６２：ＮＯ）、ステップＳＰ６３に進む。
アプリ・データ仮想化ファイル・サーバ３は、ライト要求７３をしたクライアント装置２がアプリ・データへのライト権限がないため、クライアント装置２にエラーを返して（ステップＳＰ６３）、その後、データ・ライト処理であるステップＳＰ３５を完了する。
アプリ・データ仮想化ファイル・サーバ３は、ライト要求７３をしたクライアント装置２にそのデータのアクセス権限がある場合（ステップＳＰ６２：ＹＥＳ）、アプリ登録・管理テーブル２７の更新可否２７Ｄを参照し、特定したデータのアプリケーション装置４が更新可能なアプリケーション装置４かどうかをチェックする（ステップＳＰ６４）。アプリ・データ仮想化ファイル・サーバ３は、更新可能なアプリケーション装置４の場合（ステップＳＰ６４：ＹＥＳ）、ステップＳＰ６５に進む。アプリ・データ仮想化ファイル・サーバ３は、更新不可のアプリケーション装置４である場合（ステップＳＰ６４：ＮＯ）、ステップＳＰ６６に進む。
アプリ・データ仮想化ファイル・サーバ３は、そのアプリケーション装置４のデータ・ライト用コマンドを使ってデータを更新するために、ライト要求７３を指定して変換プログラム２５を呼び出す。アプリ・データ仮想化ファイル・サーバ３は、変換プログラム２５内で、実際にそのアプリケーション装置４用のデータ・ライト用コマンドを使ってアプリケーション装置４内のデータを更新する（ステップＳＰ６５）。また、アプリ・データ仮想化ファイル・サーバ３は、更新データのフォーマットも、アプリケーション装置４のフォーマットに変換したのちに、アプリ・データをそのデータで更新する。
アプリ・データ仮想化ファイル・サーバ３は、更新不可のアプリケーション装置４である場合（ステップＳＰ６４：ＮＯ）、データ管理テーブル２６の更新先格納位置２６Ｆを参照し、既に更新データが存在するかどうかをチェックする（ステップＳＰ６６）。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在しない場合（ステップＳＰ６６：ＮＯ）、ステップＳＰ６７に進む。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在する場合（ステップＳＰ６６：ＹＥＳ）、ステップＳＰ６９に進む。
アプリ・データ仮想化ファイル・サーバ３は、アプリケーション装置４から更新対象のデータを更新データ用のボリューム５４にコピーするため、ライト要求７３に基づいて作成されるリード要求を指定して変換プログラム２５を呼び出す。アプリ・データ仮想化ファイル・サーバ３は、その結果リードしたデータを、データ・フォーマットを統一フォーマットに変換してから、更新データ用のボリューム５４に新規データとして書き込む（ステップＳＰ６７）。
アプリ・データ仮想化ファイル・サーバ３は、データ更新テーブル２６の更新先格納位置２６Ｆに、更新データ用のボリューム５４にコピーしたデータの情報を記録する（ステップＳＰ６８）。
アプリ・データ仮想化ファイル・サーバ３は、更新データ用のボリューム５４内の更新データを更新する（ステップＳＰ６９）。
アプリ・データ仮想化ファイル・サーバ３は、クライアント装置２に処理終了の旨を応答して（ステップＳＰ７０）、その後、データ・ライト処理であるステップＳＰ３５を完了する。
図２１に、データ・リード時の要求フォーマットであるリード要求７４の例を示す。データ・リード時は、アプリ・データ自体をリードする。ただし、アプリ・データが更新不可の場合で、すでにそのデータを更新していた場合は、最新データが更新データ用のボリューム５４に存在するため、そちらのデータをリードする。リード要求７４では、データ・リードを行うデータを特定する仮想識別子７４Ａ、データをリードする位置（ファイルの先頭位置からのオフセット）７４Ｂ、及びリードするデータ長７４Ｃが指定される。
図２２に、データ・リード処理であるステップＳＰ３６の処理フローを示す。本処理は、統一ファイル・サーバ機能のサブ・ルーチンとして呼び出される。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のオリジナル格納位置２６ＢのＩＰアドレス２６Ｇとアプリ種別２６Ｈを参照し、指定された仮想識別子２６Ａに対応するアプリケーション装置４を特定する（ステップＳＰ７１）。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のアカウント情報２６Ｄを参照し、リード要求７４をしたクライアント装置２にそのデータのアクセス権限があるかどうかをチェックする（ステップＳＰ７２）。アプリ・データ仮想化ファイル・サーバ３は、もし、リード要求７４をしたクライアント装置２にそのデータのアクセス権限がない場合（ステップＳＰ７２：ＮＯ）、ステップＳＰ７３に進む。
アプリ・データ仮想化ファイル・サーバ３は、リード要求７４をしたクライアント装置２がアプリ・データへのリード権限がないため、クライアント装置２にエラーを返して（ステップＳＰ７３）、その後、データ・リード処理であるステップＳＰ３６を完了する。
アプリ・データ仮想化ファイル・サーバ３は、リード要求７４をしたクライアント装置２にそのデータのアクセス権限がある場合（ステップＳＰ７２：ＹＥＳ）、データ管理テーブル２６の更新先格納位置２６Ｆを参照し、更新データが存在するかどうかをチェックする（ステップＳＰ７４）。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在しない場合（ステップＳＰ７４：ＮＯ）、ステップＳＰ７５に進む。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在する場合（ステップＳＰ７４：ＹＥＳ）、ステップＳＰ７７に進む。
アプリ・データ仮想化ファイル・サーバ３は、そのアプリケーション装置４のデータ・リード用コマンドを使ってデータをリードするために、リード要求７４を指定して変換プログラム２５を呼び出す。アプリ・データ仮想化ファイル・サーバ３は、変換プログラム２５内で、実際にそのアプリケーション装置４用のデータ・リード用コマンドを使ってアプリケーション装置４内のデータをリードする（ステップＳＰ７５）。
アプリ・データ仮想化ファイル・サーバ３は、そのアプリケーション装置４からリードしたデータのフォーマットを統一フォーマット（図７の例ではＮＦＳ）に変換する（ステップＳＰ７６）。
アプリ・データ仮想化ファイル・サーバ３は、更新データ用のボリューム５４からデータをリードする（ステップＳＰ７７）。
アプリ・データ仮想化ファイル・サーバ３は、リード・データをクライアント装置２に送信して（ステップＳＰ７８）、その後、データ・リード処理であるステップＳＰ３６を完了する。
図２３に、データ削除時の要求フォーマットある削除要求７５の例を示す。データ削除時は、アプリ・データ自体を削除する。ただし、更新データが存在する場合は、更新データの方を削除する。削除要求７５では、削除したデータの仮想識別子７５Ａを指定する。
図２４に、削除処理であるステップＳＰ３７の処理フローを示す。本処理は、統一ファイル・サーバ機能のサブ・ルーチンとして呼び出される。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のオリジナル格納位置２６ＢのＩＰアドレス２６Ｇとアプリ種別２６Ｈを参照し、指定された仮想識別子２６Ａに対応するアプリケーション装置４を特定する（ステップＳＰ８１）。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のアカウント情報２６Ｄを参照し、削除要求７５をしたクライアント装置２にそのデータのアクセス権限があるかどうかをチェックする（ステップＳＰ８２）。アプリ・データ仮想化ファイル・サーバ３は、もし、削除要求７５をしたクライアント装置２にそのデータのアクセス権限がない場合（ステップＳＰ８２：ＮＯ）、ステップＳＰ８３に進む。
アプリ・データ仮想化ファイル・サーバ３は、削除要求７５をしたクライアント装置２がアプリ・データへの削除権限がないため、クライアント装置２にエラーを返して（ステップＳＰ８３）、その後、削除処理であるステップＳＰ３７を完了する。
アプリ・データ仮想化ファイル・サーバ３は、削除要求７５をしたクライアント装置２にそのデータのアクセス権限がある場合（ステップＳＰ８２：ＹＥＳ）、データ管理テーブル２６の更新先格納位置２６Ｆを参照し、既に更新データが存在するかどうかをチェックする（ステップＳＰ８４）。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在しない場合（ステップＳＰ８４：ＮＯ）、ステップＳＰ８５に進む。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在する場合（ステップＳＰ８４：ＹＥＳ）、ステップＳＰ８７に進む。
アプリ・データ仮想化ファイル・サーバ３は、アプリ登録・管理テーブル２７の更新可否２７Ｄを参照し、特定したデータのアプリケーション装置４が削除可能（更新可能）なアプリケーション装置４かどうかをチェックする（ステップＳＰ８５）。アプリ・データ仮想化ファイル・サーバ３は、削除可能（更新可能）なアプリケーション装置４の場合（ステップＳＰ８５：ＹＥＳ）、ステップＳＰ８６に進む。アプリ・データ仮想化ファイル・サーバ３は、削除不可（更新不可）のアプリケーション装置４である場合（ステップＳＰ８５：ＮＯ）、ステップＳＰ８３に進む。なお、この場合、ステップＳＰ８３では、アプリ・データ仮想化ファイル・サーバ３は、アプリケーション装置４が削除不可のライアント装置２であるため、クライアント装置２にエラーを返す。
アプリ・データ仮想化ファイル・サーバ３は、そのアプリケーション装置４のデータ・削除用コマンドを使ってデータを削除するために、削除要求７５を指定して変換プログラム２５を呼び出す。アプリ・データ仮想化ファイル・サーバ３は、変換プログラム２５内で、実際にそのアプリケーション装置４用のデータ・削除用コマンドを使ってアプリケーション装置４内のデータを削除する（ステップＳＰ８６）。
アプリ・データ仮想化ファイル・サーバ３は、更新データ用のボリューム５４内からデータを削除する（ステップＳＰ８７）。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６から削除したデータのエントリを削除し、クライアント装置２へ応答して（ステップＳＰ８８）、その後、削除処理であるステップＳＰ３７を完了する。
図２５に、属性参照時の要求フォーマットある属性参照要求７６の例を示す。属性参照時は、アプリ・データの属性情報を参照する。ただし、更新データが存在する場合は、その属性情報を参照する。属性参照要求７６では、属性を参照したいデータの仮想識別子７６Ａを指定する。なお、参照する属性情報としては、例えば、図７に示す属性情報６１Ｉのファイル・サイズや、作成時刻等である。
図２６に、属性参照処理であるステップＳＰ３８の処理フローを示す。本処理は、統一ファイル・サーバ機能のサブ・ルーチンとして呼び出される。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のオリジナル格納位置２６ＢのＩＰアドレス２６Ｇとアプリ種別２６Ｈを参照し、指定された仮想識別子２６Ａに対応するアプリケーション装置４を特定する（ステップＳＰ９１）。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のアカウント情報２６Ｄを参照し、属性参照要求７６をしたクライアント装置２にそのデータのアクセス権限があるかどうかをチェックする（ステップＳＰ９２）。アプリ・データ仮想化ファイル・サーバ３は、もし、属性参照要求７６をしたクライアント装置２にそのデータのアクセス権限がない場合（ステップＳＰ９２：ＮＯ）、ステップＳＰ９３に進む。
アプリ・データ仮想化ファイル・サーバ３は、属性参照要求７６をしたクライアント装置２がアプリ・データの属性参照権限がないため、クライアント装置２にエラーを返して（ステップＳＰ９３）、その後、属性参照処理であるステップＳＰ３８を完了する。
アプリ・データ仮想化ファイル・サーバ３は、属性参照要求７６をしたクライアント装置２にそのデータのアクセス権限がある場合（ステップＳＰ９２：ＹＥＳ）、データ管理テーブル２６の更新先格納位置２６Ｆを参照し、更新データが存在するかどうかをチェックする（ステップＳＰ９４）。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在しない場合（ステップＳＰ９４：ＮＯ）、ステップＳＰ９５に進む。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在する場合（ステップＳＰ９４：ＹＥＳ）、ステップＳＰ９７に進む。
アプリ・データ仮想化ファイル・サーバ３は、そのアプリケーション装置４のデータ・リード用コマンドを使ってデータをリードするために、リード要求７６を指定して変換プログラム２５を呼び出す。アプリ・データ仮想化ファイル・サーバ３は、変換プログラム２５内で、実際にそのアプリケーション装置４用のデータ・リード用コマンドを使ってアプリケーション装置４内のデータをリードする（ステップＳＰ７５）。
アプリ・データ仮想化ファイル・サーバ３は、そのアプリケーション装置４の属性参照用コマンドを使ってデータの属性情報を参照するために、属性参照要求を指定して変換プログラム２５を呼び出す。アプリ・データ仮想化ファイル・サーバ３は、変換プログラム２５内で、実際にそのアプリケーション装置４用の属性参照用コマンドを使ってアプリケーション装置４内のデータの属性情報をリードする（ステップＳＰ９５）。
アプリ・データ仮想化ファイル・サーバ３は、そのアプリケーション装置４からリードしたデータの属性情報を統一フォーマット（図７の例ではＮＦＳ）に変換する（ステップＳＰ９６）。
アプリ・データ仮想化ファイル・サーバ３は、更新データ用のボリューム５４からデータの属性情報をリードする（ステップＳＰ９７）。
アプリ・データ仮想化ファイル・サーバ３は、リードしたデータの属性情報をクライアント装置２に送信して（ステップＳＰ９８）、その後、属性参照処理であるステップＳＰ３８を完了する。
図２７に、データの属性更新時の要求フォーマットである属性更新要求７７の例を示す。属性更新時は、アプリ・データ自体の属性情報を更新可能な場合はそれを更新し、更新不可能な場合は、対象のデータを一旦更新データ用のボリューム５４にコピーし、そのコピーしたデータの属性情報を更新する。属性更新要求７７では、データを特定する仮想識別子７７Ａ、及び属性情報７７Ｂを指定する。なお、更新する属性情報としては、例えば、図７に示す属性情報６１Ｉのタグ情報や、任意の属性情報等である。
図２８に、属性更新処理であるステップＳＰ３９の処理フローを示す。本処理は、統一ファイル・サーバ機能のサブ・ルーチンとして呼び出される。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のオリジナル格納位置２６ＢのＩＰアドレス２６Ｇとアプリ種別２６Ｈを参照し、指定された仮想識別子２６Ａに対応するアプリケーション装置４を特定する（ステップＳＰ１０１）。
アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６のアカウント情報２６Ｄを参照し、属性更新要求７７をしたクライアント装置２にそのデータのアクセス権限があるかどうかをチェックする（ステップＳＰ１０２）。アプリ・データ仮想化ファイル・サーバ３は、もし、属性更新要求７７をしたクライアント装置２にそのデータのアクセス権限がない場合（ステップＳＰ１０２：ＮＯ）、ステップＳＰ６３に進む。
アプリ・データ仮想化ファイル・サーバ３は、属性更新要求７７をしたクライアント装置２がアプリ・データの属性更新権限がないため、クライアント装置２にエラーを返して（ステップＳＰ１０３）、その後、属性更新処理であるステップＳＰ３９を完了する。
アプリ・データ仮想化ファイル・サーバ３は、属性更新要求７７をしたクライアント装置２にそのデータのアクセス権限がある場合（ステップＳＰ１０２：ＹＥＳ）、アプリ登録・管理テーブル２７の更新可否２７Ｄを参照し、特定したデータのアプリケーション装置４が更新可能なアプリケーション装置４かどうかをチェックする（ステップＳＰ１０４）。アプリ・データ仮想化ファイル・サーバ３は、更新可能なアプリケーション装置４の場合（ステップＳＰ１０４：ＹＥＳ）、ステップＳＰ１０５に進む。アプリ・データ仮想化ファイル・サーバ３は、更新不可のアプリケーション装置４である場合（ステップＳＰ１０４：ＮＯ）、ステップＳＰ１０７に進む。
アプリ・データ仮想化ファイル・サーバ３は、クライアント装置２が指定した属性情報を、そのアプリケーション装置４独自の属性情報のフォーマットに変換する（ステップＳＰ１０４）。
アプリ・データ仮想化ファイル・サーバ３は、そのアプリケーション装置４の属性更新用コマンドを使って属性情報を更新するために、属性更新要求７７を指定して変換プログラム２５を呼び出す。アプリ・データ仮想化ファイル・サーバ３は、変換プログラム２５内で、実際にそのアプリケーション装置４用の属性更新用コマンドを使ってアプリ・データの属性情報を更新する（ステップＳＰ１０６）。
アプリ・データ仮想化ファイル・サーバ３は、更新不可のアプリケーション装置４である場合（ステップＳＰ１０４：ＮＯ）、データ管理テーブル２６の更新先格納位置２６Ｆを参照し、既に更新データが存在するかどうかをチェックする（ステップＳＰ１０７）。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在しない場合（ステップＳＰ１０７：ＮＯ）、ステップＳＰ１０８に進む。アプリ・データ仮想化ファイル・サーバ３は、更新データが存在する場合（ステップＳＰ１０７：ＹＥＳ）、ステップＳＰ１１０に進む。
アプリ・データ仮想化ファイル・サーバ３は、アプリケーション装置４から属性更新対象のデータを更新データ用のボリューム５４にコピーするため、属性更新要求７７に基づいて作成されるリード要求を指定して変換プログラム２５を呼び出す。アプリ・データ仮想化ファイル・サーバ３は、その結果リードしたデータを、データ・フォーマットを統一フォーマットに変換してから、更新データ用のボリューム５４に新規データとして書き込む（ステップＳＰ１０８）。
アプリ・データ仮想化ファイル・サーバ３は、データ更新テーブル２６の更新先格納位置２６Ｆに、更新データ用のボリューム５４にコピーしたデータの情報を記録する（ステップＳＰ１０９）。
アプリ・データ仮想化ファイル・サーバ３は、更新データ用のボリューム５４内の更新データの属性情報をクライアント装置２が指定した属性情報で更新する（ステップＳＰ１１０）。
アプリ・データ仮想化ファイル・サーバ３は、クライアント装置２に処理終了の旨を応答して（ステップＳＰ１１１）、その後、属性更新処理であるステップＳＰ３９を完了する。
このようにして、アプリ・データ仮想化ファイル・システム１では、アプリ・データ仮想化ファイル・サーバ３が統一アクセス手段（図７の例ではＮＦＳ）とアプリケーション装置４毎のアクセス手段（図７の例ではＩＭＡＰ４）とを変換する変換プログラム２５を使い、アプリ登録・管理テーブル２７内にある全ＩＰアドレス２７に対応するアプリケーション装置４に対して、データ・ディスカバリ処理を行う。その結果、アプリ・データ仮想化ファイル・サーバ３は、全データを仮想識別子で区別するデータ管理テーブル２６を作成する。
アプリ・データ仮想化ファイル・サーバ３は、内部でクライアント装置２からのアクセス要求をアプリケーション装置４毎のアクセス要求に変換プログラム２５を使って変換することで、アクセス要求を処理する。アプリ・データ仮想化ファイル・サーバ３は、もし、アクセス要求がデータの更新であり、アプリケーション・データの更新ができない場合には、アプリ・データを一度更新データ用のボリューム５４に格納し、そのデータを更新する。その際、アプリ・データ仮想化ファイル・サーバ３は、データ管理テーブル２６で、更新されたデータがどこにあるかを管理する。
これにより、アプリ・データ仮想化ファイル・システム１では、クライアント装置２が、アプリ・データ仮想化ファイル・サーバ３が提供する統一アクセス手段により、異なるアプリケーション装置４であっても、全データにアクセスすることができ、クライアント装置２のユーザがアプリケーション装置４毎のアクセス手段の違いを気にすることなく、統一的な方法で複数のアプリケーション装置４をまたがってデータにアクセスすることができるため、データの再利用性を高めることができる。
また、アプリ・データ仮想化ファイル・サーバ３は、データ・ディスカバリ時には、データの関連情報をストレージ制御プログラム２４などを使って、ストレージ装置５から入手する。アプリ・データ仮想化ファイル・サーバ３は、その情報をデータ関連情報テーブル２９に記録し、それに基づいてデータ管理テーブル２６内の各データについて検索結果の並び順序を決めるためのスコアを計算し、データ管理テーブル２６に記録する。例えば、コピー回数を計算することで、コピー回数が多い方が重要なデータであると考えられるため、コピー回数を計算することで、検索順位を並び替える処理を行う。
これにより、アプリ・データ仮想化ファイル・システム１では、データ検索を行う場合に、データ間のコピー関係や、データが格納されているストレージ装置５の信頼性などによって検索結果をフィルタリングすることで、クライアント装置のデータ利用者が必要なデータを見つけやすくすることができる。
（２）実施例２
図１とは異なる構成の実施例として、図２９を説明する。
このアプリ・データ仮想化システム９１は、クライアント装置２、アプリ・データ仮想化ファイル・サーバ９２、アプリケーション装置４及びストレージ装置９３から構成される。
図１と比較して、アプリ・データ仮想化ファイル・サーバ９２は、アプリケーション装置４と直接データ・アクセスを行わない点が異なる。本実施例では、アプリケーション装置４経由でデータ・アクセスを行うのではなく、一旦アプリ・データをストレージ装置９３側でコピーし、そのコピー・データを仮想化の対象としている。
アプリ・データ仮想化ファイル・サーバ９２のプログラムは、データ・ディスカバリプログラム２１の代わりにデータ・ディスカバリプログラム９４がある点と、変換プログラム２５の代わりにフォーマット解析プログラム９５がある点を除いて、実施例１と同じである。ただし、アプリ・データ仮想化ファイル・サーバ９２は、各プログラムによる機能を実現する際に、図１ではアプリケーション装置４経由でデータにアクセスしていたが、本実施例ではコピー・データにアクセスする点が異なる。異なる箇所については後述する。
アプリ・データ仮想化ファイル・サーバ９２の管理データに関しては、データ管理テーブル９６の構造がデータ管理テーブル２６と一部違っている。具体的には、データ管理テーブル９６は、図３０に示したように、当該データ管理テーブルにおいてアプリ・データのオリジナル格納位置９６Ａを決定するために、アプリケーション装置４のＩＰアドレス２６Ｇではなく、アプリ・データのコピー・データが入ったボリューム９７のＬＵＮを指定する情報であるコピーＬＵ９６Ｂで構成される。
ストレージ装置９３には、アプリ・データのコピー・データを入れるボリューム９７がある。
図３１に、アプリ・データ仮想化ファイル・サーバ９２のＣＰＵ３１がデータ・ディスカバリプログラム９４を実行することにより実現するデータ・ディスカバリ機能の処理フローを示す。本実施例では、アプリ・データのコピー・データに対してデータのディスカバリを行う。コピー・データ利用中にも、オリジナルのアプリ・データは更新されるため、定期的にコピー・データを作成することで、データ管理テーブル９６を最新の状態に保つ。
アプリ・データ仮想化ファイル・サーバ９２は、例えば、一日に一回程度、定期的に以下を実行する（ステップＳＰ１２１）。
アプリ・データ仮想化ファイル・サーバ９２は、アプリ登録・管理テーブル２７にある各ＩＰアドレス２７Ａに対応するアプリケーション装置４に対してステップＳＰ１２３以下を実行する（ステップＳＰ１２２）。
アプリ・データ仮想化ファイル・サーバ９２は、アプリ登録・管理テーブル２７内のすべてのエントリについて処理を完了したか否かをチェックする（ステップＳＰ１２３）。アプリ・データ仮想化ファイル・サーバ３は、もし、アプリ登録・管理テーブル２７内のすべてのエントリについて処理を完了した場合（ステップＳＰ１２３：ＹＥＳ）、ステップＳＰ１２１に戻る。
アプリ・データ仮想化ファイル・サーバ９２は、アプリ登録・管理テーブル２７内のすべてのエントリについて処理を完了していない場合（ステップＳＰ１２３：ＮＯ）、ストレージ制御プログラム２４を使って、アプリ・データのコピー・データを作成する（ステップＳＰ１２４）。
アプリ・データ仮想化ファイル・サーバ９２は、コピー・データ内に格納されている全データのリストを得る（ステップＳＰ１２５）。このとき、アプリ・データ仮想化ファイル・サーバ３は、フォーマット解析プログラム９５を実行することにより、アプリ・データの格納フォーマットを解析できるものと仮定する。アプリ・データをアプリケーション装置４を介さずに読み書きする技術は、従来技術で実現可能である。
アプリ・データ仮想化ファイル・サーバ９２は、入手したデータに対して、図１１におけるステップＳＰ８以下の処理を行う。データ参照時は、アプリ・データの格納フォーマットを解析して直接リードする。ステップＳＰ８以下の処理は実施例１と同様である。
図１０、図１８、図２０、図２２、図２４、図２６、図２８については、フローチャートの枠が二重線になっているステップが、本実施例と実施例１で異なる部分である。差異は、コピー・データを解析してデータやデータの属性情報にアクセスするのか、アプリケーション装置４経由でデータやデータの属性情報にアクセスするのかである。
例えば、図２２のデータ・リード時では、ステップＳＰ７５が異なる。実施例１ではアプリケーション装置４のデータ・リード用コマンドを使ってアプリケーション装置４経由でデータをリードしたが、本実施例ではコピー・データを解析して要求されたデータをリードする。また、実施例１では変換プログラム２５を使って、統一アクセス手段からアプリケーション装置４固有のアクセス手段に変換していたが、本実施例ではフォーマット解析プログラム９５を使って、ボリューム９７に格納されているコピー・データのフォーマットを解析して、アプリケーション装置４固有のアクセス手段（フォーマット）からアプリケーション装置４のコピー・データを直接アクセスする統一アクセス手段（共有フォーマット）への変換を行っている。他の図も同様である。
このようにして、アプリ・データ仮想化システム９１では、アプリ・データのコピー・データを複数世代取得することで、コピー・データが変更されていた場合、ステップＳＰ１２４で更新した内容が失われることを防ぐことができる。その場合、アプリ・データ仮想化システム９１では、新しく作成したコピー・データで、古いコピー・データと内容が異なるデータを、新しいデータとしてデータ管理テーブル９６に登録する。
また、アプリ・データ仮想化システム９１では、アプリ・データ仮想化ファイル・サーバ９２が、アプリケーション装置４経由でデータ・アクセスを行うのではなく、一旦アプリ・データをストレージ装置９３側でコピーし、そのコピー・データを仮想化の対象とする。
これにより、アプリ・データ仮想化システム９１では、ボリューム９７に対してデータ・アクセスがなされるため、アプリケーション装置４のデータが万が一にも加工されてしまうような事態を未然かつ有効に防止すると共に、ボリューム５３へのアクセスがなくなるため、アプリケーション装置４を直接使うユーザやクライアント装置に対するアプリケーション装置４の性能を向上することができる。
本発明は、異なる複数のアプリケーション装置が稼動するシステムにおいて、クライアント装置に対して全アプリケーション装置のデータに統一的なアクセス手段を提供するシステムに利用することができる。
実施例１のアプリ・データ仮想化システムの概略的な構成を示すブロック図である。 クライアント装置のハード構成を示すブロック図である。 アプリ・データ仮想化ファイル・サーバのハード構成を示すブロック図である。 ストレージ装置のハード構成を示すブロック図である。 データ管理テーブルの説明に供する概念図である。 アプリ登録・管理テーブルの説明に供する概念図である。 ＮＦＳとＩＭＡＰ４の変換の例の説明に供する概念図である。 アプリ用ＬＵ管理テーブルの説明に供する概念図である。 データ関連情報テーブルの説明に供する概念図である。 データ・ディスカバリ機能の処理手順を示すフローチャートである。 データ・ディスカバリ機能の処理手順を示すフローチャートである。 データ関連情報入手機能の処理手順を示すフローチャートである。 統一ファイル・サーバ機能の処理手順を示すフローチャートである。 検索要求の要求フォーマットの説明に供する概念図である。 検索処理手順を示すフローチャートである。 データ関係情報に基づく検索結果の並び替えの例の説明に供する概念図である。 データ作成要求の要求フォーマットの説明に供する概念図である。 データ作成処理手順を示すフローチャートである。 データ・ライト要求の要求フォーマットの説明に供する概念図である。 データ・ライト処理手順を示すフローチャートである。 データ・リード要求の要求フォーマットの説明に供する概念図である。 データ・リード処理手順を示すフローチャートである。 データ削除要求の要求フォーマットの説明に供する概念図である。 データ削除処理手順を示すフローチャートである。 属性参照要求の要求フォーマットの説明に供する概念図である。 属性参照処理手順を示すフローチャートである。 属性更新要求の要求フォーマットの説明に供する概念図である。 属性更新処理手順を示すフローチャートである。 実施例２のアプリ・データ仮想化システムの概略的な構成を示すブロック図である。 実施例２のデータ管理テーブルの説明に供する概念図である。 実施例２のデータ・ディスカバリ機能の処理手順を示すフローチャートである。
符号の説明
１、９１……アプリ・データ仮想化システム、２……クライアント装置、３……アプリ・データ仮想化ファイル・サーバ、４……アプリケーション装置、５……ストレージ装置、１１……統一ファイル・システム・クライアントプログラム、２１、９４……データ・ディスカバリプログラム、２２……データ関連情報入手プログラム、２３……統一ファイル・サーバプログラム、２４……ストレージ制御プログラム、２５……変換プログラム、２６、９６……データ管理テーブル、２７……アプリ登録・管理テーブル、２８……アプリ用ＬＵ管理テーブル、２９……データ関連情報テーブル、３０……インデックス、３１……ＣＰＵ、４１……データ・アクセスプログラム、５１……データ・アクセスプログラム、５２……ストレージ制御プログラム、５３、５４、９７……ボリューム、６１……変換テーブル、７１……検索要求、７２……データ作成要求、７３……データ・ライト要求、７４……データ・リード要求、７５……削除要求、７６……属性参照要求、７７……属性更新要求

Claims (14)

  1. ストレージ装置と、
    所定のフォーマットで記録されて前記ストレージ装置に格納される複数の第１のデータの各々を第１の識別子を用いて管理する第１のアプリケーション装置と、
    前記第１のデータとは異なるフォーマットで記録されて前記ストレージ装置に格納される複数の第２のデータの各々を前記第１の識別子とは異なる第２の識別子を用いて管理する第２のアプリケーション装置と、
    複数の前記第１のデータ及び前記第２のデータにアクセスするサーバ装置と、
    前記サーバ装置にアクセスして、複数の前記第１のデータ及び前記第２のデータを使用するクライアント装置と
    を備え、
    前記サーバ装置は、
    所定期間ごとに、前記第１のアプリケーション装置及び前記第２のアプリケーション装置のそれぞれが管理する全ての前記第１のデータ及び前記第２のデータを抽出し、抽出した前記第１のデータ及び前記第２のデータについて、新規データ、更新データ及び削除データの有無をチェックし、前記第１のデータ及び前記第２のデータの各々に対して前記第１の識別子及び前記第２の識別子とは異なる第３の識別子を割り当てるとともに、前記第１のデータ及び前記第２のデータの各々に対してインデックスを作成又は更新するデータディスカバリ部と、
    前記第３の識別子と、前記第３の識別子で識別される前記第１のデータ又は前記第２のデータの前記第１の識別子又は前記第２の識別子と、前記第３の識別子で識別される前記第１のデータ又は前記第２のデータにアクセスするためのアクセス方法との対応関係を管理する管理部と、
    前記クライアント装置からの検索要求に応じて前記インデックスを用いて検索された１以上の前記第１のデータ若しくは前記第２のデータ又は前記クライアント装置からのデータ作成要求に応じて作成された前記第１のデータ若しくは前記第２のデータのそれぞれに割り当てられ、前記管理部により管理されている前記第３の識別子を、前記クライアント装置に対して提示する提示部と、
    前記クライアント装置から前記第３の識別子を指定して要求された前記第１のデータ又は前記第２のデータへのアクセス要求を、前記管理部により前記第３の識別子に対応づけられた前記アクセス方法及び前記第１の識別子又は前記第２の識別子により、前記第３の識別子に対応する前記第１のデータ又は前記第２のデータにアクセスするためのアクセス要求に変換する変換部と、
    前記変換部により変換された前記アクセス要求により、前記第１のデータ又は前記第２のデータへのアクセス要求を行って、アクセス結果を、前記クライアント装置に送信するデータアクセス部と
    を備えることを特徴とする情報処理システム。
  2. 前記サーバ装置は、
    前記クライアント装置から前記第３の識別子を指定して前記第１のデータ又は前記第２のデータを更新するアクセス要求である更新要求が受信されたときに、前記第１のデータ又は前記第２のデータの更新データを前記第１のデータ及び前記第２のデータが格納されるボリュームとは異なる更新用のボリュームに書き込むデータ書き込み部
    を備え、
    前記管理部は、
    前記データ書き込み部により前記更新データが書き込まれた後には、当該更新データにアクセス要求するように、前記第３の識別子と前記更新データとの対応関係を管理し、
    前記データアクセス部は、
    前記更新データに対応する前記第１のデータ又は前記第２のデータへの前記アクセス要求が受信されたときに、前記変換部により変換された前記アクセス要求により、対応する前記第１のデータ又は前記第２のデータの更新データへのアクセス要求を行う
    ことを特徴とする請求項１に記載の情報処理システム。
  3. 前記データ書き込み部は、
    前記第１のデータ又は前記第２のデータを管理する前記第１のアプリケーション装置又は前記第２のアプリケーション装置がデータ更新をすることができない場合に、前記第１のデータ又は前記第２のデータの更新データを前記更新用のボリュームに書き込む
    ことを特徴とする請求項２に記載の情報処理システム。
  4. 前記管理部は、
    前記第１のデータ又は前記第２のデータの作成要求が受信されたときに、受信された前記第１のデータ又は前記第２のデータと前記第３の識別子との対応関係を管理し、
    前記データアクセス部は、
    前記変換部により変換された前記アクセス要求により、前記受信された前記第１のデータ又は前記第２のデータの作成要求を行って、作成結果を、作成された前記第１のデータ又は前記第２のデータに対応する前記第３の識別子と共に、前記クライアント装置に送信する
    ことを特徴とする請求項１に記載の情報処理システム。
  5. 前記データアクセス部は、
    前記第１のデータ又は前記第２のデータの検索要求が受信されたときに、前記変換部により変換された前記アクセス要求により、対応する前記第１のデータ又は前記第２のデータの検索要求を行って、検索結果を、検索された前記第１のデータ又は前記第２のデータに対応する前記第３の識別子と共に、前記クライアント装置に送信する
    ことを特徴とする請求項１に記載の情報処理システム。
  6. 前記サーバ装置は、
    前記ストレージ装置から前記第１のデータ又は前記第２のデータのデータ関係情報を取得するデータ関係情報取得部を備え、
    前記データ関係情報は、
    複数の前記第１のデータ間又は複数の前記第２のデータ間のコピー関係であり、
    前記データアクセス部は、
    コピー関係にある前記第１のデータ又は前記第２のデータが存在するときには、オリジナルの前記第１のデータ又は前記第２のデータのみとなるように、前記検索結果を変更する
    ことを特徴とする請求項５に記載の情報処理システム。
  7. 前記データ関係情報は、
    前記第１のデータ又は前記第２のデータを格納する前記ボリュームの種別又は前記ボリュームのハードディスクドライブの種別であり、
    前記データアクセス部は、
    前記ボリュームの種別又は前記ハードディスクドライブの種別の信頼性や性能が高い順となるように、前記検索結果を変更する
    ことを特徴とする請求項５に記載の情報処理システム。
  8. 所定のフォーマットで記録されてストレージ装置に格納される複数の第１のデータの各々を第１の識別子を用いて管理する第１のアプリケーション装置と、前記第１のデータとは異なるフォーマットで記録されて前記ストレージ装置に格納される複数の第２のデータの各々を前記第１の識別子とは異なる第２の識別子を用いて管理する第２のアプリケーション装置と、複数の前記第１のデータ及び前記第２のデータにアクセスするサーバ装置と、前記サーバ装置にアクセスして、複数の前記第１のデータ及び前記第２のデータを使用するクライアント装置とを有する情報処理システムのデータアクセス方法であって、
    所定時間ごとに、前記第１のアプリケーション装置及び前記第２のアプリケーション装置のそれぞれが管理する全ての前記第１のデータ及び前記第２のデータを抽出し、抽出した前記第１のデータ及び前記第２のデータについて、新規データ、更新データ及び削除データの有無をチェックし、前記第１のデータ及び前記第２のデータの各々に対して前記第１の識別子及び前記第２の識別子とは異なる第３の識別子を割り当てるとともに、前記第１のデータ及び前記第２のデータの各々に対してインデックスを作成又は更新する第１のステップと、
    前記第３の識別子と、前記第３の識別子で識別される前記第１のデータ又は前記第２のデータの前記第１の識別子又は前記第２の識別子と、前記第３の識別子で識別される前記第１のデータ又は前記第２のデータにアクセスするためのアクセス方法との対応関係を管理する第２のステップと、
    前記クライアント装置からの検索要求に応じて前記インデックスを用いて検索された１以上の前記第１のデータ若しくは前記第２のデータ又は前記クライアント装置からのデータ作成要求に応じて作成された前記第１のデータ若しくは前記第２のデータのそれぞれに割り当てられている前記第３の識別子を、前記クライアント装置に対して提示する第３のステップと、
    前記クライアント装置から前記第３の識別子を指定して要求された前記第１のデータ又は前記第２のデータへのアクセス要求を、前記第３の識別子に対応づけられている前記アクセス方法及び前記第１の識別子又は前記第２の識別子により、前記第３の識別子に対応する前記第１のデータ又は前記第２のデータにアクセスするためのアクセス要求に変換する第４のステップと、
    前記第４のステップにおいて変換した前記アクセス要求により、前記第１のデータ又は前記第２のデータへのアクセス要求を行って、アクセス結果を、前記クライアント装置に送信する第５のステップと
    を備えることを特徴とするデータアクセス方法。
  9. 前記クライアント装置から前記第３の識別子を指定して前記第１のデータ又は前記第２のデータを更新する前記アクセス要求である更新要求を受信したときに、前記第１のデータ又は前記第２のデータの更新データを前記第１のデータ及び前記第２のデータが格納されるボリュームとは異なる更新用のボリュームに書き込むデータ書き込みステップ
    を備え、
    前記第２のステップでは、
    前記データ書き込みステップにおいて前記更新データを書き込んだ後には、当該更新データにアクセスするように、前記第３の識別子と前記更新データとの対応関係を管理し、
    前記第５のステップでは、
    前記更新データに対応する前記第１のデータ又は前記第２のデータへの前記アクセス要求を受信したときに、前記第４のステップにおいて変換した前記アクセス要求により、対応する前記第１のデータ又は前記第２のデータの更新データへのアクセス要求を行う
    ことを特徴とする請求項８に記載のデータアクセス方法。
  10. 前記データ書き込みステップでは、
    前記第１のデータ又は前記第２のデータを管理する前記第１のアプリケーション装置又は前記第２のアプリケーション装置がデータ更新をすることができない場合に、前記第１のデータ又は前記第２のデータの更新データを前記更新用のボリュームに書き込む
    ことを特徴とする請求項９に記載のデータアクセス方法。
  11. 前記第２のステップでは、
    前記第１のデータ又は前記第２のデータの作成要求を受信したときに、受信した前記第１のデータ又は前記第２のデータと前記第３の識別子との対応関係を管理し、
    前記第５のステップでは、
    前記第４のステップにおいて変換した前記アクセス要求により、前記受信した前記第１のデータ又は前記第２のデータの作成要求を行って、作成結果を、作成された前記第１のデータ又は前記第２のデータに対応する前記第３の識別子と共に、前記クライアント装置に送信する
    ことを特徴とする請求項８に記載のデータアクセス方法。
  12. 前記第５のステップでは、
    前記第１のデータ又は前記第２のデータの検索要求を受信したときに、前記第４のステップにおいて変換した前記アクセス要求により、対応する前記第１のデータ又は前記第２のデータの検索要求を行って、検索結果を、検索された前記第１のデータ又は前記第２のデータに対応する前記第３の識別子と共に、前記クライアント装置に送信する
    ことを特徴とする請求項８に記載のデータアクセス方法。
  13. 前記サーバは、
    前記ストレージ装置から前記第１のデータ又は前記第２のデータのデータ関係情報を取得するデータ関係情報取得部を備え、
    前記データ関係情報は、
    複数の前記第１のデータ間又は複数の前記第２のデータ間のコピー関係であり、
    前記第５のステップでは、
    コピー関係にある前記第１のデータ又は前記第２のデータが存在するときには、オリジナルの前記第１のデータ又は前記第２のデータのみとなるように、前記検索結果を変更する
    ことを特徴とする請求項１２に記載のデータアクセス方法。
  14. 前記データ関係情報は、
    前記第１のデータ又は前記第２のデータを格納する前記ボリュームの種別又は前記ボリュームのハードディスクドライブの種別であり、
    前記第５のステップでは、
    前記ボリュームの種別や前記ハードディスクドライブの種別の信頼性又は性能が高い順となるように、前記検索結果を変更する
    ことを特徴とする請求項１２に記載のデータアクセス方法。
JP2007285524A 2007-11-01 2007-11-01 情報処理システム及びデータ管理方法 Expired - Fee Related JP5046863B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2007285524A JP5046863B2 (ja) 2007-11-01 2007-11-01 情報処理システム及びデータ管理方法
US12/068,320 US8473636B2 (en) 2007-11-01 2008-02-05 Information processing system and data management method
US13/924,761 US9609045B2 (en) 2007-11-01 2013-06-24 Information processing system and data management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007285524A JP5046863B2 (ja) 2007-11-01 2007-11-01 情報処理システム及びデータ管理方法

Publications (2)

Publication Number Publication Date
JP2009116414A JP2009116414A (ja) 2009-05-28
JP5046863B2 true JP5046863B2 (ja) 2012-10-10

Family

ID=40589298

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007285524A Expired - Fee Related JP5046863B2 (ja) 2007-11-01 2007-11-01 情報処理システム及びデータ管理方法

Country Status (2)

Country Link
US (2) US8473636B2 (ja)
JP (1) JP5046863B2 (ja)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009187309A (ja) * 2008-02-06 2009-08-20 Canon Inc 認証サーバ及び認証システム及びアカウント保守方法
US8135838B2 (en) 2008-04-08 2012-03-13 Geminare Incorporated System and method for providing data and application continuity in a computer system
JP5539126B2 (ja) * 2010-09-09 2014-07-02 キヤノン株式会社 データ処理装置、制御方法、及びプログラム
JP2012084119A (ja) * 2010-09-16 2012-04-26 Ricoh Co Ltd 機器管理装置および機器管理プログラム
JP5548825B2 (ja) * 2011-02-28 2014-07-16 株式会社日立製作所 情報処理装置
US9396277B2 (en) * 2011-12-09 2016-07-19 Microsoft Technology Licensing, Llc Access to supplemental data based on identifier derived from corresponding primary application data
NO20120022A1 (no) * 2012-01-10 2013-07-11 Magnus Skraastad Gulbrandsen System og fremgangsmate for kontroll av tilgang til opphavsrettsbeskyttede data
US8799746B2 (en) * 2012-06-13 2014-08-05 Caringo, Inc. Erasure coding and replication in storage clusters
CN102752457B (zh) * 2012-07-19 2014-09-03 腾讯科技（深圳）有限公司 一种安装应用的方法及系统
FI20126010A (fi) * 2012-09-28 2014-03-29 Tekla Corp Lähdekohteiden muuntaminen kohdekohteiksi
US9521197B2 (en) * 2012-12-05 2016-12-13 International Business Machines Corporation Utilizing data object storage tracking in a dispersed storage network
US10587691B2 (en) 2012-12-05 2020-03-10 Pure Storage, Inc. Impatient writes
US9305007B1 (en) * 2013-02-08 2016-04-05 Symantec Corporation Discovering relationships using deduplication metadata to provide a value-added service
EP3089421A4 (en) * 2013-12-31 2017-01-18 Huawei Technologies Co., Ltd. Network element data access method and apparatus, and network management system
US10735514B2 (en) * 2017-08-29 2020-08-04 Western Digital Technologies, Inc. Remote application configuration on network-attached storage
CN112055849B (zh) * 2018-04-19 2024-01-16 村田机械株式会社 排他控制系统以及排他控制方法
US11520742B2 (en) * 2018-12-24 2022-12-06 Cloudbrink, Inc. Data mesh parallel file system caching
GB2581504A (en) * 2019-02-20 2020-08-26 Smartpipe Tech Ltd Processing data in a network
US11061927B2 (en) * 2019-04-03 2021-07-13 Sap Se Optimization of relocated queries in federated databases using cross database table replicas

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2404319A1 (en) * 2000-03-31 2001-10-11 Andrei Mikheev Method and system for gathering, organizing, and displaying information from data searches
US6976060B2 (en) 2000-12-05 2005-12-13 Agami Sytems, Inc. Symmetric shared file storage system
JP2003345810A (ja) * 2002-05-28 2003-12-05 Hitachi Ltd 文書検索方法、文書検索システム及び文書検索結果示方システム
US6938038B2 (en) * 2002-06-04 2005-08-30 Sap Aktiengesellschaft Method and apparatus for generating and utilizing qualifiers and qualified taxonomy tables
JP2005530280A (ja) * 2002-06-13 2005-10-06 アガミ システムズ， インコーポレイテッド 関連アプリケーション相互参照対称的共有ファイル記憶システム
JP2004178337A (ja) * 2002-11-28 2004-06-24 Hitachi Ltd 記憶装置システム、記憶装置、計算機およびプログラム
JP4294353B2 (ja) * 2003-03-28 2009-07-08 株式会社日立製作所 ジョブ管理機能を有するストレージ系障害管理方法及び装置
US20050086192A1 (en) * 2003-10-16 2005-04-21 Hitach, Ltd. Method and apparatus for improving the integration between a search engine and one or more file servers
US7516133B2 (en) * 2003-10-17 2009-04-07 Hitachi, Ltd. Method and apparatus for file replication with a common format
JP4391265B2 (ja) * 2004-02-26 2009-12-24 株式会社日立製作所 ストレージサブシステムおよび性能チューニング方法
US7185030B2 (en) * 2004-03-18 2007-02-27 Hitachi, Ltd. Storage system storing a file with multiple different formats and method thereof
US20060218146A1 (en) * 2005-03-28 2006-09-28 Elan Bitan Interactive user-controlled relevance ranking of retrieved information in an information search system
JP4720303B2 (ja) * 2005-06-08 2011-07-13 株式会社日立製作所 ストレージシステムを含む計算機システムの構成管理方法
JP4877921B2 (ja) * 2006-01-25 2012-02-15 株式会社日立製作所 ストレージシステム、記憶制御装置及び記憶制御装置のリカバリポイント検出方法
KR100772872B1 (ko) * 2006-02-24 2007-11-02 삼성전자주식회사 다중 자바 어플리케이션 환경에서 가상 아이디를 이용하여자원을 관리하는 장치 및 그 방법
JP2007280324A (ja) * 2006-04-12 2007-10-25 Hitachi Ltd 計算機システム、管理計算機および仮想ストレージ装置
US20070245107A1 (en) * 2006-04-14 2007-10-18 Hitachi, Ltd. System and method for processing a plurality kinds of event markers of a continuous data protection
US7882077B2 (en) * 2006-10-17 2011-02-01 Commvault Systems, Inc. Method and system for offline indexing of content and classifying stored data
US20080228771A1 (en) * 2006-12-22 2008-09-18 Commvault Systems, Inc. Method and system for searching stored data
JP4951331B2 (ja) * 2006-12-26 2012-06-13 株式会社日立製作所 ストレージシステム
US7801993B2 (en) * 2007-07-19 2010-09-21 Hitachi, Ltd. Method and apparatus for storage-service-provider-aware storage system
US8396838B2 (en) * 2007-10-17 2013-03-12 Commvault Systems, Inc. Legal compliance, electronic discovery and electronic document handling of online and offline copies of data

Also Published As

Publication number Publication date
US20130282799A1 (en) 2013-10-24
US8473636B2 (en) 2013-06-25
US20090119395A1 (en) 2009-05-07
JP2009116414A (ja) 2009-05-28
US9609045B2 (en) 2017-03-28

Similar Documents

Publication Publication Date Title
JP5046863B2 (ja) 情報処理システム及びデータ管理方法
US8504797B2 (en) Method and apparatus for managing thin provisioning volume by using file storage system
JP5775177B2 (ja) クローンファイル作成方法と、それを用いたファイルシステム
US10210167B1 (en) Multi-level page caching for distributed object store
US9208181B2 (en) Migrating data from legacy storage systems to object storage systems
US10852976B2 (en) Transferring snapshot copy to object store with deduplication preservation and additional compression
JP5608811B2 (ja) 情報処理システムの管理方法、及びデータ管理計算機システム
JP5066415B2 (ja) ファイルシステム仮想化のための方法および装置
US9015123B1 (en) Methods and systems for identifying changed data in an expandable storage volume
US9128942B1 (en) On-demand operations
US11797477B2 (en) Defragmentation for objects within object store
US20090319736A1 (en) Method and apparatus for integrated nas and cas data backup
US11016943B2 (en) Garbage collection for objects within object store
US20090089335A1 (en) Method and apparatus for nas/cas unified storage system
US20090043828A1 (en) Method and apparatus for nas/cas integrated storage system
US20090198704A1 (en) Method for automated network file and directory virtualization
JP2007272874A (ja) クラスタ化ファイルシステムにおいてデータのバックアップを取る方法
JP2008117322A (ja) 情報提供システム及び情報提供方法
WO2014183708A1 (zh) 一种实现分布式文件系统块存储的方法及系统
US9760457B2 (en) System, method and computer program product for recovering stub files
US10838641B2 (en) Defragmenting backup objects
US8612495B2 (en) Computer and data management method by the computer
US8627446B1 (en) Federating data between groups of servers
US20160048529A1 (en) Coalescing storage operations
US8332351B2 (en) Method and system for preserving files with multiple links during shadow migration

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100122

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120327

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120528

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120619

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120717

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150727

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees