JP5343166B2 - 通信ネットワークを介してリモートのファイルサーバにファイルを転送するローカルのファイルサーバ、及び、それらのファイルサーバを有するストレージシステム - Google Patents

Description

本発明は、通信ネットワークを介してファイルを転送し記憶する記憶制御に関する。

従来、企業や個人が自費でサーバやソフトウェアを購入し、これを利用する形態が主流であったが、ＴＣＯ（Total Cost of Ownership）を削減するため、インターネット経由でサーバやソフトウェアを利用するクラウドコンピューティングが広まる傾向にある。

クラウドコンピューティングの一例として、特許文献１には、ストレージ装置をインターネット経由で利用可能にする発明（以降、クラウドストレージ装置と呼ぶ）が記載されている。

さらに、特許文献２には、複数のストレージ装置が組み合わされた階層ストレージシステムに関する発明が記載されている。

特開２００９−１１０４０１号公報 特開２００９−２８９２５２号公報

上記従来技術では、クラウドストレージ装置内のファイルへのアクセスのためには、インターネットを経由してアクセスする必要がある。このため、データの転送遅延が生じ、アクセススピードが遅くなる。

また、ファイルをクラウドストレージ装置に格納するか、ローカルのストレージ装置に格納するかの判断がユーザ任せになっている。クラウドストレージ装置に格納されたファイルへのアクセススピードは、上記の通り、遅い。

そのため、ユーザは、ローカルのストレージ装置を拡張することで、クラウドストレージ装置の代わりにローカルのストレージ装置にデータを格納してしまう傾向にある。その結果、クラウドストレージ装置の利用機会が減ってしまい、結局、ＴＣＯが削減できないという問題がある。

そこで、ファイルをローカルのストレージ装置に格納するか、クラウドストレージ装置に格納するかをユーザに委ねることなく適切に判断することが好ましい。しかし、そうすると、ユーザが利用するファイルの種類によっては、インターネット経由のアクセスが頻発し、上述の転送遅延と相まって、ファイルへのアクセス性能（特に、リードの性能）が悪くなる可能性がある。

以上の問題は、通信ネットワークが、インターネット以外の通信ネットワークの場合にも、有り得る。

従って、本発明の目的は、ファイルへのアクセス性能をなるべく損なわずに、リモートのストレージ装置の利用機会を増やすことにある。

リモートの記憶デバイスを管理するリモートのファイルサーバと、ローカルの記憶デバイスを管理するローカルのファイルサーバとが、通信ネットワーク（例えばインターネット）に接続されている。ローカルのファイルサーバが、（Ａ）ローカルの記憶デバイス内のファイルをリモートのファイルサーバにレプリケーションし、（Ｂ）第１の条件が満たされた場合に、レプリケーションされたファイルであるレプリケーション済みファイルを、マイグレーション対象ファイルとして管理する。ローカルのファイルサーバは、（Ｂ）が完了してもマイグレーション対象ファイルをローカルの記憶デバイスから削除せず、第２の条件が満たされた場合に、マイグレーション対象ファイルをローカルの記憶デバイスから削除する。第２の条件とは、例えば、マイグレーション対象ファイルが参照された後にどのユーザ端末からも参照されなくなったことである。

本発明の一実施例の概要を示す。 本発明の一実施例に係るシステム全体のハードウェア構成を示す。 本発明の一実施例に係るシステム全体のソフトウェア構成を示す。 inode管理テーブルを示す。 図４のinode管理テーブルにおけるinode番号「１００」のinodeと、ファイルの位置との関係を示す。 inode管理テーブル４００に追加されている新たな種類のメタデータを示す。 レプリケーション処理の流れを示す。 レプリケーション済みファイル又はそれのメタデータに関するライト処理の流れを示す。 同期処理の流れを示す。 メタデータのリード処理の流れを示す。 ファイルのリード処理の流れを示す。 図１２Ａは、オープン要求に応答して行われる処理を示す。図１２Ｂは、クローズ要求に応答して行われる処理を示す。図１２Ｃは、ファイルの削除を示す。 マイグレーション済みファイルに関するライト処理の流れを示す。 図１４Ａは、ＬＵ内の空き容量の一例を示す。図１４Ｂは、リコールされたファイルがＬＵに書き込まれたが故にＬＵの空き容量が閾値未満に減った例を示す。 レプリケーション対象外のファイルをレプリケーション候補のファイルとする処理の流れを示す。 図１５のＳＴＥＰ２７−３及び２７−４を示す。 レプリケーション候補のファイルをレプリケーションする流れを示す。 ファイルシステム１２１１（受付プログラム１２１１０）の処理の流れを示すフローチャートである。 データムーバプログラムの処理の流れを示すフローチャートである。 監視プログラム１２１４の処理の流れの一部を示すフローチャートである。 監視プログラム１２１４の処理の流れの別の部分を示すフローチャートである。 本発明の一実施例に係るシステム全体のソフトウェア構成において、Ｅｄｇｅ側のＬＵにThin provisioningを適用した構成を示す。

以下、本発明の一実施例を説明する。

なお、以下の説明では、「ｘｘｘテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ｘｘｘテーブル」を「ｘｘｘ情報」と呼ぶことができる。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インタフェース装置（例えば通信ポート）を用いながら行うため、処理の主語がプロセッサとされても良い。プログラムを主語として説明された処理は、ファイルサーバ（例えば、後述のファイルストレージ装置、アーカイブ装置）が行う処理としても良い。また、プロセッサは、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでも良い。コンピュータプログラムは、プログラムソースから各計算機にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。

図１は、本発明の一実施例の概要を示す。

ローカルの計算機システム２と、リモートの計算機システム３がある。

ローカルの計算機システム２は、クライアント（例えばパーソナルコンピュータ）／ホスト（例えばサーバ）１３０と、ファイルストレージ装置１２０と、ＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）システム１１０とを有する。ファイルストレージ装置１２０に、クライアント／ホスト１３０と、ＲＡＩＤシステム１１０とが接続されている。ファイルストレージ装置１２０は、ローカルのファイルサーバの一例である。

リモートの計算機システム３が、アーカイブ装置２２０とＲＡＩＤシステム２１０とを有する。アーカイブ装置２２０は、リモートのファイルサーバの一例である。

ファイルストレージ装置１２０とアーカイブ装置２２０が、通信ネットワーク１経由で接続されている。通信ネットワーク１は、典型的にはインターネットであるが、それ以外の通信ネットワーク（例えば、ＬＡＮ（Local Area Network））でも良い。

本実施例では、例えば、以下の処理が行われる。

すなわち、ファイルストレージ装置１２０は、クライアント／ホスト１３０から、ファイルのライト要求を受信し、そのライト要求に従い、ファイル１０を、ＲＡＩＤシステム１１０に書き込む。

その後、ファイルストレージ装置１２０は、ファイル１０をレプリケーションする（Ｓ１００１）。具体的には、ファイルストレージ装置１２０は、ＲＡＩＤシステム１１０からファイル１０を読み出し、読み出したファイル１０を、通信ネットワーク１経由で、アーカイブ装置２２０に転送する。アーカイブ装置２２０は、ファイルストレージ装置１２０からのファイルを、ＲＡＩＤシステム２１０に書き込む。これにより、ＲＡＩＤシステム１１０とＲＡＩＤシステム２１０の両方にファイル１０が存在する状態となる。

ファイルストレージ装置１２０は、ファイル１０のレプリケーションが完了して直ちにＲＡＩＤシステム１１０からファイル１０を削除することをしない。なぜなら、そうすることは、ファイル１０をマイグレーションすることと同等だからである。ファイル１０がリモートの計算機システム３にマイグレーションされた後にファイル１０をクライアント／ホスト１３０に提供するためには、ファイルストレージ装置１２０は、通信ネットワーク１経由でアーカイブ装置２２０にファイル１０を要求する必要がある。

そこで、本実施例では、ファイルストレージ装置１２０は、ファイル１０のレプリケーションが完了しても、ファイル１０をＲＡＩＤシステム１１０から削除せずに残しておく。

このため、ファイルストレージ装置１２０は、ファイル１０のリード要求をクライアント／ホスト１３０から受信した場合（Ｓ１１０１）、ＲＡＩＤシステム１１０からファイル１０を読み出してクライアント／ホスト１３０に提供できる（Ｓ１１０２）。つまり、ファイルストレージ装置１２０は、ファイル１０を通信ネットワーク１経由でアーカイブ装置２２０から取得する必要が無い。

ファイルストレージ装置１２０は、ファイル１０がいずれのクライアント／ホスト１３０からも読み出されなくなった（参照されなくなった）場合に、ファイル１０（厳密には、その実体）を削除する（Ｓ１１０３）。この結果、ファイル１０は、実質的に、アーカイブ装置１２０側のみに格納されていることになる。なお、ファイル１０を削除するタイミングは、ファイル１０がいずれのクライアント／ホスト１３０からも読み出されなくなったことに代えて又は加えて、他の条件が満たされたこと（例えば、ファイル１０に対するアクセス（リード）の最終時刻から一定時間が経過したこと）が、採用されて良い。

以下、本実施例を詳細に説明する。

図２は、本発明の一実施例に係るシステム全体のハードウェア構成を示す。

Ｅｄｇｅ１００とＣｏｒｅ２００がある。Ｅｄｇｅ１００とは、ローカルの計算機システムを含んだ拠点であり、例えば、支店や営業所などユーザが実際に業務を行う拠点である。また、Ｃｏｒｅ２００とは、リモートの計算機システムを含んだ拠点であり、例えば、サーバやストレージ装置を一括管理する拠点やクラウドサービスを提供する拠点である。

なお、図１に示す例では、Ｅｄｇｅ１００は複数、Ｃｏｒｅ２００が単数であるが、Ｅｄｇｅ１００が単数、及び／又は、Ｃｏｒｅ２００が複数でも良い。また、図１では、ファイルストレージ装置１２０に接続されている１つのクライアント／ホスト１３０が示されているが、実際には、ファイルストレージ装置１２０には複数のクライアント／ホスト１３０が接続されている（図示の通り、クライアント／ホスト１３０は、１つでも良い）。

Ｅｄｇｅ１００は、ＲＡＩＤシステム１１０と、ファイルストレージ装置１２０と、クライアント／ホスト１３０と、を備える。ファイルストレージ装置１２０は、例えば、通信ネットワーク（例えばＬＡＮ）経由で、クライアント／ホスト１３０に接続されている。また、ファイルストレージ装置１２０は、例えば、通信ネットワーク（例えばＳＡＮ（Storage Area Network））経由で、ＲＡＩＤシステム１１０に接続されている。

ＲＡＩＤシステム１１０は、コントローラ部と記憶部とに大別される。コントローラ部は、ＣＨＡ（Channel Adaptor）１１１と、ＤＫＣ（DisK Controller)１１２とを備える。記憶部は、ＤＩＳＫ１１３を備える。ＤＫＣ１１２に、ＣＨＡ１１１及びＤＩＳＫ１１３が接続されている。ＣＨＡ１１１は、ファイルストレージ装置１２０に接続される通信インタフェース装置である。ＤＫＣ１１２は、コントローラである。ＤＩＳＫ１１３は、ディスク型の物理記憶デバイス（例えば、ＨＤＤ（Hard Disk Drive））である。物理記憶デバイスとして、他種の物理記憶デバイス（例えば、フラッシュメモリデバイス）が採用されても良い。また、ＤＩＳＫ１１３は、図１では単数であるが、実際は、複数である（図示通り、単数でも良い）。複数のＤＩＳＫ１１３で、１以上のＲＡＩＤグループが構成されて良い。

ＲＡＩＤシステム１１０は、ファイルストレージ装置１２０から送信されたブロックレベルのＩ／Ｏ要求をＣＨＡ１１１で受信し、ＤＫＣ１１２の制御に基づいて、適切なＤＩＳＫ１１３へのＩ／Ｏを実行する。

ファイルストレージ装置１２０は、メモリ１２１と、ＣＰＵ（Central Processing Unit）１２２と、ＮＩＣ（Network Interface Card）１２３と、ＨＢＡ（Host Bus Adaptor）１２４と、を備える。メモリ１２１、ＮＩＣ１２３及びＨＢＡ１２４に、ＣＰＵ１２２が接続されている。

ＮＩＣ１２３は、アーカイブ装置２２０及びクライアント／ホスト１３０と通信する通信インタフェース装置である。

ＨＢＡ１２４は、ＲＡＩＤシステム１１０と通信する通信インタフェース装置である。

メモリ１２１は、ＣＰＵ１２２が直接読み書きできる記憶領域（例えば、ＲＡＭ（Random Access Memory）やＲＯＭ（リード Only Memory））である。ファイルストレージ装置１２０は、メモリ１２１上にファイルストレージ装置１２０を制御するプログラム（例えばＯＳ（Operating System））を読み込み、ＣＰＵ１２２にそのプログラムを実行させる。ファイルストレージ装置１２０は、メモリ１２１に加えて又は代えて、別種の記憶資源を有しても良い。

ファイルストレージ装置１２０は、ＮＩＣ１２３経由で、クライアント／ホスト１３０からファイルレベルのＩ／Ｏ要求を受信する。ファイルストレージ装置１２０は、そのＩ／Ｏ要求で指定されているファイルを構成するデータブロックのＩ／ＯのためのＩ／Ｏ要求（ブロックレベルのＩ／Ｏ要求)を作成する。ファイルストレージ装置１２０は、ブロックレベルのＩ／Ｏ要求を、ＨＢＡ１２４経由で、ＲＡＩＤシステム１１０に送信する。

クライアント／ホスト１３０は、メモリ１３１と、ＣＰＵ１３２と、ＮＩＣ１３３と、ＤＩＳＫ１３４と、を備える。クライアント／ホスト１３０は、メモリ１３１及び／又はＤＩＳＫ１３４に加えて又は代えて、別種の記憶資源を有しても良い。

クライアント／ホスト１３０は、ＤＩＳＫ１３４に格納されているプログラム（クライアント／ホスト１３４を制御するプログラム（例えばＯＳ））をメモリ１３１上に読み込み、ＣＰＵ１３２にプログラムを実行させる。また、クライアント／ホスト１３０は、ＮＩＣ１３３経由で、ファイルレベルのＩ／Ｏ要求をファイルストレージ装置１２０に送信する。

Ｃｏｒｅ２００は、ＲＡＩＤシステム２１０と、アーカイブ装置２２０と、を備える。アーカイブ装置２２０に、ＲＡＩＤシステム２１０が接続されている。

ＲＡＩＤシステム２１０は、ＣＨＡ２１１と、ＤＫＣ２１２と、ＤＩＳＫ２１３と、を備える。図１では、ＲＡＩＤシステム２１０の構成とＲＡＩＤシステム１１０の構成は、同一である。従って、ＲＡＩＤシステム２１０も、アーカイブ装置２２０から送信されたブロックレベルのＩ／Ｏ要求をＣＨＡ２１１で受信し、ＤＫＣ２１２の制御に基づいて、適切なＤＩＳＫ２１３へのＩ／Ｏを実行する。なお、ＲＡＩＤシステム２１０の構成とＲＡＩＤシステム１１０の構成は、異なっていても良い。

アーカイブ装置２２０は、メモリ２２１と、ＣＰＵ２２２と、ＮＩＣ２２３と、ＨＢＡ２２４と、を備える。メモリ２２１に代えて又は加えて、別種の記憶資源が備えられても良い。アーカイブ装置２２０は、メモリ２２１上にアーカイブ装置２２０を制御するプログラム（例えばＯＳ）を読み込み、ＣＰＵ２２２にそのプログラムを実行させる。また、アーカイブ装置２２０は、ＮＩＣ２２３及び通信ネットワーク１経由で、ファイルストレージ装置１２０と通信する。アーカイブ装置２２０は、ＨＢＡ２２４経由で接続され、ブロック単位のアクセスを行う。

図３は、本実施例に係るシステム全体のソフトウェア構成を示す。

ＲＡＩＤシステム１１０（２１０）は、複数のＬＵ（Logical Unit）１１００（２１００）を有する。ＬＵ１１００（２１００）は、論理的な記憶デバイスである。ＬＵ１１００（２１００）は、１以上のＤＩＳＫ１１３（２１３）に基づく実体的なＬＵであっても良いし、Thin Provisioningに従う仮想的なＬＵであっても良い。ＬＵ１１００（２１００）は、複数のブロック（記憶領域）で構成されている。ＬＵ１１００（２１００）に、ファイルが記憶される。また、ＬＵ１１００（２１００）に、後述のファイルシステム情報の全部又は一部が、記憶されて良い。

図２２は、本発明の一実施例に係るシステム全体のソフトウェア構成において、Ｅｄｇｅ側のＬＵにThin provisioningを適用した構成を示す図である。

Thin provisioningが適用されたＲＡＩＤシステム１１０には、１又は複数のプール１１２０が備えられる。プール１１２０は複数のページ１１３０を含んでいる。ページ１１３０は、プール１１２０が固定長で分割されることにより得られた個々の格納領域である。仮想ＬＵ（Thin provisioningが適用されたＬＵ）が、複数の仮想領域で構成されている。仮想ＬＵ１１１０に書き込みが行われると、その都度、ページ１１３０が仮想ＬＵ１１１０の書き込み先の仮想領域へ割り当てられる。ディスクの容量は、プール１１２０単位で増設することができる。プール１１２０に、サイズの異なる複数のページ１１３０が含まれていても良い。

再び図３を参照する。ファイルストレージ装置１２０のメモリ１２１（アーカイブ装置２２０のメモリ２２１）には、データムーバプログラム１２１０（２２１０）と、ファイルシステム１２１１（２２１１）と、カーネル／ドライバ１２１２（２２１２）と、が記憶されている。ファイルストレージ装置１２０のメモリ１２１には、更に、ファイル共有プログラム１２１３が記憶されている。以下、ファイルストレージ装置１２０内のデータムーバプログラムを、「ローカルムーバ」と言い、アーカイブストレージ装置２２０内のデータムーバプログラムを、「リモートムーバ」と言い、それらを特に区別しない場合に、「データムーバプログラム」と言う。ファイルサーバ装置１２０とアーカイブ装置２２０との間では、ローカルムーバ１２１０及びリモートムーバ２２１０を介して、ファイルのやり取りが行われる。

ローカルムーバ１２１０は、ＲＡＩＤシステム１１０のＬＵ１１００から、レプリケーション対象のファイルを読み出し、そのファイルをアーカイブ装置２２０に転送する。リモートムーバ２２１０は、レプリケーション対象のファイルをファイルストレージ装置１２０から受信し、そのファイルを、ＲＡＩＤシステム２１０のＬＵ２１００に書き込む。

また、ローカルムーバ１２１０は、ＬＵ１１００内のレプリケーション済みファイル（厳密にはその実体）を、ある所定の条件が満たされた場合に、削除し、それにより、レプリケーション済みファイルの実質的なマイグレーションを実現する。その後、ローカルムーバ１２１０は、削除されたファイルのスタブ（メタデータ）に対してクライアント／ホスト１３０からリード要求を受けた場合、リモートムーバ２２１０を経由して、スタブにリンクしているファイルを取得し、取得したファイルをクライアント／ホスト１３０に送信する。なお、本実施例において、「スタブ」とは、ファイルの格納先情報（リンク先を表す情報）に関連付けられたオブジェクト（メタデータ）である。クライアント／ホスト１３０からは、ファイルであるかスタブであるかは分からない。

ファイルシステム１２１１（２２１１）は、ファイルシステムプログラムであり、ファイルシステム情報を管理する。ファイルシステム情報は、各ファイルに関する情報（例えば、ファイルのサイズや場所などを表す情報）を含む。具体的には、例えば、ファイルシステム情報は、図４に示すinode管理テーブル４００を含む。inode管理テーブル４００は、複数のinodeより構成される（１行が１つのinodeに対応する）。各inodeは、複数のメタデータで構成される。メタデータの種類としては、ファイルの所有者、ファイルのアクセス権、ファイルサイズ、ファイルの格納位置（データブロックアドレス１、２、３、…）などがある。例えば、inode番号「１００」を含んだ行によれば、ファイルは、図５に示すように、下記のブロック（ＬＵ内のブロック）が記憶するデータで構成されていることがわかる。
（＊）アドレス１００のブロックを先頭とした３つの連続したブロック（データブロックアドレス「１００−３」から特定されるブロック群）内のデータ。
（＊）アドレス２００のブロックを先頭とした２つの連続したブロック（データブロックアドレス２「２００−２」から特定されるブロック群）内のデータ。
（＊）アドレス２５０のブロックを先頭とした５つの連続したブロック（データブロックアドレス３「２５０−５」から特定されるブロック群）内のデータ。

再び、図３を参照する。カーネル／ドライバ１２１２（２１２１）は、ファイルストレージ装置１２０（アーカイブ装置２２０）上で動作する複数のプログラム（プロセス）のスケジュール制御やハードウェアからの割り込みをハンドリングするなど、全般的な制御及びハードウェア固有の制御を行う。

ファイル共有プログラム１２１３は、ＣＩＦＳ（Common Internet File System）、ＮＦＳ（Network File System）といった通信プロトコルを使用して、クライアント／ホスト１３０との間で、ファイル共有サービスを提供するプログラムである。

クライアント／ホスト１３０のメモリ１３１には、アプリケーション１３１０と、ファイルシステム１３１１と、カーネル／ドライバ１３１２が記憶されている。

アプリケーション１３１０は、クライアント／ホスト１３０が、作業の目的に応じて使うソフトウェア（アプリケーションプログラム）である。ファイルシステム１３１１及びカーネル／ドライバ１３１２は、上述のファイルシステム１２１１（２２１１）、カーネル／ドライバ１２１２（２２１２）とほぼ同様である。

本実施例では、inode管理テーブル４００に新たな種類のメタデータが追加されている。

図６は、inode管理テーブル４００に追加されている新たな種類のメタデータを示す。

ファイル毎に（inode毎に）、新たな種類のメタデータがあり、それらは、スタブ化フラグ３１００、データ同期要フラグ３１０１、メタデータ同期要フラグ３１０２、レプリケーションフラグ３１０３、及びリンク先３１０４である。以下、これらのメタデータについて、１つのファイル（図６の説明において「対象ファイル」と言う）を例に採り、説明する。

スタブ化フラグ３１００は、対象ファイルがスタブ化されているか否かを表す。具体的には、例えば、スタブ化フラグ３１００は、対象ファイルがスタブ化されている場合、「ＯＮ」とされ、対象ファイルがスタブ化されていない場合、「ＯＦＦ」とされる。

データ同期要フラグ３１０１（メタデータ同期要フラグ３１０２）は、ファイル（メタデータ）を同期化する必要があるか否かを表す。データ同期要フラグ３１０１（メタデータ同期要フラグ３１０２）は、レプリケーション済みの対象ファイル（そのメタデータ）がＥｄｇｅ１００側とＣｏｒｅ２００側とで一致している場合、「ＯＦＦ」とされる。また、データ同期要フラグ３１０１（メタデータ同期要フラグ３１０２）は、Ｅｄｇｅ１００側で対象ファイル（そのメタデータ）の更新が発生し、Ｃｏｒｅ２００側の対象ファイル（そのメタデータ）と一致しなくなった場合（つまり、同期しなくなった場合）、両方のファイル（両方のメタデータ）を互いに一致させる必要があるため、「ＯＮ」とされる。

レプリケーションフラグ３１０３は、対象ファイルがレプリケーション対象か否かを表す。レプリケーションフラグ３１０３は、対象ファイルがレプリケーション済みの場合に「ＯＮ」とされ、対象ファイルがレプリケーションされていない場合は「ＯＦＦ」とされる。

リンク先３１０４は、対象ファイルの格納先（リンク先）を表す情報（例えば、ＵＲＬ（Uniform Resource Locator））である。

次に、本実施例で行われる処理を説明する。

図７は、レプリケーション処理の流れを示す。なお、図中のＳ＊とはＳＴＥＰ＊（＊は１以上の整数）の略である。

この処理によって、Ｅｄｇｅ１００側と、Ｃｏｒｅ２００側とで、レプリケーション対象のファイルが共有される。

まず、ＳＴＥＰ１では、ローカルムーバ１２１０が、レプリケーション要求を受け取る。レプリケーション要求の発行元や、レプリケーション要求が発行されるタイミングは、特に限定されない。レプリケーション要求は、少なくとも、レプリケーション対象ファイルの識別情報（例えばファイル名）を含む。

次に、ＳＴＥＰ２−１で、ローカルムーバ１２１０は、アーカイブ装置２２０に、レプリケーション対象ファイルの記憶領域を確保することの指令を出す。その指令は、例えば、レプリケーション対象ファイルの識別情報及びサイズを含んでも良い。アーカイブ装置２２０（リモートムーバ２２１０）は、その指令を受けて、レプリケーション対象ファイルの格納先の記憶領域を確保して良い。アーカイブ装置２２０（リモートムーバ２２１０）は、レプリケーション対象ファイルの識別情報と、そのファイルの格納先の情報であるリンク先情報（確保された記憶領域を表す情報）との対応関係をメモリ２２１に記憶することができる。

次に、ＳＴＥＰ２−２で、ローカルムーバ１２１０は、アーカイブ装置２２０（リモートムーバ２２１０）から、レプリケーション対象ファイルのリンク先情報（例えばＵＲＬ）を受信し、レプリケーション対象ファイルのリンク先３１０４として、その受信したリンク先情報を、inode管理テーブル４００に追加する。

次に、ＳＴＥＰ３で、ファイルシステム１２１１は、レプリケーション要求を基に特定されたレプリケーション対象ファイルを、ＬＵ１１００から読み出し、そのファイルを、ローカルムーバ１２１０に転送する。

次に、ＳＴＥＰ４で、ローカルムーバ１２１０は、ファイルシステム１２１１からのレプリケーション対象ファイルをリモートムーバ２２１０へ転送する。例えば、ローカルムーバ１２１０は、ＳＴＥＰ２−２で受信したリンク先情報を指定した、レプリケーション対象ファイルのライト要求（ファイルレベルのライト要求）を、リモートムーバ２２１０に送信して良い。

ＳＴＥＰ５で、リモートムーバ２２１０は、ローカルムーバ１２１０からレプリケーション対象ファイルを受信し、ファイルシステム２２１１（ファイルシステム内の受付プログラム２２１１０）に対して、そのファイルの格納要求を出す。その格納要求は、そのファイルのリンク先情報を含んで良い。ファイルシステム２２１１は、レプリケーション対象ファイルを、それのリンク先情報に基づく場所（ＬＵ２１００）に書き込む。そして、ファイルシステム２２１１による書込みが完了したことが、ファイルシステム２２１１からリモートムーバ２２１０に通知される。リモートムーバ２２１０は、その通知を受けた場合、レプリケーションの完了通知を、ローカルムーバ１２１０に送信する。

ＳＴＥＰ６で、ローカルムーバ１２１０は、リモートムーバ２２１０からレプリケーション完了通知を受信し、ファイルシステム１２１１の受付プログラム１２１１０に、レプリケーションの完了を通知する。

そして、ＳＴＥＰ７で、ファイルシステム１２１１（受付プログラム１２１１０）は、レプリケーション対象ファイルに対応したレプリケーションフラグ３１０３を「ＯＮ」にする（図６参照）。レプリケーションフラグ３１０３が「ＯＮ」となっているファイルが、レプリケーション済みファイルである。

図８は、レプリケーション済みファイル又はそれのメタデータに関するライト処理の流れを示す。

レプリケーション済みファイル又はそれのメタデータが更新されると、ファイルストレージ装置１２０側のレプリケーション済みファイル又はそれのメタデータと、アーカイブ装置２２０側のレプリケーション済みファイル又はそれのメタデータとが異なってしまう。このため、レプリケーション済みファイル又はそれのメタデータの同期処理（ファイルストレージ装置１２０側とアーカイブ装置２２０側でファイル（又はそれのメタデータ）の内容を互いに一致させる処理）が必要となる。本ライト処理では、同期処理が必要であることを表す情報が設定される（レプリケーション済みファイルに対応するデータ／メタデータ同期要フラグ３１０１／３１０２が「ＯＮ」にされる）。

まず、ＳＴＥＰ８で、ファイルシステム１２１１（受付プログラム１２１１０）が、レプリケーション済みファイル（又はそれのメタデータ）に対するライト要求（更新要求）を受け付ける。

次に、ＳＴＥＰ９で、ファイルシステム１２１１（受付プログラム１２１１０）が、当該ファイル（又はそれのメタデータ）の更新を行う。ファイルシステム１２１１（受付プログラム１２１１０）は、レプリケーション済みファイルを更新した場合、そのファイルに対応するデータ同期要フラグ３１０１を「ＯＮ」にし、メタデータを更新した場合、そのメタデータについてのファイルに対応するメタデータ同期要フラグ３１０２を「ＯＮ」にする（図６参照）。なお、更新されたファイル又はメタデータが、レプリケーション済みファイル又はそれのメタデータであるかは、それに対応するレプリケーションフラグ３１０３が「ＯＮ」か否かで判断可能である。

データ／メタデータ同期要フラグ３１０１／３１０２が「ＯＮ」であることは、それに対応するファイル又はそれのメタデータの同期処理が必要であることを示す。同期処理が行われた場合、データ／メタデータ同期要フラグ３１０１／３１０２は、「ＯＦＦ」にされる。

図９は、同期処理の流れを示す。

データ同期要フラグ３１０１が「ＯＮ」のファイル、又は、メタデータ同期要フラグ３１０２が「ＯＮ」のファイルについてのメタデータについて、同期処理が行われる。

まず、ＳＴＥＰ９で、ローカルムーバ１２１０が、同期処理要求を受ける。同期処理要求の発行元や、同期処理要求が発行されるタイミングは、特に限定されない。同期処理要求は、例えば、定期的に又は不定期的に（例えば１日に１回の頻度で）、発行されて良い。

ＳＴＥＰ１０で、ローカルムーバ１２１０は、ファイルシステム１２１１（受付プログラム１２１１０）に対して、データ/メタデータ同期要フラグ３１０１／３１０２が「ＯＮ」になっているファイル及び／又はメタデータの検索要求を出し、そのファイル及び／又はメタデータをファイルシステム１２１１から取得する。

ＳＴＥＰ１１で、ローカルムーバ１２１０は、取得したファイル及び／又はメタデータをリモートムーバ２２１０へ転送する。

ＳＴＥＰ１２で、リモートムーバ２２１０は、ローカルムーバ１２１０からのファイル及び／又はメタデータをＬＵ２１００及び／又はファイルシステム情報に格納する。これにより、ローカルとリモートにおいて、ファイル（及び／又はメタデータ）が互いに一致する（つまり、同期が完了する）。リモートムーバ２２１０は、ファイル及び／又はメタデータを格納した後、格納の完了をローカルムーバ１２１０に通知する。

ファイル及び／又はメタデータの格納が行われた後、ＳＴＥＰ１３で、ローカルムーバ１２１０は、同期処理が行われたファイル（及び／又はメタデータについてファイル）に対応するデータ／メタデータ同期要フラグ３１０１／３１０２を「ＯＦＦ」に変更する。

なお、本同期処理では、ファイル（及び／又はメタデータ）の同期が完了した後に、レプリケーション済み且つ同期済みのファイルをＬＵ１１００から削除して良いか否か（すなわち、そのファイルをレプリケーション対象からマイグレーション対象に切り替えて良いか否か）の判断が行われる。

具体的には、例えば、ローカルムーバ１２１０は、ＬＵ１１００の空き容量をチェックする。ＬＵ１１００の空き容量が所定の閾値未満の場合、ＬＵ１１００の空き容量を増やすべく、レプリケーション済み且つ同期済みのファイルの削除（マイグレーション）が許可される。すなわち、ＳＴＥＰ１４で、ローカルムーバ１２１０が、レプリケーション済み且つ同期済みのファイル（レプリケーションフラグ３１０３が「ＯＮ」であり且つデータ／メタデータ同期要フラグ３１０１／３１０２が「ＯＦＦ」となっているファイル）に対応するスタブ化フラグ３１００を「ＯＮ」にし、そのファイルに対応するレプリケーションフラグ３１０３を「ＯＦＦ」にする。

なお、ファイルの削除（マイグレーション）が許可される条件は、ファイルが格納される記憶領域（ＬＵ）の空き容量が所定の閾値未満という条件に代えて又は加えて、別の条件が採用されて良い。例えば、削除が許可されるファイルは、例えば、そのファイルへの最終アクセス時刻から一定時間が経過したファイルで良い。

本実施例では、削除が許可されたファイル（マイグレーション対象ファイル）をＬＵ１１００から削除することは、当該ファイルのレプリケーションが済んだ直後、或いは、当該ファイルの同期が完了した直後には、行われない。マイグレーション対象ファイルは、そのファイルについて所定の条件が満たされるまで、ローカル側に残る。本実施例では、マイグレーション対象ファイルをＬＵ１１００から削除することは、後述するように、ファイルのリード処理において行われる。

図１０は、メタデータのリード処理の流れを示す。

まず、ＳＴＥＰ１５−１で、ファイルシステム１２１１（受付プログラム１２１１０）が、クライアント／ホスト１３０から、ファイル共有プログラム１２１３を通じて、メタデータのリード要求を受ける。

リード対象のメタデータが、ＬＵ１１００から削除されたファイルのメタデータであるとする。ファイル（厳密にはその実体）が削除されていても、そのファイルについてのメタデータは、ファイルストレージ装置１２０側にも格納されている。

このため、ファイルシステム１２１１は、アーカイブ装置２２０からメタデータを取得することを行わない。具体的には、ＳＴＥＰ１５−２及び１６−１で、ファイルシステム１２１１は、ファイルストレージ装置１２０側のファイルシステム情報（ＬＵ１１００に格納されている情報）から、リード対象のメタデータを取得し、ＳＴＥＰ１６−２で、そのメタデータを、ファイル共有プログラム１２１３を通じてクライアント／ホスト１３０に転送する。

図１１は、ファイルのリード処理の流れを示す。

まず、ＳＴＥＰ１７で、ファイルシステム１２１１（受付プログラム１２１１０）が、クライアント／ホスト１３０から、ファイル共有プログラム１２１３を通じて、ファイルのリード要求を受ける。

ファイルシステム１２１１（受付プログラム１２１１０）は、そのファイルがリコール済みか否かを判断する。リコール済か否かは、例えば、そのファイルについてのデータブロックアドレス（図４参照）が表す値が０（ゼロ）か否かで判断できる。アドレスが表す値が０ということは、ファイルがＬＵ１１００に格納されていないということである。

リコール済みであれば、ＳＴＥＰ１８で、ファイルシステム１２１１（受付プログラム１２１１０）は、リード対象のファイルをＬＵ１１００から読み出し、ＳＴＥＰ２０で、そのファイルを、ファイル共有プログラム１２１３を通じて、クライアント／ホスト１３０に送信する。

一方、リコール済みでなければ、ファイルシステム１２１０（受付プログラム１２１１０）は、ＳＴＥＰ１９で、リコール、すなわち、アーカイブ装置２２０からリード対象のファイルを取得する（例えば、リード対象ファイルのリード要求をアーカイブ装置２２０に送信することで、リード対象ファイルを取得する）。そして、ファイルシステム１２１０は、そのファイルを、ＬＵ１１００に書き込む。ＳＴＥＰ２０で、ファイルシステム１２１０（受付プログラム１２１１０）は、そのファイルを、クライアント／ホスト１３０に送信する。

なお、ファイルのリード要求は、１つのファイルに１つであっても良いし、１つのファイルに複数であっても良い。後者の場合、ファイルは部分的に読み出される。１つのファイルについての複数のリード要求の各々は、ファイルのどの部分のデータを読み出すかが指定されて良い。具体的には、例えば、ファイルの先頭からのオフセット値と読み出すサイズを表す情報（ファイル部分を表す情報）をリード要求が有し、ファイルシステム１２１０は、そのファイル部分について、リコール済か否かを判断して良い。リコール済であれば、ファイルシステム１２１０は、リコール済のファイル部分をクライアント／ホスト１３０へ送信し、リコール済で無ければ、該当ファイル部分をアーカイブ装置２２０から取得して良い。

ところで、クライアント／ホスト１３０からは、ファイルのリード要求の前に、オープン要求が発行され、ファイルのリード要求の後に、クローズ要求が発行される。オープン要求、リード要求及びクローズ要求の３つの要求の処理が完了することで、１つのリード処理の完了となる。

本実施例では、マイグレーション対象ファイル（削除することが許可されているファイル）を実際に削除するタイミングは、リード要求の前にオープン要求が発行されリード要求の後にクローズ要求が発行されるという仕様に着目して定義されたタイミングとなっている。

具体的には、図１２Ａに示すように、ファイルシステム１２１１は、オープン要求を受けた場合、オープン対象のファイル（リードされるファイル）についての参照カウント値に１を加算する。ファイルシステム１２１１は、オープン要求を受ける都度に、オープン対象のファイルについての参照カウント値に１を加算する。

一方、図１２Ｂに示すように、ファイルシステム１２１１は、クローズ要求を受けた場合、クローズ対象のファイル（リードされたファイル）についての参照カウント値から１を減算する。ファイルシステム１２１１は、クローズ要求を受ける都度に、クローズ対象のファイルについての参照カウント値から１を減算する。

そして、マイグレーション対象ファイル（スタブ化フラグ３１００が「ＯＮ」でありデータ／メタデータ同期フラグ３１０１／３１０２が「ＯＦＦ」のファイル）についての参照カウント値が０より大きい値から０になったときに、図１２Ｃに示すように、ローカルムーバ１２１０が、当該ファイル（厳密には、その実体）をＬＵ１１００から削除する。この削除により、実質的にマイグレーションが完了したことになる。つまり、マイグレーション対象ファイルが、マイグレーション済みのファイルになる。なお、その際、ファイルシステム１２１１は、削除されたファイルについてのinodeを更新する。従って、例えば、削除されたファイルについてのデータブロックアドレスが表す値は、０（ゼロ）とされる。
さらに、Ｅｄｇｅ１００側のＬＵ１１００にThin provisioningが適用されている場合は（図２２参照）、当該ファイルを削除する代わりに、当該ファイルを、ある固定値（例えば、０）で上書きし、ＲＡＩＤシステム１１０に対して、当該ファイルが格納されていた仮想領域（当該ファイルが格納されていたブロックアドレス）が解放可能である旨を通知してもよい。ＲＡＩＤシステム１１０は、その通知を受けて、通知された仮想領域に割り当てられているページ１１３０を、その仮想領域から解放して良い。ここで、仮想領域とは、前述したように、仮想ＬＵ（Thin provisioningが適用されたＬＵ）１１００を構成する仮想的な記憶領域のことである。また、当該ファイルを固定値で上書きするとは、当該ファイルを格納している仮想領域を通じて、この仮想領域に割り当てられているページ１１３０の全域に固定値を上書きすることである。ページ１１３０の全域に固定値が書き込まれている場合、そのページ１１３０内のデータは、クライアント／ホスト１３０にとって不要である。従って、その不要なデータのみを記憶しているページ１１３０は、仮想領域から解放されて良い。これにより、プールの空き容量（未割当のページ１１３０の数）を増やすことができる。

このような削除タイミング（マイグレーションタイミング）によれば、参照頻度の高いファイルをローカル側に残し、参照頻度の低いファイルをローカル側から削除しリモート側にのみ残すことができる。

図１３は、マイグレーション済みファイルに関するライト処理の流れを示す。

ＳＴＥＰ２３で、ファイルシステム１２１１（受付プログラム１２１１０）が、クライアント／ホスト１３０から、ファイルのライト要求を受ける。

ＳＴＥＰ２４で、ファイルシステム１２１１（受付プログラム１２１１０）が、ライト対象のファイルに対応したスタブ化フラグ３１００をチェックする。

スタブ化フラグ３１００が「ＯＮ」の場合、ＳＴＥＰ２５で、ファイルシステム１２１１が、アーカイブ装置２２０から、ライト対象のファイルを取得し、取得したファイルをＬＵ１１００に書き込む。そして、ファイルシステム１２１１は、そのファイルについて、スタブ化フラグ３１００を「ＯＦＦ」にし、且つ、レプリケーションフラグ３１０３を「ＯＮ」にする。なお、ライト対象のファイルがリコール済みのファイルの場合、ファイルをアーカイブ装置２２０から取得する処理はスキップされて良い。

その後、ファイルシステム１２１１は、ＳＴＥＰ２３で受信したライト要求に従い、ＬＵ１１００内の当該ファイルを更新する。

そして、ファイルシステム１２１１は、ＳＴＥＰ２６で、更新されたファイルについてのデータ／メタデータ同期要フラグ３１０１／３１０２を「ＯＮ」にする。ファイルの更新により、ファイルストレージ装置１２０側とアーカイブ装置側２２０で、ファイル及びそのメタデータが異なり、それ故、同期処理が必要になったからである。

図１３に示すライト処理によれば、マイグレーション済みファイルについてライト要求を受けた場合（ＬＵ１１００から削除されているファイルのスタブについてライト要求を受けた場合）、ファイルのスタブが解除されることになる。

さて、前述した説明によれば、図１４Ａに示すように、ＬＵ１１００の空き容量の閾値が設定されている。ＬＵ１１００の空き容量とは、ＬＵ１１００の容量からＬＵ１１００の使用量を除く容量である。ＬＵ１１００の使用量は、レプリケーション対象外のファイルの総容量と、レプリケーション済みファイルの総容量との合計である。

図１４Ａに示す状態によれば、レプリケーション対象外のファイルの総容量が、レプリケーション済みファイルの総容量よりも多く、且つ、ＬＵ１１００の空き容量が、閾値を超えているものの、閾値に近い。

この状態において、マイグレーション済みファイル（厳密にはそのスタブ）に対するライト要求があると、そのファイルのリコール（アーカイブ装置２２０側からのそのファイルの読み出し）によって、そのファイルがＬＵ１１００に書き込まれることになり、そうすると、ファイルの空き容量が減り、その結果、図１４Ｂに示すように、空き容量が閾値未満になることがある。この場合、レプリケーション済みファイルの削除が許可される。

また、ライト処理のためにリコールされたファイル（スタブから特定されたリンク先から取得されたファイル）は、更新され同期要となる。

このため、同期処理の時間間隔が短く設定されていた場合、リコールによるファイルの移動と、同期よるファイルの移動が、頻繁に行われてしまう。つまり、通信ネットワーク１を経由したファイル転送が頻発してしまう。

そこで、本実施例では、レプリケーション対象外のファイルが、所定の条件下でレプリケーション候補とされ、レプリケーション候補も、レプリケーションされる。

図１５は、レプリケーション対象外のファイルをレプリケーション候補のファイルとする処理の流れを示す。図１６は、図１５に示すＳＴＥＰ２７−３及び２７−４を示す。

ＳＴＥＰ２７−１で、ローカルムーバ１２１０が、レプリケーション要求を受け付ける。

ＳＴＥＰ２７−２で、ローカルムーバ１２１０が、そのレプリケーション要求に含まれるファイルリスト（例えば、レプリケーション対象のファイルの識別情報のリスト）を、ファイルストレージ装置１２０内（例えばメモリ１２１）に保存する。レプリケーション対象のファイルは、前述したように、レプリケーションされるので、保存されたファイルリストを、以下、「レプリケーション済みファイルリスト」と言う。ファイルストレージ装置１２０は、例えばメモリ１２１に、１以上のレプリケーション済みファイルリストを有する。

ＳＴＥＰ２７−３で、ローカルムーバ１２１０は、保存されている１以上のレプリケーション済みファイルリストから特定される複数のレプリケーション済みファイルについての１以上のメタデータを基に、それら複数のレプリケーション済みファイルの共通の特性（例えば、ファイルサイズや最終更新日付）を抽出する。以下、抽出された共通特性を表す情報を、「特性リスト」と言う。特性リストは、１種類以上のメタデータについて、共通特性情報を有する。また、共通特性情報は、１つの共通の値であっても良いし、値の範囲（例えば、複数の共通の値のうちの最小値から最大値までの範囲）であっても良いし、１又は複数の共通の値に一定の値が加算又は減算等された値でも良い。

その後、ＳＴＥＰ２７−４で、ローカルムーバ１２１０は、レプリケーション対象外のファイル（レプリケーションフラグ３１０３が「ＯＦＦ」且つリンク先３１０４が設定されていないファイル）の１以上のメタデータと、特性リストが有する共通特性情報とを比較する。ローカルムーバ１２１０は、レプリケーション対象外のファイルのうち、共通特性情報に適合するメタデータに対応したファイルを、レプリケーション候補とする。

レプリケーション候補のファイルが、レプリケーションされる。そのレプリケーションのタイミングは、例えば、図１７に示す監視プログラム１２１４の判断結果に基づいて決定される。監視プログラム１２１４は、図１７に示すように、ファイルストレージ装置１２０内のＣＰＵ１２２で実行されるプログラムである。なお、レプリケーション候補のファイルをレプリケーションするタイミングはこれに限定されないで良い。

図１７は、レプリケーション候補のファイルをレプリケーションする流れを示す。

定期的に又は不定期的に、ＳＴＥＰ２８が行われる。

ＳＴＥＰ２８で、監視プログラム１２１４が、ＬＵ１１００の使用量（ＬＵ１１００におけるレプリケーション済みファイルの総容量）に対する、ＬＵ１１００におけるレプリケーション対象外ファイルの総容量の割合（以下、対象外割合）を算出する。

そして、ＳＴＥＰ２９で、監視プログラム１２１４が、対象外割合が或る一定値を超えている場合、対象外割合が一定値よりも下がるまで、レプリケーション候補としたファイルのレプリケーションを実施する。

図１５乃至図１７を参照した説明によれば、対象外割合が一定値を超えていれば、レプリケーション対象として指定されていない複数のファイル（レプリケーション対象外ファイル）のうちの１以上のファイルが、レプリケーションされ、それにより、レプリケーション済みファイルとなる。つまり、レプリケーション済みファイルが増える。レプリケーション済みファイルは、やがて、スタブ化されるので、ＬＵ１１００の空き容量が増えることになる。このため、ＬＵ１１００の空き容量とその閾値との差が広がることが期待される。従って、通信ネットワーク１を介したファイル転送が頻発することの回避が期待できる。

次に、図１８〜図２１のフローチャートを参照して、プログラムごとの処理の流れを説明する。

図１８は、ファイルシステム１２１１（受付プログラム１２１１０）の処理の流れを示すフローチャートである。

ＳＴＥＰ３００で、ファイルシステム１２１１は、ファイルの処理要求（例えば、アクセス要求、オープン要求又はクローズ要求）を受け付けると、その処理要求から特定されるファイル（以下、図１８の説明において「対象ファイル」）のスタブ化フラグ３１００をチェックする。スタブ化フラグ３１００が「ＯＮ」であれば（ＳＴＥＰ３００：ＹＥＳ）、ＳＴＥＰ３０１に進む。スタブ化フラグ３１００が「ＯＦＦ」であれば（ＳＴＥＰ３００：ＮＯ）、ファイルがＬＵ１１００に残っているのでＳＴＥＰ３０５に進む。

ＳＴＥＰ３０１で、ファイルシステム１２１１は、受信した処理要求をチェックする。処理要求が、リード要求の場合、ＳＴＥＰ３０２に進み、リード要求以外の場合、ＳＴＥＰ３１０に進む。

ＳＴＥＰ３０２で、ファイルシステム１２１１は、対象ファイルのメタデータの一種であるデータブロックアドレスが有効かどうかを判断する。データブロックアドレスが有効な場合（ＳＴＥＰ３０２：ＹＥＳ）、ＳＴＥＰ３０３に進む。データブロックアドレスが有効でない場合（ＳＴＥＰ３０２：ＮＯ）、ＳＴＥＰ３０４に進む。

ＳＴＥＰ３０３で、ファイルシステム１２１１は、対象ファイルをＬＵ１１００から読み出し、読み出したファイルを、要求元（クライアント／ホスト１３０）へ送信する。

ＳＴＥＰ３０４で、ファイルシステム１２１１は、ファイルのリコールを行う。すなわち、ファイルシステム１２１１は、ローカルムーバ１２１０に対して、アーカイブ装置２２０側から対象ファイルを取得するように要求し、その要求に応答してアーカイブ装置２２０から取得されたファイルを、一旦ＬＵ１１００に格納してから、要求元へ送信する。

ＳＴＥＰ３０５で、ファイルシステム１２１１は、受信した処理要求をチェックする。処理要求が、ライト要求以外の場合（ＳＴＥＰ３０５：ＮＯ）、ＳＴＥＰ３０６に進む。処理要求が、ライト要求の場合、ＳＴＥＰ３０７に進む。

ＳＴＥＰ３０６で、ファイルシステム１２１１は、受信した処理要求（オープン要求、クローズ要求又はリード要求）に従う処理を行う。

ＳＴＥＰ３０７で、ファイルシステム１２１１は、対象ファイルのレプリケーションフラグ３１０３を確認する。レプリケーションフラグ３１０３が「ＯＮ」の場合（ＳＴＥＰ３０７：ＹＥＳ）、ＳＴＥＰ３０８に進む。レプリケーションフラグ３１０３が「ＯＦＦ」の場合（ＳＴＥＰ３０７：ＮＯ）、ＳＴＥＰ３０９に進む。

ＳＴＥＰ３０８で、ファイルシステム１２１１は、対象ファイルのデータ／メタデータ同期要フラグ３１０１／３１０２を「ＯＮ」にする。後のＳＴＥＰ３０９のライト処理により、ファイルストレージ装置１２０側とアーカイブ装置２２０側との間で対象ファイル及びそれのメタデータが異なってしまうからである。

ＳＴＥＰ３０９で、ファイルシステム１２１１は、対象ファイルのライト処理を実行する。また、Ｅｄｇｅ１００側のＬＵ１１１０にThin provisioningが適用されている場合は（図２２）、ＳＴＥＰ３０９の実行時に格納領域として、ページが割り当てられる。

ＳＴＥＰ３１０で、ファイルシステム１２１１は、受信した処理要求をチェックする。処理要求がライト要求の場合、ＳＴＥＰ３１２に進む。処理要求がオープン処理の場合、ＳＴＥＰ３１１に進む。処理要求がクローズ処理の場合、ＳＴＥＰ３１６に進む。

ＳＴＥＰ３１１で、ファイルシステム１２１１は、対象ファイルについての参照カウント値に１を加算して、オープン処理を実行する。

ＳＴＥＰ３１２で、ファイルシステム１２１１は、データムーバプログラム１２１０に対して、対象ファイルをリコールする（アーカイブ装置２２０にファイルの取得を要求する）。

ＳＴＥＰ３１３で、ファイルシステム１２１１は、対象ファイルについて、スタブ化フラグ３１００をＯＦＦにし、レプリケーションフラグ３１０３をＯＮにする。

ＳＴＥＰ３１４で、ファイルシステム１２１１は、ＳＴＥＰ３１２で取得したファイルを更新する（そのファイルに、処理要求に従うファイルを上書きする）。また、Ｅｄｇｅ１００側のＬＵ１１１０にThin provisioningが適用されている場合は（図２２参照）、ＳＴＥＰ３１４の実行時に格納領域としてページが割り当てられる。

ＳＴＥＰ３１５で、ファイルシステム１２１１は、対象ファイルのデータ／メタデータ同期要フラグ３１０１／３１０２を「ＯＮ」にする。

ＳＴＥＰ３１６で、ファイルシステム１２１１は、対象ファイルについての参照カウント値から１を減算し、クローズ処理を実行する。

ＳＴＥＰ３１７で、ファイルシステム１２１１は、対象ファイルについての参照カウント値が０で、かつ、対象ファイルのデータ／メタデータ同期要フラグ３１０１／３１０２が「ＯＦＦ」かどうかを判断する。

ＳＴＥＰ３１７の判断結果が肯定的の場合（ＳＴＥＰ３１７：ＹＥＳ）、ＳＴＥＰ３１８で、ファイルシステム１２１１は、Thin provisioningの適用可否を判断する。判断結果が否定的の場合（ＳＴＥＰ３１８：ＮＯ）、ＳＴＥＰ３１９で、ファイルシステム１２１１は、対象ファイルをＬＵ１１００から削除する（対象ファイルのメタデータは、ファイルシステム情報に残る）。また、ＳＴＥＰ３１８で、判断結果が肯定的の場合（ＳＴＥＰ３１８：ＹＥＳ）、ファイルシステム１２１１は、ＳＴＥＰ３２０で割当領域を解放する（対象ファイルのメタデータは、ファイルシステム情報に残る）。これにより、対象ファイルの実質的なマイグレーションが完了する。

ＳＴＥＰ３１７の判断結果が否定的の場合（ＳＴＥＰ３１７：ＮＯ）、ファイルシステム１２１１は、対象ファイルを削除しない。対象ファイルについての参照カウント値が１以上であるということは、対象ファイルがいずれかのクライアント／ホスト１３０から参照されているからである。

図１９は、データムーバプログラムの処理の流れを示すフローチャートである。

本実施例では、ファイルストレージ装置１２０とアーカイブ装置２２０の両方に、同一のデータムーバプログラムを実行させることができる。データムーバプログラムの動作モードとして、ファイルストレージ装置とアーカイブ装置があり、装置１２０及び２２０のどちらで実行されるかによって、設定される動作モードが異なる。

ＳＴＥＰ４００で、データムーバプログラムは、設定されている動作モードをチェックする。動作モードが「ファイルストレージ装置」の場合、ＳＴＥＰ４０２に進み、動作モードが「アーカイブ装置」の場合、ＳＴＥＰ４１７に進む。

ＳＴＥＰ４０２で、データムーバプログラムが、レプリケーション対象のファイルに対する処理要求を受信したかどうかを判断する。ここで、処理要求とは、レプリケーション要求、又は、データ／メタデータの同期処理要求である。処理要求を受信した場合（ＳＴＥＰ４０２：ＹＥＳ）、ＳＴＥＰ４０３に進む。

ＳＴＥＰ４０３で、データムーバプログラムが、処理要求に含まれるファイルリストを保存する。

ＳＴＥＰ４０４で、データムーバプログラムが、処理要求の種別をチェックする。処理要求がレプリケーション要求の場合は、ＳＴＥＰ４０５に進み、処理要求が同期処理要求の場合は、ＳＴＥＰ４１０に進む。

ＳＴＥＰ４０５で、データムーバプログラムが、アーカイブ装置２２０から、保存したファイルリストから特定されるファイル（レプリケーション対象のファイル）の格納先情報（例えばＵＲＬ）を取得する。

ＳＴＥＰ４０６で、データムーバプログラムが、レプリケーション対象のファイルについて、リンク先３１０４として、取得した格納先情報を登録する。

ＳＴＥＰ４０７で、データムーバプログラムが、レプリケーション対象のファイルをＬＵ１１００から読み出す。

ＳＴＥＰ４０８で、データムーバプログラムが、読み出したファイルをアーカイブ装置２２０に転送する。具体的には、例えば、データムーバプログラムが、読み出したファイルのライト要求（そのファイルのリンク先３１０４が表す格納先情報を有するライト要求）をアーカイブ装置２２０に送信する。

ＳＴＥＰ４０９で、データムーバプログラムが、転送したファイルのレプリケーションフラグ３１０３を「ＯＮ」にする。これにより、当該ファイルがレプリケーション済みファイルとなる。

ＳＴＥＰ４１０で、データムーバプログラムが、データ／メタデータ同期要フラグ３１０１／３１０２がＯＮになっているファイルをＬＵ１１００から読み出す。

ＳＴＥＰ４１１で、データムーバプログラムが、読み出したファイルをアーカイブ装置２２０へ転送する。具体的には、例えば、データムーバプログラムが、読み出したファイルのライト要求（そのファイルのリンク先３１０４が表す格納先情報を有するライト要求）をアーカイブ装置２２０に送信する。

ＳＴＥＰ４１２で、データムーバプログラムが、転送したファイルについて、データ／メタデータ同期要フラグ３１０１／３１０２を「ＯＦＦ」にする。これにより、レプリケーション済みファイルの同期処理が完了する。

ＳＴＥＰ４１３で、データムーバプログラムが、ＬＵ１１００の空き容量が所定の閾値未満か否かを判断する。

ＬＵ１１００の空き容量が所定の閾値未満の場合（ＳＴＥＰ４１３：ＹＥＳ）、ＳＴＥＰ４１５で、データムーバプログラムが、レプリケーションフラグ３１０３が「ＯＮ」のファイルについて、スタブ化フラグ３１００を「ＯＮ」にし、且つ、レプリケーションフラグ３１０３を「ＯＦＦ」にする。つまり、レプリケーション済みファイルの削除が許可される。この後、クライアント／ホスト１３０からの当該ファイルに関するリード処理が少なくとも１回行われ、そのファイルについての参照カウント値が０になったら、そのファイルが削除される。つまり、実質的にマイグレーションが完了する。

ＳＴＥＰ４１７で、データムーバプログラムが、ファイルストレージ装置１２０からファイルを受信したかどうかを判断する。ファイルを受信した場合（ＳＴＥＰ４１７：ＹＥＳ）、ＳＴＥＰ４１８に進む。

ＳＴＥＰ４１８で、データムーバプログラムは、受信したファイルを、ＬＵ２１００に格納する。

図２０及び図２１は、監視プログラム１２１４の処理の流れを示すフローチャートである。

ＳＴＥＰ５００で、監視プログラム１２１４は、ファイルリスト（レプリケーション済みファイルリスト）が追加されたかどうかをチェックする。ファイルリストが追加された場合（Ｓ５００：ＹＥＳ）、ＳＴＥＰ５０２に進む。

ＳＴＥＰ５０２で、監視プログラム１２１４は、特性リストがあるかどうかをチェックする。特性リストがある場合（ＳＴＥＰ５０２：ＹＥＳ）、ＳＴＥＰ５０３に進む。特性リストがない場合（ＳＴＥＰ５０２：ＮＯ）、特性リストを作成すべく、監視プログラム１２１４は、図２１に示す処理を行う。

ＳＴＥＰ５０３で、監視プログラム１２１４は、追加されたファイルリストから特定されるファイルのメタデータと、特性リストの共通特性情報とを比較する。その結果、メタデータが共通特性情報に適合する場合（ＳＴＥＰ５０４：ＹＥＳ）、ＳＴＥＰ５０５に進む。メタデータが共通特性情報に適合しない場合（ＳＴＥＰ５０４：ＮＯ）、特性リストに新たな共通特性情報を追加すべく、監視プログラム１２１４は、図２１に示す処理を行う。

ＳＴＥＰ５０５で、監視プログラム１２１４は、マイグレーション対象外のファイルについてのメタデータと特性リストが有する共通特性情報とを比較し、共通特定情報に適合するメタデータに対応したレプリケーション対象外ファイルを、レプリケーション候補とする。ここでは、レプリケーション候補のファイルのリスト（以下、候補リスト）が作成される。候補リストは、例えば、各レプリケーション候補ファイルの識別情報を有する。

ＳＴＥＰ５０６では、監視プログラム１２１４は、前述した対象外割合（ＬＵ１１００の使用量（レプリケーション対象のファイルの総容量とレプリケーション対象外のファイルの総容量との合計値）に対するレプリケーション対象外のファイルの総容量の割合）を求め、その割合が、一定値を超えているかどうかを判断する。超えている場合（ＳＴＥＰ５０５：ＹＥＳ）、ＳＴＥＰ５０６に進む。超えていない場合（ＳＴＥＰ５０５：ＹＥＳ）、ＳＴＥＰ５００に戻る。

ＳＴＥＰ５０７で、監視プログラム１２１４は、対象外割合が上記一定値以下となるように、候補リストから１以上のファイルを選択する。これは、候補リストが表す各ファイルの容量を基に行われる。監視プログラム１２１４は、選択したファイルのリスト（以下、レプリケーション対象リスト）を作成する。なお、そのリストを作成することに代えて、上記の候補リストが、レプリケーション対象リストとされても良い。

ＳＴＥＰ５０８で、監視プログラム１２１４は、作成したレプリケーション対象リストを有するレプリケーション要求を、ローカルムーバ１２１０に送付する。ローカルムーバ１２１０は、そのレプリケーション要求に応答して、レプリケーション対象リストから特定されるファイルをレプリケーションする。

さて、前述したように、ＳＴＥＰ５０２：ＮＯ、又は、ＳＴＥＰ５０４：ＮＯの場合、図２１が示す処理が行われる。この処理は、特性リストを作成又は更新する処理である。図２１には、チェック対象のメタデータの種類が幾つか挙げられているが、そのメタデータ種類は一例であり、これに限定されない。ＳＴＥＰ６００〜ＳＴＥＰ６０５では、共通特性を検出すべく、種々の特性（メタデータ）と、追加されたレプリケーション済みファイルを含む複数のレプリケーション済みファイルのメタデータとが比較される。

ＳＴＥＰ６００で、監視プログラム１２１４は、複数のレプリケーション済みファイルの更新日付が一定範囲内にあるかどうかをチェックする。

ＳＴＥＰ６０１で、監視プログラム１２１４は、複数のレプリケーション済みファイルの最終アクセス日付が一定範囲内にあるかどうかをチェックする。

ＳＴＥＰ６０２で、監視プログラム１２１４は、複数のレプリケーション済みファイルの容量（サイズ）が一定範囲内にあるかどうかをチェックする。

ＳＴＥＰ６０３で、監視プログラム１２１４は、複数のレプリケーション済みファイルの参照頻度（リード頻度）が一定範囲内にあるかどうかをチェックする。

ＳＴＥＰ６０４で、監視プログラム１２１４は、複数のレプリケーション済みファイルの更新頻度（ライト頻度）が一定範囲内にあるかどうかをチェックする。

ＳＴＥＰ６０５で、監視プログラム１２１４は、複数のレプリケーション済みファイルの拡張子が同一かどうかをチェックする。

ＳＴＥＰ６０６で、監視プログラム１２１４は、ＳＴＥＰ６０１〜６０５において、複数のレプリケーション済みファイルについて、共通の特性を検出した場合、その特性を表す情報を特性リストに追加する。

以上、本発明の一実施例を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

例えば、ＲＡＩＤシステム１１０及び／又は２１０に代えて、別種のストレージ装置が採用されても良い。

また、レプリケーションされたファイルについて、レプリケーションフラグ３１０３が「ＯＮ」にされるが、データ／メタデータ同期要フラグ３１０１／３１０２が「ＯＦＦ」にされてよい。

また、マイグレーション対象ファイル（レプリケーションフラグ３１０３が「ＯＮ」であり、且つ、データ／メタデータ同期要フラグ３１０１／３１０２が「ＯＦＦ」であるファイル）の削除は、参照カウント値が０になったときと別のタイミングで行われても良い。例えば、マイグレーション対象ファイルの最終アクセス日時から一定時間経過したときに、そのファイルが削除されても良い。

また、スタブの解除は、スタブに対応したファイルについての更新とは異なる契機で行われても良い。

また、ファイルが格納される記憶領域は、ＬＵに限られなくて良い。

１２０…ファイルストレージ装置、２２０…アーカイブ装置

Claims (13)

1. リモートの記憶デバイスを管理するリモートのファイルサーバが接続されているインターネットに接続されておりローカルの記憶デバイスを管理するローカルのファイルサーバであって、
   前記インターネットに接続された第１の通信インタフェース装置と、
   ファイルを指定したリード要求又はライト要求であるアクセス要求を送信する複数のユーザ端末に接続されており前記アクセス要求をユーザ端末から受信する第２の通信インタフェース装置と、
   前記第１及び第２の通信インタフェース装置に接続されたプロセッサと
   を有し、
   各ユーザ端末は、前記リード要求の前に、オープン要求を送信し、前記リード要求の後に、クローズ要求を送信し、
   前記プロセッサが、
   （Ａ）前記ローカルの記憶デバイス内のファイルを前記リモートのファイルサーバにレプリケーションし、
   （Ｂ）第１の条件が満たされた場合に、レプリケーションされたファイルであるレプリケーション済みファイルを、削除可能なマイグレーション対象ファイルとして、前記ローカルの記憶デバイスから削除せずに管理し、
   （Ｃ）前記マイグレーション対象ファイルについて、前記オープン要求を受信する都度に、そのファイルについてのカウント値を第１の規則に従って更新し、
   （Ｄ）前記マイグレーション対象ファイルについて、前記クローズ要求を受信する都度に、そのファイルについてのカウント値を第２の規則に従って更新し、
   （Ｅ）第２の条件が満たされた場合に、前記マイグレーション対象ファイルを前記ローカルの記憶デバイスから削除し、
   前記第２の条件とは、前記マイグレーション対象ファイルについてのカウント値の更新が開始された後に、そのカウント値が所定の値になったことであり、
   前記所定の値は、ファイルがどのユーザ端末からも参照されていないことに相当する値である、
   ファイルサーバ。
2. 請求項１記載のファイルサーバであって、
   前記第１の条件は、前記ローカルの記憶デバイスの空き容量が所定の閾値未満であることである、
   ファイルサーバ。
3. 請求項２記載のファイルサーバであって、
   前記プロセッサは、
   （Ｈ）前記レプリケーション済みファイルについてのライト要求を受けた場合に、そのレプリケーション済みファイルを、同期化対象ファイルとして管理し、
   （Ｉ）前記リモートのファイルサーバが管理するレプリケーション済みファイルを前記同期化対象ファイルと一致させるよう前記同期化対象ファイルを前記リモートのファイルサーバに転送し、
   前記プロセッサは、前記（Ｉ）の後に、前記第１の条件が満たされたか否かの判断を行う、
   ファイルサーバ。
4. 請求項３記載のファイルサーバであって、
   前記プロセッサは、
   （Ｋ）前記ローカルの記憶デバイスから削除された前記マイグレーション対象ファイルのスタブについてライト要求を受けた場合に、そのスタブから特定されるリンク先にある、前記リモートのファイルサーバが管理するファイルを、前記リモートのファイルサーバから取得し、
   （Ｌ）前記取得したファイルを、前記ローカルの記憶デバイスに格納し、
   （Ｍ）前記取得したファイルを、前記（Ｋ）で受けたライト要求に従って更新し、
   前記プロセッサは、前記（Ｋ）を行った場合に、前記スタブを解除する、
   ファイルサーバ。
5. 請求項４記載のファイルサーバであって、
   前記ローカルの記憶デバイスは、複数のレプリケーション済みファイルと、複数のレプリケーション済みファイル以外の１以上のファイルである１以上のレプリケーション対象外ファイルとを記憶し、
   前記プロセッサは、
   （Ｏ）複数のレプリケーション済みファイルのメタデータを基に、前記複数のレプリケーション済みファイルの１以上の共通の特性を抽出し、
   （Ｐ）前記１以上のレプリケーション対象外ファイルから、前記１以上の共通の特性に適合するメタデータに対応したレプリケーション対象外ファイルを選択し、
   （Ｑ）選択したレプリケーション対象外ファイルを、前記リモートのファイルサーバにマイグレーションする、
   ファイルサーバ。
6. 請求項１記載のファイルサーバであって、
   前記第１の条件は、前記ローカルの記憶デバイスの空き容量が所定の閾値未満であることである、
   ファイルサーバ。
7. 請求項６記載のファイルサーバであって、
   前記プロセッサは、
   （Ｈ）前記レプリケーション済みファイルについてのライト要求を受けた場合に、そのレプリケーション済みファイルを、同期化対象ファイルとして管理し、
   （Ｉ）前記リモートのファイルサーバが管理するレプリケーション済みファイルを前記同期化対象ファイルと一致させるよう前記同期化対象ファイルを前記リモートのファイルサーバに転送し、
   前記プロセッサは、前記（Ｉ）の後に、前記第１の条件が満たされたか否かの判断を行う、
   ファイルサーバ。
8. 請求項１記載のファイルサーバであって、
   前記プロセッサは、
   （Ｋ）前記ローカルの記憶デバイスから削除された前記マイグレーション対象ファイルのスタブについてライト要求を受けた場合に、そのスタブから特定されるリンク先にある、前記リモートのファイルサーバが管理するファイルを、前記リモートのファイルサーバから取得し、
   （Ｌ）前記取得したファイルを、前記ローカルの記憶デバイスに格納し、
   （Ｍ）前記取得したファイルを、前記（Ｋ）で受けたライト要求に従って更新し、
   前記プロセッサは、前記（Ｋ）を行った場合に、前記スタブを解除する、
   ファイルサーバ。
9. 請求項１記載のファイルサーバであって、
   前記ローカルの記憶デバイスは、複数のレプリケーション済みファイルと、複数のレプリケーション済みファイル以外の１以上のファイルである１以上のレプリケーション対象外ファイルとを記憶し、
   前記プロセッサは、
   （Ｏ）複数のレプリケーション済みファイルのメタデータを基に、前記複数のレプリケーション済みファイルの１以上の共通の特性を抽出し、
   （Ｐ）前記１以上のレプリケーション対象外ファイルから、前記１以上の共通の特性に適合するメタデータに対応したレプリケーション対象外ファイルを選択し、
   （Ｑ）選択したレプリケーション対象外ファイルを、前記リモートのファイルサーバにマイグレーションする、
   ファイルサーバ。
10. 請求項９記載のファイルサーバであって、
    前記ローカルの記憶デバイスの容量に対する、前記１以上のレプリケーション対象外ファイルの総容量の割合が、一定値以上の場合、前記プロセッサが、前記（Ｐ）を実行する、ファイルサーバ。
11. 請求項１０記載のファイルサーバであって、
    前記（Ｐ）では、前記割合が前記一定値未満になるように、１以上のレプリケーション対象外ファイルが選択される、
    ファイルサーバ。
12. リモートの記憶デバイスを管理するリモートのファイルサーバと、
    ローカルの記憶デバイスを管理しインターネットを介して前記リモートのファイルサーバに接続されたローカルのファイルサーバと
    を備え、
    前記ローカルのファイルサーバは、ファイルを指定したリード要求又はライト要求であるアクセス要求を送信する複数のユーザ端末に接続されており、
    各ユーザ端末は、前記リード要求の前に、オープン要求を送信し、前記リード要求の後に、クローズ要求を送信し、
    （Ａ）前記ローカルのファイルサーバが、前記ローカルの記憶デバイス内のファイルを前記インターネットを介して前記リモートのファイルサーバに転送し、前記リモートのファイルサーバが、そのファイルを前記リモートの記憶デバイスに格納し、それにより、そのファイルがレプリケーションされ、
    （Ｂ）前記ローカルのファイルサーバが、第１の条件が満たされた場合に、レプリケーションされたファイルである、前記ローカルの記憶デバイス内のレプリケーション済みファイルを、削除可能なマイグレーション対象ファイルとして、前記ローカルの記憶デバイスから削除せずに管理し、
    （Ｃ）前記ローカルのファイルサーバが、前記マイグレーション対象ファイルについて、前記オープン要求を受信する都度に、そのファイルについてのカウント値を第１の規則に従って更新し、
    （Ｄ）前記ローカルのファイルサーバが、前記マイグレーション対象ファイルについて、前記クローズ要求を受信する都度に、そのファイルについてのカウント値を第２の規則に従って更新し、
    （Ｅ）前記ローカルのファイルサーバが、第２の条件が満たされた場合に、前記マイグレーション対象ファイルを前記ローカルの記憶デバイスから削除し、
    前記第２の条件とは、前記マイグレーション対象ファイルについてのカウント値の更新が開始された後に、そのカウント値が所定の値になったことであり、
    前記所定の値は、ファイルがどのユーザ端末からも参照されていないことに相当する値である、
    ストレージシステム。
13. リモートの記憶デバイスを管理するリモートのファイルサーバが接続されているインターネットに接続されており、ファイルを指定したリード要求又はライト要求であるアクセス要求を送信する複数のユーザ端末に接続されており、各ユーザ端末から、前記リード要求の前に、オープン要求を受信し、前記リード要求の後に、クローズ要求を受信し、ローカルの記憶デバイスを管理するローカルのファイルサーバに、下記の（Ａ）乃至（Ｅ）、
    （Ａ）前記ローカルの記憶デバイス内のファイルを前記リモートのファイルサーバにレプリケーションし、
    （Ｂ）第１の条件が満たされた場合に、レプリケーションされたファイルであるレプリケーション済みファイルを、削除可能なマイグレーション対象ファイルとして、前記ローカルの記憶デバイスから削除せずに管理し、
    （Ｃ）前記マイグレーション対象ファイルについて、前記オープン要求を受信する都度に、そのファイルについてのカウント値を第１の規則に従って更新し、
    （Ｄ）前記マイグレーション対象ファイルについて、前記クローズ要求を受信する都度に、そのファイルについてのカウント値を第２の規則に従って更新し、
    （Ｅ）第２の条件が満たされた場合に、前記マイグレーション対象ファイルを前記ローカルの記憶デバイスから削除し、
    を実行させ、
    前記第２の条件とは、前記マイグレーション対象ファイルについてのカウント値の更新が開始された後に、そのカウント値が所定の値になったことであり、
    前記所定の値は、ファイルがどのユーザ端末からも参照されていないことに相当する値である、
    コンピュータプログラム。
    

Images