JP2013054521A - 分散制御プログラム、分散制御方法、および情報処理装置 - Google Patents

分散制御プログラム、分散制御方法、および情報処理装置 Download PDF

Info

Publication number
JP2013054521A
JP2013054521A JP2011191957A JP2011191957A JP2013054521A JP 2013054521 A JP2013054521 A JP 2013054521A JP 2011191957 A JP2011191957 A JP 2011191957A JP 2011191957 A JP2011191957 A JP 2011191957A JP 2013054521 A JP2013054521 A JP 2013054521A
Authority
JP
Japan
Prior art keywords
node
request
communication
processing unit
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2011191957A
Other languages
English (en)
Other versions
JP5811703B2 (ja
JP2013054521A5 (ja
Inventor
Toshiaki Saeki
敏章 佐伯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2011191957A priority Critical patent/JP5811703B2/ja
Priority to US13/594,991 priority patent/US9424325B2/en
Publication of JP2013054521A publication Critical patent/JP2013054521A/ja
Publication of JP2013054521A5 publication Critical patent/JP2013054521A5/ja
Application granted granted Critical
Publication of JP5811703B2 publication Critical patent/JP5811703B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】ＤＢが複数のノードに分散していると生じ得る状況の変化に追従するためのアプリケーション層の仕組みを簡単化する。
【解決手段】コンピュータ１００ｂは、対応するキーが定められているエントリを複数含むＤＢから、キーの定義域の特定の部分集合Ｋａにキーが属するエントリ１０２を取得し、記憶装置１０１ｂに記憶する。また、コンピュータ１００ｂは、部分集合Ｋａと対応づけられている通信端点情報Ｐａを自身のネットワークインタフェイスＩｂと対応づける。通信端点情報Ｐａは、２以上の所定個数の通信端点をそれぞれ論理的に識別するための上記所定個数の通信端点情報のうちの１つである。各通信端点情報は、ＤＢを分散して記憶する複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられ、定義域内の互いに素な複数の部分集合（そのうち１つは部分集合Ｋａ）の１つに静的に対応づけられる。
【選択図】図１

Description

本発明は、分散データベースのための分散制御に関する。
データベースには、伝統的なリレーショナル・データベース（ＲＤＢ：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）となるように（つまり、Ｋｉ∩Ｋｊが空集合となるように）、各部分集合が定義されるものとする。
そして、定義域Ｋは、式（１）のとおり、部分集合Ｋ０〜ＫＭ−１の和集合であるとする。
各部分集合Ｋｊが具体的にどのような部分集合であるかは、実施形態に応じて任意である。また、Ｍの値も実施形態に応じて任意である。換言すれば、定義域Ｋが重複も漏れもなくＭ個の部分集合Ｋ０〜ＫＭ−１に分割されさえすれば、部分集合Ｋ０〜ＫＭ−１がどのように定義されてもよい。
例えば、定義域Ｋが整数を要素とする集合である場合、各部分集合Ｋｊは、式（２）により定義されていてもよい。なお、式（２）における関数ｍｏｄ（ｘ，ｙ）は、ｘをｙで割った余りを計算する剰余関数である。
あるいは、引数ｘのハッシュ値を計算する適宜のハッシュ関数ｈａｓｈ（ｘ）を用いて、各部分集合Ｋｊが式（３）により定義されていてもよい。式（３）の定義は、定義域Ｋがどのような集合であるかによらず、適用可能である。
なお、式（３）のハッシュ関数ｈａｓｈ（ｘ）としては、任意のハッシュ関数が利用可能だが、ハッシュ関数ｈａｓｈ（ｘ）は暗号学的ハッシュ関数であることが好ましい。なぜなら、暗号学的ハッシュ関数はハッシュ値の分布の一様性が高いからである。
ハッシュ値の分布の一様性が高いと、「キーの値に応じた水平分割のバランスが良い」と期待される。そして、バランスの良い分割は、効率の良い分散化を意味する。そのため、ハッシュ関数ｈａｓｈ（ｘ）は暗号学的ハッシュ関数であることが好ましい。例えば、暗号学的ハッシュ関数の一例は、１６０ビットのハッシュ値を出力するＳＨＡ−１（Secure Hash Algorithm 1）である。
あるいは、Ｂを１以上の整数として、Ｍ＝２Ｂが成り立つ場合には、各部分集合Ｋｊが式（４）または（５）により定義されていてもよい。なお、式（４）と（５）における関数ｅｘｔ（ｘ，ｙ，ｚ）は、ビット列ｘのｙビット目からｚビット目までを抽出する関数である。また、０ビット目が最上位ビットであるものとする。
例えば、式（４）によれば、キーｋを表すビット列の第Ｌビットから第（Ｌ＋Ｂ−１）ビットまでのＢビットが抽出される。そして、抽出されたＢビットで表される０以上（２Ｂ−１）以下の数により、キーｋの属するキー領域が定められる。式（５）は、式（４）のようにキーｋを表すビット列そのものからＢビットを抽出する代わりに、キーｋのハッシュ値を表すビット列そのものからＢビットを抽出することを示している。
なお、関数ｅｘｔ（ｘ，ｙ，ｚ）は、入力ビット列から複数の所定の位置のビットを抽出する関数の一例である。関数ｅｘｔ（ｘ，ｙ，ｚ）のように連続した（ｚ−ｙ＋１）ビットを抽出する関数の代わりに、例えば「２ビット目と５ビット目と８ビット目」のような、不連続な複数の位置のビットを抽出する関数が利用されてもよい。
また、各部分集合Ｋｊは、式（６）のように定義されていてもよい。式（６）における関数ｆは、集合Ｋから、式（７）を満たす集合Ｘへの、任意の写像である。なお、式（６）と（７）において、０≦ｊ≦Ｍなる任意のｊについて、Ｔｊは適宜に選ばれた実数の閾値であるものとし、０≦ｊ≦Ｍ−１なる任意のｊについて、Ｔｊ＜Ｔｊ＋１であるものとする。
式（７）によれば、関数ｆは、キーの定義域Ｋから、閾値Ｔ０以上かつ閾値ＴＭ未満の実数の少なくとも一部を要素とする集合Ｘへの、任意の写像である。キーの定義域Ｋによっては、関数ｆは、例えば恒等写像であってもよいし、ハッシュ関数であってもよい。もちろん、実施形態に応じて、関数ｆは、ハッシュ関数（特に暗号学的ハッシュ関数）、剰余関数、入力ビット列から複数の所定の位置のビットを抽出する関数のうちの１つまたは複数を利用する所定の写像であってよい。
以上の式（２）〜（７）に例示したように、部分集合Ｋ０〜ＫＭ−１は、所定の写像によるキーの像に基づいて定義されていてもよい。また、下記のとおり、式（６）は式（２）〜（５）を一般化した式でもある。
ここで、キーｋからＳＨＡ−１によりハッシュ値を求める関数を、ＳＨＡ１（ｋ）と表記することにする。すると、式（５）の例において、ハッシュ関数ｈａｓｈ（ｋ）としてＳＨＡ１（ｋ）を用い、Ｌ＝０とし、Ｂ＝７とした場合、各部分集合Ｋｊは、式（８）のように定義される。
別の観点から述べれば、式（８）の例は、式（６）において、０≦ｊ≦Ｍなる任意のｊについてＴｊ＝２１５３×ｊと定め、かつ、関数ｆ（ｋ）としてＳＨＡ（ｋ）を利用する例でもある。
そして、式（２）の例は、式（６）において、関数ｆ（ｋ）として剰余関数ｍｏｄ（ｋ，Ｍ）を用いるとともに、０≦ｊ≦Ｍなる任意のｊについてＴｊ＝ｊと定めた例でもある。同様に、式（３）の例は、式（６）において、関数ｆ（ｋ）として関数ｍｏｄ（ｈａｓｈ（ｋ），Ｍ）を用いるとともに、０≦ｊ≦Ｍなる任意のｊについてＴｊ＝ｊと定めた例でもある。また、式（４）と（５）のそれぞれも、式（６）の具体例の一つであることは明らかであろう。
さてここで、部分集合Ｋ０〜ＫＭ−１のうちのある特定の１つを「Ｋａ」とする。部分集合Ｋａにキーが属するすべてのエントリ１０２は、図１のステップＳ１ではコンピュータ１００ａの記憶装置１０１ａに記憶されているのに対し、ステップＳ２ではコンピュータ１００ｂの記憶装置１０１ｂに記憶されている。なお、エントリ１０２の数は、１のこともあるし複数のこともある。
コンピュータ１１０は、エントリ１０２のうちの少なくとも１つにアクセスしようとする場合、ＤＢアクセス要求を送信する。具体的には、エントリ１０２が記憶装置１０１ａに記憶されているステップＳ１では、コンピュータ１１０は、ＤＢアクセス要求１２０ａをコンピュータ１００ａに送信する。また、エントリ１０２が記憶装置１０１ｂに記憶されているステップＳ２では、コンピュータ１１０は、ＤＢアクセス要求１２０ｂをコンピュータ１００ｂに送信する。なお、「コンピュータ１１０は、なぜ、ステップＳ１ではＤＢアクセス要求１２０ａをコンピュータ１００ａに送信することができ、ステップＳ２ではＤＢアクセス要求１２０ｂをコンピュータ１００ｂに送信することができるのか」という理由については後述する。
ＤＢアクセス要求１２０ａは、コンピュータ１００ａのネットワークインタフェイスＩａにおいて受信される。そして、コンピュータ１００ａは、ＤＢアクセス要求１２０ａにしたがって記憶装置１０１ａにアクセスし、ＤＢアクセス応答をコンピュータ１１０に返す。
また、ＤＢアクセス要求１２０ｂは、コンピュータ１００ｂのネットワークインタフェイスＩｂにおいて受信される。そして、コンピュータ１００ｂは、ＤＢアクセス要求１２０ｂにしたがって記憶装置１０１ｂにアクセスし、ＤＢアクセス応答をコンピュータ１１０に返す。
このように、キーが部分集合Ｋａに属するエントリに対するＤＢアクセス要求に応答するのは、当該エントリを記憶しているノードである。以下では、ある部分集合Ｋｊ（０≦ｊ≦Ｍ−１）にキーが属するエントリをノードのローカルな記憶装置に記憶しているノードを、「部分集合Ｋｊの担当ノード」または「部分集合Ｋｊを担当するノード」ともいう。
ところで、１つのノードは、１つの部分集合のみを担当する場合もあるし、複数の部分集合を担当する場合もある。すると、各ノードが担当する部分集合の数に応じて、ノード間の負荷が偏ることがある。
また、ある部分集合にキーが属するエントリへのＤＢアクセス要求は多く、別の部分集合にキーが属するエントリへのＤＢアクセス要求は少ない、という場合もある。すると、ＤＢアクセス要求の量に応じて、ノード間の負荷が偏ることもある。
例えば、コンピュータ１００ａの負荷が高く、コンピュータ１００ｂの負荷が低ければ、負荷分散のために、コンピュータ１００ａの負荷の一部をコンピュータ１００ｂに移すことが好ましい。例えば上記のような負荷分散を目的として、部分集合Ｋａの担当ノードがコンピュータ１００ａからコンピュータ１００ｂに変更され、ステップＳ１からステップＳ２への状況の変化が生じる、という場合がある。
もちろん、ステップＳ１からステップＳ２への状況の変化は、他の原因によることもある。例えば以下のような場合である。
図１では、ステップＳ１を示す上段にもコンピュータ１００ｂが描かれている。しかし、ステップＳ１の段階では、コンピュータ１００ｂが分散ＤＢシステムのノードとして存在しなくてもよい。コンピュータ１００ｂが新たなノードとして追加されたことが原因で、ステップＳ１からステップＳ２へと状況が変化することもある。
また、図１では、ステップＳ２を示す下段にもコンピュータ１００ａが描かれている。しかし、ステップＳ２の段階では、コンピュータ１００ａが分散ＤＢシステムのノードとして存在しなくてもよい。つまり、ステップＳ１の直後にコンピュータ１００ａが故障した場合などに、コンピュータ１００ｂが部分集合Ｋａの担当を引き継ぐことにより、ステップＳ１からステップＳ２へと状況が変化することもある。
以上のように、引き継ぎ（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アドレスにより識別されることを特徴とする付記１から１０のいずれか１項に記載の分散制御プログラム。
（付記１２）
前記データベースがキー・バリュー・ストアであるか、または
前記データベースがリレーショナル・データベースであって、かつ、前記キーが前記エントリ内の所定のフィールドのデータである
ことを特徴とする付記１から１１のいずれか１項に記載の分散制御プログラム。
（付記１３）
コンピュータが、
対応するキーが定められているエントリを複数含むデータベースから、前記キーの定義域の特定の部分集合にキーが属する１つ以上の特定のエントリを取得し、
取得した前記１つ以上の特定のエントリを、前記コンピュータに備えられており前記データベースを分散して記憶する複数の記憶装置の１つとして使われる記憶装置に記憶し、
２以上の所定個数の通信端点をそれぞれ論理的に識別するための前記所定個数の通信端点情報であって、各々は、前記複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられるとともに、前記定義域内の互いに素な、前記特定の部分集合を含む複数の部分集合のいずれか１つに静的に対応づけられる、前記所定個数の前記通信端点情報のうち、前記特定の部分集合と対応づけられている特定の通信端点情報を、前記コンピュータのネットワークインタフェイスと対応づける
ことを特徴とする分散制御方法。
（付記１４）
情報処理装置であって、
ネットワークインタフェイスと、
対応するキーが定められているエントリを複数含むデータベースを分散して記憶する複数の記憶装置のうちの１つとして使われる記憶装置と、
前記データベースから、前記キーの定義域の特定の部分集合にキーが属する１つ以上の特定のエントリを取得して、取得した前記１つ以上の特定のエントリを、前記情報処理装置の前記記憶装置に記憶するための制御を行う取得制御手段と、
２以上の所定個数の通信端点をそれぞれ論理的に識別するための前記所定個数の通信端点情報であって、各々は、前記複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられるとともに、前記定義域内の互いに素な、前記特定の部分集合を含む複数の部分集合のいずれか１つに静的に対応づけられる、前記所定個数の前記通信端点情報のうち、前記特定の部分集合と対応づけられている特定の通信端点情報を、前記情報処理装置の前記ネットワークインタフェイスと対応づける対応づけ手段
を備える情報処理装置。
１００ａ、１００ｂ、１１０、５００ コンピュータ
１０１ａ、１０１ｂ、５０７ 記憶装置
１０２ エントリ
Ｉａ、Ｉｂ、３２０、４１０、５０４ ネットワークインタフェイス
１１１ 静的対応づけ情報
１１２ 動的対応づけ情報
１２０ａ、１２０ｂ、 ＤＢアクセス要求
Ｎ１〜Ｎ２５、３００ ノード
Ｋ 定義域、キー空間
Ｋ０〜Ｋ１５、Ｋａ 部分集合、キー領域
ｋ１、ｋ２ キー
Ｐ０〜Ｐ１５、Ｐａ 通信端点、通信端点情報
２００、２３０、２４０ ブロードキャストドメイン
２０１ デプロイサーバ
Ｃ、２０２、２２０、４００ クライアント
２０３、２３１、２４１ ルータ
２１０、２５０ インターネット
２４２ アプリケーションサーバ
２６０ クライアントＰＣ
３１０ ローカルストア
３３０、４２０ 通信処理部
３３１、４２１、６０２ ＡＲＰテーブル
３３２ インタフェイス設定ファイル
３４０、４３１、６０１ 対応表
３５０ａ〜３５０ｃ キー領域管理部
３５１ リード・ライト処理部
３５２ 取得制御部
３５３ 供給制御部
３５４ 対応づけ部
３５５ 監視依頼部
３５６、６０５ 依頼ノードリスト
３６０ 監視部
３６１、６０４ 対象ノードリスト
４３０ ＤＢ要求処理部
４４０ アプリケーション
５０１ ＣＰＵ
５０２ ＲＯＭ
５０３ ＲＡＭ
５０５ 入力装置
５０６ 出力装置
５０８ 駆動装置
５０９ バス
５１０ 可搬型記憶媒体
６０３ ＫＶＳ
６０６ フレーム
７０１、７０８、７０９、７１７、７２２、７２７、７３６ ＡＲＰ要求
７０２、７１０、７１８、７２３、７２８、７３７ ＡＲＰ応答
７０３、７０６、７１１、７１４、７１９、７２４、７２９、７３８ ＡＲＰエントリ
７０４、７１５、７２０、７２５、７３５、７３９ リード要求
７０５、７２１、７２６、７４０ リード応答
７０７ 生存確認メッセージ
７１２ コピー要求
７１３ コピー応答
７１６ 管理用メッセージ
７３０ 引き継ぎ提案
７３１ ＡＣＫ応答
７３２ 引き継ぎ要求
７３３ 引き継ぎ応答
７３４ 割り当て指示

Claims (7)

  1. コンピュータに、
    対応するキーが定められているエントリを複数含むデータベースから、前記キーの定義域の特定の部分集合にキーが属する１つ以上の特定のエントリを取得し、
    取得した前記１つ以上の特定のエントリを、前記コンピュータに備えられており前記データベースを分散して記憶する複数の記憶装置の１つとして使われる記憶装置に記憶し、
    ２以上の所定個数の通信端点をそれぞれ論理的に識別するための前記所定個数の通信端点情報であって、各々は、前記複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられるとともに、前記定義域内の互いに素な、前記特定の部分集合を含む複数の部分集合のいずれか１つに静的に対応づけられる、前記所定個数の前記通信端点情報のうち、前記特定の部分集合と対応づけられている特定の通信端点情報を、前記コンピュータのネットワークインタフェイスと対応づける
    ことを含む処理を実行させる分散制御プログラム。
  2. 前記複数の部分集合のそれぞれに対して、２以上の通信端点情報が対応づけられており、
    前記分散制御プログラムが前記コンピュータに実行させる前記処理は、
    前記複数の部分集合のいずれか１つである対象部分集合に対応づけられている２以上の通信端点情報のうちの１つを宛先として指定したメッセージを送信し、
    前記メッセージに対する応答を監視し、
    所定時間内に前記応答が返ってこない場合、前記宛先として指定した前記通信端点情報と対応づけられたネットワークインタフェイスを備える第１の他のコンピュータに障害が発生していると認識する
    ことをさらに含む
    ことを特徴とする請求項１に記載の分散制御プログラム。
  3. 前記対象部分集合が前記特定の部分集合であり、かつ、前記障害の発生を認識したときに、
    前記特定の部分集合に対応づけられた前記２以上の通信端点情報のうちで前記メッセージの前記宛先には指定されていないいずれか１つの通信端点情報と対応づけられたネットワークインタフェイスを備える第２の他のコンピュータに、前記複数の記憶装置の１つとして前記第２の他のコンピュータが備える記憶装置から前記１つ以上の特定のエントリを読み出して送信するように要求し、
    前記１つ以上の特定のエントリを、前記第２の他のコンピュータから受信する
    ことを、前記１つ以上の特定のエントリを取得する処理が含むことを特徴とする請求項２に記載の分散制御プログラム。
  4. 前記１つ以上の特定のエントリを取得する処理は、
    前記所定個数の通信端点情報のうちの１つを前記特定の通信端点情報として選択するか、または、前記特定の通信端点情報を指定する指示を受け取ることにより、前記特定の通信端点情報を決定し、
    決定した前記特定の通信端点情報と対応づけられたネットワークインタフェイスを備える第３の他のコンピュータに、前記複数の記憶装置の１つとして前記第３の他のコンピュータが備える記憶装置から前記１つ以上の特定のエントリを読み出して送信するように要求し、
    前記１つ以上の特定のエントリを、前記第３の他のコンピュータから受信する
    ことを含むことを特徴とする請求項１に記載の分散制御プログラム。
  5. 暗号学的ハッシュ関数、剰余関数、および、入力ビット列から複数の所定の位置のビットを抽出する関数のうちの少なくとも１つを利用する所定の写像によるキーの像に基づいて、前記複数の部分集合が定義される
    ことを特徴とする請求項１から４のいずれか１項に記載の分散制御プログラム。
  6. コンピュータが、
    対応するキーが定められているエントリを複数含むデータベースから、前記キーの定義域の特定の部分集合にキーが属する１つ以上の特定のエントリを取得し、
    取得した前記１つ以上の特定のエントリを、前記コンピュータに備えられており前記データベースを分散して記憶する複数の記憶装置の１つとして使われる記憶装置に記憶し、
    ２以上の所定個数の通信端点をそれぞれ論理的に識別するための前記所定個数の通信端点情報であって、各々は、前記複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられるとともに、前記定義域内の互いに素な、前記特定の部分集合を含む複数の部分集合のいずれか１つに静的に対応づけられる、前記所定個数の前記通信端点情報のうち、前記特定の部分集合と対応づけられている特定の通信端点情報を、前記コンピュータのネットワークインタフェイスと対応づける
    ことを特徴とする分散制御方法。
  7. 情報処理装置であって、
    ネットワークインタフェイスと、
    対応するキーが定められているエントリを複数含むデータベースを分散して記憶する複数の記憶装置のうちの１つとして使われる記憶装置と、
    前記データベースから、前記キーの定義域の特定の部分集合にキーが属する１つ以上の特定のエントリを取得して、取得した前記１つ以上の特定のエントリを、前記情報処理装置の前記記憶装置に記憶するための制御を行う取得制御手段と、
    ２以上の所定個数の通信端点をそれぞれ論理的に識別するための前記所定個数の通信端点情報であって、各々は、前記複数の記憶装置のいずれかへのアクセスを提供するネットワークインタフェイスに動的に対応づけられるとともに、前記定義域内の互いに素な、前記特定の部分集合を含む複数の部分集合のいずれか１つに静的に対応づけられる、前記所定個数の前記通信端点情報のうち、前記特定の部分集合と対応づけられている特定の通信端点情報を、前記情報処理装置の前記ネットワークインタフェイスと対応づける対応づけ手段
    を備える情報処理装置。
JP2011191957A 2011-09-02 2011-09-02 分散制御プログラム、分散制御方法、および情報処理装置 Active JP5811703B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011191957A JP5811703B2 (ja) 2011-09-02 2011-09-02 分散制御プログラム、分散制御方法、および情報処理装置
US13/594,991 US9424325B2 (en) 2011-09-02 2012-08-27 Recording medium, distribution controlling method, and information processing device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011191957A JP5811703B2 (ja) 2011-09-02 2011-09-02 分散制御プログラム、分散制御方法、および情報処理装置

Publications (3)

Publication Number Publication Date
JP2013054521A true JP2013054521A (ja) 2013-03-21
JP2013054521A5 JP2013054521A5 (ja) 2014-11-13
JP5811703B2 JP5811703B2 (ja) 2015-11-11

Family

ID=47753966

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011191957A Active JP5811703B2 (ja) 2011-09-02 2011-09-02 分散制御プログラム、分散制御方法、および情報処理装置

Country Status (2)

Country Link
US (1) US9424325B2 (ja)
JP (1) JP5811703B2 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015135568A (ja) * 2014-01-16 2015-07-27 株式会社日立製作所 ゲートウェイ装置、ファイルサーバシステム及びファイル分散方法
JP2018036962A (ja) * 2016-09-01 2018-03-08 日本電信電話株式会社 通信管理装置、通信管理方法、および、通信管理プログラム
JP2018191294A (ja) * 2017-05-10 2018-11-29 日置電機株式会社 ノード検索装置、測定システムおよび検索処理用プログラム
US10303680B2 (en) 2014-02-07 2019-05-28 Kabushiki Kaisha Toshiba Data processing apparatus and data processing method

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8731542B2 (en) 2005-08-11 2014-05-20 Seven Networks International Oy Dynamic adjustment of keep-alive message intervals in a mobile network
US10855734B2 (en) * 2011-06-29 2020-12-01 Interdigital Ce Patent Holdings Remote management of devices
US8780913B2 (en) * 2011-08-30 2014-07-15 International Business Machines Corporation Operating an infiniband network having nodes and at least one IB switch
US9990478B2 (en) * 2012-11-30 2018-06-05 The Nielsen Company (Us), Llc Methods, apparatus, and articles of manufacture to encode auxiliary data into relational database keys and methods, apparatus, and articles of manufacture to obtain encoded data from relational database keys
US8874761B2 (en) 2013-01-25 2014-10-28 Seven Networks, Inc. Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols
WO2014179508A1 (en) 2013-04-30 2014-11-06 Seven Networks, Inc. Detection and reporting of keepalive messages for optimization of keepalive traffic in a mobile network
WO2014194333A1 (en) 2013-05-31 2014-12-04 Seven Networks, Inc. Optimizing traffic by controlling keep-alives
EP3008943A4 (en) 2013-06-11 2017-02-22 Seven Networks, LLC Optimizing keepalive and other background traffic in a wireless network
US9819551B2 (en) * 2013-11-20 2017-11-14 Big Switch Networks, Inc. Systems and methods for testing networks with a controller
CN105204931B (zh) * 2014-06-11 2019-03-15 联发科技（新加坡）私人有限公司 低功耗可穿戴设备及其多操作系统切换、通信及管理方法
US10775875B2 (en) * 2014-06-11 2020-09-15 Mediatek Singapore Pte. Ltd. Devices and methods for switching and communication among multiple operating systems and application management methods thereof
US9781225B1 (en) * 2014-12-09 2017-10-03 Parallel Machines Ltd. Systems and methods for cache streams
US10142167B2 (en) * 2015-05-13 2018-11-27 Cisco Technology, Inc. Peer-assisted image update with self-healing capabilities
US11182365B2 (en) * 2016-03-21 2021-11-23 Mellanox Technologies Tlv Ltd. Systems and methods for distributed storage of data across multiple hash tables
US11210279B2 (en) * 2016-04-15 2021-12-28 Apple Inc. Distributed offline indexing
US10356039B1 (en) * 2016-09-30 2019-07-16 Amdocs Development Limited Apparatus, computer program, and method for utilizing a data structure to access fully qualified domain name information
US11496435B2 (en) * 2016-10-28 2022-11-08 The Nielsen Company (Us), Llc Systems, methods, and apparatus to facilitate mapping a device name to a hardware address
CN111464661B (zh) * 2020-06-17 2020-09-22 北京金迅瑞博网络技术有限公司 负载均衡方法、装置、代理设备、缓存设备及服务节点

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11313101A (ja) * 1998-04-24 1999-11-09 Nec Corp 二重化ｌａｎシステムのコネクション再接続の高速化方法及び方式
JP2002016622A (ja) * 2000-06-29 2002-01-18 Mitsubishi Electric Corp ネットワーク管理方式
JP2002185464A (ja) * 2000-12-12 2002-06-28 Nec Corp クライアント・サーバシステムおよびそのアドレス変更方法
JP2004072603A (ja) * 2002-08-08 2004-03-04 Nippon Telegr & Teleph Corp <Ntt> 障害回復システム、障害回復方法、障害回復プログラムおよび記録媒体
JP2006197400A (ja) * 2005-01-14 2006-07-27 Brother Ind Ltd 情報配信システム、情報更新プログラム、及び情報更新方法等
JP2007174672A (ja) * 2005-12-21 2007-07-05 Ntt Docomo Inc ピアツーピアルックアップシステムに対するモビリティチャーン処理のための方法および装置
JP2008234445A (ja) * 2007-03-22 2008-10-02 Brother Ind Ltd コンテンツ分散保存システム、複製データ取得方法、ノード装置、及びノード処理プログラム
JP2009187141A (ja) * 2008-02-04 2009-08-20 Brother Ind Ltd 情報配信システム及び同システムにおける重複数調整方法
JP2010086046A (ja) * 2008-09-29 2010-04-15 Brother Ind Ltd ネットワークシステム、監視装置、情報処理装置、情報処理方法並びに監視装置用プログラム及び情報処理装置用プログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002057682A (ja) * 2000-08-09 2002-02-22 Hitachi Ltd ネットワークインタフェース切替え方法及びネットワークに接続可能なコンピュータ
US7684352B2 (en) * 2006-11-02 2010-03-23 Nortel Networks Ltd Distributed storage of routing information in a link state protocol controlled network
JP4855355B2 (ja) 2007-07-18 2012-01-18 株式会社日立製作所 フェールオーバにおける引き継ぎ先を自律的に変更する計算機システム及び方法
US8489750B2 (en) * 2008-02-28 2013-07-16 Level 3 Communications, Llc Load-balancing cluster
US8775817B2 (en) * 2008-05-12 2014-07-08 Microsoft Corporation Application-configurable distributed hash table framework
JP2009295127A (ja) 2008-06-09 2009-12-17 Nippon Telegr & Teleph Corp <Ntt> アクセス方法、アクセス装置及び分散データ管理システム
US8549010B2 (en) * 2011-05-13 2013-10-01 Nokia Corporation Method and apparatus for providing distributed key range management

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11313101A (ja) * 1998-04-24 1999-11-09 Nec Corp 二重化ｌａｎシステムのコネクション再接続の高速化方法及び方式
JP2002016622A (ja) * 2000-06-29 2002-01-18 Mitsubishi Electric Corp ネットワーク管理方式
JP2002185464A (ja) * 2000-12-12 2002-06-28 Nec Corp クライアント・サーバシステムおよびそのアドレス変更方法
JP2004072603A (ja) * 2002-08-08 2004-03-04 Nippon Telegr & Teleph Corp <Ntt> 障害回復システム、障害回復方法、障害回復プログラムおよび記録媒体
JP2006197400A (ja) * 2005-01-14 2006-07-27 Brother Ind Ltd 情報配信システム、情報更新プログラム、及び情報更新方法等
JP2007174672A (ja) * 2005-12-21 2007-07-05 Ntt Docomo Inc ピアツーピアルックアップシステムに対するモビリティチャーン処理のための方法および装置
JP2008234445A (ja) * 2007-03-22 2008-10-02 Brother Ind Ltd コンテンツ分散保存システム、複製データ取得方法、ノード装置、及びノード処理プログラム
JP2009187141A (ja) * 2008-02-04 2009-08-20 Brother Ind Ltd 情報配信システム及び同システムにおける重複数調整方法
JP2010086046A (ja) * 2008-09-29 2010-04-15 Brother Ind Ltd ネットワークシステム、監視装置、情報処理装置、情報処理方法並びに監視装置用プログラム及び情報処理装置用プログラム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015135568A (ja) * 2014-01-16 2015-07-27 株式会社日立製作所 ゲートウェイ装置、ファイルサーバシステム及びファイル分散方法
US10303680B2 (en) 2014-02-07 2019-05-28 Kabushiki Kaisha Toshiba Data processing apparatus and data processing method
JP2018036962A (ja) * 2016-09-01 2018-03-08 日本電信電話株式会社 通信管理装置、通信管理方法、および、通信管理プログラム
JP2018191294A (ja) * 2017-05-10 2018-11-29 日置電機株式会社 ノード検索装置、測定システムおよび検索処理用プログラム

Also Published As

Publication number Publication date
US20130060815A1 (en) 2013-03-07
JP5811703B2 (ja) 2015-11-11
US9424325B2 (en) 2016-08-23

Similar Documents

Publication Publication Date Title
JP5811703B2 (ja) 分散制御プログラム、分散制御方法、および情報処理装置
US11445019B2 (en) Methods, systems, and media for providing distributed database access during a network split
US10185497B2 (en) Cluster federation and trust in a cloud environment
US9405781B2 (en) Virtual multi-cluster clouds
US10887276B1 (en) DNS-based endpoint discovery of resources in cloud edge locations embedded in telecommunications networks
US7992201B2 (en) Dynamic network tunnel endpoint selection
US11095534B1 (en) API-based endpoint discovery of resources in cloud edge locations embedded in telecommunications networks
US9342575B2 (en) Providing high availability in an active/active appliance cluster
US10320905B2 (en) Highly available network filer super cluster
US10873498B2 (en) Server network interface level failover
US9912632B2 (en) High availability internet protocol address solution for disaster recovery
US11743325B1 (en) Centralized load balancing of resources in cloud edge locations embedded in telecommunications networks
US11595470B1 (en) Resolving L2 mapping conflicts without reporter synchronization
CN111225003B (zh) 一种nfs节点配置方法和装置
US20220210086A1 (en) Managing network state for high flow availability within distributed network platform
CN109951388B (zh) 路由不间断方法和主控板
EP3977707A1 (en) Hardware load balancer gateway on commodity switch hardware
WO2023231836A1 (zh) 一种文件同步方法、装置、设备及存储介质
US10084890B2 (en) Sysplexport allocation across a z/OS sysplex
JP2019021022A (ja) 負荷分散装置、負荷分散方法、および、負荷分散プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140508

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140922

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20141001

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20141215

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150127

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150825

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150907

R150 Certificate of patent or registration of utility model

Ref document number: 5811703

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150