JP6182861B2 - 情報処理装置、情報処理端末、情報検索プログラム及び情報検索方法 - Google Patents

情報処理装置、情報処理端末、情報検索プログラム及び情報検索方法 Download PDF

Info

Publication number
JP6182861B2
JP6182861B2 JP2012288855A JP2012288855A JP6182861B2 JP 6182861 B2 JP6182861 B2 JP 6182861B2 JP 2012288855 A JP2012288855 A JP 2012288855A JP 2012288855 A JP2012288855 A JP 2012288855A JP 6182861 B2 JP6182861 B2 JP 6182861B2
Authority
JP
Japan
Prior art keywords
information
hash
server
information processing
group
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.)
Active
Application number
JP2012288855A
Other languages
English (en)
Other versions
JP2014130535A (ja
Inventor
康夫 小池
康夫 小池
藤田 和久
藤田  和久
敏之 前田
敏之 前田
越智 亮
亮 越智
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 JP2012288855A priority Critical patent/JP6182861B2/ja
Priority to US14/105,656 priority patent/US9319245B2/en
Publication of JP2014130535A publication Critical patent/JP2014130535A/ja
Application granted granted Critical
Publication of JP6182861B2 publication Critical patent/JP6182861B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • H04L12/6418Hybrid transport

Description

本発明は、情報処理装置の情報検索技術に関する。
コンピュータが分散化されたシステム(分散システム)では、通信先のサーバの宛先情報(例えば、IP(Internet Protocol)アドレス等)が必要になる。分散システムにおける宛先管理の方法の種類として、例えば、中央管理型及びP2P(Peer to Peer)型の方法がある。中央管理型の管理方法では、クライアントは、一旦、宛先を管理する専用サーバにアクセスして、専用サーバから目的サーバの宛先を取得する。一方、P2P型の管理方法では、分散システム内のサーバそれぞれが、他サーバへの宛先情報を管理する(全てのサーバが管理サーバの機能を持つ)。
P2P型の分散システムでは、サーバ間の関係を疎にするため、データをどのサーバに配置するかは計算により決定する方がよい。これには分散ハッシュテーブル(DHT:Distributed Hash Table)を用いることが多い。分散ハッシュテーブルは、所定のハッシュ関数によって決まるハッシュ値の集合であるハッシュ空間にノードを写像し、それによってオーバーレイ・ネットワークを構築する。DHTを用いて宛先となるサーバを決定する方法では、データに対しキーを割り当て、そのキーをハッシュすることによってどのサーバにデータを割り当てるかを決定することができる。DHTを用いれば、確率的にサーバに対するデータの分布が均一になることが期待できるため、負荷分散が期待できる。特に、コンシステント・ハッシュ(CH)というハッシュ法は、ネットワーク上のサーバの追加・削除に対して強い柔軟性を持つため、分散データストレージシステムまたは分散キャッシュシステム等の分野にも応用されている。DHTを用いた分散システムに関する技術として、例えば、次の技術がある。
第1の技術として、複数のノード装置に情報を送信する際に、情報を送信するノード装置等の負担を軽減した情報通信システムがある。情報通信システムは、通信経路を介して互いに接続された複数のノード装置の参加により形成される。情報通信システムにおいて、あるノード装置Xは、複数のノード装置が所定の規則(例えば、DHT)に従って複数(4つ)のグループに分けられた各グループに含まれる代表のノード装置を決定する。ノード装置Xは、決定されたノード装置A,B,Cに向けて主情報を送信する。他のノード装置から受信した主情報が自ノード装置を含むグループ宛の場合には、ノード装置Xは、自ノード装置が属するグループの代表のノード装置に向けて、同様に受信した主情報を送信する。
第2の技術として、次の情報検索方法がある。情報検索方法は、サービスの提供元となる端末装置が提供する情報の所在、内容等を示す情報や当該情報を利用するための情報であるサービス情報を保持し、所定の条件に基づいてグループに分けられた通信装置を具備する情報検索システムに適用される。情報検索方法では、属性情報取得工程、第1の検索工程、要求転送工程、第2の検索工程を含む。属性情報取得工程は、サービス情報の検索を要求する情報検索要求に含まれるサービス情報を識別するための属性情報を取得する。第1の検索工程は、属性情報取得工程で取得した属性情報に基づいて、目的のサービス情報を保持する通信装置が属するグループを検索する。要求転送工程は、第1の検索工程の検索結果であるグループの代表通信装置に前記情報検索要求を転送する。第2の検索工程は、自身が代表通信装置である場合に、要求転送工程で転送された情報検索要求を受け取り、自グループ内で目的のサービス情報を検索する。
オンライン証券取引のようなシステムでは、膨大なリクエストを迅速に処理することが要求されている。更に、昨今ではこうしたオンライン取引のリクエスト量の成長の予測が困難であり、システムは柔軟に処理許容量を拡張できる仕組みが望まれる。この要望を満たすため、動的拡張可能な分散処理システムが望まれる。
中央管理型分散システムは、構造が非常に単純で、2回の通信で目的のサーバに到達できるが、同時に管理サーバが単一障害点となり、異常が発生した場合に、全システムに影響を与えることになる。また、サーバ数が非常に多くなると、問い合わせの通信がボトルネックになりやすいというデメリットを持つ。
P2P型分散システムは、サーバの一部がダウンしても全体としては停止しないというメリットがあり、可用性が求められる大規模分散システムで採用する場合が多い。また、DHT型のオーバーレイ・ネットワークを構築している場合は負荷分散も期待できる。つまり、前述した中央管理型のデメリットを解消することができる。
特開2007−053662号公報 特開2007−156700号公報
Luiz R. Monnerat 他1名"D1HT: A Distributed One Hop Hash Table Extended Version"、[online]、[平成24年10月10日検索]、インターネット<URL:http://www.cos.ufrj.br/uploadfiles/1164201892.pdf>
P2P型ではクライアントおよびサーバそれぞれが、システムに参加している全てのサーバの宛先情報を知っていることが理想となる。その場合、どのクライアント/サーバからでも目的のサーバに即座に通信できる。
しかしなから、システムに参加するサーバ数が非常に多くなると、宛先情報量、コネクション資源が膨大になり、高性能なハードが要求される。また、サーバの死活監視や、サーバ構成変動時に宛先情報を同期するための通信トラフィックが増大し、通信負荷が大きくなる。
本発明は、一側面として、相互に通信可能な情報処理装置を含むシステムにおいて、ネットワーク管理維持の負担を軽減する技術を提供する。
本発明の一側面にかかる、情報処理装置は、通信ネットワークを介して相互に通信可能に接続され、分散ハッシュ法によりハッシュ値を提供する分散ハッシュ情報に基づくハッシュ空間に対応付けられたいずれかのハッシュ値を有する情報処理装置であって、前記ハッシュ空間に対応付けられた該ハッシュ値の大きさの順に従って、複数のグループに分けられた各前記グループに属するいずれかの前記情報処理装置である第1装置同士についての前記ハッシュ空間における前記ハッシュ値を用いた分散ハッシュ情報を示す第1分散ハッシュ情報に基づいて他の前記情報処理装置から送信された、目的とする前記情報処理装置へのアクセスを要求するアクセス情報を取得する取得部と、前記第1装置が属するグループに属する前記情報処理装置である第2装置についての前記ハッシュ空間の前記ハッシュ値を用いた分散ハッシュ情報を示す第2分散ハッシュ情報を格納する格納部と、前記第2分散ハッシュ情報から、前記アクセス情報から生成したハッシュ値に対応する前記第2装置を検索する検索部と、検索された前記第2装置が前記複数のグループのうち他のグループに属する場合、前記第1分散ハッシュ情報を検索して、前記他のグループに属する第1装置に前記アクセス情報を送信し、検索された前記第2装置が自身のグループに属する場合、検索された前記第2装置に前記アクセス情報を送信する送信部と、前記情報処理装置が、前記第1装置が前記通信ネットワークより脱退した場合において、脱退した前記第1装置が属する前記グループに属する第2装置のうち前記脱退した第1装置の次に大きいまたは小さいハッシュ値を有する場合、他の前記情報処理装置に対して前記第2装置が前記第1装置が脱退したグループにおける第1装置である旨を、前記脱退の際に複製されて格納されていた前記第1分散ハッシュ情報を用いて通知すると共に、前記第2装置を前記第1分散ハッシュ情報に追加し前記他の情報処理装置または情報処理端末へ送信する脱退処理部と、を含む。
本発明の一側面によれば、相互に通信可能な情報処理装置を含むシステムにおいて、ネットワーク管理維持の負担を軽減することができる。
本実施形態における情報処理システムのブロック図を示す。 本実施形態におけるスプリット・ハッシュを説明するための図である。 本実施形態における親サーバと子サーバのCH上の関係、及びそれらのネットワーク接続について説明するための図である。 本実施形態におけるオーバレイ・ネットワークでのルーティングを説明するための図である。 本実施形態における分散システムのネットワーク構成例を示す。 本実施形態における親サーバの構成例を示す。 本実施形態における子サーバの構成例を示す。 本実施形態におけるクライアントの構成例を示す。 本実施形態におけるクライアント・サーバ間またはサーバ間の通信で使用する通信情報の構造例を示す。 本実施形態におけるサーバ管理情報の一例を示す。 本実施形態における、(A)親CHまたは子CHを構築するサーバ情報構造体及び(B)サーバ情報構造体の一例を示す。 本実施形態におけるCH表のデータ構造の一例を示す。 本実施形態における分散システムへのデータアクセスのフローを示す。 本実施形態におけるCH表の検索フローを示す。 本実施形態におけるスプリット・ハッシュの動的分割を説明するための図である。 本実施形態におけるスプリット・ハッシュに対して、追加されるサーバが実行する処理フローを示す。 図16の参加依頼処理(S36)の詳細フローを示す。 本実施形態におけるスプリット・ハッシュでのCH表のレプリケーションを説明するための図である。 本実施形態におけるサーバの脱退時でのスプリット・ハッシュに参加している各サーバが実行する処理フローを示す。 本実施形態の一実施例に係るコンピュータのハードウェア環境の構成ブロック図である。
目的サーバへの到達速度と宛先情報の保守コストは以下のようなトレードオフの関係にあり、どのように最適化するかがポイントとなっている。
宛先情報量 : 少← →多
到達速度 : 遅← →速
維持コスト : 小← →大
DHTによるオーバーレイ・ネットワークの構築アルゴリズムには、例えば、Chord 、Pastry、CAN がある。Chordは、1つのサーバで保持する宛先情報を削減する代わりに目的地に到達するのに何回かのホップ(サーバ間を探索しながら移動すること)を行うルーティングアルゴリズムである。Chordはこの分野でも効率の良いアルゴリズムであり、システムの規模に関わらず、O(log2 N)(Nはサーバ数)のオーダーのホップ回数で目的地に到達する。
しかし、例えばオンライン証券取引のWebフロントシステムのように、1回の通信(数百マイクロ秒)でも削減してレイテンシ(応答速度)を速くすることが競争力に繋がるシステムでは、Chordでもデータ到達までの速度やその安定性は十分とは言えない。また、ストリーミング処理のように、常に最も遅い場合に処理を合わせる必要があるシステムでは、Chordでもデータ到達までの速度やその安定性は十分とは言えない。
具体的には、Chordはサーバ台数に寄らず高確率で2ホップ以上必要となる上、100台構成ならば最大5ホップの通信が必要となり、1ミリ秒以上の通信性能差が発生する場合がある。
一方、高速化と安定を追求し、ホップ回数を極限まで減らす手法が研究されている。DHTの探索を高速化する方法として、D1HT等の1ホップDHTと呼ばれる手法があり、ホップを通常時1回だけしか発生させないアルゴリズムである。しかしながら、このような方法では、全サーバが他サーバへの経路を記憶する必要があるため、システムに参加するサーバ数が非常に多くなると、宛先情報量、コネクション資源が膨大になり、高性能なハードが要求される。また、サーバの死活監視や、サーバ構成変動時に宛先情報を同期するための通信トラフィックが増大し、通信負荷が大きくなる。つまり、よりシステム維持負荷が低く、かつ応答性能の良いオーバレイ・ネットワークの構築が競争力のあるシステムの課題となっている。
本実施形態では、コンシステント・ハッシュと同等の高可用性と柔軟な構成変更の特性を持ち、かつ、ネットワーク維持の負荷が低く応答性能が速いオーバレイ・ネットワークの構築法を提案する。
図1は、本実施形態における情報処理システムのブロック図を示す。情報検索システム1は、情報処理端末2、情報処理装置3、通信ネットワーク4を含む。
情報処理装置3は、通信ネットワーク4を介して相互に通信可能に接続され、分散ハッシュ法によりハッシュ値を提供する分散ハッシュ情報に基づくハッシュ空間に対応付けられたいずれかのハッシュ値を有する。分散ハッシュ情報の一例としては、分散ハッシュテーブルが挙げられる。情報処理装置3は、取得部3−1、格納部3−2、検索部3−3、送信部3−4、分離制御部3−5、脱退処理部3−6を含む。
取得部3−1は、第1分散ハッシュ情報に基づいて他の情報処理装置3から送信された、目的とする情報処理装置3へのアクセスを要求するアクセス情報を取得する。取得部3−1の一例として、通信制御部41が挙げられる。第1分散ハッシュ情報は、第1装置同士についてのハッシュ空間におけるハッシュ値を用いた分散ハッシュ情報を示す。第1分散ハッシュ情報の一例としては、親ハッシュ表49が挙げられる。第1装置は、ハッシュ空間に対応付けられたハッシュ値の大きさの順に従って、複数のグループに分けられた各グループに属するいずれかの情報処理装置3である。第1装置の一例としては、親サーバ12が挙げられる。
格納部3−2は、第2分散ハッシュ情報を格納する。第2分散ハッシュ情報は、第1装置が属するグループに属する情報処理装置である第2装置についてのハッシュ空間のハッシュ値を用いた分散ハッシュ情報を示す。納部3−2の一例としては、記憶部48が挙げられる。第2分散ハッシュ情報の一例として、子CH表50が挙げられる。
検索部3−3は、第2分散ハッシュ情報から、アクセス情報から生成したハッシュ値に対応する第2装置を検索する。検索部3−3の一例として、子CH宛先管理部46が挙げられる。第2装置の一例としては、子サーバ13が挙げられる。
送信部3−4は、検索された第2装置へアクセス情報を送信する。送信部3−4の一例としては、通信制御部41が挙げられる。
このように構成することにより、同一ハッシュ空間を階層化することができるので、ネットワーク管理維持の負担を軽減することができる。
前記情報処理装置が前記第1装置である場合、格納部3−2は、さらに、第1分散ハッシュ情報を格納する。検索部3−3は、取得されたアクセス情報が当該情報処理装置以外の第1装置が処理すべきアクセス情報である場合、第1分散ハッシュ情報から、アクセス情報から生成したハッシュ値に対応する第1装置を検索する。送信部3−5は、検索された第1装置へアクセス情報を送信する。
情報処理装置3は、さらに、分離制御部3−5を含む。分離制御部3−5は、いずれのグループにも属していない情報処理装置3から、第1装置が属する第1グループへの参加依頼が通知された場合、第1グループに属する第2装置の数と、所定の閾値とを比較する。分離制御部3−5は、比較結果に応じていずれかの第2装置を選択する。分離制御部3−5は、第1グループに対応するハッシュ空間の先頭から、選択した第2装置が有するハッシュ値までの範囲に含まれるハッシュ値を有する第2装置を第1グループから分離させる。分離制御部3−5は、分離させた第2装置により形成されるグループについての第2分散ハッシュ情報を生成し、選択した第2装置を第1分散ハッシュ情報に追加する。分離制御部3−5の一例として、構成管理部44が挙げられる。
情報処理装置3は、さらに、脱退処理部3−6を含む。情報処理装置3が、第1装置が通信ネットワーク4より脱退した場合において、脱退した第1装置が属するグループに属する第2装置のうち脱退した第1装置の次に大きいまたは小さいハッシュ値を有する場合、脱退処理部3−6は、次の処理を行う。すなわち、脱退処理部3−6は、他の情報処理装置3に対して第2装置が第1装置が脱退したグループにおける第1装置である旨を通知すると共に、第2装置を第1分散ハッシュ情報に追加し他の情報処理装置3または情報処理端末2へ送信する。脱退処理部3−6の一例として、構成管理部44が挙げられる。
このように構成することにより、同一ハッシュ空間を階層化することにより、ネットワーク構成変更の影響をその階層のネットワークに局所化することができので、ネットワーク管理維持の負担を軽減することができる。
情報処理端末2は、通信ネットワーク4を介して他の情報処理装置3と相互に通信可能に接続され、分散ハッシュ情報に基づくハッシュ空間に対応付けられたいずれかのハッシュ値を有する情報処理装置を含む情報処理システムへアクセスする。情報処理端末2は、格納部2−1、取得部2−2、検索部2−3、送信部2−4を含む。格納部2−1は、代表装置分散ハッシュ情報を格納する。代表装置分散ハッシュ情報(第1分散ハッシュ情報)は、代表装置(第1装置)同士についての前記ハッシュ空間における前記ハッシュ値を用いた分散ハッシュ情報を示す。代表装置(第1装置)は、ハッシュ空間に対応付けられた該ハッシュ値の大きさの順に従って、複数のグループに分けられた各前記グループに属するいずれかの情報処理装置3である。格納部2−1の一例として、記憶部56が挙げられる。
取得部2−2は、目的とする情報処理装置へのアクセスを要求するアクセス情報を取得する。取得部2−2の一例として、ライブラリ52が挙げられる。
検索部2−3は、代表装置分散ハッシュ情報から、アクセス情報から生成したハッシュ値に対応する代表装置を検索する。検索部2−3の一例として、親CH宛先管理部54が挙げられる。
送信部2−4は、検索された代表装置へアクセス情報を送信する。送信部2−4の一例として、通信制御部55が挙げられる。
このように構成することにより、同一ハッシュ空間を階層化することができるので、ネットワーク管理維持の負担を軽減することができる。
本実施形態では、まず、コンシステント・ハッシュ(CH)を用いたオーバレイ・ネットワークにおいて、サーバ数に応じてハッシュ空間を複数に分割する。以下では、分割されたハッシュ空間を“エリア”と呼ぶことにする。次に、エリア毎に代表となる親サーバを自動的に選出し、エリア内の各サーバへのアクセスは親サーバを経由して行うように制御する。これにより、1つのハッシュ空間を階層構造で扱うことができる。この分割・階層化されたハッシュ空間をスプリット・ハッシュと呼ぶことにする。
図2は、本実施形態におけるスプリット・ハッシュを説明するための図である。符号15は、物理的なネットワーク15を示す。符号11は、円環で表されたハッシュ空間を示し、具体的には、円環全体は、コンシステント・ハッシュ空間を表す。円環上にある小さい円それぞれがサーバを表す。
まずは、物理的なネットワーク15上に、論理的なハッシュ空間11が形成され、ハッシュ空間11中の小さい円で示すように、各サーバがハッシュ空間にマッピングされる。更に、ハッシュ空間にマッピングされたサーバの数に応じて、ハッシュ空間11は複数のエリア14に分割される。
図2では、それぞれのエリア14で、黒丸で示す親サーバ12が1つずつ選出された状態を示している。また、各エリア14において、白丸で示すサーバを、子サーバ13という。親サーバ12は、分割されたエリア14の“終端”(例えばハッシュ空間が数値で表されるならば、区間内のもっとも大きい値)であるサーバであり、“前”の親サーバが担当するハッシュ値より後から、自身のハッシュ値までのハッシュ空間を担当する。これはCHにおけるサーバのハッシュ空間担当範囲の決定方法と同様である。
各エリア14内で許容できるサーバ数は予め定められており、その許容できるサーバ数を超えて、エリア14で示すハッシュ空間にサーバが追加されようとすると、後述するように、そのエリア14は分割される。これにより、エリア14内のサーバ数が閾値を超過した場合に、過密となったそのエリアをアルゴリズム的に分割することができる。その結果、ネットワーク構成を動的に変更することができ、変更の影響を局所化することができる。
図3は、本実施形態における親サーバと子サーバのCH上の関係、及びそれらのネットワーク接続について説明するための図である。符号21で示す円環が全体のCH、符号22で示す円環が親サーバ12同士で形成されるハッシュ空間(親CH)を示す。親CH22は、全体のCH21のサブセットであり、ハッシュ空間に写像されている位置は全体のCH21と同じである。
親サーバ12間では、親CH21により、独自のネットワークを構成する。また、各エリア14では、エリア14内に含まれるサーバ間で独自のネットワークを構成する。各エリア14でのハッシュ空間を子CH23と呼ぶ。
親サーバ12同士は、相互に死活監視・構成監視を行う。そのために、符号24で示すように、親サーバ12同士でフルメッシュのネットワークが構築される。また、符号25で示すように、各エリア14の子CH23内についてもフルメッシュのネットワークが構築され、エリア14内のサーバ同士は、相互に、死活監視と構成情報監視を行う。なお、フルメッシュは例であり、死活監視・構成情報の同期コストが少ない方法を用いてもよい。
図4は、本実施形態におけるオーバレイ・ネットワークでのルーティングを説明するための図である。クライアント31は親CH22についての情報(親CH情報)を保持しており、アプリケーションプログラムよりデータの操作が依頼されると、親CH情報に基づいてアクセスするサーバを決定する。図4では、全体のCHで見るとキーのハッシュ値はサーバBとなるが、クライアント31からは親サーバ12しか見えない。そのため、クライアント31は、一旦親サーバとしてのサーバAにアクセスし、リクエストを通知する。サーバAは、子CHについての情報(子CH情報)とネットワーク経路についての情報(ネットワーク経路情報)を保持している。そのため、サーバAは、子CH情報とネットワーク経路情報を用いて、サーバBに、クライアント31からのリクエストを転送する。
本実施形態によれば、オーバレイ・ネットワークは、フルメッシュのネットワークと比べると、動的な構成変更によりネットワーク維持の負荷を“1/エリア分割数”に軽減できるので、ネットワークの負荷を分散することができる。
また、本実施形態のオーバレイ・ネットワークは、分散ハッシュの階層化により“O(エリア分割の階層数)”の転送回数で目的サーバに到達するため、高速な応答を実現できる。
以下に本実施形態の実施例について説明する。
図5は、本実施形態における分散システムのネットワーク構成例を示す。分散システム30は、クライアント31、通信ネットワーク32、複数のサーバ33を含む。クライアント31及び複数のサーバ33は、通信ネットワーク32を介して接続されている。
クライアント31は、親CHについてのオーバレイ・ネットワークに接続する情報処理端末を示す。複数のサーバ33は、CH空間を構成するサーバ群であり、1以上の親サーバ12と、1以上の子サーバ13を含む。親サーバ12は、オーバレイ・ネットワークのゲートウェイと言えるサーバである。子サーバ13は、ネットワーク32の末端サーバである。
図6は、本実施形態における親サーバの構成例を示す。親サーバ12は、通信制御部41、データ処理部42、構成管理部44、記憶部48を含む。記憶部48には、親CH表49、及び子CH表50、サーバ管理情報65等が格納される。通信制御部41は、ネットワーク32を介して接続されるサーバ間の通信及びクライアント31との通信を制御する。データ処理部42は、その親サーバ12が担当するデータが格納されたデータ格納部43を含んでおり、その格納されたデータを処理する。
構成管理部44は、その親サーバ12と同じ階層の親CHの構成とその親サーバが属するエリアに含まれる子サーバ12の子CHの構成を管理する。構成管理部44は、親CH宛先管理部45、子CH宛先管理部46、死活監視部47を含む。親CH宛先管理部45は、記憶部48に格納された親CH表を用いて、その親サーバ12と同じ階層の親CHについての情報を管理する。子CH宛先管理部46は、記憶部48に格納された子CH表を用いて、その親サーバ12が担当するエリア14の子CHについての情報を管理する。死活監視部47は、他の親サーバ12および担当するエリア14内の子サーバ13の死活監視を行う。すなわち、死活監視部47は、ネットワークへのサーバの追加、ネットワークからのサーバの脱退を監視する。
図7は、本実施形態における子サーバの構成例を示す。子サーバ13は、親サーバ12から親CH宛先管理部45と親CH表49を除いたものである。子サーバ13は、通信制御部41、データ処理部42、構成管理部44、記憶部48を含む。記憶部48には、子CH表50、サーバ管理情報65等が格納される。通信制御部41は、ネットワーク32を介して接続される、その子サーバが属するエリア14の、親サーバ12との通信及び子サーバ13との通信を制御する。データ処理部42は、その子サーバ13が担当するデータが格納されたデータ格納部43を含んでおり、その格納されたデータを処理する。
構成管理部44は、その子サーバ13が属するエリア14についての子CHの構成を管理する。構成管理部44は、子CH宛先管理部46、死活監視部47を含む。死活監視部47は、その子サーバ13が属するエリア内の親サーバ12及びその子サーバ13が属するエリア内の子サーバ13の死活監視を行う。すなわち、死活監視部47は、ネットワークへのサーバの追加、ネットワークからのサーバの脱退を監視する。
図8は、本実施形態におけるクライアントの構成例を示す。クライアント31は、アプリケーションプログラム51、ライブラリ52、宛先制御部53、通信制御部55、記憶部56を含む。アプリケーションプログラム(以下、「アプリケーション」という。)51は、ユーザの指示に基づいて、データの操作をサーバに依頼する。ライブラリ52は、アプリケーションから本実施形態における分散システム30にアクセスするためのアプリケーションプログラムインタフェース(API)を提供する。記憶部56には、親CH表49、ユーザデータ等が格納される。
宛先制御部53は、各サーバの宛先情報を管理する。宛先制御部53は、親CH宛先管理部54を含む。親CH宛先管理部54は、記憶部56に格納された親CH表49を用いて、親サーバの宛先を決定する。通信制御部55は、ネットワーク32を介して接続されるサーバとの通信を制御する。
図9は、本実施形態におけるクライアント・サーバ間またはサーバ間の通信で使用する通信情報の構造例を示す。図9(A)に示す通信情報61は、通信ヘッダ部62、データ部63を含む。通信ヘッダ部62は、「通信種別」62−1、「データ長」62−2、通信プロトコルで用いる情報を含む。「データ長」62−2は、データ部63のデータ長(データサイズ)を示す。
「通信種別」62−1は、通信の種別を識別するものであり、通信種別によってデータ部63の構成が変化する。例えば、リクエストの内容が、サーバに対するデータの更新を示す場合、「通信種別」62−1には、「データ更新要求」が設定される。この場合、図9(B)に示すように、データ部63は、CH用のデータの「キー値長」63−1、「キー値」63−2、「データ長」63−3、「実データ」63−4という可変長構造体となる。
また、リクエストの内容がCH表50を操作するためのデータの送信を示す場合は、「通信種別」62−1には、「CH表送信」が設定される。この場合、図9(C)に示すように、データ部63は、「総宛先情報数」63−5、「サーバ識別子長」63−6、「サーバ識別子」63−7、「宛先情報」63−8を含む。「総宛先情報数」63−5には、宛先情報の総数が設定される。「サーバ識別子長」63−6には、サーバ識別子のサイズが設定される。「サーバ識別子」63−7には、サーバを識別する情報が設定される。「宛先情報」63−8には、送信先の情報が設定される。「サーバ識別子長」63−6、「サーバ識別子」6−7、「宛先情報」63−8は1セットであり、総宛先情報数(n組)含まれる。
図10は、本実施形態におけるサーバ管理情報の一例を示す。サーバ管理情報65は、各サーバが有する自身についての情報であり、そのサーバの記憶部48に格納されている。サーバ管理情報65は、「ハッシュ値」66、「親サーバ判定フラグ」67、「親サーバ識別子」68を含む。「ハッシュ値」66には、各サーバに割り当てられているハッシュ値が格納される。「親サーバ判定フラグ」67には、当該サーバが親サーバか否かを示す情報が格納されている。「親サーバ識別子」68には、当該サーバが親サーバでない場合(子サーバである場合)、当該サーバの属するエリアの親サーバを識別する識別情報が格納される。
図11(A)は、本実施形態における、親CHまたは子CHを構築するサーバ情報構造体を示す。図11(B)は、サーバ情報構造体の一例を示す。サーバ情報構造体により構築される親CHについてのサーバ情報は、クライアント31の記憶部56及び親サーバ12の記憶部48に格納されている。また、サーバ情報構造体により構築される子CHについてのサーバ情報は、子サーバ13の記憶部48に格納されている。
サーバ情報構造体71は、「サーバ識別子」72、「ハッシュ値」73、「宛先情報」74、「アドレス情報1」75、「アドレス情報2」76を含むデータ構造体である。
「サーバ識別子」72は、システム全体で一意となるサーバの識別情報であり、CHを構成する場合のキーとなる。サーバ識別子は、ハッシュ計算ができるデータであれば、文字列でも数値でもよい。
「ハッシュ値」73は、「サーバ識別子」72からハッシュ関数を通じて生成される値であり、0から始まる数値で、最大値はシステム規模に応じて決定される。「宛先情報」74は、サーバ間の通信用情報であり、IPアドレスやホスト名等、通信プロトコルを解決できる情報である。
「アドレス情報1」75及び「アドレス情報2」76は、オペレーティングシステム(OS)のアドレス情報であって、他のサーバ情報へのポインタであり、後述するハッシュ空間検索用のデータ構造で使用される。
図12は、本実施形態におけるCH表のデータ構造の一例を示す。CH表のデータ構造は、親CH表49及び子CH表50で共通した構造である。CH表のデータ構造は、親CH宛先管理部45、子CH宛先管理部46、親CH宛先管理部54において、サーバの検索に用いられる。図12では、一例として、2分探索木で表現しているが、平衡2分探索木や、その他の検索用データ構造でもよい。ここでは実現方法の一例として、2分探索木を使った場合の検索方法について述べる。
2分探索木における節及び葉はそれぞれ、図9(A)に示したサーバ情報構造体61である。ここでは「ハッシュ値」63について、分かりやすいように整数値にして表しているが、現実的にはハッシュ関数に依存した形式となる。「アドレス情報1」75及び「アドレス情報2」76は、2分探索木において子となるサーバ情報構造体の先頭アドレスを示す。「アドレス情報1」75は、該当節よりも小さいハッシュ値、「アドレス情報2」76は該当節よりも大きいハッシュ値のサーバ情報構造体へのリンクとなる。子となるサーバ情報が無い場合は、「アドレス情報1」75または「アドレス情報2」76に、“NULL”が格納される。
図13は、本実施形態における分散システムへのデータアクセスのフローを示す。図13では、クライアント31からのデータアクセス処理の例を説明する。
クライアント31において、アプリケーション51からデータ操作(挿入・参照・更新・削除等)がライブラリ52に含まれるAPIを用いて、宛先制御部53へ依頼される(S1)。ここでは、ライブラリ52は、ハッシュ関数を用いて、アプリケーション51から渡されたサーバ識別子からハッシュ値を取得し、そのハッシュ値を親CH宛先管理部54へ渡す。
親CH宛先管理部54は、記憶部56に格納された親CH表49を参照し、ライブラリ52より与えられたキー値に基づいて、親CH表49から親サーバ12を検索する。親CH宛先管理部54は、親CH表49から親サーバ12の宛先情報(IP(Internet Protocol)アドレス、ホスト名等)を取得する(S2)。
ライブラリ52は、受信したデータ操作依頼に基づいて通信種別を決定し、決定した通信種別に基づいて、図9(A)に示す通信情報61を生成する。ライブラリ52は、通信制御部55を介して、その取得した宛先情報により示される親サーバ12に対して、生成した通信情報61を送信する(S3)。
親サーバ12において、通信制御部41は、クライアント31からの通信情報61を受信する(S4)。すると、親CH宛先管理部45は、その通信情報の「キー値」63−2に基づいて、記憶部48に格納された子CH表50から、子サーバ13を検索する(S5)。
その検索の結果、そのリクエストは、当該リクエストを受信したサーバが担当すべきものであると判定された場合(S6で「Yes」)、データ格納部43は、データ操作処理を行い(S8)、クライアント31に処理後の応答結果を返却する(S9)。クライアント31は、その応答結果を受信する(S10)。
その検索の結果、そのリクエストは、当該リクエストを受信したサーバが担当すべきものでないと判定された場合(S6で「No」)、構成管理部44は、次の処理を行う。すなわち、構成管理部44は、子CH表50でヒットした宛先の子サーバ(同一エリア内の子サーバ)13に、受信したリクエストメッセージを転送する(S7)。もし、そのリクエストメッセージが、当該親サーバ12が属するエリアのデータでない場合、構成管理部44は、親CH表49を検索し、検索された親サーバ12にそのリクエストメッセージを転送する。その転送されたリクエストメッセージを受信した親サーバ12は、S4以降の処理を実行する。
図14は、本実施形態におけるCH表の検索フローを示す。このフローは、図13のS2、S5の詳細フローであり、親CH表49又は子CH表50を用いて、目的のサーバを検索する場合に適用される。ここでは、あるデータのキーが、親CH宛先管理部45、子CH宛先管理部46、または親CH宛先管理部54に渡され、そのデータがどのサーバにあるかを図12のCH表から導出する流れを説明する。以下では、親CH宛先管理部45、子CH宛先管理部46、または親CH宛先管理部54を宛先管理部と称する。
まず、宛先管理部は、本フローで使用するパラメタ“result”を“”(NULL)で初期化する(S11)。“result”は、検索の結果、返却する宛先情報を表すパラメタである。
次に、宛先管理部は、特定のハッシュ関数を使用してキーをハッシュ値に変換し、パラメタ“hash_A”に格納する(S12)。ハッシュ関数にはSHA-1やMD5等を用いてもよい。宛先管理部は、そのパラメタ“hash_A”に格納されたハッシュ値と、CH表のルートにある「Server-8」のサーバ情報構造体のハッシュ値(hash_B)とを比較する(S13)。以降、hash_Aの値によってどのようにフローが遷移するか、例を用いて示す。
(i)hash_A= 5の場合
図12において、現在参照しているルートノードのサーバ情報構造体のハッシュ値hash_Bは8であるため、「hash_A<hash_B(=8)」となる(S13)。この場合、宛先管理部は、一旦、返却値resultに、現在参照しているサーバ情報構造体の宛先情報“10.10.100.108”を設定する(S16)。宛先管理部は、hash_Aをより小さいhash_Bと比較するため、現在参照しているサーバ情報構造体のアドレス情報1によって示されるサーバ情報構造体を参照する(S17で「No」、S18)。
すると、参照先である「Server-3」のサーバ情報構造体が、現在参照しているサーバ情報構造体となるので、宛先管理部は、hash_B=3を設定する。ここでは、「hash_A>hash_B(=3)」であるため(S13)、宛先管理部は、現在参照しているサーバ情報構造体のアドレス情報2によって示されるサーバ情報構造体を参照する(S19で「No」、S20)。
すると、参照先である「Server-6」のサーバ情報構造体が、現在参照しているサーバ情報構造体となるので、宛先管理部は、hash_B=6を設定する。ここでは、「hash_A<hash_B(=6)」であるため(S13)、宛先管理部は、resultに現在参照しているサーバ情報構造体の宛先情報“10.10.100.106”を設定する(S16)。それから、宛先管理部は、現在参照しているサーバ情報構造体のアドレス情報1によって示されるサーバ情報構造体を参照する(S17で「No」、S18)。
すると参照先である「Server-4」のサーバ情報構造体が、現在参照しているサーバ情報構造体となるので、宛先管理部は、hash_B=4を設定する。ここでは、「hash_A> hash_B(=4)」であり(S13)、かつ、現在参照しているサーバ情報構造体より大きな子(サーバ情報構造体)がない(アドレス情報2がNULL)のため(S19で「Yes」)、宛先管理部は、次の処理を行う。すなわち、宛先管理部は、result=“10.10.100.106”を返却して終了する(S21で「No」、S24)。
(ii)ハッシュ値が3の場合(ハッシュ値が合致する場合)
図12において、現在参照しているルートノードのサーバ情報構造体のハッシュ値hash_Bは8であるため、「hash_A<hash_B(=8)」となる(S13)。この場合、宛先管理部は、一旦、返却値resultに、現在参照しているサーバ情報構造体の宛先情報“10.10.100.108”を設定する(S16)。宛先管理部は、hash_Aをより小さいhash_Bと比較するため、現在参照しているサーバ情報構造体のアドレス情報1によって示されるサーバ情報構造体を参照する(S17で「No」、S18)。
参照先である「Server-3」のサーバ情報構造体が、現在参照しているサーバ情報構造体であるので、宛先管理部は、hash_B=3を設定する。ここでは、「hash_A= hash_B(=3)」であるため(S13)、目的のサーバが確定する。この場合、宛先管理部は、resultに、現在参照しているサーバ情報構造体の宛先情報“10.10.100.103”を設定して返却する(S14、S15)。
(iii)hash_A=15の場合(環状のハッシュ空間を一周する場合)
図12において、現在参照しているルートノードのサーバ情報構造体のハッシュ値は8であるため、「hash_A>hash_B(=8)」となる(S13)。この場合、宛先管理部は、現在参照しているサーバ情報構造体のアドレス情報2によって示されるサーバ情報構造体を参照する(S19で「No」、S20)。
すると、参照先である「Server-10」のサーバ情報構造体が、現在参照しているサーバ情報構造体となるので、宛先管理部は、hash_B=10を設定する。ここでは、「hash_A>hash_B(=10)」であるため(S13)、宛先管理部は、現在参照しているサーバ情報構造体のアドレス情報2によって示されるサーバ情報構造体を参照する(S19で「No」、S20)。
すると参照先である「Server-14」のサーバ情報構造体が、現在参照しているサーバ情報構造体となるので、宛先管理部は、hash_B=14を設定する。ここでは、「hash_A>hash_B(=14)」であり(S13)、かつ現在参照しているサーバ情報構造体のアドレス情報2がNULLであり(S19で「Yes」)、result=“”(NULL)である(S21で「Yes」)。この場合、宛先管理部は、このキーは環状ハッシュ空間を一周したと判定し、hash_Aに「0」を設定し(S22)、再びルートのサーバ情報構造体から検索する(S23)。
すると、参照先である「Server-8」のサーバ情報構造体が、現在参照しているサーバ情報構造体となるので、宛先管理部は、hash_B=8を設定する。ここでは、「hash_A<hash_B(=8)」であるため(S13)、宛先管理部は、resultに、現在参照しているサーバ情報構造体の宛先情報“10.10.100.108”を設定する(S16)。宛先管理部は、現在参照しているサーバ情報構造体のアドレス情報1によって示されるサーバ情報構造体を参照する(S17で「No」、S18)。
すると、参照先である「Server-3」のサーバ情報構造体が、現在参照しているサーバ情報構造体となるので、宛先管理部は、hash_B=3を設定する。ここでは、「hash_A<hash_B(=3)」であるため(S13)、宛先管理部は、resultに、現在参照しているサーバ情報構造体の宛先情報“10.10.100.103”を設定する(S16)。宛先管理部は、現在参照しているサーバ情報構造体のアドレス情報1によって示されるサーバ情報構造体を参照する(S17で「No」、S18)。
すると、参照先である「Server-1」のサーバ情報構造体が、現在参照しているサーバ情報構造体となるので、宛先管理部は、hash_B=1を設定する。ここでは、「hash_A< hash_B(=1)」であるため(S13)、宛先管理部は、resultに、現在参照しているサーバ情報構造体の宛先情報“10.10.100.101”を設定する(S16)。現在参照しているサーバ情報構造体のアドレス情報1がNULLであるため(S17で「Yes」)、宛先管理部は、result=“10.10.100.101”を返却する(S15)。
なお、ここではCH表の検索フローのみ説明しているが、CH表に対する単純なサーバ(節)の追加・削除は2分木の方式に従うため、ここでは割愛する。
次に、ハッシュ空間の動的変化の実施例について説明する。
図15は、本実施形態におけるスプリット・ハッシュの動的分割を説明するための図である。スプリット・ハッシュは「エリア内サーバ数上限」というシステム共通のパラメタを持ち、1エリアに含まれるサーバ数がこの値を超過した時、そのエリアを分割する。図15において、エリア内のサーバ数の上限(閾値)は10である。
図15(A)は、エリア内にサーバ数の上限である10台のサーバが配置されている状態を示す(この例ではまだ1度も分割が発生していない)。ここに新たなサーバを追加し、サーバ数が11になった場合、ハッシュ値順に見て、エリア内のサーバ数が半分となる位置または半分+1となる位置にあるサーバ(エリアにおける「中間サーバ」と称する。)を境界としてエリア分割が行われる。分割後の結果を図15(B)に示す。
図15(B)は、ハッシュ空間の起点であるサーバAと、そこから数えて、エリア内のサーバ数が半分となる6台目のサーバであるサーバBに分割の境界を設けて、エリア1とエリア2に分割した状態を示す。そして、エリア1、エリア2のそれぞれ終端であるサーバBとCは親サーバとなる。
図15(C)、図15(D)では、エリア2のサーバ数が増え、エリア2内のサーバ数の上限に達した後、更にサーバが追加された状態を示す。この場合、エリア2が2つに分割されるが、エリア1の範囲には影響しない。
図16は、本実施形態におけるスプリット・ハッシュに対して、追加されるサーバが実行する処理フローを示す。サーバ死活監視部47は、ネットワーク上の他のサーバの動作状況を監視することにより、ネットワークワークへのサーバの参加を監視する(S31)。サーバの追加は、CH表が最初に構築される場合と、既に存在するCH表にサーバが追加される場合で異なる。
最初にCHを構築する場合(ネットワークの新規作成の場合)にはまだハッシュ空間の分割がないため、サーバは、管理者から入力された情報に基づいて、エリア内サーバ数の上限を設定する(S32)。サーバは、自身のサーバ識別子をハッシュ値に変換して、サーバ管理情報65に設定する。また、サーバは、CH表50を作成し(S33)、自身のハッシュ値、サーバ識別子、宛先情報、アドレス情報1,2を登録する。また、サーバは、エリア内サーバ数をインクリメントする(すなわち、現在のエリア内のサーバ数=1に設定する)(S34)。
CHに後から追加されるサーバ(ネットワークへの2台目以降のサーバの追加の場合)は、既にCHに参加しているいずれかのサーバ(ゲートウェイ機能を有する)と通信し(S35)、CHへの参加依頼を行う(S36)。S36の処理については図17にて説明する。追加されるサーバは、参加処理依頼したサーバから、応答情報を受信する(S37)。応答情報は、例えば、図9(A)−図9(C)で説明したフォーマットで送信される。
その応答情報に基づいて、追加されるサーバは、自身が子サーバであると判定した場合(S38で「No」)、S42の処理を行う。このとき、追加されるサーバは、応答結果を用いて、サーバ管理情報の「親サーバ判定フラグ」67を「子サーバ」に更新し、「親サーバ識別子」68を更新する。
その応答情報に基づいて、その追加されるサーバが、自身が親サーバであると判定した場合(S38で「Yes」)は、応答情報から親CH表49を構築し(S39)、親サーバ12同志のネットワーク接続を確立する(S40)。その追加されるサーバは、応答情報からエリア内のサーバ数の上限と、現在のエリア内のサーバ数を記憶部48に格納する(S41)。また、追加されるサーバは、応答結果を用いて、サーバ管理情報の「親サーバ判定フラグ」67を「親サーバ」に更新し、「親サーバ識別子」68を自身のサーバ識別子に更新する。
そして、その追加されるサーバは、応答情報から自身が属するエリアの子CH表50を構築し(S42)、そのCH表50に基づいて、子サーバ13との接続を確立する(S43)。この時、各子サーバ13は旧親サーバ12との接続を破棄する。
そして、サーバの追加に伴いデータの担当ハッシュ空間が変動するため、その変動したハッシュ空間に対応して管理されていたデータの移行処理が、ハッシュ空間が変更したサーバと、追加されたサーバ間で行われる(S44)。このデータ移行処理はCHの一般的技術であるため割愛する。
図17は、図16の参加依頼処理(S36)の詳細フローを示す。図17は、追加されるサーバ(参加要求サーバ)から参加依頼要求を受信した既存サーバの処理フローである。図16のS36において、既にCHに参加しているいずれかのサーバは、参加要求サーバからスプリット・ハッシュへの参加リクエストを受信する(S51)。スプリット・ハッシュ参加のリクエストを受けた所定のサーバが子サーバ13である場合(S52)、子サーバ13は、自身が属するエリアの親サーバ12にそのスプリット・ハッシュ参加のリクエストを転送する(S53)。
スプリット・ハッシュ参加のリクエストを受けたサーバが親サーバ(対象親サーバと称する)12である場合(S52で「No」)、対象親サーバは、次の処理を行う。すなわち、対象親サーバは、参加要求サーバのサーバ識別子から、ハッシュ関数を用いてハッシュ値を計算し、親CH表を用いて図14の処理を行い、そのハッシュ値を担当する親サーバを検索する(S54)。検索の結果、他の親サーバが担当するエリアに対応するハッシュ値である場合(S55でNo)、対象親サーバは、検索された親サーバにそのリクエストを転送する(S56)。
検索の結果、自身が担当するエリアに対応するハッシュ値である場合(S55で「Yes」)、対象親サーバは、現在のエリア内サーバ数を確認し、サーバが追加された場合にエリア内のサーバ数が上限を超過するかどうか判定する(S57)。
サーバが追加された場合にエリア内のサーバ数が上限を超過しない場合(S57で「No」)は、対象親サーバは、図9(C)のフォーマットを用いて子CH構築に必要なサーバ宛先情報群を応答として参加要求サーバに返却する(S58)。
サーバが追加された場合にエリア内のサーバ数が上限を超過する場合(S57で「Yes」)は、対象親サーバは、参加要求サーバを含めて子CH表から、図15で説明したように、そのエリアの中間サーバを親サーバとして選出する(S59)。
選出された親サーバが既存サーバだった場合(S60で「No」)、対象親サーバは、参加要求サーバに対して、分割されたエリア内の子CH表を返却する(S62)。すなわち、対象親サーバは、参加要求サーバに、図9(C)のフォーマットを用いて、そのエリアの先頭から、選出されたサーバのハッシュ値までのハッシュ空間(エリア)に含まれる子サーバの宛先情報を参加要求サーバに返却する。対象親サーバは、選出された既存サーバに対して、親サーバへの昇格を通知する(S63)。
選出された親サーバが参加要求サーバだった場合(S60で「Yes」)、対象親サーバは、参加要求サーバに、親サーバへの昇格を通知する。また、対象親サーバは、参加要求サーバに、図9(C)のフォーマットを用いてそのエリアの先頭から参加要求サーバのハッシュ値までのハッシュ空間に含まれる子サーバの宛先情報を参加要求サーバに返却する(S61)。
その後、対象親サーバは、自身の有する親CH表49と子CH表50を更新する(S64)。すなわち、対象親サーバは、自身の有する親CH表49に、選出した親サーバを追加して、その親CH表49を更新する。また、対象親サーバは、自身の有する子CH表50から、S61、S62で参加要求サーバに通知した子サーバを除いた子サーバについての子CH表50を作成する。
対象親サーバは、その更新した親CH表及び子CH表を用いて、親サーバ同士及び当該親サーバが属するエリア内のネットワークの通信接続(経路情報)を更新する。これにより、親サーバと参加要求サーバとの通信が確立する。さらに、対象親サーバは、他の親サーバに対して、更新した親CH表49を送信する。また、対象親サーバは、エリア内の子サーバに対して、更新した子CH表50を送信する(S65)。このとき、子サーバから親サーバへ昇格した場合、エリア外の子サーバとの接続が切断される。
その後、対象親サーバは、クライアント31に、更新した親CH表59を通知し(S66)、本フローは終了する。
なお、図17では割愛しているが、エリア内のサーバ数の上限は1つのエリアを構築するために用いられる。親CHの階層レベルにも同様にサーバ数上限を当てはめると、この分割方法は入れ子(階層)構造にすることができる。
図18は、本実施形態におけるスプリット・ハッシュでのCH表のレプリケーションを説明するための図である。CH方式の分散データストアでは、分散システムの可用性を高めるためにデータの複製を作成する。図18(A)に示すように、子サーバ13がハッシュ空間から脱退する場合、ハッシュ空間上でのハッシュ値が増値する方向のサーバに、その脱退する子サーバ13のデータの複製が作成される。これにより、CHではハッシュ空間上の前のサーバ位置から次のサーバの位置までが担当空間になるため、前にあるサーバが離脱した時に迅速にその離脱したサーバのデータを復旧できる。
スプリット・ハッシュでは、親CH表49についての情報を隣接サーバに複製し、親サーバが離脱する場合に新たな親サーバとして隣のサーバが昇格する。図18(B)に示すように、通常のデータについては通常のCHと同じ方式に、ハッシュ空間上でのハッシュ値が増値する方向のサーバに、その脱退するサーバのデータの複製が作成される。しかし、親CH表49については、通常のデータとは反対の方向にあるサーバ上に複製が作成される。これは、親サーバ12はエリアの終端にあるという特性を維持するための挙動である。仮に、通常データと同じ方向に複製を作成した場合、親サーバの離脱に伴い「右隣」のサーバが親に昇格することになるので、新しい親サーバ12は、隣のエリアに属するサーバになる。そのため、エリア構成の変更およびネットワーク接続の張り直しが煩雑になる。それに対して、図18(B)に示すように、ハッシュ空間の減値方向に次の親サーバ候補を作ることで、エリア内のネットワーク情報の変動を離脱したサーバに絞ることができる。
図19は、本実施形態におけるサーバの脱退時でのスプリット・ハッシュに参加している各サーバが実行する処理フローを示す。このフローは、スプリット・ハッシュに参加している各サーバで実行されている。また、各サーバは、自身が親サーバか子サーバかを判定する情報及び当該エリア内の親サーバがどのサーバであるかを判定する情報を記憶部48に記憶している。
サーバ死活監視部47は、スプリット・ハッシュに参加しているいずれかのサーバがスプリット・ハッシュからの脱退を検出する(S71)。スプリット・ハッシュからのサーバの脱退を検出したサーバ(対象サーバ)は、自身の子CH表50からその脱退したサーバのサーバ情報構造体を削除し、アドレス情報1及びアドレス情報2を更新してリンクを再形成し、子CH表50を再構築する(S72)。
対象サーバの記憶部48に格納された情報に基づいて、脱退したサーバが子サーバであると判定した場合(S73で「No」)、対象サーバは、本フローを終了する。
対象サーバの記憶部48に格納された情報に基づいて、脱退したサーバが親サーバであると判定した場合(S73で「Yes」)、対象サーバは、自身が次の親であるか否かを判定する。ここでは、対象サーバは、対象サーバのハッシュ値と現在のエリア内にあるサーバの最大のハッシュ値とを比較することにより、自身が次の親であるか否かを判定することができる。
対象サーバ自身が次の親であると判定した場合(S74で「Yes」)、対象サーバは、記憶部48に、予め複製されて格納されていた親CH表49を用いて、各親サーバ12に対して、親サーバへの昇格を通知する(S76)。また、対象サーバは、親CH表49において、脱退した親サーバのサーバ情報構造体の「サーバ識別子」72、「ハッシュ値」73、「宛先情報」74を、自身の「サーバ識別子」、「ハッシュ値」、「宛先情報」で更新する(S77)。さらに、対象サーバは、更新した親CH表49の複製を、エリア内で、次に大きいハッシュ値を有する子サーバに送信する(S78)。その子サーバは、その親CH表の複製を記憶部48に格納する。
対象サーバ自身が次の親ではないと判定した場合(S74で「No」)、対象サーバは、他のサーバから通知された情報(S76)に基づいて、当該エリア内の親サーバがどのサーバであるかを判定する情報を更新して完了する(S75)。
(スプリット・ハッシュ空間の動的変化の実施例)
最後に、本実施形態で構築された分散システムにアクセスする場合の流れを簡単に説明する。クライアント31は、まず親CH表49を検索し、親サーバ12にアクセスする。こうして親サーバ12に通知されたキーとデータは、必ず該当エリア内に格納先が存在している。親サーバ12は自身が属するエリア内の全サーバの宛先情報を持っているので、1ホップで目的のサーバに到達できる。上述したように、分割を入れ子(階層化)にしている場合、親サーバが管理するサーバが1階層下の親サーバ群となる。この場合、目的地に到達するには更に1回のホップが必要となる。しかし、1サーバで管理できる宛先情報が仮にN(N:任意の整数)個だとすると、Nn台(n:任意の整数)のサーバ構成に対して情報量はΣN、ホップ回数は0〜n回で探索できるオーバーレイ・ネットワークを構築することができる。
なお、本実施形態では、エリアに属するサーバのうち、最もハッシュ値が高いサーバを親サーバとしたが、これに限定されず、エリアに属するサーバのうち、最もハッシュ値が小さいサーバを親サーバとしてもよい。
図20は、本実施形態の一実施例に係るコンピュータのハードウェア環境の構成ブロック図である。コンピュータ80は、親サーバ12、子サーバ13、またはクライアント31として用いることができる。
コンピュータ80は、出力I/F81、CPU82、ROM83、通信I/F84、入力I/F85、RAM86、記憶装置87、読み取り装置88、バス89を含む。コンピュータ80は、出力機器91、入力機器92と接続されている。
ここで、CPUは、中央演算装置であり、プロセッサの一例である。ROMは、リードオンリメモリを示す。RAMは、ランダムアクセスメモリを示す。I/Fは、インターフェースを示す。バス89には、出力I/F81、CPU82、ROM83、通信I/F84、入力I/F85、RAM86、記憶装置87、読み取り装置88が接続されている。読み取り装置88は、可搬型記録媒体を読み出す装置である。出力機器91は、出力I/F81に接続されている。入力機器92は、入力I/F85に接続にされている。
記憶装置87としては、ハードディスクドライブ、フラッシュメモリ装置、磁気ディスク装置など様々な形式の記憶装置を使用することができる。記憶装置87またはROM83には、例えば、本実施形態で説明した処理を実現するプログラムが格納されている。
また、コンピュータ80が親サーバ12である場合、記憶装置87またはROM83には、親CH表50、親サーバ12が属するエリアの子CH表50、サーバ管理情報65、エリア内サーバ数上限値等が格納されている。また、コンピュータ80が子サーバ12である場合、記憶装置87またはROM83には、当該エリアの子CH表50、サーバ管理情報65、エリア内サーバ数上限値等が格納されている。また、コンピュータ80がクライアント31である場合、記憶装置87またはROM83には、親CH表等が格納されている。
CPU82は、記憶装置87またはROM83に格納した本実施形態で説明した処理を実現するプログラムを読み出し、当該プログラムを実行する。
本実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク90、および通信I/F84を介して、例えば記憶装置87に格納してもよい。また、本実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置88にセットされて、CPU82によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはCD−ROM、フレキシブルディスク、光ディスク、光磁気ディスク、ICカード、USBメモリ装置など様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読み取り装置88によって読み取られる。
また、入力機器92には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレット、タッチパネルなどを用いることが可能である。また、出力機器91には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。また、ネットワーク90は、インターネット、LAN、WAN、専用線、有線、無線等の通信網であってよい。
なお、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
1 情報検索システム
2 情報処理端末
2−1 格納部
2−2 取得部
2−3 検索部
2−4 送信部
3 情報処理装置
3−1 取得部
3−2 格納部
3−3 検索部
3−4 送信部
3−5 分離制御部
3−6 脱退処理部
4 通信ネットワーク
12 親サーバ
13 子サーバ
30 分散システム
31 クライアント
32 通信ネットワーク
33 サーバ
41 通信制御部
42 データ処理部
44 構成管理部
45 親CH宛先管理部
46 子CH宛先管理部
47 死活監視部
48 記憶部
49 親CH表
50 子CH表
51 アプリケーション
52 ライブラリ
53 宛先制御部
54 親CH宛先管理部
55 通信制御部
56 記憶部
65 サーバ管理情報

Claims (7)

  1. 通信ネットワークを介して相互に通信可能に接続され、分散ハッシュ法によりハッシュ値を提供する分散ハッシュ情報に基づくハッシュ空間に対応付けられたいずれかのハッシュ値を有する情報処理装置であって、
    前記ハッシュ空間に対応付けられた該ハッシュ値の大きさの順に従って、複数のグループに分けられた各前記グループに属するいずれかの前記情報処理装置である第1装置同士についての前記ハッシュ空間における前記ハッシュ値を用いた分散ハッシュ情報を示す第1分散ハッシュ情報に基づいて他の前記情報処理装置から送信された、目的とする前記情報処理装置へのアクセスを要求するアクセス情報を取得する取得部と、
    前記第1装置が属するグループに属する前記情報処理装置である第2装置についての前記ハッシュ空間の前記ハッシュ値を用いた分散ハッシュ情報を示す第2分散ハッシュ情報を格納する格納部と、
    前記第2分散ハッシュ情報から、前記アクセス情報から生成したハッシュ値に対応する前記第2装置を検索する検索部と、
    検索された前記第2装置が前記複数のグループのうち他のグループに属する場合、前記第1分散ハッシュ情報を検索して、前記他のグループに属する第1装置に前記アクセス情報を送信し、検索された前記第2装置が自身のグループに属する場合、検索された前記第2装置に前記アクセス情報を送信する送信部と、
    前記情報処理装置が、前記第1装置が前記通信ネットワークより脱退した場合において、脱退した前記第1装置が属する前記グループに属する第2装置のうち前記脱退した第1装置の次に大きいまたは小さいハッシュ値を有する場合、他の前記情報処理装置に対して前記第2装置が前記第1装置が脱退したグループにおける第1装置である旨を、前記脱退の際に複製されて格納されていた前記第1分散ハッシュ情報を用いて通知すると共に、前記第2装置を前記第1分散ハッシュ情報に追加し前記他の情報処理装置または情報処理端末へ送信する脱退処理部と、
    を備えることを特徴とする情報処理装置。
  2. 前記情報処理装置が前記第1装置である場合、前記格納部は、さらに、前記第1分散ハッシュ情報を格納し、
    前記検索部は、前記取得されたアクセス情報が当該情報処理装置以外の前記第1装置が処理すべきアクセス情報である場合、前記第1分散ハッシュ情報から、前記アクセス情報から生成したハッシュ値に対応する前記第1装置を検索し、
    前記送信部は、検索された前記第1装置へ前記アクセス情報を送信する
    ことを特徴とすることを特徴とする請求項1に記載の情報処理装置。
  3. 前記情報処理装置は、さらに、
    いずれの前記グループにも属していない情報処理装置から、該第1装置が属する第1グループへの参加依頼が通知された場合、前記第1グループに属する前記第2装置の数と、所定の閾値とを比較し、該比較結果に応じていずれかの前記第2装置を選択し、該第1グループに対応するハッシュ空間の先頭から、選択した前記第2装置が有するハッシュ値までの範囲に含まれるハッシュ値を有する前記第2装置を前記第1グループから分離させ、該分離させた第2装置により形成されるグループについての前記第2分散ハッシュ情報を生成し、前記選択した第2装置を前記第1分散ハッシュ情報に追加する分離制御部
    を備えることを特徴とする請求項1または2に記載の情報処理装置。
  4. 前記各グループに属する前記第1装置と複数の前記第2装置との間はフルメッシュネットワークで接続されている、
    ことを特徴とする請求項1記載の情報処理装置。
  5. 前記検索部は、探索木を用いて前記第2装置を検索した結果、前記アクセス情報から生成したハッシュ値に対応する前記第2装置が見つからなかった場合、前記アクセス情報から生成したハッシュ値をゼロにして、前記探索木を用いた再度の検索を行う、
    ことを特徴とする請求項1記載の情報処理装置。
  6. 通信ネットワークを介して相互に通信可能に接続され、分散ハッシュ法によりハッシュ値を提供する分散ハッシュ情報に基づくハッシュ空間に対応付けられたいずれかのハッシュ値を有する情報処理装置に、
    前記ハッシュ空間に対応付けられた該ハッシュ値の大きさの順に従って、複数のグループに分けられた各前記グループに属するいずれかの前記情報処理装置である第1装置同士についての前記ハッシュ空間における前記ハッシュ値を用いた分散ハッシュ情報を示す第1分散ハッシュ情報に基づいて他の前記情報処理装置から送信された、目的とする前記情報処理装置へのアクセスを要求するアクセス情報を取得し、
    前記第1装置が属するグループに属する前記情報処理装置である第2装置についての前記ハッシュ空間の前記ハッシュ値を用いた分散ハッシュ情報を示す第2分散ハッシュ情報から、前記アクセス情報から生成したハッシュ値に対応する前記第2装置を検索し、
    検索された前記第2装置が前記複数のグループのうち他のグループに属する場合、前記第1分散ハッシュ情報を検索して、前記他のグループに属する第1装置に前記アクセス情報を送信し、検索された前記第2装置が自身のグループに属する場合、検索された前記第2装置に前記アクセス情報を送信し、
    前記情報処理装置が、前記第1装置が前記通信ネットワークより脱退した場合において、脱退した前記第1装置が属する前記グループに属する第2装置のうち前記脱退した第1装置の次に大きいまたは小さいハッシュ値を有する場合、他の前記情報処理装置に対して前記第2装置が前記第1装置が脱退したグループにおける第1装置である旨を、前記脱退の際に複製されて格納されていた前記第1分散ハッシュ情報を用いて通知すると共に、前記第2装置を前記第1分散ハッシュ情報に追加し前記他の情報処理装置または情報処理端末へ送信する
    処理を実行させることを特徴とする情報検索プログラム。
  7. 通信ネットワークを介して相互に通信可能に接続され、分散ハッシュ法によりハッシュ値を提供する分散ハッシュ情報に基づくハッシュ空間に対応付けられたいずれかのハッシュ値を有する情報処理装置を含む情報処理システムのいずれかの情報処理装置へアクセスする情報検索方法であって、
    前記複数の情報処理装置のうちいずれかの情報処理装置は、
    前記ハッシュ空間に対応付けられた該ハッシュ値の大きさの順に従って、複数のグループに分けられた各前記グループに属するいずれかの前記情報処理装置である第1装置同士についての前記ハッシュ空間における前記ハッシュ値を用いた分散ハッシュ情報を示す第1分散ハッシュ情報に基づいて他の前記情報処理装置から送信された、目的とする前記情報処理装置へのアクセスを要求するアクセス情報を取得し、
    前記第1装置が属するグループに属する前記情報処理装置である第2装置についての前記ハッシュ空間の前記ハッシュ値を用いた分散ハッシュ情報を示す第2分散ハッシュ情報から、前記アクセス情報から生成したハッシュ値に対応する前記第2装置を検索し、
    検索された前記第2装置が前記複数のグループのうち他のグループに属する場合、前記第1分散ハッシュ情報を検索して、前記他のグループに属する第1装置に前記アクセス情報を送信し、検索された前記第2装置が自身のグループに属する場合、検索された前記第2装置に前記アクセス情報を送信し、
    前記情報処理装置が、前記第1装置が前記通信ネットワークより脱退した場合において、脱退した前記第1装置が属する前記グループに属する第2装置のうち前記脱退した第1装置の次に大きいまたは小さいハッシュ値を有する場合、他の前記情報処理装置に対して前記第2装置が前記第1装置が脱退したグループにおける第1装置である旨を、前記脱退の際に複製されて格納されていた前記第1分散ハッシュ情報を用いて通知すると共に、前記第2装置を前記第1分散ハッシュ情報に追加し前記他の情報処理装置または情報処理端末へ送信する
    ことを特徴とする情報検索方法。
JP2012288855A 2012-12-28 2012-12-28 情報処理装置、情報処理端末、情報検索プログラム及び情報検索方法 Active JP6182861B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012288855A JP6182861B2 (ja) 2012-12-28 2012-12-28 情報処理装置、情報処理端末、情報検索プログラム及び情報検索方法
US14/105,656 US9319245B2 (en) 2012-12-28 2013-12-13 Information processing device, recording medium storing information search program, and information search method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012288855A JP6182861B2 (ja) 2012-12-28 2012-12-28 情報処理装置、情報処理端末、情報検索プログラム及び情報検索方法

Publications (2)

Publication Number Publication Date
JP2014130535A JP2014130535A (ja) 2014-07-10
JP6182861B2 true JP6182861B2 (ja) 2017-08-23

Family

ID=51018388

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012288855A Active JP6182861B2 (ja) 2012-12-28 2012-12-28 情報処理装置、情報処理端末、情報検索プログラム及び情報検索方法

Country Status (2)

Country Link
US (1) US9319245B2 (ja)
JP (1) JP6182861B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8966012B2 (en) * 2011-08-31 2015-02-24 Metaswitch Networks Ltd Processing data and operating a communications device
CN108011929B (zh) * 2017-11-14 2020-08-25 平安科技(深圳)有限公司 数据请求处理方法、装置、计算机设备和存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7418454B2 (en) * 2004-04-16 2008-08-26 Microsoft Corporation Data overlay, self-organized metadata overlay, and application level multicasting
JP4375303B2 (ja) 2005-08-19 2009-12-02 ブラザー工業株式会社 情報通信システム、情報通信方法、情報通信システムに含まれるノード装置、情報処理プログラムおよびノード装置のプログラム
JP2007156700A (ja) 2005-12-02 2007-06-21 Mitsubishi Electric Corp 情報検索方法、情報登録方法およびネットワークサービス情報検索システム
US8582469B2 (en) * 2007-11-14 2013-11-12 Cisco Technology, Inc. Peer-to-peer network including routing protocol enhancement
US20110153737A1 (en) * 2009-12-17 2011-06-23 Chu Thomas P Method and apparatus for decomposing a peer-to-peer network and using a decomposed peer-to-peer network
US8849825B1 (en) * 2010-12-23 2014-09-30 Amazon Technologies, Inc. System and method for clustering distributed hash table entries
US8675672B1 (en) * 2011-12-30 2014-03-18 Emc Corporation Hierarchical cluster tree overlay network
US20130263151A1 (en) * 2012-04-03 2013-10-03 Microsoft Corporation Consistent Hashing Table for Workload Distribution
US10069903B2 (en) * 2013-04-16 2018-09-04 Amazon Technologies, Inc. Distributed load balancer

Also Published As

Publication number Publication date
US9319245B2 (en) 2016-04-19
US20140188833A1 (en) 2014-07-03
JP2014130535A (ja) 2014-07-10

Similar Documents

Publication Publication Date Title
JP5551270B2 (ja) ピアツーピアネットワークを分解して、分解されたピアツーピアネットワークを使用するための方法および装置
US8296420B2 (en) Method and apparatus for constructing a DHT-based global namespace
US20140052817A1 (en) Method, apparatus, and network system for acquiring content
Hao et al. BlockP2P: Enabling fast blockchain broadcast with scalable peer-to-peer network topology
Takeda et al. Simple dynamic load balancing mechanism for structured p2p network and its evaluation
JP6182861B2 (ja) 情報処理装置、情報処理端末、情報検索プログラム及び情報検索方法
Yu et al. Granary: A sharing oriented distributed storage system
JP2008140388A (ja) 階層型ピアツーピアシステムにおける負荷バランシング機能を有するスーパーピア及び該スーパーピアを動作させる方法
Girdzijauskas et al. Fuzzynet: Ringless routing in a ring-like structured overlay
Cao et al. Cost-effective replication schemes for query load balancing in DHT-based peer-to-peer file searches
Lazaro et al. Decentralized resource discovery mechanisms for distributed computing in peer-to-peer environments
Sun et al. A lightweight data location service for nondeterministic exascale storage systems
Bouget et al. Polystyrene: the decentralized data shape that never dies
Wong et al. Approximate matching for peer-to-peer overlays with cubit
CN106527982B (zh) 一种针对由异构存储设备组成的对象存储系统的对象分布算法
Sun et al. SLUP: A semantic-based and location-aware unstructured P2P network
Obafemi-Ajayi et al. Cluster-k+: Network topology for searching replicated data in p2p systems
Liu et al. Double‐layer P2P networks supporting semantic search and keeping scalability
Ding et al. Performing MapReduce on data centers with hierarchical structures
Zhou et al. An effective pointer replication algorithm in P2P networks
Saju et al. Geographically Clustered P2P File Sharing
Olszak HyCube: A distributed hash table based on a variable metric
Guo et al. Theory and network applications of balanced kautz tree structures
Lin et al. A P2P framework for developing bioinformatics applications in dynamic cloud environments
Lebre et al. AS-cast: Lock Down the Traffic of Decentralized Content Indexing at the Edge

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150903

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160726

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160830

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161028

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170110

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170301

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: 20170627

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170710

R150 Certificate of patent or registration of utility model

Ref document number: 6182861

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150