JP2019219954A - クラスタストレージシステム、データ管理制御方法、データ管理制御プログラム - Google Patents

Abstract

【課題】クライアント装置からのデータＩ／Ｏに対するクラスタストレージシステムの可用性を向上できるようにする。【解決手段】複数のノード２０と、クラスタネットワーク１２と、を備えるクラスタストレージシステム２において、それぞれのノード２０は、ボリュームを単位としてデータを格納可能であり、複数のノード２０に格納されている複数のボリュームにより構成されるボリュームグループを複数有し、ノード２０を、クラスタネットワーク１２を介して同一のボリュームグループのボリュームを同期させるように構成する。ノード２０は、クラスタネットワーク１２における通信が分断された場合に、ボリュームの同期が実行不可能となった分断ボリュームグループに属するいずれか１つのボリュームに対するクライアント装置１０からのアクセスを実行可能な状態とする。【選択図】図１

Description

本発明は、データを格納する複数のストレージノードを備えるクラスタストレージシステム等に関する。

一般的なＳｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｓｔｏｒａｇｅ（ＳＤＳ）においては、ノードの追加削除を検出したり、ダウン状態のノードがないかをチェックしたりするための監視機構が備えられている。例えば、代表的なＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）の分散ストレージシステムであるＣｅｐｈの場合では、モニタと呼ばれるコンポーネントがクラスタ全体の監視を行っている。Ｃｅｐｈのストレージは、オブジェクトストレージであり、各データは一定のサイズに分割され、オブジェクトの集まりであるＰｌａｃｅｍｅｎｔ Ｇｒｏｕｐ（ＰＧ）の単位で扱われている。ＰＧは、各ノードの物理デバイスごとにマッピングされたオブジェクトストレージデバイス（ＯＳＤ）のいずれかに割り当てられる。ＰＧの割り当てについてはＣＲＵＳＨという分散アルゴリズムが用いられている。どのオブジェクトがどのＯＳＤに割り当てられているかはＣＲＵＳＨによるハッシュ計算により一意に求めることができ、ＯＳＤへ問い合わせる必要がない。

Ｃｅｐｈでは、ＯＳＤ間のハートビートに一定期間応答がなく、障害があると判断された場合には、モニタが障害を検知する前に、発生したＯＳＤの障害の全ては、ＯＳＤ側からモニタに報告される。モニタは、ＯＳＤの構成の変化に合わせクラスタマップを更新し、各ノードに対して最新の構成情報を配布する。モニタは、耐故障性向上のために、奇数台での冗長化を行うことが推奨されており、ＯＳＤはモニタに最新のクラスタマップを要求し、一定期間応答がなかった場合、異なるモニタと通信することでクラスタマップを取得する。

分散ストレージシステムにおいて、クラスタ間のネットワークが断絶した際に、スプリットブレインが発生することを回避するための代表的な手段としては、第３の地点にｑｕｏｒｕｍを立て、先にロックをとったノードを残し、他方は、ｆａｉｌｏｖｅｒさせるのが一般的である。また、Ｃｅｐｈのようなスケールアウト可能な分散ストレージシステムにおいては、モニタに報告されたＯＳＤの障害情報をもとに、多数派のＯＳＤ群を判断し、少数派となったノードへのＩ／Ｏを停止し、多数派に存在するオブジェクトのレプリカに対してＩ／Ｏを継続する。

例えば、クラスタシステムにおいて、スプリットブレインが発生した際の不要なサービス停止を防ぐ技術として、例えば、特許文献１に記載の技術が知られている。

特開２０１２−１７３９９６号公報

Ｃｅｐｈにおいては、同一オブジェクトを複数生成し、それらを異なるＰＧに配置することでデータの冗長性を確保しているが、例えば、データの冗長度を３にした場合において、ネットワークの分断により、少数派のノード数が冗長度以上となった場合には、多数派のノードへのＩ／Ｏも停止されてしまう。すなわち、クラスタシステム全体におけるＩ／Ｏ処理が停止されてしまう。

本発明は、上記事情に鑑みなされたものであり、その目的は、クライアント装置からのデータＩ／Ｏに対するクラスタストレージシステムの可用性を向上することのできる技術を提供することにある。

上記目的を達成するため、一観点に係るクラスタストレージシステムは、クライアント装置で利用するデータを格納する複数のストレージノードと、クライアント装置とストレージノードとを接続する第１ネットワークと異なる、複数のストレージノードを相互に通信可能に接続する第２ネットワークと、を備えるクラスタストレージシステムであって、それぞれのストレージノードは、ボリュームを単位としてデータを格納可能であり、複数のストレージノードに格納されている複数のボリュームにより構成されるボリュームグループを複数有し、ボリュームグループの各ボリュームを格納する複数のストレージノードは、第２ネットワークを介して同一のボリュームグループのボリュームを同期させる。

本発明によれば、クライアント装置からのデータＩ／Ｏに対するクラスタストレージシステムの可用性を向上することができる。

図１は、一実施形態に係る計算機システムの全体構成図である。 図２は、一実施形態に係るサブクラスタペアを説明する図である。 図３は、一実施形態に係るノード管理表の構成図である。 図４は、一実施形態に係るボリューム管理表の構成図である。 図５は、一実施形態に係るサブクラスタ構成管理表の構成図である。 図６は、一実施形態に係るノード種別認識及びリーダ選出処理のフローチャートである。 図７は、一実施形態に係るノード種別認識及びリーダ選出処理の一例を説明する図である。 図８は、一実施形態に係るノード種別認識及びリーダ選出処理のラダーチャートである。 図９は、一実施形態に係るサブクラスタペアの状態の一例を説明する図である。 図１０は、一実施形態に係るサブクラスタペアＩ／Ｏ制御処理のフローチャートである。 図１１は、一実施形態に係るサブクラスタペアＩ／Ｏ制御処理を含む全体制御処理のラダーチャートである。 図１２は、一実施形態に係る復旧時処理のフローチャートである。 図１３は、一実施形態に係る復旧時処理の一例を説明する図である。 図１４は、一実施形態に係る復旧時処理のラダーチャートである。

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

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

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

計算機システム１は、１以上のクライアント装置（クライアントともいう）１０と、クラスタストレージシステム２とを備える。クライアント装置１０と、クラスタストレージシステム２の各ノード２０とは、例えば、パブリックネットワーク１１（第１ネットワークの一例）を介して接続されている。また、クラスタストレージシステム２の各ノード２０は、クラスタネットワーク１２（第２ネットワークの一例）を介して接続されている。

クライアント装置１０は、クラスタストレージシステム２で管理されるボリュームに対してデータ（ユーザデータ）の入出力（Ｉ／Ｏ）を実行して、各種処理を実行する。

パブリックネットワーク１１は、例えば、インターネット等のパブリックなネットワークである。なお、パブリックネットワーク１１に代えて、パブリックではないネットワークとしてもよい。パブリックネットワーク１１は、例えば、クライアント装置１０からのユーザデータのＩ／Ｏや、ノード２０への管理コマンドの送受信等に利用される。クラスタネットワーク１２は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であるが、ＬＡＮに限らず、他のネットワークとしてもよい。クラスタネットワーク１２は、例えば、サブクラスタペアを構成するノード２０間のハートビートや、サブクラスタペアのノードを変更した際のデータコピー等を行うために使用される。

クラスタストレージシステム２は、複数のノード２０（ストレージノード）を備える。ノード２０は、例えば、物理的な計算機であってもよい。ノード２０は、コントロールプレーン３０と、データプレーン４０とを含む。

コントロールプレーン３０は、複数のノード２０をまたがって構成されている仮想的な単一ストレージシステム（クラスタストレージシステム）を制御する制御部である。コントロールプレーン３０は、ノード２０のハードウェアや、データプレーン４０の動作状態を監視・診断しながら構成を管理する。コントロールプレーン３０は、例えば、仮想計算機（ＶＭ）により構成されてもよく、コンテナにより構成されてもよい。

コントロールプレーン３０は、ノードコントローラ３１と、クラスタコントローラ３２と、コーディネーションサービス部３３と、構成データベース３４とを備える。なお、クラスタコントローラ３２は、各ノード２０において実行可能な機能を有するが、リーダとなるノード２０（リーダノード）のみで機能が活性化される。ノードコントローラ３１と、クラスタコントローラ３２と、コーディネーションサービス部３３とは、ノード２０のプロセッサがメモリに格納されているプログラム（データ管理制御プログラム）を実行することにより構成される。

クラスタコントローラ３２は、各ノード２０のノードコントローラ３１からコーディネーションサービス部３３を介して通知される監視情報を参照し、クラスタストレージシステム２の全体の状態を把握し、各ノード２０のノードコントローラ３１を介して各ノード２０の構成を制御する。また、クラスタコントローラ３２は、構成データベース３４の後述する各管理表３５〜３７について参照・更新等を行う。

ノードコントローラ３１は、各ノード２０に独立して設けられており、自身のノード３０のデータプレーン４０の状態を監視・制御する。例えば、ノードコントローラ３１は、コーディネーションサービス部３３を介して、クラスタコントローラ３２（リーダノードのクラスタコントローラ３２）にノード２０の監視情報を通知する。また、ノードコントローラ３１は、クラスタコントローラ３２の要求に従って、データプレーン４０の構成を設定する。

コーディネーションサービス部３３は、ノード２０をまたがってクラスタストレージシステム２の管理を行う。具体的には、コーディネーションサービス部３３は、ノード２０間の接続状態を監視（生存監視）し、ノードコントローラ３１との間での通知を行う。コーディネーションサービス部３３は、クラスタ構築時、障害発生時、障害復旧時においてリーダノードを決定する処理（リーダ選出処理）を実行する。

構成データベース３４は、クラスタ全体で共有する必要がある構成情報や監視情報を保持し、これらの情報を、他のコンポーネント（他のノード、データプレーン等）がノードをまたがってアクセス可能とする。構成データベース３４は、リーダノードのみで活性化する。なお、構成データベース３４のレプリカを他の複数のノードに格納するようにして冗長性を確保するようにしてもよい。

構成データベース３４は、ノード管理表３５と、ボリューム管理表３６と、サブクラスタ構成管理表３７とを含む。構成データベース３４は、リーダノードのクラスタコントローラ３２から参照・更新される。ノード管理表３５、ボリューム管理表３６、及びサブクラスタ構成管理表３７の詳細な構成については後述する。

データプレーン４０は、ノード２０で管理しているボリュームに格納されているユーザデータのリード／ライト処理（Ｉ／Ｏ処理）の実行を制御する。データプレーン４０は、仮想計算機（ＶＭ）により構成されてもよく、コンテナにより構成されてもよい。

データプレーン４０は、ターゲット機能部４１と、サブクラスタ管理機能部４２と、プロテクション機能部４３と、構成データベースキャッシュ４４と、１以上のボリューム５０とを含む。ターゲット機能部４１と、サブクラスタ管理機能部４２と、プロテクション機能部４３とは、ノード２０のプロセッサがメモリに格納されているプログラム（データ管理制御プログラム）を実行することにより構成される。

ボリューム５０は、ユーザデータを格納する。ボリューム５０は、ノード２０の図示しない物理ストレージデバイスに格納されている。本実施形態では、複数のノード２０のグループ（本実施形態では、２つのノード）で、或るボリューム５０を同期させて管理している。本実施形態では、或るボリューム５０を同期させて管理するノードのグループ（例えば、ペア）をサブクラスタ６０（サブクラスタペア、サブクラスタグループ）という。このサブクラスタ６０のノード２０により同期対象とするボリューム５０のペアを、ボリュームペア（ボリュームグループ）という。

ターゲット機能部４１は、ｉＳＣＳＩやＦＣ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）等のインターフェースにおけるターゲット機能を有する。ターゲット機能部４１は、クライアント装置１０と、サブクラスタペアのボリュームを提供する物理ストレージデバイスとの間でのＳＣＳＩコマンドの転送を行う。本実施形態では、ターゲット機能部４１は、コントロールプレーン３０の構成データベース３４にアクセスせずに、データプレーン４０にキャッシュされた構成データベースキャッシュ４４を参照してデータ転送先のノード２０を決定する。

サブクラスタ管理機能部４２は、シンプロビジョニング、ストレージ階層化、スナップショット、レプリケーション等のサブクラスタ６０に関するデータサービスを制御する。サブクラスタ管理機能部４２は、各データサービスにおける構成情報を、サブクラスタ毎に固有に管理する。なお、サブクラスタ６０を構成するボリュームを格納するノード同士では、このサブクラスタ６０を構成するボリューム５０については、同じ構成情報が管理される。サブクラスタ管理機能部４２は、サブクラスタ６０を構成するノード２０のサブクラスタ管理機能部４２と連携して、コントロールプレーン３０を介さずに、各ノード２０の生存状況をハートビートで確認をする。なお、正常時には、サブクラスタ６０の一方のノード２０のボリューム５０がａｃｔｉｖｅ状態として動作し、他方のノード２０のボリューム５０がｓｔａｎｂｙ状態として動作する。

プロテクション機能部４３は、サブクラスタ管理機能部４２と、物理ストレージデバイスとの間における、ノード２０をまたがったユーザデータの読み書き処理及びユーザデータ保護を行う。本実施形態では、プロテクション機能部４３は、サブクラスタペア間でボリュームのデータを冗長化することにより、ノード障害等が発生した場合におけるボリュームのデータの消失を防止する。プロテクション機能部４３は、構成データベースキャッシュ４４を参照して、データ転送先のノード２０の物理ストレージデバイスを決定する。

構成データベースキャッシュ４４は、構成データベース３４に格納されたノード管理表３５、ボリューム管理表３６、サブクラスタ構成管理表３７のコピーデータを格納する。構成データベースキャッシュ４４に対しては、例えば、クラスタ構築時（データプレーン４０の各コンポーネントのプロセス起動時）、又はノードコントローラ３１から構成要求があった場合に、クラスタコントローラ３２が構成データベース３４を参照して、各ノード２０のノードコントローラ３１経由でコピーデータが格納される。なお。構成データベースキャッシュ４４は、データプレーン４０のコンポーネントが参照できる場所（ノード２０のローカルのシステムメモリ等）に設けてもよい。構成データベースキャッシュ４４のコピーデータは、ノードコントローラ３１からの構成設定指示があるごとに更新される。

図２は、一実施形態に係るサブクラスタペアを説明する図である。

図２に示すクラスタストレージシステム２においては、ノード（Ｎｏｄｅ）＃０とノード＃１とでサブクラスタペア＃１が構成され、ノード＃１とノード＃２とでサブクラスタペア＃２が構成され、ノード＃２とノード＃３とでサブクラスタペア＃３が構成され、ノード＃３とノード＃４とでサブクラスタペア＃４が構成されている。クラスタストレージシステム２が正常時においては、サブクラスタペア＃１のノード＃０とノード＃１とで管理対象のボリューム５０のデータが同期され、サブクラスタペア＃２のノード＃１とノード＃２とで管理対象のボリューム５０のデータが同期され、サブクラスタペア＃３のノード＃２とノード＃３とで管理対象のボリューム５０のデータが同期され、サブクラスタペア＃４のノード＃３とノード＃４とで管理対象のボリューム５０のデータが同期されている。

したがって、サブクラスタペア＃１のボリューム５０のデータは、ノード＃０とノード＃１のいずれかから取得することができ、同様に、サブクラスタペア＃２のボリューム５０のデータは、ノード＃１とノード＃２のいずれかから取得することができ、サブクラスタペア＃３のボリューム５０のデータは、ノード＃２とノード＃３のいずれかから取得することができ、サブクラスタペア＃４のボリューム５０のデータは、ノード＃３とノード＃４のいずれかから取得することができる。

図３は、一実施形態に係るノード管理表の構成図である。

ノード管理表３５は、各ノード２０毎のエントリを格納する。ノード管理表３５の各エントリは、ノードＩＤ３５ａと、クラスタネットワークＩＰアドレス３５ｂと、パブリックネットワークＩＰアドレス３５ｃと、ノード状態３５ｄとのフィールドを含む。

ノードＩＤ３５ａには、エントリに対応するノード２０のＩＤ（識別子）が格納される。クラスタネットワークＩＰアドレス３５ｂには、エントリに対応するノード２０のクラスタネットワーク１２におけるＩＰアドレス（クラスタネットワークＩＰアドレス）が格納される。パブリックネットワークＩＰアドレス３５ｃには、エントリに対応するノード２０のパブリックネットワーク１１におけるＩＰアドレス（パブリックネットワークＩＰアドレス）が格納される。ノード状態３５ｄには、エントリに対応するノード２０の動作状態が格納される。

図４は、一実施形態に係るボリューム管理表の構成図である。

ボリューム管理表３６は、各ボリューム５０毎のエントリを格納する。ボリューム管理表３６のエントリは、ボリュームＩＤ３６ａと、サブクラスタＩＤ３６ｂとのフィールドを含む。ボリュームＩＤ３６ａには、エントリに対応するボリューム５０のＩＤ（ボリュームＩＤ）が格納される。なお、本実施形態では、同一のサブクラスタ６０に属するボリューム５０のボリュームＩＤは同一としている。サブクラスタＩＤ３６ｂには、エントリに対応するボリューム５０が属する（管理される）サブクラスタ６０のＩＤ（サブクラスタＩＤ）が格納される。

図５は、一実施形態に係るサブクラスタ構成管理表の構成図である。

サブクラスタ構成管理表３７は、各サブクラスタ６０の構成に関するエントリを格納する。サブクラスタ構成管理表３７のエントリは、サブクラスタＩＤ３７ａと、プライマリノードＩＤ３７ｂと、セカンダリノードＩＤ３７ｃと、サブクラスタ状態３７ｄとのフィールドを含む。

サブクラスタＩＤ３７ａには、エントリに対応するサブクラスタ６０のＩＤ（サブクラスタＩＤ）が格納される。プライマリノードＩＤ３７ｂには、エントリに対応するサブクラスタ６０におけるプライマリボリューム（正ボリューム）を格納するノードのＩＤ（プライマリノードＩＤ）が格納される。セカンダリノードＩＤ３７ｃには、セカンダリボリューム（副ボリューム）を格納するノードのＩＤ（セカンダリノードＩＤ）が格納される。サブクラスタ状態３７ｄには、サブクラスタ６０の状態（サブクラスタ状態）が格納される。サブクラスタ状態としては、サブクラスタ６０のプライマリノードのボリューム５０と、セカンダリノードのボリューム５０とでと同期がとれていることを示すＡｃｔｉｖｅ、サブクラスタ６０のプライマリノードのボリューム５０はアクセス可能であるが、セカンダリノードのボリューム５０との同期がとれていないことを示すＡｃｔｉｖｅ−Ｄｏｗｎ、サブクラスタ６０のプライマリノードのボリューム５０がアクセス可能でないが、セカンダリノードのボリューム５０がアクセス可能であることを示すＦａｉｌｏｖｅｒ（フェイルオーバー）、サブクラスタ６０の状態を把握することができないことを示すＵｎｋｎｏｗｎがある。

次に、クラスタストレージシステム２の各ノード２０によるノード種別認識及びリーダノード決定処理の動作について説明する。

図６は、一実施形態に係るノード種別認識及びリーダ選出処理のフローチャートである。

ノード種別認識及びリーダ選出処理は、クラスタストレージシステム２を動作させる際に各ノード２０において実行される。

まず、ノード２０のコーディネーションサービス部３３は、他のノード２０のコーディネーションサービス部３３と連携して、クラスタストレージシステム２の各ノード２０の順番付けを行う（Ｓ１１）。なお、ノード２０の順番付けについては、例えば、予めノードＩＤ順や、ノードのＩＰアドレス順としてもよい。本実施形態では、例えば、ノードＩＤ順としている。なお、ノード２０の順番付けが予め設定されている場合には、ステップＳ１１を実行しなくてもよい。

次いで、コーディネーションサービス部３３は、クラスタネットワーク１２にネットワーク障害が発生したか否かを判定する（Ｓ１２）。この結果、ネットワーク障害が発生していない場合（Ｓ１２：Ｎｏ）には、コーディネーションサービス部３３は、処理をステップＳ１２に進める。

一方、ネットワーク障害が発生している場合（Ｓ１２：Ｙｅｓ）には、コーディネーションサービス部３３は、自身のノード２０をリーダとして投票する（Ｓ１３）。具体的には、コーディネーションサービス部３３は、クラスタネットワーク１２に自身のノード２０をリーダとする投票（自身のノード２０の番号を含む投票）をブロードキャストする（Ｓ１３）。

次いで、コーディネーションサービス部３３は、新しく選出されたリーダノード（代表ノード：新リーダノード）から投票処理完了通知を受信したか否かを判定する（Ｓ１４）。この結果、新リーダノードから投票処理完了通知を受信していない場合（Ｓ１４：Ｎｏ）には、コーディネーションサービス部３３は、処理をステップＳ１５に進める。

一方、新リーダノードから投票処理完了通知を受信した場合（Ｓ１４：Ｙｅｓ）には、自身のノード２０が多数派（最大ストレージノードグループ）に属するノード（多数派ノード）であることを認識し（Ｓ１７）、処理を終了する。

ステップＳ１５では、コーディネーションサービス部３３は、クラスタストレージシステム２の全体のノード２０の数（全体数）の過半数から自身のノード２０をリーダとする投票を取得したか否かを判定し、この結果、全体数の過半数から自身のノード２０をリーダとする投票を取得した場合（Ｓ１５：Ｙｅｓ）には、自身のノード２０が新リーダノードであることを意味しているので、自身のノード２０が新リーダノードであることを認識し、投票を行った各ノード２０に対して、投票処理完了通知を送信し（Ｓ１６）、自身のノード２０が多数派ノードであることを認識し（Ｓ１７）、処理を終了する。

一方、全体数の過半数から自身のノード２０をリーダとする投票を取得していない場合（Ｓ１５：Ｎｏ）には、コーディネーションサービス部３３は、自身が投票しているノードの番号よりも若い番号の投票を他のノード２０から受信したか否かを判定し（Ｓ１８）、自身が投票しているノードの番号よりも若い番号の投票を他のノード２０から受信していない場合（Ｓ１８：Ｎｏ）には、自身のノード２０が少数派に属するノード（少数派ノード）であることを認識し（Ｓ２０）、処理を終了する。

一方、自身が投票しているノードの番号よりも若い番号の投票を他のノード２０から受信している場合（Ｓ１８：Ｙｅｓ）には、コーディネーションサービス部３３は、自身が投票しているノードの番号よりも若い番号のノード２０をリーダとして再投票し（Ｓ１９）、処理をステップＳ１４に進める。

上記したノード種別認識及びリーダ選出処理によると、自身のノード２０がリーダノードであるのか否か、多数派に属するのか否かを適切に把握することができる。

次に、ノード種別認識及びリーダ選出処理について具体的に説明する。

図７は、一実施形態に係るノード種別認識及びリーダ選出処理の一例を説明する図である。図８は、一実施形態に係るノード種別認識及びリーダ選出処理のラダーチャートである。

ここで、クラスタストレージシステム２は、図７に示すように、ノード＃０〜ノード＃４までの５つのノード２０を備え、ノード＃０とノード＃１とでサブクラスタペア＃１が構成され、ノード＃１とノード＃２とでサブクラスタペア＃２が構成され、ノード＃２とノード＃３とでサブクラスタペア＃３が構成され、ノード＃３とノード＃４とでサブクラスタペア＃４が構成され、クラスタネットワーク１２において、ノード＃０〜ノード＃２と、ノード＃３及びノード＃４とに分断するスプリットブレインが発生した場合を例にノード種別認識及びリーダ選出処理について説明する。なお、ノード＃０〜ノード＃４の番号は、＃０〜＃４とする。

クラスタネットワーク１２において、ノード＃０〜ノード＃２と、ノード＃３及びノード＃４とに分断するネットワーク障害（スプリットブレイン）が発生した場合（図８（０））には、各ノード＃０〜＃４のコーディネーションサービス部３３は、ネットワークの障害を検出し、自身のノード２０をリーダとする投票を行う（図８（１））。この場合には、ノード＃０の投票は、ノード＃１及びノード＃２に受信され、ノード＃１の投票は、ノード＃０及びノード＃２に受信され、ノード＃２の投票は、ノード＃０及びノード＃１に受信される。また、ノード＃３の投票は、ノード＃４に受信され、ノード＃４の投票は、ノード＃３に受信される（図８（２））。

この結果、自身が投票しているノード２０の番号よりも若い番号（＃０）の投票を受信したノード＃１と、ノード＃２は、若い番号（＃０）を再投票し、自身が投票しているノードの番号（＃４）よりも若い番号（＃３）の投票を受信したノード＃４は、若い番号（＃３）を再投票する（図８（３））。

この再投票の結果、ノード＃０のコーディネーションサービス部３３は、ノード＃１とノード＃２から自身の番号（＃０）への再投票を受信する（図８（４））と、全体数（５個）の過半数である３つの投票を得たと判定して、自身が新リーダノードと認識し、投票処理完了通知を送信し（図８（５））、自身のノード２０が多数派に属すると認識する。この際、新リーダノードと認識したノード＃０のコーディネーションサービス部３３は、自身に対して投票した各ノード（有効ノード：多数派に属するノード２０）についてのノード情報（例えば、ノード管理表３５の有効ノードに対応するエントリの情報）を投票処理完了通知とともに送信する。投票処理完了通知は、クラスタネットワーク１２の障害により、ノード＃１とノード＃２とにしか受領されない。この投票処理完了通知を受信したノード＃１とノード＃２とは、自身のノード２０が多数派に属すると認識する。

一方、ノード＃３、ノード＃４においては、投票処理完了通知を受領することもなく、全体数（５個）の過半数である３つの投票を得ることもなく、自身が投票しているノードの番号よりも若い番号の投票を受信することもないので、自身が少数派に属すると認識する（図８（６））。

上記処理によると、多数派に属するノードの中から適切にリーダノードを選出（決定）することができる。また、各ノード２０は、多数派に属するのか、少数派に属するのかを適切に認識することができる。

次に、クラスタネットワーク１２の障害時におけるサブクラスタペアの状態について説明する。

図９は、一実施形態に係るサブクラスタペアの状態の一例を説明する図である。

クラスタネットワーク１２の障害時においては、サブクラスタ６０は、例えば、図９（ａ）に示すように、サブクラスタ６０を構成する２つのノード２０が多数派に属する場合と、図９（ｂ）に示すように、サブクラスタ６０を構成するノード２０の一方のノード２０が多数派に属し、他方のノード２０が少数派に属する場合と、図９（ｃ）に示すように、サブクラスタ６０を構成する２つのノード２０が少数派に属する場合とがある。

本実施形態では、図９（ａ）に示すように、サブクラスタ６０を構成する２つのノード２０が多数派に属する場合には、サブクラスタ６０におけるボリューム５０の同期が実行可能であるので、クライアント装置１０からのＩ／Ｏを継続して処理可能の状態を継続するようにする。また、図９（ｃ）に示すように、サブクラスタ６０を構成する２つのノード２０が少数派に属する場合には、サブクラスタ６０におけるボリューム５０の同期が実行可能であるので、クライアント装置１０からのＩ／Ｏを継続して処理可能な状態を継続するようにする。

一方、図９（ｂ）に示すように、サブクラスタ６０を構成するノード２０の一方のノード２０が多数派に属し、他方のノード２０が少数派に属する場合、すなわち、一方のボリューム５０が多数派のノード２０に格納され、他方のボリューム５０が少数派のノード２０に格納されている場合には、多数派に属するノード２０がＳｔａｎｂｙである場合には、クラスタ６０の状態をＡｃｔｉｖｅとするように設定する。なお、このように、サブクラスタ６０の一方のボリュームが少数派のノード２０に格納され、他方のボリュームが多数派のノード２０に格納されている場合におけるボリュームペアを、分断ボリュームペア（分断ボリュームグループ）という。

図１０は、一実施形態に係るサブクラスタペアＩ／Ｏ制御処理のフローチャートである。

サブクラスタペアＩ／Ｏ処理は、例えば、図６に示すノード種別認識及びリーダ選出処理が終了した直後に、実行される。

まず、ノード２０のサブクラスタ管理機能部４２は、自身のノード２０が含まれるサブクラスタペアが多数派と少数派とにまたがっているか否か、すなわち、サブクラスタペアの一方のノード２０が多数派に属し、他方のノード２０が少数派に属しているか否かを判定する（Ｓ２１）。

この結果、自身のノード２０が含まれるサブクラスタペアが多数派と少数派とにまたがっていない場合（Ｓ２１：Ｎｏ）には、サブクラスタ６０のボリュームの同期を行えることを意味しているので、サブクラスタペアを構成する２つのノード２０が多数派に属していても、少数派に属していても、クライアント装置１０からのＩ／Ｏを継続して受け継可可能な状態を維持し（Ｓ２２）、処理をステップＳ２４に進める。

一方、自身のノード２０が含まれるサブクラスタペアが多数派と少数派とにまたがっている場合（Ｓ２１：Ｙｅｓ）には、自身のノード２０が少数派である場合には、このサブクラスタペアのボリューム５０に対するＩ／Ｏの受け付けを停止する一方、自身のノード２０が多数派である場合には、このサブクラスタペアのボリューム５０に対するＩ／Ｏの受け付けるようにする。例えば、少数派のノード２０のボリューム５０がＡｃｔｉｖｅだった場合には、多数派のノード２０のボリュームをＡｃｔｉｖｅにするようにＦａｉｌｏｖｅｒを行い（Ｓ２３）、処理をステップＳ２４に進める。

ステップＳ２４では、サブクラスタ管理機能部４２は、自身のノード２０が少数派であり、クラスタ構成変更によってコントロールプレーン３０へのアクセスが必要であるか否かを判定する。この結果、クラスタ構成変更によってコントロールプレーン３０へのアクセスが必要でないと判定した場合（Ｓ２４：Ｎｏ）には、サブクラスタ管理機能部４２は、クライアント装置１０からのＩ／Ｏを継続して受付可能とし（Ｓ２５）、処理をステップＳ２４に進める。

一方、クラスタ構成変更によってコントロールプレーン３０へのアクセスが必要であると判定した場合（Ｓ２４：Ｙｅｓ）には、サブクラスタ管理機能部４２は、サブクラスタペアのボリューム５０に対するＩ／Ｏの受け付けを停止し（Ｓ２６）、処理を終了する。

次に、クラスタストレージシステム２におけるサブクラスタペアＩ／Ｏ制御処理を含む全体制御処理について説明する。

図１１は、一実施形態に係るサブクラスタペアＩ／Ｏ制御処理を含む全体制御処理のラダーチャートである。なお、クラスタストレージシステム２は、図７に示す構成であり、動作後に図７に示すネットワーク分断が発生した場合を例に処理を説明する。

まず、クラスタストレージシステム２は、以下に示すクラスタ初期設定及びデータＩ／Ｏ開始処理を実行する（図１１（０））。

具体的には、クラスタ初期設定時（構築時）において、初期時におけるリーダとされているノード（リーダノード）のクラスタコントローラ３２は、各ノード２０のノードコントローラ３１からコーディネーションサービス部３３にて通知された構成情報（例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）情報、デバイス数、デバイス容量、ＣＰＵコア数等）に基づいて、最適なリソース割り当てを決定する。なお、リソース割り当てについては、サブクラスタやボリュームが特定のノード２０のリソースに偏って作成されないよう、ラウンドロビン等の既知の手法で分散して配置する。

クラスタコントローラ３２は、通知のあったノード２０に対し順次ノードＩＤを付加し、ノード２０のＩＰアドレス情報と、ノード状態（初期状態ではＡｃｔｉｖｅ)とを含むエントリを作成して、ノード管理表３５を作成する。なお、ノード２０のＩＰアドレスは、リーダノードにＤＨＣＰサーバ機能を持たせておき、この機能によりノード２０のＩＰアドレスを決定し、その内容をクラスタコントローラ３２に通知するようにしてもよいし、管理者からのＩＰアドレス設定コマンドでノード２０ごとのＩＰアドレス指定を受け付けてノードコントローラ３２に通知するようにしてもよい。

また、クラスタコントローラ３２は、決定したリソース割り当て（サブクラスタをどのノード２０のペアで作成するかについての割り当て）に基づいて、対象の２つのノード２０のノードコントローラ３１にサブクラスタ構成を指示する。このとき、クラスタコントローラ３２は、サブクラスタ構成管理表３７にエントリが存在する場合は、各エントリと重複しないサブクラスタＩＤをあわせて指定する。

サブクラスタ構成の指示を受けた各ノード２０のノードコントローラ３１は、サブクラスタ構成が完了すると、コーディネーションサービス部３３により、クラスタコントローラ３２に対してサブクラスタ構成の完了を通知する。クラスタコントローラ３２は、サブクラスタ構成管理表３７に、作成されたサブクラスタのサブクラスタＩＤと、ノードＩＤ（プライマリノードＩＤ、セカンダリノードＩＤ）と、サブクラスタ状態（初期状態ではＡｃｔｉｖｅ）とを含むエントリを追加する。

ユーザから（クライアント装置１０）からボリューム５０の作成コマンドが実行されると、クラスタコントローラ３２は、サブクラスタ構成管理表３７でサブクラスタ状態がＡｃｔｉｖｅであるサブクラスタ６０のうち、ボリュームを割り当てるのに最適なサブクラスタを選定する。サブクラスタ６０を選定する方法としては、例えば、ボリューム管理表３６において、ボリューム５０の割り当てが最も少ないサブクラスタを選定する方法を用いてもよい。また、クラスタコントローラ３２は、ボリューム管理表３６にある既存のボリューム５０とボリュームＩＤとが重複しないようにして、サブクラスタ構成管理表３７から選定されたサブクラスタ６０におけるプライマリノードＩＤのノード２０（プライマリノード）のノードコントローラ３１に対してボリューム作成を指示し、作成するボリュームＩＤとサブクラスタＩＤとを含むエントリをボリューム管理表３６に追加する。

ボリューム作成指示を受けたノード２０のノードコントローラ３１は、データプレーン４０のサブクラスタ管理機能部４２と連携（必要に応じてシンプロビジョニングなどの機能の設定を実施)して、ボリューム５０を作成する。さらに、ノードコントローラ３１は、クラスタコントローラ３２から構成データベース３４のノード管理表３５、サブクラスタ構成管理表３７、ボリューム管理表３６を受け取り、その情報を構成データベースキャッシュ４４として、自身のノード２０上の領域に記憶させる。プライマリノードに作成されたボリューム５０は、プライマリノードのデータプレーン４０のプロテクション機能部４３により、構成データベースキャッシュ４４のサブクラスタ構成管理表（サブクラスタ構成管理表３７と同内容の表）から参照したセカンダリノードＩＤと、構成データベースキャッシュ４４のノード管理表（ノード管理表３５と同内容の表）から参照した、セカンダリノードＩＤと合致するノード２０のクラスタネットワークＩＰアドレスとに基づいて、ボリューム５０のレプリカをセカンダリノードに作成し、これらボリューム５０を同期させる。

リーダノードのクラスタコントローラ３２に対して、クライアント装置１０側からクラスタ６０の所定のボリュームＩＤのボリューム５０（対象ボリューム）に対してＩ／Ｏ要求があると、クラスタコントローラ３２は、対象のボリューム５０を管理するサブクラスタ６０のプライマリノードを特定して、クライアント装置１０と、プライマリノードとの間のネットワーク接続を確立する。ネットワーク接続の確立には、例えば、既知の技術であるｉＳＣＳＩログインリダイレクション機能を利用してもよい。具体的には、クライアント装置１０からＩ／Ｏ要求を受けると、クラスタコントローラ３２は、構成データベース３４のボリューム管理表３６を参照して、対象ボリューム５０のオーナとなっているサブクラスタ６０のサブクラスタＩＤを特定する。続いて、クラスタコントローラ３２は、サブクラス構成管理表３７を参照し、サブクラスタＩＤを検索キーとして、合致するエントリからプライマリノードＩＤを特定する。さらに、クラスタコントローラ３２は、ノード管理表３５を参照し、プライマリノードＩＤを検索キーとして、ノードＩＤと合致するエントリからクラスタネットワークＩＰアドレスを特定する。クラスタコントローラ３２は、特定したクラスタネットワークＩＰアドレスをクライアント装置１０に送信する。ＩＰアドレスを受け取ったクライアント装置１０は、そのＩＰアドレスに対してネットワーク接続要求を出す。ネットワーク接続要求を受け取ったノード２０（すなわち、プライマリノード）のターゲット機能部４１は、接続承認をクライアント装置１０に通知して、クライアント装置１０とのネットワーク接続を確立する。ネットワーク接続確立後、クライアント装置１０は、対象ボリュームを持つプライマリノードに対してパブリックネットワーク１１経由でのＩ／Ｏが可能となる。

クライアント装置１０からのＩ／Ｏ要求を受け取ったプライマリノードのプロテクション機能部４３は、ボリューム５０の実データを格納すべきローカルの物理ストレージデバイスに対して、Ｉ／Ｏ要求に従って読み書きの処理（Ｉ／Ｏ処理）を実行するとともに、構成データベースキャッシュ４４のサブクラスタ構成管理表から特定されるセカンダリノードＩＤのノード２０（セカンダリノード）に対して、構成データベースキャッシュ４４のノード管理表から特定されるクラスタネットワークＩＰアドレス宛で同一のＩ／Ｏ対象のデータを転送する。セカンダリノードのプロテクション機能部４３は、セカンダリノードのローカルの物理ストレージデバイスにデータを保存する。これにより、データが同期されて冗長性が確保される。

次に、クラスタネットワーク１２においてネットワーク分断が発生した場合には、クラスタストレージシステム２は、以下に示すリーダ選出処理及び構成データベース情報展開処理を実行する（図１１（１））。

クラスタネットワーク１２においてネットワーク分断が発生して、サブクラスタペア間のハードビートが途切れていることをノード２０のノードコントローラ３１が検知すると、ノードコントローラ３１は、コーディネーションサービス部３３により、リーダノードに監視情報を通知する。このとき、リーダノードはコーディネーションサービス部３３によるリーダ選出処理を開始する。リーダ選出処理により新しいリーダが決定すると、新しいリーダノードのコーディネーションサービス部３３は、クラスタコントローラ３２と、構成データベース３４とを活性化する。

構成データベース３４の情報引継ぎに関しては、例えば下記の２つの手法がある。
・あらかじめクラスタ正常動作時から、構成データベース３４の情報を複数の他ノード２０に複製し、同期しておく。ネットワーク障害によるリーダ選出処理により、新しいリーダとなったノード２０は、クラスタの各ノード２０に対して、構成データベース３４の情報の要求をブロードキャストし、構成データベース３４の複製を保持しているノード２０から構成データベース３４の情報を取得する。なお、新しいリーダノードとして選出されるノードを、構成データベース３４の複製を持っているノード２０に限定した場合には、新しいリーダノードはすでに構成データベース３４を保持していることになるので、構成データベース３４の情報の要求は不要である。なお、構成データベース３４を複製する数は、クラスタ内の全ノード２０の過半数あれば、ネットワーク分断が発生しても、必ず多数派に含まれるノードにリーダ候補（構成データベース３４の複製を持っているノード２０）が含まれることとなる。また、例えば、ノード２０を搭載するラックやデータセンター単位での電源境界を考慮して、異なる電源を利用するノード２０に対して構成データベース３４の複製を保持させておくことで、実使用上高い耐障害性を維持しつつ構成データベース３４の複製のオーバーヘッドを減らすことができる。
・リーダノードはクラスタの任意のノード２０がなり得、且つ新たなリーダノードとそれまでのリーダノードとが疎通可能な場合は、それまでのリーダノードに保存されていた構成データベース３４の情報をそのままコピーして新たなリーダノードが引き継ぐようにする。もし、新たなリーダノードとそれまでのリーダノードが疎通不可能な場合は、新たなリーダノードは、自身の構成データベースキャッシュ４４の情報をクラスタの構成データベース３４の情報として一旦設定した上で、後述の管理表の更新処理を実施することで、最新の情報とする。

新たなリーダノードのクラスタコントローラ３２は、構成データベース３４のノード管理表３５において、投票してきたノード２０以外のノード２０のエントリのノード状態３５ｄをＡｃｔｉｖｅからＤｏｗｎに変更する。

また、クラスタコントローラ３２は、サブクラスタ構成管理表３７を参照し、投票してこなかったノード（ネットワーク分断により投票が到達しなかったノード）のノードＩＤを検索キーとして、プライマリノードＩＤもしくはセカンダリノードＩＤと合致するエントリを検索する。プライマリノードＩＤのノード２０からは投票があり、セカンダリノードＩＤのノード２０からは投票がなかった条件に合致するエントリが見つかった場合は、クラスタコントローラ３２は、そのエントリのサブクラスタ状態をＡｃｔｉｖｅ−Ｄｏｗｎに変更する。また、プライマリノードＩＤのノードからは投票がなく、セカンダリノードＩＤのノードからは投票があった条件に合致するエントリが見つかった場合は、クラスタコントローラ３２は、そのエントリのサブクラスタ状態３７ｄをＦａｉｌｏｖｅｒに変更する。また、プライマリノードＩＤのノード２０と、セカンダリノードＩＤのノード２０のどちらからも投票がなかった条件に合致するエントリが見つかった場合は、クラスタコントローラ３２は、そのエントリのサブクラスタ状態３７ｄをＵｎｋｎｏｗｎに変更する。なお、ネットワーク分断時には、ボリューム管理表３６の更新は発生しない。

構成データベース３４の各管理表の更新が完了すると、リーダノードのクラスタコントローラ３２は、投票があった多数派のノード２０のノードコントローラ３１経由で、各ノード２０の構成データベースキャッシュ４４の更新を指示する。これにより、多数派のノード２０においては、最新の状態の構成データベース３４と同じ情報がキャッシュされることとなる。

次に、クラスタストレージシステム２は、以下に示すサブクラスタペア＃３のＦａｉｌｏｖｅｒ処理を実行し（図１１（２））、コントロールプレーン２０停止後もサブクラスタペア＃４へのＩ／Ｏを継続する処理を実行する（図１１（３））。

具体的には、リーダノードのクラスタコントローラ３２は、サブクラスタ構成管理表３７でサブクラスタ状態３７ｄをＦａｉｌｏｖｅｒに変更したエントリのセカンダリノードＩＤのノード２０のノードコントローラ３１に対して、Ｆａｉｌｏｖｅｒ処理の実行を指示する。Ｆａｉｌｏｖｅｒ処理の実行指示を受けたノード２０のノードコントローラ３１は、クライアント装置１０からのネットワーク再接続要求を待つ。

ここで、Ｉ／Ｏを停止する対象となるボリューム５０を持つプライマリノードにおいては、ターゲット機能部４１が、ネットワーク分断時のリーダ選出処理で投票完了通知を受け取らずに、自身が少数派に属するノードであると認識した時点で、クライアント装置１０からのＩ／Ｏ受付を停止するか否かの判断処理を実行する。少数派に属するプライマリノードのターゲット機能部４１は、構成データベースキャッシュ４４のノード管理表とサブクラスタ構成管理表を参照して、Ｉ／Ｏ転送先のセカンダリノードに到達可能か否かを確認する。

セカンダリノードに到達可能な場合は、プライマリノードのターゲット機能部４１は、クライアント装置１０からのＩ／Ｏを停止させずに、セカンダリノードへのＩ／Ｏ転送（同期）も継続する。図１１における、少数派のノード２０のみで構成されるサブクラスタペア＃４のボリュームがこのケースに相当する。このサブクラスタペア＃４のボリュームペアが少数側ボリュームグループに相当する。

一方、セカンダリノードに到達できない場合は、ターゲット機能部４１は、クライアント装置１０からのＩ／Ｏ受付、及びセカンダリノードへのＩ／Ｏ転送を停止する。図１１におけるサブクラスタペア＃３のボリュームがこのケースに相当する。Ｉ／Ｏ受付を停止されたクライアント装置１０は、パブリックネットワーク１１経由でクラスタコントローラ３２に対して、ネットワーク再接続要求出す。ここで、クライアント装置１０がクラスタコントローラ３２に対してネットワーク再接続要求を送信できるようにするためには、例えば、予め決められた代表のＩＰアドレスに対してネットワーク再接続要求を送信すると、その代表ＩＰアドレスに設定されたリーダノードがネットワーク再接続要求を受信するようにしてもよく、或いは、代表ＩＰアドレスが設定されている装置がリーダノードからリーダノードのＩＰアドレスを取得しておき、クライアント装置１０から代表ＩＰアドレスに対してネットワーク再接続要求が来た場合に、リーダノードに対してリダイレクトしてネットワーク再接続要求をリーダノードが受信できるようにしてもよい。

ネットワーク再接続要求を受信したリーダノードのクラスタコントローラ３２は、構成データベース３４のボリューム管理表３６およびサブクラスタ構成管理表３７を参照して、受信したネットワーク再接続要求が、サブクラスタ状態３７ｄをＦａｉｌｏｖｅｒに設定したサブクラスタが管理するボリューム（この例では、サブクラスタペア＃３のボリューム）への接続要求であることを確認した場合、サブクラス構成管理表３７のこのサブクラスタに対応するエントリのセカンダリノードＩＤを検索キーとして、ノード管理表３５からセカンダリノードのパブリックネットワークＩＰアドレスを特定し、クライアント装置１０にパブリックネットワークＩＰアドレスを送信する。

パブリックネットワークＩＰアドレスを受信したクライアント装置１０は、そのＩＰアドレスに対してネットワーク接続要求を出す。ネットワーク接続要求を受け取ったノード２０のターゲット機能部４１は、接続承認をクライアント装置１０に通知して、クライアント装置１０とのネットワーク接続を確立する。ネットワーク接続確立後、クライアント装置１０は、対象ボリュームを持つノード２０に対してパブリックネットワーク１１経由でＩ／Ｏを開始可能となる。

なお、クライアント装置１０からのＩ／Ｏを受けていたプライマリノードは、ネットワーク分断時のリーダ選出処理で投票完了通知を新たなリーダノードから受信して、自身が多数派に属するノードであると認識した場合、プライマリノードのローカルの物理ストレージデバイスへの読み書きを停止させない。ただし、更新された構成データベースキャッシュ４４のサブクラスタ構成管理表において、サブクラスタ状態がＡｃｔｉｖｅ−Ｄｏｗｎとなっている場合、このプライマリノードのプロテクション機能部４３は、セカンダリノードへのＩ／Ｏ転送（すなわち同期）を停止させる。

以降において、クラスタストレージシステム２は、以下に示すクラスタ構成変更によるサブクラスタペア＃３へのＩ／Ｏ停止処理を実行する（図１１（４））。

具体的には、ノード削除、ストレージデバイス交換、ネットワークスイッチ停止、そのほか多重障害発生等、クラスタがネットワーク分断から復旧していない状態におけるクラスタ構成の変更が発生したことにより、少数派に属するノード間のプライマリノードのプロテクション機能部４３によるセカンダリノードへのＩ／Ｏ転送に失敗した場合、この時点でプライマリノードのターゲット機能部４３は、クライアント装置１０からのＩ／Ｏ受付を停止する。Ｉ／Ｏ受付を停止されたクライアント装置１０は、パブリックネットワーク１１経由でクラスタコントローラ３２に対して、ネットワーク再接続要求を出す。

ネットワーク再接続要求を受信したクラスタコントローラ３２は、構成データベース３４のボリューム管理表３６およびサブクラスタ構成管理表３７を参照して、クライアント装置１０から受け付けたネットワーク再接続要求が、サブクラスタ状態３７ｄをＵｎｋｎｏｗｎにしたサブラスタが管理するボリュームへの接続要求であることを確認した場合、少数派に属するノード間でボリュームペアの同期ができなくなったと判断し、接続拒否をクライアント装置１０に通知して、クライアント装置１０にネットワーク接続失敗を認識させる。

次に、クラスタストレージシステム２における復旧時処理について説明する。

図１２は、一実施形態に係る復旧時処理のフローチャートである。

クラスタコントローラ３２は、クラスタネットワーク１２におけるネットワーク障害から復旧したか否かを判定し（Ｓ３１）、ネットワーク障害から復旧していない場合（Ｓ３１：Ｎｏ）には、処理をステップＳ３１に進める一方、ネットワーク障害から復旧している場合（Ｓ３１：Ｙｅｓ）には、少数派だった各ノード２０に対して構成データベース３４の情報を展開（送信）する（Ｓ３２）。

次いで、クラスタコントローラ３２は、構成データベース３４のサブクラスタ構成管理表３７を参照して、サブクラスタ状態３７ｄがＦａｉｌｏｖｅｒに設定されたサブクラスタがあるか否かを判定する（Ｓ３３）。

この結果、Ｆａｉｌｏｖｅｒに設定されたサブクラスタがない場合（Ｓ３３：Ｎｏ）には、クラスタコントローラ３２は、復旧時処理を終了する。一方、Ｆａｉｌｏｖｅｒに設定されたサブクラスタがある場合（Ｓ３３：Ｙｅｓ）には、クラスタコントローラ３２は、Ｆａｉｌｏｖｅｒに設定されているサブクラスタペアのＦａｉｌｂａｃｋ（フェールバック）を実行する（Ｓ３４）。具体的にはクラスタコントローラ３２は、サブクラスタ構成管理表３７のＦａｉｌｏｖｅｒに設定されているサブクラスタペアのエントリのプライマリノードＩＤのノード２０にサブクラスタに対応するボリュームへのＩ／Ｏを受付可能に設定する要求を送信するとともに、セカンダリノードＩＤのノード２０にサブクラスタに対応するボリュームへのＩ／Ｏを停止する要求を送信し、対応するエントリのサブクラスタ状態３７ｄをＡｃｔｉｖｅ−Ｓｔａｎｂｙに設定する。

図１３は、一実施形態に係る復旧時処理の一例を説明する図である。

復旧時処理によるとネットワーク障害から復旧すると、少数派に属するノード２０が、多数派と疎通可能な状態となり、少数派に属するノード２０（図１３のノード＃３、ノード＃４）の構成データベースキャッシュ４４の内容が構成データベース３４の最新の内容に更新される。その後、少数派のノード２０と、多数派のノード２０とで構成されるサブクラスタ（サブクラスタ＃３）に対して、Ｆａｉｌｂａｃｋが実行され、サブクラスタペアのエントリのプライマリノードＩＤのノード２０がサブクラスタに対応するボリュームへのＩ／Ｏを受付可能に設定され、セカンダリノードＩＤのノード２０がサブクラスタに対応するボリュームへのＩ／Ｏを停止される。

図１４は、一実施形態に係る復旧時処理のラダーチャートである。なお、クラスタストレージシステム２は、図１１に示す処理（３）の直後の状態となっている場合を例に処理を説明する。

クラスタストレージシステム２は、データＩ／Ｏを継続している（図１４（０））。この状態においては、少数派に属するプライマリノードとセカンダリノードとの間で互いに疎通できている場合は、プライマリノードのターゲット機能部４１は、クライアント装置１０からのＩ／Ｏを停止させずに、セカンダリノードへのＩ／Ｏ転送も継続している。サブクラスタペア＃４のボリュームがこのケースに対応している。

この後、クラスタネットワーク１２がネットワーク障害から復旧すると、少数派のノード２０のノードコントローラ３１は、コーディネーションサービス機能部３２により、リーダノードに対して生存通知ができるようになる。このとき、リーダノードのクラスタコントローラ３２は通知のあったノード２０のノードコントローラ３１に対して構成データベース３４の情報を展開し、このノード２０の構成データベースキャッシュ４４を更新させる（図１４（１））。

続いて、クラスタコントローラ３２は、構成データベース３４のノード管理表３５において、ノード状態３５ｄがＤｏｗｎとなっているノード２０について、生存通知を確認できたノード２０については、ノード状態３５ｄをＤｏｗｎからＡｃｔｉｖｅに変更する。また、クラスタコントローラ３２は、構成データベース３４のサブクラスタ構成管理表３７において、サブクラスタ状態３７ｄがＡｃｔｉｖｅ−Ｄｏｗｎ、Ｕｎｋｎｏｗｎとなっているサブクラスタについて、プライマリノードのノードコントローラ３１に対してサブクラスタ状態の更新と通知を指示する。また、クラスタコントローラ３２は、構成データベース３４のサブクラスタ構成管理表３７において、サブクラスタ状態３７ｄがＦａｉｌｏｖｅｒとなっているサブクラスタについて、セカンダリノードのノードコントローラ３１に対してサブクラスタ状態の更新と通知を指示する。

指示を受けたノード２０のノードコントローラ３１は、更新された構成データベースキャッシュ４４のサブクラスタ構成管理表から、自身のノード２０とサブクラスタを構成しているノードのノードＩＤを特定し、構成データベースキャッシュ４４のノード管理表から、クラスタネットワークＩＰアドレスを特定し、そのＩＰアドレスを用いてサブクラスタを構成する他のノード２０に対して応答確認を行う。

応答確認を行ったノード２０から応答がない場合は、ノードコントローラ３１は、その結果をリーダノードに通知する。リーダノードは、構成データベース３４のサブクラスタ構成管理表３７の対象のサブクラスタのエントリのサブクラスタ状態３７ｄがＵｎｋｎｏｗｎであれば、Ａｃｔｉｖｅ−ｄｏｗｎに変更し、各ノード２０のノードコントローラ３１経由で、構成データベースキャッシュ４４を更新する。

一方、応答確認を行ったノード２０から応答があった場合は、ノードコントローラ３１は、その結果をリーダノードに通知する。リーダノードのクラスタコントローラ３２は、構成データベース３４のサブクラスタ構成管理表３７の対象のサブクラスタのエントリのサブクラスタ状態３７ｄを確認する。

この結果、サブクラスタ状態３７ｄがＵｎｋｎｏｗｎであれば、クラスタコントローラ３２は、サブクラスタ状態３７ｄをＡｃｔｉｖｅに変更し、各ノード２０のノードコントローラ３１経由で、構成データベースキャッシュ４４を更新する。

また、サブクラスタ状態３７ｄがＡｃｔｉｖｅ−Ｄｏｗｎであれば、クラスタコントローラ３２は、プライマリノードのノードコントローラ３１にボリュームペアの同期を指示する。指示を受けたプライマリノードのノードコントローラ３１は、停止していたプロテクション機能部４３の操作を再開し、ローカルの物理ストレージデバイスにあるボリュームの実データをセカンダリノード上の物理ストレージデバイスにコピーして同期させる。ボリュームの同期が完了するとプライマリノードのノードコントローラ３１は、リーダノードに同期完了を通知する。通知を受けるとリーダノードのクラスタコントローラ３２は、構成データベース３４のサブクラスタ構成管理表３７の対象のサブクラスタのエントリのサブクラスタ状態３７ｄをＡｃｔｉｖｅ−ＤｏｗｎからＡｃｔｉｖｅに変更し、各ノード２０のノードコントローラ３１経由で、構成データベースキャッシュ４４を更新する。

また、サブクラスタ状態３７ｄがＦａｉｌｏｖｅｒであれば、クラスタコントローラ３２は、セカンダリノードのノードコントローラ３１にボリュームペアの同期とＦａｉｌｂａｃｋを指示する。指示を受けたセカンダリノードのノードコントローラ３１は、停止していたプロテクション機能部４３の動作を再開し、ローカルの物理ストレージデバイスにあるボリュームの実データをプライマリノード上の物理ストレージデバイスにコピーして同期させる。また、同期が完了するとセカンダリノードは、クライアント装置１０からのＩ／Ｏ受付を停止する。

Ｉ／Ｏ受付を停止されたクライアント装置１０は、パブリックネットワーク１１経由でクラスタコントローラ３２に対して、ネットワーク再接続要求を出す。クラスタコントローラ３２は、構成データベース３４のボリューム管理表３６及びサブクラスタ構成管理表３７を参照して、クライアント装置１０から受け付けたネットワーク再接続要求が、サブクラスタ状態３７ｄがＦａｉｌｏｖｅｒであるサブクラスタが管理するボリューム（図１４の例では、サブクラスタペア＃３のボリューム)への接続要求であることを確認した場合、サブクラスタ構成管理表３７のこのサブクラスタのエントリのプライマリノードＩＤを検索キーとして、ノード管理表３５からプライマリノードのクラスタネットワークＩＰアドレスを特定し、クライアント装置１０にＩＰアドレスを送信する。

ＩＰアドレスを受け取ったクライアント装置１０は、受信したＩＰアドレスに対してネットワーク接続要求を出す。ネットワーク接続要求を受け取ったノード２０のターゲット機能部４１は、接続承認をクライアント装置１０に通知してクライアント装置１０とのネットワーク接続を確立する。ネットワーク接続確立後、クライアント装置１０は、対象ボリュームを持つプライマリノードに対してパブリックネットワーク１１経由でＩ／Ｏを開始可能となる。これにより、Ｆａｉｌｂａｃｋが完了し、各ノード２０をネットワーク障害発生の前の設定に従った役割を担う状態とすることができる。ネットワーク接続が確立し、Ｆａｉｌｂａｃｋが完了すると、プライマリノードはリーダノードにＦａｉｌｂａｃｋの完了を通知する。通知を受けるとリーダノードのクラスタコントローラ３２は、構成データベース３４のサブクラスタ構成管理表３７の対象のエントリのサブクラスタ状態３７ｄをＦａｉｌｏｖｅｒからＡｃｔｉｖｅに変更し、各ノード２０のノードコントローラ３１経由で、構成データベースキャッシュ４４を更新する。これにより、クラスタストレージシステム２をネットワーク障害の発生前の状態に復旧することができる。

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

例えば、上記実施形態において、ネットワーク障害により、サブクラスタのボリュームペアのノード２０が多数派と、少数派とに分断されて、多数派のノード２０（第１ストレージノードの一例）のボリュームにＦａｉｌｏｖｅｒする処理を実行した場合に、多数派の他のノード２０（第２ストレージノードの一例）に、そのボリュームをコピーし、そのノード２０のボリュームとの間でボリュームペアを構成して同期するようにしてもよい。このようにすると、ネットワーク障害発生時においても、ボリュームの冗長性を適切に確保することができる。

また、上記実施形態では、サブクラスタとして、２つのノードから構成されるサブクラスタペアを例に挙げていたが、本発明はこれに限られず、サブクラスタを３つ以上のノード２０で構成するようにしてもよい。すなわち、３つ以上のボリュームを同期させて管理するようにしてもよい。

また、上記実施形態において、リーダノードを決定する方法は上記した例に限られず、任意の方法を用いてもよく、例えば、多数派のノードの中からランダムに決定するようにしてもよい。

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

１…計算機システム、２…クラスタストレージシステム、１０…クライアント装置、１１…パブリックネットワーク、１２…クラスタネットワーク、２０…ノード、３０…コントロールプレーン、３１…ノードコントローラ、３２…クラスタコントローラ、３３…コーディネーションサービス部、３４…構成データベース、３５…ノード管理表、３６…ボリューム管理表、３７…サブクラスタ構成管理表、４０…データプレーン、４１…ターゲット機能部、４２…サブクラスタ管理機能部、４３…プロテクション機能部、４４…構成データベースキャッシュ、５０…ボリューム、６０…サブクラスタ

Claims (10)

1. クライアント装置で利用するデータを格納する複数のストレージノードと、前記クライアント装置と前記ストレージノードとを接続する第１ネットワークと異なる、前記複数のストレージノードを相互に通信可能に接続する第２ネットワークと、を備えるクラスタストレージシステムであって、
   それぞれの前記ストレージノードは、ボリュームを単位として前記データを格納可能であり、
   複数の前記ストレージノードに格納されている複数のボリュームにより構成されるボリュームグループを複数有し、
   前記ボリュームグループの各ボリュームを格納する複数のストレージノードは、前記第２ネットワークを介して同一のボリュームグループのボリュームを同期させる
   クラスタストレージシステム。
2. 前記複数のストレージノードの少なくともいずれか１つのストレージノードは、
   前記第２ネットワークにおける前記複数のストレージノード間の通信が分断されたか否かを判定し、
   前記第２ネットワークにおける通信が分断されたと判定した場合に、前記ボリュームグループが、前記ボリュームグループ中のボリュームの同期が実行不可能となった分断ボリュームグループであるか否かを判定し、
   前記分断ボリュームグループに属するいずれか１つのボリュームに対する前記クライアント装置からのアクセスを実行可能な状態とする
   請求項１に記載のクラスタストレージシステム。
3. 複数のストレージノードは、
   前記第２ネットワークにおける前記複数のストレージノード間の通信が分断されたと判定された場合に、自身が前記複数のストレージノードの中の前記第２ネットワークを介して相互に通信可能なストレージノードの数が最大となる最大ストレージノードグループに属するか否かを判定し、
   前記最大ストレージノードグループに属するストレージノードの中の代表となるストレージノードである代表ストレージノードは、前記最大ストレージノードグループのストレージノードに格納されている、前記分断ボリュームグループに属するボリュームを前記クライアント装置からのアクセスを実行可能な状態とする
   請求項２に記載のクラスタストレージシステム。
4. 前記代表ストレージノードは、
   前記最大ストレージノードグループの前記分断ボリュームグループに属するボリュームを格納する第１ストレージノード以外の第２ストレージノードに、前記分断ボリュームグループに属するボリュームをコピーし、
   前記第１ストレージノードのボリュームと、前記第２ストレージノードのボリュームとを含む新たなボリュームグループを構成し、
   前記第１ストレージノードと前記第２ストレージノードとは、前記新たなボリュームグループのボリュームを同期させる
   請求項３記載のクラスタストレージシステム。
5. 前記代表ストレージノードは、
   前記第２ネットワークにおける前記複数のストレージノード間の通信の分断の解消を検出し、
   前記通信の分断の解消を検出した場合に、前記クライアント装置からアクセス可能に設定された前記分断ボリュームグループのボリュームの内容を、前記分断ボリュームグループの他のボリュームに反映させ、
   前記分断ボリュームグループペアの各ボリュームを格納する複数のストレージノードは、前記各ボリュームの同期を開始する
   請求項３又は請求項４に記載のクラスタストレージシステム。
6. 前記代表ストレージノードは、
   前記分断ボリュームグループの複数のボリュームの役割を、前記第２ネットワークにおける前記複数のストレージノード間の通信の分断の発生前の役割に設定する
   請求項５に記載のクラスタストレージシステム。
7. 前記ボリュームグループが、前記最大ストレージノードグループに属しておらず、前記第２ネットワークを介して通信可能な複数のストレージノードのみに格納されているボリュームで構成されている少数側ボリュームグループである場合に、前記少数側ボリュームグループのボリュームを格納する複数のストレージノードのいずれかのストレージノードは、前記クライアント装置からのアクセスを実行可能な状態とし、
   以降において、前記少数側ボリュームグループのボリュームの同期が不可能になった場合に、前記クライアント装置からの前記ボリュームへのアクセスを実行不能な状態とする
   請求項３から請求項６のいずれか一項に記載のクラスタストレージシステム。
8. 前記複数のストレージノードは、前記第２ネットワークを介して通信可能な他のストレージノードの数に基づいて、最大ストレージノードグループに属するか否かを判定し、自身が最大ストレージノードグループに属しており、且つ自身が最も優先度が高いノードである場合に、自身を代表ストレージノードと決定する
   請求項３から請求項７のいずれか一項に記載のクラスタストレージシステム。
9. クライアント装置で利用するデータを格納する複数のストレージノードと、前記クライアント装置と前記ストレージノードとを接続する第１ネットワークと異なる、前記複数のストレージノードを相互に通信可能に接続する第２ネットワークと、を備えるクラスタストレージシステムによるデータ管理制御方法であって、
   それぞれの前記ストレージノードは、ボリュームを単位として前記データを格納可能であり、
   複数の前記ストレージノードに格納されている複数のボリュームにより構成されるボリュームグループを複数有し、
   前記ボリュームグループの各ボリュームを格納する複数のストレージノードは、前記第２ネットワークを介して同一のボリュームグループのボリュームを同期させる
   データ管理制御方法。
10. クライアント装置で利用するデータを格納する複数のストレージノードと、前記クライアント装置と前記ストレージノードとを接続する第１ネットワークと異なる、前記複数のストレージノードを相互に通信可能に接続する第２ネットワークと、を備えるクラスタストレージシステムにおける前記ストレージノードを構成するコンピュータにより実行されるデータ管理制御プログラムであって、
    それぞれの前記ストレージノードは、ボリュームを単位として前記データを格納可能であり、
    複数の前記ストレージノードに格納されている複数のボリュームにより構成されるボリュームグループを複数有し、
    前記コンピュータを、
    前記第２ネットワークにおける前記複数のストレージノード間の通信が分断されたか否かを判定し、
    前記第２ネットワークが分断されたと判定された場合に、自身が前記複数のストレージノードの中の前記第２ネットワークを介して相互に通信可能なストレージノードの数が最大となる最大ストレージノードグループに属するか否かを判定し、
    前記最大ストレージノードグループに属すると判定した場合に、自身が最大ストレージノードグループの中の代表となるストレージノードである代表ストレージノードであるか否かを判定し、
    代表ストレージノードであると判定した場合に、最大ストレージノードグループのストレージノードのボリュームが含まれている前記ボリュームグループが、前記ボリュームグループ中のボリュームの同期が実行不可能となった分断ボリュームグループであるか否かを判定し、
    前記分断ボリュームグループに属するいずれか１つのボリュームに対する前記クライアント装置からのアクセスを実行可能な状態とするように機能させる
    データ管理制御プログラム。