JP2019046180A - 計算機システム、データ管理方法、及びデータ管理プログラム - Google Patents

Abstract

【課題】データの冗長性を比較的容易に保持できるようにする。【解決手段】データを記憶可能な複数のノード１００と、複数のノード１００を管理する管理計算機４１０とを備える計算機システム１０において、第１ノードの第１ボリュームと、第２ノードの第２ボリュームとは、同一のデータを２重化して管理するＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ）ペアとして構成されている。第２ノードのＣＰＵを、第１ノードがオフラインとなった場合において、それ以降に第２ノードの第２ボリュームに対して書き込まれるライトデータを、第２ボリュームに書き込ませるとともに、第１ノード及び第２ノードとは異なる第３ノードの第３ボリュームに書き込ませるように構成する。【選択図】図１

Description

本発明は、データを管理する計算機システム等に関する。

複数の計算機（ノード）を、ストレージ機能を提供するソフトウェアを用いて連携することにより、ストレージシステムを構成するＳＤＳ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｓｔｏｒｅｇｅ）が知られている。

ＳＤＳに関する技術として、異なるノード間でデータの複製を行うことで、データ書き込み処理におけるノード間のデータの冗長化を行い、データ保護を行う手法が知られている（例えば、特許文献１，２，３参照）。

米国特許第８８０６１６１号明細書 米国特許第８２７１４４７号明細書 米国特許第６９０７５４３号明細書

ＳＤＳにおけるクライアントからのデータ書き込み処理は、データを冗長化することで、データ保護を行う。データの冗長化としては、ノード間でデータ転送を実施し、かつノード毎にデータを永続化してから、クライアントへ応答する。

例えば、ソフトウェア・ハードウェアの更新・新規インストールなどのメンテナンス時には、一時的に一方のノードをシャットダウンさせる必要がある。

一方のノードをシャットダウンさせた場合において、他方のノードへ新規書き込みが発生した場合には、他方のノードのみにデータが書き込まれることとなる。このような状態において、他方のノードに障害が発生した場合には、他方のノードのみに書き込まれたデータが消失してしまう、所謂データロスが発生してしまう。

こうしたメンテナンス等によるデータの冗長性の低下を回避するために、メンテナンスを行う前に、メンテナンス対象のノードのデータを、他のノードに完全にコピーし、コピー先のノードを用いてデータの冗長化を実施することが行われている。

しかしながら、メンテナンス対象のノードのデータを他のノードにコピーするようにすると、コピーが完了するまでに多くの時間とリソースとを費やしてしまうこととなる。この結果、ホスト計算機におけるＩ／Ｏの性能（ホストＩＯの性能）を低下させてしまう。特に、多くのノードによりクラスタを構成している場合においては、各ノードをメンテナンスする必要があるが、クラスタを稼動させつつ、１ノードずつメンテナンスする場合は、メンテナンス対象のノードのデータを他のノードにコピーすることを順次実行しなくてはならず、非常に多くの時間（例えば、数週間単位の時間）とリソースを費やしてしまうこととなる。

本発明は、上記事情に鑑みなされたものであり、その目的は、データの冗長性を比較的容易に保持することのできる技術を提供することにある。

上記目的を達成するため、一観点に係る計算機システムは、データを記憶可能な複数のノードと、複数のノードを管理する管理計算機とを備える計算機システムであって、第１ノードの第１ボリュームと、第２ノードの第２ボリュームとは、同一のデータを２重化して管理するＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ）ペアとして構成されており、第２ノードのプロセッサ部は、第１ノードがオフラインとなった場合において、それ以降に第２ノードの前記第２ボリュームに対して書き込まれるライトデータを、第２ボリュームに書き込ませるとともに、第１ノード及び第２ノードとは異なる第３ノードの第３ボリュームに書き込ませる。

本発明によれば、データの冗長性を比較的容易に保持することができる。

図１は、第１実施例に係る計算機システムの全体構成図である。 図２は、第１実施例に係る計算機システムにおけるノードを含む一部の構成図である。 図３は、第１実施例に係るペア管理テーブルの一例の構成図である。 図４は、第１実施例に係るジャーナルログの一例の構成図である。 図５は、第１実施例に係る管理計算機の構成図である。 図６は、第１実施例に係るホストコンピュータによるＨＡペアのボリュームへのアクセスを説明する図である。 図７は、第１実施例に係るノード停止に関わるデータ管理処理を説明する図である。 図８は、第１実施例に係る複数のＨＡペアと、それらに関する回復ボリュームを説明する図である。 図９は、第１実施例に係るノード計画停止処理のフローチャートである。 図１０は、第１実施例に係るボリューム回復処理のフローチャートである。 図１１は、第１実施例に係るホストライトＩＯ処理のフローチャートである。 図１２は、第１実施例に係るネットワーク障害発生時処理のフローチャートである。 図１３は、第２実施例に係るデータ管理処理を説明する図である。 図１４は、第３実施例に係るデータ管理処理を説明する図である。

いくつかの実施例について、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲に係る発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

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

また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のようなマイクロプロセッサである。１以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、以下の説明では、「プログラム」を動作主体として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インタフェースデバイス（例えばポート）を用いながら行うため、処理の主体がプログラムとされてもよい。プログラムを動作主体として説明された処理は、プロセッサ或いはそのプロセッサを有する計算機（例えば、管理計算機、ホスト計算機等）が行う処理としてもよい。

また、プロセッサが行う処理の一部又は全部を、ハードウェア回路で行うようにしてもよい。プロセッサが実行するプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。

また、以下の説明では、「ＲＡＩＤ」は、Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ （ｏｒ Ｉｎｅｘｐｅｎｓｉｖｅ） Ｄｉｓｋｓの略である。ＲＡＩＤグループは、複数の物理デバイス（典型的には同種の物理デバイス）で構成され、そのＲＡＩＤグループに関連付けられたＲＡＩＤレベルに従いデータを記憶する。ＲＡＩＤグループは、パリティグループと呼ばれてもよい。パリティグループは、例えば、パリティを格納するＲＡＩＤグループのことでよい。

また、以下の説明では、要素の識別情報として、ＩＤが使用されるが、それに代えて又は加えて他種の識別情報が使用されてもよい。また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号又は参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用又は参照符号に代えてその要素に割り振られたＩＤを使用することがある。また、以下の説明では、ＩＯ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）要求は、ライト要求又はリード要求であり、アクセス要求と呼ばれてもよい。

まず、第１実施例について説明する。

図１は、第１実施例に係る計算機システムの全体構成図である。

計算機システム１０は、１以上のホストコンピュータ（以下、ホストという）４００と、管理計算機４１０と、複数のノード（計算機）１００（１００ａ、１００ｂ、１００ｃ等）とを備える。なお、計算機システム１０に含まれる複数のノード群をストレージクラスタという。

各ノード１００は、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）３００や、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）３１０、バックエンドＳＡＮ３２０等で接続されている。また、ホスト４００、管理計算機４１０、及びノード１００は、ＳＡＮ３００やＬＡＮ３１０によって接続されている。このような構成により、ノード１００間や、ノード１００とホスト４００との間、ノード１００と管理計算機４１０との間で、制御情報やデータ等が送信される。

次に、ノード１００について詳細に説明する。

図２は、第１実施例に係る計算機システムにおけるノードを含む一部の構成図である。

ノード１００は、ネットワークインタフェース１１０、プロセッサ部の一例としてのＣＰＵ１２０、メモリコントローラ１３０、ディスクコントローラ１４０、ストレージデバイス１５０、外部ストレージインタフェース１６０、入出力インタフェース１７０、内部ネットワークバス１８０、及びメモリ２００を備える。ノード１００は、各構成１１０、１２０、１３０、１４０、１５０、１６０、１７０、１８０、２００のいずれか１つ以上を複数備えるようにしてもよい。なお、以下の説明においては、説明容易にするために、各構成が１つずつ存在している場合を例にする。

ネットワークインタフェース１１０は、ノード１００を、ホスト４００、管理計算機４１０等の他の計算機とネットワーク１１１を介して通信可能に接続するためのインタフェースである。ノード１００は、ネットワークインタフェース１１０を用いて、データや制御情報を、他の計算機とやり取りする。ネットワーク１１１は、例えば、ＳＡＮ３００、ＬＡＮ３１０、インターネットでもよく、専用線でも、公衆回線でもよい。

ＣＰＵ１２０は、１以上のコアから構成されるプロセッサである。ＣＰＵ１２０は、ある決まったタスクを高速かつ効率よく処理するために、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）であってもよい。ＣＰＵ１２０は、メモリ２００に格納された各種プログラムを実行することにより、各種処理を実行する。

メモリコントローラ１３０は、ＣＰＵ１２０からの指示に従って、メモリ２００からのデータ読み取り、または、メモリ２００へのデータの書き込みを行う。

ディスクコントローラ１４０は、ＣＰＵ１２０からの指示に従って、ストレージデバイス１５０からのデータ読み取り、または、ストレージデバイス１５０へのデータの書き込みを行う。

ストレージデバイス１５０は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等のデータを記憶するためのデバイスである。ストレージデバイス１５０は、ユーザデータ、ＯＳ、アプリケーションプログラム、アプリケーションデータ、ディスク管理用メタデータ、ノード１００を運用するために必要なデータ等を格納する。ストレージデバイス１５０は、例えば、複数の物理ディスクを使用して設定された論理デバイスでもよく、ＲＡＩＤによりデータ保護されていてもよい。ストレージデバイス１５０には、例えば、ホスト４００から参照可能なボリュームが格納される。

外部ストレージインタフェース１６０は、ノード１００に接続された、１以上の外部ストレージシステム１９１、ストレージデバイス１９２等の外部ストレージとの間でのデータ転送を行う。ストレージデバイス１９２は、ストレージデバイス１５０と同様な構成としてもよい。ストレージデバイス１９２は、接続されているノード１００で管理するボリュームを格納するようにしてもよい。なお、ストレージデバイス１９２に格納されているボリュームについても、ノード１００に格納されているボリュームということができる。

入出力インタフェース１７０は、ノード１００に接続された入出力デバイス１９４との間の通信を行う。

内部ネットワークバス１８０は、ノード１００の各要素（１１０，１２０，１３０，１４０，１６０，１７０，２００）を通信可能に接続する。

メモリ２００は、例えば、１以上のＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等により構成される。メモリ２００は、各種情報を記憶する。メモリ２００は、ＣＰＵ１２０による処理中のデータや将来的に使用する可能性のあるデータを一時的に格納するキャッシュメモリ２１０を含んでもよい。キャッシュメモリ２１０は、データブロック管理のためのメタデータを一時的に格納してもよいし、ＯＳやアプリケーションプログラムの処理に必要になる情報、ＣＰＵ間の通信に必要な制御情報を格納してもよい。

本実施例では、メモリ２００は、ノードのペア情報を管理する制御情報であるペア管理テーブル２２０を格納する。また、メモリ２００は、ＣＰＵ１２０が実行するプログラムを格納する。本実施例では、メモリ２００は、データ書き込みプログラム７４０、回復ボリューム作成プログラム７８０、再同期プログラム８００、その他の必要なプログラムを格納する。

ノード１００は、汎用的または専用的な目的で使用される計算機又はシステムであり、例えば、ブロックデータストレージシステム、ファイルデータストレージシステム、オブジェクトデータストレージシステム、ユニファイドストレージシステムなどになり得る。

次に、ペア管理テーブル２２０について詳細に説明する。

図３は、第１実施例に係るペア管理テーブルの一例の構成図である。

ペア管理テーブル２２０は、ノード１００によって管理されている各ボリュームについてのペアに関する設定情報と、そのペアの状態とを格納する。ペア管理テーブル２２０は、ボリューム毎に対応するエントリーを格納する。ペア管理テーブル２２０のエントリーは、ボリュームＩＤ２２１と、ＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ）ペア状態２２２と、ＨＡペアボリューム情報２２３と、回復ペア状態２２４と、回復ペアボリューム情報２２５とのフィールドを含む。

ボリュームＩＤ２２１には、エントリーに対応するボリュームの識別情報（ボリュームＩＤ）が格納される。ＨＡペア状態２２２には、エントリーに対応するボリュームのＨＡペアの状態（ＨＡペア状態）が格納される。ここで、ＨＡペアとは、一方のボリュームのノードが停止した場合に、他方のボリュームのノードが引き続きデータを提供できるようにする関係を確保する対象とするボリュームのペアのことをいう。また、ＨＡペア状態としては、ＨＡペアとなるボリューム間で引き続きデータを提供できる状態（すなわち、データが同期している状態）を示す「ＰＡＩＲ」（ペア）と、ＨＡペアの一方が一時的にオフラインとなっている状態を示す「一時的にオフライン」等がある。ＨＡペアボリューム情報２２２には、エントリーに対応するボリュームとＨＡペアを組むボリューム（ＨＡペアボリューム）の識別情報（ＩＤ）が格納される。

回復ペア状態２２４には、エントリーに対応するボリュームと、このボリュームとＨＡペアにあるボリュームを回復させるために利用される回復ボリュームとを含む回復ペアの状態（回復ペア状態）が格納される。ここで、回復ペアとは、エントリーに対応するボリュームと、回復ボリュームとのペアのことをいう。また、回復ペア状態としては、回復ペアとなるボリューム間でデータが同期している状態を示す「ＰＡＩＲ」等がある。回復ペアボリューム情報２２５には、エントリーに対応するボリュームと回復ペアを組む回復ボリュームの識別情報（ＩＤ）が格納される。

次に、ボリュームを回復させるための回復ボリュームに対して格納させるジャーナルログ６００について詳細に説明する。

図４は、第１実施例に係るジャーナルログの一例の構成図である。

ジャーナルログ６００は、固定長のヘッダ６１０と、可変長のボディ６２０とを含む。ヘッダ６１０は、ジャーナルログサイズ６１１と、エントリー数６１２とのフィールドを有する。ジャーナルログサイズ６１１には、ジャーナルログ６００の全体のサイズが格納される。エントリー数６１２には、ボディ６２０に含まれる後述するエントリー６２１の総数が格納される。

ボディ６２０は、１以上のエントリー６２１（６２１ａ，６２１ｂ・・・）を有する。エントリー６２１は、ＬＢＡ６２２と、オフセット６２３と、サイズ６２４と、データ６２５とのフィールドを有する。ＬＢＡ６２２には、更新データ（ライトデータ）を格納したボリューム内の論理ブロックアドレス（ＬＢＡ）が格納される。オフセット６２３には、ＬＢＡにおける更新した場所を示す情報（例えば、先頭からのバイト数）が格納される。サイズ６２４には、更新データのサイズが格納される。データ６２５には、更新データが格納される。データ６２５は、可変長のフィールドである。

次に、管理計算機４１０について詳細に説明する。

図５は、第１実施例に係る管理計算機の構成図である。

管理計算機４１０は、ネットワークインタフェース４１１、プロセッサ部の一例としてのＣＰＵ４１２、メモリコントローラ４１３、ディスクコントローラ４１４、ストレージデバイス４１５、メモリ４１６、入出力インタフェース４１７、及び内部ネットワークバス４１８を備える。

ネットワークインタフェース４１１は、管理計算機４１０を、ホスト４００、ノード１００等の他の計算機と通信可能に接続するためのインタフェースである。

ＣＰＵ４１２は、１以上のコアから構成されるプロセッサである。ＣＰＵ４１２は、メモリ４１６に格納された各種プログラムを実行することにより、各種処理を実行する。

メモリコントローラ４１３は、ＣＰＵ４１２からの指示に従って、メモリ４１３からのデータ読み取り、または、メモリ４１３へのデータの書き込みを行う。

ディスクコントローラ４１４は、ＣＰＵ４１２からの指示に従って、ストレージデバイス４１５からのデータ読み取り、または、ストレージデバイス４１５へのデータの書き込みを行う。

ストレージデバイス４１５は、ＨＤＤやＳＳＤ等のデータを記憶するためのデバイスである。ストレージデバイス４１５は、ＯＳ、アプリケーションプログラム、アプリケーションデータ、その他のデータ等を格納する。

入出力インタフェース４１７は、管理計算機４１０に接続された入出力デバイス４１９との間の通信を行う。

内部ネットワークバス４１８は、管理計算機４１０の各要素（４１１，４１２，４１３，４１４，４１６，４１７）を通信可能に接続する。

メモリ４１６は、例えば、１以上のＤＲＡＭ等により構成される。メモリ４１６は、各種情報を記憶する。メモリ４１６は、計画停止プログラム７００、データ再同期プログラム７２０、その他の必要なプログラムを格納する。

次に、ホスト４００について詳細に説明する。

図６は、第１実施例に係るホストコンピュータによるＨＡペアのボリュームへのアクセスを説明する図である。

ホスト４００は、例えば、ＣＰＵ、メモリ等を備えた一般的な計算機であり、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）や、Ｌｉｎｕｘ（登録商標）等のＯＳ（Ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）４０１や、マルチパスソフトウェア４０２をメモリに格納して実行する。

ホスト４００は、例えば、図６（ａ）に示すように、ノード１００ａのボリューム１５５ａに対して、ＳＡＮ３００を経由するパス３０１ａにより接続されており、また、ノード１００ｂのボリューム１５５ｂに対して、ＳＡＮ３００を経由するパス３０１ｂにより接続されている。

ここで、ノード１００ａのボリューム１５５ａと、ノード１００ｂのボリューム１５５ｂとが、ＨＡペアとして設定されている場合には、ノード１００ａと、ノード１００ｂとは、ホスト４００のマルチパスソフトウェア４０２に対して、ボリューム１５５ａとボリューム１５５ｂとのそれぞれについて、同じボリュームＩＤを返す。この場合には、マルチパスソフトウェア４０２は、パス３０１ａと、パス３０１ｂとに接続されているボリュームに対して同じボリュームＩＤを利用できること判定し、図６（ｂ）に示すように、パス３０１ａと、パス３０１ｂとの２つのパスに仮想ノード１００ｋが接続され、その仮想ノード１００ｋ内に仮想ボリューム１５５ｋがあると想定する。

このようにＨＡペアが設定されている場合には、マルチパスソフトウェア４０２は、仮想ボリューム１５５ｋにアクセスする際に、パス３０１ａ又は、パス３０１ｂを利用する。なお、ノード１００ａのボリューム１５５ａと、ノード１００ｂのボリューム１５５ｂとをＨＡペアと設定している場合には、いずれのボリュームがＰＶＯＬ（Ｐｒｉｍａｒｙ Ｖｏｌｕｍｅ）であるかをノード間で統一できていない問題、所謂スプリットブレイン問題が発生する可能性がある。これに対しては、いずれのボリュームがＰＶＯＬであるか等を管理する所謂クォーラムディスクを、ＨＡペアのボリュームを管理するノード１００ａ、１００ｂと異なるノード１００に設けるようにしてもよい。

次に、ノード停止に関わるデータ管理処理について説明する。

図７は、第１実施例に係るノード停止に関わるデータ管理処理を説明する図である。

ここで、計算機システム１０は、図７（ａ）に示すような初期状態にあるものとする。具体的には、計算機システム１０には、ノード１００ａ、ノード１００ｂ、及びノード１００ｃがあり、ノード１００ａには、ボリューム１５５ａが管理され、ノード１００ｂには、ボリューム１５５ｂが管理され、ボリューム１５５ａと、ボリューム１５５ｂとが、ＨＡペアとして構成されているものとする。なお、ノード１００ｃを、ボリューム１５５ａと、ボリューム１５５ｂとのＨＡペアのクォーラムディスクを保持するノードとして使用してもよい。

図７（ａ）に示す状態においては、ホスト４００は、ＩＯ要求をボリューム１５５ａ又はボリューム１５５ｂに送ることができる。ホスト４００からいずれかのボリュームに対するライト要求があった場合には、ライト要求の対象のライトデータは、ボリューム１５５ａと１５５ｂとの間で同期され、結果として、ボリューム１５５ａと１５５ｂとに冗長化（２重化）されて保持されることとなる。一方、ホスト４００からいずれかのボリュームに対するリード要求があった場合には、リード要求を受信したノードが自身のボリュームからリード対象のデータを読み出して、ホスト４００に送信することとなる。

ここで、ノード１００ａ（第１ノード）を計画停止するときには、図７（ｂ）に示すように、管理計算機４１０の計画停止プログラム７００は、ＨＡペアであるボリューム１５５ａと１５５ｂとを格納しているノード１００ａ及びノード１００ｂ（第２ノード）以外のノード１００ｃ（第３ノード）に、ノード１００ａの動作を再開した場合にボリューム１５５ａを回復するための回復ボリューム１５６ａ（ここでは、ジャーナルログ６００を格納するジャーナルボリューム）を作成し、ボリューム１５５ｂと、回復ボリューム１５６ａとにより、回復ペアを作成する。この場合において、ノード１００ｂのボリューム１５５ｂに対するホスト４００からのライト要求（ホストライトＩＯ）のライトデータは、ボリューム１５５ｂと回復ボリューム１５６ａとにより、二重化される。

図７（ｂ）に示す状態において、ノード１００ｂに障害が発生した場合には、図７（ｃ）に示すように、ホスト４００からノード１００ｂのボリューム１５５ｂに対してアクセスすることができなくなる。

図７（ｃ）に示す状態となった場合には、ノード１００ａの停止を解除した後に、図７（ｄ）に示すように、管理計算機４１０のデータ再同期プログラム７２０は、ノード１００ｃの回復ボリューム１５６ａに格納されたジャーナルログ６００を用いて、ボリューム１５５ａを最新のデータを保持した状態に回復させる。

具体的には、管理計算機４１０のデータ再同期プログラム７２０は、ホスト４００からのＩＯを一時的に止めた状態で、ノード１００ａのボリューム１５５ａと回復ボリューム１５６ａとを再同期ペアに設定する。これにより、ノード１００ｃの再同期プログラム８００が、回復ボリューム１５６ａに格納された全てのジャーナルログ６００を読み、各ジャーナルログ６００の各エントリー６２１のデータを、ボリューム１５５ａにおけるエントリー６２１のＬＢＡ６２２が示す論理ブロックに対して、オフセット６２３が示すアドレスをオフセットとして書き出す。これにより、ノード１００ａのボリューム１５５ａは、最新のデータを保持した状態となる。

この後、管理計算機４１０のデータ再同期プログラム７２０が、ノード１００ａのボリューム１５５ａに対するホスト４００からのＩＯを再開すると、図７（ｅ）に示すように、ホスト４００は、最新のデータを保持しているボリューム１５５ａに対してＩＯを行うことができるようになる。なお、ボリューム１５５ａを最新のデータに回復させた後においては、回復ボリューム１５６ａのジャーナルログ６００の全てのエントリーを削除するようにしてもよい。

次に、計算機システム１０が３つのノード１００（１００ａ、１００ｂ、１００ｃ）を備え、これらノード１００により管理されている複数のボリュームに対して、複数のＨＡペアを構成している場合における回復ボリュームの作成方法について説明する。

図８は、第１実施例に係る複数のＨＡペアと、それらに関する回復ボリュームを説明する図である。

ここで、計算機システム１０は、図８（ａ）に示すような初期状態にあるものとする。具体的には、計算機システム１０には、ノード１００ａ、ノード１００ｂ、及びノード１００ｃがあり、ノード１００ａには、ボリューム１５５ａ，１５５ｃが保持され、ノード１００ｂには、ボリューム１５５ｂ，１５５ｅが保持され、ノード１００ｃには、ボリューム１５５ｄ，１５５ｆが保持されているものとする。また、ノード１００ａのボリューム１５５ａと、ノード１００ｂのボリューム１５５ｂとが、ＨＡペア（第１ＨＡペア）として構成され、ノード１００ａのボリューム１５５ｃと、ノード１００ｃのボリューム１５５ｄとが、ＨＡペア（第２ＨＡペア）として構成され、ノード１００ｂのボリューム１５５ｅと、ノード１００ｃのボリューム１５５ｆとが、ＨＡペア（第３ＨＡペア）として構成されているものとする。

図８（ａ）に示す状態において、ノード１００ａを停止させる場合には、計算機システム１０は、図８（ｂ）に示すような構成とする。

ノード１００ａを停止させると、第１ＨＡペアと、第２ＨＡペアについては、そのＨＡペアの一方のボリュームが使用できない状態となる。この場合においては、計算機システム１０では、第１ＨＡペアに対しては、ノード１００ｃに回復ボリューム１５６ａが作成され、ボリューム１５５ｂに対するライト要求のジャーナルログ６００が、回復ボリューム１５６ａに格納されることとなる。また、第２ＨＡペアに対しては、ノード１００ｂに回復ボリューム１５６ｂが作成され、ボリューム１５５ｄに対するライト要求のジャーナルログ６００が、回復ボリューム１５６ｂに格納されることとなる。

一方、第３ＨＡペアについては、そのＨＡペアの両方のボリュームがノード１００ａに存在しないので、そのまま利用することができる。なお、第３ＨＡペアに関するクォーラムディスクをノード１００ａに作成している場合においては、ノード１００ａが停止してしまうとクォーラムディスクを利用することができなくなる。この場合においては、スプリットブレイン問題を回避するために、管理計算機４１０の計画停止プログラム７００は、ＨＡペアのいずれか一方のボリュームへのホスト４００からのＩＯを停止させて、ホストからのＩＯを受け付けるボリュームを１つとし、このボリュームを保持するノードが、このボリュームに対するライトデータを、他のボリュームへ同期コピーするようにしてもよい。図８（ｂ）に示す例では、管理計算機４１０は、ボリューム１５５ｆに対するホスト４００からのＩＯを停止し、ノード１００ｂがボリューム１５５ｅに対するホスト４００からのライトデータをボリューム１５５ｆへも書き込むことにより、データを二重化する。

次に、計算機システム１０における処理動作について説明する。

図９は、第１実施例に係るノード計画停止処理のフローチャートである。

ノード計画停止処理は、管理計算機４１０において、ＣＰＵ４１２がメモリ４１６の計画停止プログラム７００を実行することにより実現される処理である。

管理計算機４１０の計画停止プログラム７００は、入力デバイス４１９を介して管理者から計画停止するノード（第１ノード）を指定した計画停止の要求（ノード計画停止要求）を受け付ける（ステップＳ７０１）。

次いで、計画停止プログラム７００は、計画停止の対象となるノードが保持するボリュームであって、データ冗長度の維持が必要なボリュームを決定する（ステップＳ７０２）。具体的には、計画停止プログラム７００は、停止対象の対象となるノード１００に対して、そのノードが保持するボリュームとＨＡペアを構成している全てのボリュームのボリューム情報の要求を送信する。これに対して、ボリューム情報の要求を受けたノード１００は、ペア管理テーブル２２０を参照し、ＨＡペア状態２２２がＰＡＩＲであるエントリーのボリュームＩＤ２２１のボリュームＩＤと、ＨＡペアボリューム情報２２３に格納されているボリューム情報とを特定し、そのボリュームＩＤと、ボリューム情報とを管理計算機４１０の計画停止プログラム７００に送信する。この後、計画停止プログラム７００は、取得したボリュームＩＤと、ボリューム情報とに基づいて、データ冗長度の維持が必要なボリュームを決定する。

なお、管理者がＨＡペアを構成するボリュームのボリュームＩＤを指定することにより、回復ボリュームを作成する対象のボリュームを決定するようにしてもよい。また、管理計算機４１０において、ストレージクラスタを構成する複数のノード１００がそれぞれ保持する最新のペア管理テーブル２２０の情報を予め取得しておき、計画停止プログラム７００は、予め取得している情報に基づいてデータ冗長度の維持が必要なボリュームを決定するようにしてもよい。このようにすると、ノード計画停止処理時において、計画停止対象のノード１００に対して、ボリューム情報を問い合わせる処理を省略することができる。

次いで、計画停止プログラム７００は、予め記憶しているストレージクラスタを構成しているノード１００の情報を参照して、計画停止の対象のノード１００のボリュームを回復するための回復ボリューム１５５を作成するノード１００（第３ノード）を選択する（ステップＳ７０３）。

計画停止プログラム７００は、以下の２つの条件を満たすノード１００を、回復ボリュームを作成するノード（第３ノード）として選択する。
条件１：ノードは、すぐに停止されるノードであってはいけない。
条件２：ノードは、計画停止対象のノードがオフラインの間、データ冗長度の維持が必要なボリュームに関するジャーナルログを格納できるだけの十分な空き容量を持つノードでなくてはならない。

計画停止プログラム７００は、計画停止対象のノード１００内のデータの冗長性が必要な各ボリュームに対して、回復ボリュームを作成するノード１００を選択する。回復ボリュームを作成するノード１００として、冗長性が必要な各ボリュームとＨＡペアを構成するボリュームを保持するノード（第２ノード）と異なるノードが選択される。

次いで、計画停止プログラム７００は、選択されたノード１００へ回復ボリュームの作成を指示する要求（回復ボリューム作成要求）を送る（ステップＳ７０４）。回復ボリューム作成要求を受けたノード１００は、回復ボリュームを作成する。

次いで、計画停止プログラム７００は、データ冗長度の維持が必要なボリュームとＨＡペアを構成するボリュームを保持するノード１００と、回復ボリュームを作成させたノード１００とに対して、これらボリューム間で回復ボリュームペアを組むように指示する要求（回復ボリュームペア要求）を送る（ステップＳ７０５）。回復ボリュームペア要求を受信したそれぞれのノード１００は、回復ボリュームペア要求に対応するボリューム情報を、各ノード１００が持つペア管理テーブル２２０の要求に対応するエントリーの回復ペアボリューム情報２２５に格納する。

次いで、計画停止プログラム７００は、計画停止対象のノード１００と、計画停止対象のノード１００のボリュームとＨＡペアを構成するボリュームを保持するノード１００に対して、これらのボリュームのＨＡペアを停止する要求を送信し、計画停止対象のノード１００には、ＨＡペアを構成するボリュームをオフラインにする要求を送信する（ステップＳ７０６）。

この結果、計画停止対象のノード１００は、自身のキューに格納されている処理中のＩＯ要求をすべて処理し、対象のボリュームをオフラインとし、ペア管理テーブル２２０のそのボリュームに対応するエントリーのＨＡペア状態２２２を一時的にオフラインに設定する。一方、計画停止対象のノード１００のボリュームとＨＡペアを構成するボリュームを保持するノード１００は、ペア管理テーブル２２０のそのボリュームに対応するエントリーのＨＡペア状態２２２を一時的にオフラインに設定する。

次いで、計画停止プログラム７００は、計画停止対象のノード１００に対して、停止要求を送る（ステップＳ７０７）。停止要求を受けたノード１００は、自身の動作を停止し、オフライン状態にする。

以上説明したように、上記したノード計画停止処理によると、データの冗長性が必要な各ボリュームに対応する回復ボリュームを作成でき、その回復ボリュームに対して、データの冗長性が必要な各ボリュームに反映させるべきジャーナルログを格納できるようになる。また、データの冗長性が必要な各ボリュームの全体を他のノードにコピーする必要が無いので、処理時間を低減することができると共に、必要となるリソースを低減することができ、比較的容易にデータの冗長性を保持することができる。

次に、一旦停止させたノード１００のボリュームを最新のデータに回復させるためのボリューム回復処理について説明する。

図１０は、第１実施例に係るボリューム回復処理のフローチャートである。

ボリューム回復処理は、管理計算機４１０において、ＣＰＵ４１２がメモリ４１６のデータ再同期プログラム７２０を実行することにより実現される処理である。ボリューム回復処理は、例えば、或るノード１００の計画停止中に、アクティブとなっているボリュームに障害が発生した場合や、ノード１００の計画停止が終了した場合等に実行される。

管理計算機４１０のデータ再同期プログラム７２０は、計画停止されているノード１００に対して、データの冗長性が必要であり、回復対象となるボリューム（回復対象ボリューム）がホスト４００からのＩＯ要求を受け付けない状態でオンにする要求を送信する（ステップＳ７２１）。この要求を受け取ると、計画停止されているノード１００は、ＩＯ要求を受け付けない状態でのオン状態となる。

次いで、データ再同期プログラム７２０は、オン状態となったノード１００（再開ノード）に対して、回復対象ボリュームと、回復対象ボリュームに対応する回復ボリュームとを再同期ペアとする要求（再同期ペア要求）を送る。再同期ペア要求を受け取った再開ノードは、回復ボリュームを保持するノード１００へ再同期ペア要求を送るとともに、ペア管理テーブル２２０の回復対象ボリュームに対応するエントリーの回復ペア状態２２４に再同期を設定する（ステップＳ７２２）。

次いで、データ再同期プログラム７２０は、再開ノードへ再同期プログラム８００の実行を開始する要求（実行開始要求）を送る（ステップＳ７２３）。実行開始要求を受け取った再開ノードは、再同期プログラム８００の実行を開始する。再同期プログラム８００は、回復対象ボリュームを、回復ボリュームが保持する最新のデータで更新する。これにより、回復対象ボリュームを最新の状態に回復させることができる。

次いで、データ再同期プログラム７２０は、回復対象ボリュームの再同期（最新の状態となること）が完了するまで待つ（ステップＳ７２４）。なお、再開ノードからの再同期に関する完了の応答を非同期で待ってもよく、その間、別の回復対象ボリュームに対する処理を実行してもよい。

回復対象ボリュームの再同期が完了した後に、データ再同期プログラム７２０は、再開ノードへ回復対象ボリュームのホスト４００からのＩＯの受付を許可するようにする要求（ＩＯ受付許可要求）を送る（ステップＳ７２５）。ＩＯ受付許可要求を受け取ると、再開ノードは、回復対象ボリュームを、ホスト４００からのＩＯを受け付け可能な状態とする。この結果、ホスト４００は、パス再スキャンを実行することにより、再開ノードの回復対象ボリュームが利用可能になったことを発見することができ、回復対象ボリュームに対するＩＯ要求を発行できるようになる。

次いで、データ再同期プログラム７２０は、回復ボリュームを保持するノード１００に対して回復ボリュームを削除する要求（回復ボリューム削除要求）を送る。この結果、回復ボリュームを保持するノード１００では、回復ボリュームを削除することができ、使用可能な記憶容量を増加させることができる。なお、回復ボリュームを削除せずに、この回復ボリュームを、他のノード１００を計画停止させる際の回復ボリュームとして利用するようにしてもよい。

以上説明したように、上記したボリューム回復処理によると、再開ノードのボリュームを最新のデータに回復させて、ホスト４００から利用できるようにすることができる。

次に、ノード１００におけるホスト４００からの書き込み要求（ライト要求）があった場合のホストライトＩＯ処理について説明する。

図１１は、第１実施例に係るホストライトＩＯ処理のフローチャートである。

ホストライトＩＯ処理は、ノード１００において、ＣＰＵ１２０がメモリ２００のデータ書き込みプログラム７４０を実行することにより実現される処理である。

データ書き込みプログラム７４０は、ホスト４００からライト要求と、ライト要求の対象のデータ（ライトデータ）を受信すると（ステップＳ７４１）、ライト要求の要求先のボリュームがＰＶＯＬであるかＳＶＯＬ（Ｓｅｃｏｎｄａｒｙ Ｖｏｌｕｍｅ）であるかを判定する（ステップＳ７４２）。

この結果、要求先のボリュームがＳＶＯＬである場合（ステップＳ７４２：ＳＶＯＬ）には、データ書き込みプログラム７４０は、ライト要求先のボリュームとＨＡペアを構成するＰＶＯＬであるボリュームを保持するノード１００に対して、受信したライト要求と、ライトデータとを転送し（ステップＳ７４３）、処理をステップＳ７４１に進める。

一方、要求先のボリュームがＰＶＯＬである場合（ステップＳ７４２：ＰＶＯＬ）には、データ書き込みプログラム７４０は、ライトデータを、要求先のボリュームに書き込む（ステップＳ７４４）。

次いで、データ書き込みプログラム７４０は、ペア管理テーブル２２０の要求先のボリュームに対応するエントリーを参照し、そのエントリーのＨＡペア状態２２２に設定されているＨＡペア状態を確認する（ステップＳ７４５）。

この結果、ＨＡペア状態がペアである場合（ステップＳ７４５：ペア）には、データ書き込みプログラム７４０は、そのエントリーにおけるＨＡペアボリューム情報２２３からＨＡペアとなっているボリューム（ＨＡペアボリューム）を特定し、このボリュームを保持するノードに対して、当該ボリュームへの書き込み要求と、ライトデータを送信し（ステップＳ７４６）、この要求に対する確認応答（ＡＣＫ）を受信した後（ステップＳ７４７）、処理をステップＳ７４８に進める。これにより、ＨＡペアを構成するボリュームのペアに同一データを格納させることができる、すなわち、データを冗長化することができる。

一方、ＨＡペア状態がペア以外である場合（ステップＳ７４５：ペア以外）には、データ書き込みプログラム７４０は、処理をステップＳ７４８に進める。

ステップＳ７４８では、データ書き込みプログラム７４０は、ペア管理テーブル２２０の要求先のボリュームに対応するエントリーの回復ペア状態２２４に格納されている回復ペア状態を確認する。

この結果、回復ペア状態がペアである場合（ステップＳ７４８：ペア）には、データ書き込みプログラム７４０は、そのエントリーにおける回復ペアボリューム情報２２５から回復ペアとなっているボリューム（回復ボリューム）を特定し、この回復ボリュームを保持するノードに対して、当該回復ボリュームへの書き込み要求と、ライトデータを送信する（ステップＳ７４９）。この要求を受け取ったノードでは、そのノードのデータ書き込みプログラム７４０が、書き込み要求に対応する内容（書き込み先のＬＢＡ、オフセット、データサイズ、データ等）をジャーナルログ６００に追加し、要求に対する確認応答（ＡＣＫ）を返すこととなる。要求を送信したノード１００では、確認応答を受信した後（ステップＳ７５０）、処理をステップＳ７５１に進める。これにより、回復ペアを構成する回復ボリュームにライトデータを格納させることができる、すなわち、ライトデータを冗長化することができる。

一方、回復ペア状態がペア以外である場合（ステップＳ７４８：ペア以外）には、データ書き込みプログラム７４０は、処理をステップＳ７５１に進める。

ステップＳ７５１では、データ書き込みプログラム７４０は、ホスト４００からのライト要求が完了したことをホスト４００へ応答する。

次に、ＨＡペアを構成するボリュームを保持するノード１００との間でネットワーク障害が発生した場合におけるネットワーク障害発生時処理を説明する。なお、本例では、ネットワーク障害には、ノード１００との間のネットワーク自体に障害が発生していて通信できない状態だけでなく、ノード１００自体に障害が発生していて通信ができない状態を含んでいる。

図１２は、第１実施例に係るネットワーク障害発生時処理のフローチャートである。

ネットワーク障害発生時処理は、ノード１００において、ＣＰＵ１２０がメモリ２００の回復ボリューム作成プログラム７８０を実行することにより実現される処理である。

回復ボリューム作成プログラム７８０は、ペア管理テーブル２２０を参照し、自身のノード１００で保持するボリュームとＨＡペアを構成するボリュームを保持するノードの中で、通信不可となっているノード１００を検出する（ステップＳ７８１）と、自身のボリュームに対するホスト４００からのＩＯ要求に基づくＩＯ処理を停止する（ステップＳ７８２）。

次いで、回復ボリューム作成プログラム７８０は、ＨＡペアの状態を停止し、ペア管理テーブル２２０のこのボリュームに対応するエントリーのＨＡペア状態２２２に停止を設定する（ステップＳ７８３）。

次いで、回復ボリューム作成プログラム７８０は、通信不可となっているノードのＨＡペアを構成するボリュームを回復するための回復ボリュームを作成するノードを選択する（ステップＳ７８４）。

本実施形態では、この回復ボリュームを作成するノードは、以下のいずれか１つの処理によって決定している。
処理１ 計算機システム１０における全てのオンラインであるノードと通信し、最大の空き容量を持つノードを選択する。
処理２ 計算機システム１０における全てのオンラインであるノードと通信し、十分な空き容量を持ち、かつ、ＩＯワークロードが最も低いノードを選択する。
処理３ 管理計算機４１０と通信し、管理計算機４１０による処理１又は処理２の実行により得られた結果に対応するノードを選択する。

以下、選択されたノード１００を回復用ノードという。

次いで、回復ボリューム作成プログラム７８０は、回復用ノードに対して、回復ボリュームを作成する要求（回復ボリューム作成要求）を送信する（ステップＳ７８５）。回復ボリューム作成要求を受信した回復用ノードでは、回復ボリュームを作成することとなる。

次いで、回復ボリューム作成プログラム７８０は、自身のボリュームと、作成された回復ボリュームとにより回復ペアを作成し、この回復ペアの情報を、ペア管理テーブル２２０のボリュームに対応するエントリーの回復ペアボリューム情報２２５に格納する（ステップＳ７８６）。なお、回復用ノードも、ペア管理テーブル２２０の回復ボリュームに対応するエントリーの回復ペアボリューム情報２２５に、回復ペアの情報を格納する。これにより、これ以降において、ＨＡペアのうちのアクティブなボリュームに対してライトデータが書き込まれた場合に、そのライトデータが適切に回復ボリュームに格納されるようになる。

次いで、回復ボリューム作成プログラム７８０は、ホスト４００からのＩＯ処理を停止しているボリュームに対するＩＯ処理を再開する（ステップＳ７８７）。これにより、このノード１００では、図１１に示すホストライトＩＯ処理が実行されることとなる。

これにより、ＨＡペアを構成するボリュームを保持するノード１００との間でネットワーク障害が発生した場合において、その後においてボリュームに書き込まれるライトデータを適切に冗長化して格納することができる。

次に、第２実施例について説明する。

第２実施例は、第１実施例とは、以下の点が異なっている。第１実施例では、回復ボリュームに対して、ジャーナルログ６００を格納することにより、ライトデータと、ボリュームにおけるライトデータの格納先とを特定可能にしていたが、第２実施例では、回復ボリュームに対してライトデータを格納するとともに、ボリュームにおけるライトデータの格納先を、ボリュームにおける各ページの更新情報を示すビットマップで管理するようにしている。ここで、ページは、例えば、１つの論理ブロックに対応する領域であってもよいし、複数の論理ブロックに対応する領域であってもよい。

次に、第２実施例に係るデータ管理処理を説明する。

図１３は、第２実施例に係るデータ管理処理を説明する図である。

ここで、計算機システム１０は、図１３（ａ）に示すような初期状態にあるものとする。なお、図１３（ａ）の状態は、図７（ａ）の状態と同じである。

ここで、ノード１００ａ（第１ノード）を停止するときには、図１３（ｂ）に示すように、管理計算機４１０の計画停止プログラム７００は、ＨＡペアであるボリューム１５５ａと１５５ｂとを格納しているノード１００ａ及びノード１００ｂ（第２ノード）以外のノード１００ｃ（第３ノード）に、ノード１００ａの動作を再開した場合にボリューム１５５ａを回復するための回復ボリューム１５７ａを作成し、ボリューム１５５ｂと、回復ボリューム１５７ａとにより、回復ペアを作成する。また、管理計算機４１０の計画停止プログラム７００は、ノード１００ｂと、ノード１００ｃとに、ボリューム１５５ｂ、１５７ａの各ページに対するライトデータの更新状態を示すビットマップ１５８ａ、１５８ｂを生成する。

この場合において、ノード１００ｂのボリューム１５５ｂに対するホスト４００からのライト要求（ホストライトＩＯ）のライトデータは、ボリューム１５５ｂと回復ボリューム１５７ａとにより、二重化される。また、ライトデータを格納する際には、ノード１００ｂは、ビットマップ１５８ｂにおけるライトデータを格納したボリューム１５５ｂのページに対応するビットを更新されたことを示す値（例えば“１”）に設定する。同様に、ノード１００ｃは、ビットマップ１５８ａにおけるライトデータを格納した回復ボリューム１５７ａのページに対応するビットを更新されたことを示す値（例えば“１”）に設定する。

図１３（ｂ）に示す状態において、ノード１００ｂに障害が発生した場合には、図１３（ｃ）に示すように、ホスト４００からノード１００ｂのボリューム１５５ｂに対してアクセスすることができなくなる。

図１３（ｃ）に示す状態となった場合には、ノード１００ａの停止を解除した後に、図１３（ｄ）に示すように、管理計算機４１０のデータ再同期プログラム７２０は、ノード１００ｃのビットマップ１５８ａと、回復ボリューム１５７ａとに基づいて、ボリューム１５５ａを最新のデータを保持した状態に回復させる。具体的には、管理計算機４１０のデータ再同期プログラム７２０は、ノード１００ｃのビットマップ１５８ａにおいて更新がされていることを示す値となっている回復ボリューム１５７ａのページを特定し、回復ボリューム１５７ａの特定されたページのデータをボリューム１５５ａの対応するページに格納する。

この後、管理計算機４１０のデータ再同期プログラム７２０が、ノード１００ａのボリューム１５５ａに対するホスト４００からのＩＯを再開すると、図１３（ｅ）に示すように、ホスト４００は、最新のデータを保持しているボリューム１５５ａに対してＩＯを行うことができるようになる。

次に、第３実施例について説明する。

第３実施例は、第１実施例とは以下の点が異なっている。第１実施例では、回復ボリュームに対して、ジャーナルログ６００を格納することにより、ライトデータと、ボリュームにおけるライトデータの格納先とを特定可能にしていたが、第３実施例では、ＨＡペアのボリュームの静止点（ノード１００を静止した時点）からの更新差分をスナップショットボリュームに格納するようにしている。スナップショットボリュームによると、更新された部分とそのデータが特定可能となっている。スナップショットボリュームは、ＨＡペアのボリュームが格納されているノードとは異なるノードに作成される。

次に、第３実施例に係るデータ管理処理を説明する。

図１４は、第３実施例に係るデータ管理処理を説明する図である。

ここで、計算機システム１０は、図１４（ａ）に示すような初期状態にあるものとする。なお、図１４（ａ）の状態は、図７（ａ）の状態と同じである。

ここで、ノード１００ａ（第１ノード）を停止するときには、図１４（ｂ）に示すように、管理計算機４１０の計画停止プログラム７００は、ＨＡペアであるボリューム１５５ａと１５５ｂとを格納しているノード１００ａ及びノード１００ｂ（第２ノード）以外のノード１００ｃ（第３ノード）に、ボリューム１５５ｂに対応するボリューム１６５を作成する。

次に、図１４（ｃ）に示すように、管理計算機４１０の計画停止プログラム７００は、ボリューム１５５ｂを格納しているノード１００ｂにおいて、ボリューム１５５ｂのその時点のスナップショットをとってスナップショットボリューム１６６ａを生成するとともに、ボリューム１６５を格納しているノード１００ｃにおいて、ボリューム１６５のその時点のスナップショットをとってスナップショットボリューム１６６ｂ（第３ボリューム）を生成し、スナップショットボリューム１６６ａと、スナップショットボリューム１６６ｂと、をＴＣ（Ｔｒｕｅ Ｃｏｐｙ）ペアとして構成する。

この場合において、ノード１００ｂは、ボリューム１５５ｂに対するホスト４００からのライト要求（ホストライトＩＯ）のライトデータを、ボリューム１５５ｂに対する格納位置を特定可能にスナップショットボリューム１６６ａに格納する。また、ノード１００ｂは、スナップショットボリューム１６６ａに書き込まれた内容を、スナップショットボリューム１６６ｂにコピーする。これにより、スナップショットボリューム１６６ｂには、ボリューム１５５ｂの格納先を特定可能にライトデータが格納され、ライトデータが二重化される。

図１４（ｄ）に示す状態において、ノード１００ｂに障害が発生した場合には、図１４（ｅ）に示すように、ホスト４００からノード１００ｂのボリューム１５５ｂに対してアクセスすることができなくなる。

図１４（ｅ）に示す状態となった場合には、ノード１００ａの停止を解除した後に、図１４（ｆ）に示すように、管理計算機４１０のデータ再同期プログラム７２０は、スナップショットボリューム１６６ｂの更新差分に基づいて、ボリューム１５５ａを最新のデータを保持した状態に回復させる。具体的には、管理計算機４１０のデータ再同期プログラム７２０は、スナップショットボリューム１６６ａに格納されている更新データを、ボリューム１５５ａの対応する位置に格納する。

この結果、管理計算機４１０のデータ再同期プログラム７２０が、ノード１００ａのボリューム１５５ａに対するホスト４００からのＩＯを再開すると、ホスト４００は、最新のデータを保持しているボリューム１５５ａに対してＩＯを行うことができるようになる。

なお、本発明は、上述の実施例に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。

例えば、上記実施例では、図１２に示すネットワーク障害発生時処理をノード１００が実行するようにして、障害の発生に対して早期に処理を実行できるようにしていたが、本発明はこれに限られず、図１２に示すネットワーク障害発生時処理を、例えば、管理計算機４１０が実行するようにしてもよい。

また、上記第３実施例では、スナップショットボリュームに、第１ノードのオフライン後のＨＡペアのアクティブのボリュームに対するライトデータの更新の内容を格納させるようにしていたが、本発明はこれに限られず、例えば、ノード１００のＣＰＵ１２０は、スナップショットボリュームを通常の使用、すなわち、ＨＡペアのアクティブのボリュームに対して更新が発生した場合に、スナップショットボリュームに、更新領域の更前のデータを格納させるようにしてもよい。この場合には、予め第２ノードのボリュームに対応するサイズのボリューム（回復ボリューム）を第３ノードに生成し、管理計算機４１０のＣＰＵ４１２は、第１ノードのオフライン後のライトデータを、第２ノードの対応するボリュームに格納させるとともに、第３ノードの回復ボリュームに格納させるようにすればよく、このようにすると、スナップショットボリュームの内容から、オフライン後に更新された領域を特定でき、回復ボリュームにおける特定した領域のデータが、第１ノードのオフライン後に更新されたデータとなる。したがって、管理計算機４１０のＣＰＵ４１２又はノード１００のＣＰＵ１２０が、この更新されたデータを第１ノードのボリュームに対して書き込むことにより、第１ノードのボリュームを最新の状態に回復することができる。

また、上記実施例では、ノード１００と、管理計算機４１０とを別の計算機で構成した例を示していたが、本発明はこれに限られず、ノード１００と管理計算機４１０とを一つの計算機で構成するようにしてもよい。

また、上記実施例において、ノード１００のＣＰＵ１２０、管理計算機４１０のＣＰＵ４１２が行っていた処理の一部又は全部を、ハードウェア回路で実現するようにしてもよい。また、上記実施例におけるノード１００や管理計算機４１０で実行される各プログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。

１０…計算機システム、１００，１００ａ，１００ｂ，１００ｃ…ノード、１２０…ＣＰＵ、４００…ホスト、４１０…管理計算機、４１２…ＣＰＵ

Claims (11)

1. データを記憶可能な複数のノードと、前記複数のノードを管理する管理計算機とを備える計算機システムであって、
   第１ノードの第１ボリュームと、第２ノードの第２ボリュームとは、同一のデータを２重化して管理するＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ）ペアとして構成されており、
   前記第２ノードのプロセッサ部は、前記第１ノードがオフラインとなった場合において、それ以降に前記第２ノードの前記第２ボリュームに対して書き込まれるライトデータを、前記第２ボリュームに書き込ませるとともに、前記第１ノード及び第２ノードとは異なる第３ノードの第３ボリュームに書き込ませる
   計算機システム。
2. 前記第２ノードのプロセッサ部は、前記第２ボリュームに対して書き込まれるライトデータをジャーナルログとして前記第３ボリュームに書き込ませる
   請求項１に記載の計算機システム。
3. 前記第２ノードのプロセッサ部は、前記第１ノードがオフラインとなった場合以降における、前記ライトデータを書き込ませた前記第２ボリュームの１以上の領域を識別可能なビットマップを前記第２ノードと、前記第３ノードとに管理する
   請求項１に記載の計算機システム。
4. 前記第２ノードのプロセッサ部は、前記第１ノードがオフラインとなった時点における、前記第２ボリュームの状態を示す第１スナップショットボリュームを前記第２ノードに生成するとともに、前記第３ノードに前記第１スナップショットボリュームに対応する第２スナップショットボリュームを前記第３ボリュームとして作成し、前記第２ボリュームに対するライトデータを、前記第２ボリュームにおける格納位置が特定可能なように前記第１スナップショットボリュームと、前記第２スナップショットボリュームとに書き込ませる
   請求項１に記載の計算機システム。
5. 前記複数のノード又は前記管理計算機のいずれかのプロセッサ部は、
   前記第１ノードがオンラインとなった場合において、前記第３ノードの前記第３ボリュームに書き込まれたライトデータに基づいて、前記第１ノードの前記第１ボリュームが、前記第２ノードの前記第２ボリュームと同一のデータとなるようにデータの書き込みを制御する
   請求項１から請求項４のいずれか一項に記載の計算機システム。
6. 前記複数のノード又は前記管理計算機のいずれかのプロセッサ部は、
   前記第１ノードがオフラインとなったことを検出した場合に、前記第１ノードの前記第１ボリュームと、前記第２ノードの前記第２ボリュームとのＨＡペアの状態を停止し、
   前記第３ボリュームを作成する前記第３ノードを決定し、前記第３ノードに前記第３ボリュームを生成する
   請求項１から請求項５のいずれか一項に記載の計算機システム。
7. 前記管理計算機のいずれかのプロセッサ部は、
   オフラインの対象とする前記第１ノードの指定を受け付け、前記第１ノードの１以上のボリュームのうちのＨＡペアを構成している１以上の前記第１ボリュームを特定し、
   前記１以上の前記第１ボリュームとＨＡペアとなっている１以上の前記第２ボリュームを特定し、
   前記第３ボリュームを生成させる前記第３ノードを決定し、
   前記第３ノードに前記第３ボリュームを生成させ、
   前記第３ボリュームを生成させた以降において、前記第１ノードを停止させる要求を出力する
   請求項１から請求項５のいずれか一項に記載の計算機システム。
8. データを記憶可能な複数のノードと、前記複数のノードを管理する管理計算機とを備える計算機システムによるデータ管理方法であって、
   第１ノードの第１ボリュームと、第２ノードの第２ボリュームとは、同一のデータを２重化して管理するＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｒｉｔｙ）ペアとして構成されており、
   前記第１ノードがオフラインとなった場合において、それ以降に前記第２ノードの前記第２ボリュームに対して書き込まれるライトデータを、前記第２ボリュームに書き込ませるとともに、前記第１ノード及び第２ノードとは異なる第３ノードの第３ボリュームに書き込ませる
   データ管理方法。
9. 前記第１ノードがオンラインとなった場合において、前記第３ノードの前記第３ボリュームに書き込まれたライトデータに基づいて、前記第１ノードの前記第１ボリュームが、前記第２ノードの前記第２ボリュームと同一のデータとなるようにデータを書き込ませる
   請求項８に記載のデータ管理方法。
10. 複数のノードに管理されているボリュームのデータを管理するためのコンピュータに実行させるためのデータ管理プログラムであって、
    前記コンピュータを、
    第１ノードの第１ボリュームと、第２ノードの第２ボリュームとが、同一のデータを２重化して管理するＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ）ペアとして構成されている場合に、前記第１ノードがオフラインとなった場合において、それ以降に前記第２ノードの前記第２ボリュームに対して書き込まれるライトデータを、前記第２ボリュームに書き込ませるとともに、前記第１ノード及び第２ノードとは異なる第３ノードの第３ボリュームに書き込ませるように機能させる
    データ管理プログラム。
11. 前記コンピュータを、
    さらに、前記第１ノードがオンラインとなった場合において、前記第３ノードの前記第３ボリュームに書き込まれたライトデータに基づいて、前記第１ノードの前記第１ボリュームが、前記第２ノードの前記第２ボリュームと同一のデータとなるようにデータを書き込ませるように機能させる
    請求項１０に記載のデータ管理プログラム。