(57)【要約】【課題】複数のノードで構成された計算機システムにおいて、ホストによるＩ／Ｏ処理の性能を向上することができるようにする。【解決手段】計算機システム１００において、ボリュームＶＯＬに対するＩ／Ｏ処理の要求を発行するホスト部１０２と、一のノード１０１のドライブ１１２の記憶領域に基づくローカルプール１５１の管理を担当するローカルプール制御部１５０と、複数のローカルプール１５１に基づくグローバルプール１４２の管理を担当するグローバルプール制御部１４１と、を備え、グローバルプール制御部１４１は、Ｉ／Ｏ処理を行ったホスト部１０２が形成された第１ノードと、自身が形成された第２ノードと、ローカルプール１５１を管理するローカルプール制御部１５０が形成された第３ノードと、の異同関係に基づいて、ホスト部１０２によるＩ／Ｏ処理の対象データの送信を制御するように構成する。【選択図】図４
2020154990.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードを備える計算機システムであって、
少なくともいずれか一つのノードに形成され、所定のデータ管理単位に対するＩ／Ｏ処理の要求を発行するホスト部と、
前記データ管理単位に対する記憶領域を提供する記憶デバイスを備える複数のノードのそれぞれに形成され、一のノードの記憶デバイスの記憶領域に基づくローカル論理領域の管理を担当する複数のローカル制御部と、
少なくともいずれか一つのノードに形成され、前記ホスト部によるＩ／Ｏ処理の対象となる前記データ管理単位に割り当てられる、複数の前記ローカル論理領域に基づくグローバル論理領域の管理を担当するグローバル制御部と、を備え、
前記グローバル制御部は、
前記Ｉ／Ｏ処理を行った前記ホスト部が形成された第１ノードと、自身が形成された第２ノードと、前記グローバル論理領域に対応するローカル論理領域を管理するローカル制御部が形成された第３ノードと、の異同関係に基づいて、前記ホスト部による前記データ管理単位のＩ／Ｏ処理の対象データの送信を制御する
計算機システム。
【請求項２】
前記第１ノードと、前記第２ノードと、前記第３ノードと、がそれぞれ異なるノードであり、
前記グローバル制御部は、
前記データ管理単位のＩ／Ｏ処理の対象データを、前記第１ノードと前記第３ノードとの間で前記第２ノードを介さずに送信させる
請求項１に記載の計算機システム。
【請求項３】
前記グローバル制御部は、
前記第１ノードと前記第３ノードとの中の送信元のノードに送信先のノードを示す情報送信する
請求項２に記載の計算機システム。
【請求項４】
前記Ｉ／Ｏ処理は、前記データ管理単位からデータを読み込むリード処理であり、
前記グローバル制御部は、前記データ管理単位のデータについてキャッシュする処理を実行可能であり、
前記グローバル制御部は、
前記Ｉ／Ｏ処理対象のデータがキャッシュされている場合には、第１ノードと、前記第２ノードとが同一か否かを判定し、同一である場合には、第１ノードにキャッシュされているデータを送信する一方、同一でない場合には、第１ノードと第３ノードとが同一のノードであるか否かを判定し、第１ノードと第３ノードとが同一のノードである場合には、前記ローカル制御部に前記第３ノードから前記第１ノードへデータを送信させる
請求項１に記載の計算機システム。
【請求項５】
前記Ｉ／Ｏ処理は、前記データ管理単位からデータを読み込むリード処理であり、
前記グローバル制御部は、前記データ管理単位のデータについてキャッシュする処理を実行可能であり、
前記グローバル制御部は、
前記Ｉ／Ｏ処理対象のデータがキャッシュされていない場合において、前記ローカル制御部に前記第３ノードから前記第１ノードへデータを送信させる
請求項４に記載の計算機システム。
【請求項６】
前記Ｉ／Ｏ処理は、前記データ管理単位に対してデータを書き込むライト処理であり、
前記グローバル論理領域の所定の単位領域は、１以上のローカル論理領域に格納されて管理されており、
前記グローバル制御部は、前記データ管理単位のデータについてキャッシュする処理を実行可能であり、
前記グローバル制御部は、
前記Ｉ／Ｏ処理の対象領域の旧データがキャッシュされている場合において、前記第２ノードと前記第１ノードとが同一であるか否かを判定し、前記第２ノードと前記第１ノードとが同一である場合には、ホスト部による対象データを取得してキャッシュし、対象データをローカル論理領域が管理されている１以上の第３ノードに送信する
請求項１に記載の計算機システム。
【請求項７】
前記グローバル制御部は、
前記第２ノードと前記第１ノードとが同一でない場合には、対象データを第１ノードから第３ノードに送信させる
請求項６に記載の計算機システム。
【請求項８】
前記Ｉ／Ｏ処理は、前記データ管理単位に対してデータを書き込むライト処理であり、
前記グローバル論理領域の所定の単位領域は、複数のローカル論理領域にＥｒａｓｕｒｅ  Ｃｏｄｉｎｇにより冗長管理されており、
前記グローバル制御部は、前記データ管理単位のデータについてキャッシュする処理を実行可能であり、
前記グローバル制御部は、
前記Ｉ／Ｏ処理の対象領域がＥｒｓｕｒｅ  Ｃｏｄｉｎｇのストライプのデータ部の一部の領域であり、対象領域の旧データがキャッシュされている場合において、前記第２ノードと前記第１ノードとが同一のノードであるか否かを判定し、前記第２ノードと前記第１ノードとが同一のノードである場合に、自ノードの対象領域の新データと、キャッシュされている旧データとに基づいて、前記ストライプにおけるパリティ部のパリティを生成するための中間データを生成し、前記パリティ部を管理するローカル制御部に前記中間データを送信し、データ部を管理する複数のローカル制御部に前記新データを送信する
請求項１に記載の計算機システム。
【請求項９】
前記グローバル制御部は、
前記第２ノードと前記第１ノードとが同一のノードでない場合に、第１ノードから前記第２ノードに前記新データを送信させ、送信された前記新データと、キャッシュされている旧データとに基づいて、前記ストライプにおけるパリティ部のパリティを生成するための中間データを生成する
請求項８に記載の計算機システム。
【請求項１０】
前記Ｉ／Ｏ処理は、前記データ管理単位に対してデータを書き込むライト処理であり、
前記グローバル論理領域の所定の単位領域は、複数のローカル論理領域にＥｒａｓｕｒｅ  Ｃｏｄｉｎｇにより冗長管理されており、
前記グローバル制御部は、前記データ管理単位のデータについてキャッシュする処理を実行可能であり、
前記グローバル制御部は、
前記Ｉ／Ｏ処理の対象領域がＥｒｓｕｒｅ  Ｃｏｄｉｎｇのストライプのデータ部の全体の領域であり、対象領域の新データをキャッシュし、
前記ストライプのデータ部を管理する複数のローカル制御部のそれぞれの第３ノードについて、前記第２ノードと同じノードである場合には、前記キャッシュされている対象領域の新データからデータ部に対応するデータを送信し、前記第２ノードと同じノードでない場合には、第１ノードと前記第３ノードとが同じノードであれば、第１ノードから対象領域の新データからデータ部に対応するデータを送信する
請求項１に記載の計算機システム。
【請求項１１】
前記グローバル制御部は、
前記第２ノードと、前記ストライプのパリティ部を管理するローカル制御部の第３ノードとが同じノードである場合には、前記キャッシュされている対象領域の新データからパリティを作成し、前記パリティを前記ストライプのパリティ部を管理するローカル制御部の第３ノードに送信し、前記第２ノードと、前記ストライプのパリティ部を管理するローカル制御部の第３ノードとが同じノードでない場合には、第１ノードと、第３ノードとが同じノードであれば、第１ノードに新データからパリティを作成させ、前記パリティを前記ストライプのパリティ部を管理するローカル制御部の第３ノードに送信させる
請求項１０に記載の計算機システム。
【請求項１２】
前記ホスト部は、他のノードに移動可能である
請求項１に記載の計算機システム。
【請求項１３】
前記データ管理単位に対して他のグローバル制御部が管理する他のグローバル論理領域を割り当てることが可能であるとともに、前記データ管理単位に割り当てるグローバル論理領域に対して、他のローカル制御部が管理する他のローカル論理領域を割り当てることが可能である
請求項１に記載の計算機システム。
【請求項１４】
複数のノードを備える計算機システムによるデータ管理方法であって、
前記計算機システムは、
少なくともいずれか一つのノードに形成され、所定のデータ管理単位に対するＩ／Ｏ処理の要求を発行するホスト部と、
前記データ管理単位に対する記憶領域を提供する記憶デバイスを備える複数のノードのそれぞれに形成され、一のノードの記憶デバイスの記憶領域に基づくローカル論理領域の管理を担当する複数のローカル制御部と、
少なくともいずれか一つのノードに形成され、前記ホスト部によるＩ／Ｏ処理の対象となる前記データ管理単位に割り当てられる、複数の前記ローカル論理領域に基づくグローバル論理領域の管理を担当するグローバル制御部と、を備え、
前記計算機システムのグローバル制御部は、
前記Ｉ／Ｏ処理を行った前記ホスト部が形成された第１ノードと、自身が形成された第２ノードと、前記グローバル論理領域に対応するローカル論理領域を管理するローカル制御部が形成された第３ノードと、の異同関係に基づいて、前記ホスト部による前記データ管理単位のＩ／Ｏ処理の対象データの送信を制御する
データ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の物理ノードを備える計算機システムにおけるデータを管理する技術に関する。
【背景技術】
【０００２】
ストレージデバイスを備える複数のノード（物理計算機：例えば、汎用サーバ）により構成された計算機システムが知られている。このような計算機システムには、例えば、Ｈｙｐｅｒｖｉｓｏｒやコンテナ等により、同一のノード内に仮想的なホストや、仮想的なストレージを構成したＨＣＩ（Ｈｙｐｅｒ−Ｃｏｎｖｅｒｇｅｄ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）が知られている。
【０００３】
ＨＣＩにおけるホストのＩ／Ｏ処理を実行する要素としては、ホストＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）と、論理データ領域（ボリューム）のオーナ権を有するＳＤＳ（Ｓｏｆｔｗａｒｅ  Ｄｅｆｉｎｄ  Ｓｔｏｒａｇｅ：論理領域オーナＳＤＳ）と、物理データ領域（ドライブの記憶領域）のオーナ権を有するＳＤＳ（物理領域オーナＳＤＳ）とがある。
【０００４】
ＨＣＩにおいては、例えば、ノードにおけるＭＰ（マイクロプロセッサ）の負荷を分散させるために、ホストＶＭを他のノードに移動させることがある。ホストＶＭを移動させる技術としては、例えば、特許文献１に記載されている技術が知られている。
【０００５】
また、ノード内の記憶容量の不足を解消させるために、ボリュームを担当する論理領域オーナＳＤＳや物理領域オーナＳＤＳを別のノードのＳＤＳに移動させることがある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開第２０１８／０２９８２０号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
例えば、ＨＣＩにおけるホストのＩ／Ｏ処理の性能を高く維持するためには、ホストＶＭと、Ｉ／Ｏ処理の対象のデータの論理領域オーナＳＤＳ及び物理領域オーナＳＤＳとを同一のノード上に配置しておくことが好ましい。
【０００８】
しかしながら、上述のように、ホストＶＭが移動されたり、対象のデータを担当する論理領域オーナＳＤＳと物理領域オーナＳＤＳとを別のノードのＳＤＳに移動されたりすることがある。この場合には、ホストＶＭ、論理領域オーナＳＤＳ、及び物理領域オーナＳＤＳの間の通信がノード間の通信となるので、Ｉ／Ｏ処理の性能が低下する。特に、ホストＶＭ、論理領域オーナＳＤＳ、及び物理領域オーナＳＤＳのそれぞれが別のノードに配置されている場合には、Ｉ／Ｏ処理の対象のデータを転送するためのノード間の通信の回数が多くなり、Ｉ／Ｏ処理の性能が低下してしまう。
【０００９】
また、ＨＣＩ構成に限られず、ホストＶＭ、論理領域オーナＳＤＳ、及び物理領域オーナＳＤＳを別のノードとして構成している場合にも同様な問題が発生する。
【００１０】
本発明は、上記事情に鑑みなされたものであり、その目的は、複数のノードで構成された計算機システムにおいて、ホストによるＩ／Ｏ処理の性能を向上することのできる技術を提供することにある。
【課題を解決するための手段】
【００１１】
上記目的を達成するため、一観点に係る計算機システムは、複数のノードを備える計算機システムであって、少なくともいずれか一つのノードに形成され、所定のデータ管理単位に対するＩ／Ｏ処理の要求を発行するホスト部と、データ管理単位に対する記憶領域を提供する記憶デバイスを備える複数のノードのそれぞれに形成され、一のノードの記憶デバイスの記憶領域に基づくローカル論理領域の管理を担当する複数のローカル制御部と、少なくともいずれか一つのノードに形成され、ホスト部によるＩ／Ｏ処理の対象となるデータ管理単位に割り当てられる、複数のローカル論理領域に基づくグローバル論理領域の管理を担当するグローバル制御部と、を備え、グローバル制御部は、Ｉ／Ｏ処理を行ったホスト部が形成された第１ノードと、自身が形成された第２ノードと、グローバル論理領域に対応するローカル論理領域を管理するローカル制御部が形成された第３ノードと、の異同関係に基づいて、ホスト部によるデータ管理単位のＩ／Ｏ処理の対象データの送信を制御する。
【発明の効果】
【００１２】
本発明によれば、複数のノードで構成された計算機システムにおいて、ホストによるＩ／Ｏ処理の性能を向上することができる。
【図面の簡単な説明】
【００１３】
【図１】図１は、一実施形態に係るリード処理の一例の概要を説明する図である。
【図２】図２は、一実施形態に係るライト処理の一例の概要を説明する図である。
【図３】図３は、一実施形態に係る計算機システムの全体構成図である。
【図４】図４は、一実施形態に係るＩ／Ｏ処理の概要及びデータの論理構成を説明する図である。
【図５】図５は、一実施形態に係るメモリ及びドライブの構成図である。
【図６】図６は、一実施形態に係るノード構成管理テーブルの構成図である。
【図７】図７は、一実施形態に係るドライブ構成管理テーブルの構成図である。
【図８】図８は、一実施形態に係るホストパス管理テーブルの構成図である。
【図９】図９は、一実施形態に係るボリューム管理テーブルの構成図である。
【図１０】図１０は、一実施形態に係るグローバルプール管理テーブルの構成図である。
【図１１】図１１は、一実施形態に係るローカルプール管理テーブルの構成図である。
【図１２】図１２は、一実施形態に係るホスト部のＩ／Ｏ処理のフローチャートである。
【図１３】図１３は、一実施形態に係るホストパス制御部の処理のフローチャートである。
【図１４】図１４は、一実施形態に係るボリューム制御部の処理のフローチャートである。
【図１５】図１５は、一実施形態に係るグローバルプール制御部のメイン処理のフローチャートである。
【図１６】図１６は、一実施形態に係るリード時転送処理のフローチャートである。
【図１７】図１７は、一実施形態に係るリードキャッシュミス時処理のフローチャートである。
【図１８】図１８は、一実施形態に係るライト時転送処理のフローチャートである。
【図１９】図１９は、一実施形態に係る転送処理（Ｗｒｉｔｅ  Ｍｉｒｒｏｒｉｎｇ）のフローチャートである。
【図２０】図２０は、一実施形態に係るキャッシュミス時処理（Ｗｒｉｔｅ  Ｍｉｒｒｏｒｉｎｇ）のフローチャートである。
【図２１】図２１は、一実施形態に係る転送処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）のフローチャートである。
【図２２】図２２は、一実施形態に係るキャッシュミス時処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）のフローチャートである。
【図２３】図２３は、一実施形態に係るキャッシュミス時リモート処理のフローチャートである。
【図２４】図２４は、一実施形態に係る転送処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ  フルストライプ）のフローチャートである。
【図２５】図２５は、一実施形態に係るキャッシュミス時処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ  フルストライプ）のフローチャートである。
【図２６】図２６は、一実施形態に係るローカルプール制御部の転送処理のフローチャートである。
【図２７】図２７は、一実施形態に係るホストパス制御部の転送処理のフローチャートである。
【図２８】図２８は、一実施形態に係るローカルプールページライト処理のフローチャートである。
【図２９】図２９は、一実施形態に係るホストパス制御部の中間データ生成処理のフローチャートである。
【図３０】図３０は、一実施形態に係るローカルプール制御部の中間データ生成処理のフローチャートである。
【発明を実施するための形態】
【００１４】
実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１５】
以下の説明では、「ＡＡＡテーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ＡＡＡテーブル」を「ＡＡＡ情報」と呼ぶことができる。
【００１６】
図１は、一実施形態に係るリード処理の一例の概要を説明する図である。ここで、図１において、実線の矢印は、リード対象のデータの送信を示し、点線の矢印は、リード対象のデータの送信を伴わない送信、例えば、コマンドの送信を示している。
【００１７】
計算機システム１００においては、複数のノード１０１がネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｉｎｆｉｎｉｂａｎｄ、ＦＣ（Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ）、ＰＣＩ直結、無線等）を介して接続されてクラスタ化されている。ノード１０１は、物理的な計算機（例えば、汎用サーバ）で構成される。
【００１８】
ノード１０１においては、ホストプログラムがプロセッサに実行されることによりホスト部１０２が構成され、ストレージ制御プログラムがプロセッサに実行されることによりストレージ制御部１０３が構成される。図１の例では、例えばＨｙｐｅｒｖｉｓｏｒ、コンテナ等の技術を用いて、ホスト部１０２と、ストレージ制御部１０３とを１つのノードで動作できる構成となっている。なお、ホスト部１０２と、ストレージ制御部１０３とを別々のノードでしか動作できない構成としてもよい。
【００１９】
ホスト部１０２から、ドライブ（ストレージデバイス）１１２上に永続化されているデータにアクセスする場合、ストレージ制御部１０３が提供する仮想化されたデータ管理単位（例えば、ボリューム、ＬＵ（論理ユニット）、オブジェクト等）の領域へアクセスを行う。ストレージ制御部１０３は、複数（後述する図3の例では、４つ）の階層化された制御部で構成されている。各制御部は、それぞれが担当するリソース（例えば、ボリューム、ページ（グルーバルプールページ、ローカルプールページ））などを管理する権利（オーナ権）を持っている。したがって、ストレージ制御部１０３内では、ホスト部１０２によるデータアクセスを実現するために、複数の制御部間で通信が行われる。
【００２０】
ここで、図１を参照して、ノード０のホスト部１０２がノード２のドライブ１１２に格納されているデータをリードする場合の処理について説明する。ここで、ノード２のドライブ１１２に格納されているデータを管理する仮想的なボリュームに割り当てられているグローバルプール（グローバル論理領域の一例。Ｇプールという）のページ（Ｇプールページ）については、ノード１のストレージ制御部１０３がオーナ権を有している、すなわち、処理を担当するものとする。
【００２１】
まず、ノード０のホスト部１０２がリード対象のデータ（図1の説明において対象データ）に対応するコマンド（リードコマンド）をノード０のストレージ制御部１０３に送信する（図１の（１））。ここで、コマンドには、例えば、対象データが管理されているボリュームや、データの送信先情報（ノード０のホスト部１０２のノード１０１の情報）等が含まれている。
【００２２】
ストレージ制御部１０３は、コマンドに対応するボリュームに割り当てられているＧプールページを担当するストレージ制御部１０３（本例では、ノード１のストレージ制御部１０３）に対して、コマンドを送信する（図１の（２））。
【００２３】
ノード１のストレージ制御部１０３は、受信したコマンドに基づいて、Ｇプールページに対応するローカルプール（ローカル論理領域の一例。Ｌプール）のページ（Ｌプールページ）のオーナ権を有しているストレージ制御部１０３（本例では、ノード２のストレージ制御部１０３）を特定し、特定したストレージ制御部１０３に、データの送信先情報を含むコマンドを送信する（図１の（３））。ここで、送信先情報は、例えば、リードコマンドを送信したホスト部１０２のノード情報である。
【００２４】
ノード２のストレージ制御部１０３は、コマンドに基づいて、Ｌプールページに対応するドライブ１１２の領域から対象データを読み出す（図１の（４））。
【００２５】
次いで、ノード２のストレージ制御部１０３は、読み出した対象データを、送信先情報が示すノード１０１（本例では、ノード０）のストレージ制御部１０３に送信する（図１の（５−１））とともに、コマンドに対する応答を、コマンドを送信してきたノード１のストレージ制御部１０３に送信する（図１の（５−２））。
【００２６】
コマンドの応答を受け取った、ノード１のストレージ装置１０３は、自身に対するコマンドの送信元のノード０のストレージ制御部１０３に、コマンドに対する応答を送信する（図１の（６））。
【００２７】
ノード０のストレージ制御部１０３は、ノード２から送信された対象データをメモリ等に格納する。
【００２８】
ノード０のストレージ制御部１０３は、ノード２から対象データを受信するとともに、ノード１からコマンドに対応する応答を受信した場合には、コマンドに対する応答をホスト部１０２に通知する（図１の（７））。この応答には、例えば、対象データを格納したメモリのアドレスを含んでもよく、対象データを含んでもよい。なお、ノード２からのリード対象のデータの受信のタイミング（図１の（５−１））と、ノード１からのコマンドに対する応答のタイミング（図１の（６））は、いずれが先であってもよい。
【００２９】
これにより、ホスト部１０２では、対象データを取得でき、処理に利用することができる。
【００３０】
従来においては、ノード２で読み出された対象データは、コマンドの送信元のノード１のストレージ制御部を経由して、ノード０のストレージ制御部に送信されることとなるが、上記したように本実施形態によると、対象データは、ノード１を経由せずに、ノード２から直接ノード０のストレージ制御部１０３に送信されることとなる。このため、ノード間の送信回数を低減することができ、ホスト１０２によるＩ／Ｏ処理の応答時間を短縮することができ、Ｉ／Ｏ処理の性能が向上する。
【００３１】
なお、図１の例では、ホスト部１０２は、自ノードのストレージ制御部１０３にコマンドを送信するようにしていたが、例えば、対象データのボリュームについてのオーナ権を有するノード１にコマンドを送信する構成としてもよい。
【００３２】
次に、ノード１０１のホスト部１０２がデータをライトする場合の処理について説明する。
【００３３】
図２は、一実施形態に係るライト処理の一例の概要を説明する図である。
【００３４】
ここで、本例では、ノード１のホスト部１０２がデータをライトする場合であり、ライト対象のデータ（図２の説明において、対象データという）は、ノード０のドライブ１１２と、ノード３のドライブ１１２にミラーリング（２重化）されて管理されており、また、対象データを管理する仮想的なボリュームに割り当てられているＧプールページについては、ノード２のストレージ制御部１０３がオーナ権を有している、すなわち、処理を担当するものとする。
【００３５】
まず、ノード１のホスト部１０２が対象データに対応するコマンド（ライトコマンド）をノード１のストレージ制御部１０３に送信する（図２の（１））。ここで、コマンドには、例えば、ライト対象のデータが管理されているボリュームや、対象データが格納されているメモリの領域の情報、ホスト部１０２のノード（ノード１）の情報等が含まれている。
【００３６】
ノード１のストレージ制御部１０３は、コマンドに対応するボリュームに割り当てられているＧプールページを担当するストレージ制御部１０３（本例では、ノード２のストレージ制御部１０３）に対して、同様なコマンドを送信する（図２の（２））。
【００３７】
ノード２のストレージ制御部１０３は、受信したコマンドに基づいて、Ｇプールページに対応するＬプールページのオーナ権を有しているストレージ制御部１０３（本例では、ノード０及びノード３のストレージ制御部１０３）を特定し、ノード１のストレージ制御部１０３に、データのライト先となる特定したストレージ制御部１０３のノード（本例では、ノード０及びノード３）を示す送信先情報を含むコマンドを送信する（図２の（３））。
【００３８】
ノード１のストレージ制御部１０３は、ノード２から受け取ったコマンドの転送先情報に対応するノード（本例では、ノード０とノード３）に対して、コマンドと、対象データとを送信する。ここで、コマンドには、Ｇプールページのオーナ権を有するノード２の情報がコマンドに対応する応答先の情報として含まれている（図２の（４））。
【００３９】
ノード０とノード３においては、ストレージ制御部１０３がコマンド及び対象データを受け取ると、対象データをドライブ１１２に格納し（図２の（５））、ライトが完了した応答を、コマンドに含まれているＧページプールのオーナ権を有するノード２に対して送信する（図２の（６））。
【００４０】
ノード２のストレージ制御部１０３は、ノード０とノード３のストレージ制御部１０３からライトが完了したとの応答を受け取ると、コマンドの要求元のノード１のストレージ制御部１０３に対して、応答を送信する（図２の（７））。
【００４１】
ノード１のストレージ制御部１０３は、ノード２からコマンドに対する応答を受け取ると、ホスト部１０２に対してライトが終了した旨の応答を送信する（図２の（８））。これにより、ホスト部１０２では、ライト処理が完了したことを把握することができる。
【００４２】
従来においては、対象データは、ホスト部１０２のノード１からコマンドの送信先のノード２のストレージ制御部を経由して、ノード０とノード３とのストレージ制御部に送信されることとなるが、上記したように本実施形態によると、対象データは、ノード２を経由せずに、ノード１から直接ノード０及びノード３のストレージ制御部１０３に送信されることとなる。このため、対象データのノード間の送信回数を低減することができ、ホスト１０２のＩ／Ｏ処理の応答時間を短縮することができ、Ｉ／Ｏ処理の性能が向上する。
【００４３】
次に、本実施形態に係る計算機システムについて詳細に説明する。
【００４４】
図３は、一実施形態に係る計算機システムの全体構成図である。
【００４５】
計算機システム１００は、複数のノード１０１を備える。複数のノードは、１又は複数のサイトに配置されていてもよい。図３の例では、計算機システム１は、複数のサイト１０Ａ，１０Ｂにノード１０１が配置されている。具体的には、サイトＡ（１０Ａ）においては、複数のノード１０１がネットワーク１１５を介して接続されている。また、サイトＢ（１０Ｂ）においては、複数のノード１０１がネットワーク１１５を介して接続されている。サイトＡのネットワーク１１５と、サイトＢのネットワーク１１５は、ネットワーク１１６を介して接続されている。ここで、ネットワーク１１５，１１６は、有線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、無線ＬＡＮ、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｏｗｏｒｋ）などである。
【００４６】
ノード１０１は、メモリ１１０と、プロセッサ１１１と、複数のドライブ（記憶デバイスの一例）１１２と、ポート１１３と、バス１１４とを備える。メモリ１１０、プロセッサ１１１、ドライブ１１２、及びポート１１３は、バス１１４を介して接続されている。
【００４７】
メモリ１１０は、例えば、ＲＡＭ（ＲＡＮＤＯＭ  ＡＣＣＥＳＳ  ＭＥＭＯＲＹ）であり、プロセッサ１１１で実行されるプログラムや、必要な情報を記憶する。
【００４８】
ポート１１３は、例えば、有線ＬＡＮカードや無線ＬＡＮカードなどのインターフェースであり、ネットワーク１１５を介して他の装置（ノード１０１）と通信する。
【００４９】
プロセッサ１１１は、メモリ１１０及び／又はドライブ１１２に格納されているプログラムに従って各種処理を実行する。
【００５０】
ドライブ１１２は、例えば、ＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）、不揮発メモリなどであり、プロセッサ１１１で実行されるプログラムや、プロセッサ１１１に利用されるデータを記憶する。また、ドライブ１１２の記憶領域は、例えば、バッファやキャッシュとして利用される。
【００５１】
図４は、一実施形態に係るＩ／Ｏ処理の概要及びデータの論理構成を説明する図である。
【００５２】
計算機システム１００は、ホスト部１０２、ホストパス制御部群１２０、ボリューム制御部群１３０、グローバルプール制御部群１４０、ローカルプール制御部１５０を備える。
【００５３】
ホスト部１０２は、ホストプログラム２１１（図５参照）をプロセッサ１１１が実行することにより構成される。ホストプログラム２１１としては、データ処理を実行するプログラムであり、例えば、データベースプログラム、Ｗｅｂサーバプログラム、データ解析プログラム等である。
【００５４】
ホスト部１０２は、ストレージ制御プログラム２１２（図５参照）が提供する仮想化されたデータ領域（データ管理単位、例えば、ボリュームＶＯＬ）をマウントし、ボリュームＶＯＬに対するＩ／Ｏ要求（リード（ｒｅａｄ）要求、ライト（ｗｒｉｔｅ）要求）を発行することにより、いずれかのノード１０１のドライブ１１２に対するデータのＩ／Ｏ（リード、ライト）を実行する。
【００５５】
ここで、ホスト部１０２が発行するＩ／Ｏ要求には、コマンドと、必要に応じてライト対象のデータとが含まれる。Ｉ／Ｏ要求のコマンドには、例えば、Ｉ／Ｏ種別（リード又はライト）と、Ｉ／Ｏ対象の領域を特定する情報（ＬＵＮ（論理ユニット番号）、ボリュームＩＤ）と、Ｉ／Ｏ対象の領域のアドレス（例えば、ＬＢＡ（Ｌｏｇｃａｌ  Ｂｌｏｃｋ  Ａｄｄｒｅｓｓ））と、Ｉ／Ｏ対象のデータサイズと、Ｉ／Ｏ対象のデータの格納先又は格納元のメモリアドレス、ホスト部１０２のノード１０１の情報等が含まれる。
【００５６】
ホスト部１０２は、１つのノード１０１に複数形成されてもよい。また、ホスト部１０２は、ノード１０１における負荷分散のために、他のノード１０１に移動可能である。
【００５７】
ホストパス制御部群１２０は、ホストパス制御プログラム２１５（図５参照）を各ノード１０１のプロセッサ１１１が実行することにより構成されるホストパス制御部１２１の集合である。各ノード１０１のホストパス制御部１２１は、他のノード１０１のホストパス制御部１２１と連携して各種処理を実行する。ホストパス制御部１２１は、ホスト部１０２とボリュームＶＯＬ間のコマンド、データ転送を仮想化する制御を行う。ホストパス制御部１２１は、ホストパス管理テーブル２０３（図５参照）を管理する。
【００５８】
ホストパス制御部群１２０は、ホスト部１０２からのコマンドを、コマンドが対象とするボリュームのオーナのノード１０１（ボリューム制御部１３１）に転送する制御を行う。ホスト部１０２と、ホストパス制御部１２１との間の通信プロトコルとしては、ブロックアクセス用のプロトコル（ＳＣＳＩ、ｉＳＣＳＩ、ＮＶＭｅ、ＮＶＭｅ−ＯＦ等）、ファイルアクセス用のプロトコル、オブジェクトアクセス用のプロトコル、他のプロトコルでもよい。
【００５９】
ホストパス制御部１２１は、例えば、コマンドが対象とするボリュームＶＯＬのオーナのノード１０１が、自ノードである場合には、コマンドをメモリへコピーするか、又は、コマンドの格納先の物理アドレスや仮想アドレスをボリューム制御部１３１に通知する。一方、コマンドが対象とするボリュームＶＯＬのオーナのノード１０１が、自ノードでない場合には、ホストパス制御部１２１は、ノード間のネットワークを介してのデータコピーによりコマンドを送信する。
【００６０】
ボリューム制御部群１３０は、ボリューム制御プログラム２１６（図５参照）を各ノード１０１のプロセッサ１１１が実行することにより構成されるボリューム制御部１３１の集合である。ボリューム制御部群１３０は、ボリュームＶＯＬに対してＧプールページＧＰ単位のシンプロビジョニングを行う等のストレージ機能を提供する。ボリューム制御部１３１は、ホスト部１０２に提供するボリュームＶＯＬを担当するノード、すなわち、オーナとなるノードを管理する。ボリューム制御部１３１は、ボリューム管理テーブル２０４（図５参照）により、ボリュームを管理する。ボリューム制御部１３１は、ホストパス制御部１２１から転送されたコマンドに従って、対象のボリューム内のアクセス対象のＧプールページＧＰを特定し、特定したＧプールページのオーナであるグローバルプール制御部１４１にコマンドを転送する。
【００６１】
本実施形態では、ノード１０１における容量不足を解消するために、例えば、ボリュームに対して割り当てるＧプールを別のＧプールとすることもできる。この場合には、ボリュームに割り当てられているＧプールページを担当するグローバルプール制御部１４１が変わることとなる。この場合には、担当するグローバルプール制御部１４１を備えるノード１０１が変わることもある。
【００６２】
グローバルプール制御部群１４０は、グローバルプール制御プログラム２１７（図５参照）を各ノード１０１のプロセッサ１１１が実行することにより構成されるグローバルプール制御部１４１（グローバル制御部の一例）の集合である。グローバルプール制御部群１４０は、複数のノード１０１のドライブ１１２の記憶領域により構成される仮想的なプールである１以上のグローバルプール１４２を管理制御する。本実施形態では、グローバルプール１４２のＧプールページＧＰを単位として、オーナとなるグローバルプール制御部１４１が設定されている。ＧプールページＧＰは、ローカルプール制御部１５０が提供する複数のＬプールページＬＰによるノード間データ保護によって保護された論理領域である。ＧプールページＧＰのデータサイズは、固定長でも可変長でもよい。なお、ＧプールページＧＰをノード間データ保護によって保護しなくてもよい。具体的には、ＧプールページＧＰと、ＬプールページＬＰとを一対一に対応させてもよく、ＲＡＩＤ０のように、ＧプールページＧＰが複数のＬプールページでストライピングされて構成されていてもよい。なお、この場合には、ホストプログラム２１１自体が、ノード間データ保護を実施するようにしてもよい。
【００６３】
ノード間データ保護としては、２つ以上のノードのローカルプール間で、複製を持つミラリング（Ｍｉｒｒｏｒｉｎｇ）や、パリティによって冗長化するＥｒａｓｕｒｅ  Ｃｏｄｉｎｇ（ＲＡＩＤ５、ＲＡＩＤ６を含む）を採用することができる。
【００６４】
本実施形態では、ホスト部１０２のＩ／Ｏ処理の対象のボリュームに割り当てられたＧプールページを担当するグローバルプール制御部１４１が、Ｉ／Ｏ処理を実行するホスト部１０２及びホストパス制御部１２１のノード（第１ノード）と、自身のノード（第２ノード）と、Ｉ／Ｏ処理の対象のＧプールページに割り当てられているＬプールページのＬプールを担当するローカルプール制御部１５０のノード（第３ノード）とのいずれか複数についての異同関係、すなわち、同じノードであるか、又は違うノードであるかの関係に基づいて、ホスト部１０２によるＩ／Ｏ処理の対象データの送信（例えば、送信元や送信先）を制御する。これにより、状態に応じて、処理効率の高い経路を適切に選択することができ、Ｉ／Ｏ処理の効率を向上することができる。
【００６５】
本実施形態では、ノード１０１におけるドライブ１１２の容量不足を解消するために、例えば、Ｇプールページに対して割り当てるＬプールページを提供するＬプールを別のＬプールとすることもできる。この場合には、Ｇプールページに割り当てられるＬプールページを担当するローカルプール制御部１５０が変わることとなる。この場合には、担当するローカルプール制御部１５０を備えるノード１０１が変わることとなる。
【００６６】
ローカルプール制御部１５０（ローカル制御部の一例）は、ローカルプール制御プログラム２１８（図５参照）をノード１０１のプロセッサ１１１が実行することにより構成される。ローカルプール制御部１５０は、自ノード１０１内の複数のドライブ１１２の記憶領域により構成される仮想的なプールであるローカルプール１５１を管理制御する。ローカルプール制御部１５０は、ローカルプール１５１のＬプールページ（ＬＰ）をグローバルプール制御部１４１に提供する。ＬプールページＬＰは、ドライブ１１２内の１以上のデータ領域（チャンクＣＫ）により構成される。チャンクＣＫのデータサイズは、固定長でも可変長でもよい。Ｌプールページは、複数のチャンクによるノード内データ保護によって保護されている。ノード内データ保護としては、例えば、ＲＡＩＤ０，１，５，６を採用することができる。なお、ＬプールページＬＰを、ノード内データ保護によって保護しなくてもよい。具体的には、Ｌプールページと、チャンクとを一対一に対応させるようにしてもよく、ＲＡＩＤ０のように、ＬプールページＬＰが複数のチャンクでストライピングされて構成されていてもよい。
【００６７】
なお、図４においては、各ノード１０１に、ホスト部１０２、ホストパス制御部１２１、ボリューム制御部１３１、グローバルプール制御部１４１、ローカルプール制御部１５０を備えた例を示しているが、これら構成要素は、計算機システム１００の各ノード１０１の役割等に応じて、一部のノード１０１のみに備えるようにしてもよく、また、一部の構成要素のみノード１０１に備えるようにしてもよい。
【００６８】
図５は、一実施形態に係るメモリ及びドライブの構成図である。
【００６９】
メモリ１１０は、制御情報テーブル２００と、プログラム２１０とを記憶する。制御情報テーブル２００は、ノード構成管理テーブル２０１と、ドライブ構成管理テーブル２０２と、ホストパス管理テーブル２０３と、ボリューム管理テーブル２０４と、グローバルプール管理テーブル２０５と、ローカルプール管理テーブル２０６とを含む。なお、制御情報テーブル２００の全てのテーブルが各ノード１０１に格納されていなくてもよく、各ノード１０１は、そのノードにおいて必要な一部のテーブルを格納しておけばよい。
【００７０】
プログラム２１０は、ホストプログラム２１１と、ストレージ制御プログラム２１２とを含む。ストレージ制御プログラム２１２は、クラスタ制御プログラム２１３と、ノード制御プログラム２１４と、ホストパス制御プログラム２１５と、ボリューム制御プログラム２１６と、グローバルプール制御プログラム２１７と、ローカルプール制御プログラム２１８とを含む。なお、プログラム２１０の全てのプログラムが各ノード１０１に格納されていなくてもよく、各ノード１０１は、そのノードにおいて必要なプログラムを格納しておけばよい。
【００７１】
クラスタ制御プログラム２１３は、プロセッサ１１１に実行されることにより、複数のノード１０１により構成されるクラスタを制御する処理を実行する。ノード制御プログラム２１４は、プロセッサ１１１に実行されることにより、ノード１０１を制御する処理を実行する。
【００７２】
ドライブ１１２は、メモリ１１０に格納されている制御情報テーブル２００及びプログラム２１０のバックアップデータ２３０を格納している。ドライブ１１２のバックアップデータ２３０については、例えば、ノード１０１内で冗長化して管理してもよく、複数のノード１０１間で冗長化して管理してもよい。
【００７３】
次に、ノード構成管理テーブル２０１について詳細に説明する。
【００７４】
図６は、一実施形態に係るノード構成管理テーブルの構成図である。
【００７５】
ノード構成管理テーブル２０１は、システム毎に１つ備えられている。ノード構成管理テーブル２０１は、クラスタを構成するノード毎に対応するエントリを格納する。ノード構成管理テーブル２０１のエントリは、ノードＩＤと、ノードアドレスリストと、走行アプリケーションプログラムＩＤリストと、所属グローバルプールＩＤとのフィールドを含む。ノードＩＤのフィールドには、エントリに対応するノード１０１の識別情報（ノードＩＤ）が格納される。ノードアドレスリストのフィールドには、エントリに対応するノード１０１のアドレス（例えば、ＩＰアドレス）のリストが格納される。走行アプリケーションプログラムＩＤリストのフィールドには、エントリに対応するノード１０１において走行しているアプリケーションのＩＤのリストが格納される。所属グローバルプールのフィールドには、エントリに対応するノード１０１が所属する、すなわち、ノード１０１のドライブ１１２の記憶容量が提供されるグローバルプールのＩＤ（グローバルプールＩＤ）が格納される。
【００７６】
次に、ドライブ構成管理テーブル２０２について詳細に説明する。
【００７７】
図７は、一実施形態に係るドライブ構成管理テーブルの構成図である。
【００７８】
ドライブ構成管理情報テーブル２０２は、ノード毎に１つ備えられており、各テーブルには、テーブルに対応するノード１０１のノードＩＤが対応付けられている。ドライブ構成管理情報テーブル２０２は、テーブルに対応するノード１０１のドライブ１１２毎のエントリを格納する。ドライブ構成管理情報テーブル２０２のエントリは、ドライブＩＤと、物理容量と、所属ローカルプールＩＤとのフィールドを含む。ドライブＩＤのフィールドは、エントリに対応するドライブ１１２のＩＤ（ドライブＩＤ）が格納される。物理容量のフィールドは、エントリに対応するドライブ１１２の物理容量が格納される。所属ローカルプールＩＤのフィールドには、エントリに対応するドライブ１１２が所属するローカルプールのＩＤ（ローカルプールＩＤ）が格納される。
【００７９】
次に、ホストパス管理テーブル２０３について詳細に説明する。
【００８０】
図８は、一実施形態に係るホストパス管理テーブルの構成図である。
【００８１】
ホストパス管理情報テーブル２０３は、グローバルプール毎に１つ備えられており、各テーブルには、テーブルに対応するグローバルプール１４２のグローバルプールＩＤが対応付けられている。ホストパス管理情報テーブル２０３は、ボリューム毎のエントリを格納する。ホストパス管理情報テーブル２０３のエントリは、ボリュームＩＤと、ボリュームオーナのノードＩＤと、ホストアプリケーションのノードＩＤリストとのフィールドを含む。ボリュームＩＤのフィールドには、エントリに対応するグローバルプールのページが割り当てられているボリュームのＩＤ（ボリュームＩＤ）が格納される。ボリュームオーナのノードＩＤのフィールドには、ボリュームを担当するノード（ボリュームオーナ）のノードＩＤが格納される。ホストアプリケーションのノードＩＤリストのフィールドには、エントリに対応するボリュームを使用するホストプログラムが走行するノードのノードＩＤが格納される。
【００８２】
次に、ボリューム管理テーブル２０４について詳細に説明する。
【００８３】
図９は、一実施形態に係るボリューム管理テーブルの構成図である。
【００８４】
ボリューム管理テーブル２０４は、ボリューム毎に１つ備えられており、各テーブルには、テーブルに対応するボリュームのボリュームＩＤが対応付けられている。ボリューム管理テーブル２０４は、ボリュームにおける論理ブロックごとのエントリを格納する。ボリューム管理テーブル２０４のエントリは、論理ブロックＩＤと、ブロックサイズと、グローバルプールＩＤと、グローバルプールページＩＤとのフィールドを含む。
【００８５】
論理ブロックＩＤのフィールドには、エントリに対応する論理ブロックのＩＤ（論理ブロックＩＤ）が格納される。ブロックサイズのフィールドには、エントリに対応する論理ブロックのデータサイズ（ブロックサイズ）が格納される。グローバルプールＩＤのフィールドには、エントリに対応する論理ブロックに対してページが割り当てられているＧプールのＩＤが格納される。グローバルプールページＩＤのフィールドには、エントリに対する論理ブロックに割り当てられているＧプールページのＩＤ（ＧプールページＩＤ）が格納される。
【００８６】
次に、グローバルプール管理テーブル２０５について詳細に説明する。
【００８７】
図１０は、一実施形態に係るグローバルプール管理テーブルの構成図である。
【００８８】
グローバルプール管理テーブル２０５は、グローバルプール毎に１つ備えられており、各テーブルには、テーブルに対応するグローバルプール１４２のグローバルプールＩＤが対応付けられている。グローバルプール管理テーブル２０５は、Ｇプールページ毎のエントリを格納する。グローバルプール管理テーブル２０５のエントリは、グローバルプールページＩＤと、ページサイズと、オーナノードＩＤと、データ保護設定と、ノードＩＤ、ローカルプールＩＤ、及びローカルプールページＩＤのリストとのフィールドを含む。
【００８９】
グローバルプールページＩＤのフィールドには、エントリに対応するＧプールページのＩＤが格納される。ページサイズのフィールドには、エントリに対応するＧプールページのページサイズが格納される。オーナノードＩＤのフィールドには、エントリに対応するＧプールページのオーナとなるノードのノードＩＤが格納される。データ保護設定のフィールドには、エントリに対応するＧプールページのデータを、複数のノードを用いて冗長化して保護する設定（データ保護設定）が格納される。ここで、データ保護設定としては、データを多重化して保存するＭｉｒｒｏｒｉｎｇや、パリティを用いて冗長化するＥｒａｓｕｒｅ  Ｃｏｄｉｎｇ等がある。ノードＩＤ、ローカルプールＩＤ、及びローカルプールページＩＤのリストのフィールドには、エントリに対応するＧプールページに割り当てられている複数のＬプールページを特定する情報が格納される。Ｌプールページを特定する情報としては、Ｌプールを格納するノード１０１のノードＩＤと、ＬプールのＩＤと、ＬプールページのＩＤとがある。
【００９０】
次に、ローカルプール管理テーブル２０６について詳細に説明する。
【００９１】
図１１は、一実施形態に係るローカルプール管理テーブルの構成図である。
【００９２】
ローカルプール管理テーブル２０６は、ローカルプール毎に１つ備えられており、各テーブルには、テーブルに対応するローカルプール１５１を有するノード１０１、すなわち、ローカルプール１５１のオーナのノード１０１のノードＩＤと、ローカルプール１５１のローカルプールＩＤとが対応付けられている。ローカルプール管理テーブル２０６は、Ｌプールページ毎のエントリを格納する。ローカルプール管理テーブル２０６のエントリは、ローカルプールページＩＤと、ページサイズと、データ保護設定と、ドライブＩＤ、開始アドレス、及びサイズのリストとのフィールドを含む。
【００９３】
ローカルプールページＩＤのフィールドには、エントリに対応するＬプールページのＩＤが格納される。ページサイズのフィールドには、エントリに対応するＬプールページのページサイズが格納される。データ保護設定のフィールドには、エントリに対応するＬプールページのデータを冗長化して保護する設定（データ保護設定）が格納される。ここで、データ保護設定としては、ＲＡＩＤのレベル（例えば、ＲＡＩＤ０、ＲＡＩＤ１、ＲＡＩＤ５、ＲＡＩＤ６等）がある。ドライブＩＤ、開始アドレス、及びサイズのリストのフィールドには、エントリに対応するＬプールページのデータを格納するドライブ１１２の領域を示す情報が格納する。ドライブ１１２の領域を示す情報としては、Ｌプールページを格納するドライブのドライブＩＤと、ドライブ１１２における領域の先頭を示す開始アドレスと、Ｌプールページのサイズとがある。
【００９４】
次に、計算機システム１００における処理動作について説明する。
【００９５】
まず、ホスト部１０２におけるＩ／Ｏ処理について説明する。
【００９６】
図１２は、一実施形態に係るホスト部のＩ／Ｏ処理のフローチャートである。
【００９７】
ホスト部１０２は、自ノード１０１のホストパス制御部１２１にＩ／Ｏのコマンドを発行し（ステップＳ１）、ホストパス制御部１２１からのコマンドに対応する結果（応答）を待ち（ステップＳ２）、コマンドに対する応答を受けた場合には、Ｉ／Ｏ処理を終了する。
【００９８】
次に、ホストパス制御部１２１におけるＩ／Ｏ処理について説明する。
【００９９】
図１３は、一実施形態に係るホストパス制御部の処理のフローチャートである。この処理は、ステップＳ１でホスト部１０２から送信されたコマンドを受信したホストパス制御部１２１が実行する処理である。
【０１００】
ホストパス制御部１２１は、ホスト部１０２からのコマンドを受信すると（ステップＳ１１）、ホストパス管理テーブル２０３を参照し、コマンドに含まれているＩ／Ｏの対象のボリューム（対象ボリュームという）のオーナのノードの情報（ノードＩＤ等）を取得する（ステップＳ１２）。オーナのノードＩＤは、対象ボリュームのボリュームＩＤと、コマンドを送信したホスト部１０２のノードＩＤとを用いて、ホストパス管理テーブル２０３を参照することにより取得することができる。
【０１０１】
次いで、ホストパス制御部１２１は、対象ボリュームのオーナのノード１０１が自ノードであるか否かを判定する（ステップＳ１３：Ｙｅｓ）。
【０１０２】
この結果、対象ボリュームのオーナが自ノードである場合（Ｓ１３：Ｙｅｓ）には、ホストパス制御部１２１は、自ノード１０１のボリューム制御部１３１にＩ／Ｏに係る処理依頼を送信し、処理をステップＳ１６に進める。一方、対象ボリュームのオーナが自ノードでない場合（Ｓ１３：Ｎｏ）には、ホストパス制御部１２１は、対象ボリュームのオーナのノード１０１のボリューム制御部１３１に対して、ノード間通信によりＩ／Ｏに係る処理依頼を送信し、処理をステップＳ１６に進める。ここで、処理依頼には、ホスト部１０２が送信したコマンドの内容の中の必要なものが含まれている。
【０１０３】
ステップＳ１６では、ホストパス制御部１２１は、処理依頼を行ったボリューム制御部１２１からの処理依頼に対する処理結果（応答）を待つ。ここで、リードの処理要求を行った場合には、処理結果には、リード対象のデータが含まれる。
【０１０４】
次いで、ホストパス制御部１２１は、処理結果を受け取った場合には、コマンドを送信した自ノード１０１のホスト部１０２に結果を返却し（ステップＳ１７）、処理を終了する。
【０１０５】
次に、ボリューム制御部１３１における処理について説明する。
【０１０６】
図１４は、一実施形態に係るボリューム制御部の処理のフローチャートである。この処理は、図１３のステップＳ１４、又はステップＳ１５でホストパス制御部１２１から送信された処理依頼を受信したボリューム制御部１３１が実行する処理である。
【０１０７】
ボリューム制御部１３１は、ホストパス制御部１２１から処理依頼を受信すると（ステップＳ２１）、ボリューム管理テーブル２０４を参照し、対象ボリュームのＩ／Ｏ対象となる論理ブロック（対象論理ブロック）に割り当てられているＧプールページのオーナとなるノード１０１の情報を取得する（ステップＳ２２）。ここで、Ｉ／Ｏ対象の論理ブロックが複数ある場合には、各対象論理ブロックについて、Ｇプールページのオーナとなるノード１０１の情報を取得する。
【０１０８】
次いで、ボリューム制御部１３１は、各対象論理ブロックについて、以下のステップＳ２３〜ステップＳ２５の処理を実行する。すなわち、ボリューム制御部１３１は、対象論理ブロックに割り当てられているＧプールページのオーナのノード１０１が、自ノード１０１（このボリューム制御部１３１が属するノード１０１）であるか否かを判定する（ステップＳ２３）。
【０１０９】
この結果、対象ボリュームの対象論理ブロックに割り当てられているＧプールページのオーナとなるノード１０１が、自ノード１０１である場合（ステップＳ２３：Ｙｅｓ）には、ボリューム制御部１３１は、自ノード１０１のグローバルプール制御部１４１にＩ／Ｏに係る処理依頼を送信し、処理をステップＳ２６に進める。一方、対象ボリュームのオーナが自ノードでない場合（ステップＳ２３：Ｎｏ）には、ボリューム制御部１３１は、Ｇプールページのオーナのノード１０１のグローバルプール制御部１４１に対して、ノード間通信によりＩ／Ｏに係る処理依頼を送信し、処理をステップＳ２６に進める。ここで、処理依頼には、ステップＳ２１で受信した処理内容の少なくとも一部が含まれている。
【０１１０】
ステップＳ２６では、ボリューム制御部１３１は、ステップＳ２４又はステップＳ２５で送信した処理依頼に対するグローバルプール制御部１４１からの処理結果を待つ。グローバル制御部１４１からの処理結果を全て受信した場合には、ボリューム制御部１３１は、結果をホストパス制御部１２１に返却し（ステップＳ２７）、処理を終了する。
【０１１１】
次に、グローバルプール制御部１４１における処理について説明する。
【０１１２】
図１５は、一実施形態に係るグローバルプール制御部のメイン処理のフローチャートである。この処理は、図１４のステップＳ２４、又はステップＳ２５でボリューム制御部１３１から送信された処理依頼を受信したグローバルプール制御部１４１が実行する処理である。
【０１１３】
グローバルプール制御部１４１は、ボリューム制御部１３１から処理依頼を受信すると（ステップＳ３１）、処理依頼に対応するＧプールページ（対象Ｇプールページ）についての情報を取得する（ステップＳ３２）。対象Ｇプールページについての情報としては、対象Ｇプールページのデータ保護設定、対象Ｇプールページのデータのキャッシュ状態（キャッシュヒット又はキャッシュミス）、対象Ｇプールページの領域に対するアクセスに関する統計情報等がある。例えば、対象Ｇプールページのデータ保護設定は、グローバルプール管理テーブル２０５から取得でき、その他の情報については、図示しないテーブルから取得できる。
【０１１４】
次いで、グローバルプール制御部１４１は、ローカルプール管理テーブル２０６を参照し、対象Ｇプールページに割り当てられているＬプールページのオーナとなるノード１０１の情報を取得する（ステップＳ３３）。
【０１１５】
次いで、グローバルプール制御部１４１は、処理依頼におけるコマンドの種類を特定する（ステップＳ３４）。この結果、コマンドの種類がリードである場合（ステップＳ３４：Ｒｅａｄ）には、グローバルプール制御部１４１は、リード時転送処理（図１６参照）を実行し（ステップＳ３５）、コマンドの種類がライトである場合（ステップＳ３４：Ｗｒｉｔｅ）には、グローバルプール制御部１４１は、ライト時転送処理（図１８参照）を実行する（ステップＳ３６）。
【０１１６】
次いで、グローバルプール制御部１４１は、処理結果をボリューム制御部１３１に返却し（ステップＳ３７）、処理を終了する。
【０１１７】
次に、リード時転送処理（図１５のステップＳ３５）について説明する。
【０１１８】
図１６は、一実施形態に係るリード時転送処理のフローチャートである。
【０１１９】
グローバルプール制御部１４１は、処理依頼におけるコマンドのリード対象の対象Ｇプールページのデータがキャッシュヒットするか否か、すなわち、自ノード１０１に対象Ｇプールページのデータがキャッシュされているか否かを判定する（ステップＳ４１）。
【０１２０】
この結果、対象Ｇプールページのデータがキャッシュヒットする場合（ステップＳ４１：Ｙｅｓ）には、グローバルプール制御部１４１は、自ノード１０１が、処理依頼に対応する当初のコマンドの発行元のホスト部１０２（発行元ホスト部）と同一のノード１０１であるか否かを判定する（ステップＳ４２）。なお、当初のコマンドの発行元のホスト部１０２のノード１０１の情報については、処理依頼に含まれている。
【０１２１】
この結果、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１である場合（ステップＳ４２：Ｙｅｓ）には、グローバルプール制御部１４１は、処理依頼元のホストパス制御部１２０に、キャッシュされているデータを送信し（ステップＳ４３）、リード時転送処理を終了する。
【０１２２】
一方、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合（ステップＳ４２：Ｎｏ）には、グローバルプール制御部１４１は、発行元ホスト１０２のノード１０１と、対象Ｇプールページに対応するＬプールページのオーナのノード１０１とが同じノード１０１であるか否かを判定する（ステップＳ４４）。
【０１２３】
この結果、発行元ホスト１０２のノード１０１と、対象Ｇプールページに対応するＬプールページのオーナのノード１０１とが同じノード１０１である場合（ステップＳ４４：Ｙｅｓ）には、グローバルプール制御部１４１は、Ｌプールページのオーナのノード１０１のローカルプール制御部１５０に、処理依頼元のホストパス制御部１２１へのデータ送信を依頼する（ステップＳ４５）。なお、この依頼を受けたローカルプール制御部１５０は、グローバルプール制御部１４１を介さずに、同一のノード１０１内における通信（ノード内通信）により、処理依頼元のホストパス制御部１２１に対象データを送信することとなる。これにより、対象データを別のノード１０１のグローバルプール制御部１４１に送信する必要がなく、ノード１０１間のデータ送信の回数を低減することができる。
【０１２４】
次いで、グローバルプール制御部１４１は、Ｌプールページのオーナのノード１０１のローカルプール制御部１５０からの処理結果を待ち（ステップＳ４６）、処理結果を受け取った後に処理を終了する。
【０１２５】
一方、発行元ホスト１０２のノード１０１と、対象Ｇプールページに対応するＬプールページのオーナのノード１０１とが同じノード１０１でない場合（ステップＳ４４：Ｎｏ）には、グローバルプール制御部１４１は、キャッシュされているデータを処理依頼元のホストパス制御部１２１に送信するか、又は、グローバルプール制御部１４１は、Ｌプールページのオーナのノード１０１のローカルプール制御部１５０に、処理依頼元のホストパス制御部１２１へのデータ送信を依頼し（ステップＳ４７）、処理を終了する。なお、キャッシュされているデータを処理依頼元のホストパス制御部１２１に送信するか、ローカルプール制御部１５０に、処理依頼元のホストパス制御部１２１へのデータ送信を依頼するかは、通信時間の短いほうに決定してもよい。
【０１２６】
一方、対象Ｇプールページのデータがキャッシュヒットしない場合（ステップＳ４１：Ｎｏ）には、グローバルプール制御部１４１は、リードキャッシュミス時処理（図１７参照）を実行し（ステップＳ４８）、処理を終了する。
【０１２７】
次に、リードキャッシュミス時処理（図１６のステップＳ４８）について説明する。
【０１２８】
図１７は、一実施形態に係るリードキャッシュミス時処理のフローチャートである。
【０１２９】
グローバルプール制御部１４１は、発行元ホスト１０２のノード１０１と、対象Ｇプールページに対応するＬプールページのオーナのノード１０１とが同じノード１０１であるか否かを判定する（ステップＳ５１）。
【０１３０】
この結果、発行元ホスト１０２のノード１０１と、対象Ｇプールページに対応するＬプールページのオーナのノード１０１と、が同じノード１０１である場合（ステップＳ５１：Ｙｅｓ）には、グローバルプール制御部１４１は、Ｌプールページのオーナのノード１０１のローカルプール制御部１５０に、処理依頼元のホストパス制御部１２１へのデータ送信を依頼する（ステップＳ５２）。なお、この依頼を受けたローカルプール制御部１５０は、グローバルプール制御部１４１を介さずに、同一のノード１０１内における通信（ノード内通信）により、処理依頼元のホストパス制御部１２１に対象データを送信することとなる。これにより、リードデータを別のノード１０１のグローバルプール制御部１４１に送信する必要がなく、ノード１０１間のデータ送信の回数を低減することができる。
【０１３１】
次いで、グローバルプール制御部１４１は、Ｌプールページのオーナのノード１０１のローカルプール制御部１５０からの処理結果を待ち（ステップＳ５３）、処理結果を受け取った後に処理を終了する。
【０１３２】
一方、発行元ホスト１０２のノード１０１と、対象Ｇプールページに対応するＬプールページのオーナのノード１０１とが同じノード１０１でない場合（ステップＳ５１：Ｎｏ）には、グローバルプール制御部１４１は、対象データをキャッシュするか否かを判定する（ステップＳ５４）。対象データをキャッシュするか否かは、例えば、対象領域のアクセスに関する統計情報（アクセスパターンや、リソース使用量等）に基づいて決定してもよい。
【０１３３】
この結果、対象データをキャッシュすると判定した場合（ステップＳ５４：Ｙｅｓ）には、グローバルプール制御部１４１は、対象データのキャッシュ登録を実行するとともにホストパス制御部１２１への対象データの送信を行い（ステップＳ５５）、処理を終了する。
【０１３４】
具体的には、例えば、このグローバルプール制御部１４１と、対象データの領域のオーナのノードのローカルプール制御部１５０とが、同一のノード１０１である場合には、グローバルプール制御部１４１は、ローカルプール制御部１５０に対象データを要求し、ノード内通信によりローカルプール制御部１５０から対象データを取得し、メモリにキャッシュデータとして格納する。また、グローバルプール制御部１４１は、キャッシュしたデータをホストパス制御部１０２に送信するか、又はローカルプール制御部１５０に対象データをホストパス制御部１０２へ送信させる。なお、キャッシュの登録と、ホストパス制御部１２１へのデータ送信とは、並列に実行可能であれば、並列で行ってもよい。一方、このグローバルプール制御部１４１と、対象データの領域のオーナのノードのローカルプール制御部１５０とが、同一のノード１０１でない場合には、グローバルプール制御部１４１は、ローカルプール制御部１５０に対象データを要求し、ノード間通信によりローカルプール制御部１５０から対象データを取得し、メモリにキャッシュデータとして格納する。また、グローバルプール制御部１４１は、キャッシュしたデータをホストパス制御部１０２に送信するか、又はローカルプール制御部１５０に対象データをホストパス制御部１０２へ送信させる。
【０１３５】
一方、対象データをキャッシュしないと判定した場合（ステップＳ５４：Ｎｏ）には、グローバルプール制御部１４１は、ローカルプール制御部１５０に対象データをホストパス制御部１２１に送信するように依頼する（ステップＳ５６）。ここで、送信の依頼には、ホストパス制御部１２１のノード１１１の情報が含まれている。この依頼を受けると、ローカルプール制御部１５０は、対象データをドライブ１１２から取り出して、ホストパス制御部１２１に送信する。これにより、対象データをグローバルプール制御部１４１に送信する必要がなく、データ送信の回数を低減することができる。
【０１３６】
次いで、グローバルプール制御部１４１は、Ｌプールページのオーナのノード１０１のローカルプール制御部１５０からの処理結果を待ち（ステップＳ５７）、処理結果を受け取った後に処理を終了する。
【０１３７】
次に、ライト時転送処理（図１５のステップＳ３６）について説明する。
【０１３８】
図１８は、一実施形態に係るライト時転送処理のフローチャートである。
【０１３９】
グローバルプール制御部１４１は、グローバルプール管理テーブル２０５を参照し、コマンドのライト対象のグローバルページ（対象領域）の保護設定の種類を特定する（ステップＳ６１）。
【０１４０】
この結果、対象領域の保護設定が、Ｍｉｒｒｏｒｉｎｇである場合（ステップＳ６１：Ｍｉｒｒｏｒｉｎｇ）には、グローバルプール制御部１４１は、転送処理（Ｗｒｉｔｅ  Ｍｉｒｒｏｒｉｎｇ）（図１９参照）を実行し（ステップＳ６２）、処理を終了する。なお、対象領域の保護設定として、保護なしの設定（すなわち、ノード間データ保護をしない設定）ができる場合においては、保護設定が保護なしの設定である場合には、Ｍｉｒｒｏｒｉｎｇである場合と同様な流れで処理を行うようにすればよい。なお、ノード間データ保護をしない設定における処理と、Ｍｉｒｒｏｒｉｎｇである場合における処理との違いについては、後述する。
【０１４１】
一方、対象領域の保護設定が、Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇである場合（ステップＳ６１：Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）には、グローバルプール制御部１４１は、対象領域は、ストライプのデータ部の一部分であるか否かを判定する（ステップＳ６３）。
【０１４２】
この結果、対象領域が、ストライプのデータ部の一部分である場合（ステップＳ６３：Ｙｅｓ）には、グローバルプール制御部１４１は、転送処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）（図２１参照）を実行し（ステップＳ６４）、処理を終了する。
【０１４３】
一方、対象領域が、ストライプのデータ部の一部分でない、すなわち、ストライプのデータ部の全体（フルストライプ）である場合（ステップＳ６３：Ｎｏ）には、グローバルプール制御部１４１は、転送処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ  フルストライプ）（図２４参照）を実行し（ステップＳ６５）、処理を終了する。
【０１４４】
次に、転送処理（Ｗｒｉｔｅ  Ｍｉｒｒｏｒｉｎｇ）（図１８のステップＳ６２）について説明する。
【０１４５】
図１９は、一実施形態に係る転送処理（Ｗｒｉｔｅ  Ｍｉｒｒｏｒｉｎｇ）のフローチャートである。
【０１４６】
グローバルプール制御部１４１は、処理依頼におけるコマンドのライト対象の対象Ｇプールページのデータがキャッシュヒットするか否か、すなわち、自ノード１０１に対象Ｇプールページのデータがキャッシュされているか否かを判定する（ステップＳ７１）。
【０１４７】
この結果、対象Ｇプールページのデータがキャッシュヒットする場合（ステップＳ７１：Ｙｅｓ）には、グローバルプール制御部１４１は、自ノード１０１が、処理依頼に対応する当初のコマンドの発行元のホスト部１０２（発行元ホスト部）と同一のノード１０１であるか否かを判定する（ステップＳ７２）。
【０１４８】
この結果、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１である場合（ステップＳ７２：Ｙｅｓ）には、グローバルプール制御部１４１は、処理をステップＳ７５に進める。
【０１４９】
一方、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合（ステップＳ７２：Ｎｏ）には、グローバルプール制御部１４１は、発行元ホスト部１０２のノード１０１のホストパス制御部１２１に、自ノード１０１（グルーバルプール制御部１４１）へのデータ送信を依頼する（ステップＳ７３）。
【０１５０】
次いで、グローバルプール制御部１４１は、ホストパス制御部１２１からの処理結果を待ち（ステップＳ７４）、処理結果を受け取った後に処理をステップＳ７５に進める。
【０１５１】
ステップＳ７５では、グローバルプール制御部１４１は、キャッシュされているＧプールページのデータをメモリ上のデータ又はステップＳ７４で取得された対象データにより更新する。
【０１５２】
次いで、グローバルプール制御部１４１は、自ノード１０１が、発行元ホスト部と同一のノード１０１であるか否かを判定する（ステップＳ７６）。
【０１５３】
この結果、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１である場合（ステップＳ７６：Ｙｅｓ）には、グローバルプール制御部１４１は、対象データを、ライト対象のＧプールページに対応するＬプールページのオーナのノード１０１のローカルプール制御部１５０に送信し（ステップＳ７７）、処理をステップＳ７９に進める。ここで、保護設定がＭｉｒｒｏｒｉｎｇである場合には、ライト対象のＧプールページに対応するＬプールページのオーナのノード１０１は、複数であり、複数のノード１０１に同一のデータを送信するのに対して、保護設定が保護なしである場合には、ライト対象のＧプールページに対応するＬプールページのオーナのノード１０１は、１つ又は複数であり、複数である場合には、複数のノード１０１に対しては異なるデータを送信する。
【０１５４】
一方、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合（ステップＳ７６：Ｎｏ）には、グローバルプール制御部１４１は、発行元ホスト部１０２のノード１０１のホストパス制御部１２１に、対象Ｇプールページに対応するＬプールページのオーナのノード１０１のローカルプール制御部１５０への対象データの送信を依頼し（ステップＳ７８）、処理をステップＳ７９に進める。ここで、保護設定がＭｉｒｒｏｒｉｎｇである場合には、対象Ｇプールページに対応するＬプールページのオーナのノード１０１は、複数であり、複数のノード１０１に同一のデータを送信するのに対して、保護設定が保護なしである場合には、対象Ｇプールページに対応するＬプールページのオーナのノード１０１は、１つ又は複数であり、複数である場合には、複数のノード１０１に対しては異なるデータを送信する。
【０１５５】
次いで、グローバルプール制御部１４１は、ローカルプールページライト処理（図２８参照）を実行し（ステップＳ７９）、処理を終了する。
【０１５６】
一方、対象Ｇプールページのデータがキャッシュヒットしない場合（ステップＳ７１：Ｎｏ）には、グローバルプール制御部１４１は、キャッシュミス時処理（Ｗｒｉｔｅ  Ｍｉｒｒｏｒｉｎｇ）（図２０参照）を実行し（ステップＳ８０）、処理を終了する。
【０１５７】
なお、転送処理（Ｗｒｉｔｅ  Ｍｉｒｒｏｒｉｎｇ）では、ステップＳ７２〜Ｓ７５に示すように、キャッシュがヒットした場合に、新しいデータでキャッシュを更新するようにしていたが、例えば、対象領域の統計情報やシステム状態によっては、キャッシュを更新せずに、キャッシュを無効化してもよい。
【０１５８】
次に、キャッシュミス時処理（Ｗｒｉｔｅ  Ｍｉｒｒｏｒｉｎｇ）（図１９のステップＳ８０）について説明する。
【０１５９】
図２０は、一実施形態に係るキャッシュミス時処理（Ｗｒｉｔｅ  Ｍｉｒｒｏｒｉｎｇ）のフローチャートである。
【０１６０】
グローバルプール制御部１４１は、発行元ホスト部１０２のノード１０１のホストパス制御部１２１に、対象Ｇプールページに対応するＬプールページのオーナのノード１０１のローカルプール制御部１５０への対象データの送信を依頼し（ステップＳ８１）、グローバルプール制御部１４１は、ローカルプールページライト処理（図２８参照）を実行する（ステップＳ８２）。ここで、ステップＳ８１では、保護設定がＭｉｒｒｏｒｉｎｇである場合には、対象Ｇプールページに対応するＬプールページのオーナのノード１０１は、複数であり、これらノード１０１に同一のデータを送信するに対して、保護設定が保護なしである場合には、対象Ｇプールページに対応するＬプールページのオーナのノード１０１は、１つ又は複数であり、複数である場合には、複数のノード１０１に対しては異なるデータを送信する。
【０１６１】
次いで、グローバルプール制御部１４１は、対象データをキャッシュするか否かを判定する（ステップＳ８３）。対象データをキャッシュするか否かは、例えば、対象領域のアクセスに関する統計情報（アクセスパターンや、リソース使用量等）に基づいて決定してもよい。
【０１６２】
この結果、対象データをキャッシュしないと判定した場合（ステップＳ８３：Ｎｏ）には、グローバルプール制御部１４１は、処理を終了する。
【０１６３】
一方、対象データをキャッシュすると判定した場合（ステップＳ８３：Ｙｅｓ）には、グローバルプール制御部１４１は、自ノード１０１が、発行元ホスト部と同一のノード１０１であるか否かを判定する（ステップＳ８４）。
【０１６４】
この結果、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１である場合（ステップＳ８４：Ｙｅｓ）には、グローバルプール制御部１４１は、処理をステップＳ８７に進める。
【０１６５】
一方、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合（ステップＳ８４：Ｎｏ）には、グローバルプール制御部１４１は、発行元ホスト部１０２のノード１０１のホストパス制御部１２１に、自ノード１０１（グルーバルプール制御部１４１）へのデータ送信を依頼する（ステップＳ８５）。
【０１６６】
次いで、グローバルプール制御部１４１は、ホストパス制御部１２１からの処理結果を待ち（ステップＳ８６）、処理結果を受け取った後に処理をステップＳ８７に進める。
【０１６７】
ステップＳ８７では、グローバルプール制御部１４１は、キャッシュされているＧプールページのデータを、メモリ上又はステップＳ８６で取得されたライト対象のデータにより更新し、処理を終了する。
【０１６８】
次に、転送処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）（図１８のステップＳ６４）について説明する。
【０１６９】
図２１は、一実施形態に係る転送処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）のフローチャートである。
【０１７０】
グローバルプール制御部１４１は、処理依頼におけるコマンドのライトの対象の対象Ｇプールページのデータがキャッシュヒットするか否か、すなわち、自ノード１０１に対象Ｇプールページのデータがキャッシュされているか否かを判定する（ステップＳ９１）。
【０１７１】
この結果、対象Ｇプールページのデータがキャッシュヒットする場合（ステップＳ９１：Ｙｅｓ）には、グローバルプール制御部１４１は、自ノード１０１が、発行元ホスト部１０２と同一のノード１０１であるか否かを判定する（ステップＳ９２）。
【０１７２】
この結果、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１である場合（ステップＳ９２：Ｙｅｓ）には、グローバルプール制御部１４１は、処理をステップＳ９５に進める。
【０１７３】
一方、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合（ステップＳ９２：Ｎｏ）には、グローバルプール制御部１４１は、発行元ホスト部１０２のノード１０１のホストパス制御部１２１に、自ノード１０１（グルーバルプール制御部１４１）へのデータ送信を依頼する（ステップＳ９３）。
【０１７４】
次いで、グローバルプール制御部１４１は、ホストパス制御部１２１からの処理結果を待ち（ステップＳ９４）、処理結果を受け取った後に処理をステップＳ９５に進める。
【０１７５】
ステップＳ９５では、グローバルプール制御部１４１は、キャッシュされている更新前のＧプールページのデータ部（旧データ部）と、新たに受け取ったＧプールページのデータ部（新データ部）とに基づいて、更新後のパリティ部（新パリティ部）を求めるために使用するデータ（中間データ）を生成する。なお、旧データ部と新データ部とで、新パリティ部を求めるための中間データを生成する方法としては、例えば、旧データ部と新データ部とのデータの差分（ＸＯＲ）を取る方法を用いることができる。
【０１７６】
次いで、グローバルプール制御部１４１は、キャッシュされているＧプールページのデータを、メモリ上又はステップＳ９４で取得された対象データにより更新する（ステップＳ９６）。
【０１７７】
次いで、グローバルプール制御部１４１は、対象Ｇプールページのパリティ部に対応するＬプールページのオーナのノード１０１のローカルプール制御部１５０に、中間データを送信し（ステップＳ９７）、対象Ｇプールページのデータ部に対応するＬプールページのオーナのノード１０１のローカルプール制御部１５０に、データ部のデータを送信する（ステップＳ９８）。なお、ステップＳ９７及びＳ９８の処理は、並行して行ってもよい。
【０１７８】
次いで、グローバルプール制御部１４１は、ローカルプールページライト処理（図２８参照）を実行し（ステップＳ９９）、処理を終了する。
【０１７９】
一方、対象Ｇプールページのデータがキャッシュヒットしない場合（ステップＳ９１：Ｎｏ）には、グローバルプール制御部１４１は、キャッシュミス時処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）（図２２参照）を実行し（ステップＳ１００）、処理を終了する。
【０１８０】
次に、キャッシュミス時処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）（図２１のステップＳ１００）について説明する。
【０１８１】
図２２は、一実施形態に係るキャッシュミス時処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）のフローチャートである。
【０１８２】
グローバルプール制御部１４１は、発行元ホスト部１０２と、対象Ｇプールページのデータ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１であるか否かを判定する（ステップＳ１０１）。
【０１８３】
この結果、発行元ホスト部１０２と、対象Ｇプールページのデータ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１である場合（ステップＳ１０１：Ｙｅｓ）には、グローバルプール制御部１４１は、自ノード１０１が、発行元ホスト部と同一のノード１０１であるか否かを判定する（ステップＳ１０２）。
【０１８４】
この結果、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１である場合（ステップＳ１０２：Ｙｅｓ）には、グローバルプール制御部１４１は、ローカルプール制御部１５０から更新前のＧプールページに対応するデータ部（旧データ部）を取得し、ホストパス制御部１２１から新たに受け取ったＧプールページのデータ部（新データ部）を取得し、旧データ部と新データ部とに基づいて、更新後のパリティ部（新パリティ部）を求めるために使用するデータ（中間データ）を生成する（ステップＳ１０３）。
【０１８５】
次いで、グローバルプール制御部１４１は、対象Ｇプールページのパリティ部に対応するＬプールページのオーナのノード１０１のローカルプール制御部１５０に、中間データを送信し（ステップＳ１０４）、処理をステップＳ１０６に進める。
【０１８６】
一方、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合（ステップＳ１０２：Ｎｏ）には、グローバルプール制御部１４１は、ホストパス制御部１２１に、ローカルプール制御部１５０から旧データ部を取得し、新データ部と旧データ部とで中間データを生成し、生成した中間データを対象Ｇプールページに対応するパリティ部のＬプールページのオーナのノード１０１のローカルプール制御部１５０に送信するように依頼し（ステップＳ１０５）、処理をステップＳ１０６に進める。
【０１８７】
ステップＳ１０６では、グローバルプール制御部１４１は、ホストパス制御部１２１に、対象Ｇプールページに対応するデータ部のＬプールページのオーナのノード１０１のローカルプール制御部１５０に、Ｇプールページの新データ部のデータを送信する。
【０１８８】
次いで、グローバルプール制御部１４１は、ローカルプールページライト処理（図２８参照）を実行し（ステップＳ１０７）、処理を終了する。
【０１８９】
一方、発行元ホスト部と、ライト対象のＧプールページのデータ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１でない場合（ステップＳ１０１：Ｎｏ）には、グローバルプール制御部１４１は、キャッシュミス時リモート処理（図２３参照）を実行し（ステップＳ１０８）、処理を終了する。
【０１９０】
なお、上記キャッシュミス時処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ）において、ステップＳ１０２〜Ｓ１０５と、ステップＳ１０６との処理は、並行して行ってもよい。
【０１９１】
次に、キャッシュミス時リモート処理（図２２のステップＳ１０８）について説明する。
【０１９２】
図２３は、一実施形態に係るキャッシュミス時リモート処理のフローチャートである。
【０１９３】
グローバルプール制御部１４１は、自ノード１０１と、対象Ｇプールページのデータ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１であるか否かを判定する（ステップＳ１１１）。
【０１９４】
この結果、グローバルプール制御部１４１の自ノード１０１と、対象Ｇプールページのデータ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１である場合（ステップＳ１１１：Ｙｅｓ）には、グローバルプール制御部１４１は、ホストパス制御部１２１からライト対象のデータ部（新データ部）を取得し、Ｇプールページのデータ部に対応するＬプールページのオーナのノード１０１のローカルプール制御部１５０から更新前のＧプールページに対応するデータ部（旧データ部）を取得し（ステップＳ１１２）、新データ部と旧データ部とに基づいて、中間データを生成する（ステップＳ１１３）。
【０１９５】
次いで、グローバルプール制御部１４１は、対象Ｇプールページのパリティ部に対応するＬプールページのオーナのノード１０１のローカルプール制御部１５０に中間データを送信し（ステップＳ１１４）、処理をステップＳ１１６に進める。
【０１９６】
一方、グローバルプール制御部１４１の自ノード１０１と、対象Ｇプールページのデータ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１でない場合（ステップＳ１１１：Ｎｏ）には、グローバルプール制御部１４１は、ホストパス制御部１２１に、Ｌプールページのデータ部のオーナのノード１０１のローカルプール制御部１５０に新データ部を送信させ、このローカルプール制御部１５０に中間データを生成させ、このローカルプール制御部１５０に生成した中間データをＬプールページのパリティ部のオーナのノード１０１のローカルプール制御部１５０に送信させる依頼を行い（ステップＳ１１５）、処理をステップＳ１１６に進める。
【０１９７】
ステップＳ１１６では、グローバルプール制御部１４１は、ローカルプールページライト処理（図２８参照）を実行する。その後、グローバルプール制御部１４１は、処理を終了する。
【０１９８】
次に、転送処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ  フルストライプ）（図１８のステップＳ６５）について説明する。
【０１９９】
図２４は、一実施形態に係る転送処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ  フルストライプ）のフローチャートである。
【０２００】
グローバルプール制御部１４１は、対象データをキャッシュするか否かを判定する（ステップＳ１２１）。対象データをキャッシュするか否かは、例えば、対象領域のアクセスに関する統計情報（アクセスパターンや、リソース使用量等）に基づいて決定してもよい。
【０２０１】
この結果、対象データをキャッシュする場合（ステップＳ１２１：Ｙｅｓ）には、グローバルプール制御部１４１は、自ノード１０１が、発行元ホスト部１０２と同一のノード１０１であるか否かを判定する（ステップＳ１２２）。
【０２０２】
この結果、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１である場合（ステップＳ１２２：Ｙｅｓ）には、グローバルプール制御部１４１は、処理をステップＳ１２４に進める。
【０２０３】
一方、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合（ステップＳ１２２：Ｎｏ）には、グローバルプール制御部１４１は、発行元ホスト部１０２のノード１０１のホストパス制御部１２１に、自ノード１０１（グルーバルプール制御部１４１）への対象データの送信を依頼し（ステップＳ１２３）、処理をステップＳ１２４に進める。
【０２０４】
ステップＳ１２４では、グローバルプール制御部１４１は、メモリ上又はステップＳ１２３で取得された対象データをキャッシュする。
【０２０５】
次いで、グローバルプール制御部１４１は、対象Ｇプールページのデータ部ごとに、ループＡの処理（ステップＳ１２４〜Ｓ１２９）を実行する。ここで、ループＡの処理の対象とするデータ部を処理対象データ部ということとする。
【０２０６】
ループＡにおいて、グローバルプール制御部１４１は、自ノード１０１と、処理対象データ部のオーナのノード１０１（ローカルプール制御部１５０）とが同じノード１０１であるか否かを判定する（ステップＳ１２５）。
【０２０７】
この結果、自ノード１０１と、処理対象データ部のオーナのノード１０１（ローカルプール制御部１５０）とが同じノード１０１である場合（ステップＳ１２５：Ｙｅｓ）には、グローバルプール制御部１４１は、キャッシュされている対象データを、処理対象データ部のオーナのノード１０１のローカルプール制御部１５０に送信する（ステップＳ１２６）。
【０２０８】
一方、自ノード１０１と、処理対象データ部のオーナのノード１０１（ローカルプール制御部１５０）とが同じノード１０１でない場合（ステップＳ１２５：Ｎｏ）には、グローバルプール制御部１４１は、発行元ホスト部１０２と、処理対象データ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１であるか否かを判定する（ステップＳ１２７）。
【０２０９】
この結果、発行元ホスト部と、処理対象データ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１である場合（ステップＳ１２７：Ｙｅｓ）には、グローバルプール制御部１４１は、ホストパス制御部１２１に、対象データを処理対象データ部のオーナのノード１０１のローカルプール制御部１５０へ送信する依頼する（ステップＳ１２８）。この場合には、対象データは、ノード内通信で送信されることとなるので、処理効率がよい。
【０２１０】
一方、発行元ホスト部と、処理対象データ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１でない場合（ステップＳ１２７：Ｎｏ）には、グローバルプール制御部１４１は、キャッシュされている対象データを、処理対象データ部のオーナのノード１０１のローカルプール制御部１５０に送信する（ステップＳ１２９）。
【０２１１】
グローバルプール制御部１４１は、対象Ｇプールページのすべてのデータ部を対象にループＡの処理を実行した場合には、ループＡを抜ける。
【０２１２】
次いで、グローバルプール制御部１４１は、自ノード１０１と、対象データに対応するパリティ部（対象パリティ部）のオーナのノード１０１（ローカルプール制御部１５０のあるノード）とが同じノードであるか否かを判定する（ステップＳ１３０）。
【０２１３】
この結果、自ノード１０１と、対象パリティ部のオーナのノード１０１とが同じノード１０１である場合（ステップＳ１３０：Ｙｅｓ）には、グローバルプール制御部１４１は、キャッシュされている対象データに基づいてパリティを作成し、作成したパリティを、対象パリティ部のオーナのノード１０１のローカルプール制御部１５０に送信して格納させ（ステップＳ１３１）、処理をステップＳ１３５に進める。
【０２１４】
一方、自ノード１０１と、対象パリティ部のオーナのノード１０１とが同じノードでない場合（ステップＳ１３０：Ｎｏ）には、グローバルプール制御部１４１は、発行元ホスト部と、対象Ｇプールページのパリティ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１であるか否かを判定する（ステップＳ１３２）。
【０２１５】
この結果、発行元ホスト部と、対象Ｇプールページのパリティ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１である場合（ステップＳ１３２：Ｙｅｓ）には、グローバルプール制御部１４１は、ホストパス制御部１２１に、ホストパス制御部１２１の対象データに基づいてパリティを作成させるとともに、作成したパリティを対象パリティ部のオーナのノード１０１のローカルプール制御部１５０へ送信させる依頼を行い（ステップＳ１３３）、処理をステップＳ１３５に進める。この場合には、生成されたパリティが、ノード内通信で送信されることとなるので、処理効率がよい。
【０２１６】
一方、発行元ホスト部と、対象Ｇプールページのパリティ部に対応するＬプールページのオーナのノード１０１とが同一のノード１０１でない場合（ステップＳ１３２：Ｎｏ）には、グローバルプール制御部１４１は、キャッシュされている対象データに基づいてパリティを作成し、作成したパリティを対象パリティ部のオーナのノード１０１のローカルプール制御部１５０に送信して格納させ（ステップＳ１３４）、処理をステップＳ１３５に進める。
【０２１７】
ステップＳ１３５では、グローバルプール制御部１４１は、ローカルプールページライト処理（図２８参照）を実行する。その後、グローバルプール制御部１４１は、処理を終了する。
【０２１８】
次に、キャッシュミス時処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ  フルストライプ）（図２４のステップＳ１３６）について説明する。
【０２１９】
図２５は、一実施形態に係るキャッシュミス時処理（Ｗｒｉｔｅ  Ｅｒａｓｕｒｅ  Ｃｏｄｉｎｇ  フルストライプ）のフローチャートである。
【０２２０】
グローバルプール制御部１４１は、自ノード１０１が、発行元ホスト部１０２と同一のノード１０１であるか否かを判定する（ステップＳ１４１）。
【０２２１】
この結果、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１である場合（ステップＳ１４１：Ｙｅｓ）には、グローバルプール制御部１４１は、ホストパス制御部１２１から対象データを受け取って、パリティを生成し（ステップＳ１４２）、処理をステップＳ１４４に進める。この処理では、対象データをノード１０１内で取得してパリティを生成できるので処理効率がよい。
【０２２２】
一方、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合（ステップＳ１４１：Ｎｏ）には、グローバルプール制御部１４１は、ホストパス制御部１２１に、対象データに基づいてパリティを作成させる依頼を行い（ステップＳ１４３）、処理をステップＳ１４４に進める。この場合には、対象データをホストパス制御部１２１があるノード内で取得してパリティを生成することができるので、処理効率がよい。
【０２２３】
ステップＳ１４４では、グローバルプール制御部１４１は、対象データをデータ部のオーナのノード１０１のローカルプール制御部１５０に送信する。なお、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合には、グローバルプール制御部１４１は、発行元ホスト部１０２のホストパス制御部１２１に対象データを送信させる。
【０２２４】
次いで、グローバルプール制御部１４１は、生成したパリティをパリティ部のオーナのノード１０１のローカルプール制御部１５０に転送する（ステップＳ１４５）。なお、グローバルプール制御部１４１の自ノード１０１が、発行元ホスト部１０２と同一のノード１０１でない場合には、グローバルプール制御部１４１は、発行元ホスト部１０２のホストパス制御部１２１にパリティを送信させる。
【０２２５】
次いで、グローバルプール制御部１４１は、ローカルプールページライト処理（図２８参照）を実行し（ステップＳ１４６）、処理を終了する。
【０２２６】
次に、ローカルプール制御部の転送処理について説明する。
【０２２７】
図２６は、一実施形態に係るローカルプール制御部の転送処理のフローチャートである。
【０２２８】
ローカルプール制御部１５０の転送処理は、ローカルプール制御部１５０に対してデータ送信の依頼（データ送信依頼）があった場合（ステップＳ４５，Ｓ５２，Ｓ５６，Ｓ１０６等）に実行される処理である。
【０２２９】
ローカルプール制御部１５０は、データ送信依頼を受信すると（ステップＳ１５１）、依頼の対象となる領域（対象領域）の情報を取得する（ステップＳ１５２）。具体的には、ローカルプール制御部１５０は、ローカルプール管理テーブル２０６を参照し、対象領域のＬプールページを特定し、Ｌプールページに対応する対象領域の情報（ドライブ１１２、開始アドレス、サイズ）を取得する。
【０２３０】
次いで、ローカルプール制御部１５０は、対象領域の情報に基づいて、ドライブ１１２から対象データを取得し（ステップＳ１５３）、データ送信依頼に指定された送信先に、取得した対象データを送信する（ステップＳ１５４）。送信先としては、ホストパス制御部１２１やグローバルプール制御部１４１である。
【０２３１】
次いで、ローカルプール制御部１５０は、データ送信依頼に指定された結果返却先に処理結果を返却し（ステップＳ１５５）、処理を終了する。結果返却先としては、基本的には、グローバルプール制御部１４１である。
【０２３２】
このローカルプール制御部１５０の転送処理によると、データ送信依頼に指定された送信先にデータを送信できるとともに、データ送信依頼に指定された結果返却先に対して処理結果を返却することができる。
【０２３３】
次に、ホストパス制御部１２１の転送処理について説明する。
【０２３４】
図２７は、一実施形態に係るホストパス制御部の転送処理のフローチャートである。
【０２３５】
ホストパス制御部１２１の転送処理は、ホストパス制御部１２１に対してデータ送信の依頼（データ送信依頼）があった場合（ステップＳ１，Ｓ７３，Ｓ８１，Ｓ８５，Ｓ９３，Ｓ１０５，Ｓ１２３、Ｓ１２８等）に実行される処理である。
【０２３６】
ホストパス制御部１２１は、データ送信依頼を受信すると（ステップＳ１６１）、メモリから対象データを取得して、データ送信依頼に指定された送信先に送信する（ステップＳ１６２）。送信先としては、ホストパス制御部１２１やグローバルプール制御部１４１である。
【０２３７】
次いで、ホストパス制御部１２１は、データ送信依頼に指定された結果返却先に処理結果を返却し（ステップＳ１６３）、処理を終了する。結果返却先としては、基本的には、グローバルプール制御部１４１である。
【０２３８】
このホストパス制御部１２１の転送処理によると、データ送信依頼に指定された送信先にデータを転送できるとともに、データ送信依頼に指定された結果返却先に対して処理結果を返却することができる。
【０２３９】
次に、ローカルプールページライト処理（ステップＳ７９，Ｓ８２，Ｓ９９，Ｓ１０７，Ｓ１１６，Ｓ１３６，Ｓ１４６）について説明する。
【０２４０】
図２８は、一実施形態に係るローカルプールページライト処理のフローチャートである。
【０２４１】
グローバルプール制御部１４１は、ライト対象のＬプールページのオーナのノード１０１のローカルプール制御部１５０に、ライト対象のＬプールページのデータの更新要求を発行し（ステップＳ１９１）、更新完了の同期待ち、すなわち、ノード間データ保護設定の組を構成する全てのローカルプール制御部１５０からの後述するステップＳ２０６における更新完了が返却を待ち（ステップＳ１９２）、ノード間データ保護設定の組を構成する全てのローカルプール制御部１５０から更新完了が返却されたらローカルプール制御部１５０に更新完了通知を行い（ステップＳ１９３）、処理を終了する。なお、本実施形態では、更新前の状態に戻せるようにデータ管理を行っており、もし、更新完了の同期が得られない場合には、更新前の状態に戻すようになっている。なお、ステップＳ１９１では、保護設定がＭｉｒｒｏｒｉｎｇである場合には、ライト対象のＧプールページに対応するＬプールページのオーナのノード１０１は、複数であるのに対して、保護設定が保護なしである場合には、ライト対象のＧプールページに対応するＬプールページのオーナのノード１０１は、１つ又は複数となる。
【０２４２】
一方、ステップＳ１９１で発行された更新要求の要求先であるライト対象のＬプールページのオーナのノード１０１のローカルプール制御部１５０は、更新要求を受信すると（ステップＳ２０１）、更新要求の対象のデータが中間データであるか否かを判定する（ステップＳ２０２）。
【０２４３】
この結果、更新要求の対象のデータが中間データである場合（ステップＳ２０２：Ｙｅｓ）には、ローカルプール制御部１５０は、ドライブ１１２から旧パリティを取得し（ステップＳ２０３）、中間データと旧パリティとから新パリティを生成し（ステップＳ２０４），処理をステップＳ２０５に進める。
【０２４４】
一方、更新要求の対象のデータが中間データでない場合（ステップＳ２０２：Ｎｏ）には、ローカルプール制御部１５０は、処理をステップＳ２０５に進める。
【０２４５】
ステップＳ２０５では、ローカルプール制御部１５０は、ドライブ１１２の対象領域を受け取ったデータ（新パリティを生成した場合には、新パリティ）により更新する。
【０２４６】
次いで、ローカルプール制御部１５０は、更新要求を行ったグローバルプール制御部１４１に対して更新完了を返却し（ステップＳ２０６）、ステップＳ１９３でのグローバルプール制御部１４１による更新完了の通知を待ち（ステップＳ２０７）、更新完了の通知を受けた場合に、ローカルプール制御部１５０側の処理を終了する。なお、本実施形態では、更新前の状態に戻せるようにデータ管理を行っており、もし、更新完了の通知が得られない場合には、ドライブ１１２を更新前の状態に戻すようになっている。
【０２４７】
次に、ホストパス制御部１２１の中間データ生成処理について説明する。
【０２４８】
図２９は、一実施形態に係るホストパス制御部の中間データ生成処理のフローチャートである。
【０２４９】
ホストパス制御部１２１の中間データ生成処理は、図２２のステップＳ１０５において、中間データの作成の処理の依頼（中間データ作成処理依頼）があった場合に実行される処理である。この処理が実行される場合には、ホストパス制御部１２１のノード１０１と、ライト対象の領域のデータ部のオーナのノード１０１とが同一のノード１０１となっている。
【０２５０】
ホストパス制御部１２１は、中間データ作成処理依頼の依頼を受信すると（ステップＳ２１１）、対象領域の更新前データ（旧データ）を自ノード１０１のローカルプール制御部１５０から取得する（ステップＳ２１２）。このように、更新前データを自ノードから取得できるので、効率がよい。
【０２５１】
次いで、ホストパス制御部１２１は、更新後データをホスト部１０２（又はメモリ１１０）から取得し、更新前データと、更新後データとに基づいて、中間データを生成する（ステップＳ２１３）。
【０２５２】
次いで、ホストパス制御部１２１は、生成した中間データを中間データ作成処理依頼に指定された送信先に送信する（ステップＳ２１４）。送信先としては、ホストパス制御部１２１やグローバルプール制御部１４１である。
【０２５３】
次いで、ホストパス制御部１２１は、中間データ作成処理依頼に指定された結果返却先に処理結果を返却し（ステップＳ２１５）、処理を終了する。結果返却先としては、基本的には、グローバルプール制御部１４１である。
【０２５４】
この中間データ生成処理によると、ホストパス制御部１２１のノード１０１におけるノード内転送により中間データの生成に必要なデータを集めて、中間データを生成することができるので、処理効率がよい。
【０２５５】
次に、ローカルプール制御部１５０の中間データ生成処理について説明する。
【０２５６】
図３０は、一実施形態に係るローカルプール制御部の中間データ生成処理のフローチャートである。
【０２５７】
ローカルプール制御部１５０の中間データ生成処理は、図２３のステップＳ１１５の依頼に起因して、ホストパス制御部１２１から中間データの作成の処理の依頼（中間データ作成処理依頼）があった場合に実行される処理である。この処理が実行される場合には、ローカルプール制御部１５０のノード１０１は、ライト対象の領域のデータ部のオーナのノード１０１と同一となっている。なお、この場合における中間データ作成処理依頼は、対象データ（更新後データ）の送信とともに行われる。
【０２５８】
ローカルプール制御部１５０は、中間データ作成処理依頼を受信すると（ステップＳ２２１）、対象領域の更新後データを受信し、対象領域の更新前データ（旧データ）をドライブ１１２から取得する（ステップＳ２２２）。このように、更新前データを自身でドライブ１１２から取得できるので、効率がよい。
【０２５９】
次いで、ローカルプール制御部１５０は、更新後データと、更新前データとに基づいて、中間データを生成する（ステップＳ２２３）。
【０２６０】
次いで、ローカルプール制御部１５０は、生成した中間データを中間データ作成処理依頼に指定された送信先に送信する（ステップＳ２２４）。送信先としては、ホストパス制御部１２１やグローバルプール制御部１４１である。
【０２６１】
次いで、ローカルプール制御部１５０は、中間データ作成処理依頼に指定された結果返却先に処理結果を返却し（ステップＳ２２５）、処理を終了する。結果返却先としては、基本的には、グローバルプール制御部１４１である。
【０２６２】
この中間データ生成処理によると、ローカルプール制御部１５０のノード１０１におけるノード内転送により中間データの生成に必要なデータを集めて、中間データを生成することができるので、処理効率がよい。
【０２６３】
なお、本発明は、上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。
【０２６４】
例えば、図１７のリードキャッシュミス時処理において、ステップＳ５２及びステップＳ５３の処理のみを実行するようにしてもよい。
【０２６５】
また、上記実施形態において、プロセッサ１１１が行っていた処理の一部又は全部を、ハードウェア回路で行うようにしてもよい。また、上記実施形態におけるプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。
【符号の説明】
【０２６６】
１００…計算機システム、１０１…ノード、１０２…ホスト部、１１０…メモリ、１１１…プロセッサ、１１２…ドライブ、１２１…ホストパス制御部、１３１…ボリューム制御部、１４１…グローバルプール制御部、１５０…ローカルプール制御部
【図１】
2020154990.tif 000003
【図２】
2020154990.tif 000004
【図３】
2020154990.tif 000005
【図４】
2020154990.tif 000006
【図５】
2020154990.tif 000007
【図６】
2020154990.tif 000008
【図７】
2020154990.tif 000009
【図８】
2020154990.tif 000010
【図９】
2020154990.tif 000011
【図１０】
2020154990.tif 000012
【図１１】
2020154990.tif 000013
【図１２】
2020154990.tif 000014
【図１３】
2020154990.tif 000015
【図１４】
2020154990.tif 000016
【図１５】
2020154990.tif 000017
【図１６】
2020154990.tif 000018
【図１７】
2020154990.tif 000019
【図１８】
2020154990.tif 000020
【図１９】
2020154990.tif 000021
【図２０】
2020154990.tif 000022
【図２１】
2020154990.tif 000023
【図２２】
2020154990.tif 000024
【図２３】
2020154990.tif 000025
【図２４】
2020154990.tif 000026
【図２５】
2020154990.tif 000027
【図２６】
2020154990.tif 000028
【図２７】
2020154990.tif 000029
【図２８】
2020154990.tif 000030
【図２９】
2020154990.tif 000031
【図３０】
2020154990.tif 000032