(57)【特許請求の範囲】
【請求項１】
複数のクラスタメンバが分散処理を行うクラスタシステムであって、
前記複数のクラスタメンバそれぞれは、前記複数のクラスタメンバの識別子を含むメンバ管理表を保持しており、
前記複数のクラスタメンバのうちの代表メンバは、前記メンバ管理表を更新し、その更新したメンバ管理表を前記複数のクラスタメンバそれぞれに配信し、
前記複数のクラスタメンバのうち、前記代表メンバが故障した場合の次の代表メンバである次期代表メンバ候補が予め選出されており、
前記複数のクラスタメンバそれぞれは、
前記複数のクラスタメンバの間で行う死活監視対象を決定する際に、前記次期代表メンバ候補に対して死活監視を行うクラスタメンバを、そのときの前記代表メンバ以外から選出するように定めた監視先メンバ設定規則を記憶する記憶部と、
前記複数のクラスタメンバの間で行う死活監視対象を決定する際に、前記監視先メンバ設定規則にしたがって自身の監視対象を選出する処理部と、
を備えることを特徴とするクラスタシステム。
【請求項２】
前記監視先メンバ設定規則は、
前記複数のクラスタメンバの間で行う死活監視の関係が、任意のクラスタメンバから出発して、そのクラスタメンバの監視先クラスタメンバ、さらにそのクラスタメンバの監視先クラスタメンバ、と順にたどった場合に、前記複数のクラスタメンバすべてを網羅してから元の出発のクラスタメンバに戻るように設定された規則である
ことを特徴とする請求項１に記載のクラスタシステム。
【請求項３】
前記監視先メンバ設定規則は、
クラスタメンバ数（Ｎ）が奇数の場合、各クラスタメンバの監視対象を前記メンバ管理表における順番の降順で一つ飛ばしのクラスタメンバとし、最後から一つ前の「Ｎ−１」番目のクラスタメンバは先頭のクラスタメンバを監視し、最後のＮ番目のクラスタメンバは先頭から二番目のクラスタメンバを監視するように設定された規則である
ことを特徴とする請求項１または請求項２に記載のクラスタシステム。
【請求項４】
前記監視先メンバ設定規則は、
クラスタメンバ数（Ｎ）が偶数の場合、各クラスタメンバの監視対象を、
前記メンバ管理表における順番の先頭から「Ｎ−２」番目のクラスタメンバについては、前記メンバ管理表における順番の降順で一つ飛ばしのクラスタメンバとし、
最後から一つ前の「Ｎ−１」番目のクラスタメンバは先頭から二番目のクラスタメンバを監視し、最後のＮ番目のクラスタメンバは先頭のクラスタメンバを監視するように設定された規則である
ことを特徴とする請求項１または請求項２に記載のクラスタシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のクラスタメンバ（サーバなど。以下、単に「メンバ」と称する場合もある。）が分散処理を行うクラスタシステムにおける、クラスタメンバ間の死活監視の技術に関する。
【背景技術】
【０００２】
大容量データ保持、高速アクセス、高可用性が求められる近年のＷｅｂシステムでは、複数のサーバを協調させることにより、システム全体の処理能力を向上するクラスタシステムが多く用いられている。クラスタシステムによる分散処理では、クラスタを構成するクラスタメンバと、担当するデータが、対応付けられている必要がある。クラスタメンバとデータを対応付ける手法には、例えば、コンシステントハッシング（Consistent Hashing）法という手法がある（非特許文献１）。
【０００３】
コンシステントハッシング法は、データのハッシュ値と、クラスタメンバに割り当てたアドレスとを同一のＩＤ（IDentifier）空間上へマッピングすることで、クラスタメンバの担当データを定める手法である。この手法は、クラスタメンバが増減した場合でも、クラスタメンバとデータとの対応関係について全体の１／Ｎ（Ｎ：クラスタメンバ数）だけの変更で済むため、データ再配置の負荷を抑えられるという特徴がある。
【０００４】
また、この手法では、クラスタシステムの可用性を向上させるために、担当サーバ以外にもデータの複製を持たせる方法を併用する場合がある。その場合、各クラスタメンバは、全メンバの一覧表（メンバ管理表）を保持し、特定の規則のもとにメンバ管理表から複製先を特定できる必要がある。図１に示すように、メンバ管理表には、各メンバを一意に指定するキーとなるメンバＩＤと、ＩＰ（Internet Protocol）アドレスといったメンバ固有の付加情報と、が含まれる。また、このとき、メンバ管理表の一貫性を担保するには、その更新権限がクラスタ内外の特定サーバにのみ与えられていることが望ましい。
【０００５】
このような、メンバ管理表の一貫性を実現する方式として、クラスタメンバのうちの一つを代表メンバとし、メンバ管理表の更新と他メンバへの配信を行う方式がある（非特許文献２）。この方式において、代表メンバは、任意に定められた代表メンバ選出規則に従ってクラスタメンバの中から選出される。また、各クラスタメンバは代表メンバの選出規則を把握（記憶）しており、メンバ管理表の情報を元に、自分自身を含んで代表メンバの特定を可能とする。クラスタメンバの増減による代表メンバの交代もクラスタメンバの自律的な判断によって行われる。
【０００６】
（クラスタメンバ間死活監視と代表メンバの交代）
クラスタメンバの故障（異常）検知手法として、クラスタメンバ間で監視を行う方式がある。クラスタメンバごとに監視対象を定め、例えば定期的な（所定時間ごとの）ハートビート送信による応答有無を確認することで、所定時間内での故障検知を行う。故障が検知された場合には、監視を行ったクラスタメンバから全クラスタメンバへと当該メンバの故障が通知される。そして、当該メンバはクラスタシステムから減設される。そのため、代表メンバはメンバ管理表を更新し、その更新したメンバ管理表を全メンバに配信する。また、このとき、故障したメンバが代表メンバであった場合には、代表メンバの選出規則に従って次期の代表メンバが自律的に出現する。
【０００７】
代表メンバとその他のメンバが有する機能（処理部の構成）や情報について、図２を参照して説明する。
図２（ａ）に示すように、代表メンバは、処理部、記憶部、入出力部を備えて構成される。
処理部は、メンバ管理表配信部、メンバ管理表更新部、代表メンバ特定部、他メンバ死活監視部を備えている。
記憶部は、メンバ管理表、代表メンバ選出規則、旧監視先メンバ設定規則を記憶している。
【０００８】
図２（ｂ）に示すように、非代表メンバは、処理部、記憶部、入出力部を備えて構成される。
処理部は、代表メンバ特定部、他メンバ死活監視部を備えている。
記憶部は、メンバ管理表、代表メンバ選出規則、旧監視先メンバ設定規則を記憶している。
【０００９】
なお、代表メンバと非代表メンバは、図示を省略しているが、クラスタメンバとしてのメッセージ処理機能や、複製データの送信機能や管理機能などを有している。
【００１０】
（実装例と問題点）
上記のメンバ管理表（図１も参照）によるメンバ管理と、クラスタメンバ間の死活監視方式の実装例を考える。例えば、代表メンバ選出規則により、最初の代表メンバを、メンバ管理表の記載順序の先頭のメンバとする。このとき、メンバ管理表の記載順序はクラスタへの参加順序に従うものとする。さらに、各クラスタメンバの死活監視対象を、メンバ管理表で自身の次の（１つ下の）メンバとする（最後尾メンバは先頭メンバを監視する）。例として、クラスタメンバ数Ｎ＝４の場合を図３に示す。この場合に、１つのメンバ故障に伴うクラスタメンバの動作としては、以下の通りとなる。
【００１１】
＜（ａ）代表メンバ以外のメンバが故障した場合（図４参照）＞
例として、メンバ３が故障した場合について考える。メンバ３を死活監視しているメンバ２がメンバ３の故障を検知し（Ｓ４１）、メンバ３の故障を全メンバへ通知する（Ｓ４２）。その後、通知を受けた代表メンバはメンバ管理表を更新して（Ｓ４３）、その更新したメンバ管理表を全メンバへ配信する（Ｓ４４）。代表メンバ以外の他メンバ２，４が故障した場合も同様である。
【００１２】
＜（ｂ）代表メンバが故障した場合（図５参照）＞
メンバ１（代表メンバ）を死活監視しているメンバ４がメンバ１（代表メンバ）の故障を検知し（Ｓ５１）、メンバ１（代表メンバ）の故障を全メンバへ通知する（Ｓ５２）。その後、通知を受けたメンバ２（次期代表メンバ候補）は、自身を新代表メンバとして認識し（Ｓ５３）、メンバ管理表を更新し（Ｓ５４）、その更新したメンバ管理表を全メンバへ配信する（Ｓ５５）。以降、メンバ２は代表メンバとして動作する。
【００１３】
次に、２つのメンバが同時に故障した場合の動作として、以下の場合を考える。
【００１４】
＜（ｃ）代表メンバが故障するとともに、次期代表メンバ候補（先頭から二番目のメンバ）を監視するメンバでもなく代表メンバを監視するメンバでもないメンバが故障した場合（図６参照）＞
メンバ１（代表メンバ）とメンバ３が故障した場合を考える。まず、メンバ１（代表メンバ）を死活監視しているメンバ４がメンバ１（代表メンバ）の故障を検知し（Ｓ６１）、メンバ１（代表メンバ）の故障を全メンバへ通知する（Ｓ６２）。また、並行して、メンバ３を死活監視しているメンバ２がメンバ３の故障を検知し（Ｓ６３）、メンバ３の故障を全メンバへ通知する（Ｓ６４）。その後、次期代表メンバ候補であるメンバ２は、メンバ１（代表メンバ）とメンバ３の故障通知を受けて、自身を新代表メンバとして認識し（Ｓ６５）、メンバ管理表を更新し（Ｓ６６）、その更新したメンバ管理表を全メンバへ配信する（Ｓ６７）。以降、メンバ２は代表メンバとして動作する。
【００１５】
＜（ｄ）代表メンバが故障するとともに、次期代表メンバ候補（先頭から二番目のメンバ）が故障した場合（図７参照）＞
メンバ１（代表メンバ）とメンバ２（次期代表メンバ候補）が故障した場合を考える。まず、メンバ１（代表メンバ）を死活監視しているメンバ４がメンバ１（代表メンバ）の故障を検知し（Ｓ７１）、メンバ１（代表メンバ）の故障を全メンバへ通知する（Ｓ７２）。このとき、メンバ２（次期代表メンバ候補）も故障しているが、監視元のメンバ１（代表メンバ）が故障しているために故障検知が正常に行われない。この場合、メンバ１（代表メンバ）、メンバ２（次期代表メンバ候補）の同時故障であるため、次々期代表メンバ候補であるメンバ３が代表メンバとなる必要がある。ここで、メンバ２は、次期代表メンバ候補であるが、故障しているため、メンバ管理表を更新しない（Ｓ７３前段）。しかし、メンバ３は、メンバ２（次期代表メンバ候補）の故障が通知されないために、メンバ２（次期代表メンバ候補）を新代表メンバとして認識する（Ｓ７３後段）。そして、メンバ３は、そのメンバ２（次期代表メンバ候補）が新代表メンバとしてメンバ管理表の更新と配信を行うのを待ち続けることになり、クラスタシステムの処理が停止してしまう。
【００１６】
＜（ｅ）代表メンバが故障するとともに、代表メンバを監視するメンバ（最後尾メンバ）が故障した場合（図８参照）＞
メンバ１（代表メンバ）とメンバ４（代表メンバを監視するメンバ）が故障した場合を考える。まず、メンバ４（代表メンバを監視するメンバ）を死活監視しているメンバ３がメンバ４（代表メンバを監視するメンバ）の故障を検知し（Ｓ８１）、メンバ４（代表メンバを監視するメンバ）の故障を全メンバへ通知する（Ｓ８２）。このとき、メンバ１（代表メンバ）も故障しているが、監視元のメンバ４（代表メンバを監視するメンバ）が故障しているために故障検知が正常に行われない。この場合、メンバ１（代表メンバ）が故障しているため、次期代表メンバ候補であるメンバ２が代表メンバとなる必要がある。ここで、メンバ１（代表メンバ）は、故障しているため、メンバ管理表を更新しない（Ｓ８３前段）。しかし、メンバ２（次期代表メンバ候補）は、メンバ１（代表メンバ）の故障が通知されないために、メンバ１を代表メンバとして認識する（Ｓ８３後段）。そして、メンバ２（次期代表メンバ候補）は、メンバ１（代表メンバ）の故障が通知されないために、メンバ１（代表メンバ）がメンバ管理表の更新と配信を行うのを待ち続けることになり、クラスタシステムの処理が停止してしまう。
【００１７】
上記（ｄ）（図７）に示した代表メンバと次期代表メンバ候補が同時に故障した場合、および、（ｅ）（図８）に示した代表メンバと代表メンバを監視するメンバが同時に故障した場合には、新代表メンバが現れず、メンバ管理表の更新が行われないために、システムが停止してしまうという問題がある。
【００１８】
本問題の従来の解決手法の一つを図９に示す。図７の場合と同様、メンバ１（代表メンバ）とメンバ２（次期代表メンバ候補）が故障した場合を考える。この解決手法では、クラスタメンバの故障通知が発生した際に、所定時間、代表メンバによるメンバ管理表の更新が行われなかった場合には、本来の死活監視メンバとは異なるメンバが、代表メンバもしくは次期代表メンバ候補の故障検知を行う。
【００１９】
まず、メンバ１（代表メンバ）を死活監視しているメンバ４がメンバ１（代表メンバ）の故障を検知し（Ｓ９１）、メンバ１（代表メンバ）の故障を全メンバへ通知する（Ｓ９２）。ここで、メンバ２は、次期代表メンバ候補であるが、故障しているため、メンバ管理表を更新しない（Ｓ９３前段）。しかし、メンバ３は、メンバ２（次期代表メンバ候補）の故障が通知されないために、メンバ２（次期代表メンバ候補）を新代表メンバとして認識する（Ｓ９３後段）。
【００２０】
ここで、故障通知から所定時間、メンバ管理表の更新が行われなかった場合に、メンバ４は、メンバ２（次期代表メンバ候補）の故障検知をメンバ３へ依頼する（Ｓ９４）。そして、メンバ３は、メンバ２（次期代表メンバ候補）の故障を検知し（Ｓ９５）、メンバ２（次期代表メンバ候補）の故障を全メンバに通知する（Ｓ９６）。その後、メンバ３は、自身を新代表メンバとして認識し（Ｓ９７）、メンバ管理表を更新し（Ｓ９８）、その更新したメンバ管理表を全メンバへ配信する（Ｓ９９）。
【先行技術文献】
【非特許文献】
【００２１】
【非特許文献１】丸山不二夫、首藤一幸、「スケールアウトの技術」、雲の世界の向こうをつかむ  クラウドの技術、株式会社アスキー・メディアワークス、２００９年１１月６日、ＩＳＢＮ９７８−４−０４−８６８０６４−６  Ｃ３００４、ｐ．８８‐９９
【非特許文献２】岩佐絵里子、外５名、「スケールアウト型セッション制御サーバにおける動的構成変更負荷軽減方式」、信学技報、社団法人電子情報通信学会、２０１２年、ＮＳ２０１１−１５６（２０１２−０１）、ｐ．６５‐７０
【発明の概要】
【発明が解決しようとする課題】
【００２２】
このように、図９に示すように、クラスタメンバの故障通知が発生した際に、所定時間、代表メンバによるメンバ管理表の更新が行われなかった場合には、本来の死活監視メンバとは異なるメンバが、代表メンバもしくは次期代表メンバ候補の故障検知を行う方法は有効である。しかしながら、この方法は代表メンバや次期代表メンバ候補の故障検知を行うまでの判断に時間を要するため、最終的にメンバ管理表が更新されるまでに比較的長時間を要するという問題がある。メンバ管理表が正しく更新されていない期間は、データの複製が正常に管理されていない状態であるため、サービスの停止が許されない高可用システムにおいては、より高速にクラスタメンバの状態を反映可能な手法が求められる。
【００２３】
そこで、本発明は、前記した事情に鑑みてなされたものであり、クラスタシステムにおいて、メンバ管理表の更新と配信を行う代表メンバと他のメンバとが同時に故障した場合でも、新代表メンバを高速に選出することを課題とする。
【課題を解決するための手段】
【００２４】
前記課題を解決するために、本発明は、複数のクラスタメンバが分散処理を行うクラスタシステムであって、前記複数のクラスタメンバそれぞれは、前記複数のクラスタメンバの識別子を含むメンバ管理表を保持しており、前記複数のクラスタメンバのうちの代表メンバは、前記メンバ管理表を更新し、その更新したメンバ管理表を前記複数のクラスタメンバそれぞれに配信し、前記複数のクラスタメンバのうち、前記代表メンバが故障した場合の次の代表メンバである次期代表メンバ候補が予め選出されており、前記複数のクラスタメンバそれぞれは、前記複数のクラスタメンバの間で行う死活監視対象を決定する際に、次期代表メンバ候補に対して死活監視を行うクラスタメンバを、そのときの代表メンバ以外から選出するように定めた監視先メンバ設定規則を記憶する記憶部と、前記複数のクラスタメンバの間で行う死活監視対象を決定する際に、前記監視先メンバ設定規則にしたがって自身の監視対象を選出する処理部と、を備えることを特徴とする。
【００２５】
これにより、クラスタシステムにおいて、前記した監視先メンバ設定規則を用いることで、メンバ管理表の更新と配信を行う代表メンバと他のメンバとが同時に故障した場合でも、新代表メンバを高速に選出することができる。
【００２６】
また、本発明において、前記監視先メンバ設定規則は、前記複数のクラスタメンバの間で行う死活監視の関係が、任意のクラスタメンバから出発して、そのクラスタメンバの監視先クラスタメンバ、さらにそのクラスタメンバの監視先クラスタメンバ、と順にたどった場合に、全クラスタメンバを網羅してから元の出発のクラスタメンバに戻るように設定された規則であることが望ましい。
【００２７】
これにより、各クラスタメンバの監視先が全メンバを跨った系を成すように構成することで、複数メンバの同時故障時に故障検知不能となるメンバをより少なくすることができる。
【００２８】
また、本発明において、前記監視先メンバ設定規則は、クラスタメンバ数（Ｎ）が奇数の場合、各クラスタメンバの監視対象を前記メンバ管理表における順番の降順で一つ飛ばしのクラスタメンバとし、最後から一つ前の「Ｎ−１」番目のクラスタメンバは先頭のクラスタメンバを監視し、最後のＮ番目のクラスタメンバは先頭から二番目のクラスタメンバを監視するように設定された規則であることが望ましい。
【００２９】
これにより、クラスタメンバ数（Ｎ）が奇数の場合に、各クラスタメンバの監視先が全メンバを跨った系を成すように容易に構成することができる。
【００３０】
また、本発明において、前記監視先メンバ設定規則は、クラスタメンバ数（Ｎ）が偶数の場合、各クラスタメンバの監視対象を、先頭から「Ｎ−２」番目のクラスタメンバについては、前記メンバ管理表における順番の降順で一つ飛ばしのクラスタメンバとし、最後から一つ前の「Ｎ−１」番目のクラスタメンバは先頭から二番目のクラスタメンバを監視し、最後のＮ番目のクラスタメンバは先頭のクラスタメンバを監視するように設定された規則であることが望ましい。
【００３１】
これにより、クラスタメンバ数（Ｎ）が偶数の場合に、各クラスタメンバの監視先が全メンバを跨った系を成すように容易に構成することができる。
【発明の効果】
【００３２】
本発明によれば、クラスタシステムにおいて、メンバ管理表の更新と配信を行う代表メンバと他のメンバとが同時に故障した場合でも、新代表メンバを高速に選出するができる。
【図面の簡単な説明】
【００３３】
【図１】従来技術のメンバ管理表のデータ構成図である。
【図２】（ａ）は、従来技術の代表メンバの構成図である。（ｂ）は、従来技術の非代表メンバの構成図である。
【図３】従来技術における、クラスタメンバ数Ｎ＝４の場合のクラスタメンバ間の死活監視関係を示す図である。
【図４】従来技術において、図３の例でメンバ３が故障した場合について、（ａ）は各メンバの状態を示す模式図であり、（ｂ）は各メンバによる処理を示すフローチャートである。
【図５】従来技術において、図３の例でメンバ１が故障した場合について、（ａ）は各メンバの状態を示す模式図であり、（ｂ）は各メンバによる処理を示すフローチャートである。
【図６】従来技術において、図３の例でメンバ１とメンバ３が同時に故障した場合について、（ａ）は各メンバの状態を示す模式図であり、（ｂ）は各メンバによる処理を示すフローチャートである。
【図７】従来技術において、図３の例でメンバ１とメンバ２が同時に故障した場合について、（ａ）は各メンバの状態を示す模式図であり、（ｂ）は各メンバによる処理を示すフローチャートである。
【図８】従来技術において、図３の例でメンバ１とメンバ４が同時に故障した場合について、（ａ）は各メンバの状態を示す模式図であり、（ｂ）は各メンバによる処理を示すフローチャートである。
【図９】別の従来技術において、図３の例でメンバ１とメンバ２が同時に故障した場合について、（ａ）は各メンバの状態を示す模式図であり、（ｂ）は各メンバによる処理を示すフローチャートである。
【図１０】（ａ）は、本実施形態の代表メンバの構成図である。（ｂ）は、本実施形態の非代表メンバの構成図である。
【図１１】（ａ）は、本実施形態の方式をメンバ数（Ｎ）が奇数の場合に適用したときのメンバ間の監視関係を示す図である。（ｂ）は、本実施形態の方式をメンバ数（Ｎ）が偶数の場合に適用したときのメンバ間の監視関係を示す図である。
【図１２】本実施形態において、図７の場合と同様に、メンバ１とメンバ２が同時に故障した場合について、（ａ）は各メンバの状態を示す模式図であり、（ｂ）は各メンバによる処理を示すフローチャートである。
【図１３】（ａ）は、本実施形態において、監視先が全メンバを跨った系を成すように構成する場合のメンバ間の監視関係を示す図である。（ｂ）は、比較例として、監視先が全メンバを跨っていない構成の場合のメンバ間の監視関係を示す図である。
【図１４】本実施形態において、監視先が全メンバを跨った系を成すように構成するためのクラスタメンバの監視先の設定手順の説明図であり、（ａ）は、メンバ管理表における各メンバの配列状況を示す図であり、（ｂ）はその設定手順を示すフローチャートである。
【発明を実施するための形態】
【００３４】
以下、本発明を実施するための形態（以下、実施形態と称する。）について、図面を参照（言及図以外の図も適宜参照）しながら説明する。
本実施形態では、複数のクラスタメンバが分散処理を行うクラスタシステムについて説明する。なお、本実施形態ではクラスタメンバとデータを対応付ける手法としてコンシステントハッシング法を用いるが、本発明はコンシステントハッシング法に限定されない。
【００３５】
まず、本実施形態の代表メンバとその他のメンバが有する機能（処理部の構成）や情報について、図１０を参照して説明する。
図１０（ａ）に示すように、代表メンバ１００は、処理部１１０、記憶部１２０、入出力部１３０を備えて構成される。
処理部１１０は、メンバ管理表配信部１１１、メンバ管理表更新部１１２、代表メンバ特定部１１３、他メンバ死活監視部１１４を備えている。
【００３６】
メンバ管理表配信部１１１は、メンバ管理表１２１を他のメンバに配信する。
メンバ管理表更新部１１２は、所定の契機（例えば、メンバの増減時）に、メンバ管理表１２１を更新する。
代表メンバ特定部１１３は、所定の契機（例えば、代表メンバの故障時）に、代表メンバ選出規則１２２を用いて、代表メンバを特定する。
他メンバ死活監視部１１４は、監視先メンバ設定規則１２３により定められた他のメンバの死活監視を行う。
【００３７】
記憶部１２０は、メンバ管理表１２１、代表メンバ選出規則１２２、監視先メンバ設定規則１２３を記憶している。
入出力部１３０は、情報の入力インタフェース、出力インタフェース、通信インタフェースを備える。
【００３８】
なお、代表メンバ１００は、図２（ａ）に示す代表メンバと比較して、監視先メンバ設定規則１２３が旧監視先メンバ設定規則と異なっている点で技術的特徴を有する（詳細は後記）。その他の構成については、図２（ａ）に示す代表メンバにおいて対応する構成と同様であるので、詳細な説明を省略する。
【００３９】
また、図１０（ａ）に図示していないが、代表メンバ１００は、記憶部１２０に、次期代表メンバ候補の選出規則も記憶している。そして、代表メンバ１００は、その次期代表メンバ候補の選出規則を用いることで、必要に応じて、次期代表メンバ候補を新たに選出することができる。または、代表メンバ１００は、次期代表メンバ候補の識別子を所定の記憶領域に常に記憶していて、代表メンバが変更になる契機に、次期代表メンバ候補の選出規則に基づいて次期代表メンバ候補を新たに選出し、その所定の記憶領域に記憶している次期代表メンバ候補の識別子を更新するようにしてもよい。なお、次期代表メンバ候補の選出規則は、例えば、メンバ管理表１２１における代表メンバの次（１つ下）のメンバを次期代表メンバとする規則である。
【００４０】
図１０（ｂ）に示すように、非代表メンバ２００は、処理部２１０、記憶部２２０、入出力部２３０を備えて構成される。
処理部２１０は、代表メンバ特定部２１１、他メンバ死活監視部２１２を備えている。
代表メンバ特定部２１１は、所定の契機（例えば、代表メンバの故障時）に、代表メンバ選出規則２２２を用いて、代表メンバを特定する。
他メンバ死活監視部２１２は、監視先メンバ設定規則２２３により定められた他のメンバの死活監視を行う。
記憶部２２０は、メンバ管理表２２１、代表メンバ選出規則２２２、監視先メンバ設定規則２２３を記憶している。
入出力部２３０は、情報の入力インタフェース、出力インタフェース、通信インタフェースを備える。
【００４１】
なお、非代表メンバ２００は、図２（ｂ）に示す非代表メンバと比較して、監視先メンバ設定規則２２３が旧監視先メンバ設定規則と異なっている点で技術的特徴を有する（詳細は後記）。その他の構成については、図２（ｂ）に示す非代表メンバにおいて対応する構成と同様であるので、詳細な説明を省略する。
【００４２】
また、図１０（ｂ）に図示していないが、非代表メンバ２００は、記憶部２２０に、次期代表メンバ候補の選出規則（代表メンバ１００のものと共通）も記憶している。
【００４３】
また、代表メンバ１００と非代表メンバ２００は、図示を省略しているが、クラスタメンバとしてのメッセージ処理機能や、複製データの送信機能や管理機能などを有している。
【００４４】
また、図１０（ｂ）では、非代表メンバ２００の処理部２１０は、代表メンバ１００の処理部１１０におけるメンバ管理表配信部１１１メンバ管理表更新部１１２に対応する構成を図示していないが、非代表メンバ２００が代表メンバ１００になった際には、そのような構成も有することになることは、言うまでもない。
【００４５】
本実施形態では、前述した（ｄ）（図７）と（ｅ）（図８）の問題を解決するクラスタメンバ間の監視方式を提案する。そのためには、代表メンバの監視対象が次期代表メンバ候補となることを避けることが有効である。つまり、監視先メンバ設定規則１２３および監視先メンバ設定規則２２３は、複数のクラスタメンバの間で行う死活監視対象を決定する際に、次期代表メンバ候補に対して死活監視を行うクラスタメンバを、そのときの代表メンバ以外から選出するように定めた規則であり、具体的には、次の通りである。
【００４６】
例えば、クラスタメンバ数（Ｎ）が奇数の場合、各クラスタメンバの監視対象をメンバ管理表１２１（図１と同じ）の一つ飛ばし（２つ下）のメンバとする。なお、メンバ管理表１２１では、列最後尾（最下段）の次は先頭に戻るものとして扱う。
【００４７】
つまり、図１１（ａ）に示すように、Ｎ＝５の場合で考えると、メンバ１（代表メンバ）はメンバ３を監視する。メンバ２はメンバ４を監視する。メンバ３はメンバ５を監視する。そして、最後尾（メンバ５）から一つ前の「Ｎ−１」番目のメンバ（メンバ４）は先頭メンバ（メンバ１）を監視する。また、最後尾のＮ番目のメンバ（メンバ５）は先頭から二番目のメンバ（メンバ２）を監視する。これにより、各クラスタメンバの監視先が全メンバを跨った系を成すように容易に構成することができる。
【００４８】
ここで、「監視先が全メンバを跨った系」とは、複数のクラスタメンバの間で行う死活監視の関係が、任意のクラスタメンバから出発して、そのクラスタメンバの監視先クラスタメンバ、さらにそのクラスタメンバの監視先クラスタメンバ、と順にたどった場合に、全クラスタメンバを網羅してから元の出発のクラスタメンバに戻ることを指す。
【００４９】
図１１（ｂ）に示すように、メンバ数（Ｎ）が偶数の場合には、Ｎ番目のメンバ（メンバ４）が先頭メンバ（メンバ１）を監視し、Ｎ−１番目のメンバが先頭から二番目のメンバを監視することとする。これにより、各クラスタメンバの監視先が全メンバを跨った系を成すように容易に構成することができる。また、メンバ数Ｎ＝４の場合に、メンバ２とメンバ４が互いを監視してそれらの同時故障時に故障検知が行われない事態を防ぐという効果もある。
【００５０】
以上の方式を用いた場合の、メンバ１（代表メンバ）とメンバ２（次期代表メンバ候補）が同時に故障したときの動作について図１２に示す（Ｎ＝４の場合）。動作主体は、処理部１１０内の各部と、処理部２１０内の各部であるが、記載を簡潔にするために各メンバを動作主体とする。
【００５１】
まず、メンバ１（代表メンバ）を死活監視しているメンバ４がメンバ１（代表メンバ）の故障を検知し（Ｓ１２１）、メンバ１（代表メンバ）の故障を全メンバへ通知する（Ｓ１２２）。また、並行して、メンバ２を死活監視しているメンバ３がメンバ２の故障を検知し（Ｓ１２３）、メンバ２の故障を全メンバへ通知する（Ｓ１２４）。次々期代表メンバ候補であるメンバ３は、メンバ１（代表メンバ）とメンバ２（次期代表メンバ候補）の故障通知を受けて、自身を新代表メンバとして認識し（Ｓ１２５）、メンバ管理表１２１を更新し（Ｓ１２６）、その更新したメンバ管理表１２１を全メンバへ配信する（Ｓ１２７）。以降、メンバ３は代表メンバとして動作する。
【００５２】
以上のように、本方式を用いることで、代表メンバと次期代表メンバの故障検知が並行して行われ、新代表メンバの高速な選出を行うことが可能となる。つまり、クラスタシステムにおいて、メンバ管理表１２１の更新と配信を行う代表メンバと他のメンバとが同時に故障した場合でも、新代表メンバを高速に選出できる。
【００５３】
ここで、本方式を一般化して示す。本方式では前提として、複数メンバの同時故障時に故障検知不能となるメンバをできるだけ少なくするために、相互監視しあうペアを発生させないことに加えて、図１３（ａ）に示すように各クラスタメンバの監視先が全メンバを跨った系を成すように構成する監視先メンバ設定規則１２３，２２３を用いる。
【００５４】
比較例として、各クラスタメンバの監視先が全メンバを跨っていない構成の場合、図１３（ｂ）の例では、メンバ１〜３が同時に故障した場合に故障検知が不能であり、また、メンバ４〜Ｎが同時に故障した場合にも故障検知が不能である。
【００５５】
一方、「監視先が全メンバを跨った系」を採用する本方式では、メンバｋを代表メンバ、メンバｊを次期代表メンバ候補とするとき、各クラスタメンバの監視先を、図１４（ｂ）に示す手順で決定する。図１４（ａ）は、Ｎ個のメンバのうちｋ番目が代表メンバでｊ番目が次期代表メンバ候補であることを表している。
【００５６】
まず、条件１（ｘ≠ｋ，ｘ≠ｊ）に従い、メンバｋ（代表メンバ）の監視先メンバｘを決定する（Ｓ１４１）。つまり、メンバｋ（代表メンバ）の監視先メンバｘを、メンバｊ（次期代表メンバ候補）と自身を除いた（Ｎ−２）個のメンバの中から選択する。
【００５７】
次に、条件２（ｙ≠ｋ，ｙ≠ｘ）に従い、メンバｘの監視先メンバｙを決定する（Ｓ１４２）。つまり、メンバｘの監視先メンバｙを、系の始点である代表メンバｋと、既に監視元メンバが決定しているメンバｘを除いた（Ｎ−２）個のメンバの中から選択する。
【００５８】
次に、監視先を未設定のメンバ数が「２以上」か「１」かを判断し、「２以上」であればＳ１４５に進み、「１」であれば最終メンバの監視先をメンバｋ（代表メンバ）に設定し（Ｓ１４４）、処理を終了する。
【００５９】
Ｓ１４５において、条件３（ｚ≠ｋ，ｚ≠ｘ，ｚ≠ｙ）に従い、メンバｙの監視先メンバｚを決定する。つまり、メンバｙの監視先メンバｚを、系の始点である代表メンバｋと、既に監視元メンバが決定しているメンバｘ，ｙを除いた（Ｎ−３）個のメンバの中から選択する。
【００６０】
次に、監視先を未設定のメンバ数が「２以上」か「１」かを判断し、「２以上」であれば｛Ｓ１４２，Ｓ１４３｝、｛Ｓ１４５，Ｓ１４６｝と同様の処理（条件４，５，・・・を用いて監視先メンバを決定）を継続し、「１」であれば最終メンバの監視先をメンバｋ（代表メンバ）に設定し（Ｓ１４７）、処理を終了する。
【００６１】
このようにして、代表メンバが次期代表メンバを監視することを避けるとともに、各クラスタメンバの監視先が全メンバを跨った系を成すように構成することで、複数メンバの同時故障時に故障検知不能となるメンバをできるだけ少なくすることができる。なお、Ｎ＝２の場合は、代表メンバと次期代表メンバ候補が相互監視することになるので、本実施形態におけるＮの必要条件はＮ≧３である。
【００６２】
この方式は、クラスタシステムのソフトウェアに大きな変更を加えることなく実装可能であるので、汎用的な利用に有効である。
【００６３】
以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。具体的な構成や処理について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００６４】
１００  代表メンバ
１１０  処理部
１１１  メンバ管理表配信部
１１２  メンバ管理表更新部
１１３  代表メンバ特定部
１１４  他メンバ死活監視部
１２０  記憶部
１２１  メンバ管理表
１２２  代表メンバ選出規則
１２３  監視先メンバ設定規則
１３０  入出力部
２００  非代表メンバ
２１０  処理部
２１１  代表メンバ特定部
２１２  他メンバ死活監視部
２２０  記憶部
２２２  代表メンバ選出規則
２２３  監視先メンバ設定規則
２３０  入出力部
【図１】
0005848743.tif 000002
【図２】
0005848743.tif 000003
【図３】
0005848743.tif 000004
【図４】
0005848743.tif 000005
【図５】
0005848743.tif 000006
【図６】
0005848743.tif 000007
【図７】
0005848743.tif 000008
【図８】
0005848743.tif 000009
【図９】
0005848743.tif 000010
【図１０】
0005848743.tif 000011
【図１１】
0005848743.tif 000012
【図１２】
0005848743.tif 000013
【図１３】
0005848743.tif 000014
【図１４】
0005848743.tif 000015