JP5381998B2 - クラスタ制御システム、クラスタ制御方法、及びプログラム - Google Patents

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２００８−３０８３６８号（２００８年１２月 ３日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、クラスタ制御システム、クラスタ制御方法、及びプログラムに関し、特に分散型ロードバランスクラスタの制御を行うクラスタ制御システム、クラスタ制御方法、及びプログラムに関する。

システムの耐障害性や拡張性のために、サーバをクラスタ化することが多くなっている。従来は、現用系と待機系の２系統を用意して、現用系に問題が発生したときには待機系に切り替えて運用を継続するフェイルオーバクラスタが多く用いられていた。しかし、フェイルオーバクラスタでは、通常時の待機系がリソースとして有効活用されないという欠点がある。地球温暖化問題をきっかけに消費電力がクローズアップされる中、両系で処理を受け持つロードバランスクラスタが求められる。

ロードバランスクラスタは、大きく分類すると、シングルＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス型と、マルチＩＰアドレス型に分けられる。

シングルＩＰアドレス型は、全てのクライアントに対して、サーバ側のＩＰアドレスが１つに見え、複数のサーバがあたかも１つのサーバであるかのように見える方式である。

それに対して、マルチＩＰアドレス型は、クライアントによって異なるＩＰアドレスを見せ、対応するサーバに対してアクセスさせる方式である。マルチＩＰアドレス方式では、異なるＩＰアドレスを１つに見せるために、ＩＰアドレス自体を解決する名前解決（サーバ名からＩＰアドレスを解決すること）のレイヤで１つのサーバ名が異なるＩＰアドレスになるようにする。マルチＩＰアドレス方式の代表的な方式として、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ）ロードバランス等が知られている。

すなわち、マルチＩＰアドレス方式では、ＤＮＳのような名前解決手段が必要であり、異なるＩＰアドレスがクライアントに見えるためにアプリケーションのレベルで問題が発生する可能性がある。

従って、ロードバランスクラスタにおいては、アプリケーションへの影響を考慮しなくて良いシングルＩＰアドレス型が望ましい。

シングルＩＰアドレス型は、以下の２つの方式に大別できる。

１つ目の方式は、代表ノード型である。この方式は、クライアントに見せるシングルＩＰアドレスを持つ１つの代表ノードと、それぞれのＩＰアドレスを持つ複数のバックエンドノードを有する。この方式では、クライアントからのパケットは全て代表ノードを通り、セッション毎に割り当てられたバックエンドノードに転送される。このとき、応答パケットが代表ノードを経由する方式と、応答パケットが代表ノードを経由せずに直接クライアントに返る方式がある。通常、代表ノードがクライアントからのパケットを全て受けてロードバランスをするので、いろいろな情報を持ちつつ、様々なロードバランスアルゴリズムを適用することができるというメリットがある。デメリットとしては、代表ノードが性能ボトルネックになりがちなこと、ＳＰＯＦ（Ｓｉｎｇｌｅ Ｐｏｉｎｔ Ｏｆ Ｆａｉｌｕｒｅ：単一障害点）になることが挙げられる。そのため、代表ノードは、ハードウエアベースでＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：カスタムＩＣ）を用いて実装されたりもする。

２つ目の方式は、分散型である。この方式は、全てのノードが同じＩＰアドレスを持ち、クライアントからのパケットが全てのノードに届くようにする。届いたパケットに対し、１つのノードが処理をして返す。処理するノードを決めるために、クライアントのＩＰアドレスをキーとする方式が一般的である。この方式では、自ノードが処理するかをパケット毎に即座に決定しなければならないため、複雑なロードバランスアルゴリズムは適用できない。分散型は、代表ノード型と違ってＳＰＯＦはなく、ノードがボトルネックとなることは少ない。デメリットとして、前述のように即座にパケット受け入れを決定しなければならないため、柔軟なロードバランスアルゴリズムの適用は難しく、特定のノードに負荷が集中する可能性があること、全てのノードにパケットを届けるためにＨＵＢやスイッチのポートミラーリングを用いるため、ネットワーク自体がボトルネックとなることが挙げられる。非特許文献１では、分散型でありつつマスタノードを設け、柔軟なロードバランスアルゴリズムの適用を可能にしている。

このように、シングルＩＰアドレス型では、代表ノード型と分散型があるが、総合的に判断すると、ＳＰＯＦやボトルネックになるノードがない分散型が望ましい。

しかし、分散型は、ネットワークがボトルネックとなることや、ＨＵＢやポートミラーリングが必要なこと、単純なロードバランスアルゴリズムしか適用できないことが欠点として残っている。

非特許文献１では、分散型で柔軟なロードバランスアルゴリズムを適用可能にしているが、他の欠点は、解決できていない。つまり、シングルＩＰアドレス型で、柔軟なロードバランスが可能であり、拡張性もあり、特別なネットワークを必要としない方式は、実現できていない。

なお、関連する技術として、特開２００４−０４６４４２号公報（特許文献１）に負荷分散方法が開示されている。この関連技術では、負荷分散システムは、ネットワークで接続されたコンピュータであるクラアント端末と、コンピュータであるアプリケーションサーバ群からなり、クラアントにサーバでの処理やコンテンツ等、様々なサービスを提供する。

また、特開２００５−１６７４２５号公報（特許文献２）にネットワーク電話システム、このネットワーク電話システムの主装置及びネットワーク電話システムを利用した接続情報更新方法が開示されている。この関連技術では、主装置は、他の主装置から追加、変更または削除されたＩＰアドレスを受信した場合に、記憶部に記憶されたテーブル中の該当するＩＰアドレスの追加、変更または削除を行う。

また、特開２００６−２５９８４５号公報（特許文献３）にサーバ装置、サーバシステムおよびサーバシステムの負荷分散方法が開示されている。この関連技術では、ネットワークは、単一のＩＰアドレスを共有する全てのノードが接続される。ノードの種別には、マスタとスレーブがある。ネットワークに接続されているノードのうち、ただひとつのノードがマスタとなり、それ以外のノードは全てスレーブとなる。ネットワークは、単一のＩＰアドレスのみの使用で、複数ノードを論理的に単一のノードに見せる。また、未知／既知のクライアントからＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求を受信する。なお、ＡＲＰは、ＩＰアドレスからＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを解決するためのプロトコルである。

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

「柔軟な負荷分散を可能にする分散型シングルＩＰクラスタ」情報処理学会 研究報告２００７−ＯＳ−１０６（１）、２００７／８／３

上記特許文献１〜３及び非特許文献１の全開示内容はその引用をもって本書に繰込み記載する。
以下に本発明による関連技術の分析を与える。
本発明の目的は、シングルＩＰアドレス型でクライアント単位のロードバランスを行うクラスタ制御システムを提供することである。

本発明の第１の視点に係るクラスタ制御システムは、複数のクライアントと、複数のクライアントの各々とフロントネットワークを介して接続するサーバ群と、サーバ群とバックエンドネットワークを介して接続し、サーバ群を管理するマスタコンピュータとを含む。サーバ群は、フロントネットワークに対して、同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータを含む。複数のスレーブコンピュータの各々は、夫々が受け持つクライアントを示す担当クライアントテーブルと、複数のクライアントの各々からシングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、担当クライアントテーブルを参照し、担当クライアントテーブルにＡＲＰ要求を出したクライアントが存在すればＡＲＰ応答を返し、担当クライアントテーブルにＡＲＰ要求を出したクライアントが存在しなければＡＲＰ応答をしない処理を行うＡＲＰ処理手段（ＡＲＰ処理部）とを具備する。マスタコンピュータは、バックエンドネットワークを介して、担当クライアントテーブルに対し、複数のスレーブコンピュータの各々が受け持つクライアントの追加・変更・削除に関する情報の維持管理を行う担当ノード決定処理手段（担当ノード決定処理部）を具備する。

本発明の第２の視点に係るクラスタ制御方法では、複数のクライアントの各々とサーバ群とをフロントネットワークを介して接続する。また、サーバ群を管理するマスタコンピュータとサーバ群とをバックエンドネットワークを介して接続する。また、サーバ群からフロントネットワークに対してシングルＩＰアドレスを提示し、サーバ群に含まれる複数のスレーブコンピュータが同一のＩＰアドレスであるように見せる。また、サーバ群に対して、複数のクライアントの各々からシングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、複数のスレーブコンピュータの各々が夫々受け持つクライアントを示す担当クライアントテーブルを参照し、担当クライアントテーブルにＡＲＰ要求を出したクライアントが存在すればＡＲＰ応答を返し、担当クライアントテーブルにＡＲＰ要求を出したクライアントが存在しなければＡＲＰ応答をしない処理を行う。また、バックエンドネットワークを介して、マスタコンピュータから担当クライアントテーブルに対し、複数のスレーブコンピュータの各々が受け持つクライアントの追加・変更・削除に関する情報の維持管理を行う。さらに、複数のスレーブコンピュータの各々は、クライアントが追加された場合には前記クライアントに対してＡＲＰ応答を送信する。
本発明の第３の視点に係るスレーブコンピュータは、複数のクライアントとフロントネットワークを介して接続するとともに、該フロントネットワークに対して同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータのうちの一のスレーブコンピュータであって、
自身が受け持つクライアントを示す担当クライアントテーブルと、
前記複数のクライアントのいずれか１つから前記シングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、前記担当クライアントテーブルを参照し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在する場合にはＡＲＰ応答を返し、それ以外の場合にはＡＲＰ応答をしないＡＲＰ処理部とを備え、
前記担当クライアントテーブルにおけるクライアントの追加、変更又は削除を、バックエンドネットワークを介して接続されたマスタコンピュータによって行われる。
本発明の第４の視点に係るマスタコンピュータは、複数のクライアントとフロントネットワークを介して接続するとともに該フロントネットワークに対して同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータとバックエンドネットワークを介して接続し、該複数のスレーブコンピュータを管理するマスタコンピュータであって、
前記複数のスレーブコンピュータのそれぞれが受け持つクライアントを示す担当クライアントテーブルに対し、前記バックエンドネットワークを介して、クライアントの追加、変更又は削除を行う担当ノード決定処理部を備えている。
本発明の第５の視点に係るクラスタ制御方法は、
複数のクライアントとフロントネットワークを介して接続するとともに、該フロントネットワークに対して同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータの各スレーブコンピュータが、
前記複数のクライアントのいずれか１つから前記シングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、自身が受け持つクライアントを示す担当クライアントテーブルを参照し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在する場合にはＡＲＰ応答を返し、それ以外の場合にはＡＲＰ応答をしない工程と、
前記担当クライアントテーブルにおけるクライアントの追加、変更又は削除を、バックエンドネットワークを介して接続されたマスタコンピュータによって行われる工程とを含む。
本発明の第６の視点に係るプログラムは、
複数のクライアントとフロントネットワークを介して接続するとともに、該フロントネットワークに対して同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータの各スレーブコンピュータに、
前記複数のクライアントのいずれか１つから前記シングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、自身が受け持つクライアントを示す担当クライアントテーブルを参照し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在する場合にはＡＲＰ応答を返し、それ以外の場合にはＡＲＰ応答をしない処理と、
前記担当クライアントテーブルにおけるクライアントの追加、変更又は削除を、バックエンドネットワークを介して接続されたマスタコンピュータによって行われる処理とを実行させる。

このように、本発明では、ＡＲＰプロトコルのレイヤでロードバランスを行い、クライアントからのＡＲＰリクエストに対して、異なるＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを返してやることで、クライアント単位のロードバランスを行う。なお、ＡＲＰは、ＩＰアドレスからＭＡＣアドレスを解決するためのプロトコルである。

シングルＩＰアドレス型で、柔軟なロードバランスと拡張性を実現できる。

図１は、本発明の第１実施形態のシステム構成を示す（ブロック）図である。 図２は、本発明の第１実施形態のマスタノードとスレーブノードの内部構成を示す（ブロック）図である。 図３は、本発明の第１実施形態のテーブル構成を示す図である。 図４は、本発明の第１実施形態の担当ノード決定処理部の（動作）フローを示すフローチャートである。 図５は、本発明の第１実施形態のＡＲＰ処理部の（動作）フローを示すフローチャートである。 図６は、本発明の第１実施形態のＡＲＰ通知部の（動作）フローを示すフローチャートである。 図７は、本発明の第１実施形態のノード間通信を示す図である。 図８は、本発明の第１実施形態のシステムの（動作）フローを示す（シーケンス）図である。 図９は、本発明の第２実施形態のシステム構成を示す（ブロック）図である。 図１０は、本発明の第２実施形態のマスタノードとスレーブノードの内部構成を示す（ブロック）図である。

第１の展開形態のクラスタ制御システムは、上記第１の視点に係るクラスタ制御システムであることが好ましい。
第２の展開形態のクラスタ制御システムは、前記複数のスレーブコンピュータの各々が、前記担当クライアントテーブルに存在しないクライアントからＡＲＰ要求を受け取ると、前記マスタコンピュータに対して、新規クライアントとして、前記クライアントのＩＰアドレス及びＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを通知するＡＲＰ通知部を更に具備することが好ましい。
第３の展開形態のクラスタ制御システムは、
前記複数のスレーブコンピュータの各々が、前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断するための通知フラグを更に具備し、
前記ＡＲＰ通知部は、前記通知フラグを確認して、前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断することが好ましい。
第４の展開形態のクラスタ制御システムは、
前記マスタコンピュータが、前記複数のスレーブコンピュータの各々に対するクライアントの割当を記憶するためのクライアント割当テーブルと、
前記複数のスレーブコンピュータの各々の状態を管理するためのスレーブノードテーブルと
を更に具備し、
前記担当ノード決定処理部が、前記複数のスレーブコンピュータの各々が前記新規クライアントからのＡＲＰ要求を受け取ったことを検出すると、前記クライアント割当テーブル及び前記スレーブノードテーブルを参照し、前記新規クライアントに対してスレーブコンピュータが既に割当済みであれば、前記割り当てられたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行い、前記新規クライアントに対してスレーブコンピュータの割当がなければ、前記スレーブノードテーブルを参照して、前記複数のスレーブコンピュータのうちいずれか１つのスレーブコンピュータを選択し、前記選択されたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行うことが好ましい。
第５の展開形態のクラスタ制御システムは、
前記担当ノード決定処理部が、前記スレーブノードテーブルにおける前記スレーブコンピュータの増減や、前記スレーブコンピュータ間の負荷が不均等になっていることを検出したことに伴い、前記複数のスレーブコンピュータの各々の担当クライアントテーブルにおけるクライアントのＩＰアドレス及びＭＡＣアドレスの追加・削除を行い、前記複数のスレーブコンピュータの負荷が均等になるように再配置を行うことが好ましい。
第６の展開形態のクラスタ制御システムは、
前記担当ノード決定処理部が、前記複数のスレーブコンピュータの各々に対して、コマンドとＩＰアドレスとＭＡＣアドレスとを含むデータを送信し、
前記コマンドの種類は、追加・削除・全削除があり、
前記複数のスレーブコンピュータの各々が、前記コマンドと前記ＩＰアドレスと前記ＭＡＣアドレスとを含むデータを受け取ると、前記コマンドに従い、前記担当クライアントテーブルに対して、前記ＩＰアドレスと前記ＭＡＣアドレスとの追加・削除・全削除を行い、追加コマンドの場合には前記ＩＰアドレスと前記ＭＡＣアドレスで指定されるクライアントに対してＡＲＰ応答を送信し、前記コマンドに応じた処理が正常に終了したか否かを示す情報を前記マスタコンピュータに返すことが好ましい。
第７の展開形態のコンピュータは、上記のクラスタ制御システムで、前記複数のスレーブコンピュータの１つとして使用されるコンピュータであることが好ましい。
第８の展開形態のコンピュータは、上記のクラスタ制御システムで、前記マスタコンピュータとして使用されるコンピュータであることが好ましい。
第９の展開形態のクラスタ制御方法は、上記第２の視点に係るクラスタ制御方法であることが好ましい。
第１０の展開形態のクラスタ制御方法は、前記複数のスレーブコンピュータの各々が前記担当クライアントテーブルに存在しないクライアントからＡＲＰ要求を受け取ると、前記複数のスレーブコンピュータの各々から前記マスタコンピュータに対して、新規クライアントとして、前記クライアントのＩＰアドレス及びＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを通知するステップを更に含むことが好ましい。
第１１の展開形態のクラスタ制御方法は、前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断するための通知フラグを確認して、前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断するステップを更に含むことが好ましい。
第１２の展開形態のクラスタ制御方法は、
前記マスタコンピュータに、前記複数のスレーブコンピュータの各々に対するクライアントの割当を記憶するためのクライアント割当テーブルを設けるステップと、
前記マスタコンピュータに、前記複数のスレーブコンピュータの各々の状態を管理するためのスレーブノードテーブルを設けるステップと、
前記複数のスレーブコンピュータの各々が前記新規クライアントからのＡＲＰ要求を受け取ったことを検出すると、前記クライアント割当テーブル及び前記スレーブノードテーブルを参照するステップと、
前記新規クライアントに対してスレーブコンピュータが既に割当済みであれば、前記マスタコンピュータから前記割り当てられたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行うステップと、
前記新規クライアントに対してスレーブコンピュータの割当がなければ、前記スレーブノードテーブルを参照して、前記複数のスレーブコンピュータのうちいずれか１つのスレーブコンピュータを選択し、前記マスタコンピュータから前記選択されたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行うステップとを更に含むことが好ましい。
第１３の展開形態のクラスタ制御方法は、前記スレーブノードテーブルにおける前記スレーブコンピュータの増減や、前記スレーブコンピュータ間の負荷が不均等になっていることを検出したことに伴い、前記複数のスレーブコンピュータの各々の担当クライアントテーブルにおけるクライアントのＩＰアドレス及びＭＡＣアドレスの追加・削除を行い、前記複数のスレーブコンピュータの負荷が均等になるように再配置を行うステップを更に含むことが好ましい。
第１４の展開形態のクラスタ制御方法は、
前記マスタコンピュータから前記複数のスレーブコンピュータの各々に対して、コマンドとＩＰアドレスとＭＡＣアドレスとを含むデータを送信するステップと、
前記コマンドの種類は、追加・削除・全削除があり、前記複数のスレーブコンピュータの各々が前記コマンドと前記ＩＰアドレスと前記ＭＡＣアドレスとを含むデータを受け取ると、前記コマンドに従い、前記担当クライアントテーブルに対して、前記ＩＰアドレスと前記ＭＡＣアドレスとの追加・削除・全削除を行い、前記コマンドに応じた処理が正常に終了したか否かを示す情報を前記マスタコンピュータに返すステップとを更に含むことが好ましい。
第１５の展開形態のプログラムは、上記のクラスタ制御方法における前記複数のスレーブコンピュータの各々の動作を、コンピュータに実行させることが好ましい。
第１６の展開形態のプログラムは、上記のクラスタ制御方法における前記マスタコンピュータの動作を、コンピュータに実行させることが好ましい。
第１７の展開形態のスレーブコンピュータは、上記第３の視点に係るスレーブコンピュータであることが好ましい。
第１８の展開形態のスレーブコンピュータは、前記担当クライアントテーブルに存在しないクライアントからＡＲＰ要求を受け取ると、前記マスタコンピュータに対して、新規クライアントとして、前記クライアントのＩＰアドレス及びＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを通知するＡＲＰ通知部をさらに備えていることが好ましい。
第１９の展開形態のスレーブコンピュータは、
前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断するための通知フラグをさらに備え、
前記ＡＲＰ通知部は、前記通知フラグを確認して、前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断することが好ましい。
第２０の展開形態のマスタコンピュータは、上記第４の視点に係るマスタコンピュータであることが好ましい。
第２１の展開形態のクラスタ制御システムは、上記のスレーブコンピュータと、上記のマスタコンピュータとを備えていることが好ましい。
第２２の展開形態のクラスタ制御システムは、
前記マスタコンピュータが、
前記複数のスレーブコンピュータに対するクライアントの割当を記憶するためのクライアント割当テーブルと、
前記複数のスレーブコンピュータの状態を管理するためのスレーブノードテーブルとをさらに備え、
前記担当ノード決定処理部は、前記複数のスレーブコンピュータの各々が前記新規クライアントからのＡＲＰ要求を受け取ったことを検出すると、前記クライアント割当テーブル及び前記スレーブノードテーブルを参照し、前記新規クライアントに対してスレーブコンピュータが既に割当済みであれば、前記割り当てられたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行い、前記新規クライアントに対してスレーブコンピュータの割当がなければ、前記スレーブノードテーブルを参照して、前記複数のスレーブコンピュータのうちいずれか１つのスレーブコンピュータを選択し、前記選択されたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加することが好ましい。
第２３の展開形態のクラスタ制御システムは、前記担当ノード決定処理部が、前記スレーブノードテーブルにおける前記複数のスレーブコンピュータの増減、又は、前記複数のスレーブコンピュータ間の負荷が不均等になっていることを検出したことに伴い、前記複数のスレーブコンピュータの各々の担当クライアントテーブルにおけるクライアントのＩＰアドレス及びＭＡＣアドレスの追加・削除を行い、前記複数のスレーブコンピュータの負荷が均等になるように再配置を行うことが好ましい。
第２４の展開形態のクラスタ制御システムは、
前記担当ノード決定処理部が、前記複数のスレーブコンピュータの各々に対して、コマンドとＩＰアドレスとＭＡＣアドレスとを含むデータを送信し、
前記コマンドの種類は、追加・削除・全削除があり、
前記複数のスレーブコンピュータの各々は、前記コマンドと前記ＩＰアドレスと前記ＭＡＣアドレスとを含むデータを受け取ると、前記コマンドに従い、前記担当クライアントテーブルに対して、前記ＩＰアドレスと前記ＭＡＣアドレスとの追加・削除・全削除を行い、追加コマンドの場合には前記ＩＰアドレスと前記ＭＡＣアドレスで指定されるクライアントに対してＡＲＰ応答を送信し、前記コマンドに応じた処理が正常に終了したか否かを示す情報を前記マスタコンピュータに返すことが好ましい。
第２５の展開形態のクラスタ制御方法は、上記第５の視点に係るクラスタ制御方法であることが好ましい。
第２６の展開形態のプログラムは、上記第６の視点に係るプログラムであることが好ましい。
＜第１実施形態＞
以下に、本発明の第１実施形態について添付図面を参照して説明する。
図１は、本発明のクラスタ制御システムのシステム構成を示したものである。
本発明のクラスタ制御システムは、複数のクライアント１（１−ｉ、ｉ＝１〜ｎ：ｎはクライアント数）と、フロントネットワーク１０と、サーバ群２と、バックエンドネットワーク２０と、マスタノード３を含む。

クライアント１（１−ｉ、ｉ＝１〜ｎ）の各々は、フロントネットワーク１０を介してサーバ群２と通信する。

サーバ群２は、フロントネットワーク１０に対して、シングルＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを提示し、サーバ群２自体が１つのサーバであるかのように見せる。つまり、サーバ群２は、クライアント１（１−ｉ、ｉ＝１〜ｎ）から見ると、シングルＩＰアドレスの１つのサーバに見える。サーバ群２は、バックエンドネットワーク２０を介してマスタノード３と通信する。ここでは、サーバ群２は、複数のスレーブノード４（４−ｊ、ｊ＝１〜ｍ：ｍはスレーブノード数）を含む。

マスタノード３は、サーバ群２とバックエンドネットワーク２０を介して接続し、サーバ群２を管理する。

複数のスレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々は、フロントネットワーク１０及びバックエンドネットワーク２０に接続しており、クライアント１（１−ｉ、ｉ＝１〜ｎ）及びマスタノード３と通信する。各スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、バックエンドネットワーク２０に対しては、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）毎に異なるＩＰアドレスを持ち、特定のスレーブノード４（４−ｊ、ｊ＝１〜ｍ）を指定した通信が可能となっている。

クライアント１（１−ｉ、ｉ＝１〜ｎ）、マスタノード３、及びスレーブノード４（４−ｊ、ｊ＝１〜ｍ）の例として、ＰＣ（パソコン）、シンクライアント端末／サーバ、ワークステーション、メインフレーム、スーパーコンピュータ等のコンピュータが考えられる。但し、実際には、これらの例に限定されない。

フロントネットワーク１０及びバックエンドネットワーク２０の例として、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ ＬＡＮ）、ケーブルテレビ（ＣＡＴＶ）回線、固定電話網、携帯電話網、専用線等が考えられる。但し、実際には、これらの例に限定されない。

なお、制限事項として、フロントネットワーク１０は、ＩＰネットワークであり、サーバ群２に属するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、全て同一セグメントに属することとする。同一セグメントに属するということは、間にルータを介さないということであり、ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が全スレーブノード４（４−ｊ、ｊ＝１〜ｍ）に同報（ブロードキャスト）されることを意味する。なお、ＡＲＰは、ＩＰアドレスからＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを解決するためのプロトコルである。

バックエンドネットワーク２０は、必ずしもＩＰネットワークに限定されるわけではなく、何らかのアドレスが振られて通信が可能なネットワークであれば何でも良い。

＜マスタノード及びスレーブノードの内部構成＞
図２を参照して、本発明のマスタノード３、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の内部構成について説明する。

マスタノード３は、担当ノード決定処理部３１と、クライアント割当テーブル３２と、スレーブノードテーブル３３と、ノード死活管理部３４を備える。

担当ノード決定処理部３１は、新たなクライアント１（１−ｉ、ｉ＝１〜ｎ）をどのスレーブノード４（４−ｊ、ｊ＝１〜ｍ）に割り当てるかを決定し、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）に対して追加・削除・全削除コマンドを発行する処理を行う。担当ノード決定処理部３１は、新規のクライアント１（１−ｉ、ｉ＝１〜ｎ）が割り当てられるスレーブノード４（４−ｊ、ｊ＝１〜ｍ）を決定をするために、クライアント割当テーブル３２とスレーブノードテーブル３３の情報を用いる。

クライアント割当テーブル３２は、マスタノード３が持つテーブルである。クライアント割当テーブル３２は、現在どのクライアント１（１−ｉ、ｉ＝１〜ｎ）がどのスレーブノード４（４−ｊ、ｊ＝１〜ｍ）に割り当てられているかを記憶している。また、クライアント割当テーブル３２は、そのクライアント１（１−ｉ、ｉ＝１〜ｎ）から最後にＡＲＰ要求が来た時刻を記憶している。

スレーブノードテーブル３３は、マスタノード３が持つテーブルである。スレーブノードテーブル３３は、各スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の現在の状態を記憶している。

ノード死活管理部３４は、各スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の状態を管理する。例えば、ノード死活管理部３４は、「Ｐｉｎｇ」のような方法でスレーブノード４（４−ｊ、ｊ＝１〜ｍ）が正常に起動しているかをチェックする機能を持つ。

スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々は、ＡＲＰ処理部４１と、担当クライアントテーブル４２と、テーブル管理部４３と、ＡＲＰ通知部４４と、通知フラグ４５を備える。

ＡＲＰ処理部４１は、フロントネットワーク１０側からのＡＲＰ要求に対して、担当クライアントテーブル４２を参照し、ＡＲＰ応答を選択的に破棄する機能を持つ。ＡＲＰ処理部４１は、担当クライアントテーブル４２を参照して、ＡＲＰ要求を出してきたクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスを検索し、ＡＲＰ要求を出してきたクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスが担当クライアントテーブル４２内にあれば、ＡＲＰ応答を返し、ＡＲＰ要求を出してきたクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスが担当クライアントテーブル４２内になければ、ＡＲＰ応答をしない。

担当クライアントテーブル４２は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々が持つテーブルである。担当クライアントテーブル４２は、いずれかのクライアント１（１−ｉ、ｉ＝１〜ｎ）から最後にアクセス要求が来た時刻を記憶している。

テーブル管理部４３は、マスタノード３からのクライアント追加・削除・全削除コマンドを受け取り、それに応じて担当クライアントテーブル４２を操作する。

ＡＲＰ通知部４４は、ＡＲＰ処理部４１からの指示に応じて、担当クライアントテーブル４２にないクライアントからＡＲＰ要求を受信したことをマスタノード３へ通知する機能を持つ。ここでは、ＡＲＰ通知部４４は、マスタノード３への通知として、クライアント割当要求をマスタノード３へ送信する。クライアント割当要求は、担当クライアントテーブル４２にないクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレス及びＭＡＣアドレスを含む。このとき、ＡＲＰ通知部４４は、マスタノード３へ通知するか否かについては、通知フラグ４５によって判断する。

通知フラグ４５を設けている理由は、全てのスレーブノード４（４−ｊ、ｊ＝１〜ｍ）からＡＲＰ要求受信を受けているとマスタノード３の負荷が上がるため、ＡＲＰ要求受信を通知するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）を限定する目的である。もちろん、通知するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、１つに限定される必要はなく、信頼性確保のために複数のスレーブノード４（４−ｊ、ｊ＝１〜ｍ）に通知フラグ４５を設定しても構わない。

＜テーブル類の詳細＞
図３を参照して、上記説明したテーブル類（クライアント割当テーブル３２、スレーブノードテーブル３３、担当クライアントテーブル４２）の詳細について説明する。

クライアント割当テーブル３２は、「クライアントＩＰアドレス」と、「クライアントＭＡＣアドレス」と、「割当スレーブノードＩＰアドレス」と、「最終ＡＲＰ時刻（Ｌａｓｔ ＡＲＰ Ｔｉｍｅ）」のフィールドを含む。

スレーブノードテーブル３３は、「スレーブノードＩＰアドレス」と、「状態」と、「最終アクセス時刻（Ｌａｓｔ Ａｃｃｅｓｓ Ｔｉｍｅ）」のフィールドを含む。

担当クライアントテーブル４２は、「クライアントＩＰアドレス」と、「クライアントＭＡＣアドレス」と、「最終アクセス時刻（Ｌａｓｔ Ａｃｃｅｓｓ Ｔｉｍｅ）」のフィールドを含む。

次に、各テーブルに含まれるフィールドについて説明する。

「クライアントＩＰアドレス」は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスを格納する。「クライアントＭＡＣアドレス」は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＭＡＣアドレスを格納する。スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、クライアントのＩＰアドレスとＭＡＣアドレスがあれば、そのクライアントだけにＡＲＰ応答するパケットを作成することができる。

「割当スレーブノードＩＰアドレス」及び「スレーブノードＩＰアドレス」は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＩＰアドレスを格納する。なお、「割当スレーブノードＩＰアドレス」は、「クライアントＩＰアドレス」に対応するクライアント１（１−ｉ、ｉ＝１〜ｎ）に割り当てられたスレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＩＰアドレスを格納する。「スレーブノードＩＰアドレス」は、バックエンドネットワーク２０に属するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＩＰアドレスを格納する。

スレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＩＰアドレスは、バックエンドネットワーク２０に割り当てられているＩＰアドレスである。但し、前述したように、バックエンドネットワーク２０は、ＩＰネットワークには、限定されない。何らかのネットワークで、各スレーブノード４（４−ｊ、ｊ＝１〜ｍ）が個別にアクセスできれば良い。

「最終ＡＲＰ時刻（Ｌａｓｔ ＡＲＰ Ｔｉｍｅ）」は、クライアント１（１−ｉ、ｉ＝１〜ｎ）から最後にＡＲＰ要求が来た時刻を示している。ここでは、「最終ＡＲＰ時刻（Ｌａｓｔ ＡＲＰ Ｔｉｍｅ）」は、一定期間が過ぎたらクライアント１（１−ｉ、ｉ＝１〜ｎ）のエントリを削除するために記憶している。

「状態」は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）が正常に起動しネットワークに接続できているかを示している。すなわち、「状態」は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）のネットワーク接続状態を示している。

「最終アクセス時刻（Ｌａｓｔ Ａｃｃｅｓｓ Ｔｉｍｅ）」は、最後にネットワークを経由したアクセスが行われた時刻を示している。なお、スレーブノードテーブル３３の「最終アクセス時刻（Ｌａｓｔ Ａｃｃｅｓｓ Ｔｉｍｅ）」は、マスタノード３において、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）から最後にアクセスがあった時刻を示している。また、担当クライアントテーブル４２の「最終アクセス時刻（Ｌａｓｔ Ａｃｃｅｓｓ Ｔｉｍｅ）」は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々において、クライアント１（１−ｉ、ｉ＝１〜ｎ）から最後にアクセスがあった時刻を示している。ここでは、「最終アクセス時刻（Ｌａｓｔ Ａｃｃｅｓｓ Ｔｉｍｅ）」は、定期的に状態を確認するため、或いは、エラー状態であった場合に、復帰しているかを確認するために記憶しておく。

＜担当ノード決定処理部の動作フロー＞
図４を参照して、マスタノード３の担当ノード決定処理部３１の動作フローについて説明する。

（１）ステップＳ１０１
まず、担当ノード決定処理部３１は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＡＲＰ通知部４４を通じて新たなクライアント割当要求を受信する。

（２）ステップＳ１０２
担当ノード決定処理部３１は、クライアント割当要求に含まれるクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスを基に、クライアント割当テーブル３２を検索する。

（３）ステップＳ１０３
担当ノード決定処理部３１は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレス、及び、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスに対応するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＩＰアドレスがクライアント割当テーブル３２に登録されているか確認する。

（４）ステップＳ１０４
担当ノード決定処理部３１は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレス、及び、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスに対応するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＩＰアドレスのうち少なくとも一方がクライアント割当テーブル３２に登録されていない場合、当該クライアント１（１−ｉ、ｉ＝１〜ｎ）に対して、新たにクライアント１（１−ｉ、ｉ＝１〜ｎ）を担当するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）を決定する。この決定の仕方は、単純なラウンドロビン、クライアントＩＰアドレスを用いたハッシュ、各スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の負荷状況に応じて割り当てる等の複雑な計算に基づいても良く、柔軟なロードバランスアルゴリズムの選択が可能である。

（５）ステップＳ１０５
担当ノード決定処理部３１は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレス、及び、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスに対応するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＩＰアドレスが既にクライアント割当テーブル３２に登録されている場合、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスに対応するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）のテーブル管理部４３へ、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスとＭＡＣアドレスの追加要求を送信する。或いは、担当ノード決定処理部３１は、新たにクライアント１（１−ｉ、ｉ＝１〜ｎ）を担当するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）を決定したら、そのスレーブノード４（４−ｊ、ｊ＝１〜ｍ）に対して、新たにクライアント１（１−ｉ、ｉ＝１〜ｎ）を担当するよう命令（コマンド）を送信する。すなわち、担当ノード決定処理部３１は、そのスレーブノード４（４−ｊ、ｊ＝１〜ｍ）のテーブル管理部４３へ、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスとＭＡＣアドレスの追加要求を送信する。

（６）ステップＳ１０６
スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスとＭＡＣアドレスの追加要求を受信すると、後述する担当クライアントテーブル４２にクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスを追加し、追加が完了した旨の通知（追加完了通知）をマスタノード３に送信する。このとき、マスタノード３は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）から追加完了通知を受信したか確認する。

（７）ステップＳ１０７
担当ノード決定処理部３１は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）から追加完了通知を受信できなければ、スレーブノードテーブル３３の当該スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の状態フィールドをエラー状態にし、当該スレーブノード４（４−ｊ、ｊ＝１〜ｍ）以外に新たな担当するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）を決定する。例えば、担当ノード決定処理部３１は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）から追加がエラーしたり（担当クライアントテーブル４２に空きがないケース、フロントネットワーク側でリンクダウンを検出しているケース等があり得る）、タイムアウトしたりした場合には、スレーブノードテーブル３３の当該スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の状態フィールドをエラー状態にし、当該スレーブノード４（４−ｊ、ｊ＝１〜ｍ）以外に新たな担当するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）を決定する。

（８）ステップＳ１０８
担当ノード決定処理部３１は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）から追加完了通知を受信すると、スレーブノードテーブル３３の更新を行う。

（９）ステップＳ１０９
また、担当ノード決定処理部３１は、クライアント割当テーブル３２の更新を行う。その後、担当ノード決定処理部３１は、処理を終了する。

＜ＡＲＰ処理部の動作フロー＞
図５を参照して、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＡＲＰ処理部４１の動作フローについて説明する。

（１）ステップＳ２０１
ＡＲＰ処理部４１は、クライアント１（１−ｉ、ｉ＝１〜ｎ）から、フロントネットワーク１０側のＩＰアドレスに対するＡＲＰ要求を受け取る。

（２）ステップＳ２０２
ＡＲＰ処理部４１は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスを基に、担当クライアントテーブル４２を検索する。

（３）ステップＳ２０３
ＡＲＰ処理部４１は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスが担当クライアントテーブル４２に登録されているか確認する。
（４）ステップＳ２０４
ＡＲＰ処理部４１は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスが担当クライアントテーブル４２に登録されていれば、ＡＲＰ応答をクライアント１（１−ｉ、ｉ＝１〜ｎ）に送信し、処理を終了する。

（５）ステップＳ２０５
ＡＲＰ処理部４１は、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスが担当クライアントテーブル４２に登録されていなければ、ＡＲＰ応答を送信せずに破棄する。

（６）ステップＳ２０６
ＡＲＰ処理部４１は、ＡＲＰ通知部４４にクライアント情報を通知して、処理を終了する。なお、クライアント情報は、担当クライアントテーブル４２に登録されていないクライアントであって、ＡＲＰ要求を送信してきたクライアントのＩＰアドレスとＭＡＣアドレスを含むものとする。ここでは、ＡＲＰ処理部４１は、ＡＲＰ通知部４４に当該クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスとＭＡＣアドレスを通知して、処理を終了する。

＜ＡＲＰ通知部の動作フロー＞
図６を参照して、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＡＲＰ通知部４４の動作フローについて説明する。

（１）ステップＳ３０１
ＡＲＰ通知部４４は、ＡＲＰ処理部４１からクライアント情報を受信すると、通知フラグ４５を確認する。ここでは、ＡＲＰ通知部４４は、ＡＲＰ処理部４１からクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスとＭＡＣアドレスを受信すると、通知フラグ４５を確認する。

（２）ステップＳ３０２
ＡＲＰ通知部４４は、通知フラグ４５が通知するように設定されているか否かを確認する。なお、ＡＲＰ通知部４４は、通知フラグ４５が「Ｔｒｕｅ（真）」であれば、通知するように設定されていると判断する。例えば、ＡＲＰ通知部４４は、通知フラグ４５の値が「０」であれば「Ｆａｌｓｅ（偽）」であると判断し、通知フラグ４５の値が「１」であれば「Ｔｒｕｅ（真）」であると判断する。このとき、ＡＲＰ通知部４４は、通知フラグ４５が通知しないように設定されていた場合には、ＡＲＰ通知をせずに、処理を終了する。ここでは、ＡＲＰ通知部４４は、通知フラグ４５が通知しないように設定されていた場合、マスタノード３へクライアント情報を送信せずに、処理を終了する。すなわち、ＡＲＰ通知部４４は、通知フラグ４５が通知しないように設定されていた場合、マスタノード３に対して、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスとＭＡＣアドレスを通知せずに、処理を終了する。

（３）ステップＳ３０３
ＡＲＰ通知部４４は、通知フラグ４５が通知するように設定されていた場合、マスタノード３へクライアント情報を送信し、処理を終了する。ここでは、ＡＲＰ通知部４４は、通知フラグ４５が通知するように設定されていた場合、マスタノード３に対して、クライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスとＭＡＣアドレスを送信し、処理を終了する。

＜マスタノードとスレーブノードの間の通信内容＞
図７を参照して、本実施形態においてマスタノード３とスレーブノード４（４−ｊ、ｊ＝１〜ｍ）の間で通信される内容について説明する。

マスタノード３からスレーブノード４（４−ｊ、ｊ＝１〜ｍ）への通信内容は、「コマンド」と「クライアントＩＰアドレスとＭＡＣアドレスのリスト」を含む。すなわち、マスタノード３は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）に対して、「コマンド」と「クライアントＩＰアドレスとＭＡＣアドレスのリスト」を含むデータを送信する。

スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、マスタノード３から、「コマンド」と「クライアントＩＰアドレスとＭＡＣアドレスのリスト」を含むデータを受信すると、「コマンド」に基づき、担当クライアントテーブル４２の操作を行う。

ここでは、「コマンド」は、「追加（ＡＤＤ）」、「削除（ＤＥＬＥＴＥ）」、及び「全削除（ＣＬＥＡＲ）」のうちの少なくとも１つである。

スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、「追加（ＡＤＤ）」を受信すると、後続のクライアントＩＰアドレスとＭＡＣアドレスのリストを担当クライアントテーブル４２に追加する。更に、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、それらのクライアントに対してＡＲＰ応答を送信する。スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、ＩＰアドレスとＭＡＣアドレスがあれば、そのＩＰアドレスとＭＡＣアドレスを持つクライアントのみにＡＲＰ応答をすることができる。このとき、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、「追加（ＡＤＤ）」を受信した際に、担当クライアントテーブル４２が存在しない場合、担当クライアントテーブル４２を新規に作成するようにしても良い。

スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、「削除（ＤＥＬＥＴＥ）」を受信すると、後続のクライアントＩＰアドレスとＭＡＣアドレスのリストを担当クライアントテーブル４２から削除する。

スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、「全削除（ＣＬＥＡＲ）」を受信すると、担当クライアントテーブル４２内のクライアントＩＰアドレスとＭＡＣアドレスのリストを全て削除（全削除）する。このとき、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、「全削除（ＣＬＥＡＲ）」を受信すると、担当クライアントテーブル４２自体を削除するようにしても良い。

スレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、これらのコマンドを実行した後、実行結果の「コード」をマスタノード３に返す。

「コード」は、「正常終了／エラー」、及び「エラーコード」である。

「正常終了／エラー」は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）でのコマンドの実行が正常終了したか、或いはエラーしたかを示すデータである。例えば、このデータの値が「０」であれば「正常終了」を示し、このデータの値が「１」であれば「エラー」を示す。但し、実際には、これらの例に限定されない。

「エラーコード」は、エラーの種類（タイプ）を示すデータである。なお、エラーコード上では、「正常終了」もエラーの一種として区分するようにしても良い。

スレーブノード４（４−ｊ、ｊ＝１〜ｍ）からマスタノード３への通信内容も「コマンド」と「クライアントＩＰアドレス及びクライアントＭＡＣアドレスのリスト」を含む。すなわち、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）も、マスタノード３に対して、「コマンド」と「クライアントＩＰアドレス及びクライアントＭＡＣアドレスのリスト」を含むデータを送信する。

ここでは、「コマンド」は、「新規（ＮＥＷ）」だけである。すなわち、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）からマスタノード３へ、「新規（ＮＥＷ）」のコマンドが送信される。

マスタノード３は、「コマンド」と「クライアントＩＰアドレス及びクライアントＭＡＣアドレスのリスト」を含むデータを受信すると、クライアントＩＰアドレス及びクライアントＭＡＣアドレスのリストを基に、担当ノード決定処理を行い、実行結果をスレーブノード４（４−ｊ、ｊ＝１〜ｍ）に返す。

以上のように、本発明の実施形態における各処理を説明したが、これにより柔軟かつ拡張性のあるロードバランスが可能であることを以下に説明する。

＜実施例＞
図８を参照して、クライアント１（１−ｉ、ｉ＝１〜ｎ）がサーバ群２に接続する際の処理について詳細に説明する。
ここでは、サーバ群２は、４台のスレーブノード４（４−ｊ、ｊ＝１〜ｍ）を含むものとする。この４台のスレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々を、それぞれ、「スレーブノード＃１」、「スレーブノード＃２」、「スレーブノード＃３」、「スレーブノード＃４」とする。

まず、クライアント１（１−ｉ、ｉ＝１〜ｎ）は、サーバ群２に初めて接続する際、ＩＰアドレスからＭＡＣアドレスを解決するために、ＡＲＰ要求を送信する。

ＡＲＰ要求は、フロントネットワーク１０内のスイッチングハブ又はＨＵＢによって、サーバ群２の全てのスレーブノード４（４−ｊ、ｊ＝１〜ｍ）に同報（ブロードキャスト）される。すなわち、フロントネットワーク１０内のスイッチングハブ又はＨＵＢは、ＡＲＰ要求を、サーバ群２の全てのスレーブノード４（４−ｊ、ｊ＝１〜ｍ）に同報する。

図８の例では、ＡＲＰ要求は、４台のスレーブノード４（４−ｊ、ｊ＝１〜ｍ）があるため、４つに複製されて同報される。この同報は、ＩＰネットワークを構成する機器全てが持つ機能であり、特別なネットワーク構成や装置を一切必要としない。また、現在使われている多くのスイッチングハブにおいては、この同報は、内部でハードウエア的に複製されて行われており、性能上のボトルネックにはなりにくい。また、ＩＰネットワークにおいては、ＳＰＯＦを避けるために数々の既存技術（例えば、スパニングツリー）が存在し、これを用いれば、耐障害性を高めることは容易である。

このようにして同報されたＡＲＰ要求を、全てのスレーブノード４（４−ｊ、ｊ＝１〜ｍ）が受信する。すなわち、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々は、フロントネットワーク１０内のスイッチングハブ又はＨＵＢによって同報されたＡＲＰ要求を受信する。

もし、既に担当ノードが決定していれば、そのスレーブノード４（４−ｊ、ｊ＝１〜ｍ）の担当クライアントテーブル４２に登録されているので、担当スレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＭＡＣアドレスを含むＡＲＰ応答が返り、以降は、担当スレーブノード４（４−ｊ、ｊ＝１〜ｍ）との通信となる。ここでは、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々は、担当クライアントテーブル４２を参照して、ＡＲＰ要求を出してきたクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスを検索し、ＡＲＰ要求を出してきたクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスが担当クライアントテーブル４２内にあれば、ＡＲＰ応答を返し、ＡＲＰ要求を出してきたクライアント１（１−ｉ、ｉ＝１〜ｎ）との通信を行う。

この通信は、担当スレーブノード４（４−ｊ、ｊ＝１〜ｍ）のＭＡＣアドレスを指定して行われるので、同報されることはなく、ネットワークを有効利用することができる。

もし、担当ノードが決定していない場合、或いは、担当ノードが故障していたりする場合には、ＡＲＰ通知部４４からマスタノード３へクライアント割当要求（ＮＥＷコマンド）が送信される。ここでは、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々は、担当クライアントテーブル４２を参照して、ＡＲＰ要求を出してきたクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスを検索し、ＡＲＰ要求を出してきたクライアント１（１−ｉ、ｉ＝１〜ｎ）のＩＰアドレスが担当クライアントテーブル４２内に無ければ、ＡＲＰ応答をせず、マスタノード３へクライアント割当要求（ＮＥＷコマンド）を送信する。なお、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々は、自身が担当ノードでも、故障している場合、当然、ＡＲＰ応答をせず、マスタノード３へクライアント割当要求（ＮＥＷコマンド）を送信しない。

マスタノード３は、クライアント割当要求（ＮＥＷコマンド）を受信すると、担当ノード決定処理部３１が担当ノード決定処理を行い、担当スレーブノード４（４−ｊ、ｊ＝１〜ｍ）にクライアント追加命令（ＡＤＤコマンド）を送信する。

図８の例では、マスタノード３は、担当スレーブノードを、スレーブノード＃１に決定したので、スレーブノード＃１に対してクライアント追加を行っている。他のスレーブノード４（４−ｊ、ｊ＝１〜ｍ）に対しては、何も行わない。すなわち、マスタノード３は、スレーブノード＃１に該当するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）にのみ、クライアント追加命令（ＡＤＤコマンド）を送信する。

スレーブノード＃１に該当するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、クライアント追加命令（ＡＤＤコマンド）を受信すると、ＡＲＰ要求を出してきたクライアント１（１−ｉ、ｉ＝１〜ｎ）を、担当クライアントテーブル４２に登録する。

更に、スレーブノード＃１は、クライアント１に対してＡＲＰ応答を送信する。これにより、クライアント１（１−ｉ、ｉ＝１〜ｎ）は、ＡＲＰ解決ができ、以降は、スレーブノード＃１とのポイント−ポイント通信（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ通信）となる。すなわち、スレーブノード＃１に該当するスレーブノード４（４−ｊ、ｊ＝１〜ｍ）は、自身が担当するクライアント１（１−ｉ、ｉ＝１〜ｎ）に対して、ＡＲＰ応答を返し、通信接続を確立する。

なお、クライアント１（１−ｉ、ｉ＝１〜ｎ）は、ＡＲＰ要求に対する応答がない場合には、一定期間をおいて再送する機能を持っている。これ（再送機能）は、ネットワーク上でパケットが廃棄される場合や何らかの障害に備えての機能であり、ほぼ全てのクライアント実装で再送することが確認できている。従って、もしスレーブノード＃１からのＡＲＰ応答が何らかの障害によりクライアント１に届かなかった場合には、クライアント１はＡＲＰ要求を再送し、スレーブノード＃１は再度ＡＲＰ応答を送信する。このとき、スレーブノード＃１は、ネットワーク上でのパケットロスに備えて、クライアント追加命令（ＡＤＤコマンド）を受けると、一定期間を置いて複数のＡＲＰ応答を送信するようにしても良い。

この方式のポイントとして、以下の２つの利点が挙げられる。

１つ目は、ロードバランスアルゴリズムをマスタノード３で集中的に行うために、柔軟なアルゴリズムが実現できることである。既存の分散型ロードバランスでは、各ノードが独立して自分の担当かを判断しなければならないため、単純なアルゴリズムしか実装できないが、本発明では、アルゴリズム実装をマスタノード３に集中させており、課題を解決している。

２つ目は、ＡＲＰ解決を用いているため、ＡＲＰ解決後は、クライアントと担当ノードのポイントーポイント通信になり、拡張性が高いことである。つまり、全てのパケットが集中する部分がなく、ノードを追加してスイッチングハブでネットワークを組めば性能が拡張できる。ＡＲＰの同報をする部分とマスタノード３が担当ノード決定をする部分に負荷が集中する可能性もあるが、ＡＲＰ要求は、一度ＡＲＰ解決してしまえば、しばらくは出ないため、マスタノード３にとって大きな負荷とはならない。

＜第２実施形態＞
以下に、本発明の第２実施形態について説明する。
図９は、本実施形態におけるクラスタ制御システムのシステム構成を示したものである。
本実施形態におけるクラスタ制御システムは、複数のクライアント１（１−ｉ、ｉ＝１〜ｎ：ｎはクライアント数）と、フロントネットワーク１０と、サーバ群２と、バックエンドネットワーク２０を含む。

ここでは、フロントネットワーク１０側は、図１と同じ構成であるが、バックエンドネットワーク２０のマスタノード３がサーバ群２の中に入った構成となっている。

クライアント１（１−ｉ、ｉ＝１〜ｎ）、フロントネットワーク１０、バックエンドネットワーク２０については、第１実施形態と同様である。

ここでは、サーバ群２は、マスタノード３と、複数のスレーブノード４（４−ｊ、ｊ＝１〜ｍ：ｍはスレーブノード数）を含む。

この場合、マスタノード３は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の機能も併せ持つ。

＜マスタノード及びスレーブノードの内部構成＞
図１０を参照して、本実施形態におけるマスタノード３、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の内部構成について説明する。

本実施形態におけるマスタノード３は、第１実施形態におけるマスタノード３とスレーブノード４（４−ｊ、ｊ＝１〜ｍ）の機能を両方持った形となっている。

ここでは、マスタノード３は、担当ノード決定処理部３１と、クライアント割当テーブル３２と、スレーブノードテーブル３３と、ノード死活管理部３４と、ＡＲＰ処理部３５と、担当クライアントテーブル３６と、テーブル管理部３７と、ＡＲＰ通知部３８と、通知フラグ３９を備える。

また、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）の各々は、ＡＲＰ処理部４１と、担当クライアントテーブル４２と、テーブル管理部４３と、ＡＲＰ通知部４４と、通知フラグ４５を備える。

担当ノード決定処理部３１、クライアント割当テーブル３２、スレーブノードテーブル３３、ノード死活管理部３４、ＡＲＰ処理部４１、担当クライアントテーブル４２、テーブル管理部４３、ＡＲＰ通知部４４、及び通知フラグ４５については、第１実施形態と同様である。

ＡＲＰ処理部３５は、ＡＲＰ処理部４１と同様である。すなわち、ＡＲＰ処理部３５は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）におけるＡＲＰ処理部４１に相当する。

担当クライアントテーブル３６は、担当クライアントテーブル４２と同様である。すなわち、担当クライアントテーブル３６は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）における担当クライアントテーブル４２に相当する。

テーブル管理部３７は、テーブル管理部４３と同様である。すなわち、テーブル管理部３７は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）におけるテーブル管理部４３に相当する。

ＡＲＰ通知部３８は、ＡＲＰ通知部４４と同様である。すなわち、ＡＲＰ通知部３８は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）におけるＡＲＰ通知部４４に相当する。

通知フラグ３９は、通知フラグ４５と同様である。すなわち、通知フラグ３９は、スレーブノード４（４−ｊ、ｊ＝１〜ｍ）における通知フラグ４５に相当する。

＜第３実施形態＞
以下に、本発明の第３実施形態について説明する。
前述の各実施形態によりクライアント１をスレーブノード４に分散して割り当てることができる。各スレーブノード４の負荷を均等にすれば、全体としてはスレーブノード４の数に比例した処理性能を得ることができる。

しかし、クライアント１の割り当て方によっては、特定のスレーブノード４に負荷が集中し、他のスレーブノード４は負荷が少ないような状態が発生する。また、新たにスレーブノード４を追加した場合、追加されたスレーブノード４にクライアントを割り当てないと、追加した意味がなくなる。

更に、スレーブノード４が故障した等の事情により、スレーブノード４を削除した場合、それまでその削除されたスレーブノード４が担当していたクライアント１を他のスレーブノード４に再配置しなければならない。

このような再配置を行う方法について説明する。

マスタノード３は、管理者からのコマンドや、負荷の不均等を検出する別のモジュールからの通知により、再配置を行うためのトリガーを取得する。マスタノード３の担当ノード決定処理部３２は、このトリガーに応じて、再配置を行う。マスタノード３は、再配置により新たに決定した割当に従い、スレーブノード４に対して、クライアント追加・削除・全削除命令を送信する。具体的には、まず、マスタノード３は、全削除命令を送信してスレーブノード４の担当クライアントテーブル４２を全て削除する。その後、マスタノード３は、クライアント追加命令として、新たに割り当てるクライアント１の追加命令を送信する。クライアント１の追加命令には、クライアント１のＩＰアドレスとＭＡＣアドレスが含まれる。

スレーブノード４は、クライアント追加命令を受けると、クライアント追加命令に含まれるＩＰアドレスとＭＡＣアドレスを担当クライアントテーブル４２に追加し、このＩＰアドレスとＭＡＣアドレスを持つクライアント１に対して、ＡＲＰ応答を送信する。クライアント１は、ＡＲＰ応答を受信すると、自身のＡＲＰテーブルを変更する。これにより、クライアント１は、新たなスレーブノード４と通信するようになり、再配置が実現できる。

なお、クライアント１の通信中にＡＲＰテーブルが変更されて、宛先のスレーブノード４が変わると、アプリケーションによってはセッションが破棄されてエラーが起きる可能性がある。例えば、スレーブノード４を追加した場合等、エラーを発生させてまで再配置をする必要がない場合があり得る。このような場合には、マスタノード３は、クライアント１の通信状況を監視し、通信のないタイミングまで待ってから再配置をする。このとき、個々のスレーブノード４が、クライアント１の通信状況を監視し、通信のないタイミングになると、その旨をマスタノード３に通知するようにしても良い。

＜他の実施形態＞
最後に、他の実施形態について詳細に説明する。

本実施形態のクラスタ制御システムは、複数のクライアントと、複数のクライアントにより接続される複数のコンピュータと、複数のコンピュータを管理するマスタコンピュータを含む。複数のコンピュータは、複数のクライアントと複数のコンピュータが接続するネットワーク（フロントネットワーク）と、複数のコンピュータとマスタコンピュータが接続するネットワーク（バックエンドネットワーク）に接続している。複数のコンピュータは、フロントネットワークに対しては、同一のＩＰアドレス（シングルＩＰアドレス）を持っている。また、複数のコンピュータは、それぞれが受け持つクライアントのテーブル（担当クライアントテーブル）を持っている。担当クライアントテーブルは、バックエンドネットワークを介して、マスタコンピュータから追加・変更・削除等の維持管理をされており、クライアントからシングルＩＰアドレスに対してＡＲＰ要求が来たときに、担当クライアントテーブルを参照し、ＡＲＰ要求を出したクライアントが存在すればＡＲＰ応答を返し、存在しなければＡＲＰ応答をしない処理を行う。

また、複数のコンピュータは、担当クライアントテーブルに存在しないクライアントからＡＲＰ要求が来たときに、マスタコンピュータに対して、新規クライアントとして通知する。

また、複数のコンピュータは、新規クライアント通知をするか否かを判断するフラグを有する。

また、複数のコンピュータは、新規クライアント通知に、クライアントから受信したＡＲＰ要求パケットも合わせて通知する。

また、マスタコンピュータは、複数のコンピュータへのクライアントの割当を記憶したテーブル（クライアント割当テーブル）と複数のコンピュータの状態を管理するテーブル（ノード管理テーブル（ないしスレーブノードテーブル））を持つ。マスタコンピュータは、新規クライアントからのＡＲＰ要求が複数のコンピュータに来たことを検出すると、クライアント割当テーブルとノード管理テーブルを参照し、既に割当済みであれば、そのコンピュータの担当クライアントテーブルに新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行い、割当がなければ、ノード管理テーブルを参照して複数のコンピュータから１つを選択し、そのコンピュータの担当クライアントテーブルに新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行う。

また、マスタコンピュータは、ノード管理テーブルの増減やスレーブコンピュータ間の負荷の不均等を検出したことに伴い、複数のコンピュータの担当クライアントテーブルにクライアントのＩＰアドレスとＭＡＣアドレスの追加・削除・全削除を行う。

本発明のクラスタ制御システムにおいて、ネットワーク上を流れる通信内容は、コマンドと、ＩＰアドレス及びＭＡＣアドレスのリストを含む。コマンドの種類として、追加・削除・全削除がある。複数のコンピュータは、コマンドと、クライアントのＩＰアドレス及びＭＡＣアドレスのリストを受け取ると、コマンドに従い、担当クライアントテーブルにＩＰアドレスとＭＡＣアドレスの追加・削除・全削除を行い、追加コマンドの場合には、追加されたクライアントに対してＡＲＰ応答を送信し、正常に終了したか否かを返すことにより、ＡＲＰ応答を制御可能とする。

以上のように、本発明では、ＡＲＰプロトコルのレイヤでロードバランスを行う。ＡＲＰは、ＩＰアドレスからＭＡＣアドレスを解決するためのプロトコルである。本発明では、クライアントからのＡＲＰリクエストに対して、異なるＭＡＣアドレスを返してやることでクライアント単位のロードバランスを行う。

本発明によれば、シングルＩＰアドレスで柔軟なロードバランスと拡張性を実現できるため、コンピュータ資源を有効活用しつつ信頼性を高めることができる。また、特別なネットワークを必要としないため、新規投資を最小限にすることができる。

以上、本発明の実施形態を詳述してきたが、実際には上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。
本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲（クレーム）の枠内において、種々の開示要素の多様な組み合せないし選択が可能である。

１（−ｉ、ｉ＝１〜ｎ）… 複数のクライアント
１０… フロントネットワーク
２… サーバ群
２０… バックエンドネットワーク
３… マスタノード
３１… 担当ノード決定処理部
３２… クライアント割当テーブル
３３… スレーブノードテーブル
３４… ノード死活管理部
３５… ＡＲＰ処理部
３６… 担当クライアントテーブル
３７… テーブル管理部
３８… ＡＲＰ通知部
３９… 通知フラグ
４（−ｊ、ｊ＝１〜ｍ）… スレーブノード
４１… ＡＲＰ処理部
４２… 担当クライアントテーブル
４３… テーブル管理部
４４… ＡＲＰ通知部
４５… 通知フラグ

Claims (26)

1. 複数のクライアントと、
   前記複数のクライアントの各々とフロントネットワークを介して接続するサーバ群と、
   前記サーバ群とバックエンドネットワークを介して接続し、前記サーバ群を管理するマスタコンピュータと
   を含み、
   前記サーバ群は、
   前記フロントネットワークに対して、同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータ
   を含み、
   前記複数のスレーブコンピュータの各々は、
   夫々が受け持つクライアントを示す担当クライアントテーブルと、
   前記複数のクライアントの各々から前記シングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、前記担当クライアントテーブルを参照し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在すればＡＲＰ応答を返し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在しなければＡＲＰ応答をしない処理を行うＡＲＰ処理部と
   を具備し、
   前記マスタコンピュータは、
   前記バックエンドネットワークを介して、前記担当クライアントテーブルに対し、前記複数のスレーブコンピュータの各々が受け持つクライアントの追加・変更・削除に関する情報の維持管理を行う担当ノード決定処理部
   を具備する
   クラスタ制御システム。
2. 請求項１に記載のクラスタ制御システムであって、
   前記複数のスレーブコンピュータの各々は、
   前記担当クライアントテーブルに存在しないクライアントからＡＲＰ要求を受け取ると、前記マスタコンピュータに対して、新規クライアントとして、前記クライアントのＩＰアドレス及びＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを通知するＡＲＰ通知部
   を更に具備する
   クラスタ制御システム。
3. 請求項２に記載のクラスタ制御システムであって、
   前記複数のスレーブコンピュータの各々は、
   前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断するための通知フラグ
   を更に具備し、
   前記ＡＲＰ通知部は、前記通知フラグを確認して、前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断する
   クラスタ制御システム。
4. 請求項２又は３に記載のクラスタ制御システムであって、
   前記マスタコンピュータは、
   前記複数のスレーブコンピュータの各々に対するクライアントの割当を記憶するためのクライアント割当テーブルと、
   前記複数のスレーブコンピュータの各々の状態を管理するためのスレーブノードテーブルと
   を更に具備し、
   前記担当ノード決定処理部は、前記複数のスレーブコンピュータの各々が前記新規クライアントからのＡＲＰ要求を受け取ったことを検出すると、前記クライアント割当テーブル及び前記スレーブノードテーブルを参照し、前記新規クライアントに対してスレーブコンピュータが既に割当済みであれば、前記割り当てられたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行い、前記新規クライアントに対してスレーブコンピュータの割当がなければ、前記スレーブノードテーブルを参照して、前記複数のスレーブコンピュータのうちいずれか１つのスレーブコンピュータを選択し、前記選択されたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行う
   クラスタ制御システム。
5. 請求項４に記載のクラスタ制御システムであって、
   前記担当ノード決定処理部は、前記スレーブノードテーブルにおける前記スレーブコンピュータの増減や、前記複数のスレーブコンピュータ間の負荷が不均等になっていることを検出したことに伴い、前記複数のスレーブコンピュータの各々の担当クライアントテーブルにおけるクライアントのＩＰアドレス及びＭＡＣアドレスの追加・削除を行い、前記複数のスレーブコンピュータの負荷が均等になるように再配置を行う
   クラスタ制御システム。
6. 請求項１乃至５のいずれか一項に記載のクラスタ制御システムであって、
   前記担当ノード決定処理部は、前記複数のスレーブコンピュータの各々に対して、コマンドとＩＰアドレスとＭＡＣアドレスとを含むデータを送信し、
   前記コマンドの種類は、追加・削除・全削除があり、
   前記複数のスレーブコンピュータの各々は、前記コマンドと前記ＩＰアドレスと前記ＭＡＣアドレスとを含むデータを受け取ると、前記コマンドに従い、前記担当クライアントテーブルに対して、前記ＩＰアドレスと前記ＭＡＣアドレスとの追加・削除・全削除を行い、追加コマンドの場合には前記ＩＰアドレスと前記ＭＡＣアドレスで指定されるクライアントに対してＡＲＰ応答を送信し、前記コマンドに応じた処理が正常に終了したか否かを示す情報を前記マスタコンピュータに返す
   クラスタ制御システム。
7. 請求項１乃至６のいずれか一項に記載のクラスタ制御システムで、前記複数のスレーブコンピュータの１つとして使用されるコンピュータ。
8. 請求項１乃至６のいずれか一項に記載のクラスタ制御システムで、前記マスタコンピュータとして使用されるコンピュータ。
9. 複数のクライアントの各々とサーバ群とをフロントネットワークを介して接続するステップと、
   前記サーバ群を管理するマスタコンピュータと前記サーバ群とをバックエンドネットワークを介して接続するステップと、
   前記サーバ群から前記フロントネットワークに対してシングルＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを提示し、前記サーバ群に含まれる複数のスレーブコンピュータが同一のＩＰアドレスであるように見せるステップと、
   前記サーバ群に対して、前記複数のクライアントの各々から前記シングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、前記複数のスレーブコンピュータの各々が夫々受け持つクライアントを示す担当クライアントテーブルを参照し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在すればＡＲＰ応答を返し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在しなければＡＲＰ応答をしない処理を行うステップと、
   前記バックエンドネットワークを介して、前記マスタコンピュータから前記担当クライアントテーブルに対し、前記複数のスレーブコンピュータの各々が受け持つクライアントの追加・変更・削除に関する情報の維持管理を行うステップと、
   前記複数のスレーブコンピュータの各々は、クライアントが追加された場合には前記クライアントに対してＡＲＰ応答を送信するステップと
   を含む
   クラスタ制御方法。
10. 請求項９に記載のクラスタ制御方法であって、
    前記複数のスレーブコンピュータの各々が前記担当クライアントテーブルに存在しないクライアントからＡＲＰ要求を受け取ると、前記複数のスレーブコンピュータの各々から前記マスタコンピュータに対して、新規クライアントとして、前記クライアントのＩＰアドレス及びＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを通知するステップ
    を更に含む
    クラスタ制御方法。
11. 請求項１０に記載のクラスタ制御方法であって、
    前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断するための通知フラグを確認して、前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断するステップ
    を更に含む
    クラスタ制御方法。
12. 請求項１０又は１１に記載のクラスタ制御方法であって、
    前記マスタコンピュータに、前記複数のスレーブコンピュータの各々に対するクライアントの割当を記憶するためのクライアント割当テーブルを設けるステップと、
    前記マスタコンピュータに、前記複数のスレーブコンピュータの各々の状態を管理するためのスレーブノードテーブルを設けるステップと、
    前記複数のスレーブコンピュータの各々が前記新規クライアントからのＡＲＰ要求を受け取ったことを検出すると、前記クライアント割当テーブル及び前記スレーブノードテーブルを参照するステップと、
    前記新規クライアントに対してスレーブコンピュータが既に割当済みであれば、前記マスタコンピュータから前記割り当てられたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行うステップと、
    前記新規クライアントに対してスレーブコンピュータの割当がなければ、前記スレーブノードテーブルを参照して、前記複数のスレーブコンピュータのうちいずれか１つのスレーブコンピュータを選択し、前記マスタコンピュータから前記選択されたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行うステップと
    を更に含む
    クラスタ制御方法。
13. 請求項１２に記載のクラスタ制御方法であって、
    前記スレーブノードテーブルにおける前記スレーブコンピュータの増減や、前記複数のスレーブコンピュータ間の負荷が不均等になっていることを検出したことに伴い、前記複数のスレーブコンピュータの各々の担当クライアントテーブルにおけるクライアントのＩＰアドレス及びＭＡＣアドレスの追加・削除を行い、前記複数のスレーブコンピュータの負荷が均等になるように再配置を行うステップ
    を更に含む
    クラスタ制御方法。
14. 請求項９乃至１３のいずれか一項に記載のクラスタ制御方法であって、
    前記マスタコンピュータから前記複数のスレーブコンピュータの各々に対して、コマンドとＩＰアドレスとＭＡＣアドレスとを含むデータを送信するステップと、
    前記コマンドの種類は、追加・削除・全削除があり、前記複数のスレーブコンピュータの各々が前記コマンドと前記ＩＰアドレスと前記ＭＡＣアドレスとを含むデータを受け取ると、前記コマンドに従い、前記担当クライアントテーブルに対して、前記ＩＰアドレスと前記ＭＡＣアドレスとの追加・削除・全削除を行い、前記コマンドに応じた処理が正常に終了したか否かを示す情報を前記マスタコンピュータに返すステップと
    を更に含む
    クラスタ制御方法。
15. 請求項９乃至１４のいずれか一項に記載のクラスタ制御方法における前記複数のスレーブコンピュータの各々の動作を、コンピュータに実行させるためのプログラム。
16. 請求項９乃至１４のいずれか一項に記載のクラスタ制御方法における前記マスタコンピュータの動作を、コンピュータに実行させるためのプログラム。
17. 複数のクライアントとフロントネットワークを介して接続するとともに、該フロントネットワークに対して同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータのうちの一のスレーブコンピュータであって、
    自身が受け持つクライアントを示す担当クライアントテーブルと、
    前記複数のクライアントのいずれか１つから前記シングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、前記担当クライアントテーブルを参照し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在する場合にはＡＲＰ応答を返し、それ以外の場合にはＡＲＰ応答をしないＡＲＰ処理部とを備え、
    前記担当クライアントテーブルにおけるクライアントの追加、変更又は削除を、バックエンドネットワークを介して接続されたマスタコンピュータによって行われることを特徴とするスレーブコンピュータ。
18. 前記担当クライアントテーブルに存在しないクライアントからＡＲＰ要求を受け取ると、前記マスタコンピュータに対して、新規クライアントとして、前記クライアントのＩＰアドレス及びＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを通知するＡＲＰ通知部をさらに備えていることを特徴とする、請求項１７に記載のスレーブコンピュータ。
19. 前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断するための通知フラグをさらに備え、
    前記ＡＲＰ通知部は、前記通知フラグを確認して、前記クライアントのＩＰアドレス及びＭＡＣアドレスを通知するか否かを判断することを特徴とする、請求項１８に記載のスレーブコンピュータ。
20. 複数のクライアントとフロントネットワークを介して接続するとともに該フロントネットワークに対して同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータとバックエンドネットワークを介して接続し、該複数のスレーブコンピュータを管理するマスタコンピュータであって、
    前記複数のスレーブコンピュータのそれぞれが受け持つクライアントを示す担当クライアントテーブルに対し、前記バックエンドネットワークを介して、クライアントの追加、変更又は削除を行う担当ノード決定処理部を備えていることを特徴とするマスタコンピュータ。
21. 請求項１７乃至１９のいずれか１項に記載のスレーブコンピュータと、
    請求項２０に記載のマスタコンピュータとを備えていることを特徴とするクラスタ制御システム。
22. 前記マスタコンピュータは、
    前記複数のスレーブコンピュータに対するクライアントの割当を記憶するためのクライアント割当テーブルと、
    前記複数のスレーブコンピュータの状態を管理するためのスレーブノードテーブルとをさらに備え、
    前記担当ノード決定処理部は、前記複数のスレーブコンピュータの各々が前記新規クライアントからのＡＲＰ要求を受け取ったことを検出すると、前記クライアント割当テーブル及び前記スレーブノードテーブルを参照し、前記新規クライアントに対してスレーブコンピュータが既に割当済みであれば、前記割り当てられたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加する処理を行い、前記新規クライアントに対してスレーブコンピュータの割当がなければ、前記スレーブノードテーブルを参照して、前記複数のスレーブコンピュータのうちいずれか１つのスレーブコンピュータを選択し、前記選択されたスレーブコンピュータの担当クライアントテーブルに対して、前記新規クライアントのＩＰアドレス及びＭＡＣアドレスを追加することを特徴とする、請求項２１に記載のクラスタ制御システム。
23. 前記担当ノード決定処理部は、前記スレーブノードテーブルにおける前記複数のスレーブコンピュータの増減、又は、前記複数のスレーブコンピュータ間の負荷が不均等になっていることを検出したことに伴い、前記複数のスレーブコンピュータの各々の担当クライアントテーブルにおけるクライアントのＩＰアドレス及びＭＡＣアドレスの追加・削除を行い、前記複数のスレーブコンピュータの負荷が均等になるように再配置を行うことを特徴とする、請求項２２に記載のクラスタ制御システム。
24. 前記担当ノード決定処理部は、前記複数のスレーブコンピュータの各々に対して、コマンドとＩＰアドレスとＭＡＣアドレスとを含むデータを送信し、
    前記コマンドの種類は、追加・削除・全削除があり、
    前記複数のスレーブコンピュータの各々は、前記コマンドと前記ＩＰアドレスと前記ＭＡＣアドレスとを含むデータを受け取ると、前記コマンドに従い、前記担当クライアントテーブルに対して、前記ＩＰアドレスと前記ＭＡＣアドレスとの追加・削除・全削除を行い、追加コマンドの場合には前記ＩＰアドレスと前記ＭＡＣアドレスで指定されるクライアントに対してＡＲＰ応答を送信し、前記コマンドに応じた処理が正常に終了したか否かを示す情報を前記マスタコンピュータに返すことを特徴とする、請求項２１乃至２３のいずれか１項に記載のクラスタ制御システム。
25. 複数のクライアントとフロントネットワークを介して接続するとともに、該フロントネットワークに対して同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータの各スレーブコンピュータが、
    前記複数のクライアントのいずれか１つから前記シングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、自身が受け持つクライアントを示す担当クライアントテーブルを参照し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在する場合にはＡＲＰ応答を返し、それ以外の場合にはＡＲＰ応答をしない工程と、
    前記担当クライアントテーブルにおけるクライアントの追加、変更又は削除を、バックエンドネットワークを介して接続されたマスタコンピュータによって行われる工程とを含むことを特徴とするクラスタ制御方法。
26. 複数のクライアントとフロントネットワークを介して接続するとともに、該フロントネットワークに対して同一のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスであるシングルＩＰアドレスを提示する複数のスレーブコンピュータの各スレーブコンピュータに、
    前記複数のクライアントのいずれか１つから前記シングルＩＰアドレスに対するＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求が来たときに、自身が受け持つクライアントを示す担当クライアントテーブルを参照し、前記担当クライアントテーブルに前記ＡＲＰ要求を出したクライアントが存在する場合にはＡＲＰ応答を返し、それ以外の場合にはＡＲＰ応答をしない処理と、
    前記担当クライアントテーブルにおけるクライアントの追加、変更又は削除を、バックエンドネットワークを介して接続されたマスタコンピュータによって行われる処理とを実行させることを特徴とするプログラム。

Images