(57)【特許請求の範囲】
【請求項１】
コンピュータに、
キーにより静的に分割され、かつ、複数の情報処理装置で分散配置され、かつ、前記キーによる前記静的な分割が前記複数の情報処理装置間での分散配置の境界をまたがないデータベースの、１または複数のキーにより特定される第１のキー領域に対応した前記データベースのデータの割り当て指示を受け付け、
前記割り当て指示に対応して、前記データベースの複数のキー領域それぞれと前記複数の情報処理装置のいずれかに配置された通信端点のアドレスとを対応づけた対応づけ情報に沿って、前記第１のキー領域に対応するアドレスを、前記コンピュータに設定する、
処理を実行させる分散制御プログラム。
【請求項２】
前記複数のキー領域のそれぞれに対して、２以上の通信端点のアドレスが対応づけられており、
前記分散制御プログラムが前記コンピュータに実行させる前記処理は、
前記複数のキー領域のいずれか１つである対象キー領域に対応づけられている２以上の通信端点のアドレスのうちの１つを宛先として指定したメッセージを送信し、
前記メッセージに対する応答を監視し、
所定時間内に前記応答が返ってこない場合、前記複数の情報処理装置のうちの１台であって前記宛先として指定した前記アドレスが設定されている第１の他のコンピュータに、障害が発生している、と認識する
ことをさらに含む
ことを特徴とする請求項１に記載の分散制御プログラム。
【請求項３】
前記対象キー領域が前記第１のキー領域であり、かつ、前記障害の発生を認識したときに、前記障害の発生の認識に応じて前記割り当て指示が受け付けられ、
前記分散制御プログラムが前記コンピュータに実行させる前記処理は、前記対象キー領域が前記第１のキー領域であり、かつ、前記障害の発生を認識したときに、
前記複数の情報処理装置のうちの１台であって、前記第１のキー領域に対応づけられた前記２以上の通信端点のアドレスのうちで前記メッセージの前記宛先には指定されていないいずれか１つのアドレスが設定された第２の他のコンピュータに、前記データベースのうち前記第１のキー領域に対応したデータを送信するように要求し、
要求した前記データを、前記第２の他のコンピュータから受信して記憶する
ことをさらに含むことを特徴とする請求項２に記載の分散制御プログラム。
【請求項４】
前記割り当て指示は、前記複数のキー領域に対応する複数の通信端点のアドレスのうちの１つを前記コンピュータが選択した結果として発行されるか、または、前記コンピュータの外部から与えられ、
前記複数の情報処理装置のうちの１台であって、前記第１のキー領域に対応する前記アドレスが設定された第３の他のコンピュータに、前記データベースのうち前記第１のキー領域に対応したデータを送信するように要求し、要求した前記データを、前記第３の他のコンピュータから受信して記憶することを、前記分散制御プログラムが前記コンピュータに実行させる前記処理がさらに含む
ことを特徴とする請求項１に記載の分散制御プログラム。
【請求項５】
暗号学的ハッシュ関数、剰余関数、および、入力ビット列から複数の所定の位置のビットを抽出する関数のうちの少なくとも１つを利用する所定の写像によるキーの像に基づいて、前記複数のキー領域が定義される
ことを特徴とする請求項１から４のいずれか１項に記載の分散制御プログラム。
【請求項６】
コンピュータが、
キーにより静的に分割され、かつ、複数の情報処理装置で分散配置され、かつ、前記キーによる前記静的な分割が前記複数の情報処理装置間での分散配置の境界をまたがないデータベースの、１または複数のキーにより特定される第１のキー領域に対応した前記データベースのデータの割り当て指示を受け付け、
前記割り当て指示に対応して、前記データベースの複数のキー領域それぞれと前記複数の情報処理装置のいずれかに配置された通信端点のアドレスとを対応づけた対応づけ情報に沿って、前記第１のキー領域に対応するアドレスを、前記コンピュータに設定する、
ことを特徴とする分散制御方法。
【請求項７】
情報処理装置であって、
ネットワークインタフェイスと、
キーにより静的に分割され、かつ、複数の情報処理装置で分散配置され、かつ、前記キーによる前記静的な分割が前記複数の情報処理装置間での分散配置の境界をまたがないデータベースのうち、分割された少なくとも一部分を記憶する記憶装置と、
前記データベースの、１または複数のキーにより特定される第１のキー領域に対応した前記データベースのデータの割り当て指示に対応して、前記データベースの複数のキー領域それぞれと前記複数の情報処理装置のいずれかに配置された通信端点のアドレスとを対応づけた対応づけ情報に沿って、前記第１のキー領域に対応するアドレスを前記ネットワークインタフェイスと対応づけるプロセッサ
を備える情報処理装置。
【請求項８】
複数の情報処理装置と、キーにより静的に分割され、かつ、前記複数の情報処理装置で分散配置され、かつ、前記キーによる前記静的な分割が前記複数の情報処理装置間での分散配置の境界をまたがないデータベースと、を有する分散システムであって、
前記複数の情報処理装置は、前記データベースの複数のキー領域それぞれと前記複数の情報処理装置のいずれかに配置された通信端点のアドレスとを対応づけた対応づけ情報を有し、
前記データベースの前記複数の情報処理装置の少なくとも一部に対するキー領域の割り当てを変化させる場合に、前記対応づけ情報に含まれる変化の対象となるキー領域に対応した通信端点のアドレスを、担当する情報処理装置それぞれに割り当てる、
ことを特徴とする分散システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散データベースのための分散制御に関する。
【背景技術】
【０００２】
データベースには、伝統的なリレーショナル・データベース（ＲＤＢ：Relational Database）だけでなく、キー・バリュー・ストア（ＫＶＳ：Key-Value Store）など、他の種類のものもある。そして、ＲＤＢもＫＶＳのいずれも、複数のノードへの分散化が可能である。例えば、分散ＲＤＢの例としてOracle RAC（Oracle Real Application Cluster）、分散ＫＶＳの例として、DynamoやCassandraなどが知られている。
【０００３】
また、分散データベースシステムにも様々な種類がある。例えば、いくつかの分散データベースシステムは、分散ハッシュテーブル（ＤＨＴ：Distributed Hash Table）を利用する。ＤＨＴは、ピア・ツー・ピア（Ｐ２Ｐ：Peer-To-Peer）型のデータ配信システムでも利用される技術であり、ＤＨＴに関して様々な研究が行われている。
【０００４】
例えば、多数のユーザが共同利用するＤＨＴデータ管理機構において、ノードの負荷を均等に分散するための、次のような分散データ管理システムが提案されている。
当該分散データ管理システムにおいては、管理部が仮想ノードを設定し、データ管理システムに格納されたデータへのアクセス処理を各仮想ノードに振り分ける。また、マッピング部が、仮想ノードとデータ管理システムのノードとを関連付ける。仮想ノード数、仮想ノードとノードのマッピングを調整することで、各ノードの負荷を調整することができる。
【０００５】
ところで、分散データベースシステムとＮＡＳ（Network Attached Storage）は、異なる技術ではあるが、ネットワークで結合されたノード上にデータが記憶されるという点では共通している。また、分散データベースシステムやＮＡＳなど、複数のノードを含むシステムは、いずれかのノードの障害に備えて冗長化されることがある。そして、冗長化システムにおける研究テーマの１つは、フェイルオーバ機能である。
【０００６】
例えば、ＮＡＳに関連して、最適なフェイルオーバを実現するための、次のような計算機システムが提案されている。
当該計算機システムは、第１〜第３計算機と、ネットワークを介して第１〜第３計算機を含む複数の計算機に接続される記憶装置とを備える。そして、第１計算機は、上記複数の計算機に接続されたクライアント計算機から記憶装置へのアクセス要求を受信すると、要求されたアクセスを実行し、アクセス要求に対する応答をクライアント計算機に送信する。また、第２計算機は、第１計算機に障害が発生したか否かを判定し、第２計算機の負荷情報を取得し、第３計算機から第３計算機の負荷情報を取得し、取得した負荷情報が所定の条件を満たす場合、第３計算機に変更要求を送信する。そして、第３計算機は、第２計算機から変更要求を受信した場合、第１計算機に障害が発生したか否かを判定する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−２９５１２７号公報
【特許文献２】特開２００９−２５９６５号公報
【非特許文献】
【０００８】
【非特許文献１】Guiseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels, "Dynamo: Amazon's Highly Available Key-value Store", SOSP (Symposium on Operating Systems Principles) 2007 (インターネット<URL: http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf> にも掲載 [2011年7月28日検索])
【非特許文献２】"The Apache Cassandra Project", [online], [2011年7月28日検索], インターネット<URL: http://cassandra.apache.org/>
【非特許文献３】首藤一幸著「スケールアウトの技術」  丸山不二夫・首藤一幸編『クラウドの技術』（株）アスキー・メディアワークス, 2009年11月6日, pp.88-101, (インターネット<URL: http://www.shudo.net/article/UNIX-magazine-200904-scaleout/> にも掲載 [2011年7月28日検索])
【非特許文献４】首藤一幸著「スケールアウトの技術」  UNIX magazine, (株)アスキー・メディアワークス, 2009年4月号, pp. 78-91 (インターネット<URL: http://www.shudo.net/article/UNIX-magazine-200904-scaleout/> にも掲載 [2011年7月28日検索])
【発明の概要】
【発明が解決しようとする課題】
【０００９】
データベースが複数のノードに分散している場合、データベースの運用中には、何らかの状況の変化が生じることがある。例えば、複数のノードのうちのいずれかが故障するかもしれないし、新たなノードが追加されることによってノードの数が変わるかもしれない。
【００１０】
ところで、複数のノードがそれぞれ有する記憶装置にデータベースが分散されて記憶される、ある種の分散データベースシステムでは、状況の変化に追従するために、ノード同士が何らかの制御情報を交換することがある。そして、制御情報の交換に使われるプロトコルは、ノードが多数でも構わないようにスケーラビリティを考慮して設計された場合などには、複雑になりがちである。
【００１１】
また、状況の変化に追従するためのノード間での制御情報の交換に使われるプロトコルは、分散データベースシステムの設計に応じて、アプリケーション層に実装されることが多い。すると、上記プロトコルの実装のために、アプリケーション層での複雑なプログラミングが必要になることがあり、プログラマの負担も大きい。
【００１２】
他方で、通信機能を持つ多くの装置には、通信端点とネットワークインタフェイスの対応づけが動的に変化しても適切に通信を行うことができるようにするための通信プロトコルが実装される。そして、通信機能を持つ装置は様々な用途に使われ得るので、通信プロトコルは、アプリケーション層よりも下層に実装されることが多い。
【００１３】
本発明は、１つの側面では、データベースが複数のノードに分散している場合に生じ得る状況の変化に追従するためのアプリケーション層の仕組みを、アプリケーション層よりも下層に実装される通信プロトコルの存在を利用することで簡単化することを目的とする。
【課題を解決するための手段】
【００１４】
一態様による分散制御プログラムは、コンピュータに以下の処理を実行させる。
当該処理は、対応するキーが定められているエントリを複数含むデータベースから、前記キーの定義域の特定の部分集合にキーが属する１つ以上の特定のエントリを取得することを含む。また、当該処理は、取得した前記１つ以上の特定のエントリを、前記コンピュータに備えられており前記データベースを分散して記憶する複数の記憶装置の１つとして使われる記憶装置に記憶することを含む。
【００１５】
当該処理はさらに、２以上の所定個数の通信端点をそれぞれ論理的に識別するための前記所定個数の通信端点情報のうち、前記特定の部分集合と対応づけられている特定の通信端点情報を、前記コンピュータのネットワークインタフェイスと対応づけることを含む。
【００１６】
ここで、前記所定個数の前記通信端点情報の各々は、前記複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに、動的に対応づけられる。また、前記所定個数の前記通信端点情報の各々は、前記定義域内の互いに素な、前記特定の部分集合を含む複数の部分集合のいずれか１つに、静的に対応づけられる。
【発明の効果】
【００１７】
上記の分散制御プログラムによれば、「データベースを分散して記憶する複数の記憶装置のそれぞれが、キーの定義域内のどの部分集合に対応するか」ということは、直接的かつ動的な対応づけにより管理されるのではなく、間接的な対応づけにより管理される。つまり、部分集合と通信端点情報が静的に対応づけられ、そうして部分集合と静的に対応づけられた通信端点情報が、記憶装置へのアクセスを提供するネットワークインタフェイスと動的に対応づけられることにより、部分集合と記憶装置が間接的に対応づけられる。
【００１８】
ここで、データベースが複数の記憶装置に分散している場合に生じ得る状況の変化とは、換言すれば、記憶装置と部分集合の間の上記のような間接的な対応づけの変化である。また、記憶装置と部分集合との間接的な対応づけに利用されている、部分集合と通信端点情報の対応づけは、状況の変化と関係なく静的なので、追従の必要がない。よって、記憶装置と部分集合との間接的な対応づけに利用されている、通信端点情報とネットワークインタフェイスとの対応づけの変化への追従により、状況の変化への追従が実現される。
【００１９】
そして、通信端点情報とネットワークインタフェイスとの間の対応づけの変化は、アプリケーション層よりも下層に実装される通信プロトコルを利用することで、追従可能である。したがって、上記の分散制御プログラムによれば、アプリケーション層よりも下層に実装される通信プロトコルを利用することで、状況の変化に追従することが可能である。すなわち、上記の分散制御プログラムによれば、ノード間での制御情報の交換のための複雑なプロトコルなどは不要であり、通信プロトコルの存在を利用することで、状況の変化に追従するためのアプリケーション層の仕組みが簡単化される。
【図面の簡単な説明】
【００２０】
【図１】分散データベースシステムにおける状況の変化と、変化に応じた動作の概要を示す図である。
【図２】キー領域と通信端点とノードとの対応づけの一例を示す図である。
【図３】第１のネットワーク構成例の図である。
【図４】第２のネットワーク構成例の図である。
【図５】ノードのブロック構成図である。
【図６】クライアントのブロック構成図である。
【図７】コンピュータのハードウェア構成図である。
【図８】各種データの例を示す図である。
【図９】メッセージ送信を指示されたときの、通信処理部とネットワークインタフェイスにおける、インターネット層とリンク層の動作フローチャートである。
【図１０】ＡＲＰ応答のフローチャートである。
【図１１】クライアントによるリード操作のフローチャートである。
【図１２】クライアントによるライト操作のフローチャートである。
【図１３】クライアントからのＤＢアクセス要求にノードが応答する処理のフローチャートである。
【図１４】ノードが新規追加された場合、または自身が低負荷の場合に、他のノードからキー領域を引き継ぐ処理のフローチャートである。
【図１５】ノードが他のノードを監視し、監視対象が故障した場合に引き継ぎを行う処理のフローチャートである。
【図１６】監視されるノードが行う処理のフローチャートである。
【図１７】クライアントからの要求とノードからの正常な応答のシーケンス図である。
【図１８】ノードの故障と引き継ぎのシーケンス図である。
【図１９】引き継ぎ後にクライアントのＡＲＰテーブルが古い状態で行われるＤＢアクセスのシーケンス図である。
【図２０】引き継ぎ後にクライアントでＡＲＰテーブルが更新されてから行われるＤＢアクセスのシーケンス図である。
【図２１】新規ノードの追加にともなう引き継ぎのシーケンス図である。
【図２２】クライアントからの要求と追加された新規ノードによる応答のシーケンス図である。
【発明を実施するための形態】
【００２１】
以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、まず図１〜２を参照して本実施形態の概要を説明する。次に、図３〜４を参照して、本実施形態が適用されるネットワーク構成の例について説明する。その後、図５〜７を参照して、本実施形態で使われる装置の構成を説明し、図８を参照して、本実施形態で使われるデータの例を説明する。続いて、図９〜１６のフローチャートを参照して個々の装置が行う処理について説明し、図１７〜２２のシーケンス図を参照して、システムの動作例について説明する。最後に、いくつかの変形例についても説明する。
【００２２】
図１は、分散データベースシステムにおける状況の変化と、変化に応じた動作の概要を示す図である。なお、以下では「データベース」を「ＤＢ」と略す。
図１には、データが複数のノードの記憶装置に分散して記憶される分散ＤＢシステムにおける、２つのノードと１つのクライアントが例示されている。分散ＤＢシステムの各ノードは、クライアントに対してサーバとして動作する。また、各ノードおよびクライアントは、具体的にはコンピュータ（すなわち情報処理装置）である。
【００２３】
図１の例では、コンピュータ１００ａと１００ｂが複数のノードのうちの２つのノードであり、コンピュータ１１０がクライアントである。コンピュータ１００ａ、１００ｂ、および１１０は、不図示のネットワークを介して互いに接続されている。
【００２４】
コンピュータ１００ａは、記憶装置１０１ａとネットワークインタフェイスＩａを有する。また、コンピュータ１００ｂは、記憶装置１０１ｂとネットワークインタフェイスＩｂを有する。
【００２５】
記憶装置１０１ａと１０１ｂは、具体的には、高速なアクセスが可能なＲＡＭ（Random Access Memory）であることが好ましい。しかし、ＤＢアクセスのレイテンシが多少長くても問題がない実施形態においては、記憶装置１０１ａと１０１ｂは、ハードディスク装置などの外部記憶装置であってもよい。
【００２６】
ネットワークインタフェイスＩａとＩｂのそれぞれは、例えば、オンボードのネットワークアダプタでもよいし、外付けのＮＩＣ（Network Interface Card）でもよい。また、ネットワークインタフェイスＩａとＩｂのそれぞれは、例えば、ＯＳＩ（Open Systems Interconnection）参照モデルにおける物理層の処理回路とＭＡＣ（Media Access Control）副層の処理回路などのハードウェア回路により実現されてもよい。
【００２７】
なお、図１では説明の便宜上、ネットワークインタフェイスＩａとＩｂをそれぞれ識別する情報が、ネットワークインタフェイスＩａとＩｂそれぞれの参照符号を用いて、「Ｉａ」および「Ｉｂ」と表記されている。ネットワークインタフェイスＩａとＩｂをそれぞれ識別する情報の具体例は、ＭＡＣアドレスなどの物理アドレス（ハードウェアアドレスともいう）である。
【００２８】
図１の分散ＤＢシステムにおけるＤＢは、エントリを複数含み、複数のノードの記憶装置に分散して記憶される。また、各エントリには、当該エントリに対応するキーが定められている。
【００２９】
例えば、ＤＢは、具体的にはＫＶＳであってもよい。ＫＶＳにおけるエントリは、キーとバリューのペアである。つまり、当該エントリに対応するキーとは、当該エントリが含むキーである。
【００３０】
あるいは、ＤＢは、ＲＤＢであってもよい。ＲＤＢは１つ以上のテーブルを含み、各テーブルのエントリは、１つ以上のフィールドの組（tuple）である。各テーブルにおける所定の１つのフィールドが、「当該テーブルのキーとして使われるフィールド」として予め定められる。つまり、あるエントリに対応するキーとは、当該エントリにおける上記所定のフィールドのデータである。
【００３１】
以上のように各エントリに対応するキーが定められていると、キーの値に応じた水平分割（horizontal partitioning）によるＤＢの分散化が可能である。つまり、水平分割による分散化は、ＫＶＳとＲＤＢの双方に適用可能である。また、ハッシュ値がキーとして使われる場合、ＤＢはＤＨＴとも見なせる。
【００３２】
ここで、キーの定義域をＫとする。例えば、１６ビットの符号なし整数がキーとして使われる場合、定義域Ｋは、０以上２１６−１の整数の集合である。あるいは、長さが１以上の任意の文字列がキーとして使われ得る場合、定義域Ｋは、長さが１以上の任意の文字列の集合である。
【００３３】
また、Ｍは２以上の所定の整数であるとし、０≦ｊ≦Ｍ−１なる各ｊについて、定義域Ｋの部分集合Ｋｊが適宜定義されるものとする。なお、任意のｉとｊに対して、ｉ≠ｊならば部分集合ＫｉとＫｊが互いに素（disjoint）となるように（つまり、Ｋｉ∩Ｋｊが空集合となるように）、各部分集合が定義されるものとする。
【００３４】
そして、定義域Ｋは、式（１）のとおり、部分集合Ｋ０〜ＫＭ−１の和集合であるとする。
【００３５】
【数１】
0005811703.tif 000002
【００３６】
各部分集合Ｋｊが具体的にどのような部分集合であるかは、実施形態に応じて任意である。また、Ｍの値も実施形態に応じて任意である。換言すれば、定義域Ｋが重複も漏れもなくＭ個の部分集合Ｋ０〜ＫＭ−１に分割されさえすれば、部分集合Ｋ０〜ＫＭ−１がどのように定義されてもよい。
【００３７】
例えば、定義域Ｋが整数を要素とする集合である場合、各部分集合Ｋｊは、式（２）により定義されていてもよい。なお、式（２）における関数ｍｏｄ（ｘ，ｙ）は、ｘをｙで割った余りを計算する剰余関数である。
【００３８】
【数２】
0005811703.tif 000003
【００３９】
あるいは、引数ｘのハッシュ値を計算する適宜のハッシュ関数ｈａｓｈ（ｘ）を用いて、各部分集合Ｋｊが式（３）により定義されていてもよい。式（３）の定義は、定義域Ｋがどのような集合であるかによらず、適用可能である。
【００４０】
【数３】
0005811703.tif 000004
【００４１】
なお、式（３）のハッシュ関数ｈａｓｈ（ｘ）としては、任意のハッシュ関数が利用可能だが、ハッシュ関数ｈａｓｈ（ｘ）は暗号学的ハッシュ関数であることが好ましい。なぜなら、暗号学的ハッシュ関数はハッシュ値の分布の一様性が高いからである。
【００４２】
ハッシュ値の分布の一様性が高いと、「キーの値に応じた水平分割のバランスが良い」と期待される。そして、バランスの良い分割は、効率の良い分散化を意味する。そのため、ハッシュ関数ｈａｓｈ（ｘ）は暗号学的ハッシュ関数であることが好ましい。例えば、暗号学的ハッシュ関数の一例は、１６０ビットのハッシュ値を出力するＳＨＡ−１（Secure Hash Algorithm 1）である。
【００４３】
あるいは、Ｂを１以上の整数として、Ｍ＝２Ｂが成り立つ場合には、各部分集合Ｋｊが式（４）または（５）により定義されていてもよい。なお、式（４）と（５）における関数ｅｘｔ（ｘ，ｙ，ｚ）は、ビット列ｘのｙビット目からｚビット目までを抽出する関数である。また、０ビット目が最上位ビットであるものとする。
【００４４】
【数４】
0005811703.tif 000005
【００４５】
【数５】
0005811703.tif 000006
【００４６】
例えば、式（４）によれば、キーｋを表すビット列の第Ｌビットから第（Ｌ＋Ｂ−１）ビットまでのＢビットが抽出される。そして、抽出されたＢビットで表される０以上（２Ｂ−１）以下の数により、キーｋの属するキー領域が定められる。式（５）は、式（４）のようにキーｋを表すビット列そのものからＢビットを抽出する代わりに、キーｋのハッシュ値を表すビット列そのものからＢビットを抽出することを示している。
【００４７】
なお、関数ｅｘｔ（ｘ，ｙ，ｚ）は、入力ビット列から複数の所定の位置のビットを抽出する関数の一例である。関数ｅｘｔ（ｘ，ｙ，ｚ）のように連続した（ｚ−ｙ＋１）ビットを抽出する関数の代わりに、例えば「２ビット目と５ビット目と８ビット目」のような、不連続な複数の位置のビットを抽出する関数が利用されてもよい。
【００４８】
また、各部分集合Ｋｊは、式（６）のように定義されていてもよい。式（６）における関数ｆは、集合Ｋから、式（７）を満たす集合Ｘへの、任意の写像である。なお、式（６）と（７）において、０≦ｊ≦Ｍなる任意のｊについて、Ｔｊは適宜に選ばれた実数の閾値であるものとし、０≦ｊ≦Ｍ−１なる任意のｊについて、Ｔｊ＜Ｔｊ＋１であるものとする。
【００４９】
【数６】
0005811703.tif 000007
【００５０】
【数７】
0005811703.tif 000008
【００５１】
式（７）によれば、関数ｆは、キーの定義域Ｋから、閾値Ｔ０以上かつ閾値ＴＭ未満の実数の少なくとも一部を要素とする集合Ｘへの、任意の写像である。キーの定義域Ｋによっては、関数ｆは、例えば恒等写像であってもよいし、ハッシュ関数であってもよい。もちろん、実施形態に応じて、関数ｆは、ハッシュ関数（特に暗号学的ハッシュ関数）、剰余関数、入力ビット列から複数の所定の位置のビットを抽出する関数のうちの１つまたは複数を利用する所定の写像であってよい。
【００５２】
以上の式（２）〜（７）に例示したように、部分集合Ｋ０〜ＫＭ−１は、所定の写像によるキーの像に基づいて定義されていてもよい。また、下記のとおり、式（６）は式（２）〜（５）を一般化した式でもある。
【００５３】
ここで、キーｋからＳＨＡ−１によりハッシュ値を求める関数を、ＳＨＡ１（ｋ）と表記することにする。すると、式（５）の例において、ハッシュ関数ｈａｓｈ（ｋ）としてＳＨＡ１（ｋ）を用い、Ｌ＝０とし、Ｂ＝７とした場合、各部分集合Ｋｊは、式（８）のように定義される。
【００５４】
【数８】
0005811703.tif 000009
【００５５】
別の観点から述べれば、式（８）の例は、式（６）において、０≦ｊ≦Ｍなる任意のｊについてＴｊ＝２１５３×ｊと定め、かつ、関数ｆ（ｋ）としてＳＨＡ（ｋ）を利用する例でもある。
【００５６】
そして、式（２）の例は、式（６）において、関数ｆ（ｋ）として剰余関数ｍｏｄ（ｋ，Ｍ）を用いるとともに、０≦ｊ≦Ｍなる任意のｊについてＴｊ＝ｊと定めた例でもある。同様に、式（３）の例は、式（６）において、関数ｆ（ｋ）として関数ｍｏｄ（ｈａｓｈ（ｋ），Ｍ）を用いるとともに、０≦ｊ≦Ｍなる任意のｊについてＴｊ＝ｊと定めた例でもある。また、式（４）と（５）のそれぞれも、式（６）の具体例の一つであることは明らかであろう。
【００５７】
さてここで、部分集合Ｋ０〜ＫＭ−１のうちのある特定の１つを「Ｋａ」とする。部分集合Ｋａにキーが属するすべてのエントリ１０２は、図１のステップＳ１ではコンピュータ１００ａの記憶装置１０１ａに記憶されているのに対し、ステップＳ２ではコンピュータ１００ｂの記憶装置１０１ｂに記憶されている。なお、エントリ１０２の数は、１のこともあるし複数のこともある。
【００５８】
コンピュータ１１０は、エントリ１０２のうちの少なくとも１つにアクセスしようとする場合、ＤＢアクセス要求を送信する。具体的には、エントリ１０２が記憶装置１０１ａに記憶されているステップＳ１では、コンピュータ１１０は、ＤＢアクセス要求１２０ａをコンピュータ１００ａに送信する。また、エントリ１０２が記憶装置１０１ｂに記憶されているステップＳ２では、コンピュータ１１０は、ＤＢアクセス要求１２０ｂをコンピュータ１００ｂに送信する。なお、「コンピュータ１１０は、なぜ、ステップＳ１ではＤＢアクセス要求１２０ａをコンピュータ１００ａに送信することができ、ステップＳ２ではＤＢアクセス要求１２０ｂをコンピュータ１００ｂに送信することができるのか」という理由については後述する。
【００５９】
ＤＢアクセス要求１２０ａは、コンピュータ１００ａのネットワークインタフェイスＩａにおいて受信される。そして、コンピュータ１００ａは、ＤＢアクセス要求１２０ａにしたがって記憶装置１０１ａにアクセスし、ＤＢアクセス応答をコンピュータ１１０に返す。
【００６０】
また、ＤＢアクセス要求１２０ｂは、コンピュータ１００ｂのネットワークインタフェイスＩｂにおいて受信される。そして、コンピュータ１００ｂは、ＤＢアクセス要求１２０ｂにしたがって記憶装置１０１ｂにアクセスし、ＤＢアクセス応答をコンピュータ１１０に返す。
【００６１】
このように、キーが部分集合Ｋａに属するエントリに対するＤＢアクセス要求に応答するのは、当該エントリを記憶しているノードである。以下では、ある部分集合Ｋｊ（０≦ｊ≦Ｍ−１）にキーが属するエントリをノードのローカルな記憶装置に記憶しているノードを、「部分集合Ｋｊの担当ノード」または「部分集合Ｋｊを担当するノード」ともいう。
【００６２】
ところで、１つのノードは、１つの部分集合のみを担当する場合もあるし、複数の部分集合を担当する場合もある。すると、各ノードが担当する部分集合の数に応じて、ノード間の負荷が偏ることがある。
【００６３】
また、ある部分集合にキーが属するエントリへのＤＢアクセス要求は多く、別の部分集合にキーが属するエントリへのＤＢアクセス要求は少ない、という場合もある。すると、ＤＢアクセス要求の量に応じて、ノード間の負荷が偏ることもある。
【００６４】
例えば、コンピュータ１００ａの負荷が高く、コンピュータ１００ｂの負荷が低ければ、負荷分散のために、コンピュータ１００ａの負荷の一部をコンピュータ１００ｂに移すことが好ましい。例えば上記のような負荷分散を目的として、部分集合Ｋａの担当ノードがコンピュータ１００ａからコンピュータ１００ｂに変更され、ステップＳ１からステップＳ２への状況の変化が生じる、という場合がある。
【００６５】
もちろん、ステップＳ１からステップＳ２への状況の変化は、他の原因によることもある。例えば以下のような場合である。
図１では、ステップＳ１を示す上段にもコンピュータ１００ｂが描かれている。しかし、ステップＳ１の段階では、コンピュータ１００ｂが分散ＤＢシステムのノードとして存在しなくてもよい。コンピュータ１００ｂが新たなノードとして追加されたことが原因で、ステップＳ１からステップＳ２へと状況が変化することもある。
【００６６】
また、図１では、ステップＳ２を示す下段にもコンピュータ１００ａが描かれている。しかし、ステップＳ２の段階では、コンピュータ１００ａが分散ＤＢシステムのノードとして存在しなくてもよい。つまり、ステップＳ１の直後にコンピュータ１００ａが故障した場合などに、コンピュータ１００ｂが部分集合Ｋａの担当を引き継ぐことにより、ステップＳ１からステップＳ２へと状況が変化することもある。
【００６７】
以上のように、引き継ぎ（takeover）は、障害発生を契機とするフェイルオーバ（failover）のこともあるし、障害とは無関係なこともある。しかし、状況の変化の原因が何であれ、ステップＳ１からステップＳ２へと状況が変化する際にコンピュータ１００ｂは、ＤＢからエントリ１０２を取得し、取得したエントリ１０２を記憶装置１０１ｂに記憶する。
【００６８】
なお、上記では「ＤＢからエントリ１０２を取得」と述べたが、より具体的には、コンピュータ１００ｂは、コンピュータ１００ａからエントリ１０２を取得してもよい。あるいは、もしコンピュータ１００ａ以外の不図示のコンピュータ（つまり、複数のノードのうちの他の１つ）がエントリ１０２のバックアップコピーを有していれば、コンピュータ１００ｂは、当該不図示のコンピュータからエントリ１０２を取得してもよい。
【００６９】
また、エントリ１０２を取得したコンピュータ１００ｂはさらに、ある特定の通信端点情報をコンピュータ１００ｂのネットワークインタフェイスＩｂと対応づける。この対応づけにより、部分集合Ｋａの担当ノードがコンピュータ１００ａからコンピュータ１００ｂに変化したことが、他のコンピュータ（例えば、コンピュータ１１０や、複数のノードのうちの不図示の他のノード）にも認識可能となる。その理由の詳細は、以下のとおりである。
【００７０】
通信端点情報は、通信端点（communication end point）を論理的に識別するための情報である。例えば、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）プロトコルスイートにしたがった通信においては、通信端点は、ＩＰアドレスとポート番号の組み合わせによって論理的に識別される。以下では特に断らないが、ポート番号は、例えばＴＣＰやＵＤＰ（User Datagram Protocol）などの、ＴＣＰ／ＩＰプロトコルスイートにおけるトランスポート層プロトコルでの、ポート番号のことである。
【００７１】
ただし、ある通信端点との通信を行おうとするコンピュータは、通信端点情報として、必ずしもＩＰアドレスとポート番号の双方を取得する必要はない。コンピュータが通信端点情報としてＩＰアドレスのみを取得すれば十分な場合もある。
【００７２】
例えば、図１のような分散ＤＢシステムのためのＤＢアプリケーションにおいて、ポート番号は固定された値であってもよい。ポート番号が予め決められた定数の場合、任意のコンピュータは、目的の通信端点のＩＰアドレスさえ取得することができれば、取得したＩＰアドレスと固定された既知のポート番号により、目的の通信端点を論理的に識別することができる。
【００７３】
また、１つのアプリケーションが使うポート番号は、必ずしも１つに限定されるわけではない。例えば、７０００以上７０２０以下の任意のポート番号が、同じ１つのＤＢアプリケーションにより使われてもよい。すると、任意のコンピュータは、目的の通信端点のＩＰアドレスさえ取得することができれば、取得したＩＰアドレスと、７０００以上７０２０以下の範囲から適宜選択したポート番号により、目的の通信端点を論理的に識別することができる。
【００７４】
したがって、通信端点情報は、例えばＩＰアドレスのみであってもよいし、ＩＰアドレスとポート番号のペアであってもよい。いずれにせよ、通信端点情報は通信端点を論理的に識別するための情報であり、物理的な識別情報ではない。よって、通信端点情報によって論理的に識別される通信端点と物理的な実体との間の対応関係は、動的に変更することが可能である。
【００７５】
本実施形態では、式（１）に示すＭ個の部分集合Ｋ０〜ＫＭ−１に合わせて、Ｍ個の通信端点をそれぞれ論理的に識別するための、少なくともＭ個の通信端点情報が使われる。詳しくは図８などとともに後述するが、各部分集合Ｋｊに対して２以上の通信端点情報が対応づけられていてもよい。例えば、各部分集合Ｋｊに対して３個の通信端点情報が対応づけられる場合は、３Ｍ個の通信端点をそれぞれ論理的に識別する３Ｍ個の通信端点情報が使われる。
【００７６】
各通信端点情報は、Ｍ個の部分集合Ｋ０〜ＫＭ−１のいずれか１つに静的に対応づけられる。例えば、図１の例では、通信端点情報Ｐａは、部分集合Ｋａと静的に対応づけられる。
【００７７】
以下、説明の便宜上、キーの定義域Ｋを、「キー空間」（key space）ともいう。また、式（１）の部分集合Ｋ０〜ＫＭ−１のそれぞれを、「キー領域」（key region）ともいう。キー領域は、キー空間の部分空間である。
【００７８】
上述の通信端点情報とキーの部分集合の静的な対応づけは、本実施形態では、図１に示すように、静的対応づけ情報１１１としてコンピュータ１１０に記憶される。なお、図１ではコンピュータ１１０のみが静的対応づけ情報１１１を含むが、コンピュータ１００ａと１００ｂも同様に、静的対応づけ情報１１１を記憶していてもよい。
【００７９】
図１では、紙面の都合上、静的対応づけ情報１１１の例として、キー領域Ｋａ（つまり部分集合Ｋａ）と通信端点情報Ｐａとの対応づけのみが示されている。しかし、静的対応づけ情報１１１は、所定個数（例えば、各部分集合Ｋｊに対して３個の通信端点情報が対応づけられる場合は、３Ｍ個）の通信端点情報のそれぞれを、Ｍ個のキー領域Ｋ０〜ＫＭ−１のいずれか１つに、静的に対応づける情報である。
【００８０】
また、各通信端点情報は、ＤＢを分散して記憶する複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられる。
例えば、ステップＳ１では、キー領域Ｋａにキーが属する全エントリ１０２が、記憶装置１０１ａに記憶されている。よって、キー領域Ｋａに静的に対応づけられている通信端点情報Ｐａは、ステップＳ１では、記憶装置１０１ａへのアクセスを提供するネットワークインタフェイスＩａに対応づけられている。
【００８１】
また、ステップＳ２では、エントリ１０２が記憶装置１０１ｂに記憶されている。よって、ステップＳ２では、通信端点情報Ｐａは、記憶装置１０１ｂへのアクセスを提供するネットワークインタフェイスＩｂに対応づけられている。
【００８２】
以上のような通信端点情報とネットワークインタフェイスとの動的な対応づけは、本実施形態では、図１に示すように、動的対応づけ情報１１２としてコンピュータ１１０に記憶される。なお、図１ではコンピュータ１１０のみが動的対応づけ情報１１２を含むが、コンピュータ１００ａと１００ｂも同様に、動的対応づけ情報１１２を記憶していてもよい。
【００８３】
図１では、紙面の都合上、動的対応づけ情報１１２の例として、通信端点情報Ｐａとネットワークインタフェイスの対応づけのみが示されている。具体的には、ステップＳ１での動的対応づけ情報１１２は、通信端点情報ＰａとネットワークインタフェイスＩａを対応づけている。しかし、動的対応づけ情報１１２は動的に書き換え可能なので、ステップＳ２での動的対応づけ情報１１２は、通信端点情報ＰａとネットワークインタフェイスＩｂを対応づけている。もちろん、動的対応づけ情報１１２は、他の通信端点情報と他のネットワークインタフェイスとをさらに対応づけてもいる。
【００８４】
ところで、上記のとおり、通信端点情報はＩＰアドレスを含み、ネットワークインタフェイスはＭＡＣアドレスにより識別される。したがって、通信端点情報とネットワークインタフェイスを動的に対応づける動的対応づけ情報１１２として、例えば、ＡＲＰ（Address Resolution Protocol）テーブルのエントリが使われてもよい。
【００８５】
ＡＲＰテーブルは、ＡＲＰキャッシュとも呼ばれ、ＩＰアドレスとＭＡＣアドレスを対応づけるエントリを含む。また、ＡＲＰテーブルの各エントリは、ＡＲＰ要求とＡＲＰ応答に基づいて作成および更新され、所定時間にわたって一度もアクセスされない場合は消去される。このように、ＡＲＰテーブルの各エントリは、ＩＰアドレスとＭＡＣアドレスを動的に対応づける動的対応づけ情報１１２の好適な一例である。
【００８６】
さてここで、ステップＳ１からステップＳ２へと状況が変化する際に、コンピュータ１００ｂが取得するエントリ１０２とは、上記のとおり、キーが部分集合Ｋａに属するすべてのエントリである。そこで、ステップＳ１からステップＳ２への移行時に、コンピュータ１００ｂは、コンピュータ１００ｂが新たに担当する部分集合Ｋａと静的に対応づけられている通信端点情報Ｐａを、コンピュータ１００ｂ自体のネットワークインタフェイスＩｂと対応づける。つまり、上記の「ある特定の通信端点情報」とは、図１の例では通信端点情報Ｐａである。
【００８７】
上記のとおり、ネットワークインタフェイスＩｂは、例えばＭＡＣアドレスにより識別され、通信端点情報Ｐａは、ＩＰアドレスを含む。よって、コンピュータ１００ｂによる通信端点情報ＰａとネットワークインタフェイスＩｂの対応づけは、具体的には、例えば「ＩＰエリアシング（IP aliasing）」と呼ばれる技術により実現することができる。
【００８８】
ＩＰエリアシング機能は、いくつかのＯＳ（Operating System）に実装されている。ＩＰエリアシング機能は、１つのネットワークインタフェイスに複数のＩＰアドレスを割り当てるための機能である。つまり、ＩＰエリアシング機能により、１つのＭＡＣアドレスに複数のＩＰアドレスを対応づけることが可能となる。
【００８９】
そして、コンピュータ１００ｂが通信端点情報ＰａをネットワークインタフェイスＩｂと対応づけると、コンピュータ１１０は、「通信端点情報ＰａがネットワークインタフェイスＩｂに対応づけられた」と認識することができる。つまり、コンピュータ１１０は、動的対応づけ情報１１２を更新することができる。理由は以下のとおりである。
【００９０】
実際の通信では、通信端点情報Ｐａのような論理的な情報により宛先が指定されるメッセージは、カプセル化されて、下位層のフレームのペイロードの中に含められる。そして、下位層のフレームが送信される。例えば、ＩＰデータグラムがイーサネットフレームのペイロードに含められ、イーサネットフレームが送信される（なお、「イーサネット」は登録商標である）。
【００９１】
そこで、コンピュータ１１０は、通信端点情報Ｐａにより論理的に識別される通信端点宛のメッセージを送信する前に、通信端点情報Ｐａにより論理的に識別される通信端点として働くネットワークインタフェイスを物理的に識別する物理的な識別情報を調べる。具体的には、コンピュータ１１０は、動的対応づけ情報１１２を参照して、通信端点情報Ｐａに対応する物理的な識別情報を調べる。
【００９２】
もし、動的対応づけ情報１１２によって通信端点情報Ｐａが何らかの物理的な識別情報と対応づけられていれば、コンピュータ１１０は、通信端点情報Ｐａと対応づけられた物理的な識別情報を、下位の層のフレームの宛先に指定する。
【００９３】
逆に、動的対応づけ情報１１２が、通信端点情報Ｐａをどの物理的な識別情報とも対応づけていなければ、コンピュータ１１０は、ブロードキャストにより、通信端点情報Ｐａに対応するネットワークインタフェイスを問い合わせる。すると、通信端点情報Ｐａに対応づけられたネットワークインタフェイスを有するコンピュータが問い合わせに応答する。
【００９４】
例えば、コンピュータ１００ｂが通信端点情報ＰａをネットワークインタフェイスＩｂと対応づけた後、コンピュータ１１０からの問い合わせがブロードキャストされると、コンピュータ１００ｂが問い合わせに応答する。すると、コンピュータ１１０は応答を受信し、通信端点情報Ｐａに対応する物理的な識別情報として、ネットワークインタフェイスＩｂを識別する識別情報を取得する。
【００９５】
さらに、コンピュータ１１０は、受信した応答に基づき、動的対応づけ情報１１２を更新する。つまり、コンピュータ１１０は、通信端点情報ＰａとネットワークインタフェイスＩｂを対応づけるように、動的対応づけ情報１１２を更新する。そして、コンピュータ１１０は、更新した動的対応づけ情報１１２にしたがって、ネットワークインタフェイスＩｂを物理的に識別する識別情報を、フレームの宛先に指定する。
【００９６】
以上のように、実際の通信は、論理的な識別情報を物理的な識別情報に解決（resolve）する処理をともなう。そして、解決のために、必要に応じて上記のように問い合わせがブロードキャストされ、応答に基づいて動的対応づけ情報１１２が更新される。よって、論理的な識別情報と物理的な識別情報の対応づけがたとえ動的に変化しても、動的対応づけ情報１１２は、変化に追従して適切に更新される。
【００９７】
また、仮にコンピュータ１１０が動的対応づけ情報１１２を参照した時点で、動的対応づけ情報１１２が偶然まだステップＳ１の状態のままであったとしても、適宜の処理をコンピュータ１１０が行えば問題はない。ここで「適宜の処理」とは、通信において一般的なタイムアウト処理とリトライ処理であってもよいし、動的な情報の管理において一般的なエージング処理であってもよいし、これらの処理の組み合わせであってもよい。
【００９８】
例えば、コンピュータ１１０は、ＤＢアクセス要求１２０ｂを送信しようとして動的対応づけ情報１１２を参照し、動的対応づけ情報１１２から、「通信端点情報ＰａにはネットワークインタフェイスＩａが対応する」という古い情報を得るかもしれない。その結果、コンピュータ１１０は、ネットワークインタフェイスＩａを物理的に識別する情報を、ＤＢアクセス要求１２０ｂのフレームの宛先に指定するかもしれない。
【００９９】
しかし、ステップＳ２の時点では、ネットワークインタフェイスＩａと通信端点情報Ｐａの対応づけは、もはや解消されている。よって、たとえコンピュータ１００ａのネットワークインタフェイスＩａにおいて、ＤＢアクセス要求１２０ｂのフレームが受信されるとしても、ＤＢアクセス要求１２０ｂは、コンピュータ１００ａにおいて破棄される。すると、ＤＢアクセス要求１２０ｂへの応答は返ってこない。
【０１００】
つまり、もし、コンピュータ１１０が、古い動的対応づけ情報１１２による誤った解決結果に基づいてＤＢアクセス要求１２０ｂのフレームを送信したとすると、コンピュータ１１０は、応答を得られず、タイムアウトする。コンピュータ１１０は、タイムアウトに応じて適宜のリトライ処理を行うことで、動的対応づけ情報１１２を更新することができる。
【０１０１】
例えば、コンピュータ１１０は、応答が得られずタイムアウトしたＤＢアクセス要求１２０ｂの宛先を論理的に識別する通信端点情報ＰａとネットワークインタフェイスＩａとの対応づけを、動的対応づけ情報１１２から強制的に削除してもよい。その後、コンピュータ１１０は、再度ＤＢアクセス要求１２０ｂの送信を試みてもよい。
【０１０２】
すると、強制削除の後の動的対応づけ情報１１２は、通信端点情報Ｐａをどの物理的な識別情報とも対応づけていないので、コンピュータ１１０は上記のブロードキャストによる問い合わせを行う。その結果、動的対応づけ情報１１２は正しく更新される。すなわち、「通信端点情報ＰａにはネットワークインタフェイスＩｂが対応づけられている」という新しい状況が、動的対応づけ情報１１２に反映される。
【０１０３】
そして、コンピュータ１１０が更新後の動的対応づけ情報１１２に基づいてＤＢアクセス要求１２０ｂのフレームの宛先を決定すると、ＤＢアクセス要求１２０ｂは、今度は正しくコンピュータ１００ｂに受信される。そして、コンピュータ１１０は、コンピュータ１００ｂからＤＢアクセス要求１２０ｂに対する応答を受信することができる。
【０１０４】
あるいは、コンピュータ１１０は、上記のような明示的なタイムアウト処理とリトライ処理を行わないかもしれない。その代わり、コンピュータ１１０は、動的対応づけ情報１１２に対するエージング処理を行い、動的対応づけ情報１１２が古くなったら強制的に動的対応づけ情報１１２を削除してもよい。
【０１０５】
すると、通信端点情報ＰａとネットワークインタフェイスＩａを対応づける古い動的対応づけ情報１１２は、エージング処理によっていずれは削除される。よって、通信端点情報Ｐａを宛先に指定した何らかのメッセージ（例えばＤＢアクセス要求１２０ｂでもよい）を、古い動的対応づけ情報１１２の削除後にコンピュータ１１０が送信しようとすると、上記と同様にブロードキャストによる問い合わせが生じる。
【０１０６】
その結果、やはり動的対応づけ情報１１２は正しく更新される。すると、コンピュータ１１０は、正しく更新された動的対応づけ情報１１２に基づいて上記メッセージを送信する。よって、上記メッセージは、「通信端点情報ＰａにはネットワークインタフェイスＩｂが対応づけられている」という新しい状況に合わせて、適切にネットワークインタフェイスＩｂで受信される。
【０１０７】
以上説明したとおりなので、コンピュータ１００ｂが通信端点情報ＰａをネットワークインタフェイスＩｂと対応づけると、コンピュータ１１０は、「通信端点情報ＰａがネットワークインタフェイスＩｂに対応づけられた」と認識することができる。つまり、コンピュータ１１０は、認識した結果にしたがって、動的対応づけ情報１１２を更新することができる。
【０１０８】
よって、ステップＳ１からステップＳ２へと状況が変化してから多少のタイムラグはあるかもしれないが、コンピュータ１１０は、状況の変化に合わせて動的対応づけ情報１１２を適切に更新することができる。そして、コンピュータ１１０は、適切に更新した動的対応づけ情報１１２に基づいて、ＤＢアクセス要求１２０ｂなどの任意のメッセージを、適切な宛先に送信することができる。
【０１０９】
換言すれば、コンピュータ１１０は、動的対応づけ情報１１２を動的に更新することにより、ステップＳ１においては、ＤＢアクセス要求１２０ａのフレームの宛先として、ネットワークインタフェイスＩａを識別する識別情報を正しく指定することができる。また、コンピュータ１１０は、動的対応づけ情報１１２を動的に更新することにより、ステップＳ２においては、ＤＢアクセス要求１２０ｂのフレームの宛先として、ネットワークインタフェイスＩｂを識別する識別情報を正しく指定することができる。
【０１１０】
その結果、ＤＢアクセス要求１２０ａは正しくコンピュータ１００ａで受信され、ＤＢアクセス要求１２０ｂは正しくコンピュータ１００ｂで受信される。すなわち、キー領域Ｋａを担当するノードがコンピュータ１００ａからコンピュータ１００ｂに変化したとしても、コンピュータ１１０は、変化に応じて、キー領域Ｋａを担当するノードにＤＢアクセス要求を送信することができる。
【０１１１】
なお、ＤＢアクセス要求１２０ａと１２０ｂの各々は、少なくとも以下の（１−１）〜（１−３）のフィールドを含む。
（１−１）ＤＢアクセス要求の宛先の通信端点を識別するための通信端点情報
（１−２）コンピュータ１１０がアクセスしようとするエントリを識別するためのキー
（１−３）ＤＢに対して行う操作の内容を示す要求内容
【０１１２】
具体的には、ＤＢアクセス要求１２０ａには、通信端点情報Ｐａと、キー領域Ｋａに属するキーｋ１と、適宜の要求内容が指定されている。また、ＤＢアクセス要求１２０ｂには、通信端点情報Ｐａと、キー領域Ｋａに属するキーｋ２と、適宜の要求内容が指定されている。
【０１１３】
以上のＤＢアクセス要求１２０ａと１２０ｂの例から明らかなとおり、ＤＢアクセス要求に指定される通信端点情報は、ＤＢアクセス要求に指定されるキーが属するキー領域と静的対応づけ情報１１１によって対応づけられている通信端点情報である。よって、コンピュータ１１０は、まず、アクセスしようとするエントリのキーから、当該キーの属するキー領域を決定する。そして、コンピュータ１１０は、静的対応づけ情報１１１を参照することにより、決定したキー領域に対応する通信端点情報を取得し、取得した通信端点情報をＤＢアクセス要求に指定する。
【０１１４】
なお、コンピュータ１１０は、キー領域がどのように定義されているかに応じて、キーから適宜キー領域を決定することができる。例えば、キー領域が式（２）にしたがって定義されているとする。この場合、コンピュータ１１０にとって定数Ｍは既知である。よって、コンピュータ１１０がアクセスしようとするエントリのキーが例えばキーｋ１であれば、コンピュータ１１０は、式（２）にしたがってｍｏｄ（ｋ１，Ｍ）を計算し、計算結果に応じて、キーｋ１が属するキー領域Ｋａを決定することができる。キー領域が他の式によって定義されている場合も同様である。
【０１１５】
また、（１−３）の要求内容は、分散ＤＢシステムのためのＤＢアプリケーションの仕様に応じて適宜の書式で表される。例えば、ＤＢに対して行う操作として、エントリを読み出すリード操作と、エントリにデータを書き込むライト操作の２種類の操作のみをＤＢアプリケーションが定義していてもよい。その場合、要求内容は、操作の種類を示すフィールドと、ライト操作で書き込む対象のデータを表すオプショナルなフィールドとを含んでいてもよい。
【０１１６】
また、ＤＢアプリケーションによっては、ライト操作の代わりに、新たなエントリを追加するインサート操作と、既存のエントリを書き換えるアップデート操作を定義していてもよい。この場合も、要求内容は、操作の種類を示すフィールドと、インサート操作またはアップデート操作で書き込む対象のデータを表すオプショナルなフィールドとを含んでいてもよい。また、要求内容として、既存のエントリを削除するデリート操作がさらに指定可能であってもよい。
【０１１７】
以上のように、ＤＢアクセス要求が通信端点情報とキーと要求内容を含むので、ＤＢアクセス要求を受信したノードは、ＤＢアクセス要求にしたがって、アクセス対象のエントリを識別し、識別したエントリに対して、要求された操作を実行することができる。その結果、ＤＢアクセス要求を受信したノードは、ＤＢアクセスの結果を、ＤＢアクセス要求の送信元のコンピュータ１１０に対して、ＤＢアクセス応答として返信することができる。
【０１１８】
ＤＢアクセス応答の形式は実施形態に応じて任意である。例えば、リード操作が要求された場合のＤＢアクセス応答は、ＤＢアクセス要求に指定されたキーに対応するエントリのデータを含む。また、リード操作以外の操作に対するＤＢアクセス応答は、例えば、操作が成功したか否かを示す情報を含んでもよい。
【０１１９】
続いて、静的対応づけ情報１１１と動的対応づけ情報１１２による対応づけに関して、図２を参照してさらに詳しく説明する。図２は、キー領域と通信端点とノードとの対応づけの一例を示す図である。
【０１２０】
図２において、ドーナツ状の灰色の部分が、キー空間Ｋ（つまりキーの定義域Ｋ）を示す。キー空間Ｋは、図２の例では、１６個の互いに素なキー領域Ｋ０〜Ｋ１５（つまり定義域Ｋにおける互いに素な部分集合Ｋ０〜Ｋ１５）に分割される。図２の例では、式（１）のＭの値は１６である。
【０１２１】
そして、上記のとおり静的対応づけ情報１１１は、各キー領域Ｋｊ（０≦ｊ≦Ｍ−１）に対して、キー領域Ｋｊと通信端点情報Ｐｊを静的に対応づける。キー領域Ｋｊと通信端点情報Ｐｊの対応づけは、換言すれば、キー領域Ｋｊと、通信端点情報Ｐｊで識別される通信端点との対応づけである。
【０１２２】
図２では、通信端点情報Ｐ０〜Ｐ１５は、黒い円で表されている。そして、静的対応づけ情報１１１によるキー領域Ｋｊと通信端点情報Ｐｊの静的な対応づけは、黒い円と灰色のブロックの間の実線により示されている。
【０１２３】
他方、動的対応づけ情報１１２は、通信端点情報とネットワークインタフェイスを動的に対応づける。換言すれば、動的対応づけ情報１１２は、通信端点情報と静的に対応づけられているキー領域を、通信端点情報を介して、ネットワークインタフェイスに動的に対応づける。
【０１２４】
また、個々のネットワークインタフェイスは、複数のノードのいずれかに静的に対応する。よって、動的対応づけ情報１１２は、通信端点情報とネットワークインタフェイスの対応づけを介して、キー領域とノードとを対応づけてもいる。つまり、動的対応づけ情報１１２は、キー領域に静的に対応づけられた通信端点情報と、ノードが有するネットワークインタフェイスとの対応づけにより、当該ノードが当該キー領域を担当することを示してもいる。
【０１２５】
そして、図２において破線の楕円形はノードを示す。つまり、図２の例では、分散ＤＢシステムに５つのノードＮ１〜Ｎ５が含まれる。また、動的対応づけ情報１１２による動的な対応づけは、図２において楕円形と灰色のブロックの対応づけに相当する。
【０１２６】
具体的には、図２の例では、ノードＮ１は、キー領域Ｋ１、Ｋ２およびＫ３を担当している。つまり、ノードＮ１は、ノードＮ１自体が有するネットワークインタフェイスに、３つのキー領域Ｋ１、Ｋ２およびＫ３に対応する３つの通信端点情報Ｐ１、Ｐ２およびＰ３を対応づけている。そして、ノードＮ１は、ノードＮ１自体が有する記憶装置に、キー領域Ｋ１、Ｋ２およびＫ３のいずれかにキーが属するすべてのエントリを記憶している。
【０１２７】
また、図２の例では、ノードＮ２は、キー領域Ｋ４、Ｋ５、Ｋ６およびＫ７を担当している。つまり、ノードＮ２は、ノードＮ２自体が有するネットワークインタフェイスに、４つのキー領域Ｋ４、Ｋ５、Ｋ６およびＫ７に対応する４つの通信端点情報Ｐ４、Ｐ５、Ｐ６およびＰ７を対応づけている。そして、ノードＮ２は、ノードＮ２自体が有する記憶装置に、キー領域Ｋ４、Ｋ５、Ｋ６およびＫ７のいずれかにキーが属するすべてのエントリを記憶している。
【０１２８】
また、図２の例では、ノードＮ３は、キー領域Ｋ８、Ｋ９、Ｋ１０およびＫ１１を担当している。つまり、ノードＮ３は、ノードＮ３自体が有するネットワークインタフェイスに、４つのキー領域Ｋ８、Ｋ９、Ｋ１０およびＫ１１に対応する４つの通信端点情報Ｐ８、Ｐ９、Ｐ１０およびＰ１１を対応づけている。そして、ノードＮ３は、ノードＮ３自体が有する記憶装置に、キー領域Ｋ８、Ｋ９、Ｋ１０およびＫ１１のいずれかにキーが属するすべてのエントリを記憶している。
【０１２９】
また、図２の例では、ノードＮ４は、キー領域Ｋ１２、Ｋ１３およびＫ１４を担当している。つまり、ノードＮ４は、ノードＮ４自体が有するネットワークインタフェイスに、３つのキー領域Ｋ１２、Ｋ１３およびＫ１４に対応する３つの通信端点情報Ｐ１２、Ｐ１３およびＰ１４を対応づけている。そして、ノードＮ４は、ノードＮ４自体が有する記憶装置に、キー領域Ｋ１２、Ｋ１３およびＫ１４のいずれかにキーが属するすべてのエントリを記憶している。
【０１３０】
また、図２の例では、ノードＮ５は、キー領域Ｋ１５およびＫ０を担当している。つまり、ノードＮ５は、ノードＮ５自体が有するネットワークインタフェイスに、２つのキー領域Ｋ１５およびＫ０に対応する２つの通信端点情報Ｐ１５およびＰ０を対応づけている。そして、ノードＮ５は、ノードＮ５自体が有する記憶装置に、キー領域Ｋ１５およびＫ０のいずれかにキーが属するすべてのエントリを記憶している。
【０１３１】
なお、図示の便宜上、図２には、各ノードが連続した複数のキー領域を担当している例を示した。しかし、各ノードが担当するキー領域は必ずしも連続していなくてもよい。例えば、ノードの構成が動的に変化した結果として、ある時点においてノードＮ３がキー領域Ｋ１とＫ８とＫ９とＫ１２を担当することになってもよい。
【０１３２】
ところで、図２のクライアントＣは、例えば図１のコンピュータ１１０であってもよく、コンピュータ１００ａや１００ｂであってもよい。したがって、クライアントＣは、図１の静的対応づけ情報１１１を記憶している。
【０１３３】
よって、クライアントＣは、クライアントＣがアクセスしようとするエントリに対応するキーから、ＤＢアクセス要求の宛先の通信端点を静的に決定することができる。つまり、本実施形態の利点の一つは、クライアントＣが直接的にＤＢアクセス要求の宛先の通信端点を決定することができる点である。
【０１３４】
つまり、クライアントＣは、ＤＢアクセス要求の宛先の通信端点をキーから決定するために、例えばゲートウェイサーバなどの他のコンピュータに問い合わせを送信する必要がない。換言すれば、どのノードがどのキー領域を担当しているかを管理するためのゲートウェイサーバなどのコンピュータが、本実施形態では不要である。したがって、本実施形態では、他の分散ＤＢシステムにおいて生じ得る以下のような様々な問題を避けることができる。
【０１３５】
ＤＢアクセス要求の宛先をキーから決定するためのゲートウェイサーバを含む分散ＤＢシステムでは、ゲートウェイサーバが分散ＤＢシステム全体の単一故障点（ＳＰｏＦ：Single Point of Failure）になってしまう。また、ゲートウェイサーバは、分散ＤＢシステム全体の性能のボトルネックにもなってしまう。仮に２台以上のゲートウェイサーバが存在するとしても、それらのゲートウェイサーバがボトルネックであることに変わりはない。つまり、ゲートウェイサーバは、耐故障性と性能の両面での問題を引き起こしかねない。
【０１３６】
さらに、上記のようなゲートウェイサーバを含む分散ＤＢシステムでは、クライアントが、ＤＢアクセス要求の宛先のノードを尋ねる問い合わせをゲートウェイサーバに送信し、ゲートウェイサーバがクライアントに応答を返す。その後、クライアントは、ゲートウェイサーバからの応答において通知されたノードを宛先に指定して、ＤＢアクセス要求を送信する。したがって、クライアントからゲートウェイサーバへの問い合わせとゲートウェイサーバからクライアントへの応答にかかる時間のぶん、ＤＢアクセスのレイテンシは長くなる。
【０１３７】
仮に、ゲートウェイサーバが、クライアントから問い合わせを受け付けてクライアントに応答を返す代わりに、以下のように動作するとしても、レイテンシへの悪影響は避けられない。つまり、仮に、ゲートウェイサーバが、クライアントからＤＢアクセス要求を受け付け、ＤＢアクセス要求からノードを決定し、決定したノードにＤＢアクセス要求を転送するとしても、ゲートウェイサーバの利用によりＤＢアクセスのレイテンシが悪化する。なぜなら、クライアントからゲートウェイサーバへの通信が行われることに変わりはないからである。
【０１３８】
しかし、本実施形態によれば、ゲートウェイサーバがなくてもクライアント自体がＤＢアクセス要求の宛先の通信端点をキー自体といくつかの既知の情報だけから決定することができる。ここで「既知の情報」とは、例えば式（３）によりキー領域Ｋｊが定義される場合ならば、定数Ｍの値と、キーからキー領域を決定するためのｍｏｄ（ｈａｓｈ（ｋ，Ｍ）という関数の定義である。よって、本実施形態によれば、ゲートウェイサーバに起因する上記のような様々な問題が回避可能である。
【０１３９】
また、ノードとキー領域を直接動的に対応づける情報を、上記のように少数のゲートウェイサーバだけが保持する代わりに、多数のクライアントが保持するような分散ＤＢシステムも考えられる。しかしながら、多数のクライアントが動的な情報を保持するシステムでは、多数のクライアントがそれぞれ保持する情報を最新の状態に保つための複雑なプロトコルと、当該プロトコルにしたがった多数の制御メッセージの交換が必要になる。したがって、ノード数に比べて交換される制御メッセージの数が多すぎる場合では特に、制御メッセージの交換によるオーバヘッドが分散ＤＢシステム全体の性能に悪影響を与えることがある。したがって、現実には、多数のクライアントが動的な情報を最新の状態に保ちつつ保持することは非常に難しい。
【０１４０】
以上のように、他の分散ＤＢシステムでは様々な問題が生じ得る。しかしながら、図１〜２を参照して説明した本実施形態によれば、キー領域と通信端点は、静的対応づけ情報１１１によって静的に対応づけられるので、上記のような様々な問題を回避することが可能である。つまり、本実施形態では、静的対応づけ情報１１１の保守コストはゼロであり、ゲートウェイサーバの導入によって生じ得る、耐故障性・性能・レイテンシ等の悪化も生じない。
【０１４１】
続いて、本実施形態が適用されるネットワークの例について図３〜４を参照して説明する。
図３は、第１のネットワーク構成例の図である。図３の例では、１つのブロードキャストドメイン２００の中に、ＤＢを分散して記憶する８つのノードＮ１１〜Ｎ１８と、デプロイサーバ（deployment server）２０１と、クライアント２０２と、ルータ２０３が含まれる。
【０１４２】
デプロイサーバ２０１は、分散ＤＢシステムのデプロイ時に、ノードＮ１１〜Ｎ１８の初期化を行う。初期化には、ＯＳのインストールや、コンピュータを分散ＤＢシステムのノードとして動作させるためのプログラムのインストールなどの処理が含まれる。また、デプロイサーバ２０１はさらに、初期状態における各ノードとキー領域との対応づけを設定してもよい。さらに、デプロイサーバ２０１は、ノードＮ１１〜Ｎ１８間の負荷のバランスを監視するなど、各種の処理を行ってもよい。しかし、デプロイサーバ２０１は、なくてもよい。
【０１４３】
例えば、図１のコンピュータ１００ａは、ノードＮ１１〜Ｎ１８のうちのいずれか１つであってもよい。そして、図１のコンピュータ１００ｂは、ノードＮ１１〜Ｎ１８のうちの他のいずれか１つであってもよい。
【０１４４】
また、図１のコンピュータ１１０は、クライアント２０２であってもよい。あるいは、ＤＢアクセス要求の送信元のクライアントとしてのコンピュータ１１０は、ノードＮ１１〜Ｎ１８のうちの、コンピュータ１００ａと１００ｂ以外のいずれか１つであってもよい。
【０１４５】
例えば、あるキー領域の担当ノードが変更される場合などに、あるノードが他のノードにエントリを要求することがあり、当該要求もＤＢアクセス要求の一種である。よって、図１のコンピュータ１１０は、ノードＮ１１〜Ｎ１８のうちのいずれかであってもよい。
【０１４６】
また、ルータ２０３はインターネット２１０に接続されており、インターネット２１０には他のクライアント２２０も接続されている。図１のコンピュータ１１０は、ノードＮ１１〜Ｎ１８が属するブロードキャストドメイン２００の外部のクライアント２２０であってもよい。
【０１４７】
図４は、第２のネットワーク構成例の図である。図４の例では、ＤＢを分散して記憶する５つのノードＮ２１〜Ｎ２５が、２つのブロードキャストドメイン２３０と２４０に分かれて存在する。具体的には、ノードＮ２１、Ｎ２２およびＮ２３はブロードキャストドメイン２３０に属し、ノードＮ２４およびＮ２５はブロードキャストドメイン２４０に属する。
【０１４８】
また、ブロードキャストドメイン２３０にはルータ２３１があり、ブロードキャストドメイン２４０にはルータ２４１とアプリケーションサーバ２４２がある。そして、ルータ２３１と２４１は互いに接続されている。
【０１４９】
また、ルータ２３１と２４１はいずれもインターネット２５０に接続されている。インターネット２５０には、クライアントＰＣ（Personal Computer）２６０も接続されている。
【０１５０】
例えば、図１のコンピュータ１００ａは、ノードＮ２１〜Ｎ２５のうちのいずれか１つであってもよい。そして、図１のコンピュータ１００ｂは、ノードＮ２１〜Ｎ２５のうちの他のいずれか１つであってもよい。
【０１５１】
また、図１のコンピュータ１１０は、クライアントＰＣ２６０であってもよい。もちろん、図３に関する説明と同様に、ノードＮ２１〜Ｎ２５自体も、図１のコンピュータ１１０と同様に、他のノードに対するクライアントとして動作することがある。
【０１５２】
あるいは、アプリケーションサーバ２４２が、インターネット２５０とルータ２４１を介してクライアントＰＣ２６０からの要求を受け付けてもよい。そして、アプリケーションサーバ２４２が提供するウェブアプリケーションのバックエンドとして、分散ＤＢシステムが使われてもよい。
【０１５３】
その場合、アプリケーションサーバ２４２は、クライアントＰＣ２６０からの要求に応じて、ＤＢアクセス要求をいずれかのノードに送信することがある。つまり、図１のコンピュータ１１０は、アプリケーションサーバ２４２であってもよい。アプリケーションサーバ２４２は、ノードから受信したＤＢアクセス応答の内容に応じて、クライアントＰＣ２６０に応答（例えばＨＴＭＬ（Hypertext Markup Language）で記述されたページ）を返してもよい。
【０１５４】
続いて、本実施形態のノードとクライアントの構成について図５〜７を参照して説明する。
図５は、ノードのブロック構成図である。本実施形態では、図１のコンピュータ１００ａおよび１００ｂ、図２のノードＮ１〜Ｎ５、図３のノードＮ１１〜Ｎ１８、ならびに図４のノードＮ２１〜Ｎ２５は、いずれも、図５のノード３００のように構成される。
【０１５５】
ノード３００は、ローカルストア３１０とネットワークインタフェイス３２０と通信処理部３３０を有する。また、通信処理部３３０はＡＲＰテーブル３３１とインタフェイス設定ファイル３３２を保持する。さらに、ノード３００は、対応表３４０を保持する。
【０１５６】
そして、ノード３００は、ノード３００が担当するキー領域ごとに、１つのキー領域管理部を有する。換言すれば、ノード３００は、ノード３００が担当する通信端点ごとに、１つのキー領域管理部を有する。より詳しくは、ノード３００は、ネットワークインタフェイス３２０に動的に割り当てられたＩＰアドレスごとに、１つのキー領域管理部を有する。
【０１５７】
図５の例では説明の便宜上、ノード３００が３つの通信端点情報に対応する３つのキー領域を担当するものとする。よって、ノード３００は、３つのキー領域管理部３５０ａ〜３５０ｃを有する。
【０１５８】
キー領域管理部３５０ａ〜３５０ｃは同様の構成なので、図５にはキー領域管理部３５０ａのみ、内部の詳細を図示してある。具体的には、キー領域管理部３５０ａは、リード・ライト処理部３５１と、取得制御部３５２と、供給制御部３５３と、対応づけ部３５４と、監視依頼部３５５を有する。そして、監視依頼部３５５は依頼ノードリスト３５６を保持する。
また、ノード３００は、監視部３６０も有する。監視部３６０は対象ノードリスト３６１を保持する。
【０１５９】
以上のノード３００内の各ブロックについて詳しく説明すれば、以下のとおりである。なお、以下では特に断らない限り、層に関する言及は、ＲＦＣ（Request for Comments）１１２２と同様に、リンク層、インターネット層、トランスポート層、およびアプリケーション層の４層からなるモデルに基づく。
【０１６０】
ローカルストア３１０は、ノード３００が担当する１つ以上のキー領域に対応するエントリを記憶する。つまり、ローカルストア３１０は、図１の記憶装置１０１ａと１０１ｂに対応する。ローカルストア３１０は、好ましくはＲＡＭであるが、ハードディスク装置などの二次記憶装置であってもよい。
【０１６１】
ネットワークインタフェイス３２０は、図１のネットワークインタフェイスＩａやＩｂと同様である。つまり、ネットワークインタフェイス３２０は、リンク層の処理を行う。そして、ノード３００は、ネットワークインタフェイス３２０と通信処理部３３０を介して他の装置と通信する。
【０１６２】
通信処理部３３０は、ＯＳの一部を使って実現されてもよく、例えば、ＴＣＰ／ＩＰプロトコルスタックの標準ライブラリを使って実装されていてもよい。通信処理部３３０を実現するために、さらにイーサネットドライバが利用されてもよい。つまり、通信処理部３３０は、トランスポート層およびインターネット層の処理を行うとともに、インターネット層とリンク層のインタフェイス処理も行う。
【０１６３】
以下では説明の便宜上、「通信処理部３３０とネットワークインタフェイス３２０を介した通信は、ＴＣＰ／ＩＰプロトコルスイートによる通信であり、リンク層ではイーサネットが使われる」と仮定する。
【０１６４】
そして、通信処理部３３０は、上記のようにＴＣＰ／ＩＰプロトコルスイートによる通信の基盤を提供するだけでなく、他の装置から受信したメッセージを適宜のモジュールに振り分ける。つまり、通信処理部３３０は、振り分け処理というアプリケーション層の処理も行う。
【０１６５】
ここで、他の装置からノード３００が受信するメッセージには、例えば以下の（２−１）〜（２−６）のようなものがある。
（２−１）リード・ライト処理部３５１が処理する対象のＤＢアクセス要求
（２−２）取得制御部３５２が処理する対象のＤＢアクセス応答
（２−３）供給制御部３５３が処理する対象のＤＢアクセス要求
（２−４）監視依頼部３５５に対する監視用の生存確認メッセージ
（２−５）監視部３６０に対する監視依頼
（２−６）監視部３６０に対するＡＣＫ（acknowledgement）
【０１６６】
通信処理部３３０は、受信したメッセージのヘッダに指定されたタイプに応じて、上記（２−１）〜（２−６）の違いを判別してメッセージを適宜のブロックに振り分けてもよい。例えば、タイプがＡＣＫを表していれば、通信処理部３３０は、受信したメッセージを監視部３６０に出力する。
【０１６７】
また、ＤＢアクセス要求の中には、例えば、ＤＢからのデータの読み出しを求めるリード要求と、ＤＢへのデータの書き込みを求めるライト要求がある。
そして、本実施形態では、あるキー領域に対応する全エントリのコピーを求めるコピー要求も、ＤＢアクセス要求の１つである。また、あるキー領域（より詳しくは、当該キー領域に対応する通信端点）を要求の宛先のノードから引き継ぐために、当該キー領域に対応する全エントリのデータを求める引き継ぎ要求も、ＤＢアクセス要求の１つである。なお、コピー要求は、要求の宛先のノードから通信端点を引き継ぐことなく、単にエントリのコピーのみを求めるための要求である。
【０１６８】
詳しくは後述するが、コピー要求と引き継ぎ要求は、あるキー領域を担当するノードが変更されるときに使われる。そして、上記（２−２）のＤＢアクセス応答は、具体的には、コピー要求または引き継ぎ要求に対する応答（以下、それぞれ「コピー応答」と「引き継ぎ応答」という）である。
【０１６９】
なお、図１に示したように、リード要求とライト要求にはキーが指定される。また、コピー要求と引き継ぎ要求には、キー領域を識別可能な情報（例えば、式（１）〜（６）および（８）における添え字ｊのような、キー領域を識別するインデックス、または、キー領域に静的に対応づけられている通信端点情報）が指定される。
【０１７０】
ところで、あるキーが指定されたリード要求またはライト要求の宛先ＩＰアドレスと宛先ポート番号は、指定されたキーが属するキー領域に対応する通信端点を識別する、ＩＰアドレスとポート番号のペアである。同様に、あるキー領域が指定されたコピー要求または引き継ぎ要求の宛先ＩＰアドレスと宛先ポート番号は、指定されたキー領域に対応する通信端点を識別する、ＩＰアドレスとポート番号のペアである。
【０１７１】
そして、キー領域管理部３５０ａ〜３５０ｃはそれぞれ異なる通信端点情報に対応する。例えば、キー領域管理部３５０ａは、キー領域管理部３５０ａに対応する通信端点情報（具体的にはＩＰアドレスとポート番号のペア）で識別される通信端点を指定して通信処理部３３０の機能を呼び出すことで、ＴＣＰソケットを初期化してもよい。また、詳しくは後述するように、監視部３６０は、いずれのキー領域とも対応づけられない固定的なＩＰアドレスを利用する。
【０１７２】
したがって、通信処理部３３０は、受信した（２−１）〜（２−６）のメッセージを、宛先ＩＰアドレスと宛先ポート番号に応じて、キー領域管理部３５０ａ〜３５０ｃのいずれか適切な１つへ、あるいは監視部３６０へ、振り分けることができる。
【０１７３】
また、通信処理部３３０は、受信したＤＢアクセス要求のサブタイプを判別してもよい。サブタイプがリード要求またはライト要求の場合には、通信処理部３３０は、宛先ＩＰアドレスに対応するキー領域管理部内のリード・ライト処理部３５１に、リード要求またはライト要求を出力する。また、サブタイプがコピー要求または引き継ぎ要求の場合は、通信処理部３３０は、宛先ＩＰアドレスに対応するキー領域管理部内の供給制御部３５３に、コピー要求または引き継ぎ要求を出力する。
【０１７４】
その結果、例えばキー領域管理部３５０ａに対応するキー領域に属するキーが指定されたリード要求またはライト要求は、キー領域管理部３５０ａ内のリード・ライト処理部３５１に出力される。同様に、キー領域管理部３５０ａに対応するキー領域が指定されたコピー要求または引き継ぎ要求は、キー領域管理部３５０ａ内の供給制御部３５３に出力される。
【０１７５】
また、通信処理部３３０は、ＡＲＰテーブル３３１とインタフェイス設定ファイル３３２を有する。
ＡＲＰテーブル３３１は、図１の動的対応づけ情報１１２として使われる。ＡＲＰテーブル３３１は、他の装置のＩＰアドレスごとにエントリ（以下「ＡＲＰエントリ」ともいう）を有する。そして、各ＡＲＰエントリは、ＩＰアドレスと、当該ＩＰアドレスが割り当てられたネットワークインタフェイスを識別するＭＡＣアドレスとを対応づける。
【０１７６】
インタフェイス設定ファイル３３２は、ノード３００自体のネットワークインタフェイス３２０を識別するＭＡＣアドレスと、ネットワークインタフェイス３２０に割り当てられているＩＰアドレスを対応づける。ＩＰエリアシング機能により、１つのネットワークインタフェイス３２０には複数のＩＰアドレスが対応づけられる場合がある。インタフェイス設定ファイル３３２は、例えば、ＯＳによって決められた「/etc/sysconfig/network-scripts/ifcfg-eth0」などの所定のパスにある設定ファイルである。
【０１７７】
対応表３４０は、図１の静的対応づけ情報１１１の具体例である。対応表３４０の詳細なデータ例は図８とともに後述する。また、対応表３４０は、キー領域管理部３５０ａ〜３５０ｃと監視部３６０のいずれからも参照可能である。
【０１７８】
キー領域管理部３５０ａ〜３５０ｃは、例えば、別々のスレッドまたは別々のプロセスにより実現されてもよい。キー領域管理部３５０ａ〜３５０ｃは、アプリケーション層で動作する。キー領域管理部３５０ａ内の各部の動作は以下のとおりである。
【０１７９】
リード・ライト処理部３５１は、ネットワークインタフェイス３２０と通信処理部３３０を介して他の装置からＤＢアクセス要求を受信し、ＤＢアクセス要求にしたがってローカルストア３１０にアクセスする。そして、リード・ライト処理部３５１は、ＤＢアクセスの結果を、ＤＢアクセス応答として、通信処理部３３０とネットワークインタフェイス３２０を介して、ＤＢアクセス要求の送信元の装置に返す。
【０１８０】
なお、上記のとおり通信処理部３３０が振り分け処理を行うので、キー領域管理部３５０ａ内のリード・ライト処理部３５１が処理するのは、キー領域管理部３５０ａに対応するキー領域に属するキーが指定されたリード要求またはライト要求のみである。
【０１８１】
受信したＤＢアクセス要求がリード要求の場合、リード・ライト処理部３５１は、ローカルストア３１０に記憶されているエントリの内容を読み出す。また、受信したＤＢアクセス要求がライト要求の場合、リード・ライト処理部３５１は、ＤＢアクセス要求にしたがって、ローカルストア３１０にへの書き込み操作（例えば、新規エントリの作成または既存エントリの書き換え）を行う。そして、リード・ライト処理部３５１は、読み出し操作または書き込み操作の結果をＤＢアクセス応答として返す。
【０１８２】
さて、取得制御部３５２は、通信処理部３３０とネットワークインタフェイス３２０を介してコピー要求または引き継ぎ要求を他のノードに送信する。そして、取得制御部３５２は、通信処理部３３０とネットワークインタフェイス３２０を介して、他のノードから、コピー要求または引き継ぎ要求に対する応答として、あるキー領域に対応する分散ＤＢ内の全エントリを取得する。そして、取得制御部３５２は、取得した全エントリをローカルストア３１０に追加する。
【０１８３】
例えば、ノード３００が新たにあるキー領域Ｋｊを担当することに決まると、ノード３００はキー領域Ｋｊに対応する新たなキー領域管理部のスレッドを生成してもよい。説明の便宜上、キー領域管理部３５０ａのスレッドが新たに生成されたとする。すると、キー領域管理部３５０ａの取得制御部３５２が、キー領域Ｋｊを指定したコピー要求または引き継ぎ要求を送信し、キー領域Ｋｊに対応する全エントリを取得し、取得した全エントリをローカルストア３１０に追加する。
【０１８４】
供給制御部３５３は、逆に、他のノードからのコピー要求または引き継ぎ要求に応答して、他のノードにＤＢのエントリのコピーを供給する。すなわち、供給制御部３５３は、ネットワークインタフェイス３２０と通信処理部３３０を介してコピー要求または引き継ぎ要求を受信する。そして、供給制御部３５３は、コピー要求または引き継ぎ要求に指定されたキー領域に対応する全エントリをローカルストア３１０から読み出す。さらに、供給制御部３５３は、読み出した全エントリを、通信処理部３３０とネットワークインタフェイス３２０を介して、コピー要求または引き継ぎ要求の送信元のノードに送信する。
【０１８５】
また、対応づけ部３５４は、インタフェイス設定ファイル３３２を更新するための処理を行う。つまり、対応づけ部３５４はインタフェイス設定ファイル３３２を直接書き換えるか、または、インタフェイス設定ファイル３３２を書き換えるように通信処理部３３０に命じる。
【０１８６】
ノード３００が新たなキー領域を担当することになった場合、またはノード３００が今まで担当していたキー領域を担当しなくなる場合に、ネットワークインタフェイス３２０と通信端点の対応関係は変化する。そこで、ネットワークインタフェイス３２０と通信端点の対応関係が変化する場合に、対応づけ部３５４は、インタフェイス設定ファイル３３２の更新するための処理を行う。その結果、対応関係の変化がインタフェイス設定ファイル３３２に反映される。
【０１８７】
具体的には、ノード３００が新たなキー領域を担当することになると、取得制御部３５２が、当該新たなキー領域に対応する通信端点情報に含まれるＩＰアドレスを、対応づけ部３５４に指示する。すると、対応づけ部３５４は、取得制御部３５２から指示されたＩＰアドレスをネットワークインタフェイス３２０のＭＡＣアドレスと対応づけるように、インタフェイス設定ファイル３３２を更新する。インタフェイス設定ファイル３３２の更新は、対応づけ部３５４により直接的に行われてもよいし、通信処理部３３０を介して間接的に行われてもよい。
【０１８８】
また、供給制御部３５３は、引き継ぎ要求に応答した後に、供給制御部３５３を含むキー領域管理部に対応するＩＰアドレスの、ネットワークインタフェイス３２０への対応づけを解除するよう、対応づけ部３５４に指示する。すると、対応づけ部３５４は、供給制御部３５３から指示されたＩＰアドレスと、ネットワークインタフェイス３２０のＭＡＣアドレスとの対応づけを解除するように、インタフェイス設定ファイル３３２を更新する。インタフェイス設定ファイル３３２の更新は、対応づけ部３５４により直接的に行われてもよいし、通信処理部３３０を介して間接的に行われてもよい。
【０１８９】
以上のようにして、対応づけ部３５４は、取得制御部３５２または供給制御部３５３からの指示にしたがって、直接的または間接的にインタフェイス設定ファイル３３２を更新する。つまり、対応づけ部３５４は、ネットワークインタフェイス３２０と通信端点との対応づけを更新するための制御を行う。
【０１９０】
ところで、本実施形態では、ノード間での死活監視（alive monitoring）が行われる。監視依頼部３５５と監視部３６０は死活監視のためのモジュールである。また、監視部３６０もアプリケーション層で動作する。
【０１９１】
具体的には、キー領域管理部３５０ａ内の監視依頼部３５５は、キー領域管理部３５０ａに対応する通信端点を監視するよう、１台以上の他のノードに依頼する。監視依頼は、監視依頼部３５５から通信処理部３３０とネットワークインタフェイス３２０を介して送信される。
【０１９２】
また、監視依頼部３５５は、監視依頼部３５５が監視を依頼した１台以上の他のノードをそれぞれ識別する情報を、依頼ノードリスト３５６に保持する。依頼ノードリスト３５６の具体例は図８とともに後述する。
【０１９３】
他方、監視部３６０は、他のノードから、ネットワークインタフェイス３２０と通信処理部３３０を介して監視依頼を受信する。監視依頼には、監視対象の通信端点を識別する通信端点情報（例えばＩＰアドレスとポート番号のペア）が含まれる。つまり、監視依頼には、監視を依頼するノードが担当するキー領域に静的に対応づけられている通信端点を識別する通信端点情報が含まれる。
【０１９４】
監視部３６０は、監視依頼を受信すると、監視対象の通信端点を識別する通信端点情報を対象ノードリスト３６１に登録する。そして、監視部３６０は、監視依頼にしたがって、監視対象の通信端点宛に、通信処理部３３０とネットワークインタフェイス３２０を介して監視用の制御メッセージである生存確認メッセージを送信する。生存確認メッセージの送信は、適宜の間隔をおいて繰り返し行われる。
【０１９５】
監視部３６０は、生存確認メッセージを送信するたびに、「生存確認メッセージに対する応答（つまりＡＣＫ）が所定時間以内にネットワークインタフェイス３２０と通信処理部３３０を介して受信されるか否か」を監視する。そして、もしＡＣＫが所定時間以内に受信されない場合は、監視部３６０は、「監視対象のノードに障害が発生した」と認識する。
【０１９６】
監視部３６０は、「監視対象のノードに障害が発生した」と認識すると、「監視対象の通信端点に対応するキー領域を、ノード３００が新たに担当する」と決定する。そして、監視部３６０は、当該キー領域に対応する新たなキー領域管理部のスレッドを生成する。
【０１９７】
説明の便宜上、例えば、監視対象の通信端点にはキー領域Ｋｊが対応し、キー領域Ｋｊに対応してキー領域管理部３５０ａのスレッドが新たに生成されたとする。すると、監視部３６０は、キー領域管理部３５０ａの取得制御部３５２に、ノード３００が新たにあるキー領域Ｋｊを担当することに決まったことを通知する。通知を受けた取得制御部３５２は、上記のとおり、コピー要求または引き継ぎ要求を送信するとともに、キー領域Ｋｊに対応する通信端点情報に含まれるＩＰアドレスを対応づけ部３５４に通知する。
【０１９８】
さて、図６は、クライアントのブロック構成図である。例えば、図１のコンピュータ１１０は、複数のノードのうちの１つであってもよいが、図６のクライアント４００のように構成されていてもよい。また、図２のクライアントＣも、複数のノードのうちの１つであってもよいが、図６のクライアント４００のように構成されていてもよい。図３のクライアント２０２および２２０、ならびに図４のアプリケーションサーバ２４２およびクライアントＰＣ２６０は、本実施形態では図６のクライアント４００のように構成される。
【０１９９】
クライアント４００は、ネットワークインタフェイス４１０と通信処理部４２０を有し、通信処理部４２０はＡＲＰテーブル４２１を保持する。さらに、クライアント４００は、ＤＢ要求処理部４３０を有し、ＤＢ要求処理部４３０は対応表４３１を保持する。また、クライアント４００はアプリケーション４４０を実行する。
【０２００】
ネットワークインタフェイス４１０は、図１のネットワークインタフェイスＩａやＩｂと同様である。つまり、ネットワークインタフェイス４１０は、リンク層の処理を行う。そして、クライアント４００は、ネットワークインタフェイス４１０と通信処理部４２０を介して他の装置と通信する。
【０２０１】
通信処理部４２０は、ＯＳの一部であってもよく、例えば、ＴＣＰ／ＩＰプロトコルスタックの標準ライブラリにより実装されていてもよい。通信処理部４２０を実現するために、さらにイーサネットドライバが利用されてもよい。つまり、通信処理部４２０は、トランスポート層およびインターネット層の処理を行うとともに、インターネット層とリンク層のインタフェイス処理も行う。
【０２０２】
以下では説明の便宜上、「通信処理部４２０とネットワークインタフェイス４１０を介した通信は、ＴＣＰ／ＩＰプロトコルスイートによる通信であり、リンク層ではイーサネットが使われる」と仮定する。
【０２０３】
また、ＡＲＰテーブル４２１は、図１の動的対応づけ情報１１２として使われる。ＡＲＰテーブル４２１は、他の装置のネットワークインタフェイスごとにエントリを有し、各エントリはＩＰアドレスとＭＡＣアドレスを対応づける。
【０２０４】
ＤＢ要求処理部４３０は、例えば、ＤＢアクセスのインタフェイスをアプリケーション４４０に提供するための、ライブラリまたはミドルウェアとして実装されてもよい。ＤＢ要求処理部４３０とアプリケーション４４０はアプリケーション層で動作する。
【０２０５】
ＤＢ要求処理部４３０は、アプリケーション４４０からＤＢアクセス要求を受け取り、通信処理部４２０とネットワークインタフェイス４１０を介してＤＢアクセス要求を送信する。そして、ＤＢ要求処理部４３０は、ＤＢアクセス要求に対するＤＢアクセス応答を、ネットワークインタフェイス４１０と通信処理部４２０を介して受信し、ＤＢアクセス応答の内容をアプリケーション４４０に返す。
【０２０６】
なお、対応表４３１は図１の静的対応づけ情報１１１の具体例であり、図５の対応表３４０と同じである。ＤＢ要求処理部４３０は、ＤＢアクセス要求の宛先を決めるのに対応表４３１を利用する。
【０２０７】
具体的には、ＤＢ要求処理部４３０は、アプリケーション４４０から受け取ったＤＢアクセス要求に指定されているキーが属するキー領域に基づいて対応表４３１を参照することで、通信端点情報を取得する。例えば、通信端点情報がＩＰアドレスとポート番号のペアで表される場合、ＤＢ要求処理部４３０は、取得したＩＰアドレスを宛先ＩＰアドレスとして設定し、取得したポート番号を宛先ポート番号として設定したパケットを、ＤＢアクセス要求として送信する。
なお、アプリケーション４４０は、分散ＤＢ内のデータを利用する任意のアプリケーションであってよい。
【０２０８】
図７は、コンピュータのハードウェア構成図である。例えば、下記（３−１）〜（３−６）の各装置は、具体的には図７のコンピュータ５００により実現されていてもよい。
【０２０９】
（３−１）図１のコンピュータ１００ａ、１００ｂ、および１１０
（３−２）図２のノードＮ１〜Ｎ５、およびクライアントＣ
（３−３）図３のノードＮ１１〜Ｎ１８、デプロイサーバ２０１、クライアント２０２、およびクライアント２２０
（３−４）図４のノードＮ２１〜Ｎ２５、アプリケーションサーバ２４２、およびクライアントＰＣ２６０
（３−５）図５のノード３００
（３−６）図６のクライアント４００
【０２１０】
さて、図７のコンピュータ５００は、ＣＰＵ（Central Processing Unit）５０１と、ＲＯＭ（Read Only Memory）５０２と、ＲＡＭ５０３と、ネットワークインタフェイス５０４を有する。コンピュータ５００はさらに、入力装置５０５と、出力装置５０６と、記憶装置５０７と、可搬型記憶媒体５１０の駆動装置５０８を有する。そして、コンピュータ５００の上記各部は、バス５０９で互いに接続されている。
【０２１１】
ＣＰＵ５０１は、プログラムをＲＡＭ５０３にロードし、ＲＡＭ５０３をワークエリアとして用いながら、プログラムを実行する。実施形態によっては、汎用的なＣＰＵ５０１の代わりに（あるいはＣＰＵ５０１と組み合わせて）、ＡＳＩＣ（Application Specific Integrated Circuit）などの専用のハードウェア回路が使われてもよい。なお、ＲＡＭ５０３は、より具体的には、例えばＤＲＡＭ（Dynamic Random Access Memory）である。
【０２１２】
ＣＰＵ５０１が実行するプログラムは、ＲＯＭ５０２または記憶装置５０７に予め記憶されていてもよい。あるいは、プログラムは、ネットワークインタフェイス５０４を介してネットワークからダウンロードされ、記憶装置５０７にコピーされてもよい。
【０２１３】
または、プログラムは、可搬型記憶媒体５１０に記憶されて提供され、駆動装置５０８により読み取られてもよい。駆動装置５０８により可搬型記憶媒体５１０から読み取られたプログラムは、直接ＲＡＭ５０３にロードされてもよいし、一旦記憶装置５０７にコピーされて、記憶装置５０７からＲＡＭ５０３にロードされてもよい。
【０２１４】
可搬型記憶媒体５１０としては、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク、磁気ディスク、不揮発性の半導体メモリカードなどが利用可能である。なお、ノードまたはクライアントは、駆動装置５０８を持たないコンピュータであってもよい。
【０２１５】
また、ネットワークインタフェイス５０４は、ネットワークを介した通信を行うための通信インタフェイス装置である。ネットワークインタフェイス５０４は、オンボードのネットワークアダプタでもよいし、外付けのＮＩＣでもよい。ネットワークインタフェイス５０４は、例えば、有線ＬＡＮ、無線ＬＡＮ、またはその双方を介した通信機能を提供する。ネットワークインタフェイス５０４は、例えば、ハードウェア回路（いわゆる「ＰＨＹチップ」および「ＭＡＣチップ」と呼ばれる回路など）を含む。
【０２１６】
なお、図７には１つのネットワークインタフェイス５０４のみが図示されているが、コンピュータ５００が複数のネットワークインタフェイス５０４を有してもよい。例えば、２つのネットワークインタフェイス５０４を有するコンピュータ５００がノードとして使われてもよい。そして、２つのネットワークインタフェイス５０４のそれぞれに、動的に１つまたは複数のＩＰアドレスが割り当てられてもよい。
【０２１７】
入力装置５０５は、例えば、キーボード、マウスやタッチスクリーンなどのポインティングデバイス、マイク、またはそれらの組み合わせである。出力装置５０６は、例えば、ディスプレイ、スピーカ、またはそれらの組み合わせである。ディスプレイは、タッチスクリーンであってもよい。なお、入力装置５０５と出力装置５０６はなくてもよい。例えばコンピュータ５００がノードとして使われ、ノードに対する管理者の作業がデプロイサーバ２０１のコンソールを介して行われる場合などは、入力装置５０５と出力装置５０６はなくてもよい。
【０２１８】
記憶装置５０７は、不揮発性の記憶装置であり、例えば、フラッシュメモリなどの半導体メモリ、ハードディスク装置、またはそれらの組み合わせである。なお、ＲＯＭ５０２、ＲＡＭ５０３、記憶装置５０７、および可搬型記憶媒体５１０は、いずれも、コンピュータ読み取り可能な記憶媒体の例である。これらのコンピュータ読み取り可能な記憶媒体は、有形の（tangible）記憶媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。
【０２１９】
ところで、コンピュータ５００が図５のノード３００として使われる場合、図５の各ブロックは、図７のハードウェアにより、例えば以下のようにして実現される。
ローカルストア３１０は、ＲＡＭ５０３であることが好ましいが、記憶装置５０７であってもよい。ネットワークインタフェイス３２０は、ネットワークインタフェイス５０４であってもよい。通信処理部３３０は、プログラムを実行するＣＰＵ５０１と、ＡＲＰテーブル３３１を保持するＲＡＭ５０３と、インタフェイス設定ファイル３３２を保持する記憶装置５０７により実現されてもよい。対応表３４０は、ＲＯＭ５０２または記憶装置５０７に予め記憶され、ＲＡＭ５０３に読み出されて保持されてもよい。
【０２２０】
キー領域管理部３５０ａ〜３５０ｃのそれぞれは、ＣＰＵ５０１とＲＡＭ５０３により実現されてもよい。つまり、リード・ライト処理部３５１、取得制御部３５２、供給制御部３５３、対応づけ部３５４はプログラムを実行するＣＰＵ５０１により実現されてもよい。そして、監視依頼部３５５は、プログラムを実行するＣＰＵ５０１と、依頼ノードリスト３５６を保持するＲＡＭ５０３により実現されてもよい。
【０２２１】
また、監視部３６０も、プログラムを実行するＣＰＵ５０１と、対象ノードリスト３６１を保持するＲＡＭ５０３により実現されてもよい。
そして、コンピュータ５００が図６のクライアント４００として使われる場合、図６の各ブロックは、図７のハードウェアにより、例えば以下のようにして実現される。
【０２２２】
ネットワークインタフェイス４１０は、ネットワークインタフェイス５０４であってもよい。通信処理部４２０は、プログラムを実行するＣＰＵ５０１と、ＡＲＰテーブル４２１を保持するＲＡＭ５０３により実現されてもよい。
【０２２３】
対応表４３１は、ＲＯＭ５０２または記憶装置５０７に予め記憶され、ＲＡＭ５０３に読み出されて保持されてもよい。そして、ＤＢ要求処理部４３０は、プログラムを実行するＣＰＵ５０１と対応表４３１を保持するＲＡＭ５０３により実現されてもよい。
【０２２４】
なお、アプリケーション４４０は、ＣＰＵ５０１により実行されてもよい。
続いて、本実施形態の分散ＤＢシステムで使われる各種データについて説明する。図８は、各種データの例を示す図である。
【０２２５】
対応表６０１は、図１の静的対応づけ情報１１１の具体例である。図５の対応表３４０と図６の対応表４３１は、具体的には図８の対応表６０１のとおりであってもよい。
対応表６０１の各エントリは１つのキー領域に対応する。各エントリは、「キー領域のインデックス」、「第１通信端点」、「第２通信端点」、および「第３通信端点」というフィールドを有する。
【０２２６】
対応表６０１は、キーの定義域Ｋが図２の例のように１６個のキー領域Ｋ０〜Ｋ１５に分割される場合（すなわちＭ＝１６の場合）の例である。したがって、対応表６０１に例示されているキー領域のインデックスは０〜１５である。例えば、キー領域のインデックスがｊ（０≦ｊ≦１５）のエントリは、キー領域Ｋｊに対応する。
【０２２７】
また、本実施形態では、１つのキー領域Ｋｊに対応する同じデータを３台のノードが保持する。そのため、対応表６０１の各エントリは、３台のノードそれぞれにおいてキー領域Ｋｊに対応する通信端点情報を示す「第１通信端点」〜「第３通信端点」というフィールドを有する。なお、１つのキー領域Ｋｊに対応する同じデータを３台のノードが保持する理由は、以下のとおりである。
【０２２８】
仮に、あるキー領域Ｋｊに対応するエントリを１台のノードしか保持していないとすると、当該ノードが故障した場合、キー領域Ｋｊに対応するエントリが消滅してしまうおそれがあり、望ましくない。よって、キー領域Ｋｊに対応するエントリを２台以上のノードが保持することが望ましい。
【０２２９】
また、キー領域Ｋｊに対応するエントリが２台のノードにしか保持されていない場合、二次障害のおそれがある。二次障害に対する耐故障性を分散ＤＢシステム全体として高めるため、本実施形態では、キー領域Ｋｊに対応するエントリを３台のノードが保持する。
【０２３０】
例えば、ノードＮ１とＮ２がキー領域Ｋｊに対応するエントリを保持しているとして、ある時点でノードＮ１が故障したとする。ノードＮ１の故障にともなうフェイルオーバにより、例えば、ノードＮ３が新たにキー領域Ｋｊに対応するエントリを保持してもよい。この場合、ノードＮ３は、故障したノードＮ１からはキー領域Ｋｊに対応するエントリを取得することができないので、正常なノードＮ２からキー領域Ｋｊに対応するエントリを取得しようとする。
【０２３１】
しかし、例えば、ノードＮ１とＮ２のハードウェアが同時期にリリースされた同じものである場合、ノードＮ１とＮ２の耐用年数は同じである。そのため、ノードＮ１が故障しやすくなる頃には、ノードＮ２も故障しやすくなっていると考えられる。そして、キー領域Ｋｊに対応する全エントリをノードＮ３に送信する処理の負荷は、ＤＢの規模が大きければ、決して小さくはない。つまり、耐用期限間近のノードＮ２に、フェイルオーバのための処理による高負荷がかかるおそれがある。その結果、「フェイルオーバが完了しないうちにノードＮ２も故障してしまう」という二次障害が起こりかねない。
【０２３２】
そこで、本実施形態では、１つのキー領域Ｋｊに対応する同じデータを３台のノードが保持する。例えば、３台のノードＮ１とＮ２とＮ４が同じキー領域Ｋｊに対応するエントリを保持していれば、上記のような「ノードＮ１の故障にともなうフェイルオーバの途中でノードＮ２も故障する」という二次障害が起きても、ほとんどの場合回復可能である。
【０２３３】
なぜなら、ノードＮ１とＮ２とＮ４の３台がほぼ同時に故障することはほとんどないからである。つまり、たとえ二次障害が起きても、ほとんどの場合においてノードＮ４は正常である。したがって、ノードＮ３は、キー領域Ｋｊに対応する全エントリをノードＮ４から取得することができ、フェイルオーバを完了することができる。
【０２３４】
また、ノードＮ１からノードＮ３へのフェイルオーバと同様にして、ノードＮ２からノードＮ５へのフェイルオーバも可能である。または、ノードＮ５は、フェイルオーバ完了後のノードＮ３から、キー領域Ｋｊに対応する全エントリを取得してもよい。
【０２３５】
いずれにせよ、分散ＤＢシステム全体は、「同じキー領域Ｋｊに対応するエントリを３台のノード（具体的にはＮ３とＮ４とＮ５）が保持している」という状態へと回復する。このように、１つのキー領域Ｋｊに対応する同じデータを３台のノードが保持することで、優れた耐故障性が実現される。
【０２３６】
例えば、図８の対応表６０１の例では、キー領域のインデックスが１のエントリにおいて、第１通信端点は「１９２．１６８．２５４．１：７０００」というＩＰアドレスとポート番号のペアで識別される。また、第２通信端点は「１９２．１６８．２５４．１７：７０００」というＩＰアドレスとポート番号のペアで識別され、第３通信端点は「１９２．１６８．２５４．３３：７０００」というＩＰアドレスとポート番号のペアで識別される。つまり、上記エントリは、次の（４−１）〜（４−３）のことを示す。
【０２３７】
（４−１）キー領域Ｋ１に対応するエントリを保持する１台目のノードは、「１９２．１６８．２５４．１：７０００」という通信端点情報で論理的に識別されるノードである。
（４−２）キー領域Ｋ１に対応するエントリを保持する２台目のノードは、「１９２．１６８．２５４．１７：７０００」という通信端点情報で論理的に識別されるノードである。
（４−３）キー領域Ｋ１に対応するエントリを保持する３台目のノードは、「１９２．１６８．２５４．３３：７０００」という通信端点情報で論理的に識別されるノードである。
【０２３８】
ところで、同じキー領域Ｋ１に対応するエントリを保持する３台のノードの間には、優先順位があってもよいし、なくてもよい。本実施形態では、「第１通信端点」フィールドの通信端点情報で識別される通信端点のノードが最高の優先度であり、「第３通信端点」フィールドの通信端点情報で識別される通信端点のノードが最低の優先度であるものとする。後述の図１１のフローチャートでは、上記優先度にしたがって、第１通信端点から順にアクセスされる。
【０２３９】
なお、対応表６０１の例は、図３のように１つのブロードキャストドメインに全ノードが属し、かつ、クライアントも同じブロードキャストドメインに属する場合の例である。よって、対応表６０１中の通信端点情報に含まれるＩＰアドレスは、プライベートＩＰアドレスである。しかし、もちろん実施形態によっては、通信端点を識別するのにグローバルＩＰアドレスが使われてもよい。
【０２４０】
また、対応表６０１の例では、４８（＝３×１６）個の通信端点情報それぞれのポート番号はすべて同じ「７０００」という値である。しかし、実施形態によっては、４８個の通信端点情報の中で、ｐ個（２≦ｐ≦４８）の異なるポート番号が使われてもよい。
【０２４１】
あるいは、対応表６０１のようにポート番号が定数の場合は、対応表６０１が保持する通信端点情報は、ＩＰアドレスのみで表されてもよい。たとえＩＰアドレスしか対応表６０１に記憶されていなくても、ポート番号が定数の場合は、ＩＰアドレスと定数のポート番号のペアにより通信端点を一意に識別することができる。
【０２４２】
さて、ＡＲＰテーブル６０２は、図１の動的対応づけ情報１１２の具体例である。そして、図５のＡＲＰテーブル３３１と図６のＡＲＰテーブル４２１は、ともにＡＲＰテーブル６０２のような形式のテーブルである。ＡＲＰテーブル６０２の各エントリは、ＩＰアドレスとＭＡＣアドレスを対応づける。
【０２４３】
また、図８では省略されているが、エージングのために、各エントリには、寿命（lifetime）をカウントダウンするカウンタ、または、エントリの最終更新時刻が対応づけられている。例えば、ＡＲＰテーブル６０２の各エントリは、所定時間（例えば２分間）の間に１回も使用されない場合は消去される。そして、エントリが使用（つまり参照または更新）されると、カウンタが所定時間に再設定されるか、または最終更新時刻に現在時刻が再設定される。
【０２４４】
さらに、ＡＲＰテーブル６０２の各エントリは、使用されるか否かによらず、最長でも所定時間（例えば１０分間）しか保持されなくてもよい。つまり、各エントリには、最長保持時間までの寿命をカウントダウンするカウンタ、または、エントリの作成時刻がさらに対応づけられていてもよい。
【０２４５】
例えば、図８の１つ目のエントリでは、「１９２．１６８．２５４．１」というＩＰアドレスと「００-２３−２６−６Ａ−Ｃ２−４Ｃ」というＭＡＣアドレスが対応づけられている。したがって、対応表６０１を考慮に入れると、この１つ目のエントリは、「００-２３−２６−６Ａ−Ｃ２−４Ｃ」というＭＡＣアドレスで識別されるネットワークインタフェイス３２０を持つノード３００が現在キー領域Ｋ１を担当していることを示している。
【０２４６】
ところで、複数のノードそれぞれの記憶装置に分散して記憶される分散ＤＢは、ＲＤＢとＫＶＳのどちらでもよいが、説明の便宜上、本実施形態の分散ＤＢはＫＶＳであるとする。図８のＫＶＳ６０３は、分散ＤＢであるＫＶＳの全ノードのうち、ある１つのキー領域に対応して、ある１つのノード３００がローカルストア３１０に記憶するエントリを抜粋して示したものである。
【０２４７】
ＫＶＳ６０３の各エントリは、キーとバリューのペアであり、図８には２つのエントリが例示されている。１番目のエントリにおいて、キーは「ｄｅｆ」であり、バリューは「ＤＥＦ」である。また、２番目のエントリにおいて、キーは「ｇｈｉ」であり、バリューは「ＧＨＩ」である。
【０２４８】
また、図８の対象ノードリスト６０４は、図５の対象ノードリスト３６１の具体例である。つまり、対象ノードリスト６０４の各要素は、ノード３００の監視部３６０が監視する対象のノードを識別する情報であり、具体的には、監視対象の通信端点を識別する通信端点情報である。
【０２４９】
図８には、対象ノードリスト６０４の要素として、「１９２．１６８．２５４．９：７０００」と「１９２．１６８．２５４．２３：７０００」が例示されている。よって、対応表６０１を考慮に入れると、対象ノードリスト６０４は以下のことを示す。すなわち、図８の対象ノードリスト６０４を対象ノードリスト３６１として保持する監視部３６０は、キー領域Ｋ９を担当する１台目のノードと、キー領域Ｋ７を担当する２台目のノードを監視している。
【０２５０】
また、図８の依頼ノードリスト６０５は、図５の依頼ノードリスト３５６の具体例である。つまり、依頼ノードリスト６０５の各要素は、監視依頼部３５５がノード３００の通信端点を監視するよう依頼した先の他のノードを識別する情報であり、より具体的には通信端点を識別する通信端点情報である。
【０２５１】
なお、本実施形態では、各ノードに、動的に割り当てが変化するＩＰアドレス（すなわち対応表６０１に現れるＩＰアドレス）のほかに、保守用の固定的なＩＰアドレスが割り当てられる。例えば、分散ＤＢシステムが図３のように８台のノードを含む場合、対応表６０１には現れない「１９２．１６８．２５４．１２８」〜「１９２．１６８．２５４．１３５」の８個の固定ＩＰアドレスが使われてもよい。
【０２５２】
図８には、依頼ノードリスト６０５の要素として、「１９２．１６８．２５４．１２８」と「１９２．１６８．２５４．１３３」というＩＰアドレスが例示されている。つまり、依頼ノードリスト６０５は、監視依頼部３５５が監視を依頼したノードの中に、「１９２．１６８．２５４．１２８」と「１９２．１６８．２５４．１３３」というＩＰアドレスがそれぞれ固定的に割り当てられた２台のノードが含まれることを示す。なお、依頼ノードリスト６０５の要素として、ＩＰアドレスの代わりにＩＰアドレスとポート番号のペアが使われてもよい。
【０２５３】
また、フレーム６０６は、本実施形態においてＤＢアクセス要求やＤＢアクセス応答などのために使われるフレームの例である。フレーム６０６は、より具体的にはイーサネットフレームである。
【０２５４】
フレーム６０６は、ＭＡＣヘッダと、フレームペイロードと、誤り検出用のＦＣＳ（Frame Check Sequence）を含む。そして、フレームペイロードはＩＰデータグラムを含み、ＩＰデータグラムはＩＰヘッダとＩＰペイロードを含む。
【０２５５】
また、図８ので例では、ＩＰペイロードは、ＴＣＰセグメントを含む。実施形態によっては、ＩＰペイロードは、ＵＤＰセグメントなど、トランスポート層におけるＴＣＰ以外のプロトコルのＰＤＵ（Protocol Data Unit）を含んでもよい。
【０２５６】
ＴＣＰセグメントは、ＴＣＰヘッダとＴＣＰペイロードを含む。そして、ＴＣＰペイロードは、アプリケーション層のＰＤＵを含む。
本実施形態では、「アプリケーション層のＰＤＵ」とは、具体的には、分散ＤＢシステムのためのＤＢアプリケーションにおいて、ノード間の通信またはノードとクライアントの間の通信に使われるＰＤＵである。なお、ＤＢアプリケーションは、具体的には、以下の（５−１）と（５−２）の部分に相当する。
【０２５７】
（５−１）図５のノード３００においては、対応表３４０、キー領域管理部３５０ａ〜３５０ｃ、監視部３６０の部分
（５−２）図６のクライアント４００においては、アプリケーション４４０とＤＢ要求処理部４３０の部分
【０２５８】
以下では説明の便宜上、アプリケーション層のＰＤＵを「ＤＢパケット」という。ＤＢパケットは、ヘッダとペイロードを含む。以下では説明の便宜上、ＤＢパケットのヘッダおよびペイロードを、それぞれ「ＤＢヘッダ」および「ＤＢペイロード」という。
【０２５９】
例えば、ＤＢヘッダは、タイプやサブタイプなどのフィールドを含んでもよく、さらに、ＤＢアクセス要求などの要求ごとに割り当てられる識別番号のフィールドを含んでもよい。そして、ある要求に対する応答のＤＢヘッダには、当該要求の識別番号が設定されてもよい。すると、要求の送信元の装置は、受信した応答がどの要求に対する応答なのかを判別することができる。また、フレーム６０６が図１のＤＢアクセス要求１２０ａのためのフレームである場合、ＤＢペイロードは、図１のキーと要求内容のフィールドを含む。
【０２６０】
以上説明したとおり、フレーム６０６の中には上位層のＰＤＵがカプセル化されて含まれている。したがって、フレーム６０６は、具体的には図８に示したとおり、ＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ＤＢヘッダ、ＤＢペイロード、およびＦＣＳが、この記載順に並んだ形式である。
【０２６１】
もちろん、ＤＢペイロードが長い場合には、ＩＰフラグメンテーションにより、１つのＤＢパケットが複数のＩＰデータグラムに分割されて複数のフレームが送信されることもある。しかし、図８では説明の簡略化のため、分割されていないフレーム６０６を例示した。
【０２６２】
なお、ＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダの詳細は周知である。よって、ＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダについては、詳しい説明を省略するが、本実施形態に関連する点を説明すると、以下のとおりである。
【０２６３】
ＭＡＣヘッダは、送信元ＭＡＣアドレスと宛先ＭＡＣアドレスを含む。また、ＩＰヘッダは、送信元ＩＰアドレスと宛先ＩＰアドレスを含む。そして、ＴＣＰヘッダは、送信元ポート番号と宛先ポート番号を含む。なお、実施形態によってはＴＣＰの代わりにＵＤＰが使われてもよいが、ＵＤＰヘッダも同様に、送信元ポート番号と宛先ポート番号を含む。
【０２６４】
ここで、ＤＢパケットの宛先の通信端点は、宛先ＩＰアドレスと宛先ポート番号のペアにより識別される。例えば、フレーム６０６が図１のＤＢアクセス要求１２０ａのためのフレームである場合、ＤＢアクセス要求１２０ａの通信端点は、具体的には、ＩＰヘッダ内の宛先ＩＰアドレスフィールドと、ＴＣＰヘッダ内の宛先ポート番号フィールドにより表される。
【０２６５】
また、説明の簡単化のため、全ノードとクライアントが同じブロードキャストドメインに属すると仮定する。すると、宛先ＭＡＣアドレスは、ＡＲＰによるアドレス解決によって宛先ＩＰアドレスから取得された値であり、送信元ＭＡＣアドレスは、フレーム６０６の送信元のネットワークインタフェイスを識別するＭＡＣアドレスである。逆に、フレーム６０６が１つ以上のルータにより中継される場合、ＭＡＣヘッダは各ルータにおいて書き換えられる。
【０２６６】
なお、送信元ポート番号は、ＤＢアプリケーションにより決められる。また、送信元ＩＰアドレスは、フレーム６０６の送信元のネットワークインタフェイスに割り当てられている１つまたは複数のＩＰアドレスのうちの１つである。
【０２６７】
続いて、図９〜１６のフローチャートを参照して、分散ＤＢシステムに含まれる個々の装置が行う処理について説明する。
【０２６８】
具体的には、ノード３００とクライアント４００に共通する、ＡＲＰに関連する処理について図９〜１０とともに説明する。本実施形態ではＡＲＰテーブルが図１の動的対応づけ情報１１２として使われるので、図９〜１０の処理は、動的対応づけ情報１１２の動的な更新に関連する。その後、図１１〜１２を参照して、クライアント４００が行う処理について説明する。また、図１３〜１６を参照して、ノード３００が行う処理について説明する。
【０２６９】
図９は、メッセージ送信を指示されたときの、通信処理部とネットワークインタフェイスにおける、インターネット層とリンク層の動作フローチャートである。図９の処理は、ノード３００とクライアント４００で共通である。よって、図９に関する説明においては、「通信処理部３３０または４２０」、「ＡＲＰテーブル３３１または４２１」、「ネットワークインタフェイス３２０または４１０」などの表記を用いることがある。
【０２７０】
なお、図９の処理は、後述の図１１〜１６内のいくつかのステップから呼び出される。例えば、以下の（６−１）〜（６−６）の場合などに図９の処理が行われる。
【０２７１】
（６−１）通信処理部３３０が、リード・ライト処理部３５１から、リード要求またはライト要求に対する応答の送信を指示されたとき。
（６−２）通信処理部３３０が、取得制御部３５２から、コピー要求の送信、または引き継ぎ要求の送信を指示されたとき。
（６−３）通信処理部３３０が、供給制御部３５３から、コピー要求に対する応答の送信、または引継ぎ要求に対する応答の送信を指示されたとき。
（６−４）通信処理部３３０が、監視依頼部３５５から、監視依頼の送信、または生存確認メッセージに対するＡＣＫの送信を指示されたとき。
（６−５）通信処理部３３０が、監視部３６０から、監視用の生存確認メッセージの送信を指示されたとき。
（６−６）通信処理部４２０が、ＤＢ要求処理部４３０から、ＤＢアクセス要求（具体的には、リード要求またはライト要求）の送信を指示されたとき。
【０２７２】
さて、通信処理部３３０または４２０は、何らかのメッセージの送信を指示されると、ステップＳ１０１で、指定された宛先ＩＰアドレスから転送先ＩＰアドレス（forwarding IP address）を取得する。メッセージの例は、例えば上記のような、ＤＢアクセス応答、監視依頼、生存確認メッセージ、ＤＢアクセス要求、その他の制御用メッセージなどである。
【０２７３】
例えば、図３のクライアント２０２がノードＮ１１にメッセージを送信しようとしているとする。図３の例では、クライアント２０２とノードＮ１１は同じブロードキャストドメイン２００に属する。よって、ステップＳ１０１でクライアント２０２の通信処理部４２０は、宛先ＩＰアドレス（すなわち、ノードＮ１１が現在担当するキー領域に対応する通信端点のＩＰアドレス）そのものを、転送先ＩＰアドレスとして取得する。
【０２７４】
同じブロードキャストドメイン２００に属するノード間の通信の場合も同様である。つまり、ノード３００の通信処理部３３０は、宛先ＩＰアドレスそのものを、転送先ＩＰアドレスとしてステップＳ１０１で取得する。
【０２７５】
逆に、図４のアプリケーションサーバ２４２が、クライアントとしてノードＮ２１にメッセージを送信しようとしている場合は、転送先ＩＰアドレスは宛先ＩＰアドレスそのものではない。なぜなら、アプリケーションサーバ２４２とノードＮ２１は異なるブロードキャストドメインに属するからである。
【０２７６】
この場合、アプリケーションサーバ２４２の通信処理部４２０は、例えばサブネットマスクを用いることで「宛先ＩＰアドレスは、アプリケーションサーバ２４２の属するブロードキャストドメイン２４０内のマシンのＩＰアドレスではない」と認識する。そして、アプリケーションサーバ２４２の通信処理部４２０は、同じブロードキャストドメイン２４０に属するルータ２４１のＩＰアドレスを、転送先ＩＰアドレスとしてステップＳ１０１で取得する。
【０２７７】
異なるブロードキャストドメイン２３０と２４０に属するノード間の通信の場合も同様である。例えば、ノードＮ２２がノードＮ２５に何らかのメッセージを送信しようとする場合、ノードＮ２２の通信処理部３３０は、転送先ＩＰアドレスとしてルータ２３１のＩＰアドレスをステップＳ１０１で取得する。
【０２７８】
通信処理部３３０または４２０は、以上のようにして転送先ＩＰアドレスを取得すると、次のステップＳ１０２で、転送先ＩＰアドレスを持つエントリを、ＡＲＰテーブル３３１または４２１において検索する。
【０２７９】
そして、ステップＳ１０３で通信処理部３３０または４２０は、ステップＳ１０２の検索の結果としてエントリが見つかったか否かを判断する。エントリが見つかった場合、通信処理部３３０または４２０は、見つかったエントリの寿命を所定の値（例えば２分など）に再設定し、その後、処理はステップＳ１０４に移行する。逆に、エントリが見つからなかった場合、処理はステップＳ１０５に移行する。
【０２８０】
ステップＳ１０４で通信処理部３３０または４２０は、メッセージを送信するためのフレームを組み立てる。具体的には、通信処理部３３０または４２０は、送信するよう指定されたメッセージ、指定された宛先ＩＰアドレス、見つかったエントリに登録されているＭＡＣアドレスなどに基づいて、フレームを組み立てる。指定された宛先ＩＰアドレスは、ＩＰヘッダの宛先ＩＰアドレスフィールドに設定され、見つかったエントリに登録されているＭＡＣアドレスは、ＭＡＣヘッダの宛先ＭＡＣアドレスフィールドに設定される。
【０２８１】
そして、通信処理部３３０または４２０は、ネットワークインタフェイス３２０または４１０を介して、フレームを送信する。そして、フレームが送信されると、図９の処理は正常終了する。
【０２８２】
他方、ステップＳ１０５では、通信処理部３３０または４２０は、転送先ＩＰアドレスをＴＰＡ（Target Protocol Address）として指定したＡＲＰ要求を生成する。そして、通信処理部３３０または４２０は、ネットワークインタフェイス３２０または４１０を介して、生成したＡＲＰ要求をブロードキャストする。
【０２８３】
また、次のステップＳ１０６で通信処理部３３０または４２０は、所定時間（以下では「ＴＯ＿ａｒｐ」と表記する）以内に、ネットワークインタフェイス３２０または４１０を介してＡＲＰ応答を受信したか否かを判断する。所定時間ＴＯ＿ａｒｐ以内にＡＲＰ応答がなければ、通信処理部３３０または４２０は、メッセージ送信を指示した呼び出し元（caller）に対してエラーコードを返し、図９の処理は異常終了する。
【０２８４】
逆に、所定時間ＴＯ＿ａｒｐ以内にＡＲＰ応答が受信されれば、通信処理部３３０または４２０は、ステップＳ１０７において、受信したＡＲＰ応答に基づいて、ＡＲＰテーブル３３１または４２１を更新する。すなわち、通信処理部３３０または４２０は、（７−１）のＩＰアドレスと（７−２）のＭＡＣアドレスを対応づける新たなエントリを、ＡＲＰテーブル３３１または４２１に追加する。
【０２８５】
（７−１）受信したＡＲＰ応答にＳＰＡ（Sender Protocol Address）として指定されているＩＰアドレス
（７−２）受信したＡＲＰ応答にＳＨＡ（Sender Hardware Address）として指定されているＭＡＣアドレス
【０２８６】
さらに、通信処理部３３０または４２０は、追加した新たなエントリの寿命を所定の値（例えば２分など）に設定する。
以上のようなＡＲＰテーブル３３１または４２１の更新後、処理はステップＳ１０２に戻る。ステップＳ１０７の後のステップＳ１０２の検索ではエントリが見つかるので、その後、ステップＳ１０４でフレームが送信される。なお、上記ステップＳ１０７でのＡＲＰテーブル３３１または４２１の更新は、図１の動的対応づけ情報１１２が更新される場合の一例である。
【０２８７】
次に、図１０を参照して、図９のステップＳ１０５で送信されたＡＲＰ要求を受信する装置における処理について説明する。図１０は、ＡＲＰ応答のフローチャートである。図１０の処理も、ノード３００とクライアント４００で共通である。
【０２８８】
また、図１０の処理は、イーサネットポートごとに（換言すればＭＡＣアドレスごとに）行われる。例えば、ノード３００のネットワークインタフェイス３２０が２つのイーサネットポートを有する場合、２つのイーサネットポートのそれぞれについて、独立に図１０の処理が行われる。便宜上、図１０の説明においては、図１０の処理の対象であるイーサネットポートのことを「注目イーサネットポート」という。
【０２８９】
ステップＳ２０１で通信処理部３３０または４２０は、ネットワークインタフェイス３２０または４１０を介してＡＲＰ要求を受信するまで待機する。
そして、ＡＲＰ要求が受信されると、ステップＳ２０２で通信処理部３３０または４２０は、必要に応じてＡＲＰテーブル３３１または４２１を更新する。
【０２９０】
具体的には、通信処理部３３０または４２０は、ＡＲＰテーブル３３１または４２１を検索して、ＡＲＰ要求にＳＰＡとして指定されているＩＰアドレスを持つエントリを探す。もしエントリが見つかれば、通信処理部３３０または４２０は、当該エントリのＭＡＣアドレスを、ＡＲＰ要求にＳＨＡとして指定されているＭＡＣアドレスに更新し、当該エントリの寿命を所定の値（例えば２分など）に再設定する。そして処理はステップＳ２０３へと移行する。
【０２９１】
逆に、エントリが見つからなければ、通信処理部３３０または４２０は、「受信したＡＲＰ要求にＴＰＡとして指定されているＩＰアドレスは、注目イーサネットポートに割り当てられているＩＰアドレスか否か」を判断する。通信処理部３３０は、インタフェイス設定ファイル３３２を参照することで上記判断を行ってもよい。また、図６では省略されているが、通信処理部４２０も、図５のインタフェイス設定ファイル３３２と同様のインタフェイス設定ファイルを含む。よって、通信処理部４２０も通信処理部３３０と同様にして、上記判断を行うことができる。
【０２９２】
もし、ＴＰＡとして指定されているＩＰアドレスが、注目イーサネットポートに割り当てられているＩＰアドレスであれば、通信処理部３３０または４２０は、新たなエントリをＡＲＰテーブル３３１または４２１に追加する。追加される新たなエントリは、具体的には、ＡＲＰ要求にＳＰＡとＳＨＡとしてそれぞれ指定されているＩＰアドレスとＭＡＣアドレスとを対応づけるエントリである。そして、通信処理部３３０または４２０は、追加した新たなエントリの寿命を所定の値（例えば２分など）に設定する。そして処理はステップＳ２０３へと移行する。
【０２９３】
逆に、ＴＰＡとして指定されているＩＰアドレスが、注目イーサネットポートに割り当てられているＩＰアドレスとは異なれば、通信処理部３３０または４２０は、ステップＳ２０２ではエントリを追加しない。この場合は、ＡＲＰテーブル３３１または４２１が更新されないままで、処理がステップＳ２０２からステップＳ２０３へと移行する。
【０２９４】
なお、以上のステップＳ２０２でのＡＲＰテーブル３３１または４２１の更新（つまりＡＲＰエントリの更新または追加）によって、図１の動的対応づけ情報１１２が更新される場合もあり得る。
【０２９５】
また、次のステップＳ２０３で通信処理部３３０または４２０は、「受信したＡＲＰ要求にＴＰＡとして指定されているＩＰアドレスは、注目イーサネットポートに割り当てられているＩＰアドレスであるか否か」を判断する。この判断はステップＳ２０２に関して説明した方法により行われてもよい。
【０２９６】
そして、受信したＡＲＰ要求にＴＰＡとして指定されているＩＰアドレスが、注目イーサネットポートに割り当てられているＩＰアドレスと異なれば、処理はステップＳ２０１に戻る。
【０２９７】
逆に、受信したＡＲＰ要求にＴＰＡとして指定されているＩＰアドレスが、注目イーサネットポートに割り当てられているＩＰアドレスである場合、ステップＳ２０４で通信処理部３３０または４２０は、ＡＲＰ応答を返す。具体的には、通信処理部３３０または４２０は、受信したＡＲＰ要求にＴＰＡとして指定されているＩＰアドレスをＳＰＡとして含み、かつ注目イーサネットポートのＭＡＣアドレスをＳＨＡとして含むようなＡＲＰ応答を生成する。そして、通信処理部３３０または４２０は、生成したＡＲＰ応答を、ネットワークインタフェイス３２０または４１０を介して送信する。
【０２９８】
そして、ＡＲＰ応答の送信後、処理はステップＳ２０１に戻る。なお、送信されたＡＲＰ応答は、前述のとおり、図９のステップＳ１０６で受信される。
続いて、図１１〜１２を参照して、図６のクライアント４００による処理について説明する。
【０２９９】
図１１は、クライアントによるリード操作のフローチャートである。図１１のリード操作は、アプリケーション４４０がＤＢ要求処理部４３０にリード要求の送信を指示したときに、開始される。また、本実施形態での分散ＤＢは、図８のＫＶＳ６０３に一部を例示したとおり、ＫＶＳである。したがって、リード要求には、キーが指定されている。
【０３００】
ステップＳ３０１でＤＢ要求処理部４３０は、アプリケーション４４０から指定されたキーと、対応表４３１を用いて、３つの通信端点を特定する。
具体的には、ＤＢ要求処理部４３０は、まず指定されたキーがどのキー領域に属するかを判断する。例えば、各キー領域Ｋｊが式（３）により定義されており、指定されたキーがｘであるとする。この場合、ＤＢ要求処理部４３０は、ｍｏｄ（ｈａｓｈ（ｘ），Ｍ）の値を計算し、計算結果に基づいて、指定されたキーが属するキー領域を特定する。もちろん、各キー領域Ｋｊが他の式により定義されていても、ＤＢ要求処理部４３０は、指定されたキーが属するキー領域を特定することができる。
【０３０１】
また、本実施形態の対応表４３１は、具体的には図８の対応表６０１のように、各キー領域に３つの通信端点を対応づけている。よって、ＤＢ要求処理部４３０は、特定したキー領域に対応するエントリを対応表４３１の中から探し、見つけたエントリから第１〜第３通信端点をそれぞれ識別する通信端点情報を読み出す。
【０３０２】
そして、次のステップＳ３０２でＤＢ要求処理部４３０は、通信処理部４２０とネットワークインタフェイス４１０を介して、ステップＳ３０１で特定した第１通信端点にリード要求を送信する。つまり、ＤＢ要求処理部４３０は、リード要求の内容と第１通信端点の通信端点情報を指定して、通信処理部４２０にリード要求の送信を指示する。そして、通信処理部４２０は、指示にしたがって図９のようにしてフレームを組み立て、フレームを送信する。
【０３０３】
また、ＤＢ要求処理部４３０は、通信処理部４２０にリード要求の送信を指示した後、第１通信端点からの応答の受信を待つ（以下、リード要求に対する応答を「リード応答」という）。そして、ステップＳ３０３に示すように、所定時間（以下「ＴＯ＿ｄｂ」と表記する）以内にＤＢ要求処理部４３０がリード応答を受信すれば、処理はステップＳ３０４に移行する。逆に、所定時間ＴＯ＿ｄｂが経過してもＤＢ要求処理部４３０がリード応答を受信することができなければ、処理はステップＳ３０５に移行する。
【０３０４】
ステップＳ３０４でＤＢ要求処理部４３０は、受信したリード応答の内容をアプリケーション４４０に返す。そして、図１１のリード操作は正常に終了する。なお、ステップＳ３０４の詳細は以下のとおりである。
【０３０５】
もし、アプリケーション４４０から指定されたキーに対応するエントリがＫＶＳ内にあれば、受信したリード応答には、当該エントリによりキーに対応づけられているバリューが含まれる。よって、ＤＢ要求処理部４３０はステップＳ３０４において、当該バリューをアプリケーション４４０に返す。
【０３０６】
逆に、アプリケーション４４０から指定されたキーに対応するエントリがＫＶＳ内になければ、受信したリード応答は、指定されたキーに対応するバリューがないことを示す。よって、ＤＢ要求処理部４３０はステップＳ３０４において、バリューが見つからなかったことをアプリケーション４４０に通知する。
【０３０７】
他方、ステップＳ３０５では、ＤＢ要求処理部４３０が、通信処理部４２０とネットワークインタフェイス４１０を介して、第２通信端点にリード要求を送信する。ステップＳ３０５は、リード要求の宛先以外はステップＳ３０２と同様なので、詳細な説明は省略する。
【０３０８】
そして、ＤＢ要求処理部４３０は、通信処理部４２０にリード要求の送信を指示した後、第２通信端点からのリード応答の受信を待つ。ステップＳ３０６に示すように、所定時間ＴＯ＿ｄｂ以内にＤＢ要求処理部４３０がリード応答を受信すれば、処理はステップＳ３０７に移行する。逆に、所定時間ＴＯ＿ｄｂが経過してもＤＢ要求処理部４３０がリード応答を受信することができなければ、処理はステップＳ３０８に移行する。
【０３０９】
そして、ステップＳ３０７でＤＢ要求処理部４３０は、受信したリード応答の内容をアプリケーション４４０に返す。すると、図１１のリード操作は正常に終了する。なお、ステップＳ３０７はステップＳ３０４と同様なので、詳細な説明は省略する。
【０３１０】
他方、ステップＳ３０８では、ＤＢ要求処理部４３０が、通信処理部４２０とネットワークインタフェイス４１０を介して、第３通信端点にリード要求を送信する。ステップＳ３０８も、リード要求の宛先以外はステップＳ３０２と同様なので、詳細な説明は省略する。
【０３１１】
そして、ＤＢ要求処理部４３０は、通信処理部４２０にリード要求の送信を指示した後、第３通信端点からのリード応答の受信を待つ。そして、ステップＳ３０９に示すように、所定時間ＴＯ＿ｄｂ以内にＤＢ要求処理部４３０がリード応答を受信すれば、処理はステップＳ３１０に移行する。逆に、所定時間ＴＯ＿ｄｂが経過してもＤＢ要求処理部４３０がリード応答を受信することができなければ、処理はステップＳ３１１に移行する。
【０３１２】
そして、ステップＳ３１０でＤＢ要求処理部４３０は、受信したリード応答の内容をアプリケーション４４０に返す。すると、図１１のリード操作は正常に終了する。なお、ステップＳ３１０もステップＳ３０４と同様なので、詳細な説明は省略する。
他方、ステップＳ３１１でＤＢ要求処理部４３０は、アプリケーション４４０にエラーを通知する。そして、図１１のリード操作は異常終了する。
【０３１３】
ところで、図１１に関する以上の説明は、主にアプリケーション層で動作するＤＢ要求処理部４３０に関する説明である。そこで、ネットワーク層やリンク層の振る舞いに関して、ステップＳ３０２〜Ｓ３０３でのリード要求の送信とリード応答の受信を例にして、以下に補足する。以下の補足は、ステップＳ３０５〜Ｓ３０６にも、ステップＳ３０８〜Ｓ３０９にも、同様に当てはまる。
【０３１４】
場合によっては、ステップＳ３０２でのＤＢ要求処理部４３０から通信処理部４２０への指示を契機として、通信処理部４２０が、まずＴＣＰコネクションの確立のための処理を行うことがある。つまり、第１通信端点とクライアント４００との間にＴＣＰコネクションがまだ確立されていなければ、通信処理部４２０は、ＴＣＰコネクションの確立を試みる。具体的には、通信処理部４２０は、ＳＹＮ（synchronize）セグメントを送信し、ＳＹＮ／ＡＣＫセグメントの受信を待ち、受信後、ＡＣＫセグメントを送信する。それにより、通信処理部４２０は、第１通信端点とクライアント４００の間にＴＣＰコネクションを確立する。
【０３１５】
そして、ＴＣＰコネクションが確立すると、通信処理部４２０は、ＤＢ要求処理部４３０から指示されたリード要求を、確立したＴＣＰコネクション上で送信する。場合によっては、ＳＹＮセグメントの送信の際に呼び出される図９の処理において、ＡＲＰ要求がブロードキャストされることもある。なお、図９の処理は、ＳＹＮセグメントの送信のときだけでなく、もちろん、ＡＣＫセグメントの送信のときにも、リード要求の送信のときにも、呼び出される。
【０３１６】
逆に、第１通信端点とクライアント４００との間にＴＣＰコネクションが既に確立されていれば、通信処理部４２０は単に、ＤＢ要求処理部４３０から指示されたリード要求を、確立済みのＴＣＰコネクション上で送信する。こうしてリード要求が送信される場合も、もちろん図９の処理が呼び出される。
【０３１７】
ところで、ステップＳ３０２でのＤＢ要求処理部４３０からの指示を契機として、ＴＣＰコネクションを確立するための処理が行われるか否かによらず、リード要求の送信が１回で成功するとは限らない。例えば、以下のように様々な場合があり得る。
【０３１８】
１回目に送信されたリード要求は、第１通信端点を担当するノードに、成功裡に到達することもある。その結果、所定時間ＴＯ＿ｄｂ以内に、ＤＢ要求処理部４３０がリード応答を受信することもある。
【０３１９】
あるいは、リード要求の１回目の送信は失敗するかもしれない。しかし、ＴＣＰによる再送制御を通信処理部４２０が行うので、所定のリトライ回数（例えば３回）以内には、第１通信端点を担当するノードに、リード要求が成功裡に到達することもある。その結果、所定時間ＴＯ＿ｄｂ以内に、ＤＢ要求処理部４３０がリード応答を受信することもある。
【０３２０】
あるいは、上記の所定のリトライ回数までリード要求の再送が繰り返されても、リード要求（つまりリード要求のデータセグメント）に対するＡＣＫセグメントがクライアント４００に受信されないかもしれない。なお、リード要求に対するＡＣＫセグメントは、ピギーバックＡＣＫセグメントであってもよく、換言すれば、リード応答においてＴＣＰヘッダ内のＡＣＫフラグが「１」にセットされていてもよい。
【０３２１】
所定のリトライ回数までリード要求の再送が繰り返されてもリード要求に対するＡＣＫセグメントがクライアント４００に受信されない理由は、いくつか考えられる。
例えば、第１通信端点を担当するノードが交代したにもかかわらず、クライアント４００がまだ交代を認識していない場合があり得る。すると、ＡＲＰテーブル４２１では、第１通信端点のＩＰアドレスに、既に現在は第１通信端点を担当していないノード３００のネットワークインタフェイス３２０のＭＡＣアドレスが対応づけられているかもしれない。つまり、現状を反映していない古いＡＲＰエントリに基づいてフレームが送信されることがあり得る。
【０３２２】
あるいは、第１通信端点を担当するノードに偶然障害が発生しており、かつ障害の発生にともなう第１通信端点の引き継ぎがまだ完了していないこともある。この場合も、現在故障中のノード３００のネットワークインタフェイス３２０のＭＡＣアドレスがフレームの送信に使われ得る。
【０３２３】
以上のように、何らかの理由により、所定のリトライ回数までリード要求の再送が繰り返されても、リード要求に対するＡＣＫセグメントがクライアント４００に受信されない場合がある。そして、その場合におけるエラー処理の実装は、実施形態に応じて様々であってよい。
【０３２４】
例えば、通信処理部４２０は、上記のとおりＴＣＰ／ＩＰプロトコルスタックの標準ライブラリにより実装されていてもよく、具体的には、ＴＣＰモジュール、ＩＰモジュール、ＡＲＰモジュールなどを含んでいてもよい。そして、所定のリトライ回数までリード要求の再送が繰り返されてもリード要求に対するＡＣＫセグメントがクライアント４００に受信されない場合、トランスポート層のＴＣＰモジュールは、以下のように動作してもよい。
【０３２５】
すなわち、ＴＣＰモジュールは、異常発生によるＴＣＰコネクションの切断を認識して、ＴＣＰコネクションをクローズする。また、ＴＣＰモジュールは、ＩＰモジュールを介して間接的に、あるいは直接的に、ＡＲＰモジュールに異常を通知してもよい。なお、異常の通知は、切断されたＴＣＰコネクションで使われている宛先ＩＰアドレスを含む。
【０３２６】
すると、異常の通知を受けたＡＲＰモジュールは、通知された宛先ＩＰアドレスに対応するエントリを、ＡＲＰテーブル４２１から削除する。一方で、ＴＣＰモジュールは、ＴＣＰコネクションの再確立を試みる。
【０３２７】
例えば、図１１のステップＳ３０２での第１通信端点へのリード要求の送信に関してコネクションの再確立が試みられるとする。この場合、通信処理部４２０のＴＣＰモジュールは、ＳＹＮセグメントを送信し、ＳＹＮ／ＡＣＫセグメントの受信を待ち、受信後、ＡＣＫセグメントを送信する。
【０３２８】
そして、ＳＹＮセグメントの際に図９の処理が呼び出されると、上記のようにＡＲＰテーブル４２１のエントリが既に強制的に削除されているため、図９のステップＳ１０２の検索の結果、エントリは見つからない。その結果、ステップＳ１０５でＡＲＰ要求がブロードキャストされ、ステップＳ１０７で新たなエントリがＡＲＰテーブル４２１に追加される。
【０３２９】
場合によっては、以上のようにしてＡＲＰエントリを強制的にクリアして作成しなおすことで、問題が解消する。よって、通信処理部４２０のＴＣＰモジュールは、再確立したＴＣＰコネクション上で、再度、リード要求を送信してもよい。
【０３３０】
例えば、第１通信端点を担当するノードが交代したことをクライアント４００が認識していなかった場合は、以上のコネクションの再確立により、今までＴＣＰコネクションが確立していたノードとは物理的に異なるノードとの間に新たなコネクションが確立する。そして、新たに確立したコネクション上で送信されるリード要求は、第１通信端点を現在担当しているノードに成功裡に到達し、リード応答がクライアント４００に返される。
【０３３１】
例えば、以上のような通信処理部４２０による再送制御とコネクション再確立に十分な長さの時間が、ステップＳ３０３の所定時間ＴＯ＿ｄｂとして予め決められていてもよい。すると、アプリケーション層で動作するＤＢ要求処理部４３０は、再送やＡＲＰエントリの削除と再作成について何ら認識することもなく、単に、「所定時間ＴＯ＿ｄｂ以内にリード応答が受信された」とステップＳ３０３で判断する。
【０３３２】
あるいは、実施形態によっては逆に、ＡＲＰエントリの削除と再作成に関してアプリケーション層のＤＢ要求処理部４３０が責任を持つような実装が採用されてもよい。つまり、通信処理部４２０のＴＣＰモジュールは、上記のようにＡＲＰモジュールへ異常を通知する代わりに、アプリケーション層に異常を通知するように実装されていてもよい。換言すれば、ＴＣＰモジュールは、「所定の回数、データセグメントの再送を繰り返しても、ＡＣＫセグメントが受信されない」とアプリケーション層に通知してもよい。
【０３３３】
すると、ＤＢ要求処理部４３０は、異常が通知されたＴＣＰコネクションのソケットに対してクローズ命令を呼び出す。クローズ命令は、例えば、システムコールでもよいし、ＡＰＩ（Application Programming Interface）関数でもよい。
【０３３４】
また、ＤＢ要求処理部４３０は、異常が通知されたＴＣＰコネクションで使われていた宛先ＩＰアドレスを指定して、ＡＲＰモジュールに対して、ＡＲＰテーブル４２１からのエントリの強制削除を命令する。例えば、ＤＢ要求処理部４３０は、「ａｒｐ」コマンドの呼び出しにより、ＡＲＰモジュールにエントリの強制削除を命令してもよい。
【０３３５】
エントリの強制削除の命令の後のＤＢ要求処理部４３０の動作は、以下の２通りのうちどちらでもよい。
【０３３６】
第１の例は、ＤＢ要求処理部４３０が再送制御を行う例である。つまり、ＤＢ要求処理部４３０は、ステップＳ３０３でリード応答の受信を待っている間に、上記のような異常の通知を受け、ＡＲＰモジュールにエントリの強制削除を命令した場合、ステップＳ３０２と同様の処理を再度行ってもよい。すると、第１通信端点へのリード要求の送信をＤＢ要求処理部４３０から指示された通信処理部４２０は、新たにＳＹＮセグメントを送信することから始めてＴＣＰコネクションの確立を試みる。
【０３３７】
また、ＳＹＮセグメントの送信の際に、図９の処理が呼び出され、ＡＲＰ要求がブロードキャストされる。そして、ＴＣＰコネクションの確立に成功すると、通信処理部４２０は、ＤＢ要求処理部４３０から指示されたリード要求のデータセグメントを、確立したＴＣＰコネクション上で送信する。
【０３３８】
なお、この場合は、以上のようなＤＢ要求処理部４３０による再送制御に十分な長さの時間が、ステップＳ３０３の所定時間ＴＯ＿ｄｂとして予め決められていることが望ましい。すると、１回目のステップＳ３０２の実行から所定時間ＴＯ＿ｄｂ以内に、ＤＢ要求処理部４３０がリード応答を受信することが可能な場合がある。
【０３３９】
また、第２の例は、ＤＢ要求処理部４３０が再送制御を行わない例である。つまり、ＤＢ要求処理部４３０は、ステップＳ３０３でリード応答の受信を待っている間に、上記のような異常の通知を受け、ＡＲＰモジュールにエントリの強制削除を命令した場合は、所定時間ＴＯ＿ｄｂの経過を待たずにステップＳ３０５の処理を行ってもよい。
【０３４０】
この場合は、例えば、同じキー領域に属するキーを指定した別の新たなＤＢアクセス要求がアプリケーション４４０において生じた場合に、当該新たなＤＢアクセス要求を契機として、ＡＲＰ要求がブロードキャストされることがある。そして、その結果、図９のステップＳ１０７で新たなエントリがＡＲＰテーブル４２１に追加されることがある。
【０３４１】
以上、様々な実装例を説明したが、いずれの実装例においても、ＴＣＰコネクションが障害などにより異常に切断してしまった場合は、以下の（８−１）〜（８−３）の処理が行われる。
【０３４２】
（８−１）ＡＲＰテーブル４２１のエントリが強制的に削除される。
（８−２）エントリの強制削除の後（「強制削除後すぐにか、それとも、別の新たなＤＢアクセス要求が生じたときにか」という違いはあるものの）、再度ＴＣＰコネクションが確立される。
（８−３）ＴＣＰコネクションを再確立するためのＳＹＮセグメントの送信の前には、ＡＲＰ要求がブロードキャストされ、強制削除されたエントリにおけるＩＰアドレスと同じＩＰアドレスに関する新たなエントリがＡＲＰテーブル４２１に追加される。
【０３４３】
したがって、ＡＲＰテーブル４２１のエントリの強制削除、再送制御、およびＴＣＰコネクションの再確立が、それぞれＤＢ要求処理部４３０と通信処理部４２０のいずれにより制御されているかによらず、図１の動的対応づけ情報１１２の動的更新が実現される。
【０３４４】
さて、図１２は、クライアントによるライト操作のフローチャートである。図１２のライト操作は、アプリケーション４４０がＤＢ要求処理部４３０にライト要求の送信を指示したときに、開始される。また、ライト要求には、キーとバリューのペアが指定されている。
【０３４５】
ステップＳ４０１でＤＢ要求処理部４３０は、アプリケーション４４０から指定されたキーと、対応表４３１を用いて、３つの通信端点を特定する。ステップＳ４０１は図１１のステップＳ３０１と同様なので、詳しい説明は省略する。
【０３４６】
そして、次のステップＳ４０２でＤＢ要求処理部４３０は、通信処理部４２０とネットワークインタフェイス４１０を介して、ステップＳ４０１で特定した第１通信端点にライト要求を送信する。つまり、ＤＢ要求処理部４３０は、ライト要求の内容と第１通信端点の通信端点情報を指定して、通信処理部４２０にライト要求の送信を指示する。ステップＳ４０２は、送信されるＤＢアクセス要求の内容以外は、図１１のステップＳ３０２と同様である。よって、詳しい説明は省略する。
【０３４７】
また、次のステップＳ４０３でＤＢ要求処理部４３０は、通信処理部４２０とネットワークインタフェイス４１０を介して、ステップＳ４０１で特定した第２通信端点にライト要求を送信する。ステップＳ４０３は、ライト要求の宛先以外はステップＳ４０２と同様である。よって、詳しい説明は省略する。
【０３４８】
さらに、次のステップＳ４０４でＤＢ要求処理部４３０は、通信処理部４２０とネットワークインタフェイス４１０を介して、ステップＳ４０１で特定した第３通信端点にライト要求を送信する。ステップＳ４０４も、ライト要求の宛先以外はステップＳ４０２と同様である。よって、詳しい説明は省略する。
【０３４９】
そして、ステップＳ４０２〜Ｓ４０４の送信の後、ＤＢ要求処理部４３０は、３つの通信端点からの応答の受信を待つ（以下、ライト要求に対する応答を「ライト応答」という）。そして、ステップＳ４０５に示すように、所定時間ＴＯ＿ｄｂ以内に３つの通信端点すべてからＤＢ要求処理部４３０がライト応答を受信すれば、処理はステップＳ４０６に移行する。逆に、所定時間ＴＯ＿ｄｂが経過しても０、１、または２個の通信端点からのライト応答しか受信されなければ、処理はステップＳ４０７に移行する。
【０３５０】
ステップＳ４０６でＤＢ要求処理部４３０は、アプリケーション４４０にライト操作の正常終了を通知する。そして、図１２のライト操作は正常終了する。
逆に、ステップＳ４０７では、ＤＢ要求処理部４３０は、アプリケーション４４０にエラーを通知する。そして、図１２のライト操作は異常終了する。なお、エラーを通知されたアプリケーション４４０は、同じコピーを持つことが期待される３台のノード間でのデータの不一致をなくすため、ロールバックのための何らかの制御を行い、ＤＢ要求処理部４３０に対してロールバックのための特殊なＤＢアクセス要求を発行してもよい。
【０３５１】
なお、ステップＳ４０２〜Ｓ４０４のそれぞれにおいて、図１１のステップＳ３０２などと同様に、図９の処理が呼び出される。また、図１１に関する補足説明と類似のことは、以下のとおり、図１２のステップＳ４０２〜Ｓ４０５にも当てはまる。
【０３５２】
場合によっては、ライト要求のデータセグメントの送信に先立って、ＴＣＰコネクションの確立のための処理が行われる。
また、実装によっては、ＤＢ要求処理部４３０がライト応答の受信を待っている所定時間ＴＯ＿ｄｂの間に、通信処理部４２０による再送制御が行われる。そして、所定のリトライ回数までライト要求の再送が繰り返されてもライト要求に対するＡＣＫセグメントがクライアント４００に受信されない場合は、ＡＲＰテーブル４２１のエントリが強制的に削除される。エントリの強制削除は、図１１に関する補足説明で述べたとおり、通信処理部４２０の制御のもとで行われてもよいし、ＤＢ要求処理部４３０の制御のもとで行われてもよい。
【０３５３】
その後、ＴＣＰコネクションの確立が再度試みられてもよく、新たに確立したＴＣＰコネクション上でライト要求が再送されてもよい。そして、例えば、ＴＣＰコネクションの再確立のためのＳＹＮセグメントの送信の際に、ＡＲＰ要求がブロードキャストされ、その結果、新たなエントリがＡＲＰテーブル４２１に作成される。
【０３５４】
以上、図１１〜１２を参照して、クライアント４００の動作について説明した。続いて、図１３〜１６を参照して、ノード３００の動作について説明する。
図１３は、クライアントからのＤＢアクセス要求にノードが応答する処理のフローチャートである。図１３の処理は、ノード３００が動作している間、実行され続ける。なお、以下では説明の便宜上、図５のノード３００にとってのノード３００自身のことを「ローカルノード」といい、ノード３００以外の他のノードのことを「リモートノード」ということもある。
【０３５５】
ノード３００は、ローカルノードの通信端点（すなわちノード３００自身が担当するキー領域に対応する通信端点）へのＤＢアクセス要求を受信するまで、ステップＳ５０１で待機する。そして、ローカルノードの通信端点へのＤＢアクセス要求が受信されると、処理はステップＳ５０２に移行する。ステップＳ５０１の詳細は、具体的には以下のとおりである。
【０３５６】
ここで、ノード３００自身が担当するキー領域に対応する通信端点は、インタフェイス設定ファイル３３２によってネットワークインタフェイス３２０のＭＡＣアドレスに対応づけられたＩＰアドレスと、ポート番号とのペアにより、識別される。そして、ネットワークインタフェイス３２０において受信されたフレームは、宛先ＩＰアドレスと宛先ポート番号とＤＢヘッダ内のサブタイプに応じて、通信処理部３３０により振り分けられる。
【０３５７】
例えば図５のようにノード３００が３つのキー領域管理部３５０ａ〜３５０ｃを有するとする。この場合、キー領域管理部３５０ａ〜３５０ｃのいずれかに対応する通信端点情報が宛先ＩＰアドレスと宛先ポート番号として指定されたリード要求またはライト要求を受信するまで、通信処理部３３０はステップＳ５０１で待機する。
【０３５８】
そして、通信処理部３３０は、キー領域管理部３５０ａ〜３５０ｃのいずれかに対応する通信端点情報が指定されたリード要求またはライト要求を受信すると、受信したリード要求またはライト要求を出力する。すなわち、リード要求またはライト要求は、宛先ＩＰアドレスに応じて、キー領域管理部３５０ａ〜３５０ｃのいずれかのリード・ライト処理部３５１へと出力される。
【０３５９】
そして、ステップＳ５０２でリード・ライト処理部３５１は、通信処理部３３０から出力されたＤＢアクセス要求がリード要求とライト要求のいずれであるかを判定する。通信処理部３３０からリード要求が出力された場合、処理はステップＳ５０３に移行する、逆に、通信処理部３３０からライト要求が出力された場合、処理はステップＳ５０５に移行する。
【０３６０】
ステップＳ５０３でリード・ライト処理部３５１は、リード要求で指定されているキーに対応するバリューを、ローカルストア３１０から読み出す。
例えば、リード要求には「ｄｅｆ」というキーが指定されているものとし、「ｄｅｆ」というキーは、図５のキー領域管理部３５０ａに対応するキー領域に属しているものとする。また、図８の例によれば、「ｄｅｆ」というキーに対応するバリューは「ＤＥＦ」である。この場合、ステップＳ５０３では、キー領域管理部３５０ａ内のリード・ライト処理部３５１が、ローカルストア３１０から「ＤＥＦ」というバリューを読み出す。
【０３６１】
そして、次のステップＳ５０４でリード・ライト処理部３５１は、ローカルストア３１０から読み出したバリューをクライアント４００に応答する。つまり、リード・ライト処理部３５１は、読み出したバリューをＤＢペイロードに含むＤＢアクセス応答を生成し、生成したＤＢアクセス応答を、通信処理部３３０とネットワークインタフェイス３２０を介してクライアント４００に返す。その後、処理はステップＳ５０１に戻る。
【０３６２】
また、ステップＳ５０５でリード・ライト処理部３５１は、ライト要求で指定されているキーに対応するローカルストア３１０上のバリューを、ライト要求で指定されているバリューに書き換える。
【０３６３】
例えば、ライト要求には「ｄｅｆ」というキーと「ＸＹＺ」というバリューが指定されているものとし、「ｄｅｆ」というキーは、図５のキー領域管理部３５０ａに対応するキー領域に属しているものとする。この場合、ステップＳ５０５でキー領域管理部３５０ａ内のリード・ライト処理部３５１は、図８のように「ｄｅｆ」というキーに対応づけられてローカルストア３１０に記憶されている「ＤＥＦ」というバリューを、「ＸＹＺ」というバリューで上書きする。
【０３６４】
そして、次のステップＳ５０６でリード・ライト処理部３５１は、ライト要求の正常終了をクライアント４００に通知する。つまり、リード・ライト処理部３５１は、ライト要求の正常終了を示すデータをＤＢペイロードまたはＤＢヘッダに含むＤＢアクセス応答を生成し、生成したＤＢアクセス応答をクライアント４００に返す。その後、処理はステップＳ５０１に戻る。
【０３６５】
なお、本実施形態では、上記のとおりノード３００におけるＤＢアクセス要求の受信に先立って、クライアント４００とノード３００の間でＴＣＰコネクションが確立される。そして、ステップＳ５０１では、確立済みのＴＣＰコネクション上でＤＢアクセス要求が受信され、ステップＳ５０４またはＳ５０６におけるＤＢアクセス応答の送信も、確立済みのＴＣＰコネクション上で行われる。
【０３６６】
また、ステップＳ５０４またはＳ５０６におけるＤＢアクセス応答の送信は、上記のとおり通信処理部３３０を介して行われる。よって、ステップＳ５０４またはＳ５０６でリード・ライト処理部３５１が通信処理部３３０へＤＢアクセス応答の送信を指示すると、通信処理部３３０では図９の処理を呼び出す。
【０３６７】
さて、図１４は、ノード３００が新規追加された場合、またはノード３００自身が低負荷の場合に、ノード３００が他のノードからキー領域を引き継ぐ処理のフローチャートである。つまり、ノード３００が新規に追加されると、ノード３００が図１４の処理を開始してもよい。また、既存のノード３００は、ノード３００自体の負荷を監視してもよく、負荷が所定の基準以下の場合に図１４の処理を開始してもよい。負荷は、例えば、以下の（９−１）〜（９−３）のいずれかの指標により計測されてもよい。
【０３６８】
（９−１）ローカルストア３１０の使用率または使用量
（９−２）ノード３００のＣＰＵ５０１の使用率
（９−３）上記（９−１）と（９−２）を組み合わせて計算されるスコア
【０３６９】
ステップＳ６０１でノード３００は、対応表３４０の中から通信端点を１つ選択する。具体的には、ノード３００は、ネットワークインタフェイス３２０に割り当てられていないＩＰアドレスによって識別されるいずれか１つの通信端点を、対応表３４０の中から１つ選択する。より好ましくは、ノード３００は、ネットワークインタフェイス３２０に割り当てられているいずれかのＩＰアドレスに対応するキー領域を避けて、他のキー領域に対応する通信端点の中から１つの通信端点を選択する。ステップＳ６０１における選択は、ランダムな選択であってもよいし、ノード３００に固有の情報（例えばホスト名またはＦＱＤＮ（Fully-Qualified Domain Name））のハッシュ値に基づく選択であってもよい。
【０３７０】
例えば、ネットワークインタフェイス３２０に「１９２．１６８．２５４．１５」と「１９２．１６８．２５４．１７」と「１９２．１６８．２５４．３６」という３つのＩＰアドレスが割り当てられているとする。この場合、ノード３００は、３つのＩＰアドレスにそれぞれ対応するキー領域Ｋ１５、Ｋ１、およびＫ４を避けて、他のキー領域に対応する通信端点の中から、１つの通信端点をランダムに選択してもよい。以下では説明の便宜上、ステップＳ６０１で選択された通信端点を「選択通信端点」という。
【０３７１】
そして、次のステップＳ６０２でノード３００は、選択通信端点に対して引き継ぎを提案する。
例えば、対応表３４０が具体的には図８の対応表６０１であるものとし、ノード３００がステップＳ６０１で「１９２．１６８．２５４．３６：７０００」という通信端点情報で識別される通信端点を選択したとする。図８によれば、「１９２．１６８．２５４．３６」というＩＰアドレスが現在割り当てられているノードは、「４」というインデックスで識別されるキー領域Ｋ４を「第３通信端点」として担当しているノードである。
【０３７２】
この場合、図１４の処理を行うノード３００は、宛先ＩＰアドレスとして「１９２．１６８．２５４．３６」を指定し、宛先ポート番号として「７０００」を指定した制御メッセージ（以下、説明の便宜上「引き継ぎ提案」という）をステップＳ６０２で生成する。
【０３７３】
なお、引き継ぎ提案の送信元ＩＰアドレスとしては、図８の依頼ノードリスト６０５に関して説明した固定的なＩＰアドレスが使われる。例えば、図１４の処理を実行しているノード３００に「１９２．１６８．２５４．１３０」というＩＰアドレスが固定的に割り当てられているとすると、引き継ぎ提案の送信元ＩＰアドレスは「１９２．１６８．２５４．１３０」である。
【０３７４】
以下、説明の便宜上、選択通信端点が現在割り当てられているノードを「現在担当ノード」という。例えば、上記のとおり選択通信端点が「１９２．１６８．２５４．３６：７０００」という通信端点情報で識別されるとすると、「現在担当ノード」は、「４」というインデックスで識別されるキー領域Ｋ４を「第３通信端点」として担当しているノードである。
【０３７５】
また、ステップＳ６０２で生成される引き継ぎ提案は、送信元ＩＰアドレスで識別されるノードが、宛先ＩＰアドレスと宛先ポート番号により識別される通信端点を現在担当ノードから引き継ぐことを、現在担当ノードに提案するためのメッセージである。ノード３００は、ステップＳ６０２において、上記のとおり生成した引き継ぎ提案を、通信処理部３３０とネットワークインタフェイス３２０を介して送信する。
【０３７６】
そして、ノード３００は、引き継ぎ提案への応答を選択通信端点から受信するのをステップＳ６０３で待つ。もし、所定時間（以下「ＴＯ＿ｐｒｏｐ」と表記する）以内に選択通信端点から（換言すれば現在担当ノードから）応答が受信されれば、処理はステップＳ６０４に移行する。逆に、もし所定時間ＴＯ＿ｐｒｏｐ以内に選択通信端点からの応答が受信されなければ、処理はステップＳ６１１へ移行する。
【０３７７】
そして、ステップＳ６０４でノード３００は、応答の内容がＡＣＫとＮＡＣＫ（negative acknowledgement）のいずれであるかを判断する。ＡＣＫ応答は、現在担当ノードが提案を受け入れること（すなわち、現在担当ノードが引き継ぎを希望すること）を示す。逆に、ＮＡＣＫ応答は、現在担当ノードが提案を受け入れないこと（すなわち、引き継ぎは不要であること）を示す。
【０３７８】
例えば、引き継ぎ提案を受けた任意のノードは、当該ノード自身の負荷が所定の基準よりも高いときにＡＣＫ応答を返してもよく、当該ノード自身の負荷が所定の基準以下のときにＮＡＣＫ応答を返してもよい。負荷は、例えば、上記の（９−１）〜（９−３）のいずれかの指標により計測されてもよい。
【０３７９】
ＡＣＫ応答が受信された場合、ノード３００は、選択通信端点（つまり、現在担当ノードからノード３００が引き継ぐ予定の通信端点）に対応する新たなキー領域管理部を生成する。そして、処理はステップＳ６０５に移行する。なお、以下では説明の便宜上、キー領域管理部３５０ｃが新たに生成されたものとする。
【０３８０】
逆に、ＮＡＣＫ応答が受信された場合、処理はステップＳ６１１へと移行する。
そして、ステップＳ６０５では、ＡＣＫ応答の受信を契機として生成されたキー領域管理部３５０ｃ内の取得制御部３５２が、選択通信端点に対して、引き継ぎ要求を送信する。引き継ぎ要求は、具体的には通信処理部３３０とネットワークインタフェイス３２０を介して送信される。また、引き継ぎ要求の宛先ＩＰアドレス、宛先ポート番号、および送信元ＩＰアドレスは、引き継ぎ提案と同じである。
【０３８１】
そして、取得制御部３５２は、送信した引き継ぎ要求に対する引き継ぎ応答を選択通信端点から受信するのを、ステップＳ６０６で待つ。もし、所定時間（以下「ＴＯ＿ｂｕｌｋ」と表記する）以内に選択通信端点から（換言すれば現在担当ノードから）引き継ぎ応答が受信されなければ、図１４の処理は異常終了する。逆に、もし所定時間ＴＯ＿ｂｕｌｋ以内に選択通信端点からの引き継ぎ応答が受信されれば、処理はステップＳ６０７に移行する。
【０３８２】
なお、例えば上記のように選択通信端点が「１９２．１６８．２５４．３６：７０００」という通信端点情報で識別されるとすると、引き継ぎ応答は、「４」というインデックスで識別されるキー領域Ｋ４にキーが属するすべてのエントリを含む。よって、引き継ぎの対象のキー領域に多くのキーが属する場合、時間ＴＯ＿ｂｕｌｋは、十分に長く設定されることが望ましい。例えば、引き継ぎ提案を受けた現在担当ノードは、ＡＣＫ応答を返す場合には、引き継ぎ対象のキー領域に属するキーの数に応じて時間ＴＯ＿ｂｕｌｋの値をＡＣＫ応答において指定してもよい。
【０３８３】
また、引き継ぎ応答は、ネットワークインタフェイス３２０で受信され、通信処理部３３０を介して、引き継ぎ要求の送信元であるキー領域管理部３５０ｃ内の取得制御部３５２へと出力される。なお、引き継ぎ応答において、送信元ＩＰアドレスは選択通信端点のＩＰアドレスであり、宛先ＩＰアドレスは引き継ぎ要求の送信元ＩＰアドレス（すなわち固定的なＩＰアドレス）である。
【０３８４】
また、取得制御部３５２は、ステップＳ６０７において、受信したデータ（つまり引き継ぎ応答に含まれる全エントリ）をローカルストア３１０に保存する。例えば上記の例では、「４」というインデックスで識別されるキー領域Ｋ４にキーが属するすべてのエントリを、取得制御部３５２が新たにローカルストア３１０に追加する。
【０３８５】
その後、取得制御部３５２は、割り当て指示を受信するのをステップＳ６０８で待つ。ここで、「割り当て指示」とは、図１４の処理を実行しているノード３００のネットワークインタフェイス３２０に、選択通信端点のＩＰアドレスを割り当てるよう指示するための制御メッセージである。例えば、説明の便宜上、以下の（１０−１）〜（１０−３）のように想定する。
【０３８６】
（１０−１）選択通信端点は「１９２．１６８．２５４．３６：７０００」という通信端点情報で識別される。
（１０−２）現在担当ノードに固定的に割り当てられているＩＰアドレスは「１９２．１６８．２５４．１３３」である。
（１０−３）図１４の処理を実行しているノード３００に固定的に割り当てられているＩＰアドレスは「１９２．１６８．２５４．１３０」である。
【０３８７】
上記の（１０−１）〜（１０−３）の場合、割り当て指示とは、現在担当ノードが、図１４の処理を実行中のノード３００に対して、「１９２．１６８．２５４．３６」というＩＰアドレスの割り当てを指示するための制御メッセージである。そして、割り当て指示において、送信元ＩＰアドレスは、「１９２．１６８．２５４．１３３」という固定的なＩＰアドレスであり、宛先ＩＰアドレスも、「１９２．１６８．２５４．１３０」という固定的なＩＰアドレスである。
【０３８８】
もし、所定時間（以下「ＴＯ＿ａｓｓｉｇｎ」と表記する）以内に割り当て指示が受信されなければ、図１４の処理は異常終了する。逆に、もし所定時間ＴＯ＿ａｓｓｉｇｎ以内に割り当て指示が受信されれば、処理はステップＳ６０９に移行する。
【０３８９】
そして、ステップＳ６０９で取得制御部３５２は、選択通信端点のＩＰアドレスをネットワークインタフェイス３２０に割り当てるよう、対応づけ部３５４に指示する。すると、対応づけ部３５４は、選択通信端点のＩＰアドレスをネットワークインタフェイス３２０に割り当てるための処理を行う。
【０３９０】
例えば、対応づけ部３５４は、通信処理部３３０内のインタフェイス設定ファイル３３２を直接書き換えて、選択通信端点のＩＰアドレスをネットワークインタフェイス３２０と対応づけてもよい。あるいは、対応づけ部３５４は、例えば「ｉｆｃｏｎｆｉｇ」コマンドなどの適宜のコマンドを発行することにより、通信処理部３３０の機能を呼び出して、通信処理部３３０にインタフェイス設定ファイル３３２を書き換えさせてもよい。
【０３９１】
いずれにしろ、ステップＳ６０９の結果、例えば上記（１０−１）〜（１０−３）の例の場合は、「１９２．１６８．２５４．３６」というＩＰアドレスが、図１４の処理を実行中のノード３００のネットワークインタフェイス３２０に割り当てられる。
【０３９２】
すると、次のステップＳ６１０で監視依頼部３５５は、１つ以上の他のノードを選んで依頼ノードリスト３５６に登録する。そして、監視依頼部３５５は、依頼ノードリスト３５６に登録した各ノードに対して、選択通信端点の監視を要求する。
【０３９３】
例えば、分散ＤＢシステムが８台のノードを含み、「１９２．１６８．２５４．１２８」〜「１９２．１６８．２５４．１３５」の８個のＩＰアドレスがこれら８台のノードに固定的に割り当てられているとする。また、上記（１０−２）のとおり、図１４の処理を実行中のノード３００には「１９２．１６８．２５４．１３０」というＩＰアドレスが固定的に割り当てられているとする。そして、ステップＳ６０９では上記のとおり、「１９２．１６８．２５４．３６」というＩＰアドレスが割り当てられたとする。
【０３９４】
この場合、監視依頼部３５５は、不図示の設定ファイルを読み込むなどの処理により、８つの固定ＩＰアドレスを予め認識しており、ノード３００自身の固定ＩＰアドレスも予め認識している。
【０３９５】
あるいは、監視依頼部３５５は、対応表３４０に現れるＩＰアドレスのうち、ノード３００自身ネットワークインタフェイス３２０に割り当てられていないＩＰアドレスの各々について、当該ＩＰアドレスを宛先ＩＰアドレスとした問い合わせを送信してもよい。問い合わせを受信したノードが、当該ノードの固定ＩＰアドレスを含む応答を返すことにより、監視依頼部３５５は、分散ＤＢシステム内のノード用に使われる固定ＩＰアドレスの集合を認識することができる。
【０３９６】
いずれにせよ、監視依頼部３５５は、８つの固定ＩＰアドレスを予め認識している。よって、ステップＳ６１０で監視依頼部３５５は、「１９２．１６８．２５４．１３０」以外の７つの固定ＩＰアドレスの中から１つ以上の任意のＩＰアドレスを選び、選んだ各ＩＰアドレスを依頼ノードリスト３５６に登録する。例えば、監視依頼部３５５は、「１９２．１６８．２５４．１２８」と「１９２．１６８．２５４．１３３」を選んで依頼ノードリスト３５６に登録してもよい。
【０３９７】
上記の２つのＩＰアドレスを選んだ場合、監視依頼部３５５は、以下の（１１−１）と（１１−２）の監視依頼のデータを生成し、生成した各監視依頼のデータを、通信処理部３３０とネットワークインタフェイス３２０を介して送信する。
【０３９８】
（１１−１）送信元ＩＰアドレスが「１９２．１６８．２５４．１３０」で、宛先ＩＰアドレスが「１９２．１６８．２５４．１２８」で、監視対象としての通信端点を示すＩＰアドレスとポート番号のペアが「１９２．１６８．２５４．３６：７０００」の監視依頼。
（１１−２）送信元ＩＰアドレスが「１９２．１６８．２５４．１３０」で、宛先ＩＰアドレスが「１９２．１６８．２５４．１３２」で、監視対象としての通信端点を示すＩＰアドレスとポート番号のペアが「１９２．１６８．２５４．３６：７０００」の監視依頼。
【０３９９】
もちろん、実施形態によっては、「１９２．１６８．２５４．３６」のようにキー領域に応じて動的に割り当てられるＩＰアドレスが、監視依頼の送信元ＩＰアドレスとして使われてもよい。そして、監視依頼の送信元ポート番号に、監視対象の通信端点のポート番号が指定されてもよい、つまり、監視依頼のパケットにおいては、送信元ＩＰアドレスと送信元ポート番号自体により、監視対象が指定されてもよい。
【０４００】
なお、監視依頼を受信した他のノードでは、通信処理部３３０が監視依頼を監視部３６０に出力する。すると、監視部３６０が、監視依頼に指定されている監視対象の通信端点情報を対象ノードリスト３６１に追加する。
【０４０１】
そして、ステップＳ６１０での１つ以上の他のノードへの監視依頼の送信が終わると、次のステップＳ６１１でノード３００は、図１４の処理を終了するための特定の条件（以下「終了条件」という）が満たされているか否かを判断する。終了条件は、例えば、以下の（１２−１）〜（１２−３）の条件のいずれであってもよいし、その他の条件であってもよい。
【０４０２】
（１２−１）ノード３００の負荷が、図１４の処理を開始するか否かを判断するためにノード３００が参照する基準を超えている。
（１２−２）ノード３００は、図１４の処理を開始してから、ステップＳ６０１での選択を既に所定の回数（例えば３回）行った。
（１２−３）上記（１２−１）と（１２−２）のうち少なくとも一方が成立する。
【０４０３】
そして、終了条件が満たされていれば、ノード３００は図１４の処理を終了する。逆に、終了条件が満たされていなければ、処理はステップＳ６０１へと戻る。
【０４０４】
なお、本実施形態では、引き継ぎ提案、引き継ぎ提案に対するＡＣＫ応答またはＮＡＣＫ応答、引き継ぎ要求、および引き継ぎ応答は、確立済みのＴＣＰコネクション上で送受信される。つまり、場合によっては、ステップＳ６０２で引き継ぎ提案を送信するために、ノード３００は、先にＴＣＰコネクションの確立のための一連の処理（すなわち、ＳＹＮセグメントの送信、ＳＹＮ／ＡＣＫセグメントの受信、およびＡＣＫセグメントの送信）を行う。
【０４０５】
また、図１４では省略されているが、現在担当ノードが割り当て指示を送信する前に、引き継ぎ応答等の送受信に使われたＴＣＰコネクションをクローズするための一連の処理が行われる。なぜなら、当該ＴＣＰコネクションで使われるＩＰアドレスが割り当てられるノードが変化するからである。
【０４０６】
具体的には、現在担当ノードは、引き継ぎ応答の送信後、ＦＩＮ／ＡＣＫセグメントを送信する。そして、図１４の処理を実行しているノード３００は、ＦＩＮ／ＡＣＫセグメントを受信すると、ＦＩＮ／ＡＣＫセグメントに対するＡＣＫセグメントを送信する。また、ＴＣＰコネクションは双方向なので、ノード３００はさらにＦＩＮ／ＡＣＫセグメントを送信する。現在担当ノードは、ＦＩＮ／ＡＣＫセグメントを受信すると、ＦＩＮ／ＡＣＫセグメントに対するＡＣＫセグメントを送信する。以上の処理により、ＴＣＰコネクションはクローズされる。
【０４０７】
また、本実施形態では、割り当て指示もＴＣＰコネクション上で送受信される。割り当て指示の送受信に使われるＴＣＰコネクションの両端の通信端点のＩＰアドレスは、上記（１０−２）と（１０−３）に例示したような固定ＩＰアドレスである。つまり、割り当て指示の送受信に使われるＴＣＰコネクションは、引き継ぎ応答等の送受信に使われたＴＣＰコネクションとは別物である。
【０４０８】
よって、もし固定ＩＰアドレスでそれぞれ識別される通信端点間のＴＣＰコネクションが存在していなければ、現在担当ノードは、割り当て指示を送信する前に、ＴＣＰコネクションを確立するためのＳＹＮセグメントを送信する。すると、図１４の処理を実行しているノード３００の通信処理部３３０がＳＹＮ／ＡＣＫセグメントを送信し、現在担当ノードがさらにＡＣＫセグメントを送信する。割り当て指示は、以上のようにして新たに確立した（あるいは、何らかの別の用途のためにたまたま既に確立していた）ＴＣＰコネクション上で、送受信される。
【０４０９】
さらに、本実施形態では、監視依頼の送信も確立済みのＴＣＰコネクション上で行われる。つまり、場合によっては、ステップＳ６１０で監視依頼を送信するために、ＴＣＰコネクションの確立のための一連の処理を先に通信処理部３３０が行うことがある。
【０４１０】
そして、ステップＳ６０２、Ｓ６０５、およびＳ６１０のいずれにおいても、通信処理部３３０により図９の処理が呼び出される。
また、ステップＳ６０３とＳ６０６とＳ６０８でのタイムアウト処理は、図１１のステップＳ３０３の処理と同様に、ＡＲＰテーブル３３１からのエントリの強制削除、再送制御、ＴＣＰコネクションの再確立などの処理を含んでいてもよい。そして、クライアント４００に関して説明したのと同様に、例えば「アプリケーション層の監視部３６０とトランスポート層の通信処理部３３０のどちらが再送制御を行うのか」という観点などの、いくつかの観点において、具体的実装は様々に異なり得る。
【０４１１】
さて次に、監視を要求されたノードが行う処理について説明する。図１５は、ノードが他のノードを監視し、監視対象が故障した場合に引き継ぎを行う処理のフローチャートである。
【０４１２】
例えば、図３のノードＮ１１が図１４の処理を実行したとする。そして、ノードＮ１１は、ステップＳ６０９でノードＮ１１に動的に割り当てたある１つの通信端点の監視を、ステップＳ６１０においてノードＮ１５とＮ１７に依頼したとする。この場合、ノードＮ１５とＮ１７は、それぞれ図１５の処理を行う。そして、もしその後ノードＮ１１が故障した場合は、ノードＮ１５とＮ１７のうち、先に図１５の処理によりノードＮ１１の故障を認識した方が、監視対象の通信端点の新たな割り当て先のノードとなる。
【０４１３】
なお、図１５の処理は、ノード３００が動作している間、監視部３６０内の対象ノードリスト３６１（より具体的には、例えば図８の対象ノードリスト６０４）に登録されている各通信端点に関して、それぞれ独立に実行され続ける。以下では説明の便宜上、図１５の処理の対象の通信端点を「対象通信端点」という。
【０４１４】
ステップＳ７０１で監視部３６０は、対象通信端点に生存確認メッセージを送信する。例えば、対象通信端点が図８の対象ノードリスト６０４の１番目の通信端点の場合、監視部３６０は、宛先ＩＰアドレスに「１９２．１６８．２５４．９」を指定し、宛先ポート番号に「７０００」を指定した生存確認メッセージを生成する。また、生存確認メッセージの送信元ＩＰアドレスは、図１５の処理を実行しているノード３００に固定的に割り当てられているＩＰアドレスである。監視部３６０は、生成した生存確認メッセージを、通信処理部３３０とネットワークインタフェイス３２０を介して対象通信端点に送信する。
【０４１５】
そして、監視部３６０は、生存確認メッセージに対する応答を対象通信端点から受信するのをステップＳ７０２で待つ。
もし、所定時間（以下「ＴＯ＿ｋｅｅｐａｌｉｖｅ」と表記する）以内に対象通信端点から生存確認メッセージに対する応答が受信されれば、監視部３６０は「対象通信端点が割り当てられているノードは正常である」と判断する。そして、処理はステップＳ７０３に移行する。
【０４１６】
逆に、もし所定時間ＴＯ＿ｋｅｅｐａｌｉｖｅ以内に対象通信端点から生存確認メッセージに対する応答が受信されなければ、監視部３６０は「対象通信端点が割り当てられているノードに障害が発生した」と判断する。そして、フェイルオーバのために処理はステップＳ７０６に移行する。
【０４１７】
ステップＳ７０３で監視部３６０は、生存確認メッセージに対する応答の内容を読み取る。本実施形態では、生存確認メッセージに対する応答は、「監視が必要か否か」を示す情報（例えばフラグなど）を含む。もし、応答において「監視は不要」と指定されていれば、処理はステップＳ７０４に移行する。逆に、応答において「監視が必要」と指定されていれば、処理はステップＳ７０５に移行する。
【０４１８】
なお、生存確認メッセージに対する応答が、「監視が必要か否か」を示す情報を含む理由は、以下のとおりである。
本実施形態では、第１のノードに割り当てられていた通信端点を何らかの理由で第２のノードが引き継ぐと、第２のノードは、第１のノードがどのノードに第１のノードの監視を依頼していたかに関係なく、任意に１つ以上のノードを選ぶ。そして、第２のノードは、選んだ各ノードに、第２のノードに新たに割り当てた通信端点の監視を依頼する。すると、第１のノードから依頼されて第１のノードを監視していた第３のノードからの生存確認メッセージを、第２のノードが受信してしまう場合があり得る。
【０４１９】
なぜなら、生存確認メッセージの宛先は、論理的に通信端点を識別するＩＰアドレスとポート番号により定められるからである。つまり、第３のノードにおけるＡＲＰテーブルの更新にともなって、第３のノードからの生存確認メッセージを、第２のノードが受信してしまうことがあり得る。
【０４２０】
一方、第２のノードが偶然にも第３のノードを選んで監視を依頼した場合を除いて、第２のノードにとって第３のノードは、第２のノードの監視を依頼したノードではない。つまり、第２のノードは、依頼ノードリスト３５６に登録されていないノードから生存確認メッセージを受信する可能性がある。
【０４２１】
そこで、本実施形態では、生存確認メッセージに対する応答が、「監視が必要か否か」を示す情報を含む。以下の図１５〜１６に関する説明から理解されるように、この情報により、生存確認メッセージの宛先のノードが保持する依頼ノードリスト３５６と、生存確認メッセージの実際の送信元のノードとの整合性を保つことが可能となる。
【０４２２】
さて、ここでステップＳ７０３の分岐の説明に戻る。生存確認メッセージに対する応答において「監視が不要」と指定されている場合、ステップＳ７０４で監視部３６０は、対象通信端点を監視対象から外す。つまり、監視部３６０は、対象通信端点を識別する通信端点情報を、対象ノードリスト３６１から削除する。そして、図１５の処理は終了する。その結果、対象ノードリスト３６１から削除された通信端点情報により識別される通信端点についての監視は、行われなくなる。
【０４２３】
他方、ステップＳ７０５で監視部３６０は、ステップＳ７０１での送信から所定時間（以下「Ｉ＿ｋｅｅｐａｌｉｖｅ」と表記する）が経過するまで待機する。所定時間Ｉ＿ｋｅｅｐａｌｉｖｅは、生存確認メッセージの送信間隔として決められた時間である。そして、ステップＳ７０１での送信から所定時間Ｉ＿ｋｅｅｐａｌｉｖｅが経過すると、処理はステップＳ７０１に戻る。よって、対象通信端点のノードが故障しても、故障から最大で（Ｉ＿ｋｅｅｐａｌｉｖｅ＋ＴＯ＿ｋｅｅｐａｌｉｖｅ）以内の時間で、故障が検出可能である。
【０４２４】
さて、ステップＳ７０６〜Ｓ７１３の処理は、監視対象の通信端点における故障が検出された場合に、フェイルオーバのために行われる引き継ぎの処理である。
まず、ステップＳ７０６で監視部３６０は、新たに１つのキー領域管理部を生成する。例えば、上記のように図５のキー領域管理部３５０ａ〜３５０ｃは、別々の３つのスレッドにより実現されていてもよく、監視部３６０は、新たなスレッドを生成することで、新たなキー領域管理部を生成してもよい。生成される新たなキー領域管理部は、具体的には、対象通信端点に対応しており、したがって、対象通信端点と静的に対応づけられているキー領域に対応している。以下では説明の便宜上、ステップＳ７０６でキー領域管理部３５０ｃが生成されたものとする。
【０４２５】
さらにステップＳ７０６では、新たに生成されたキー領域管理部３５０ｃの取得制御部３５２が、対象通信端点に対応するキー領域を担当する別の通信端点を対応表３４０において検索する。
【０４２６】
例えば、対応表３４０が具体的には図８の対応表６０１のとおりであるとし、対象通信端点が「１９２．１６８．２５４．９：７０００」という通信端点情報で識別されるものとする。この場合、対象通信端点は、「９」というインデックスで識別されるキー領域Ｋ９の「第１通信端点」である。
【０４２７】
よって、新たに生成されたキー領域管理部３５０ｃの取得制御部３５２は、キー領域Ｋ９の「第２通信端点」と「第３通信端点」を検索する。その結果、取得制御部３５２は、「第２通信端点」に対応する「１９２．１６８．２５４．２５：７０００」という通信端点情報と、「第３通信端点」に対応する「１９２．１６８．２５４．４１：７０００」という通信端点情報を得る。
【０４２８】
そして、次のステップＳ７０７で取得制御部３５２は、「ステップＳ７０６での検索で見つかった通信端点のうち、まだステップＳ７０８以降の処理の対象として選んでいない通信端点が残っているか否か」を判断する。未選択の通信端点が残っていれば、処理はステップＳ７０８に移行する。
【０４２９】
逆に、ステップＳ７０６で見つかったすべての通信端点について既に選択し終わっているにもかかわらず、ステップＳ７０７の処理が実行される場合とは、「同じキー領域を担当する３つのノードがすべて故障している」などの異常な場合である。よって、未選択の通信端点が残っていない場合は、図１５の処理は異常終了する。
【０４３０】
ステップＳ７０８で取得制御部３５２は、ステップＳ７０６で見つかった通信端点のうち未選択の通信端点を１つ選択する。以下では説明の便宜上、ステップＳ７０８で選択された通信端点を「選択通信端点」という。
【０４３１】
そして、取得制御部３５２は、選択通信端点に対して、選択通信端点に対応するキー領域の全データを要求する。なお、選択通信端点に対応するキー領域は、対象通信端点に対応するキー領域と同じである。
【０４３２】
ここで説明の便宜上、例えば、次の（１３−１）〜（１３−２）のように想定する。
（１３−１）上記のように、ステップＳ７０６で「１９２．１６８．２５４．２５：７０００」と「１９２．１６８．２５４．４１：７０００」という通信端点情報が得られた。
（１３−２）ステップＳ７０８では、「１９２．１６８．２５４．２５：７０００」という通信端点情報で識別される通信端点が選択された。
【０４３３】
上記（１３−１）〜（１３−２）の場合、新たに生成されたキー領域管理部３５０ｃ内の取得制御部３５２は、キー領域Ｋ９にキーが属する全エントリのデータを、選択通信端点に要求する。こうしてステップＳ７０８で送信される要求は、前述のコピー要求である。コピー要求は、取得制御部３５２の指示にしたがって、通信処理部３３０とネットワークインタフェイス３２０を介して送信される。
【０４３４】
上記（１３−１）〜（１３−２）の例におけるコピー要求では、宛先ＩＰアドレスが「１９２．１６８．２５４．２５」であり、宛先ポート番号が「７０００」である。また、送信元ＩＰアドレスは、図１４のステップＳ６０５における引き継ぎ要求と同様に、図１５の処理を実行中のノード３００に固定的に割り当てられているＩＰアドレスである。
【０４３５】
コピー要求の送信後、取得制御部３５２は、コピー応答の受信をステップＳ７０９において待つ。
もし、所定時間（例えば、図１４のステップＳ６０６の所定時間ＴＯ＿ｂｕｌｋと同じでもよい）以内に正常なコピー応答が選択通信端点から受信されなければ、処理はステップＳ７０７へと戻る。逆に、所定時間ＴＯ＿ｂｕｌｋにコピー要求に対する応答を取得制御部３５２が受信した場合、処理はステップＳ７１０に移行する。
【０４３６】
なお、上記では説明を省略したが、取得制御部３５２は、ステップＳ７０８でコピー要求を送信する前に、選択通信端点に対して、所定時間ＴＯ＿ｂｕｌｋを問い合わせるための制御メッセージを送信してもよい。選択通信端点のノードは、選択通信端点に対応するキー領域にキーが属するエントリの数に応じた適宜の時間を、取得制御部３５２に返答してもよい。取得制御部３５２は、制御メッセージに対する応答に基づいて所定時間ＴＯ＿ｂｕｌｋを設定し、その後、上記のようにステップＳ７０８でコピー要求を送信してもよい。
【０４３７】
さて、コピー応答は、より詳しくは、ネットワークインタフェイス３２０で受信され、通信処理部３３０を介して、コピー要求の送信元であるキー領域管理部３５０ｃ内の取得制御部３５２へと出力される。なお、コピー応答において、送信元ＩＰアドレスは選択通信端点のＩＰアドレスであり、宛先ＩＰアドレスはコピー要求の送信元ＩＰアドレス（すなわち固定的なＩＰアドレス）である。
【０４３８】
そして、コピー応答を受信した取得制御部３５２は、ステップＳ７１０において、受信したデータ（つまりコピー応答に含まれる全エントリ）をローカルストア３１０に保存する。
【０４３９】
例えば上記（１３−２）の例における選択通信端点は、キー領域Ｋ９の「第２通信端点」である。よって、コピー応答は、キー領域Ｋ９にキーが属するすべてのエントリを含む。したがって、ステップＳ７１０で取得制御部３５２は、キー領域Ｋ９にキーが属するすべてのエントリを、新たにローカルストア３１０に追加する。
【０４４０】
また、次のステップＳ７１１で取得制御部３５２は、対象通信端点のＩＰアドレスをネットワークインタフェイス３２０に割り当てるよう、対応づけ部３５４に指示する。すると、対応づけ部３５４は、対象通信端点のＩＰアドレスをネットワークインタフェイス３２０に割り当てるための処理を行う。例えば、対象通信端点が「１９２．１６８．２５４．９：７０００」という通信端点情報で識別される場合、ノード３００自身のネットワークインタフェイス３２０には「１９２．１６８．２５４．９」というＩＰアドレスが対応づけられる。
【０４４１】
なお、図１４のステップＳ６０９と同様に、ステップＳ７１１において対応づけ部３５４は、通信処理部３３０内のインタフェイス設定ファイル３３２を直接書き換えてもよい。あるいは、対応づけ部３５４は、コマンドを発行することにより、通信処理部３３０の機能を呼び出して、通信処理部３３０にインタフェイス設定ファイル３３２を書き換えさせてもよい。
【０４４２】
そして、次のステップＳ７１２において、コピー要求を送信した取得制御部３５２と同じキー領域管理部３５０ｃ内の監視依頼部３５５が、１つ以上の他のノードを選んで依頼ノードリスト３５６に登録する。そして、監視依頼部３５５は依頼ノードリスト３５６に登録した各ノードに対して、対象通信端点の監視を要求する。
【０４４３】
ステップＳ７１２は、「どの通信端点の監視が要求されるか」という点以外は、図１４のステップＳ６１０と同様である。よってステップＳ７１２の詳細についての説明は省略する。
【０４４４】
また、次のステップＳ７１３では、取得制御部３５２がフェイルオーバの完了を監視部３６０に報告する。すると、監視部３６０は、対象通信端点をローカルノード（つまりノード３００自身）の監視対象から外す。つまり、監視部３６０は、対象通信端点を識別する通信端点情報を、対象ノードリスト３６１から削除する。なぜなら、対象通信端点に対応する物理的なノードは、いまやローカルノード３００であって、リモートノードではないからである。
【０４４５】
ステップＳ７１３での削除の後、図１５の処理も終了する。なお、実施形態によっては、取得制御部３５２がステップＳ７１０〜Ｓ７１２の処理を実行するのと並行して、監視部３６０がステップＳ７１３の処理を実行してもよい。あるいは、ステップＳ７１３の処理がステップＳ７１０〜Ｓ７１２の処理の前に実行されてもよい。
【０４４６】
ところで、以上説明した図１５の処理において、ステップＳ７０１での生存確認メッセージの送信と、ステップＳ７０８でのコピー要求の送信と、ステップＳ７１２での監視依頼の送信は、図９の処理を含む。つまり、ＡＲＰテーブル３３１の状態によっては、ステップＳ７０１、Ｓ７０８、またはＳ７１２においてＡＲＰ要求のブロードキャストとＡＲＰテーブル３３１の更新が行われることもある。
【０４４７】
また、場合によっては、ステップＳ７０１、Ｓ７０８、またはＳ７１２での送信が、通信処理部３３０によるＴＣＰコネクションの確立を含むこともある。
すなわち、生存確認メッセージとそれに対する応答は、本実施形態では、予め確立されたＴＣＰコネクション上で送受信される。同様に、コピー要求とそれに対する応答も、予め確立されたＴＣＰコネクション上で送受信される。また、監視依頼も、予め確立されたＴＣＰコネクション上で送受信される。
【０４４８】
よって、もし送信対象のメッセージに対応するＴＣＰコネクションがまだ確立されていなければ、ステップＳ７０１、Ｓ７０８、またはＳ７１２における送信指示を契機として、通信処理部３３０が、ＴＣＰコネクションを確立するための処理を行う。具体的には、通信処理部３３０は、ＳＹＮセグメントの送信、ＳＹＮ／ＡＣＫセグメントの受信、およびＡＣＫセグメントの送信により、ＴＣＰコネクションを確立する。
【０４４９】
なお、上記のようなＡＲＰ要求のブロードキャストは、例えば、通信処理部３３０がＳＹＮセグメントを送信しようとしてＡＲＰテーブル３３１を参照した結果として、ＳＹＮセグメントの実際の送信に先立って行われることもある。あるいは、ＡＲＰエントリがエージングにより削除されるタイミングによっては、通信処理部３３０が確立済みのＴＣＰコネクション上でデータセグメントを送信しようとしたときに、ＡＲＰ要求がブロードキャストされることもあり得る。
【０４５０】
また、ステップＳ７０２とＳ７０９でのタイムアウト処理は、クライアント４００における図１１のステップＳ３０３の処理と同様に、ＡＲＰテーブル３３１からのエントリの強制削除、再送制御、ＴＣＰコネクションの再確立などの処理を含んでいてもよい。そして、クライアント４００に関して説明したのと同様に、例えば「アプリケーション層の監視部３６０とトランスポート層の通信処理部３３０のどちらが再送制御を行うのか」という観点などの、いくつかの観点において、具体的実装は様々に異なり得る。そこで、タイムアウト処理の詳細については、図１８とともに後述する。
【０４５１】
続いて、図１６のフローチャートを参照して、監視されるノードが行う処理について説明する。つまり、図１４のステップＳ６１０または図１５のステップＳ７１２で監視依頼を送信したノードは、その後、図１６の処理を実行する。より具体的には、ノード３００の各キー領域管理部内の監視依頼部３５５が図１６の処理を実行する。
【０４５２】
ステップＳ８０１で監視依頼部３５５は、依頼ノードリスト３５６のエントリ数が所定数（以下では「Ｅ＿ｒｅｑ」と表記する）未満か否かを判断する。
なお、所定数Ｅ＿ｒｅｑは、２以上であることが望ましい。なぜなら、「偶然、監視するノードと監視されるノードの双方が故障している」という状況が、まれに（しかし無視することはできない程度に）起こり得るからである。当該状況において、もしＥ＿ｒｅｑ＝１だと、監視されるノードの故障が検出不能である。
【０４５３】
しかし、Ｅ＿ｒｅｑ＞１であれば、「監視される１台のノードと監視するＥ＿ｒｅｑ台のノードがすべて故障している」という状況の確率はほとんどゼロである。よって、監視されるノードの故障は、監視するＥ＿ｒｅｑ台のノードのうちで正常な少なくとも１台のノードにより、確実に検出可能である。よって、Ｅ＿ｒｅｑ＞１であることが望ましい。
【０４５４】
そして、依頼ノードリスト３５６のエントリ数が所定数Ｅ＿ｒｅｑ以上ならば、処理はステップＳ８０２に移行する。逆に、依頼ノードリスト３５６のエントリ数が所定数Ｅ＿ｒｅｑ未満の場合、処理はステップＳ８０８に移行する。
【０４５５】
ステップＳ８０２で監視依頼部３５５は、過去の所定期間（以下では「Ｐ＿ｋｅｅｐａｌｉｖｅ」と表記する）内に生存確認メッセージを送信してきていない依頼ノードがあるか否かを判断する。なお、以下の説明においては、依頼ノードリスト３５６の各要素により識別される各ノードを「依頼ノード」という。
【０４５６】
ステップＳ８０２における所定期間Ｐ＿ｋｅｅｐａｌｉｖｅの長さは、例えば、生存確認メッセージの送信間隔Ｉ＿ｋｅｅｐａｌｉｖｅに適宜のマージンを加えた長さである。例えば、所定期間Ｐ＿ｋｅｅｐａｌｉｖｅが送信間隔Ｉ＿ｋｅｅｐａｌｉｖｅの２倍程度であってもよい。
【０４５７】
もし、所定期間Ｐ＿ｋｅｅｐａｌｉｖｅ内に生存確認メッセージを送信してきていない依頼ノードがなければ、処理はステップＳ８０３に移行する。つまり、依頼ノードリスト３５６に登録されている各依頼ノードが、所定期間Ｐ＿ｋｅｅｐａｌｉｖｅ内に少なくとも１回は生存確認メッセージを送信してきている場合、すべての依頼ノードは正常に監視を続行中である。よって、処理はステップＳ８０３に移行する。
【０４５８】
逆に、所定期間Ｐ＿ｋｅｅｐａｌｉｖｅ内に生存確認メッセージを送信してきていない依頼ノードがあれば、処理はステップＳ８０７に移行する。例えば、ある依頼ノードが故障してしまった場合、故障した依頼ノードからの生存確認メッセージの送信は途絶えてしまう。よって、依頼ノードが故障した場合などに、処理がステップＳ８０２からステップＳ８０７へと進むことがある。
【０４５９】
ステップＳ８０３で監視依頼部３５５は、いずれかのノードから生存確認メッセージを受信するまで待つ。ネットワークインタフェイス３２０と通信処理部３３０を介して監視依頼部３５５がいずれかのノードから生存確認メッセージを受信すると、処理はステップＳ８０４に移行する。
【０４６０】
なお、図１５のステップＳ７０１に関して説明したとおり、生存確認メッセージの送信元ＩＰアドレスは、管理用の固定的なＩＰアドレスである。また、生存確認メッセージの宛先ＩＰアドレスは、キー領域とノードの対応関係に応じて動的に割り当てられるＩＰアドレスである。
【０４６１】
ステップＳ８０４で監視依頼部３５５は、受信した生存確認メッセージの送信元のノードが依頼ノードリスト３５６に存在するか否かを判断する。
ここで、図８に関して説明したとおり、依頼ノードリスト３５６の各要素も固定的なＩＰアドレスである。
【０４６２】
よって、受信した生存確認メッセージの送信元ＩＰアドレスが依頼ノードリスト３５６に含まれれば、監視依頼部３５５は「受信した生存確認メッセージの送信元のノードが依頼ノードリスト３５６に存在する」と判断する。そして、処理はステップＳ８０５に移行する。
【０４６３】
逆に、受信した生存確認メッセージの送信元ＩＰアドレスが依頼ノードリスト３５６に含まれなければ、監視依頼部３５５は「受信した生存確認メッセージの送信元のノードが依頼ノードリスト３５６に存在しない」と判断する。そして、処理はステップＳ８０６に移行する。
【０４６４】
ステップＳ８０５で監視依頼部３５５は、「ノード３００（より詳細には、監視依頼部３５５を含むキー領域管理部）が生存している」と示す通常の応答を返す。
【０４６５】
つまり、監視依頼部３５５は、以下の（１４−１）〜（１４−４）のような応答を生成する。
【０４６６】
（１４−１）送信元ＩＰアドレスは、監視依頼部３５５を含むキー領域管理部に対応するＩＰアドレスである。
（１４−２）宛先ＩＰアドレスは、生存確認メッセージの送信元ＩＰアドレスである。
（１４−３）ＤＢヘッダのタイプ（またはサブタイプ）は、生存確認メッセージに対する応答であることを示す。
（１４−４）ＤＢヘッダまたはＤＢペイロードは、「以後も監視が必要であること」を示す情報を含む。
【０４６７】
そして、監視依頼部３５５は、生成した応答を、通信処理部３３０とネットワークインタフェイス３２０を介して、生存確認メッセージの送信元ノードに送信する。送信後、処理はステップＳ８０１に戻る。なお、ステップＳ８０５で送信された応答は、図１５の処理を実行する依頼ノードにおいて、ステップＳ７０２で受信される。
【０４６８】
ところで、依頼ノードリスト３５６に登録されていないノードからの生存確認メッセージを受信した場合、監視依頼部３５５は、ステップＳ８０６において、「以後は監視不要である」と指定した応答を返す。ステップＳ８０６で返される応答は、（１４−１）〜（１４−３）の点で、ステップＳ８０５で返される応答と同じである。違いは、ステップＳ８０６で返される応答には（１４−４）の情報の代わりに「監視不要」を示す情報が含まれる点である。
【０４６９】
なお、ステップＳ８０６においても、監視依頼部３５５が生成した応答は、通信処理部３３０とネットワークインタフェイス３２０を介して送信される。そして、送信後、処理はステップＳ８０１に戻る。また、送信された応答は、図１５の処理を実行する依頼ノードにおいて、ステップＳ７０２で受信される。
【０４７０】
さて、ステップＳ８０７の処理は、所定期間Ｐ＿ｋｅｅｐａｌｉｖｅ内に生存確認メッセージを送信してきていない依頼ノードがある場合に実行される。ステップＳ８０７で監視依頼部３５５は、所定期間Ｐ＿ｋｅｅｐａｌｉｖｅ内に生存確認メッセージを送信してきていない各依頼ノードのＩＰアドレスを依頼ノードリスト３５６から削除する。そして、処理はステップＳ８０１に戻る。
【０４７１】
また、依頼ノードリスト３５６のエントリ数が所定数Ｅ＿ｒｅｑ未満のとき、ステップＳ８０８で監視依頼部３５５は、不足に応じて、新たなノードを選ぶ。例えば、所定数Ｅ＿ｒｅｑが３であり、依頼ノードリスト３５６のエントリ数が１の場合、監視依頼部３５５は、２（＝３−１）台のノードを新たに選ぶ。
【０４７２】
図１４のステップＳ６１０に関して述べたとおり、監視依頼部３５５は、分散ＤＢシステムで使われる固定ＩＰアドレスの集合を予め認識しており、ノード３００自体に固定的に割り当てられているＩＰアドレスも予め認識している。よって、監視依頼部３５５は、ステップＳ８０８においても、固定ＩＰアドレスの集合の中から、ローカルノード３００以外の他のノードに割り当てられているＩＰアドレスを選択することができる。
【０４７３】
そして、監視依頼部３５５は、不足に応じて新たなノードを選ぶと（換言すれば、各ノードの固定ＩＰアドレスを選ぶと）、次にステップＳ８０９において、選んだ各ノードにノード３００の監視を依頼する。より具体的には、監視依頼部３５５は、監視依頼部３５５を含むキー領域管理部に対応する通信端点を監視対象として指定する監視依頼を生成する。そして、監視依頼部３５５は、生成した監視依頼を、通信処理部３３０とネットワークインタフェイス３２０を介して送信する。
【０４７４】
例えば、以下の（１５−１）〜（１５−３）の仮定が成り立つとする。
（１５−１）対応表３４０は、図８の対応表６０１のとおりである。
（１５−２）図１６の処理を実行している監視依頼部３５５は、キー領域管理部３５０ｂ内の監視依頼部３５５である。
（１５−３）キー領域管理部３５０ｂは、「４」というインデックスで識別されるキー領域Ｋ４の「第３通信端点」に対応する。
【０４７５】
上記（１５−１）〜（１５−３）の場合、キー領域管理部３５０ｂの監視依頼部３５５は、「１９２．１６８．２５４．３６：７０００」という通信端点情報により、監視対象の通信端点を指定する。なお、図１４のステップＳ６１０と同様に、ステップＳ８０９で送信される監視依頼においても、送信元ＩＰアドレスとして、固定ＩＰアドレスが使われてもよいし、監視対象の通信端点のＩＰアドレスが使われてもよい。
【０４７６】
また、次のステップＳ８１０で監視依頼部３５５は、ステップＳ８０８で選んだ各ノードを対象ノードリスト３６１に追加する。つまり、監視依頼部３５５は、ステップＳ８０８で選んだ各固定ＩＰアドレスを依頼ノードリスト３５６に追加する。そして、処理はステップＳ８０１に戻る。
【０４７７】
なお、本実施形態では、生存確認メッセージと、生存確認メッセージに対する応答は、確立済みのＴＣＰコネクション上で送信される。つまり、ステップＳ８０５とＳ８０６では、ステップＳ８０３で受信された生存確認メッセージが送られるのに使われた確立済みのＴＣＰコネクション上で、応答が送信される。
【０４７８】
また、本実施形態では、監視依頼も確立済みのＴＣＰコネクション上で送信される。よって、ステップＳ８０９で監視依頼を生成した監視依頼部３５５から監視依頼の送信を指示された通信処理部３３０は、場合によっては、まずＴＣＰコネクションを確立するための処理を行う。つまり、ステップＳ８０９での監視依頼の送信のために、ＳＹＮセグメントの送信から始まる一連の処理が行われることがある。
【０４７９】
なお、監視依頼の送信元ＩＰアドレスに、監視対象の通信端点のＩＰアドレスが使われる場合は、監視依頼と、監視依頼に応じた生存確認メッセージと、生存確認メッセージに対する応答が、すべて同じＴＣＰコネクション上で送受信されてもよい。
【０４８０】
そして、ステップＳ８０５、Ｓ８０６、およびＳ８０９のいずれも、図９の処理の呼び出しを含む。したがって、ＡＲＰテーブル３３１の状態によっては、ステップＳ８０５、Ｓ８０６、またはＳ８０９での送信が、ＡＲＰ要求のブロードキャストとＡＲＰテーブル３３１の更新をともなうことがある。
【０４８１】
続いて、図１７〜２２のシーケンス図を参照して、図３の分散ＤＢシステムの動作シーケンスの例をいくつか説明する。図１７〜２２の例から理解されるように、図３のノードＮ１１〜Ｎ１８がそれぞれ図９〜１０および図１３〜１６のフローチャートにしたがって動作することにより、分散ＤＢシステム全体がうまく動作する。
【０４８２】
なお、図１７〜２２の説明においては、以下の（１６−１）〜（１６−３）のように仮定する。
【０４８３】
（１６−１）図３のノードＮ１１〜Ｎ１８のそれぞれは、図５のノード３００のように構成されている。
（１６−２）図３のクライアント２０２は図６のクライアント４００のように構成されている。
（１６−３）ノード３００の対応表３４０とクライアント４００の対応表４３１は、図８の対応表６０１のとおりである。
【０４８４】
さて、図１７は、クライアント２０２からの要求とノードからの正常な応答のシーケンス図である。図１７〜２２では紙幅の都合上、ノードＮ１１〜Ｎ１８のうち、ノードＮ１５〜Ｎ１８は省略されている。
【０４８５】
まず、クライアント２０２のアプリケーション４４０が、「ａｂｃ」というキーを指定してリード操作を行うようＤＢ要求処理部４３０に指示する。すると、ＤＢ要求処理部４３０は図１１の処理を開始する。
【０４８６】
以下では説明の便宜上、「ａｂｃ」というキーが属するキー領域が、「１」というインデックスで識別されるキー領域Ｋ１であるものとする。すると、図１１のステップＳ３０２で指定される第１通信端点とは、図８によれば、具体的には「１９２．１６８．２５４．１：７０００」という通信端点情報で識別される通信端点のことである。
【０４８７】
ＤＢ要求処理部４３０は、図１１のステップＳ３０２において、上記の第１通信端点へのリード要求の送信を通信処理部４２０に指示する。すると、通信処理部４２０は、クライアント２０２と、ＤＢ要求処理部４３０から指定された通信端点の間にＴＣＰコネクションが存在するか否かを確認する。ところが、図１７の例では、まだＴＣＰコネクションが存在しない。
【０４８８】
そこで、通信処理部４２０は、「１９２．１６８．２５４．１：７０００」という通信端点情報で識別される通信端点とクライアント２０２との間にＴＣＰコネクションを確立しようとする。具体的には、通信処理部４２０は、ＳＹＮセグメントを送信しようとする。そして、ＳＹＮセグメントの送信のために、図９の処理が呼び出される。
【０４８９】
図１７の例は、図９のステップＳ１０２の検索においてエントリが見つからない場合の例である。したがって、図９のステップＳ１０５では、具体的には図１７のステップＳ９０１に示すように、ＴＰＡ（Target Protocol Address）として「１９２．１６８．２５４．１」というＩＰアドレスが指定されたＡＲＰ要求７０１が、クライアント２０２からブロードキャストされる。
【０４９０】
ＡＲＰ要求７０１は、図３のブロードキャストドメイン２００内の各装置で受信される。そして、ＡＲＰ要求７０１を受信した各装置は、図１０にしたがって動作する。
ここで、ＡＲＰ要求７０１がブロードキャストされた時点において、「１９２．１６８．２５４．１」というＩＰアドレスが、ノードＮ１１のネットワークインタフェイス３２０に割り当てられているものとする。すると、図１７のステップＳ９０２に示すように、ノードＮ１１が図１０のステップＳ２０４でＡＲＰ応答７０２をクライアント２０２に返す。
【０４９１】
ＡＲＰ応答７０２には、ＳＨＡ（Sender Hardware Address）としてノードＮ１１のネットワークインタフェイス３２０のＭＡＣアドレスが指定されている。以下では説明の便宜上、図１７に例示するとおり、ノードＮ１１のネットワークインタフェイス３２０のＭＡＣアドレスが「００−２３−２６−６Ａ−Ｃ２−４Ｃ」であるものとする。
【０４９２】
また、クライアント２０２はＡＲＰ応答７０２を受信する。ＡＲＰ応答７０２の受信は、図９のステップＳ１０６に相当する。よって、図９のステップＳ１０７に示すとおり、ＡＲＰ応答７０２を受信したクライアント２０２では、ＡＲＰテーブル４２１が更新される。
【０４９３】
具体的には、図１７のステップＳ９０３のとおり、クライアント２０２のＡＲＰテーブル４２１には、新たなＡＲＰエントリ７０３が追加される。ＡＲＰエントリ７０３は、「１９２．１６８．２５４．１」というＩＰアドレスと「００−２３−２６−６Ａ−Ｃ２−４Ｃ」というＭＡＣアドレスを対応づけている。
【０４９４】
こうして図９のステップＳ１０７に相当する図１７のステップＳ９０３でＡＲＰエントリ７０３が追加されると、クライアント２０２は再度図９のステップＳ１０２でＡＲＰテーブル４２１を検索する。その結果、ステップＳ１０３では、新たに追加されたＡＲＰエントリ７０３が見つかる。
【０４９５】
したがって、図９のステップＳ１０４で、クライアント２０２の通信処理部４２０は、宛先ＩＰアドレスが「１９２．１６８．２５４．１」で宛先ポート番号が「７０００」のＳＹＮセグメントを生成する。そして、通信処理部４２０は、生成したＳＹＮセグメントを、ネットワークインタフェイス４１０を介して送信する。
【０４９６】
なお、このＳＹＮセグメントの宛先ＭＡＣアドレスは、「００−２３−２６−６Ａ−Ｃ２−４Ｃ」である。よって、ＳＹＮセグメントは、ノードＮ１１のネットワークインタフェイス３２０で受信され、ノードＮ１１の通信処理部３３０に出力される。
【０４９７】
その結果、ノードＮ１１の通信処理部３３０は、ＳＹＮ／ＡＣＫセグメントを生成し、ネットワークインタフェイス３２０を介してＳＹＮ／ＡＣＫセグメントをクライアント２０２に送信する。すると、ＳＹＮ／ＡＣＫセグメントはクライアント２０２のネットワークインタフェイス４１０で受信されて通信処理部４２０に出力される。
【０４９８】
その結果、クライアント２０２の通信処理部４２０は、ＡＣＫセグメントを生成し、ネットワークインタフェイス４１０を介してＡＣＫセグメントをノードＮ１１に送信する。すると、ＡＣＫセグメントはノードＮ１１のネットワークインタフェイス３２０で受信されて通信処理部３３０に出力される。
【０４９９】
以上の３ウェイハンドシェイクによるＴＣＰコネクションの確立が、図１７ではステップＳ９０４の両向き矢印により表されている。そして、上記のとおり、ＴＣＰコネクションの確立は、図１１のステップＳ３０２でのリード要求の送信のために行われる。
【０５００】
したがって、ステップＳ９０４でＴＣＰコネクションが確立すると、次のステップＳ９０５に示すように、クライアント２０２のＤＢ要求処理部４３０は、ＴＣＰコネクション上でリード要求７０４を送信する。リード要求７０４は図８のフレーム６０６のような形式だが、図１７には一部のフィールドのみ抜粋して示してある。
【０５０１】
リード要求７０４の宛先ＭＡＣアドレスは、ＡＲＰ応答７０２により判明したＭＡＣアドレス（すなわちノードＮ１１のネットワークインタフェイス３２０のＭＡＣアドレス）であり、具体的には「００−２３−２６−６Ａ−Ｃ２−４Ｃ」である。また、リード要求７０４の宛先ＩＰアドレスと宛先ポート番号は、クライアント２０２が図１１のステップＳ３０１で特定した第１通信端点を識別するＩＰアドレスとポート番号であり、具体的には「１９２．１６８．２５４．１」と「７０００」である。
【０５０２】
そして、リード要求７０４のＤＢヘッダで指定されているサブタイプは「リード要求」を示す値である。また、リード要求７０４のＤＢペイロードには、アプリケーション４４０が指定したキー（すなわち「ａｂｃ」というキー）が指定されている。
【０５０３】
そして、リード要求７０４はノードＮ１１で受信される。また、リード要求７０４を受信した時点でノードＮ１１は、「１９２．１６８．２５４．１：７０００」という通信端点情報で識別される通信端点を担当している。つまり、「１９２．１６８．２５４．１：７０００」という通信端点情報に対応するキー領域Ｋ１の全エントリがノードＮ１１のローカルストア３１０には記憶されており、ノードＮ１１には、キー領域Ｋ１に対応するキー領域管理部が存在する。
【０５０４】
よって、リード要求７０４を受信したノードＮ１１は、図１３の処理を実行する。すると、図１３のステップＳ５０３で、リード・ライト処理部３５１は、リード要求７０４に指定されている「ａｂｃ」というキーに対応する「ＡＢＣ」というバリューを、ローカルストア３１０から読み出す。
【０５０５】
そして、図１３のステップＳ５０４に対応する図１７のステップＳ９０６では、「ＡＢＣ」というバリューを含むリード応答７０５が、ノードＮ１１からクライアント２０２へと送信される。もちろんリード応答７０５も、ステップＳ９０４で確立したＴＣＰコネクション上で送信される。
【０５０６】
以上のようにして、クライアント２０２は、リード応答７０５を受信する。
なお、ＤＢ要求処理部４３０が図１１のステップＳ３０２でリード要求の送信を通信処理部４２０に指示してから、ステップＳ９０６での受信までの時間の長さは、図１７の例では、図１１のステップＳ３０３の所定時間ＴＯ＿ｄｂ以内であるものとする。したがって、図１１の処理はステップＳ３０３からステップＳ３０４へと進む。その結果、クライアント２０２のＤＢ要求処理部４３０は、ステップＳ３０４で、リード応答７０５から取得した「ＡＢＣ」というバリューをアプリケーション４４０に返す。
【０５０７】
続いて、図１８を参照して、ノードの故障と引き継ぎの例について説明する。なお、図１８の動作シーケンスは、下記（１７−１）〜（１７−７）を前提とする。
【０５０８】
（１７−１）ノードＮ１３のネットワークインタフェイス３２０のＭＡＣアドレスは、「００−２３−２６−０２−Ｃ６−Ｄ７」である。
（１７−２）ある時点（以下「時点Ｔ１」という）において、ノードＮ１３は、図１４または図１５の処理を実行した結果として、「３」というインデックスで識別されるキー領域Ｋ３を「第１通信端点」として新たに担当することになった。つまり、時点Ｔ１において、ノードＮ１３のネットワークインタフェイス３２０には、「１９２．１６８．２５４．３」というＩＰアドレスが割り当てられた。
（１７−３）ノードＮ１３は、キー領域Ｋ３を「第１通信端点」として担当するに際して、「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される通信端点の監視を、少なくともノードＮ１２に依頼した。
（１７−４）時点Ｔ１は、図１７のステップＳ９０１より前でもよいし、ステップＳ９０６より後でもよいし、ステップＳ９０１とステップＳ９０６の間の任意の時点であってもよい。また、時点Ｔ１は、図１８の動作シーケンスの開始時点より前である。
（１７−５）時点Ｔ１以後に、何らかの事情により、ノードＮ１２のＡＲＰテーブル３３１には、「１９２．１６８．２５４．３」というＩＰアドレスと「００−２３−２６−０２−Ｃ６−Ｄ７」というＭＡＣアドレスを対応づける、図１８のＡＲＰエントリ７０６が登録された。
（１７−６）図１８の動作シーケンスの開始時点において、ＡＲＰエントリ７０６は、まだ削除されずにノードＮ１２のＡＲＰテーブル３３１に残っている。
（１７−７）図１８の動作シーケンスの開始時点でも、ノードＮ１３はまだキー領域Ｋ３を「第１通信端点」として担当している。
【０５０９】
さて、以上の（１７−１）〜（１７−７）の仮定のもと、ステップＳ１００１に示すように、ある時点でノードＮ１３が故障したとする。
他方、（１７−３）の仮定より、ノードＮ１２の監視部３６０は、図１５の処理を実行する。すなわち、ノードＮ１２の監視部３６０は、「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される通信端点を監視する。そして、図１８のステップＳ１００２のタイミングで、ノードＮ１２の監視部３６０は、図１５のステップＳ７０１の処理を実行する。すると、宛先ＩＰアドレスが「１９２．１６８．２５４．３」で宛先ポート番号が「７０００」の生存確認メッセージ７０７が、ステップＳ１００２において、ノードＮ１２から送信される。
【０５１０】
ステップＳ１００２の動作の詳細は以下のとおりである。ノードＮ１２の監視部３６０は、図１５のステップＳ７０１で、生存確認メッセージ７０７を送信するよう通信処理部３３０に指示する。すると、通信処理部３３０は、「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される通信端点と、ノードＮ１２の固定ＩＰアドレスと所定のポート番号で識別される通信端点との間に、ＴＣＰコネクションが確立されているか否かを判断する。
【０５１１】
ここでは説明の簡単化のため、ＴＣＰコネクションが既に確立されていたものとする。すると、通信処理部３３０は、確立済みのＴＣＰコネクション上で生存確認メッセージ７０７を送信しようとする。つまり、通信処理部３３０は生存確認メッセージ７０７の送信のために図９の処理を開始する。
【０５１２】
すると、図９のステップＳ１０２の検索において図１８のＡＲＰエントリ７０６が見つかる。その結果、図９のステップＳ１０４で、図１８の生存確認メッセージ７０７が送信される。
【０５１３】
仮に、生存確認メッセージ７０７の宛先のノードＮ１３が正常に動作していれば、ノードＮ１３は、図１６の処理を実行し、図１６のステップＳ８０５で生存確認メッセージ７０７に対する応答を送信するであろう。しかし、ノードＮ１３は、上記のとおりステップＳ１００１で既に故障している。したがって、生存確認メッセージ７０７に対する応答は、ノードＮ１３から送信されてこない。
【０５１４】
また、ノードＮ１２の監視部３６０は、図１５のステップＳ７０２に示すように、生存確認メッセージ７０７に対する応答を受信するのを待っている。図１８の例は、ステップＳ７０２でのタイムアウト処理の具体例の一つである。
【０５１５】
図１８の例では、通信処理部３３０は、例えばＴＣＰ／ＩＰプロトコルスタックの標準ライブラリにより実装され、具体的には、ＴＣＰモジュール、ＩＰモジュール、ＡＲＰモジュールなどを含む。そして、通信処理部３３０のＴＣＰモジュールは、監視部３６０またはその他のモジュール（例えば取得制御部３５２など）からデータセグメントの送信を指示されると、データセグメントを送信する。その後、通信処理部３３０のＴＣＰモジュールは、送信したデータセグメントに対するＡＣＫセグメントの受信を待つ。
【０５１６】
もし、所定時間以内にＡＣＫセグメントが受信されなければ、通信処理部３３０のＴＣＰモジュールは、データセグメントの再送を試みる。なお、ここでの「所定時間」は、具体的には、図１４の時間ＴＯ＿ｐｒｏｐ、図１４と図１５の時間ＴＯ＿ｂｕｌｋ、図１４の時間ＴＯ＿ａｓｓｉｇｎ、および図１５の時間ＴＯ＿ｋｅｅｐａｌｉｖｅのどれよりも短くてもよい。また、ＡＣＫセグメントは、もちろんピギーバックＡＣＫセグメントであってもよい。
【０５１７】
通信処理部３３０のＴＣＰモジュールは、所定のリトライ回数（例えば３回）までは、上記のようにしてデータセグメントの再送を試みてもよい。上記のようにして通信処理部３３０のＴＣＰモジュールによりトランスポート層で行われる再送制御には、監視部３６０またはその他のアプリケーション層のモジュールは関与しなくてもよい。なお、紙幅の都合上、図１８ではＴＣＰモジュールによる再送は省略されている。
【０５１８】
もし、通信処理部３３０のＴＣＰモジュールが上記の所定のリトライ回数だけ再送を試みてもＡＣＫセグメントが受信されない場合、通信処理部３３０のＴＣＰモジュールは、以下のように動作してもよく、以下に説明する動作が図１８に例示されている。
【０５１９】
すなわち、ＴＣＰモジュールは、ＴＣＰコネクションの切断を認識して、ＴＣＰコネクションをクローズする。また、ＴＣＰモジュールは、ＩＰモジュールを介して間接的に、あるいは直接的に、ＡＲＰモジュールに異常を通知する。なお、異常の通知は、切断されたＴＣＰコネクションで使われている宛先ＩＰアドレス（すなわち、図１８の例では「１９２．１６８．２５４．３」）を含む。
【０５２０】
すると、異常の通知を受けたＡＲＰモジュールは、通知された宛先ＩＰアドレスに対応するエントリ（すなわち、図１８の例ではＡＲＰエントリ７０６）を、ＡＲＰテーブル３３１から強制的に削除する。一方で、ＴＣＰモジュールは、ＴＣＰコネクションの再確立を試みる。
【０５２１】
図１８の例では、ノードＮ１２の通信処理部３３０のＴＣＰモジュールは、（１８−１）と（１８−２）の通信端点間のＴＣＰコネクションの再確立を試みる。
（１８−１）ノードＮ１２の監視部３６０が監視に用いる通信端点（つまりノードＮ１２の固定ＩＰアドレスと所定のポート番号により識別される通信端点）
（１８−２）「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される通信端点
【０５２２】
具体的には、ＴＣＰモジュールは、まずＳＹＮセグメントを送信しようとする。そして、ＳＹＮセグメントの宛先ＩＰアドレスは、（１８−２）のとおり「１９２．１６８．２５４．３」である。また、上記のとおり、異常の通知にともなって、ＡＲＰエントリ７０６は既に強制的に削除されている。
【０５２３】
したがって、ＳＹＮセグメントの送信のために図９の処理が呼び出されると、ステップＳ１０２の検索の結果、エントリが見つからない。そのため、ステップＳ１０５でＡＲＰ要求がブロードキャストされる。
【０５２４】
このステップＳ１０５でのブロードキャストが、図１８にはステップＳ１００３として示されている。すなわち、ステップＳ１００３でブロードキャストされるＡＲＰ要求７０８には、ＴＰＡとして「１９２．１６８．２５４．３」というＩＰアドレスが指定されている。
【０５２５】
例えば、ステップＳ１００１の「故障」が、実は「ネットワークインタフェイス３２０の交換のために一時的に陥った通信不能状態」にすぎない場合などは、ＡＲＰ要求７０８のブロードキャストによってＩＰアドレスが解決されることもある。なぜなら、ステップＳ１００３の時点ではノードＮ１３のネットワークインタフェイス３２０の交換が完了している場合があり得るからである。
【０５２６】
しかし、図１８の例では、ノードＮ１３は、ステップＳ１００１で本当に故障しているものとする。また、ノードＮ１３が修復不能であるか、または修復がステップＳ１００３の時点には間に合わないものとする。故障の種類は、例えば、ＣＰＵなどのハードウェアの異常のこともあるし、ＯＳまたはアプリケーションなどのソフトウェアの不具合のこともある。いずれにせよ、図１８の例では、故障しているノードＮ１３は、ＡＲＰ要求７０８に対するＡＲＰ応答を返すことができない。
【０５２７】
そのため、ノードＮ１２の通信処理部３３０のＡＲＰモジュールは、図９のステップＳ１０６で所定時間ＴＯ＿ａｒｐ以内にＡＲＰ応答を受信することができない。その結果、図９の処理は異常終了する。つまり、通信処理部３３０は、ＳＹＮセグメントを送信することができず、ＴＣＰコネクションを再確立することもできない。
【０５２８】
よって、通信処理部３３０は、図１５のステップＳ７０１で生存確認メッセージ７０７の送信を指示した監視部３６０に対して、異常終了を報告する。図１５のステップＳ７０２の所定時間ＴＯ＿ｋｅｅｐａｌｉｖｅは、通信処理部３３０のＴＣＰモジュールにおける再送間隔やリトライ回数などに応じて、予め適切な値に決められる。つまり、所定時間ＴＯ＿ｋｅｅｐａｌｉｖｅは、（１９−１）の時点から（１９−２）の時点までにかかる時間以上の長さに、予め設定されているものとする。
【０５２９】
（１９−１）図１５のステップＳ７０１で、監視部３６０が通信処理部３３０に生存確認メッセージ７０７の送信を指示した時点
（１９−２）以上説明した一連の処理により、通信処理部３３０が異常終了を監視部３６０に報告する時点
【０５３０】
そして、たとえ（１９−１）の時点から所定時間ＴＯ＿ｋｅｅｐａｌｉｖｅがまだ経過していなくても、監視部３６０が通信処理部３３０から異常終了の報告を受けた場合は、図１５の処理はステップＳ７０２からステップＳ７０６へと移行する。なぜなら、異常終了が通信処理部３３０から報告された場合、「たとえ所定時間ＴＯ＿ｋｅｅｐａｌｉｖｅが経過するまで待っても、監視部３６０は生存確認メッセージに対する応答を受信することができない」と見込まれるからである。
【０５３１】
すると、ノードＮ１２の取得制御部３５２は、図１５のステップＳ７０６で、「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される通信端点に対応するキー領域Ｋ３に対応する他の２つの通信端点を対応表３４０において検索する。ここで、上記（１６−３）より、対応表３４０は図８の対応表６０１のとおりである。よって、検索の結果、「１９２．１６８．２５４．１９：７０００」と「１９２．１６８．２５４．３５：７０００」という通信端点情報でそれぞれ識別される通信端点が見つかる。そして、図１８の例では、以下の（２０−１）〜（２０−４）のとおり想定する。
【０５３２】
（２０−１）ノードＮ１２においてキー領域Ｋ３に対応するキー領域管理部は、図５のキー領域管理部３５０ｃである。そして、図１５のステップＳ７０８でノードＮ１２のキー領域管理部３５０ｃの取得制御部３５２は、「１９２．１６８．２５４．１９：７０００」という通信端点情報で識別される通信端点を選ぶ。
（２０−２）上記（２０−１）での選択がなされた時点において、「１９２．１６８．２５４．１９」というＩＰアドレスは、ノードＮ１４のネットワークインタフェイス３２０に割り当てられている。
（２０−３）上記（２０−１）での選択がなされた時点において、選択通信端点と、ノードＮ１２の監視部３６０が監視を行うための上記（１８−１）の通信端点との間には、ＴＣＰコネクションが存在しない。
（２０−４）上記（２０−１）での選択がなされた時点において、ノードＮ１２のＡＲＰテーブル３３１には、「１９２．１６８．２５４．１９」というＩＰアドレスについてのエントリが存在しない。
【０５３３】
以上の（２０−１）〜（２０−４）の想定によれば、ノードＮ１２のキー領域管理部３５０ｃの取得制御部３５２は、（２０−１）で選択した通信端点に対して、図１５のステップＳ７０８で、キー領域Ｋ３の全データを要求する。つまり、取得制御部３５２は、ステップＳ７０８でコピー要求を生成し、生成したコピー要求を送信するよう通信処理部３３０に指示する。
【０５３４】
すると、通信処理部３３０はコピー要求のデータセグメントを送信しようとする。しかし、上記（２０−３）の想定より、ＴＣＰコネクションが存在しない。そこで、通信処理部３３０は、まずＳＹＮセグメントを送信してＴＣＰコネクションを確立しようとする。
【０５３５】
そして、通信処理部３３０は、ＳＹＮセグメントの送信のために図９の処理を開始する。すると、上記（２０−４）の想定より、図９のステップＳ１０２ではエントリが見つからない。したがって、ステップＳ１０５でＡＲＰ要求がブロードキャストされる。
【０５３６】
図１８には、このステップＳ１０５がステップＳ１００４として表されている。すなわち、ステップＳ１００４でブロードキャストされるＡＲＰ要求７０９には、取得制御部３５２が（２０−１）で選択した「１９２．１６８．２５４．１９」というＩＰアドレスがＴＰＡとして指定されている。
【０５３７】
図３のブロードキャストドメイン２００に属する各装置は、ＡＲＰ要求７０９を受信すると図１０にしたがって動作する。よって、上記（２０−２）の想定より、ノードＮ１４から図１０のステップＳ２０４でＡＲＰ応答が返される。
【０５３８】
図１８には、このステップＳ２０４がステップＳ１００５として表されている。すなわち、ステップＳ１００５で送信されるＡＲＰ応答７１０には、ＳＨＡとして、ノードＮ１４のネットワークインタフェイス３２０のＭＡＣアドレスである「００−２３−２６−１７−Ｆ３−Ｂ９」が指定されている。
【０５３９】
そして、ステップＳ１００４からステップＳ１００５までの時間は、図９の所定時間ＴＯ＿ａｒｐ以下の長さである。したがって、ＡＲＰ応答７１０を受信したノードＮ１２の通信処理部３３０は、図９のステップＳ１０７でＡＲＰテーブル３３１を更新する。すなわち、図１８のステップＳ１００６に示すように、ノードＮ１２の通信処理部３３０は、ＡＲＰテーブル３３１にＡＲＰエントリ７１１を追加する。ＡＲＰエントリ７１１は、「１９２．１６８．２５４．１９」というＩＰアドレスと「００−２３−２６−１７−Ｆ３−Ｂ９」というＭＡＣアドレスを対応づけている。
【０５４０】
すると、ノードＮ１２の通信処理部３３０は再度図９のステップＳ１０２でＡＲＰテーブル３３１を検索する。その結果、今度はＡＲＰエントリ７１１が見つかるので、ステップＳ１０４でＳＹＮセグメントが送信される。
【０５４１】
ここで、説明の簡単化のため、ノードＮ１４は正常に動作しているとする。すると、ＳＹＮセグメントを受信したノードＮ１４の通信処理部３３０は、ＳＹＮ／ＡＣＫセグメントを送信する。その結果、ノードＮ１２の通信処理部３３０は、ＳＹＮ／ＡＣＫセグメントを受信し、ＡＣＫセグメントを送信する。そして、ノードＮ１４の通信処理部３３０はＡＣＫセグメントを受信する。
【０５４２】
以上の３ウェイハンドシェイクにより、「１９２．１６８．２５４．１９：７０００」という通信端点情報で識別される選択通信端点と、ノードＮ１２上の上記（１８−１）の通信端点との間に、ＴＣＰコネクションが確立する。図１８では、以上の３ウェイハンドシェイクがステップＳ１００７として表されている。
【０５４３】
その後、ノードＮ１２の通信処理部３３０は、図１５のステップＳ７０８で取得制御部３５２から送信するよう指示されたコピー要求のデータセグメントを、確立したＴＣＰコネクション上で送信する。このコピー要求の送信は、図１５ではステップＳ７０８に相当し、図１８ではステップＳ１００８として表されている。
【０５４４】
すなわち、図１８に示すとおり、ステップＳ１００８で送信されるコピー要求７１２には、ノードＮ１２がデータを要求する対象のキー領域Ｋ３を識別する「３」というインデックスが指定されている。なお、コピー要求では、キー領域Ｋ３を識別する情報として、インデックスの代わりに、宛先ＩＰアドレスそのものが使われてもよい。なぜなら、宛先ＩＰアドレスである「１９２．１６８．２５４．１９」はキー領域Ｋ３に静的に対応づけられているからである。
【０５４５】
そして、ノードＮ１２においてキー領域Ｋ３に対応する（つまり「１９２．１６８．２５４．１９：７０００」という通信端点情報に対応する）キー領域管理部３５０ｃの取得制御部３５２は、コピー要求７１２に対する応答の受信を待つ。図１８の例では、ステップＳ１００９に示すように、コピー要求７１２に対するコピー応答７１３が送信される。より具体的には、図１５のステップＳ７０８での送信指示から所定時間ＴＯ＿ｂｕｌｋ以内に、ノードＮ１２のキー領域管理部３５０ｃの取得制御部３５２は、コピー応答７１３を受信する。コピー応答７１３は、コピー要求７１２で指定されたキー領域Ｋ３にキーが属する全エントリのデータを含む。
【０５４６】
コピー応答７１３の受信後、ノードＮ１２のキー領域管理部３５０ｃの取得制御部３５２は、コピー応答７１３のデータを、図１５のステップＳ７１０でローカルストア３１０に保存する。
【０５４７】
そして、次のステップＳ７１１でノードＮ１２のキー領域管理部３５０ｃの取得制御部３５２は、対象通信端点のＩＰアドレスを、ノードＮ１２のネットワークインタフェイス３２０に割り当てるよう、対応づけ部３５４に指示する。その結果、ノードＮ１２の監視部３６０が故障を検出したノードＮ１３に今まで割り当てられていた「１９２．１６８．２５４．３」というＩＰアドレスは、新たに、ノードＮ１２のネットワークインタフェイス３２０に割り当てられる。このステップＳ７１１での割り当てが、図１８ではステップＳ１０１０として表されている。
【０５４８】
また、図１５のステップＳ７１２でノードＮ１２のキー領域管理部３５０ｃの監視依頼部３５５は、「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される対象通信端点の監視を１つ以上の他のノードに要求する。そして、ステップＳ７１３でノードＮ１２の監視部３６０は、対象通信端点を対象ノードリスト３６１から除外する。
【０５４９】
したがって、たとえキー領域Ｋ３を「第１通信端点」として担当していたノードＮ１３が図１８のステップＳ１００１のように故障しても、キー領域Ｋ３に関するノードＮ１３の機能をノードＮ１２が引き継ぐ。つまり、ノードＮ１２は、新たにキー領域Ｋ３を「第１通信端点」として担当するようになる。よって、分散ＤＢシステム全体としては、フェイルオーバ機能が実現される。
【０５５０】
また、故障したノードＮ１３は、キー領域Ｋ３以外のキー領域をさらに担当していたかもしれない。例えば、ノードＮ１３は、ステップＳ１００１で故障した時点において、キー領域Ｋ３を「第１通信端点」として担当するとともに、キー領域Ｋ１５を「第２通信端点」として担当していたかもしれない。
【０５５１】
その場合、キー領域Ｋ１５に関するノードＮ１３の機能は、キー領域Ｋ１５の「第２通信端点」（すなわち、「１９２．１６８．２５４．３１：７０００」という通信端点情報で識別される通信端点）を監視する他のノードに引き継がれる。したがって、たとえ複数のキー領域を担当するノードが故障しても、各キー領域についてそれぞれフェイルオーバが行われる。
【０５５２】
続いて、図１８での引き継ぎの後に行われるＤＢアクセスについて、図１９と図２０を参照して説明する。図１９と図２０では前提条件が異なるので動作シーケンスも異なる。しかし、どちらの場合でも、クライアント２０２は、キー領域Ｋ３に属するキーを指定したＤＢアクセス要求を送信すると、キー領域Ｋ３を引き継いだノードＮ１２からＤＢアクセス応答を受信することができる。
【０５５３】
図１９は、図１８での引き継ぎ後にクライアント２０２のＡＲＰテーブル４２１が古い状態で行われるＤＢアクセスのシーケンス図である。図１９の動作シーケンスの前提条件は以下の（２１−１）〜（２１−５）のとおりである。
【０５５４】
（２１−１）図１８のステップＳ１００１でノードＮ１３が故障する前に、クライアント２０２は、キー領域Ｋ３に属するキーを指定したＤＢアクセス要求をノードＮ１３に送信して、ＤＢアクセス応答をノードＮ１３から受信した。そして、当該ＤＢアクセス要求と当該ＤＢアクセス応答の送受信は、確立済みのＴＣＰコネクション上で行われた。
（２１−２）上記（２１−１）のＴＣＰコネクションは、図１９の動作シーケンスの開始時点において、正常な手順（つまりＦＩＮ／ＡＣＫセグメントとＡＣＫセグメントの送受信を２方向のパイプそれぞれについて行う手順）によってはまだ切断されていない。
（２１−３）上記（２１−１）の通信の前には、クライアント２０２のＡＲＰテーブル４２１に図１９のＡＲＰエントリ７１４が作成された（なお、ＡＲＰエントリ７１４は、図１８でノードＮ１３の故障前にノードＮ１２が保持していたＡＲＰエントリ７０６と同じである）。
（２１−４）ＡＲＰエントリ７１４は、図１９の動作シーケンスの開始時点において、まだ削除されずにクライアント２０２のＡＲＰテーブル４２１に残っている。
（２１−５）「ｄｅｆ」というキーは、キー領域Ｋ３に属する。
【０５５５】
さて、以上の（２１−１）〜（２１−５）の仮定のもと、ステップＳ１１０１でクライアント２０２は、上記（２１−２）の既存のＴＣＰコネクション上で、リード要求７１５などのＤＢアクセス要求か、または、何らかの管理用メッセージ７１６を送信する。
【０５５６】
ここで、リード要求７１５に指定されるキーが「ｄｅｆ」であるとする。この場合、上記（２１−５）の仮定より、クライアント２０２のＤＢ要求処理部４３０が図１１のステップＳ３０１で見つける「第１通信端点」は、図８の対応表６０１によれば「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される。よって、リード要求７１５において、宛先ＩＰアドレスは「１９２．１６８．２５４．３」であり、宛先ポート番号は「７０００」である。
【０５５７】
また、管理用メッセージ７１６の内容は任意であるが、管理用メッセージ７１６の宛先ＩＰアドレスも「１９２．１６８．２５４．３」である。そして、（２１−２）の仮定より、クライアント２０２の通信処理部４２０は、図１９の処理の開始時点ではまだ（２１−１）のＴＣＰコネクションが切断されたことを認識していない。よって、通信処理部４２０は、改めて「ＳＹＮセグメントを送信する」などの処理をすることなく、（２１−１）のＴＣＰコネクション上でリード要求７１５または管理用メッセージ７１６のデータセグメントを送信しようとする。その結果、図９の処理が呼び出される。
【０５５８】
そして、図９のステップＳ１０２でクライアント２０２の通信処理部４２０がＡＲＰテーブル４２１を検索すると、上記（２１−４）の仮定より、ＡＲＰエントリ７１４が見つかる。その結果、リード要求７１５と管理用メッセージ７１６のいずれにも、宛先ＭＡＣアドレスとして「００−２３−２６−０２−Ｃ６−Ｄ７」というＭＡＣアドレスが指定される。
【０５５９】
こうしてリード要求７１５または管理用メッセージ７１６のフレームが、図９のステップＳ１０４に相当する図１９のステップＳ１１０１において、クライアント２０２の通信処理部４２０から送信される。ところが、ステップＳ１１０１の時点でノードＮ１３は故障しているので、リード要求７１５または管理用メッセージ７１６に対する応答は返されない。
【０５６０】
また、仮に例えば管理者がノードＮ１３を故障から復旧させたと仮定し、正常な状態に復旧したノードＮ１３がリード要求７１５または管理用メッセージ７１６を受信したとしても、応答は返されない。理由は以下のとおりである。
【０５６１】
復旧したノードＮ１３の通信処理部３３０は、ノードＮ１３のネットワークインタフェイス３２０のＭＡＣアドレスが宛先ＭＡＣアドレスに指定されたフレームを受信するかもしれない。しかし、図１８のステップＳ１０１０で、「１９２．１６８．２５４．３」というＩＰアドレスは既にノードＮ１２のネットワークインタフェイス３２０に割り当てられている。そして、復旧直後のノードＮ１３には、図８の対応表６０１に現れる動的なＩＰアドレスは１つも割り当てられていない。ノードＮ１３が今後図１４または図１５の処理を実行することではじめて、動的なＩＰアドレスがノードＮ１３に割り当てられる。
【０５６２】
したがって、リード要求７１５または管理用メッセージ７１６は、たとえ復旧したノードＮ１３のネットワークインタフェイス３２０で受信されたとしても、ノードＮ１３の通信処理部３３０により破棄される。なぜなら、リード要求７１５または管理用メッセージ７１６の宛先ＩＰアドレスは、ノードＮ１３のネットワークインタフェイス３２０に割り当てられていないからである。
【０５６３】
よって、ノードＮ１３が故障したままであろうが既に復旧していようが、いずれにせよクライアント２０２は、リード要求７１５または管理用メッセージ７１６に対する応答を受信することができない。
【０５６４】
なお、図１１に関して説明したように、クライアント２０２の通信処理部４２０のＴＣＰモジュールは、所定時間が経ってもＡＣＫセグメントが受信されない場合には、データセグメントを再送してもよい（図１９では再送を示す矢印は省略されている）。しかし、図１９の例では、フレーム中の宛先ＭＡＣアドレスと宛先ＩＰアドレスが異なるネットワークインタフェイス３２０に対応しているので、トランスポート層での再送によっては問題が解決しない。
【０５６５】
その結果、たとえクライアント２０２の通信処理部４２０のＴＣＰモジュールが所定回数（例えば３回）の再送を繰り返したとしても、ＡＣＫセグメントは受信されない。したがって、ＴＣＰモジュールは、上記（２１−２）の既存のＴＣＰコネクションが切断されたことを認識する。そして、ＴＣＰモジュールは、コネクション切断のための適宜の処理（例えば、ＴＣＰコネクションのために使っていたＲＡＭ５０３上の領域の解放など）を行う。
【０５６６】
さらに、ＴＣＰモジュールは、ＩＰモジュールを介して間接的に、あるいは直接的に、ＡＲＰモジュールに異常を通知する。異常の通知を受けたＡＲＰモジュールは、図１９のステップＳ１１０２に示すとおり、ＡＲＰエントリ７１４を強制的にＡＲＰテーブル４２１から削除する。
【０５６７】
一方で、ＴＣＰモジュールは、ＴＣＰコネクションの再確立を試みる。すなわち、ＴＣＰモジュールは、ＴＣＰコネクションの再確立のため、まずＳＹＮセグメントを送信しようとする。ＳＹＮセグメントの宛先ＩＰアドレスは、リード要求７１５や管理用メッセージ７１６と同じく、「１９２．１６８．２５４．３」である。
【０５６８】
よって、ＳＹＮセグメントの送信のために図９の処理が開始される。そして、図１９のステップＳ１１０２での削除の結果、図９のステップＳ１０２の検索ではエントリが見つからない。したがって、図９のステップＳ１０５でＡＲＰ要求がブロードキャストされる。このステップＳ１０５が、図１９ではステップＳ１１０３として表されている。つまり、ステップＳ１１０３で送信されるＡＲＰ要求７１７には、ＴＰＡとして上記の「１９２．１６８．２５４．３」というＩＰアドレスが指定されている。
【０５６９】
図３のブロードキャストドメイン２００内の各装置は、ＡＲＰ要求７１７を受信すると、図１０にしたがって動作する。その結果、図１９のステップＳ１１０４に示すとおり、ノードＮ１２からＡＲＰ応答７１８が送信される。なぜなら、図１８のステップＳ１０１０の結果、現在「１９２．１６８．２５４．３」というＩＰアドレスはノードＮ１２のネットワークインタフェイス３２０に割り当てられているからである。
【０５７０】
ＡＲＰ応答７１８には、ＳＨＡとしてノードＮ１２のネットワークインタフェイス３２０のＭＡＣアドレスである「００−２３−２６−９Ｂ−３５−ＥＦ」が指定されている。また、ＡＲＰ応答７１８は、クライアント２０２で受信される。
【０５７１】
ＡＲＰ応答７１８の受信は、図９のステップＳ１０６に相当する。よって、図９のステップＳ１０７に示すとおり、ＡＲＰ応答７１８を受信したクライアント２０２では、ＡＲＰテーブル４２１が更新される。
【０５７２】
具体的には、図１９のステップＳ１１０５のとおり、クライアント２０２のＡＲＰテーブル４２１には、新たなＡＲＰエントリ７１９が追加される。ＡＲＰエントリ７１９は、「１９２．１６８．２５４．３」というＩＰアドレスと「００−２３−２６−９Ｂ−３５−ＥＦ」というＭＡＣアドレスを対応づけている。
【０５７３】
こうして図９のステップＳ１０７に相当する図１９のステップＳ１１０５でＡＲＰエントリ７１９が追加されると、クライアント２０２は再度図９のステップＳ１０２でＡＲＰテーブル４２１を検索する。その結果、新たに追加されたＡＲＰエントリ７１９が見つかる。
【０５７４】
したがって、図９のステップＳ１０４で、クライアント２０２の通信処理部４２０は、宛先ＩＰアドレスが「１９２．１６８．２５４．３」で宛先ポート番号が「７０００」のＳＹＮセグメントを生成する。そして、通信処理部４２０は、生成したＳＹＮセグメントを、ネットワークインタフェイス４１０を介して送信する。
【０５７５】
なお、このＳＹＮセグメントの宛先ＭＡＣアドレスは、「００−２３−２６−９Ｂ−３５−ＥＦ」である。よって、ＳＹＮセグメントは、ノードＮ１２で受信される。そして、ノードＮ１２はＳＹＮ／ＡＣＫセグメントを送信する。すると、クライアント２０２がＳＹＮ／ＡＣＫセグメントを受信し、ＡＣＫセグメントを送信する。
【０５７６】
以上のようにして、ノードＮ１２上の、「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される通信端点と、クライアント２０２上の通信端点との間に、３ウェイハンドシェイクによりＴＣＰコネクションが確立される。この３ウェイハンドシェイクは、図１９ではステップＳ１１０６の両向き矢印により表されている。
【０５７７】
そして、ステップＳ１１０６で確立したＴＣＰコネクション上で、リード要求または管理用メッセージが再送される。図１９では紙幅の都合上、ステップＳ１１０１で送信されたデータセグメントがリード要求７１５であった場合の再送についてのみ、図示してある。
【０５７８】
具体的には、クライアント２０２の通信処理部４２０は、ステップＳ１１０１での送信の契機としてＤＢ要求処理部４３０から指示されたリード要求のデータセグメントを送信するため、図９の処理を開始する。すると、図９のステップＳ１０２の検索の結果、追加されたＡＲＰエントリ７１９が見つかる。
【０５７９】
したがって、ステップＳ１０４でリード要求７２０のフレームが送信される。このステップＳ１０４が、図１９ではステップＳ１１０７として表されている。
リード要求７２０のフレームは、宛先ＭＡＣアドレスがリード要求７１５のフレームとは異なる。つまり、リード要求７２０の宛先ＭＡＣアドレスは「００−２３−２６−９Ｂ−３５−ＥＦ」である。しかし、宛先ＩＰアドレス、宛先ポート番号、サブタイプ、キーなどは、リード要求７１５と７２０で同じである。
【０５８０】
そして、リード要求７２０はノードＮ１２で受信される。すると、ノードＮ１２は図１３にしたがって動作する。その結果、図１３のステップＳ５０４に相当する図１９のステップＳ１１０８において、指定された「ｄｅｆ」というキーに対応する「ＤＥＦ」というバリューを含むリード応答７２１が、ノードＮ１２からクライアント２０２に送信される。
【０５８１】
リード応答７２１は、クライアント２０２のネットワークインタフェイス４１０で受信され、ＤＢ要求処理部４３０に出力される。そして、図１１の所定時間ＴＯ＿ｄｂは、以下の（２２−１）の時点から（２２−２）の時点までにかかる時間以上の長さとなるように、予め決められている。
【０５８２】
（２２−１）リード要求７１５の送信をＤＢ要求処理部４３０が通信処理部４２０に指示した時点
（２２−２）通信処理部４２０を介してＤＢ要求処理部４３０がリード応答７２１を受信する時点
【０５８３】
換言すれば、図１９のような処理が行われた場合に上記（２２−１）から（２２−２）までにかかる時間が、下記（２３−１）〜（２３−２）などに基づいて予め見積もられる。そして、見積もりの結果に基づいて、所定時間ＴＯ＿ｄｂが適宜に決められる。
【０５８４】
（２３−１）通信処理部４２０のＴＣＰモジュールにおいて、ＳＹＮセグメントとデータセグメントについてそれぞれ定められている、再送間隔やリトライ回数などの定数。
（２３−２）通信処理部４２０のＡＲＰモジュールにおいて定められている、図９の所定時間ＴＯ＿ａｒｐ
【０５８５】
したがって、クライアント２０２のＤＢ要求処理部４３０が、通信処理部４２０を介してリード応答７２１を受信すると、図１１において処理はステップＳ３０３からステップＳ３０４へと移行する。そして、ＤＢ要求処理部４３０は、リード応答７２１から得られる「ＤＥＦ」というバリューをアプリケーション４４０に返す。
【０５８６】
また、図１９では図示を省略したが、管理用メッセージが再送される場合も、ステップＳ１１０７〜Ｓ１１０８と同様である。つまり、クライアント２０２からノードＮ１２へと管理用メッセージが送信され、管理用メッセージに対する応答が、ノードＮ１２からクライアント２０２へと送信される。
【０５８７】
続いて、図１９とは異なる前提条件の場合に、図１８での引き継ぎ後に行われるＤＢアクセスの動作シーケンスについて、図２０を参照して説明する。図２０は、図１８での引き継ぎ後にクライアント２０２でＡＲＰテーブル４２１が更新されてから行われるＤＢアクセスのシーケンス図である。図２０の動作シーケンスの前提条件は以下の（２４−１）〜（２４−５）のとおりである。
【０５８８】
（２４−１）図１８のステップＳ１００１でノードＮ１３が故障する前に、クライアント２０２は、キー領域Ｋ３に属するキーを指定したＤＢアクセス要求をノードＮ１３に送信して、ＤＢアクセス応答をノードＮ１３から受信した。そして、当該ＤＢアクセス要求と当該ＤＢアクセス応答の送受信は、確立済みのＴＣＰコネクション上で行われた。
（２４−２）しかし、上記（２４−１）のＴＣＰコネクションは、何らかの理由により、図１８のステップＳ１００１より前に、正常な手順によりクローズされた。例えば、アプリケーション４４０が一旦終了する場合、アプリケーション４４０用に使われていたＴＣＰコネクションをクローズする処理を、ＤＢ要求処理部４３０が行ってもよい。
（２４−３）上記（２４−１）の通信の前には、クライアント２０２のＡＲＰテーブル４２１に、図１９と同じＡＲＰエントリ７１４が作成された。
（２４−４）ＡＲＰエントリ７１４は、図２０の動作シーケンスの開始時点において、まだ削除されずにクライアント２０２のＡＲＰテーブル４２１に残っている。
（２４−５）「ｄｅｆ」というキーは、キー領域Ｋ３に属する。
【０５８９】
さて、上記（２４−４）のとおり、クライアント２０２のＡＲＰテーブル４２１にはＡＲＰエントリ７１４がある。しかし、例えばアプリケーション４４０が一旦終了するなどの理由により、しばらくの間ＡＲＰエントリ７１４が使われないと、図２０のステップＳ１２０１に示すように、ＡＲＰエントリ７１４は消滅する。なぜなら、通信処理部４２０はＡＲＰテーブル４２１の各エントリについてエージング処理を行うからである。
【０５９０】
そして、ＡＲＰエントリ７１４が消滅した後で、クライアント２０２のアプリケーション４４０が再び起動されることがある。さらに、アプリケーション４４０がＤＢ要求処理部４３０に対して、「ｄｅｆ」というキーを指定してリード操作を行うよう指示することがある。すると、ＤＢ要求処理部４３０は図１１の処理を開始する。
【０５９１】
以降の処理の流れは、図１７のステップＳ９０１〜Ｓ９０６と同様である。つまり、図１７のステップＳ９０１〜Ｓ９０６と図２０のステップＳ１２０２〜Ｓ１２０７の違いは、アプリケーション４４０により指定されるキーと、キーに応じて異なる情報の具体的な値のみである。
【０５９２】
そこで、ステップＳ１２０２〜Ｓ１２０７については簡単に説明する。まず、図１１の処理が開始されると、ステップＳ３０１で、「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される「第１通信端点」が特定される。
【０５９３】
そして、ステップＳ３０２でＤＢ要求処理部４３０は通信処理部４２０にリード要求の送信を指示する。しかし、（２４−２）の仮定よりＴＣＰコネクションが存在しない。よって、通信処理部４２０は、まずＳＹＮセグメントを送信しようとする。
【０５９４】
そして、ＳＹＮセグメントの送信のために図９の処理が呼び出される。ここで、ＡＲＰエントリ７１４は図２０のステップＳ１２０１で既に消滅しているので、図９のステップＳ１０２の検索ではエントリが見つからない。よって、ステップＳ１０５でＡＲＰ要求がブロードキャストされる。
【０５９５】
このステップＳ１０５は図２０のステップＳ１２０２に相当する。また、ステップＳ１２０２でブロードキャストされるＡＲＰ要求７２２には、ＴＰＡとして「１９２．１６８．２５４．３」というＩＰアドレスが指定されている。
【０５９６】
また、図１８の処理の結果として、現在は、ノードＮ１２のネットワークインタフェイス３２０に「１９２．１６８．２５４．３」というＩＰアドレスが割り当てられている。したがって、図２０のステップＳ１２０３に示すとおり、ノードＮ１２からＡＲＰ応答７２３が返される。ＡＲＰ応答７２３にはＳＨＡとして、ノードＮ１２のＭＡＣアドレスである「００−２３−２６−９Ｂ−３５−ＥＦ」が指定されている。
【０５９７】
すると、クライアント２０２がＡＲＰ応答７２３を受信し、図９のステップＳ１０７のとおりＡＲＰテーブル４２１を更新する。このステップＳ１０７は図２０ではステップＳ１２０４として表されており、具体的にはＡＲＰエントリ７２４がＡＲＰテーブル４２１に追加される。ＡＲＰエントリ７２４は、「１９２．１６８．２５４．３」というＩＰアドレスと「００−２３−２６−９Ｂ−３５−ＥＦ」というＭＡＣアドレスを対応づけている。
【０５９８】
通信処理部４２０は、ＡＲＰエントリ７２４を参照し、ネットワークインタフェイス４１０を介してＳＹＮセグメントを送信する。その後、ノードＮ１２がＳＹＮ／ＡＣＫセグメントを送信し、クライアント２０２はＡＣＫセグメントを送信する。以上の３ウェイハンドシェイクが、図２０ではステップＳ１２０５の両向き矢印により表されている。
【０５９９】
そして、ステップＳ１２０５で確立したＴＣＰコネクション上で、次のステップＳ１２０６に示すように、クライアント２０２のＤＢ要求処理部４３０はリード要求７２５を送信する。リード要求７２５の内容は図１９のリード要求７２０と同様である。
【０６００】
すると、リード要求７２５を受信したノードＮ１２は図１３にしたがって動作し、図２０のステップＳ１２０７に示すように、リード要求７２６を返す。リード要求７２６には、リード要求７２５で指定されている「ｄｅｆ」というキーに対応する「ＤＥＦ」というバリューが含まれる。「ＤＥＦ」というバリューは、リード応答７２６を受信したＤＢ要求処理部４３０により、図１１のステップＳ３０４においてアプリケーション４４０に返される。
【０６０１】
以上、図１９〜２０を参照して説明したとおり、ある通信端点に対応する物理的なノードが変化した後も、クライアント２０２は、ＡＲＰテーブル４２１に古いＡＲＰエントリが残っているか否かに関わらず、当該通信端点との間で通信を行うことができる。
【０６０２】
続いて、図１８の引き継ぎが行われた後に、図３のブロードキャストドメイン２００に新たなノードＮ１９が追加された場合の動作を、図２１と図２２を参照して説明する。
図２１は、新規ノードの追加にともなう引き継ぎのシーケンス図である。
【０６０３】
まず、ステップＳ１３０１で新たなノードＮ１９が追加される。ノードＮ１９は、具体的には例えば図７のコンピュータ５００により実現されてもよい。ステップＳ１３０１では、単にノードＮ１９のハードウェアが分散ＤＢシステムに追加されるだけでなく、以下の（２５−１）〜（２５−３）のような作業も行われる。
【０６０４】
（２５−１）ＯＳのインストール
（２５−２）ハードウェアとしてのコンピュータ５００を、図５のノード３００のように構成された分散ＤＢシステム内のノードＮ１９として動作させるための、プログラムやデータのインストール
（２５−３）保守用の固定的なＩＰアドレス（以下では説明の便宜上、「１９２．１６８．２５４．１３６」とする）の、ネットワークインタフェイス３２０への割り当て
【０６０５】
なお、（２５−１）でインストールされるＯＳの中には、図９と図１０の処理をＣＰＵ５０１に実行させ、ＣＰＵ５０１を通信処理部３３０として機能させるためのプログラムモジュールが含まれていてもよい。ＯＳだけでなく、イーサネットドライバなどのデバイスドライバも、必要に応じてインストールされる。
【０６０６】
また、（２５−２）でインストールされるデータの例は、図５の対応表３４０である。そして、（２５−２）でインストールされるプログラムの例は、図１３〜１６の処理の処理をＣＰＵ５０１に実行させ、ＣＰＵ５０１をキー領域管理部３５０ａ〜３５０ｃや監視部３６０として機能させるためのプログラムである。
【０６０７】
また、（２５−１）〜（２５−３）の作業は、システム管理者が手動で行ってもよいし、図３のデプロイサーバ２０１が自動的に行ってもよい。いずれにせよ、ステップＳ１３０１においては、ノードＮ１９は、まだどのキー領域も担当していない。したがって、図８の対応表６０１に現れるどのＩＰアドレスも、まだノードＮ１９のネットワークインタフェイス３２０には割り当てられていない。
【０６０８】
ステップＳ１３０１で追加されたノードＮ１９は、図１４の処理を開始する。図２１の例においては、ノードＮ１９が図１４のステップＳ６０１で、「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される通信端点をランダムに選び出したものとする。すると、ステップＳ６０２でノードＮ１９は引き継ぎ提案を送信しようとする。
【０６０９】
しかし、ノードＮ１９は追加されたばかりなので、ノードＮ１９と他の装置の間にはまだＴＣＰコネクションが存在しない。また、ノードＮ１９のＡＲＰテーブル３３１には、対応表３４０に現れるＩＰアドレスについてのエントリがまだ１つもない。
【０６１０】
よって、ノードＮ１９の通信処理部３３０はまず、（２６−１）と（２６−２）の通信端点間にＴＣＰコネクションを確立しようとする。
【０６１１】
（２６−１）上記（２５−３）の「１９２．１６８．２５４．１３６」という固定的なＩＰアドレスを含む、「１９２．１６８．２５４．１３６：７０００」という通信端点情報により識別される、ノードＮ１９上の通信端点
（２６−２）「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される、選択通信端点
【０６１２】
そして、ノードＮ１９の通信処理部３３０は、ＴＣＰコネクションの確立のため、ＳＹＮセグメントを送信しようとし、図９の処理を開始する。ところが上記のとおり、ノードＮ１９のＡＲＰテーブル３３１には、まだ「１９２．１６８．２５４．３」というＩＰアドレスについてのエントリがない。よって、図９のステップＳ１０２の検索ではエントリが見つからない。
【０６１３】
そこで、ステップＳ１０５で通信処理部３３０はＡＲＰ要求をブロードキャストする。このステップＳ１０５が図２１ではステップＳ１３０２として表されている。ステップＳ１３０２でブロードキャストされるＡＲＰ要求７２７には、ＴＰＡとして「１９２．１６８．２５４．３」というＩＰアドレスが指定されている。
【０６１４】
図３のブロードキャストドメイン２００内の各装置は、ＡＲＰ要求７２７を受信すると、図１０にしたがって動作する。また、図１８の引き継ぎの結果として、ステップＳ１３０２の時点で「１９２．１６８．２５４．３」というＩＰアドレスは、ノードＮ１２のネットワークインタフェイス３２０に割り当てられている。
【０６１５】
したがって、図２１にステップＳ１３０３として示すように、ノードＮ１２からＡＲＰ応答７２８が送信される。ＡＲＰ応答７２８には、ノードＮ１２のネットワークインタフェイス３２０のＭＡＣアドレスである「００−２３−２６−９Ｂ−３５−ＥＦ」がＳＨＡとして指定されている。
【０６１６】
そして、ＡＲＰ応答７２８を受信したノードＮ１９の通信処理部３３０は、図９のステップＳ１０７でＡＲＰテーブル３３１を更新する。具体的には、ノードＮ１９の通信処理部３３０は、図２１のステップＳ１３０４に示すとおり、ＡＲＰエントリ７２９をＡＲＰテーブル３３１に追加する。ＡＲＰエントリ７２９は、「１９２．１６８．２５４．３」というＩＰアドレスと「００−２３−２６−９Ｂ−３５−ＥＦ」というＭＡＣアドレスを対応づけている。
【０６１７】
すると、ノードＮ１９の通信処理部３３０は再度図９のステップＳ１０２でＡＲＰテーブル３３１を検索し、追加したＡＲＰエントリ７２９を見つける。よって、ステップＳ１０４でＳＹＮセグメントのフレームが送信される。
【０６１８】
すると、ノードＮ１２の通信処理部３３０が、ＳＹＮセグメントを受信し、ＳＹＮ／ＡＣＫセグメントを送信する。そして、ノードＮ１９の通信処理部３３０が、ＳＹＮ／ＡＣＫセグメントを受信し、ＡＣＫセグメントを送信する。以上の３ウェイハンドシェイクの結果、図２１にステップＳ１３０５として示すように、ノードＮ１９上の上記（２６−１）の通信端点と、ノードＮ１２上の上記（２６−２）の通信端点の間にＴＣＰコネクションが確立する。
【０６１９】
そして、ステップＳ１３０５で確立したＴＣＰコネクション上で、図１４のステップＳ６０２の引き継ぎ提案が送信される。具体的には、図２１にステップＳ１３０６として示すように、引き継ぎ提案７３０がノードＮ１９からノードＮ１２へ送信される。ノードＮ１９は、引き継ぎ提案７３０の送信により、「宛先ＩＰアドレスである『１９２．１６８．２５４．３』と宛先ポート番号である『７０００』により識別される通信端点を、ノードＮ１２からノードＮ１９が引き継ぐこと」をノードＮ１２に提案している。
【０６２０】
そして、図２１の例では、引き継ぎ提案７３０を受信したノードＮ１２が、引き継ぎ提案７３０に対してステップＳ１３０７でＡＣＫ応答７３１を返す。より詳しくは、ノードＮ１２において、キー領域Ｋ３の「第１通信端点」のＩＰアドレスである「１９２．１６８．２５４．３」に対応するキー領域管理部内の、供給制御部３５３が、ＡＣＫ応答７３１を返す。
【０６２１】
すると、ノードＮ１９の通信処理部３３０は、ＡＣＫ応答７３１を受信する。そして、ノードＮ１９は、キー領域Ｋ３に対応する（より詳しくは、「１９２．１６８．２５４．３」というＩＰアドレスに対応する）キー領域管理部を新たに生成し、図１４の処理はステップＳ６０５へと進む。
【０６２２】
なお、以下では説明の便宜上、図５のキー領域管理部３５０ａが上記のようにしてノードＮ１９内に新たに生成されたものとする。ノードＮ１９には、まだ１つのキー領域管理部３５０ａしかない。
【０６２３】
さて、ノードＮ１９内に生成されたキー領域管理部３５０ａの取得制御部３５２が、図１４のステップＳ６０５で、ノードＮ１２上の上記（２６−２）の通信端点に対して、引き継ぎ要求を送信する。このステップＳ６０５が図２１ではステップＳ１３０８として表されている。
【０６２４】
ステップＳ１３０８で送信される引き継ぎ要求７３２は、例えば図２１に示すように、引き継ぎ対象のキー領域Ｋ３を識別する「３」というインデックスを含んでもよい。あるいは、キー領域Ｋ３は、引き継ぎ要求７３２の宛先ＩＰアドレスである「１９２．１６８．２５４．３」自体によっても識別することができるので、引き継ぎ要求７３２はインデックスを含まなくてもよい。
【０６２５】
いずれにしろ、ノードＮ１２は、引き継ぎ要求７３２を受信すると図２１のステップＳ１３０９に示すように、引き継ぎ応答７３３を返す。引き継ぎ応答７３３は、ノードＮ１２のローカルストア３１０から読み出されてコピーされた、キー領域Ｋ３にキーが属する全エントリのデータを含む。
【０６２６】
なお、以上の引き継ぎ提案７３０、ＡＣＫ応答７３１、引き継ぎ要求７３２、および引き継ぎ応答７３３はすべて、ステップＳ１３０５で確立されたＴＣＰコネクション上で送受信される。
【０６２７】
ノードＮ１９のキー領域管理部３５０ａの取得制御部３５２は、通信処理部３３０を介して引き継ぎ応答７３３を受信すると、図１４のステップＳ６０７において、引き継ぎ応答７３３に含まれる全エントリのデータをローカルストア３１０に保存する。
【０６２８】
一方、引き継ぎ応答７３３を送信し終わったノードＮ１２では、ＴＣＰコネクションをクローズするための処理が開始される。なお以下では、図１８に関する（２０−１）の仮定と同様に、便宜上、ノードＮ１２においてキー領域Ｋ３に対応する（換言すれば「１９２．１６８．２５４．３」というＩＰアドレスに対応する）キー領域管理部が、図５のキー領域管理部３５０ｃであるとする。
【０６２９】
ノードＮ１２のキー領域管理部３５０ｃの供給制御部３５３は、通信処理部３３０に対して、引き継ぎ応答７３３の送信に用いたＴＣＰコネクションをクローズするよう指示する。すると、ノードＮ１２の通信処理部３３０は、ＦＩＮ／ＡＣＫセグメントを送信する。そして、ノードＮ１９の通信処理部３３０は、ＦＩＮ／ＡＣＫセグメントを受信すると、ノードＮ１２にＡＣＫセグメントを返す。
【０６３０】
また、ノードＮ１９がキー領域Ｋ３（より詳しくは、キー領域Ｋ３の「第１通信端点」）をノードＮ１２から引き継いだ後に、ノードＮ１９がノードＮ１２に送信するデータは特にない。よって、ノードＮ１９の通信処理部３３０も、ＦＩＮ／ＡＣＫセグメントを送信する。そして、ノードＮ１２の通信処理部３３０は、ＦＩＮ／ＡＣＫセグメントを受信すると、ノードＮ１９にＡＣＫセグメントを返す。ステップＳ１３０５で確立されたＴＣＰコネクションは、以上のようにして、ステップＳ１３１０でクローズされる。
【０６３１】
また、さらにステップＳ１３１１では、ノードＮ１２のキー領域管理部３５０ｃが、「１９２．１６８．２５４．３」というＩＰアドレスの、ノードＮ１２のネットワークインタフェイス３２０への割り当てを解消するための処理を行う。
【０６３２】
具体的には、キー領域管理部３５０ｃの供給制御部３５３が対応づけ部３５４に割り当て解消を指示する。すると、対応づけ部３５４は、直接インタフェイス設定ファイル３３２を書き換えるか、または「ｉｆｃｏｎｆｉｇ」コマンドなどのコマンドの発行により通信処理部３３０の機能を呼び出して、間接的にインタフェイス設定ファイル３３２を書き換える。
【０６３３】
いずれにしろ、インタフェイス設定ファイル３３２からは、下記（２７−１）と（２７−２）の対応づけが削除される。
（２７−１）ノードＮ１２のネットワークインタフェイス３２０の、「００−２３−２６−９Ｂ−３５−ＥＦ」というＭＡＣアドレス
（２７−２）今までノードＮ１２のネットワークインタフェイス３２０に割り当てられていた、「１９２．１６８．２５４．３」というＩＰアドレス
【０６３４】
そして、「１９２．１６８．２５４．３」というＩＰアドレスのネットワークインタフェイス３２０への割り当てが解消されると、次に、ステップＳ１３１２でノードＮ１２のキー領域管理部３５０ｃの供給制御部３５３は、割り当て指示７３４を送信する。具体的には、割り当て指示７３４も、通信処理部３３０とネットワークインタフェイス３２０を介して送信される。また、図２１では紙幅の都合上省略されているが、ステップＳ１３１２の処理は、固定的な２つのＩＰアドレスを用いて識別される通信端点間のＴＣＰコネクションを確立することをさらに含んでもよい。
【０６３５】
割り当て指示７３４の送信元ＩＰアドレスは、ノードＮ１２に固定的に割り当てられた「１９２．１６８．２５４．１２９」というＩＰアドレスである。そして、割り当て指示７３４の宛先ＩＰアドレスは、ノードＮ１９に固定的に割り当てられた「１９２．１６８．２５４．１３６」というＩＰアドレスである。また、送信元ポート番号は例えば「７０００」であり、宛先ポート番号も例えば「７０００」である。
【０６３６】
以上の送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、および宛先ポート番号で識別されるＴＣＰコネクションがまず確立されてもよく、当該ＴＣＰコネクション上で、割り当て指示７３４が送信されてもよい。
【０６３７】
なお、割り当て指示７３４には、宛先ＩＰアドレスで識別されるノードＮ１９に新たに割り当てる対象の「１９２．１６８．２５４．３」というＩＰアドレスが含まれる。そして、割り当て指示７３４は、ノードＮ１９において、通信処理部３３０を介してキー領域管理部３５０ａの取得制御部３５２で受信される。
【０６３８】
すると、取得制御部３５２は、割り当て指示７３４にしたがって、図１４のステップＳ６０９で、「１９２．１６８．２５４．３」というＩＰアドレスをネットワークインタフェイス３２０に割り当てるための処理を行う。つまり、取得制御部３５２は対応づけ部３５４に割り当てを指示する。すると、取得制御部３５２はインタフェイス設定ファイル３３２を直接書き換えるか、または、通信処理部３３０を介して間接的にインタフェイス設定ファイル３３２を書き換える。
【０６３９】
その結果、インタフェイス設定ファイル３３２では、ノードＮ１９のネットワークインタフェイス３２０のＭＡＣアドレスと、「１９２．１６８．２５４．３」というＩＰアドレスが対応づけられる。すなわち、「１９２．１６８．２５４．３」というＩＰアドレスが、ノードＮ１９のネットワークインタフェイス３２０に割り当てられる。
【０６４０】
以上のような図１４のステップＳ６０９の処理が、図２１ではステップＳ１３１３として表されている。また、図２１では省略されているが、ノードＮ１９のキー領域管理部３５０ａの監視依頼部３５５は、続いて図１４のステップＳ６１０の処理も行う。また、ステップＳ６１１で終了条件が満たされていなければ、ノードＮ１９は再度ステップＳ６０１から図１４の処理を繰り返す。
【０６４１】
一方、ノードＮ１２では、ステップＳ１３１１でのＩＰアドレスの割り当て解消の後、キー領域Ｋ３に対応するキー領域管理部３５０ｃは、キー領域Ｋ３に対応するエントリをローカルストア３１０から削除する。そして、キー領域管理部３５０ｃは、例えばキー領域管理部３５０ｃ自体のスレッドを終了させることにより、キー領域管理部３５０ｃ自体を消滅させる。
【０６４２】
以上の図２１の動作シーケンスによれば、ステップＳ１３１１からステップＳ１３１３までのごく短い期間は、「１９２．１６８．２５４．３」というＩＰアドレスがどのノードにも割り当てられていない。よって、もし宛先ＩＰアドレスが「１９２．１６８．２５４．３」のパケットが当該期間中に送信されると、当該パケットは廃棄されて消えてしまう。
【０６４３】
しかしながら、例えば当該パケットに対する応答についてのタイムアウト処理などが行われる過程で、ＡＲＰエントリの強制削除とＡＲＰ要求のブロードキャストなどが行われる。そして、ステップＳ１３１１からステップＳ１３１３までの時間はごくわずかなので、例えばＡＲＰ要求がブロードキャストされる時点では、既にステップＳ１３１３の割り当てが済んでいると期待される。つまり、「１９２．１６８．２５４．３」というＩＰアドレスがどのノードにも割り当てられていない期間がたとえあったとしても、分散ＤＢシステムの可用性は、実質的にはほとんど低下しない。
【０６４４】
また、図２１のステップＳ１３１１〜Ｓ１３１３の手順によれば、「１９２．１６８．２５４．３」というＩＰアドレスが同時に２つのノードＮ１２とＮ１９に割り当てられるというコンフリクトが、確実に回避される。そして、一般に、ある１つのＩＰアドレスが複数の装置に同時に割り当てられている状態は、あるＩＰアドレスがどの装置にも割り当てられていない状態よりも、好ましくない。よって、ステップＳ１３１１〜Ｓ１３１３の手順は、問題回避のために好ましい手順である。
【０６４５】
続いて、以上のようにして新規ノードＮ１９に「１９２．１６８．２５４．３」というＩＰアドレスが割り当てられた後に、新規ノードＮ１９がクライアント２０２からのＤＢアクセス要求に応答する動作シーケンスについて、図２２を参照しながら説明する。
【０６４６】
なお、図２２の動作シーケンスは、下記（２８−１）〜（２８−３）を前提とする。
【０６４７】
（２８−１）図２２の動作シーケンスの開始時点において、クライアント２０２のＡＲＰテーブル４２１は、図１９のステップＳ１１０５で作成されたＡＲＰエントリ７１９、または図２０のステップＳ１２０４で作成されたＡＲＰエントリ７２４を有する。なお、図１９と図２０に示すとおり、ＡＲＰエントリ７１９と７２４は同じ内容である。
（２８−２）図１９のステップＳ１１０６または図２０のステップＳ１２０５で確立したＴＣＰコネクションは、図２０のステップＳ１３１１でのＩＰアドレスの割り当て解消により、事実上は既に切断されている。それにもかかわらず、図２２の動作シーケンスの開始時点において、クライアント２０２の通信処理部４２０は、「図１９のステップＳ１１０６または図２０のステップＳ１２０５で確立したＴＣＰコネクションが、依然として確立した状態である」と認識している。なぜなら、クライアント２０２もノードＮ１２もＦＩＮ／ＡＣＫセグメントを送信しておらず、ＴＣＰレベルでのキープアライブ動作も本実施形態では行われないからである。そのため、図２２の動作シーケンスの開始時点において、クライアント２０２の通信処理部４２０は、まだＴＣＰコネクションの切断を認識していない。
（２８−３）「ｇｈｉ」というキーが属するキー領域は、「３」というインデックスで識別されるキー領域Ｋ３である。
【０６４８】
さて、以上の（２８−１）〜（２８−３）の前提条件のもと、まず、クライアント２０２のアプリケーション４４０が、「ｇｈｉ」というキーを指定してリード操作を行うようＤＢ要求処理部４３０に指示する。すると、ＤＢ要求処理部４３０は図１１の処理を開始する。図１１のステップＳ３０２で指定される第１通信端点とは、（２８−３）の仮定と図８によれば、具体的には「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される通信端点のことである。
【０６４９】
ＤＢ要求処理部４３０は、図１１のステップＳ３０２において、上記の第１通信端点へのリード要求の送信を通信処理部４２０に指示する。すると、通信処理部４２０は、ＴＣＰコネクションが存在するか否かを確認する。ここで（２８−２）の仮定より、通信処理部４２０は、「ＴＣＰコネクションが存在する」と認識し、確立済みのＴＣＰコネクション上でリード要求７３５を送信しようとする。リード要求７３５の送信は、図２２ではステップＳ１４０１として表されている。
【０６５０】
なお、リード要求７３５のデータセグメントの送信にあたっては、図９の処理が呼び出される。そして、（２８−１）の仮定より、図９のステップＳ１０２の検索では「１９２．１６８．２５４．３」というＩＰアドレスに対応するエントリが見つかる。よって、ステップＳ１０４では、見つかったエントリに登録されている「００−２３−２６−９Ｂ−３５−ＥＦ」というＭＡＣアドレスが、図２２に示すごとく、リード要求７３５のフレームの宛先ＭＡＣアドレスとして指定される。
【０６５１】
リード要求７３５のフレームは、宛先ＭＡＣアドレスにしたがってノードＮ１２のネットワークインタフェイス３２０で受信され、ノードＮ１２の通信処理部３３０に出力される。しかし、「００−２３−２６−９Ｂ−３５−ＥＦ」というＭＡＣアドレスで識別されるノードＮ１２のネットワークインタフェイス３２０への、「１９２．１６８．２５４．３」というＩＰアドレスの割り当ては、図２１のステップＳ１３１１で解消済みである。
【０６５２】
よって、ノードＮ１２の通信処理部３３０は「リード要求７３５の宛先ＩＰアドレスはノードＮ１２のＩＰアドレスではない」と判断し、リード要求７３５を破棄する。したがって、リード要求７３５に対する応答がクライアント２０２に返ることはない。
【０６５３】
他方、クライアント２０２のＤＢ要求処理部４３０は、図１１のステップＳ３０３に示すとおり、リード要求７３５に対する応答を受信するのを待つ。ところで、「リード要求７３５に対する応答がクライアント２０２に返されない」という状況は、「図１９のステップＳ１１０１で送信されるリード要求７１５に対する応答がクライアント２０２に返されない」という状況と類似である。
【０６５４】
したがって、詳しい説明は省略するが、図１９のステップＳ１１０１〜Ｓ１１０３の処理の流れと同様にして、図２２においても、ステップＳ１４０２でＡＲＰ要求７３６がブロードキャストされる。なお、図２２においては、クライアント２０２の通信処理部４２０のＴＣＰモジュールによる再送や、ＡＲＰエントリ７１９（またはＡＲＰエントリ７２４）の強制削除は、省略されている。
【０６５５】
ステップＳ１４０２で送信されるＡＲＰ要求７３６には、ＴＰＡとして「１９２．１６８．２５４．３」というＩＰアドレスが指定されている。そして、図３のブロードキャストドメイン２００内の各装置は、ＡＲＰ要求７３６を受信すると、図１０にしたがって動作する。
【０６５６】
その結果、図２２のステップＳ１４０３に示すとおり、ノードＮ１９からＡＲＰ応答７３７が送信される。なぜなら、図２１のステップＳ１３１３に示すとおり、「１９２．１６８．２５４．３」というＩＰアドレスは、現在ノードＮ１９のネットワークインタフェイス３２０に割り当てられているからである。
【０６５７】
ＡＲＰ応答７３７には、ＳＨＡとしてノードＮ１９のネットワークインタフェイス３２０のＭＡＣアドレスである「００−２４−Ｄ２−Ｆ０−９４−３Ａ」が指定されている。また、ＡＲＰ応答７３７は、クライアント２０２で受信される。
【０６５８】
ＡＲＰ応答７３７の受信は、図９のステップＳ１０６に相当する。よって、図９のステップＳ１０７に示すとおり、ＡＲＰ応答７３７を受信したクライアント２０２では、ＡＲＰテーブル４２１が更新される。
【０６５９】
具体的には、図２２のステップＳ１４０４のとおり、クライアント２０２のＡＲＰテーブル４２１には、新たなＡＲＰエントリ７３８が追加される。ＡＲＰエントリ７３８は、「１９２．１６８．２５４．３」というＩＰアドレスと「００−２４−Ｄ２−Ｆ０−９４−３Ａ」というＭＡＣアドレスを対応づけている。以上のようにして、古いＡＲＰエントリ７１９または７２４が、新たなＡＲＰエントリ７３８に置き換えられる。
【０６６０】
そして、上記のようにして図９のステップＳ１０７に相当する図２２のステップＳ１４０４でＡＲＰエントリ７３８が追加されると、クライアント２０２は再度図９のステップＳ１０２でＡＲＰテーブル４２１を検索する。その結果、新たに追加されたＡＲＰエントリ７３８が見つかる。
【０６６１】
また、ステップＳ１４０１からステップＳ１４０２へと至る過程は、上記では詳しい説明を省略したが、図１９のステップＳ１１０１〜Ｓ１１０３の処理の流れと同様である。よって、図１９のステップＳ１１０５でＡＲＰエントリ７１９が追加された後にステップＳ１１０６でＴＣＰコネクションが確立されるのと同様にして、図２２でも、ステップＳ１４０５でＴＣＰコネクションが確立される。
【０６６２】
具体的には、ステップＳ１４０４でＡＲＰエントリ７３８が追加された後、クライアント２０２の通信処理部４２０のＴＣＰモジュールは、「１９２．１６８．２５４．３」というＩＰアドレスを宛先ＩＰアドレスとするＳＹＮセグメントを送信する。そして、ＳＹＮセグメントはノードＮ１９で受信され、ノードＮ１９がＳＹＮ／ＡＣＫセグメントを送信する。そして、クライアント２０２はＳＹＮ／ＡＣＫセグメントを受信し、ＡＣＫセグメントを送信する。
【０６６３】
以上のようにして、ノードＮ１９上の、「１９２．１６８．２５４．３：７０００」という通信端点情報で識別される通信端点と、クライアント２０２上の通信端点との間に、３ウェイハンドシェイクによりＴＣＰコネクションが確立される。そして、以上のようにしてステップＳ１４０５で確立したＴＣＰコネクション上で、リード要求が再送される。
【０６６４】
具体的には、クライアント２０２の通信処理部４２０は、ステップＳ１４０１での送信の契機としてＤＢ要求処理部４３０から指示されたリード要求のデータセグメントを送信するため、図９の処理を開始する。すると、図９のステップＳ１０２の検索の結果、追加されたＡＲＰエントリ７３８が見つかる。
【０６６５】
したがって、ステップＳ１０４でリード要求７３９のフレームが送信される。このステップＳ１０４が、図２２ではステップＳ１４０６として表されている。
リード要求７３９のフレームは、宛先ＭＡＣアドレスがリード要求７３５のフレームとは異なる。つまり、リード要求７３９の宛先ＭＡＣアドレスは「００−２４−Ｄ２−Ｆ０−９４−３Ａ」である。しかし、宛先ＩＰアドレス、宛先ポート番号、サブタイプ、キーなどは、リード要求７３５と７３９で同じである。
【０６６６】
そして、リード要求７３９はノードＮ１９で受信される。すると、ノードＮ１９は図１３にしたがって動作する。その結果、図１３のステップＳ５０４に相当する図２２のステップＳ１４０７において、指定された「ｇｈｉ」というキーに対応する「ＧＨＩ」というバリューを含むリード応答７４０が、ノードＮ１９からクライアント２０２に送信される。
【０６６７】
リード応答７４０は、クライアント２０２のネットワークインタフェイス４１０で受信され、通信処理部４２０を介してＤＢ要求処理部４３０に出力される。また、図１１の所定時間ＴＯ＿ｄｂは、図１９に関して説明したように、上記（２３−１）〜（２３−２）などの定数に基づいて、予め適切な長さに決められている。したがって、クライアント２０２のＤＢ要求処理部４３０は、所定時間ＴＯ＿ｄｂ以内にリード応答７４０を受信することができる。よって、クライアント２０２における図１１の処理はステップＳ３０３からステップＳ３０４へと移行する。そして、ＤＢ要求処理部４３０は、リード応答７４０から得られる「ＧＨＩ」というバリューをアプリケーション４４０に返す。
【０６６８】
以上、いくつかの具体的な条件下での分散ＤＢシステム全体の振る舞いについて図１７〜２２を参照して説明したが、図９〜１６のフローチャートによれば、他の条件下でも同様に分散ＤＢシステムがうまく動作することは明らかであろう。
【０６６９】
例えば、リード要求ではなくライト要求がクライアント２０２から送信された場合も、分散ＤＢシステムはうまく動作する。また、図２１のように新たに追加されたノードＮ１９ではなく、既存のノード（例えばノードＮ１５）が、キー領域Ｋ３（より具体的には、「１９２．１６８．２５４．３」というＩＰアドレスで識別される通信端点）をノードＮ１２から引き継ぐ場合もあり得る。その場合も、図２１と同様にうまく引き継ぎが行われる。
【０６７０】
また、図１４と図１５のフローチャートには、所定時間以内に応答が受信されるか否かを判断する処理が含まれるが、所定時間の長さの定義は実施形態に応じて任意である。そして、「トランスポート層とアプリケーション層のどちらで、再送やＡＲＰエントリの強制削除が制御され、ＴＣＰコネクションの再確立のトリガがかけられるのか」ということも、実施形態に応じて任意である。図１８および図２１に関する説明は、一実装例にすぎない。
【０６７１】
また、ＴＣＰコネクションの利用の仕方も実施形態に応じて任意である。
具体的には、例えば、１回確立されたＴＣＰコネクション上で、要求と応答の送受信が複数回繰り返されてもよい。すると、クライアント２０２が何度もＤＢアクセス要求を繰り返す場合などに、ＴＣＰコネクションの確立のためのオーバヘッドの影響を小さくすることができる。
【０６７２】
しかし、実施形態によっては、ある２つの通信端点間のＴＣＰコネクションは、１つの要求と当該要求に対する応答のためだけに確立され、応答の送信後に正常の手順によりクローズされてもよい。
【０６７３】
また、図２１の例では、ステップＳ１３１１でのＩＰアドレスの割り当て解消の前に、ノードＮ１２とノードＮ１９の間のＴＣＰコネクションがステップＳ１３１０でクローズされる。しかし、実施形態によっては、さらに他のＴＣＰコネクションがステップＳ１３１１の前にクローズされてもよい。つまり、ノードＮ１２は、ノードＮ１９に委譲する「１９２．１６８．２５４．３」というＩＰアドレスを含む通信端点情報により識別される、ノードＮ１２上の通信端点と、他の装置上の通信端点との間のＴＣＰコネクションを、すべてクローズしてもよい。
【０６７４】
ところで、図１のステップＳ１からステップＳ２に至る過程は、図１４または図１５のフローチャートによる引き継ぎに対応する。換言すれば、図１８と図１９の一連の動作シーケンス、図１８と図２０の一連の動作シーケンス、および図２１と図２２の一連の動作シーケンスは、いずれも、図１に示す変化の一例である。そこで、以下では、図１と図１４〜２２との関係について説明する。
【０６７５】
図１５の対象通信端点は、換言すれば、キーの定義域Ｋ内の互いに素な複数の部分集合Ｋ０〜ＫＭ−１のいずれか１つである対象部分集合に対応づけられている２以上の通信端点情報のうちの１つにより識別される通信端点である。そして、図１５の処理は、対象通信端点を識別する通信端点情報を宛先として指定した生存確認メッセージを送信し、生存確認メッセージに対する応答を監視することを含む。また、図１５の処理は、所定時間ＴＯ＿ｋｅｅｐａｌｉｖｅ以内に応答が返ってこない場合、宛先として指定した通信端点情報と対応づけられたネットワークインタフェイスを備える第１の他のコンピュータに障害が発生していると認識することを含む。
【０６７６】
ここで、図１５の処理を図１のコンピュータ１００ｂが実行しているとする。すると、図１におけるステップＳ１からステップＳ２への変化は、「上記の対象部分集合が図１に示す特定の部分集合Ｋａであり、かつ、コンピュータ１００ｂが障害の発生を認識した」という場合の図１５のフローチャートによる引き継ぎに相当する。
【０６７７】
つまり、生存確認メッセージの宛先は、図１の通信端点情報Ｐａであり、したがって、上記の「第１の他のコンピュータ」は、監視対象としての図１のコンピュータ１００ａである。また、以下では、部分集合Ｋａに対応づけられた２以上の通信端点情報のうちで生存確認メッセージの宛先には指定されていないいずれか１つの通信端点情報と対応づけられたネットワークインタフェイスを備えるコンピュータを「第２の他のコンピュータ」という。
【０６７８】
図１のコンピュータ１００ｂは、コンピュータ１００ａにおける障害の発生を認識した場合、図１５のステップＳ７０６〜Ｓ７１０のようにして、部分集合Ｋａにキーが属する図１のエントリ１０２を取得する。つまり、コンピュータ１００ｂは、第２の他のコンピュータに、エントリ１０２を読み出して送信するように要求し、エントリ１０２を第２の他のコンピュータから受信する。例えば、図１８の例では、ノードＮ１３が「第１の他のコンピュータ」（つまり図１のコンピュータ１００ａ）に相当し、ノードＮ１２が図１のコンピュータ１００ｂに相当し、ノードＮ１４が「第２の他のコンピュータ」に相当する。
【０６７９】
また、図１４は、図１のステップＳ１の時点でコンピュータ１００ｂが存在しない場合の例である。つまり、コンピュータ１００ｂが新たに追加されて図１４の処理を行うことで、図１のステップＳ１からステップＳ２へと状況が変化する。
【０６８０】
図１４のステップＳ６０１は、コンピュータ１００ｂが、所定個数の通信端点情報のうちの１つを、図１の特定の部分集合Ｋａと対応づけられている特定の通信端点情報Ｐａとして選択することにより、特定の通信端点情報Ｐａを決定するステップに相当する。しかし、実施形態によっては、図１４の処理を実行するコンピュータ１００ｂが、通信端点情報Ｐａを指定する指示を受け取ることにより、通信端点情報Ｐａを決定してもよい。
【０６８１】
例えば、図３のデプロイサーバ２０１は、さらに、分散ＤＢシステム内の各ノードから各ノードの負荷に関する情報を収集してもよい。そして、デプロイサーバ２０１が、図１のコンピュータ１００ｂに、収集した情報に基づいて、通信端点情報Ｐａを指定する指示を与えてもよい。例えば、コンピュータ１００ａの負荷が高ければ、図１のステップＳ１においてコンピュータ１００ａのネットワークインタフェイスＩａと動的対応づけ情報１１２により対応づけられている通信端点情報Ｐａを、デプロイサーバ２０１が指定してもよい。
【０６８２】
いずれにしろ、図１の一例としての図１４では、まず、図１のステップＳ１では存在しないコンピュータ１００ｂが新たに追加され、その後、図１４のステップＳ６０１で図１のコンピュータ１００ｂが通信端点情報Ｐａを決定する。すると、コンピュータ１００ｂは、通信端点情報Ｐａと対応づけられたネットワークインタフェイスＩａを備える第３の他のコンピュータからエントリ１０２を受信することで、エントリ１０２を取得する。
【０６８３】
つまり、上記「第３のコンピュータ」は図１のコンピュータ１００ａに相当する。また、具体的にはコンピュータ１００ｂは、コンピュータ１００ａに、コンピュータ１００ａが備える記憶装置１０１ａからエントリ１０２を読み出して送信するように要求し、その結果として、上記のようにエントリ１０２を受信する。
【０６８４】
なお、図２１の例では、ノードＮ１９が図１４の処理を実行する図１のコンピュータ１００ｂに相当し、ノードＮ１２が上記の「第３の他のコンピュータ」としての図１のコンピュータ１００ａに相当する。
【０６８５】
また、図１のステップＳ２の後、コンピュータ１００ｂは、ＤＢを分散して記憶する複数の記憶装置のうちの１つを備える第４の他のコンピュータからの要求に応じて、エントリ１０２を第４の他のコンピュータに送信することもある。そして、コンピュータ１００ｂはさらに、通信端点情報Ｐａとコンピュータ１００ｂのネットワークインタフェイスＩｂとの対応づけを解除することもある。
【０６８６】
例えば、図１８の例では、上記のようにノードＮ１２が図１のコンピュータ１００ｂに相当する。そこで、図２１でもノードＮ１２が図１のコンピュータ１００ｂに相当すると見なすことにすると、図２１の例における上記の「第４の他のコンピュータ」はノードＮ１９である。そして、図２１のステップＳ１３０９の処理がエントリ１０２の送信に相当し、ステップＳ１３１１が通信端点情報ＰａとネットワークインタフェイスＩｂとの対応づけの解除に相当する。
【０６８７】
また、コンピュータ１００ｂは、対応づけを解除したことを第４の他のコンピュータに通知してもよい。図２１のステップＳ１３１２での割り当て指示７３４の送信は、対応づけを解除したことの通知でもある。なぜなら、ノードＮ１２で「１９２．１６８．２５４．３」というＩＰアドレスとネットワークインタフェイス３２０との対応づけが解除されたからこそ、ノードＮ１９のネットワークインタフェイス３２０への当該ＩＰアドレスの割り当てが可能になるからである。よって、割り当て指示７３４は、ノードＮ１２での対応づけの解除が済んだことを含意している。
【０６８８】
ところで、本発明は上記実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の観点から様々に変形することもできる。そして、上記および下記の各種変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
【０６８９】
上記実施形態におけるいくつかの処理は、閾値との比較を含む。例えば、図１４のステップＳ６０６では、図１４の処理を実行しているノード３００が応答を待っている時間が、所定時間ＴＯ＿ｂｕｌｋと比較される。閾値との比較は、実施形態により「比較対象の数値が、閾値を超えるか否か」を判断する処理でもよいし、「比較対象の数値が、閾値以上か否か」を判断する処理でもよい。
【０６９０】
また、上記の説明では、閾値や、ＩＰアドレスや、ポート番号や、ＭＡＣアドレスなどに関して、具体的な値を例示したが、これらの具体的な値は、説明の便宜上のものにすぎない。
【０６９１】
さらに、式（１）などに示したＭの値（つまりキー領域の数）も、実施形態に応じて任意である。図８の対応表６０１では図示の便宜上、Ｍ＝１６という比較的小さな数を例示したが、例えば式（８）のようにＭ＝１２８でもよい。もちろん、Ｍは、さらに大きな数でもよい。
【０６９２】
ただし、キー領域の数Ｍは、物理的なノードの数の３〜１０倍程度であることが好ましい。なぜなら、キー領域の数Ｍが少なすぎると、ノード間の負荷の偏りが大きくなるおそれがあるからである。
【０６９３】
例えば、ノードの数が１６台であるとし、図８の対応表６０１と同様に、各キー領域に対して３つの通信端点が対応づけられているものとする。そして、説明の簡単化のため、エントリ数やアクセス数は、キー領域間で偏りがほとんどないものとする。以上の想定のもとで、Ｍ＝１６の場合とＭ＝１２８の場合を比較すると、下記のとおりである。
【０６９４】
例えばＭ＝１６の場合、全部で４８（＝３Ｍ）個の通信端点が動的に１６台のノードに割り当てられる。よって、平均して各ノードが３（＝４８／１６）個のキー領域を担当する。
【０６９５】
ここで、あるノードが故障したとして、今まで３個のキー領域を担当していたノードが、故障したノードから１つの通信端点を引き継いだとする。すると、引き継ぎにより４個の通信端点を担当することになったノードの負荷は、３個の通信端点を担当している平均的な他のノードの負荷の４／３倍（つまり約１．３３倍）である。
【０６９６】
他方、Ｍ＝１２８の場合、全部で３８４（＝３Ｍ）個の通信端点が動的に１６台のノードに割り当てられる。よって、平均して各ノードが２４（＝３８４／１６）個のキー領域を担当する。
【０６９７】
ここで、あるノードが故障したとして、今まで２４個のキー領域を担当していたノードが、故障したノードから１つの通信端点を引き継いだとする。すると、引き継ぎにより２５個の通信端点を担当することになったノードの負荷は、２４個の通信端点を担当している平均的な他のノードの負荷の２５／２４倍（つまり約１．０４倍）である。
【０６９８】
以上の例からも理解されるように、キー領域の数Ｍが少ないほど、粗い粒度でノード間に負荷が分散される。よって、キー領域の数Ｍが少ないほど、ノード間に負荷の偏りが生じやすい。そこで、負荷の偏りを少なくするためには、キー領域の数Ｍは、物理的なノードの数の、例えば３〜１０倍程度であることが好ましい。
【０６９９】
ところで、上記実施形態では、生存確認メッセージは、ＤＢアクセス要求とは別の制御用メッセージである。しかし、ＤＢアクセス要求を生存確認メッセージとして利用する実施形態も可能である。
【０７００】
例えば、図１８と同様にノードＮ１２がノードＮ１３を監視する場合、ノードＮ１２は、適宜選んだキーとバリューのペアを指定したライト要求をノードＮ１３に送信し、ノードＮ１３からの応答を監視してもよい。そして、ノードＮ１２は、ノードＮ１３から所定時間以内に応答を受信することができなければ、「ノードＮ１３が故障している」と認識してもよい。
【０７０１】
ノードＮ１２は、ノードＮ１３から所定時間以内に応答を受信した場合、さらに、上記ライト要求に指定したのと同じキーを指定したリード要求をノードＮ１３に送信し、ノードＮ１３からの応答を監視してもよい。そして、ノードＮ１２は、ノードＮ１３から所定時間以内に応答を受信することができなければ、「ノードＮ１３が故障している」と認識してもよい。
【０７０２】
ノードＮ１２は、ノードＮ１３から所定時間以内に応答を受信した場合、リード要求に対する応答に含まれるバリューと、上記ライト要求に指定したバリューを比較してもよい。そして、ノードＮ１２は、２つのバリューが等しければ「ノードＮ１３は正常である」と認識し、２つのバリューが異なれば「ノードＮ１３が故障している」と認識してもよい。
【０７０３】
以上のように、同じキーが指定されたライト要求とリード要求を、生存確認メッセージの代わりに利用する実施形態によれば、例えばリード・ライト処理部３５１にのみ生じた故障も検出可能である。
【０７０４】
また、図１４の処理では、引き継ぎ提案と引き継ぎ要求という２種類の制御メッセージが使われる。しかし、実施形態によっては、引き継ぎ提案と引き継ぎ要求を兼ねた１種類の制御メッセージが使われてもよい。その場合、応答は下記（２９−１）または（２９−２）である。
【０７０５】
（２９−１）引き継ぎ提案に対するＡＣＫ応答と、引き継ぎ提案に対する引き継ぎ応答を兼ねた応答
（２９−２）引き継ぎ提案に対するＮＡＣＫ応答と同様の応答
【０７０６】
ところで、図５の対応表３４０と図６の対応表４３１の具体例として、図８には対応表６０１を例示した。そして、対応表６０１に例示したＩＰアドレスはすべてプライベートＩＰアドレスである。しかし、グローバルＩＰアドレスが使われてもよい。
【０７０７】
例えば、図４のように異なるネットワークセグメントに複数のノードが分散している場合、グローバルＩＰアドレスが使われてもよい。例えば、説明の便宜上、（３０−１）〜（３０−４）のように想定する。
【０７０８】
（３０−１）図４のブロードキャストドメイン２３０内の装置用に割り当てられたグローバルＩＰアドレスの範囲は「２００．１．２．０／２４」である。
（３０−２）そのうち、「２００．１．２．１」〜「２００．１．２．２４」という２４個のＩＰアドレスが、対応表３４０や４３１における通信端点情報用のＩＰアドレスとして利用可能である。
（３０−３）ブロードキャストドメイン２４０の内の装置用に割り当てられたグローバルＩＰアドレスの範囲は「２００．１．３．０／２４」である。
（３０−４）そのうち、「２００．１．３．１」〜「２００．１．３．２４」という２４個のＩＰアドレスが、対応表３４０や４３１における通信端点情報用のＩＰアドレスとして利用可能である。
【０７０９】
上記（３０−２）と（３０−４）の想定より、合計４８個のＩＰアドレスを用いて４８個の通信端点が定義される。よって、上記（３０−２）と（３０−４）の想定によれば、対応表６０１と同様に、１６個のキー領域の各々に３つの通信端点を対応づけることができる。
【０７１０】
なお、（３０−２）と（３０−４）で同数のＩＰアドレスが定義されるのは単なる偶然である。環境に応じて、例えば「２００．１．２．０／２４」という範囲内の３０個のＩＰアドレスと「２００．１．３．０／２４」という範囲内の１８個のＩＰアドレスが使われてもよい。
【０７１１】
ところで、対応表６０１と図３の例では、対応表６０１に現れる４８個のＩＰアドレスは、図３のブロードキャストドメイン２００内のノードＮ１１〜Ｎ１８のいずれにも割り当て可能である。しかし、上記（３０−１）〜（３０−４）に示した想定においては、ＩＰアドレスの割り当てに制約がある。
【０７１２】
つまり、上記（３０−１）と（３０−３）の仮定より、上記（３０−２）に示した２４個のＩＰアドレスは、図４のノードＮ２１〜Ｎ２３には割り当て可能であるが、ノードＮ２４〜Ｎ２５への割り当ては禁止される。そして、上記（３０−１）と（３０−３）の仮定より、上記（３０−４）に示した２４個のＩＰアドレスは、ノードＮ２４〜Ｎ２５には割り当て可能であるが、ノードＮ２１〜Ｎ２３への割り当ては禁止される。
【０７１３】
なお、このようにＩＰアドレスの割り当てに制約がある実施形態においては、図１４〜１６の処理は、制約を満たすように変形される。
具体的には、図１４のステップＳ６０１は、図１４の処理を実行するノード３００への割り当てが可能なＩＰアドレスにより識別される通信端点の中の１つを選択するように、変形される。例えば、ノードＮ２２が図１４の処理を実行する場合は、（３０−２）の中の１つのＩＰアドレスにより識別される通信端点が、ステップＳ６０１で選択される。
【０７１４】
また、「図１５における対象通信端点のＩＰアドレスが、図１５の処理を実行するノード３００への割り当てが可能なＩＰアドレスである」という条件が満たされるように、図１４〜１６の処理が変形されてもよい。具体的には（３１−１）〜（３１−３）のように図１４〜１６の処理が変形されてもよい。
【０７１５】
（３１−１）図１４のステップＳ６１０は、図１４の処理を実行するノード３００への割り当てが可能なＩＰアドレスの割り当てが可能な他のノードの中から監視依頼の宛先を選ぶように、変形される。例えば、ノードＮ２２が図１４の処理を実行する場合は、ノードＮ２１とＮ２３の中から監視依頼の宛先が選ばれる。
（３１−２）図１５のステップＳ７１２は、図１５の処理を実行するノード３００への割り当てが可能なＩＰアドレスの割り当てが可能な他のノードの中から監視依頼の宛先を選ぶように、変形される。例えば、ノードＮ２２が図１５の処理を実行する場合は、ノードＮ２１とＮ２３の中から監視依頼の宛先が選ばれる。
（３１−３）図１６のステップＳ８０９は、図１６の処理を実行するノード３００への割り当てが可能なＩＰアドレスの割り当てが可能な他のノードの中から監視依頼の宛先を選ぶように、変形される。例えば、ノードＮ２２が図１６の処理を実行する場合は、ノードＮ２１とＮ２３の中から監視依頼の宛先が選ばれる。
【０７１６】
あるいは、（３１−１）〜（３１−３）のような変形の代わりに、図１５のステップＳ７０６以降の処理が以下の（３２−１）〜（３２−３）のように変形されてもよい。
【０７１７】
（３２−１）対象通信端点のＩＰアドレスが、図１５の処理を実行するノード３００に割り当て可能か否かを判断するステップが、ステップＳ７０６の前に追加される。
（３２−２）上記（３２−１）のステップで、「対象通信端点のＩＰアドレスが、図１５の処理を実行するノード３００に割り当て可能」と判断された場合は、ステップＳ７０６以降の処理が行われる。
（３２−３）上記（３２−１）のステップで、「対象通信端点のＩＰアドレスの、図１５の処理を実行するノード３００への割り当ては禁止されている」と判断された場合は、ステップＳ７０６以降の処理は行われない。その代わり、ノード３００は、対象通信端点のＩＰアドレスの割り当てが可能な他のノードを選んで、選んだノードに対して、対象通信端点の故障を通知する。そして、通知を受けたノードが代わりにステップＳ７０６〜Ｓ７１３の処理を行う。
【０７１８】
また、図３のクライアント２２０や図４のクライアントＰＣ２６０のように、ノード３００とは別のブロードキャストドメインに属するクライアント４００からのノード３００へのアクセスについてさらに説明すれば、以下のとおりである。
【０７１９】
ノード３００とは別のブロードキャストドメインに属するクライアント４００からのアクセスがあり得る実施形態においては、ノードに動的に割り当てられる通信端点情報におけるＩＰアドレスとして、グローバルＩＰアドレスが使われる。すなわち、ノード３００内の対応表３４０およびクライアント４００内の対応表４３１に現れるＩＰアドレスは、グローバルＩＰアドレスである。したがって、クライアント４００が送信するＤＢアクセス要求の宛先ＩＰアドレスは、グローバルＩＰアドレスである。
【０７２０】
例えば、上記（３０−１）〜（３０−４）のように仮定し、さらに、ある時点において図４のノードＮ２１のネットワークインタフェイス３２０に「２００．１．２．１０」というグローバルＩＰアドレスが割り当てられていると仮定する。そして、このグローバルＩＰアドレスに対応するキー領域に属するキーを指定したＤＢアクセス要求を、図４のクライアントＰＣ２６０が送信したとする。すると、ＤＢアクセス要求は、インターネット２５０とルータ２３１を介して、ノードＮ２１に送信される。
【０７２１】
具体的には、ＤＢアクセス要求は、「２００．１．２．１０」というＩＰアドレスのネットワークアドレス部に基づいて、インターネット２５０を介してルータ２３１へと送信される。そして、ルータ２３１のＡＲＰテーブルに現状と矛盾する古いエントリが残っているのでない限り、ＤＢアクセス要求は、ルータ２３１から正しくノードＮ２１に送信される。
【０７２２】
なお、ルータ２３１は、ルータ２３１自身がＡＲＰ要求を送信してＡＲＰ応答を受信することによって、ＡＲＰテーブルを更新することもある。また、ルータ２３１は、ブロードキャストドメイン２３０内の他の装置が送信したＡＲＰ要求を受信することによって、ＡＲＰテーブルを更新することもある。
【０７２３】
よって、多くの場合、ルータ２３１のＡＲＰテーブルには、「動的に割り当てられる（３０−２）のＩＰアドレスがそれぞれ現在ブロードキャストドメイン２３０内のノードＮ２１〜Ｎ２３にどのように割り当てられているか」という状況が反映されている。
【０７２４】
しかし、ときにはルータ２３１のＡＲＰテーブルに現状と矛盾する古いエントリが残っていることもあり得る。その場合、ＤＢアクセス要求はブロードキャストドメイン２３０内で破棄されてしまい、クライアントＰＣ２６０はＤＢアクセス応答を受信することができない。しかし、古いエントリはいずれルータ２３１のＡＲＰテーブルから消滅する。よって、クライアントＰＣ２６０は、タイムアウトして、さらに適宜の時間待機してから、ＤＢアクセス要求を再送してもよい。
【０７２５】
あるいは、ノードＮ２１〜Ｎ２３へのＩＰアドレスの割り当てが変化するたびにルータ２３１のＡＲＰテーブルも確実に更新されるようにするために、各ノードＮ２１〜Ｎ２３（つまり図５のノード３００）は、次のように動作してもよい。すなわち、対応づけ部３５４が、ネットワークインタフェイス３２０に新たなＩＰアドレスを対応づけるための処理を行うたびに、通信処理部３３０は、ＡＲＰ要求を送信してもよい。
【０７２６】
具体的には、通信処理部３３０は、ＴＰＡとＳＰＡの双方に上記新たなＩＰアドレスを設定し、ＴＨＡ（Target Hardware Address）とＳＨＡの双方にネットワークインタフェイス３２０のＭＡＣアドレスを設定して、ＡＲＰ要求を送信してもよい。例えば、対応づけ部３５４が、以上のようなＡＲＰ要求の送信を通信処理部３３０に命じてもよい。より詳しくは、対応づけ部３５４は、図１４のステップＳ６０９の処理または図１５のステップＳ７１１の処理を実行するたびに、以上のようなＡＲＰ要求の送信を通信処理部３３０に命じてもよい。
【０７２７】
すると、上記ＡＲＰ要求を受信した各装置（例えばルータ２３１を含む）は、もしＳＰＡに指定されたＩＰアドレスに対応するエントリをＡＲＰテーブル内に持っていれば、当該エントリを更新する。したがって、各ノードＮ２１〜Ｎ２３が上記のように動作することで、ノードＮ２１〜Ｎ２３へのＩＰアドレスの割り当てが変化するたびに、ルータ２３１のＡＲＰテーブル内の古いエントリも確実に更新される。
【０７２８】
その結果、クライアントＰＣ２６０が送信したＤＢアクセス要求は、ルータ２３１によって正しく宛先のノード３００（例えば上記の例ではノードＮ２１）に転送される。その結果、宛先のノード３００はＤＢアクセス要求に応答し、クライアントＰＣ２６０はＤＢアクセス応答を受信することができる。
【０７２９】
もちろん、上記のようにＴＰＡとＳＰＡの双方に同じ新たなＩＰアドレスを指定したＡＲＰ要求の送信は、図３のようなネットワーク環境の実施形態においても、同様に適用可能である。上記のようなＡＲＰ要求により、ネットワークインタフェイスと通信端点の対応づけの変化が素早くＡＲＰテーブルに反映されるようになるので、上記のようなＡＲＰ要求の送信は、ＤＢアクセスの平均レイテンシを短縮する効果がある。
【０７３０】
また、上記の実施形態では、主に「リンク層ではイーサネットが使われ、インターネット層ではＩＰが使われ、トランスポート層ではＴＣＰが使われる」と想定した。しかし、通信プロトコルは実施形態により変更されてもよい。
【０７３１】
例えば、トランスポート層ではＵＤＰが使われてもよい。その場合、アプリケーション層で動作するモジュール（例えば、図５のキー領域管理部３５０ａ〜３５０ｃや監視部３６０、図６のＤＢ要求処理部４３０など）が（３３−１）〜（３３−２）のように変形されてもよい。
【０７３２】
（３３−１）ＴＣＰが提供するのと類似の、コネクションに基づくセッション管理機能を実現する。
（３３−２）ＩＰアドレスの動的な再割り当てにともなうＡＲＰキャッシュのクリア動作に、責任を持つ。
【０７３３】
あるいは、イーサネット以外の規格が利用されてもよい。例えば、サーバクラスタにおけるサーバ間のインタコネクトとして利用されるInfiniBandや、ＶＩアーキテクチャ（Virtual Interface architecture）などが、ノード間の通信およびノードとクライアント間の通信に利用されてもよい。つまり、物理的なネットワークインタフェイスと論理的な通信端点とを対応づける仕組みを持ってさえいれば、上記に例示した以外のプロトコル（またはプロトコルスイート）であっても、利用可能である。そして、ノード３００の通信処理部３３０とクライアント４００の通信処理部４２０は、実際に使われるプロトコル（またはプロトコルスイート）に応じて、適宜実装されればよい。
【０７３４】
以上、様々な実施形態について説明したが、いずれの実施形態も、「ＤＢが複数のノードそれぞれの記憶装置に分散して記憶されている場合に生じ得る状況の変化に追従するためのアプリケーション層の仕組みを、簡単化することができる」という効果がある。
【０７３５】
なぜなら、「各ノード（つまり、各ノードの記憶装置）が、キーの定義域Ｋ内の部分集合Ｋ０〜ＫＭ−１のいずれに対応するか」ということは、直接的かつ動的な対応づけにより管理されるのではなく、間接的な対応づけにより管理されるからである。より具体的に理由を説明すれば、以下のとおりである。
【０７３６】
上記の実施形態では、部分集合と通信端点情報が静的に対応づけられる。さらに、そうして部分集合と静的に対応づけられた通信端点情報が、ＤＢのエントリを記憶する記憶装置へのアクセスを提供するネットワークインタフェイス（すなわち、ノードのネットワークインタフェイス）と、動的に対応づけられる。その結果として、部分集合と記憶装置は、間接的に対応づけられる。
【０７３７】
ここで、分散ＤＢシステムにおいて生じ得る状況の変化とは、ノード構成の変化のことであり、換言すれば、各ノードの記憶装置と、キーの定義域内の部分集合との間の上記のような間接的な対応づけの変化である。また、記憶装置と部分集合との間接的な対応づけに利用されている、部分集合と通信端点情報の対応づけは、静的対応づけ情報１１１に示すごとく、状況の変化と関係なく静的なので、追従の必要がない。よって、記憶装置と部分集合との間接的な対応づけに利用されている、通信端点情報とネットワークインタフェイスとの対応づけの変化への追従さえ実現されれば、分散ＤＢシステムにおける状況の変化への追従が実現される。
【０７３８】
そして、通信端点情報とネットワークインタフェイスとの間の対応づけの変化は、アプリケーション層よりも下層に実装される通信プロトコル（例えばＡＲＰ）を利用することで、追従可能である。例えば、図１の動的対応づけ情報１１２はＡＲＰテーブルにより実現されてもよく、動的対応づけ情報１１２の変化への追従は、ＡＲＰにより実現されてもよい。
【０７３９】
こうして、上記実施形態によれば、ノード構成の動的な変化への追従のための処理は、大部分がアプリケーション層よりも下層に隠蔽される（encapsulated）。つまり、上記の実施形態によれば、ノード間での制御情報の交換のための、アプリケーション層における複雑なプロトコルなどは、不要である。
【０７４０】
したがって、上記の実施形態によれば、アプリケーション層よりも下層に実装されるＡＲＰなどの通信プロトコルを利用することで、分散ＤＢシステムの状況の変化に追従することが可能である。また、上記の実施形態によれば、ＡＲＰなどの下層の通信プロトコルの存在を利用することにより、分散ＤＢシステムの状況の変化に追従するためのアプリケーション層の仕組みが、大幅に簡単化されている。
【０７４１】
さらに、上記の様々な実施形態は、いずれも、ＤＢが複数の記憶装置に分散している場合に生じ得る状況の変化に追従するためのコストを、低減する効果がある。なお、分散ＤＢシステムにおけるノードの追加・削除などにともなうノード構成の変更に追従するためのコストには、様々な種類がある。例えば、個々のノードにおける処理負荷、ノード間の通信負荷、ノードとクライアントの間の通信負荷、通信プロトコルの複雑さ、各ノードおよびクライアントが管理用に保持する情報の量、などの様々な種類のコストがある。上記実施形態によれば、これらの種々のコストが低く抑えられる。種々のコストが抑制される理由は以下のとおりである。
【０７４２】
なぜなら、第一に、ノードが記憶装置に記憶するエントリの範囲（つまりノードが担当するキー領域）と、通信端点とが、図１の静的対応づけ情報１１１（より具体的には対応表３４０と４３１）によって静的に対応づけられているからである。静的な対応づけのコストはきわめて低い。なぜなら、１回静的対応づけ情報１１１を記憶するためのわずかなコスト（例えば、図８の対応表６０１を図３のデプロイサーバ２０１から図５のノード３００にコピーする処理のコスト）はかかるが、保守コストはゼロだからである。
【０７４３】
そして、図８の対応表６０１の例からも分かるとおり、静的対応づけ情報１１１のデータ量は、キー領域の数Ｍの線形オーダであり、キー領域の数Ｍは、極端に大きくはない定数である。よって、静的対応づけ情報１１１に関しては、データ量という意味でのコストも低い。
【０７４４】
そして、第二に、コンシステントハッシング（consistent hashing）が実現されているので、ノード構成の変更にともなう処理負荷も抑えられる。
一般に、ノード数が多い大規模な分散ＤＢシステムでは、ノード数の多さゆえに「少なくとも１台のノードが故障している」といった状況は決して珍しくない。また、分散ＤＢシステムの大きな利点の１つは、「ノードを増やすことにより（つまりスケールアウト（scale out）することにより）データ量の増加に対処することができる」というスケーラビリティにある。したがって、分散ＤＢシステムにおいては、ノードの増加または減少によるノード構成の変化がしばしば起こり得る。
【０７４５】
一方で、ノードが担当するキー領域の変更（換言すれば、ノード間でのデータの再配分）のための処理負荷は、データ量が多ければ決して軽くはない。なぜなら、大量のデータを記憶装置から読み出して送信する処理と、大量のデータを受信して記憶装置に書き込む処理が発生するからである。
【０７４６】
よって、もし仮にノード構成の変化のたびに、変化とは直接関係しない他の多くのノードにおいても担当するキー領域が変わってしまうとすれば、分散ＤＢシステム全体の性能が大きく低下してしまうだろう。したがって、ノード構成が変化しても、大多数のノードでは担当するキー領域が変化しないような仕組みが好ましい。具体的には、コンシステントハッシングが実現されることが好ましい。
【０７４７】
本実施形態による分散ＤＢシステムでは、特に図１４〜１６、１８、２１から明らかなように、コンシステントハッシングが実現される。すなわち、新規ノードが追加されたり、故障などの何らかの原因によって既存ノードが分散ＤＢシステムから切り離されたりして、ノードの数が変化しても、担当するキー領域が変わるノードは、分散ＤＢシステムに含まれるノードのうちのごく一部である。また、ノード間での負荷の偏りの是正などの何らかの目的のために、ノードとキー領域の間の対応関係が変化する場合も、担当するキー領域が変更されるノードは、分散ＤＢシステムに含まれるノードのうちのごく一部である。
【０７４８】
このように、上記実施形態によれば、コンシステントハッシングという、分散ＤＢシステムにとって好ましい条件が満たされるので、ノード間でのデータの再配分のための処理負荷が低い。
【０７４９】
また、第三に、ノードの構成変更への追従が、ＡＲＰなどの比較的シンプルなプロトコルを利用することで実現可能なため、プロトコルの複雑さという意味でのコストも低い。
多数の制御メッセージの交換を必要とするような専用の複雑なプロトコルがなくても、上記実施形態によれば、ノードの構成変更への追従が可能である。つまり、ノード構成の変化への追従を実現するための図１の動的対応づけ情報１１２として、ＡＲＰテーブル３３１と４２１を利用することで、プロトコルの複雑さという意味でのコストを抑えることができる。
【０７５０】
なお、アプリケーション層において複雑なプロトコルが不要なことから、上記実施形態には、「分散ＤＢシステムを開発するプログラマのプログラミングとデバッグの負担を減らせる」という効果もある。つまり、上記実施形態によれば、分散ＤＢシステムにおけるノード構成の変化への追従を実現するための仕組みの一部が、アプリケーション層よりも下層に隠蔽される。その結果、上記実施形態のような分散ＤＢシステムのアプリケーションは、アプリケーション層で複雑なプロトコルが使われるシステムと比較して、開発するためにプログラマにかかる負担が小さい。
【０７５１】
そして、第四に、動的対応づけ情報１１２に関しては、データ量という意味でのコストも低い。
上記実施形態の分散ＤＢシステムのためだけにＡＲＰテーブル３３１と４２１に保持されるエントリの数は、最大でも、キー領域とノードの対応関係に応じて動的に割り当てられるＩＰアドレスの数である。つまり、上記実施形態の分散ＤＢシステムのためだけにＡＲＰテーブル３３１と４２１において増えるデータの量は、キー領域の数Ｍの線形オーダであり、キー領域の数Ｍは、極端に大きくはない定数である。よって、動的対応づけ情報１１２に関しては、データ量という意味でのコストも低い。
【０７５２】
第五に、ノード構成の変化への追従のためのコストの一部は、ノード構成が変化しようが変化しまいが行われる処理に吸収されているので、吸収された分のコスト削減が実現される。詳しく説明すれば以下のとおりである。
【０７５３】
上記実施形態では、ノード構成の変更への追従は、ノード（より詳細には、ノードのネットワークインタフェイス）と通信端点の動的対応づけにより行われる。そして、ノードと通信端点との動的対応づけは、ノード構成の変更の有無によらず、ネットワーク通信機能を持つコンピュータにおいて行われる。換言すれば、ノードのネットワークインタフェイスと通信端点との対応関係は、ノード構成の変更の有無によらず、繰り返し確認され、記憶される。
【０７５４】
例えば、ＡＲＰエントリには寿命があるため、ノード構成の変更の有無によらず、ＡＲＰ要求が一度ならず送信されることになる。その結果、ＭＡＣアドレスとＩＰアドレスとの対応関係は、繰り返し確認されてはＡＲＰテーブルに記憶され直されることになる。
【０７５５】
つまり、上記実施形態によれば、ノード構成が変更されなくても日常的に行われる処理が、ノード構成の変更への追従を可能とするための仕組みとして流用される。そのため、ノード構成の変更への追従を可能とするためだけに新たに生じる処理負荷は、比較的少ない。より具体的には以下のとおりである。
【０７５６】
上記実施形態によれば、ノード構成の変化が直接の原因となって、ＡＲＰ要求の送信という負荷が生じることも、もちろんある。しかし、そもそもＡＲＰ要求は、ノード構成が変化しない場合にも送信されることがある。
【０７５７】
例えば、単に時間が経過するだけでノード構成が変化しなくても、「古いＡＲＰエントリが削除され、その結果、ＡＲＰ要求が送信される」ということが起こり得る。より具体的には、例えば、ノード間で生存確認メッセージやその他の管理用メッセージが定期的に送信される場合などに、時間の経過にともなうＡＲＰエントリの削除に応じて、ＡＲＰ要求が送信される。あるいは、ＤＢアクセスの間隔があく場合にも、時間の経過にともなうＡＲＰエントリの削除に応じて、ＡＲＰ要求が送信されることがある。
【０７５８】
したがって、「ノード構成の変化以外の原因（例えば時間の経過などの原因）で送信されるＡＲＰ要求に応じてＡＲＰテーブル３３１と４２１が更新されると、ついでに、ノード構成の変化もＡＲＰテーブル３３１と４２１に反映される」ということもある。つまり、ノード構成が変化しようが変化しまいが行われる処理によって、ノード構成の変化への追従が実現されることがある。図２０のステップＳ１２０２でのＡＲＰ要求７２２の送信と、その結果として生じるステップＳ１２０４でのＡＲＰエントリ７２４の追加は、その例である。
【０７５９】
換言すれば、ノード構成が変化しようが変化しまいが行われる処理が、ノード構成の変化への追従を実現するための処理の一部を兼ねており、ノード構成の変化への追従を実現するための処理の一部を肩代わりしている。そして、一部の処理が肩代わりされる分、ノード構成の変化への追従を実現するためのコストは削減される。
【０７６０】
以上説明した第一から第五の理由により、上記実施形態によれば、種々のコストを低く抑えることができる。また、上記実施形態によれば、ＳＰｏＦおよび性能のボトルネックとなり得るゲートウェイサーバのような装置も不要であるから、上記実施形態は耐障害性と性能の点でも優れている。
【０７６１】
なお、上記実施形態では、通信端点情報として、ＩＰアドレスとポート番号のペアか、または、ＩＰアドレスが使われる。このような通信端点情報は、より一層論理的なＦＱＤＮと比べると、以下の点で優れている。
【０７６２】
ＦＱＤＮのＩＰアドレスへの解決にはＤＮＳサーバが必要である。よって、ＤＮＳサーバはＳＰｏＦとなり得るし、分散ＤＢシステム全体の性能のボトルネックともなり得る。それに対し、ＡＲＰ要求とＡＲＰ応答によるＩＰアドレスのＭＡＣアドレスへの解決には、ＳＰｏＦやボトルネックになり得るような一元管理サーバは不要である。
【０７６３】
また、コンピュータが通信を行う際には、ＦＱＤＮはＩＰアドレスに解決される。よって、もし仮に各キー領域に静的に対応づけられたＦＱＤＮが通信端点情報として使われるとすると、キー領域とノードの対応関係が変化するたびに、ＦＱＤＮとＩＰアドレスの対応づけをＤＮＳサーバに登録し直す必要がある。また、あるキー領域のＦＱＤＮがあるノードから別のノードに引き継がれるたびに、当該ＦＱＤＮを使って通信を行おうとする装置（クライアントまたは他のノード）は、ＤＮＳサーバへの問い合わせをしなければならない。そして、以上のようなＤＮＳサーバへの登録のし直しや問い合わせは、ＡＲＰ要求のブロードキャストとは異なり、ノード構成が変化しようが変化しまいが行われる処理には吸収されない。よって、ＦＱＤＮの利用は、コスト削減につながらない。
【０７６４】
したがって、ＩＰアドレスとポート番号のペア（またはＩＰアドレス）により表される通信端点情報は、ＦＱＤＮのようなより一層論理的な情報と比べて、上記実施形態の通信端点情報として好適である。
【０７６５】
最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
コンピュータに、
対応するキーが定められているエントリを複数含むデータベースから、前記キーの定義域の特定の部分集合にキーが属する１つ以上の特定のエントリを取得し、
取得した前記１つ以上の特定のエントリを、前記コンピュータに備えられており前記データベースを分散して記憶する複数の記憶装置の１つとして使われる記憶装置に記憶し、
２以上の所定個数の通信端点をそれぞれ論理的に識別するための前記所定個数の通信端点情報であって、各々は、前記複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられるとともに、前記定義域内の互いに素な、前記特定の部分集合を含む複数の部分集合のいずれか１つに静的に対応づけられる、前記所定個数の前記通信端点情報のうち、前記特定の部分集合と対応づけられている特定の通信端点情報を、前記コンピュータのネットワークインタフェイスと対応づける
ことを含む処理を実行させる分散制御プログラム。
（付記２）
前記複数の部分集合のそれぞれに対して、２以上の通信端点情報が対応づけられており、
前記分散制御プログラムが前記コンピュータに実行させる前記処理は、
前記複数の部分集合のいずれか１つである対象部分集合に対応づけられている２以上の通信端点情報のうちの１つを宛先として指定したメッセージを送信し、
前記メッセージに対する応答を監視し、
所定時間内に前記応答が返ってこない場合、前記宛先として指定した前記通信端点情報と対応づけられたネットワークインタフェイスを備える第１の他のコンピュータに障害が発生していると認識する
ことをさらに含む
ことを特徴とする付記１に記載の分散制御プログラム。
（付記３）
前記対象部分集合が前記特定の部分集合であり、かつ、前記障害の発生を認識したときに、
前記特定の部分集合に対応づけられた前記２以上の通信端点情報のうちで前記メッセージの前記宛先には指定されていないいずれか１つの通信端点情報と対応づけられたネットワークインタフェイスを備える第２の他のコンピュータに、前記複数の記憶装置の１つとして前記第２の他のコンピュータが備える記憶装置から前記１つ以上の特定のエントリを読み出して送信するように要求し、
前記１つ以上の特定のエントリを、前記第２の他のコンピュータから受信する
ことを、前記１つ以上の特定のエントリを取得する処理が含むことを特徴とする付記２に記載の分散制御プログラム。
（付記４）
前記１つ以上の特定のエントリを取得する処理は、
前記所定個数の通信端点情報のうちの１つを前記特定の通信端点情報として選択するか、または、前記特定の通信端点情報を指定する指示を受け取ることにより、前記特定の通信端点情報を決定し、
決定した前記特定の通信端点情報と対応づけられたネットワークインタフェイスを備える第３の他のコンピュータに、前記複数の記憶装置の１つとして前記第３の他のコンピュータが備える記憶装置から前記１つ以上の特定のエントリを読み出して送信するように要求し、
前記１つ以上の特定のエントリを、前記第３の他のコンピュータから受信する
ことを含むことを特徴とする付記１に記載の分散制御プログラム。
（付記５）
前記複数の記憶装置のうちの１つを備える第４の他のコンピュータからの要求に応じて、前記１つ以上の特定のエントリを前記第４の他のコンピュータに送信し、
前記特定の通信端点情報と前記コンピュータの前記ネットワークインタフェイスとの対応づけを解除する
ことを、前記分散制御プログラムが前記コンピュータに実行させる前記処理がさらに含むことを特徴とする付記１から４のいずれか１項に記載の分散制御プログラム。
（付記６）
前記対応づけを解除したことを前記第４の他のコンピュータに通知することを、前記分散制御プログラムが前記コンピュータに実行させる前記処理がさらに含むことを特徴とする付記５に記載の分散制御プログラム。
（付記７）
暗号学的ハッシュ関数、剰余関数、および、入力ビット列から複数の所定の位置のビットを抽出する関数のうちの少なくとも１つを利用する所定の写像によるキーの像に基づいて、前記複数の部分集合が定義される
ことを特徴とする付記１から６のいずれか１項に記載の分散制御プログラム。
（付記８）
前記特定の部分集合に属するあるキーを指定して、前記あるキーと対応するエントリに対する読み出しまたは書き込みの操作を求める要求であって、前記特定の通信端点情報が宛先として指定されている要求を、前記コンピュータの前記ネットワークインタフェイスを介して受信し、
前記コンピュータが備える前記記憶装置に記憶されている前記１つ以上の特定のエントリのうちで、前記あるキーに対応する前記エントリにアクセスして、前記要求に応答する
ことを、前記分散制御プログラムが前記コンピュータに実行させる前記処理がさらに含むことを特徴とする付記１から７のいずれか１項に記載の分散制御プログラム。
（付記９）
前記通信端点情報がInternet Protocolアドレスを含むことを特徴とする付記１から８のいずれか１項に記載の分散制御プログラム。
（付記１０）
前記通信端点情報がさらに、トランスポート層で定義されるポート番号を含むことを特徴とする付記９に記載の分散制御プログラム。
（付記１１）
前記ネットワークインタフェイスは、Media Access Controlアドレスにより識別されることを特徴とする付記１から１０のいずれか１項に記載の分散制御プログラム。
（付記１２）
前記データベースがキー・バリュー・ストアであるか、または
前記データベースがリレーショナル・データベースであって、かつ、前記キーが前記エントリ内の所定のフィールドのデータである
ことを特徴とする付記１から１１のいずれか１項に記載の分散制御プログラム。
（付記１３）
コンピュータが、
対応するキーが定められているエントリを複数含むデータベースから、前記キーの定義域の特定の部分集合にキーが属する１つ以上の特定のエントリを取得し、
取得した前記１つ以上の特定のエントリを、前記コンピュータに備えられており前記データベースを分散して記憶する複数の記憶装置の１つとして使われる記憶装置に記憶し、
２以上の所定個数の通信端点をそれぞれ論理的に識別するための前記所定個数の通信端点情報であって、各々は、前記複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられるとともに、前記定義域内の互いに素な、前記特定の部分集合を含む複数の部分集合のいずれか１つに静的に対応づけられる、前記所定個数の前記通信端点情報のうち、前記特定の部分集合と対応づけられている特定の通信端点情報を、前記コンピュータのネットワークインタフェイスと対応づける
ことを特徴とする分散制御方法。
（付記１４）
情報処理装置であって、
ネットワークインタフェイスと、
対応するキーが定められているエントリを複数含むデータベースを分散して記憶する複数の記憶装置のうちの１つとして使われる記憶装置と、
前記データベースから、前記キーの定義域の特定の部分集合にキーが属する１つ以上の特定のエントリを取得して、取得した前記１つ以上の特定のエントリを、前記情報処理装置の前記記憶装置に記憶するための制御を行う取得制御手段と、
２以上の所定個数の通信端点をそれぞれ論理的に識別するための前記所定個数の通信端点情報であって、各々は、前記複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられるとともに、前記定義域内の互いに素な、前記特定の部分集合を含む複数の部分集合のいずれか１つに静的に対応づけられる、前記所定個数の前記通信端点情報のうち、前記特定の部分集合と対応づけられている特定の通信端点情報を、前記情報処理装置の前記ネットワークインタフェイスと対応づける対応づけ手段
を備える情報処理装置。
【符号の説明】
【０７６６】
１００ａ、１００ｂ、１１０、５００  コンピュータ
１０１ａ、１０１ｂ、５０７  記憶装置
１０２  エントリ
Ｉａ、Ｉｂ、３２０、４１０、５０４  ネットワークインタフェイス
１１１  静的対応づけ情報
１１２  動的対応づけ情報
１２０ａ、１２０ｂ、  ＤＢアクセス要求
Ｎ１〜Ｎ２５、３００  ノード
Ｋ  定義域、キー空間
Ｋ０〜Ｋ１５、Ｋａ  部分集合、キー領域
ｋ１、ｋ２  キー
Ｐ０〜Ｐ１５、Ｐａ  通信端点、通信端点情報
２００、２３０、２４０  ブロードキャストドメイン
２０１  デプロイサーバ
Ｃ、２０２、２２０、４００  クライアント
２０３、２３１、２４１  ルータ
２１０、２５０  インターネット
２４２  アプリケーションサーバ
２６０  クライアントＰＣ
３１０  ローカルストア
３３０、４２０  通信処理部
３３１、４２１、６０２  ＡＲＰテーブル
３３２  インタフェイス設定ファイル
３４０、４３１、６０１  対応表
３５０ａ〜３５０ｃ  キー領域管理部
３５１  リード・ライト処理部
３５２  取得制御部
３５３  供給制御部
３５４  対応づけ部
３５５  監視依頼部
３５６、６０５  依頼ノードリスト
３６０  監視部
３６１、６０４  対象ノードリスト
４３０  ＤＢ要求処理部
４４０  アプリケーション
５０１  ＣＰＵ
５０２  ＲＯＭ
５０３  ＲＡＭ
５０５  入力装置
５０６  出力装置
５０８  駆動装置
５０９  バス
５１０  可搬型記憶媒体
６０３  ＫＶＳ
６０６  フレーム
７０１、７０８、７０９、７１７、７２２、７２７、７３６  ＡＲＰ要求
７０２、７１０、７１８、７２３、７２８、７３７  ＡＲＰ応答
７０３、７０６、７１１、７１４、７１９、７２４、７２９、７３８  ＡＲＰエントリ
７０４、７１５、７２０、７２５、７３５、７３９  リード要求
７０５、７２１、７２６、７４０  リード応答
７０７  生存確認メッセージ
７１２  コピー要求
７１３  コピー応答
７１６  管理用メッセージ
７３０  引き継ぎ提案
７３１  ＡＣＫ応答
７３２  引き継ぎ要求
７３３  引き継ぎ応答
７３４  割り当て指示
【図１】
0005811703.tif 000010
【図３】
0005811703.tif 000011
【図４】
0005811703.tif 000012
【図５】
0005811703.tif 000013
【図６】
0005811703.tif 000014
【図７】
0005811703.tif 000015
【図８】
0005811703.tif 000016
【図９】
0005811703.tif 000017
【図１０】
0005811703.tif 000018
【図１１】
0005811703.tif 000019
【図１２】
0005811703.tif 000020
【図１３】
0005811703.tif 000021
【図１４】
0005811703.tif 000022
【図１５】
0005811703.tif 000023
【図１６】
0005811703.tif 000024
【図１７】
0005811703.tif 000025
【図１８】
0005811703.tif 000026
【図１９】
0005811703.tif 000027
【図２０】
0005811703.tif 000028
【図２１】
0005811703.tif 000029
【図２２】
0005811703.tif 000030
【図２】
0005811703.tif 000031