高可用性システム、サーバ、高可用性維持方法及びプログラム
【課題】データの整合性を確保しつつ、高可用性を維持する。
【解決手段】相互に接続された複数のサーバ群のそれぞれに属するいずれかのサーバによって所定のサービスの提供を継続して行う高可用性システムであって、複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成し、第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定し、複数のサーバ群毎に選定された複数の代表サーバは、複数の代表サーバの中から、所定のサービスを提供する大代表サーバを選定する。
【解決手段】相互に接続された複数のサーバ群のそれぞれに属するいずれかのサーバによって所定のサービスの提供を継続して行う高可用性システムであって、複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成し、第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定し、複数のサーバ群毎に選定された複数の代表サーバは、複数の代表サーバの中から、所定のサービスを提供する大代表サーバを選定する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数のサーバ群によって高可用性を維持する高可用性システム、サーバ、高可用性維持方法及びプログラムに関する。
【背景技術】
【0002】
オンラインショップ等の商用のサービスを提供するシステムにおいては、顧客にサービスを提供しているサーバが故障した場合でも、顧客へのサービスの提供を継続することが求められる。つまり、システムとして継続して稼働できることが重要である。
【0003】
システムが継続して稼働できることを示す指標として可用性がある。可用性は、所定の期間中、何パーセントの時間にシステムが稼働できていたかを示す。従って、商用のサービスを提供するシステムにおいては、高可用性を維持する必要がある。
【0004】
高可用性を維持するための手法としては、予め予備用のサーバを準備しておき、サービスを提供しているサーバが故障した場合、サービスの提供を予備用のサーバに切り替える方式が一般的である。但し、顧客からの要求を処理することにより、サービスを提供しているサーバに記憶された顧客データ等のデータが変化するシステムの場合、予備用のサーバは、サービスを提供しているサーバと同じ状態を維持している必要がある。以降、単にデータという場合には、顧客からの要求を処理することによって変化する顧客データ等のことを指す。
【0005】
これを実現する技術としては例えば、レプリケーション技術がある。レプリケーション技術は一般的に、複数のサーバでデータを共有するための記憶装置が存在しない場合に利用される。
【0006】
レプリケーション技術では、サービスを提供しているサーバに記憶されたデータを複数の予備用のサーバに複製しておく。そして、サービスを提供しているサーバが故障したら、サービスの提供を予備用のサーバに瞬時に切り替える。これにより、サービスの提供を継続することができる。
【0007】
図11は、レプリケーション技術を利用したサーバの構成の一例を示す図である。図11においては、サーバ(M1)がサービスを提供しているサーバである。
【0008】
レプリケーション技術を利用した場合、サーバ(M1)に記憶されたデータが変更されると、サーバ(M1)はサーバ(R1)〜(R3)にその変更内容を通知する。
【0009】
サーバ(M1)からの通知を受けたサーバ(R1)〜(R3)は、それぞれが備える記憶装置に、その変更内容を反映させる。これにより、サーバ(R1)〜(R3)は常に、サーバ(M1)と同じ状態を維持することができる。
【0010】
レプリケーション技術において、高可用性を維持するための重要な仕組みは、サービスを提供しているサーバ(M1)が故障した場合に、その故障を検知し、サービスを提供するサーバをサーバ(R1)〜(R3)の中から新たに選定する仕組みである。
【0011】
サーバ(M1)の故障の検知は、サーバ(M1)がハートビートと呼ばれる信号を所定の時間間隔でサーバ(R1)〜(R3)へ送信し、サーバ(R1)〜(R3)が予め決められた時間間隔内にハートビートを受信できたかどうかによって判断することができる。
【0012】
サーバ(R1)〜(R3)は、予め決められた時間間隔内にサーバ(M1)から送信されたハートビートを受信しなければ、サーバ(M1)が故障したとみなす。この場合、サーバ(R1)〜(R3)の中から、サービスを提供する新たなサーバが選定される。以降、サービスを提供する新たなサーバのことをサーバ(M2)という。
【0013】
サーバ(M2)を選定するための選定方法は例えば、サーバ(R1)〜サーバ(R3)の優先順位を予め決めておき、優先順位の高いサーバから順番に、サーバ(M2)になるようにしておけばよい。
【0014】
しかし、この選定方法を利用した場合、サーバ(M1)とサーバ(R1)〜(R3)とがネットワークで接続されていると、Split−brain問題が発生する可能性がある。以下に、Split−brain問題について説明する。
【0015】
サーバ(M1)とサーバ(R1)〜(R3)とを接続するネットワークに障害が発生した場合、サーバ(M1)が故障していないにも関わらず、サーバ(M1)から送信されたハートビートが、予め決められた時間間隔内にサーバ(R1)〜(R3)にて受信されない場合がある。ここでは一例として、ネットワークの障害により、サーバ(M1)とサーバ(R1)との間、及び、サーバ(R2)とサーバ(R3)との間のみでしか通信を行うことができないと仮定する。
【0016】
この場合、サーバ(R2)及びサーバ(R3)は、サーバM1から送信されたハートビートを予め決められた時間間隔内に受信しない。そのため、サーバ(R2)及びサーバ(R3)は、サーバ(M1)が故障したとみなす。また、サーバ(R2)及びサーバ(R3)は、サーバ(R1)と通信を行うこともできない。従って、サーバ(R2)及びサーバ(R3)の中からサーバ(M2)が選定される。
【0017】
しかし、実際には、サーバ(M1)は故障していないため、サービスを提供しているサーバは、サーバ(M1)とサーバ(M2)との2つになってしまう。
【0018】
図12は、図11に示した構成において、サービスを提供するサーバが新たに選定された場合の一例を説明するための図である。図12では、図11におけるサーバ(R2)がサーバ(M2)に選定された場合を示している。
【0019】
図12に示す例の場合、顧客からの要求は、サーバ(M1)またはサーバ(M2)のいずれかによって処理される。例えば、提供されるサービスが顧客の貯金を管理するサービスであった場合、クライアント端末(C1)が500円を貯金する処理を要求すると、この処理を受け付けたサーバ(M1)においては500円が貯金される。しかし、この処理を受け付けていないサーバ(M2)においては500円が貯金されてないこととなる。つまり、システムとしてデータの整合性がとれていない状態となる。これが、Split−brain問題である。
【0020】
このようなSplit−brain問題を解決するために、相互に通信を行うことが可能なサーバの数が全サーバ数の過半数以上を占めるサーバグループだけがサービスを提供できるようにする方式がある。以降、この方式により、サービスを提供するサーバを選定するアルゴリズムのことを過半数アルゴリズムという、なお、過半数アルゴリズムの1つであるPAXOSアルゴリズムが例えば、非特許文献1に開示されている。
【0021】
この方式では、サービスを提供しているサーバから送信されたハートビートが予め決められた時間間隔内に受信されない場合、他のサーバ間で通信を行うことにより、サーバグループを形成する。そして、相互に通信を行うことが可能なサーバ数が全サーバ数の過半数以上を占めるサーバグループの中から、サービスを提供する新たなサーバが選定される。
このような高可用性システムが例えば、非特許文献2に開示されている。
【0022】
図13は、過半数アルゴリズムによってサービスを提供するサーバが選定される構成の一例を説明するための図である。
【0023】
図13に示すように、相互に通信を行うことが可能なサーバ数が全サーバ数の過半数以上を占めるサーバグループは1つしか存在しない。従って、上述したSplit−brain問題を回避することができる。
【0024】
ここで、レプリケーション技術を用いた場合、データを複製するサーバの数が多ければ多いほど、高可用性を維持することができる。しかし、この場合、データの複製にかかるコストによって性能が低下してしまう場合がある。
【0025】
つまり、高可用性を維持する場合、性能とのバランスが重要になる。一般的には、相互に高速な通信が可能な複数のサーバを用いることによって性能の低下を回避するようにしている。しかし、相互に高速な通信が可能なサーバ数は限られており、例えばサーバが故障している間は可用性の低下が回避できない。
【0026】
また、相互に高速な通信が可能な複数のサーバは、同じネットワーク装置に接続されていることが多い。そのため、これら複数のサーバには、ネットワーク障害の影響が同時に及ぶ確率が高い。
【0027】
一方、物理的に離れた場所に設置されている複数のサーバ間の通信速度は、同じネットワーク装置に接続された複数のサーバ間の通信速度に比べて遅くなる。そのため、物理的に離れた場所に設置されている複数のサーバを用いた場合、性能の低下を回避することが難しくなる。
【0028】
これを解決するための方法として、相互に高速な通信が可能な複数のサーバからなるサーバ群を複数準備しておく方法が検討されている。
【0029】
図14は、複数のサーバ群を有する高可用性システムの構成の一例を説明するための図である。
【0030】
図14に示す例では通常、複数のサーバ群のいずれかに属する複数のサーバのいずれかによってサービスを提供する。1つのサーバ群に属する複数のサーバ間の通信速度は、例えば1Gbps(Giga bit per second)のように高速であり、性能の低下を回避しつつ、高可用性を維持できる。そして、そのサーバ群によってサービスの提供ができない場合にのみ、他のサーバ群のいずれかがサービスの提供を継続する。例えば、図14においてサービスを提供しているサーバ群がサーバ群Aであった場合、サーバ群Aによってサービスの提供ができなくなると、サーバ群Bがサービスの提供を継続する。
【先行技術文献】
【非特許文献】
【0031】
【非特許文献1】Paxos Made Simple, Leslie Lamport. Appears in ACM SIGACT News (Distributed Computing Column), Vol. 32, No. 4 (December 2001), pages 51-58.
【非特許文献2】"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.
【発明の概要】
【発明が解決しようとする課題】
【0032】
図13を参照して説明したような過半数アルゴリズムと、図14を参照して説明した高可用性システムとを組み合わせれば、データの整合性を確保しつつ、高可用性を維持することが可能なようにも思える。
【0033】
図15は、過半数アルゴリズムと高可用性システムとを組み合わせた場合の一例を説明するための図である。
【0034】
図15においては、サーバ群Aには、サーバ群Aに属するサーバ数の過半数以上のサーバからなるサーバグループが存在する。この場合、PAXOSアルゴリズム等の過半数アルゴリズムでは、そのサーバグループは、サービスの提供をサーバ群Bに移動させずに、自サーバグループでサービスを提供する。一方、サーバ群Aに属するサーバ数の過半数未満のサーバからなるサーバグループは、自サーバグループでサービスの提供が行えない。そのため、このサーバグループは、サービスの提供をサーバ群Bに移動させてしまう。この場合、サービスを提供するサーバが2つ存在することになってしまい、上述したSplit−brain問題が発生する。つまり、データの整合性を確保できなくなってしまうという問題点がある。
【0035】
図16は、過半数アルゴリズムと高可用性システムとを組み合わせた場合の他の例を説明するための図である。
【0036】
図16においては、サーバ群Aには、サーバ群Aに属するサーバ数の過半数以上のサーバからなるサーバグループが存在しない。この場合、PAXOSアルゴリズム等の過半数アルゴリズムでは、サーバ群Aのいずれのサーバグループもサービスを提供することができない。また、Split−brain問題を回避するために、サーバ群Aのいずれのサーバグループも、サービスの提供をサーバ群Bに移動させないと、サーバ群A及びサーバ群Bのいずれによってもサービスが提供されなくなる。つまり、サービスを提供するサーバが存在しなくなり、高可用性が維持できなくなってしまうという問題点がある。
【0037】
本発明は、データの整合性を確保しつつ、高可用性を維持することを可能にする高可用性システム、サーバ、高可用性維持方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【0038】
上記目的を達成するために本発明の高可用性システムは、相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムであって、
前記複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成し、
前記第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定し、
前記複数のサーバ群毎に選定された複数の代表サーバは、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する。
【0039】
また、上記目的を達成するために本発明のサーバは、相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバであって、
前記所定のサービスを提供するサービス提供部と、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第1のサーバグループを形成し、該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループの他のサーバと通信を行うことにより、当該第1のサーバグループの中から、当該サーバ群を代表する代表サーバを選定し、自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定し、自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供の開始を許可する許可情報を出力する高可用部と、を有し、
前記サービス提供部は、前記高可用部から出力された許可情報を受け付けると、前記所定のサービスの提供を開始する。
【0040】
また、上記目的を達成するために本発明の高可用性維持方法は、相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムにおける高可用性維持方法であって、
前記複数のサーバ群のそれぞれに属する複数のサーバが、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成する処理と、
前記第1のサーバグループのサーバが、当該第1のサーバグループのサーバ数が当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定する処理と、
前記複数のサーバ群毎に選定された複数の代表サーバが、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する処理と、を有する。
【0041】
また、上記目的を達成するために本発明のプログラムは、相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバに、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第1のサーバグループを形成する機能と、
前記第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループの他のサーバと通信を行うことにより、当該第1のサーバグループの中から、当該サーバ群を代表する代表サーバを選定する機能と、
自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する機能と、
自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供を開始する機能と、を実現させる。
【発明の効果】
【0042】
本発明によれば、複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成する。そして、第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定する。そして、複数のサーバ群毎に選定された複数の代表サーバは、その複数の代表サーバの中から、所定のサービスを提供する大代表サーバを選定する。
【0043】
これにより、所定のサービスを提供するサーバが複数存在すること、及び、所定のサービスを提供するサーバが存在しなくなるのを回避することができる。
【0044】
従って、データの整合性を確保しつつ、高可用性を維持することが可能となる。
【図面の簡単な説明】
【0045】
【図1】本発明の高可用性システムの実施の一形態の構成を示すブロック図である。
【図2】図1に示したサーバの構成の一例を示すブロック図である。
【図3】図2に示した調停部の動作を説明するための図である。
【図4】図2に示したメンバ管理部が記憶するサーバ情報及び代表サーバ情報を説明するための図である。
【図5】図2に示したメンバ管理部が代表サーバ情報を追加及び削除する動作を説明するためのフローチャートである。
【図6】図1〜図5に示した高可用性システムにおいて、大代表サーバが選定されるまでの動作を説明するためのフローチャートである。
【図7】レベルNの非代表サーバの動作を説明するための図である。
【図8】大代表サーバの動作を説明するための図である。
【図9】大代表サーバが選定された後の代表サーバの動作を説明するためのフローチャートである。
【図10】大代表サーバが選定された後の非代表サーバの動作を説明するためのフローチャートである。
【図11】レプリケーション技術を利用したサーバの構成の一例を示す図である。
【図12】図11に示した構成において、サービスを提供するサーバが新たに選定された場合の一例を説明するための図である。
【図13】過半数アルゴリズムによってサービスを提供するサーバが選定される構成の一例を説明するための図である。
【図14】複数のサーバ群を有する高可用性システムの構成の一例を説明するための図である。
【図15】過半数アルゴリズムと高可用性システムとを組み合わせた場合の一例を説明するための図である。
【図16】過半数アルゴリズムと高可用性システムとを組み合わせた場合の他の例を説明するための図である。
【発明を実施するための形態】
【0046】
以下に、本発明の実施の形態について図面を参照して説明する。
【0047】
図1は、本発明の高可用性システムの実施の一形態の構成を示すブロック図である。
【0048】
本実施形態の高可用性システムは図1に示すように、3つのサーバ10が属するサーバ群1〜6を備えている。なお、サーバ群1〜6は、階層化された構成にすることも可能である。例えば、サーバ群1〜6を1つのサーバ群とした巨大なサーバ群同士がネットワークで接続され、相互にデータの送受信ができる構成もありえる。この場合、サーバ群の階層数に制限はない。また、サーバ群の数は6つに限定されない。また、サーバ群1〜6に属するサーバの数は3つに限定されない。
【0049】
また、複数のサーバ10間でデータを送受信する際の通信速度は、スイッチやルータの配置のようなネットワークの構成や物理的距離によって異なる。ここでは、所定の通信速度以上の通信速度で相互に通信を行える3つのサーバ10が1つのサーバ群に属している。
【0050】
サーバ10は、本実施形態の高可用性システムと接続されたクライアント端末等に所定のサービスを提供する。サーバ10は例えば、メインフレームやパーソナルコンピュータ、携帯電話等である。また、サーバ10は、ネットワーク構成装置(不図示)等を用いたローカルネットワーク50に接続され、自サーバと同じサーバ群に属する他のサーバ10と相互に通信を行うことによってデータを送受信する。ローカルネットワーク50は、ネットワーク構成装置(不図示)等を用いたグローバルネットワーク150と接続されている。サーバ10は、ローカルネットワーク50及びグローバルネットワーク150を介し、自サーバと異なるサーバ群に属する他のサーバ10と相互に通信を行うことによってデータを送受信する。
【0051】
なお、ローカルネットワーク50及びグローバルネットワーク150の通信媒体や通信規格は、複数のサーバ10の間で相互に通信を行うことが可能であれば、どのようなものでもよい。例えば、インターネットやTCP/IP(Transmission Control Protocol/Internet Protocol)、無線ネットワーク等が挙げられる。
【0052】
本実施形態の高可用性システムでは、サーバ群1〜6のそれぞれにおいて、相互に通信することが可能なサーバ10からなるサーバグループを形成する。そして、そのサーバグループのサーバ数がそのサーバ群に属するサーバ数の過半数以上である場合、そのサーバグループの中から、そのサーバ群を代表する代表サーバが選定される。これは例えば、PAXOSアルゴリズムを用いることによって実現できる。そして、サーバ群1〜6毎に選定された複数の代表サーバの中から、所定のサービスを提供する大代表サーバが選定される。
【0053】
大代表サーバがサービスを提供している間、顧客からの要求を処理することにより、大代表サーバに記憶されたデータが変更されると、大代表サーバはその変更内容を示す変更情報を他のサーバ10へ送信する。変更情報を受信した他のサーバ10は、それぞれが備える記憶部にその変更情報を記憶させる。これにより、他のサーバ10は常に、大代表サーバと同じ状態を維持することができる。これは例えば、レプリケーション技術を用いることによって実現できる。
【0054】
大代表サーバが故障等により、サービスを提供できなくなると、新たに大代表サーバが選定され、新たに選定された大代表サーバがサービスの提供を継続する。なお、サーバの故障は、ハートビートと呼ばれる信号をサーバ10間で送受信することによって検知される。具体的には、あるサーバ10から送信されたハートビートを、他のサーバ10が予め決められた時間間隔内に受信しない場合、ハートビートを送信しているサーバ10は故障したとみなされる。
【0055】
なお、上述した変更情報の伝送方式としては例えば、通常は大代表サーバと同じサーバ群に属するサーバ10だけに伝送し、その大代表サーバが属するサーバ群以外から新たに大代表サーバが選定された場合には、新たに選定された大代表サーバに、それまでの差分を伝送する方式を利用できる。但し、これは、運用時の負荷を考慮した伝送方式の一例であり、変更情報の伝送方式によっては本発明の適用範囲は制限されない。
【0056】
図2は、図1に示したサーバ10の構成の一例を示すブロック図である。
【0057】
図1に示したサーバ10は図2に示すように、高可用部100と、サービス提供部110と、高可用部100及びサービス提供部110とローカルネットワーク50との間の通信を仲介する通信部120とを備えている。
【0058】
高可用部100は、メンバ管理部101と、サービス実行権管理部102と、調停部103と、記憶部104とを備えている。
【0059】
記憶部104は例えば、データを記憶するハードディスクやメモリ等であり、他のサーバ10から送信されてきた変更情報を記憶する。記憶部104に記憶されたデータは記憶部104の外部からの読み書きが可能である。なお、本実施形態においては、記憶部104が複数のサーバ10によって共有されないことを前提とするが、記憶部104が複数のサーバ10によって共有されていてもよい。
【0060】
図3は、図2に示した調停部103の動作を説明するための図である。
【0061】
調停部103は、自サーバと同じサーバ群に属する他のサーバ10の調停部103と通信を行うことにより、相互に通信を行うことが可能なサーバ10からなる第1のサーバグループを形成する。そして、第1のサーバグループのサーバ数がそのサーバ群のサーバ数の過半数以上である場合、調停部103は、第1のサーバグループの他のサーバ10の調停部103と通信を行うことにより、第1のサーバグループの中から、そのサーバ群を代表する代表サーバを選定する。以降、ここで選定された代表サーバを「レベル0代表サーバ」という。本実施形態においては、サーバ群が6つ存在する。そのため、図3に示すように6つのレベル0代表サーバが選定され得る。そして、レベル0代表サーバの調停部103は、他のサーバ群においてレベル0代表サーバに選定されたサーバ10の調停部103と通信を行うことにより、複数のレベル0代表サーバを代表する代表サーバを選定する。ここで選定された代表サーバを「レベル1代表サーバ」という。さらに、レベル1代表サーバの調停部103は、他のレベル1代表サーバの調停部103と通信を行うことにより、複数のレベル1代表サーバを代表する代表サーバを選定する。以降、ここで選定された代表サーバを「レベル2代表サーバ」という。ここでは、このレベル2代表サーバが大代表サーバとなるが、レベルの数は3つに限定されず、調停部103は、大代表サーバが選定されるまで、上述した動作を繰り返す。そして、調停部103は、代表サーバ及び大代表サーバの選定の結果を示す選定結果情報をサービス実行権管理部102へ出力する。なお、調停部103は、メンバ管理部101から出力されるサーバ情報及び代表サーバ情報を用いて他のサーバ10と通信を行う。サーバ情報及び代表サーバ情報については後述する。なお、以降、各レベルにおいて代表サーバに選定されなかったサーバ10のことを非代表サーバという。
【0062】
再度、図2を参照すると、メンバ管理部101は、サーバ情報及び代表サーバ情報を記憶している。また、メンバ管理部101は、サーバ情報や代表サーバ情報の追加及び削除を行う。また、メンバ管理部101は、調停部103等のサーバ10内の各部に、記憶されたサーバ情報及び代表サーバ情報を出力する。
【0063】
図4は、図2に示したメンバ管理部101が記憶するサーバ情報及び代表サーバ情報を説明するための図である。
【0064】
メンバ管理部101は、図4に示したようなツリー構造でサーバ情報及び代表サーバ情報を記憶している。サーバ情報は、サーバ群1〜6のそれぞれを識別する情報と、サーバ群1〜6のそれぞれに属する複数のサーバ10のそれぞれを識別する情報とを含んでいる。サーバ群1〜6のそれぞれを識別する情報としては例えば、GUID(Globally Unique IDentifier)やUUID(Universally Unique IDentifier)がある。また、サーバ群1〜6のそれぞれに属する複数のサーバ10のそれぞれを識別する情報としては例えば、IPアドレス及びポート番号がある。また、代表サーバ情報は、大代表サーバ及び各レベルの代表サーバのサーバ情報と、各代表サーバのレベルと、各代表サーバへ到達するためのリンクを示すリンク情報とを含んでいる。
【0065】
図5は、図2に示したメンバ管理部101が代表サーバ情報を追加及び削除する動作を説明するためのフローチャートである。調停部103がレベルN(N=0,1,2・・・)の代表サーバを選定する場合、レベルNの直下のレベルの代表サーバであるレベル(N−1)の代表サーバの代表サーバ情報が必要となる。そこで、ここでは一例として、メンバ管理部101がレベル(N−1)の代表サーバの代表サーバ情報を追加及び削除する場合について説明する。以降、レベルN(N=0,1,2・・)の代表サーバのことをレベルN代表サーバと表記する。
【0066】
なお、ここでは、レベルN代表サーバになり得る複数のサーバ10から成る集合のことを代表サーバ候補群という。例えば、図3に示した構成において、レベル2代表サーバになり得る代表サーバ候補群は、2つ存在する。1つ目の代表サーバ候補群は、サーバ群1〜3のそれぞれを代表する3つのレベル0代表サーバから成る集合であり、2つ目の代表サーバ候補群は、サーバ群4〜6のそれぞれを代表する3つの代表サーバから成る集合である。
【0067】
まず、メンバ管理部101は、自サーバがレベル(N−1)代表サーバであるかどうかを判定する(ステップS1)。なお、メンバ管理部101は、サービス実行権管理部102から選定結果情報を取得することにより、自サーバがレベル(N−1)代表サーバであるかどうかを判定する。
【0068】
ステップS1における判定の結果、自サーバがレベル(N−1)代表サーバである場合、メンバ管理部101は、自サーバをレベル(N−1)代表サーバとして代表サーバ情報に追加する(ステップS2)。
【0069】
次に、メンバ管理部101は、他の代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に追加されているかどうかを確認する(ステップS3)。
【0070】
ステップS3における判定の結果、他の代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に追加されている場合、メンバ管理部101は、その追加されているレベル(N−1)代表サーバに、レベルN代表サーバの選定を行うための調停要求を送信する(ステップS4)。
【0071】
そして、メンバ管理部101は、送信した調停要求に対する応答を所定の時間内に受信したかどうかを判定する(ステップS5)。
【0072】
ステップS5における判定の結果、送信した調停要求に対する応答を所定の時間内に受信しない場合、調停要求の送信先であるレベル(N−1)代表サーバを、代表サーバ情報から削除する(ステップS6)。
【0073】
そして、メンバ管理部101は、調停要求の送信先であるレベル(N−1)代表サーバを代表サーバ情報から削除する指示を、自サーバをレベル(N−1)代表サーバとするレベル(N−1)の非代表サーバへブロードキャストする(ステップS7)。
【0074】
一方、ステップS3における判定の結果、他の代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に追加されていない場合には、メンバ管理部101は、他の代表サーバ候補群のサーバ10の全てに調停要求を送信する(ステップS8)。
【0075】
そして、メンバ管理部101は、送信した調停要求に対する応答を所定の時間内に受信したかどうかを判定する(ステップS9)。
【0076】
ステップS9における判定の結果、送信した調停要求に対する応答を所定の時間内に受信した場合、応答の送信元であるサーバ10をレベル(N−1)代表サーバとして代表サーバ情報に追加する(ステップS10)。
【0077】
そして、メンバ管理部101は、応答の送信元であるサーバ10をレベル(N−1)代表サーバとして代表サーバ情報に追加する指示を、自サーバをレベル(N−1)代表サーバとするレベル(N−1)の非代表サーバへブロードキャストする(ステップS11)。なお、ステップS3〜S11の動作は繰り返し実行される。
【0078】
このように、自サーバがレベル(N−1)代表サーバである場合、メンバ管理部101は、他の代表サーバ候補群においてレベル(N−1)代表サーバが故障等により存在しないと、他の代表サーバ候補群のサーバ10の全てに調停要求を送信する。そして、この調停要求を受信したサーバ10は、自サーバがレベル(N−1)代表サーバである場合、その調停要求に対する応答を送信する。これにより、調停要求を送信したレベル(N−1)代表サーバのメンバ管理部101は、新たに選定された他のレベル(N−1)代表サーバを認識することができる。
【0079】
ここで、ステップS1における判定の結果、自サーバがレベル(N−1)代表サーバでない場合には、メンバ管理部101は、自代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に記憶されているかどうかを判定する(ステップS12)。
【0080】
ステップS12における判定の結果、自代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に記憶されている場合、メンバ管理部101は、記憶されているレベル(N−1)代表サーバをレベルN代表サーバの候補として代表サーバ情報に追加する(ステップS13)。
【0081】
次に、メンバ管理部101は、自代表サーバ候補群のレベル(N−1)代表サーバから、他の代表サーバ候補群におけるレベル(N−1)代表サーバの追加/削除の指示が送信されてきたかどうかを判定する(ステップS14)。
【0082】
ステップS14における判定の結果、他の代表サーバ候補群におけるレベル(N−1)代表サーバの追加/削除の指示が送信されてきた場合、他の代表サーバ候補群におけるレベル(N−1)代表サーバをレベルN代表サーバの候補として代表サーバ情報に追加/削除する(ステップS15)。
【0083】
このように、自サーバがレベル(N−1)代表サーバでない場合、図4に示したメンバ管理部101に記憶される情報は、自代表サーバ候補群のレベル(N−1)代表サーバによって同期される。
【0084】
再度、図2を参照すると、サービス実行権管理部102は、サービスを提供するサービス実行権を取得するプロセスを担当しており、本実施形態の高可用性システムにおいて、常に1つのサーバ10がサービスを提供するための仕組みを提供する。具体的には、サービス実行権管理部102は、調停部103から出力された選定結果情報を受け付ける。そして、受け付けた選定結果が、自サーバが各レベルにおいて代表サーバに選定されたことを示している場合、そのレベルの非代表サーバへ所定の時間間隔でハートビートを送信する。また、サービス実行権管理部102は、受け付けた選定結果が、自サーバが大代表サーバに選定されたことを示している場合、所定のサービスの提供の開始を許可する許可情報をサービス提供部110へ出力する。また、サービス実行権管理部102は、自サーバが各レベルにおいて非代表サーバである場合、そのレベルの代表サーバから送信されるハートビートを受信する。そして、サービス実行権管理部102は、タイマーを用い、代表サーバから送信されたハートビートを予め決められた時間間隔内に受信したかどうかを判定する。判定の結果、代表サーバから送信されたハートビートを予め決められた時間間隔内に受信しない場合、サービス実行権管理部102は、調停部103に新たな代表サーバの選定を指示する。
【0085】
サービス提供部110は、サービス実行権管理部102から出力された許可情報を受け付けると、所定のサービスの提供を開始する。なお、サービス提供部110は、自サーバが新たに大代表サーバに選定された場合には、記憶部104に記憶され、他のサーバ10から送信されてきた変更情報に基づいて所定のサービスの提供を開始する。
【0086】
以下に、上記のように構成された高可用性システムの動作について説明する。
【0087】
ここでは、図1~図5に示した高可用性システムの動作について、以下の4つに分けて説明する。
【0088】
(1)大代表サーバが選定されるまでの動作
(2)大代表サーバが選定されてからの通常動作
(3)大代表サーバがサービスを提供できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな代表サーバを選定できる場合の動作
(4)大代表サーバがサービスを実行できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな代表サーバを選定できない場合の動作
まず、上記(1)の「大代表サーバが選定されるまでの動作」について説明する。
【0089】
図6は、図1〜図5に示した高可用性システムにおいて、大代表サーバが選定されるまでの動作を説明するためのフローチャートである。
【0090】
調停部103は、メンバ管理部101から出力されたサーバ情報を用い、同じサーバ群に属する他のサーバ10の調停部103と通信を行う。そして、そのサーバ群内において相互に通信を行うことが可能なサーバ10からなるサーバグループである第1のサーバグループを形成する。
【0091】
第1のサーバグループのサーバ数がそのサーバ群のサーバ数の過半数以上である場合、調停部103は、第1のサーバグループの中からレベル0代表サーバを選定する(ステップS21)。
【0092】
次に、調停部103は、自サーバがレベル0代表サーバに選定されたかどうかを判定する(ステップS22)
ステップS22の判定の結果、自サーバがレベル0代表サーバに選定されている場合、調停部103は、メンバ管理部101から出力された代表サーバ情報を用い、他のレベル0代表サーバと通信を行うことにより、レベル1代表サーバを選定する(ステップS23〜S24)。
【0093】
次に、調停部103は、自サーバがレベル1代表サーバに選定されたかどうかを判定する(ステップS25)。
【0094】
ステップS25の判定の結果、自サーバがレベル1代表サーバに選定された場合、調停部103は、代表サーバに選定されたレベルが最上位であるかどうかを判定する(ステップS26)。
【0095】
ステップS26の判定の結果、代表サーバに選定されたレベルが最上位ではない場合、ステップS23の動作へ遷移する。すなわち、調停部103は、レベルを1つ上げ、そのレベルの他の代表サーバと通信を行うことにより、1つ上げたレベルの代表サーバを選定する。
【0096】
調停部103は、大代表サーバに選定されるか、その途中のレベルの代表サーバに選定されなくなるまで、上述した動作を繰り返す。そして、大代表サーバに選定されたサーバ10は、大代表サーバとしての処理を実行する。また、大代表サーバに選定されなかった代表サーバは、代表サーバに選定されたレベルまでは代表サーバとしての処理を実行し、それよりも上のレベルにおいては非代表サーバとしての処理を実行する。
【0097】
図7は、レベルNの非代表サーバの動作を説明するための図である。
【0098】
レベルNの非代表サーバは、レベルN代表サーバには選定されなかったが、レベル0からレベル(N−1)まででは代表サーバに選定されている。従って、レベル0からレベル(N−1)までにおいては、レベル0からレベル(N−1)の非代表サーバへ所定の時間間隔でハートビートを送信する。但し、レベルNにおいては、代表サーバではないため、レベルN代表サーバから送信されたハートビートを受信し、レベルN代表サーバから送信されたハートビートを、予め決められた時間間隔内に受信しない場合、新たなレベルN代表サーバの選定を開始する。なお、レベルNの非代表サーバは、レベル0からレベル(N−1)までの代表サーバとしての処理と、レベルNの非代表サーバとしての処理とを同時に実行する。
【0099】
また、あるレベルの代表サーバにならないと次のレベルの代表サーバになることができない。そのため、あるレベルで代表サーバでなくなった場合、その上のレベルの代表サーバでもなくなる。つまり、図7に示す処理のうちの1つでも終了したら、レベルN非代表サーバとしての処理は終了し、終了したレベルから代表サーバの選定が開始される。
【0100】
図8は、大代表サーバの動作を説明するための図である。
【0101】
図8に示すように、大代表サーバの動作は、図7に示したレベルNの非代表サーバの動作と比べると、全てのレベルにおいて代表サーバとしての処理をする点が異なる。
【0102】
ここで、大代表サーバが選定されるまでの動作を要約する。
【0103】
調停部103は、まず、レベル0代表サーバの選定を開始する。そして、レベル0代表サーバの調停部103は、1つ上のレベルの代表サーバの選定を開始する。そして、いずれか1つのサーバ10が大代表サーバに選定されるまでこれが繰り返される。
【0104】
大代表サーバのサービス実行権管理部102は、サービス提供部110に許可情報を出力する。そして、サービス実行権管理部102から出力された許可情報を受け付けたサービス提供部110は、所定のサービスの提供を開始する。これにより、大代表サーバが属するサーバ群によって高可用性を維持しながら所定のサービスが提供される。例えば、図3に示した構成において、図中最も左のサーバ10が大代表サーバに選定された場合、このサーバ10が属するサーバ群1の3つサーバ10により、高可用性を維持しながら所定のサービスが提供される。
【0105】
次に、上記(2)〜(4)の動作について説明するが、その前に、大代表サーバが選定された後の代表サーバ及び非代表サーバの動作を説明する。
【0106】
まず、大代表サーバが選定された後の代表サーバの動作について説明する。
【0107】
レベルNにおいては、1つの代表サーバと、非代表サーバとが存在している。ここで、代表サーバは、代表サーバであり続けようとする。一方、非代表サーバは、代表サーバから送信されたハートビートを予め決められた時間間隔内に受信しない場合、新たな代表サーバの選定を開始しようとする。
【0108】
本実施形態では、代表サーバは、選定されてから一定時間、代表サーバであることが保障される。そして、その一定時間が経過すると、代表サーバは、ハートビートを送信することにより、自サーバが正常に動作していることを非代表サーバに伝える。これにより、代表サーバは、代表サーバである時間を延長していく。
【0109】
図9は、大代表サーバが選定された後の代表サーバの動作を説明するためのフローチャートである。
【0110】
サービス実行権管理部102は、タイマーを起動させる(ステップS31)。このタイマーは、起動させてから所定の時間が経過すると停止するタイマーである。
【0111】
次に、サービス実行権管理部102は、タイマーが停止したかどうかを判定する(ステップS32)。
【0112】
ステップS32における判定の結果、タイマーが停止していない場合、タイマーが停止したかどうかの判定が繰り返し実行される。
【0113】
一方、ステップS32における判定の結果、タイマーが停止している場合、サービス実行権管理部102は、ハートビートを送信する(ステップS33)。つまり、代表サーバは、所定の時間間隔でハートビートを送信することとなる。
【0114】
そして、サービス実行権管理部102は、代表サーバである時間を延長できたかどうかを判定する(ステップS34)。
【0115】
ステップS34における判定の結果、代表サーバである時間を延長できた場合、ステップS31の動作へ遷移する。
【0116】
一方、ステップS34における判定の結果、代表サーバである時間を延長できなかった場合には、代表サーバは非代表サーバとなり、図6に示したフローチャートの動作に従い、再度代表サーバの選定が開始される。なお、代表サーバである時間を延長できないのは、ハートビートを送信した非代表サーバの過半数がハートビートを受信できない等の理由による。
【0117】
次に、大代表サーバが選定された後の非代表サーバの動作について説明する。
【0118】
図10は、大代表サーバが選定された後の非代表サーバの動作を説明するためのフローチャートである。
【0119】
サービス実行権管理部102は、タイマーを起動させる(ステップS41)。このタイマーは、起動させてから所定の時間が経過すると停止するタイマーである。
【0120】
次に、サービス実行権管理部102は、代表サーバから送信されたハートビートを受信したかどうかを判定する(ステップS42)。
【0121】
ステップS42の判定の結果、代表サーバから送信されたハートビートを受信した場合、サービス実行権管理部102は、ステップS41の動作へ遷移する。この場合、代表サーバは、代表サーバである時間を延長できたこととなる。
【0122】
一方、ステップS42の判定の結果、代表サーバから送信されたハートビートを受信していない場合には、サービス実行権管理部102は、タイマーが停止しているかどうかを判定する(ステップS43)。
【0123】
ステップS43における判定の結果、タイマーが停止していない場合、ステップS42の動作へ遷移する。つまり、サービス実行権管理部102は、代表サーバから送信されたハートビートを受信したかどうかの判定を継続する。
【0124】
一方、ステップS43における判定の結果、タイマーが停止している場合には、サービス実行権管理部102は、代表サーバが故障したとみなし、新たな代表サーバの選定を調停部103に指示する(ステップS44)。そして、図6に示したフローチャートの動作に従い、再度代表サーバの選定が開始される。
【0125】
なお、代表サーバが正常に動作している限り、代表サーバが代表サーバである時間を容易に延長できるように、あるレベルの代表サーバのタイマーが停止するまでの時間は、同じレベルの非代表サーバのタイマーが停止するまでの時間よりも短い。また、上位のレベルほど、タイマーが停止するまでの時間が長い。つまり、タイマーが停止するまでの時間の長さは以下の式(1)及び式(2)によって表される。
【0126】
レベルN代表サーバのタイマーが停止するまでの時間 < レベルNの非代表サーバのタイマーが停止するまでの時間・・・式(1)
レベル(N−1)の非代表サーバのタイマーが停止するまでの時間 < レベルNの非代表サーバのタイマーが停止するまでの時間・・・式(2)
以上を踏まえた上で次に、上記(2)の「大代表サーバが選定されてからの通常動作」について説明する。
【0127】
代表サーバのサービス実行権管理部102は、タイマーが停止すると、ハートビートを送信することにより、代表サーバである時間を延長する。上記の式(1)に示したように通常は、同じレベルにおいては、代表サーバのタイマーの方が非代表サーバのタイマーよりも先に停止する。そのため、代表サーバは、代表サーバである時間を容易に延長できる。これは、どのレベルにおいても同様である。従って、通常は、同じ大代表サーバによってサービスの提供が継続される。
【0128】
次に、上記(3)の「大代表サーバがサービスを提供できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな大代表サーバを選定できる場合の動作」について説明する。ここでは、図3に示した構成の場合において、図中最も左のサーバ10が大代表サーバ(レベル2代表サーバ)であった場合を一例として説明する。
【0129】
大代表サーバが正常に動作しなくなった場合、または、代表サーバである時間を延長できなかった場合、大代表サーバは、大代表サーバでなくなるだけではなく、レベル1及びレベル0代表サーバでもなくなる。つまり、レベル0代表サーバ及びレベル1代表サーバも不在となる。
【0130】
上記の式(2)に示したように、下位のレベルほどタイマーが停止するまでの時間が短い。そのため、まず、サーバ群1に属するサーバ10の調停部103が、サーバ群1を代表する新たなレベル0代表サーバの選定を開始する。具体的には、サーバ群1に属するサーバ10は、相互に通信することが可能なサーバグループである第2のサーバグループを形成する。そして、第2のサーバグループのサーバ数が、サーバ群1のサーバ数の過半数以上である場合、第2のサーバグループのサーバは、第2のサーバグループの中から新たなレベル0代表サーバを選定する。そして、新たにレベル0代表サーバに選定されたサー
バ10はすぐに、レベル1代表サーバ及びレベル2代表サーバの選定を開始する。
【0131】
上記の式(2)に示したように、タイマーが停止するまでの時間は、レベル0が最も短いため、レベル1及びレベル2において代表サーバの選定はまだ開始されていない。そのため、新たにレベル0代表サーバに選定されたサーバ10がレベル1代表サーバ及びレベル2代表サーバになれる。
【0132】
なお、下位のレベルにおいて新たに代表サーバの選定を開始する際、上位レベルの代表サーバに対し、ハートビートを送信する時間間隔の延長を要求するハートビート延長要求を発行する。
【0133】
ハートビート延長要求を受け付けた上位レベルの代表サーバは、タイマーが停止するまでの時間を延長する。これにより、新たにレベル0代表サーバに選定されたサーバ10は、故障等によって正常に動作しない場合を除き、確実にレベル1代表サーバ及びレベル2代表サーバに選定される。なお、ハートビート延長要求によるハートビートを送信する時間の延長は1回限りであり、タイマーが停止した場合には、図6に示したフローチャートの動作に従い、再度代表サーバの選定が開始される。
【0134】
最後に、上記(4)の「大代表サーバがサービスを実行できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな大代表サーバを選定できない場合の動作」について説明する。ここでは、図3に示した構成の場合において、図中最も左のサーバ10が大代表サーバ(レベル2代表サーバ)であった場合を一例として説明する。
【0135】
大代表サーバが正常に動作しなくなった場合、または、代表サーバである時間を延長できなかった場合、大代表サーバは、大代表サーバでなくなるだけではなく、レベル1及びレベル0代表サーバでもなくなる。つまり、レベル0代表サーバ及びレベル1代表サーバも不在となる。これは、上記(3)の場合と同様である。
【0136】
ここでは、図3の図中最も左側のレベル0代表サーバと、左側のレベル1代表サーバが不在となる。この場合、まず、サーバ群1に属する複数のサーバ10の調停部103が、サーバ群1を代表する新たなレベル0代表サーバの選定を開始する。但し、ここでは、ネットワークの障害により、サーバ群1に属するサーバ数の過半数以上を占める第2のサーバグループを形成できず、新たなレベル0代表サーバを選定できなかったものとする。つまり、サーバ群1を代表するレベル0代表サーバが存在しないこととなる。
【0137】
この場合、図3の図中左から2番目のレベル0代表サーバと、3番目のレベル0代表サーバとが通信を行うことにより、いずれかがレベル1代表サーバに選定される。そして、新たにレベル1の代表サーバに選定されたサーバ10はすぐに、レベル2代表サーバの選定を開始する。
【0138】
ここで、上記の式(2)に示したように、タイマーが停止するまでの時間は、レベル2よりもレベル1の方が短い。そのため、レベル2において代表サーバの選定はまだ開始されていない。そのため、新たにレベル1代表サーバになったサーバ10がレベル2代表サーバになれる。
【0139】
上述したように、大代表サーバが属するサーバ群において新たにレベル0代表サーバを選定できない場合、所定のサービスの提供を移動するコストが少ないサーバ群によってサービスの提供が継続される。つまり、サービスを提供することができない時間を最小限にすることができ、高可用性を維持することができる。
【0140】
このように本実施形態においては、サーバ群1〜6のそれぞれに属する複数のサーバ10は、当該サーバ群に属する複数のサーバ10のうち、相互に通信可能なサーバからなる第1のサーバグループを形成する。そして、第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバ10の中から、当該サーバ群を代表する代表サーバを選定する。そして、サーバ群1〜6毎に選定された複数の代表サーバは、その複数の代表サーバの中から、所定のサービスを提供する大代表サーバを選定する。
【0141】
これにより、所定のサービスを提供するサーバ10が複数存在すること、及び、所定のサービスを提供するサーバ10が存在しなくなるのを回避することができる。
【0142】
従って、データの整合性を確保しつつ、高可用性を維持することが可能となる。
【0143】
なお、本発明においては、サーバ内の処理は上述の専用のハードウェアにより実現されるもの以外に、その機能を実現するためのプログラムをサーバにて読取可能な記録媒体に記録し、この記録媒体に記録されたプログラムをサーバに読み込ませ、実行するものであっても良い。サーバにて読取可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、DVD、CDなどの移設可能な記録媒体の他、サーバに内蔵されたHDDなどを指す。
【符号の説明】
【0144】
1〜6 サーバ群
10 サーバ
50 ローカルネットワーク
100 高可用部
101 メンバ管理部
102 サービス実行権管理部
103 調停部
104 記憶部
110 サービス提供部
120 通信部
150 グローバルネットワーク
【技術分野】
【0001】
本発明は、複数のサーバ群によって高可用性を維持する高可用性システム、サーバ、高可用性維持方法及びプログラムに関する。
【背景技術】
【0002】
オンラインショップ等の商用のサービスを提供するシステムにおいては、顧客にサービスを提供しているサーバが故障した場合でも、顧客へのサービスの提供を継続することが求められる。つまり、システムとして継続して稼働できることが重要である。
【0003】
システムが継続して稼働できることを示す指標として可用性がある。可用性は、所定の期間中、何パーセントの時間にシステムが稼働できていたかを示す。従って、商用のサービスを提供するシステムにおいては、高可用性を維持する必要がある。
【0004】
高可用性を維持するための手法としては、予め予備用のサーバを準備しておき、サービスを提供しているサーバが故障した場合、サービスの提供を予備用のサーバに切り替える方式が一般的である。但し、顧客からの要求を処理することにより、サービスを提供しているサーバに記憶された顧客データ等のデータが変化するシステムの場合、予備用のサーバは、サービスを提供しているサーバと同じ状態を維持している必要がある。以降、単にデータという場合には、顧客からの要求を処理することによって変化する顧客データ等のことを指す。
【0005】
これを実現する技術としては例えば、レプリケーション技術がある。レプリケーション技術は一般的に、複数のサーバでデータを共有するための記憶装置が存在しない場合に利用される。
【0006】
レプリケーション技術では、サービスを提供しているサーバに記憶されたデータを複数の予備用のサーバに複製しておく。そして、サービスを提供しているサーバが故障したら、サービスの提供を予備用のサーバに瞬時に切り替える。これにより、サービスの提供を継続することができる。
【0007】
図11は、レプリケーション技術を利用したサーバの構成の一例を示す図である。図11においては、サーバ(M1)がサービスを提供しているサーバである。
【0008】
レプリケーション技術を利用した場合、サーバ(M1)に記憶されたデータが変更されると、サーバ(M1)はサーバ(R1)〜(R3)にその変更内容を通知する。
【0009】
サーバ(M1)からの通知を受けたサーバ(R1)〜(R3)は、それぞれが備える記憶装置に、その変更内容を反映させる。これにより、サーバ(R1)〜(R3)は常に、サーバ(M1)と同じ状態を維持することができる。
【0010】
レプリケーション技術において、高可用性を維持するための重要な仕組みは、サービスを提供しているサーバ(M1)が故障した場合に、その故障を検知し、サービスを提供するサーバをサーバ(R1)〜(R3)の中から新たに選定する仕組みである。
【0011】
サーバ(M1)の故障の検知は、サーバ(M1)がハートビートと呼ばれる信号を所定の時間間隔でサーバ(R1)〜(R3)へ送信し、サーバ(R1)〜(R3)が予め決められた時間間隔内にハートビートを受信できたかどうかによって判断することができる。
【0012】
サーバ(R1)〜(R3)は、予め決められた時間間隔内にサーバ(M1)から送信されたハートビートを受信しなければ、サーバ(M1)が故障したとみなす。この場合、サーバ(R1)〜(R3)の中から、サービスを提供する新たなサーバが選定される。以降、サービスを提供する新たなサーバのことをサーバ(M2)という。
【0013】
サーバ(M2)を選定するための選定方法は例えば、サーバ(R1)〜サーバ(R3)の優先順位を予め決めておき、優先順位の高いサーバから順番に、サーバ(M2)になるようにしておけばよい。
【0014】
しかし、この選定方法を利用した場合、サーバ(M1)とサーバ(R1)〜(R3)とがネットワークで接続されていると、Split−brain問題が発生する可能性がある。以下に、Split−brain問題について説明する。
【0015】
サーバ(M1)とサーバ(R1)〜(R3)とを接続するネットワークに障害が発生した場合、サーバ(M1)が故障していないにも関わらず、サーバ(M1)から送信されたハートビートが、予め決められた時間間隔内にサーバ(R1)〜(R3)にて受信されない場合がある。ここでは一例として、ネットワークの障害により、サーバ(M1)とサーバ(R1)との間、及び、サーバ(R2)とサーバ(R3)との間のみでしか通信を行うことができないと仮定する。
【0016】
この場合、サーバ(R2)及びサーバ(R3)は、サーバM1から送信されたハートビートを予め決められた時間間隔内に受信しない。そのため、サーバ(R2)及びサーバ(R3)は、サーバ(M1)が故障したとみなす。また、サーバ(R2)及びサーバ(R3)は、サーバ(R1)と通信を行うこともできない。従って、サーバ(R2)及びサーバ(R3)の中からサーバ(M2)が選定される。
【0017】
しかし、実際には、サーバ(M1)は故障していないため、サービスを提供しているサーバは、サーバ(M1)とサーバ(M2)との2つになってしまう。
【0018】
図12は、図11に示した構成において、サービスを提供するサーバが新たに選定された場合の一例を説明するための図である。図12では、図11におけるサーバ(R2)がサーバ(M2)に選定された場合を示している。
【0019】
図12に示す例の場合、顧客からの要求は、サーバ(M1)またはサーバ(M2)のいずれかによって処理される。例えば、提供されるサービスが顧客の貯金を管理するサービスであった場合、クライアント端末(C1)が500円を貯金する処理を要求すると、この処理を受け付けたサーバ(M1)においては500円が貯金される。しかし、この処理を受け付けていないサーバ(M2)においては500円が貯金されてないこととなる。つまり、システムとしてデータの整合性がとれていない状態となる。これが、Split−brain問題である。
【0020】
このようなSplit−brain問題を解決するために、相互に通信を行うことが可能なサーバの数が全サーバ数の過半数以上を占めるサーバグループだけがサービスを提供できるようにする方式がある。以降、この方式により、サービスを提供するサーバを選定するアルゴリズムのことを過半数アルゴリズムという、なお、過半数アルゴリズムの1つであるPAXOSアルゴリズムが例えば、非特許文献1に開示されている。
【0021】
この方式では、サービスを提供しているサーバから送信されたハートビートが予め決められた時間間隔内に受信されない場合、他のサーバ間で通信を行うことにより、サーバグループを形成する。そして、相互に通信を行うことが可能なサーバ数が全サーバ数の過半数以上を占めるサーバグループの中から、サービスを提供する新たなサーバが選定される。
このような高可用性システムが例えば、非特許文献2に開示されている。
【0022】
図13は、過半数アルゴリズムによってサービスを提供するサーバが選定される構成の一例を説明するための図である。
【0023】
図13に示すように、相互に通信を行うことが可能なサーバ数が全サーバ数の過半数以上を占めるサーバグループは1つしか存在しない。従って、上述したSplit−brain問題を回避することができる。
【0024】
ここで、レプリケーション技術を用いた場合、データを複製するサーバの数が多ければ多いほど、高可用性を維持することができる。しかし、この場合、データの複製にかかるコストによって性能が低下してしまう場合がある。
【0025】
つまり、高可用性を維持する場合、性能とのバランスが重要になる。一般的には、相互に高速な通信が可能な複数のサーバを用いることによって性能の低下を回避するようにしている。しかし、相互に高速な通信が可能なサーバ数は限られており、例えばサーバが故障している間は可用性の低下が回避できない。
【0026】
また、相互に高速な通信が可能な複数のサーバは、同じネットワーク装置に接続されていることが多い。そのため、これら複数のサーバには、ネットワーク障害の影響が同時に及ぶ確率が高い。
【0027】
一方、物理的に離れた場所に設置されている複数のサーバ間の通信速度は、同じネットワーク装置に接続された複数のサーバ間の通信速度に比べて遅くなる。そのため、物理的に離れた場所に設置されている複数のサーバを用いた場合、性能の低下を回避することが難しくなる。
【0028】
これを解決するための方法として、相互に高速な通信が可能な複数のサーバからなるサーバ群を複数準備しておく方法が検討されている。
【0029】
図14は、複数のサーバ群を有する高可用性システムの構成の一例を説明するための図である。
【0030】
図14に示す例では通常、複数のサーバ群のいずれかに属する複数のサーバのいずれかによってサービスを提供する。1つのサーバ群に属する複数のサーバ間の通信速度は、例えば1Gbps(Giga bit per second)のように高速であり、性能の低下を回避しつつ、高可用性を維持できる。そして、そのサーバ群によってサービスの提供ができない場合にのみ、他のサーバ群のいずれかがサービスの提供を継続する。例えば、図14においてサービスを提供しているサーバ群がサーバ群Aであった場合、サーバ群Aによってサービスの提供ができなくなると、サーバ群Bがサービスの提供を継続する。
【先行技術文献】
【非特許文献】
【0031】
【非特許文献1】Paxos Made Simple, Leslie Lamport. Appears in ACM SIGACT News (Distributed Computing Column), Vol. 32, No. 4 (December 2001), pages 51-58.
【非特許文献2】"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.
【発明の概要】
【発明が解決しようとする課題】
【0032】
図13を参照して説明したような過半数アルゴリズムと、図14を参照して説明した高可用性システムとを組み合わせれば、データの整合性を確保しつつ、高可用性を維持することが可能なようにも思える。
【0033】
図15は、過半数アルゴリズムと高可用性システムとを組み合わせた場合の一例を説明するための図である。
【0034】
図15においては、サーバ群Aには、サーバ群Aに属するサーバ数の過半数以上のサーバからなるサーバグループが存在する。この場合、PAXOSアルゴリズム等の過半数アルゴリズムでは、そのサーバグループは、サービスの提供をサーバ群Bに移動させずに、自サーバグループでサービスを提供する。一方、サーバ群Aに属するサーバ数の過半数未満のサーバからなるサーバグループは、自サーバグループでサービスの提供が行えない。そのため、このサーバグループは、サービスの提供をサーバ群Bに移動させてしまう。この場合、サービスを提供するサーバが2つ存在することになってしまい、上述したSplit−brain問題が発生する。つまり、データの整合性を確保できなくなってしまうという問題点がある。
【0035】
図16は、過半数アルゴリズムと高可用性システムとを組み合わせた場合の他の例を説明するための図である。
【0036】
図16においては、サーバ群Aには、サーバ群Aに属するサーバ数の過半数以上のサーバからなるサーバグループが存在しない。この場合、PAXOSアルゴリズム等の過半数アルゴリズムでは、サーバ群Aのいずれのサーバグループもサービスを提供することができない。また、Split−brain問題を回避するために、サーバ群Aのいずれのサーバグループも、サービスの提供をサーバ群Bに移動させないと、サーバ群A及びサーバ群Bのいずれによってもサービスが提供されなくなる。つまり、サービスを提供するサーバが存在しなくなり、高可用性が維持できなくなってしまうという問題点がある。
【0037】
本発明は、データの整合性を確保しつつ、高可用性を維持することを可能にする高可用性システム、サーバ、高可用性維持方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【0038】
上記目的を達成するために本発明の高可用性システムは、相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムであって、
前記複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成し、
前記第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定し、
前記複数のサーバ群毎に選定された複数の代表サーバは、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する。
【0039】
また、上記目的を達成するために本発明のサーバは、相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバであって、
前記所定のサービスを提供するサービス提供部と、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第1のサーバグループを形成し、該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループの他のサーバと通信を行うことにより、当該第1のサーバグループの中から、当該サーバ群を代表する代表サーバを選定し、自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定し、自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供の開始を許可する許可情報を出力する高可用部と、を有し、
前記サービス提供部は、前記高可用部から出力された許可情報を受け付けると、前記所定のサービスの提供を開始する。
【0040】
また、上記目的を達成するために本発明の高可用性維持方法は、相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムにおける高可用性維持方法であって、
前記複数のサーバ群のそれぞれに属する複数のサーバが、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成する処理と、
前記第1のサーバグループのサーバが、当該第1のサーバグループのサーバ数が当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定する処理と、
前記複数のサーバ群毎に選定された複数の代表サーバが、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する処理と、を有する。
【0041】
また、上記目的を達成するために本発明のプログラムは、相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバに、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第1のサーバグループを形成する機能と、
前記第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループの他のサーバと通信を行うことにより、当該第1のサーバグループの中から、当該サーバ群を代表する代表サーバを選定する機能と、
自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する機能と、
自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供を開始する機能と、を実現させる。
【発明の効果】
【0042】
本発明によれば、複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成する。そして、第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定する。そして、複数のサーバ群毎に選定された複数の代表サーバは、その複数の代表サーバの中から、所定のサービスを提供する大代表サーバを選定する。
【0043】
これにより、所定のサービスを提供するサーバが複数存在すること、及び、所定のサービスを提供するサーバが存在しなくなるのを回避することができる。
【0044】
従って、データの整合性を確保しつつ、高可用性を維持することが可能となる。
【図面の簡単な説明】
【0045】
【図1】本発明の高可用性システムの実施の一形態の構成を示すブロック図である。
【図2】図1に示したサーバの構成の一例を示すブロック図である。
【図3】図2に示した調停部の動作を説明するための図である。
【図4】図2に示したメンバ管理部が記憶するサーバ情報及び代表サーバ情報を説明するための図である。
【図5】図2に示したメンバ管理部が代表サーバ情報を追加及び削除する動作を説明するためのフローチャートである。
【図6】図1〜図5に示した高可用性システムにおいて、大代表サーバが選定されるまでの動作を説明するためのフローチャートである。
【図7】レベルNの非代表サーバの動作を説明するための図である。
【図8】大代表サーバの動作を説明するための図である。
【図9】大代表サーバが選定された後の代表サーバの動作を説明するためのフローチャートである。
【図10】大代表サーバが選定された後の非代表サーバの動作を説明するためのフローチャートである。
【図11】レプリケーション技術を利用したサーバの構成の一例を示す図である。
【図12】図11に示した構成において、サービスを提供するサーバが新たに選定された場合の一例を説明するための図である。
【図13】過半数アルゴリズムによってサービスを提供するサーバが選定される構成の一例を説明するための図である。
【図14】複数のサーバ群を有する高可用性システムの構成の一例を説明するための図である。
【図15】過半数アルゴリズムと高可用性システムとを組み合わせた場合の一例を説明するための図である。
【図16】過半数アルゴリズムと高可用性システムとを組み合わせた場合の他の例を説明するための図である。
【発明を実施するための形態】
【0046】
以下に、本発明の実施の形態について図面を参照して説明する。
【0047】
図1は、本発明の高可用性システムの実施の一形態の構成を示すブロック図である。
【0048】
本実施形態の高可用性システムは図1に示すように、3つのサーバ10が属するサーバ群1〜6を備えている。なお、サーバ群1〜6は、階層化された構成にすることも可能である。例えば、サーバ群1〜6を1つのサーバ群とした巨大なサーバ群同士がネットワークで接続され、相互にデータの送受信ができる構成もありえる。この場合、サーバ群の階層数に制限はない。また、サーバ群の数は6つに限定されない。また、サーバ群1〜6に属するサーバの数は3つに限定されない。
【0049】
また、複数のサーバ10間でデータを送受信する際の通信速度は、スイッチやルータの配置のようなネットワークの構成や物理的距離によって異なる。ここでは、所定の通信速度以上の通信速度で相互に通信を行える3つのサーバ10が1つのサーバ群に属している。
【0050】
サーバ10は、本実施形態の高可用性システムと接続されたクライアント端末等に所定のサービスを提供する。サーバ10は例えば、メインフレームやパーソナルコンピュータ、携帯電話等である。また、サーバ10は、ネットワーク構成装置(不図示)等を用いたローカルネットワーク50に接続され、自サーバと同じサーバ群に属する他のサーバ10と相互に通信を行うことによってデータを送受信する。ローカルネットワーク50は、ネットワーク構成装置(不図示)等を用いたグローバルネットワーク150と接続されている。サーバ10は、ローカルネットワーク50及びグローバルネットワーク150を介し、自サーバと異なるサーバ群に属する他のサーバ10と相互に通信を行うことによってデータを送受信する。
【0051】
なお、ローカルネットワーク50及びグローバルネットワーク150の通信媒体や通信規格は、複数のサーバ10の間で相互に通信を行うことが可能であれば、どのようなものでもよい。例えば、インターネットやTCP/IP(Transmission Control Protocol/Internet Protocol)、無線ネットワーク等が挙げられる。
【0052】
本実施形態の高可用性システムでは、サーバ群1〜6のそれぞれにおいて、相互に通信することが可能なサーバ10からなるサーバグループを形成する。そして、そのサーバグループのサーバ数がそのサーバ群に属するサーバ数の過半数以上である場合、そのサーバグループの中から、そのサーバ群を代表する代表サーバが選定される。これは例えば、PAXOSアルゴリズムを用いることによって実現できる。そして、サーバ群1〜6毎に選定された複数の代表サーバの中から、所定のサービスを提供する大代表サーバが選定される。
【0053】
大代表サーバがサービスを提供している間、顧客からの要求を処理することにより、大代表サーバに記憶されたデータが変更されると、大代表サーバはその変更内容を示す変更情報を他のサーバ10へ送信する。変更情報を受信した他のサーバ10は、それぞれが備える記憶部にその変更情報を記憶させる。これにより、他のサーバ10は常に、大代表サーバと同じ状態を維持することができる。これは例えば、レプリケーション技術を用いることによって実現できる。
【0054】
大代表サーバが故障等により、サービスを提供できなくなると、新たに大代表サーバが選定され、新たに選定された大代表サーバがサービスの提供を継続する。なお、サーバの故障は、ハートビートと呼ばれる信号をサーバ10間で送受信することによって検知される。具体的には、あるサーバ10から送信されたハートビートを、他のサーバ10が予め決められた時間間隔内に受信しない場合、ハートビートを送信しているサーバ10は故障したとみなされる。
【0055】
なお、上述した変更情報の伝送方式としては例えば、通常は大代表サーバと同じサーバ群に属するサーバ10だけに伝送し、その大代表サーバが属するサーバ群以外から新たに大代表サーバが選定された場合には、新たに選定された大代表サーバに、それまでの差分を伝送する方式を利用できる。但し、これは、運用時の負荷を考慮した伝送方式の一例であり、変更情報の伝送方式によっては本発明の適用範囲は制限されない。
【0056】
図2は、図1に示したサーバ10の構成の一例を示すブロック図である。
【0057】
図1に示したサーバ10は図2に示すように、高可用部100と、サービス提供部110と、高可用部100及びサービス提供部110とローカルネットワーク50との間の通信を仲介する通信部120とを備えている。
【0058】
高可用部100は、メンバ管理部101と、サービス実行権管理部102と、調停部103と、記憶部104とを備えている。
【0059】
記憶部104は例えば、データを記憶するハードディスクやメモリ等であり、他のサーバ10から送信されてきた変更情報を記憶する。記憶部104に記憶されたデータは記憶部104の外部からの読み書きが可能である。なお、本実施形態においては、記憶部104が複数のサーバ10によって共有されないことを前提とするが、記憶部104が複数のサーバ10によって共有されていてもよい。
【0060】
図3は、図2に示した調停部103の動作を説明するための図である。
【0061】
調停部103は、自サーバと同じサーバ群に属する他のサーバ10の調停部103と通信を行うことにより、相互に通信を行うことが可能なサーバ10からなる第1のサーバグループを形成する。そして、第1のサーバグループのサーバ数がそのサーバ群のサーバ数の過半数以上である場合、調停部103は、第1のサーバグループの他のサーバ10の調停部103と通信を行うことにより、第1のサーバグループの中から、そのサーバ群を代表する代表サーバを選定する。以降、ここで選定された代表サーバを「レベル0代表サーバ」という。本実施形態においては、サーバ群が6つ存在する。そのため、図3に示すように6つのレベル0代表サーバが選定され得る。そして、レベル0代表サーバの調停部103は、他のサーバ群においてレベル0代表サーバに選定されたサーバ10の調停部103と通信を行うことにより、複数のレベル0代表サーバを代表する代表サーバを選定する。ここで選定された代表サーバを「レベル1代表サーバ」という。さらに、レベル1代表サーバの調停部103は、他のレベル1代表サーバの調停部103と通信を行うことにより、複数のレベル1代表サーバを代表する代表サーバを選定する。以降、ここで選定された代表サーバを「レベル2代表サーバ」という。ここでは、このレベル2代表サーバが大代表サーバとなるが、レベルの数は3つに限定されず、調停部103は、大代表サーバが選定されるまで、上述した動作を繰り返す。そして、調停部103は、代表サーバ及び大代表サーバの選定の結果を示す選定結果情報をサービス実行権管理部102へ出力する。なお、調停部103は、メンバ管理部101から出力されるサーバ情報及び代表サーバ情報を用いて他のサーバ10と通信を行う。サーバ情報及び代表サーバ情報については後述する。なお、以降、各レベルにおいて代表サーバに選定されなかったサーバ10のことを非代表サーバという。
【0062】
再度、図2を参照すると、メンバ管理部101は、サーバ情報及び代表サーバ情報を記憶している。また、メンバ管理部101は、サーバ情報や代表サーバ情報の追加及び削除を行う。また、メンバ管理部101は、調停部103等のサーバ10内の各部に、記憶されたサーバ情報及び代表サーバ情報を出力する。
【0063】
図4は、図2に示したメンバ管理部101が記憶するサーバ情報及び代表サーバ情報を説明するための図である。
【0064】
メンバ管理部101は、図4に示したようなツリー構造でサーバ情報及び代表サーバ情報を記憶している。サーバ情報は、サーバ群1〜6のそれぞれを識別する情報と、サーバ群1〜6のそれぞれに属する複数のサーバ10のそれぞれを識別する情報とを含んでいる。サーバ群1〜6のそれぞれを識別する情報としては例えば、GUID(Globally Unique IDentifier)やUUID(Universally Unique IDentifier)がある。また、サーバ群1〜6のそれぞれに属する複数のサーバ10のそれぞれを識別する情報としては例えば、IPアドレス及びポート番号がある。また、代表サーバ情報は、大代表サーバ及び各レベルの代表サーバのサーバ情報と、各代表サーバのレベルと、各代表サーバへ到達するためのリンクを示すリンク情報とを含んでいる。
【0065】
図5は、図2に示したメンバ管理部101が代表サーバ情報を追加及び削除する動作を説明するためのフローチャートである。調停部103がレベルN(N=0,1,2・・・)の代表サーバを選定する場合、レベルNの直下のレベルの代表サーバであるレベル(N−1)の代表サーバの代表サーバ情報が必要となる。そこで、ここでは一例として、メンバ管理部101がレベル(N−1)の代表サーバの代表サーバ情報を追加及び削除する場合について説明する。以降、レベルN(N=0,1,2・・)の代表サーバのことをレベルN代表サーバと表記する。
【0066】
なお、ここでは、レベルN代表サーバになり得る複数のサーバ10から成る集合のことを代表サーバ候補群という。例えば、図3に示した構成において、レベル2代表サーバになり得る代表サーバ候補群は、2つ存在する。1つ目の代表サーバ候補群は、サーバ群1〜3のそれぞれを代表する3つのレベル0代表サーバから成る集合であり、2つ目の代表サーバ候補群は、サーバ群4〜6のそれぞれを代表する3つの代表サーバから成る集合である。
【0067】
まず、メンバ管理部101は、自サーバがレベル(N−1)代表サーバであるかどうかを判定する(ステップS1)。なお、メンバ管理部101は、サービス実行権管理部102から選定結果情報を取得することにより、自サーバがレベル(N−1)代表サーバであるかどうかを判定する。
【0068】
ステップS1における判定の結果、自サーバがレベル(N−1)代表サーバである場合、メンバ管理部101は、自サーバをレベル(N−1)代表サーバとして代表サーバ情報に追加する(ステップS2)。
【0069】
次に、メンバ管理部101は、他の代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に追加されているかどうかを確認する(ステップS3)。
【0070】
ステップS3における判定の結果、他の代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に追加されている場合、メンバ管理部101は、その追加されているレベル(N−1)代表サーバに、レベルN代表サーバの選定を行うための調停要求を送信する(ステップS4)。
【0071】
そして、メンバ管理部101は、送信した調停要求に対する応答を所定の時間内に受信したかどうかを判定する(ステップS5)。
【0072】
ステップS5における判定の結果、送信した調停要求に対する応答を所定の時間内に受信しない場合、調停要求の送信先であるレベル(N−1)代表サーバを、代表サーバ情報から削除する(ステップS6)。
【0073】
そして、メンバ管理部101は、調停要求の送信先であるレベル(N−1)代表サーバを代表サーバ情報から削除する指示を、自サーバをレベル(N−1)代表サーバとするレベル(N−1)の非代表サーバへブロードキャストする(ステップS7)。
【0074】
一方、ステップS3における判定の結果、他の代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に追加されていない場合には、メンバ管理部101は、他の代表サーバ候補群のサーバ10の全てに調停要求を送信する(ステップS8)。
【0075】
そして、メンバ管理部101は、送信した調停要求に対する応答を所定の時間内に受信したかどうかを判定する(ステップS9)。
【0076】
ステップS9における判定の結果、送信した調停要求に対する応答を所定の時間内に受信した場合、応答の送信元であるサーバ10をレベル(N−1)代表サーバとして代表サーバ情報に追加する(ステップS10)。
【0077】
そして、メンバ管理部101は、応答の送信元であるサーバ10をレベル(N−1)代表サーバとして代表サーバ情報に追加する指示を、自サーバをレベル(N−1)代表サーバとするレベル(N−1)の非代表サーバへブロードキャストする(ステップS11)。なお、ステップS3〜S11の動作は繰り返し実行される。
【0078】
このように、自サーバがレベル(N−1)代表サーバである場合、メンバ管理部101は、他の代表サーバ候補群においてレベル(N−1)代表サーバが故障等により存在しないと、他の代表サーバ候補群のサーバ10の全てに調停要求を送信する。そして、この調停要求を受信したサーバ10は、自サーバがレベル(N−1)代表サーバである場合、その調停要求に対する応答を送信する。これにより、調停要求を送信したレベル(N−1)代表サーバのメンバ管理部101は、新たに選定された他のレベル(N−1)代表サーバを認識することができる。
【0079】
ここで、ステップS1における判定の結果、自サーバがレベル(N−1)代表サーバでない場合には、メンバ管理部101は、自代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に記憶されているかどうかを判定する(ステップS12)。
【0080】
ステップS12における判定の結果、自代表サーバ候補群におけるレベル(N−1)代表サーバが代表サーバ情報に記憶されている場合、メンバ管理部101は、記憶されているレベル(N−1)代表サーバをレベルN代表サーバの候補として代表サーバ情報に追加する(ステップS13)。
【0081】
次に、メンバ管理部101は、自代表サーバ候補群のレベル(N−1)代表サーバから、他の代表サーバ候補群におけるレベル(N−1)代表サーバの追加/削除の指示が送信されてきたかどうかを判定する(ステップS14)。
【0082】
ステップS14における判定の結果、他の代表サーバ候補群におけるレベル(N−1)代表サーバの追加/削除の指示が送信されてきた場合、他の代表サーバ候補群におけるレベル(N−1)代表サーバをレベルN代表サーバの候補として代表サーバ情報に追加/削除する(ステップS15)。
【0083】
このように、自サーバがレベル(N−1)代表サーバでない場合、図4に示したメンバ管理部101に記憶される情報は、自代表サーバ候補群のレベル(N−1)代表サーバによって同期される。
【0084】
再度、図2を参照すると、サービス実行権管理部102は、サービスを提供するサービス実行権を取得するプロセスを担当しており、本実施形態の高可用性システムにおいて、常に1つのサーバ10がサービスを提供するための仕組みを提供する。具体的には、サービス実行権管理部102は、調停部103から出力された選定結果情報を受け付ける。そして、受け付けた選定結果が、自サーバが各レベルにおいて代表サーバに選定されたことを示している場合、そのレベルの非代表サーバへ所定の時間間隔でハートビートを送信する。また、サービス実行権管理部102は、受け付けた選定結果が、自サーバが大代表サーバに選定されたことを示している場合、所定のサービスの提供の開始を許可する許可情報をサービス提供部110へ出力する。また、サービス実行権管理部102は、自サーバが各レベルにおいて非代表サーバである場合、そのレベルの代表サーバから送信されるハートビートを受信する。そして、サービス実行権管理部102は、タイマーを用い、代表サーバから送信されたハートビートを予め決められた時間間隔内に受信したかどうかを判定する。判定の結果、代表サーバから送信されたハートビートを予め決められた時間間隔内に受信しない場合、サービス実行権管理部102は、調停部103に新たな代表サーバの選定を指示する。
【0085】
サービス提供部110は、サービス実行権管理部102から出力された許可情報を受け付けると、所定のサービスの提供を開始する。なお、サービス提供部110は、自サーバが新たに大代表サーバに選定された場合には、記憶部104に記憶され、他のサーバ10から送信されてきた変更情報に基づいて所定のサービスの提供を開始する。
【0086】
以下に、上記のように構成された高可用性システムの動作について説明する。
【0087】
ここでは、図1~図5に示した高可用性システムの動作について、以下の4つに分けて説明する。
【0088】
(1)大代表サーバが選定されるまでの動作
(2)大代表サーバが選定されてからの通常動作
(3)大代表サーバがサービスを提供できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな代表サーバを選定できる場合の動作
(4)大代表サーバがサービスを実行できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな代表サーバを選定できない場合の動作
まず、上記(1)の「大代表サーバが選定されるまでの動作」について説明する。
【0089】
図6は、図1〜図5に示した高可用性システムにおいて、大代表サーバが選定されるまでの動作を説明するためのフローチャートである。
【0090】
調停部103は、メンバ管理部101から出力されたサーバ情報を用い、同じサーバ群に属する他のサーバ10の調停部103と通信を行う。そして、そのサーバ群内において相互に通信を行うことが可能なサーバ10からなるサーバグループである第1のサーバグループを形成する。
【0091】
第1のサーバグループのサーバ数がそのサーバ群のサーバ数の過半数以上である場合、調停部103は、第1のサーバグループの中からレベル0代表サーバを選定する(ステップS21)。
【0092】
次に、調停部103は、自サーバがレベル0代表サーバに選定されたかどうかを判定する(ステップS22)
ステップS22の判定の結果、自サーバがレベル0代表サーバに選定されている場合、調停部103は、メンバ管理部101から出力された代表サーバ情報を用い、他のレベル0代表サーバと通信を行うことにより、レベル1代表サーバを選定する(ステップS23〜S24)。
【0093】
次に、調停部103は、自サーバがレベル1代表サーバに選定されたかどうかを判定する(ステップS25)。
【0094】
ステップS25の判定の結果、自サーバがレベル1代表サーバに選定された場合、調停部103は、代表サーバに選定されたレベルが最上位であるかどうかを判定する(ステップS26)。
【0095】
ステップS26の判定の結果、代表サーバに選定されたレベルが最上位ではない場合、ステップS23の動作へ遷移する。すなわち、調停部103は、レベルを1つ上げ、そのレベルの他の代表サーバと通信を行うことにより、1つ上げたレベルの代表サーバを選定する。
【0096】
調停部103は、大代表サーバに選定されるか、その途中のレベルの代表サーバに選定されなくなるまで、上述した動作を繰り返す。そして、大代表サーバに選定されたサーバ10は、大代表サーバとしての処理を実行する。また、大代表サーバに選定されなかった代表サーバは、代表サーバに選定されたレベルまでは代表サーバとしての処理を実行し、それよりも上のレベルにおいては非代表サーバとしての処理を実行する。
【0097】
図7は、レベルNの非代表サーバの動作を説明するための図である。
【0098】
レベルNの非代表サーバは、レベルN代表サーバには選定されなかったが、レベル0からレベル(N−1)まででは代表サーバに選定されている。従って、レベル0からレベル(N−1)までにおいては、レベル0からレベル(N−1)の非代表サーバへ所定の時間間隔でハートビートを送信する。但し、レベルNにおいては、代表サーバではないため、レベルN代表サーバから送信されたハートビートを受信し、レベルN代表サーバから送信されたハートビートを、予め決められた時間間隔内に受信しない場合、新たなレベルN代表サーバの選定を開始する。なお、レベルNの非代表サーバは、レベル0からレベル(N−1)までの代表サーバとしての処理と、レベルNの非代表サーバとしての処理とを同時に実行する。
【0099】
また、あるレベルの代表サーバにならないと次のレベルの代表サーバになることができない。そのため、あるレベルで代表サーバでなくなった場合、その上のレベルの代表サーバでもなくなる。つまり、図7に示す処理のうちの1つでも終了したら、レベルN非代表サーバとしての処理は終了し、終了したレベルから代表サーバの選定が開始される。
【0100】
図8は、大代表サーバの動作を説明するための図である。
【0101】
図8に示すように、大代表サーバの動作は、図7に示したレベルNの非代表サーバの動作と比べると、全てのレベルにおいて代表サーバとしての処理をする点が異なる。
【0102】
ここで、大代表サーバが選定されるまでの動作を要約する。
【0103】
調停部103は、まず、レベル0代表サーバの選定を開始する。そして、レベル0代表サーバの調停部103は、1つ上のレベルの代表サーバの選定を開始する。そして、いずれか1つのサーバ10が大代表サーバに選定されるまでこれが繰り返される。
【0104】
大代表サーバのサービス実行権管理部102は、サービス提供部110に許可情報を出力する。そして、サービス実行権管理部102から出力された許可情報を受け付けたサービス提供部110は、所定のサービスの提供を開始する。これにより、大代表サーバが属するサーバ群によって高可用性を維持しながら所定のサービスが提供される。例えば、図3に示した構成において、図中最も左のサーバ10が大代表サーバに選定された場合、このサーバ10が属するサーバ群1の3つサーバ10により、高可用性を維持しながら所定のサービスが提供される。
【0105】
次に、上記(2)〜(4)の動作について説明するが、その前に、大代表サーバが選定された後の代表サーバ及び非代表サーバの動作を説明する。
【0106】
まず、大代表サーバが選定された後の代表サーバの動作について説明する。
【0107】
レベルNにおいては、1つの代表サーバと、非代表サーバとが存在している。ここで、代表サーバは、代表サーバであり続けようとする。一方、非代表サーバは、代表サーバから送信されたハートビートを予め決められた時間間隔内に受信しない場合、新たな代表サーバの選定を開始しようとする。
【0108】
本実施形態では、代表サーバは、選定されてから一定時間、代表サーバであることが保障される。そして、その一定時間が経過すると、代表サーバは、ハートビートを送信することにより、自サーバが正常に動作していることを非代表サーバに伝える。これにより、代表サーバは、代表サーバである時間を延長していく。
【0109】
図9は、大代表サーバが選定された後の代表サーバの動作を説明するためのフローチャートである。
【0110】
サービス実行権管理部102は、タイマーを起動させる(ステップS31)。このタイマーは、起動させてから所定の時間が経過すると停止するタイマーである。
【0111】
次に、サービス実行権管理部102は、タイマーが停止したかどうかを判定する(ステップS32)。
【0112】
ステップS32における判定の結果、タイマーが停止していない場合、タイマーが停止したかどうかの判定が繰り返し実行される。
【0113】
一方、ステップS32における判定の結果、タイマーが停止している場合、サービス実行権管理部102は、ハートビートを送信する(ステップS33)。つまり、代表サーバは、所定の時間間隔でハートビートを送信することとなる。
【0114】
そして、サービス実行権管理部102は、代表サーバである時間を延長できたかどうかを判定する(ステップS34)。
【0115】
ステップS34における判定の結果、代表サーバである時間を延長できた場合、ステップS31の動作へ遷移する。
【0116】
一方、ステップS34における判定の結果、代表サーバである時間を延長できなかった場合には、代表サーバは非代表サーバとなり、図6に示したフローチャートの動作に従い、再度代表サーバの選定が開始される。なお、代表サーバである時間を延長できないのは、ハートビートを送信した非代表サーバの過半数がハートビートを受信できない等の理由による。
【0117】
次に、大代表サーバが選定された後の非代表サーバの動作について説明する。
【0118】
図10は、大代表サーバが選定された後の非代表サーバの動作を説明するためのフローチャートである。
【0119】
サービス実行権管理部102は、タイマーを起動させる(ステップS41)。このタイマーは、起動させてから所定の時間が経過すると停止するタイマーである。
【0120】
次に、サービス実行権管理部102は、代表サーバから送信されたハートビートを受信したかどうかを判定する(ステップS42)。
【0121】
ステップS42の判定の結果、代表サーバから送信されたハートビートを受信した場合、サービス実行権管理部102は、ステップS41の動作へ遷移する。この場合、代表サーバは、代表サーバである時間を延長できたこととなる。
【0122】
一方、ステップS42の判定の結果、代表サーバから送信されたハートビートを受信していない場合には、サービス実行権管理部102は、タイマーが停止しているかどうかを判定する(ステップS43)。
【0123】
ステップS43における判定の結果、タイマーが停止していない場合、ステップS42の動作へ遷移する。つまり、サービス実行権管理部102は、代表サーバから送信されたハートビートを受信したかどうかの判定を継続する。
【0124】
一方、ステップS43における判定の結果、タイマーが停止している場合には、サービス実行権管理部102は、代表サーバが故障したとみなし、新たな代表サーバの選定を調停部103に指示する(ステップS44)。そして、図6に示したフローチャートの動作に従い、再度代表サーバの選定が開始される。
【0125】
なお、代表サーバが正常に動作している限り、代表サーバが代表サーバである時間を容易に延長できるように、あるレベルの代表サーバのタイマーが停止するまでの時間は、同じレベルの非代表サーバのタイマーが停止するまでの時間よりも短い。また、上位のレベルほど、タイマーが停止するまでの時間が長い。つまり、タイマーが停止するまでの時間の長さは以下の式(1)及び式(2)によって表される。
【0126】
レベルN代表サーバのタイマーが停止するまでの時間 < レベルNの非代表サーバのタイマーが停止するまでの時間・・・式(1)
レベル(N−1)の非代表サーバのタイマーが停止するまでの時間 < レベルNの非代表サーバのタイマーが停止するまでの時間・・・式(2)
以上を踏まえた上で次に、上記(2)の「大代表サーバが選定されてからの通常動作」について説明する。
【0127】
代表サーバのサービス実行権管理部102は、タイマーが停止すると、ハートビートを送信することにより、代表サーバである時間を延長する。上記の式(1)に示したように通常は、同じレベルにおいては、代表サーバのタイマーの方が非代表サーバのタイマーよりも先に停止する。そのため、代表サーバは、代表サーバである時間を容易に延長できる。これは、どのレベルにおいても同様である。従って、通常は、同じ大代表サーバによってサービスの提供が継続される。
【0128】
次に、上記(3)の「大代表サーバがサービスを提供できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな大代表サーバを選定できる場合の動作」について説明する。ここでは、図3に示した構成の場合において、図中最も左のサーバ10が大代表サーバ(レベル2代表サーバ)であった場合を一例として説明する。
【0129】
大代表サーバが正常に動作しなくなった場合、または、代表サーバである時間を延長できなかった場合、大代表サーバは、大代表サーバでなくなるだけではなく、レベル1及びレベル0代表サーバでもなくなる。つまり、レベル0代表サーバ及びレベル1代表サーバも不在となる。
【0130】
上記の式(2)に示したように、下位のレベルほどタイマーが停止するまでの時間が短い。そのため、まず、サーバ群1に属するサーバ10の調停部103が、サーバ群1を代表する新たなレベル0代表サーバの選定を開始する。具体的には、サーバ群1に属するサーバ10は、相互に通信することが可能なサーバグループである第2のサーバグループを形成する。そして、第2のサーバグループのサーバ数が、サーバ群1のサーバ数の過半数以上である場合、第2のサーバグループのサーバは、第2のサーバグループの中から新たなレベル0代表サーバを選定する。そして、新たにレベル0代表サーバに選定されたサー
バ10はすぐに、レベル1代表サーバ及びレベル2代表サーバの選定を開始する。
【0131】
上記の式(2)に示したように、タイマーが停止するまでの時間は、レベル0が最も短いため、レベル1及びレベル2において代表サーバの選定はまだ開始されていない。そのため、新たにレベル0代表サーバに選定されたサーバ10がレベル1代表サーバ及びレベル2代表サーバになれる。
【0132】
なお、下位のレベルにおいて新たに代表サーバの選定を開始する際、上位レベルの代表サーバに対し、ハートビートを送信する時間間隔の延長を要求するハートビート延長要求を発行する。
【0133】
ハートビート延長要求を受け付けた上位レベルの代表サーバは、タイマーが停止するまでの時間を延長する。これにより、新たにレベル0代表サーバに選定されたサーバ10は、故障等によって正常に動作しない場合を除き、確実にレベル1代表サーバ及びレベル2代表サーバに選定される。なお、ハートビート延長要求によるハートビートを送信する時間の延長は1回限りであり、タイマーが停止した場合には、図6に示したフローチャートの動作に従い、再度代表サーバの選定が開始される。
【0134】
最後に、上記(4)の「大代表サーバがサービスを実行できなくなった場合に、その大代表サーバが属するサーバ群の中から新たな大代表サーバを選定できない場合の動作」について説明する。ここでは、図3に示した構成の場合において、図中最も左のサーバ10が大代表サーバ(レベル2代表サーバ)であった場合を一例として説明する。
【0135】
大代表サーバが正常に動作しなくなった場合、または、代表サーバである時間を延長できなかった場合、大代表サーバは、大代表サーバでなくなるだけではなく、レベル1及びレベル0代表サーバでもなくなる。つまり、レベル0代表サーバ及びレベル1代表サーバも不在となる。これは、上記(3)の場合と同様である。
【0136】
ここでは、図3の図中最も左側のレベル0代表サーバと、左側のレベル1代表サーバが不在となる。この場合、まず、サーバ群1に属する複数のサーバ10の調停部103が、サーバ群1を代表する新たなレベル0代表サーバの選定を開始する。但し、ここでは、ネットワークの障害により、サーバ群1に属するサーバ数の過半数以上を占める第2のサーバグループを形成できず、新たなレベル0代表サーバを選定できなかったものとする。つまり、サーバ群1を代表するレベル0代表サーバが存在しないこととなる。
【0137】
この場合、図3の図中左から2番目のレベル0代表サーバと、3番目のレベル0代表サーバとが通信を行うことにより、いずれかがレベル1代表サーバに選定される。そして、新たにレベル1の代表サーバに選定されたサーバ10はすぐに、レベル2代表サーバの選定を開始する。
【0138】
ここで、上記の式(2)に示したように、タイマーが停止するまでの時間は、レベル2よりもレベル1の方が短い。そのため、レベル2において代表サーバの選定はまだ開始されていない。そのため、新たにレベル1代表サーバになったサーバ10がレベル2代表サーバになれる。
【0139】
上述したように、大代表サーバが属するサーバ群において新たにレベル0代表サーバを選定できない場合、所定のサービスの提供を移動するコストが少ないサーバ群によってサービスの提供が継続される。つまり、サービスを提供することができない時間を最小限にすることができ、高可用性を維持することができる。
【0140】
このように本実施形態においては、サーバ群1〜6のそれぞれに属する複数のサーバ10は、当該サーバ群に属する複数のサーバ10のうち、相互に通信可能なサーバからなる第1のサーバグループを形成する。そして、第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバ10の中から、当該サーバ群を代表する代表サーバを選定する。そして、サーバ群1〜6毎に選定された複数の代表サーバは、その複数の代表サーバの中から、所定のサービスを提供する大代表サーバを選定する。
【0141】
これにより、所定のサービスを提供するサーバ10が複数存在すること、及び、所定のサービスを提供するサーバ10が存在しなくなるのを回避することができる。
【0142】
従って、データの整合性を確保しつつ、高可用性を維持することが可能となる。
【0143】
なお、本発明においては、サーバ内の処理は上述の専用のハードウェアにより実現されるもの以外に、その機能を実現するためのプログラムをサーバにて読取可能な記録媒体に記録し、この記録媒体に記録されたプログラムをサーバに読み込ませ、実行するものであっても良い。サーバにて読取可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、DVD、CDなどの移設可能な記録媒体の他、サーバに内蔵されたHDDなどを指す。
【符号の説明】
【0144】
1〜6 サーバ群
10 サーバ
50 ローカルネットワーク
100 高可用部
101 メンバ管理部
102 サービス実行権管理部
103 調停部
104 記憶部
110 サービス提供部
120 通信部
150 グローバルネットワーク
【特許請求の範囲】
【請求項1】
相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムであって、
前記複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成し、
前記第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定し、
前記複数のサーバ群毎に選定された複数の代表サーバは、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する高可用性システム。
【請求項2】
請求項1に記載の高可用性システムにおいて、
前記大代表サーバは、当該大代表サーバと同じサーバ群に属する他のサーバへ所定の時間間隔で信号を送信し、
前記大代表サーバと同じサーバ群に属する他のサーバは、当該大代表サーバから送信された信号を予め決められた第1の時間間隔内に受信しない場合、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第2のサーバグループを形成し、
前記第2のサーバグループのサーバは、当該第2のサーバグループのサーバ数が前記所定数以上である場合、当該第2のサーバグループの中から、前記代表サーバを新たに選定し、
前記新たに選定された前記代表サーバは、前記大代表サーバとして前記所定のサービスの提供を開始する高可用性システム。
【請求項3】
請求項2に記載の高可用性システムにおいて、
前記大代表サーバは、当該大代表サーバ以外の前記代表サーバへ前記所定の時間間隔で信号を送信し、
前記大代表サーバ以外の前記代表サーバは、当該大代表サーバから送信された信号を前記第1の時間間隔よりも長い第2の時間間隔内に受信しない場合、前記複数の代表サーバの中から前記大代表サーバを新たに選定し、
前記新たに選定された前記大代表サーバは、前記所定のサービスの提供を開始する高可用性システム。
【請求項4】
請求項1乃至3のいずれか1項に記載の高可用性システムにおいて、
前記所定数は、前記サーバ群に属するサーバ数の過半数である高可用性システム。
【請求項5】
相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバであって、
前記所定のサービスを提供するサービス提供部と、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第1のサーバグループを形成し、該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループの他のサーバと通信を行うことにより、当該第1のサーバグループの中から、当該サーバ群を代表する代表サーバを選定し、自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定し、自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供の開始を許可する許可情報を出力する高可用部と、を有し、
前記サービス提供部は、前記高可用部から出力された許可情報を受け付けると、前記所定のサービスの提供を開始するサーバ。
【請求項6】
請求項5に記載のサーバにおいて、
前記高可用部は、自サーバが前記大代表サーバである場合、自サーバと同じサーバ群に属する他のサーバへ所定の時間間隔で信号を送信し、自サーバが前記大代表サーバと同じサーバ群に属する他のサーバである場合、当該大代表サーバから送信された信号を予め決められた第1の時間間隔内に受信しないと、当該サーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第2のサーバグループを形成し、該第2のサーバグループのサーバ数が前記所定数以上である場合、当該第2のサーバグループの他のサーバと通信を行うことにより、当該第2のサーバグループの中から前記代表サーバを新たに選定し、自サーバが新たに前記代表サーバに選定されると、前記許可情報を出力するサーバ。
【請求項7】
請求項6に記載のサーバにおいて、
前記高可用部は、自サーバが前記大代表サーバである場合、自サーバ以外の前記代表サーバへ前記所定の時間間隔で信号を送信し、自サーバが前記大代表サーバ以外の前記代表サーバである場合、当該大代表サーバから送信された信号を前記第1の時間間隔よりも長い第2の時間間隔内に受信しないと、自サーバ以外の前記代表サーバと通信を行うことにより、前記複数の代表サーバの中から前記大代表サーバを新たに選定し、自サーバが新たに前記大代表サーバに選定されると、前記許可情報を出力するサーバ。
【請求項8】
請求項5乃至7のいずれか1項に記載のサーバにおいて、
前記所定数は、前記サーバ群に属するサーバ数の過半数であるサーバ。
【請求項9】
相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムにおける高可用性維持方法であって、
前記複数のサーバ群のそれぞれに属する複数のサーバが、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成する処理と、
前記第1のサーバグループのサーバが、当該第1のサーバグループのサーバ数が当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定する処理と、
前記複数のサーバ群毎に選定された複数の代表サーバが、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する処理と、を有する高可用性維持方法。
【請求項10】
相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバに、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第1のサーバグループを形成する機能と、
前記第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループの他のサーバと通信を行うことにより、当該第1のサーバグループの中から、当該サーバ群を代表する代表サーバを選定する機能と、
自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する機能と、
自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供を開始する機能と、を実現させるためのプログラム。
【請求項1】
相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムであって、
前記複数のサーバ群のそれぞれに属する複数のサーバは、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成し、
前記第1のサーバグループのサーバは、当該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定し、
前記複数のサーバ群毎に選定された複数の代表サーバは、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する高可用性システム。
【請求項2】
請求項1に記載の高可用性システムにおいて、
前記大代表サーバは、当該大代表サーバと同じサーバ群に属する他のサーバへ所定の時間間隔で信号を送信し、
前記大代表サーバと同じサーバ群に属する他のサーバは、当該大代表サーバから送信された信号を予め決められた第1の時間間隔内に受信しない場合、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第2のサーバグループを形成し、
前記第2のサーバグループのサーバは、当該第2のサーバグループのサーバ数が前記所定数以上である場合、当該第2のサーバグループの中から、前記代表サーバを新たに選定し、
前記新たに選定された前記代表サーバは、前記大代表サーバとして前記所定のサービスの提供を開始する高可用性システム。
【請求項3】
請求項2に記載の高可用性システムにおいて、
前記大代表サーバは、当該大代表サーバ以外の前記代表サーバへ前記所定の時間間隔で信号を送信し、
前記大代表サーバ以外の前記代表サーバは、当該大代表サーバから送信された信号を前記第1の時間間隔よりも長い第2の時間間隔内に受信しない場合、前記複数の代表サーバの中から前記大代表サーバを新たに選定し、
前記新たに選定された前記大代表サーバは、前記所定のサービスの提供を開始する高可用性システム。
【請求項4】
請求項1乃至3のいずれか1項に記載の高可用性システムにおいて、
前記所定数は、前記サーバ群に属するサーバ数の過半数である高可用性システム。
【請求項5】
相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバであって、
前記所定のサービスを提供するサービス提供部と、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第1のサーバグループを形成し、該第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループの他のサーバと通信を行うことにより、当該第1のサーバグループの中から、当該サーバ群を代表する代表サーバを選定し、自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定し、自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供の開始を許可する許可情報を出力する高可用部と、を有し、
前記サービス提供部は、前記高可用部から出力された許可情報を受け付けると、前記所定のサービスの提供を開始するサーバ。
【請求項6】
請求項5に記載のサーバにおいて、
前記高可用部は、自サーバが前記大代表サーバである場合、自サーバと同じサーバ群に属する他のサーバへ所定の時間間隔で信号を送信し、自サーバが前記大代表サーバと同じサーバ群に属する他のサーバである場合、当該大代表サーバから送信された信号を予め決められた第1の時間間隔内に受信しないと、当該サーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第2のサーバグループを形成し、該第2のサーバグループのサーバ数が前記所定数以上である場合、当該第2のサーバグループの他のサーバと通信を行うことにより、当該第2のサーバグループの中から前記代表サーバを新たに選定し、自サーバが新たに前記代表サーバに選定されると、前記許可情報を出力するサーバ。
【請求項7】
請求項6に記載のサーバにおいて、
前記高可用部は、自サーバが前記大代表サーバである場合、自サーバ以外の前記代表サーバへ前記所定の時間間隔で信号を送信し、自サーバが前記大代表サーバ以外の前記代表サーバである場合、当該大代表サーバから送信された信号を前記第1の時間間隔よりも長い第2の時間間隔内に受信しないと、自サーバ以外の前記代表サーバと通信を行うことにより、前記複数の代表サーバの中から前記大代表サーバを新たに選定し、自サーバが新たに前記大代表サーバに選定されると、前記許可情報を出力するサーバ。
【請求項8】
請求項5乃至7のいずれか1項に記載のサーバにおいて、
前記所定数は、前記サーバ群に属するサーバ数の過半数であるサーバ。
【請求項9】
相互に接続された複数のサーバ群を有し、該複数のサーバ群のうちのいずれかが、当該サーバ群に属する複数のサーバのいずれかによって所定のサービスを提供し、当該サーバ群が前記所定のサービスを提供できない場合、前記複数のサーバ群のうち、当該サーバ群以外のサーバ群に属する複数のサーバのいずれかによって前記所定のサービスの提供を継続する高可用性システムにおける高可用性維持方法であって、
前記複数のサーバ群のそれぞれに属する複数のサーバが、当該サーバ群に属する複数のサーバのうち、相互に通信可能なサーバからなる第1のサーバグループを形成する処理と、
前記第1のサーバグループのサーバが、当該第1のサーバグループのサーバ数が当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループのサーバの中から、当該サーバ群を代表する代表サーバを選定する処理と、
前記複数のサーバ群毎に選定された複数の代表サーバが、該複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する処理と、を有する高可用性維持方法。
【請求項10】
相互に接続された複数のサーバ群のいずれかに属し、前記複数のサーバ群に属する複数のサーバのいずれかが所定のサービスを提供し、当該サーバが前記所定のサービスを提供できない場合、前記所定のサービスの提供を継続するサーバに、
自サーバと同じサーバ群に属する他のサーバと通信を行うことにより、相互に通信可能なサーバからなる第1のサーバグループを形成する機能と、
前記第1のサーバグループのサーバ数が、当該サーバ群のサーバ数に応じた所定数以上である場合、当該第1のサーバグループの他のサーバと通信を行うことにより、当該第1のサーバグループの中から、当該サーバ群を代表する代表サーバを選定する機能と、
自サーバが前記代表サーバに選定されると、前記複数のサーバ群のうち他のサーバ群にて選定された前記代表サーバと通信を行うことにより、前記複数のサーバ群毎に選定された複数の代表サーバの中から、前記所定のサービスを提供する大代表サーバを選定する機能と、
自サーバが前記大代表サーバに選定されると、前記所定のサービスの提供を開始する機能と、を実現させるためのプログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【公開番号】特開2011−186609(P2011−186609A)
【公開日】平成23年9月22日(2011.9.22)
【国際特許分類】
【出願番号】特願2010−49198(P2010−49198)
【出願日】平成22年3月5日(2010.3.5)
【国等の委託研究の成果に係る記載事項】(出願人による申告)平成21年度、総務省「セキュアクラウドネットワーキング技術(クラウドサービス連携技術)の研究開発」委託事業、産業技術力強化法第19条の適用を受ける特許出願
【出願人】(000004226)日本電信電話株式会社 (13,992)
【Fターム(参考)】
【公開日】平成23年9月22日(2011.9.22)
【国際特許分類】
【出願日】平成22年3月5日(2010.3.5)
【国等の委託研究の成果に係る記載事項】(出願人による申告)平成21年度、総務省「セキュアクラウドネットワーキング技術(クラウドサービス連携技術)の研究開発」委託事業、産業技術力強化法第19条の適用を受ける特許出願
【出願人】(000004226)日本電信電話株式会社 (13,992)
【Fターム(参考)】
[ Back to top ]