知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024154603
(43)【公開日】2024-10-31
(54)【発明の名称】ストレージシステム及びストレージノード管理方法
(51)【国際特許分類】
G06F 11/20 20060101AFI20241024BHJP
G06F 13/10 20060101ALI20241024BHJP
G06F 13/14 20060101ALI20241024BHJP
G06F 3/06 20060101ALI20241024BHJP
【ＦＩ】
G06F11/20 694
G06F13/10 340A
G06F13/14 330B
G06F3/06 305C
G06F3/06 306Z
【審査請求】未請求
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2023068517
(22)【出願日】2023-04-19
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110000925
【氏名又は名称】弁理士法人信友国際特許事務所
(72)【発明者】
【氏名】小田 元
(72)【発明者】
【氏名】相川 亮
【テーマコード（参考）】
5B034
【Ｆターム（参考）】
5B034CC02
5B034DD07
(57)【要約】
【課題】マスターノードに障害が発生した時に、マスター昇格可能なワーカーノードを自動的に選定可能なストレージシステムを提供する。
【解決手段】ストレージシステム１が備えるワーカーノードは、ワーカーノードの障害履歴及び稼働状況に基づいてワーカーノードのスコアを計算するスコア計算部３１を有し、マスターノード（Ｐ）は、マスターノードの一つに障害が発生した場合に、ワーカーノードごとにスコアを比較して、障害が発生したマスターノードに代えて、マスターノードに昇格させるワーカーノードをスコアに基づいて選定する昇格ノード選定部５２を有する。
【選択図】図７
【解決手段】ストレージシステム１が備えるワーカーノードは、ワーカーノードの障害履歴及び稼働状況に基づいてワーカーノードのスコアを計算するスコア計算部３１を有し、マスターノード（Ｐ）は、マスターノードの一つに障害が発生した場合に、ワーカーノードごとにスコアを比較して、障害が発生したマスターノードに代えて、マスターノードに昇格させるワーカーノードをスコアに基づいて選定する昇格ノード選定部５２を有する。
【選択図】図７
【特許請求の範囲】
【請求項1】
プロセッサと、メモリと、記憶装置と、を有する複数のストレージノードがネットワークで接続され、複数のストレージノードをマスターノードとし、残りの前記ストレージノードをワーカーノードとしてクラスターが構成されるストレージシステムであって、
前記ワーカーノードの前記プロセッサは、前記ワーカーノードの障害履歴及び稼働状況に基づいて前記ワーカーノードのスコアを計算するスコア計算部を有し、
前記マスターノードの前記プロセッサは、前記マスターノードの一つに障害が発生した場合に、前記ワーカーノードごとに前記スコアを比較して、障害が発生した前記マスターノードに代えて、前記マスターノードに昇格させる前記ワーカーノードを前記スコアに基づいて選定する昇格ノード選定部を有する
ストレージシステム。
前記ワーカーノードの前記プロセッサは、前記ワーカーノードの障害履歴及び稼働状況に基づいて前記ワーカーノードのスコアを計算するスコア計算部を有し、
前記マスターノードの前記プロセッサは、前記マスターノードの一つに障害が発生した場合に、前記ワーカーノードごとに前記スコアを比較して、障害が発生した前記マスターノードに代えて、前記マスターノードに昇格させる前記ワーカーノードを前記スコアに基づいて選定する昇格ノード選定部を有する
ストレージシステム。
【請求項2】
前記マスターノードの前記プロセッサは、前記昇格ノード選定部により選定された前記ワーカーノードを前記マスターノードに昇格させて、前記クラスターを再構成するマスター側再構成部を有する
請求項１に記載のストレージシステム。
請求項１に記載のストレージシステム。
【請求項3】
複数の前記マスターノードは、一定の冗長度により構成され、
前記昇格ノード選定部は、前記マスターノードの数が前記冗長度を確保できない場合に、前記マスターノードに昇格させる前記ワーカーノードを選定する
請求項２に記載のストレージシステム。
前記昇格ノード選定部は、前記マスターノードの数が前記冗長度を確保できない場合に、前記マスターノードに昇格させる前記ワーカーノードを選定する
請求項２に記載のストレージシステム。
【請求項4】
前記スコア計算部は、指標を分類した指標分類ごとに、前記ワーカーノードの前記障害履歴及び前記稼働状況を前記昇格ノード選定部が比較可能な情報として前記スコアを計算し、
前記マスターノードの前記メモリは、前記スコアの情報が前記ワーカーノードごと、かつ前記指標分類ごとに保存されるスコアテーブルを有する
請求項３に記載のストレージシステム。
前記マスターノードの前記メモリは、前記スコアの情報が前記ワーカーノードごと、かつ前記指標分類ごとに保存されるスコアテーブルを有する
請求項３に記載のストレージシステム。
【請求項5】
前記指標分類は、前記ワーカーノードの障害履歴の指標である本体障害、前記ワーカーノードが接続される前記ネットワークの障害履歴の指標であるネットワーク障害、前記ワーカーノードの稼働に関する指標である稼働時間、及び前記ワーカーノードの仮想化環境の状況に関する指標である仮想化状況のうち、少なくとも一つを含む
請求項４に記載のストレージシステム。
請求項４に記載のストレージシステム。
【請求項6】
前記昇格ノード選定部は、前記指標分類に規定される優先順位に従って、前記指標分類ごと、かつ複数の前記ワーカーノードごとに前記スコアを比較し、前記優先順位が高い前記指標分類のスコアが複数の前記ワーカーノードで同値であった場合に、次に前記優先順位が高い前記指標分類のスコアで比較する処理を繰り返し、前記指標分類が同じであって、前記スコアが高い前記ワーカーノードを選定する
請求項４に記載のストレージシステム。
請求項４に記載のストレージシステム。
【請求項7】
前記マスターノードの前記プロセッサは、前記ワーカーノードから受信した前記スコアの情報を前記スコアテーブルにより管理し、所定時間以上、前記スコアの情報を受信できない前記ワーカーノードの前記スコアを前記スコアテーブルから無効化するスコア管理部を有する
請求項４に記載のストレージシステム。
請求項４に記載のストレージシステム。
【請求項8】
前記マスター側再構成部は、障害が発生した前記マスターノードを前記クラスターから除き、前記マスターノードに昇格させる前記ワーカーノードの情報により、前記マスターノードとして管理する前記ストレージノードの情報を更新し、
前記マスターノードに昇格される前記ワーカーノードの前記プロセッサは、前記昇格ノード選定部の指示により、前記マスターノードとして稼働するために起動され、前記マスター側再構成部と同期して、前記マスターノードとして必要な情報を再構成するワーカー側再構成部を有する
請求項３に記載のストレージシステム。
前記マスターノードに昇格される前記ワーカーノードの前記プロセッサは、前記昇格ノード選定部の指示により、前記マスターノードとして稼働するために起動され、前記マスター側再構成部と同期して、前記マスターノードとして必要な情報を再構成するワーカー側再構成部を有する
請求項３に記載のストレージシステム。
【請求項9】
電源系統及びネットワークスイッチのうち、少なくとも一つを共有する複数の前記ストレージノードごとにフォールトドメインが設定され、
前記昇格ノード選定部は、前記フォールトドメインを単位として、前記マスターノードに昇格させる前記ワーカーノードを選定する
請求項３に記載のストレージシステム。
前記昇格ノード選定部は、前記フォールトドメインを単位として、前記マスターノードに昇格させる前記ワーカーノードを選定する
請求項３に記載のストレージシステム。
【請求項10】
前記昇格ノード選定部は、前記マスターノードが最も少ない前記フォールトドメインに含まれる前記ワーカーノードから、前記マスターノードに昇格させる前記ワーカーノードを選定する
請求項９に記載のストレージシステム。
請求項９に記載のストレージシステム。
【請求項11】
複数の前記マスターノードのうち、一つは現用系として用いられるプライマリと、残りは待機系として用いられるセカンダリとして構成され、
前記プライマリとして構成される前記マスターノードが、前記ワーカーノードから前記スコアの情報を受信し、前記セカンダリとして構成される前記マスターノードに前記スコアの情報を反映する
請求項３に記載のストレージシステム。
前記プライマリとして構成される前記マスターノードが、前記ワーカーノードから前記スコアの情報を受信し、前記セカンダリとして構成される前記マスターノードに前記スコアの情報を反映する
請求項３に記載のストレージシステム。
【請求項12】
プロセッサと、メモリと、記憶装置と、を有する複数のストレージノードがネットワークで接続され、複数のストレージノードをマスターノードとし、残りの前記ストレージノードをワーカーノードとしてクラスターが構成されるストレージシステムで行われるストレージ管理方法であって、
前記ワーカーノードの前記プロセッサが、前記ワーカーノードの障害履歴及び稼働状況に基づいて前記ワーカーノードのスコアを計算するステップと、
前記マスターノードの前記プロセッサが、前記マスターノードの一つに障害が発生した場合に、前記ワーカーノードごとに前記スコアを比較して、障害が発生した前記マスターノードに代えて、前記マスターノードに昇格させる前記ワーカーノードを前記スコアに基づいて選定する前記ワーカーノードを前記スコアに基づいて選定するステップと、を含む
ストレージノード管理方法。
前記ワーカーノードの前記プロセッサが、前記ワーカーノードの障害履歴及び稼働状況に基づいて前記ワーカーノードのスコアを計算するステップと、
前記マスターノードの前記プロセッサが、前記マスターノードの一つに障害が発生した場合に、前記ワーカーノードごとに前記スコアを比較して、障害が発生した前記マスターノードに代えて、前記マスターノードに昇格させる前記ワーカーノードを前記スコアに基づいて選定する前記ワーカーノードを前記スコアに基づいて選定するステップと、を含む
ストレージノード管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ストレージシステム及びストレージノード管理方法に関する。
【背景技術】
【0002】
従来のサーバークラスター技術では、全サーバー台数のうち故障台数が閾値を越えるまではフェイルオーバを繰り返しながらシステムの運用を継続し、サーバー故障台数が閾値を超えた時点でシステム全体を一時停止してサーバー交換等の保守作業を実施している。
【0003】
多数のストレージノード（以下、「ノード」と略称）で構成されるＳＤＳ（Software Defined Storage）等のストレージシステムでは、可用性及び信頼性向上のため異なるサーバー筐体にデータの複製を格納する冗長化構成での運用を行っている。ＳＤＳとは、ストレージ機能を有するソフトウェアを汎用のサーバー装置に実装することにより構築されるストレージ装置のことである。また、ストレージノードとは、ＣＰＵ（Central Processing Unit）、メモリ、ドライブが割り当てられた物理サーバー又は仮想サーバーである。
【0004】
ＳＤＳでは、各ノードが他の複数のノードと共にストレージクラスター（以下、「クラスター」と略称）と呼ぶグループにまとめて管理される。クラスターは、複数のストレージノードから構築される、仮想的なストレージシステムである。クラスターではノードを協調動作させるためのCoordination ServiceやScale-out DBが動作している。協調動作とは、クラスター内の各ノードの動作を確認したり、ノードごとに用いられる情報を管理したりする処理である。クラスター内のマスターの役割を持つノード（マスターノードと呼ぶ）は、ノクラスター内の各ノードを協調動作させる機能を持つ。
【0005】
特許文献１には、「ストレージノードに発生した第１の障害にかかる第１の障害情報を取得し、ストレージノード管理情報に基づいて、第１の障害情報に対するストレージシステムの構成のリビルド時間と、さらに第２の障害が発生する障害発生確率を計算し、リビルド時間と障害発生確率を用いて、障害が発生してストレージシステムが停止となる状態へ遷移する確率を可用性レベルとして計算し、可用性レベルに基づいて、保守作業の要否を報知する。」と記載されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特許第６８５０７７１号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
クラスターでは、マスターノードの数が一定数を下回ると協調動作の機能が正常に動作しなくなる。このため、クラスター内では常に複数のマスターノードを確保して、マスターノードを冗長化した構成としている。マスターノードに障害が発生した場合には、マスターノードの数を保つために新たなノードを、マスターノードとしてクラスターに参加させる運用が行われる。この運用において、新たなノードを構築する場合、手動の保守操作によって障害が発生したノードと、新たに構築したノードとを交換する方法がある。
【0008】
また、マスターノードに障害が発生した場合、稼働中のマスターノードではない他のノード（「ワーカーノード」と呼ぶ）をマスターノードへ昇格させるマスター昇格が行われる方法もとられる。このようにマスターノードではないクラスター内のワーカーノードをマスターノードに切り替えることを「マスター昇格」と呼ぶ。マスター昇格が行われる際には、クラスターの初期構築時に事前に設定したワーカーノードが昇格していた。
【0009】
ワーカーノードは、マスターノードに障害が発生した時点までの稼働実績を履歴として持っており、ワーカーノードごとに過去の障害発生回数や稼働時間などに差異がある。過去に多数の障害を起こしているノードがマスター昇格対象として選ばれると、マスター昇格後に障害が再発することが懸念される。しかし、従来は、ワーカーノードの稼働実績は、ユーザーが障害の内容を把握するために参照される用途しかなく、マスター昇格候補としてのワーカーノードを同列に扱うことしかできなかった。このため、ユーザーが多数のワーカーノードからマスター昇格させるために最適なワーカーノードを選定することは困難であった。
【0010】
本発明はこのような状況に鑑みて成されたものであり、マスター昇格の対象となるノードを自動的に選定することを目的とする。
【課題を解決するための手段】
【0011】
本発明に係るストレージシステムは、プロセッサと、メモリと、記憶装置と、を有する複数のストレージノードがネットワークで接続され、複数のストレージノードをマスターノードとし、残りのストレージノードをワーカーノードとしてクラスターが構成される。ワーカーノードのプロセッサは、ワーカーノードの障害履歴及び稼働状況に基づいてワーカーノードのスコアを計算するスコア計算部を有し、マスターノードのプロセッサは、マスターノードの一つに障害が発生した場合に、ワーカーノードごとにスコアを比較して、障害が発生したマスターノードに代えて、マスターノードに昇格させるワーカーノードをスコアに基づいて選定する昇格ノード選定部を有する。
【発明の効果】
【0012】
本発明によれば、マスター昇格の対象となるワーカーノードをスコアに基づいて自動的に選定することができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【0013】
【図1】本発明の一実施形態に係るストレージシステムの構成例を示す図である。
【図2】本発明の一実施形態に係るストレージノードの概略構成例を示すブロック図である。
【図3】マスター昇格候補のワーカーノードから選択した一つのノードをマスターノードに昇格する従来の方法の例を示す図である。
【図4】マスター昇格の前提となる考え方を示す図である。
【図5】マスター昇格させるワーカーノードを選択する従来の方法の例を示す図である。
【図6】本発明の一実施形態に係るクラスターのマスターノード及びワーカーノードの構成例を示す図である。
【図7】本発明の一実施形態に係るマスターノードとワーカーノードの内部構成例を示すブロック図である。
【図8】本発明の一実施形態に係る通信異常時にスコアテーブルに設定されるスコアの例を示す図である。
【図9】本発明の一実施形態に係るマスターノードに障害が発生した時のフォールトドメインの設定方法を示す図である。
【図10】本発明の一実施形態に係るワーカーノードの選定処理の例を示す図である。
【図11】本発明の一実施形態に係るワーカーノードのマスター昇格とグループ再構成処理の例を示す図である。
【図12】本発明の一実施形態に係るマスター降格とスコアテーブルの更新処理の例を示す図である。
【図13】本発明の一実施形態に係る指標管理テーブルの例を示す図である。
【図14】本発明の一実施形態に係る指標分類の優先順位管理テーブルの例を示す図である。
【図15】本発明の一実施形態に係るスコアテーブルの例を示す図である。
【図16】本発明の一実施形態に係る履歴管理テーブルの例を示す図である。
【図17】本発明の一実施形態に係るスコア計算表の例を示す図である。
【図18】本発明の一実施形態に係るスコア情報の例を示す図である。
【図19】本発明の一実施形態に係るスコア計算に関わる処理の例を示すフローチャートである。
【図20】本発明の一実施形態に係るマスターノード（Ｐ）とワーカーノードの処理の関係を示すシーケンス図である。
【図21】本発明の一実施形態に係る障害発生からマスター昇格完了までの処理の例を示すフローチャートである。
【図22】本発明の一実施形態に係るマスターノード（Ｐ）とワーカーノードの処理の関係を示すシーケンス図である。
【図23】本発明の一実施形態に係る通知画面の表示例を示す図である。
【発明を実施するための形態】
【0014】
以下、本発明を実施するための形態について、添付図面を参照して説明する。本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。
【0015】
以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、少なくとも１以上のプロセッサ（例えば、ＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。
【0016】
同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノード、ストレージシステム、ストレージ装置、サーバー、管理計算機、クライアント、又は、ホストであってもよい。プログラムを実行して行う処理の主体（例えばプロセッサ）は、処理の一部又は全部を行うハードウェア回路を含んでもよい。例えば、プログラムを実行して行う処理の主体は、暗号化及び復号化、又は圧縮及び伸張を実行するハードウェア回路を含んでもよい。プロセッサは、プログラムに従って処理することによって、所定の機能を実現する機能部として動作する。プロセッサを含む装置及びシステムは、これらの機能部を含む装置及びシステムである。
【0017】
プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバー又は計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバーの場合、プログラム配布サーバーはプロセッサ（例えばＣＰＵ）と記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバーのプロセッサが配布プログラムを実行することで、プログラム配布サーバーのプロセッサは配布対象のプログラムを他の計算機に配布してもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
【0018】
［一実施形態］
図１は、本発明の一実施形態に係るストレージシステム１の構成例を示す図である。
ストレージシステム１は、複数のコンピュートノード２（１）～２（３）と、複数のストレージノード３（１）～３（３）によって構成される。なお、コンピュートノード２（１）～２（３）の個々を特定しない場合には符号「２」を用いる。また、ストレージノード３（１）～３（３）の個々を特定しない場合には符号「３」を用いる。その他の構成要素の符号についても同様である。
図１は、本発明の一実施形態に係るストレージシステム１の構成例を示す図である。
ストレージシステム１は、複数のコンピュートノード２（１）～２（３）と、複数のストレージノード３（１）～３（３）によって構成される。なお、コンピュートノード２（１）～２（３）の個々を特定しない場合には符号「２」を用いる。また、ストレージノード３（１）～３（３）の個々を特定しない場合には符号「３」を用いる。その他の構成要素の符号についても同様である。
【0019】
各コンピュートノード２及び各ストレージノード３の間は、例えばファイバーチャネル（Fibre Channel）、イーサネット（登録商標）、ＩｎｆｉｎｉＢａｎｄ又は無線ＬＡＮ（Local Area Network）などから構成されるストレージサービスネットワーク４を介して接続される。
各ストレージノード３の間は、ＬＡＮ、イーサネット（登録商標）、ＩｎｆｉｎｉＢａｎｄ又は無線ＬＡＮなどから構成されるバックエンドネットワーク５を介して接続されている。
各ストレージノード３の間は、ＬＡＮ、イーサネット（登録商標）、ＩｎｆｉｎｉＢａｎｄ又は無線ＬＡＮなどから構成されるバックエンドネットワーク５を介して接続されている。
【0020】
ただし、ストレージサービスネットワーク４及びバックエンドネットワーク５が同一のネットワークにより構成されていてもよく、また各コンピュートノード２及び各ストレージノード３がストレージサービスネットワーク４やバックエンドネットワーク５以外の管理用ネットワークに接続されていてもよい。
【0021】
コンピュートノード２は、ストレージノード３に対してホスト（上位装置）として機能する汎用のコンピュータ装置である。なお、コンピュートノード２は仮想マシンのような仮想的なコンピュータ装置であってもよい。コンピュートノード２は、ユーザーの操作や実装されたアプリケーションプログラムからの要求に応じて、ストレージサービスネットワーク４を介してストレージノード３にデータを読み書きする。
【0022】
ストレージノード３は、コンピュートノード２に対してデータを読み書きするための記憶領域を提供するサーバー装置である。ストレージノード３は、仮想マシンであってもよい。またストレージノード３がコンピュートノード２と同一の物理ノードに同居する構成であってもよい。
【0023】
本実施形態に係る各ストレージノード３は、図１に示すように、他の１又は複数のストレージノード３と共にクラスター６と呼ぶグループにまとめられて管理される。図１の例では、クラスター６が１つ設定された場合について例示しているが、ストレージシステム１内に複数のクラスター６を設けてもよい。クラスター６は、分散ストレージシステムと呼ばれてもよい。
【0024】
図２は、ストレージノード３の概略構成例を示すブロック図である。
ストレージノード３は、図２に示すように、１以上のＣＰＵ１０と、１以上のメモリ１１及び複数の記憶装置１２と、第１の通信装置１３及び第２の通信装置１４とを含む。ストレージノード３は、ＣＰＵ１０及び記憶装置１２と、第１の通信装置１３及び第２の通信装置１４とが内部ネットワーク１５を介して接続された汎用の物理サーバー装置から構成される。
ストレージノード３は、図２に示すように、１以上のＣＰＵ１０と、１以上のメモリ１１及び複数の記憶装置１２と、第１の通信装置１３及び第２の通信装置１４とを含む。ストレージノード３は、ＣＰＵ１０及び記憶装置１２と、第１の通信装置１３及び第２の通信装置１４とが内部ネットワーク１５を介して接続された汎用の物理サーバー装置から構成される。
【0025】
ＣＰＵ１０は、ストレージノード３全体の制御を司るプロセッサである。またメモリ１１は、ＳＲＡＭ（Static RAM(Random Access Memory)）やＤＲＡＭ（Dynamic RAM）などの揮発性の半導体メモリや、不揮発性の半導体メモリから構成され、ＣＰＵ１０のワークメモリとして各種プログラムや必要なデータを一時的に保持するために利用される。メモリ１１に格納されたプログラムを、少なくとも１以上のＣＰＵ１０が実行することにより、後述のようなストレージノード３全体としての各種処理が実行される。
【0026】
記憶装置１２は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）又はＳＣＭ（Storage Class Memory）などの大容量の不揮発性の記憶装置から構成され、ＮＶＭｅ（Non-Volatile Memory Express）やＳＡＳ（Serial Attached SCSI(Small Computer System Interface)）、ＳＡＴＡ（Serial ATA(Advanced Technology Attachment)）などのインタフェースで接続され、コンピュートノード２からのリード要求やライト要求に応じてデータを読み書きするための記憶領域を提供する。
【0027】
第１の通信装置１３は、ストレージノード３がストレージサービスネットワーク４を介してコンピュートノード２と通信を行うためのインタフェースであり、例えばファイバーチャネルカードやイーサネット（登録商標）カード、ＩｎｆｉｎｉＢａｎｄカード、無線ＬＡＮカードなどから構成される。第１の通信装置１３は、コンピュートノード２との通信時におけるプロトコル制御を行う。
【0028】
第２の通信装置１４は、ストレージノード３がバックエンドネットワーク５を介して他のストレージノード３と通信を行うためのインタフェースであり、例えばファイバーチャネルカードやイーサネット（登録商標）カード、ＩｎｆｉｎｉＢａｎｄカード、無線ＬＡＮカード、ＰＣＩｅホストアダプタなどから構成される。第２の通信装置１４は、他のストレージノード３との通信時におけるプロトコル制御を行う。
【0029】
本実施形態に係る各ストレージノード３は、図１に示すように、他の一又は複数のストレージノード３と共に、クラスター６と呼ぶグループにまとめられて管理される。図１の例では、クラスター６が１つのみ設定された場合について例示しているが、ストレージシステム１内に複数のクラスター６を設けてもよい。
【0030】
＜従来のマスター昇格方法＞
ここで、従来のマスター昇格方法について、図３を参照して説明する。
図３は、マスター昇格候補のワーカーノードから選択した一つのノードをマスターノードに昇格する従来の方法の例を示す図である。
ここで、従来のマスター昇格方法について、図３を参照して説明する。
図３は、マスター昇格候補のワーカーノードから選択した一つのノードをマスターノードに昇格する従来の方法の例を示す図である。
【0031】
図３のノード構成図（１）に示すように、クラスター６は、マスター及びワーカーの複数のノード全体を指す６個のストレージノード３を含んで構成され、ストレージクラスターの一例として用いられる。各ストレージノード３には、Node1～Node6とノード名が付けられており、以下の説明ではノード名を用いることがある。Node1～Node3はマスターノードであり、Node4～Node6はワーカーノードである。マスターノードは、クラスター６全体を管理する役割を持つクラスター６内にあるストレージノードのことである。また、ワーカーノードは、マスターノードではないクラスター６内のノードである。マスターノードとワーカーノードは、いずれも常に稼働するノードである。
【0032】
クラスター６では、複数のマスターノードのうち、一つは現用系として用いられるプライマリとして構成され、残りは待機系として用いられるセカンダリとして構成される。例えば、マスターノードであるNode1～Node3のうち、Node1はプライマリであり、Node2とNode3はセカンダリである。現用系のマスターノードに問題が発生した時には、セカンダリのマスターノードがプライマリの機能を引き継ぐ。以下の説明では、プライマリのマスターノードをマスターノード（Ｐ）と呼び、セカンダリのマスターノードをマスターノード（Ｓ）と呼ぶ。図中では、マスターノード（Ｐ）を「Master(P)」と記載し、マスターノード（Ｓ）を「Master(S)」と記載している。
【0033】
マスターノードであるNode1～Node3では、Storage Software、Coordination Service、Scale-out DBが稼働している。
【0034】
Storage Softwareは、クラスター６を実現するソフトウェアプログラムである。
Coordination Serviceは、クラスター６内の協調動作を制御するソフトウェアプログラムである。Coordination Serviceは、分散している一又は複数のストレージノードを一つのクラスター６として動作させるための基盤として用いられる。Coordination Serviceは、本実施形態に係る処理の基盤である。他にも、Coordination Serviceは、ストレージノード間での死活監視、及び複数のストレージノード３間のプロセス通信等を実現するためにも使用されている。
Coordination Serviceは、クラスター６内の協調動作を制御するソフトウェアプログラムである。Coordination Serviceは、分散している一又は複数のストレージノードを一つのクラスター６として動作させるための基盤として用いられる。Coordination Serviceは、本実施形態に係る処理の基盤である。他にも、Coordination Serviceは、ストレージノード間での死活監視、及び複数のストレージノード３間のプロセス通信等を実現するためにも使用されている。
【0035】
Scale-out DBは、クラスター６内の情報を冗長化しつつ管理するデータベースである。Scale-out DBは、マスターノード（Ｐ）及びマスターノード（Ｓ）だけで冗長化して実行されており、ワーカーノードでは実行されない。このため、一つのマスターノード（Ｓ）に障害が発生しても、他のマスターノード（Ｓ）とマスターノード（Ｐ）のScale-out DBが実行されているため、Scale-out DBの内容が損なわれない。
【0036】
ワーカーノードであるNode4～Node6では、Storage Softwareだけが稼働している。マスターノードの一つ（例えば、Node3）に障害が発生した場合には、Node4～Node6のうちの一つが、マスター昇格の候補となる。
【0037】
図３のノード構成図（２）に示すように、障害が発生したNode3はクラスター６の構成から切り離される。そして、ワーカーノードであったNode4がマスター昇格し、Storage Softwareに加えて、Coordination Service、Scale-out DBが稼働し始める。マスター昇格したNode4は、マスターノード（Ｓ）として用いられる。
【0038】
図４は、マスター昇格の前提となる考え方を示す図である。ここでは、前提１と前提２に分けて、マスター昇格について説明する。
【0039】
（前提１）
マスターノードの過半数が閉塞してしまうとクラスター６が正しく動作できなくなる。図４のノード構成図（１）に示すように、３台のマスターノード（Node1～Node3）のうち、１台のマスターノード（Node3）に障害が発生したまま放置すると、別のマスターノードに障害が発生した時に、マスターノードの過半数（３台中の２台）が閉塞してしまう。このためマスターノードの台数は、３台又は５台の冗長度で構成されることが望ましい。
マスターノードの過半数が閉塞してしまうとクラスター６が正しく動作できなくなる。図４のノード構成図（１）に示すように、３台のマスターノード（Node1～Node3）のうち、１台のマスターノード（Node3）に障害が発生したまま放置すると、別のマスターノードに障害が発生した時に、マスターノードの過半数（３台中の２台）が閉塞してしまう。このためマスターノードの台数は、３台又は５台の冗長度で構成されることが望ましい。
【0040】
（前提２）
前提１で説明したように、１台のマスターノード（Node3）に障害が発生すると、図４のノード構成図（２）に示すように、ワーカーノードのうち１台（例えば、Node6）をマスターノードへ昇格する。Node3の機能はNode6に引き継がれる。このマスター昇格が自動的に行われると、障害の発生していないマスターノードの数が３台となるため、マスターノードの冗長度を保ってクラスター６の稼働を継続できる。なお、Node6がマスター昇格した場合、ワーカーノードであるNode4, Node5では、Coordination ServiceやScale-out DBを起動させない。この理由として、マスターノードの数が多くなると、マスターノード間でＤＢ情報のレプリケーションに時間がかかることが挙げられる。稼働させるマスターノードの数を最小限とすることで、ＤＢ情報のレプリケーションにかかる時間が低減される。
前提１で説明したように、１台のマスターノード（Node3）に障害が発生すると、図４のノード構成図（２）に示すように、ワーカーノードのうち１台（例えば、Node6）をマスターノードへ昇格する。Node3の機能はNode6に引き継がれる。このマスター昇格が自動的に行われると、障害の発生していないマスターノードの数が３台となるため、マスターノードの冗長度を保ってクラスター６の稼働を継続できる。なお、Node6がマスター昇格した場合、ワーカーノードであるNode4, Node5では、Coordination ServiceやScale-out DBを起動させない。この理由として、マスターノードの数が多くなると、マスターノード間でＤＢ情報のレプリケーションに時間がかかることが挙げられる。稼働させるマスターノードの数を最小限とすることで、ＤＢ情報のレプリケーションにかかる時間が低減される。
【0041】
図５は、マスター昇格させるワーカーノードを選択する従来の方法の例を示す図である。
クラスター６には、マスター昇格候補として複数のワーカーノード（Node4～Node6）が含まれる。ユーザーは、複数のワーカーノードからマスター昇格に適したワーカーノードを選択する必要がある。
クラスター６には、マスター昇格候補として複数のワーカーノード（Node4～Node6）が含まれる。ユーザーは、複数のワーカーノードからマスター昇格に適したワーカーノードを選択する必要がある。
【0042】
上述したように、従来、ワーカーノードの稼働実績は障害発生時の解析等に用いられるだけであった。また、過去に障害が発生したストレージノードのリソース（主にハードウェア）の交換又は修理が行われると、交換又は修理された箇所に対応する稼働実績がリセットされていた。このため、ユーザーは、初期構築時以降のノードの稼働実績をマスター昇格対象の判断に活用できておらず、障害が再発しやすいノードをマスター昇格対象として選ぶことがあった。なお、図中のクエスチョンマークは、ワーカーノードであるNode4～Node6のいずれが選定されるかは不明であることを表している。
【0043】
一方、本実施形態では、ワーカーノードの障害履歴、及びワーカーノードの構成に基づいてスコアが自動的に計算され、スコアが高く、信頼性の高いワーカーノードが自動的に選定される。スコアとは、ストレージノードがこれまでどの程度安定して稼働してきたのかを示す値である。例えば、Node4のスコアが「70」であり、Node5のスコアが「80」であり、Node6のスコアが「90」であるとする。この場合、最もスコアの高いNode6がマスター昇格するノードとして選定される。
【0044】
＜本発明の一実施形態に係るノード構成例＞
図６は、本発明の一実施形態に係るクラスター６のマスターノード及びワーカーノードの構成例を示す図である。
図６は、本発明の一実施形態に係るクラスター６のマスターノード及びワーカーノードの構成例を示す図である。
【0045】
本実施形態に係るストレージシステム１は、図２に示したＣＰＵ１０と、メモリ１１と、記憶装置１２と、を有する複数のストレージノード３がノード間ネットワーク７で接続された構成としている。また、複数のストレージノード３をマスターノードとし、残りのストレージノード３をワーカーノードとしてクラスター６が構成される。複数のマスターノードは、一定の冗長度（例えば、３台又は５台）により構成されている。
【0046】
クラスター６は、図３のノード構成図（１）と同様に６個のストレージノード３（Node1～Node6）で構成される。図６に示すようにNode1～Node3はマスターノードであり、Node4～Node6はワーカーノードである。ストレージノード３に対する各種プログラムの初期インストール時は、ユーザーがマスターノードを指定する。ユーザーが指定しなかったノードはワーカーノードとして用いられる。初期インストールの完了後は、クラスター６内のストレージノード３のどれをマスターノードとし、どれをワーカーノードとするかが、マスターノードのScale-out DBによって管理される。なお、クラスター６は、６個より少ない数、又は６個より多い数のストレージノード３で構成されてもよい。
【0047】
クラスター６に含まれる全てのノードは、ノード間ネットワーク７によって接続され、ノード間ネットワーク７を介して各種のデータを互いに通信可能である。ノード間ネットワーク７は、図１に示したストレージサービスネットワーク４、バックエンドネットワーク５のいずれであってもよい。
【0048】
Node4～Node6は、クラスター６の構築完了時に初期スコアとして、それぞれスコアを計算する。クラスター６の初期構築時に計算される各ワーカーノードのスコアは、いずれも同じような値である。各ワーカーノードは、自ノードの合計スコアであるスコアをスコア情報２０（４）～２０（６）として、マスターノード（Ｐ）であるNode1に送信する。マスターノードであるNode1は、ノード間ネットワーク７を介して全てのワーカーノードから受信したスコア情報２０（４）～２０（６）をScale-out DB内のスコアテーブル４０に書きこみ、各ワーカーノードのスコアを管理する。スコア情報２０（４）～２０（６）の個々を特定しない場合には符号「２０」を用いる。クラスター６によりユーザーにサービスが提供される時間が長くなると、各ワーカーノードのスコアに違いが生じてくる。
【0049】
スコアテーブル４０は、マスターノード（Ｐ）が全てのワーカーノードのスコアをまとめて管理するためのテーブルである。スコアテーブル４０は、マスターノード（Ｐ）のScale-out DBによって管理される。このスコアテーブル４０には、分類Ａ，Ｂ，Ｃごとに計算されたスコアがワーカーノードごとに格納される。そして、Node1のマスターノードは、スコアテーブル４０を参照して、セカンダリノードの障害発生時にマスター昇格させるワーカーノードを選定する。マスター昇格候補となるストレージノード３は、Coordination ServiceやScale-out DBが設定されていない、リソースに余裕があるストレージノード（Node4, Node5, Node6）である。
【0050】
マスターノード（Ｐ）のScale-out DBと、マスターノード（Ｓ）のScale-out DBは、常に通信を行っている。そして、マスターノード（Ｐ）のScale-out DBの情報が更新されると、マスターノード（Ｓ）に更新内容が通知されて、マスターノード（Ｓ）のScale-out DBの情報が更新される。このため、マスターノード（Ｐ）のScale-out DBと、マスターノード（Ｓ）のScale-out DBは、同じ内容となる。この処理は、マスターノード（Ｐ）のCoordination Serviceと、マスターノード（Ｓ）のCoordination Serviceについても同様である。このため、マスターノード（Ｐ）が有するスコアテーブル４０がScale-out DBに構成されるのであれば、マスターノード（Ｓ）にスコアテーブル４０がコピーされることで、全てのマスターノードが同じスコアテーブル４０を有してもよい。この場合、マスターノード（Ｐ）は、ワーカーノードからスコア情報２０を受信し、スコアテーブル４０にスコア情報２０のスコアを反映する。その後、マスターノード（Ｓ）にスコアテーブル４０をコピーすることで、マスターノード（Ｐ）とマスターノード（Ｓ）のスコアテーブル４０が同期される。
【0051】
図７は、マスターノードとワーカーノードの内部構成例を示すブロック図である。図７では、マスターノードとしてNode1の例を示し、ワーカーノードとしてNode4の例を示す。他のマスターノードは、Node1と同様の構成としてあり、他のワーカーノードは、Node4と同様の構成としている。
【0052】
（ワーカーノード）
ワーカーノードであるストレージノード３（４）のメモリ１１は、スコア情報２０、履歴管理テーブル２１、スコア計算表２２及び構成情報２３を有する。スコア情報２０、履歴管理テーブル２１、スコア計算表２２及び構成情報２３は、いずれもワーカーノードのメモリ１１に、ワーカーノード独自のデータベースあるいはファイルとして保存される。これらの情報は、ワーカーノードの記憶装置１２に保存されてもよい。
ワーカーノードであるストレージノード３（４）のメモリ１１は、スコア情報２０、履歴管理テーブル２１、スコア計算表２２及び構成情報２３を有する。スコア情報２０、履歴管理テーブル２１、スコア計算表２２及び構成情報２３は、いずれもワーカーノードのメモリ１１に、ワーカーノード独自のデータベースあるいはファイルとして保存される。これらの情報は、ワーカーノードの記憶装置１２に保存されてもよい。
【0053】
スコア情報２０は、上述したようにワーカーノードからマスターノード（Ｐ）に送られるスコアを格納したデータである。スコア情報２０の詳細な構成例は、後述する図１８に示す。
【0054】
履歴管理テーブル２１は、ワーカーノード自身の障害履歴、稼働履歴等の履歴情報を管理するテーブルである。履歴管理テーブル２１の詳細な構成例は、後述する図１６に示す。
スコア計算表２２は、スコア計算部３１が自ノードのスコアを計算する時に参照される。スコア計算表２２には、指標毎にスコアの計算式が格納されている。スコア計算表２２の詳細な構成例は、後述する図１７に示す。
構成情報２３には、ワーカーノード自身のＣＰＵ１０のスペック、メモリ１１及び記憶装置１２の記憶容量、ワーカーノードにインストールされているプログラム等の情報が格納されている。
スコア計算表２２は、スコア計算部３１が自ノードのスコアを計算する時に参照される。スコア計算表２２には、指標毎にスコアの計算式が格納されている。スコア計算表２２の詳細な構成例は、後述する図１７に示す。
構成情報２３には、ワーカーノード自身のＣＰＵ１０のスペック、メモリ１１及び記憶装置１２の記憶容量、ワーカーノードにインストールされているプログラム等の情報が格納されている。
【0055】
ワーカーノードのＣＰＵ１０は、スコア計算部３１及びワーカー側グループ再構成部３２を有する。ワーカーノードのStorage Software（図６を参照）は、スコア計算部３１の機能を持つ。また、マスターノードとして起動する時には、ワーカーノードのCoordination Service及びScale-out DB（後述する図１１を参照）が、ワーカー側グループ再構成部３２の機能を持つ。
【0056】
スコア計算部３１は、ワーカーノードの障害履歴及び稼働状況に基づいてワーカーノードのスコアを計算する。例えば、スコア計算部３１は、指標を分類した指標分類ごとに、ワーカーノードの障害履歴及び稼働状況を、マスターノードの昇格ノード選定部５２が比較可能な情報として自身のスコアを計算する。スコアは、スコア計算部３１が履歴管理テーブル２１から読み出した履歴情報をスコア計算表２２の計算式に当てはめることで計算可能である。スコア計算部３１は、スコアの計算後、スコア情報２０にスコアを格納し、スコア情報２０をマスターノード（Ｐ）であるNode1に送信する。
【0057】
ワーカー側グループ再構成部３２は、昇格ノード選定部５２の指示により、自ノードをマスターノードとして稼働するために起動され、マスター側グループ再構成部５３と同期して、マスターノードとして必要な情報を再構成する。ワーカー側グループ再構成部３２は、自ノードがマスター昇格の対象になると、自ノードのCoordination Service、Scale-out DBが起動される。そして、自ノードのCoordination Service、Scale-out DBがそれぞれ有するワーカー側グループ再構成部３２の機能により、クラスター６におけるCoordination ServiceのグループとScale-out DBのグループが、マスターノードとして必要な情報として再構成される。この結果、自ノードがマスターノードとして稼働できるようになる。
【0058】
（マスターノード）
マスターノード（Ｐ）であるストレージノード３（１）のメモリ１１は、スコアテーブル４０、指標管理テーブル４１、優先順位管理テーブル４２を有する。これらのテーブルは、マスターノード（Ｐ）の記憶装置１２に保存されてもよい。
マスターノード（Ｐ）であるストレージノード３（１）のメモリ１１は、スコアテーブル４０、指標管理テーブル４１、優先順位管理テーブル４２を有する。これらのテーブルは、マスターノード（Ｐ）の記憶装置１２に保存されてもよい。
【0059】
スコアテーブル４０には、スコア情報２０から取り出されたスコアがワーカーノードごと、かつ指標分類ごとに保存される。そして、スコアテーブル４０は、クラスター６に構成される全てのワーカーノードのスコアをまとめて管理する。スコアテーブル４０のスコアは、スコア管理部５１によって追加、削除、又は更新される。スコアテーブル４０の詳細な構成例は、後述する図１５に示す。
【0060】
指標管理テーブル４１は、スコア計算に使用される指標を管理する。指標管理テーブル４１の詳細な構成例は、後述する図１３に示す。
優先順位管理テーブル４２は、指標分類の優先順位を管理するテーブルである。優先順位管理テーブル４２の詳細な構成例は、後述する図１４に示す。
優先順位管理テーブル４２は、指標分類の優先順位を管理するテーブルである。優先順位管理テーブル４２の詳細な構成例は、後述する図１４に示す。
【0061】
マスターノード（Ｐ）のＣＰＵ１０は、スコア管理部５１、昇格ノード選定部５２及びマスター側グループ再構成部５３を備える。マスターノード（Ｐ）のStorage Software（図６を参照）は、スコア管理部５１及び昇格ノード選定部５２の機能を持つ。また、マスターノード（Ｐ）のCoordination Service及びScale-out DB（図６を参照）は、マスター側グループ再構成部５３の機能を持つ。
【0062】
スコア管理部５１は、ワーカーノードから受信したスコア情報２０に基づいてスコアテーブル４０のスコアを更新する。また、スコア管理部５１は、ワーカーノードから受信したスコア情報２０をスコアテーブル４０により管理する。スコア管理部５１は、例えば、後述する図８に示すネットワーク障害により所定時間以上、スコア情報２０を受信できないワーカーノードのスコアをスコアテーブル４０から無効化することができる。
【0063】
昇格ノード選定部５２は、マスターノードの数が冗長度を確保できない場合に、マスターノードに昇格させるワーカーノードを選定する。例えば、昇格ノード選定部５２は、クラスター６を構成するマスターノードの一つに障害が発生した場合に、ワーカーノードごとにスコアを比較して、障害が発生したマスターノードに代えて、マスターノードに昇格させるワーカーノードをスコアに基づいて選定する。ここで、昇格ノード選定部５２は、指標管理テーブル４１及び優先順位管理テーブル４２を参照して、スコアテーブル４０に格納されるワーカーノードごとにスコアを比較し、最もスコアの高いワーカーノードを選択する。
【0064】
マスター側グループ再構成部５３は、障害が発生したマスターノードをクラスターノードから除き、昇格ノード選定部５２により選定されたワーカーノードをマスターノードに昇格させ、障害が発生したマスターノードをマスターから降格させる。マスター側グループ再構成部５３は、マスターノードに昇格させるワーカーノードの情報により、マスターノードとして管理するストレージノードの情報を更新することで、クラスター６におけるCoordination ServiceのグループとScale-out DBのグループを再構成する。クラスター６におけるCoordination ServiceのグループとScale-out DBのグループを再構成することを、「クラスター６を再構成する」とも呼ぶ。
【0065】
次に、ストレージシステム１のクラスター６で行われる各ノードの処理の概要と、スコアテーブル４０のスコアの変化について、各図を参照して説明する。
【0066】
＜通信異常時のスコアテーブル＞
図８は、通信異常時にスコアテーブル４０に設定されるスコアの例を示す図である。図８では、Node6にネットワーク断の障害が発生しており、マスターノード（Ｐ）と、Node6とが通信できないものとする。
図８は、通信異常時にスコアテーブル４０に設定されるスコアの例を示す図である。図８では、Node6にネットワーク断の障害が発生しており、マスターノード（Ｐ）と、Node6とが通信できないものとする。
【0067】
図６に示したように、マスターノード（Ｐ）であるNode1のスコアテーブル４０に各ワーカーノードのスコアが管理されている。スコアの計算は、上述したクラスター６の構築完了時の他、定期的に実行されたり、クラスター６の構成情報が変更されたりしたタイミングで実行される。また、スコア計算部３１は、１ノードあたりのスコアを分類ごとに計算する。スコアが計算された後、マスターノード（Ｐ）にスコア情報２０が送信される。
【0068】
マスターノード（Ｐ）であるNode1は、ワーカーノードからスコア情報２０を受信すると、Scale-out DB内のスコアテーブル４０を更新する。図８では、Node6にネットワーク断の障害が発生したことにより、Node1は、Node6からスコア情報２０を受信できない状態である。そこで、Node1のスコア管理部５１は、スコア情報２０を受信できないワーカーノードがあることを検出すると、このワーカーノードのスコアテーブル４０に保存されているスコアを「０」に設定する。スコアが「０」に設定されたワーカーノードは、一時的にマスター昇格の候補から外れる。このため、昇格ノード選定部５２が選定可能なマスター昇格の候補は、Node1がスコア情報２０を受信可能なNode4とNode5のワーカーノードのみとなる。
【0069】
＜フォールトドメイン＞
図９は、マスターノードに障害が発生した時のフォールトドメインの設定方法を示す図である。
図９は、マスターノードに障害が発生した時のフォールトドメインの設定方法を示す図である。
【0070】
フォールトドメインは、電源系統及びネットワークスイッチのうち、少なくとも一つを共有している複数のストレージノードごとに設定されるグループである。図９では、フォールトドメイン１に２つのマスターノードが含まれる構成としているが、この例は、マスターノードの初期インストール時にユーザーが自由に設定できるケースを想定したものである。図７に示した昇格ノード選定部５２は、フォールトドメインを単位として、マスターノードに昇格させるワーカーノードを選定する。例えば、クラスター６の内部処理であるマスター昇格の処理では、いずれのグルーピングにおいても障害点を共有しないように、マスターノードが分散配置される。昇格ノード選定部５２は、障害が発生したNode3と障害点を共有しないフォールトドメイン３に含まれるワーカーノードをマスター昇格の候補とする。
【0071】
図９には、２台のノードごとにフォールトドメイン１，２，３が設定された例が示される。例えば、フォールトドメイン１は、Node1とNode2がグルーピングして構成される。フォールトドメイン２は、Node3とNode4がグルーピングして構成される。フォールトドメイン３は、Node5とNode6がグルーピングして構成される。
【0072】
マスターノード（Ｐ）であるNode1の昇格ノード選定部５２は、フォールトドメインごとにマスターノードの数を計算する。ただし、この計算では、障害が発生したノードを計上しない。この結果、フォールトドメイン１の障害が発生していないマスターノードの数は２台と計算される。また、フォールトドメイン３の障害が発生していないワーカーノードの数は２台と計算される。一方、Node3に障害が発生したことから、フォールトドメイン２の障害が発生していないマスターノードの数は１台と計算される。
【0073】
Node1で稼働する昇格ノード選定部５２は、マスターノードの数が最も少ないフォールトドメインに含まれるワーカーノードから、マスターノードに昇格させるワーカーノードを選定する。複数のフォールトドメインでマスターノードの数が０であった場合、昇格ノード選定部５２は、複数のフォールトドメインを、マスターノードに昇格させるワーカーノードの選択範囲としてもよい。
【0074】
上述したようにフォールトドメインは、電源系統及びネットワークスイッチを共有しているので、例えば、Node3にハードウェア障害が発生した場合、Node3の修理又は撤去のために、Node4に電圧変動の影響が及ぶことが予想される。このような場合、昇格ノード選定部５２は、各ワーカーノードのうち、Node4のスコアが最も高かったとしても、Node4の優先順位を下げてもよい。一つのフォールトドメインに複数のマスターノードが配置されると、いずれかのマスターノードで発生した障害の影響が、同じフォールトドメインの他のマスターノードに波及する。このため、昇格ノード選定部５２は、異なるフォールトドメインにマスターノードを分散配置することで、いずれかのノードで発生した障害の影響が他のノードの波及することを防ぐ。
【0075】
＜ワーカーの選定処理＞
図１０は、ワーカーノードの選定処理の例を示す図である。ワーカーノードの選定処理は、マスターノードに障害が発生した時に２段階で行われる。
図１０は、ワーカーノードの選定処理の例を示す図である。ワーカーノードの選定処理は、マスターノードに障害が発生した時に２段階で行われる。
【0076】
（選定処理の１段階目）
図１０のノード構成図（１）には、ワーカーノードの選定処理の１段階目の様子が示される。マスターノード（Ｐ）であるNode1の昇格ノード選定部５２は、自ノードのScale-out DBに保存されているスコアテーブル４０を基に、最もスコアの高いワーカーノードをマスター昇格先として選択する。ただし、スコアテーブル４０に保存された分類Ａのスコアは、Node5とNode6で同じ「30」とする。なお、マスターノード（Ｐ）に障害が発生した場合は、マスターノード（Ｓ）をプライマリに昇格させるマスター昇格が行われた後に、ワーカーノードの選定処理が実行開始される。
図１０のノード構成図（１）には、ワーカーノードの選定処理の１段階目の様子が示される。マスターノード（Ｐ）であるNode1の昇格ノード選定部５２は、自ノードのScale-out DBに保存されているスコアテーブル４０を基に、最もスコアの高いワーカーノードをマスター昇格先として選択する。ただし、スコアテーブル４０に保存された分類Ａのスコアは、Node5とNode6で同じ「30」とする。なお、マスターノード（Ｐ）に障害が発生した場合は、マスターノード（Ｓ）をプライマリに昇格させるマスター昇格が行われた後に、ワーカーノードの選定処理が実行開始される。
【0077】
（選定処理の２段階目）
図１０のノード構成図（２）には、ワーカーノードの選定処理の２段階目の様子が示される。スコアは優先度ごとに分類されており上位のスコアからの比較処理が実施される。昇格ノード選定部５２は、指標分類に規定される優先順位に従って、指標分類ごと、かつ複数のワーカーノードごとにスコアを比較する。そして、昇格ノード選定部５２は、優先順位が高い指標分類のスコアが複数のワーカーノードで同値であった場合に、次に優先順位が高い指標分類のスコアで比較する処理を繰り返し、指標分類が同じであって、スコアが高いワーカーノードを選定する。例えば、ある分類のスコアが同率（同値あるいは僅差）である場合は、優先度が低い別の分類のスコアが比較に使用される。上述したように、分類Ａのスコアは、Node5とNode6で同じであったため、次に、分類Ｂのスコアが比較される。
図１０のノード構成図（２）には、ワーカーノードの選定処理の２段階目の様子が示される。スコアは優先度ごとに分類されており上位のスコアからの比較処理が実施される。昇格ノード選定部５２は、指標分類に規定される優先順位に従って、指標分類ごと、かつ複数のワーカーノードごとにスコアを比較する。そして、昇格ノード選定部５２は、優先順位が高い指標分類のスコアが複数のワーカーノードで同値であった場合に、次に優先順位が高い指標分類のスコアで比較する処理を繰り返し、指標分類が同じであって、スコアが高いワーカーノードを選定する。例えば、ある分類のスコアが同率（同値あるいは僅差）である場合は、優先度が低い別の分類のスコアが比較に使用される。上述したように、分類Ａのスコアは、Node5とNode6で同じであったため、次に、分類Ｂのスコアが比較される。
【0078】
図１１は、ワーカーノードのマスター昇格とグループ再構成処理の例を示す図である。ワーカーノードがマスター昇格した後、Coordination ServiceのグループとScale-out DBのグループが再構成される様子が示される。
【0079】
図１１のノード構成図（１）には、マスター昇格先として選定されたワーカーノードのNode6にて、Coordination ServiceとScale-out DBが起動される様子が示される。Coordination ServiceとScale-out DBが起動されることで、Node6がマスター昇格する準備が整う。
【0080】
図１１のノード構成図（２）には、グループ再構成の様子が示される。Node6で起動したCoordination Serviceのグループは、ワーカー側グループ再構成部３２により再構成される。Coordination Serviceのグループとは、協調動作を制御するマスターノード達の集合であり、全てのマスターノードが該当する。Coordination Serviceのグループ再構成により、障害が発生したマスターノードがCoordination Serviceのグループから除外され、マスター昇格先のノードがCoordination Serviceのグループに追加される。
【0081】
また、Scale-out DBのグループについても、ワーカー側グループ再構成部３２により再構成される。Scale-out DBのグループとは、Scale-out DBを操作するマスターノードの集合であり、全てのマスターノードが該当する。Scale-out DBのグループ再構成により、障害が発生したマスターノードがScale-out DBのグループから除外され、マスター昇格先のノードがScale-out DBのグループに追加される。
【0082】
図１２は、マスター降格とスコアテーブル４０の更新処理の例を示す図である。ここでは、Node３がマスターから降格された後、スコアテーブル４０が更新される様子が示される。
【0083】
図１２のノード構成図（１）には、障害が発生したマスターノードであるNode3がマスターから降格される様子が示される。昇格ノード選定部５２によってNode3がマスターから降格されると、Node3で稼働していたCoordination ServiceとScale-out DBが停止される。
【0084】
図１２のノード構成図（２）には、マスターノード（Ｐ）であるNode1がスコアテーブル４０を更新する様子が示される。上述したようにNode3がマスターから降格され、Node6がマスターに昇格されると、Node1のスコア管理部５１は、スコアテーブル４０から、マスター昇格先のNode6のエントリを削除する。その後、クラスター６が新たな構成で稼働する。なお、Node3のノードは、修理又は交換された後、再びクラスター６に組み込まれる。この場合、Node3のノードは、ワーカーノードとして稼働し、Node1のスコア管理部５１は、スコアテーブル４０にNode3のスコアを保存する。
【0085】
ここまで、マスターノード（Ｐ）が各ワーカーノードからスコア情報２０を集めてスコアを管理し、マスターノード（Ｓ）に障害が発生すると、マスター昇格を制御する形態について説明した。マスターノード（Ｐ）自体に障害が発生すると、マスター昇格の処理を実行する前に、マスターノード（Ｓ）の中から新たにマスターノード（Ｐ）を選出する処理が実行される。その後、新たに選出されたマスターノード（Ｐ）がマスター昇格の処理を主導する。
【0086】
図１３は、指標管理テーブル４１の例を示す図である。指標管理テーブル４１は、ワーカーノードの障害及び稼働状況に対応付けられた指標を管理するためのテーブルである。マスターノード自体は、スコアを計算しないが、ワーカーノードのスコア計算部３１がスコアを計算する時に参照する計算方式を指標管理テーブル４１に付して説明する。
【0087】
指標管理テーブル４１は、指標名称、指標分類、説明、計算方式の各項目で構成される。
指標名称項目には、ワーカーノードに発生する障害の名称、ワーカーノードの稼働状況等を表す指標の名称が格納される。
指標分類項目には、指標の種類を分類した指標分類が格納される。指標分類は、ワーカーノードの障害履歴の指標である本体障害、ワーカーノードが接続されるネットワークの障害履歴の指標であるネットワーク障害、ワーカーノードの稼働に関する指標である稼働時間、及びワーカーノードの仮想化環境の状況に関する指標である仮想化状況のうち、少なくとも一つを含む。ここでは、指標分類として、例えば、「Ａ：本体障害」、「Ｂ：ネットワーク（ＮＷ）障害」、「Ｃ：稼働時間」、「Ｄ：仮想化状況」の４種類を想定して説明する。
指標名称項目には、ワーカーノードに発生する障害の名称、ワーカーノードの稼働状況等を表す指標の名称が格納される。
指標分類項目には、指標の種類を分類した指標分類が格納される。指標分類は、ワーカーノードの障害履歴の指標である本体障害、ワーカーノードが接続されるネットワークの障害履歴の指標であるネットワーク障害、ワーカーノードの稼働に関する指標である稼働時間、及びワーカーノードの仮想化環境の状況に関する指標である仮想化状況のうち、少なくとも一つを含む。ここでは、指標分類として、例えば、「Ａ：本体障害」、「Ｂ：ネットワーク（ＮＷ）障害」、「Ｃ：稼働時間」、「Ｄ：仮想化状況」の４種類を想定して説明する。
【0088】
説明項目には、指標毎の説明が格納される。説明項目は、本明細書での理解を助けるために設けたものであり、実際の指標管理テーブル４１に説明項目は不要である。
計算方式項目には、指標毎の計算方式が格納される。
計算方式項目には、指標毎の計算方式が格納される。
【0089】
次に、指標管理テーブル４１に格納された指標名称、指標分類、説明、計算方式について、順に説明する。
【0090】
（＃１：ユーザーデータドライブ障害）
ユーザーデータドライブ障害の指標分類は「Ａ：本体障害」であり、説明は「ユーザーデータを保存するドライブの障害履歴をスコアに反映すること」である。計算方式は、１か月あたりのドライブ閉塞回数の平均値をxとした場合に、以下のように求められる。
x = 0 ...スコア=3
0 < x ≦ 1回 ...スコア=2
1回 < x ≦ 5回 ...スコア=1
5回 ≦ x ...スコア=0
ユーザーデータドライブ障害の指標分類は「Ａ：本体障害」であり、説明は「ユーザーデータを保存するドライブの障害履歴をスコアに反映すること」である。計算方式は、１か月あたりのドライブ閉塞回数の平均値をxとした場合に、以下のように求められる。
x = 0 ...スコア=3
0 < x ≦ 1回 ...スコア=2
1回 < x ≦ 5回 ...スコア=1
5回 ≦ x ...スコア=0
【0091】
（＃２：ノード閉塞）
ノード閉塞の指標分類は「Ａ：本体障害」であり、説明は「ソフトウェア障害やハードウェア障害によってノードとして稼働できなくなった履歴をスコアに反映すること」である。計算方式は、１か月あたりのノード閉塞回数の平均値をxとした場合に、以下のように求められる。
0 = x ...スコア=3
0 < x ≦ 3回 ...スコア=2
3回 < x ≦ 10回 ...スコア=1
10回 ≦ x ...スコア=0
ノード閉塞の指標分類は「Ａ：本体障害」であり、説明は「ソフトウェア障害やハードウェア障害によってノードとして稼働できなくなった履歴をスコアに反映すること」である。計算方式は、１か月あたりのノード閉塞回数の平均値をxとした場合に、以下のように求められる。
0 = x ...スコア=3
0 < x ≦ 3回 ...スコア=2
3回 < x ≦ 10回 ...スコア=1
10回 ≦ x ...スコア=0
【0092】
（＃３：Compute Network障害）
Compute Network障害の指標分類は「B : NW障害」であり、説明は「ユーザーデータの読み書きに関するデータ送信の再送要求回数をスコアに反映すること」である。計算方式は、ユーザーデータの読み書き（IO:Input/Output）の１回あたりの再送要求回数の平均値をxとした場合に、以下のように求められる。
x < 10 ...スコア=3
10回 < x ≦ 100回 ...スコア=2
100回< x ≦ 700回...スコア=1
700回< x ...スコア=0
Compute Network障害の指標分類は「B : NW障害」であり、説明は「ユーザーデータの読み書きに関するデータ送信の再送要求回数をスコアに反映すること」である。計算方式は、ユーザーデータの読み書き（IO:Input/Output）の１回あたりの再送要求回数の平均値をxとした場合に、以下のように求められる。
x < 10 ...スコア=3
10回 < x ≦ 100回 ...スコア=2
100回< x ≦ 700回...スコア=1
700回< x ...スコア=0
【0093】
（＃４：Inter-Node Network障害）
Inter-Node Network障害の指標分類は「B : NW障害」であり、説明は「ノード間通信の再送要求回数をスコアに反映すること」である。計算方式は、ノード間通信１回あたりの再送要求回数の平均値をxとした場合に、以下のように求められる。
x = 0 ...スコア=2
0 < x ≦ 1回 ...スコア=1
3回 < x ≦ ...スコア=0
Inter-Node Network障害の指標分類は「B : NW障害」であり、説明は「ノード間通信の再送要求回数をスコアに反映すること」である。計算方式は、ノード間通信１回あたりの再送要求回数の平均値をxとした場合に、以下のように求められる。
x = 0 ...スコア=2
0 < x ≦ 1回 ...スコア=1
3回 < x ≦ ...スコア=0
【0094】
（＃５：Management Network障害）
Management Network障害の指標分類は「B : NW障害」であり、説明は「ユーザーからの管理操作に関する通信の再送要求回数をスコアに反映すること」である。計算方式は、管理操作のための通信１回あたりの再送要求回数の平均値をxとした場合に、以下のように求められる。
x = 0 ...スコア=2
0 < x ≦ 1回 ...スコア=1
3回 < x ≦ ...スコア=0
Management Network障害の指標分類は「B : NW障害」であり、説明は「ユーザーからの管理操作に関する通信の再送要求回数をスコアに反映すること」である。計算方式は、管理操作のための通信１回あたりの再送要求回数の平均値をxとした場合に、以下のように求められる。
x = 0 ...スコア=2
0 < x ≦ 1回 ...スコア=1
3回 < x ≦ ...スコア=0
【0095】
（＃６：ノードが動作している物理サーバーの稼働時間）
ノードが動作している物理サーバーの稼働時間の指標分類は「C : 稼働時間」であり、説明は「ノードの稼働時間の短さをスコアに反映すること」である。計算方式は、稼働時間の平均値をxとした場合に、以下のように求められる。
x ⊂ {初期故障期} ...スコア=1
x ⊂ {偶発故障期} ...スコア=2
x ⊂ {摩耗故障期} ...スコア=0
ノードが動作している物理サーバーの稼働時間の指標分類は「C : 稼働時間」であり、説明は「ノードの稼働時間の短さをスコアに反映すること」である。計算方式は、稼働時間の平均値をxとした場合に、以下のように求められる。
x ⊂ {初期故障期} ...スコア=1
x ⊂ {偶発故障期} ...スコア=2
x ⊂ {摩耗故障期} ...スコア=0
【0096】
（＃７：物理サーバー上のドライブの稼働時間）
物理サーバー上のドライブの稼働時間の指標分類は「C : 稼働時間」であり、説明は「ドライブの稼働時間の短さをスコアに反映すること」である。計算方式は、稼働時間の平均値をxとした場合に、以下のように求められる。
x ⊂ {初期故障期} ...スコア=1
x ⊂ {偶発故障期} ...スコア=2
x ⊂ {摩耗故障期} ...スコア=0
物理サーバー上のドライブの稼働時間の指標分類は「C : 稼働時間」であり、説明は「ドライブの稼働時間の短さをスコアに反映すること」である。計算方式は、稼働時間の平均値をxとした場合に、以下のように求められる。
x ⊂ {初期故障期} ...スコア=1
x ⊂ {偶発故障期} ...スコア=2
x ⊂ {摩耗故障期} ...スコア=0
【0097】
（＃８：(仮想化環境)リソースの共有状況）
(仮想化環境)リソースの共有状況の指標分類は「D : 仮想化状況」であり、説明は「物理CPUを共有する他のVM（Virtual Machine）によって奪われた処理時間をスコアに反映すること」である。計算方式は、一定期間における、VMがCPU割り当て待ちとなった時間割合の平均値をxとした場合に、以下のように求められる。
x ≦ 10% ...スコア=2
10% < x ≦ 30% ...スコア=1
30% < x ...スコア=0
(仮想化環境)リソースの共有状況の指標分類は「D : 仮想化状況」であり、説明は「物理CPUを共有する他のVM（Virtual Machine）によって奪われた処理時間をスコアに反映すること」である。計算方式は、一定期間における、VMがCPU割り当て待ちとなった時間割合の平均値をxとした場合に、以下のように求められる。
x ≦ 10% ...スコア=2
10% < x ≦ 30% ...スコア=1
30% < x ...スコア=0
【0098】
図１４は、優先順位管理テーブル４２の例を示す図である。優先順位管理テーブル４２には、指標管理テーブルの優先順位が格納される。優先順位管理テーブル４２は、スコア管理部５１がマスターノード（Ｐ）が指標分類の優先順位に応じてスコアを比較する時に使用される。
【0099】
優先順位管理テーブル４２は、指標分類、指標分類の優先順位を変動させる動機の例の各項目で構成される。
指標分類の項目には、上述したＡ～Ｄの指標分類が格納される。
指標分類の優先順位を変動させる動機の例の項目には、優先順位が変動させる時の条件が格納される。以下に、指標分類ごとに優先順位を変動させる動機の例について説明する。
指標分類の項目には、上述したＡ～Ｄの指標分類が格納される。
指標分類の優先順位を変動させる動機の例の項目には、優先順位が変動させる時の条件が格納される。以下に、指標分類ごとに優先順位を変動させる動機の例について説明する。
【0100】
指標分類が「A : 本体障害」の場合、優先順位を変動させる動機は、「ストレージノードとしての根幹機能に対する障害履歴であるため、常に高い優先度で比較されることを想定したもの」である。
指標分類が「B : NW障害」の場合、優先順位を変動させる動機は、「ネットワークインフラの管理がクラウドサービス側に依存しており、重要視しない場合は”B : NW障害”の優先順位を落とす」こととなる。
指標分類が「B : NW障害」の場合、優先順位を変動させる動機は、「ネットワークインフラの管理がクラウドサービス側に依存しており、重要視しない場合は”B : NW障害”の優先順位を落とす」こととなる。
【0101】
指標分類が「C : 稼働時間」の場合、優先順位を変動させる動機は、「サーバーを短い間隔でリプレースするため稼働時間を重視しない場合は、”C : 稼働時間”の優先順位を落とす」こととなる。
指標分類が「D : 仮想化状況」の場合、優先順位を変動させる動機は、「仮想化環境での構築ではあるがハードウェアリソースを分離した状態でクラスターを構築する場合は” D : 仮想化状況”の優先順位を落とす」こととなる。ただし、オンプレミス環境であれば、本指標分類「Ｄ」は用いられない。例えば、ベアメタルサーバー（物理サーバー）上での運用や、サーバー上でノードごとに仮想マシンを運用しているが、各仮想マシンがサーバーのハードウェアリソースを共有していないケースでは、「D:仮想化状況」の優先度が下げられる。
指標分類が「D : 仮想化状況」の場合、優先順位を変動させる動機は、「仮想化環境での構築ではあるがハードウェアリソースを分離した状態でクラスターを構築する場合は” D : 仮想化状況”の優先順位を落とす」こととなる。ただし、オンプレミス環境であれば、本指標分類「Ｄ」は用いられない。例えば、ベアメタルサーバー（物理サーバー）上での運用や、サーバー上でノードごとに仮想マシンを運用しているが、各仮想マシンがサーバーのハードウェアリソースを共有していないケースでは、「D:仮想化状況」の優先度が下げられる。
【0102】
図１５は、スコアテーブル４０の例を示す図である。ここでは、ワーカーノードを識別するためのワーカーノードＩＤが、Node1等の数字でなく、Node_A～Node_D等の英字で識別されているものとする。
【0103】
スコアテーブル４０は、ワーカーノードＩＤ、指標分類Ａスコア、指標分類Ｂスコア、指標分類Ｃスコア、指標分類Ｄスコア、最終更新時刻、更新者ノードＩＤの各項目で構成される。スコアテーブル４０では、ワーカーノードＩＤごとに計算された、指標分類ごとのスコアが格納されている。また、更新者ノードＩＤは、Node_Eであること、NodeEがスコアを最終更新した時刻が示される。
【0104】
図１６は、履歴管理テーブル２１の例を示す図である。履歴管理テーブル２１は、ワーカーノードが自ノードの障害に関する履歴を保持するために用いられるテーブルである。
【0105】
履歴管理テーブル２１は、指標名称、履歴、最終更新時刻の各項目で構成される。
指標名称の項目には、図１３に示した指標管理テーブル４１の指標名称と同じ名称が格納される。
履歴の項目には、ワーカーノードに発生した障害の履歴、及びワーカーノードの使用状況を表す履歴（稼働時間、リソースの共有状況等）等の、スコア計算部３１によるスコア計算の基となる各種指標の計測値が格納される。
最終更新時刻の項目には、履歴管理テーブル２１が更新された時刻が指標ごとに格納される。
指標名称の項目には、図１３に示した指標管理テーブル４１の指標名称と同じ名称が格納される。
履歴の項目には、ワーカーノードに発生した障害の履歴、及びワーカーノードの使用状況を表す履歴（稼働時間、リソースの共有状況等）等の、スコア計算部３１によるスコア計算の基となる各種指標の計測値が格納される。
最終更新時刻の項目には、履歴管理テーブル２１が更新された時刻が指標ごとに格納される。
【0106】
図１７は、スコア計算表２２の例を示す図である。スコア計算表２２は、ワーカーノードのスコア計算部３１が自ノードのスコア計算に使用するために用いられる。
【0107】
スコア計算表２２は、指標名称、指標分類、計算方式の各項目で構成される。このスコア計算表２２は、図１３に示した指標管理テーブル４１から指標名称、指標分類、計算方式の各項目を選択したものであり、同じ内容であるため、詳細な説明を省略する。
ワーカーノードは、スコア計算表２２を使用することで、自ノードのスコアを指標毎に計算することができる。
ワーカーノードは、スコア計算表２２を使用することで、自ノードのスコアを指標毎に計算することができる。
【0108】
ここで、図１６に示した履歴管理テーブル２１の履歴の情報に基づいて、スコア計算表２２に従って計算される処理の具体例を説明する。計算方式の欄には、各指標で計算された結果が破線で囲って示される。
履歴管理テーブル２１では、ユーザーデータドライブ障害の履歴が「0」であるので、x = 0の式を満たし、スコアが「3」と計算される。
同様に、ノード閉塞の履歴が「1」であるので、0 < x ≦ 3回の式を満たし、スコアが「2」と計算される。
Compute Network障害の履歴が「20」であるので、10回 < x ≦ 100回の式を満たし、スコアが「2」と計算される。
Inter-Node Network障害の履歴が「0」であるので、x = 0の式を満たし、スコアが「2」と計算される。
Management Network障害の履歴が「4」であるので、3回< xの式を満たし、スコアが「0」と計算される。
ノードが動作している物理サーバーの稼働時間の履歴が「1200」であるので、x ⊂ {偶発故障期}の式を満たし、スコアが「２」と計算される。
物理サーバー上のドライブの稼働時間の履歴が「1400」であるので、x ⊂ {摩耗故障期}の式を満たし、スコアが「０」と計算される。
(仮想化環境)リソースの共有状況の履歴が「20」であるので、10% < x ≦ 30%の式を満たし、スコアが「１」と計算される。
これらの計算結果を踏まえて、スコア計算部３１は、指標分類Aのスコア合計を「5」、指標分類Bのスコア合計「4」、指標分類Cのスコア合計を「2」、指標分類Dのスコア合計を「1」と計算する。
履歴管理テーブル２１では、ユーザーデータドライブ障害の履歴が「0」であるので、x = 0の式を満たし、スコアが「3」と計算される。
同様に、ノード閉塞の履歴が「1」であるので、0 < x ≦ 3回の式を満たし、スコアが「2」と計算される。
Compute Network障害の履歴が「20」であるので、10回 < x ≦ 100回の式を満たし、スコアが「2」と計算される。
Inter-Node Network障害の履歴が「0」であるので、x = 0の式を満たし、スコアが「2」と計算される。
Management Network障害の履歴が「4」であるので、3回< xの式を満たし、スコアが「0」と計算される。
ノードが動作している物理サーバーの稼働時間の履歴が「1200」であるので、x ⊂ {偶発故障期}の式を満たし、スコアが「２」と計算される。
物理サーバー上のドライブの稼働時間の履歴が「1400」であるので、x ⊂ {摩耗故障期}の式を満たし、スコアが「０」と計算される。
(仮想化環境)リソースの共有状況の履歴が「20」であるので、10% < x ≦ 30%の式を満たし、スコアが「１」と計算される。
これらの計算結果を踏まえて、スコア計算部３１は、指標分類Aのスコア合計を「5」、指標分類Bのスコア合計「4」、指標分類Cのスコア合計を「2」、指標分類Dのスコア合計を「1」と計算する。
【0109】
図１８は、スコア情報２０の例を示す図である。スコア計算部３１は、指標分類ごとのスコア合計を格納したスコア情報２０を生成する。このスコア情報２０は、送信者ノードＩＤがNode_Aであるワーカーノードによりマスターノード（Ｐ）へ送信される。
【0110】
スコア情報２０は、送信者ノードＩＤ、指標分類Ａスコア、指標分類Ｂスコア、指標分類Ｃスコア、指標分類Ｄスコアの各項目で構成される。
指標分類ごとのスコアは、送信者ノードＩＤで特定されるワーカーノードが計算したものである。そして、マスターノード（Ｐ）は、クラスター６に含まれる各ワーカーノードからスコア情報２０を収集する。スコア情報２０には、送信者ノードＩＤが付されているので、マスターノード（Ｐ）は、送信者ノードＩＤをワーカーノードに読み替えてスコアテーブル４０にスコアを保存する。
指標分類ごとのスコアは、送信者ノードＩＤで特定されるワーカーノードが計算したものである。そして、マスターノード（Ｐ）は、クラスター６に含まれる各ワーカーノードからスコア情報２０を収集する。スコア情報２０には、送信者ノードＩＤが付されているので、マスターノード（Ｐ）は、送信者ノードＩＤをワーカーノードに読み替えてスコアテーブル４０にスコアを保存する。
【0111】
【0112】
（スコア計算に関わる処理）
始めに、図１９と図２０を参照してスコア計算に関わる処理の例を説明する。
図１９は、スコア計算に関わる処理の例を示すフローチャートである。
図２０は、マスターノード（Ｐ）とワーカーノードの処理の関係を示すシーケンス図である。図２０に示す各処理ステップの符号は、図１９に示す各処理ステップに対応付けている。
始めに、図１９と図２０を参照してスコア計算に関わる処理の例を説明する。
図１９は、スコア計算に関わる処理の例を示すフローチャートである。
図２０は、マスターノード（Ｐ）とワーカーノードの処理の関係を示すシーケンス図である。図２０に示す各処理ステップの符号は、図１９に示す各処理ステップに対応付けている。
【0113】
始めに、ワーカーノードのスコア計算部３１は、履歴管理テーブル２１を参照する（図１９のＳ１）。この時、ワーカーノードのStorage Softwareは、履歴管理テーブル２１から、自ノードの障害履歴、稼働履歴等の情報を取得する（図２０のＳ１Ａ）。
【0114】
次に、スコア計算部３１は、メモリ１１（図２を参照）に保存された自ノードの構成情報２３（図７を参照）を参照する（図１９のＳ２）。この時、ワーカーノードのStorage Softwareは、自ノードの構成情報２３を取得する（図２０のＳ２Ａ）。
【0115】
次に、スコア計算部３１は、スコア計算表２２を参照して自ノードのスコアを計算する（図１９のＳ３）。この時、ワーカーノードのStorage Softwareは、参照した自ノードの障害履歴、稼働履歴及び構成情報２３に基づいて、自ノードのスコアを計算する（図２０のＳ３Ａ）。
【0116】
次に、スコア計算部３１は、計算した自ノードのスコアを、マスターノード（Ｐ）に送信する（図１９のＳ４）。この時、ワーカーノードのStorage Softwareは、計算した自ノードのスコアを、マスターノード（Ｐ）のStorage Softwareに送信する（図２０のＳ４Ａ）。
【0117】
次に、マスターノード（Ｐ）のスコア管理部５１は、スコアテーブル４０を更新する（図１９のＳ５）。この時、マスターノード（Ｐ）のStorage Softwareは、Scale-out DBにスコアテーブル４０の最終更新時刻を問い合わせる（図２０のＳ５Ａ）。
【0118】
次に、スコア管理部５１は、スコア未受信ノードをチェックし、問題のあるノードのスコアを減点し（図１９のＳ６）、本処理を終了する。この時、マスターノード（Ｐ）のStorage Softwareは、一定時間スコア更新のないノードのスコアを無効化する（図２０のＳ６Ａ）。
【0119】
（障害発生からマスター昇格完了までの処理）
次に、図２１と図２２を参照して障害発生からマスター昇格完了までの処理の例を説明する。
図２１は、障害発生からマスター昇格完了までの処理の例を示すフローチャートである。
図２２は、マスターノード（Ｐ）とワーカーノードの処理の関係を示すシーケンス図である。図２２に示す各処理ステップの符号は、図２１に示す各処理ステップに対応付けている。
次に、図２１と図２２を参照して障害発生からマスター昇格完了までの処理の例を説明する。
図２１は、障害発生からマスター昇格完了までの処理の例を示すフローチャートである。
図２２は、マスターノード（Ｐ）とワーカーノードの処理の関係を示すシーケンス図である。図２２に示す各処理ステップの符号は、図２１に示す各処理ステップに対応付けている。
【0120】
始めに、マスターノード（Ｐ）の昇格ノード選定部５２は、フォールトドメインごとのマスターノード数をチェックする（図２１のＳ１１）。この時、マスターノード（Ｐ）のStorage Softwareは、自ノードのScale-out DBに対して、フォールトドメインの所属情報を問い合わせる（図２２のＳ１１Ａ）。また、マスターノード（Ｐ）のStorage Softwareは、自ノードのScale-out DBに対して、ワーカーノードのスコアを問い合わせ（図２２のＳ１１Ｂ）、ワーカーノードのスコアを取得する。
【0121】
次に、昇格ノード選定部５２は、ワーカーノードのスコアを比較する（図２１のＳ１２）。この時、マスターノード（Ｐ）のStorage Softwareは、ワーカーノードのスコアを比較する（図２２のＳ１２Ａ）。
【0122】
次に、マスターノード（Ｐ）のStorage Softwareは、マスター昇格対象であるワーカーノードのCoordination Serviceを起動する（図２１のＳ１３）。この時、マスターノード（Ｐ）のStorage Softwareは、マスター昇格対象であるワーカーノードのStorage SoftwareにCoordination Serviceの起動指示を送信する（図２２のＳ１３Ａ）。ワーカーノードのStorage Softwareは、起動指示を受信すると、自ノードのCoordination Serviceを起動する（図２２のＳ１３Ｂ）。
【0123】
次に、マスターノード（Ｐ）のマスター側グループ再構成部５３は、マスターノード（Ｐ）のCoordination Serviceグループを再構成し、マスター昇格対象であるワーカーノードのワーカー側グループ再構成部３２は、自ノードのCoordination Serviceグループを再構成する（図２１のＳ１４）。この時、マスターノード（Ｐ）のStorage Softwareは、自ノードのCoordination Serviceにグループ再構成を指示し（図２２のＳ１４Ａ）、マスターノード（Ｐ）のCoordination Serviceのマスター側グループ再構成部５３は、自ノードのCoordination Serviceグループを再構成する（図２２のＳ１４Ｂ）。このため、自ノードのCoordination Serviceグループに、マスター昇格対象であるワーカーノードがマスターノードとして含まれるようになる。
【0124】
また、マスターノード（Ｐ）のStorage Softwareは、マスター昇格対象であるワーカーノードのStorage SoftwareにCoordination Serviceグループの再構成を指示する（図２２のＳ１４Ｃ）。ワーカーノードのStorage Softwareは、自ノードのCoordination Serviceにグループ再構成を指示し（図２２のＳ１４Ｄ）、Coordination Serviceのワーカー側グループ再構成部３２は、ワーカーノードのCoordination Serviceグループを再構成する（図２２のＳ１４Ｅ）。再構成されたCoordination Serviceグループの内容は、図２２のＳ１４Ｂで説明したマスターノード（Ｐ）のCoordination Serviceグループと同じ内容となる。
【0125】
次に、マスターノード（Ｐ）のStorage Softwareは、マスター昇格対象であるワーカーノードのScale-out DBを起動する（図２１のＳ１５）。この時、マスターノード（Ｐ）のStorage Softwareは、マスター昇格対象であるワーカーノードのStorage SoftwareにScale-out DBの起動を指示する（図２２のＳ１５Ａ）。ワーカーノードのStorage Softwareは、起動指示を受信すると、自ノードのScale-out DBを起動する（図２２のＳ１５Ｂ）。
【0126】
次に、マスターノード（Ｐ）のマスター側グループ再構成部５３は、マスターノード（Ｐ）のScale-out DBグループを再構成し、マスター昇格対象であるワーカーノードのワーカー側グループ再構成部３２は、自ノードのScale-out DBグループを再構成する（図２１のＳ１６）。この時、マスターノード（Ｐ）のStorage Softwareは、自ノードのScale-out DBにグループ再構成を指示し（図２２のＳ１６Ａ）、マスターノード（Ｐ）のScale-out DBのマスター側グループ再構成部５３は、自ノードのScale-out DBグループを再構成する（図２２のＳ１６Ｂ）。このため、自ノードのScale-out DBグループに、マスター昇格対象であるワーカーノードがマスターノードとして含まれるようになる。
【0127】
また、マスターノード（Ｐ）のStorage Softwareは、マスター昇格対象であるワーカーノードのStorage SoftwareにScale-out DBグループの再構成を指示する（図２２のＳ１６Ｃ）。ワーカーノードのStorage Softwareは、自ノードのScale-out DBにグループ再構成を指示し（図２２のＳ１６Ｄ）、Scale-out DBのワーカー側グループ再構成部３２は、ワーカーノードのScale-out DBグループを再構成する（図２２のＳ１６Ｅ）。再構成されたScale-out DBグループの内容は、図２２のＳ１６Ｂで説明したマスターノード（Ｐ）のScale-out DBグループと同じ内容となる。
【0128】
次に、マスターノード（Ｐ）のマスター側グループ再構成部５３は、障害が発生したマスターノード（Ｓ）のCoordination ServiceとScale-out DBを停止する（Ｓ１７）。この時、マスターノード（Ｐ）のStorage Softwareは、障害が発生したマスターノード（Ｓ）のCoordination ServiceとScale-out DBを停止させる（図２２のＳ１７Ａ）。
【0129】
ステップＳ１７Ａでは、Coordination ServiceとScale-out DBが停止される処理を説明したが、マスターノード（Ｓ）の障害発生時点でクラスター６から障害が発生したマスターノード（Ｓ）が論理的に切り離されるものとする。このため、障害が発生したマスターノード（Ｓ）による他のノードへの影響を抑えることができる。
【0130】
次に、マスターノード（Ｐ）のスコア管理部５１は、スコアテーブル４０を更新し（図２１のＳ１８）、本処理を終了する。この時、図１２に示したように、マスターノード（Ｐ）のStorage Softwareは、マスター昇格対象のノードのエントリをスコアテーブル４０から削除することで、スコアテーブル４０を更新する（図２２のＳ１８Ａ）。
【0131】
＜通知画面の表示例＞
図２３は、通知画面７０の表示例を示す図である。通知画面７０は、マスターの障害発生時に、ワーカーノードのマスター昇格が行われると表示される。
図２３は、通知画面７０の表示例を示す図である。通知画面７０は、マスターの障害発生時に、ワーカーノードのマスター昇格が行われると表示される。
【0132】
通知画面７０は、障害が発生したマスターノード、マスター昇格したワーカーノードをユーザーが確認するために用いられる。この通知画面７０には、対象となるクラスター６がNode1～Node6で構成されること、障害が発生したノードがNode3であること、及びマスター昇格時のスコアテーブル４０が表示される。通知画面７０の下部には、「マスターノード（Node3）を降格して削除し、スコアの高かったワーカーノード6をマスターノードに昇格しました」というメッセージが表示される。ユーザーは、この通知画面７０により、マスターノードであったNode3が降格し、ワーカーノードであったNode6がマスターノードに昇格したことを確認できる。このため、ユーザーは、マスターから降格したNode3の修理対応、障害対応等を円滑に行うことができる。
【0133】
以上説明した一実施形態に係るストレージシステム１では、クラスター６の稼働中に、障害が発生したマスターノードの代わりに、マスター昇格対象として安定した稼働が見込まれるワーカーノードが自動で選定され、選定されたワーカーノードがマスター昇格される。このため、障害の発生しにくいワーカーノードがマスター昇格の対象として選定されやすい。また、マスター昇格の対象となるワーカーノードの選定が自動化されるので、ユーザーが多数のワーカーノードからマスター昇格できるワーカーノードを選ぶ作業が不要である。また、マスターノードに障害が発生してサービスが停止しても、マスター昇格されたマスターノードを使って短時間でサービスを再開できるので、サービス停止時間を少なくすることができる。このため、ユーザーの作業量を増やすことなくストレージシステム１の可用性を高めることができる。
【0134】
また、クラスター６の稼働中に、ワーカーノードのスコア計算部３１は、自身の過去の障害発生回数や稼働時間などを基にどの程度安定して稼働しているのかを表すスコアを計算し、マスターノードのスコア管理部５１が、ワーカーノードごとにスコアを管理する。また、マスターノードの昇格ノード選定部５２は、実際にマスター昇格が必要になったタイミングでワーカーノードのスコアを比較して、信頼できるワーカーノードをマスター昇格の対象として自動で選択できる。
【0135】
また、スコアテーブル４０には、指標分類ごとにスコアが管理される。また、指標分類の優先順位に従って、スコアが高い順に、マスター昇格の対象となるワーカーノードが選定される。このため、障害が発生しにくいワーカーノードがマスター昇格の対象として選定されやすくなる。
【0136】
また、障害が発生したマスターノード、スコアテーブル４０の内容、マスター昇格されたワーカーノードの情報が通知画面７０によってユーザーに通知される。ユーザーは、通知画面７０を通じて、クラスター６の稼働状況を把握しやすくなり、障害が発生したマスターノードの修理又は交換の対応を早めることができる。
【0137】
また、クラスター６では、フォールトドメインごとにマスターノード及びワーカーノードの台数が管理され、マスターノードの台数が最も少ないフォールトドメインに属するワーカーノードがマスター昇格の対象として選定されやすくなる。このため、障害が発生したマスターノードと同じフォールトドメインに属するワーカーノードがマスター昇格した後、障害が発生したマスターノードの障害対応により、電源遮断されることによるマスター昇格したマスターノードの停止等を避けることができる。
【0138】
なお、本発明は上述した実施形態に限られるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
例えば、上述した実施形態は本発明を分かりやすく説明するためにシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、本実施形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
例えば、上述した実施形態は本発明を分かりやすく説明するためにシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、本実施形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【0139】
１…ストレージシステム、３…ストレージノード、６…クラスター、１０…ＣＰＵ、１１…メモリ、１２…記憶装置、２０…スコア情報、２１…履歴管理テーブル、２２…スコア計算表、３１…スコア計算部、３２…ワーカー側グループ再構成部、４０…スコアテーブル、４１…指標管理テーブル、４２…優先順位管理テーブル、５１…スコア管理部、５２…昇格ノード選定部、５３…マスター側グループ再構成部、７０…通知画面
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
