(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-09-16
(45)【発行日】2022-09-28
(54)【発明の名称】ストレージシステムおよびデータ移行方法
(51)【国際特許分類】
G06F 16/182 20190101AFI20220920BHJP
G06F 3/06 20060101ALI20220920BHJP
G06F 13/10 20060101ALI20220920BHJP
G06F 16/13 20190101ALI20220920BHJP
【ＦＩ】
G06F16/182
G06F3/06 301X
G06F3/06 301Z
G06F13/10 340A
G06F16/13 100
【請求項の数】
10
(21)【出願番号】P 2019184724
(22)【出願日】2019-10-07
(65)【公開番号】P2021060818
(43)【公開日】2021-04-15
【審査請求日】2021-06-01
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110002365
【氏名又は名称】特許業務法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】鴨生 悠冬
(72)【発明者】
【氏名】深谷 崇元
(72)【発明者】
【氏名】早坂 光雄
【審査官】鹿野 博嗣
(56)【参考文献】
【文献】米国特許出願公開第２０１２／０１５０７９９（ＵＳ，Ａ１）
【文献】特開２００６－３５０５９９（ＪＰ，Ａ）
【文献】特開２００７－２８０３１９（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １６／１８２
Ｇ０６Ｆ ３／０６
Ｇ０６Ｆ １３／１０
Ｇ０６Ｆ １６／１３
(57)【特許請求の範囲】
【請求項1】
１以上のノードを備えるストレージシステムであって、前記ノードは、システムの管理するデータを格納し、
前記ノードを用いて構成される移行元のシステムから前記ノードを用いて構成される移行先のシステムに、前記移行元のシステムにおいて管理される前記データの移行を制御するデータ移行部と、
前記データの前記移行元のシステムにおける格納先を示す情報を含むスタブ情報を前記移行先のシステムに作成するデータ処理部と、
前記移行元のシステムと前記移行先のシステムとで共有される論理デバイスのページを論理ボリュームに割り当てる論理ボリューム管理部と、
を備え、
前記データ移行部は、前記移行元のシステムのデータの前記移行先のシステムへの移行を前記データ処理部に指示し、
前記データ処理部は、前記データの移行の指示を受けた場合に、前記データのスタブ情報があるときは、前記スタブ情報をもとに前記移行元のシステムから前記データを読み出し、前記データを書き込むように前記移行先のファイルシステムに指示し、前記スタブ情報を削除し、
前記データ移行部は、前記データの移行が完了した場合に、前記データを削除するように前記移行元のシステムに指示し、
前記データ移行部は、論理ボリューム単位で前記データ移行の指示を行い、前記移行元のシステムで用いられる論理ボリュームに割り当てられているページの全てのデータが前記移行先のシステムに移行されたと判定した場合、前記論理ボリュームのページを解放するように指示する、
ストレージシステム。
【請求項2】
前記システムは、複数のデータを管理し、前記データ移行部は、前記移行元のシステムおよび前記移行先のシステムで用いられている前記ノードの空容量を管理し、
前記データ移行部は、
（Ａ）前記ノードの空容量に基づいて前記移行するデータを選択して、前記データの移動を前記データ処理部に指示する、
（Ｂ）前記移行が完了したデータを削除するように前記移行元のシステムに指示する、
（Ｃ）前記データが削除された前記ノードの空容量を更新する
の（Ａ）～（Ｃ）を繰り返してデータ移行を制御する
請求項１に記載のストレージシステム。
【請求項3】
前記ノードは複数あり、ノードごとに前記データを格納する記憶デバイスを有している請求項２に記載のストレージシステム。
【請求項4】
前記移行元のシステムおよび前記移行先のシステムは、複数の前記ノードを用いて構成される分散システムである、請求項１に記載のストレージシステム。
【請求項5】
前記移行元のシステムおよび前記移行先のシステムは、前記複数のノードを用いて構成される分散システムであり、前記複数のノードに分散させてデータを格納し、少なくとも１のノードを共有している請求項３に記載のストレージシステム。
【請求項6】
前記データ移行部は、前記移行元のシステムにおける格納先であるノードの空容量が少ないデータを、移行するデータとして選択する、請求項２に記載のストレージシステム。
【請求項7】
前記移行元のシステムおよび前記移行先のシステムで用いられている前記ノードは、ストレージデバイスを有し、前記移行元のシステムと前記移行先のシステムとで共有される前記ストレージデバイスの論理デバイスのページを論理ボリュームに割り当てる論理ボリューム管理部を備え、
前記データ移行部は、論理ボリューム単位で前記データ移行の指示を行い、前記移行元のシステムで用いられる論理ボリュームに割り当てられているページの全てのデータが前記移行先のシステムに移行されたと判定した場合、前記論理ボリュームのページを解放するように指示する、
請求項４に記載のストレージシステム。
【請求項8】
前記移行元のシステムおよび前記移行先のシステムのデータ管理単位は、ファイル、オブジェクトまたはブロックの何れかである、請求項１に記載のストレージシステム。
【請求項9】
前記ノードは、前記移行元のシステムと前記移行先のシステムとで共有される論理デバイスのページを前記移行先のシステムと前記移行元のシステムとで共有される論理ボリュームに割り当てる論理ボリューム管理部と、前記移行元のシステムと前記移行先のシステムとのデータを前記論理ボリュームを介して管理するローカルシステム部と、を備える、請求項１に記載のストレージシステム。
【請求項10】
１以上のノードを備えるストレージシステムにおけるデータ移行方法であって、前記ノードは、システムの管理するデータを格納し、
前記ストレージシステムは、
前記ノードを用いて構成される移行元のシステムから前記ノードを用いて構成される移行先のシステムに、前記移行元のシステムにおいて管理される前記データの移行を制御するデータ移行部と、
前記データの前記移行元のシステムにおける格納先を示す情報を含むスタブ情報を前記移行先のシステムに作成するデータ処理部と、
前記移行元のシステムと前記移行先のシステムとで共有される論理デバイスのページを論理ボリュームに割り当てる論理ボリューム管理部と、
を備え、
前記データ移行部が、前記移行元のシステムのデータの前記移行先のシステムへの移行を前記データ処理部に指示することと、
前記データ処理部が、前記データの移行の指示を受けた場合に、前記データのスタブ情報があるときは、前記スタブ情報をもとに前記移行元のシステムから前記データを読み出し、前記データを書き込むように前記移行先のファイルシステムに指示し、前記スタブ情報を削除することと、
前記データ移行部が、前記データの移行が完了した場合に、前記データを削除するように前記移行元のシステムに指示することと、
前記データ移行部が、論理ボリューム単位で前記データ移行の指示を行い、前記移行元のシステムで用いられる論理ボリュームに割り当てられているページの全てのデータが前記移行先のシステムに移行されたと判定した場合、前記論理ボリュームのページを解放するように指示することと、
を含むデータ移行方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ストレージシステムおよびデータ移行方法に関し、例えば、移行元のシステムから移行先のシステムにデータを移行可能なストレージシステムおよびデータ移行方法に適用して好適なものである。
【背景技術】
【0002】
ストレージシステムのユーザが古いシステムを新しいシステムに交換する場合、ワークロードを引き継ぐためにシステム間のデータの同期が必要である。最近のストレージメディアは、以前よりもはるかに大きい容量を持つ。このため、新旧のシステム間でデータを同期するには、非常に長い時間がかかり、場合によっては１週間以上かかる。ユーザは、このように長い間、業務を停止したくなく、同期の間も業務を続けたいと考えている。
【0003】
ここで、移行元ファイルシステムから移行先ファイルシステムへのデータ同期中に、受領した要求を移行元ファイルシステムと移行先ファイルシステムとに転送し、同期の完了後は、受領した要求を移行先ファイルシステムに転送することで、ファイルシステムの移行時の業務の停止時間を抑制する技術が開示されている（特許文献１参照）。
【0004】
また、同期確認中の業務の停止時間の削減を目的として、スタブファイルを作成し、アクセス先を移行前に移行先ファイルシステムに切り替える技術が開示されている（特許文献２参照）。
【先行技術文献】
【特許文献】
【0005】
【文献】米国特許第９３１１３１４号明細書
【文献】米国特許第８８５６０７３号明細書
【発明の概要】
【発明が解決しようとする課題】
【0006】
スケールアウト型のファイルＳＤＳ（Software Defined Storage）は、企業のプライベートクラウドで広く用いられている。こうしたファイルＳＤＳにおいても、ソフトウェアのバージョンアップ、製品のＥＯＬ（End of Life）等を契機に下位互換性のない異種システムに移行が必要となる場合がある。
【0007】
ここで、ファイルＳＤＳは、数十台から数千台の汎用サーバから構成されるが、データの移行の際に同等性能および同等容量を実現する装置を別途用意するのは、コスト面および物理的制約から現実的でない。
【0008】
しかしながら、特許文献１と特許文献２とに記載の各技術においては、移行元と移行先とが別装置であることを前提としており、移行先の装置として移行元と同等以上の装置を用意する必要がある。仮に、移行先として同一装置を使用した場合、特許文献１と特許文献２とに記載の各技術では、移行中に移行元と移行先とでデータを重複して持つこととなる。移行元の容量と移行先の容量との合計が物理容量より大きい場合、容量が枯渇し、移行が失敗してしまう。
【0009】
本発明は、以上の点を考慮してなされたもので、装置を追加することなくデータを適切に移行し得るストレージシステム等を提案しようとするものである。
【課題を解決するための手段】
【0010】
かかる課題を解決するため本発明においては、１以上のノードを備えるストレージシステムであって、前記ノードは、システムの管理するデータを格納し、前記ノードを用いて構成される移行元のシステムから前記ノードを用いて構成される移行先のシステムに、前記移行元のシステムにおいて管理される前記データの移行を制御するデータ移行部と、前記データの前記移行元のシステムにおける格納先を示す情報を含むスタブ情報を前記移行先のシステムに作成するデータ処理部と、を備え、前記データ移行部は、前記移行元のシステムのデータの前記移行先のシステムへの移行を前記データ処理部に指示し、前記データ処理部は、前記データの移行の指示を受けた場合に、前記データのスタブ情報があるときは、前記スタブ情報をもとに前記移行元のシステムから前記データを読み出し、前記データを書き込むように前記移行先のファイルシステムに指示し、前記スタブ情報を削除し、前記データ移行部は、前記データの移行が完了した場合に、前記データを削除するように前記移行元のシステムに指示する。
【0011】
上記構成では、移行が行われていないデータについてはスタブ情報を用いて移行元のシステムから当該データが読み出され、移行先のシステムに当該データの書き込みが行われたときに当該データが移行元のシステムから削除される。かかる構成によれば、ストレージシステムは、データを重複して持つことを避けることができるので、移行元のシステムから移行先のシステムへのデータの移行のためにユーザが装置を追加することなく、既存の装置を用いてデータを移行することができる。
【発明の効果】
【0012】
本発明によれば、装置を追加することなくデータを適切に移行することができる。なお、上記した以外の課題、構成および効果は、以下の実施の形態の説明により明らかにされる。
【図面の簡単な説明】
【0013】
【図1】第１の実施の形態によるストレージシステムの概要を説明するための図である。
【図2】第１の実施の形態によるストレージシステムに係る構成の一例を示す図である。
【図3】第１の実施の形態によるホスト計算機に係る構成の一例を示す図である。
【図4】第１の実施の形態による管理システムに係る構成の一例を示す図である。
【図5】第１の実施の形態によるノードに係る構成の一例を示す図である。
【図6】第１の実施の形態によるスタブファイルを使う分散ＦＳの実装例を示す図である。
【図7】第１の実施の形態によるスタブファイルの構成の一例を示す図である。
【図8】第１の実施の形態による移行元ファイル管理テーブルのデータ構造の一例を示す図である。
【図9】第１の実施の形態による物理プール管理テーブルのデータ構造の一例を示す図である。
【図10】第１の実施の形態によるページ割当管理テーブルのデータ構造の一例を示す図である。
【図11】第１の実施の形態による移行管理テーブルのデータ構造の一例を示す図である。
【図12】第１の実施の形態による移行ファイル管理テーブルのデータ構造の一例を示す図である。
【図13】第１の実施の形態による移行元ボリューム解放領域管理テーブルのデータ構造の一例を示す図である。
【図14】第１の実施の形態によるノード容量管理テーブルのデータ構造の一例を示す図である。
【図15】第１の実施の形態による分散ＦＳ移行処理に係るフローチャートの一例を示す図である。
【図16】第１の実施の形態によるファイル移行処理に係るフローチャートの一例を示す図である。
【図17】第１の実施の形態によるページ解放処理に係るフローチャートの一例を示す図である。
【図18】第１の実施の形態によるスタブ管理処理に係るフローチャートの一例を示す図である。
【図19】第２の実施の形態によるストレージシステムの概要を説明するための図である。
【発明を実施するための形態】
【0014】
以下図面について、本発明の一実施の形態を詳述する。本実施の形態では、データの移行のために装置（ストレージメディア、ストレージアレイ、および／または、ノード）を追加することなく、移行元のシステム（移行元システム）から移行先のシステム（移行先システム）にデータを移行する技術に関して説明する。
【0015】
移行元システムおよび移行先システムは、分散システムであってもよいし、分散システムでなくてもよい。また、移行元システムおよび移行先システムのデータ管理単位としては、ブロックであってもよいし、ファイルであってもよいし、オブジェクトであってもよい。なお、本実施の形態では、移行元システムおよび移行先システムとしては、分散ファイルシステム（分散ＦＳ）を例に挙げて説明する。
【0016】
本実施の形態のストレージシステムでは、ファイルを移行する前に既存のノード（同一装置）内にファイルに代えて当該ファイルにアクセス可能なスタブファイルを作成し、アクセス先を移行先分散ＦＳに切り替える。そして、本ストレージシステムでは、移行処理中に、移行が完了したファイルを移行元分散ＦＳから削除する。
【0017】
また、例えば、本ストレージシステムでは、移行処理中に各ノードまたはストレージメディアの空容量を監視し、移行元分散ＦＳのアルゴリズムを考慮して、空容量の少ないノードまたはストレージメディアのファイルから選択して移行するようにしてもよい。これにより、ノードまたはストレージメディアにおける使用量の偏りによる特定ノードの容量超過を防ぐことができる。
【0018】
また、例えば、本ストレージシステムでは、移行元分散ＦＳの削除したファイルのファイル容量を移行先分散ＦＳで使用できるようにシンプロビジョニングした論理デバイスを共有し、ファイルの削除時にページの回収を指示するようにしてもよい。これにより、ページを利用できるようになる。
【0019】
なお、以下の説明では、「ａａａテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ａａａテーブル」を「ａａａ情報」と呼ぶこともできる。
【0020】
また、以下の説明では、「インタフェース（Ｉ／Ｆ）」は、１以上の通信インタフェースデバイスを含んでよい。１以上の通信インタフェースデバイスは、１以上の同種の通信インタフェースデバイス（例えば、１以上のＮＩＣ（Network Interface Card））であってもよいし、２以上の異種の通信インタフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。
【0021】
また、以下の説明では、「ストレージメディア」は、物理的な不揮発性の記憶デバイス（例えば、補助記憶デバイス）、例えば、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）、フラッシュメモリ、光ディスク、磁気テープ等である。
【0022】
また、以下の説明では、「メモリ」は、１以上のメモリを含む。少なくとも１つのメモリは、揮発性メモリであってもよいし、不揮発性メモリであってもよい。メモリは、主に、プロセッサによる処理の際に使用される。
【0023】
また、以下の説明では、「プロセッサ」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、ＣＰＵ（Central Processing Unit）でよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。
【0024】
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えば、ＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶部（例えば、メモリ）および／またはインタフェース（例えば、ポート）を用いながら行うため、処理の主語がプログラムとされてもよい。プログラムを主語として説明された処理は、プロセッサ或いはそのプロセッサを備える計算機（例えば、ノード）が行う処理としてもよい。また、コントローラ（ストレージコントローラ）は、プロセッサそれ自体であってもよいし、コントローラが行う処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたはコンピュータ読取可能な（例えば、非一時的な）記憶メディアであってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
【0025】
また、以下の説明では、要素の識別情報として、ＩＤが使用されるが、それに代えてまたは加えて他種の識別情報が使用されてもよい。
【0026】
また、以下の説明では、分散ストレージシステムは、１以上の物理的な計算機（ノード）を含む。１以上の物理的な計算機は、物理的なサーバと物理的なストレージとのうちの少なくとも１つを含んでよい。少なくとも１つの物理的な計算機が、仮想的な計算機（例えばＶＭ（Virtual Machine））を実行してもよいし、ＳＤｘ（Software-Defined anything）を実行してもよい。ＳＤｘとしては、例えば、ＳＤＳ（Software Defined Storage）（仮想的なストレージ装置の一例）またはＳＤＤＣ（Software-defined Datacenter）を採用することができる。
【0027】
また、以下の説明では、同種の要素を区別しないで説明する場合には、枝番を含む参照符号のうちの共通部分（枝番を除く部分）を使用し、同種の要素を区別して説明する場合は、枝番を含む参照符号を使用することがある。例えば、ファイルを特に区別しないで説明する場合には、「ファイル６１３」と記載し、個々のファイルを区別して説明する場合には、「ファイル６１３－１」、「ファイル６１３－２」のように記載することがある。
【0028】
（１）第１の実施の形態
図１において、１００は全体として第１の実施の形態によるストレージシステムを示す。
図１において、１００は全体として第１の実施の形態によるストレージシステムを示す。
【0029】
図１は、ストレージシステム１００の概要を説明するための図である。ストレージシステム１００では、既存のノード１１０が用いられて、同種または異種の分散ＦＳ間のファイルの移行が行われる。
【0030】
ストレージシステム１００では、複数のノード１１０上において、移行元分散ＦＳ１０１から移行先分散ＦＳ１０２にファイルを移行する処理が行われる。また、ストレージシステム１００は、ファイルの移行時に各ノード１１０の空容量を監視し、移行が完了したファイルを削除することで、空容量の不足による移行の失敗を回避している。例えば、移行元分散ＦＳ１０１と移行先分散ＦＳ１０２とで同一のノード１１０を用いることで、別途、移行のためにノード１１０を導入することなく、分散ＦＳ間のファイルの移行を実現している。
【0031】
より具体的には、ストレージシステム１００は、１以上のノード１１０と、ホスト計算機１２０と、管理システム１３０とを含んで構成される。ノード１１０とホスト計算機１２０と管理システム１３０とは、フロントエンドネットワーク１４０（ＦＥネットワーク）を介して通信可能に接続されている。また、ノード１１０間は、バックエンドネットワーク１５０（ＢＥネットワーク）を介して通信可能に接続されている。
【0032】
ノード１１０は、例えば、分散ＦＳサーバであり、分散ＦＳ移行部１１１と、ネットワークファイル処理部１１２（ネットワークファイル処理部１１２はスタブ管理部１１３を備える。）と、移行元分散ＦＳ部１１４と、移行先分散ＦＳ部１１５と、論理ボリューム管理部１１６とを備える。なお、分散ＦＳ移行部１１１については、全てのノード１１０が備える構成であってもよいし、一部のノード１１０が備える構成であってもよい。図１では、１つのノード１１０が分散ＦＳ移行部１１１を備える例を示している。
【0033】
本ストレージシステム１００では、管理システム１３０は、分散ＦＳの移行を分散ＦＳ移行部１１１に依頼する。分散ＦＳ移行部１１１は、依頼を受け付けると、移行元分散ＦＳ１０１のリバランスを停止する。次に、分散ＦＳ移行部１１１は、移行元分散ＦＳ１０１のファイルの情報と各ノード１１０の物理プール１１７の空容量とからデータを移行可能であるか否かを判定する。また、分散ＦＳ移行部１１１は、移行元分散ＦＳ１０１の全ファイルの格納されているノード１１０とサイズの情報とを取得する。さらに、分散ＦＳ移行部１１１は、スタブ管理部１１３にスタブファイルの作成を要求する。要求を受けたスタブ管理部１１３は、移行先分散ＦＳ１０２上に移行元分散ＦＳ１０１と同じファイルツリーを作成する。なお、作成されるファイルツリーでは、ファイルは、移行元分散ＦＳ１０１のファイルにアクセス可能なスタブファイルとして作成される。
【0034】
次に、分散ＦＳ移行部１１１は、ファイルの移行処理を行う。ファイルの移行処理では、以下に示す、（Ａ）監視処理１６１、（Ｂ）読込書込処理１６２（コピー処理）、（Ｃ）削除処理１６３および（Ｄ）解放処理１６４が行われる。
【0035】
（Ａ）監視処理１６１
分散ＦＳ移行部１１１は、各ノード１１０の論理ボリューム管理部１１６に物理プール１１７の空容量を定期的に問い合わせ、物理プール１１７の空容量を監視する。
分散ＦＳ移行部１１１は、各ノード１１０の論理ボリューム管理部１１６に物理プール１１７の空容量を定期的に問い合わせ、物理プール１１７の空容量を監視する。
【0036】
（Ｂ）読込書込処理１６２
分散ＦＳ移行部１１１は、物理プール１１７の空容量の少ないノード１１０（対象ノード１１０）に格納されているファイルを優先して移行する。例えば、分散ＦＳ移行部１１１は、移行先分散ＦＳ１０２のファイルの読み込みを対象ノード１１０のネットワークファイル処理部１１２に依頼する。依頼を受けたネットワークファイル処理部１１２は、スタブファイルに対応するファイルを、対象ノード１１０の移行元分散ＦＳ部１１４を介して移行元分散ＦＳ１０１から読み込み、対象ノード１１０の移行先分散ＦＳ部１１５に移行先分散ＦＳ１０２への書き込みを依頼する。対象ノード１１０の移行先分散ＦＳ部１１５は、他のノード１１０の移行先分散ＦＳ部１１５と連携して移行先分散ＦＳ１０２に読み込まれたファイルを書き込む。
分散ＦＳ移行部１１１は、物理プール１１７の空容量の少ないノード１１０（対象ノード１１０）に格納されているファイルを優先して移行する。例えば、分散ＦＳ移行部１１１は、移行先分散ＦＳ１０２のファイルの読み込みを対象ノード１１０のネットワークファイル処理部１１２に依頼する。依頼を受けたネットワークファイル処理部１１２は、スタブファイルに対応するファイルを、対象ノード１１０の移行元分散ＦＳ部１１４を介して移行元分散ＦＳ１０１から読み込み、対象ノード１１０の移行先分散ＦＳ部１１５に移行先分散ＦＳ１０２への書き込みを依頼する。対象ノード１１０の移行先分散ＦＳ部１１５は、他のノード１１０の移行先分散ＦＳ部１１５と連携して移行先分散ＦＳ１０２に読み込まれたファイルを書き込む。
【0037】
（Ｃ）削除処理１６３
分散ＦＳ移行部１１１は、分散ＦＳ移行部１１１の読込書込処理１６２またはホスト計算機１２０のファイルＩ／Ｏの要求によって移行先分散ＦＳ１０２への読み込みおよび書き込み（コピー）が完了したファイルを対象ノード１１０のネットワークファイル処理部１１２および移行元分散ＦＳ部１１４を介して移行元分散ＦＳ１０１から削除する。
分散ＦＳ移行部１１１は、分散ＦＳ移行部１１１の読込書込処理１６２またはホスト計算機１２０のファイルＩ／Ｏの要求によって移行先分散ＦＳ１０２への読み込みおよび書き込み（コピー）が完了したファイルを対象ノード１１０のネットワークファイル処理部１１２および移行元分散ＦＳ部１１４を介して移行元分散ＦＳ１０１から削除する。
【0038】
（Ｄ）解放処理１６４
分散ＦＳ移行部１１１は、ファイルの削除によって使用されなくなった移行元分散ＦＳ１０１の論理ボリューム１１８（移行元ＦＳ論理ＶＯＬ）に割り当てられている物理ページの解放を対象ノード１１０の論理ボリューム管理部１１６に依頼する。論理ボリューム管理部１１６は、物理ページを解放することで、当該物理ページを、移行先分散ＦＳ１０２の論理ボリューム１１９（移行先ＦＳ論理ＶＯＬ）に割り当てることができるようになる。
分散ＦＳ移行部１１１は、ファイルの削除によって使用されなくなった移行元分散ＦＳ１０１の論理ボリューム１１８（移行元ＦＳ論理ＶＯＬ）に割り当てられている物理ページの解放を対象ノード１１０の論理ボリューム管理部１１６に依頼する。論理ボリューム管理部１１６は、物理ページを解放することで、当該物理ページを、移行先分散ＦＳ１０２の論理ボリューム１１９（移行先ＦＳ論理ＶＯＬ）に割り当てることができるようになる。
【0039】
分散ＦＳ移行部１１１は、ファイルの移行処理が終わると、移行元分散ＦＳ１０１を削除し、管理システム１３０に結果を返却する。
【0040】
なお、移行元分散ＦＳ１０１は、各ノード１１０の移行元分散ＦＳ部１１４が連携することにより実現される。また、移行先分散ＦＳ１０２は、各ノード１１０の移行先分散ＦＳ部１１５が連携することにより実現される。付言するならば、分散ＦＳ移行部１１１は、対象ノード１１０の移行先分散ＦＳ部１１５にファイルの書き込みの依頼を行う例を示したが、この構成に限らない。移行元分散ＦＳ１０１は、対象ノード１１０とは異なるノード１１０の移行先分散ＦＳ部１１５にファイルの書き込みの依頼を行う構成であってもよい。
【0041】
図２は、ストレージシステム１００に係る構成の一例を示す図である。
【0042】
ストレージシステム１００は、１つまたは複数のノード１１０と、１つまたは複数のホスト計算機１２０と、１つまたは複数の管理システム１３０とを備える。
【0043】
ノード１１０は、ホスト計算機１２０（ストレージシステム１００のユーザ）に分散ＦＳを提供する。ノード１１０は、例えば、フロントエンドネットワーク１４０を介してフロントエンドインタフェース２１１（ＦＥ Ｉ／Ｆ）を用いてホスト計算機１２０からのファイルＩ／Ｏの要求を受信する。また、ノード１１０は、バックエンドネットワーク１５０を介してバックエンドインタフェース２１２（ＢＥ Ｉ／Ｆ）を用いて他のノード１１０とのデータの送受信（通信）を行う。付言するならば、フロントエンドインタフェース２１１は、フロントエンドネットワーク１４０を介してノード１１０とホスト計算機１２０とが通信するために使用される。バックエンドインタフェース２１２は、バックエンドネットワーク１５０を介して各ノード１１０が通信するために使用される。
【0044】
ホスト計算機１２０は、ノード１１０のクライアント装置である。ホスト計算機１２０は、例えば、フロントエンドネットワーク１４０を介してネットワークインタフェース２２１（ネットワークＩ／Ｆ）を用いてファイルＩ／Ｏの要求を発行する。
【0045】
管理システム１３０は、ストレージシステム１００を管理するための管理装置である。管理システム１３０は、例えば、フロントエンドネットワーク１４０を介して管理ネットワークインタフェース２３１（管理ネットワークＩ／Ｆ）を用いて分散ＦＳの移行指示をノード１１０（分散ＦＳ移行部１１１）に送信する。
【0046】
なお、フロントエンドネットワーク１４０において、ホスト計算機１２０は、ネットワークインタフェース２２１を使用することによって、フロントエンドネットワーク１４０を介してノード１１０にファイルＩ／Ｏの要求を発行する。ＮＦＳ（Network File System）、ＣＩＦＳ（Common Internet File System）、ＡＦＰ（Apple Filing Protocol）等のネットワークを介したファイルＩ／Ｏの要求のインタフェースのためのいくつかの一般的なプロトコルがある。さらに、各ホスト計算機１２０は、様々な目的のために他のホスト計算機１２０と通信することができる。
【0047】
また、バックエンドネットワーク１５０において、ノード１１０は、バックエンドインタフェース２１２を使用し、バックエンドネットワーク１５０を介して他のノード１１０と通信する。バックエンドネットワーク１５０は、ファイルを移行する、メタデータを交換する、または他の様々な目的に役立つ。バックエンドネットワーク１５０は、フロントエンドネットワーク１４０から分離している必要はない。フロントエンドネットワーク１４０とバックエンドネットワーク１５０との両方を併合することが可能である。
【0048】
図３は、ホスト計算機１２０に係る構成の一例を示す図である。
【0049】
ホスト計算機１２０は、プロセッサ３０１、メモリ３０２、ストレージインタフェース３０３（ストレージＩ／Ｆ）およびネットワークインタフェース２２１を備える。また、ホスト計算機１２０は、ストレージメディア３０４を備えていてもよい。また、ホスト計算機１２０は、ストレージアレイ３０５（共有ストレージ）と接続されていてもよい。
【0050】
ホスト計算機１２０は、ホスト計算機１２０の機能として、処理部３１１とネットワークファイルアクセス部３１２とを備える。
【0051】
処理部３１１は、ストレージシステム１００のユーザがデータの処理を指示することにより外部のファイルサーバ上のデータを処理するプログラムである。処理部３１１は、例えば、ＲＤＭＳ（Relational Database Management System）、Virtual Machine Hypervisor等のプログラムである。
【0052】
ネットワークファイルアクセス部３１２は、ノード１１０に対してファイルＩ／Ｏの要求を発行してノード１１０に対するデータの読み書きを行うプログラムである。ネットワークファイルアクセス部３１２は、ネットワーク通信プロトコルにおいて、クライアント装置側の制御を提供するが、これに限定されるものではない。
【0053】
また、ネットワークファイルアクセス部３１２は、アクセス先サーバ情報３１３を備える。アクセス先サーバ情報３１３は、ファイルＩ／Ｏの要求を発行するノード１１０と分散ＦＳとを特定するための情報である。例えば、アクセス先サーバ情報３１３は、ノード１１０のコンピュータ名、ＩＰ（インターネットプロトコル）アドレス、ポート番号、または分散ＦＳ名のうちの１つまたは複数を含む。
【0054】
図４は、管理システム１３０に係る構成の一例を示す図である。
【0055】
管理システム１３０は、基本的には、ホスト計算機１２０と同等のハードウェア構成を備える。ただし、管理システム１３０は、管理システム１３０の機能として、管理部４１１を備え、処理部３１１およびネットワークファイルアクセス部３１２を備えない。管理部４１１は、ユーザがファイルの移行を管理するプログラムである。
【0056】
図５は、ノード１１０に係る構成の一例を示す図である。
【0057】
ノード１１０は、プロセッサ３０１、メモリ３０２、ストレージインタフェース３０３、フロントエンドインタフェース２１１、バックエンドインタフェース２１２およびストレージメディア３０４を備える。ノード１１０は、ストレージメディア３０４に加えてまたは代えて、ストレージアレイ３０５と接続されていてもよい。なお、本実施の形態では、基本的には、ストレージメディア３０４にデータが記憶される例を挙げて説明する。
【0058】
ノード１１０の機能（分散ＦＳ移行部１１１、ネットワークファイル処理部１１２、スタブ管理部１１３、移行元分散ＦＳ部１１４、移行先分散ＦＳ部１１５、論理ボリューム管理部１１６、移行元分散ＦＳアクセス部５１１、移行先分散ＦＳアクセス部５１２およびローカルファイルシステム部５２１等）は、例えば、プロセッサ３０１がプログラムをメモリ３０２に読み出して実行すること（ソフトウェア）により実現されてもよいし、専用の回路等のハードウェアにより実現されてもよいし、ソフトウェアとハードウェアとが組み合わされて実現されてもよい。また、ノード１１０の機能の一部は、ノード１１０と通信可能な他のコンピュータにより実現されてもよい。
【0059】
プロセッサ３０１は、ノード１１０内のデバイスを制御する。
【0060】
プロセッサ３０１は、ネットワークファイル処理部１１２によって、フロントエンドインタフェース２１１を介して、ホスト計算機１２０からファイルＩ／Ｏの要求を受信し、結果を返却する。ネットワークファイル処理部１１２は、移行元分散ＦＳ１０１または移行先分散ＦＳ１０２に格納されたデータへのアクセスが必要な場合に、移行元分散ＦＳアクセス部５１１または移行先分散ＦＳアクセス部５１２を介して、データへのアクセスの要求（ファイルＩ／Ｏの要求）を移行元分散ＦＳ部１１４または移行先分散ＦＳ部１１５に発行する。
【0061】
プロセッサ３０１は、移行元分散ＦＳ部１１４または移行先分散ＦＳ部１１５によって、ファイルＩ／Ｏの要求を処理し、移行元ファイル管理テーブル５３１または移行先ファイル管理テーブル５４１を参照して、ストレージインタフェース３０３を介して接続されているストレージメディア３０４にデータを読み書きする、またはバックエンドインタフェース２１２を介して他のノード１１０にデータの読み書きを依頼する。
【0062】
移行元分散ＦＳ部１１４または移行先分散ＦＳ部１１５の例として、ＧｌｕｓｔｅｒＦＳ、ＣｅｐｈＦＳ等があるが、これらに限定するものではない。
【0063】
プロセッサ３０１は、スタブ管理部１１３によって、スタブファイルの管理とスタブファイルに対応するファイルの取得を行う。スタブファイルとは、ファイルのデータを持たず、移行元分散ＦＳ１０１に格納されているファイルの場所を示す仮想ファイルのことである。スタブファイルは、データの一部または全体をキャッシュとして持つことができる。なお、米国特許第７，３３０，９５０号明細書および米国特許第８，８５６，０７３号明細書では、スタブファイルに基づくファイル単位の階層型ストレージ管理方法を開示し、スタブファイルの構造の一例を示している。
【0064】
プロセッサ３０１は、論理ボリューム管理部１１６によって、ページ割当管理テーブル５５２を参照して、移行元分散ＦＳ部１１４または移行先分散ＦＳ部１１５の使用する論理ボリューム１１８，１１９に物理ページを割り当てたり、割り当てた物理ページを解放したりする。
【0065】
論理ボリューム管理部１１６は、移行元分散ＦＳ部１１４と移行先分散ＦＳ部１１５とに対し、論理ボリューム１１８，１１９を提供する。論理ボリューム管理部１１６は、１台以上のストレージメディア３０４の物理記憶領域を固定長（例えば、４２ＭＢ）の物理ページに分割し、ノード１１０内の全ての物理ページを物理プール１１７として管理する。論理ボリューム管理部１１６は、論理ボリューム１１８，１１９の領域を物理ページと同サイズの論理ページの集合として管理し、論理ページに最初の書き込みがあった際に、物理ページを割り当てる。このように、実際に使用される論理ページに限定して物理ページを割当てることで容量効率を高めることができる（いわゆるシンプロビジョニング機能）。
【0066】
プロセッサ３０１は、分散ＦＳ移行部１１１を用いて、移行元分散ＦＳ１０１から移行先分散ＦＳ１０２にファイルをコピーし、コピーが完了したファイルを移行元分散ＦＳ１０１から削除する。
【0067】
プロセッサ３０１とストレージインタフェース３０３との間の通信には、ＦＣ（ファイバチャネル）、ＳＡＴＡ（Serial Attached Technology Attachment）、ＳＡＳ（Serial Attached SCSI）、ＩＤＥ（Integrated Device Electronics）等のインタフェースが用いられる。ノード１１０は、ＨＤＤ、ＳＳＤ、フラッシュメモリ、光ディスク、磁気テープ等のような多くの種類のストレージメディア３０４を備えることができる。
【0068】
ローカルファイルシステム部５２１は、移行元分散ＦＳ１０１または移行先分散ＦＳ１０２がノード１１０に分散したファイルを管理するために利用するファイルシステムの制御プログラムである。ローカルファイルシステム部５２１は、論理ボリューム管理部１１６が提供する論理ボリューム１１８，１１９上に、ファイルシステムを構築し、使用プログラムに対してファイル単位のアクセスを可能とする。
【0069】
例えば、ＧｌｕｓｔｅｒＦＳでは、ＸＦＳ、ＥＸＴ４が用いられる。なお、本実施の形態では、移行元分散ＦＳ１０１と移行先分散ＦＳ１０２とが、同じファイルシステムによってノード１１０内のデータを管理してもよいし、異なるファイルシステムによってノード１１０内のデータを管理してもよい。また、ＣｅｐｈＦＳのようにローカルファイルシステムを有さず、ファイルをオブジェクトとして格納してもよい。
【0070】
メモリ３０２は、各種の情報（移行元ファイル管理テーブル５３１、移行先ファイル管理テーブル５４１、物理プール管理テーブル５５１、ページ割当管理テーブル５５２、移行管理テーブル５６１、移行ファイル管理テーブル５６２、移行元ボリューム解放領域管理テーブル５６３、およびノード容量管理テーブル５６４等）を記憶する。なお、各種の情報は、ストレージメディア３０４に記憶され、メモリ３０２に読み出されてもよい。
【0071】
移行元ファイル管理テーブル５３１は、移行元分散ＦＳ１０１におけるファイルのデータの格納先（実際の位置、場所）を管理するテーブルである。移行先ファイル管理テーブル５４１は、移行先分散ＦＳ１０２におけるファイルのデータの格納先を管理するテーブルである。物理プール管理テーブル５５１は、ノード１１０における物理プール１１７の空容量を管理するテーブルである。ページ割当管理テーブル５５２は、ストレージメディア３０４から提供される物理容量の論理ボリューム１１８，１１９への物理ページの割り当てを管理するテーブルである。
【0072】
移行管理テーブル５６１は、分散ＦＳの移行状態を管理するテーブルである。移行ファイル管理テーブル５６２は、移行元分散ＦＳ１０１から移行先分散ＦＳ１０２に移行するファイルを管理するテーブルである。移行元ボリューム解放領域管理テーブル５６３は、移行元分散ＦＳ１０１が使用する論理ボリューム１１８内のファイルの削除済みの領域および解放済みの領域を管理するテーブルである。ノード容量管理テーブル５６４は、各ノード１１０の物理プール１１７の空容量を管理するテーブルである。
【0073】
なお、本実施の形態では、ネットワークファイル処理部１１２がスタブ管理部１１３、移行元分散ＦＳアクセス部５１１および移行先分散ＦＳアクセス部５１２を備える構成としているが、他のプログラムがこれらを備えてもよい。例えば、ＲＤＢＭＳ（リレーショナルデータベース管理システム）、Ｗｅｂサーバ、動画配信サーバ等のアプリケーションがネットワークファイル処理部１１２、スタブ管理部１１３、移行元分散ＦＳアクセス部５１１および移行先分散ＦＳアクセス部５１２を備える構成であってもよい。
【0074】
図６は、スタブファイルを使う分散ＦＳの実装例を示す図である。
【0075】
移行元分散ＦＳ１０１のファイルツリー６１０は、ノード１１０がホスト計算機１２０に示す移行元分散ＦＳ１０１のファイル階層を示す。ファイルツリー６１０は、ｒｏｏｔ６１１およびディレクトリ６１２を備え、各ディレクトリ６１２は、ファイル６１３を備える。各ファイル６１３の場所は、各ディレクトリ６１２のディレクトリ名とファイル６１３のファイル名とをスラッシュで接続したパス名で示される。例えば、ファイル６１３－１のパス名は、「/root/dirA/file1」である。
【0076】
移行先分散ＦＳ１０２のファイルツリー６２０は、ノード１１０がホスト計算機１２０に示す移行先分散ＦＳ１０２のファイル階層を示す。ファイルツリー６２０は、ｒｏｏｔ６２１およびディレクトリ６２２を備え、各ディレクトリ６２２は、ファイル６２３を備える。各ファイル６２３の場所は、各ディレクトリ６２２のディレクトリ名とファイル６２３のファイル名とをスラッシュで接続したパス名で示される。例えば、ファイル６２３－１のパス名は、「/root/dirA/file1」である。
【0077】
上述の例では、移行元分散ＦＳ１０１のファイルツリー６１０と、移行先分散ＦＳ１０２のファイルツリー６２０とは、同じツリー構造となる。ただし、ファイルツリー６１０とファイルツリー６２０とは、異なるツリー構造であってもよい。
【0078】
スタブファイルを使う分散ＦＳ自体は、通常の分散ＦＳとして使用できる。例えば、ファイル６２３－１，６２３－２，６２３－３は、通常のファイルであるため、ホスト計算機１２０は、「/root/dirA/file1」、「/root/dirA/file2」、「/root/dirA/」等のパス名を指定して読み書きできる。
【0079】
また、例えば、ファイル６２３－４，６２３－５，６２３－６は、スタブ管理部１１３によって管理されるスタブファイルの例である。移行先分散ＦＳ１０２は、ファイル６２３－４，６２３－５，６２３－６のデータの一部を分散アルゴリズムによって決められるノード１１０のストレージメディア３０４に格納している。
【0080】
ファイル６２３－４，６２３－５，６２３－６は、ファイル名およびファイルサイズのようなメタデータのみを格納し、それ以外のデータは格納しない。ファイル６２３－４，６２３－５，６２３－６は、データ全体を保持する代わりに、データの場所に関する情報を格納する。
【0081】
スタブファイルの管理は、スタブ管理部１１３により行われる。スタブファイルの構成を図７に示す。図７に示すように、スタブ管理部１１３は、メタ情報７１０にスタブ情報７２０を付加することでスタブファイルを実現する。スタブ管理部１１３は、スタブファイルの構成に基づいて、スタブファイルに係る制御を実現する。
【0082】
なお、ディレクトリ６２２－３「/root/dirC」は、スタブファイルとして扱うことができる。この状況では、スタブ管理部１１３は、その下のファイル６２３－７，６２３－８，６２３－９についての情報を全く有さない可能性がある。ホスト計算機１２０がディレクトリ６２２－３の下のファイルにアクセスすると、スタブ管理部１１３は、ファイル６２３－７，６２３－８，６２３－９のスタブファイルを作成する。
【0083】
図７は、スタブファイルの構成の一例（スタブファイル７００）を示す図である。
【0084】
メタ情報７１０は、各ファイル６２３のメタデータを格納する。メタ情報７１０は、ファイル６２３がスタブファイルであるか否か（スタブファイルであるか通常ファイルであるか）を示す情報（エントリ７１１）を備える。
【0085】
ファイル６２３がスタブファイルである場合、メタ情報７１０は、対応するスタブ情報７２０と関連付けられている。例えば、メタ情報７１０は、ファイル６２３がスタブファイルである場合、スタブ情報７２０を含んで構成され、ファイル６２３がスタブファイルでない場合、スタブ情報７２０を備えない。なお、メタ情報７１０は、ファイルシステムのユーザにとって十分な情報でなければならない。
【0086】
ファイル６２３がスタブファイルである場合、パス名とファイル６２３がスタブファイルであるかどうかの状態とを指定するために必要なのは、エントリ７１１とファイル名を示す情報（エントリ７１２）である。スタブファイルのファイルサイズ等、スタブファイルの他の情報を示す情報（エントリ７１３）は、移行先分散ＦＳ部１１５が対応するスタブ情報７２０および移行元分散ＦＳ１０１を参照することにより取得される。
【0087】
スタブ情報７２０は、ファイル６２３のデータの格納先（実際の位置）を示す情報である。図７に示す例では、スタブ情報７２０は、移行元分散ＦＳ１０１の移行元分散ＦＳ名を示す情報（エントリ７２１）、および移行元分散ＦＳ１０１上のパス名を示す情報（エントリ７２２）を備える。移行元分散ＦＳ１０１上のパス名を指定することによってファイルのデータの場所が特定される。なお、実際のファイル６１３は、移行先分散ＦＳ１０２のパス名と同じパス名を持つ必要はない。
【0088】
スタブ管理部１１３は、「リコール」により、スタブファイルをファイルに変換できる。「リコール」は、バックエンドネットワーク１５０を介してスタブ情報７２０により特定される移行元分散ＦＳ１０１から実際のファイルのデータを読み出す処理である。ファイルの全データのコピーが行われた後、スタブ管理部１１３は、スタブファイル７００からスタブ情報７２０を削除し、メタ情報７１０の状態を「通常」にすることで、ファイル６２３をスタブファイルから通常のファイルにすることができる。
【0089】
スタブ情報７２０の格納先の例としては、ＣｅｐｈＦＳのｅｘｔｅｎｄｅｄ ａｔｔｒｉｂｕｔｅｓが挙げられるが、これに限定するものではない。
【0090】
図８は、移行元ファイル管理テーブル５３１のデータ構造の一例を示す図である。なお、移行先ファイル管理テーブル５４１については、任意のデータ構造とすることができるので、説明を省略する。
【0091】
移行元ファイル管理テーブル５３１は、パス名８０１、分散方式８０２、冗長化８０３、ノード名８０４、ファイル内オフセット８０５、ノード内パス８０６、論理ＬＢＡ（Logical Block Addressing）オフセット８０７および長さ８０８から構成される情報（エントリ）を含む。
【0092】
パス名８０１は、移行元分散ＦＳ１０１におけるファイルの場所を示す名前（パス名）を格納するフィールドである。分散方式８０２は、移行元分散ＦＳ８０１の分散方式（ファイルがどの単位で分散されるか）を示すフィールドである。例として、ＧｌｕｓｔｅｒＦＳのＤＨＴ（Distributed Hash Tables）、Ｅｒａｓｕｒｅ ｃｏｄｅ、ＣｅｐｈＦＳによるデータの分散があるが、これに限定するものではない。冗長化８０３は、移行元分散ＦＳ１０１において、ファイルがどのように冗長化されているかを示すフィールドである。冗長化８０３としては、二重化、三重化等がある。
【0093】
ノード名８０４は、ファイルのデータが格納されているノード１１０のノード名を格納するフィールドである。ノード名８０４は、ファイルに対して１つまたは複数設けられる。
【0094】
ファイル内オフセット８０５は、ファイル内で分割して格納するデータの塊ごとにファイル内のオフセットを格納するフィールドである。ノード内パス８０６は、ファイル内オフセット８０５に対応するノード１１０内でのパスを格納するフィールドである。ファイル内オフセット８０５に対応するデータの識別子であってもよい。論理ＬＢＡオフセット８０７は、ノード内パス８０６に対応するデータが格納されている論理ボリューム１１８のＬＢＡ（論理ＬＢＡ）のオフセットを格納するフィールドである。長さ８０８は、ノード内パス８０６が移行元分散ＦＳ１０１上で使用する論理ＬＢＡの数を格納するフィールドである。
【0095】
図９は、物理プール管理テーブル５５１のデータ構造の一例を示す図である。
【0096】
物理プール管理テーブル５５１は、物理プール容量９０１、物理プール空容量９０２およびチャンクサイズ９０３から構成される情報（エントリ）を含む。
【0097】
物理プール容量９０１は、ノード１１０内のストレージメディア３０４から提供される物理容量を示すフィールドである。物理プール空容量９０２は、物理プール容量９０１のうち、論理ボリューム１１８，１１９に割り当てられていない物理ページの総容量を示すフィールドである。チャンクサイズ９０３は、論理ボリューム１１８，１１９に割り当てる物理ページのサイズを示すフィールドである。
【0098】
図１０は、ページ割当管理テーブル５５２のデータ構造の一例を示す図である。
【0099】
ページ割当管理テーブル５５２は、物理ページ番号１００１、物理ページ状態１００２、論理ボリュームＩＤ１００３、論理ＬＢＡ１００４、デバイスＩＤ１００５および物理ＬＢＡ１００６から構成される情報（エントリ）を含む。
【0100】
物理ページ番号１００１は、物理プール１１７における物理ページのページ番号を格納するフィールドである。物理ページ状態１００２は、物理ページが割り当てられているか否かを示すフィールドである。
【0101】
論理ボリュームＩＤ１００３は、物理ページが割り当てられている場合、物理ページ番号１００１に対応する割当先の論理ボリューム１１８，１１９の論理ボリュームＩＤを格納するフィールドである。物理ページが割り当てられていない場合、空となる。論理ＬＢＡ１００４は、物理ページが割り当てられている場合、物理ページ番号１００１に対応する割当先の論理ＬＢＡを格納するフィールドである。物理ページが割り当てられていない場合、空となる。
【0102】
デバイスＩＤ１００５は、物理ページ番号１００１の物理ページを有するストレージメディア３０４を識別するデバイスＩＤを格納するフィールドである。物理ＬＢＡ１００６は、物理ページ番号１００１の物理ページに対応するＬＢＡ（物理ＬＢＡ）を格納するフィールドである。
【0103】
図１１は、移行管理テーブル５６１のデータ構造の一例を示す図である。
【0104】
移行管理テーブル５６１は、移行元分散ＦＳ名１１０１、移行先分散ＦＳ名１１０２および移行状態１１０３から構成される情報（エントリ）を含む。
【0105】
移行元分散ＦＳ名１１０１は、移行元分散ＦＳ１０１の移行元分散ＦＳ名を格納するフィールドである。移行先分散ＦＳ名１１０２は、移行先分散ＦＳ１０２の移行先分散ＦＳ名を格納するフィールドである。移行状態１１０３は、分散ＦＳの移行状態を示すフィールドである。移行状態１１０３としては、「移行前」と「移行中」と「移行完了」との３つがある。
【0106】
図１２は、移行ファイル管理テーブル５６２のデータ構造の一例を示す図である。
【0107】
移行ファイル管理テーブル５６２は、移行元パス名１２０１、移行先パス名１２０２、状態１２０３、分散方式１２０４、冗長化１２０５、ノード名１２０６およびデータサイズ１２０７から構成される情報（エントリ）を含む。
【0108】
移行元パス名１２０１は、移行元分散ＦＳ１０１におけるファイルのパス名を格納するフィールドである。移行先パス名１２０２は、移行先分散ＦＳ１０２におけるファイルのパス名を格納するフィールドである。状態１２０３は、移行元パス名１２０１および移行先パス名１２０２に対応するファイルの状態を格納するフィールドである。状態１２０３としては、「移行前」と「削除」と「コピー完了」との３つがある。
【0109】
分散方式１２０４は、移行元分散ＦＳ８０１の分散方式（ファイルがどの単位で分散されるか）を示すフィールドである。例として、ＧｌｕｓｔｅｒＦＳのＤＨＴ（Distributed Hash Tables）、Ｅｒａｓｕｒｅ ｃｏｄｅ、ＣｅｐｈＦＳによるデータの分散があるが、これに限定するものではない。冗長化１２０５は、移行元分散ＦＳ８０１において、ファイルがどのように冗長化されているかを示すフィールドである。
【0110】
ノード名１２０６は、移行元ファイルのデータが格納されているノード１１０のノード名を格納するフィールドである。ノード名１２０６は、ファイルに対して１つまたは複数設けられる。データサイズ１２０７は、ノード１１０に格納されている移行元ファイルのデータサイズを格納するフィールドである。
【0111】
図１３は、移行元ボリューム解放領域管理テーブル５６３のデータ構造の一例を示す図である。
【0112】
移行元ボリューム解放領域管理テーブル５６３は、ノード名１３０１、ボリューム内ページ番号１３０２、ページ状態１３０３、論理ＬＢＡ１３０４、オフセット１３０５、長さ１３０６およびファイル使用状況１３０７から構成される情報（エントリ）を含む。
【0113】
ノード名１３０１は、移行元分散ＦＳ１０１を構成するノード１１０のノード名を格納するフィールドである。ボリューム内ページ番号は、ノード名１３０１に対応するノード１１０において、移行元分散ＦＳ１０１が利用する論理ボリューム１１８に割り当てられている物理ページの物理ページ番号を格納するフィールドである。ページ状態１３０３は、ボリューム内ページ番号１３０２に対応する物理ページが解放されているか否かを示すフィールドである。論理ＬＢＡ１３０４は、ボリューム内ページ番号１３０２の物理ページに対応する移行元分散ＦＳ１０１が利用する論理ボリューム１１８のＬＢＡを格納するフィールドである。
【0114】
オフセット１３０５は、ボリューム内ページ番号１３０２に対応する物理ページ内のオフセットを格納するフィールドである。長さ１３０６は、オフセット１３０５からの長さを格納するフィールドである。ファイル使用状況１３０７は、オフセット１３０５から長さ１３０６分の領域に関する使用状況を示すフィールドである。ファイル使用状況１３０７としては、「削除済み」と「不明」との２つがある。
【0115】
図１４は、ノード容量管理テーブル５６４のデータ構造の一例を示す図である。
【0116】
ノード容量管理テーブル５６４は、ノード名１４０１、物理プール容量１４０２、移行元分散ＦＳ物理プール使用量１４０３、移行先分散ＦＳ物理プール使用量１４０４および物理プール空容量１４０５から構成される情報（エントリ）を含む。
【0117】
ノード名１４０１は、ノード１１０のノード名を格納するフィールドである。物理プール容量１４０２は、ノード名１４０１に対応するノード１１０の物理プール１１７の容量を格納するフィールドである。移行元分散ＦＳ物理プール使用量１４０３は、移行元分散ＦＳ１０１がノード名１４０１に対応するノード１１０において使用している物理プール１１７の容量を格納するフィールドである。移行先分散ＦＳ物理プール使用量１４０４は、移行先分散ＦＳ１０２がノード名１４０１に対応するノード１１０において使用している物理プール１１７の容量を格納するフィールドである。物理プール空容量１４０５は、ノード名１４０１に対応するノード１１０の物理プール１１７の空容量を格納するフィールドである。
【0118】
図１５は、分散ＦＳ移行処理に係るフローチャートの一例を示す図である。分散ＦＳ移行部１１１は、ユーザから管理システム１３０経由で分散ＦＳの移行指示を受信したことを契機として、分散ＦＳ移行処理を開始する。
【0119】
分散ＦＳ移行部１１１は、移行元分散ＦＳ部１１４にリバランスの停止を要求する（ステップＳ１５０１）。リバランスの停止の要求は、ファイルの移行に伴い、移行元分散ＦＳ１０１からファイルを削除した際に、移行元分散ＦＳ１０１がリバランスを実施すると、性能低下が生じるのを防ぐためである。
【0120】
分散ＦＳ移行部１１１は、移行元分散ＦＳ部１１４の備える移行元ファイル管理テーブル５３１から、全ファイルの移行元パス名１２０１、分散方式１２０４、冗長化１２０５、ノード名１２０６およびデータサイズ１２０７の情報を取得し、移行ファイル管理テーブル５６２を作成する（ステップＳ１５０２）。
【0121】
分散ＦＳ移行部１１１は、各ノード１１０の論理ボリューム管理部１１６に問い合わせ、物理プール１１７の容量と物理プール１１７の空容量との情報を取得し、ノード名１４０１、物理プール容量１４０２および物理プール空容量１４０５の情報としてノード容量管理テーブル５６４に格納する（ステップＳ１５０３）。
【0122】
分散ＦＳ移行部１１１は、物理プール空容量１４０５から、移行可能であるか否かを判定する(ステップＳ１５０４)。例えば、分散ＦＳ移行部１１１は、ノード１１０の物理プール１１７の空容量が５％以下である場合、移行可能でない（移行不可）と判定する。この閾値は、管理システム１３０が与えるものとする。分散ＦＳ移行部１１１は、移行可能であると判定した場合、ステップＳ１５０５に処理を移し、移行可能でないと判定した場合、ステップＳ１５１１に処理を移す。
【0123】
ステップＳ１５０５では、分散ＦＳ移行部１１１は、スタブ管理部１１３によりスタブファイルを作成する。なお、スタブ管理部１１３は、移行先分散ＦＳ１０２上に移行元分散ＦＳ１０１と同じファイルツリーを作成する。この時、全てのファイルは、スタブファイルであり、データを持たない。
【0124】
続いて、ホスト計算機１２０がユーザから管理システム１３０経由でアクセス先サーバ情報３１３を変更することにより、既存の移行元分散ＦＳ１０１から新しい移行先分散ＦＳ１０２にファイルＩ／Ｏの要求の送信が切り替えられる（ステップＳ１５０６）。その後、ホスト計算機１２０からの全てのファイルＩ／Ｏの要求については、新しい移行先分散ＦＳ１０２に送信される。
【0125】
分散ＦＳ移行部１１１は、全てのファイルの移行（ファイル移行処理）を実施する（ステップＳ１５０７）。なお、ファイル移行処理の詳細については、図１６を用いて後述する。
【0126】
分散ＦＳ移行部１１１は、ファイル移行処理が成功したか否かを判定する（ステップＳ１５０８）。分散ＦＳ移行部１１１は、ファイル移行処理が成功したと判定した場合、ステップＳ１５０９に処理を移し、ファイル移行処理が成功しなかったと判定した場合、ステップＳ１５１１に処理を移す。
【0127】
ステップＳ１５０９では、分散ＦＳ移行部１１１は、移行元分散ＦＳ１０１を削除する。
【0128】
続いて、分散ＦＳ移行部１１１は、移行成功を管理システム１３０に通知（ステップＳ１５１０）し、分散ＦＳ移行処理を終了する。
【0129】
ステップＳ１５１１では、分散ＦＳ移行部１１１は、移行失敗を管理システム１３０に通知（ステップＳ１５１１）し、分散ＦＳ移行処理を終了する。
【0130】
図１６は、ファイル移行処理に係るフローチャートの一例を示す図である。
【0131】
分散ＦＳ移行部１１１は、各ノード１１０の物理プール１１７の空容量をもとに、移行するファイルを選択する（ステップＳ１６０１）。より具体的には、分散ＦＳ移行部１１１は、ノード容量管理テーブル５６４から各ノード１１０の物理プール空容量１４０５を確認し、物理プール１１７の空容量の少ないノード１１０を特定し、移行ファイル管理テーブル５６２から、特定したノード１１０にデータを持つファイルの移行先パス名１２０２を取得する。
【0132】
このとき、分散ＦＳ移行部１１１は、特定したノード１１０にデータを持つファイル群のうち、一定のアルゴリズムでファイルを選択してもよい。例えば、分散ＦＳ移行部１１１は、データサイズ１２０７の最も小さいファイルを選択する。また、最も少ない物理プール１１７の空容量が管理システム１３０にて設定した閾値より大きい場合、分散ＦＳ移行部１１１は、複数のファイル(固定長サイズ、ディレクトリ以下のファイル全て)を選択し、ステップＳ１６０２にて複数のファイルの移行を移行先分散ＦＳ１０２に依頼してもよい。
【0133】
分散ＦＳ移行部１１１は、ステップＳ１６０１で選択した移行先分散ＦＳ１０２上のファイルの読み込みを、ネットワークファイル処理部１１２に依頼（ファイルＩ／Ｏの要求を送信）する（ステップＳ１６０２）。ネットワークファイル処理部１１２のスタブ管理部１１３により、ファイルの読み込みに伴うデータコピーと同様にして、選択されたファイルがコピーされ、ファイルのコピーが完了する。ファイルの読み込みに伴うデータコピーの詳細については、図１８を用いて後述する。
【0134】
分散ＦＳ移行部１１１は、移行先分散ＦＳ１０２から結果を受領し、移行ファイル管理テーブル５６２を参照し、状態１２０３が「コピー完了」であるエントリが存在するか否か（コピーが完了したファイルがあるか否か）を判定する（ステップＳ１６０３）。分散ＦＳ移行部１１１は、コピーが完了したファイルがあると判定した場合、ステップＳ１６０４に処理を移し、コピーが完了したファイルがないと判定した場合、ステップＳ１６０８に処理を移す。
【0135】
ステップＳ１６０４では、分散ＦＳ移行部１１１は、上述のエントリの移行元パス名１２０１を持つファイルの削除を、ネットワークファイル処理部１１２を介して移行元分散ＦＳ１０１に要求する。ここで、分散ＦＳ移行部１１１は、ステップＳ１６０３にて複数のファイルを取得し、複数のファイルの削除を移行元分散ＦＳ１０１に要求してもよい。
【0136】
続いて、分散ＦＳ移行部１１１は、上述のエントリの状態１２０３を「削除」に変更する（ステップＳ１６０５）。
【0137】
続いて、分散ＦＳ移行部１１１は、削除したファイルに対応する移行元ボリューム解放領域管理テーブル５６３のファイル使用状況１３０７を「削除済」に設定する（ステップＳ１６０６）。より具体的には、分散ＦＳ移行部１１１は、削除したファイルの使用ブロック（論理ＬＢＡのオフセットと長さ）を移行元分散ＦＳ１０１から取得し、移行元ボリューム解放領域管理テーブル５６３のファイル使用状況１３０７を「削除済」に設定する。例えば、ＧｌｕｓｔｅｒＦＳでは、内部的に用いているＸＦＳに対し、ＸＦＳ＿ＢＭＡＰコマンドを発行することで、これらの情報を取得することができる。ただし、この方式に限られるものではなく、その他の方式であってもよい。
【0138】
続いて、分散ＦＳ移行部１１１は、ページ解放処理を行う（ステップＳ１６０７）。ページ解放処理では、分散ＦＳ移行部１１１は、移行元ボリューム解放領域管理テーブル５６３を参照し、解放可能な物理ページを解放する。なお、ページ解放処理の詳細については、図１７を用いて後述する。
【0139】
ステップＳ１６０８では、分散ＦＳ移行部１１１は、各ノード１１０の論理ボリューム管理部１１６に物理プール空容量９０２を要求し、ノード容量管理テーブル５６４の物理プール空容量１４０５を更新する。
【0140】
続いて、分散ＦＳ移行部１１１は、移行元ボリューム解放領域管理テーブル５６３を参照し、全エントリの状態１２０３が「削除」であるか否か（全ファイルの移行が完了したか否か）を判定する。分散ＦＳ移行部１１１は、全ファイルの移行が完了したと判定した場合、ファイル移行処理を終了し、全ファイルの移行が完了していないと判定した場合、ステップＳ１６０１に処理を移す。
【0141】
図１７は、ページ解放処理に係るフローチャートの一例を示す図である。
【0142】
分散ＦＳ移行部１１１は、移行元ボリューム解放領域管理テーブル５６３を参照し、ファイル使用状況１３０７が全て「削除済」であるエントリが存在するか否か（解放できる物理ページがあるか否か）を判定する(ステップＳ１７０１)。分散ＦＳ移行部１１１は、解放できる物理ページがあると判定した場合、ステップＳ１７０２に処理を移し、解放できる物理ページがないと判定した場合、ページ解放処理を終了する。
【0143】
ステップＳ１７０２では、分散ＦＳ移行部１１１は、ファイル使用状況１３０７が全て「削除済」であるエントリのノード名１３０１のノード１１０の論理ボリューム管理部１１６にボリューム内ページ番号１３０２の物理ページの解放を指示し、ページ状態１３０３を「解放」に設定し、ページ解放処理を終了する。
【0144】
図１８は、ネットワークファイル処理部１１２がファイルＩ／Ｏの要求を受信したときに実行されるスタブ管理処理に係るフローチャートの一例を示す図である。
【0145】
スタブ管理部１１３は、メタ情報７１０の状態を参照し、処理対象のファイルがスタブファイルであるか否かを判定する（ステップＳ１８０１）。スタブ管理部１１３は、スタブファイルであると判定した場合、ステップＳ１８０２に処理を移し、スタブファイルでないと判定した場合、ステップＳ１８０５に処理を移す。
【0146】
ステップＳ１８０２では、移行元分散ＦＳアクセス部５１１は、移行元分散ＦＳ部１１４を介して、移行元分散ＦＳ１０１から処理対象のファイルのデータを読み出す。なお、ホスト計算機１２０がファイルの上書きを要求する場合、当該ファイルのデータの読み出しは不要である。
【0147】
続いて、移行先分散ＦＳアクセス部５１２は、移行先分散ＦＳ部１１５を介して、読み出されたファイルのデータを移行先分散ＦＳ１０２に書き込む（ステップＳ１８０３）。
【0148】
続いて、スタブ管理部１１３は、書き込み（ファイルのコピー）が成功したか否かを判定する（ステップＳ１８０４）。スタブ管理部１１３は、ファイル内の全データがコピーされた書き込まれた、すなわち、移行元分散ＦＳ１０１からファイルのデータを取得する必要のないファイルと判定した場合、スタブファイルをファイルに変換し、ステップＳ１８０５に処理を移し、書き込みが成功しなかったと判定した場合、ステップＳ１８０８に処理を移す。
【0149】
ステップＳ１８０５では、移行先分散ＦＳアクセス部５１２は、移行先分散ＦＳ部１１５を介して、通常通りにファイルＩ／Ｏの要求を処理する。
【0150】
続いて、スタブ管理部１１３は、分散ＦＳ移行部１１１に移行完了を通知する（ステップＳ１８０６）。より具体的には、スタブ管理部１１３は、ファイル内の全データが読み込まれたまたは書き込まれた、すなわち、移行元分散ＦＳ１０１からファイルのデータを取得する必要のないファイルに対応する移行ファイル管理テーブル５６２のエントリの状態１２０３を「コピー完了」に変更し、分散ＦＳ移行部１１１に移行完了を通知する。なお、スタブ管理部１１３は、ホスト計算機１２０よりディレクトリまたはファイルの移動を要求された場合、移行ファイル管理テーブル５６２の移行先パス名１２０２に反映する。
【0151】
続いて、スタブ管理部１１３は、ホスト計算機１２０または分散ＦＳ移行部１１１に成功を返却し（ステップＳ１８０７）、スタブ管理処理を終了する。
【0152】
ステップＳ１８０８では、スタブ管理部１１３は、ホスト計算機１２０または分散ＦＳ移行部１１１に失敗を返却し、スタブ管理処理を終了する。
【0153】
なお、本実施の形態では、シンプロビジョニングの物理プール１１７を用いて、移行元分散ＦＳ１０１と移行先分散ＦＳ１０２との容量共有を実現しているが、その他の容量共有方式（例えば、ストレージアレイ３０５）についても適用可能である。
【0154】
また、本実施の形態では、分散ＦＳにおけるデータ移行を実現しているが、オブジェクトをファイルとして管理することで、オブジェクトストレージにも適用可能である。また、ボリュームを固定長サイズに分割し、ファイルとして管理することでブロックストレージにも適用可能である。また、同一ノード１１０内のローカルファイルシステム間にも適用可能である。
【0155】
本実施の形態によれば、移行先のノードを別途用意することなく、異種のシステムの移行が可能となり、最新のソフトウェアへの追随が可能となる。
【0156】
（２）第２の実施の形態
本実施の形態は、移行元分散ＦＳ１０１と移行先分散ＦＳ１０２とが各ノード１１０に格納するデータを共通のローカルファイルシステム部５２１で管理している。本実施の形態に示す構成を用いることで、移行対象となるシステムの論理ボリューム管理部１１６がシンプロビジョニング機能を提供しない構成においても、本発明が適用可能となる。
本実施の形態は、移行元分散ＦＳ１０１と移行先分散ＦＳ１０２とが各ノード１１０に格納するデータを共通のローカルファイルシステム部５２１で管理している。本実施の形態に示す構成を用いることで、移行対象となるシステムの論理ボリューム管理部１１６がシンプロビジョニング機能を提供しない構成においても、本発明が適用可能となる。
【0157】
図１９は、本実施の形態のストレージシステム１００の概要を説明するための図である。本実施の形態では、移行元分散ＦＳ１０１と移行先分散ＦＳ１０２とが各ノード１１０に格納するデータを共通のローカルファイルシステム部５２１で管理している場合における異種分散ＦＳ間の同一ノード１１０内のデータ移行処理について説明する。
【0158】
移行元分散ＦＳ１０１と移行先分散ＦＳ１０２とは、共通の論理ボリューム１９０１を用いる。
【0159】
第１の実施の形態との差分は、移行元分散ＦＳ１０１の論理ボリューム１９０１のページ解放処理がないことである。これは、移行元分散ＦＳ１０１で削除されたファイルの割り当て領域の解放および再利用は、移行先分散ＦＳ１０２と共通のローカルファイルシステム部５２１が行うため、論理ボリュームレベルのページ解放処理が不要となるためである。
【0160】
【0161】
【0162】
移行元ファイル管理テーブル５３１は、第１の実施の形態（図８）と同じである。ただし、本実施の形態では、分散ＦＳ移行部１１１は、ページ解放を行わないため、移行元ファイル管理テーブル５３１のノード内パス８０６と論理ＬＢＡオフセット８０７とを参照しない。
【0163】
物理プール管理テーブル５５１については、第１の実施の形態（図９）と同じである。ページ割当管理テーブル５５２については、第１の実施の形態（図１０）と同じである。ただし、本実施の形態では、分散ＦＳ移行部１１１は、ページ解放を行わないため、ページ割当管理テーブル５５２を参照しない。
【0164】
移行管理テーブル５６１については、第１の実施の形態（図１１）と同じである。移行ファイル管理テーブル５６２については、第１の実施の形態（図１２）と同じである。移行元ボリューム解放領域管理テーブル５６３（図１３）については、本実施の形態では不要である。ノード容量管理テーブル５６４については、第１の実施の形態（図１４）と同じである。
【0165】
分散ＦＳ移行処理については、第１の実施の形態（図１５）と同じである。ファイル移行処理については、本実施の形態では、図１６のステップＳ１６０６とステップＳ１６０７とが不要である。ページ解放処理（図１７）については、本実施の形態では、不要である。分散ＦＳサーバがファイルＩ／Ｏの要求を受信したときにスタブ管理部１１３および移行先分散ＦＳ部１１５が実行する処理については、第１の実施の形態（図１８）と同じである。
【0166】
（３）他の実施の形態
なお、上述の実施の形態においては、本発明をストレージシステムに適用するようにした場合について述べたが、本発明はこれに限らず、この他種々のシステム、装置、方法、プログラムに広く適用することができる。
なお、上述の実施の形態においては、本発明をストレージシステムに適用するようにした場合について述べたが、本発明はこれに限らず、この他種々のシステム、装置、方法、プログラムに広く適用することができる。
【0167】
また、上述の説明において、各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等のストレージメディア、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【0168】
上述した実施の形態は、例えば、以下の特徴的な構成を備える。
【0169】
１以上のノード（例えば、ノード１１０）を備えるストレージシステム（例えば、ストレージシステム１００）であって、上記ノードは、システム（例えば、移行元分散ＦＳ１０１、移行先分散ＦＳ１０２）の管理するデータを格納し、上記ノード（ストレージシステム１００の全てのノード１１０であってもよいし、一部のノード１１０であってもよい。）を用いて構成される移行元のシステム（例えば、移行元分散ＦＳ１０１）から上記ノード（移行元分散ＦＳ１０１を構成するノード１１０と同じであってもよいし、異なっていてもよい。）を用いて構成される移行先のシステム（例えば、移行先分散ＦＳ１０２）に、上記移行元のシステムにおいて管理される上記データ（ブロックであってもよいし、ファイルであってもよいし、オブジェクトであってもよい。）の移行を制御するデータ移行部（例えば、分散ＦＳ移行部１１１）と、上記データの上記移行元のシステムにおける格納先を示す情報（例えば、パス名）を含むスタブ情報（例えば、スタブ情報７２０）を上記移行先のシステムに作成するデータ処理部（例えば、ネットワークファイル処理部１１２、スタブ管理部１１３）と、を備え、上記データ移行部は、上記移行元のシステムのデータの上記移行先のシステムへの移行を上記データ処理部に指示し（例えば、ステップＳ１６０１およびステップＳ１６０２）、上記データ処理部は、上記データの移行の指示を受けた場合に、上記データのスタブ情報があるときは、上記スタブ情報をもとに上記移行元のシステムから上記データを読み出し、上記データを書き込むように上記移行先のファイルシステムに指示し（例えば、ステップＳ１８０１～ステップＳ１８０３）、上記スタブ情報を削除し、上記データ移行部は、上記データの移行が完了した場合に、上記データを削除するように上記移行元のシステムに指示する（例えば、ステップＳ１６０４）。
【0170】
上記構成では、移行が行われていないデータについてはスタブ情報を用いて移行元のシステムから当該データが読み出され、移行先のシステムに当該データの書き込みが行われたときに当該データが移行元のシステムから削除される。かかる構成によれば、ストレージシステムは、データを重複して持つことを避けることができるので、移行元のシステムから移行先のシステムへのデータの移行のためにユーザが装置を追加することなく、既存の装置を用いてデータを移行することができる。
【0171】
上記システムは、複数のデータを管理し、上記データ移行部は、上記移行元のシステムおよび上記移行先のシステムで用いられている上記ノードの空容量を管理し（ステップＳ１５０３）、上記データ移行部は、（Ａ）上記ノードの空容量に基づいて上記移行するデータを選択して（ステップＳ１６０１）、上記データの移動を上記データ処理部に指示する（ステップＳ１６０２）、（Ｂ）上記移行が完了したデータを削除するように上記移行元のシステムに指示する（ステップＳ１６０４）、（Ｃ）上記データが削除された上記ノードの空容量を更新する（ステップＳ１６０８）、の（Ａ）～（Ｃ）を繰り返してデータ移行を制御する。
【0172】
上記ノードは複数あり、ノードごとに上記データを格納する記憶デバイス（例えば、ストレージメディア３０４）を有している。
【0173】
上記移行元のシステムおよび上記移行先のシステムは、複数の上記ノードを用いて構成される分散システム（例えば、分散ブロックシステム、分散ファイルシステム、分散オブジェクトシステム）である。
【0174】
上記構成によれば、例えば、移行元の分散システムから移行先の分散システムへのデータの移行のために装置を追加することなく、既存の装置を用いて分散システムのデータを移行することができる。
【0175】
上記移行元のシステムおよび上記移行先のシステムは、上記複数のノードを用いて構成される分散システムであり、上記複数のノードに分散させてデータを格納し、少なくとも１のノードを共有している（図１、図１９参照）。
【0176】
上記データ移行部は、上記移行元のシステムにおける格納先であるノードの空容量が少ないデータを、移行するデータとして選択する（例えば、ステップＳ１６０１およびステップＳ１６０２）。
【0177】
上記構成によれば、例えば、移行先のシステムがデータをノードに均等に格納する構成において、空容量が少ないノードからデータが移行されることで、データの移行において空容量が少なくなってＩＯが失敗する回数を低減することができる。
【0178】
上記移行元のシステムと上記移行先のシステムとで共有される論理デバイス（例えば、物理プール１１７）のページ（例えば、物理ページ）を論理ボリューム（例えば、論理ボリューム１１８，１１９）に割り当てる論理ボリューム管理部（例えば、論理ボリューム管理部１１６）を備え、上記データ移行部は、論理ボリューム単位で上記データ移行の指示を行い、上記移行元のシステムで用いられる論理ボリューム（例えば、論理ボリューム１１８）に割り当てられているページの全てのデータが上記移行先のシステムに移行されたと判定した場合、上記論理ボリュームのページを解放するように指示する（例えば、ステップＳ１７０１およびステップＳ１７０２）。
【0179】
上記構成によれば、例えば、移行元のシステムと移行先のシステムとで論理デバイスを共有する場合であっても、ページを解放することで容量の枯渇を回避できるので、適切にデータを移行することができる。
【0180】
上記データ移行部は、複数のデータを移行（例えば、複数のファイルまたはディレクトリ単位でファイルを移行）するように上記データ処理部に指示する。
【0181】
上記構成によれば、例えば、データを複数まとめて移行することにより、データの移行におけるオーバーヘッドを削減することができる。
【0182】
上記移行元のシステムおよび上記移行先のシステムで用いられている上記ノードは、ストレージデバイス（例えば、ストレージアレイ３０５）を有し、上記移行元のシステムと上記移行先のシステムとで共有される上記ストレージデバイスの論理デバイス（例えば、物理プール）のページ（例えば、物理ページ）を論理ボリューム（例えば、論理ボリューム１１８，１１９）に割り当てる論理ボリューム管理部（例えば、ボリューム管理部１１６）を備え、上記データ移行部は、論理ボリューム単位で上記データ移行の指示を行い、上記移行元のシステムで用いられる論理ボリュームに割り当てられているページの全てのデータが上記移行先のシステムに移行されたと判定した場合、上記論理ボリュームのページを解放するように指示する。
【0183】
上記構成によれば、例えば、移行元のシステムと移行先のシステムとで共有ストレージの論理デバイスを共有する場合であっても、ページを解放することで容量の枯渇を回避できるので、適切にデータを移行することができる。
【0184】
上記移行元のシステムおよび上記移行先のシステムのデータ管理単位は、ファイル、オブジェクトまたはブロックの何れかである。
【0185】
上記構成によれば、例えば、移行元のシステムおよび移行先のシステムが、ファイルシステム、オブジェクトシステムまたはブロックシステムの何れであっても、適切にデータを移行することができる。
【0186】
上記ノードは、上記移行元のシステムと上記移行先のシステムとで共有される論理デバイス（例えば、物理プール１１７）のページ（物理ページ）を上記移行先のシステムと上記移行元のシステムとで共有される論理ボリューム（例えば、論理ボリューム１９０１）に割り当てる論理ボリューム管理部（例えば、論理ボリューム管理部１１６）と、上記移行元のシステムと上記移行先のシステムとのデータを上記論理ボリュームを介して管理するローカルシステム部（例えば、ローカルファイルシステム部５２１）と、を備える。
【0187】
上記構成によれば、例えば、移行先のシステムと移行元のシステムとのデータをローカルシステム部により管理することで、ページの解放が不要となり、容量が枯渇してしまう事態を回避できるので、適切にデータを移行することができる。
【0188】
「Ａ、Ｂ、およびＣのうちの少なくとも１つ」という形式におけるリストに含まれる項目は、（Ａ）、（Ｂ）、（Ｃ）、（ＡおよびＢ）、（ＡおよびＣ）、（ＢおよびＣ）または（Ａ、Ｂ、およびＣ）を意味することができると理解されたい。同様に、「Ａ、Ｂ、またはＣのうちの少なくとも１つ」の形式においてリストされた項目は、（Ａ）、（Ｂ）、（Ｃ）、（ＡおよびＢ）、（ＡおよびＣ）、（ＢおよびＣ）または（Ａ、Ｂ、およびＣ）を意味することができる。
【0189】
以上、本発明の実施の形態を説明したが、以上の実施の形態は、本発明を分かりやすく説明するために詳細に説明したものであり、本発明は、必ずしも説明した全ての構成を備えるものに限定されるものではない。ある例の構成の一部を他の例の構成に置き換えることが可能であり、ある例の構成に他の例の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。図の構成は説明上必要と考えられるものを示しており、製品上必ずしも全ての構成を示しているとは限らない。
【符号の説明】
【0190】
１００……ストレージシステム、１１０……ノード。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】