(57)【要約】【課題】効率良くサーバの切り替えを実施する。【解決手段】プライマリサーバと、前記プライマリサーバのデータを同期方式でバックアップする１又は複数の同期型バックアップサーバと、前記プライマリサーバのデータを非同期でバックアップする１又は複数の非同期型バックアップサーバとを含むサーバシステムにおいて、前記サーバシステム内の１又は複数のサーバにおける障害により前記同期型バックアップサーバの数が減少する場合に、１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう。【選択図】図９
2019185371.tif 000002
【特許請求の範囲】
【請求項１】
プライマリサーバと、前記プライマリサーバのデータを同期方式でバックアップする１又は複数の同期型バックアップサーバと、前記プライマリサーバのデータを非同期でバックアップする１又は複数の非同期型バックアップサーバとを含むサーバシステムにおけるサーバ切り替えプログラムであって、
前記サーバシステム内の１又は複数のサーバにおける障害により前記同期型バックアップサーバの数が減少する場合に、１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、
処理をコンピュータに実行させることを特徴とする、サーバ切り替えプログラム。
【請求項２】
前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御する際、減少する同期型バックアップサーバの数と同じ数の非同期型バックアップサーバを同期型バックアップサーバとして動作するように制御する、処理を前記コンピュータに実行させることを特徴とする、請求項１に記載のサーバ切り替えプログラム。
【請求項３】
前記制御は、前記同期型バックアップサーバの数が減少する場合であって、かつ、減少後の前記同期型バックアップサーバの数が所定数となる場合に実行される、ことを特徴とする、請求項１に記載のサーバ切り替えプログラム。
【請求項４】
前記非同期型バックアップサーバを前記同期型バックアップサーバへ切り替える際、前記非同期型バックアップサーバの前記プライマリサーバに対する同期状態に基づいて切り替える処理を前記コンピュータに実行させることを特徴とする、請求項１〜３のいずれか１項に記載のサーバ切り替えプログラム。
【請求項５】
前記プライマリサーバに対する同期状態は、ＷＡＬの情報に基づいて決定されることを特徴とする、請求項４に記載のサーバ切り替えプログラム。
【請求項６】
前記プライマリサーバにおける障害が発生した場合に、１又は複数の前記同期型バックアップサーバのうちのいずれか１つの同期型バックアップサーバを、新たなプライマリサーバとして動作するように制御を行ない、
１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、
処理を前記コンピュータに実行させることを特徴とする、請求項１〜５のいずれか１項に記載のサーバ切り替えプログラム。
【請求項７】
プライマリサーバと、前記プライマリサーバのデータを同期方式でバックアップする１又は複数の同期型バックアップサーバと、前記プライマリサーバのデータを非同期でバックアップする１又は複数の非同期型バックアップサーバとを含むサーバシステムにおけるサーバ切り替え方法であって、
前記プライマリサーバのプロセッサが、前記サーバシステム内の１又は複数のサーバにおける障害により前記同期型バックアップサーバの数が減少する場合に、１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、ことを特徴とする、サーバ切り替え方法。
【請求項８】
プライマリサーバと、
前記プライマリサーバのデータを同期方式でバックアップする１又は複数の同期型バックアップサーバと、
前記プライマリサーバのデータを非同期でバックアップする１又は複数の非同期型バックアップサーバと、をそなえ、
前記プライマリサーバは、
前記サーバシステム内の１又は複数のサーバにおける障害により前記同期型バックアップサーバの数が減少する場合に、１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、ことを特徴とする、サーバ切り替えシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ切り替えプログラム、サーバ切り替え方法、及びサーバ切り替えシステムに関する。
【背景技術】
【０００２】
複数のノード、例えば複数のＤＢ（Database）サーバにより多重化環境を構成するクラスタシステムでは、クラスタシステムを構成するノード数に見合った可用性向上を実現するために、マルチ同期スタンバイ機能が用いられることがある。
【０００３】
マルチ同期スタンバイ機能は、プライマリサーバ、及び、１以上のスタンバイサーバをそなえる多重化環境において、ノードに異常が発生した場合にクラスタ構成を再構築する技術である。マルチ同期スタンバイ機能において採用される手法としては、例えば、フェイルオーバ及びフォールバック等が知られている。
【０００４】
フェイルオーバは、プライマリサーバが故障した場合に、いずれかのスタンバイサーバをプライマリサーバに切り替えて、新プライマリサーバで業務を継続する手法である。フェイルオーバでは、プライマリサーバが故障する都度、アクティブなスタンバイサーバが無くなるまで、スタンバイサーバからプライマリサーバへの切り替えが行なわれる。
【０００５】
なお、スタンバイサーバをプライマリサーバに「切り替える」とは、スタンバイサーバとして動作するノードに対して、プライマリサーバとして動作するように機能を切り替える（制御する）ことを意味してよい。
【０００６】
フォールバックは、スタンバイサーバが故障した場合に、故障したスタンバイサーバを縮退し、残りのスタンバイサーバによってＤＢの冗長化を担保する手法である。
【０００７】
マルチ同期スタンバイ機能を採用するクラスタシステムの可用性は、スタンバイサーバ数の増加に比例して向上する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００６−３０９４３９号公報
【特許文献２】特開２０１６−５１４４８号公報
【特許文献３】特開２０１３−３７４３３号公報
【特許文献４】特開２０１１−１４１６０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、端末によるクラスタシステムに対するＤＢの更新業務においてプライマリサーバのＤＢが更新されると、プライマリサーバは当該更新をスタンバイサーバのＤＢに反映させるための同期処理を行なう。
【００１０】
このため、スタンバイサーバ数を増加させることにより、クラスタシステムの可用性が向上する一方、プライマリサーバによる同期処理の処理負荷は増加し、ＤＢの更新性能が低下することがあり、効率良くサーバの切り替えを行なうことが困難な場合がある。
【００１１】
１つの側面では、本発明は、効率良くサーバの切り替えを実施することを目的とする。
【課題を解決するための手段】
【００１２】
１つの側面では、サーバシステムにおけるサーバ切り替えプログラムは、以下の処理をコンピュータに実行させてよい。なお、サーバシステムは、プライマリサーバと、前記プライマリサーバのデータを同期方式でバックアップする１又は複数の同期型バックアップサーバと、前記プライマリサーバのデータを非同期でバックアップする１又は複数の非同期型バックアップサーバとを含む。前記処理は、前記サーバシステム内の１又は複数のサーバにおける障害により前記同期型バックアップサーバの数が減少する場合に、１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なってよい。
【発明の効果】
【００１３】
１つの側面では、効率良くサーバの切り替えを実施することができる。
【図面の簡単な説明】
【００１４】
【図１】一実施形態に係るクラスタシステムの構成例を示すブロック図である。
【図２】一実施形態に係るノードの構成例を示すブロック図である。
【図３】ノード情報の一例を示す図である。
【図４】一実施形態に係るＤＢインスタンスの状態遷移の一例を示す図である。
【図５】一実施形態に係る同期スタンバイサーバの動作例を示すフローチャートである。
【図６】図５に示す同期スタンバイサーバの動作例を説明する図である。
【図７】図５に示す同期スタンバイサーバの動作例を説明する図である。
【図８】一実施形態に係るプライマリサーバの動作例を示すフローチャートである。
【図９】図８に示すプライマリサーバの動作例を説明する図である。
【図１０】一実施形態に係るコンピュータのハードウェア構成例を示す図である。
【図１１】一実施形態に係るクラスタシステムの構成例を示すブロック図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。例えば、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。
【００１６】
〔１〕一実施形態
〔１−１〕クラスタシステムの構成例
図１は、一実施形態の一例としてのクラスタシステム１の構成例を示すブロック図である。図１に示すように、クラスタシステム１は、サーバシステムの一例であり、例示的に、クラスタを構成する複数（図１の例では７台）のノード２と、１以上（図１の例では１台）のノード３と、をそなえてよい。
【００１７】
複数のノード２の各々は、例えば、データベース管理システム（ＤＢＭＳ；Database Management System）等のソフトウェアがインストールされたＤＢサーバであり、マルチ同期スタンバイ機能を用いてよい。複数のノード２において実行されるＤＢＭＳにより、ＤＢの多重化環境が実現されてよい。
【００１８】
複数のノード２間は、インターコネクト、例えばＬＡＮ（Local Area Network）等のネットワーク１ａにより、相互に通信可能に接続されてよい。
【００１９】
ノード２は、プライマリサーバ、１以上の同期スタンバイサーバ、及び、１以上の非同期スタンバイサーバ、のいずれか１つの種別の機能（役割）を可変的に割り当てられ、割り当てられた種別のサーバとして動作してよい。
【００２０】
図１の例では、１台のノード２Ａ−１がプライマリサーバとして動作し、３台のノード２Ｂ−１〜２Ｂ−３が同期スタンバイサーバとして動作し、３台のノード２Ｃ−１〜２Ｃ−３が非同期スタンバイサーバとして動作するものとする。
【００２１】
以下の説明において、プライマリサーバとして動作するノード２を「ノード２Ａ」又は「プライマリサーバ２Ａ」と表記する場合がある。また、同期スタンバイサーバとして動作するノード２を「ノード２Ｂ」又は「同期サーバ２Ｂ」と表記する場合がある。さらに、非同期スタンバイサーバとして動作するノード２を「ノード２Ｃ」又は「非同期サーバ２Ｃ」と表記する場合がある。また、ノード２を「サーバ２」又は「ＤＢサーバ２」と表記する場合がある。
【００２２】
プライマリサーバ２Ａは、ＤＢのマスタデータを管理する運用系ノードの一例である。プライマリサーバ２Ａは、ＤＢの更新業務に応じて、プライマリサーバ２Ａが有するＤＢの更新処理を行なう。ＤＢの更新業務は、例えば、図１に示す端末４が、ネットワーク５及びノード３を経由してプライマリサーバ２Ａにアクセスすることで実行されてよい。
【００２３】
また、プライマリサーバ２Ａは、ＤＢの更新処理に加えて、クラスタを構成するノード２に対する同期処理を行なう。一例として、プライマリサーバ２Ａは、同期処理において、更新処理に係る更新結果の情報（例えばＷＡＬ等のログ）を、同期サーバ２Ｂ及び非同期サーバ２Ｃに対して送信（例えばブロードキャスト）してよい。
【００２４】
ＷＡＬは、Write Ahead Logging（ログ先行書き込み）の略称であり、ＤＢへの書き込みに先立って書き出されるトランザクションのログである。以下、同期処理がＷＡＬを用いて行なわれるものとして説明する。
【００２５】
１以上の同期サーバ２Ｂは、運用系ノードの予備である待機系ノード群であって、プライマリサーバ２Ａのデータを同期方式でバックアップする１又は複数の同期型バックアップサーバの一例である。各同期サーバ２Ｂは、プライマリサーバ２ＡからＷＡＬを受信すると、ログの転送が完了したことを示す応答（ログ転送完了応答）をプライマリサーバ２Ａに送信してよい。
【００２６】
なお、ログ転送応答は、例えば、同期サーバ２ＢがＷＡＬを受信したことを示す応答として、同期サーバ２ＢがＷＡＬを受信したタイミングで送信されてもよい。或いは、ログ転送応答は、例えば、同期サーバ２Ｂが受信したＷＡＬを用いて同期サーバ２ＢのＤＢの更新処理を完了したタイミングで送信されてもよい。
【００２７】
プライマリサーバ２Ａは、ＷＡＬの送信先のノード２のうち、全ての同期サーバ２Ｂからログ転送完了応答を受信した場合に、同期処理が完了したと判断し、同期処理のトランザクションを終了してよい。これにより、プライマリサーバ２Ａと同期サーバ２Ｂとの間のデータ同期（データの同一性）を保証できる。
【００２８】
１以上の非同期サーバ２Ｃは、待機系ノード群の予備である非同期待機系ノード群であって、プライマリサーバ２Ａのデータを非同期でバックアップする１又は複数の非同期型バックアップサーバの一例である。各非同期サーバ２Ｃは、プライマリサーバ２ＡからＷＡＬを受信すると、受信したＷＡＬを用いて非同期サーバ２ＣのＤＢの更新処理を行なってよい。
【００２９】
プライマリサーバ２Ａは、ＷＡＬの送信先のノード２のうち、非同期サーバ２Ｃについては、非同期サーバ２Ｃからの応答を待たずに、全ての同期サーバ２Ｂから応答を受信したことを以って、同期処理のトランザクションを終了してよい。なお、各非同期サーバ２Ｃについては、ＷＡＬを受信した場合におけるプライマリサーバ２Ａに対するログ転送完了応答の送信を不要としてもよい。
【００３０】
プライマリサーバ２Ａは、同期処理において、同期サーバ２Ｂに対してはログ転送完了応答の受信待ちを行なうため、同期サーバ２Ｂの台数が増加するほど、プライマリサーバ２Ａの処理負荷が高まり、更新処理に利用可能なリソースが減少するため、更新処理のレスポンスが不安定になるリスクが増加する。
【００３１】
そこで、一実施形態に係るクラスタシステム１においては、稼働する同期サーバ２Ｂの台数が、更新業務の性能要件と同時障害耐久性とのバランスを考慮した最適な上限数（台数）に調整され、決定されてよい。これにより、プライマリサーバ２Ａの処理負荷の増加を低減でき、更新処理に利用可能なリソースの減少を抑制できるため、更新処理において安定したレスポンスが確保できる。
【００３２】
プライマリサーバ２Ａ、同期サーバ２Ｂ、及び非同期サーバ２Ｃ等のノード２の詳細については後述する。
【００３３】
なお、端末４或いは図示しない他の端末は、例えば、ネットワーク５及びノード３を経由して同期サーバ２Ｂに対してアクセスすることで、ＤＢの参照業務を実行してよい。また、マルチ同期スタンバイ機能における、ＤＢ多重化環境の連携は、同期サーバ２Ｂ以外のノード２（例えば非同期サーバ２Ｃ）であれば可能である。
【００３４】
ノード３は、例えばアプリケーション（Application；以下、「ＡＰ」と表記する）サーバである。ノード３は、端末４或いは他の端末に対するクラスタシステム１へのインタフェース（Interface；ＩＦ）を提供してよい。以下の説明において、ノード３を「ＡＰサーバ３」と表記する場合がある。
【００３５】
ＡＰサーバ３と複数のノード２の各々との間は、ネットワーク１ｂにより相互に通信可能に接続されてよい。ネットワーク１ｂは、ネットワーク１ａと同一の、又は、異なるインターコネクト、例えばＬＡＮ等であってよい。
【００３６】
ＡＰサーバ３は、更新業務のアクセス先であるプライマリサーバ２Ａ、及び、参照業務のアクセス先である同期サーバ２Ｂを、複数のノード２の中から特定し、端末４或いは他の端末からのアクセスの接続先を、特定したノード２に切り替えてよい。例えば、ＡＰサーバ３は、ノード２からノード情報２１２（図２参照）を参照又は受信し、ノード情報２１２に基づいて、各ノード２の「プライマリ」、「同期スタンバイ」、「非同期スタンバイ」等の動作モード（同期属性）を判定してよい。
【００３７】
端末４は、クラスタシステム１が提供するＤＢの利用者が使用するコンピュータである。端末４としては、ユーザＰＣ（Personal Computer）、サーバ、スマートホン、或いはタブレット等の情報処理装置が挙げられる。
【００３８】
ネットワーク５は、例えば、ＬＡＮ或いはＷＡＮ（Wide Area Network）、又はこれらの組み合わせを含む、インターネット及びイントラネットの少なくとも一方であってよい。また、ネットワーク５は、ＶＰＮ（Virtual Private Network）等の仮想ネットワークを含んでもよい。なお、ネットワーク５は、有線ネットワーク及び無線ネットワークの一方又は双方により形成されてよい。
【００３９】
〔１−２〕ＤＢサーバの構成例
次に、図２を参照して、ＤＢサーバ２としてのノード２の構成例について説明する。なお、図１に示す各ノード２は、動作モードの切り替えによって、プライマリサーバ２Ａ、同期サーバ２Ｂ、及び非同期サーバ２Ｃのいずれとして動作可能であるため、以下、これらのサーバ２Ａ〜２Ｃの機能を包含した機能構成例を説明する。なお、クラスタの構成や環境、運用等によって、各ノード２がそなえる機能構成は、サーバ２Ａ〜２Ｃのうちの１つ又は２つを実現するための機能構成に制限されてもよい。
【００４０】
図２に示すように、ノード２は、例示的に、ＤＢ２１、ＤＢ制御部２２、同期制御部２３、及び、切替制御部２４をそなえてよい。
【００４１】
ＤＢ２１は、クラスタシステム１が提供するデータベースであり、業務データ等のユーザデータ２１１を格納してよい。なお、プライマリサーバ２ＡのＤＢ２１が格納するユーザデータ２１１は、マスタデータとして扱われてよく、同期サーバ２Ｂ又は非同期サーバ２Ｃが格納するユーザデータ２１１は、マスタデータの同期バックアップ又は非同期バックアップとして扱われてよい。
【００４２】
また、一実施形態に係るＤＢ２１は、ＤＢ制御部２２、同期制御部２３、及び、切替制御部２４の処理に用いられる情報として、例えば、ノード情報２１２及び優先度情報２１３を格納してよい。
【００４３】
なお、ＤＢ２１としては、メモリ、例えばＲＡＭ（Random Access Memory）等の揮発性メモリ、並びに、記憶部、例えばＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）等の記憶装置、の一方又は双方が挙げられる。ユーザデータ２１１、ノード情報２１２、及び優先度情報２１３は、１つのＤＢ２１に格納されてもよいし、複数のＤＢ２１（図示省略）に分散して格納されてもよい。また、ノード情報２１２、及び優先情報２１３はＤＢに格納されなくてもよい。
【００４４】
ＤＢ制御部２２は、ＤＢ２１に関する種々の制御を行なう。
【００４５】
例えば、プライマリサーバ２ＡのＤＢ制御部２２は、更新業務において、端末４からの更新指示に基づくＷＡＬ等のログの生成、及び、更新指示に基づくユーザデータ２１１の更新処理（例えばデータの追加、削除、或いは更新）を行なってよい。
【００４６】
また、同期サーバ２Ｂ及び非同期サーバ２ＣのＤＢ制御部２２は、それぞれ、同期制御部２３がプライマリサーバ２Ａから受信したＷＡＬに基づき、同期サーバ２Ｂ及び非同期サーバ２ＣのＤＢ２１に格納されたユーザデータ２１１の更新処理を行なってよい。
【００４７】
同期制御部２３は、ノード２間のデータ同期に関する種々の制御を行なう。
【００４８】
例えば、プライマリサーバ２Ａの同期制御部２３は、更新指示に応じて同期処理を開始し、ＤＢ制御部２２が生成したＷＡＬを、同期サーバ２Ｂ及び非同期サーバ２Ｃに送信（例えばブロードキャスト）してよい。また、同期制御部２３は、各同期サーバ２Ｂからの転送完了応答の受信を待ち受け、全ての同期サーバ２Ｂから転送完了応答を受信すると、同期処理を終了してよい。
【００４９】
なお、プライマリサーバ２Ａは、例えば、ＤＢ２１に格納されたノード情報２１２（図２参照）を参照することで、複数のノード２の各々の動作モードが同期サーバ２Ｂ及び非同期サーバ２Ｃのいずれかであるのかを判定してよい。
【００５０】
図３は、ノード情報２１２の一例を示す図である。図３に示すように、ノード情報２１２は、例示的に、ノード２を識別するための識別情報、及び、当該ノード２の動作モードの項目を含んでよい。なお、ノード情報２１２は、ＤＢＭＳにより管理されてよく、動作モードの更新は、例えば、マルチ同期スタンバイ機能におけるフェイルオーバやフォールバックの実行に応じて更新されてよい。
【００５１】
なお、ノード情報２１２において、「プライマリ」の情報（エントリ）は省略されてもよい。プライマリサーバ２Ａ、並びに、同期サーバ２Ｂ及び非同期サーバ２Ｃの動作モードは、ＤＢの状態、例えば、ＰｏｓｔｇｒｅＳＱＬの場合にはＤＢにおける“recovery.conf”の有無によって決定（判断）されてもよい。“recovery.conf”は、リカバリに関する設定ファイルであり、例えば同期サーバ２Ｂ及び非同期サーバ２Ｃのようなスレーブのノード２に設定される。従って、各ノード２は、“recovery.conf”が存在しないノード２の動作モードを「プライマリ」と判断してもよい。
【００５２】
同期サーバ２Ｂ及び非同期サーバ２Ｃの同期制御部２３は、同期処理として、ＷＡＬの受信を待ち受け、プライマリサーバ２ＡからＷＡＬを受信すると、受信したＷＡＬをＤＢ制御部２２に出力し、ＤＢ制御部２２に更新処理を実行させてよい。また、同期サーバ２Ｂの同期制御部２３は、ＷＡＬを受信したタイミングで、或いは、ＤＢ制御部２２による更新処理が完了したタイミングで、プライマリサーバ２Ａに対して、転送完了応答を送信してよい。
【００５３】
切替制御部２４は、ノード２の動作モードの切り替えに関する種々の制御を行なう。例えば、切替制御部２４は、フェイルオーバやフォールバックにおいて、障害の発生したノード２を縮退する際に、縮退先（切替先）のノード２を決定してよい。
【００５４】
図４は、一実施形態に係るＤＢインスタンスの状態遷移（動作モードの切り替え）の一例を示す図である。
【００５５】
図４に示すように、切替制御部２４は、ノード２の障害或いは電源ＯＦＦ制御等に応じて、ノード２の状態を「プライマリ」、「同期スタンバイ」、或いは「非同期スタンバイ」から「停止」に切り替えてよい。また、切替制御部２４は、ノード２の障害復旧、組み込み、或いは電源ＯＮ制御等に応じて、ノード２の状態を「停止」から「プライマリ」、「同期スタンバイ」、或いは「非同期スタンバイ」に切り替えてよい。
【００５６】
また、切替制御部２４は、「プライマリ」の状態であるノード２の障害或いは電源ＯＦＦ制御等に応じて、「同期スタンバイ」の状態である複数のノード２のうちのいずれか１つのノード２を選択して、「プライマリ」の状態に切り替えてよい。
【００５７】
「同期スタンバイ」から「プライマリ」への昇格では、状態（動作モード）の再構築による更新業務への影響を抑制するために、例えば、到達ＷＡＬが最新である同期サーバ２Ｂが優先的に切替対象のノード２として選択されてよい。
【００５８】
さらに、切替制御部２４は、「同期スタンバイ」の状態であるノード２と、「非同期スタンバイ」の状態であるノード２と、の間で、優先順に基づく状態の再構築が実行されてよい。
【００５９】
例えば、切替制御部２４は、「同期スタンバイ」の状態であるノード２の障害の発生や「プライマリ」への昇格等に応じて、「非同期スタンバイ」の状態である１つのノード２を、「同期スタンバイ」の状態に切り替えてよい（昇格させてよい）。換言すれば、切替制御部２４は、減少した「同期スタンバイ」の状態であるノード２の数と同じ数の「非同期スタンバイ」の状態であるノード２を、「同期スタンバイ」の状態に切り替える。このとき、切替制御部２４は、動作モードの切り替え対象となるノード２として、到達ＷＡＬが最新に近いノード２を選択してよい。
【００６０】
なお、切替制御部２４は、「同期スタンバイ」の状態であるノード２のうちの、到達ＷＡＬが古い等の同期性能の低いノード２を、「非同期スタンバイ」の状態に切り替えてもよい（降格させてもよい）。この場合、切替制御部２４は、「非同期スタンバイ」の状態であるノード２のうちの、「非同期スタンバイ」の状態への切替対象のノード２よりも到達ＷＡＬが新しいノード２を、「同期スタンバイ」の状態に切り替えてもよい。
【００６１】
上述した切替制御部２４による処理は、例えば、プライマリサーバ２Ａが正常であれば、プライマリサーバ２Ａ（プライマリサーバ２Ａが切り替わった場合は切替後のプライマリサーバ２Ａ）の切替制御部２４が実行してよい。一方、プライマリサーバ２Ａに障害が発生した場合には、複数の同期サーバ２Ｂの切替制御部２４が協働して上述した処理を実行してよい。
【００６２】
なお、一実施形態に係るクラスタシステム１は、同時障害耐久性を確保するために、複数のノード２に障害が発生した場合には、障害が発生したノード２数や障害が発生したノード２の動作モードに基づいて、上述した処理を組み合わせて実施してよい。
【００６３】
例えば、複数の同期サーバ２Ｂに障害が発生した場合には、プライマリサーバ２Ａの切替制御部２４は、到達ＷＡＬが最新に近い順に、障害の発生した同期サーバ２Ｂの数に相当する（同じ数の）非同期サーバ２Ｃを同期サーバ２Ｂに切り替えてよい。
【００６４】
また、プライマリサーバ２Ａと、１以上の同期サーバ２Ｂとに障害が発生した場合には、以下の（ｉ）及び（ii）の手順により切り替え制御を行なってよい。
【００６５】
（ｉ）上述のように、複数の同期サーバ２Ｂの切替制御部２４が協働して、１つの同期サーバ２Ｂを新たなプライマリサーバ２Ａに昇格させる。
【００６６】
（ii）新たなプライマリサーバ２Ａが、到達ＷＡＬが最新に近い順に、障害の発生した１以上の同期サーバ２Ｂの数に“１”（上記（ｉ）で減少した同期サーバ２Ｂの数）を加算した数に相当する非同期サーバ２Ｃを同期サーバ２Ｂに切り替える。
【００６７】
なお、切替制御部２４は、例えば、ＤＢ２１に格納された優先度情報２１３（図２参照）を参照することで、各ノード２の各々のＷＡＬ（到達ＷＡＬ）の情報を取得してよい。
【００６８】
優先度情報２１３は、自身のノード２のプライマリサーバ２Ａに対する同期状態を示す情報の一例である。プライマリサーバ２Ａに対する同期状態は、ＷＡＬの情報に基づいて決定されてよい。例えば、優先度情報２１３には、ＷＡＬごとに異なる（例えばシーケンシャルに増加する）番号部分を含むＷＡＬ番号が設定されてよい。ＷＡＬ番号は、例えば、ＷＡＬのファイル名等であってよい。なお、優先度情報２１３として、ＷＡＬ自体が用いられてもよく、この場合、優先度情報２１３（ＷＡＬ）は、ユーザデータ２１１の一部として管理されてもよい。
【００６９】
ＷＡＬは、ＷＡＬ番号における上記の番号部分が大きいＷＡＬほど、新しいＷＡＬである。このため、ＷＡＬ番号が最新に近いノード２ほど、レイテンシが低く転送効率の良いノード２であり、縮退先としての優先度の高いノード２であるといえる。
【００７０】
このように、一実施形態に係るクラスタシステム１によれば、ノード２の縮退や組み込みのタイミングで、「同期スタンバイ」及び「非同期スタンバイ」の状態であるノード２を再構築することで、クラスタシステム１の高可用性を維持することができる。一実施形態において、プライマリサーバ２Ａの切り替えは、フェイルオーバ（或いは計画的な手動切り替え）によって実施されるため、縮退の際の参照業務の無停止を実現できる。
【００７１】
また、「同期スタンバイ」のノード２からの縮退先となる「非同期スタンバイ」のノード２の選定ルールについて、例えば、縮退先候補のノード２を最新のＷＡＬが適用済みのノード２に制限する等の優先度を設けたチューニングを行なうことができる。これにより、「同期スタンバイ」及び「非同期スタンバイ」のノード２のそれぞれの運用要件（例えば参照業務の優先度等）を満たした運用を実現可能とすることができる。
【００７２】
さらに、切替制御部２４は、同期サーバ２Ｂが更新業務に影響を与えるＷＡＬ転送のレイテンシに基づいた評価によって、フェイルオーバ等に応じて非同期サーバ２Ｃを同期サーバ２Ｂに昇格させる場合の優先順位を決定する。例えば、回線性能の安定しないクラウド環境等においてクラスタシステム１が実施される場合、このようなベストエフォート方式により各ノード２の動作モードを最適化することが効果的である。
【００７３】
なお、上述した説明においては、フェイルオーバが行なわれるタイミングで、ＷＡＬ到達順序が最新に近い非同期サーバ２Ｃを同期サーバ２Ｂに切り替えるものとしたが、これに限定されるものではない。
【００７４】
例えば、過去の統計情報に基づいて、レイテンシが低い非同期サーバ２Ｃを、フェイルオーバが行なわれるタイミングで同期サーバ２Ｂに切り替えてもよい。過去の統計情報としては、例えば、過去の特定の期間における各ノード２のスループット（単位時間当たりの処理量等）、ＣＰＵ（Central Processing Unit）使用率、ＷＡＬ到達時刻、等の種々の情報が含まれてよい。過去の統計情報は、例えば、優先度情報２１３としてＤＢ２１に格納されてもよい。
【００７５】
これにより、過去の統計情報に基づき負荷の大きい非同期サーバ２Ｃを、同期サーバ２Ｂに切り替える対象から除外することができ、クラスタシステム１の性能低下を抑制できる。また、ノード２の台数に比例した可用性を実現するために、同期処理の処理負荷が小さい非同期サーバ２Ｃを利用できる。このため、プライマリサーバ２Ａにおける同期処理の処理負荷の増加を低減しつつ、同期サーバ２Ｂの台数を制限することによる可用性の低下を抑制できる。
【００７６】
また、上述した説明においては、フェイルオーバが行なわれるタイミングにおいて、切替制御部２４がノード２の動作モードを切り替えるものとしたが、これに限定されるものではない。
【００７７】
例えば、切替制御部２４は、一定間隔で同期サーバ２Ｂを入れ替えてもよい。一例として、切替制御部２４は、上述した「同期スタンバイ」から「非同期スタンバイ」への切り替え（降格）処理と、「非同期スタンバイ」から「同期スタンバイ」への切り替え（昇格）処理とのセットを、定期的に実行してもよい。
【００７８】
これにより、クラスタシステム１の運用中に処理負荷の増加等によりレイテンシが低下した同期サーバ２Ｂと、当該同期サーバ２ＢよりもＷＡＬのレイテンシが低い非同期サーバ２Ｃと、を入れ替えることができ、性能低下を抑制できる。
【００７９】
また、一実施形態においては、障害の発生した同期サーバ２Ｂの数に相当する非同期サーバ２Ｃを同期サーバ２Ｂとして動作するように制御する例について説明したが、これに限定するものではない。障害の発生した同期サーバ２Ｂの数と、同期サーバ２Ｂに昇格する非同期サーバ２Ｃの数とは、一致しなくてもよい。
【００８０】
例えば、プライマリサーバ２Ａの切替制御部２４は、同期サーバ２Ｂに障害が発生した場合であっても、クラスタシステム１において稼働する同期サーバ２Ｂの数が所定数よりも多い場合には、非同期サーバ２Ｃから同期サーバ２Ｂへの切り替えを抑制してもよい。このように、切替制御部２４による処理は、同期サーバ２Ｂの数が減少する場合であって、かつ、減少後の同期サーバ２Ｂの数が所定数となる場合に実行されてもよい。
【００８１】
〔１−３〕動作例
次に、図５〜図９を参照して、上述の如く構成されたクラスタシステム１の動作例を説明する。
【００８２】
〔１−３−１〕プライマリサーバに障害が発生した場合の動作例
まず、図５〜図７を参照して、プライマリサーバ２Ａ−１に障害が発生した場合の動作例を、同期サーバ（同期スタンバイサーバ）２Ｂ−１〜２Ｂ−３の動作に着目して説明する。
【００８３】
図５に例示するように、プライマリサーバ２Ａ−１（図６参照）にサーバダウンを伴う障害が発生したことを、同期サーバ２Ｂ（及び非同期サーバ２Ｃ）が検出する（ステップＳ１；図６の矢印（１）参照）。なお、クラスタシステム１においてノード２の障害発生を他のノード２が検出する手法は、既知の種々の手法により実現されてよい。
【００８４】
各同期サーバ２Ｂ−１〜２Ｂ−３の切替制御部２４は、プライマリサーバ２Ａの障害発生を検出すると、同期サーバ２Ｂ−１〜２Ｂ−３間で、ＷＡＬ状態を比較する（ステップＳ２；図６の矢印（２）参照）。
【００８５】
例えば、各同期サーバ２Ｂの切替制御部２４は、自身のノード２の優先度情報２１３を他の同期サーバ２Ｂに対して送信するとともに、当該優先度情報２１３と、他の同期サーバ２Ｂから受信する他のノード２の優先度情報２１３とを比較してよい。なお、同期サーバ２Ｂは、例えばノード情報２１２を参照することで、他の同期サーバ２Ｂを特定してよい。
【００８６】
そして、各同期サーバ２Ｂの切替制御部２４は、ＷＡＬ状態の比較の結果、自身のノード２のＷＡＬ状態が最新を示すか（例えば最新のＷＡＬが適用されているか）否かを判定する（ステップＳ３）。
【００８７】
自身のノード２のＷＡＬ状態が最新ではない場合（ステップＳ３でＮｏ）、当該ノード２においては、処理が終了する。
【００８８】
一方、自身のノード２のＷＡＬ状態が最新である場合（ステップＳ３でＹｅｓ）、当該ノード２が新たなプライマリサーバ２Ａ−２（図６参照）に昇格する（ステップＳ４；図６の矢印（３）参照）。
【００８９】
図６の例では、ノード２Ｂ−１のＷＡＬ番号が“１０”であり、ノード２Ｂ−２及び２Ｂ−３のＷＡＬ番号がそれぞれ“９”であるため、ＷＡＬ番号の大きい（最新である）ノード２Ｂ−１がプライマリサーバ２Ａ−２に昇格する。
【００９０】
なお、最新のＷＡＬが適用されている同期サーバ２Ｂが複数存在する場合（切替候補が複数存在する場合）、同期サーバ２Ｂ間で予め共有されたルールに基づき、これらの切替候補の中のいずれか１つの同期サーバ２Ｂがプライマリサーバ２Ａ−２に昇格してよい。ルールとしては、例示的に、以下のいずれかが挙げられる。
【００９１】
・ノード情報２１２に含まれるノード２の識別情報の番号が小さい（例えば最小である）ノード２がプライマリサーバ２Ａ−２に昇格する。
【００９２】
・最新のＷＡＬの受信時刻が先である（例えば最先である）ノード２がプライマリサーバ２Ａ−２に昇格する。
【００９３】
・過去の統計に基づくＷＡＬの転送効率が良い（例えば最良である）ノード２がプライマリサーバ２Ａ−２に昇格する。
【００９４】
自身のノード２を含む複数のノード２に最新のＷＡＬが適用されていると判断したノード２の各々は、自身のノード２が、上記のいずれかのルールに基づきプライマリサーバ２Ａ−２への昇格対象となるか否かを判定してよい。この場合、昇格対象となるノード２がステップＳ３のＹｅｓのルートに従ってプライマリサーバ２Ａ−２に昇格する。一方、昇格対象とはならないノード２については、ステップＳ３のＮｏのルートに従って、処理が終了する。
【００９５】
なお、ＷＡＬの受信時刻や過去の統計等の情報は、マルチ同期スタンバイ機能によってノード２間で共有されていてもよい。或いは、ステップＳ２において、各同期サーバ２Ｂの切替制御部２４は、自身のノード２におけるＷＡＬの受信時刻や過去の統計等の情報を、自身の優先度情報２１３とともに他のノード２に送信してもよい。
【００９６】
次いで、プライマリサーバ２Ａ−２に昇格したノード２の切替制御部２４は、非同期サーバ２Ｃ−１〜２Ｃ−３のＷＡＬ状態を比較する（ステップＳ５；図７の矢印（４）参照）。例えば、プライマリサーバ２Ａ−２の切替制御部２４は、ノード情報２１２に基づき特定される非同期サーバ２Ｃ−１〜２Ｃ−３の各々に対して優先度情報２１３の取得要求を送信し、各非同期サーバ２Ｃから受信した優先度情報２１３を比較してよい。
【００９７】
プライマリサーバ２Ａ−２の切替制御部２４は、ＷＡＬ状態の比較の結果、ＷＡＬ状態が最新に近い（例えば最新に近いＷＡＬが適用されている）非同期サーバ２Ｃを特定する。そして、プライマリサーバ２Ａ−２の切替制御部２４は、ＷＡＬ状態が最新に近い非同期サーバ２Ｃを、新たな同期サーバ２Ｂ−４（図７参照）に昇格させ（ステップＳ６；図７の矢印（５）参照）、処理が終了する。
【００９８】
図７の例では、ノード２Ｃ−１及び２Ｃ−２のＷＡＬ番号がそれぞれ“８”であり、ノード２Ｃ−３のＷＡＬ番号が“９”であるため、ＷＡＬ番号の大きい（最新に近い）ノード２Ｃ−３が同期サーバ２Ｂ−４に昇格する。
【００９９】
なお、ＷＡＬ番号が最新に近い非同期サーバ２Ｃが複数存在する場合（切替候補が複数存在する場合）、プライマリサーバ２Ａ−２の切替制御部２４は、これらの切替候補の中のいずれか１つの非同期サーバ２Ｃを同期サーバ２Ｂに昇格させてよい。昇格させる基準は、同期サーバ２Ｂからプライマリサーバ２Ａへの昇格の判定に用いる上述したルールと同様であってよい。
【０１００】
上述したノード２の動作モードの切り替えの結果は、例えば、各ノード２で実行されるマルチ同期スタンバイ機能により、ノード情報２１２に反映されてよい。また、優先度情報２１３の一例であるＷＡＬ番号についても、プライマリサーバ２Ａによる更新処理、及び、各ノード２による同期処理の実行に応じて更新されてよい。
【０１０１】
〔１−３−２〕同期スタンバイサーバに障害が発生した場合の動作例
次に、図８及び図９を参照して、同期サーバ（同期スタンバイサーバ）２Ｂ−１に障害が発生した場合の動作例を、プライマリサーバ２Ａ−１の動作に着目して説明する。
【０１０２】
図８に例示するように、同期サーバ２Ｂ−１（図９参照）にサーバダウンを伴う障害が発生したことを、プライマリサーバ２Ａ−１が検出する（ステップＳ１１；図９の矢印（１）参照）。
【０１０３】
プライマリサーバ２Ａ−１の切替制御部２４は、非同期サーバ２Ｃ−１〜２Ｃ−３のＷＡＬ状態を比較する（ステップＳ１２；図９の矢印（２）参照）。例えば、プライマリサーバ２Ａ−１の切替制御部２４は、ノード情報２１２に基づき特定される非同期サーバ２Ｃ−１〜２Ｃ−３の各々に対して優先度情報２１３の取得要求を送信し、各非同期サーバ２Ｃから受信した優先度情報２１３を比較してよい。
【０１０４】
プライマリサーバ２Ａ−１の切替制御部２４は、ＷＡＬ状態の比較の結果、ＷＡＬ状態が最新に近い（例えば最新に近いＷＡＬが適用されている）非同期サーバ２Ｃを特定する。そして、プライマリサーバ２Ａ−１の切替制御部２４は、ＷＡＬ状態が最新に近い非同期サーバ２Ｃを、新たな同期サーバ２Ｂ−４（図９参照）に昇格させ（ステップＳ１３；図９の矢印（３）参照）、処理が終了する。
【０１０５】
図９の例では、ノード２Ｃ−１及び２Ｃ−２のＷＡＬ番号がそれぞれ“８”であり、ノード２Ｃ−３のＷＡＬ番号が“９”であるため、ＷＡＬ番号の大きい（最新に近い）ノード２Ｃ−３が同期サーバ２Ｂ−４に昇格する。
【０１０６】
なお、ＷＡＬ番号が最新に近い非同期サーバ２Ｃが複数存在する場合（切替候補が複数存在する場合）、プライマリサーバ２Ａ−１の切替制御部２４は、これらの切替候補の中のいずれか１つの非同期サーバ２Ｃを同期サーバ２Ｂに昇格させてよい。昇格させる基準は、同期サーバ２Ｂからプライマリサーバ２Ａへの昇格の判定に用いる上述したルールと同様であってよい。
【０１０７】
以上のように、プライマリサーバ２Ａとして動作するノード２の切替制御部２４は、以下の処理を行なう制御部又は第１制御部の一例である。当該処理は、クラスタシステム１内の１又は複数のノード２における障害により同期サーバ２Ｂの数が減少する場合に、１又は複数の非同期サーバ２Ｃを同期サーバ２Ｂとして動作するように制御を行なう、ことを含んでよい。
【０１０８】
〔１−４〕ハードウェア構成例
次に、図１０を参照して、一実施形態に係るノード２及びノード３のハードウェア構成例について説明する。ノード２及びノード３は、互いに同様のハードウェア構成をそなえてよいため、以下、これらの一例としてコンピュータ１０を例に挙げて、コンピュータ１０のハードウェア構成例について説明する。
【０１０９】
図１０に示すように、コンピュータ１０は、例示的に、プロセッサ１０ａ、メモリ１０ｂ、記憶部１０ｃ、ＩＦ（Interface）部１０ｄ、Ｉ／Ｏ（Input / Output）部１０ｅ、及び読取部１０ｆをそなえてよい。
【０１１０】
プロセッサ１０ａは、種々の制御や演算を行なう演算処理装置の一例である。プロセッサ１０ａは、コンピュータ１０内の各ブロックとバス１０ｉで相互に通信可能に接続されてよい。プロセッサ１０ａとしては、例えば、ＣＰＵ、ＭＰＵ、ＧＰＵ、ＡＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ等の集積回路（ＩＣ；Integrated Circuit）が用いられてもよい。なお、ＭＰＵはMicro Processing Unitの略称である。ＧＰＵはGraphics Processing Unitの略称であり、ＡＰＵはAccelerated Processing Unitの略称である。ＤＳＰはDigital Signal Processorの略称であり、ＡＳＩＣはApplication Specific ICの略称であり、ＦＰＧＡはField-Programmable Gate Arrayの略称である。
【０１１１】
メモリ１０ｂは、種々のデータやプログラム等の情報を格納するハードウェアの一例である。メモリ１０ｂとしては、例えばＲＡＭ等の揮発性メモリが挙げられる。
【０１１２】
記憶部１０ｃは、種々のデータやプログラム等の情報を格納するハードウェアの一例である。記憶部１０ｃとしては、例えばＨＤＤ等の磁気ディスク装置、ＳＳＤ等の半導体ドライブ装置、不揮発性メモリ等の各種記憶装置が挙げられる。不揮発性メモリとしては、例えば、フラッシュメモリ、ＳＣＭ（Storage Class Memory）、ＲＯＭ（Read Only Memory）等が挙げられる。
【０１１３】
なお、図２に示すノード２のＤＢ２１は、例えば、ノード２のメモリ１０ｂ及び記憶部１０ｃの少なくとも一方の記憶領域により実現されてもよい。
【０１１４】
また、記憶部１０ｃは、コンピュータ１０の各種機能の全部若しくは一部を実現するプログラム１０ｇを格納してよい。プロセッサ１０ａは、記憶部１０ｃに格納されたプログラム１０ｇをメモリ１０ｂに展開して実行することにより、図１に示すプライマリサーバ２Ａ、同期サーバ２Ｂ、非同期サーバ２Ｃ、又は、ＡＰサーバ３としての機能を実現できる。
【０１１５】
例えば、ノード２においては、ノード２のプロセッサ１０ａが、記憶部１０ｃに格納されたプログラム（サーバ切り替えプログラム）１０ｇをメモリ１０ｂに展開して演算処理を実行することで、動作モードに応じたノード２の機能を実現できる。当該機能は、ＤＢ制御部２２、同期制御部２３、及び切替制御部２４の機能を含んでよい。
【０１１６】
また、ＡＰサーバ３においては、ＡＰサーバ３のプロセッサ１０ａが、記憶部１０ｃに格納されたプログラム１０ｇをメモリ１０ｂに展開して演算処理を実行することで、ＡＰサーバ３としての機能を実現できる。
【０１１７】
ＩＦ部１０ｄは、ネットワーク１ａ、１ｂ、又は５との間の接続及び通信の制御等を行なう通信インタフェースの一例である。例えば、ＩＦ部１０ｄは、ＬＡＮ、或いは、光通信（例えばＦＣ（Fibre Channel；ファイバチャネル））等に準拠したアダプタを含んでよい。
【０１１８】
例えば、ノード２のプログラム１０ｇは、当該通信インタフェース及びネットワーク１ｂ（或いは管理用ネットワーク）を介して、ネットワーク５からコンピュータ１０にダウンロードされ、記憶部１０ｃに格納されてもよい。また、例えば、ノード３のプログラム１０ｇは、当該通信インタフェースを介して、ネットワーク５からコンピュータ１０にダウンロードされ、記憶部１０ｃに格納されてもよい。
【０１１９】
Ｉ／Ｏ部１０ｅは、マウス、キーボード、又は操作ボタン等の入力部、並びに、タッチパネルディスプレイ、ＬＣＤ（Liquid Crystal Display）等のモニタ、プロジェクタ、又はプリンタ等の出力部、の一方又は双方を含んでよい。
【０１２０】
読取部１０ｆは、記録媒体１０ｈに記録されたデータやプログラムの情報を読み出すリーダの一例である。読取部１０ｆは、記録媒体１０ｈを接続可能又は挿入可能な接続端子又は装置を含んでよい。読取部１０ｆとしては、例えば、ＵＳＢ（Universal Serial Bus）等に準拠したアダプタ、記録ディスクへのアクセスを行なうドライブ装置、ＳＤカード等のフラッシュメモリへのアクセスを行なうカードリーダ等が挙げられる。なお、記録媒体１０ｈにはプログラム１０ｇが格納されてもよく、読取部１０ｆが記録媒体１０ｈからプログラム１０ｇを読み出して記憶部１０ｃに格納してもよい。
【０１２１】
記録媒体１０ｈとしては、例示的に、磁気／光ディスクやフラッシュメモリ等の非一時的な記録媒体が挙げられる。磁気／光ディスクとしては、例示的に、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク、ＨＶＤ（Holographic Versatile Disc）等が挙げられる。フラッシュメモリとしては、例示的に、ＵＳＢメモリやＳＤカード等が挙げられる。なお、ＣＤとしては、例示的に、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ等が挙げられる。また、ＤＶＤとしては、例示的に、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等が挙げられる。
【０１２２】
上述したコンピュータ１０のハードウェア構成は例示である。従って、コンピュータ１０内でのハードウェアの増減（例えば任意のブロックの追加や削除）、分割、任意の組み合わせでの統合、又は、バスの追加若しくは削除等は適宜行なわれてもよい。
【０１２３】
〔２〕その他
上述した一実施形態に係る技術は、以下のように変形、変更して実施することができる。
【０１２４】
例えば、図２に示すＤＢ制御部２２、同期制御部２３、及び、切替制御部２４の少なくとも１つの機能を併合してもよく、或いは、分割してもよい。
【０１２５】
また、図１０に示すコンピュータ１０のプロセッサ１０ａは、シングルプロセッサやシングルコアプロセッサに限定されるものではなく、マルチプロセッサやマルチコアプロセッサであってもよい。
【０１２６】
さらに、一実施形態において、クォーラム構成が採用されてもよい。クォーラム構成は、例えば、プライマリサーバ２ＡがＤＢ多重化環境内で唯一となるように、ノード群を複数発生させないようにするマルチノードクラスタ構成の技術である。
【０１２７】
図１１に例示するように、ネットワーク１ａの障害（例えば回線の分断）により、クラスタシステム１がノード群１Ａとノード群１Ｂとに分断された場合を考える。なお、ノード群１Ａには、プライマリサーバ２Ａ、同期サーバ２Ｂ−１及び２Ｂ−２、並びに、非同期サーバ２Ｃ−１及び２Ｃ−２とが含まれる。また、ノード群１Ｂには、同期サーバ２Ｂ−３及び非同期サーバ２Ｃ−３が含まれる。
【０１２８】
このような例において、ノード群１Ｂでは、同期サーバ２Ｂ−３の切替制御部２４が、プライマリサーバ２Ａに昇格してしまうと、ノード群１Ａのプライマリサーバ２Ａと合わせて、クラスタシステム１に２つのプライマリサーバ２Ａが存在することになる。
【０１２９】
このような事態を回避するために、例えば、各ノード２は、クラスタシステム１を構成するノード２の数の過半数以上のノードと通信できなくなった場合、自身のノード２がクォーラムが不成立なノード群に属していると判断し、クラスタ構成から離脱してよい。
【０１３０】
図１１の例では、ノード群１Ｂの同期サーバ２Ｂ−３及び非同期サーバ２Ｃ−３の各々は、クラスタシステム１を構成する７台の過半数以上である、４台のノード２と通信できなくなったため、クラスタ構成から離脱する。
【０１３１】
一方、ノード群１Ａのプライマリサーバ２Ａは、４台のノードと通信できるため、２台の同期サーバ２Ｂがダウンしたと判断し、２台の非同期サーバ２Ｃを同期サーバ２Ｂに切り替える制御を行なってよい。
【０１３２】
なお、離脱状態においては、プライマリサーバ２Ａは切り替えが行なわれず、同期サーバ２Ｂ及び非同期サーバ２Ｃは昇格等の動作モードの変更対象とはならない。なお、ネットワーク１ａの復旧により通信が回復した場合、離脱状態のノード２は、クォーラム構成へ再参入してよい。
【０１３３】
また、クラスタシステム１を構成するノード２の数が偶数の場合には、いずれかのノード２を、ユーザデータ２１１を格納するＤＢ２１が存在しない（同期対象外とする）裁定サーバとして動作させることにより、クォーラム構成を実現できる。
【０１３４】
〔３〕付記
以上の実施形態に関し、さらに以下の付記を開示する。
【０１３５】
（付記１）
プライマリサーバと、前記プライマリサーバのデータを同期方式でバックアップする１又は複数の同期型バックアップサーバと、前記プライマリサーバのデータを非同期でバックアップする１又は複数の非同期型バックアップサーバとを含むサーバシステムにおけるサーバ切り替えプログラムであって、
前記サーバシステム内の１又は複数のサーバにおける障害により前記同期型バックアップサーバの数が減少する場合に、１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、
処理をコンピュータに実行させることを特徴とする、サーバ切り替えプログラム。
【０１３６】
（付記２）
前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御する際、減少する同期型バックアップサーバの数と同じ数の非同期型バックアップサーバを同期型バックアップサーバとして動作するように制御する、処理を前記コンピュータに実行させることを特徴とする、付記１に記載のサーバ切り替えプログラム。
【０１３７】
（付記３）
前記制御は、前記同期型バックアップサーバの数が減少する場合であって、かつ、減少後の前記同期型バックアップサーバの数が所定数となる場合に実行される、ことを特徴とする、付記１に記載のサーバ切り替えプログラム。
【０１３８】
（付記４）
前記非同期型バックアップサーバを前記同期型バックアップサーバへ切り替える際、前記非同期型バックアップサーバの前記プライマリサーバに対する同期状態に基づいて切り替える処理を前記コンピュータに実行させることを特徴とする、付記１〜３のいずれか１項に記載のサーバ切り替えプログラム。
【０１３９】
（付記５）
前記プライマリサーバに対する同期状態は、ＷＡＬ（Write Ahead Logging）の情報に基づいて決定されることを特徴とする、付記４に記載のサーバ切り替えプログラム。
【０１４０】
（付記６）
前記プライマリサーバにおける障害が発生した場合に、１又は複数の前記同期型バックアップサーバのうちのいずれか１つの同期型バックアップサーバを、新たなプライマリサーバとして動作するように制御を行ない、
１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、
処理を前記コンピュータに実行させることを特徴とする、付記１〜５のいずれか１項に記載のサーバ切り替えプログラム。
【０１４１】
（付記７）
プライマリサーバと、前記プライマリサーバのデータを同期方式でバックアップする１又は複数の同期型バックアップサーバと、前記プライマリサーバのデータを非同期でバックアップする１又は複数の非同期型バックアップサーバとを含むサーバシステムにおけるサーバ切り替え方法であって、
前記プライマリサーバのプロセッサが、前記サーバシステム内の１又は複数のサーバにおける障害により前記同期型バックアップサーバの数が減少する場合に、１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、ことを特徴とする、サーバ切り替え方法。
【０１４２】
（付記８）
前記プロセッサが、前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御する際、減少する同期型バックアップサーバの数と同じ数の非同期型バックアップサーバを同期型バックアップサーバとして動作するように制御する、ことを特徴とする、付記７に記載のサーバ切り替え方法。
【０１４３】
（付記９）
前記制御は、前記同期型バックアップサーバの数が減少する場合であって、かつ、減少後の前記同期型バックアップサーバの数が所定数となる場合に実行される、ことを特徴とする、付記７に記載のサーバ切り替え方法。
【０１４４】
（付記１０）
前記プロセッサが、前記非同期型バックアップサーバを前記同期型バックアップサーバへ切り替える際、前記非同期型バックアップサーバの前記プライマリサーバに対する同期状態に基づいて切り替えることを特徴とする、付記７〜９のいずれか１項に記載のサーバ切り替え方法。
【０１４５】
（付記１１）
前記プライマリサーバに対する同期状態は、ＷＡＬ（Write Ahead Logging）の情報に基づいて決定されることを特徴とする、付記１０に記載のサーバ切り替え方法。
【０１４６】
（付記１２）
前記プロセッサが、
前記プライマリサーバにおける障害が発生した場合に、１又は複数の前記同期型バックアップサーバのうちのいずれか１つの同期型バックアップサーバを、新たなプライマリサーバとして動作するように制御を行ない、
１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、
ことを特徴とする、付記７〜１１のいずれか１項に記載のサーバ切り替え方法。
【０１４７】
（付記１３）
プライマリサーバと、
前記プライマリサーバのデータを同期方式でバックアップする１又は複数の同期型バックアップサーバと、
前記プライマリサーバのデータを非同期でバックアップする１又は複数の非同期型バックアップサーバと、をそなえ、
前記プライマリサーバは、
前記サーバシステム内の１又は複数のサーバにおける障害により前記同期型バックアップサーバの数が減少する場合に、１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、ことを特徴とする、サーバ切り替えシステム。
【０１４８】
（付記１４）
前記プライマリサーバは、前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御する際、減少する同期型バックアップサーバの数と同じ数の非同期型バックアップサーバを同期型バックアップサーバとして動作するように制御する、ことを特徴とする、付記１３に記載のサーバ切り替えシステム。
【０１４９】
（付記１５）
前記制御は、前記同期型バックアップサーバの数が減少する場合であって、かつ、減少後の前記同期型バックアップサーバの数が所定数となる場合に実行される、ことを特徴とする、付記１３に記載のサーバ切り替えシステム。
【０１５０】
（付記１６）
前記プライマリサーバが、前記非同期型バックアップサーバを前記同期型バックアップサーバへ切り替える際、前記非同期型バックアップサーバの前記プライマリサーバに対する同期状態に基づいて切り替えることを特徴とする、付記１３〜１５のいずれか１項に記載のサーバ切り替えシステム。
【０１５１】
（付記１７）
前記プライマリサーバに対する同期状態は、ＷＡＬ（Write Ahead Logging）の情報に基づいて決定されることを特徴とする、付記１６に記載のサーバ切り替えシステム。
【０１５２】
（付記１８）
前記プライマリサーバが、
前記プライマリサーバにおける障害が発生した場合に、１又は複数の前記同期型バックアップサーバのうちのいずれか１つの同期型バックアップサーバを、新たなプライマリサーバとして動作するように制御を行ない、
１又は複数の前記非同期型バックアップサーバを前記同期型バックアップサーバとして動作するように制御を行なう、
ことを特徴とする、付記１３〜１７のいずれか１項に記載のサーバ切り替えシステム。
【符号の説明】
【０１５３】
１    クラスタシステム
１ａ、１ｂ、５    ネットワーク
２、３    ノード
２Ａ、２Ａ−１、２Ａ−２    プライマリサーバ
２Ｂ、２Ｂ−１〜２Ｂ−４    同期スタンバイサーバ
２Ｃ、２Ｃ−１〜２Ｃ−３    非同期スタンバイサーバ
２１    ＤＢ
２１１    ユーザデータ
２１２    ノード情報
２１３    優先度情報
２２    ＤＢ制御部
２３    同期制御部
２４    切替制御部
４    端末
【図１】
2019185371.tif 000003
【図２】
2019185371.tif 000004
【図３】
2019185371.tif 000005
【図４】
2019185371.tif 000006
【図５】
2019185371.tif 000007
【図６】
2019185371.tif 000008
【図７】
2019185371.tif 000009
【図８】
2019185371.tif 000010
【図９】
2019185371.tif 000011
【図１０】
2019185371.tif 000012
【図１１】
2019185371.tif 000013