JP6724998B2 - サーバ装置、クラスタシステム、クラスタ制御方法およびプログラム - Google Patents

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１６−２０５９３９号（２０１６年１０月２０日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、サーバ装置、クラスタシステム、クラスタ制御方法およびプログラムに関し、特にクラスタシステムに設けられたサーバ装置、複数のサーバ装置を備えたクラスタシステム、クラスタ制御方法およびプログラムに関する。

高信頼性または高可用性を要求されるシステムにおいては、システムを冗長化して、複数のサーバ装置でクラスタシステムを構成する手法が用いられる。

クラスタシステムの主な構成として、アクティブ・スタンバイ（ＡＣＴ−ＳＢＹ、Active-Standby）構成およびＮ−ＡＣＴ（Active）構成が知られている。

ＡＣＴ−ＳＢＹ構成は、２台のサーバ装置を備えている。通常運転時には現用系（ＡＣＴ、Active）のサーバ装置のみが有効化され、待機系（ＳＢＹ、Standby）のサーバ装置は無効化される。現用系（ＡＣＴ）のサーバ装置に障害が生じた場合、現用系（ＡＣＴ）のサーバ装置の処理が待機系（ＳＢＹ）のサーバ装置に引き継がれることでサービスの提供が維持される。

一方、Ｎ−ＡＣＴ構成は、複数のサーバ装置を同時に稼働させる。すなわち、Ｎ−ＡＣＴ構成は、処理中のサーバ装置が同時に他サーバ装置の予備系の役割を担う冗長化構成である。

関連技術として、特許文献１には、ハートビートＬＡＮ（Local Area Network）経由での監視用信号（ハートビート）の疎通ができなくなった場合に、ハートビートの送信経路を一般ＬＡＮ経由に切り替える技術が記載されている。

また、特許文献２には、各ノード上でそれぞれ処理を実行できる割当て時間を算出し、各ノードは割当てられた時間内で処理を実行することで、両ノードで処理が同時に起動しないようにする技術が記載されている。

さらに、特許文献３には、遠隔クラスタシステムがネットワーク障害で分断されたとき、障害発生後に双方のサーバ装置で更新したデータを障害復旧後に双方で差異が生じないように復旧するためのスプリットブレインリカバリ方式が記載されている。

また、特許文献４には、対象サーバから定期的に送信されるハートビート信号を監視し、一定期間以上ハートビート信号を受信しなかった場合、対象サーバの障害発生を検出してフェイルオーバを実行する技術が記載されている。

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

上記特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。以下の分析は、本発明者によってなされたものである。

Ｎ−ＡＣＴ（Active）構成においては、バックアップの多重度を柔軟に変更することができる。したがって、ＡＣＴ−ＳＢＹ（Active-Standby）構成と比較して設備の利用効率を高めることができる。また、後述するスプリットブレイン（split brain）のような問題も生じ難いというメリットもある。しかしながら、特にキャリア向け製品・ソリューションの分野では、Ｎ−ＡＣＴ構成よりもＡＣＴ−ＳＢＹ構成を採用する場合が多い。その理由は、ＡＣＴ−ＳＢＹ構成には、以下（１）〜（３）のような利点があるためである。

（１）Ｎ−ＡＣＴ構成の場合、同一のサービスを複数のサーバ装置内で多重起動させ、これらを同時に稼働させる。このとき、複数のＡＣＴ（Active）ノード間のデータ整合性を維持するための同期メカニズムが必要とされる。状態データを持たないステートレスなクラスタシステムであれば、Ｎ−ＡＣＴ構成を比較的容易に実現することができる。一方、状態データを持つステートフルなクラスタシステムでは、同期メカニズムのために高度な技術が必要とされる。したがって、一般的にＮ−ＡＣＴ構成のクラスタシステムは高価となり、運用も難しいという問題がある。一方、ＡＣＴ−ＳＢＹ構成の場合、Ｎ−ＡＣＴ構成よりも単純な技術によって実現することができる。したがって、ＡＣＴ−ＳＢＹ構成のシステムは、システム導入コストおよび運用コストを削減し易いという特長がある。キャリア向け製品／ソリューションにおいては、呼の状態を保持する必要があるステートフルシステムとなることが多い。したがって、Ｎ−ＡＣＴ構成よりもＡＣＴ−ＳＢＹ構成の方が適用しやすいという面もある。

（２）ＡＣＴ−ＳＢＹ構成の場合、フローティングＩＰ（Internet Protocol）アドレスにより対向ノードから単一のＩＰアドレスでクラスタシステムにアクセスすることができる。したがって、冗長構成を組んだ場合であっても、対向ノードへのインパクトが少ないという利点がある。例えば、１組のＡＣＴ−ＳＢＹ構成のクラスタシステムであれば、対向ノード側に複数ノードへの振り分け機構を実装する必要がない。すなわち、ＡＣＴ−ＳＢＹ構成はＮ−ＡＣＴ構成と比較して冗長構成を導入し易く、より広く採用されている。

（３）Ｎ−ＡＣＴ構成では、ＡＣＴ−ＳＢＹ構成のように予備系（ＳＢＹ）専用のサーバ装置を待機させることなく、処理中のサーバ装置が同時に他サーバ装置の予備系の役割も果たす。したがって、Ｎ−ＡＣＴ構成は、設備の利用効率を高める目的で導入されることがある。かかる目的でＮ−ＡＣＴ構成を採用する場合、クラスタシステムの多重度（すなわちサーバ装置数）を極力少なくすることになる。したがって、システム内の１つまたは複数のサーバ装置がフェイルし（すなわち障害が発生し）、残りのサーバ装置の処理キャパシティ内で稼働を継続させる（すなわち縮退運転させる）場合、処理能力が不足するおそれがある。一方、ＡＣＴ−ＳＢＹ構成では、１台の現用系（ＡＣＴ）につき１台の専用の待機系（ＳＢＹ）が設けられる。したがって、障害が発生した場合でも、障害発生前と同数のサーバ装置で稼働を継続することができる。すなわち、ＡＣＴ−ＳＢＹ構成は、Ｎ−ＡＣＴ構成よりも耐障害性が高いシステムであるといえる。したがって、高い信頼性と可用性を求められる（例えば１台のサーバ装置がフェイルしても残りのサーバ装置で所要の処理能力を提供することが求められる）キャリア向けシステムでは、一般にＮ−ＡＣＴ構成よりもＡＣＴ−ＳＢＹ構成の方が適している。

そこで、以下ではＡＣＴ−ＳＢＹ構成のクラスタシステムを対象とする。なお、ＡＣＴ−ＳＢＹ構成のクラスタにおいては、後述するスプリットブレインの状態が発生する可能性がある。本発明は、ＡＣＴ−ＳＢＹ構成におけるスプリットブレインに関連する少なくとも１つの問題を解決するものである。

２ノードで構成されるＡＣＴ−ＳＢＹ構成のクラスタシステムにおいては通常、定期的な時間間隔（例えば１秒おき）でハートビートパケットを相互に送信し合う。これにより、自ノードの状態（例えば、正常動作しているか、ノード状態は現用系か待機系かなどを示す情報）を対向ノードに通知する。待機系ノードにおいては、対向ノード（現用系ノード）からのハートビートパケットが一定期間届かなかった場合（すなわちタイムアウト発生時）、対向する現用系ノードで障害が発生したものと判断し、自らが現用系としての動作（例えばサービスの起動、フローティングＩＰアドレスの有効化など、すなわちフェイルオーバ処理）を開始する。かかるクラスタシステムでは、以下に詳述する問題が生じるおそれがある。

［１］第１の問題
上記のように、ＡＣＴ−ＳＢＹ構成のクラスタシステムでは、ハートビートパケットの通信障害に起因して以下に述べるスプリットブレインという現象が生じるという問題（第１の問題）がある。

元現用系ノードにおいて実際に障害が発生してサービスが停止していた場合には、上述の機構によりフェイルオーバ処理が問題なく機能する。この場合、待機系が現用系に切り替わることでサービスの提供を継続することができる。一方、ハートビートパケット到達の途絶が現用系ノードの障害によるものではなく、ハートビート通信経路上のネットワークの一時的な障害または不安定動作に起因する場合がある。これらの原因によりハートビートパケットの喪失や送達遅延が発生した場合、現用系ノードはそのまま現用系の動作を継続している。このとき、待機系ノードが現用系としての動作を開始すると、両ノードがいずれも現用系として動作する、いわゆる「スプリットブレイン（split brain）」と呼ばれる状態に陥る。スプリットブレインの状態においては、一般に、クラスタ内の両ノード間の整合性が失われ、正常な動作ができなくなる。したがって、ハートビートパケットの通信障害に起因するスプリットブレインの発生（第１の問題）を回避することが求められる。

クラスタシステムにおいてスプリットブレインの状態が生じると、さらに次のような問題も起こり得る。すなわち、共有ディスクを用いるシステムにおいては、両ノードから同時にデータ書き換えが発生することにより、データが破壊されるおそれがある。

また、共有ディスクを用いることなく、各サーバ装置のローカルディスク内にＤＢ（Database）を持つクラスタシステム（両ローカルディスク内のＤＢを随時同期するシステム）においても、問題が生じるおそれがある。かかるシステムでは上述のようなデータ破壊の危険性はない。しかし、本来クラスタ内のいずれかのサーバ装置のみが現用系として動作すべきところ、両ノードがそれぞれ独自に現用系として動作し、それぞれのローカルデータを更新することにより、両ノード間のデータの整合性が失われるおそれがある。

両ノード間の通信復旧後にローカルデータを同期する機能を有し、データの復旧が可能なシステムであっても、スプリットブレインが発生している間は両ノードが同一のフローティングＩＰアドレスをactivate（有効化）してサービスを提供してしまう。このとき、クラスタシステムにアクセスする外部ノード（相互接続する対向ノードやエンドユーザ端末）は、クラスタシステムにアクセス不能となるか、または、ＩＰルーティングに依存して到達可能ないずれかのノードにルーティングされることになる。

また、接続中の呼／セッションにおいてその途中でアクセス先のノードが変わってしまった場合、サービスの継続が不可能となるケースがある。例えば、スプリットブレイン発生前に両ノード間のＤＢや呼／セッション情報の同期のための通信が途絶えており、これらの情報が待機系に引き継がれていなかった場合、このような問題が起こり得る。

以上のように、スプリットブレインが発生した場合には、様々な問題が発生することが想定される。したがって、スプリットブレインを未然に防ぐ必要がある。

また、ＩＰネットワークにおいては、パケットの喪失や一時的なパケット送達の遅延が発生し得る。特に、クラスタシステム内の２つのノードをそれぞれ地理的に離れた別々のサイトに配置する地理的冗長構成を採用した場合、２ノード間のハートビートパケットは高速専用線ではなくサイト間を接続する通常のＩＰネットワーク（ＷＡＮ（Wide Area Network）など）を経由してやりとりされることもある。このような場合、ハートビートパケットの途絶や遅延が発生する可能性が高くなる。

ところで、ネットワーク障害によりハートビートパケットが一定時間届かないことによる誤ったフェイルオーバ（スプリットブレイン）の問題を解決するために、次の方法が考えられる。すなわち、ハートビートパケットの途絶を検知してから対向ノード障害と判断するまでのタイムアウト期間を予め長めに設定して、フェイルオーバの発生確率を下げる方法が考えられる。しかしながら、テレコム系システムのように高信頼性を要求されるシステムにおいては、ノード障害発生時におけるサービス停止時間を極力短くすることが求められる。したがって、対向ノードの障害発生を短時間で検知するために、ハートビートのタイムアウト期間も短く設定する必要があり、かかる方法を採用することは困難である。

以上より、対向ノード障害の検知・フェイルオーバの応答性を極力維持しつつ、ネットワーク障害に起因するハートビートパケットの不達・遅延による不適切なフェイルオーバ（スプリットブレイン）の発生（第１の問題）を防ぐことが望まれる。

［２］第２の問題
ＡＣＴ−ＳＢＹ構成のクラスタシステムでは、スプリットブレインが生じた後、実行中のサービスに影響が及ぶという問題（第２の問題）がある。

第１の問題で述べたように、ＡＣＴ−ＳＢＹ構成のクラスタシステムでは、待機系ノードにて現用系からのハートビート到着が一定時間途絶してタイムアウトとなった場合、対向ノード障害と認識して自身が現用系としての動作を開始（すなわちフェイルオーバ処理を実行）する。しかし、実際にはノード障害ではなくネットワークの一時的な不通が原因であり、元現用系は現用系としての動作を継続している（すなわちスプリットブレインが生じる）場合がある。かかる場合においても、実行中のサービスへの影響を最小限に抑えつつ、正常状態に復帰させることが望ましい。

その理由は、スプリットブレイン発生後もアクセス先のノードが変わらない呼／セッションにおいては、そのままサービス（呼接続）が継続している状態であり、これらの呼／セッションを維持する必要があるからである。また、スプリットブレイン発生後に新たに生成されたシステムへのトランザクション要求や呼処理要求についても、アクセスした方のノードによってサービス処理が実行されるため、これらを維持する必要もあるからである。

ハートビート疎通が復旧して相互のノードの状態を把握できるようになった場合、システムを通常の状態に戻すために、一方のノードを現用系として維持し、他方のノードを待機系に遷移させるという動作を速やかに実行する必要がある。なぜなら、スプリットブレインの状態では、上述の通りシステムへの様々な弊害が生じることに加えて、フェイルオーバが不可能な冗長性を欠いた異常な状態ともいえるからである。

上記のように、スプリットブレイン発生後も継続している呼／セッションが存在する可能性がある。しかし、ハートビート復旧後に待機系に遷移させることになった方のノード上の呼やセッションに関しては、待機系への遷移動作を行った瞬間にサービス断となってしまう。

単一のリクエスト／レスポンスのみで完結するサービスであれば、リトライすることで存続している現用系にアクセスしてサービスが完了するため、サービスへの影響は小さい。しかしながら、長時間に亘って通話の呼状態を維持する必要があるテレコム系システムにおいては、スプリットブレインから復旧させるタイミングにおいて呼状態のノード間での同期が行われていない。したがって、待機系への切り替えのタイミングで呼救済されず、呼切断となってしまう。しかし、高可用性が要求されるキャリア系システムにおいては、ハートビート通信の途絶といった異常発生時／復旧動作時においても、接続中の呼は可能な限り維持することが求められる。

一例として、スプリットブレイン状態になる直前まで現用系として動作していたノードをスプリットブレイン発生直後にそのまま待機系に遷移させる方法が考えられる。しかし、かかる方法によると、システムに保持しているトランザクション／接続中セッション（呼）のほぼ全数が当該ノード上に存在するため、サービスへの影響が非常に大きくなるという問題がある。

したがって、スプリットブレイン状態を検知しつつも、両ノード間でデータの同期およびセッション保持数の比較ができない状態となった場合、元現用系ノードがスプリットブレイン発生の直後に待機系に遷移することを防ぐ必要がある。すなわち、このような場合には、元現用系ノードは少なくとも一定期間に亘って現用系の動作を維持することが望ましい。

ここで、スプリットブレイン状態を検知しつつも、両ノード間でデータの同期およびセッション保持数の比較ができない状態として、例えば、元現用系から元待機系への一方向のみのハートビートが途絶してスプリットブレインに至ったケースが考えられる。

ハートビート通信が両方向について途絶してスプリットブレイン状態となった後、両方向のハートビート通信が復旧した状態（双方向の通信が可能になった状態）であれば、ハートビートパケットを用いて両ノードが自ノードが保持するトランザクションやセッション（呼）の数に関する情報を交換することができる。このとき、例えばセッション数が少ない方のノードのセッション情報を他方のノードにハートビート通信路を経由して同期した後、セッション数が少ない方のノードを即座に待機系に遷移させることができる。

一方、元現用系から元待機系への一方向のハートビートパケットのみが途絶してスプリットブレインに至った状態では、スプリットブレインが発生したことを把握しているノードは、ハートビートパケットを受信している側の元現用系ノードのみとなる。このとき、自ノードを待機系に遷移させてスプリットブレインを解消するかどうか、および、そのタイミングについては、元現用系ノードの判断に委ねられる。

しかし、クラスタシステムを長期間に亘ってスプリットブレイン状態のままとした場合、上述のようなさまざまな弊害が生じるおそれがある。したがって、セッション保持数の比較およびデータ同期ができない状態が続いていた場合であっても、いずれかのタイミングで待機系への遷移動作を行うことが好ましい。

以下、ＡＣＴ−ＳＢＹ構成のクラスタシステムで第２の問題（スプリットブレインが生じた後、実行中のサービスに影響が及ぶ問題）が生じるケースについて具体的に説明する。

［２−１］ハートビートパケットが途絶（タイムアウト）したのが現用系と待機系の間の両方向である場合
この場合、待機系ノードは対向ノード（現用系ノード）に障害が発生したものと認識して、現用系としての動作を開始する。しかし、ハートビートが双方向途絶しているため、元現用系ノードは元待機系ノードが現用系の動作を開始したことを把握することができない。したがって、元現用系ノードは、そのまま現用系としての動作を継続する。この時点で、両ノードがいずれも現用系として動作するスプリットブレインが生じる。

ここで、双方向のハートビートが復旧した場合、現用系の動作を行う両ノードは、それぞれ受信したハートビートパケット内の情報に基づいて、対向ノードも自ノードと同様に現用系の動作をしていることを把握する。

スプリットブレインの状態を解消するために、いずれかのノードのサービスを停止して待機系に遷移させる必要がある。しかし、サービスを停止させた方のノードに接続してサービスを受けていた他ノードや端末のトランザクションや呼は切断されるため、サービスに影響が出ることになる。そこで、サービスへの影響を抑えつつ、クラスタシステムを正常な状態（すなわち、一方が現用系のノード、他方が待機系のノードとして動作する状態）に復旧させる方法を提供する必要がある。

［２−２］現用系から待機系の一方向のハートビートパケットのみが途絶（タイムアウト）し、逆方向のハートビートパケットが到達している場合
待機系のノードは対向ノード（現用系）に障害が発生したものと認識して、現用系としての動作を開始する（すなわち、両ノードが現用系の状態となる）。ただし、この場合、元現用系ノードはハートビートパケットを参照することで、元待機系ノードが現用系としての動作を開始したことを把握することができる。

この段階で、自らを待機系に遷移させてスプリットブレインの状態を解消することができるのは、両ノードが現用系の動作を行っていることを把握している元現用系ノードのみである。ところで、元待機系ノードが現用系としての動作を開始（フェイルオーバを実行）した直後の段階では、システムにて保持しているトランザクションや呼のセッションの大半は元現用系ノード上に存在している。逆に、新たに現用系として動作を開始した元待機系のノード側には、フェイルオーバ直後にはトランザクションや呼のセッションはほとんど存在していない。ここで、元現用系から元待機系へのハートビートパケットが途絶したのが一時的なネットワークの問題である場合、フェイルオーバ発生直後にハートビートパケットの送達が復旧する可能性もある（なお、元現用系から元待機系へのハートビートパケットが復旧すれば、現用系動作を開始したばかりの元待機系ノードが、システムがスプリットブレインの状態になっていることを検知して再度自らを待機系に遷移させてもよい）。

以上より、対向ノード（元待機系）が現用系としての動作を開始したことを、元現用系ノードがハートビートパケットを介して把握した場合、元現用系ノードが現用系としての動作を直ちに停止して待機系に遷移してスプリットブレインを解消することは、必ずしも適切とはいえない。かかる動作によると、実行中のサービスへのインパクトが大きくなるおそれがあるからである。すなわち、元現用系ノードが即座に待機系に遷移すると、元現用系ノードが保持していた大半のトランザクションや呼が破棄され、サービスに大きな影響が出るからである。

そこで、元現用系ノードが、対向ノード（元待機系）が現用系としての動作を開始したことを、ハートビートパケットを介して検知した場合、サービスへの影響を抑えつつシステムを正常な状態（現用系／待機系での動作）に復旧させる方法を提供する必要がある。

上述の第１および第２の問題に関連する先行技術が知られている。特許文献１は、第１の問題（すなわちネットワーク障害に起因するハートビートパケットの不達によるスプリットブレインの発生）に関連する技術を開示する。しかし、特許文献１は、本発明のように、ハートビートパケットをやり取りするために単一の通信経路を利用する状況（例えば、地理的冗長構成のようにサイト間の通信経路を複数確保できない場合や、複数の通信経路が存在するものの災害発生時などにおいてこれらの通信経路の一部が使用できない場合など）を想定したものではない。

また、第１の問題を解消するための技術として、次の技術が知られている。すなわち、クラスタシステム内の対向ノードの状態を正確に把握するために、２ノード間のハートビートパケットのみならず、第３のサーバ装置（Witnessサーバ装置）からの情報も利用する技術が知られている。具体的には、待機系ノードは、対向する現用系ノードからのハートビートパケットが途絶えた場合、Witnessサーバ装置から取得した情報も対向する現用系ノード上で障害が発生していることを示すときに限り、フェイルオーバ処理を実行する。しかし、かかる方法によると、システム内に第３のサーバ装置を追加的に設置する必要があり、コストの増大を招くおそれがある。特に地理的冗長構成においては、第３のサーバ装置が上記の目的を果たすためには、両ノードが設置されるサイトとは別の第３のサイトに第３のサーバ装置を設置する必要があり、制約が大きいという問題もある。したがって、第３のサーバ装置（Witnessサーバ装置）を用いた技術によると、クラスタシステム内の２ノード間のハートビートパケットのやり取りのみに基づいて自律的にスプリットブレインを回避することができない。

特許文献２は、第２の問題（スプリットブレインが生じた後、実行中のサービスに影響が及ぶ問題）に関連する技術を開示する。しかしながら、特許文献２に記載された技術は各ノードが割当てられた時間内で処理を実行するものである。したがって、かかる技術はテレコム系システムのように呼が接続している間、継続して呼情報を同一のノードで保持し、その呼に関連する処理を継続する必要があるシステムには適していない。

また、特許文献３はスプリットブレインリカバリ方式を開示するものの、かかる方式によると、スプリットブレイン発生時において、システムを正常状態に復帰させる際、実行中のサービスへの影響を抑えることはできない。

さらに、特許文献４に記載された技術は冗長機能を持つクラスタシステムにおけるフェイルオーバの一般的な動作を開示するものである。すなわち、かかる技術は、ハートビート通信ネットワークの不安定動作、輻輳、障害などに起因する誤ったフェイルオーバ（ないしスプリットブレイン）が発生しないようにすることには何ら寄与しない。

そこで、クラスタシステムにおいてハートビートパケットの通信障害に起因するサービスの低下を防ぐことが課題となる。本発明の目的は、かかる課題解決に寄与するサーバ装置、クラスタシステム、クラスタ制御方法およびプログラムを提供することにある。なお、その他の課題および解決手段は、後述する実施形態の説明において明らかにされる。

本発明の第１の態様に係るサーバ装置は、現用系または待機系として動作する２台のサーバ装置を備えたクラスタシステムにおける一のサーバ装置（第１のサーバ装置）である。このサーバ装置（第１のサーバ装置）は、対向するサーバ装置（第２のサーバ装置）との間でハートビートパケットを送受信するハートビート送受信部を備えている。また、サーバ装置（第１のサーバ装置）は、前記ハートビートパケットの受信状況に応じて、自サーバ装置（即ち、第１のサーバ装置）の動作を待機系から現用系に遷移するためのタイムアウト期間を調整する対向ノード監視部を備えている。

本発明の第２の態様に係るクラスタシステムは、第１の態様に係る第１のサーバ装置を、現用系または待機系として動作する２台のサーバ装置の一方として備えている。

本発明の第３の態様に係るクラスタ制御方法は、現用系または待機系として動作する２台のサーバ装置を備えたクラスタシステムにおける一のサーバ装置（第１のサーバ装置）によるクラスタ制御方法である。クラスタ制御方法は、対向するサーバ装置（第２のサーバ装置）との間でハートビートパケットを送受信するステップを含む。また、クラスタ制御方法は、前記ハートビートパケットの受信状況に応じて、自サーバ装置（第１のサーバ装置）の動作を待機系から現用系に遷移するためのタイムアウト期間を調整するステップを含む。

本発明の第４の態様に係るプログラムは、現用系または待機系として動作する２台のサーバ装置を備えたクラスタシステムにおける一のサーバ装置（第１のサーバ装置）に設けられたコンピュータに対して処理を実行させる。プログラムは、対向するサーバ装置（第２のサーバ装置）との間でハートビートパケットを送受信する処理を実行させる。また、プログラムは、前記ハートビートパケットの受信状況に応じて、自サーバ装置（第１のサーバ装置）の動作を待機系から現用系に遷移するためのタイムアウト期間を調整する処理を実行させる。なお、プログラムは、非一時的なコンピュータ可読記録媒体（non-transitory computer-readable storage medium）に記録されたプログラム製品として提供することもできる。

本発明に係るサーバ装置、クラスタシステム、クラスタ制御方法およびプログラムによると、クラスタシステムにおいてハートビートパケットの通信障害に起因するサービスの低下を防ぐことが可能となる。即ち、本発明は、背景技術に示したクラスタシステムを、その信頼性及び可用性を飛躍的に向上させたクラスタシステムへと変換するものとなっている。

一実施形態に係るサーバ装置の構成を例示するブロック図である。 実施形態に係るクラスタシステムの構成を例示するブロック図である。 第１の実施形態におけるハートビートパケットの構成を例示する図である。 第１の実施形態におけるハートビートパケット送信側のサーバ装置の動作を例示するフロー図である。 第１の実施形態におけるハートビート受信側のサーバ装置の動作を例示するフロー図である。 第２および第３の実施形態におけるハートビートパケットの構成を例示する図である。 第２の実施形態に係るクラスタシステムの動作を例示するシーケンス図である。 第３の実施形態に係るクラスタシステムの動作を例示するシーケンス図である。

はじめに、一実施形態の概要について説明する。なお、この概要に付記する図面参照符号は、専ら理解を助けるための例示であり、本発明を図示の態様に限定することを意図するものではない。また、以下の説明で用いる図面中のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。

図１は、一実施形態に係るサーバ装置２の構成を例示するブロック図である。サーバ装置２は、現用系または待機系として動作する２台のサーバ装置２Ａ、２Ｂを備えたクラスタシステム１（図２）における一のサーバ装置（２Ａまたは２Ｂ）である。図１を参照すると、サーバ装置２は、対向するサーバ装置との間でハートビートパケットを送受信するハートビート送受信部６と、ハートビートパケットの受信状況に応じて、自サーバ装置の動作を待機系から現用系に遷移するためのタイムアウト期間を調整する対向ノード監視部５と、を備えている。

かかるサーバ装置２によると、対向ノード監視部５はハートビートパケットの受信状況に応じて（例えばハートビートパケットが欠落した場合、または、ハートビートパケットを受信するまでの遅延時間が所定の閾値以上である場合）、タイムアウト期間を延長することができる。したがって、かかるサーバ装置２によると、クラスタシステム１においてハートビートパケットの通信障害に起因するスプリットブレインの発生確率を低減し、スプリットブレインによるサービスの低下を防ぐことが可能となる。

次に、一実施形態の他の構成について説明する。図２を参照すると、サーバ装置２は、自サーバ装置が保持するセッション数と対向するサーバ装置が保持するセッション数とを比較して、自サーバ装置の動作を現用系のまま維持するか、または、待機系に遷移させるかを決定するクラスタ管理部３を備えている。ここで、クラスタ管理部３（例えばサーバ装置２Ｂのクラスタ管理部３）は、スプリットブレインの発生後（例えば図７のステップＣ１１、Ｃ１２）、自サーバ装置（２Ｂ）の保持するセッション数（ｎ）が対向するサーバ装置（２Ａ）の保持するセッション数（ｍ）よりも多い場合（ｎ＞ｍ）、自サーバ装置（２Ｂ）の動作を現用系のまま維持する（図７のステップＣ２５、Ｃ３２）。

かかるサーバ装置２によると、スプリットブレインを解消するために、一方のノードを待機系に遷移させる際、セッション数が相対的に多いノードの方を現用系のまま維持することができる。したがって、かかるサーバ装置２によると、サービスへの影響を抑えつつ、クラスタシステム１をスプリットブレインの状態から正常な状態に復旧させることができる。

また、現用系のサーバ装置（２Ｂ）から待機系のサーバ装置（２Ａ）へのハートビートパケットのみが不通となり（図８のステップＤ１４）、スプリットブレインが発生することもある（例えば図８のステップＤ３）。この場合、クラスタ管理部３（サーバ装置２Ｂのクラスタ管理部３）は対向するサーバ装置（２Ａ）の保持するセッション数（ｍ）が自サーバ装置（２Ｂ）の保持するセッション数（ｎ）よりも多い場合（図８のステップＤ６１のＹｅｓ）、または、対向するサーバ装置（２Ａ）が現用系の動作を開始したことを把握（図８のステップＤ５１）してから所定の期間が経過した場合（図８のステップＤ６２のＹｅｓ）、自サーバ装置（２Ｂ）の動作を待機系に遷移させ（図８のステップＤ６３）、それ以外の場合、自サーバ装置の動作を現用系のまま維持するようにしてもよい。

かかるサーバ装置２によると、現用系から待機系へのハートビートのみが不通となりスプリットブレインが発生し、その後ハートビート通信が復旧せず、データの同期が実行できない場合であっても、サービスへの影響を抑えることができる。その理由は、スプリットブレイン発生を検知した方のノード（すなわち元現用系ノード）がすぐに待機系に遷移する代わりに、所定の条件を充足するのを待ってから待機系に遷移するからである。

＜実施形態１＞
次に、第１の実施形態に係るクラスタシステムについて図面を参照して説明する。本実施形態のクラスタシステムは、上述の第１の問題を解消することを目的とする。すなわち、本実施形態のクラスタシステムは、ネットワーク不安定動作による一時的なハートビートパケットの途絶または遅延により対向ノード障害と誤認することによるフェイルオーバ（スプリットブレイン）の発生を防ぐことを目的とする。

［構成］
まず、本実施形態のクラスタシステムの構成について図面を参照して説明する。ここでは、クラスタシステムは、一例としてＡＣＴ−ＳＢＹ（Active-Standby）構成を有するものとする。図２は、本実施形態に係るクラスタシステム１の構成を例示するブロック図である。なお、図２には、呼処理ネットワーク８を介してクラスタシステム１にアクセスするクライアント端末９および他ノード１０を併せて示す。

図２を参照すると、クラスタシステム１は、ハートビートネットワーク７を介して接続されたサーバ装置２Ａおよび２Ｂを備えている。サーバ装置２Ａおよび２Ｂは、通常同一のサイト内に設置される。また、通常運用時には、サーバ装置２Ａ、２Ｂのうちの一方が現用系として動作し、他方が待機系として動作する。以下では、サーバ装置２Ａ、２Ｂを区別する必要がない場合、サーバ装置２などと総称する。

現用系として動作するサーバ装置２はフローティングＩＰ（Internet Protocol）アドレスを有効化し、呼処理ネットワーク８を介して、クライアント端末９や他の呼処理ノード（図２の他ノード１０）と通信を行う。

図２を参照すると、サーバ装置２Ａ、２Ｂは、それぞれクラスタ管理部３、負荷監視部４、対向ノード監視部５、および、ハートビート送受信部６を備えている。

ハートビート送受信部６は、対向ノードとの間でハートビートパケットを相互に送受信する。各サーバ装置２のハートビート送受信部６は、ハートビートネットワーク７を介して定期的にハートビートパケットを相手ノードに送信する。

クラスタ管理部３は、自ノードのクラスタ状態（現用系／待機系）を管理する。クラスタ管理部３は、自ノードが待機系の状態において、対向ノード（現用系）からのハートビートパケットがタイムアウトした場合、フェイルオーバ処理を起動して自ノードを現用系の動作に切り替える。

負荷監視部４は、自ノードの負荷状態（例えばＣＰＵ（Central Processing Unit）使用率など）を監視する。

対向ノード監視部５は、対向ノードから受信したハートビートパケットに基づいて、対向ノードの状態を監視する。また、対向ノード監視部５は、ハートビートパケットの受信状況に応じて、自サーバ装置の動作を待機系から現用系に遷移するためのタイムアウト期間を調整する。対向ノード監視部５は、ハートビートパケットが欠落した場合、または、ハートビートパケットを受信するまでの遅延時間が所定の閾値以上である場合、タイムアウト期間を延長する。さらに、対向ノード監視部５は、対向するサーバ装置２の負荷が所定の閾値以下である場合、タイムアウト期間を延長するようにしてもよい。

図３は、ハートビートパケットの構成を例示する図である。図３を参照すると、ハートビートパケットは、「シーケンス番号」、「ノード状態情報（現用系／待機系）」および「負荷状態情報」を含む。「シーケンス番号」はハートビートパケットの送信ごとに更新（例えば、インクリメントまたはデクリメント）される整数値である。「ノード状態情報（現用系／待機系）」は、自ノードのクラスタ状態（現用系／待機系）を表す値である。「負荷状態情報」は、自ノードの負荷状態（ＣＰＵ使用率など）を表す値である。

ハートビート送受信部６は、ハートビートパケットの送信ごとに「シーケンス番号」を更新してハートビートパケットに設定する。また、ハートビート送受信部６は、クラスタ管理部３から自ノードのクラスタ状態（現用系／待機系）を取得してハートビートパケットの「ノード状態情報」に設定する。さらに、ハートビート送受信部６は、負荷監視部４から自ノードの負荷状態を取得してハートビートパケットの「負荷状態情報」に設定する。

［動作］
次に、本実施形態のクラスタシステム１の動作について図面を参照して説明する。図４は、ハートビート送信側ノードの動作を例示するフロー図である。

図４を参照すると、ハートビートパケットを送信する側のサーバ装置２のハートビート送受信部６は、送信するハートビートパケットに、図３に示す情報を設定（セット）する（ステップＡ１）。

ハートビート送受信部６は、ステップＡ１で作成したハートビートパケットを対向ノードのハートビート送受信部６に向けて、ハートビートネットワーク７を介して送信する（ステップＡ２）。

ハートビート送受信部６は、予め設定されたハートビート送信間隔（例えば１秒間）だけ処理を一時停止した後（ステップＡ３）、ハートビートパケットの設定（ステップＡ１）に戻る。以下、ハートビート送受信部６は、同様の処理を繰り返す。

図５は、ハートビート受信側のノードの動作を例示するフロー図である。待機系のサーバ装置が現用系のサーバ装置から送信されるハートビートパケットを用いて現用系のサーバ装置の状態監視を行う際、通常、ハートビート途絶のタイムアウト期間（すなわち障害と判断するまでの期間）は固定値（例えば３秒）に設定される。一方、本実施形態では、対向ノード監視部５はパケット落ち（欠落）、または、遅延の傾向（例えば統計的な振る舞い）に応じて、タイムアウト期間を動的に変化させる。

サーバ装置２の対向ノード監視部５は、ハートビートタイムアウト期間を表す変数を保持する。対向ノード監視部５は、かかる変数に対してシステム起動時にデフォルト値（例えば３秒）を設定する（ステップＢ１）。

対向ノード監視部５は、ハートビート監視タイマを起動する（ステップＢ２）。

次に、ハートビート送受信部６は、対向ノードからハートビートパケットの受信を開始する（ステップＢ３）。

対向ノード監視部５は、ハートビート監視タイマがタイムアウトする前に対向ノードからハートビートパケットを受信したかどうかを確認する（ステップＢ４）。

タイムアウト前にハートビートパケットを受信しなかった場合（ステップＢ４のＮｏ）、対向ノード監視部５はクラスタ管理部３から自ノードの状態（現用系か待機系か）を読み出し、自ノードが待機系か否かを判定する（ステップＢ５）。

自ノードの状態が待機系である場合（ステップＢ５のＹｅｓ）、クラスタ管理部３はフェイルオーバ処理を実行し、自ノードを現用系に遷移させる（ステップＢ６）。

一方、タイムアウト前にハートビートパケットを受信した場合（ステップＢ４のＹｅｓ）、または、自ノードの状態が待機系でない場合（ステップＢ５のＮｏ）、対向ノード監視部５は、受信したハートビートパケット内のシーケンス番号を読み出す。これにより、対向ノード監視部５は、シーケンス番号が飛んでいる（すなわち到達していないハートビートパケットがある）かどうかを確認する（ステップＢ７）。

シーケンス番号に飛びがある場合（ステップＢ７のＹｅｓ）、対向ノード監視部５の処理はステップＢ９へ進む。一方、シーケンス番号に飛びがない場合（ステップＢ７のＮｏ）、対向ノード監視部５の処理はステップＢ８へ進む。

対向ノード監視部５は、受信したハートビートパケットの到着時刻を確認する（ステップＢ８）。平均到着間隔からの遅延時間が予め設定した閾値以上である場合（ステップＢ８のＹｅｓ）、対向ノード監視部５の処理はステップＢ９へ進む。

対向ノード監視部５は、受信したハートビートパケット内の負荷状態情報（図３）を読み出し、対向ノードの負荷状態（例えばＣＰＵ使用率など）が予め設定した閾値以下であるかどうかを確認する（ステップＢ９）。対向ノードの負荷が閾値を超えている場合（ステップＢ９のＮｏ）、対向ノード監視部５は観測されたハートビートパケットの欠落（シーケンス番号飛び）またはハートビートパケットの到着遅延はネットワークに起因する現象ではなく、対向ノードの高負荷によるものと判断する。このとき、対向ノード監視部５はハートビートタイムアウト期間の再計算（変更）を行うことなく、ハートビート監視タイマ起動処理（ステップＢ２）に戻り、次のハートビートパケットを監視する。

一方、対向ノードの負荷が閾値以下である場合（ステップＢ９のＹｅｓ）、対向ノード監視部５は観測されたハートビートパケットの欠落（シーケンス番号飛び）またはハートビートパケットの到着遅延が対向ノードの高負荷によるものではなく、ネットワークの輻輳、不安定動作、障害などに起因するものと判断する。このとき、誤ったフェイルオーバを防止するため、対向ノード監視部５はハートビートタイムアウト期間を長くするように再計算を行う（ステップＢ１０）。

対向ノード監視部５は、例えば次の式（１）を用いてハートビートタイムアウト期間を計算する。

ハートビートタイムアウト期間（ｓ）
＝ハートビートタイムアウト期間のデフォルト値（ｓ）
＋｛α×連続したハートビートパケット欠落数（シーケンス番号飛びの数）｝
＋｛β×ハートビートパケット到着遅延時間（ｓ）｝ …（１）

ここで、αおよびβは予めシステムに設定されたパラメータである。

対向ノード監視部５はハートビートタイムアウト期間を再計算すると（ステップＢ１０）、ハートビート監視タイマ起動処理（ステップＢ２）に戻り、新しいハートビートタイムアウト期間を用いて次のハートビートパケットを監視する。

一方、受信したハートビートパケットの到着時刻を確認した結果、平均到着間隔からの遅延時間が予め設定した閾値よりも短い場合（ステップＢ８のＮｏ）、対向ノード監視部５はネットワークの状態が正常に戻ったものと判断する。このとき、対向ノード監視部５はハートビートタイムアウト期間を初期値（デフォルト値）で上書きして（ステップＢ１１）、ハートビート監視タイマ起動処理（ステップＢ２）に戻り、次のハートビートパケットを監視する。

［効果］
本実施形態のクラスタシステムでは、受信するハートビートパケットの欠落や遅延の傾向を監視し、これらが観測された場合、ネットワークが不安定状態にあるものとみなしてハートビートタイムアウト期間を長くする再計算を行う。かかる構成によると、ハートビート通信路ネットワークの不安定動作、輻輳、障害による誤ったフェイルオーバの発生（これによるスプリットブレインの発生）を防ぐことができる。

すなわち、本実施形態に係るクラスタシステムによると、２ノードで構成されるクラスタシステムにおいて、現用系ノードが正常に動作しているにも関わらずネットワークの不安定性あるいは障害によりハートビートの到達が途絶した場合に、待機系ノードが対向ノード障害と誤認識して現用系としての動作を開始してしまい、両ノードが現用系として動作してしまう現象（スプリットブレイン）が発生する確率を小さくすることができる。このとき、スプリットブレインによりサービスの提供に影響が及ぶという事態も回避することができる。

＜実施形態２＞
次に、第２の実施形態に係るクラスタシステムについて図面を参照して説明する。本実施形態のクラスタシステムは、ハートビートパケットの途絶（タイムアウト）が現用系と待機系の間の両方向であり、その後ハートビートパケットが両方向とも復旧した場合に生じる上述の第２の問題を解消することを目的とする。すなわち、本実施形態は、ハートビートパケットが両方向について途絶してスプリットブレインが生じた場合に、サービスへの影響を抑えつつクラスタシステムを正常な状態に復旧させることを目的とする。なお、本実施形態のようなスプリットブレインが生じるケースとして、例えば、待機系ノードにおいて現用系からのハートビートパケットが途絶してタイムアウトとなりフェイルオーバしたものの、実際にはネットワークの一時的な不通が原因であり、元現用系は現用系としての動作を継続している場合などが考えられる。

ハートビートパケットが途絶した状態から双方向のハートビートパケットの通信が復旧した際、スプリットブレインを解消するためには、いずれかのサーバ装置のサービスを停止して待機系に遷移させる必要がある。しかし、単純に一方のノードのサービスを停止させてしまうと、そのノードに接続してサービスを受けていたクライアント端末９や他ノード１０のトランザクションや呼が切断され、サービスに影響が出るおそれがある。

そこで、サービスへの影響を抑えつつ、クラスタシステムを正常な状態（現用系／待機系での動作）に遷移させることが好ましい。そこで、本実施形態では、スプリットブレインの状態においていずれも現用系動作をしている両サーバ装置２において、以下の処理を実行する。すなわち、双方向のハートビートパケットの通信が復旧した後、両サーバ装置２は、その時点で自ノードにて保持しているトランザクションやセッションの数に関する情報を、ハートビートパケットを用いてお互いに交換する。また、保持しているトランザクションやセッションの数が少ない方のサーバ装置２が、保持中のセッション情報を他方のサーバ装置２に同期した後、待機系に遷移する。以下、具体的な構成と動作について説明する。

［構成］
本実施形態のクラスタシステムの構成は、第１の実施形態におけるクラスタシステム１の構成（図２）と同様である。以下、本実施形態と第１の実施形態との差分を中心に説明する。

本実施形態では、クラスタ管理部３は、自サーバ装置が保持するセッション数と対向するサーバ装置が保持するセッション数とを比較して、自サーバ装置の動作を現用系のまま維持するか、または、待機系に遷移させるかを決定する。クラスタ管理部３は、例えば、自サーバ装置の保持するセッション数が対向するサーバ装置の保持するセッション数よりも多い場合、自サーバ装置の動作を現用系のまま維持し、それ以外の場合、自サーバ装置の動作を待機系に遷移させる。

図６は、本実施形態におけるハートビートパケットの構成を例示する図である。図６を参照すると、本実施形態のハートビートパケットは、第１の実施形態のハートビートパケット（図３）が保持する情報に加えて、さらに「保持セッション数情報」および「系状態遷移宣言フラグ（現用系／待機系）」を含む。「保持セッション数情報」は、自ノードが保持するセッション数を示す情報である。一方、「系状態遷移宣言フラグ（現用系／待機系）」は、自ノードが現用系／待機系に遷移することを相手ノードに通知するためのフラグである。

本実施形態では、ハートビート送受信部６は、自ノードが保持するセッション数を「保持セッション数情報」としてハートビートパケットに設定する。また、ハートビート送受信部６は、クラスタ管理部３が自ノードの状態を現用系／待機系に遷移させることを決定した場合、自ノードの遷移先の状態（現用系／待機系）を示す情報を「系状態遷移宣言フラグ（現用系／待機系）」としてハートビートパケットに設定する。

［動作］
図７は、本実施形態におけるクラスタシステム１の動作を例示するシーケンス図である。

図７を参照すると、サーバ装置２Ａ、２Ｂのいずれも現用系の動作を行うスプリットブレインが生じている（ステップＣ１１、Ｃ１２）。また、ハートビートネットワーク７の輻輳、不安定動作、障害などにより、両ノード間のハートビートパケットが双方向とも不通となっている（ステップＣ１３）。

ここで、ハートビートネットワーク７が復旧すると（ステップＣ２１）、両ノードとも、相手ノードからのハートビートパケットを受信する（ステップＣ２２、Ｃ２３）。受信したハートビートパケットは、図６に示すように、相手ノード（すなわち、そのハートビートパケットを送信した他ノード）が保持するセッション数に関する情報を含む。ハートビートパケットを受信すると、各ノードのクラスタ管理部３は、相手ノードの保持セッション数と自ノードの保持セッション数とを比較する（ステップＣ２４、Ｃ２５）。ここでは、サーバ装置２Ａ、２Ｂがそれぞれ保持するセッション数をｍ、ｎとする。

クラスタ管理部３は、自ノードのセッション数が相手ノードのセッション数よりも少ない場合、待機系に遷移することを決定する。このとき、ハートビート送受信部６はハートビートパケット内の「系状態遷移宣言フラグ」（図６）を用いて自ノードが待機系に遷移することを相手ノードに通知する（ステップＣ３２）。一方、クラスタ管理部３は、自ノードのセッション数が相手ノードのそれと比較して多い場合、現用系の動作を継続することを決定する。このとき、ハートビート送受信部６はハートビートパケット内の「系状態遷移宣言フラグ」（図６）を用いて自ノードが現用系を継続することを相手ノードに通知する（ステップＣ３３）。

サーバ装置２Ａは、自ノードを待機系に遷移させることを選択した場合、相手ノード（サーバ装置２Ｂ）から受信したハートビートパケットに含まれる「系状態遷移宣言フラグ」を確認する。相手ノード（サーバ装置２Ｂ）が現用系を継続することを「系状態遷移宣言フラグ」が示す場合、サーバ装置２Ａは、まず自ノードに入ってくる新規の呼要求の受け付けを停止する（ステップＣ４１）。また、自ノード内に保持する既存の呼のセッション状態に関するデータを、ハートビートネットワーク７を介して対向ノード（現用系の動作を継続するサーバ装置２Ｂ）に転送する（ステップＣ４２）。

ここで、セッション状態に関するデータとは、サーバ装置２が呼処理サーバ装置である場合には、呼処理を継続させるために必要なデータである。かかるデータは、例えば、発信元電話番号（またはユーザ名）、着信先電話番号（またはユーザ名）、セッションＩＤ（Identifier）、セッションタイマ値、課金情報などの組で表される。

セッション状態に関するデータの転送が完了し、対向ノード（すなわち現用系の動作を継続するサーバ装置２Ｂ）から同期完了の応答を受信すると（ステップＣ５１）、サーバ装置２Ａのクラスタ管理部３は自ノードを待機系へ遷移させる（ステップＣ５２）。

その後、サーバ装置２Ａ（すなわち待機系に遷移したノード）から送信されるハートビートパケット内のノード状態情報（図６）には「待機系」が設定される（ステップＣ６２）。これにより、サーバ装置２Ｂ（すなわち現用系の動作を継続するノード）は、対向ノードが待機系への遷移を完了したことを確認する。同様に、サーバ装置２Ｂ（すなわち現用系に遷移したノード）から送信されるハートビートパケット内のノード状態情報（図６）には「現用系」が設定される（ステップＣ６３）。これにより、サーバ装置２Ａ（すなわち待機系の動作を継続するノード）は、対向ノードが現用系の動作を行うことを把握する。

［効果］
本実施形態のクラスタシステムでは、スプリットブレインが発生した場合であっても、その後両ノード間の双方向の通信が復旧してデータの同期が可能なときには、待機系に遷移させる方のノード上の既存呼セッション状態情報をもう一方のノードに同期させる処理を実行し、状態を完全に引き継いだ上で、待機系への遷移動作を実行する。

すなわち、本実施形態では、両ノード間の既存の呼セッション状態情報の同期を行った上で、一方のノードを待機系に遷移させて、通常の現用系／待機系の動作状態を回復する。これにより、スプリットブレインが発生した場合であっても、サービスへの影響を抑えつつ、クラスタシステムを正常な現用系／待機系の動作状態に復旧させることができる。

また、本実施形態では、スプリットブレインを解消するために、一方のノードを待機系に遷移させる際、セッション数が相対的に多いノードの方を現用系のまま維持する。したがって、本実施形態によると、サービスへの影響を抑えつつ、クラスタシステムをスプリットブレインの状態から正常な状態に復旧させることができる。

＜実施形態３＞
次に、第３の実施形態に係るクラスタシステムについて図面を参照して説明する。本実施形態のクラスタシステムは、ハートビートパケットの途絶（タイムアウト）が現用系から待機系への一方向のみであり、逆方向はハートビートが到達している場合に生じる上述の第２の問題を解消することを目的とする。すなわち、本実施形態は、ハートビートパケットが現用系から待機系への一方向についてのみ途絶（タイムアウト）してスプリットブレインが生じた場合、サービスへの影響を抑えつつ、クラスタシステムを正常な状態に復旧させることを目的とする。

この場合、待機系は対向ノード（現用系）に障害が発生したと認識して、現用系としての動作を開始する。また、元現用系は元待機系が現用系としての動作を開始したことを、ハートビートパケットを介して知ることができる。通常、スプリットブレインの状態が発生したことを知った元現用系は、この状態を解消するため、現用系としての動作を停止して待機系に遷移する。しかし、これにより元現用系に接続していた他ノードや端末はそのトランザクションや呼が切断され、サービスに影響が出るおそれがある。そこで、本実施形態では、以下の構成および動作を採用することで、サービスへの影響を抑制する。

［構成］
本実施形態のクラスタシステムの構成は、第１および第２の実施形態におけるクラスタシステム１の構成（図２）と同様である。また、本実施形態におけるハートビートパケットの構成は、第２の実施形態におけるハートビートパケットの構成（図６）と同様である。以下、本実施形態と第２の実施形態との差分を中心に説明する。

本実施形態では、クラスタ管理部３は、対向するサーバ装置の保持するセッション数が自サーバ装置の保持するセッション数よりも多い場合、または、対向するサーバ装置が現用系の動作を開始したことを把握してから所定の期間が経過した場合、自サーバ装置の動作を待機系に遷移させる。一方、クラスタ管理部３は、それ以外の場合、自サーバ装置の動作を現用系のまま維持する。

［動作］
図８は、本実施形態に係るクラスタシステム１の動作を例示するシーケン図である。

図８を参照すると、サーバ装置２Ａが待機系の動作を行い（ステップＤ１１）、一方サーバ装置２Ｂが現用系の動作を行う（ステップＤ１２）。このとき、クラスタシステム１は正常に稼働している。ここで、ハートビートネットワーク７の輻輳、不安定動作、障害などにより、サーバ装置２Ｂ（現用系）からサーバ装置２Ａ（待機系）へのハートビートパケットのみが不通となる（ステップＤ１３〜Ｄ１５）。

サーバ装置２Ａ（待機系）の対向ノード監視部５において、ハートビート監視タイマがタイムアウトする（ステップＤ２）。

サーバ装置２Ａ（待機系）のクラスタ管理部３はフェイルオーバ処理を実行し、自ノードを現用系に遷移させる（ステップＤ３）。このとき、サーバ装置２Ａ、２Ｂのいずれも現用系の動作を行うスプリットブレインが発生する。

サーバ装置２Ａ（元待機系）のハートビート送受信部６は、ハートビートパケット（図６）内のノード状態情報を「現用系」に設定してサーバ装置２Ｂ（元現用系）へ送信する（ステップＤ４２）。

サーバ装置２Ａ（元待機系）からサーバ装置２Ｂ（元現用系）へのハートビートパケットは疎通している（ステップＤ４１）。したがって、サーバ装置２Ｂ（元現用系）はサーバ装置２Ａ（元待機系）が現用系としての動作を開始したこと（すなわち、スプリットブレインが発生したこと）を検知する（ステップＤ５１）。なお、サーバ装置２Ｂ（元現用系）からサーバ装置２Ａ（元待機系）へのハートビートパケットは不通のままである（ステップＤ５２）。

ここで、サーバ装置２Ｂ（元現用系）は、直ちに現用系としての動作を停止して待機系に遷移する代わりに、所定の条件を満たすまで現用系としての動作を継続する（ステップＤ６）。また、所定の条件を満たした場合、サーバ装置２Ｂ（元現用系）は待機系へ遷移する（ステップＤ６３）。

ここで、所定の条件として、例えば以下の条件を用いることができる。すなわち、サーバ装置２Ｂのクラスタ管理部３は、以下の（ａ）、（ｂ）のいずれか一方または双方を満たした場合、自ノードを待機系に遷移させてもよい（ステップＤ６３）。

（ａ）サーバ装置２Ｂ（元現用系）のクラスタ管理部３は、自ノードが保持するセッションの数よりも、対向ノード（サーバ装置２Ａ、元待機系）が保持するセッション数の方が多くなった場合（ステップＤ６１のＹｅｓ）、自ノードを待機系に遷移させる（ステップＤ６３）。具体的には、サーバ装置２Ｂ（元現用系）は、以下の手順を実施する。

サーバ装置２Ｂのクラスタ管理部３は、対向ノード（サーバ装置２Ａ、元待機系）から受信したハートビートパケットに含まれる、対向ノード（サーバ装置２Ａ、元待機系）が保持するセッションの数（ｍ）を、自ノードが保持するセッション数（ｎ）と比較する（ステップＤ６１）。

自ノードによって保持されるセッション数（ｎ）が相手ノードによって保持されるセッション数（ｍ）よりも少ない（ｎ＜ｍ）場合（ステップＤ６１のＹｅｓ）、クラスタ管理部３は自ノードを待機系へ遷移させる（ステップＤ６３）。

（ｂ）また、対向するサーバ装置２Ａ（元待機系）が現用系としての動作を開始したことを、ハートビートパケットを用いて把握してから（ステップＤ５１）所定の待機時間が経過した場合（ステップＤ６２のＹｅｓ）、サーバ装置２Ｂのクラスタ管理部３は自ノードを待機系に遷移させる（ステップＤ６３）。

ここで、所定の待機時間は、例えば以下の方法で指定することができる。
・固定値（システムの設定値などとして指定）
・ハートビートパケット受信の統計情報から動的に設定

ネットワークが不安定である状態においては、比較的長い期間に亘ってハートビートパケットが不通となった後、ハートビートパケットの通知が復旧する傾向がある。したがって、サーバ装置２Ｂ（元現用系）が受信しているハートビートパケットの欠落数や到着の遅延時間の大きさに係数を乗じることにより、所定の待機時間を求めることができる。一例として、所定の待機時間は、以下の式（２）を用いて計算することができる。

待機時間（ｓ）
＝α２
＋｛β２×連続したハートビートパケット欠落数（シーケンス番号飛びの数）｝
＋｛γ２×ハートビートパケット到着遅延時間（ｓ）｝ …（２）

ここで、α２、β２およびγ２は予めシステムに設定されたパラメータである。

一方、ステップＤ６に記載した条件を満たす（ステップＤ６１のＹｅｓまたはステップＤ６２のＹｅｓにより元現用系が待機系に遷移する）前に、サーバ装置２Ｂ（元現用系）からサーバ装置２Ａ（元待機系）へのハートビート疎通が復旧した場合（ステップＤ７１）、図７のステップＣ３１以降と同様の動作を実行する。すなわち、両ノードはその時点で自ノードが保持しているセッションの数に関する情報を、ハートビートパケットを用いて交換する（ステップＤ７２）。保持するセッション数が少ない方のノードは、保持している既存の呼セッション状態情報を他方のノードに送信し（図７のステップＣ４２参照）、セッション状態情報の同期完了応答を受信した後（図７のステップＣ５１参照）、待機系に遷移する（図７のステップＣ５２参照）。

［効果］
本実施形態のクラスタシステムでは、現用系から待機系へのハートビートパケットのみが不通となったことに起因してスプリットブレインが生じた場合に、ハートビート通信が復旧せず、データの同期が実行できないときに、次のように動作する。すなわち、この場合、スプリットブレイン発生を検知した方のノード（元現用系ノード）は直ちに待機系への遷移動作を実行する代わりに、上述の所定の条件が満たされるのを待ってから待機系へ遷移する。これにより、スプリットブレインが発生した場合であっても、サービスへの影響を抑えつつ、クラスタシステムを正常な現用系／待機系の動作状態に復旧させることができる。

＜変形例＞
上記実施形態に係るクラスタシステムに対して、様々な変形が可能である。一例として、ハートビートパケットを、ハートビート専用のハートビートネットワーク７の代わりに、呼処理ネットワーク８を経由してやり取りしてもよい。

また、上記実施形態のように、同一サイト内に両サーバ装置２が配置される構成の代わりに、クラスタシステム内の２つのサーバ装置を別個のサイトに配置する地理的冗長構成の場合にも、本発明を適用することができる。

さらに、上記第３の実施形態では、ハートビートパケットを参照することで元待機系のサーバ装置２Ａが現用系の動作を開始したことを把握した元現用系のサーバ装置２Ｂは、所定の条件を満たすまで現用系の動作を継続する（図８）。一方、元現用系のサーバ装置２Ｂは、現用系の動作を継続する代わりに、自ノード内の呼やトランザクションの情報を保持しつつ処理の実行が停止したサスペンド状態に遷移してもよい。

また、サスペンド状態に遷移した後、所定の条件を満たした場合に、元現用系のサーバ装置２Ｂは待機系への遷移動作を実行してもよい。ここで、例えば元現用系のサーバ装置２Ｂが待機系に遷移する前に元現用系のサーバ装置２Ｂから元待機系のサーバ装置２Ａへのハートビート疎通が復旧したとする。この場合、両ノードは復旧時点で自ノードが保持しているセッションの数に関する情報を、ハートビートパケットを用いて交換する。さらに、セッション数が相対的に少ない方のサーバ装置２は、既存の呼セッション状態情報を対向ノードに同期させた後、待機系に遷移する。その後、第３の実施形態と同様の動作を行うようにしてもよい。

さらに、元待機系のサーバ装置２Ａが再度待機系に遷移し、一方元現用系のサーバ装置２Ｂが現用系としての動作を継続することになった場合、次のようにしてもよい。すなわち、元現用系のサーバ装置２Ｂは、サスペンド状態として保持していた呼やセッションの情報を用いてサスペンド状態から通常の動作状態に遷移して、サービス処理を継続するようにしてもよい。

なお、本発明において、下記の形態が可能である。
［形態１］
上記第１の態様に係るサーバ装置（第１のサーバ装置）のとおりである。
［形態２］
前記対向ノード監視部は、前記ハートビートパケットが欠落した場合、または、前記ハートビートパケットを受信するまでの遅延時間が所定の閾値以上である場合、前記タイムアウト期間を延長する、形態１に記載の第１のサーバ装置。
［形態３］
前記対向ノード監視部は、前記対向するサーバ装置の負荷が所定の閾値以下である場合、前記タイムアウト期間を延長する、形態２に記載の第１のサーバ装置。
［形態４］
自サーバ装置が保持するセッション数と前記対向する第２のサーバ装置が保持するセッション数とを比較して、自サーバ装置の動作を現用系のまま維持するか、または、待機系に遷移させるかを決定するクラスタ管理部を備える、形態１ないし３のいずれか一に記載の第１のサーバ装置。
［形態５］
前記クラスタ管理部は、前記第１のサーバ装置の保持するセッション数が前記対向する第２のサーバ装置の保持するセッション数よりも多い場合、前記第１のサーバ装置の動作を現用系のまま維持する、形態４に記載の第１のサーバ装置。
［形態６−１］
前記クラスタ管理部は、前記対向する第２のサーバ装置の保持するセッション数が自サーバ装置の保持するセッション数よりも多い場合、自サーバ装置の動作を待機系に遷移させ、それ以外の場合、前記第１のサーバ装置の動作を現用系のまま維持する、形態４に記載の第１のサーバ装置。
［形態６−２］
前記クラスタ管理部は、前記対向する第２のサーバ装置が現用系の動作を開始したことを把握してから所定の期間が経過した場合、前記第１のサーバ装置の動作を待機系に遷移させ、それ以外の場合、前記第１のサーバ装置の動作を現用系のまま維持する、形態４に記載の第１のサーバ装置。
［形態７］
前記ハートビート送受信部は、前記ハートビートパケットを送信するごとに更新されるシーケンス番号を、前記ハートビートパケットに含めて前記対向する第２のサーバ装置に送信する、形態１ないし６のいずれか一に記載の第１のサーバ装置。
［形態８］
前記ハートビート送受信部は、前記第１のサーバ装置の負荷を示す情報を前記ハートビートパケットに含めて前記対向する第２のサーバ装置に送信する、形態１ないし７のいずれか一に記載の第１のサーバ装置。
［形態９］
前記ハートビート送受信部は、前記第１のサーバ装置が保持するセッション数を示す情報を、前記ハートビートパケットに含めて前記対向する第２のサーバ装置に送信する、形態１ないし８のいずれか一に記載の第１のサーバ装置。
［形態１０］
形態１ないし９のいずれか一に記載の第１のサーバ装置を、現用系または待機系として動作する２台のサーバ装置の一方として備える、クラスタシステム。
［形態１１］
上記第３の態様に係るクラスタ制御方法のとおりである。
［形態１２］
前記ハートビートパケットが欠落した場合、または、前記ハートビートパケットを受信するまでの遅延時間が所定の閾値以上である場合、前記タイムアウト期間を延長する、形態１１に記載のクラスタ制御方法。
［形態１３］
前記対向する第２のサーバ装置の負荷が所定の閾値以下である場合、前記タイムアウト期間を延長する、形態１２に記載のクラスタ制御方法。
［形態１４］
前記第１のサーバ装置が保持するセッション数と前記対向する第２のサーバ装置が保持するセッション数とを比較して、前記第１のサーバ装置の動作を現用系のまま維持するか、または、待機系に遷移させるかを決定するステップを含む、形態１１ないし１３のいずれか一に記載のクラスタ制御方法。
［形態１５］
前記第１のサーバ装置の保持するセッション数が前記対向する第２のサーバ装置の保持するセッション数よりも多い場合、前記第１のサーバ装置の動作を現用系のまま維持する、形態１４に記載のクラスタ制御方法。
［形態１６−１］
前記対向する第２のサーバ装置の保持するセッション数が前記第１のサーバ装置の保持するセッション数よりも多い場合、前記第１のサーバ装置の動作を待機系に遷移させ、それ以外の場合、前記第１のサーバ装置の動作を現用系のまま維持する、形態１４に記載のクラスタ制御方法。
［形態１６−２］
前記対向する第２のサーバ装置が現用系の動作を開始したことを把握してから所定の期間が経過した場合、前記第１のサーバ装置の動作を待機系に遷移させ、それ以外の場合、前記第１のサーバ装置の動作を現用系のまま維持する、形態１４に記載のクラスタ制御方法。
［形態１７］
上記第４の態様に係るプログラムのとおりである。
［形態１８］
前記ハートビートパケットが欠落した場合、または、前記ハートビートパケットを受信するまでの遅延時間が所定の閾値以上である場合、前記タイムアウト期間を延長する、形態１７に記載のプログラム。
［形態１９］
前記対向する第２のサーバ装置の負荷が所定の閾値以下である場合、前記タイムアウト期間を延長する、形態１８に記載のプログラム。
［形態２０］
前記第１のサーバ装置が保持するセッション数と前記対向する第２のサーバ装置が保持するセッション数とを比較して、前記第１のサーバ装置の動作を現用系のまま維持するか、または、待機系に遷移させるかを決定する処理を、前記コンピュータに実行させる、形態１７ないし１９のいずれか一に記載のプログラム。
［形態２１］
前記第１のサーバ装置の保持するセッション数が前記対向する第２のサーバ装置の保持するセッション数よりも多い場合、前記第１のサーバ装置の動作を現用系のまま維持する、形態２０に記載のプログラム。
［形態２２−１］
前記対向する第２のサーバ装置の保持するセッション数が前記第１のサーバ装置の保持するセッション数よりも多い場合、前記第１のサーバ装置の動作を待機系に遷移させ、それ以外の場合、前記第１のサーバ装置の動作を現用系のまま維持する、形態２０に記載のプログラム。
［形態２２−２］
前記対向する第２のサーバ装置が現用系の動作を開始したことを把握してから所定の期間が経過した場合、前記第１のサーバ装置の動作を待機系に遷移させ、それ以外の場合、前記第１のサーバ装置の動作を現用系のまま維持する、形態２０に記載のプログラム。

なお、上記特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態の各要素、各図面の各要素などを含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１ クラスタシステム
２、２Ａ、２Ｂ サーバ装置
３ クラスタ管理部
４ 負荷監視部
５ 対向ノード監視部
６ ハートビート送受信部
７ ハートビートネットワーク
８ 呼処理ネットワーク
９ クライアント端末
１０ 他ノード

Claims (8)

1. 現用系または待機系として動作する２台のサーバ装置を備えたクラスタシステムにおける第１のサーバ装置であって、
   対向する第２のサーバ装置との間でハートビートパケットを送受信するハートビート送受信部と、
   前記ハートビートパケットの受信状況に応じて、前記第１のサーバ装置の動作を待機系から現用系に遷移するためのタイムアウト期間を調整する対向ノード監視部と、を備え、
   前記対向ノード監視部は、前記ハートビートパケットが欠落した場合、または、前記ハートビートパケットを受信するまでの遅延時間が所定の閾値以上であり、かつ、
   前記対向する第２のサーバ装置の負荷が所定の閾値以下である場合、前記タイムアウト期間を延長する、
   ことを特徴とする第１のサーバ装置。
2. 前記第１のサーバ装置が保持するセッション数と前記対向する第２のサーバ装置が保持するセッション数とを比較して、前記第１のサーバ装置の動作を現用系のまま維持するか、または、待機系に遷移させるかを決定するクラスタ管理部を備える、
   請求項１に記載の第１のサーバ装置。
3. 前記クラスタ管理部は、前記第１のサーバ装置の保持するセッション数が前記対向する第２のサーバ装置の保持するセッション数よりも多い場合、前記第１のサーバ装置の動作を現用系のまま維持する、
   請求項２に記載のサーバ装置。
4. 前記クラスタ管理部は、前記対向する第２のサーバ装置の保持するセッション数が前記第１のサーバ装置の保持するセッション数よりも多い場合、または、前記対向する第２のサーバ装置が現用系の動作を開始したことを把握してから所定の期間が経過した場合、前記第１のサーバ装置の動作を待機系に遷移させ、それ以外の場合、前記第１のサーバ装置の動作を現用系のまま維持する、
   請求項２に記載のサーバ装置。
5. 前記ハートビート送受信部は、前記ハートビートパケットを送信するごとに更新されるシーケンス番号を、前記ハートビートパケットに含めて前記対向する第２のサーバ装置に送信する、
   請求項１ないし４のいずれか１項に記載の第１のサーバ装置。
6. 請求項１ないし５のいずれか１項に記載の第１のサーバ装置を、現用系または待機系として動作する２台のサーバ装置の一方として備える、
   ことを特徴とするクラスタシステム。
7. 現用系または待機系として動作する２台のサーバ装置を備えたクラスタシステムにおける第１のサーバ装置が、
   対向する第２のサーバ装置との間でハートビートパケットを送受信するステップと、
   前記ハートビートパケットの受信状況に応じて、前記第１のサーバ装置の動作を待機系から現用系に遷移するためのタイムアウト期間を調整するステップと、を含み、
   前記タイムアウト期間を調整するステップにおいて、前記ハートビートパケットが欠落した場合、または、前記ハートビートパケットを受信するまでの遅延時間が所定の閾値以上であり、かつ、
   前記対向する第２のサーバ装置の負荷が所定の閾値以下である場合、前記タイムアウト期間を延長する、
   ことを特徴とするクラスタ制御方法。
8. 現用系または待機系として動作する２台のサーバ装置を備えたクラスタシステムにおける第１のサーバ装置に設けられたコンピュータに対して、
   対向する第２のサーバ装置との間でハートビートパケットを送受信する処理と、
   前記ハートビートパケットの受信状況に応じて、前記第１のサーバ装置の動作を待機系から現用系に遷移するためのタイムアウト期間を調整する処理と、を実行させ、
   前記タイムアウト期間を調整する処理において、前記ハートビートパケットが欠落した場合、または、前記ハートビートパケットを受信するまでの遅延時間が所定の閾値以上であり、かつ、
   前記対向する第２のサーバ装置の負荷が所定の閾値以下である場合、前記タイムアウト期間を延長する、
   ことを特徴とするプログラム。

Images