JP5016696B2 - 高可用性システム、サーバ、高可用性維持方法及びプログラム - Google Patents

Description

本発明は、複数のサーバ群によって高可用性を維持する高可用性システム、サーバ、高可用性維持方法及びプログラムに関する。

オンラインショップ等の商用のサービスを提供するシステムにおいては、顧客にサービスを提供しているサーバが故障した場合でも、顧客へのサービスの提供を継続することが求められる。つまり、システムとして継続して稼働できることが重要である。

システムが継続して稼働できることを示す指標として可用性がある。可用性は、所定の期間中、何パーセントの時間にシステムが稼働できていたかを示す。従って、商用のサービスを提供するシステムにおいては、高可用性を維持する必要がある。

高可用性を維持するための手法としては、予め予備用のサーバを準備しておき、サービスを提供しているサーバが故障した場合、サービスの提供を予備用のサーバに切り替える方式が一般的である。但し、顧客からの要求を処理することにより、サービスを提供しているサーバに記憶された顧客データ等のデータが変化するシステムの場合、予備用のサーバは、サービスを提供しているサーバと同じ状態を維持している必要がある。以降、単にデータという場合には、顧客からの要求を処理することによって変化する顧客データ等のことを指す。

これを実現する技術としては例えば、レプリケーション技術がある。レプリケーション技術は一般的に、複数のサーバでデータを共有するための記憶装置が存在しない場合に利用される。

レプリケーション技術では、サービスを提供しているサーバに記憶されたデータを複数の予備用のサーバに複製しておく。そして、サービスを提供しているサーバが故障したら、サービスの提供を予備用のサーバに瞬時に切り替える。これにより、サービスの提供を継続することができる。

図１１は、レプリケーション技術を利用したサーバの構成の一例を示す図である。図１１においては、サーバ（Ｍ１）がサービスを提供しているサーバである。

レプリケーション技術を利用した場合、サーバ（Ｍ１）に記憶されたデータが変更されると、サーバ（Ｍ１）はサーバ（Ｒ１）〜（Ｒ３）にその変更内容を通知する。

サーバ（Ｍ１）からの通知を受けたサーバ（Ｒ１）〜（Ｒ３）は、それぞれが備える記憶装置に、その変更内容を反映させる。これにより、サーバ（Ｒ１）〜（Ｒ３）は常に、サーバ（Ｍ１）と同じ状態を維持することができる。

レプリケーション技術において、高可用性を維持するための重要な仕組みは、サービスを提供しているサーバ（Ｍ１）が故障した場合に、その故障を検知し、サービスを提供するサーバをサーバ（Ｒ１）〜（Ｒ３）の中から新たに選定する仕組みである。

サーバ（Ｍ１）の故障の検知は、サーバ（Ｍ１）がハートビートと呼ばれる信号を所定の時間間隔でサーバ（Ｒ１）〜（Ｒ３）へ送信し、サーバ（Ｒ１）〜（Ｒ３）が予め決められた時間間隔内にハートビートを受信できたかどうかによって判断することができる。

サーバ（Ｒ１）〜（Ｒ３）は、予め決められた時間間隔内にサーバ（Ｍ１）から送信されたハートビートを受信しなければ、サーバ（Ｍ１）が故障したとみなす。この場合、サーバ（Ｒ１）〜（Ｒ３）の中から、サービスを提供する新たなサーバが選定される。以降、サービスを提供する新たなサーバのことをサーバ（Ｍ２）という。

サーバ（Ｍ２）を選定するための選定方法は例えば、サーバ（Ｒ１）〜サーバ（Ｒ３）の優先順位を予め決めておき、優先順位の高いサーバから順番に、サーバ（Ｍ２）になるようにしておけばよい。

しかし、この選定方法を利用した場合、サーバ（Ｍ１）とサーバ（Ｒ１）〜（Ｒ３）とがネットワークで接続されていると、Ｓｐｌｉｔ−ｂｒａｉｎ問題が発生する可能性がある。以下に、Ｓｐｌｉｔ−ｂｒａｉｎ問題について説明する。

サーバ（Ｍ１）とサーバ（Ｒ１）〜（Ｒ３）とを接続するネットワークに障害が発生した場合、サーバ（Ｍ１）が故障していないにも関わらず、サーバ（Ｍ１）から送信されたハートビートが、予め決められた時間間隔内にサーバ（Ｒ１）〜（Ｒ３）にて受信されない場合がある。ここでは一例として、ネットワークの障害により、サーバ（Ｍ１）とサーバ（Ｒ１）との間、及び、サーバ（Ｒ２）とサーバ（Ｒ３）との間のみでしか通信を行うことができないと仮定する。

この場合、サーバ（Ｒ２）及びサーバ（Ｒ３）は、サーバＭ１から送信されたハートビートを予め決められた時間間隔内に受信しない。そのため、サーバ（Ｒ２）及びサーバ（Ｒ３）は、サーバ（Ｍ１）が故障したとみなす。また、サーバ（Ｒ２）及びサーバ（Ｒ３）は、サーバ（Ｒ１）と通信を行うこともできない。従って、サーバ（Ｒ２）及びサーバ（Ｒ３）の中からサーバ（Ｍ２）が選定される。

しかし、実際には、サーバ（Ｍ１）は故障していないため、サービスを提供しているサーバは、サーバ（Ｍ１）とサーバ（Ｍ２）との２つになってしまう。

図１２は、図１１に示した構成において、サービスを提供するサーバが新たに選定された場合の一例を説明するための図である。図１２では、図１１におけるサーバ（Ｒ２）がサーバ（Ｍ２）に選定された場合を示している。

図１２に示す例の場合、顧客からの要求は、サーバ（Ｍ１）またはサーバ（Ｍ２）のいずれかによって処理される。例えば、提供されるサービスが顧客の貯金を管理するサービスであった場合、クライアント端末（Ｃ１）が５００円を貯金する処理を要求すると、この処理を受け付けたサーバ（Ｍ１）においては５００円が貯金される。しかし、この処理を受け付けていないサーバ（Ｍ２）においては５００円が貯金されてないこととなる。つまり、システムとしてデータの整合性がとれていない状態となる。これが、Ｓｐｌｉｔ−ｂｒａｉｎ問題である。

このようなＳｐｌｉｔ−ｂｒａｉｎ問題を解決するために、相互に通信を行うことが可能なサーバの数が全サーバ数の過半数以上を占めるサーバグループだけがサービスを提供できるようにする方式がある。以降、この方式により、サービスを提供するサーバを選定するアルゴリズムのことを過半数アルゴリズムという、なお、過半数アルゴリズムの１つであるＰＡＸＯＳアルゴリズムが例えば、非特許文献１に開示されている。

この方式では、サービスを提供しているサーバから送信されたハートビートが予め決められた時間間隔内に受信されない場合、他のサーバ間で通信を行うことにより、サーバグループを形成する。そして、相互に通信を行うことが可能なサーバ数が全サーバ数の過半数以上を占めるサーバグループの中から、サービスを提供する新たなサーバが選定される。
このような高可用性システムが例えば、非特許文献２に開示されている。

図１３は、過半数アルゴリズムによってサービスを提供するサーバが選定される構成の一例を説明するための図である。

図１３に示すように、相互に通信を行うことが可能なサーバ数が全サーバ数の過半数以上を占めるサーバグループは１つしか存在しない。従って、上述したＳｐｌｉｔ−ｂｒａｉｎ問題を回避することができる。

ここで、レプリケーション技術を用いた場合、データを複製するサーバの数が多ければ多いほど、高可用性を維持することができる。しかし、この場合、データの複製にかかるコストによって性能が低下してしまう場合がある。

つまり、高可用性を維持する場合、性能とのバランスが重要になる。一般的には、相互に高速な通信が可能な複数のサーバを用いることによって性能の低下を回避するようにしている。しかし、相互に高速な通信が可能なサーバ数は限られており、例えばサーバが故障している間は可用性の低下が回避できない。

また、相互に高速な通信が可能な複数のサーバは、同じネットワーク装置に接続されていることが多い。そのため、これら複数のサーバには、ネットワーク障害の影響が同時に及ぶ確率が高い。

一方、物理的に離れた場所に設置されている複数のサーバ間の通信速度は、同じネットワーク装置に接続された複数のサーバ間の通信速度に比べて遅くなる。そのため、物理的に離れた場所に設置されている複数のサーバを用いた場合、性能の低下を回避することが難しくなる。

これを解決するための方法として、相互に高速な通信が可能な複数のサーバからなるサーバ群を複数準備しておく方法が検討されている。

図１４は、複数のサーバ群を有する高可用性システムの構成の一例を説明するための図である。

図１４に示す例では通常、複数のサーバ群のいずれかに属する複数のサーバのいずれかによってサービスを提供する。１つのサーバ群に属する複数のサーバ間の通信速度は、例えば１Ｇｂｐｓ（Ｇｉｇａ ｂｉｔ ｐｅｒ ｓｅｃｏｎｄ）のように高速であり、性能の低下を回避しつつ、高可用性を維持できる。そして、そのサーバ群によってサービスの提供ができない場合にのみ、他のサーバ群のいずれかがサービスの提供を継続する。例えば、図１４においてサービスを提供しているサーバ群がサーバ群Ａであった場合、サーバ群Ａによってサービスの提供ができなくなると、サーバ群Ｂがサービスの提供を継続する。

Paxos Made Simple, Leslie Lamport. Appears in ACM SIGACT News (Distributed Computing Column), Vol. 32, No. 4 (December 2001), pages 51-58. "The Chubby lock service for loosely-coupled distributed systems", Mike Burrows, GAppears in Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI), November, 2006.

図１３を参照して説明したような過半数アルゴリズムと、図１４を参照して説明した高可用性システムとを組み合わせれば、データの整合性を確保しつつ、高可用性を維持することが可能なようにも思える。

図１５は、過半数アルゴリズムと高可用性システムとを組み合わせた場合の一例を説明するための図である。

図１５においては、サーバ群Ａには、サーバ群Ａに属するサーバ数の過半数以上のサーバからなるサーバグループが存在する。この場合、ＰＡＸＯＳアルゴリズム等の過半数アルゴリズムでは、そのサーバグループは、サービスの提供をサーバ群Ｂに属する唯一のサービス提供サーバに移動させずに、自サーバグループ内でサービスを提供する唯一のサービス提供サーバを選定する。一方、サーバ群Ａに属するサーバ数の過半数未満のサーバからなるサーバグループは、自サーバグループでサービスの提供が行える唯一のサービスサーバを選定できない。そのため、このサーバグループは、サービスの提供をサーバ群Ｂのサービス提供サーバに移動させてしまう。この場合、サービスを提供するサーバが２つ存在することになってしまい、上述したＳｐｌｉｔ−ｂｒａｉｎ問題が発生する。つまり、データの整合性を確保できなくなってしまうという問題点がある。

図１６は、過半数アルゴリズムと高可用性システムとを組み合わせた場合の他の例を説明するための図である。

図１６においては、サーバ群Ａには、サーバ群Ａに属するサーバ数の過半数以上のサーバからなるサーバグループが存在しない。この場合、ＰＡＸＯＳアルゴリズム等の過半数アルゴリズムでは、サーバ群Ａのいずれのサーバグループも、サービス提供サーバを選定できないため、サービスを提供することができない。また、この状態ではアルゴリズム上、Ｓｐｌｉｔ−ｂｒａｉｎ問題を回避するために、サーバ群Ａのいずれのサーバグループも、サーバ群Ｂに対してサービス提供を依頼できない。つまり、サービスを提供するサーバが存在しなくなり、高可用性が維持できなくなってしまうという問題点がある。

本発明は、データの整合性を確保しつつ、高可用性を維持することを可能にする高可用性システム、サーバ、高可用性維持方法及びプログラムを提供することを目的とする。

上記目的を達成するために本発明の高可用性システムは、相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムであって、
前記複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第１のサーバグループを形成し、
前記第１のサーバグループのサーバは、当該第１のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定し、
前記複数のサーバ群毎に選定された複数の代表サーバは、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する。

また、上記目的を達成するために本発明のサーバは、相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバであって、
前記所定のサービスを提供するサービス提供部と、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第１のサーバグループを形成し、該第１のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループの他のサーバと通信を行うことにより、当該第１のサーバグループの中から、当該サーバ群を代表する代表サーバを選定し、自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定し、自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供の開始を許可する許可情報を出力する高可用部と、を有し、
前記サービス提供部は、前記高可用部から出力された許可情報を受け付けると、前記所定のサービスの提供を開始する。

また、上記目的を達成するために本発明の高可用性維持方法は、相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムにおける高可用性維持方法であって、
前記複数のサーバ群のそれぞれに属する複数のサーバが、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第１のサーバグループを形成する処理と、
前記第１のサーバグループのサーバが、当該第１のサーバグループのサーバ数が当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定する処理と、
前記複数のサーバ群毎に選定された複数の代表サーバが、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する処理と、を有する。

また、上記目的を達成するために本発明のプログラムは、相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバに、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第１のサーバグループを形成する機能と、
前記第１のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループの他のサーバと通信を行うことにより、当該第１のサーバグループの中から、当該サーバ群を代表する代表サーバを選定する機能と、
自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する機能と、
自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供を開始する機能と、を実現させる。

本発明によれば、複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第１のサーバグループを形成する。そして、第１のサーバグループのサーバは、当該第１のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定する。そして、複数のサーバ群毎に選定された複数の代表サーバは、その複数の代表サーバの中から、所定のサービスを提供する大代表サーバを選定する。

これにより、所定のサービスを提供するサーバが複数存在すること、及び、所定のサービスを提供するサーバが存在しなくなるのを回避することができる。

従って、データの整合性を確保しつつ、高可用性を維持することが可能となる。

本発明の高可用性システムの実施の一形態の構成を示すブロック図である。 図１に示したサーバの構成の一例を示すブロック図である。 図２に示した調停部の動作を説明するための図である。 図２に示したメンバ管理部が記憶するサーバ情報及び代表サーバ情報を説明するための図である。 図２に示したメンバ管理部が代表サーバ情報を追加及び削除する動作を説明するためのフローチャートである。 図１〜図５に示した高可用性システムにおいて、大代表サーバが選定されるまでの動作を説明するためのフローチャートである。 レベルＮの非代表サーバの動作を説明するための図である。 大代表サーバの動作を説明するための図である。 大代表サーバが選定された後の代表サーバの動作を説明するためのフローチャートである。 大代表サーバが選定された後の非代表サーバの動作を説明するためのフローチャートである。 レプリケーション技術を利用したサーバの構成の一例を示す図である。 図１１に示した構成において、サービスを提供するサーバが新たに選定された場合の一例を説明するための図である。 過半数アルゴリズムによってサービスを提供するサーバが選定される構成の一例を説明するための図である。 複数のサーバ群を有する高可用性システムの構成の一例を説明するための図である。 過半数アルゴリズムと高可用性システムとを組み合わせた場合の一例を説明するための図である。 過半数アルゴリズムと高可用性システムとを組み合わせた場合の他の例を説明するための図である。

以下に、本発明の実施の形態について図面を参照して説明する。

図１は、本発明の高可用性システムの実施の一形態の構成を示すブロック図である。

本実施形態の高可用性システムは図１に示すように、３つのサーバ１０が属するサーバ群１〜６を備えている。なお、サーバ群１〜６は、階層化された構成にすることも可能である。例えば、サーバ群１〜６を１つのサーバ群とした巨大なサーバ群同士がネットワークで接続され、相互にデータの送受信ができる構成もありえる。この場合、サーバ群の階層数に制限はない。また、サーバ群の数は６つに限定されない。また、サーバ群１〜６に属するサーバの数は３つに限定されない。

また、複数のサーバ１０間でデータを送受信する際の通信速度は、スイッチやルータの配置のようなネットワークの構成や物理的距離によって異なる。ここでは、所定の通信速度以上の通信速度で相互に通信を行える３つのサーバ１０が１つのサーバ群に属している。

サーバ１０は、本実施形態の高可用性システムと接続されたクライアント端末等に所定のサービスを提供する。サーバ１０は例えば、メインフレームやパーソナルコンピュータ、携帯電話等である。また、サーバ１０は、ネットワーク構成装置（不図示）等を用いたローカルネットワーク５０に接続され、自サーバと同じサーバ群に属する他のサーバ１０と相互に通信を行うことによってデータを送受信する。ローカルネットワーク５０は、ネットワーク構成装置（不図示）等を用いたグローバルネットワーク１５０と接続されている。サーバ１０は、ローカルネットワーク５０及びグローバルネットワーク１５０を介し、自サーバと異なるサーバ群に属する他のサーバ１０と相互に通信を行うことによってデータを送受信する。

なお、ローカルネットワーク５０及びグローバルネットワーク１５０の通信媒体や通信規格は、複数のサーバ１０の間で相互に通信を行うことが可能であれば、どのようなものでもよい。例えば、インターネットやＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、無線ネットワーク等が挙げられる。

本実施形態の高可用性システムでは、サーバ群１〜６のそれぞれにおいて、相互に通信することが可能なサーバ１０からなるサーバグループを形成する。そして、そのサーバグループのサーバ数がそのサーバ群に属するサーバ数の過半数以上である場合、そのサーバグループの中から、そのサーバ群を代表する代表サーバが選定される。これは例えば、ＰＡＸＯＳアルゴリズムを用いることによって実現できる。そして、サーバ群１〜６毎に選定された複数の代表サーバの中から、所定のサービスを提供する大代表サーバが選定される。

大代表サーバがサービスを提供している間、顧客からの要求を処理することにより、大代表サーバに記憶されたデータが変更されると、大代表サーバはその変更内容を示す変更情報を他のサーバ１０へ送信する。変更情報を受信した他のサーバ１０は、それぞれが備える記憶部にその変更情報を記憶させる。これにより、他のサーバ１０は常に、大代表サーバと同じ状態を維持することができる。これは例えば、レプリケーション技術を用いることによって実現できる。

大代表サーバが故障等により、サービスを提供できなくなると、新たに大代表サーバが選定され、新たに選定された大代表サーバがサービスの提供を継続する。なお、サーバの故障は、ハートビートと呼ばれる信号をサーバ１０間で送受信することによって検知される。具体的には、あるサーバ１０から送信されたハートビートを、他のサーバ１０が予め決められた時間間隔内に受信しない場合、ハートビートを送信しているサーバ１０は故障したとみなされる。

なお、上述した変更情報の伝送方式としては例えば、通常は大代表サーバと同じサーバ群に属するサーバ１０だけに伝送し、その大代表サーバが属するサーバ群以外から新たに大代表サーバが選定された場合には、新たに選定された大代表サーバに、それまでの差分を伝送する方式を利用できる。但し、これは、運用時の負荷を考慮した伝送方式の一例であり、変更情報の伝送方式によっては本発明の適用範囲は制限されない。

図２は、図１に示したサーバ１０の構成の一例を示すブロック図である。

図１に示したサーバ１０は図２に示すように、高可用部１００と、サービス提供部１１０と、高可用部１００及びサービス提供部１１０とローカルネットワーク５０との間の通信を仲介する通信部１２０とを備えている。

高可用部１００は、メンバ管理部１０１と、サービス実行権管理部１０２と、調停部１０３と、記憶部１０４とを備えている。

記憶部１０４は例えば、データを記憶するハードディスクやメモリ等であり、他のサーバ１０から送信されてきた変更情報を記憶する。記憶部１０４に記憶されたデータは記憶部１０４の外部からの読み書きが可能である。なお、本実施形態においては、記憶部１０４が複数のサーバ１０によって共有されないことを前提とするが、記憶部１０４が複数のサーバ１０によって共有されていてもよい。

図３は、図２に示した調停部１０３の動作を説明するための図である。

調停部１０３は、自サーバと同じサーバ群に属する他のサーバ１０の調停部１０３と通信を行うことにより、相互に通信を行うことが可能なサーバ１０からなる第１のサーバグループを形成する。そして、第１のサーバグループのサーバ数がそのサーバ群のサーバ数の過半数以上である場合、調停部１０３は、第１のサーバグループの他のサーバ１０の調停部１０３と通信を行うことにより、第１のサーバグループの中から、そのサーバ群を代表する代表サーバを選定する。以降、ここで選定された代表サーバを「レベル０代表サーバ」という。本実施形態においては、サーバ群が６つ存在する。そのため、図３に示すように６つのレベル０代表サーバが選定され得る。そして、レベル０代表サーバの調停部１０３は、他のサーバ群においてレベル０代表サーバに選定されたサーバ１０の調停部１０３と通信を行うことにより、複数のレベル０代表サーバを代表する代表サーバを選定する。ここで選定された代表サーバを「レベル１代表サーバ」という。さらに、レベル１代表サーバの調停部１０３は、他のレベル１代表サーバの調停部１０３と通信を行うことにより、複数のレベル１代表サーバを代表する代表サーバを選定する。以降、ここで選定された代表サーバを「レベル２代表サーバ」という。ここでは、このレベル２代表サーバが大代表サーバとなるが、レベルの数は３つに限定されず、調停部１０３は、大代表サーバが選定されるまで、上述した動作を繰り返す。そして、調停部１０３は、代表サーバ及び大代表サーバの選定の結果を示す選定結果情報をサービス実行権管理部１０２へ出力する。なお、調停部１０３は、メンバ管理部１０１から出力されるサーバ情報及び代表サーバ情報を用いて他のサーバ１０と通信を行う。サーバ情報及び代表サーバ情報については後述する。なお、以降、各レベルにおいて代表サーバに選定されなかったサーバ１０のことを非代表サーバという。

再度、図２を参照すると、メンバ管理部１０１は、サーバ情報及び代表サーバ情報を記憶している。また、メンバ管理部１０１は、サーバ情報や代表サーバ情報の追加及び削除を行う。また、メンバ管理部１０１は、調停部１０３等のサーバ１０内の各部に、記憶されたサーバ情報及び代表サーバ情報を出力する。

図４は、図２に示したメンバ管理部１０１が記憶するサーバ情報及び代表サーバ情報を説明するための図である。

メンバ管理部１０１は、図４に示したようなツリー構造でサーバ情報及び代表サーバ情報を記憶している。サーバ情報は、サーバ群１〜６のそれぞれを識別する情報と、サーバ群１〜６のそれぞれに属する複数のサーバ１０のそれぞれを識別する情報とを含んでいる。サーバ群１〜６のそれぞれを識別する情報としては例えば、ＧＵＩＤ（Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ）やＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ）がある。また、サーバ群１〜６のそれぞれに属する複数のサーバ１０のそれぞれを識別する情報としては例えば、ＩＰアドレス及びポート番号がある。また、代表サーバ情報は、大代表サーバ及び各レベルの代表サーバのサーバ情報と、各代表サーバのレベルと、各代表サーバへ到達するためのリンクを示すリンク情報とを含んでいる。

図５は、図２に示したメンバ管理部１０１が代表サーバ情報を追加及び削除する動作を説明するためのフローチャートである。調停部１０３がレベルＮ（Ｎ＝０，１，２・・・）の代表サーバを選定する場合、レベルＮの直下のレベルの代表サーバであるレベル（Ｎ−１）の代表サーバの代表サーバ情報が必要となる。そこで、ここでは一例として、メンバ管理部１０１がレベル（Ｎ−１）の代表サーバの代表サーバ情報を追加及び削除する場合について説明する。以降、レベルＮ（Ｎ＝０，１，２・・）の代表サーバのことをレベルＮ代表サーバと表記する。

なお、ここでは、レベルＮ代表サーバになり得る複数のサーバ１０から成る集合のことを代表サーバ候補群という。例えば、図３に示した構成において、レベル２代表サーバになり得る代表サーバ候補群は、２つ存在する。１つ目の代表サーバ候補群は、サーバ群１〜３のそれぞれを代表する３つのレベル０代表サーバから成る集合であり、２つ目の代表サーバ候補群は、サーバ群４〜６のそれぞれを代表する３つの代表サーバから成る集合である。

まず、メンバ管理部１０１は、自サーバがレベル（Ｎ−１）代表サーバであるかどうかを判定する（ステップＳ１）。なお、メンバ管理部１０１は、サービス実行権管理部１０２から選定結果情報を取得することにより、自サーバがレベル（Ｎ−１）代表サーバであるかどうかを判定する。

ステップＳ１における判定の結果、自サーバがレベル（Ｎ−１）代表サーバである場合、メンバ管理部１０１は、自サーバをレベル（Ｎ−１）代表サーバとして代表サーバ情報に追加する（ステップＳ２）。

次に、メンバ管理部１０１は、他の代表サーバ候補群におけるレベル（Ｎ−１）代表サーバが代表サーバ情報に追加されているかどうかを確認する（ステップＳ３）。

ステップＳ３における判定の結果、他の代表サーバ候補群におけるレベル（Ｎ−１）代表サーバが代表サーバ情報に追加されている場合、メンバ管理部１０１は、その追加されているレベル（Ｎ−１）代表サーバに、レベルＮ代表サーバの選定を行うための調停要求を送信する（ステップＳ４）。

そして、メンバ管理部１０１は、送信した調停要求に対する応答を所定の時間内に受信したかどうかを判定する（ステップＳ５）。

ステップＳ５における判定の結果、送信した調停要求に対する応答を所定の時間内に受信しない場合、調停要求の送信先であるレベル（Ｎ−１）代表サーバを、代表サーバ情報から削除する（ステップＳ６）。

そして、メンバ管理部１０１は、調停要求の送信先であるレベル（Ｎ−１）代表サーバを代表サーバ情報から削除する指示を、自サーバをレベル（Ｎ−１）代表サーバとするレベル（Ｎ−１）の非代表サーバへブロードキャストする（ステップＳ７）。

一方、ステップＳ３における判定の結果、他の代表サーバ候補群におけるレベル（Ｎ−１）代表サーバが代表サーバ情報に追加されていない場合には、メンバ管理部１０１は、他の代表サーバ候補群のサーバ１０の全てに調停要求を送信する（ステップＳ８）。

そして、メンバ管理部１０１は、送信した調停要求に対する応答を所定の時間内に受信したかどうかを判定する（ステップＳ９）。

ステップＳ９における判定の結果、送信した調停要求に対する応答を所定の時間内に受信した場合、応答の送信元であるサーバ１０をレベル（Ｎ−１）代表サーバとして代表サーバ情報に追加する（ステップＳ１０）。

そして、メンバ管理部１０１は、応答の送信元であるサーバ１０をレベル（Ｎ−１）代表サーバとして代表サーバ情報に追加する指示を、自サーバをレベル（Ｎ−１）代表サーバとするレベル（Ｎ−１）の非代表サーバへブロードキャストする（ステップＳ１１）。なお、ステップＳ３〜Ｓ１１の動作は繰り返し実行される。

このように、自サーバがレベル（Ｎ−１）代表サーバである場合、メンバ管理部１０１は、他の代表サーバ候補群においてレベル（Ｎ−１）代表サーバが故障等により存在しないと、他の代表サーバ候補群のサーバ１０の全てに調停要求を送信する。そして、この調停要求を受信したサーバ１０は、自サーバがレベル（Ｎ−１）代表サーバである場合、その調停要求に対する応答を送信する。これにより、調停要求を送信したレベル（Ｎ−１）代表サーバのメンバ管理部１０１は、新たに選定された他のレベル（Ｎ−１）代表サーバを認識することができる。

ここで、ステップＳ１における判定の結果、自サーバがレベル（Ｎ−１）代表サーバでない場合には、メンバ管理部１０１は、自代表サーバ候補群におけるレベル（Ｎ−１）代表サーバが代表サーバ情報に記憶されているかどうかを判定する（ステップＳ１２）。

ステップＳ１２における判定の結果、自代表サーバ候補群におけるレベル（Ｎ−１）代表サーバが代表サーバ情報に記憶されている場合、メンバ管理部１０１は、記憶されているレベル（Ｎ−１）代表サーバをレベルＮ代表サーバの候補として代表サーバ情報に追加する（ステップＳ１３）。

次に、メンバ管理部１０１は、自代表サーバ候補群のレベル（Ｎ−１）代表サーバから、他の代表サーバ候補群におけるレベル（Ｎ−１）代表サーバの追加／削除の指示が送信されてきたかどうかを判定する（ステップＳ１４）。

ステップＳ１４における判定の結果、他の代表サーバ候補群におけるレベル（Ｎ−１）代表サーバの追加／削除の指示が送信されてきた場合、他の代表サーバ候補群におけるレベル（Ｎ−１）代表サーバをレベルＮ代表サーバの候補として代表サーバ情報に追加／削除する（ステップＳ１５）。

このように、自サーバがレベル（Ｎ−１）代表サーバでない場合、図４に示したメンバ管理部１０１に記憶される情報は、自代表サーバ候補群のレベル（Ｎ−１）代表サーバによって同期される。

再度、図２を参照すると、サービス実行権管理部１０２は、サービスを提供するサービス実行権を取得するプロセスを担当しており、本実施形態の高可用性システムにおいて、常に１つのサーバ１０がサービスを提供するための仕組みを提供する。具体的には、サービス実行権管理部１０２は、調停部１０３から出力された選定結果情報を受け付ける。そして、受け付けた選定結果が、自サーバが各レベルにおいて代表サーバに選定されたことを示している場合、そのレベルの非代表サーバへ所定の時間間隔でハートビートを送信する。また、サービス実行権管理部１０２は、受け付けた選定結果が、自サーバが大代表サーバに選定されたことを示している場合、所定のサービスの提供の開始を許可する許可情報をサービス提供部１１０へ出力する。また、サービス実行権管理部１０２は、自サーバが各レベルにおいて非代表サーバである場合、そのレベルの代表サーバから送信されるハートビートを受信する。そして、サービス実行権管理部１０２は、タイマーを用い、代表サーバから送信されたハートビートを予め決められた時間間隔内に受信したかどうかを判定する。判定の結果、代表サーバから送信されたハートビートを予め決められた時間間隔内に受信しない場合、サービス実行権管理部１０２は、調停部１０３に新たな代表サーバの選定を指示する。

サービス提供部１１０は、サービス実行権管理部１０２から出力された許可情報を受け付けると、所定のサービスの提供を開始する。なお、サービス提供部１１０は、自サーバが新たに大代表サーバに選定された場合には、記憶部１０４に記憶され、他のサーバ１０から送信されてきた変更情報に基づいて所定のサービスの提供を開始する。

以下に、上記のように構成された高可用性システムの動作について説明する。

ここでは、図１~図５に示した高可用性システムの動作について、以下の４つに分けて説明する。

（１）大代表サーバが選定されるまでの動作
（２）大代表サーバが選定されてからの通常動作
（３）大代表サーバがサービスを提供できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな代表サーバを選定できる場合の動作
（４）大代表サーバがサービスを実行できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな代表サーバを選定できない場合の動作
まず、上記（１）の「大代表サーバが選定されるまでの動作」について説明する。

図６は、図１〜図５に示した高可用性システムにおいて、大代表サーバが選定されるまでの動作を説明するためのフローチャートである。

調停部１０３は、メンバ管理部１０１から出力されたサーバ情報を用い、同じサーバ群に属する他のサーバ１０の調停部１０３と通信を行う。そして、そのサーバ群内において相互に通信を行うことが可能なサーバ１０からなるサーバグループである第１のサーバグループを形成する。

第１のサーバグループのサーバ数がそのサーバ群のサーバ数の過半数以上である場合、調停部１０３は、第１のサーバグループの中からレベル０代表サーバを選定する（ステップＳ２１）。

次に、調停部１０３は、自サーバがレベル０代表サーバに選定されたかどうかを判定する（ステップＳ２２）
ステップＳ２２の判定の結果、自サーバがレベル０代表サーバに選定されている場合、調停部１０３は、メンバ管理部１０１から出力された代表サーバ情報を用い、他のレベル０代表サーバと通信を行うことにより、レベル１代表サーバを選定する（ステップＳ２３〜Ｓ２４）。

次に、調停部１０３は、自サーバがレベル１代表サーバに選定されたかどうかを判定する（ステップＳ２５）。

ステップＳ２５の判定の結果、自サーバがレベル１代表サーバに選定された場合、調停部１０３は、代表サーバに選定されたレベルが最上位であるかどうかを判定する（ステップＳ２６）。

ステップＳ２６の判定の結果、代表サーバに選定されたレベルが最上位ではない場合、ステップＳ２３の動作へ遷移する。すなわち、調停部１０３は、レベルを１つ上げ、そのレベルの他の代表サーバと通信を行うことにより、１つ上げたレベルの代表サーバを選定する。

調停部１０３は、大代表サーバに選定されるか、その途中のレベルの代表サーバに選定されなくなるまで、上述した動作を繰り返す。そして、大代表サーバに選定されたサーバ１０は、大代表サーバとしての処理を実行する。また、大代表サーバに選定されなかった代表サーバは、代表サーバに選定されたレベルまでは代表サーバとしての処理を実行し、それよりも上のレベルにおいては非代表サーバとしての処理を実行する。

図７は、レベルＮの非代表サーバの動作を説明するための図である。

レベルＮの非代表サーバは、レベルＮ代表サーバには選定されなかったが、レベル０からレベル（Ｎ−１）まででは代表サーバに選定されている。従って、レベル０からレベル（Ｎ−１）までにおいては、レベル０からレベル（Ｎ−１）の非代表サーバへ所定の時間間隔でハートビートを送信する。但し、レベルNにおいては、代表サーバではないため、レベルＮ代表サーバから送信されたハートビートを受信し、レベルＮ代表サーバから送信されたハートビートを、予め決められた時間間隔内に受信しない場合、新たなレベルＮ代表サーバの選定を開始する。なお、レベルＮの非代表サーバは、レベル０からレベル（Ｎ−１）までの代表サーバとしての処理と、レベルＮの非代表サーバとしての処理とを同時に実行する。

また、あるレベルの代表サーバにならないと次のレベルの代表サーバになることができない。そのため、あるレベルで代表サーバでなくなった場合、その上のレベルの代表サーバでもなくなる。つまり、図７に示す処理のうちの１つでも終了したら、レベルＮ非代表サーバとしての処理は終了し、終了したレベルから代表サーバの選定が開始される。

図８は、大代表サーバの動作を説明するための図である。

図８に示すように、大代表サーバの動作は、図７に示したレベルＮの非代表サーバの動作と比べると、全てのレベルにおいて代表サーバとしての処理をする点が異なる。

ここで、大代表サーバが選定されるまでの動作を要約する。

調停部１０３は、まず、レベル０代表サーバの選定を開始する。そして、レベル０代表サーバの調停部１０３は、１つ上のレベルの代表サーバの選定を開始する。そして、いずれか１つのサーバ１０が大代表サーバに選定されるまでこれが繰り返される。

大代表サーバのサービス実行権管理部１０２は、サービス提供部１１０に許可情報を出力する。そして、サービス実行権管理部１０２から出力された許可情報を受け付けたサービス提供部１１０は、所定のサービスの提供を開始する。これにより、大代表サーバが属するサーバ群によって高可用性を維持しながら所定のサービスが提供される。例えば、図３に示した構成において、図中最も左のサーバ１０が大代表サーバに選定された場合、このサーバ１０が属するサーバ群１の３つサーバ１０により、高可用性を維持しながら所定のサービスが提供される。

次に、上記（２）〜（４）の動作について説明するが、その前に、大代表サーバが選定された後の代表サーバ及び非代表サーバの動作を説明する。

まず、大代表サーバが選定された後の代表サーバの動作について説明する。

レベルNにおいては、１つの代表サーバと、非代表サーバとが存在している。ここで、代表サーバは、代表サーバであり続けようとする。一方、非代表サーバは、代表サーバから送信されたハートビートを予め決められた時間間隔内に受信しない場合、新たな代表サーバの選定を開始しようとする。

本実施形態では、代表サーバは、選定されてから一定時間、代表サーバであることが保障される。そして、その一定時間が経過すると、代表サーバは、ハートビートを送信することにより、自サーバが正常に動作していることを非代表サーバに伝える。これにより、代表サーバは、代表サーバである時間を延長していく。

図９は、大代表サーバが選定された後の代表サーバの動作を説明するためのフローチャートである。

サービス実行権管理部１０２は、タイマーを起動させる（ステップＳ３１）。このタイマーは、起動させてから所定の時間が経過すると停止するタイマーである。

次に、サービス実行権管理部１０２は、タイマーが停止したかどうかを判定する（ステップＳ３２）。

ステップＳ３２における判定の結果、タイマーが停止していない場合、タイマーが停止したかどうかの判定が繰り返し実行される。

一方、ステップＳ３２における判定の結果、タイマーが停止している場合、サービス実行権管理部１０２は、ハートビートを送信する（ステップＳ３３）。つまり、代表サーバは、所定の時間間隔でハートビートを送信することとなる。

そして、サービス実行権管理部１０２は、代表サーバである時間を延長できたかどうかを判定する（ステップＳ３４）。

ステップＳ３４における判定の結果、代表サーバである時間を延長できた場合、ステップＳ３１の動作へ遷移する。

一方、ステップＳ３４における判定の結果、代表サーバである時間を延長できなかった場合には、代表サーバは非代表サーバとなり、図６に示したフローチャートの動作に従い、再度代表サーバの選定が開始される。なお、代表サーバである時間を延長できないのは、ハートビートを送信した非代表サーバの過半数がハートビートを受信できない等の理由による。

次に、大代表サーバが選定された後の非代表サーバの動作について説明する。

図１０は、大代表サーバが選定された後の非代表サーバの動作を説明するためのフローチャートである。

サービス実行権管理部１０２は、タイマーを起動させる（ステップＳ４１）。このタイマーは、起動させてから所定の時間が経過すると停止するタイマーである。

次に、サービス実行権管理部１０２は、代表サーバから送信されたハートビートを受信したかどうかを判定する（ステップＳ４２）。

ステップＳ４２の判定の結果、代表サーバから送信されたハートビートを受信した場合、サービス実行権管理部１０２は、ステップＳ４１の動作へ遷移する。この場合、代表サーバは、代表サーバである時間を延長できたこととなる。

一方、ステップＳ４２の判定の結果、代表サーバから送信されたハートビートを受信していない場合には、サービス実行権管理部１０２は、タイマーが停止しているかどうかを判定する（ステップＳ４３）。

ステップＳ４３における判定の結果、タイマーが停止していない場合、ステップＳ４２の動作へ遷移する。つまり、サービス実行権管理部１０２は、代表サーバから送信されたハートビートを受信したかどうかの判定を継続する。

一方、ステップＳ４３における判定の結果、タイマーが停止している場合には、サービス実行権管理部１０２は、代表サーバが故障したとみなし、新たな代表サーバの選定を調停部１０３に指示する（ステップＳ４４）。そして、図６に示したフローチャートの動作に従い、再度代表サーバの選定が開始される。

なお、代表サーバが正常に動作している限り、代表サーバが代表サーバである時間を容易に延長できるように、あるレベルの代表サーバのタイマーが停止するまでの時間は、同じレベルの非代表サーバのタイマーが停止するまでの時間よりも短い。また、上位のレベルほど、タイマーが停止するまでの時間が長い。つまり、タイマーが停止するまでの時間の長さは以下の式（１）及び式（２）によって表される。

レベルＮ代表サーバのタイマーが停止するまでの時間 ＜ レベルＮの非代表サーバのタイマーが停止するまでの時間・・・式（１）
レベル（Ｎ−１）の非代表サーバのタイマーが停止するまでの時間 ＜ レベルＮの非代表サーバのタイマーが停止するまでの時間・・・式（２）
以上を踏まえた上で次に、上記（２）の「大代表サーバが選定されてからの通常動作」について説明する。

代表サーバのサービス実行権管理部１０２は、タイマーが停止すると、ハートビートを送信することにより、代表サーバである時間を延長する。上記の式（１）に示したように通常は、同じレベルにおいては、代表サーバのタイマーの方が非代表サーバのタイマーよりも先に停止する。そのため、代表サーバは、代表サーバである時間を容易に延長できる。これは、どのレベルにおいても同様である。従って、通常は、同じ大代表サーバによってサービスの提供が継続される。

次に、上記（３）の「大代表サーバがサービスを提供できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな大代表サーバを選定できる場合の動作」について説明する。ここでは、図３に示した構成の場合において、図中最も左のサーバ１０が大代表サーバ（レベル２代表サーバ）であった場合を一例として説明する。

大代表サーバが正常に動作しなくなった場合、または、代表サーバである時間を延長できなかった場合、大代表サーバは、大代表サーバでなくなるだけではなく、レベル１及びレベル０代表サーバでもなくなる。つまり、レベル０代表サーバ及びレベル１代表サーバも不在となる。

上記の式（２）に示したように、下位のレベルほどタイマーが停止するまでの時間が短い。そのため、まず、サーバ群１に属するサーバ１０の調停部１０３が、サーバ群１を代表する新たなレベル０代表サーバの選定を開始する。具体的には、サーバ群１に属するサーバ１０は、相互に通信することが可能なサーバグループである第２のサーバグループを形成する。そして、第２のサーバグループのサーバ数が、サーバ群１のサーバ数の過半数以上である場合、第２のサーバグループのサーバは、第２のサーバグループの中から新たなレベル０代表サーバを選定する。そして、新たにレベル０代表サーバに選定されたサー
バ１０はすぐに、レベル１代表サーバ及びレベル２代表サーバの選定を開始する。

上記の式（２）に示したように、タイマーが停止するまでの時間は、レベル０が最も短いため、レベル１及びレベル２において代表サーバの選定はまだ開始されていない。そのため、新たにレベル０代表サーバに選定されたサーバ１０がレベル１代表サーバ及びレベル２代表サーバになれる。

なお、下位のレベルにおいて新たに代表サーバの選定を開始する際、上位レベルの代表サーバに対し、ハートビートを送信する時間間隔の延長を要求するハートビート延長要求を発行する。

ハートビート延長要求を受け付けた上位レベルの代表サーバは、タイマーが停止するまでの時間を延長する。これにより、新たにレベル０代表サーバに選定されたサーバ１０は、故障等によって正常に動作しない場合を除き、確実にレベル１代表サーバ及びレベル２代表サーバに選定される。なお、ハートビート延長要求によるハートビートを送信する時間の延長は１回限りであり、タイマーが停止した場合には、図６に示したフローチャートの動作に従い、再度代表サーバの選定が開始される。

最後に、上記（４）の「大代表サーバがサービスを実行できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな大代表サーバを選定できない場合の動作」について説明する。ここでは、図３に示した構成の場合において、図中最も左のサーバ１０が大代表サーバ（レベル２代表サーバ）であった場合を一例として説明する。

大代表サーバが正常に動作しなくなった場合、または、代表サーバである時間を延長できなかった場合、大代表サーバは、大代表サーバでなくなるだけではなく、レベル１及びレベル０代表サーバでもなくなる。つまり、レベル０代表サーバ及びレベル１代表サーバも不在となる。これは、上記（３）の場合と同様である。

ここでは、図３の図中最も左側のレベル０代表サーバと、左側のレベル１代表サーバが不在となる。この場合、まず、サーバ群１に属する複数のサーバ１０の調停部１０３が、サーバ群１を代表する新たなレベル０代表サーバの選定を開始する。但し、ここでは、ネットワークの障害により、サーバ群１に属するサーバ数の過半数以上を占める第２のサーバグループを形成できず、新たなレベル０代表サーバを選定できなかったものとする。つまり、サーバ群１を代表するレベル０代表サーバが存在しないこととなる。

この場合、図３の図中左から２番目のレベル０代表サーバと、３番目のレベル０代表サーバとが通信を行うことにより、いずれかがレベル１代表サーバに選定される。そして、新たにレベル１の代表サーバに選定されたサーバ１０はすぐに、レベル２代表サーバの選定を開始する。

ここで、上記の式（２）に示したように、タイマーが停止するまでの時間は、レベル２よりもレベル１の方が短い。そのため、レベル２において代表サーバの選定はまだ開始されていない。そのため、新たにレベル１代表サーバになったサーバ１０がレベル２代表サーバになれる。

上述したように、大代表サーバが属するサーバ群において新たにレベル０代表サーバを選定できない場合、所定のサービスの提供を移動するコストが少ないサーバ群によってサービスの提供が継続される。つまり、サービスを提供することができない時間を最小限にすることができ、高可用性を維持することができる。

このように本実施形態においては、サーバ群１〜６のそれぞれに属する複数のサーバ１０は、当該サーバ群に属する複数のサーバ１０のうち、相互に通信可能なサーバからなる第１のサーバグループを形成する。そして、第１のサーバグループのサーバは、当該第１のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループのサーバ１０の中から、当該サーバ群を代表する代表サーバを選定する。そして、サーバ群１〜６毎に選定された複数の代表サーバは、その複数の代表サーバの中から、所定のサービスを提供する大代表サーバを選定する。

これにより、所定のサービスを提供するサーバ１０が複数存在すること、及び、所定のサービスを提供するサーバ１０が存在しなくなるのを回避することができる。

従って、データの整合性を確保しつつ、高可用性を維持することが可能となる。

なお、本発明においては、サーバ内の処理は上述の専用のハードウェアにより実現されるもの以外に、その機能を実現するためのプログラムをサーバにて読取可能な記録媒体に記録し、この記録媒体に記録されたプログラムをサーバに読み込ませ、実行するものであっても良い。サーバにて読取可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＤＶＤ、ＣＤなどの移設可能な記録媒体の他、サーバに内蔵されたＨＤＤなどを指す。

１〜６ サーバ群
１０ サーバ
５０ ローカルネットワーク
１００ 高可用部
１０１ メンバ管理部
１０２ サービス実行権管理部
１０３ 調停部
１０４ 記憶部
１１０ サービス提供部
１２０ 通信部
１５０ グローバルネットワーク

Claims (10)

1. 相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムであって、
   前記複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第１のサーバグループを形成し、
   前記第１のサーバグループのサーバは、当該第１のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定し、
   前記複数のサーバ群毎に選定された複数の代表サーバは、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する高可用性システム。
2. 請求項１に記載の高可用性システムにおいて、
   前記大代表サーバは、当該大代表サーバと同じサーバ群に属する他のサーバへ所定の時間間隔で信号を送信し、
   前記大代表サーバと同じサーバ群に属する他のサーバは、当該大代表サーバから送信された信号を予め決められた第１の時間間隔内に受信しない場合、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第２のサーバグループを形成し、
   前記第２のサーバグループのサーバは、当該第２のサーバグループのサーバ数が前記所定数以上である場合、当該第２のサーバグループの中から、前記代表サーバを新たに選定し、
   前記新たに選定された前記代表サーバは、前記大代表サーバとして前記所定のサービスの提供を開始する高可用性システム。
3. 請求項２に記載の高可用性システムにおいて、
   前記大代表サーバは、当該大代表サーバ以外の前記代表サーバへ前記所定の時間間隔で信号を送信し、
   前記大代表サーバ以外の前記代表サーバは、当該大代表サーバから送信された信号を前記第１の時間間隔よりも長い第２の時間間隔内に受信しない場合、前記複数の代表サーバの中から前記大代表サーバを新たに選定し、
   前記新たに選定された前記大代表サーバは、前記所定のサービスの提供を開始する高可用性システム。
4. 請求項１乃至３のいずれか１項に記載の高可用性システムにおいて、
   前記所定数は、前記サーバ群に属するサーバ数の過半数である高可用性システム。
5. 相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバであって、
   前記所定のサービスを提供するサービス提供部と、
   自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第１のサーバグループを形成し、該第１のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループの他のサーバと通信を行うことにより、当該第１のサーバグループの中から、当該サーバ群を代表する代表サーバを選定し、自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定し、自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供の開始を許可する許可情報を出力する高可用部と、を有し、
   前記サービス提供部は、前記高可用部から出力された許可情報を受け付けると、前記所定のサービスの提供を開始するサーバ。
6. 請求項５に記載のサーバにおいて、
   前記高可用部は、自サーバが前記大代表サーバである場合、自サーバと同じサーバ群に属する他のサーバへ所定の時間間隔で信号を送信し、自サーバが前記大代表サーバと同じサーバ群に属する他のサーバである場合、当該大代表サーバから送信された信号を予め決められた第１の時間間隔内に受信しないと、当該サーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第２のサーバグループを形成し、該第２のサーバグループのサーバ数が前記所定数以上である場合、当該第２のサーバグループの他のサーバと通信を行うことにより、当該第２のサーバグループの中から前記代表サーバを新たに選定し、自サーバが新たに前記代表サーバに選定されると、前記許可情報を出力するサーバ。
7. 請求項６に記載のサーバにおいて、
   前記高可用部は、自サーバが前記大代表サーバである場合、自サーバ以外の前記代表サーバへ前記所定の時間間隔で信号を送信し、自サーバが前記大代表サーバ以外の前記代表サーバである場合、当該大代表サーバから送信された信号を前記第１の時間間隔よりも長い第２の時間間隔内に受信しないと、自サーバ以外の前記代表サーバと通信を行うことにより、前記複数の代表サーバの中から前記大代表サーバを新たに選定し、自サーバが新たに前記大代表サーバに選定されると、前記許可情報を出力するサーバ。
8. 請求項５乃至７のいずれか１項に記載のサーバにおいて、
   前記所定数は、前記サーバ群に属するサーバ数の過半数であるサーバ。
9. 相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムにおける高可用性維持方法であって、
   前記複数のサーバ群のそれぞれに属する複数のサーバが、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第１のサーバグループを形成する処理と、
   前記第１のサーバグループのサーバが、当該第１のサーバグループのサーバ数が当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定する処理と、
   前記複数のサーバ群毎に選定された複数の代表サーバが、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する処理と、を有する高可用性維持方法。
10. 相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバに、
    自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第１のサーバグループを形成する機能と、
    前記第１のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第１のサーバグループの他のサーバと通信を行うことにより、当該第１のサーバグループの中から、当該サーバ群を代表する代表サーバを選定する機能と、
    自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する機能と、
    自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供を開始する機能と、を実現させるためのプログラム。