JP2022100514A

JP2022100514A - ストレージシステムおよびデータ管理方法

Info

Publication number: JP2022100514A
Application number: JP2020214534A
Authority: JP
Inventors: 光雄早坂; Mitsuo Hayasaka; 鎮平野村; Shimpei Nomura; 悠冬鴨生; Yuto Komo; 英紀長崎; Hideki Nagasaki; 賢太志賀; Kenta Shiga
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2020-12-24
Filing date: 2020-12-24
Publication date: 2022-07-06
Anticipated expiration: 2040-12-24
Also published as: US20220206991A1; CN114676075A; JP7391826B2

Abstract

【課題】拠点間で、全てのファイルに対する関連ファイルを持ち合うことなく、ファイルを共有可能なストレージシステムを提供する。【解決手段】それぞれがファイルシステムを提供するストレージを備える複数の拠点間でファイルを共有可能なストレージシステムであって、ストレージは、ファイルのデータを記憶した記憶装置と、記憶装置に接続されたコントローラと、を備え、ファイルと関連付けられ、ファイルを参照する関連ファイルを有し、コントローラは、ファイルが更新される場合に、関連ファイルからの参照状況に基づいて、ファイルおよび関連ファイルを更新し、コントローラは、他拠点において記憶されているファイルに係るアクセス要求を受け付けた場合に、他拠点に問い合わせを行い、アクセス要求にかかるファイルにアクセスするための関連ファイルをアクセス要求を受けたコントローラにかかる拠点に作成する。【選択図】図３

Description

本発明は、概して、分散した拠点間でファイルを共有するストレージシステムおよびデータ管理方法に関する。

デジタルデータのデータ量は、急速に増大しており、企業がこれらデータを分析することで、ビジネス上の知見を抽出するためのデータの利活用が推進されている。増大するデジタルデータの中でも大きな比率を占める非構造データについては、ファイルストレージ、オブジェクトストレージ等に収集して分析するのが一般的である。

また、オンプレミス、プライベートクラウド、パブリッククラウド等を組み合わせた、ハイブリッドクラウド、マルチクラウドといったシステム形態が普及してきている。こうした複数の拠点にまたがるシステムにおいて生成されるデータを企業が利活用するためには、当該システムでは、分散している各拠点から必要なデータを発見し、分析対象とするデータを自拠点へと転送する機能が必要となる。

上記システムは、拠点に設置されたファイル・オブジェクトストレージに格納されたユーザファイルに対して、他拠点のファイル・オブジェクトストレージにはメタデータを保持するスタブ情報を作成する。また、上記システムは、スタブ情報の参照時に他拠点からデータを取得するリコール機能を提供する。加えて、上記システムでは、アクセスの少ないユーザファイルについては、メタデータを残してデータを拠点に設置されたファイル・オブジェクトストレージから削除するスタブ化機能、他拠点のファイル・オブジェクトストレージにユーザファイルをレプリケーションする機能を提供する。これらの拠点に設置されたファイル・オブジェクトストレージが連携して提供するこれらの機能をファイル仮想化機能と呼ぶ。

近年、拠点間で各拠点のスタブ情報を持ち合うことでファイルの存在確認を行い、またスタブ情報の参照を検知し、必要なデータブロックを取得する方法が開示されている（特許文献１参照）。また、メタデータの更新については、拠点間の整合性を保つために、グローバルロックが取得される。

国際公開第２０１６／１２１０９３号

しかし、特許文献１に記載されている技術では、拠点間で記憶するユーザファイルのスタブ情報（例えば、ユーザファイルを参照する関連ファイル）を保持し合うため、ストレージの記憶容量の消費が大きくなる。加えて、拠点の追加時には、新しい拠点で関連ファイルを作成するための他拠点からのデータの取得が必要となり、時間を要する。

本発明は、以上の点を考慮してなされたもので、拠点間で、全てのファイルに対する関連ファイルを持ち合うことなく、ファイルを共有可能なストレージシステム等を提案しようとするものである。

かかる課題を解決するため本発明においては、それぞれがファイルシステムを提供するストレージを備える複数の拠点間でファイルを共有可能なストレージシステムであって、前記ストレージは、ファイルのデータを記憶した記憶装置と、前記記憶装置に接続されたコントローラと、を備え、前記ファイルと関連付けられ、前記ファイルを参照する関連ファイルを有し、前記コントローラは、前記ファイルが更新される場合に、前記関連ファイルからの参照状況に基づいて、前記ファイルおよび関連ファイルを更新し、前記コントローラは、他拠点において記憶されているファイルに係るアクセス要求を受け付けた場合に、前記他拠点に問い合わせを行い、前記アクセス要求にかかるファイルにアクセスするための関連ファイルを前記アクセス要求を受けたコントローラにかかる拠点に作成する。

上記構成では、他拠点において記憶されているファイルに係るアクセス要求に応じて関連ファイルが作成されるので、ストレージは、他の拠点の全てのファイルの関連ファイルを記憶する必要がなく、拠点間におけるファイルの共有に必要な関連ファイルを削減することができる。例えば、各拠点において関連ファイルの記憶に必要な記憶容量と、新たな拠点の追加時に関連ファイルを取得する時間とについて、改善することができる。

本発明によれば、拠点間で、全てのファイルに対する関連ファイルを持ち合うことなく、ファイルを共有することができる。

第１の実施の形態によるストレージシステムに係る構成の一例を示す図である。第１の実施の形態によるファイル・オブジェクトストレージに係る構成の一例を示す図である。第１の実施の形態によるユーザファイルおよびユーザディレクトリの一例を示す図である。第１の実施の形態によるメタデータＤＢの一例を示す図である。第１の実施の形態による管理情報ファイルの一例を示す図である。第１の実施の形態によるオペレーションログの一例を示す図である。第１の実施の形態によるアクセス権管理表の一例を示す図である。第１の実施の形態による拠点間接続管理表の一例を示す図である。第１の実施の形態による拠点間横断メタデータ検索結果応答の一例を示す図である。第１の実施の形態による拠点間横断メタデータ検索処理の一例を示す図である。第１の実施の形態による拠点内メタデータ検索処理の一例を示す図である。第１の実施の形態によるスタブ作成処理の一例を示す図である。第１の実施の形態によるバックグラウンドデータ取得処理の一例を示す図である。第１の実施の形態によるファイル参照処理の一例を示す図である。第１の実施の形態によるデータ取得拠点選択処理の一例を示す図である。第１の実施の形態によるファイル更新処理の一例を示す図である。第１の実施の形態によるオペレーションログ解析処理の一例を示す図である。第１の実施の形態によるメタデータ抽出処理の一例を示す図である。第１の実施の形態によるレプリケーション処理の一例を示す図である。第１の実施の形態によるスタブ化処理の一例を示す図である。

（Ｉ）第１の実施の形態
以下、本発明の一実施の形態を詳述する。ただし、本発明は、実施の形態に限定されるものではない。

本発明の１つの観点に従うファイル・オブジェクトストレージは、ユーザファイルのメタデータを管理するメタデータデータベース（メタデータＤＢ）を備える。また、クライアント端末からの検索クエリを受信し、この検索クエリを全拠点に転送して、各拠点のメタデータＤＢから該当ユーザファイルを検索する。加えて、検索結果から選択されたユーザファイルについて拠点内のファイル・オブジェクトストレージにスタブ情報を作成する。

次に、本発明の実施の形態を図面に基づいて説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施することが可能である。特に限定しない限り、各構成要素は、単数でも複数でも構わない。

なお、以下の説明では、図面において同一要素については、同じ番号を付し、説明を適宜省略する。また、同種の要素を区別しないで説明する場合には、枝番を含む参照符号のうちの共通部分（枝番を除く部分）を使用し、同種の要素を区別して説明する場合は、枝番を含む参照符号を使用することがある。例えば、拠点を特に区別しないで説明する場合には、「拠点１１０」と記載し、個々の拠点を区別して説明する場合には、「拠点１１０－１」、「拠点１１０－２」のように記載することがある。

本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は、文脈毎に用いられ、１つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。

＜システム構成＞
図１は、本実施の形態におけるストレージシステム１００に係る構成の一例を示す図である。

本ストレージシステム１００は、拠点１１０－１，１１０－２，１１０－３を備える。拠点１１０間は、ＷＡＮ（Wide Area Network）であるネットワーク１２０により接続されている。なお、図１では、３つの拠点１１０－１，１１０－２，１１０－３が図示されているが、本実施の形態において拠点１１０の数に特段の制限はない。

拠点１１０－１は、クライアント端末１１１－１と、ファイル・オブジェクトストレージ１１２－１と、管理端末１１３－１とを備える。クライアント端末１１１－１とファイル・オブジェクトストレージ１１２－１と管理端末１１３－１とは、例えば、拠点１１０－１内のＬＡＮ（Local Area Network）等のネットワークで相互に接続されている。

クライアント端末１１１は、各種の情報処理が可能なコンピュータ等の情報処理装置である。クライアント端末１１１は、ファイル・オブジェクトストレージ１１２にユーザファイルを格納し、ユーザファイルへのリードおよびライトといった各種の操作を行う。ファイル・オブジェクトストレージ１１２の具体的構成については後述する。管理端末１１３は、各種の情報処理が可能なコンピュータ等の情報処理装置である。管理端末１１３は、ファイル・オブジェクトストレージ１１２の管理を行い、ファイル・オブジェクトストレージ１１２に異常があった際等に、ファイル・オブジェクトストレージ１１２に対して各種の操作指示等を行う。

拠点１１０－２および拠点１１０－３も、クライアント端末１１１とファイル・オブジェクトストレージ１１２とを備える。なお、図１に図示する拠点１１０－１，１１０－２，１１０－３のハードウェア構成は、単なる例示であり、少なくともそれぞれ１台のファイル・オブジェクトストレージ１１２を備える構成であれば、その台数、他のハードウェア構成を備えることに制限はない。

＜ファイル・オブジェクトストレージ＞
図２は、ファイル・オブジェクトストレージ１１２に係る構成の一例を示す図である。

ファイル・オブジェクトストレージ１１２は、コントローラ２１０と記憶装置２２０とを備える。

コントローラ２１０は、プロセッサ２１１、メモリ２１２、キャッシュ２１３、インターフェース２１４（Ｉ／Ｆ）、およびインターフェース２１５（Ｉ／Ｆ）を備える。

プロセッサ２１１は、コントローラ２１０およびファイル・オブジェクトストレージ１１２全体の動作制御を行う。メモリ２１２は、プロセッサ２１１の動作制御に用いられるプログラムおよびデータを一時的に記憶する。キャッシュ２１３は、クライアント端末１１１からライトされるデータおよび記憶装置２２０からリードされたデータを一時的に格納する。インターフェース２１４は、拠点１１０－１，１１０－２，１１０－３内の他のクライアント端末１１１、ファイル・オブジェクトストレージ１１２等との間での通信を行う。インターフェース２１５は、記憶装置２２０との間での通信を行う。

メモリ２１２には、ファイル仮想化プログラム２１２Ａ、ＩＯＨｏｏｋプログラム２１２Ｂ、メタデータＤＢプログラム２１２Ｃ、メタデータ検索プログラム２１２Ｄ、メタデータ抽出プログラム２１２Ｅ、プロトコル処理プログラム２１２Ｆ、およびバージョン管理プログラム２１２Ｇが格納されている。

記憶装置２２０は、プロセッサ２２１、メモリ２２２、キャッシュ２２３、記憶デバイス２２４、およびインターフェース２２５（Ｉ／Ｆ）を備える。

プロセッサ２２１は、記憶装置２２０の動作制御を行う。メモリ２２２は、プロセッサ２２１の動作制御に用いられるプログラムおよびデータを一時的に記憶する。キャッシュ２２３は、コントローラ２１０からライトされるデータおよび記憶デバイス２２４からリードされたデータを一時的に格納する。記憶デバイス２２４は、各種のファイルを格納する。インターフェース２２５は、コントローラ２１０との間での通信を行う。記憶デバイス２２４には、ユーザファイル２０１、ユーザディレクトリ２０２、メタデータＤＢ２０３、管理情報ファイル２０４、オペレーションログ２０５、アクセス権管理表２０６、および拠点間接続管理表２０７が格納されている。

ファイル仮想化プログラム２１２Ａは、オペレーションログ２０５の監視、クライアント端末１１１からの要求に応じて、ユーザファイル２０１およびユーザディレクトリ２０２に対する処理（レプリケーション処理またはスタブ化処理またはリコール処理）等を行う。

ＩＯＨｏｏｋプログラム２１２Ｂは、クライアント端末１１１からの要求を受けてプロトコル処理プログラム２１２Ｆが発行するユーザファイル２０１とユーザディレクトリ２０２とへの処理を監視し、処理が発生した場合には、操作内容のオペレーションログ２０５への追記、操作に伴うメタデータＤＢ２０３および管理情報ファイル２０４の更新等の、管理情報の更新を行う。

メタデータＤＢプログラム２１２Ｃは、メタデータＤＢ２０３を管理する。

メタデータ検索プログラム２１２Ｄは、クライアント端末１１１からの検索クエリに基づき、全拠点１１０のメタデータ検索プログラム２１２Ｄ間で連携し、各拠点１１０のメタデータＤＢプログラム２１２Ｃにリクエストを行い、メタデータＤＢ２０３に含まれるユーザファイル２０１のメタデータの収集と加工とを行う。

メタデータ抽出プログラム２１２Ｅは、ファイル仮想化プログラム２１２Ａからのリクエストに基づき、ユーザファイル２０１のデータを解析してメタデータを抽出し、抽出したメタデータをメタデータＤＢ２０３に登録する。また、メタデータ抽出プログラム２１２Ｅは、クライアント端末１１１からのリクエストに基づき、ユーザファイル２０１のデータを解析してメタデータを抽出し、抽出したメタデータをメタデータＤＢ２０３に登録する。本実施の形態では、メタデータＤＢ２０３に登録するメタデータの一例として、後述の図４を示すが、例えば、写真ファイル中に認識されるオブジェクトの名称、推定される撮影場所の情報を登録する等、登録するメタデータの種類および数について制限されない。

プロトコル処理プログラム２１２Ｆは、クライアント端末１１１からの各種の要求を受信し、この要求に含まれるプロトコルを処理する。

バージョン管理プログラム２１２Ｇは、ファイル・オブジェクトストレージ１１２に格納されるデータに更新が発生した際に、更新前のデータを残し、バージョン分けして管理するプログラムである。

＜ファイル格納構成＞
図３は、ファイル・オブジェクトストレージ１１２が格納するユーザファイル２０１およびユーザディレクトリ２０２の一例を示す図である。

図３では、各拠点１１０において、クライアント端末１１１は、ファイル・オブジェクトストレージ１１２が提供するファイルシステムにデータを格納している。一例として、拠点１１０－１は、ユーザディレクトリ２０２－１０（ルートディレクトリ）以下に、ユーザディレクトリ２０２－１１，２０２－１２，２０２－１３を備える。ユーザディレクトリ２０２－１１，２０２－１２，２０２－１３は、それぞれにユーザファイル２０１－１２，２０１－２１，２０１－３１を備える。

なお、クライアント端末１１１が、ファイル・オブジェクトストレージ１１２が提供するファイルシステム上で、ユーザファイル２０１を操作する例を示しているが、ユーザファイル２０１の操作は、この例に限らない。例えば、オブジェクトストレージとしてＵＲＩ（Uniform Resource Identifier）によりユーザファイル２０１を指定してＳ３（Simple Storage Service）、Ｓｗｉｆｔプロトコルで操作を行う形でも構わない。

＜バージョン管理機能＞
また、ファイル・オブジェクトストレージ１１２は、バージョン管理機能を有し、バージョンの異なるユーザファイル２０１を指定して操作を行うことができる。一例として、拠点１１０－１では、ユーザファイル２０１－１２の旧バージョンとしてユーザファイル２０１－１１を備える。原則として、ファイル・オブジェクトストレージ１１２は、クライアント端末１１１からの各操作を、最新のユーザファイル２０１に適用するが、操作時にバージョンを指定することで旧バージョンのユーザファイル２０１の操作も可能である。なお、本実施の形態では、ファイル・オブジェクトストレージ１１２でバージョン管理機能を提供するが、例えば、ユーザファイル２０１の複製を作成するといった方法等で、古いユーザファイル２０１を残しても構わない。

＜ＵＵＩＤ（Universally Unique Identifier）＞
各ユーザファイル２０１には、ＵＵＩＤが付与される。異なる拠点１１０のユーザファイル２０１と、異なるファイルパスのユーザファイル２０１とが、ＵＵＩＤおよびバージョンの双方が同一の値を持つことを許容し、同一のＵＵＩＤおよびバージョンを持つユーザファイル２０１は、同一のデータを参照する。例えば、ユーザファイル２０１－１１とユーザファイル２０１－４１とユーザファイル２０１－６１とは、同一のＵＵＩＤおよびバージョンを持つため、クライアント端末１１１からの参照操作に対し、同一のデータを返す。拠点１１０間で異なるファイルパスを与えられたユーザファイル２０１であってもＵＵＩＤおよびバージョンにより指し示されるデータが同一であるケースがあるため、本ストレージシステム１００では、ファイルパスを仮想的なパス（仮想パス）、ＵＵＩＤおよびバージョンを実際のデータを特定するパス（実パス）として扱う。

＜ファイル状態＞
同一のＵＵＩＤおよびバージョンを持つユーザファイル２０１は、Ｏｒｉｇｉｎａｌ状態、Ｓｔｕｂ状態、Ｃａｃｈｅ状態、Ｒｅｐｌｉｃａ状態の４つのファイル状態に分類される。

Ｏｒｉｇｉｎａｌ状態は、クライアント端末１１１が作成したユーザファイル２０１の最初のファイル状態である。Ｏｒｉｇｉｎａｌ状態のユーザファイル２０１は、ユーザファイル２０１のデータの全てを備える。Ｓｔｕｂ状態は、Ｏｒｉｇｉｎａｌ状態のユーザファイル２０１のデータの一部を含み得るファイル状態である。Ｓｔｕｂ状態のユーザファイル２０１は、他拠点１１０のＯｒｉｇｉｎａｌ状態のユーザファイル２０１を参照するために作成され、ユーザファイル２０１のデータの全てまたは部分的に有していない。Ｓｔｕｂ状態のユーザファイル２０１については、クライアント端末１１１から非保有データの参照操作を受信した場合、ＵＵＩＤおよびバージョンを同一とするＯｒｉｇｉｎａｌ状態またはＲｅｐｌｉｃａ状態のユーザファイル２０１からデータが取得される。Ｃａｃｈｅ状態は、Ｓｔｕｂ状態のユーザファイル２０１がすべてのデータの取得を完了することで遷移しているファイル状態である。Ｒｅｐｌｉｃａ状態は、Ｏｒｉｇｉｎａｌ状態のユーザファイル２０１の冗長化データとして、ユーザファイル２０１に含まれる全てのデータを保持しているファイル状態である。

Ｏｒｉｇｉｎａｌ状態は、ＵＵＩＤおよびバージョンが同一のユーザファイル２０１の中で単一のユーザファイル２０１のみが持てるファイル状態であり、クライアント端末１１１によるライト操作を許容する。これにより、ライト操作のたびに同一ＵＵＩＤおよびバージョンの全てのユーザファイル２０１のロック取得を回避できる。Ｓｔｕｂ状態、Ｃａｃｈｅ状態、またはＲｅｐｌｉｃａ状態のユーザファイル２０１にクライアント端末１１１によるライト操作が実施された場合には、異なるＵＵＩＤを付与した後にデータを更新する。Ｃａｃｈｅ状態とＲｅｐｌｉｃａ状態とは、ともに全データを備えるファイル状態である。ただし、Ｒｅｐｌｉｃａ状態のユーザファイル２０１のデータは、データ保護のために破壊することが許されない点で異なる。そのため、Ｒｅｐｌｉｃａ状態のユーザファイル２０１に対するライト操作時には、データを複製して新しいＵＵＩＤを付与した後に更新を反映する。一方、Ｃａｃｈｅ状態のユーザファイル２０１に対するライト操作時には、データを複製することなく、新しいＵＵＩＤを付与した後に更新を反映する。

なお、本実施の形態では、Ｓｔｕｂ状態、Ｃａｃｈｅ状態、またはＲｅｐｌｉｃａ状態のユーザファイル２０１に対するライト操作時には、異なるＵＵＩＤを付与して更新を反映する。ただし、例えば、Ｓｔｕｂ状態、Ｃａｃｈｅ状態、またはＲｅｐｌｉｃａ状態のユーザファイル２０１に対するライト操作を禁止したり、ライト操作時にストレージシステム１００内で同一ＵＵＩＤを持つ全てのユーザファイル２０１に更新を反映したりする構成でも構わない。

＜メタデータＤＢ＞
図４は、ファイル・オブジェクトストレージ１１２のメタデータＤＢ２０３の一例を示す図である。

メタデータＤＢ２０３のエントリは、ファイル・オブジェクトストレージ１１２内のユーザファイル２０１ごとに作成される。

メタデータＤＢ２０３のエントリには、ＵＵＩＤ４０１、バージョン４０２、仮想パス４０３、ファイル状態４０４、Ｏｒｉｇｉｎａｌ保持拠点４０５、Ｓｔｕｂ保持拠点４０６、Ｃａｃｈｅ保持拠点４０７、Ｒｅｐｌｉｃａ保持拠点４０８、ファイル種別４０９、およびキーワード４１０の情報が含まれる。

ＵＵＩＤ４０１には、ユーザファイル２０１に付与されたＵＵＩＤを示す情報が記憶される。バージョン４０２には、ユーザファイル２０１のバージョンを示す情報が記憶される。仮想パス４０３には、ユーザファイル２０１の仮想パスを示す情報が記憶される。ファイル状態４０４には、ユーザファイル２０１のファイル状態を示す情報が記憶される。

Ｏｒｉｇｉｎａｌ保持拠点４０５には、ＵＵＩＤ４０１およびバージョン４０２が同一の値を持ち、ファイル状態がＯｒｉｇｉｎａｌ状態であるユーザファイル２０１を格納する他拠点１１０を示す情報が記憶される。Ｓｔｕｂ保持拠点４０６には、ＵＵＩＤ４０１およびバージョン４０２が同一の値を持ち、ファイル状態がＳｔｕｂ状態であるユーザファイル２０１を格納する他拠点１１０を示す情報が記憶される。Ｃａｃｈｅ保持拠点４０７には、ＵＵＩＤ４０１およびバージョン４０２が同一の値を持ち、ファイル状態がＣａｃｈｅ状態であるユーザファイル２０１を格納する他拠点１１０を示す情報が記憶される。Ｒｅｐｌｉｃａ保持拠点４０８には、ＵＵＩＤ４０１およびバージョン４０２が同一の値を持ち、ファイル状態がＲｅｐｌｉｃａ状態であるユーザファイル２０１を格納する他拠点１１０を示す情報が記憶される。

ファイル種別４０９には、ユーザファイル２０１のファイル種別を示す情報が記憶される。キーワード４１０には、ユーザファイル２０１のデータの内容からメタデータ抽出プログラム２１２Ｅにより抽出されたキーワードを示す情報が記憶される。

メタデータ抽出プログラム２１２Ｅにより抽出し、メタデータＤＢ２０３に登録する情報の一例としてキーワード４１０を示したが、例えば、写真ファイル中に認識されるオブジェクトの名称、推定される撮影場所等の情報といったように、キーワード４１０には、例とは異なる情報が複数記憶されていても構わない。

＜管理情報ファイル＞
図５は、ファイル・オブジェクトストレージ１１２の管理情報ファイル２０４の一例を示す図である。

管理情報ファイル２０４は、ファイル・オブジェクトストレージ１１２内のユーザファイル２０１ごとに作成される。管理情報ファイル２０４は、ユーザファイル管理情報５１０および部分管理情報５２０を備える。

ユーザファイル管理情報５１０には、ＵＵＩＤ５１１、バージョン５１２、仮想パス５１３、ファイル状態５１４、およびメタデータ抽出済みフラグ５１５の情報が含まれる。

ＵＵＩＤ５１１には、ユーザファイル２０１に付与されたＵＵＩＤを示す情報が記憶される。バージョン５１２には、ユーザファイル２０１のバージョンを示す情報が記憶される。仮想パス５１３には、ユーザファイル２０１の仮想パスを示す情報が記憶される。ファイル状態５１４には、ユーザファイル２０１のファイル状態を示す情報が記憶される。メタデータ抽出済みフラグ５１５には、ユーザファイル２０１について後述のメタデータ抽出処理Ｓ１８００が適用済みであるか否かを示す情報が記憶される。

部分管理情報５２０は、オフセット５２１とサイズ５２２とにより表されるユーザファイル２０１の領域に対応した複数のエントリからなる。部分管理情報５２０の各エントリには、オフセット５２１、サイズ５２２、および部分状態５２３の情報が含まれる。

オフセット５２１には、エントリが示すユーザファイル２０１内の領域のオフセットを示す情報が記憶される。サイズ５２２には、エントリが示すユーザファイル２０１内の領域のサイズを示す情報が記憶される。部分状態５２３には、エントリが示すユーザファイル２０１の領域の部分状態を示す情報が記憶される。

部分状態５２３は、「Ｃａｃｈｅ」と「Ｓｔｕｂ」と「Ｄｉｒｔｙ」の３つの値のいずれかをとり得る。「Ｃａｃｈｅ」は、対象領域のデータが自拠点１１０のユーザファイル２０１に保持されており、ＵＵＩＤ５１１およびバージョン５１２が同一の値を持ち、ファイル状態がＲｅｐｌｉｃａ状態である他拠点１１０のユーザファイル２０１に対象領域のデータが反映されていることを示す。「Ｓｔｕｂ」は、対象領域のデータが自拠点１１０のユーザファイル２０１に保持されておらず、クライアント端末１１１からのリード操作時には対象領域のデータを他拠点１１０からリコールする必要があることを示す。「Ｄｉｒｔｙ」は、対象領域のデータが自拠点１１０のユーザファイル２０１に保持されており、ＵＵＩＤ５１１およびバージョン５１２が同一の値を持ち、ファイル状態がＲｅｐｌｉｃａ状態である他拠点１１０のユーザファイル２０１に対象領域のデータが未反映であることを示す。

＜オペレーションログ＞
図６は、ファイル・オブジェクトストレージ１１２のオペレーションログ２０５の一例を示す図である。

オペレーションログ２０５のエントリは、ファイル・オブジェクトストレージ１１２で発生した操作ごとに作成される。

オペレーションログ２０５のエントリには、オペレーション６０１、ＵＵＩＤ６０２、バージョン６０３、タイプ６０４、オフセット６０５、サイズ６０６、通信拠点６０７、およびタイムスタンプ６０８の情報が含まれる。

オペレーション６０１には、発生した操作の種別を示す情報が記憶される。ＵＵＩＤ６０２には、操作対象のユーザファイル２０１またはユーザディレクトリ２０２に付与されたＵＵＩＤを示す情報が記憶される。バージョン６０３には、操作対象のユーザファイル２０１またはユーザディレクトリ２０２のバージョンを示す情報が記憶される。タイプ６０４には、操作対象の種別を示す情報が記憶される。オフセット６０５には、操作対象の領域のオフセットを示す情報が記憶される。サイズ６０６には、操作対象の領域のサイズを示す情報が記憶される。通信拠点６０７には、操作によりユーザファイル２０１またはユーザディレクトリ２０２のデータを送信または受信した拠点１１０を示す情報が記憶される。タイムスタンプ６０８には、操作の日時を示す情報が記憶される。

＜アクセス権管理表＞
図７は、ファイル・オブジェクトストレージ１１２のアクセス権管理表２０６の一例を示す図である。

アクセス権管理表２０６のエントリは、ファイル・オブジェクトストレージ１１２内のユーザファイル２０１ごとに作成される。

アクセス権管理表２０６のエントリには、ＵＵＩＤ７１０、バージョン７２０、メタデータアクセス権７３０、およびデータアクセス権７４０の情報が含まれる。

ＵＵＩＤ７１０には、ユーザファイル２０１に付与されたＵＵＩＤを示す情報が記憶される。バージョン７２０には、ユーザファイル２０１のバージョンを示す情報が記憶される。メタデータアクセス権７３０には、ユーザファイル２０１のメタデータアクセス権を示す情報が記憶される。データアクセス権７４０には、ユーザファイル２０１のデータアクセス権を示す情報が記憶される。

メタデータアクセス権７３０には、アクセス権７３１（所有者）、アクセス権７３２（所有グループ）、アクセス権７３３（その他）、転送可否７３４（他拠点移動可否）の情報が含まれる。

アクセス権７３１には、ユーザファイル２０１の所有者に対するメタデータへのアクセス権を示す情報が記憶される。アクセス権７３２には、ユーザファイル２０１の所有グループに対するメタデータへのアクセス権を示す情報が記憶される。アクセス権７３３には、ユーザファイル２０１のその他ユーザに対するメタデータへのアクセス権を示す情報が記憶される。転送可否７３４には、ユーザファイル２０１のメタデータについての他拠点１１０への転送可否を示す情報が記憶される。

データアクセス権７４０には、アクセス権７４１（所有者）、アクセス権７４２（所有グループ）、アクセス権７４３（その他）、転送可否７４４（他拠点移動可否）の情報が含まれる。

アクセス権７４１には、ユーザファイル２０１の所有者に対するデータへのアクセス権を示す情報が記憶される。アクセス権７４２には、ユーザファイル２０１の所有グループに対するデータへのアクセス権を示す情報が記憶される。アクセス権７４３には、ユーザファイル２０１のその他ユーザに対するデータへのアクセス権を示す情報が記憶される。転送可否７４４には、ユーザファイル２０１のデータについての他拠点１１０への転送可否を示す情報が記憶される。

メタデータアクセス権７３０とデータアクセス権７４０との種類の一例として、所有者、所有グループ、その他、および他拠点１１０への転送可否を示したが、これらに限られない。例えば、メタデータアクセス権７３０とデータアクセス権７４０とには、ユーザの所属部門または所属プロジェクトごとのアクセス権、国内外へのデータの転送可否等を含めても構わない。

＜拠点間接続管理表＞
図８は、ファイル・オブジェクトストレージ１１２の拠点間接続管理表２０７の一例を示す図である。

拠点間接続管理表２０７は、拠点１１０間の通信時の性能およびコストの情報を記憶する。図８の例では、各行に転送元の拠点１１０（転送元８０１）を示し、各列に転送先の拠点１１０（転送先８０２）を示す。各セルには、転送元８０１から転送先８０２にデータを転送する際の帯域幅を示す。

拠点間接続管理表２０７の一例として、各拠点１１０間のデータ転送の帯域幅を示したが、これらに限られない。例えば、拠点間接続管理表２０７には、データ転送時にかかるレイテンシ、通信経路を利用した際にかかる課金情報等の情報が複数含まれても構わない。

＜拠点間横断メタデータ検索結果応答＞
図９は、ファイル・オブジェクトストレージ１１２のメタデータ検索プログラム２１２Ｄが検索結果として応答する拠点間横断メタデータ検索結果応答９００の一例を示す図である。

拠点間横断メタデータ検索結果応答９００のエントリは、検索クエリに該当するとして全拠点１１０から抽出されたユーザファイル２０１ごとに作成される。

拠点間横断メタデータ検索結果応答９００のエントリは、ＵＵＩＤ９０１、バージョン９０２、拠点９０３、仮想パス９０４、ファイル状態９０５、ファイル種別９０６、およびキーワード９０７の情報が含まれる。

ＵＵＩＤ９０１には、ユーザファイル２０１に付与されたＵＵＩＤを示す情報が記憶される。バージョン９０２には、ユーザファイル２０１のバージョンを示す情報が記憶される。拠点９０３には、ユーザファイル２０１を格納する拠点１１０を示す情報が記憶される。仮想パス９０４には、ユーザファイル２０１の仮想パスを示す情報が記憶される。ファイル状態９０５には、ユーザファイル２０１のファイル状態を示す情報が記憶される。ファイル種別９０６には、ユーザファイル２０１のファイル種別を示す情報が記憶される。キーワード９０７には、ユーザファイル２０１のデータの内容からメタデータ抽出プログラム２１２Ｅにより抽出されたキーワードを示す情報が記憶される。

＜処理フロー＞
次に、図１０～図２０のフローチャートを参照して、本実施の形態のストレージシステム１００の動作について説明する。

＜拠点間横断メタデータ検索処理＞
図１０は、ストレージシステム１００の拠点間横断メタデータ検索処理Ｓ１０００の一例を説明するためのフローチャートである。

拠点間横断メタデータ検索処理は、メタデータ検索プログラム２１２Ｄがクライアント端末１１１より拠点間横断メタデータ検索の検索クエリを受け付けることで開始する（Ｓ１００１）。

まず、メタデータ検索プログラム２１２Ｄは、全拠点１１０に検索クエリを発行（例えば、転送）し、後述の拠点内メタデータ検索処理Ｓ１１００をリクエストする（Ｓ１００２）。

次に、転送された検索クエリを受信した各拠点１１０のメタデータ検索プログラム２１２Ｄは、拠点内メタデータ検索処理Ｓ１１００を実施する（Ｓ１００３）。

次に、メタデータ検索プログラム２１２Ｄは、各拠点１１０から拠点内メタデータ検索処理Ｓ１１００の検索結果を受信する（Ｓ１００４）。

次に、メタデータ検索プログラム２１２Ｄは、各拠点１１０の検索結果を集約して拠点間横断メタデータ検索結果応答９００の形式でクライアント端末１１１に応答を返し（Ｓ１００５）、処理を終了する（Ｓ１００６）。

＜拠点内メタデータ検索処理＞
図１１は、拠点内メタデータ検索処理Ｓ１１００の一例を説明するためのフローチャートである。

拠点内メタデータ検索処理Ｓ１１００は、クライアント端末１１１からの拠点内メタデータ検索の検索クエリがいずれかの拠点１１０において受け付けられたことに基づいて開始する（Ｓ１１０１）。

まず、メタデータ検索プログラム２１２Ｄは、メタデータＤＢプログラム２１２Ｃにリクエストして、検索クエリの条件に該当するレコードをメタデータＤＢ２０３より抽出する（Ｓ１１０２）。

次に、メタデータ検索プログラム２１２Ｄは、Ｓ１１０２で抽出したレコードから、メタデータへのアクセス権がないレコードを削除する（Ｓ１１０３）。より具体的には、メタデータ検索プログラム２１２Ｄは、アクセス権管理表２０６を参照し、該当レコードから対応するユーザファイル２０１について、検索クエリの転送元の拠点１１０ないしは検索クエリの発行元のユーザがメタデータへのアクセス権を備えるレコードを抽出する。

次に、メタデータ検索プログラム２１２Ｄは、抽出したレコードを検索結果として検索クエリの転送元に返答し（Ｓ１１０４）、処理を終了する（Ｓ１１０５）。

＜スタブ作成処理＞
図１２は、スタブ作成処理Ｓ１２００の一例を説明するためのフローチャートである。

スタブ作成処理Ｓ１２００は、ファイル仮想化プログラム２１２Ａがクライアント端末１１１よりスタブ作成要求を受信して開始する（Ｓ１２０１）。スタブ作成要求は、例えば、クライアント端末１１１において拠点間横断メタデータ検索結果応答９００におけるレコードが選択されることにより作成される。

まず、ファイル仮想化プログラム２１２Ａは、スタブ作成要求に指定されるＵＵＩＤ、バージョン、および仮想パスに基づき、管理情報ファイル２０４とＳｔｕｂ状態のユーザファイル２０１（スタブファイル）とをスタブ情報として自拠点１１０内に作成し、メタデータＤＢ２０３とアクセス権管理表２０６とに作成したユーザファイル２０１に対応するレコードを作成する（Ｓ１２０２）。

次に、ファイル仮想化プログラム２１２Ａは、Ｓｔｕｂ状態のユーザファイル２０１を作成したことを他拠点１１０のファイル仮想化プログラム２１２Ａに通知し、他拠点１１０のＵＵＩＤおよびバージョンを同一とする、メタデータＤＢ２０３のレコードと、管理情報ファイル２０４のレコードとを更新する（Ｓ１２０３）。

次に、ファイル仮想化プログラム２１２Ａは、Ｓｔｕｂ状態のユーザファイル２０１のデータについてのバックグラウンドでの転送設定を確認する（Ｓ１２０４）。ファイル仮想化プログラム２１２Ａは、転送設定が有効である場合、Ｓ１２０５に処理を移し、転送設定が無効である場合、Ｓ１２０６に処理を移す。バックグラウンドでの転送設定の方法としては、ファイルシステム単位、ディレクトリ単位、またはファイル単位にバックグラウンド転送の実施有無と使用帯域幅とを決定する方法、スタブ作成要求時にバックグラウンド転送の実施有無を指定する方法、ファイルシステムの拠点１１０間の移行時にのみバックグラウンド転送を行う方法等があり、特に制限されない。

Ｓ１２０５では、ファイル仮想化プログラム２１２Ａは、作成したＳｔｕｂ状態のユーザファイル２０１のデータを取得するための、バックグラウンドでのデータ転送処理（バックグラウンドデータ取得処理Ｓ１３００）を開始し、Ｓ１２０６に処理を移す。

Ｓ１２０６では、ファイル仮想化プログラム２１２Ａは、オペレーションログ２０５にスタブ作成操作の内容を追記する。

次に、ファイル仮想化プログラム２１２Ａは、スタブ作成処理の結果をクライアント端末１１１に応答し（Ｓ１２０７）、処理を終了する（Ｓ１２０８）。

＜バックグランドデータ取得処理＞
図１３は、バックグラウンドデータ取得処理Ｓ１３００の一例を説明するためのフローチャートである。

バックグラウンドデータ取得処理Ｓ１３００は、スタブ作成処理Ｓ１２００中のバックグラウンドでのデータ転送処理の要求、または、クライアント端末１１１から直接の特定のＳｔｕｂ状態にあるユーザファイル２０１を指定したバックグラウンドでのデータ転送処理の要求の受信により開始する（Ｓ１３０１）。

まず、ファイル仮想化プログラム２１２Ａは、データ取得拠点選択処理Ｓ１５００を実施し、対象のユーザファイル２０１のデータの取得元の拠点１１０を決定する（Ｓ１３０２）。

次に、ファイル仮想化プログラム２１２Ａは、Ｓ１３０２で決定した拠点１１０から、対象のユーザファイル２０１のＵＵＩＤおよびバージョンを指定して、対象のユーザファイル２０１のデータ（Ｓｔｕｂ部のデータ）を取得し、対象のユーザファイル２０１に書き込む（Ｓ１３０３）。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する、メタデータＤＢ２０３のレコードと管理情報ファイル２０４のレコードとについて、データの取得部分の部分状態が「Ｃａｃｈｅ」となり、ファイル状態がＣａｃｈｅ状態となったことを反映する（Ｓ１３０４）。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持つ他拠点１１０のユーザファイル２０１について、対応するメタデータＤＢ２０３のレコードと管理情報ファイル２０４のレコードとにファイル状態がＣａｃｈｅ状態となったことを反映する（Ｓ１３０５）。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持つ他拠点１１０のＯｒｉｇｉｎａｌ状態のユーザファイル２０１について、最終参照日時からの経過時間が一定の値を超過しているかを確認する（Ｓ１３０６）。ファイル仮想化プログラム２１２Ａは、最終参照日時からの経過時間が一定の値を超過している場合、Ｓ１３０７に処理を移し、最終参照日時からの経過時間が一定の値を超過していない場合、Ｓ１３０８に処理を移す。

Ｓ１３０７では、ファイル仮想化プログラム２１２Ａは、Ｃａｃｈｅ状態となった対象のユーザファイル２０１をＯｒｉｇｉｎａｌ状態へと移行し、対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持つＯｒｉｇｉｎａｌ状態のユーザファイル２０１をＣａｃｈｅ状態へと移行する。この移行を反映するため、全ての拠点１１０で対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持つユーザファイル２０１について、メタデータＤＢ２０３の対応するレコードと管理情報ファイル２０４の対応するレコードとを更新する。ファイル仮想化プログラム２１２Ａは、完了した後、Ｓ１３０８に処理を移す。

Ｓ１３０８では、ファイル仮想化プログラム２１２Ａは、オペレーションログ２０５に、対象のユーザファイル２０１に対してＳ１３０３で実施した他拠点１１０からのリコール操作を追記し、処理を終了する（Ｓ１３０９）。

＜ファイル参照処理＞
図１４は、ファイル参照処理Ｓ１４００の一例を説明するためのフローチャートである。

ファイル参照処理Ｓ１４００は、クライアント端末１１１からの特定のユーザファイル２０１へのリード操作において、当該ユーザファイル２０１のデータへのアクセス権がある場合に開始する（Ｓ１４０１）。

まず、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４を参照し、参照の対象部分の部分状態が「Ｓｔｕｂ」であるかを確認する（Ｓ１４０２）。ファイル仮想化プログラム２１２Ａは、部分状態が「Ｓｔｕｂ」である場合、Ｓ１４０３に処理を移し、部分状態が「Ｓｔｕｂ」でない場合、Ｓ１４１０に処理を移す。

Ｓ１４０３では、ファイル仮想化プログラム２１２Ａは、データ取得拠点選択処理Ｓ１５００を実施し、対象のユーザファイル２０１のデータの取得元の拠点１１０を決定する。

次に、ファイル仮想化プログラム２１２Ａは、Ｓ１４０３で決定した拠点１１０から、対象のユーザファイル２０１のＵＵＩＤ、バージョン、および参照の対象部分（オフセットおよびサイズ）を指定して、データを取得する（Ｓ１４０４）。

次に、ファイル仮想化プログラム２１２Ａは、Ｓ１４０４で取得したデータを対象のユーザファイル２０１に書き込む（Ｓ１４０５）。

次に、ファイル仮想化プログラム２１２Ａは、Ｓ１４０５でデータを書き込んだ部分について、対象のユーザファイル２０１に対応する管理情報ファイル２０４の部分状態を「Ｃａｃｈｅ」に変更する（Ｓ１４０６）。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４を確認して、全ての部分状態が「Ｃａｃｈｅ」であるかを確認する（Ｓ１４０７）。ファイル仮想化プログラム２１２Ａは、全ての部分状態が「Ｃａｃｈｅ」である場合、Ｓ１４０８に処理を移し、「Ｃａｃｈｅ」ではない部分状態が含まれている場合、Ｓ１４１０に処理を移す。

Ｓ１４０８では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１と対応する、メタデータＤＢ２０３のレコードと管理情報ファイル２０４のレコードとについて、対象のユーザファイル２０１が全データを取得してファイル状態がＣａｃｈｅ状態となったことを反映する。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持つ他拠点１１０のユーザファイル２０１について、対応するメタデータＤＢ２０３のレコードと管理情報ファイル２０４のレコードとにファイル状態がＣａｃｈｅ状態となったことを反映し（Ｓ１４０９）、Ｓ１４１０に処理を移す。

Ｓ１４１０では、ファイル仮想化プログラム２１２Ａは、オペレーションログ２０５に、対象のユーザファイル２０１へのリード操作と、実行した場合はＳ１４０４およびＳ１４０５で実施した他拠点１１０からのリコール操作を追記する。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１の参照の対象部分を読み出してユーザに応答（Ｓ１４１１）し、処理を終了する（Ｓ１４１２）。

＜データ取得拠点選択処理＞
図１５は、データ取得拠点選択処理Ｓ１５００の一例を説明するためのフローチャートである。

データ取得拠点選択処理Ｓ１５００は、バックグラウンドデータ取得処理Ｓ１３００、ファイル参照処理Ｓ１４００、または後述のファイル更新処理Ｓ１６００中で、Ｓｔｕｂ状態のユーザファイル２０１についての他拠点１１０からのデータ取得前に開始される（Ｓ１５０１）。

まず、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４から、同一のＵＵＩＤおよびバージョンを持つユーザファイル２０１であって、Ｏｒｉｇｉｎａｌ状態、Ｃａｃｈｅ状態、またはＲｅｐｌｉｃａ状態のいずれかのファイル状態であるユーザファイル２０１を保持する拠点１１０を特定する（Ｓ１５０２）。

次に、ファイル仮想化プログラム２１２Ａは、拠点間接続管理表２０７を参照して、Ｓ１５０２で特定した拠点１１０からデータの取得に最も好適な拠点１１０を選択して応答し（Ｓ１５０３）、処理を終了する（Ｓ１５０４）。本実施の形態では、ファイル仮想化プログラム２１２Ａは、拠点間接続管理表２０７に記憶されている帯域幅の値が最も大きい拠点１１０を選択する。なお、通信の帯域幅の他に、通信のレイテンシ、通信経路の利用コスト等に基づいて、拠点１１０を選択しても構わない。

＜ファイル更新処理＞
図１６は、ファイル更新処理Ｓ１６００の一例を説明するためのフローチャートである。

ファイル更新処理Ｓ１６００は、クライアント端末１１１からの特定のユーザファイル２０１へのライト操作において、当該ユーザファイル２０１のデータへのアクセス権がある場合に開始する（Ｓ１６０１）。

まず、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４からファイル状態がＯｒｉｇｉｎａｌ状態であるかを確認する（Ｓ１６０２）。ファイル仮想化プログラム２１２Ａは、ファイル状態がＯｒｉｇｉｎａｌ状態である場合、Ｓ１６０３に処理を移し、ファイル状態がＯｒｉｇｉｎａｌ状態でない場合、Ｓ１６０８に処理を移す。

Ｓ１６０３では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４から、対象のユーザファイル２０１が他拠点１１０から参照されているかを確認する。ファイル仮想化プログラム２１２Ａは、管理情報ファイル２０４のＳｔｕｂ保持拠点またはＣａｃｈｅ保持拠点にいずれかの拠点１１０が設定されている場合、他拠点１１０からの参照があると判定する。ファイル仮想化プログラム２１２Ａは、他拠点１１０からの参照がある場合、Ｓ１６０４に処理を移し、他拠点１１０からの参照がない場合、Ｓ１６０６に処理を移す。

Ｓ１６０４では、ファイル仮想化プログラム２１２Ａは、クライアント端末１１１からのライト操作の内容に基づき、対象のユーザファイル２０１を、バージョンを更新する形でデータを更新する。これにより、他拠点１１０から参照されるユーザファイル２０１を旧バージョンとして残すことができる。なお、ファイル・オブジェクトストレージ１１２がバージョン管理機能を有さない場合には、例えば、ファイル仮想化プログラム２１２Ａが更新前のユーザファイル２０１を複製するといった方法で旧バージョンのデータを残しても構わない。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４を、バージョンを更新する形で、ライト処理対象（更新領域）の部分状態を「Ｄｉｒｔｙ」に更新し、メタデータ抽出済みフラグを「Ｆａｌｓｅ」に更新する（Ｓ１６０５）。これにより、他拠点１１０から参照されるユーザファイル２０１の旧バージョンの管理情報ファイル２０４を残すことができる。なお、ファイル・オブジェクトストレージ１１２がバージョン管理機能を有さない場合には、例えば、更新前の管理情報ファイル２０４を複製するといった方法で旧バージョンのデータを残しても構わない。ファイル仮想化プログラム２１２Ａは、完了後、Ｓ１６１１に処理を移す。

Ｓ１６０６では、ファイル仮想化プログラム２１２Ａは、クライアント端末１１１からのライト操作の内容に基づき、対象のユーザファイル２０１のデータを更新する。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４について、ライト処理対象の部分状態を「Ｄｉｒｔｙ」に更新し、メタデータ抽出済みフラグを「Ｆａｌｓｅ」に更新し（Ｓ１６０７）、Ｓ１６１１に処理を移す。

Ｓ１６０８では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４から、ファイル状態がＲｅｐｌｉｃａ状態であるかを確認する。ファイル仮想化プログラム２１２Ａは、ファイル状態がＲｅｐｌｉｃａ状態である場合、Ｓ１６０９に処理を移し、Ｒｅｐｌｉｃａ状態でない場合、Ｓ１６１３に処理を移す。

Ｓ１６０９では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１を複製し、複製したユーザファイル２０１に新しいＵＵＩＤを付与して、ライト操作の内容に基づいてデータを更新する。

次に、ファイル仮想化プログラム２１２Ａは、複製したユーザファイル２０１に対応する管理情報ファイル２０４を作成し、メタデータＤＢ２０３とアクセス権管理表２０６とに、複製したユーザファイル２０１に対応するレコードを作成し（Ｓ１６１０）、Ｓ１６１１に処理を移す。

Ｓ１６１１では、ファイル仮想化プログラム２１２Ａは、オペレーションログ２０５にライト操作の内容を追記する。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１へのライト操作の完了をクライアント端末１１１に応答し（Ｓ１６１２）、処理を終了する（Ｓ１６２６）。

Ｓ１６１３では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に新しいＵＵＩＤを付与して、ライト操作の内容に基づいてデータを更新する。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４から、ファイル状態がＣａｃｈｅ状態であるかを確認する（Ｓ１６１４）。ファイル仮想化プログラム２１２Ａは、ファイル状態がＣａｃｈｅ状態である場合、Ｓ１６１５に処理を移し、ファイル状態がＣａｃｈｅ状態でない場合、Ｓ１６１７に処理を移す。

Ｓ１６１５では、ファイル仮想化プログラム２１２Ａは、ユーザファイル２０１に対応する、メタデータＤＢ２０３のレコードと、管理情報ファイル２０４のレコードと、アクセス権管理表２０６のレコードとに関して、新しいＵＵＩＤを付与し、ファイル状態がＯｒｉｇｉｎａｌ状態となったことを反映する。

次に、ファイル仮想化プログラム２１２Ａは、新しいＵＵＩＤの付与前に対象のユーザファイル２０１に付与されていた値と同一のＵＵＩＤおよびバージョンを持つ他拠点１１０のユーザファイル２０１について、対応するメタデータＤＢ２０３のレコードと管理情報ファイル２０４のレコードとに、新しいＵＵＩＤが付与されたこと（ファイル状態がＣａｃｈｅ状態でなくなったこと）を反映し（Ｓ１６１６）、Ｓ１６１１に処理を移す。

Ｓ１６１７では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４について、ライト処理対象の部分状態を「Ｄｉｒｔｙ」に更新する。

次に、ファイル仮想化プログラム２１２Ａは、オペレーションログ２０５にライト操作の内容を追記する（Ｓ１６１８）。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１へのライト操作の完了をクライアント端末１１１に応答する（Ｓ１６１９）。

次に、ファイル仮想化プログラム２１２Ａは、データ取得拠点選択処理Ｓ１５００を実施し（Ｓ１６２０）、対象のユーザファイル２０１のデータの取得元の拠点１１０を決定する。

次に、ファイル仮想化プログラム２１２Ａは、Ｓ１６２０で決定した拠点１１０から、新しいＵＵＩＤの付与前に対象のユーザファイル２０１に付与されていたＵＵＩＤおよびバージョンを指定して、対象のユーザファイル２０１のデータ（Ｓｔｕｂ部のデータ）を取得する（Ｓ１６２１）。

次に、ファイル仮想化プログラム２１２Ａは、Ｓ１６２１で取得したデータを対象のユーザファイル２０１に書き込む（Ｓ１６２２）。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する、メタデータＤＢ２０３のレコードと、管理情報ファイル２０４のレコードと、アクセス権管理表２０６のレコードとに関して、新しいＵＵＩＤを付与し、ファイル状態がＯｒｉｇｉｎａｌ状態となったことを反映する（Ｓ１６２３）。

次に、ファイル仮想化プログラム２１２Ａは、新しいＵＵＩＤの付与前に対象のユーザファイル２０１に付与されていた値と同一のＵＵＩＤおよびバージョンを持つ他拠点１１０のユーザファイル２０１について、対応するメタデータＤＢ２０３のレコードと管理情報ファイル２０４のレコードとに、新しいＵＵＩＤが付与されたこと（ファイル状態がＳｔｕｂ状態でなくなったこと）を反映する（Ｓ１６２４）。

次に、ファイル仮想化プログラム２１２Ａは、オペレーションログ２０５に他拠点１１０からのリコール操作の内容を追記し（Ｓ１６２５）、処理を終了する（Ｓ１６２６）。

＜オペレーションログ解析処理＞
図１７は、オペレーションログ解析処理Ｓ１７００の一例を説明するためのフローチャートである。

オペレーションログ解析処理Ｓ１７００は、前回のオペレーションログ解析処理Ｓ１７００からの一定時間の経過、未処理のオペレーションログが一定数以上貯まることを契機として開始する（Ｓ１７０１）。

まず、ファイル仮想化プログラム２１２Ａは、前回のオペレーションログ解析処理Ｓ１７００から追加された、未解析のオペレーションログ２０５を取得する（Ｓ１７０２）。

次に、ファイル仮想化プログラム２１２Ａは、Ｓ１７０２で取得したオペレーションログ２０５中で、操作対象となっているユーザファイル２０１を抽出する（Ｓ１７０３）。ファイル仮想化プログラム２１２Ａは、操作対象の識別子としては、ＵＵＩＤおよびバージョンの組み合わせを使い、この値のリストを作成する。

Ｓ１７０４では、ファイル仮想化プログラム２１２Ａは、Ｓ１７０３で作成したリストのうちに未処理のエントリがあるかを確認する。ファイル仮想化プログラム２１２Ａは、未処理のエントリがある場合、Ｓ１７０５に処理を移し、未処理のエントリがない場合、処理を終了する（Ｓ１７１０）。

Ｓ１７０５では、ファイル仮想化プログラム２１２Ａは、Ｓ１７０３で作成したリストから未処理のエントリのうち１つを選択し、処理対象として設定する。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１について、Ｓ１７０２で取得したオペレーションログ２０５中でライト操作が行われており、対応する管理情報ファイル２０４から、ファイル状態がＯｒｉｇｉｎａｌ状態であることを確認する（Ｓ１７０６）。ファイル仮想化プログラム２１２Ａは、ライト操作が行われており、かつ、ファイル状態がＯｒｉｇｉｎａｌ状態である場合、Ｓ１７０７に処理を移し、その他の場合、Ｓ１７０４に処理を移す。

Ｓ１７０７では、ファイル仮想化プログラム２１２Ａは、メタデータ抽出対象リストに、対象のユーザファイル２０１のＵＵＩＤおよびバージョンを追記し、Ｓ１７０８に処理を移す。

Ｓ１７０８では、ファイル仮想化プログラム２１２Ａは、Ｓ１７０２で取得したオペレーションログ２０５より、対象のユーザファイル２０１に実施された最後のライト操作以降に、対象のユーザファイル２０１にレプリケーション操作がなされていないことを確認する。ファイル仮想化プログラム２１２Ａは、レプリケーション操作がなされていない場合、Ｓ１７０９に処理を移し、その他の場合、Ｓ１７０４に処理を移す。

Ｓ１７０９では、ファイル仮想化プログラム２１２Ａは、レプリケーション対象リストに、対象のユーザファイル２０１のＵＵＩＤおよびバージョンを追加し、Ｓ１７０４に処理を移す。

＜メタデータ抽出処理＞
図１８は、メタデータ抽出処理Ｓ１８００の一例を説明するためのフローチャートである。

メタデータ抽出処理Ｓ１８００は、前回のメタデータ抽出処理Ｓ１８００からの一定時間の経過、メタデータ抽出対象リストのエントリが一定数以上貯まること等を契機として開始する（Ｓ１８０１）。

まず、メタデータ抽出プログラム２１２Ｅは、メタデータ抽出対象リストを取得する（Ｓ１８０２）。

Ｓ１８０３では、メタデータ抽出プログラム２１２Ｅは、Ｓ１８０２で取得したメタデータ抽出対象リストのうちに未処理のエントリがあるかを確認する。メタデータ抽出プログラム２１２Ｅは、未処理のエントリがある場合、Ｓ１８０４に処理を移し、未処理のエントリがない場合、処理を終了する（Ｓ１８０９）。

Ｓ１８０４では、メタデータ抽出プログラム２１２Ｅは、Ｓ１８０２で取得したメタデータ抽出対象リストから未処理のエントリのうち１つを選択し、処理対象として設定する。

次に、メタデータ抽出プログラム２１２Ｅは、処理対象のエントリのＵＵＩＤおよびバージョンが指定するユーザファイル２０１にアクセスしたり、オペレーションログ２０５を解析したりして、当該ユーザファイル２０１のメタデータを抽出する（Ｓ１８０５）。

次に、メタデータ抽出プログラム２１２Ｅは、対象のユーザファイル２０１に対応する管理情報ファイル２０４のメタデータ抽出済みフラグを「Ｔｒｕｅ」に更新し、メタデータＤＢ２０３のレコードに関して、抽出したメタデータを登録する（Ｓ１８０６）。

次に、メタデータ抽出プログラム２１２Ｅは、対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持つ他拠点１１０のユーザファイル２０１について、対応するメタデータＤＢ２０３のレコードに抽出したメタデータを登録する（Ｓ１８０７）。

次に、メタデータ抽出プログラム２１２Ｅは、オペレーションログ２０５に対象のユーザファイル２０１へのメタデータ抽出の実施内容を追記し（Ｓ１８０８）、Ｓ１８０３に処理を移す。

＜レプリケーション処理＞
図１９は、レプリケーション処理Ｓ１９００の一例を説明するためのフローチャートである。

レプリケーション処理Ｓ１９００は、前回のレプリケーション処理Ｓ１９００からの一定時間の経過、レプリケーション対象リストのエントリが一定数以上貯まること等を契機として開始する（Ｓ１９０１）。

まず、ファイル仮想化プログラム２１２Ａは、レプリケーション対象リストを取得する（Ｓ１９０２）。

Ｓ１９０３では、ファイル仮想化プログラム２１２Ａは、Ｓ１９０２で取得したレプリケーション対象リストのうちに未処理のエントリがあるかを確認する。ファイル仮想化プログラム２１２Ａは、未処理のエントリがある場合、Ｓ１９０４に処理を移し、未処理のエントリがない場合、処理を終了する（Ｓ１９１２）。

Ｓ１９０４では、ファイル仮想化プログラム２１２Ａは、Ｓ１９０２で取得したレプリケーション対象リストから未処理のエントリのうち１つを選択し、処理対象として設定する。

次に、ファイル仮想化プログラム２１２Ａは、処理対象のエントリのＵＵＩＤおよびバージョンが指定するユーザファイル２０１について、対応する管理情報ファイル２０４から部分状態が「Ｄｉｒｔｙ」の部分を特定し、データを読み出す（Ｓ１９０５）。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１について、対応する管理情報ファイル２０４からＲｅｐｌｉｃａ保持拠点を特定し、対象のユーザファイル２０１のＵＵＩＤ、バージョン、Ｄｉｒｔｙ部（部分状態が「Ｄｉｒｔｙ」であるオフセットおよびサイズ）の情報、およびＳ１９０５で読み出したＤｉｒｔｙ部のデータを含む、更新反映リクエストを転送する（Ｓ１９０６）。例えば、図４の例において、ファイル仮想化プログラム２１２Ａは、ＵＵＩＤ「ＡＡＡＡ」およびバージョン「２」のユーザファイル２０１にＤｉｒｔｙ部がある場合、ＵＵＩＤ「ＡＡＡＡ」およびバージョン「１」のエントリを参照し、Ｒｅｐｌｉｃａ保持拠点として「拠点３」を特定する。

次に、Ｓ１９０６で転送された更新反映リクエストを受信した他拠点１１０にて、ファイル仮想化プログラム２１２Ａは、指定されたＵＵＩＤおよびバージョンのユーザファイル２０１に対し、指定のＤｉｒｔｙ部に受信したデータを書き込み、更新反映リクエストへの完了応答を送信する（Ｓ１９０７）。

次に、ファイル仮想化プログラム２１２Ａは、Ｓ１９０７で送信された完了応答を受信する（Ｓ１９０８）。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４のＤｉｒｔｙ部の部分状態を「Ｃａｃｈｅ」に更新し、メタデータＤＢ２０３の対応するレコードと、管理情報ファイル２０４の対応するレコードとに関して更新反映に成功した拠点１１０をＲｅｐｌｉｃａ保持拠点に追加する（Ｓ１９０９）。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持つ他拠点１１０のユーザファイル２０１について、対応するメタデータＤＢ２０３のレコードと管理情報ファイル２０４のレコードとに、拠点１１０が追加されたことを更新する（Ｓ１９１０）。

次に、ファイル仮想化プログラム２１２Ａは、オペレーションログ２０５に対象のユーザファイル２０１へのレプリケーションの実施内容を追記し（Ｓ１９１１）、Ｓ１９０３に処理を移す。

＜スタブ化処理＞
図２０は、スタブ化処理Ｓ２０００の一例を説明するためのフローチャートである。

スタブ化処理Ｓ２０００は、拠点１１０のファイル・オブジェクトストレージ１１２の空き容量の割合が一定値を下回る等を契機として開始する（Ｓ２００１）。

まず、ファイル仮想化プログラム２１２Ａは、メタデータＤＢ２０３からファイル状態４０４がＯｒｉｇｉｎａｌ状態、Ｓｔｕｂ状態、またはＣａｃｈｅ状態のいずれかであるユーザファイル２０１を抽出し、スタブ化候補ファイルリストを作成する（Ｓ２００２）。

Ｓ２００３では、ファイル仮想化プログラム２１２Ａは、Ｓ２００２で作成したスタブ化候補ファイルリストのうちに未処理のエントリがあるかを確認する。ファイル仮想化プログラム２１２Ａは、未処理のエントリがある場合、Ｓ２００４に処理を移し、未処理のエントリがない場合、処理を終了する（Ｓ２０１７）。

Ｓ２００４では、ファイル仮想化プログラム２１２Ａは、Ｓ２００２で作成したスタブ化候補ファイルリストから未処理のエントリのうち１つを選択し、処理対象として設定する。

Ｓ２００５では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１の最終参照日時からの経過時間が一定値（基準値）を超えることを確認する。ファイル仮想化プログラム２１２Ａは、最終参照日時からの経過時間が一定値を超える場合、Ｓ２００６に処理を移し、最終参照日時からの経過時間が一定値を超えない場合、Ｓ２００３に処理を移す。

Ｓ２００６では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１に対応する管理情報ファイル２０４から、ファイル状態がＣａｃｈｅ状態またはＳｔｕｂ状態であるかを確認する。ファイル仮想化プログラム２１２Ａは、ファイル状態がＣａｃｈｅ状態またはＳｔｕｂ状態である場合、Ｓ２００７に処理を移し、ファイル状態がＣａｃｈｅ状態でもＳｔｕｂ状態でもない場合、Ｓ２００９に処理を移す。

Ｓ２００７では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１からデータを削除し、対象のユーザファイル２０１に対応する、管理情報ファイル２０４のレコードについて、全ての部分状態が「Ｓｔｕｂ」となったことと、ファイル状態がＳｔｕｂ状態となったこととを反映し、メタデータＤＢ２０３のレコードについて、ファイル状態がＳｔｕｂ状態となったことを反映する。

次に、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持つ他拠点１１０のユーザファイル２０１について、対応するメタデータＤＢ２０３のレコードと、対応する管理情報ファイル２０４のレコードとに、ファイル状態がＳｔｕｂ状態となったことを反映し（Ｓ２００８）、Ｓ２０１５処理を移す。

Ｓ２００９では、ファイル仮想化プログラム２１２Ａは、全拠点１１０のメタデータ検索プログラム２１２Ｄに問い合わせ、メタデータＤＢ２０３より対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持ち、ファイル状態がＳｔｕｂ状態またはＣａｃｈｅ状態である他拠点１１０のユーザファイル２０１を発見し、発見したユーザファイル２０１の最終参照日時を取得する。

次に、ファイル仮想化プログラム２１２Ａは、Ｓ２００９で発見したファイル状態がＳｔｕｂ状態またはＣａｃｈｅ状態であるユーザファイル２０１の中に、ファイル状態がＯｒｉｇｉｎａｌ状態である対象のユーザファイル２０１より最終参照日時が新しいものがあるかを確認する（Ｓ２０１０）。ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１より最終更新日時が新しいＳｔｕｂ状態またはＣａｃｈｅ状態のユーザファイル２０１がある場合、Ｓ２０１１に処理を移し、対象のユーザファイル２０１より最終更新日時が新しいＳｔｕｂ状態またはＣａｃｈｅ状態のユーザファイル２０１がない場合、Ｓ２００３に処理を移す。

Ｓ２０１１では、ファイル仮想化プログラム２１２Ａは、Ｓ２００９で発見したファイル状態がＳｔｕｂ状態またはＣａｃｈｅ状態であるユーザファイル２０１の中で、最終参照日時が最も新しいユーザファイル２０１のファイル状態がＳｔｕｂ状態であるかを確認する。ファイル仮想化プログラム２１２Ａは、ファイル状態がＳｔｕｂ状態である場合、Ｓ２０１２に処理を移し、ファイル状態がＳｔｕｂ状態でない場合、Ｓ２０１３に処理を移す。

Ｓ２０１２では、ファイル仮想化プログラム２１２Ａは、ファイル状態がＯｒｉｇｉｎａｌ状態である対象のユーザファイル２０１の全データを、Ｓ２００９で発見したファイル状態がＳｔｕｂ状態またはＣａｃｈｅ状態であるユーザファイル２０１の中で最終参照日時が最も新しいＳｔｕｂ状態のユーザファイル２０１を保持する拠点１１０に転送し、データを書き込み、Ｓ２０１３に処理を移す。

Ｓ２０１３では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１をＳｔｕｂ状態へと移行し、Ｓ２００９で発見したファイル状態がＳｔｕｂ状態またはＣａｃｈｅ状態であるユーザファイル２０１の中で最終参照日時が最も新しいユーザファイル２０１をＯｒｉｇｉｎａｌ状態に移行する。ファイル仮想化プログラム２１２Ａは、この移行を反映するため、全ての拠点１１０で対象のユーザファイル２０１と同一のＵＵＩＤおよびバージョンを持つユーザファイル２０１について、メタデータＤＢ２０３の対応するレコードと管理情報ファイル２０４の対応するレコードとを更新し、Ｓ２０１４に処理を移す。

Ｓ２０１４では、ファイル仮想化プログラム２１２Ａは、対象のユーザファイル２０１のデータを削除する。

次に、ファイル仮想化プログラム２１２Ａは、オペレーションログ２０５に対象のユーザファイル２０１へのスタブ化の実施内容を追記する（Ｓ２０１５）。

次に、ファイル仮想化プログラム２１２Ａは、スタブ化処理Ｓ２０００の中で十分な空き領域を確保できたかを確認する（Ｓ２０１６）。ファイル仮想化プログラム２１２Ａは、十分な空き領域を確保できた場合、処理を終了し（Ｓ２０１７）、十分な空き領域を確保できていない場合、Ｓ２００３に処理を移す。

なお、ファイル仮想化プログラム２１２Ａは、十分な空き容量を得る前にＳ２００３でスタブ化候補ファイルリストから未処理エントリがなくなり処理を終了した場合、目標の空き容量を得るため、スタブ化を行う際の最終参照日時からの経過時間の基準値（条件）をより小さな時間に緩和して、再度スタブ化処理Ｓ２０００を行っても構わない。

このように構成される本実施の形態によれば、拠点１１０ごとのファイル・オブジェクトストレージ１１２は、他拠点１１０のファイル・オブジェクトストレージ１１２のＯｒｉｇｉｎａｌ状態のユーザファイル２０１の全てに対し、Ｓｔｕｂ状態のユーザファイル２０１を作る必要はなく、転送が必要なＯｒｉｇｉｎａｌ状態のユーザファイル２０１に絞ってＳｔｕｂ状態のユーザファイル２０１を作成することができる。

したがって、本実施の形態によれば、拠点１１０間で全てのユーザファイル２０１のスタブ情報を保持し合うための、ストレージの記憶容量が削減できる。また拠点１１０の追加時には、新しい拠点１１０でのスタブ情報の作成を不要化し、拠点１１０の立ち上げ時間を低減する。また、メタデータの更新時のグローバルロックが不要となり、クライアント端末１１１への応答性能を改善する。

なお、上記した実施の形態は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施の形態の構成の一部について、他の構成に追加、削除、置換することが可能である。

（ＩＩ）付記
上述の実施の形態には、例えば、以下のような内容が含まれる。

上述の実施の形態においては、本発明をストレージシステムに適用するようにした場合について述べたが、本発明はこれに限らず、この他種々のシステム、装置、方法、プログラムに広く適用することができる。

また、上述の実施の形態においては、拠点間横断メタデータ検索結果応答９００から所望のユーザファイル２０１を選択する場合について述べたが、本発明はこれに限らない。例えば、他拠点１１０のユーザファイル２０１およびユーザディレクトリ２０２を参照して所望のユーザファイル２０１を選択するようにしてもよい。

また、上述の実施の形態において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。

また、上述の実施の形態において、説明の便宜上、ＸＸテーブル、ＸＸファイルを用いて各種のデータを説明したが、データ構造は限定されるものではなく、ＸＸ情報等と表現してもよい。

上述した実施の形態は、例えば、以下の特徴的な構成を備える。

（１）それぞれがファイルシステムを提供するストレージ（例えば、ファイル・オブジェクトストレージ１１２）を備える複数の拠点（例えば、拠点１１０）間でファイル（例えば、ユーザファイル２０１）を共有可能なストレージシステム（例えば、ストレージシステム１００）であって、上記ストレージは、ファイルのデータを記憶した記憶装置（例えば、記憶装置２２０）と、上記記憶装置に接続されたコントローラ（例えば、コントローラ２１０）と、を備え、上記ファイル（例えば、Ｏｒｉｇｉｎａｌ状態のユーザファイル２０１（オリジナルファイル））と関連付けられ、上記ファイルを参照する関連ファイル（例えば、オリジナルファイル以外のファイル、スタブファイル（スタブ情報）、換言するならば、オリジナルファイルがないと存在できないファイル）を有し、上記コントローラは、上記ファイルが更新される場合に、上記関連ファイルからの参照状況に基づいて、上記ファイルおよび関連ファイルを更新し（例えば、図１６参照）、上記コントローラは、他拠点において記憶されているファイルに係るアクセス要求（例えば、リード要求、他拠点のファイルを選択する操作）を受け付けた場合に、上記他拠点に問い合わせを行い、上記アクセス要求にかかるファイルにアクセスするための関連ファイルを上記アクセス要求を受けたコントローラにかかる拠点に作成する（例えば、Ｓ１２０２）。

（２）上記アクセス要求が検索要求の場合、上記検索要求を受け付けた第１の拠点のストレージのコントローラは、上記複数の拠点のストレージに検索クエリ（例えば、拠点間横断メタデータ検索の検索クエリ）を送信し（例えば、Ｓ１００２）、上記検索クエリを受信したストレージのコントローラは、上記検索クエリに対応するファイルのメタデータを上記第１の拠点のストレージに送信し（例えば、Ｓ１１０３）、上記第１の拠点のストレージのコントローラは、上記複数の拠点から送信された上記検索クエリに対応するファイルのメタデータに基づいて、上記ファイルを参照する関連ファイルを作成する。

例えば、メタデータが要求元（例えば、クライアント端末１１１）に送信され、要求元で確認されたメタデータに対応する関連ファイルが作成されてもよいし、要求元で要求元への確認なく、検索ヒットしたメタデータ全てについて関連ファイルが作成されてもよい。

上記構成では、例えば、要求元による確認がなくとも、検索クエリに基づいてファイルを共有することができる。

（３）上記第１の拠点のストレージのコントローラは、上記複数の拠点から送信された上記検索クエリに対応するファイルのメタデータを上記検索要求の要求元に送信し（例えば、Ｓ１００５）、上記検索クエリに対応するファイルにアクセスする要求を上記検索要求の要求元から受け付けた場合（例えば、Ｓ１２０１）、上記ファイルを参照する関連ファイルを作成する。

上記構成では、検索クエリが全ての拠点において実行されるので、例えば、ユーザは、所望するファイルが記憶されている拠点を把握して、ファイルを適切に共有することができる。

（４）上記複数の拠点の各々のストレージの記憶装置は、自拠点に記憶しているファイルおよび関連ファイルのメタデータを記憶するメタデータＤＢ（例えば、メタデータＤＢ２０３）を備え、上記検索クエリを受信したストレージのコントローラは、上記検索クエリに対応するファイルのメタデータを上記メタデータＤＢから取得して上記第１の拠点のストレージに送信する（例えば、図１１参照）。

上記構成では、各拠点にメタデータＤＢが設けられているので、例えば、ストレージは、検索クエリに対応するファイルのメタデータを容易かつ迅速に取得することができる。

（５）上記複数の拠点の各々のストレージの記憶装置は、上記メタデータＤＢに記憶されているメタデータに対するメタデータアクセス権と、記憶しているファイルのデータに対するデータアクセス権とを管理するためのアクセス権管理情報（例えば、アクセス権管理表２０６）を記憶し（例えば、図７参照）、上記検索クエリを受信したストレージのコントローラは、上記検索クエリに対応するファイルのメタデータを上記メタデータＤＢから取得し、取得したメタデータのうち、上記アクセス権管理情報に基づいてメタデータアクセス権があると判定したメタデータを上記第１の拠点のストレージに送信し（例えば、図１１参照）、上記ファイルのデータのアクセスが指示（例えば、リード操作、ライト操作等が要求）されたストレージのコントローラは、上記アクセス権管理情報に基づいて上記ファイルのデータに対してデータアクセス権があると判定したとき、上記ファイルのデータを自拠点または他拠点から取得して上記アクセスの要求元に送信する（例えば、図１４、図１６参照）。

上記構成によれば、例えば、「所定のユーザには、検索結果（メタデータ）を見せない」、「所定のユーザには、このようなファイルがあるといった検索ができるが、ファイルのデータ（実データ）には、アクセスさせない」といった制御ができるようになる。なお、料金を支払う、管理者からアクセス権が与えられる等のステップを踏むことで、メタデータおよびファイルのデータにアクセスできるようになる。

（６）上記ファイルが更新された場合に、上記ファイルを参照する関連ファイルも更新される（例えば、Ｓ１６０５、Ｓ１６０７）。

上記構成によれば、例えば、オリジナルファイルが更新された場合に関連ファイルも更新されるので、オリジナルファイルと関連ファイルとの整合性を保つことができる。

上記ストレージのコントローラは、他拠点のファイルに対するデータの更新をクライアント端末から受け付けた場合、上記他拠点のファイルに対応するファイルを作成し、作成したファイルに対してデータを更新してもよい（例えば、Ｓ１６０４）。例えば、他拠点のファイル（オリジナルファイル）を参照している人がいるときに、勝手にオリジナルファイルが更新されると、その人にとって不都合が生じる。この点、上記構成によれば、オリジナルファイルを破壊することなく、オリジナルファイルに対応するファイル（バージョンの異なるファイル、複製したファイル等）を作成することで、他拠点とのデータの整合性を保つことができる。

（７）上記ファイルが上記関連ファイルから参照されている場合には、更新前のファイルを残してファイルを更新し（例えば、Ｓ１６０４）、上記ファイルのデータを、更新前のファイルと更新後のファイルとを選択して取得して上記関連ファイルを更新可能である（例えば、Ｓ１４１１）。

上記構成では、ファイル（オリジナルファイル）のデータを更新する際、例えば、バージョンが異なるファイルが作成されて当該ファイルにデータが更新される。例えば、上記構成によれば、他拠点のファイルのデータが取得される際、当該ファイルのバージョンが指定されるので、データを更新している途中の一貫性のないデータが取得されてしまう事態を回避できるようになる。

（８）上記ファイルを参照する頻度（例えば、最終参照日時）が、他拠点の上記関連ファイルが参照される頻度（例えば、最終参照日時）よりも低い（例えば、新しい）場合、上記ファイルと上記関連ファイルとを入れ替える（例えば、図２０参照）。

上記構成では、ファイルの参照頻度に応じて、例えば、自拠点のファイルと他拠点のファイルとの位置づけ（オリジナルファイル）が入れ替わるので、２重にデータを持たなくてよくなり、システム全体として、データ量を削減することができる。

（９）上記関連ファイルはデータを有さないスタブファイル（例えば、Ｓｔｕｂ状態のユーザファイル２０１）として作成され、上記アクセス要求とは非同期に上記ファイルからデータを取得する（例えば、図１２、図１３参照）。

他拠点のファイルへのアクセスがあるたびに、他拠点からデータを取得すると、データの読み込みに時間がかかる。上記構成では、例えば、スタブファイルに基づいて他拠点のファイルのデータを事前に取得することで、データが自拠点にあるので、アクセス要求の要求元にデータを迅速に提供することができる。

（１０）上記ファイルには、ＵＵＩＤ（ＵｎｉｖｅｒｓａｌｌｙＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ）およびバージョンが対応付けられ（例えば、図２参照）、上記ストレージのコントローラは、上記ＵＵＩＤおよび上記バージョンを対応付けて関連ファイルを作成し、自拠点における上記関連ファイルのファイルパスを示す情報を作成する（例えば、図５参照）。

上記特許文献１に記載の技術では、ディレクトリの操作時に、拠点間のグローバルロックを取得して関連ファイルを持ち合う複数の拠点に更新を反映するため、クライアント端末における操作への応答性能低下を招く。この点、上記構成では、ＵＵＩＤおよびバージョン（実パス）によりファイルが特定されるので、拠点間でファイルの異なる仮想パスを用いることができる。このように、実パスが一貫していれば、同じファイルにアクセスできるので、仮に、自拠点でファイル名（仮想パス）がリネームされたとしても、他拠点に、そのファイル名を反映させる必要がなく、グローバルロックをとる必要がなくなる。これにより、ファイルシステムにおけるディレクトリの操作時の応答性能を改善することができる。

（１１）上記複数の拠点の各々のストレージの記憶装置は、拠点間の接続状態を管理するための拠点間接続管理情報（例えば、拠点間接続管理表２０７）を記憶し（例えば、図８参照）、上記ファイルのデータを全て含む拠点を示すデータ拠点情報（例えば、Ｃａｃｈｅ保持拠点４０７、Ｒｅｐｌｉｃａ保持拠点４０８）を有し、上記ストレージのコントローラは、上記データ拠点情報と上記拠点間接続管理情報とに基づいて、上記ファイルのデータを取得する拠点を決定し（例えば、図１５参照）、決定した拠点から上記データを取得する。

上記構成では、拠点間接続管理情報に基づいてファイルのデータの取得先の拠点が決定されるので、例えば、拠点間の帯域幅、レイテンシ、課金情報等を拠点間接続管理情報に規定することで、データを最適に取得することができる。

「Ａ、Ｂ、およびＣのうちの少なくとも１つ」という形式におけるリストに含まれる項目は、（Ａ）、（Ｂ）、（Ｃ）、（ＡおよびＢ）、（ＡおよびＣ）、（ＢおよびＣ）または（Ａ、Ｂ、およびＣ）を意味することができると理解されたい。同様に、「Ａ、Ｂ、またはＣのうちの少なくとも１つ」の形式においてリストされた項目は、（Ａ）、（Ｂ）、（Ｃ）、（ＡおよびＢ）、（ＡおよびＣ）、（ＢおよびＣ）または（Ａ、Ｂ、およびＣ）を意味することができる。

１００……ストレージシステム、１１０……拠点、１１１……クライアント端末、１１２……ファイル・オブジェクトストレージ（ストレージ）。

Claims

それぞれがファイルシステムを提供するストレージを備える複数の拠点間でファイルを共有可能なストレージシステムであって、
前記ストレージは、ファイルのデータを記憶した記憶装置と、前記記憶装置に接続されたコントローラと、を備え、
前記ファイルと関連付けられ、前記ファイルを参照する関連ファイルを有し、
前記コントローラは、前記ファイルが更新される場合に、前記関連ファイルからの参照状況に基づいて、前記ファイルおよび関連ファイルを更新し、
前記コントローラは、他拠点において記憶されているファイルに係るアクセス要求を受け付けた場合に、前記他拠点に問い合わせを行い、前記アクセス要求にかかるファイルにアクセスするための関連ファイルを前記アクセス要求を受けたコントローラにかかる拠点に作成する、
ストレージシステム。
前記アクセス要求が検索要求の場合、前記検索要求を受け付けた第１の拠点のストレージのコントローラは、前記複数の拠点のストレージに検索クエリを送信し、
前記検索クエリを受信したストレージのコントローラは、前記検索クエリに対応するファイルのメタデータを前記第１の拠点のストレージに送信し、
前記第１の拠点のストレージのコントローラは、前記複数の拠点から送信された前記検索クエリに対応するファイルのメタデータに基づいて、前記ファイルを参照する関連ファイルを作成する、
請求項１に記載のストレージシステム。
前記第１の拠点のストレージのコントローラは、前記複数の拠点から送信された前記検索クエリに対応するファイルのメタデータを前記検索要求の要求元に送信し、
前記検索クエリに対応するファイルにアクセスする要求を前記検索要求の要求元から受け付けた場合、前記ファイルを参照する関連ファイルを作成する、
請求項２に記載のストレージシステム。
前記複数の拠点の各々のストレージの記憶装置は、自拠点に記憶しているファイルおよび関連ファイルのメタデータを記憶するメタデータＤＢを備え、
前記検索クエリを受信したストレージのコントローラは、前記検索クエリに対応するファイルのメタデータを前記メタデータＤＢから取得して前記第１の拠点のストレージに送信する、
請求項２に記載のストレージシステム。
前記複数の拠点の各々のストレージの記憶装置は、前記メタデータＤＢに記憶されているメタデータに対するメタデータアクセス権と、記憶しているファイルのデータに対するデータアクセス権とを管理するためのアクセス権管理情報を記憶し、
前記検索クエリを受信したストレージのコントローラは、前記検索クエリに対応するファイルのメタデータを前記メタデータＤＢから取得し、取得したメタデータのうち、前記アクセス権管理情報に基づいてメタデータアクセス権があると判定したメタデータを前記第１の拠点のストレージに送信し、
前記ファイルのデータのアクセスが指示されたストレージのコントローラは、前記アクセス権管理情報に基づいて前記ファイルのデータに対してデータアクセス権があると判定したとき、前記ファイルのデータを自拠点または他拠点から取得して前記アクセスの要求元に送信する、
請求項４に記載のストレージシステム。
前記ファイルが更新された場合に、前記ファイルを参照する関連ファイルも更新される、
請求項１に記載のストレージシステム。
前記ファイルが前記関連ファイルから参照されている場合には、更新前のファイルを残してファイルを更新し、
前記ファイルのデータを、更新前のファイルと更新後のファイルとを選択して取得して前記関連ファイルを更新可能であることを特徴とする、
請求項６に記載のストレージシステム。
前記ファイルを参照する頻度が、他拠点の前記関連ファイルが参照される頻度よりも低い場合、前記ファイルと前記関連ファイルとを入れ替える、
請求項６に記載のストレージシステム。
前記関連ファイルはデータを有さないスタブファイルとして作成され、前記アクセス要求とは非同期に前記ファイルからデータを取得する、
請求項１に記載のストレージシステム。
前記ファイルには、ＵＵＩＤ（ＵｎｉｖｅｒｓａｌｌｙＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ）およびバージョンが対応付けられ、
前記ストレージのコントローラは、前記ＵＵＩＤおよび前記バージョンを対応付けて関連ファイルを作成し、自拠点における前記関連ファイルのファイルパスを示す情報を作成する、
請求項１に記載のストレージシステム。
前記複数の拠点の各々のストレージの記憶装置は、拠点間の接続状態を管理するための拠点間接続管理情報を記憶し、
前記ファイルのデータを全て含む拠点を示すデータ拠点情報を有し、
前記ストレージのコントローラは、前記データ拠点情報と前記拠点間接続管理情報とに基づいて、前記ファイルのデータを取得する拠点を決定し、決定した拠点から前記データを取得する、
請求項１に記載のストレージシステム。
前記ファイルは、オリジナル状態のファイルであり、
前記関連ファイルには、スタブ状態のファイル、キャッシュ状態のファイル、レプリカ状態のファイルが含まれる、
請求項１に記載のストレージシステム。
それぞれがファイルシステムを提供するストレージを備える複数の拠点間でファイルを共有可能なストレージシステムにおけるデータ管理方法であって、
前記ストレージは、ファイルのデータを記憶した記憶装置と、前記記憶装置に接続されたコントローラと、を備え、
前記ストレージシステムは、前記ファイルと関連付けられ、前記ファイルを参照する関連ファイルを有し、
前記コントローラが、前記ファイルが更新される場合に、前記関連ファイルからの参照状況に基づいて、前記ファイルおよび関連ファイルを更新することと、
前記コントローラが、他拠点において記憶されているファイルに係るアクセス要求を受け付けた場合に、前記他拠点に問い合わせを行い、前記アクセス要求にかかるファイルにアクセスするための関連ファイルを前記アクセス要求を受けたコントローラにかかる拠点に作成することと、
を含むデータ管理方法。