IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧

特許7391826ストレージシステムおよびデータ管理方法
<>
  • 特許-ストレージシステムおよびデータ管理方法 図1
  • 特許-ストレージシステムおよびデータ管理方法 図2
  • 特許-ストレージシステムおよびデータ管理方法 図3
  • 特許-ストレージシステムおよびデータ管理方法 図4
  • 特許-ストレージシステムおよびデータ管理方法 図5
  • 特許-ストレージシステムおよびデータ管理方法 図6
  • 特許-ストレージシステムおよびデータ管理方法 図7
  • 特許-ストレージシステムおよびデータ管理方法 図8
  • 特許-ストレージシステムおよびデータ管理方法 図9
  • 特許-ストレージシステムおよびデータ管理方法 図10
  • 特許-ストレージシステムおよびデータ管理方法 図11
  • 特許-ストレージシステムおよびデータ管理方法 図12
  • 特許-ストレージシステムおよびデータ管理方法 図13
  • 特許-ストレージシステムおよびデータ管理方法 図14
  • 特許-ストレージシステムおよびデータ管理方法 図15
  • 特許-ストレージシステムおよびデータ管理方法 図16
  • 特許-ストレージシステムおよびデータ管理方法 図17
  • 特許-ストレージシステムおよびデータ管理方法 図18
  • 特許-ストレージシステムおよびデータ管理方法 図19
  • 特許-ストレージシステムおよびデータ管理方法 図20
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-27
(45)【発行日】2023-12-05
(54)【発明の名称】ストレージシステムおよびデータ管理方法
(51)【国際特許分類】
   G06F 16/185 20190101AFI20231128BHJP
   G06F 16/907 20190101ALI20231128BHJP
【FI】
G06F16/185
G06F16/907
【請求項の数】 14
(21)【出願番号】P 2020214534
(22)【出願日】2020-12-24
(65)【公開番号】P2022100514
(43)【公開日】2022-07-06
【審査請求日】2021-12-24
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110002365
【氏名又は名称】弁理士法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】早坂 光雄
(72)【発明者】
【氏名】野村 鎮平
(72)【発明者】
【氏名】鴨生 悠冬
(72)【発明者】
【氏名】長崎 英紀
(72)【発明者】
【氏名】志賀 賢太
【審査官】酒井 恭信
(56)【参考文献】
【文献】特開2020-095340(JP,A)
【文献】特開2001-051890(JP,A)
【文献】特開平08-328933(JP,A)
【文献】特開2004-118482(JP,A)
【文献】米国特許出願公開第2011/0145363(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00 - 16/958
(57)【特許請求の範囲】
【請求項1】
それぞれがファイルシステムを提供するストレージを備える複数の拠点間でファイルを共有可能なストレージシステムであって、
複数のストレージの各々は、ファイルのデータを記憶した記憶装置と、前記記憶装置に接続されたコントローラと、を備え、
前記複数のストレージの各々は、自拠点において、他拠点のファイルと関連付けられ当該他拠点のファイルを参照する関連ファイルと、自拠点におけるファイルの管理情報ファイルと、自拠点のファイルおよび関連ファイルと関連するメタデータを記憶するメタデータデータベースとを有し、
前記コントローラは、自拠点内のファイルと関連ファイルとを管理し、自拠点における第1のファイルが更新される場合に、当該第1のファイルについて他拠点の第1の関連ファイルからの参照状況に基づいて、当該第1のファイルおよび当該第1のファイルの管理情報ファイルを更新し、自拠点におけるメタデータデータベースを更新し、
前記コントローラは、他拠点において記憶されている第2のファイルに係るアクセス要求を受け付けた場合に、複数の他拠点に問い合わせを行い、前記複数の他拠点のメタデータデータベースは、当該第2のファイルおよび当該第2のファイルの管理情報ファイルの更新を反映することに関して更新されていない状態にあり、
前記問い合わせを受け取る拠点のコントローラは、前記問い合わせを受け取ると、前記第2のファイルおよび前記第2のファイルの管理情報ファイルの更新を反映するためにメタデータデータベースを更新し、前記第2のファイルおよび前記第2のファイルの管理情報ファイルの更新が反映されたメタデータデータベースに基づいて、前記問い合わせ元の拠点のコントローラに応答を返し、
前記問い合わせ元の拠点のコントローラは、前記応答に基づいて、前記アクセス要求にかかる第2のファイルにアクセスするための第2の関連ファイルを当該コントローラの自拠点に作成し、作成した当該第2の関連ファイルに基づいて前記第2のファイルのデータを関連付ける、
ストレージシステム。
【請求項2】
前記アクセス要求が検索要求の場合、前記検索要求を受け付けた第1の拠点のストレージのコントローラは、前記複数の他拠点のストレージに検索クエリを送信し、
前記検索クエリを受信したストレージのコントローラは、前記検索クエリに対応する第2のファイルのメタデータを前記第1の拠点のストレージに送信し、
前記第1の拠点のストレージのコントローラは、前記複数の他拠点の少なくとも1つから送信された前記検索クエリに対応するファイルのメタデータに基づいて、前記第2のファイルを参照する第2の関連ファイルを作成する、
請求項1に記載のストレージシステム。
【請求項3】
前記第1の拠点のストレージのコントローラは、前記複数の他拠点の少なくとも1つから送信された前記検索クエリに対応する第2のファイルのメタデータを前記検索要求の要求元に送信し、
前記検索クエリに対応する第2のファイルにアクセスする要求を前記検索要求の要求元から受け付けた場合、前記ファイルを参照する第2の関連ファイルを作成する、
請求項2に記載のストレージシステム。
【請求項4】
前記検索クエリを受信したストレージのコントローラは、前記検索クエリに対応する第2のファイルのメタデータをメタデータデータベースから取得して前記第1の拠点のストレージに送信する、
請求項2に記載のストレージシステム。
【請求項5】
前記複数の拠点の各々のストレージの記憶装置は、メタデータデータベースに記憶されているメタデータに対するメタデータアクセス権と、記憶しているファイルのデータに対するデータアクセス権とを管理するためのアクセス権管理情報を記憶し、
前記検索クエリを受信したストレージのコントローラは、前記検索クエリに対応する第2のファイルのメタデータをメタデータデータベースから取得し、取得したメタデータのうち、前記アクセス権管理情報に基づいてメタデータアクセス権があると判定したメタデータを前記第1の拠点のストレージに送信し、
前記第2のファイルのデータのアクセスが指示されたストレージのコントローラは、前記アクセス権管理情報に基づいて前記第2のファイルのデータに対してデータアクセス権があると判定したとき、前記第2のファイルのデータを自拠点または他拠点から取得して前記アクセスの要求元に送信する、
請求項4に記載のストレージシステム。
【請求項6】
前記第2のファイルが更新された場合に、前記第2のファイルの管理情報ファイルも更新される、
請求項1に記載のストレージシステム。
【請求項7】
前記第2のファイルが前記第2の関連ファイルから参照されている場合には、更新前の第2のファイルを残して第2のファイルを更新し、
前記第2のファイルのデータを、更新前の第2のファイルと更新後の第2のファイルとを選択して取得して前記第2のファイルの管理情報ファイルを更新可能であることを特徴とする、
請求項6に記載のストレージシステム。
【請求項8】
前記関連ファイルは、スタブ状態のファイルまたはキャッシュ状態のファイルであり、
ファイルをリードする頻度が、当該ファイルを参照する他拠点の関連ファイルがリードされる頻度よりも低い場合、当該ファイルと当該関連ファイルとを入れ替える、
請求項6に記載のストレージシステム。
【請求項9】
前記関連ファイルはデータを有さないスタブファイルとして作成され、前記アクセス要求とは非同期に前記ファイルからデータを取得する、
請求項1に記載のストレージシステム。
【請求項10】
前記ファイルには、UUID(Universally Unique Identifier)およびバージョンが対応付けられ、
前記ストレージのコントローラは、前記UUIDおよび前記バージョンを対応付けてファイルの管理情報ファイルを作成し、自拠点における前記ファイルのファイルパスを示す情報を作成する、
請求項1に記載のストレージシステム。
【請求項11】
前記複数の拠点の各々のストレージの記憶装置は、拠点間の接続状態を管理するための拠点間接続管理情報を記憶し、
前記ファイルのデータを全て含む拠点を示すデータ拠点情報を有し、
前記ストレージのコントローラは、前記データ拠点情報と前記拠点間接続管理情報とに基づいて、前記ファイルのデータを取得する拠点を決定し、決定した拠点から前記データを取得する、
請求項1に記載のストレージシステム。
【請求項12】
前記ファイルは、オリジナル状態のファイルであり、
前記関連ファイルには、スタブ状態のファイル、キャッシュ状態のファイル、レプリカ状態のファイルが含まれる、
請求項1に記載のストレージシステム。
【請求項13】
前記コントローラは、自拠点でファイルを更新する場合、自拠点のメタデータデータベースを更新し、自拠点の当該ファイルを参照する他拠点の関連ファイルの当該他拠点のメタデータデータベースを更新する、
請求項1に記載のストレージシステム。
【請求項14】
それぞれがファイルシステムを提供するストレージを備える複数の拠点間でファイルを共有可能なストレージシステムにおけるデータ管理方法であって、
複数のストレージの各々は、ファイルのデータを記憶した記憶装置と、前記記憶装置に接続されたコントローラと、を備え、
前記複数のストレージの各々は、自拠点において、他拠点のファイルと関連付けられ当該他拠点のファイルを参照する関連ファイルと、自拠点におけるファイルの管理情報ファイルと、自拠点のファイルおよび関連ファイルと関連するメタデータを記憶するメタデータデータベースとを有し、
前記コントローラが、自拠点内のファイルと関連ファイルとを管理し、前記拠点における第1のファイルが更新される場合に、当該第1のファイルについて他拠点の第1の関連ファイルからの参照状況に基づいて、当該第1のファイルおよび当該第1のファイルの管理情報ファイルを更新し、自拠点におけるメタデータデータベースを更新することと、
前記コントローラが、他拠点において記憶されている第2のファイルに係るアクセス要求を受け付けた場合に、複数の他拠点に問い合わせを行うことと、前記複数の他拠点のメタデータデータベースは、当該第2のファイルおよび当該第2のファイルの管理情報ファイルの更新を反映することに関して更新されていない状態にあり、
前記問い合わせを受け取る拠点のコントローラが、前記問い合わせを受け取ると、前記第2のファイルおよび前記第2のファイルの管理情報ファイルの更新を反映するためにメタデータデータベースを更新し、前記第2のファイルおよび前記第2のファイルの管理情報ファイルの更新が反映されたメタデータデータベースに基づいて、前記問い合わせ元の拠点のコントローラに応答を返すことと、
前記問い合わせ元の拠点のコントローラが、前記応答に基づいて、前記第2のファイルにアクセスするための第2の関連ファイルを当該コントローラの自拠点に作成し、作成した当該第2の関連ファイルに基づいて前記第2のファイルのデータを関連付けることと、
を含むデータ管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概して、分散した拠点間でファイルを共有するストレージシステムおよびデータ管理方法に関する。
【背景技術】
【0002】
デジタルデータのデータ量は、急速に増大しており、企業がこれらデータを分析することで、ビジネス上の知見を抽出するためのデータの利活用が推進されている。増大するデジタルデータの中でも大きな比率を占める非構造データについては、ファイルストレージ、オブジェクトストレージ等に収集して分析するのが一般的である。
【0003】
また、オンプレミス、プライベートクラウド、パブリッククラウド等を組み合わせた、ハイブリッドクラウド、マルチクラウドといったシステム形態が普及してきている。こうした複数の拠点にまたがるシステムにおいて生成されるデータを企業が利活用するためには、当該システムでは、分散している各拠点から必要なデータを発見し、分析対象とするデータを自拠点へと転送する機能が必要となる。
【0004】
上記システムは、拠点に設置されたファイル・オブジェクトストレージに格納されたユーザファイルに対して、他拠点のファイル・オブジェクトストレージにはメタデータを保持するスタブ情報を作成する。また、上記システムは、スタブ情報の参照時に他拠点からデータを取得するリコール機能を提供する。加えて、上記システムでは、アクセスの少ないユーザファイルについては、メタデータを残してデータを拠点に設置されたファイル・オブジェクトストレージから削除するスタブ化機能、他拠点のファイル・オブジェクトストレージにユーザファイルをレプリケーションする機能を提供する。これらの拠点に設置されたファイル・オブジェクトストレージが連携して提供するこれらの機能をファイル仮想化機能と呼ぶ。
【0005】
近年、拠点間で各拠点のスタブ情報を持ち合うことでファイルの存在確認を行い、またスタブ情報の参照を検知し、必要なデータブロックを取得する方法が開示されている(特許文献1参照)。また、メタデータの更新については、拠点間の整合性を保つために、グローバルロックが取得される。
【先行技術文献】
【特許文献】
【0006】
【文献】国際公開第2016/121093号
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかし、特許文献1に記載されている技術では、拠点間で記憶するユーザファイルのスタブ情報(例えば、ユーザファイルを参照する関連ファイル)を保持し合うため、ストレージの記憶容量の消費が大きくなる。加えて、拠点の追加時には、新しい拠点で関連ファイルを作成するための他拠点からのデータの取得が必要となり、時間を要する。
【0008】
本発明は、以上の点を考慮してなされたもので、拠点間で、全てのファイルに対する関連ファイルを持ち合うことなく、ファイルを共有可能なストレージシステム等を提案しようとするものである。
【課題を解決するための手段】
【0009】
かかる課題を解決するため本発明においては、それぞれがファイルシステムを提供するストレージを備える複数の拠点間でファイルを共有可能なストレージシステムであって、前記ストレージは、ファイルのデータを記憶した記憶装置と、前記記憶装置に接続されたコントローラと、を備え、前記ファイルと関連付けられ、前記ファイルを参照する関連ファイルを有し、前記コントローラは、前記ファイルが更新される場合に、前記関連ファイルからの参照状況に基づいて、前記ファイルおよび関連ファイルを更新し、前記コントローラは、他拠点において記憶されているファイルに係るアクセス要求を受け付けた場合に、前記他拠点に問い合わせを行い、前記アクセス要求にかかるファイルにアクセスするための関連ファイルを前記アクセス要求を受けたコントローラにかかる拠点に作成する。
【0010】
上記構成では、他拠点において記憶されているファイルに係るアクセス要求に応じて関連ファイルが作成されるので、ストレージは、他の拠点の全てのファイルの関連ファイルを記憶する必要がなく、拠点間におけるファイルの共有に必要な関連ファイルを削減することができる。例えば、各拠点において関連ファイルの記憶に必要な記憶容量と、新たな拠点の追加時に関連ファイルを取得する時間とについて、改善することができる。
【発明の効果】
【0011】
本発明によれば、拠点間で、全てのファイルに対する関連ファイルを持ち合うことなく、ファイルを共有することができる。
【図面の簡単な説明】
【0012】
図1】第1の実施の形態によるストレージシステムに係る構成の一例を示す図である。
図2】第1の実施の形態によるファイル・オブジェクトストレージに係る構成の一例を示す図である。
図3】第1の実施の形態によるユーザファイルおよびユーザディレクトリの一例を示す図である。
図4】第1の実施の形態によるメタデータDBの一例を示す図である。
図5】第1の実施の形態による管理情報ファイルの一例を示す図である。
図6】第1の実施の形態によるオペレーションログの一例を示す図である。
図7】第1の実施の形態によるアクセス権管理表の一例を示す図である。
図8】第1の実施の形態による拠点間接続管理表の一例を示す図である。
図9】第1の実施の形態による拠点間横断メタデータ検索結果応答の一例を示す図である。
図10】第1の実施の形態による拠点間横断メタデータ検索処理の一例を示す図である。
図11】第1の実施の形態による拠点内メタデータ検索処理の一例を示す図である。
図12】第1の実施の形態によるスタブ作成処理の一例を示す図である。
図13】第1の実施の形態によるバックグラウンドデータ取得処理の一例を示す図である。
図14】第1の実施の形態によるファイル参照処理の一例を示す図である。
図15】第1の実施の形態によるデータ取得拠点選択処理の一例を示す図である。
図16】第1の実施の形態によるファイル更新処理の一例を示す図である。
図17】第1の実施の形態によるオペレーションログ解析処理の一例を示す図である。
図18】第1の実施の形態によるメタデータ抽出処理の一例を示す図である。
図19】第1の実施の形態によるレプリケーション処理の一例を示す図である。
図20】第1の実施の形態によるスタブ化処理の一例を示す図である。
【発明を実施するための形態】
【0013】
(I)第1の実施の形態
以下、本発明の一実施の形態を詳述する。ただし、本発明は、実施の形態に限定されるものではない。
【0014】
本発明の1つの観点に従うファイル・オブジェクトストレージは、ユーザファイルのメタデータを管理するメタデータデータベース(メタデータDB)を備える。また、クライアント端末からの検索クエリを受信し、この検索クエリを全拠点に転送して、各拠点のメタデータDBから該当ユーザファイルを検索する。加えて、検索結果から選択されたユーザファイルについて拠点内のファイル・オブジェクトストレージにスタブ情報を作成する。
【0015】
次に、本発明の実施の形態を図面に基づいて説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施することが可能である。特に限定しない限り、各構成要素は、単数でも複数でも構わない。
【0016】
なお、以下の説明では、図面において同一要素については、同じ番号を付し、説明を適宜省略する。また、同種の要素を区別しないで説明する場合には、枝番を含む参照符号のうちの共通部分(枝番を除く部分)を使用し、同種の要素を区別して説明する場合は、枝番を含む参照符号を使用することがある。例えば、拠点を特に区別しないで説明する場合には、「拠点110」と記載し、個々の拠点を区別して説明する場合には、「拠点110-1」、「拠点110-2」のように記載することがある。
【0017】
本明細書等における「第1」、「第2」、「第3」等の表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は、文脈毎に用いられ、1つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。
【0018】
<システム構成>
図1は、本実施の形態におけるストレージシステム100に係る構成の一例を示す図である。
【0019】
本ストレージシステム100は、拠点110-1,110-2,110-3を備える。拠点110間は、WAN(Wide Area Network)であるネットワーク120により接続されている。なお、図1では、3つの拠点110-1,110-2,110-3が図示されているが、本実施の形態において拠点110の数に特段の制限はない。
【0020】
拠点110-1は、クライアント端末111-1と、ファイル・オブジェクトストレージ112-1と、管理端末113-1とを備える。クライアント端末111-1とファイル・オブジェクトストレージ112-1と管理端末113-1とは、例えば、拠点110-1内のLAN(Local Area Network)等のネットワークで相互に接続されている。
【0021】
クライアント端末111は、各種の情報処理が可能なコンピュータ等の情報処理装置である。クライアント端末111は、ファイル・オブジェクトストレージ112にユーザファイルを格納し、ユーザファイルへのリードおよびライトといった各種の操作を行う。ファイル・オブジェクトストレージ112の具体的構成については後述する。管理端末113は、各種の情報処理が可能なコンピュータ等の情報処理装置である。管理端末113は、ファイル・オブジェクトストレージ112の管理を行い、ファイル・オブジェクトストレージ112に異常があった際等に、ファイル・オブジェクトストレージ112に対して各種の操作指示等を行う。
【0022】
拠点110-2および拠点110-3も、クライアント端末111とファイル・オブジェクトストレージ112とを備える。なお、図1に図示する拠点110-1,110-2,110-3のハードウェア構成は、単なる例示であり、少なくともそれぞれ1台のファイル・オブジェクトストレージ112を備える構成であれば、その台数、他のハードウェア構成を備えることに制限はない。
【0023】
<ファイル・オブジェクトストレージ>
図2は、ファイル・オブジェクトストレージ112に係る構成の一例を示す図である。
【0024】
ファイル・オブジェクトストレージ112は、コントローラ210と記憶装置220とを備える。
【0025】
コントローラ210は、プロセッサ211、メモリ212、キャッシュ213、インターフェース214(I/F)、およびインターフェース215(I/F)を備える。
【0026】
プロセッサ211は、コントローラ210およびファイル・オブジェクトストレージ112全体の動作制御を行う。メモリ212は、プロセッサ211の動作制御に用いられるプログラムおよびデータを一時的に記憶する。キャッシュ213は、クライアント端末111からライトされるデータおよび記憶装置220からリードされたデータを一時的に格納する。インターフェース214は、拠点110-1,110-2,110-3内の他のクライアント端末111、ファイル・オブジェクトストレージ112等との間での通信を行う。インターフェース215は、記憶装置220との間での通信を行う。
【0027】
メモリ212には、ファイル仮想化プログラム212A、IO Hookプログラム212B、メタデータDBプログラム212C、メタデータ検索プログラム212D、メタデータ抽出プログラム212E、プロトコル処理プログラム212F、およびバージョン管理プログラム212Gが格納されている。
【0028】
記憶装置220は、プロセッサ221、メモリ222、キャッシュ223、記憶デバイス224、およびインターフェース225(I/F)を備える。
【0029】
プロセッサ221は、記憶装置220の動作制御を行う。メモリ222は、プロセッサ221の動作制御に用いられるプログラムおよびデータを一時的に記憶する。キャッシュ223は、コントローラ210からライトされるデータおよび記憶デバイス224からリードされたデータを一時的に格納する。記憶デバイス224は、各種のファイルを格納する。インターフェース225は、コントローラ210との間での通信を行う。記憶デバイス224には、ユーザファイル201、ユーザディレクトリ202、メタデータDB203、管理情報ファイル204、オペレーションログ205、アクセス権管理表206、および拠点間接続管理表207が格納されている。
【0030】
ファイル仮想化プログラム212Aは、オペレーションログ205の監視、クライアント端末111からの要求に応じて、ユーザファイル201およびユーザディレクトリ202に対する処理(レプリケーション処理またはスタブ化処理またはリコール処理)等を行う。
【0031】
IO Hookプログラム212Bは、クライアント端末111からの要求を受けてプロトコル処理プログラム212Fが発行するユーザファイル201とユーザディレクトリ202とへの処理を監視し、処理が発生した場合には、操作内容のオペレーションログ205への追記、操作に伴うメタデータDB203および管理情報ファイル204の更新等の、管理情報の更新を行う。
【0032】
メタデータDBプログラム212Cは、メタデータDB203を管理する。
【0033】
メタデータ検索プログラム212Dは、クライアント端末111からの検索クエリに基づき、全拠点110のメタデータ検索プログラム212D間で連携し、各拠点110のメタデータDBプログラム212Cにリクエストを行い、メタデータDB203に含まれるユーザファイル201のメタデータの収集と加工とを行う。
【0034】
メタデータ抽出プログラム212Eは、ファイル仮想化プログラム212Aからのリクエストに基づき、ユーザファイル201のデータを解析してメタデータを抽出し、抽出したメタデータをメタデータDB203に登録する。また、メタデータ抽出プログラム212Eは、クライアント端末111からのリクエストに基づき、ユーザファイル201のデータを解析してメタデータを抽出し、抽出したメタデータをメタデータDB203に登録する。本実施の形態では、メタデータDB203に登録するメタデータの一例として、後述の図4を示すが、例えば、写真ファイル中に認識されるオブジェクトの名称、推定される撮影場所の情報を登録する等、登録するメタデータの種類および数について制限されない。
【0035】
プロトコル処理プログラム212Fは、クライアント端末111からの各種の要求を受信し、この要求に含まれるプロトコルを処理する。
【0036】
バージョン管理プログラム212Gは、ファイル・オブジェクトストレージ112に格納されるデータに更新が発生した際に、更新前のデータを残し、バージョン分けして管理するプログラムである。
【0037】
<ファイル格納構成>
図3は、ファイル・オブジェクトストレージ112が格納するユーザファイル201およびユーザディレクトリ202の一例を示す図である。
【0038】
図3では、各拠点110において、クライアント端末111は、ファイル・オブジェクトストレージ112が提供するファイルシステムにデータを格納している。一例として、拠点110-1は、ユーザディレクトリ202-10(ルートディレクトリ)以下に、ユーザディレクトリ202-11,202-12,202-13を備える。ユーザディレクトリ202-11,202-12,202-13は、それぞれにユーザファイル201-12,201-21,201-31を備える。
【0039】
なお、クライアント端末111が、ファイル・オブジェクトストレージ112が提供するファイルシステム上で、ユーザファイル201を操作する例を示しているが、ユーザファイル201の操作は、この例に限らない。例えば、オブジェクトストレージとしてURI(Uniform Resource Identifier)によりユーザファイル201を指定してS3(Simple Storage Service)、Swiftプロトコルで操作を行う形でも構わない。
【0040】
<バージョン管理機能>
また、ファイル・オブジェクトストレージ112は、バージョン管理機能を有し、バージョンの異なるユーザファイル201を指定して操作を行うことができる。一例として、拠点110-1では、ユーザファイル201-12の旧バージョンとしてユーザファイル201-11を備える。原則として、ファイル・オブジェクトストレージ112は、クライアント端末111からの各操作を、最新のユーザファイル201に適用するが、操作時にバージョンを指定することで旧バージョンのユーザファイル201の操作も可能である。なお、本実施の形態では、ファイル・オブジェクトストレージ112でバージョン管理機能を提供するが、例えば、ユーザファイル201の複製を作成するといった方法等で、古いユーザファイル201を残しても構わない。
【0041】
<UUID(Universally Unique Identifier)>
各ユーザファイル201には、UUIDが付与される。異なる拠点110のユーザファイル201と、異なるファイルパスのユーザファイル201とが、UUIDおよびバージョンの双方が同一の値を持つことを許容し、同一のUUIDおよびバージョンを持つユーザファイル201は、同一のデータを参照する。例えば、ユーザファイル201-11とユーザファイル201-41とユーザファイル201-61とは、同一のUUIDおよびバージョンを持つため、クライアント端末111からの参照操作に対し、同一のデータを返す。拠点110間で異なるファイルパスを与えられたユーザファイル201であってもUUIDおよびバージョンにより指し示されるデータが同一であるケースがあるため、本ストレージシステム100では、ファイルパスを仮想的なパス(仮想パス)、UUIDおよびバージョンを実際のデータを特定するパス(実パス)として扱う。
【0042】
<ファイル状態>
同一のUUIDおよびバージョンを持つユーザファイル201は、Original状態、Stub状態、Cache状態、Replica状態の4つのファイル状態に分類される。
【0043】
Original状態は、クライアント端末111が作成したユーザファイル201の最初のファイル状態である。Original状態のユーザファイル201は、ユーザファイル201のデータの全てを備える。Stub状態は、Original状態のユーザファイル201のデータの一部を含み得るファイル状態である。Stub状態のユーザファイル201は、他拠点110のOriginal状態のユーザファイル201を参照するために作成され、ユーザファイル201のデータの全てまたは部分的に有していない。Stub状態のユーザファイル201については、クライアント端末111から非保有データの参照操作を受信した場合、UUIDおよびバージョンを同一とするOriginal状態またはReplica状態のユーザファイル201からデータが取得される。Cache状態は、Stub状態のユーザファイル201がすべてのデータの取得を完了することで遷移しているファイル状態である。Replica状態は、Original状態のユーザファイル201の冗長化データとして、ユーザファイル201に含まれる全てのデータを保持しているファイル状態である。
【0044】
Original状態は、UUIDおよびバージョンが同一のユーザファイル201の中で単一のユーザファイル201のみが持てるファイル状態であり、クライアント端末111によるライト操作を許容する。これにより、ライト操作のたびに同一UUIDおよびバージョンの全てのユーザファイル201のロック取得を回避できる。Stub状態、Cache状態、またはReplica状態のユーザファイル201にクライアント端末111によるライト操作が実施された場合には、異なるUUIDを付与した後にデータを更新する。Cache状態とReplica状態とは、ともに全データを備えるファイル状態である。ただし、Replica状態のユーザファイル201のデータは、データ保護のために破壊することが許されない点で異なる。そのため、Replica状態のユーザファイル201に対するライト操作時には、データを複製して新しいUUIDを付与した後に更新を反映する。一方、Cache状態のユーザファイル201に対するライト操作時には、データを複製することなく、新しいUUIDを付与した後に更新を反映する。
【0045】
なお、本実施の形態では、Stub状態、Cache状態、またはReplica状態のユーザファイル201に対するライト操作時には、異なるUUIDを付与して更新を反映する。ただし、例えば、Stub状態、Cache状態、またはReplica状態のユーザファイル201に対するライト操作を禁止したり、ライト操作時にストレージシステム100内で同一UUIDを持つ全てのユーザファイル201に更新を反映したりする構成でも構わない。
【0046】
<メタデータDB>
図4は、ファイル・オブジェクトストレージ112のメタデータDB203の一例を示す図である。
【0047】
メタデータDB203のエントリは、ファイル・オブジェクトストレージ112内のユーザファイル201ごとに作成される。
【0048】
メタデータDB203のエントリには、UUID401、バージョン402、仮想パス403、ファイル状態404、Original保持拠点405、Stub保持拠点406、Cache保持拠点407、Replica保持拠点408、ファイル種別409、およびキーワード410の情報が含まれる。
【0049】
UUID401には、ユーザファイル201に付与されたUUIDを示す情報が記憶される。バージョン402には、ユーザファイル201のバージョンを示す情報が記憶される。仮想パス403には、ユーザファイル201の仮想パスを示す情報が記憶される。ファイル状態404には、ユーザファイル201のファイル状態を示す情報が記憶される。
【0050】
Original保持拠点405には、UUID401およびバージョン402が同一の値を持ち、ファイル状態がOriginal状態であるユーザファイル201を格納する他拠点110を示す情報が記憶される。Stub保持拠点406には、UUID401およびバージョン402が同一の値を持ち、ファイル状態がStub状態であるユーザファイル201を格納する他拠点110を示す情報が記憶される。Cache保持拠点407には、UUID401およびバージョン402が同一の値を持ち、ファイル状態がCache状態であるユーザファイル201を格納する他拠点110を示す情報が記憶される。Replica保持拠点408には、UUID401およびバージョン402が同一の値を持ち、ファイル状態がReplica状態であるユーザファイル201を格納する他拠点110を示す情報が記憶される。
【0051】
ファイル種別409には、ユーザファイル201のファイル種別を示す情報が記憶される。キーワード410には、ユーザファイル201のデータの内容からメタデータ抽出プログラム212Eにより抽出されたキーワードを示す情報が記憶される。
【0052】
メタデータ抽出プログラム212Eにより抽出し、メタデータDB203に登録する情報の一例としてキーワード410を示したが、例えば、写真ファイル中に認識されるオブジェクトの名称、推定される撮影場所等の情報といったように、キーワード410には、例とは異なる情報が複数記憶されていても構わない。
【0053】
<管理情報ファイル>
図5は、ファイル・オブジェクトストレージ112の管理情報ファイル204の一例を示す図である。
【0054】
管理情報ファイル204は、ファイル・オブジェクトストレージ112内のユーザファイル201ごとに作成される。管理情報ファイル204は、ユーザファイル管理情報510および部分管理情報520を備える。
【0055】
ユーザファイル管理情報510には、UUID511、バージョン512、仮想パス513、ファイル状態514、およびメタデータ抽出済みフラグ515の情報が含まれる。
【0056】
UUID511には、ユーザファイル201に付与されたUUIDを示す情報が記憶される。バージョン512には、ユーザファイル201のバージョンを示す情報が記憶される。仮想パス513には、ユーザファイル201の仮想パスを示す情報が記憶される。ファイル状態514には、ユーザファイル201のファイル状態を示す情報が記憶される。メタデータ抽出済みフラグ515には、ユーザファイル201について後述のメタデータ抽出処理S1800が適用済みであるか否かを示す情報が記憶される。
【0057】
部分管理情報520は、オフセット521とサイズ522とにより表されるユーザファイル201の領域に対応した複数のエントリからなる。部分管理情報520の各エントリには、オフセット521、サイズ522、および部分状態523の情報が含まれる。
【0058】
オフセット521には、エントリが示すユーザファイル201内の領域のオフセットを示す情報が記憶される。サイズ522には、エントリが示すユーザファイル201内の領域のサイズを示す情報が記憶される。部分状態523には、エントリが示すユーザファイル201の領域の部分状態を示す情報が記憶される。
【0059】
部分状態523は、「Cache」と「Stub」と「Dirty」の3つの値のいずれかをとり得る。「Cache」は、対象領域のデータが自拠点110のユーザファイル201に保持されており、UUID511およびバージョン512が同一の値を持ち、ファイル状態がReplica状態である他拠点110のユーザファイル201に対象領域のデータが反映されていることを示す。「Stub」は、対象領域のデータが自拠点110のユーザファイル201に保持されておらず、クライアント端末111からのリード操作時には対象領域のデータを他拠点110からリコールする必要があることを示す。「Dirty」は、対象領域のデータが自拠点110のユーザファイル201に保持されており、UUID511およびバージョン512が同一の値を持ち、ファイル状態がReplica状態である他拠点110のユーザファイル201に対象領域のデータが未反映であることを示す。
【0060】
<オペレーションログ>
図6は、ファイル・オブジェクトストレージ112のオペレーションログ205の一例を示す図である。
【0061】
オペレーションログ205のエントリは、ファイル・オブジェクトストレージ112で発生した操作ごとに作成される。
【0062】
オペレーションログ205のエントリには、オペレーション601、UUID602、バージョン603、タイプ604、オフセット605、サイズ606、通信拠点607、およびタイムスタンプ608の情報が含まれる。
【0063】
オペレーション601には、発生した操作の種別を示す情報が記憶される。UUID602には、操作対象のユーザファイル201またはユーザディレクトリ202に付与されたUUIDを示す情報が記憶される。バージョン603には、操作対象のユーザファイル201またはユーザディレクトリ202のバージョンを示す情報が記憶される。タイプ604には、操作対象の種別を示す情報が記憶される。オフセット605には、操作対象の領域のオフセットを示す情報が記憶される。サイズ606には、操作対象の領域のサイズを示す情報が記憶される。通信拠点607には、操作によりユーザファイル201またはユーザディレクトリ202のデータを送信または受信した拠点110を示す情報が記憶される。タイムスタンプ608には、操作の日時を示す情報が記憶される。
【0064】
<アクセス権管理表>
図7は、ファイル・オブジェクトストレージ112のアクセス権管理表206の一例を示す図である。
【0065】
アクセス権管理表206のエントリは、ファイル・オブジェクトストレージ112内のユーザファイル201ごとに作成される。
【0066】
アクセス権管理表206のエントリには、UUID710、バージョン720、メタデータアクセス権730、およびデータアクセス権740の情報が含まれる。
【0067】
UUID710には、ユーザファイル201に付与されたUUIDを示す情報が記憶される。バージョン720には、ユーザファイル201のバージョンを示す情報が記憶される。メタデータアクセス権730には、ユーザファイル201のメタデータアクセス権を示す情報が記憶される。データアクセス権740には、ユーザファイル201のデータアクセス権を示す情報が記憶される。
【0068】
メタデータアクセス権730には、アクセス権731(所有者)、アクセス権732(所有グループ)、アクセス権733(その他)、転送可否734(他拠点移動可否)の情報が含まれる。
【0069】
アクセス権731には、ユーザファイル201の所有者に対するメタデータへのアクセス権を示す情報が記憶される。アクセス権732には、ユーザファイル201の所有グループに対するメタデータへのアクセス権を示す情報が記憶される。アクセス権733には、ユーザファイル201のその他ユーザに対するメタデータへのアクセス権を示す情報が記憶される。転送可否734には、ユーザファイル201のメタデータについての他拠点110への転送可否を示す情報が記憶される。
【0070】
データアクセス権740には、アクセス権741(所有者)、アクセス権742(所有グループ)、アクセス権743(その他)、転送可否744(他拠点移動可否)の情報が含まれる。
【0071】
アクセス権741には、ユーザファイル201の所有者に対するデータへのアクセス権を示す情報が記憶される。アクセス権742には、ユーザファイル201の所有グループに対するデータへのアクセス権を示す情報が記憶される。アクセス権743には、ユーザファイル201のその他ユーザに対するデータへのアクセス権を示す情報が記憶される。転送可否744には、ユーザファイル201のデータについての他拠点110への転送可否を示す情報が記憶される。
【0072】
メタデータアクセス権730とデータアクセス権740との種類の一例として、所有者、所有グループ、その他、および他拠点110への転送可否を示したが、これらに限られない。例えば、メタデータアクセス権730とデータアクセス権740とには、ユーザの所属部門または所属プロジェクトごとのアクセス権、国内外へのデータの転送可否等を含めても構わない。
【0073】
<拠点間接続管理表>
図8は、ファイル・オブジェクトストレージ112の拠点間接続管理表207の一例を示す図である。
【0074】
拠点間接続管理表207は、拠点110間の通信時の性能およびコストの情報を記憶する。図8の例では、各行に転送元の拠点110(転送元801)を示し、各列に転送先の拠点110(転送先802)を示す。各セルには、転送元801から転送先802にデータを転送する際の帯域幅を示す。
【0075】
拠点間接続管理表207の一例として、各拠点110間のデータ転送の帯域幅を示したが、これらに限られない。例えば、拠点間接続管理表207には、データ転送時にかかるレイテンシ、通信経路を利用した際にかかる課金情報等の情報が複数含まれても構わない。
【0076】
<拠点間横断メタデータ検索結果応答>
図9は、ファイル・オブジェクトストレージ112のメタデータ検索プログラム212Dが検索結果として応答する拠点間横断メタデータ検索結果応答900の一例を示す図である。
【0077】
拠点間横断メタデータ検索結果応答900のエントリは、検索クエリに該当するとして全拠点110から抽出されたユーザファイル201ごとに作成される。
【0078】
拠点間横断メタデータ検索結果応答900のエントリは、UUID901、バージョン902、拠点903、仮想パス904、ファイル状態905、ファイル種別906、およびキーワード907の情報が含まれる。
【0079】
UUID901には、ユーザファイル201に付与されたUUIDを示す情報が記憶される。バージョン902には、ユーザファイル201のバージョンを示す情報が記憶される。拠点903には、ユーザファイル201を格納する拠点110を示す情報が記憶される。仮想パス904には、ユーザファイル201の仮想パスを示す情報が記憶される。ファイル状態905には、ユーザファイル201のファイル状態を示す情報が記憶される。ファイル種別906には、ユーザファイル201のファイル種別を示す情報が記憶される。キーワード907には、ユーザファイル201のデータの内容からメタデータ抽出プログラム212Eにより抽出されたキーワードを示す情報が記憶される。
【0080】
<処理フロー>
次に、図10図20のフローチャートを参照して、本実施の形態のストレージシステム100の動作について説明する。
【0081】
<拠点間横断メタデータ検索処理>
図10は、ストレージシステム100の拠点間横断メタデータ検索処理S1000の一例を説明するためのフローチャートである。
【0082】
拠点間横断メタデータ検索処理は、メタデータ検索プログラム212Dがクライアント端末111より拠点間横断メタデータ検索の検索クエリを受け付けることで開始する(S1001)。
【0083】
まず、メタデータ検索プログラム212Dは、全拠点110に検索クエリを発行(例えば、転送)し、後述の拠点内メタデータ検索処理S1100をリクエストする(S1002)。
【0084】
次に、転送された検索クエリを受信した各拠点110のメタデータ検索プログラム212Dは、拠点内メタデータ検索処理S1100を実施する(S1003)。
【0085】
次に、メタデータ検索プログラム212Dは、各拠点110から拠点内メタデータ検索処理S1100の検索結果を受信する(S1004)。
【0086】
次に、メタデータ検索プログラム212Dは、各拠点110の検索結果を集約して拠点間横断メタデータ検索結果応答900の形式でクライアント端末111に応答を返し(S1005)、処理を終了する(S1006)。
【0087】
<拠点内メタデータ検索処理>
図11は、拠点内メタデータ検索処理S1100の一例を説明するためのフローチャートである。
【0088】
拠点内メタデータ検索処理S1100は、クライアント端末111からの拠点内メタデータ検索の検索クエリがいずれかの拠点110において受け付けられたことに基づいて開始する(S1101)。
【0089】
まず、メタデータ検索プログラム212Dは、メタデータDBプログラム212Cにリクエストして、検索クエリの条件に該当するレコードをメタデータDB203より抽出する(S1102)。
【0090】
次に、メタデータ検索プログラム212Dは、S1102で抽出したレコードから、メタデータへのアクセス権がないレコードを削除する(S1103)。より具体的には、メタデータ検索プログラム212Dは、アクセス権管理表206を参照し、該当レコードから対応するユーザファイル201について、検索クエリの転送元の拠点110ないしは検索クエリの発行元のユーザがメタデータへのアクセス権を備えるレコードを抽出する。
【0091】
次に、メタデータ検索プログラム212Dは、抽出したレコードを検索結果として検索クエリの転送元に返答し(S1104)、処理を終了する(S1105)。
【0092】
<スタブ作成処理>
図12は、スタブ作成処理S1200の一例を説明するためのフローチャートである。
【0093】
スタブ作成処理S1200は、ファイル仮想化プログラム212Aがクライアント端末111よりスタブ作成要求を受信して開始する(S1201)。スタブ作成要求は、例えば、クライアント端末111において拠点間横断メタデータ検索結果応答900におけるレコードが選択されることにより作成される。
【0094】
まず、ファイル仮想化プログラム212Aは、スタブ作成要求に指定されるUUID、バージョン、および仮想パスに基づき、管理情報ファイル204とStub状態のユーザファイル201(スタブファイル)とをスタブ情報として自拠点110内に作成し、メタデータDB203とアクセス権管理表206とに作成したユーザファイル201に対応するレコードを作成する(S1202)。
【0095】
次に、ファイル仮想化プログラム212Aは、Stub状態のユーザファイル201を作成したことを他拠点110のファイル仮想化プログラム212Aに通知し、他拠点110のUUIDおよびバージョンを同一とする、メタデータDB203のレコードと、管理情報ファイル204のレコードとを更新する(S1203)。
【0096】
次に、ファイル仮想化プログラム212Aは、Stub状態のユーザファイル201のデータについてのバックグラウンドでの転送設定を確認する(S1204)。ファイル仮想化プログラム212Aは、転送設定が有効である場合、S1205に処理を移し、転送設定が無効である場合、S1206に処理を移す。バックグラウンドでの転送設定の方法としては、ファイルシステム単位、ディレクトリ単位、またはファイル単位にバックグラウンド転送の実施有無と使用帯域幅とを決定する方法、スタブ作成要求時にバックグラウンド転送の実施有無を指定する方法、ファイルシステムの拠点110間の移行時にのみバックグラウンド転送を行う方法等があり、特に制限されない。
【0097】
S1205では、ファイル仮想化プログラム212Aは、作成したStub状態のユーザファイル201のデータを取得するための、バックグラウンドでのデータ転送処理(バックグラウンドデータ取得処理S1300)を開始し、S1206に処理を移す。
【0098】
S1206では、ファイル仮想化プログラム212Aは、オペレーションログ205にスタブ作成操作の内容を追記する。
【0099】
次に、ファイル仮想化プログラム212Aは、スタブ作成処理の結果をクライアント端末111に応答し(S1207)、処理を終了する(S1208)。
【0100】
<バックグランドデータ取得処理>
図13は、バックグラウンドデータ取得処理S1300の一例を説明するためのフローチャートである。
【0101】
バックグラウンドデータ取得処理S1300は、スタブ作成処理S1200中のバックグラウンドでのデータ転送処理の要求、または、クライアント端末111から直接の特定のStub状態にあるユーザファイル201を指定したバックグラウンドでのデータ転送処理の要求の受信により開始する(S1301)。
【0102】
まず、ファイル仮想化プログラム212Aは、データ取得拠点選択処理S1500を実施し、対象のユーザファイル201のデータの取得元の拠点110を決定する(S1302)。
【0103】
次に、ファイル仮想化プログラム212Aは、S1302で決定した拠点110から、対象のユーザファイル201のUUIDおよびバージョンを指定して、対象のユーザファイル201のデータ(Stub部のデータ)を取得し、対象のユーザファイル201に書き込む(S1303)。
【0104】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する、メタデータDB203のレコードと管理情報ファイル204のレコードとについて、データの取得部分の部分状態が「Cache」となり、ファイル状態がCache状態となったことを反映する(S1304)。
【0105】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201と同一のUUIDおよびバージョンを持つ他拠点110のユーザファイル201について、対応するメタデータDB203のレコードと管理情報ファイル204のレコードとにファイル状態がCache状態となったことを反映する(S1305)。
【0106】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201と同一のUUIDおよびバージョンを持つ他拠点110のOriginal状態のユーザファイル201について、最終参照日時からの経過時間が一定の値を超過しているかを確認する(S1306)。ファイル仮想化プログラム212Aは、最終参照日時からの経過時間が一定の値を超過している場合、S1307に処理を移し、最終参照日時からの経過時間が一定の値を超過していない場合、S1308に処理を移す。
【0107】
S1307では、ファイル仮想化プログラム212Aは、Cache状態となった対象のユーザファイル201をOriginal状態へと移行し、対象のユーザファイル201と同一のUUIDおよびバージョンを持つOriginal状態のユーザファイル201をCache状態へと移行する。この移行を反映するため、全ての拠点110で対象のユーザファイル201と同一のUUIDおよびバージョンを持つユーザファイル201について、メタデータDB203の対応するレコードと管理情報ファイル204の対応するレコードとを更新する。ファイル仮想化プログラム212Aは、完了した後、S1308に処理を移す。
【0108】
S1308では、ファイル仮想化プログラム212Aは、オペレーションログ205に、対象のユーザファイル201に対してS1303で実施した他拠点110からのリコール操作を追記し、処理を終了する(S1309)。
【0109】
<ファイル参照処理>
図14は、ファイル参照処理S1400の一例を説明するためのフローチャートである。
【0110】
ファイル参照処理S1400は、クライアント端末111からの特定のユーザファイル201へのリード操作において、当該ユーザファイル201のデータへのアクセス権がある場合に開始する(S1401)。
【0111】
まず、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204を参照し、参照の対象部分の部分状態が「Stub」であるかを確認する(S1402)。ファイル仮想化プログラム212Aは、部分状態が「Stub」である場合、S1403に処理を移し、部分状態が「Stub」でない場合、S1410に処理を移す。
【0112】
S1403では、ファイル仮想化プログラム212Aは、データ取得拠点選択処理S1500を実施し、対象のユーザファイル201のデータの取得元の拠点110を決定する。
【0113】
次に、ファイル仮想化プログラム212Aは、S1403で決定した拠点110から、対象のユーザファイル201のUUID、バージョン、および参照の対象部分(オフセットおよびサイズ)を指定して、データを取得する(S1404)。
【0114】
次に、ファイル仮想化プログラム212Aは、S1404で取得したデータを対象のユーザファイル201に書き込む(S1405)。
【0115】
次に、ファイル仮想化プログラム212Aは、S1405でデータを書き込んだ部分について、対象のユーザファイル201に対応する管理情報ファイル204の部分状態を「Cache」に変更する(S1406)。
【0116】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204を確認して、全ての部分状態が「Cache」であるかを確認する(S1407)。ファイル仮想化プログラム212Aは、全ての部分状態が「Cache」である場合、S1408に処理を移し、「Cache」ではない部分状態が含まれている場合、S1410に処理を移す。
【0117】
S1408では、ファイル仮想化プログラム212Aは、対象のユーザファイル201と対応する、メタデータDB203のレコードと管理情報ファイル204のレコードとについて、対象のユーザファイル201が全データを取得してファイル状態がCache状態となったことを反映する。
【0118】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201と同一のUUIDおよびバージョンを持つ他拠点110のユーザファイル201について、対応するメタデータDB203のレコードと管理情報ファイル204のレコードとにファイル状態がCache状態となったことを反映し(S1409)、S1410に処理を移す。
【0119】
S1410では、ファイル仮想化プログラム212Aは、オペレーションログ205に、対象のユーザファイル201へのリード操作と、実行した場合はS1404およびS1405で実施した他拠点110からのリコール操作を追記する。
【0120】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201の参照の対象部分を読み出してユーザに応答(S1411)し、処理を終了する(S1412)。
【0121】
<データ取得拠点選択処理>
図15は、データ取得拠点選択処理S1500の一例を説明するためのフローチャートである。
【0122】
データ取得拠点選択処理S1500は、バックグラウンドデータ取得処理S1300、ファイル参照処理S1400、または後述のファイル更新処理S1600中で、Stub状態のユーザファイル201についての他拠点110からのデータ取得前に開始される(S1501)。
【0123】
まず、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204から、同一のUUIDおよびバージョンを持つユーザファイル201であって、Original状態、Cache状態、またはReplica状態のいずれかのファイル状態であるユーザファイル201を保持する拠点110を特定する(S1502)。
【0124】
次に、ファイル仮想化プログラム212Aは、拠点間接続管理表207を参照して、S1502で特定した拠点110からデータの取得に最も好適な拠点110を選択して応答し(S1503)、処理を終了する(S1504)。本実施の形態では、ファイル仮想化プログラム212Aは、拠点間接続管理表207に記憶されている帯域幅の値が最も大きい拠点110を選択する。なお、通信の帯域幅の他に、通信のレイテンシ、通信経路の利用コスト等に基づいて、拠点110を選択しても構わない。
【0125】
<ファイル更新処理>
図16は、ファイル更新処理S1600の一例を説明するためのフローチャートである。
【0126】
ファイル更新処理S1600は、クライアント端末111からの特定のユーザファイル201へのライト操作において、当該ユーザファイル201のデータへのアクセス権がある場合に開始する(S1601)。
【0127】
まず、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204からファイル状態がOriginal状態であるかを確認する(S1602)。ファイル仮想化プログラム212Aは、ファイル状態がOriginal状態である場合、S1603に処理を移し、ファイル状態がOriginal状態でない場合、S1608に処理を移す。
【0128】
S1603では、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204から、対象のユーザファイル201が他拠点110から参照されているかを確認する。ファイル仮想化プログラム212Aは、管理情報ファイル204のStub保持拠点またはCache保持拠点にいずれかの拠点110が設定されている場合、他拠点110からの参照があると判定する。ファイル仮想化プログラム212Aは、他拠点110からの参照がある場合、S1604に処理を移し、他拠点110からの参照がない場合、S1606に処理を移す。
【0129】
S1604では、ファイル仮想化プログラム212Aは、クライアント端末111からのライト操作の内容に基づき、対象のユーザファイル201を、バージョンを更新する形でデータを更新する。これにより、他拠点110から参照されるユーザファイル201を旧バージョンとして残すことができる。なお、ファイル・オブジェクトストレージ112がバージョン管理機能を有さない場合には、例えば、ファイル仮想化プログラム212Aが更新前のユーザファイル201を複製するといった方法で旧バージョンのデータを残しても構わない。
【0130】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204を、バージョンを更新する形で、ライト処理対象(更新領域)の部分状態を「Dirty」に更新し、メタデータ抽出済みフラグを「False」に更新する(S1605)。これにより、他拠点110から参照されるユーザファイル201の旧バージョンの管理情報ファイル204を残すことができる。なお、ファイル・オブジェクトストレージ112がバージョン管理機能を有さない場合には、例えば、更新前の管理情報ファイル204を複製するといった方法で旧バージョンのデータを残しても構わない。ファイル仮想化プログラム212Aは、完了後、S1611に処理を移す。
【0131】
S1606では、ファイル仮想化プログラム212Aは、クライアント端末111からのライト操作の内容に基づき、対象のユーザファイル201のデータを更新する。
【0132】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204について、ライト処理対象の部分状態を「Dirty」に更新し、メタデータ抽出済みフラグを「False」に更新し(S1607)、S1611に処理を移す。
【0133】
S1608では、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204から、ファイル状態がReplica状態であるかを確認する。ファイル仮想化プログラム212Aは、ファイル状態がReplica状態である場合、S1609に処理を移し、Replica状態でない場合、S1613に処理を移す。
【0134】
S1609では、ファイル仮想化プログラム212Aは、対象のユーザファイル201を複製し、複製したユーザファイル201に新しいUUIDを付与して、ライト操作の内容に基づいてデータを更新する。
【0135】
次に、ファイル仮想化プログラム212Aは、複製したユーザファイル201に対応する管理情報ファイル204を作成し、メタデータDB203とアクセス権管理表206とに、複製したユーザファイル201に対応するレコードを作成し(S1610)、S1611に処理を移す。
【0136】
S1611では、ファイル仮想化プログラム212Aは、オペレーションログ205にライト操作の内容を追記する。
【0137】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201へのライト操作の完了をクライアント端末111に応答し(S1612)、処理を終了する(S1626)。
【0138】
S1613では、ファイル仮想化プログラム212Aは、対象のユーザファイル201に新しいUUIDを付与して、ライト操作の内容に基づいてデータを更新する。
【0139】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204から、ファイル状態がCache状態であるかを確認する(S1614)。ファイル仮想化プログラム212Aは、ファイル状態がCache状態である場合、S1615に処理を移し、ファイル状態がCache状態でない場合、S1617に処理を移す。
【0140】
S1615では、ファイル仮想化プログラム212Aは、ユーザファイル201に対応する、メタデータDB203のレコードと、管理情報ファイル204のレコードと、アクセス権管理表206のレコードとに関して、新しいUUIDを付与し、ファイル状態がOriginal状態となったことを反映する。
【0141】
次に、ファイル仮想化プログラム212Aは、新しいUUIDの付与前に対象のユーザファイル201に付与されていた値と同一のUUIDおよびバージョンを持つ他拠点110のユーザファイル201について、対応するメタデータDB203のレコードと管理情報ファイル204のレコードとに、新しいUUIDが付与されたこと(ファイル状態がCache状態でなくなったこと)を反映し(S1616)、S1611に処理を移す。
【0142】
S1617では、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204について、ライト処理対象の部分状態を「Dirty」に更新する。
【0143】
次に、ファイル仮想化プログラム212Aは、オペレーションログ205にライト操作の内容を追記する(S1618)。
【0144】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201へのライト操作の完了をクライアント端末111に応答する(S1619)。
【0145】
次に、ファイル仮想化プログラム212Aは、データ取得拠点選択処理S1500を実施し(S1620)、対象のユーザファイル201のデータの取得元の拠点110を決定する。
【0146】
次に、ファイル仮想化プログラム212Aは、S1620で決定した拠点110から、新しいUUIDの付与前に対象のユーザファイル201に付与されていたUUIDおよびバージョンを指定して、対象のユーザファイル201のデータ(Stub部のデータ)を取得する(S1621)。
【0147】
次に、ファイル仮想化プログラム212Aは、S1621で取得したデータを対象のユーザファイル201に書き込む(S1622)。
【0148】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する、メタデータDB203のレコードと、管理情報ファイル204のレコードと、アクセス権管理表206のレコードとに関して、新しいUUIDを付与し、ファイル状態がOriginal状態となったことを反映する(S1623)。
【0149】
次に、ファイル仮想化プログラム212Aは、新しいUUIDの付与前に対象のユーザファイル201に付与されていた値と同一のUUIDおよびバージョンを持つ他拠点110のユーザファイル201について、対応するメタデータDB203のレコードと管理情報ファイル204のレコードとに、新しいUUIDが付与されたこと(ファイル状態がStub状態でなくなったこと)を反映する(S1624)。
【0150】
次に、ファイル仮想化プログラム212Aは、オペレーションログ205に他拠点110からのリコール操作の内容を追記し(S1625)、処理を終了する(S1626)。
【0151】
<オペレーションログ解析処理>
図17は、オペレーションログ解析処理S1700の一例を説明するためのフローチャートである。
【0152】
オペレーションログ解析処理S1700は、前回のオペレーションログ解析処理S1700からの一定時間の経過、未処理のオペレーションログが一定数以上貯まることを契機として開始する(S1701)。
【0153】
まず、ファイル仮想化プログラム212Aは、前回のオペレーションログ解析処理S1700から追加された、未解析のオペレーションログ205を取得する(S1702)。
【0154】
次に、ファイル仮想化プログラム212Aは、S1702で取得したオペレーションログ205中で、操作対象となっているユーザファイル201を抽出する(S1703)。ファイル仮想化プログラム212Aは、操作対象の識別子としては、UUIDおよびバージョンの組み合わせを使い、この値のリストを作成する。
【0155】
S1704では、ファイル仮想化プログラム212Aは、S1703で作成したリストのうちに未処理のエントリがあるかを確認する。ファイル仮想化プログラム212Aは、未処理のエントリがある場合、S1705に処理を移し、未処理のエントリがない場合、処理を終了する(S1710)。
【0156】
S1705では、ファイル仮想化プログラム212Aは、S1703で作成したリストから未処理のエントリのうち1つを選択し、処理対象として設定する。
【0157】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201について、S1702で取得したオペレーションログ205中でライト操作が行われており、対応する管理情報ファイル204から、ファイル状態がOriginal状態であることを確認する(S1706)。ファイル仮想化プログラム212Aは、ライト操作が行われており、かつ、ファイル状態がOriginal状態である場合、S1707に処理を移し、その他の場合、S1704に処理を移す。
【0158】
S1707では、ファイル仮想化プログラム212Aは、メタデータ抽出対象リストに、対象のユーザファイル201のUUIDおよびバージョンを追記し、S1708に処理を移す。
【0159】
S1708では、ファイル仮想化プログラム212Aは、S1702で取得したオペレーションログ205より、対象のユーザファイル201に実施された最後のライト操作以降に、対象のユーザファイル201にレプリケーション操作がなされていないことを確認する。ファイル仮想化プログラム212Aは、レプリケーション操作がなされていない場合、S1709に処理を移し、その他の場合、S1704に処理を移す。
【0160】
S1709では、ファイル仮想化プログラム212Aは、レプリケーション対象リストに、対象のユーザファイル201のUUIDおよびバージョンを追加し、S1704に処理を移す。
【0161】
<メタデータ抽出処理>
図18は、メタデータ抽出処理S1800の一例を説明するためのフローチャートである。
【0162】
メタデータ抽出処理S1800は、前回のメタデータ抽出処理S1800からの一定時間の経過、メタデータ抽出対象リストのエントリが一定数以上貯まること等を契機として開始する(S1801)。
【0163】
まず、メタデータ抽出プログラム212Eは、メタデータ抽出対象リストを取得する(S1802)。
【0164】
S1803では、メタデータ抽出プログラム212Eは、S1802で取得したメタデータ抽出対象リストのうちに未処理のエントリがあるかを確認する。メタデータ抽出プログラム212Eは、未処理のエントリがある場合、S1804に処理を移し、未処理のエントリがない場合、処理を終了する(S1809)。
【0165】
S1804では、メタデータ抽出プログラム212Eは、S1802で取得したメタデータ抽出対象リストから未処理のエントリのうち1つを選択し、処理対象として設定する。
【0166】
次に、メタデータ抽出プログラム212Eは、処理対象のエントリのUUIDおよびバージョンが指定するユーザファイル201にアクセスしたり、オペレーションログ205を解析したりして、当該ユーザファイル201のメタデータを抽出する(S1805)。
【0167】
次に、メタデータ抽出プログラム212Eは、対象のユーザファイル201に対応する管理情報ファイル204のメタデータ抽出済みフラグを「True」に更新し、メタデータDB203のレコードに関して、抽出したメタデータを登録する(S1806)。
【0168】
次に、メタデータ抽出プログラム212Eは、対象のユーザファイル201と同一のUUIDおよびバージョンを持つ他拠点110のユーザファイル201について、対応するメタデータDB203のレコードに抽出したメタデータを登録する(S1807)。
【0169】
次に、メタデータ抽出プログラム212Eは、オペレーションログ205に対象のユーザファイル201へのメタデータ抽出の実施内容を追記し(S1808)、S1803に処理を移す。
【0170】
<レプリケーション処理>
図19は、レプリケーション処理S1900の一例を説明するためのフローチャートである。
【0171】
レプリケーション処理S1900は、前回のレプリケーション処理S1900からの一定時間の経過、レプリケーション対象リストのエントリが一定数以上貯まること等を契機として開始する(S1901)。
【0172】
まず、ファイル仮想化プログラム212Aは、レプリケーション対象リストを取得する(S1902)。
【0173】
S1903では、ファイル仮想化プログラム212Aは、S1902で取得したレプリケーション対象リストのうちに未処理のエントリがあるかを確認する。ファイル仮想化プログラム212Aは、未処理のエントリがある場合、S1904に処理を移し、未処理のエントリがない場合、処理を終了する(S1912)。
【0174】
S1904では、ファイル仮想化プログラム212Aは、S1902で取得したレプリケーション対象リストから未処理のエントリのうち1つを選択し、処理対象として設定する。
【0175】
次に、ファイル仮想化プログラム212Aは、処理対象のエントリのUUIDおよびバージョンが指定するユーザファイル201について、対応する管理情報ファイル204から部分状態が「Dirty」の部分を特定し、データを読み出す(S1905)。
【0176】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201について、対応する管理情報ファイル204からReplica保持拠点を特定し、対象のユーザファイル201のUUID、バージョン、Dirty部(部分状態が「Dirty」であるオフセットおよびサイズ)の情報、およびS1905で読み出したDirty部のデータを含む、更新反映リクエストを転送する(S1906)。例えば、図4の例において、ファイル仮想化プログラム212Aは、UUID「AAAA」およびバージョン「2」のユーザファイル201にDirty部がある場合、UUID「AAAA」およびバージョン「1」のエントリを参照し、Replica保持拠点として「拠点3」を特定する。
【0177】
次に、S1906で転送された更新反映リクエストを受信した他拠点110にて、ファイル仮想化プログラム212Aは、指定されたUUIDおよびバージョンのユーザファイル201に対し、指定のDirty部に受信したデータを書き込み、更新反映リクエストへの完了応答を送信する(S1907)。
【0178】
次に、ファイル仮想化プログラム212Aは、S1907で送信された完了応答を受信する(S1908)。
【0179】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204のDirty部の部分状態を「Cache」に更新し、メタデータDB203の対応するレコードと、管理情報ファイル204の対応するレコードとに関して更新反映に成功した拠点110をReplica保持拠点に追加する(S1909)。
【0180】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201と同一のUUIDおよびバージョンを持つ他拠点110のユーザファイル201について、対応するメタデータDB203のレコードと管理情報ファイル204のレコードとに、拠点110が追加されたことを更新する(S1910)。
【0181】
次に、ファイル仮想化プログラム212Aは、オペレーションログ205に対象のユーザファイル201へのレプリケーションの実施内容を追記し(S1911)、S1903に処理を移す。
【0182】
<スタブ化処理>
図20は、スタブ化処理S2000の一例を説明するためのフローチャートである。
【0183】
スタブ化処理S2000は、拠点110のファイル・オブジェクトストレージ112の空き容量の割合が一定値を下回る等を契機として開始する(S2001)。
【0184】
まず、ファイル仮想化プログラム212Aは、メタデータDB203からファイル状態404がOriginal状態、Stub状態、またはCache状態のいずれかであるユーザファイル201を抽出し、スタブ化候補ファイルリストを作成する(S2002)。
【0185】
S2003では、ファイル仮想化プログラム212Aは、S2002で作成したスタブ化候補ファイルリストのうちに未処理のエントリがあるかを確認する。ファイル仮想化プログラム212Aは、未処理のエントリがある場合、S2004に処理を移し、未処理のエントリがない場合、処理を終了する(S2017)。
【0186】
S2004では、ファイル仮想化プログラム212Aは、S2002で作成したスタブ化候補ファイルリストから未処理のエントリのうち1つを選択し、処理対象として設定する。
【0187】
S2005では、ファイル仮想化プログラム212Aは、対象のユーザファイル201の最終参照日時からの経過時間が一定値(基準値)を超えることを確認する。ファイル仮想化プログラム212Aは、最終参照日時からの経過時間が一定値を超える場合、S2006に処理を移し、最終参照日時からの経過時間が一定値を超えない場合、S2003に処理を移す。
【0188】
S2006では、ファイル仮想化プログラム212Aは、対象のユーザファイル201に対応する管理情報ファイル204から、ファイル状態がCache状態またはStub状態であるかを確認する。ファイル仮想化プログラム212Aは、ファイル状態がCache状態またはStub状態である場合、S2007に処理を移し、ファイル状態がCache状態でもStub状態でもない場合、S2009に処理を移す。
【0189】
S2007では、ファイル仮想化プログラム212Aは、対象のユーザファイル201からデータを削除し、対象のユーザファイル201に対応する、管理情報ファイル204のレコードについて、全ての部分状態が「Stub」となったことと、ファイル状態がStub状態となったこととを反映し、メタデータDB203のレコードについて、ファイル状態がStub状態となったことを反映する。
【0190】
次に、ファイル仮想化プログラム212Aは、対象のユーザファイル201と同一のUUIDおよびバージョンを持つ他拠点110のユーザファイル201について、対応するメタデータDB203のレコードと、対応する管理情報ファイル204のレコードとに、ファイル状態がStub状態となったことを反映し(S2008)、S2015処理を移す。
【0191】
S2009では、ファイル仮想化プログラム212Aは、全拠点110のメタデータ検索プログラム212Dに問い合わせ、メタデータDB203より対象のユーザファイル201と同一のUUIDおよびバージョンを持ち、ファイル状態がStub状態またはCache状態である他拠点110のユーザファイル201を発見し、発見したユーザファイル201の最終参照日時を取得する。
【0192】
次に、ファイル仮想化プログラム212Aは、S2009で発見したファイル状態がStub状態またはCache状態であるユーザファイル201の中に、ファイル状態がOriginal状態である対象のユーザファイル201より最終参照日時が新しいものがあるかを確認する(S2010)。ファイル仮想化プログラム212Aは、対象のユーザファイル201より最終更新日時が新しいStub状態またはCache状態のユーザファイル201がある場合、S2011に処理を移し、対象のユーザファイル201より最終更新日時が新しいStub状態またはCache状態のユーザファイル201がない場合、S2003に処理を移す。
【0193】
S2011では、ファイル仮想化プログラム212Aは、S2009で発見したファイル状態がStub状態またはCache状態であるユーザファイル201の中で、最終参照日時が最も新しいユーザファイル201のファイル状態がStub状態であるかを確認する。ファイル仮想化プログラム212Aは、ファイル状態がStub状態である場合、S2012に処理を移し、ファイル状態がStub状態でない場合、S2013に処理を移す。
【0194】
S2012では、ファイル仮想化プログラム212Aは、ファイル状態がOriginal状態である対象のユーザファイル201の全データを、S2009で発見したファイル状態がStub状態またはCache状態であるユーザファイル201の中で最終参照日時が最も新しいStub状態のユーザファイル201を保持する拠点110に転送し、データを書き込み、S2013に処理を移す。
【0195】
S2013では、ファイル仮想化プログラム212Aは、対象のユーザファイル201をStub状態へと移行し、S2009で発見したファイル状態がStub状態またはCache状態であるユーザファイル201の中で最終参照日時が最も新しいユーザファイル201をOriginal状態に移行する。ファイル仮想化プログラム212Aは、この移行を反映するため、全ての拠点110で対象のユーザファイル201と同一のUUIDおよびバージョンを持つユーザファイル201について、メタデータDB203の対応するレコードと管理情報ファイル204の対応するレコードとを更新し、S2014に処理を移す。
【0196】
S2014では、ファイル仮想化プログラム212Aは、対象のユーザファイル201のデータを削除する。
【0197】
次に、ファイル仮想化プログラム212Aは、オペレーションログ205に対象のユーザファイル201へのスタブ化の実施内容を追記する(S2015)。
【0198】
次に、ファイル仮想化プログラム212Aは、スタブ化処理S2000の中で十分な空き領域を確保できたかを確認する(S2016)。ファイル仮想化プログラム212Aは、十分な空き領域を確保できた場合、処理を終了し(S2017)、十分な空き領域を確保できていない場合、S2003に処理を移す。
【0199】
なお、ファイル仮想化プログラム212Aは、十分な空き容量を得る前にS2003でスタブ化候補ファイルリストから未処理エントリがなくなり処理を終了した場合、目標の空き容量を得るため、スタブ化を行う際の最終参照日時からの経過時間の基準値(条件)をより小さな時間に緩和して、再度スタブ化処理S2000を行っても構わない。
【0200】
このように構成される本実施の形態によれば、拠点110ごとのファイル・オブジェクトストレージ112は、他拠点110のファイル・オブジェクトストレージ112のOriginal状態のユーザファイル201の全てに対し、Stub状態のユーザファイル201を作る必要はなく、転送が必要なOriginal状態のユーザファイル201に絞ってStub状態のユーザファイル201を作成することができる。
【0201】
したがって、本実施の形態によれば、拠点110間で全てのユーザファイル201のスタブ情報を保持し合うための、ストレージの記憶容量が削減できる。また拠点110の追加時には、新しい拠点110でのスタブ情報の作成を不要化し、拠点110の立ち上げ時間を低減する。また、メタデータの更新時のグローバルロックが不要となり、クライアント端末111への応答性能を改善する。
【0202】
なお、上記した実施の形態は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施の形態の構成の一部について、他の構成に追加、削除、置換することが可能である。
【0203】
(II)付記
上述の実施の形態には、例えば、以下のような内容が含まれる。
【0204】
上述の実施の形態においては、本発明をストレージシステムに適用するようにした場合について述べたが、本発明はこれに限らず、この他種々のシステム、装置、方法、プログラムに広く適用することができる。
【0205】
また、上述の実施の形態においては、拠点間横断メタデータ検索結果応答900から所望のユーザファイル201を選択する場合について述べたが、本発明はこれに限らない。例えば、他拠点110のユーザファイル201およびユーザディレクトリ202を参照して所望のユーザファイル201を選択するようにしてもよい。
【0206】
また、上述の実施の形態において、各テーブルの構成は一例であり、1つのテーブルは、2以上のテーブルに分割されてもよいし、2以上のテーブルの全部または一部が1つのテーブルであってもよい。
【0207】
また、上述の実施の形態において、説明の便宜上、XXテーブル、XXファイルを用いて各種のデータを説明したが、データ構造は限定されるものではなく、XX情報等と表現してもよい。
【0208】
上述した実施の形態は、例えば、以下の特徴的な構成を備える。
【0209】
(1)それぞれがファイルシステムを提供するストレージ(例えば、ファイル・オブジェクトストレージ112)を備える複数の拠点(例えば、拠点110)間でファイル(例えば、ユーザファイル201)を共有可能なストレージシステム(例えば、ストレージシステム100)であって、上記ストレージは、ファイルのデータを記憶した記憶装置(例えば、記憶装置220)と、上記記憶装置に接続されたコントローラ(例えば、コントローラ210)と、を備え、上記ファイル(例えば、Original状態のユーザファイル201(オリジナルファイル))と関連付けられ、上記ファイルを参照する関連ファイル(例えば、オリジナルファイル以外のファイル、スタブファイル(スタブ情報)、換言するならば、オリジナルファイルがないと存在できないファイル)を有し、上記コントローラは、上記ファイルが更新される場合に、上記関連ファイルからの参照状況に基づいて、上記ファイルおよび関連ファイルを更新し(例えば、図16参照)、上記コントローラは、他拠点において記憶されているファイルに係るアクセス要求(例えば、リード要求、他拠点のファイルを選択する操作)を受け付けた場合に、上記他拠点に問い合わせを行い、上記アクセス要求にかかるファイルにアクセスするための関連ファイルを上記アクセス要求を受けたコントローラにかかる拠点に作成する(例えば、S1202)。
【0210】
上記構成では、他拠点において記憶されているファイルに係るアクセス要求に応じて関連ファイルが作成されるので、ストレージは、他の拠点の全てのファイルの関連ファイルを記憶する必要がなく、拠点間におけるファイルの共有に必要な関連ファイルを削減することができる。例えば、各拠点において関連ファイルの記憶に必要な記憶容量と、新たな拠点の追加時に関連ファイルを取得する時間とについて、改善することができる。
【0211】
(2)上記アクセス要求が検索要求の場合、上記検索要求を受け付けた第1の拠点のストレージのコントローラは、上記複数の拠点のストレージに検索クエリ(例えば、拠点間横断メタデータ検索の検索クエリ)を送信し(例えば、S1002)、上記検索クエリを受信したストレージのコントローラは、上記検索クエリに対応するファイルのメタデータを上記第1の拠点のストレージに送信し(例えば、S1103)、上記第1の拠点のストレージのコントローラは、上記複数の拠点から送信された上記検索クエリに対応するファイルのメタデータに基づいて、上記ファイルを参照する関連ファイルを作成する。
【0212】
例えば、メタデータが要求元(例えば、クライアント端末111)に送信され、要求元で確認されたメタデータに対応する関連ファイルが作成されてもよいし、要求元で要求元への確認なく、検索ヒットしたメタデータ全てについて関連ファイルが作成されてもよい。
【0213】
上記構成では、例えば、要求元による確認がなくとも、検索クエリに基づいてファイルを共有することができる。
【0214】
(3)上記第1の拠点のストレージのコントローラは、上記複数の拠点から送信された上記検索クエリに対応するファイルのメタデータを上記検索要求の要求元に送信し(例えば、S1005)、上記検索クエリに対応するファイルにアクセスする要求を上記検索要求の要求元から受け付けた場合(例えば、S1201)、上記ファイルを参照する関連ファイルを作成する。
【0215】
上記構成では、検索クエリが全ての拠点において実行されるので、例えば、ユーザは、所望するファイルが記憶されている拠点を把握して、ファイルを適切に共有することができる。
【0216】
(4)上記複数の拠点の各々のストレージの記憶装置は、自拠点に記憶しているファイルおよび関連ファイルのメタデータを記憶するメタデータDB(例えば、メタデータDB203)を備え、上記検索クエリを受信したストレージのコントローラは、上記検索クエリに対応するファイルのメタデータを上記メタデータDBから取得して上記第1の拠点のストレージに送信する(例えば、図11参照)。
【0217】
上記構成では、各拠点にメタデータDBが設けられているので、例えば、ストレージは、検索クエリに対応するファイルのメタデータを容易かつ迅速に取得することができる。
【0218】
(5)上記複数の拠点の各々のストレージの記憶装置は、上記メタデータDBに記憶されているメタデータに対するメタデータアクセス権と、記憶しているファイルのデータに対するデータアクセス権とを管理するためのアクセス権管理情報(例えば、アクセス権管理表206)を記憶し(例えば、図7参照)、上記検索クエリを受信したストレージのコントローラは、上記検索クエリに対応するファイルのメタデータを上記メタデータDBから取得し、取得したメタデータのうち、上記アクセス権管理情報に基づいてメタデータアクセス権があると判定したメタデータを上記第1の拠点のストレージに送信し(例えば、図11参照)、上記ファイルのデータのアクセスが指示(例えば、リード操作、ライト操作等が要求)されたストレージのコントローラは、上記アクセス権管理情報に基づいて上記ファイルのデータに対してデータアクセス権があると判定したとき、上記ファイルのデータを自拠点または他拠点から取得して上記アクセスの要求元に送信する(例えば、図14図16参照)。
【0219】
上記構成によれば、例えば、「所定のユーザには、検索結果(メタデータ)を見せない」、「所定のユーザには、このようなファイルがあるといった検索ができるが、ファイルのデータ(実データ)には、アクセスさせない」といった制御ができるようになる。なお、料金を支払う、管理者からアクセス権が与えられる等のステップを踏むことで、メタデータおよびファイルのデータにアクセスできるようになる。
【0220】
(6)上記ファイルが更新された場合に、上記ファイルを参照する関連ファイルも更新される(例えば、S1605、S1607)。
【0221】
上記構成によれば、例えば、オリジナルファイルが更新された場合に関連ファイルも更新されるので、オリジナルファイルと関連ファイルとの整合性を保つことができる。
【0222】
上記ストレージのコントローラは、他拠点のファイルに対するデータの更新をクライアント端末から受け付けた場合、上記他拠点のファイルに対応するファイルを作成し、作成したファイルに対してデータを更新してもよい(例えば、S1604)。例えば、他拠点のファイル(オリジナルファイル)を参照している人がいるときに、勝手にオリジナルファイルが更新されると、その人にとって不都合が生じる。この点、上記構成によれば、オリジナルファイルを破壊することなく、オリジナルファイルに対応するファイル(バージョンの異なるファイル、複製したファイル等)を作成することで、他拠点とのデータの整合性を保つことができる。
【0223】
(7)上記ファイルが上記関連ファイルから参照されている場合には、更新前のファイルを残してファイルを更新し(例えば、S1604)、上記ファイルのデータを、更新前のファイルと更新後のファイルとを選択して取得して上記関連ファイルを更新可能である(例えば、S1411)。
【0224】
上記構成では、ファイル(オリジナルファイル)のデータを更新する際、例えば、バージョンが異なるファイルが作成されて当該ファイルにデータが更新される。例えば、上記構成によれば、他拠点のファイルのデータが取得される際、当該ファイルのバージョンが指定されるので、データを更新している途中の一貫性のないデータが取得されてしまう事態を回避できるようになる。
【0225】
(8)上記ファイルを参照する頻度(例えば、最終参照日時)が、他拠点の上記関連ファイルが参照される頻度(例えば、最終参照日時)よりも低い(例えば、新しい)場合、上記ファイルと上記関連ファイルとを入れ替える(例えば、図20参照)。
【0226】
上記構成では、ファイルの参照頻度に応じて、例えば、自拠点のファイルと他拠点のファイルとの位置づけ(オリジナルファイル)が入れ替わるので、2重にデータを持たなくてよくなり、システム全体として、データ量を削減することができる。
【0227】
(9)上記関連ファイルはデータを有さないスタブファイル(例えば、Stub状態のユーザファイル201)として作成され、上記アクセス要求とは非同期に上記ファイルからデータを取得する(例えば、図12図13参照)。
【0228】
他拠点のファイルへのアクセスがあるたびに、他拠点からデータを取得すると、データの読み込みに時間がかかる。上記構成では、例えば、スタブファイルに基づいて他拠点のファイルのデータを事前に取得することで、データが自拠点にあるので、アクセス要求の要求元にデータを迅速に提供することができる。
【0229】
(10)上記ファイルには、UUID(Universally Unique Identifier)およびバージョンが対応付けられ(例えば、図2参照)、上記ストレージのコントローラは、上記UUIDおよび上記バージョンを対応付けて関連ファイルを作成し、自拠点における上記関連ファイルのファイルパスを示す情報を作成する(例えば、図5参照)。
【0230】
上記特許文献1に記載の技術では、ディレクトリの操作時に、拠点間のグローバルロックを取得して関連ファイルを持ち合う複数の拠点に更新を反映するため、クライアント端末における操作への応答性能低下を招く。この点、上記構成では、UUIDおよびバージョン(実パス)によりファイルが特定されるので、拠点間でファイルの異なる仮想パスを用いることができる。このように、実パスが一貫していれば、同じファイルにアクセスできるので、仮に、自拠点でファイル名(仮想パス)がリネームされたとしても、他拠点に、そのファイル名を反映させる必要がなく、グローバルロックをとる必要がなくなる。これにより、ファイルシステムにおけるディレクトリの操作時の応答性能を改善することができる。
【0231】
(11)上記複数の拠点の各々のストレージの記憶装置は、拠点間の接続状態を管理するための拠点間接続管理情報(例えば、拠点間接続管理表207)を記憶し(例えば、図8参照)、上記ファイルのデータを全て含む拠点を示すデータ拠点情報(例えば、Cache保持拠点407、Replica保持拠点408)を有し、上記ストレージのコントローラは、上記データ拠点情報と上記拠点間接続管理情報とに基づいて、上記ファイルのデータを取得する拠点を決定し(例えば、図15参照)、決定した拠点から上記データを取得する。
【0232】
上記構成では、拠点間接続管理情報に基づいてファイルのデータの取得先の拠点が決定されるので、例えば、拠点間の帯域幅、レイテンシ、課金情報等を拠点間接続管理情報に規定することで、データを最適に取得することができる。
【0233】
「A、B、およびCのうちの少なくとも1つ」という形式におけるリストに含まれる項目は、(A)、(B)、(C)、(AおよびB)、(AおよびC)、(BおよびC)または(A、B、およびC)を意味することができると理解されたい。同様に、「A、B、またはCのうちの少なくとも1つ」の形式においてリストされた項目は、(A)、(B)、(C)、(AおよびB)、(AおよびC)、(BおよびC)または(A、B、およびC)を意味することができる。
【符号の説明】
【0234】
100……ストレージシステム、110……拠点、111……クライアント端末、112……ファイル・オブジェクトストレージ(ストレージ)。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20