オーバーレイネットワークの管理方法、その実行プログラム、その実行装置、その装置を含むシステム
【課題】 障害に対する対処が早く、オバーレイネットワークの信頼性を高める。
【解決手段】 オーバレイネットワーク10中の各ノード2,6,9,13は、アプリケーションデータと、このデータへのアクセスのためのノードを示すルーティングテーブル及びルーティングテーブルに示されているノードの通信アドレスを含む構成情報を保持している。管理装置100は、複数のノードから、各ノードが保持している構成情報を収集し、構成情報をOLN管理データベース140に格納するOLN構成情報管理部112と、複数のノードのそれぞれに対する通信を定期的に試みて、各ノードからの応答に応じて、ノードの状態を把握するノード状態監視部113と、いずれかのノード6が障害状態になると、ノード6の構成情報を用いて、ノード6の仮想ノード190を生成して起動させ、ノード6の通信アドレスとして、自装置の通信アドレスに変更する旨の通信アドレス切替指示を、他のノードに通知する仮想ノード生成部114と、を備えている。
【解決手段】 オーバレイネットワーク10中の各ノード2,6,9,13は、アプリケーションデータと、このデータへのアクセスのためのノードを示すルーティングテーブル及びルーティングテーブルに示されているノードの通信アドレスを含む構成情報を保持している。管理装置100は、複数のノードから、各ノードが保持している構成情報を収集し、構成情報をOLN管理データベース140に格納するOLN構成情報管理部112と、複数のノードのそれぞれに対する通信を定期的に試みて、各ノードからの応答に応じて、ノードの状態を把握するノード状態監視部113と、いずれかのノード6が障害状態になると、ノード6の構成情報を用いて、ノード6の仮想ノード190を生成して起動させ、ノード6の通信アドレスとして、自装置の通信アドレスに変更する旨の通信アドレス切替指示を、他のノードに通知する仮想ノード生成部114と、を備えている。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数のノードを備えたオーバーレイネットワークの管理技術に関する。
【背景技術】
【0002】
近年、通信ネットワークに接続された端末数が爆発的に増え、これら端末からの要求に応えるサーバの処理能力が不足することが度々生じている。そこで、各端末からの要求に応えるための処理をネットワーク全体に分散させる技術が採用されることが多くなってきている。
【0003】
このような技術として、DHT(Distributed Hash Table:分散ハッシュテーブル)を用いたオーバーレイネットワーク技術がある。オバーレイネットワークとは、既存のリンク上に仮想的なリンクを形成して構成されるネットワークである。このオバーレイネットワークでは、処理の中心となるサーバを設けず、サービス対象の情報からハッシュ関数を用いてハッシュ値を生成し、このハッシュ値と対応するノードに、サービス対象の情報を分散格納することで、処理能力の分散化を図っている。ここで、上記DHTとは、サービス対象の情報IDとそのハッシュ値とを関係付けるテーブルのことである。
【0004】
このオーバレイネットワークの形成技術に関しては、例えば、以下の特許文献1や非特許文献1に開示されている。
【0005】
非特許文献1では、さらに、複数のノードのうちの一つのノードに障害が生じたときの対処方法についても開示されている。
【0006】
この障害対処方法は、各ノードの各種情報を何らかの形で逐次保持しておき、あるノードに障害が生じたときに、他のノードに、障害のあったノードの機能を追加し、この他のノードに、障害のあったノードの機能を代替させるという方法である。各ノードの各種情報としては、サービス対象の情報の他、サービス対象の情報を検索するために問い合わせるノードを示す各ハッシュ値毎のルーティング情報や、このハッシュ値毎のルーティング情報に示されているノードの通信アドレスを含むノード管理情報等の構成情報がある。
【0007】
この障害対処方法では、障害のあったノードの各種情報を他のノードに移植すると共に、障害のあったノードがオーバーレイネットワーク上に存在しないことになるため、各ノード毎に、新たなルート情報を作成する必要がある。
【0008】
【特許文献1】特開2006−191489号公報
【非特許文献1】「分散ハッシュテーブルの軽量な負荷分散手法の検討」 社団法人 電子情報通信学会 信学技報
【発明の開示】
【発明が解決しようとする課題】
【0009】
上記障害対処方法では、前述したように、各ノード毎に新たなルーティング情報等を作成するために、各ノード相互間で多くの情報のやりとりする必要がある。このため、この方法では、ネットワーク上のオーバーヘッドが増大する上に、障害が発生してから、これの対処が終了するまでに時間がかかり、障害ノードに対応するノードが存在しない時間が比較的長くなってしまう。特に、この方法では、あるノードに何らかの一時的な通信障害が生じた場合でも、上記障害対処を実行すると、却って、障害ノードに対応するノードが存在しない時間が長くなってしまう。このことから、オーバネットネットワークのユーザからは、このオーバーレイネットワークの信頼性をより高めてほしいという要望が生じている。
【0010】
そこで、本発明では、障害に対する対処が早く、オバーレイネットワークの信頼性を高めることができる技術を提供することを目的とする。
【課題を解決するための手段】
【0011】
前記目的を達成するため、本発明では、
複数のノードが保持している、データと、このデータへのアクセスのためのノードを示すルート情報及び該ルート情報に示されているノードの通信アドレスを含む構成情報とのうち、少なくとも前記構成情報を収集し、該構成情報をコンピュータの記憶装置に格納する。さらに、前記複数のノードのそれぞれに対する通信を定期的に試みて、各ノードからの応答に応じて、該複数のノードの状態を把握する。
【0012】
把握された前記複数のノードの状態のうち、いずれかのノードの状態が予め定めた障害状態である場合には、前記記憶装置に格納されている該ノードの前記構成情報を用いて、該ノードに関して、他のノードからアクセス可能な仮想ノードを前記コンピュータ上に生成し、該仮想ノードを起動させる。該仮想ノードが起動すると、前記予め定めた障害状態であるとされた前記ノードの通信アドレスとして、該ノードの仮想ノードが生成された前記コンピュータの通信アドレスへの切替える旨の通信アドレス切替指示を、前記他のノードに通知して、該他のノードが前記予め定めた障害状態であるとされた該ノードにアクセスしようとしている場合に、該ノードの仮想ノードにアクセスさせる。
【発明の効果】
【0013】
本発明によれば、ある実ノードに予めさだめた障害が生じた場合、この実ノードの仮想ノードを生成し、これに伴って、各ノードの構成情報中の障害ノードの通信アドレスの切替処理のみで、障害に対処しているので、ネットワーク上のオーバーヘッドが増大を防ぎ、しかも、所定の障害への対処時間を極めて短時間化することができる。
【発明を実施するための最良の形態】
【0014】
以下、本発明に係るオーバーレイネットワークシステムの一実施形態について、図面を用いて説明する。
【0015】
本実施形態のオーバーレイネットワークシステムは、図1に示すように、複数のノード200b〜200eとこれら複数のノード200b〜200eを含むオーバーレイネットワーク(以下、OLN)10を管理するOLN管理装置100と、複数のノードが保持しているアプリケーション(以下、APとする)データを利用するユーザ端末300と、を備えている。
【0016】
複数のノード200b〜200eは、LAN2に接続されているアクセスポイント3と無線通信することができる。各LAN2は、WAN1に図示されていないルータを介して、WAN1と接続されている。OHL管理装置100及びユーザ端末300は、いずれも、図示されていないルータを介して、WAN1と接続されている。
【0017】
本実施形態では、WAN1及び複数のLAN2,2,…上に、一つの仮想的なネットワーク、つまりオーバレイネットワーク10を形成し、OHL管理装置100及び複数のノード200b〜200eは、このオバーレイネットワーク10上で、各ネットワークセグメントによる分断を意識せずに、互いに通信することができる。なお、OLNシステムを構成する各装置のうち、ユーザ端末300は、オバーレイネットワーク10上に存在するものではない。
【0018】
各ノード200b〜200eには、RFID(Radio Frequency IDentification)タグ5と無線通信するRFIDリーダ270が接続されている。このRFIDタグ5は、ユーザが指定した人物が保持しているもので、このユーザのIDが記憶されている。RFIDリーダ270は、このRFIDタグ5と無線通信して、このRFIDタグ5からユーザID情報を取得し、これを接続先のノードに送る。各ノード200b〜200eは、RFIDリーダ270から送られてきたユーザIDと、これに対するデータIDと、RFIDタグ5を保持していた人物の位置、つまりユーザ座標値と、を相互に関連付けて、これらのデータを、後述のAPデータテーブルに格納する。データIDは、ユーザIDのハッシュ値であり、ユーザIDが定められた時点で定められる値である。また、ユーザ座標値は、ユーザIDを検知したRFIDリーダ270の設置箇所の座標値(緯度、経度)である。このため、各ノード200b〜200eには、自ノードに接続されているRFIDリーダ270の設置箇所の座標値が予め記憶されており、この座標値が検知された人物の座標値、つまりユーザ座標値となる。
【0019】
OLN管理装置100は、機能的に、OLN10を管理するOLN管理部111と、ユーザ端末300からの要求に対処するユーザ要求対処部119と、ノード「0」170と、を有している。前述のユーザ座標値は、ユーザ毎に、このノード「0」170と、以上で説明した複数のノード200b〜200eとに分散されて、格納されている。
【0020】
各ノード200b〜200eは、図4に示すように、各種演算処理を実行するCPU210と、このCPU210のワークエリアとなるメモリ220と、各種データが格納されている外部記憶装置230と、ネットワーク通信を行う通信装置261と、可搬型ディスク記憶媒体Dに対してデータの再生及び記録を行うディスク記憶再生装置262と、RFIDリーダ270のインタフェースである入出力インタフェース263と、を備えている。なお、同図では、ノード「6」200cの構成を示しているが、他のノード200b〜200eも、ノード「6」200cの構成と同じである。
【0021】
ノード「6」200cの外部記憶装置130には、ノード「6」の各種データが格納されるノード6管理データベース250cが設けられている。さらに、この外部記憶装置130には、ユーザIDとハッシュ値であるデータIDとの対応関係を示すハッシュテーブル234と、このノード「6」200cに接続されているRFIDリーダ270からのデータを受け付けるAPプログラム231と、OLN管理装置100からノード「6」への要求等に応えるためのノード用OLN管理プログラム237と、ノード「6」が他のノードと通信して、ノードとしての機能を実現するためのOLNプログラム238と、が予め格納されている。
【0022】
ハッシュテーブル234は、図5に示すように、ユーザIDが格納されるユーザID領域234sと、ハッシュ値であるデータIDが格納されるデータID領域234tと、を有している。このハッシュテーブル234は、ユーザの加入又は脱退により更新される。
【0023】
ノード6管理データベース150aには、図4に示すように、予め定められたユーザIDのユーザ座標が格納されるAPデータテーブル251cと、ノード「6」200cが管理するデータのIDや、ノード「6」200cの通信相手等になる関連ノードの通信アドレスが格納されている管理テーブル252cと、ノード「6」200cがアプリケーションデータであるユーザ座標を検索するために問い合わせるノードを示すルーティングテーブル253cと、が設けられている。
【0024】
APデータテーブル251cは、図6に示すように、ノード「6」200cが管理するデータのID(ハッシュ値)が格納されているデータID領域251sと、データIDに対応するユーザIDが格納されているユーザID領域251tと、当該ユーザのIDが検知された時刻が格納される時刻領域251uと、当該ユーザの座標が格納されるユーザ座標領域251vと、を有している。なお、他のノード170,200b,200d,200eも、それぞれ、同様のAPデータテーブル151a,251b,251d,251eを備えている。
【0025】
ルーティングテーブル253cは、図7に示すように、適用データIDが格納されている適用データID領域253sと、適用データIDのデータを検索等のために問い合わせるノード名が格納されている次ノード名領域253tと、を有している。このルーティングテーブル253cは、自ノードで管理していないデータの検索問合せがあった場合に、いずれのノードに検索問合せをすればよいかを示すものであるため、適用データID領域253cには、自ノードで管理していないデータのIDが格納される。例えば、ノード「6」200cでは、後述するように、データIDが「3」「4」「5」「6」のデータを管理するので、これらのデータIDを除くデータIDが適用データID領域253cに格納される。また、同図中のルーティングテーブル253cでは、適用データID領域253cに「7〜9」が格納され、対応する次ノード領域253tに「9」が格納されているが、これは、データIDが「7」「8」「9」のいずれかに関するデータの検索等の問合せがあった場合、ノード「9」に問い合わせることを示している。なお、他のノード170,200b,200d,200eも、それぞれ、同様のルーティングTL153a,253b,253d,253eを備えている。
【0026】
管理テーブル252cは、図8に示すように、自ノードが管理するデータのIDが格納されている管理データのデータID領域252sと、ルーティングテーブル253cで定められている次ノードの通信アドレスが格納されている次ノードアドレス領域252tと、論理上で自ノードに対して前側に隣接している隣接ノードの通信アドレスが格納されている前隣接ノードアドレス領域252uと、論理上で自ノードに対して後側に隣接している隣接ノードの通信アドレスが格納されている後隣接ノードアドレス領域252vと、を有している。同図中の管理テーブル252cでは、管理データのデータID領域252sに、「3,4,5,6」が格納されているが、これは、自ノード「6」がデータID「3」「4」「5」「6」のデータを管理していることを示している。なお、他のノード170,200b,200d,200eも、それぞれ、同様の管理TL152a,252b,252d,252eを備えている。
【0027】
ノード「6」200cのCPU210は、機能的に、図4に示すように、このノード「6」200cに接続されているRFIDリーダ270からのデータを受け付けるAPデータ入出力制御部211と、OLN管理装置100から自ノード「6」への要求等に応えるノード用OLN管理部217と、このノード「6」200cが他のノードと通信して、ノードとしての機能を実現するOLN制御部218と、を有している。以上のAPデータ入出力制御部211、ノード用OLN管理部217、OLN制御部218は、それぞれ、CPU210が、外部記憶装置230に格納されているAPプログラム231、ノード用OLN管理プログラム237、OLNプログラム238を実行することで機能する。
【0028】
OLN管理装置100は、図2に示すように、各種演算処理を実行するCPU110と、このCPU110のワークエリアとなるメモリ120と、各種データが格納されている外部記憶装置130と、ネットワーク通信を行う通信装置161と、キーボードやディスプレイ等の入出力装置164と、そのインタフェース163と、可搬型ディスク記憶媒体Dに対してデータの再生及び記録を行うディスク記憶再生装置162と、を備えている。
【0029】
外部記憶装置130には、各ノード170,200b〜200eのデータ等を管理するためのOLN管理データベース140と、前述のノード「0」170の構成要素としてのノード0管理データベース150aとが設けられている。さらに、この外部記憶装置130には、前述のOLN管理部111の機能を実現するためのOLN管理プログラム131と、OLN管理部111からノード「0」170への要求等に応えるためのノード用OLN管理プログラム137と、ノード「0」170が他のノード200b〜200eと通信して、ノードとしての機能を実現するためのOLNプログラム138と、ユーザ端末300からの要求に対処するためのユーザ要求対処プログラム139と、が予め格納されている。
【0030】
OLN管理データベース140には、各ノード170,200b〜200eの状態が格納されるノード状態テーブル141と、OLN管理部111が各種制御を行う際の制御ポリシーが格納されている制御ポリシーテーブル142と、ハッシュテーブル144と、各ノード170,200b〜200eが保持しているノード管理データベースのコピーであるノード管理データベース150ac,250bc,250cc,250dc,250ecとが設けられている。
【0031】
OLN管理データベース140中のノード状態テーブル141は、図9に示すように、ノード名が格納されているノード名領域141sと、当該ノードの通信アドレスが格納されているノードアドレス領域141tと、当該ノードの状態が格納される状態領域141uと、を有している。この状態領域141には、「正常」「障害危機」「障害」のいずれかが格納される。
【0032】
OLN管理データベース140中の制御ポリシーテーブル142は、図9に示すように、ポリシー番号が格納されているポリシーNo領域142sと、制御ポリシーの内容が格納されている制御ポリシー内容領域142tと、該当制御ポリシー内容に対して定めた値が格納される値領域142uと、を有している。この制御ポリシーテーブル142の各領域のうち、ポリシーNo領域142s及び制御ポリシー内容領域142tには、予めデータが格納されている。また、この制御ポリシーテーブル142の値領域142uには、制御ポリシー設定部115により、入出力装置164又はディスク記憶再生装置162から取得された値が格納される。なお、この制御ポリシーテーブル142の具体的な制御ポリシー内容及びその値に関しては、後述する。
【0033】
ハッシュテーブル144は、図5を用いて説明したハッシュテーブル234と同一である。
【0034】
ノード0管理データベース150aには、図2に示すように、他のノード200b〜200eのノード管理データベース250b〜250eと同様に、APデータテーブル151aと、管理テーブル152aと、ルーティングテーブル153aと、が設けられている。
【0035】
OLN管理装置100のCPU110は、機能的に、前述のOLN管理部111と、OLN管理部111からノード「0」170(図1に示す)への要求等に応えるノード用OLN管理部117と、ノード「0」170が他のノードと通信して、ノードとしての機能を実現するOLN制御部118と、ユーザ端末300からの要求に対処するユーザ要求対処部119と、を有している。さらに、OLN管理部111は、各ノード170,200b〜200e毎の管理データを収集し、これをOLN管理データベース140の該当位置に格納するOLN構成情報管理部112と、各ノード170,200b〜200eと定期的に通信して、各ノードの状態を監視するノード状態監視部113と、いずれかのノードに障害が発生したときにこのノードの仮想ノードを生成する仮想ノード生成部114と、OLN管理部111が各種制御を行う際の制御ポリシーを外部から受け付けて、これを制御ポリシーテーブル142に格納する制御ポリシー設定部115と、以上のOLN管理部111の各機能部がオーバレイネットワーク10を介して他のノード等と通信するためのOLN通信制御部116と、を有している。以上の各機能部のうち、OLN管理部111は、外部記憶装置130に格納されているOLNプログラム131をCPU110が実行することで機能する。また、ノード用OLN管理部117、OLN制御部118、ユーザ要求対処部119は、それぞれ、外部記憶装置130に格納されているノード用OLN管理プログラム137、OLNプログラム138、ユーザ要求対処プログラム139を実行することで機能する。
【0036】
なお、図1に示すノード「0」170は、ノード用OLN管理部117と、OLN制御部118と、ノード0管理データベース150aと、ハッシュテーブル144とを有して構成される。
【0037】
次に、図11に示すシーケンス図に従って、各ノードが正常な場合のオーバーレイネットワークシステムの動作について説明する。なお、ここでは、ノード「9」200dに接続されているRFIDリーダ270がユーザID「yamada」を検知し、このユーザID「yamada」のユーザがユーザ端末300から、位置情報の提示要求をした場合の動作について説明する。
【0038】
ユーザID「yamada」が格納されているRFIDタグ5を保持している人物が、ノード「9」200dに接続されているRFIDリーダ270の傍を通ると、このRFIDリーダ270は、この人物が保持しているRFIDタグ5からユーザID「yamada」を取得し、このユーザID「yamada」をノード「9」200dへ送る。これにより、ノード「9」200dは、ユーザID「yamada」(データID「4」)を検知することになる(S11)
ノード「9」200dのAPデータ入出力部211は、このユーザID「yamada」を受け取ると、このユーザID「yamada」と共に、現在の時刻、RFIDリーダ270の座標値(緯度、経度)をOLN制御部218に渡す。OLN制御部218は、このユーザID「yamada」を受け取ると、ハッシュテーブル234(図5)を参照して、ユーザID「yamada」に対するデータID(ハッシュ値)「4」を取得する。次に、OLN制御部218は、自ノード「9」200dの管理テーブル252d(図8)の管理データのデータID領域252sを参照して、このデータID「4」が自ノード9で管理するデータであるか否かを判断する。仮に、このデータID「4」が自ノード9で管理するデータである場合には、APデータテーブル251d(図6)の検知時刻領域251u中の対応領域に現在の時刻を検知時刻として格納すると共に、ユーザ座標領域251v中の対応領域に、RFIDリーダ270の座標値(緯度、経度)をユーザ座標値として格納する。
【0039】
しかしながら、この場合、管理テーブル252d(図8)の管理データのデータID領域252sには、このデータID「4」がないので、このデータID「4」は自ノード9で管理するデータではない。そこで、OLN制御部218は、自ノード「9」200dのルーティングテーブル253d(図7)を参照して、このデータID「4」に関するデータの送出先である次ノード名「2」を取得する。続いて、自ノード「9」200dの管理テーブル252dの次ノードアドレス領域252tから、次ノード名「2」の通信アドレス「192.168.10.2」を取得する。そして、OLN制御部218は、この通信アドレス「192.168.10.2」が示すノード2へ、このデータID「4」と、検知時刻と、RFIDリーダ270の座標値(緯度、経度)、つまりユーザ座標値とを含むAPデータの登録メッセージを送信する(S12)。
【0040】
ノード「2」200bのOLN制御部218は、ノード「9」200dからAPデータの登録メッセージを受け付けると、自ノード「2」200bの管理テーブル252b(図8)の管理データのデータID領域252sを参照して、このデータID「4」が自ノード9で管理するデータであるか否かを判断する。この場合も、管理テーブル252b(図8)の管理データのデータID領域252sには、このデータID「4」がないので、このデータID「4」のAPデータは自ノード2で管理するデータではないと判断する。次に、OLN制御部218は、自ノード「2」200bのルーティングテーブル253b(図7)を参照して、このデータID「4」に関するデータの送出先である次ノード名「6」を取得すると共に、自ノード「2」200bの管理テーブル252bの次ノードアドレス領域252tから、次ノード名「6」の通信アドレス「192.168.10.6」を取得する。そして、OLN制御部218は、この通信アドレス「192.168.10.6」が示すノード6へ、このAPデータの登録メッセージを送信する(S13)。
【0041】
ノード「6」200cのOLN制御部218は、ノード「2」200bからAPデータの登録メッセージを受け付けると、自ノード「6」200cの管理テーブル252c(図8)の管理データのデータID領域252sを参照して、このデータID「4」が自ノード9で管理するデータであるか否かを判断する。この場合、管理テーブル252c(図8)の管理データのデータID領域252sには、このデータID「4」があるので、このデータID「4」のAPデータは自ノード2で管理するデータであると判断する。そして、OLN制御部218は、自ノード「6」200cのAPデータテーブル251c(図6)中のデータID「4」のレコードに、このAPデータに含まれている現在の時刻及びユーザ座標値を登録する(S14)。
【0042】
一方、このデータID「4」に対応するユーザID「yamada」のユーザが、自ユーザID「yamada」の位置情報を取得したい場合には、ユーザ端末300に自ユーザID「yamada」を入力し(S21)、このユーザID「yamada」の位置情報の提示要求メッセージをOLN管理装置100へ送信する(S22)。
【0043】
OLN管理装置100のユーザ要求対処部119は、この位置情報の提示要求メッセージを受け取ると、ノード「0」170の構成要素であるOLN制御部118に、このメッセージを渡す(S23)。ノード「0」170のOLN制御部118は、まず、ハッシュテーブル144(図5)を参照して、このメッセージに含まれているユーザID「yamada」に対するデータID(ハッシュ値)「4」を取得する。次に、OLN制御部118は、自ノード「0」170の管理テーブル152a(図8)の管理データのデータID領域252sを参照して、このデータID「4」のAPデータは自ノード0で管理しているデータであるか否かを判断する。この場合、管理テーブル152a(図8)の管理データのデータID領域252sには、このデータID「4」がないので、このデータID「4」のAPデータは自ノード0で管理していないと判断する。次に、OLN制御部118は、自ノード「0」170のルーティングテーブル153a(図7)を参照して、このデータID「4」に関するAPデータの検索先である次ノード名「6」を取得すると共に、自ノード「0」170の管理テーブル152aの次ノードアドレス領域252tから、次ノード名「6」の通信アドレス「192.168.10.6」を取得する。そして、OLN制御部118は、この通信アドレス「192.168.10.6」が示すノード6へ、このデータID「4」の検索要求メッセージを送信する(S24)。
【0044】
ノード「6」200cのOLN制御部218は、ノード「0」170からデータID「4」の検索要求メッセージを受け付けると、自ノード「6」200cの管理テーブル252c(図8)の管理データのデータID領域252sを参照して、このデータID「4」は自ノード9で管理しているデータであるか否かを判断する。この場合、管理テーブル252c(図8)の管理データのデータID領域252sには、このデータID「4」があるので、このデータID「4」のAPデータは自ノード2で管理しているデータであると判断する。そして、OLN制御部218は、自ノード「6」200cのAPデータテーブル251c(図6)中のデータID「4」のレコードから、検知時刻及びユーザ座標値を取得する。そして、この検知時刻及びユーザ座標値とデータID「4」とを含むAPデータを位置情報として、検索要求元のノード「0」170へ送る(S25)。
【0045】
ノード「0」170がこのAPデータを受け取ると、このAPデータをユーザ要求対処部119に渡す(S26)。ユーザ要求対処部119は、このAPデータを受け取ると、このAPデータに含まれている検知時刻及びユーザ座標値をユーザ端末300へ送る(S27)。なお、ユーザ座標値は、経度、緯度で表されているものであるため、ユーザがこのユーザ座標値を見ても、このユーザ座標値が示す位置を把握しにくいため、このユーザ座標値が示す地点をマークした地図を、ユーザ端末300へ送るようにしてもよい。
【0046】
次に、図12に示すシーケンス図に従って、ノード「6」200cに障害が発生した場合のオーバーレイネットワークシステムの動作について説明する。なお、ここでも、ノード「9」200dに接続されているRFIDリーダ270がユーザID「yamada」を検知し、このユーザID「yamada」のユーザがユーザ端末300から、位置情報の提示要求をした場合の動作について説明する。
【0047】
例えば、ノード「6」200cとアクセスポイント3との間に障害物が入り込む、両者の間の電波に対する干渉波が発生する等の無線障害が生じた場合や、このアクセスポイント3が接続しているLAN2の通信トラフィックが非常に高まってしまった場合等で、ノード「6」200cが他のノード170,200a,200b,200d,200eとの通信に障害が発生したとする(S1)。
【0048】
OLN管理装置100のOLN管理部111は、この障害を検知すると(S2)、OLN管理装置100内に仮想ノード「6」190を生成し、これを起動させる(S3)。なお、ノード「6」200cに障害検知に関しては、後ほど詳細に説明するが、OLN管理部111のノード状態監視部113が、定期的に各ノードに状態確認メッセージを送出し、このメッセージの応答に応じて障害を検知する。また、仮想ノード「6」190は、OLN管理部の仮想ノード生成部114が生成する。OLN管理部111のOLN構成情報管理部115は、後述するように、各ノードから定期的に各ノードが保持しているノード管理データベースを収集しており、これをOLN管理データベース140(図2)に格納している。仮想ノード生成部114は、このOLN管理データベース140中のノード6管理データベース250ccを用いて、仮想ノード「6」190を生成する。
【0049】
仮想ノード「6」190は、図3に示すように、OLN管理装置100のCPUとメモリとの複合体180上に生成される。この仮想ノード「6」190は、実ノード「6」200cと同様に、ノード用OLN管理部197とOLN制御部198とノード6管理データベース195とを有している。ノード6管理データベース195は、実ノード「6」200cのノード6管理データベース250cと同様に、APデータテーブル191と管理テーブル192とルーティングテーブル193とを有している。また、この仮想ノード「6」190は、RFIDリーダ270が接続されておらず、この関係で、実ノード「6」200cのAPデータ入出力制御部211に対応するものを有していない。したがって、仮想ノード「6」190は、APデータやノード構成情報の管理機能を有しているものの、ユーザIDの検知機能を有していない。
【0050】
OLN管理装置100のOLN管理部111は、次に、実ノード「6」を除く他の実ノードに対して、ノード「6」の新たな通信アドレスへの切替指示メッセージを送出する(S4)。この切替指示メッセージ中に含まれるノード6の新たな通信アドレスは、仮想ノード「6」190が作成されているOLN管理装置100の通信アドレス「192.168.10.100」である。なお、この通信アドレス「192.168.10.100」は、ノード「0」170の通信アドレスでもある。
【0051】
実ノード「6」200c及び仮想ノード「6」190を除く各ノード170,200b,200d,200eのノード用OLN管理部217は、この切替指示メッセージを受け取ると、自ノード管理データベース中の管理テーブル152a,252b,252d,252e中で、実ノード「6」の通信アドレスが格納されている部分が存在する場合には、この部分をノード6の新たな通信アドレス「192.168.10.100」に切り替える(S5)。
【0052】
以上で、実ノード「6」200c及び仮想ノード「6」190を除く各ノード170,200b,200d,200eは、実ノード「6」200cに障害が発生したこと、及びこの障害により仮想ノード「6」170が生成されたことを認識することなく、仮想ノード「6」190を実ノード「6」200cとして扱うことになる。
【0053】
ところで、「背景技術」の欄で説明したように、従来、あるノードに所定の障害が生じた場合、このノードの機能を他の健全なノードに移植し、障害のあったノードをオーバーレイネットワーク上にから離脱させている。このため、各ノードは、ルーティングテーブルや管理テーブル等を更新する必要が生じて、各ノード相互間で多くの情報のやりとりすることになる。この結果、従来の技術では、ネットワーク上のオーバーヘッドが増大する上に、所定の障害への対処時間の長時間化してしまう。
【0054】
これに対して、本実施形態では、あるノード「6」200cに所定の障害が生じた場合、このノード「6」200cの仮想ノード「6」190を生成し、これに伴って、各ノードの管理テーブル中の障害ノード「6」の通信アドレスの切替処理のみで、障害に対処しているので、ネットワーク上のオーバーヘッドが増大を防ぎ、しかも、所定の障害への対処時間を極めて短時間化することができる。
【0055】
以上の状態で、ユーザID「yamada」が格納されているRFIDタグ5を保持している人物が、ノード「9」200dに接続されているRFIDリーダ270の傍を通ると、このRFIDリーダ270は、この人物が保持しているRFIDタグ5からユーザID「yamada」を取得し、このユーザID「yamada」をノード「9」200dへ送る。これにより、ノード「9」200dは、ユーザID「yamada」(データID「4」)を検知することになる(S11)
ノード「9」200dは、図11のステップ12の処理と同様に、データID「4」と、検知時刻と、ユーザ座標値とを含むAPデータの登録メッセージをノード「2」へ送信する(S12)。
【0056】
ノード「2」200bは、この登録メッセージを受け付けると、図11のステップ13の処理と同様に、この登録メッセージをノード6へ送信する(S13a)。但し、この場合、このデータID「4」に関するデータの送出先である次ノード名「6」の通信アドレスが実ノード「6」200cの通信アドレス「192.168.10.6」から、仮想ノード「6」190の通信アドレス「192.168.10.100」へ切り替わっているため、データID「4」に関するAPデータの登録メッセージは、仮想ノード「6」190へ送信される。
【0057】
仮想ノード「6」190のOLN制御部198は、ノード「2」200bからAPデータの登録メッセージを受け付けると、自ノード「6」190のAPデータテーブル191中のデータID「4」のレコードに、このAPデータに含まれている現在の時刻及びユーザ座標値を登録する(S14a)。
【0058】
一方、このデータID「4」に対応するユーザID「yamada」のユーザが、自ユーザID「yamada」の位置情報を取得したい場合には、図11のステップ21及びステップ22と同様に、ユーザ端末300に自ユーザID「yamada」を入力し(S21)、このユーザID「yamada」の位置情報の提示要求メッセージをOLN管理装置100へ送信する(S22)。
【0059】
OLN管理装置100のユーザ要求対処部119は、この位置情報の提示要求メッセージを受け取ると、ノード「0」170の構成要素であるOLN制御部118に、このメッセージを渡す(S23)。ノード「0」170のOLN制御部118は、図11のステップ24と同様に、ユーザID「yamada」に対するデータID「4」の検索要求メッセージをノード6へ送信する(S24a)。但し、この場合も、このデータID「4」に関するデータの送出先である次ノード名「6」の通信アドレスが実ノード「6」200cの通信アドレス「192.168.10.6」から、仮想ノード「6」190の通信アドレス「192.168.10.100」へ切り替わっているため、データID「4」の検索要求メッセージは、仮想ノード「6」170へ送信される。
【0060】
仮想ノード「6」190のOLN制御部198は、ノード「0」170からデータID「4」の検索要求メッセージを受け付けると、図11のステップ25と同様に、自仮想ノード「6」190のAPデータテーブル191中のデータID「4」のレコードから、検知時刻及びユーザ座標値を取得し、これらを含むAPデータを位置情報として、検索要求元のノード「0」170へ送る(S25a)。
【0061】
以下、図11のステップ26,27と同様の処理が実行されて、対象者の検知時刻及びユーザ座標値がユーザ端末300へ送られる。
【0062】
次に、図13及び図14に示すフローチャートに従って、OLN管理装置100のOLN管理部111の動作について説明する。
【0063】
OLN管理部111のノード状態監視部113は、先に状態確認メッセージを各ノードに送出してから、予め定めた状態確認インターバルを経過したか否かを判断する(S31)。この状態確認インターバルは、図10に示す制御ポリシーテーブル142のポリシーNo1に規定されており、ここでは60秒である。ノード状態監視部113は、状態確認インターバルを経過したと判断すると、状態確認メッセージを各ノードに送出する(S32)。なお、ここで、状態確認メッセージを送出するノードは、実ノードのみで、仮想ノードは含まれない。また、図10に示す制御ポリシーテーブル142のポリシーNo6に規定されているように、ノード管理データの更新インターバルも、状態確認インターバルと同じ60秒であり、ここでは、この状態確認メッセージが、各ノードに対するノード管理データの送信要求も兼ねている。
【0064】
各ノードは、この状態確認メッセージを受信すると、ノードのノード用OLN管理部217が、自ノードのノード管理データベースに格納されている全データを取得し、この全データを含めた応答メッセージをOLN管理装置100へ返す。
【0065】
OLN管理装置100のノード状態監視部113は、状態確認メッセージを送出すると、このメッセージに対して、第一の待ち時間以内にノードからの応答があったか否かを判断する(S33)。この第一の待ち時間は、図10に示す制御ポリシーテーブル142のポリシーNo2に規定されており、ここでは30msである。第一の待ち時間以内にノードからの応答があった場合、この応答には、前述したように、応答ノードのノード管理データ、つまり応答ノードが管理しているノード管理データベース内のデータが含まれているので、OLN管理部111のOLN構成情報管理部112は、このノード管理データを該当ノードのノード管理データベースに格納する(S34)。例えば、ノード0,2,6,9,13のそれぞれから応答があった場合には、これらの応答に含まれているノード管理データを、該当ノード0,2,6,9,13のノード管理データベース150ac,250bc,250cc,250dc,250ecに格納する。なお、ここでは、応答中に、自ノードが管理しているノード管理データベース内の全てのデータが含まれているが、ノード管理データベース内のデータのうち、APデータテーブルのデータは含めなくてもよい。但し、ここでは、図10に示す制御ポリシーテーブル142のポリシーNo5に規定されているように、APデータの保持することを選択しているので、このAPデータが応答中に含まれている。また、ここでは、OLN管理装置100内に生成されているノード「0」170が管理しているノード管理データベース150aのデータも収集しているが、このデータは収集しなくてもよい。
【0066】
次に、ノード状態監視部113が、図9に示すノード状態テーブル141を参照して、応答のあったノードに関する仮想ノードが生成されているか否かを判断する(S35)。具体的には、このノード状態テーブル141の状態領域141uに「正常」が格納されているノードに関しては仮想ノードが生成されていないと判断し、状態領域141uに「障害」又は「障害危機」が格納されているノードに関しては仮想ノードが生成されていると判断する。
【0067】
ノード状態監視部113は、ステップ35で、応答のあったノードに関する仮想ノードが生成されていると判断すると、図9に示すノード状態テーブル141を参照して、この仮想ノードは起動中か否かを判断する(S36)。具体的には、このノード状態テーブル141の状態領域141uに「障害」が格納されているノードに関しては仮想ノードが生成されており且つ起動中であると判断し、状態領域141uに「障害危機」が格納されているノードに関しては仮想ノードが生成されているものの、起動待ち状態、つまり起動中でないと判断する。
【0068】
応答のあったノードに関する仮想ノードが起動中である場合には(S36でYES)、ノード状態監視部113は、その旨を仮想ノード生成部114に通知する。仮想ノード生成部114は、この通知を受けると、このノードの通信アドレスを仮想ノードの通信アドレスから実ノードの通信アドレスへ切り替える旨の切替指示メッセージを、各実ノードに送出する(S37)。この切替メッセージを受けた各実ノードは、通信アドレス切替の対象になっているノードの通信アドレスを新たな通信アドレスに切り替える。
【0069】
ステップ36で、仮想ノードが生成されているものの、この仮想ノードは起動中でないと判断された場合、及び、ステップ37で、ノードの通信アドレスが仮想ノードの通信アドレスから実ノードの通信アドレスへの切替指示メッセージが送出された場合、仮想ノード生成部114は、この仮想ノードを削除する(S38)。
【0070】
例えば、図12を用いて前述したように、実ノード「6」200cに障害が発生して(S1)、仮想ノード生成部114が仮想ノード「6」190を生成した後に、実ノード「6」200cに対する状態確認メッセージに対して、正常な応答があると(S33でYES)、ノード「6」の通信アドレスを仮想ノード「6」の通信アドレスから実ノード「6」の通信アドレスへの切替指示メッセージを送出した後(S37)、仮想ノード「6」が削除される(S38)。一方、他のノードは、以降、再び、実ノード6へアクセスするようになる。
【0071】
ノード状態監視部113は、ステップ35で仮想ノードが生成されていないと判断した場合、及び、ステップ38で仮想ノードが削除された場合、図9に示すノード状態テーブル141中で、応答のあったノードの状態領域141uを「正常」に設定して(S39)、処理を終了する。
【0072】
ノード状態監視部113は、ステップ33で、第一の待ち時間以内に応答がなかったと判断した場合、さらに、第二の待ち時間以内に応答があったか否かを判断する(S41)。この第二の待ち時間は、図10に示す制御ポリシーテーブル142のポリシーNo3に規定されており、ここでは3秒である。第二の待ち時間以内にノードからの応答があった場合、OLN管理部111のOLN構成情報管理部112は、この応答に含まれているノード管理データを該当ノードのノード管理データベースに格納する(S42)。
【0073】
次に、ノード状態監視部113は、前述のステップ35と同様に、図9に示すノード状態テーブル141を参照して、応答のあったノードに関する仮想ノードが生成されているか否かを判断する(S43)。ノード状態監視部113は、応答のあったノードに関する仮想ノードが生成されていないと判断すると、その旨を仮想ノード生成部114に通知し、この仮想ノード生成部114に、このノードの仮想ノードを生成させる(S44)。但し、この仮想ノードは起動させず、起動待ち状態にしておく。
【0074】
ノード状態監視部113は、ステップ43で仮想ノードが生成されていると判断した場合、及び、ステップ44で仮想ノードが生成された場合、図9に示すノード状態テーブル141中で、応答のあったノードの状態領域141uを「障害危機」に設定して(S45)、処理を終了する。なお、この障害危機も、障害の一種である。
【0075】
ノード状態監視部113は、ステップ41で、第二の待ち時間以内に応答がなかったと判断すると、図9に示すノード状態テーブル141を参照して、応答のないノードに関する仮想ノードが生成されているか否かを判断する(S51(図14))。ノード状態監視部113は、応答のないノードに関する仮想ノードが生成されていないと判断すると、その旨を仮想ノード生成部114に通知し、この仮想ノード生成部114に、このノードの仮想ノードを生成させる(S52)。
【0076】
ノード状態監視部113は、ステップ51で仮想ノードが生成されていると判断した場合、及び、ステップ52で仮想ノードが生成された場合、図9に示すノード状態テーブル141を参照して、応答のないノードに関する仮想ノードが起動中であるか否かを判断する(S53)。具体的には、応答のないノードに関して、ノード状態テーブル141の状態領域141uに「障害」が格納されている場合には、起動中であると判断し、「障害危機」が格納されている場合に、起動待ち状態、つまり起動中でないと判断する。
【0077】
ノード状態監視部113が、ステップ53で、応答のないノードに関する仮想ノードが起動中でないと判断すると、仮想ノード生成部114は、この仮想ノードを起動させる(S54)。さらに、仮想ノード生成部114は、ステップ53で仮想ノードが起動中であると判断された場合、及び、ステップ54で仮想ノードを起動させた場合、応答のないノードの通信アドレスを仮想ノードの通信アドレスの通信アドレスへ切り替える旨の切替指示メッセージを、各ノードに送出する(S55)。この切替指示メッセージを受けた各ノードは、通信アドレス切替の対象になっているノードの通信アドレスを新たな通信アドレスに切り替える。
【0078】
次に、ノード状態監視部113は、図9に示すノード状態テーブル141中で、応答のないノードの状態領域141uを「障害」に設定する(S56)。そして、このノード状態監視部113は、第三の待ち時間以内に応答があったか否かを判断する(S57)。この第三の待ち時間は、図10に示す制御ポリシーテーブル142のポリシーNo4に規定されており、ここでは300秒である。第三の待ち時間以内にノードからの応答があった場合、OLN管理部111のOLN構成情報管理部112は、この応答に含まれているノード管理データを該当ノードのノード管理データベースに格納して(S58)、処理を終了する。また、第三の待ち時間以内にノードからの応答がなかった場合、このノードに関して重度の障害があったとして、このノードの離脱処理が実行される(S61)。
【0079】
離脱処理は、以上で説明していない、OLN管理部111中に設けられている参加・離脱処理部が実行する。この離脱処理では、「背景技術」の欄で説明したように、重度の障害があったとされた実ノードの機能を他の健全な実ノードに移植し、この重度の障害があったとされた実ノードをオーバーレイネットワーク上にから離脱させる。この場合、重度の障害があったとされた実ノードの機能の移植先は、この実ノードの前隣接ノード又は後隣接ノードである。
【0080】
離脱処理が終了すると、仮想ノード生成部114は、重度の障害があったとされた実ノードの仮想ノードを削除して(S62)、処理を終了する。このように、本実施形態では、重度の障害であっても、この障害のあったノードの離脱処理の実行過程では、仮想ノードが実ノードの機能を実現しているため、「背景技術」の欄で説明した技術のように、障害への対処時間の長時間化することはない。
【0081】
以上のように、本実施形態では、ある実ノードに軽度の障害が生じた場合、この実ノードの仮想ノードを生成し、これに伴って、各ノードの管理テーブル中の障害ノードの通信アドレスの切替処理のみで、障害に対処しているので、ネットワーク上のオーバーヘッドが増大を防ぎ、しかも、所定の障害への対処時間を短時間化することができる。さらに、本実施形態では、仮想ノードを起動させるにあたり、実ノードが障害状態に至る前段階である障害危機状態で、仮想ノードを生成し、実ノードが障害状態に至ると、この仮想ノードを起動させているので、所定の障害への対処時間をより短くすることができる。また、本実施形態では、前述したように、ある実ノードに重度の障害が生じた場合であっても、この実ノードに関する切替処理が終了する迄、仮想ノードが実ノードの機能を実現しているため、障害への対処時間の長時間化することはない。
【0082】
なお、以上の実施形態では、OLN管理装置100からの状態確認メッセージが、各ノードに対するノード管理データの送信要求メッセージも兼ねているが、各メッセージを別々に送出するようにしてもよい。この場合、状態確認メッセージは、ノード状態監視部113が送出し、ノード管理データの送信要求メッセージは、OLN構成情報管理部112が送出することになる。これらのメッセージに対しては、いずれも、各ノードのノード用OLN管理部217が対応することになる。また、OLN管理装置100は、各ノードのノード管理データの収集にあたり、このノード管理データの送信要求メッセージを各ノードに送出せず、各ノードのノード用OLN管理部217が、一方的にノード管理データをOLN管理装置100へ送るようにしてもよい。
【0083】
また、以上では、各ノード200b〜200eに、それぞれ、RFIDリーダ270が一つずつ接続されているが、それぞれ、複数のRFIDリーダ270を接続するようにしてもよい。
【0084】
また、以上では、ユーザ座標値やこの検知時刻をAPデータとしているが、本発明は、各ノードに分散配置するデータであれば、他の如何なるAPデータであっても構わない。
【図面の簡単な説明】
【0085】
【図1】本発明に係る一実施形態におけるオーバーレイネットワークシステムの構成図である。
【図2】本発明に係る一実施形態におけるOLN管理装置の構成図である。
【図3】本発明に係る一実施形態における仮想ノードの構成である。
【図4】本発明に係る一実施形態における実ノードの構成図である。
【図5】本発明に係る一実施形態におけるハッシュテーブルのデータ構成を示す説明図である。
【図6】本発明に係る一実施形態における各ノードのAPデータテーブルのデータ構成を示す説明図である。
【図7】本発明に係る一実施形態における各ノードのルーティグテーブルのデータ構成を示す説明図である。
【図8】本発明に係る一実施形態における各ノードの管理テーブルのデータ構成を示す説明図である。
【図9】本発明に係る一実施形態におけるノード状態テーブルのデータ構成を示す説明図である。
【図10】本発明に係る一実施形態における制御ポリシーテーブルのデータ構成を示す説明図である。
【図11】本発明に係る一実施形態のオーバーレイネットワークシステムの動作を示すシーケンス図(障害が発生していない場合)である。
【図12】本発明に係る一実施形態のオーバーレイネットワークシステムの動作を示すシーケンス図(障害が発生した場合)である。
【図13】本発明に係る一実施形態におけるOLN管理装置のOLN管理部の動作を示すフローチャートである(その1)。
【図14】本発明に係る一実施形態におけるOLN管理装置のOLN管理部の動作を示すフローチャートである(その2)。
【符号の説明】
【0086】
1:WAN、2:LAN、3:アクセスポイント、5:RFIDタグ、10:オーバーレイネットワーク、100:OLN管理装置、110,210:CPU、111:OLN管理部、112:OLN構成情報管理部、113:ノード状態監視部、114:仮想ノード生成部、115:制御ポリシー設定部、116:OLN通信制御部、117,197,217:ノード用OLN管理部、118,198,218:OLN制御部、119:ユーザ要求対処部、120:メモリ、130:外部記憶装置、140:OLN管理データベース、141:ノード状態テーブル、142:制御ポリシーテーブル、144:ハッシュテーブル、150a,150ac:ノード0管理データベース、250bc:ノード2管理データベース、250c,250cc,195:ノード6管理データベース、250dc:ノード9管理データベース、250ec:ノード13管理データベース、151a,191,251b〜251e:APデータテーブル、152a,192,252b〜252e:管理テーブル、153a,193,253b〜253e:ルーティングテーブル、131:OLN管理プログラム、137,237:ノード用OLN管理プログラム、138,238:OLNプログラム、139:ユーザ要求対処プログラム、170:ノード0、190:仮想ノード6、200b:ノード2、200c:ノード6、200d:ノード9、200e:ノード13、270:RFIDリーダ、300:ユーザ端末
【技術分野】
【0001】
本発明は、複数のノードを備えたオーバーレイネットワークの管理技術に関する。
【背景技術】
【0002】
近年、通信ネットワークに接続された端末数が爆発的に増え、これら端末からの要求に応えるサーバの処理能力が不足することが度々生じている。そこで、各端末からの要求に応えるための処理をネットワーク全体に分散させる技術が採用されることが多くなってきている。
【0003】
このような技術として、DHT(Distributed Hash Table:分散ハッシュテーブル)を用いたオーバーレイネットワーク技術がある。オバーレイネットワークとは、既存のリンク上に仮想的なリンクを形成して構成されるネットワークである。このオバーレイネットワークでは、処理の中心となるサーバを設けず、サービス対象の情報からハッシュ関数を用いてハッシュ値を生成し、このハッシュ値と対応するノードに、サービス対象の情報を分散格納することで、処理能力の分散化を図っている。ここで、上記DHTとは、サービス対象の情報IDとそのハッシュ値とを関係付けるテーブルのことである。
【0004】
このオーバレイネットワークの形成技術に関しては、例えば、以下の特許文献1や非特許文献1に開示されている。
【0005】
非特許文献1では、さらに、複数のノードのうちの一つのノードに障害が生じたときの対処方法についても開示されている。
【0006】
この障害対処方法は、各ノードの各種情報を何らかの形で逐次保持しておき、あるノードに障害が生じたときに、他のノードに、障害のあったノードの機能を追加し、この他のノードに、障害のあったノードの機能を代替させるという方法である。各ノードの各種情報としては、サービス対象の情報の他、サービス対象の情報を検索するために問い合わせるノードを示す各ハッシュ値毎のルーティング情報や、このハッシュ値毎のルーティング情報に示されているノードの通信アドレスを含むノード管理情報等の構成情報がある。
【0007】
この障害対処方法では、障害のあったノードの各種情報を他のノードに移植すると共に、障害のあったノードがオーバーレイネットワーク上に存在しないことになるため、各ノード毎に、新たなルート情報を作成する必要がある。
【0008】
【特許文献1】特開2006−191489号公報
【非特許文献1】「分散ハッシュテーブルの軽量な負荷分散手法の検討」 社団法人 電子情報通信学会 信学技報
【発明の開示】
【発明が解決しようとする課題】
【0009】
上記障害対処方法では、前述したように、各ノード毎に新たなルーティング情報等を作成するために、各ノード相互間で多くの情報のやりとりする必要がある。このため、この方法では、ネットワーク上のオーバーヘッドが増大する上に、障害が発生してから、これの対処が終了するまでに時間がかかり、障害ノードに対応するノードが存在しない時間が比較的長くなってしまう。特に、この方法では、あるノードに何らかの一時的な通信障害が生じた場合でも、上記障害対処を実行すると、却って、障害ノードに対応するノードが存在しない時間が長くなってしまう。このことから、オーバネットネットワークのユーザからは、このオーバーレイネットワークの信頼性をより高めてほしいという要望が生じている。
【0010】
そこで、本発明では、障害に対する対処が早く、オバーレイネットワークの信頼性を高めることができる技術を提供することを目的とする。
【課題を解決するための手段】
【0011】
前記目的を達成するため、本発明では、
複数のノードが保持している、データと、このデータへのアクセスのためのノードを示すルート情報及び該ルート情報に示されているノードの通信アドレスを含む構成情報とのうち、少なくとも前記構成情報を収集し、該構成情報をコンピュータの記憶装置に格納する。さらに、前記複数のノードのそれぞれに対する通信を定期的に試みて、各ノードからの応答に応じて、該複数のノードの状態を把握する。
【0012】
把握された前記複数のノードの状態のうち、いずれかのノードの状態が予め定めた障害状態である場合には、前記記憶装置に格納されている該ノードの前記構成情報を用いて、該ノードに関して、他のノードからアクセス可能な仮想ノードを前記コンピュータ上に生成し、該仮想ノードを起動させる。該仮想ノードが起動すると、前記予め定めた障害状態であるとされた前記ノードの通信アドレスとして、該ノードの仮想ノードが生成された前記コンピュータの通信アドレスへの切替える旨の通信アドレス切替指示を、前記他のノードに通知して、該他のノードが前記予め定めた障害状態であるとされた該ノードにアクセスしようとしている場合に、該ノードの仮想ノードにアクセスさせる。
【発明の効果】
【0013】
本発明によれば、ある実ノードに予めさだめた障害が生じた場合、この実ノードの仮想ノードを生成し、これに伴って、各ノードの構成情報中の障害ノードの通信アドレスの切替処理のみで、障害に対処しているので、ネットワーク上のオーバーヘッドが増大を防ぎ、しかも、所定の障害への対処時間を極めて短時間化することができる。
【発明を実施するための最良の形態】
【0014】
以下、本発明に係るオーバーレイネットワークシステムの一実施形態について、図面を用いて説明する。
【0015】
本実施形態のオーバーレイネットワークシステムは、図1に示すように、複数のノード200b〜200eとこれら複数のノード200b〜200eを含むオーバーレイネットワーク(以下、OLN)10を管理するOLN管理装置100と、複数のノードが保持しているアプリケーション(以下、APとする)データを利用するユーザ端末300と、を備えている。
【0016】
複数のノード200b〜200eは、LAN2に接続されているアクセスポイント3と無線通信することができる。各LAN2は、WAN1に図示されていないルータを介して、WAN1と接続されている。OHL管理装置100及びユーザ端末300は、いずれも、図示されていないルータを介して、WAN1と接続されている。
【0017】
本実施形態では、WAN1及び複数のLAN2,2,…上に、一つの仮想的なネットワーク、つまりオーバレイネットワーク10を形成し、OHL管理装置100及び複数のノード200b〜200eは、このオバーレイネットワーク10上で、各ネットワークセグメントによる分断を意識せずに、互いに通信することができる。なお、OLNシステムを構成する各装置のうち、ユーザ端末300は、オバーレイネットワーク10上に存在するものではない。
【0018】
各ノード200b〜200eには、RFID(Radio Frequency IDentification)タグ5と無線通信するRFIDリーダ270が接続されている。このRFIDタグ5は、ユーザが指定した人物が保持しているもので、このユーザのIDが記憶されている。RFIDリーダ270は、このRFIDタグ5と無線通信して、このRFIDタグ5からユーザID情報を取得し、これを接続先のノードに送る。各ノード200b〜200eは、RFIDリーダ270から送られてきたユーザIDと、これに対するデータIDと、RFIDタグ5を保持していた人物の位置、つまりユーザ座標値と、を相互に関連付けて、これらのデータを、後述のAPデータテーブルに格納する。データIDは、ユーザIDのハッシュ値であり、ユーザIDが定められた時点で定められる値である。また、ユーザ座標値は、ユーザIDを検知したRFIDリーダ270の設置箇所の座標値(緯度、経度)である。このため、各ノード200b〜200eには、自ノードに接続されているRFIDリーダ270の設置箇所の座標値が予め記憶されており、この座標値が検知された人物の座標値、つまりユーザ座標値となる。
【0019】
OLN管理装置100は、機能的に、OLN10を管理するOLN管理部111と、ユーザ端末300からの要求に対処するユーザ要求対処部119と、ノード「0」170と、を有している。前述のユーザ座標値は、ユーザ毎に、このノード「0」170と、以上で説明した複数のノード200b〜200eとに分散されて、格納されている。
【0020】
各ノード200b〜200eは、図4に示すように、各種演算処理を実行するCPU210と、このCPU210のワークエリアとなるメモリ220と、各種データが格納されている外部記憶装置230と、ネットワーク通信を行う通信装置261と、可搬型ディスク記憶媒体Dに対してデータの再生及び記録を行うディスク記憶再生装置262と、RFIDリーダ270のインタフェースである入出力インタフェース263と、を備えている。なお、同図では、ノード「6」200cの構成を示しているが、他のノード200b〜200eも、ノード「6」200cの構成と同じである。
【0021】
ノード「6」200cの外部記憶装置130には、ノード「6」の各種データが格納されるノード6管理データベース250cが設けられている。さらに、この外部記憶装置130には、ユーザIDとハッシュ値であるデータIDとの対応関係を示すハッシュテーブル234と、このノード「6」200cに接続されているRFIDリーダ270からのデータを受け付けるAPプログラム231と、OLN管理装置100からノード「6」への要求等に応えるためのノード用OLN管理プログラム237と、ノード「6」が他のノードと通信して、ノードとしての機能を実現するためのOLNプログラム238と、が予め格納されている。
【0022】
ハッシュテーブル234は、図5に示すように、ユーザIDが格納されるユーザID領域234sと、ハッシュ値であるデータIDが格納されるデータID領域234tと、を有している。このハッシュテーブル234は、ユーザの加入又は脱退により更新される。
【0023】
ノード6管理データベース150aには、図4に示すように、予め定められたユーザIDのユーザ座標が格納されるAPデータテーブル251cと、ノード「6」200cが管理するデータのIDや、ノード「6」200cの通信相手等になる関連ノードの通信アドレスが格納されている管理テーブル252cと、ノード「6」200cがアプリケーションデータであるユーザ座標を検索するために問い合わせるノードを示すルーティングテーブル253cと、が設けられている。
【0024】
APデータテーブル251cは、図6に示すように、ノード「6」200cが管理するデータのID(ハッシュ値)が格納されているデータID領域251sと、データIDに対応するユーザIDが格納されているユーザID領域251tと、当該ユーザのIDが検知された時刻が格納される時刻領域251uと、当該ユーザの座標が格納されるユーザ座標領域251vと、を有している。なお、他のノード170,200b,200d,200eも、それぞれ、同様のAPデータテーブル151a,251b,251d,251eを備えている。
【0025】
ルーティングテーブル253cは、図7に示すように、適用データIDが格納されている適用データID領域253sと、適用データIDのデータを検索等のために問い合わせるノード名が格納されている次ノード名領域253tと、を有している。このルーティングテーブル253cは、自ノードで管理していないデータの検索問合せがあった場合に、いずれのノードに検索問合せをすればよいかを示すものであるため、適用データID領域253cには、自ノードで管理していないデータのIDが格納される。例えば、ノード「6」200cでは、後述するように、データIDが「3」「4」「5」「6」のデータを管理するので、これらのデータIDを除くデータIDが適用データID領域253cに格納される。また、同図中のルーティングテーブル253cでは、適用データID領域253cに「7〜9」が格納され、対応する次ノード領域253tに「9」が格納されているが、これは、データIDが「7」「8」「9」のいずれかに関するデータの検索等の問合せがあった場合、ノード「9」に問い合わせることを示している。なお、他のノード170,200b,200d,200eも、それぞれ、同様のルーティングTL153a,253b,253d,253eを備えている。
【0026】
管理テーブル252cは、図8に示すように、自ノードが管理するデータのIDが格納されている管理データのデータID領域252sと、ルーティングテーブル253cで定められている次ノードの通信アドレスが格納されている次ノードアドレス領域252tと、論理上で自ノードに対して前側に隣接している隣接ノードの通信アドレスが格納されている前隣接ノードアドレス領域252uと、論理上で自ノードに対して後側に隣接している隣接ノードの通信アドレスが格納されている後隣接ノードアドレス領域252vと、を有している。同図中の管理テーブル252cでは、管理データのデータID領域252sに、「3,4,5,6」が格納されているが、これは、自ノード「6」がデータID「3」「4」「5」「6」のデータを管理していることを示している。なお、他のノード170,200b,200d,200eも、それぞれ、同様の管理TL152a,252b,252d,252eを備えている。
【0027】
ノード「6」200cのCPU210は、機能的に、図4に示すように、このノード「6」200cに接続されているRFIDリーダ270からのデータを受け付けるAPデータ入出力制御部211と、OLN管理装置100から自ノード「6」への要求等に応えるノード用OLN管理部217と、このノード「6」200cが他のノードと通信して、ノードとしての機能を実現するOLN制御部218と、を有している。以上のAPデータ入出力制御部211、ノード用OLN管理部217、OLN制御部218は、それぞれ、CPU210が、外部記憶装置230に格納されているAPプログラム231、ノード用OLN管理プログラム237、OLNプログラム238を実行することで機能する。
【0028】
OLN管理装置100は、図2に示すように、各種演算処理を実行するCPU110と、このCPU110のワークエリアとなるメモリ120と、各種データが格納されている外部記憶装置130と、ネットワーク通信を行う通信装置161と、キーボードやディスプレイ等の入出力装置164と、そのインタフェース163と、可搬型ディスク記憶媒体Dに対してデータの再生及び記録を行うディスク記憶再生装置162と、を備えている。
【0029】
外部記憶装置130には、各ノード170,200b〜200eのデータ等を管理するためのOLN管理データベース140と、前述のノード「0」170の構成要素としてのノード0管理データベース150aとが設けられている。さらに、この外部記憶装置130には、前述のOLN管理部111の機能を実現するためのOLN管理プログラム131と、OLN管理部111からノード「0」170への要求等に応えるためのノード用OLN管理プログラム137と、ノード「0」170が他のノード200b〜200eと通信して、ノードとしての機能を実現するためのOLNプログラム138と、ユーザ端末300からの要求に対処するためのユーザ要求対処プログラム139と、が予め格納されている。
【0030】
OLN管理データベース140には、各ノード170,200b〜200eの状態が格納されるノード状態テーブル141と、OLN管理部111が各種制御を行う際の制御ポリシーが格納されている制御ポリシーテーブル142と、ハッシュテーブル144と、各ノード170,200b〜200eが保持しているノード管理データベースのコピーであるノード管理データベース150ac,250bc,250cc,250dc,250ecとが設けられている。
【0031】
OLN管理データベース140中のノード状態テーブル141は、図9に示すように、ノード名が格納されているノード名領域141sと、当該ノードの通信アドレスが格納されているノードアドレス領域141tと、当該ノードの状態が格納される状態領域141uと、を有している。この状態領域141には、「正常」「障害危機」「障害」のいずれかが格納される。
【0032】
OLN管理データベース140中の制御ポリシーテーブル142は、図9に示すように、ポリシー番号が格納されているポリシーNo領域142sと、制御ポリシーの内容が格納されている制御ポリシー内容領域142tと、該当制御ポリシー内容に対して定めた値が格納される値領域142uと、を有している。この制御ポリシーテーブル142の各領域のうち、ポリシーNo領域142s及び制御ポリシー内容領域142tには、予めデータが格納されている。また、この制御ポリシーテーブル142の値領域142uには、制御ポリシー設定部115により、入出力装置164又はディスク記憶再生装置162から取得された値が格納される。なお、この制御ポリシーテーブル142の具体的な制御ポリシー内容及びその値に関しては、後述する。
【0033】
ハッシュテーブル144は、図5を用いて説明したハッシュテーブル234と同一である。
【0034】
ノード0管理データベース150aには、図2に示すように、他のノード200b〜200eのノード管理データベース250b〜250eと同様に、APデータテーブル151aと、管理テーブル152aと、ルーティングテーブル153aと、が設けられている。
【0035】
OLN管理装置100のCPU110は、機能的に、前述のOLN管理部111と、OLN管理部111からノード「0」170(図1に示す)への要求等に応えるノード用OLN管理部117と、ノード「0」170が他のノードと通信して、ノードとしての機能を実現するOLN制御部118と、ユーザ端末300からの要求に対処するユーザ要求対処部119と、を有している。さらに、OLN管理部111は、各ノード170,200b〜200e毎の管理データを収集し、これをOLN管理データベース140の該当位置に格納するOLN構成情報管理部112と、各ノード170,200b〜200eと定期的に通信して、各ノードの状態を監視するノード状態監視部113と、いずれかのノードに障害が発生したときにこのノードの仮想ノードを生成する仮想ノード生成部114と、OLN管理部111が各種制御を行う際の制御ポリシーを外部から受け付けて、これを制御ポリシーテーブル142に格納する制御ポリシー設定部115と、以上のOLN管理部111の各機能部がオーバレイネットワーク10を介して他のノード等と通信するためのOLN通信制御部116と、を有している。以上の各機能部のうち、OLN管理部111は、外部記憶装置130に格納されているOLNプログラム131をCPU110が実行することで機能する。また、ノード用OLN管理部117、OLN制御部118、ユーザ要求対処部119は、それぞれ、外部記憶装置130に格納されているノード用OLN管理プログラム137、OLNプログラム138、ユーザ要求対処プログラム139を実行することで機能する。
【0036】
なお、図1に示すノード「0」170は、ノード用OLN管理部117と、OLN制御部118と、ノード0管理データベース150aと、ハッシュテーブル144とを有して構成される。
【0037】
次に、図11に示すシーケンス図に従って、各ノードが正常な場合のオーバーレイネットワークシステムの動作について説明する。なお、ここでは、ノード「9」200dに接続されているRFIDリーダ270がユーザID「yamada」を検知し、このユーザID「yamada」のユーザがユーザ端末300から、位置情報の提示要求をした場合の動作について説明する。
【0038】
ユーザID「yamada」が格納されているRFIDタグ5を保持している人物が、ノード「9」200dに接続されているRFIDリーダ270の傍を通ると、このRFIDリーダ270は、この人物が保持しているRFIDタグ5からユーザID「yamada」を取得し、このユーザID「yamada」をノード「9」200dへ送る。これにより、ノード「9」200dは、ユーザID「yamada」(データID「4」)を検知することになる(S11)
ノード「9」200dのAPデータ入出力部211は、このユーザID「yamada」を受け取ると、このユーザID「yamada」と共に、現在の時刻、RFIDリーダ270の座標値(緯度、経度)をOLN制御部218に渡す。OLN制御部218は、このユーザID「yamada」を受け取ると、ハッシュテーブル234(図5)を参照して、ユーザID「yamada」に対するデータID(ハッシュ値)「4」を取得する。次に、OLN制御部218は、自ノード「9」200dの管理テーブル252d(図8)の管理データのデータID領域252sを参照して、このデータID「4」が自ノード9で管理するデータであるか否かを判断する。仮に、このデータID「4」が自ノード9で管理するデータである場合には、APデータテーブル251d(図6)の検知時刻領域251u中の対応領域に現在の時刻を検知時刻として格納すると共に、ユーザ座標領域251v中の対応領域に、RFIDリーダ270の座標値(緯度、経度)をユーザ座標値として格納する。
【0039】
しかしながら、この場合、管理テーブル252d(図8)の管理データのデータID領域252sには、このデータID「4」がないので、このデータID「4」は自ノード9で管理するデータではない。そこで、OLN制御部218は、自ノード「9」200dのルーティングテーブル253d(図7)を参照して、このデータID「4」に関するデータの送出先である次ノード名「2」を取得する。続いて、自ノード「9」200dの管理テーブル252dの次ノードアドレス領域252tから、次ノード名「2」の通信アドレス「192.168.10.2」を取得する。そして、OLN制御部218は、この通信アドレス「192.168.10.2」が示すノード2へ、このデータID「4」と、検知時刻と、RFIDリーダ270の座標値(緯度、経度)、つまりユーザ座標値とを含むAPデータの登録メッセージを送信する(S12)。
【0040】
ノード「2」200bのOLN制御部218は、ノード「9」200dからAPデータの登録メッセージを受け付けると、自ノード「2」200bの管理テーブル252b(図8)の管理データのデータID領域252sを参照して、このデータID「4」が自ノード9で管理するデータであるか否かを判断する。この場合も、管理テーブル252b(図8)の管理データのデータID領域252sには、このデータID「4」がないので、このデータID「4」のAPデータは自ノード2で管理するデータではないと判断する。次に、OLN制御部218は、自ノード「2」200bのルーティングテーブル253b(図7)を参照して、このデータID「4」に関するデータの送出先である次ノード名「6」を取得すると共に、自ノード「2」200bの管理テーブル252bの次ノードアドレス領域252tから、次ノード名「6」の通信アドレス「192.168.10.6」を取得する。そして、OLN制御部218は、この通信アドレス「192.168.10.6」が示すノード6へ、このAPデータの登録メッセージを送信する(S13)。
【0041】
ノード「6」200cのOLN制御部218は、ノード「2」200bからAPデータの登録メッセージを受け付けると、自ノード「6」200cの管理テーブル252c(図8)の管理データのデータID領域252sを参照して、このデータID「4」が自ノード9で管理するデータであるか否かを判断する。この場合、管理テーブル252c(図8)の管理データのデータID領域252sには、このデータID「4」があるので、このデータID「4」のAPデータは自ノード2で管理するデータであると判断する。そして、OLN制御部218は、自ノード「6」200cのAPデータテーブル251c(図6)中のデータID「4」のレコードに、このAPデータに含まれている現在の時刻及びユーザ座標値を登録する(S14)。
【0042】
一方、このデータID「4」に対応するユーザID「yamada」のユーザが、自ユーザID「yamada」の位置情報を取得したい場合には、ユーザ端末300に自ユーザID「yamada」を入力し(S21)、このユーザID「yamada」の位置情報の提示要求メッセージをOLN管理装置100へ送信する(S22)。
【0043】
OLN管理装置100のユーザ要求対処部119は、この位置情報の提示要求メッセージを受け取ると、ノード「0」170の構成要素であるOLN制御部118に、このメッセージを渡す(S23)。ノード「0」170のOLN制御部118は、まず、ハッシュテーブル144(図5)を参照して、このメッセージに含まれているユーザID「yamada」に対するデータID(ハッシュ値)「4」を取得する。次に、OLN制御部118は、自ノード「0」170の管理テーブル152a(図8)の管理データのデータID領域252sを参照して、このデータID「4」のAPデータは自ノード0で管理しているデータであるか否かを判断する。この場合、管理テーブル152a(図8)の管理データのデータID領域252sには、このデータID「4」がないので、このデータID「4」のAPデータは自ノード0で管理していないと判断する。次に、OLN制御部118は、自ノード「0」170のルーティングテーブル153a(図7)を参照して、このデータID「4」に関するAPデータの検索先である次ノード名「6」を取得すると共に、自ノード「0」170の管理テーブル152aの次ノードアドレス領域252tから、次ノード名「6」の通信アドレス「192.168.10.6」を取得する。そして、OLN制御部118は、この通信アドレス「192.168.10.6」が示すノード6へ、このデータID「4」の検索要求メッセージを送信する(S24)。
【0044】
ノード「6」200cのOLN制御部218は、ノード「0」170からデータID「4」の検索要求メッセージを受け付けると、自ノード「6」200cの管理テーブル252c(図8)の管理データのデータID領域252sを参照して、このデータID「4」は自ノード9で管理しているデータであるか否かを判断する。この場合、管理テーブル252c(図8)の管理データのデータID領域252sには、このデータID「4」があるので、このデータID「4」のAPデータは自ノード2で管理しているデータであると判断する。そして、OLN制御部218は、自ノード「6」200cのAPデータテーブル251c(図6)中のデータID「4」のレコードから、検知時刻及びユーザ座標値を取得する。そして、この検知時刻及びユーザ座標値とデータID「4」とを含むAPデータを位置情報として、検索要求元のノード「0」170へ送る(S25)。
【0045】
ノード「0」170がこのAPデータを受け取ると、このAPデータをユーザ要求対処部119に渡す(S26)。ユーザ要求対処部119は、このAPデータを受け取ると、このAPデータに含まれている検知時刻及びユーザ座標値をユーザ端末300へ送る(S27)。なお、ユーザ座標値は、経度、緯度で表されているものであるため、ユーザがこのユーザ座標値を見ても、このユーザ座標値が示す位置を把握しにくいため、このユーザ座標値が示す地点をマークした地図を、ユーザ端末300へ送るようにしてもよい。
【0046】
次に、図12に示すシーケンス図に従って、ノード「6」200cに障害が発生した場合のオーバーレイネットワークシステムの動作について説明する。なお、ここでも、ノード「9」200dに接続されているRFIDリーダ270がユーザID「yamada」を検知し、このユーザID「yamada」のユーザがユーザ端末300から、位置情報の提示要求をした場合の動作について説明する。
【0047】
例えば、ノード「6」200cとアクセスポイント3との間に障害物が入り込む、両者の間の電波に対する干渉波が発生する等の無線障害が生じた場合や、このアクセスポイント3が接続しているLAN2の通信トラフィックが非常に高まってしまった場合等で、ノード「6」200cが他のノード170,200a,200b,200d,200eとの通信に障害が発生したとする(S1)。
【0048】
OLN管理装置100のOLN管理部111は、この障害を検知すると(S2)、OLN管理装置100内に仮想ノード「6」190を生成し、これを起動させる(S3)。なお、ノード「6」200cに障害検知に関しては、後ほど詳細に説明するが、OLN管理部111のノード状態監視部113が、定期的に各ノードに状態確認メッセージを送出し、このメッセージの応答に応じて障害を検知する。また、仮想ノード「6」190は、OLN管理部の仮想ノード生成部114が生成する。OLN管理部111のOLN構成情報管理部115は、後述するように、各ノードから定期的に各ノードが保持しているノード管理データベースを収集しており、これをOLN管理データベース140(図2)に格納している。仮想ノード生成部114は、このOLN管理データベース140中のノード6管理データベース250ccを用いて、仮想ノード「6」190を生成する。
【0049】
仮想ノード「6」190は、図3に示すように、OLN管理装置100のCPUとメモリとの複合体180上に生成される。この仮想ノード「6」190は、実ノード「6」200cと同様に、ノード用OLN管理部197とOLN制御部198とノード6管理データベース195とを有している。ノード6管理データベース195は、実ノード「6」200cのノード6管理データベース250cと同様に、APデータテーブル191と管理テーブル192とルーティングテーブル193とを有している。また、この仮想ノード「6」190は、RFIDリーダ270が接続されておらず、この関係で、実ノード「6」200cのAPデータ入出力制御部211に対応するものを有していない。したがって、仮想ノード「6」190は、APデータやノード構成情報の管理機能を有しているものの、ユーザIDの検知機能を有していない。
【0050】
OLN管理装置100のOLN管理部111は、次に、実ノード「6」を除く他の実ノードに対して、ノード「6」の新たな通信アドレスへの切替指示メッセージを送出する(S4)。この切替指示メッセージ中に含まれるノード6の新たな通信アドレスは、仮想ノード「6」190が作成されているOLN管理装置100の通信アドレス「192.168.10.100」である。なお、この通信アドレス「192.168.10.100」は、ノード「0」170の通信アドレスでもある。
【0051】
実ノード「6」200c及び仮想ノード「6」190を除く各ノード170,200b,200d,200eのノード用OLN管理部217は、この切替指示メッセージを受け取ると、自ノード管理データベース中の管理テーブル152a,252b,252d,252e中で、実ノード「6」の通信アドレスが格納されている部分が存在する場合には、この部分をノード6の新たな通信アドレス「192.168.10.100」に切り替える(S5)。
【0052】
以上で、実ノード「6」200c及び仮想ノード「6」190を除く各ノード170,200b,200d,200eは、実ノード「6」200cに障害が発生したこと、及びこの障害により仮想ノード「6」170が生成されたことを認識することなく、仮想ノード「6」190を実ノード「6」200cとして扱うことになる。
【0053】
ところで、「背景技術」の欄で説明したように、従来、あるノードに所定の障害が生じた場合、このノードの機能を他の健全なノードに移植し、障害のあったノードをオーバーレイネットワーク上にから離脱させている。このため、各ノードは、ルーティングテーブルや管理テーブル等を更新する必要が生じて、各ノード相互間で多くの情報のやりとりすることになる。この結果、従来の技術では、ネットワーク上のオーバーヘッドが増大する上に、所定の障害への対処時間の長時間化してしまう。
【0054】
これに対して、本実施形態では、あるノード「6」200cに所定の障害が生じた場合、このノード「6」200cの仮想ノード「6」190を生成し、これに伴って、各ノードの管理テーブル中の障害ノード「6」の通信アドレスの切替処理のみで、障害に対処しているので、ネットワーク上のオーバーヘッドが増大を防ぎ、しかも、所定の障害への対処時間を極めて短時間化することができる。
【0055】
以上の状態で、ユーザID「yamada」が格納されているRFIDタグ5を保持している人物が、ノード「9」200dに接続されているRFIDリーダ270の傍を通ると、このRFIDリーダ270は、この人物が保持しているRFIDタグ5からユーザID「yamada」を取得し、このユーザID「yamada」をノード「9」200dへ送る。これにより、ノード「9」200dは、ユーザID「yamada」(データID「4」)を検知することになる(S11)
ノード「9」200dは、図11のステップ12の処理と同様に、データID「4」と、検知時刻と、ユーザ座標値とを含むAPデータの登録メッセージをノード「2」へ送信する(S12)。
【0056】
ノード「2」200bは、この登録メッセージを受け付けると、図11のステップ13の処理と同様に、この登録メッセージをノード6へ送信する(S13a)。但し、この場合、このデータID「4」に関するデータの送出先である次ノード名「6」の通信アドレスが実ノード「6」200cの通信アドレス「192.168.10.6」から、仮想ノード「6」190の通信アドレス「192.168.10.100」へ切り替わっているため、データID「4」に関するAPデータの登録メッセージは、仮想ノード「6」190へ送信される。
【0057】
仮想ノード「6」190のOLN制御部198は、ノード「2」200bからAPデータの登録メッセージを受け付けると、自ノード「6」190のAPデータテーブル191中のデータID「4」のレコードに、このAPデータに含まれている現在の時刻及びユーザ座標値を登録する(S14a)。
【0058】
一方、このデータID「4」に対応するユーザID「yamada」のユーザが、自ユーザID「yamada」の位置情報を取得したい場合には、図11のステップ21及びステップ22と同様に、ユーザ端末300に自ユーザID「yamada」を入力し(S21)、このユーザID「yamada」の位置情報の提示要求メッセージをOLN管理装置100へ送信する(S22)。
【0059】
OLN管理装置100のユーザ要求対処部119は、この位置情報の提示要求メッセージを受け取ると、ノード「0」170の構成要素であるOLN制御部118に、このメッセージを渡す(S23)。ノード「0」170のOLN制御部118は、図11のステップ24と同様に、ユーザID「yamada」に対するデータID「4」の検索要求メッセージをノード6へ送信する(S24a)。但し、この場合も、このデータID「4」に関するデータの送出先である次ノード名「6」の通信アドレスが実ノード「6」200cの通信アドレス「192.168.10.6」から、仮想ノード「6」190の通信アドレス「192.168.10.100」へ切り替わっているため、データID「4」の検索要求メッセージは、仮想ノード「6」170へ送信される。
【0060】
仮想ノード「6」190のOLN制御部198は、ノード「0」170からデータID「4」の検索要求メッセージを受け付けると、図11のステップ25と同様に、自仮想ノード「6」190のAPデータテーブル191中のデータID「4」のレコードから、検知時刻及びユーザ座標値を取得し、これらを含むAPデータを位置情報として、検索要求元のノード「0」170へ送る(S25a)。
【0061】
以下、図11のステップ26,27と同様の処理が実行されて、対象者の検知時刻及びユーザ座標値がユーザ端末300へ送られる。
【0062】
次に、図13及び図14に示すフローチャートに従って、OLN管理装置100のOLN管理部111の動作について説明する。
【0063】
OLN管理部111のノード状態監視部113は、先に状態確認メッセージを各ノードに送出してから、予め定めた状態確認インターバルを経過したか否かを判断する(S31)。この状態確認インターバルは、図10に示す制御ポリシーテーブル142のポリシーNo1に規定されており、ここでは60秒である。ノード状態監視部113は、状態確認インターバルを経過したと判断すると、状態確認メッセージを各ノードに送出する(S32)。なお、ここで、状態確認メッセージを送出するノードは、実ノードのみで、仮想ノードは含まれない。また、図10に示す制御ポリシーテーブル142のポリシーNo6に規定されているように、ノード管理データの更新インターバルも、状態確認インターバルと同じ60秒であり、ここでは、この状態確認メッセージが、各ノードに対するノード管理データの送信要求も兼ねている。
【0064】
各ノードは、この状態確認メッセージを受信すると、ノードのノード用OLN管理部217が、自ノードのノード管理データベースに格納されている全データを取得し、この全データを含めた応答メッセージをOLN管理装置100へ返す。
【0065】
OLN管理装置100のノード状態監視部113は、状態確認メッセージを送出すると、このメッセージに対して、第一の待ち時間以内にノードからの応答があったか否かを判断する(S33)。この第一の待ち時間は、図10に示す制御ポリシーテーブル142のポリシーNo2に規定されており、ここでは30msである。第一の待ち時間以内にノードからの応答があった場合、この応答には、前述したように、応答ノードのノード管理データ、つまり応答ノードが管理しているノード管理データベース内のデータが含まれているので、OLN管理部111のOLN構成情報管理部112は、このノード管理データを該当ノードのノード管理データベースに格納する(S34)。例えば、ノード0,2,6,9,13のそれぞれから応答があった場合には、これらの応答に含まれているノード管理データを、該当ノード0,2,6,9,13のノード管理データベース150ac,250bc,250cc,250dc,250ecに格納する。なお、ここでは、応答中に、自ノードが管理しているノード管理データベース内の全てのデータが含まれているが、ノード管理データベース内のデータのうち、APデータテーブルのデータは含めなくてもよい。但し、ここでは、図10に示す制御ポリシーテーブル142のポリシーNo5に規定されているように、APデータの保持することを選択しているので、このAPデータが応答中に含まれている。また、ここでは、OLN管理装置100内に生成されているノード「0」170が管理しているノード管理データベース150aのデータも収集しているが、このデータは収集しなくてもよい。
【0066】
次に、ノード状態監視部113が、図9に示すノード状態テーブル141を参照して、応答のあったノードに関する仮想ノードが生成されているか否かを判断する(S35)。具体的には、このノード状態テーブル141の状態領域141uに「正常」が格納されているノードに関しては仮想ノードが生成されていないと判断し、状態領域141uに「障害」又は「障害危機」が格納されているノードに関しては仮想ノードが生成されていると判断する。
【0067】
ノード状態監視部113は、ステップ35で、応答のあったノードに関する仮想ノードが生成されていると判断すると、図9に示すノード状態テーブル141を参照して、この仮想ノードは起動中か否かを判断する(S36)。具体的には、このノード状態テーブル141の状態領域141uに「障害」が格納されているノードに関しては仮想ノードが生成されており且つ起動中であると判断し、状態領域141uに「障害危機」が格納されているノードに関しては仮想ノードが生成されているものの、起動待ち状態、つまり起動中でないと判断する。
【0068】
応答のあったノードに関する仮想ノードが起動中である場合には(S36でYES)、ノード状態監視部113は、その旨を仮想ノード生成部114に通知する。仮想ノード生成部114は、この通知を受けると、このノードの通信アドレスを仮想ノードの通信アドレスから実ノードの通信アドレスへ切り替える旨の切替指示メッセージを、各実ノードに送出する(S37)。この切替メッセージを受けた各実ノードは、通信アドレス切替の対象になっているノードの通信アドレスを新たな通信アドレスに切り替える。
【0069】
ステップ36で、仮想ノードが生成されているものの、この仮想ノードは起動中でないと判断された場合、及び、ステップ37で、ノードの通信アドレスが仮想ノードの通信アドレスから実ノードの通信アドレスへの切替指示メッセージが送出された場合、仮想ノード生成部114は、この仮想ノードを削除する(S38)。
【0070】
例えば、図12を用いて前述したように、実ノード「6」200cに障害が発生して(S1)、仮想ノード生成部114が仮想ノード「6」190を生成した後に、実ノード「6」200cに対する状態確認メッセージに対して、正常な応答があると(S33でYES)、ノード「6」の通信アドレスを仮想ノード「6」の通信アドレスから実ノード「6」の通信アドレスへの切替指示メッセージを送出した後(S37)、仮想ノード「6」が削除される(S38)。一方、他のノードは、以降、再び、実ノード6へアクセスするようになる。
【0071】
ノード状態監視部113は、ステップ35で仮想ノードが生成されていないと判断した場合、及び、ステップ38で仮想ノードが削除された場合、図9に示すノード状態テーブル141中で、応答のあったノードの状態領域141uを「正常」に設定して(S39)、処理を終了する。
【0072】
ノード状態監視部113は、ステップ33で、第一の待ち時間以内に応答がなかったと判断した場合、さらに、第二の待ち時間以内に応答があったか否かを判断する(S41)。この第二の待ち時間は、図10に示す制御ポリシーテーブル142のポリシーNo3に規定されており、ここでは3秒である。第二の待ち時間以内にノードからの応答があった場合、OLN管理部111のOLN構成情報管理部112は、この応答に含まれているノード管理データを該当ノードのノード管理データベースに格納する(S42)。
【0073】
次に、ノード状態監視部113は、前述のステップ35と同様に、図9に示すノード状態テーブル141を参照して、応答のあったノードに関する仮想ノードが生成されているか否かを判断する(S43)。ノード状態監視部113は、応答のあったノードに関する仮想ノードが生成されていないと判断すると、その旨を仮想ノード生成部114に通知し、この仮想ノード生成部114に、このノードの仮想ノードを生成させる(S44)。但し、この仮想ノードは起動させず、起動待ち状態にしておく。
【0074】
ノード状態監視部113は、ステップ43で仮想ノードが生成されていると判断した場合、及び、ステップ44で仮想ノードが生成された場合、図9に示すノード状態テーブル141中で、応答のあったノードの状態領域141uを「障害危機」に設定して(S45)、処理を終了する。なお、この障害危機も、障害の一種である。
【0075】
ノード状態監視部113は、ステップ41で、第二の待ち時間以内に応答がなかったと判断すると、図9に示すノード状態テーブル141を参照して、応答のないノードに関する仮想ノードが生成されているか否かを判断する(S51(図14))。ノード状態監視部113は、応答のないノードに関する仮想ノードが生成されていないと判断すると、その旨を仮想ノード生成部114に通知し、この仮想ノード生成部114に、このノードの仮想ノードを生成させる(S52)。
【0076】
ノード状態監視部113は、ステップ51で仮想ノードが生成されていると判断した場合、及び、ステップ52で仮想ノードが生成された場合、図9に示すノード状態テーブル141を参照して、応答のないノードに関する仮想ノードが起動中であるか否かを判断する(S53)。具体的には、応答のないノードに関して、ノード状態テーブル141の状態領域141uに「障害」が格納されている場合には、起動中であると判断し、「障害危機」が格納されている場合に、起動待ち状態、つまり起動中でないと判断する。
【0077】
ノード状態監視部113が、ステップ53で、応答のないノードに関する仮想ノードが起動中でないと判断すると、仮想ノード生成部114は、この仮想ノードを起動させる(S54)。さらに、仮想ノード生成部114は、ステップ53で仮想ノードが起動中であると判断された場合、及び、ステップ54で仮想ノードを起動させた場合、応答のないノードの通信アドレスを仮想ノードの通信アドレスの通信アドレスへ切り替える旨の切替指示メッセージを、各ノードに送出する(S55)。この切替指示メッセージを受けた各ノードは、通信アドレス切替の対象になっているノードの通信アドレスを新たな通信アドレスに切り替える。
【0078】
次に、ノード状態監視部113は、図9に示すノード状態テーブル141中で、応答のないノードの状態領域141uを「障害」に設定する(S56)。そして、このノード状態監視部113は、第三の待ち時間以内に応答があったか否かを判断する(S57)。この第三の待ち時間は、図10に示す制御ポリシーテーブル142のポリシーNo4に規定されており、ここでは300秒である。第三の待ち時間以内にノードからの応答があった場合、OLN管理部111のOLN構成情報管理部112は、この応答に含まれているノード管理データを該当ノードのノード管理データベースに格納して(S58)、処理を終了する。また、第三の待ち時間以内にノードからの応答がなかった場合、このノードに関して重度の障害があったとして、このノードの離脱処理が実行される(S61)。
【0079】
離脱処理は、以上で説明していない、OLN管理部111中に設けられている参加・離脱処理部が実行する。この離脱処理では、「背景技術」の欄で説明したように、重度の障害があったとされた実ノードの機能を他の健全な実ノードに移植し、この重度の障害があったとされた実ノードをオーバーレイネットワーク上にから離脱させる。この場合、重度の障害があったとされた実ノードの機能の移植先は、この実ノードの前隣接ノード又は後隣接ノードである。
【0080】
離脱処理が終了すると、仮想ノード生成部114は、重度の障害があったとされた実ノードの仮想ノードを削除して(S62)、処理を終了する。このように、本実施形態では、重度の障害であっても、この障害のあったノードの離脱処理の実行過程では、仮想ノードが実ノードの機能を実現しているため、「背景技術」の欄で説明した技術のように、障害への対処時間の長時間化することはない。
【0081】
以上のように、本実施形態では、ある実ノードに軽度の障害が生じた場合、この実ノードの仮想ノードを生成し、これに伴って、各ノードの管理テーブル中の障害ノードの通信アドレスの切替処理のみで、障害に対処しているので、ネットワーク上のオーバーヘッドが増大を防ぎ、しかも、所定の障害への対処時間を短時間化することができる。さらに、本実施形態では、仮想ノードを起動させるにあたり、実ノードが障害状態に至る前段階である障害危機状態で、仮想ノードを生成し、実ノードが障害状態に至ると、この仮想ノードを起動させているので、所定の障害への対処時間をより短くすることができる。また、本実施形態では、前述したように、ある実ノードに重度の障害が生じた場合であっても、この実ノードに関する切替処理が終了する迄、仮想ノードが実ノードの機能を実現しているため、障害への対処時間の長時間化することはない。
【0082】
なお、以上の実施形態では、OLN管理装置100からの状態確認メッセージが、各ノードに対するノード管理データの送信要求メッセージも兼ねているが、各メッセージを別々に送出するようにしてもよい。この場合、状態確認メッセージは、ノード状態監視部113が送出し、ノード管理データの送信要求メッセージは、OLN構成情報管理部112が送出することになる。これらのメッセージに対しては、いずれも、各ノードのノード用OLN管理部217が対応することになる。また、OLN管理装置100は、各ノードのノード管理データの収集にあたり、このノード管理データの送信要求メッセージを各ノードに送出せず、各ノードのノード用OLN管理部217が、一方的にノード管理データをOLN管理装置100へ送るようにしてもよい。
【0083】
また、以上では、各ノード200b〜200eに、それぞれ、RFIDリーダ270が一つずつ接続されているが、それぞれ、複数のRFIDリーダ270を接続するようにしてもよい。
【0084】
また、以上では、ユーザ座標値やこの検知時刻をAPデータとしているが、本発明は、各ノードに分散配置するデータであれば、他の如何なるAPデータであっても構わない。
【図面の簡単な説明】
【0085】
【図1】本発明に係る一実施形態におけるオーバーレイネットワークシステムの構成図である。
【図2】本発明に係る一実施形態におけるOLN管理装置の構成図である。
【図3】本発明に係る一実施形態における仮想ノードの構成である。
【図4】本発明に係る一実施形態における実ノードの構成図である。
【図5】本発明に係る一実施形態におけるハッシュテーブルのデータ構成を示す説明図である。
【図6】本発明に係る一実施形態における各ノードのAPデータテーブルのデータ構成を示す説明図である。
【図7】本発明に係る一実施形態における各ノードのルーティグテーブルのデータ構成を示す説明図である。
【図8】本発明に係る一実施形態における各ノードの管理テーブルのデータ構成を示す説明図である。
【図9】本発明に係る一実施形態におけるノード状態テーブルのデータ構成を示す説明図である。
【図10】本発明に係る一実施形態における制御ポリシーテーブルのデータ構成を示す説明図である。
【図11】本発明に係る一実施形態のオーバーレイネットワークシステムの動作を示すシーケンス図(障害が発生していない場合)である。
【図12】本発明に係る一実施形態のオーバーレイネットワークシステムの動作を示すシーケンス図(障害が発生した場合)である。
【図13】本発明に係る一実施形態におけるOLN管理装置のOLN管理部の動作を示すフローチャートである(その1)。
【図14】本発明に係る一実施形態におけるOLN管理装置のOLN管理部の動作を示すフローチャートである(その2)。
【符号の説明】
【0086】
1:WAN、2:LAN、3:アクセスポイント、5:RFIDタグ、10:オーバーレイネットワーク、100:OLN管理装置、110,210:CPU、111:OLN管理部、112:OLN構成情報管理部、113:ノード状態監視部、114:仮想ノード生成部、115:制御ポリシー設定部、116:OLN通信制御部、117,197,217:ノード用OLN管理部、118,198,218:OLN制御部、119:ユーザ要求対処部、120:メモリ、130:外部記憶装置、140:OLN管理データベース、141:ノード状態テーブル、142:制御ポリシーテーブル、144:ハッシュテーブル、150a,150ac:ノード0管理データベース、250bc:ノード2管理データベース、250c,250cc,195:ノード6管理データベース、250dc:ノード9管理データベース、250ec:ノード13管理データベース、151a,191,251b〜251e:APデータテーブル、152a,192,252b〜252e:管理テーブル、153a,193,253b〜253e:ルーティングテーブル、131:OLN管理プログラム、137,237:ノード用OLN管理プログラム、138,238:OLNプログラム、139:ユーザ要求対処プログラム、170:ノード0、190:仮想ノード6、200b:ノード2、200c:ノード6、200d:ノード9、200e:ノード13、270:RFIDリーダ、300:ユーザ端末
【特許請求の範囲】
【請求項1】
データを保持していると共に、データへのアクセスのためのノードを示すルート情報及び該ルート情報に示されているノードの通信アドレスを含む構成情報を保持している複数のノードを備えているオーバーレイネットワークの管理プログラムにおいて、
コンピュータの通信装置により、前記複数のノードから、各ノードが保持している少なくとも前記構成情報を収集させ、該構成情報を該コンピュータの記憶装置に格納するノード情報管理ステップと、
前記通信装置により、前記複数のノードのそれぞれに対する通信を定期的に試みさせて、各ノードからの応答に応じて、該複数のノードの状態を把握するノード状態監視ステップと、
前記ノード状態監視ステップで把握された前記複数のノードの状態のうち、いずれかのノードの状態が予め定めた障害状態である場合には、前記記憶装置に格納されている該ノードの前記構成情報を用いて、該ノードに関して、他のノードからアクセス可能な仮想ノードを前記コンピュータ上に生成し、該仮想ノードを起動させる仮想ノード生成ステップと、
前記仮想ノード生成ステップで、仮想ノードが生成され、該仮想ノードが起動すると、前記予め定めた障害状態であるとされた前記ノードの通信アドレスとして、該ノードの仮想ノードが生成された自コンピュータの通信アドレスへの切替える旨の通信アドレス切替指示を、前記通信装置により、前記他のノードに通知させて、該他のノードが前記予め定めた障害状態であるとされた該ノードにアクセスしようとしている場合に、該ノードの仮想ノードにアクセスさせる切替通知ステップと、
を前記コンピュータに実行させることを特徴とするオバーレイネットワークの管理プログラム。
【請求項2】
請求項1に記載のオバーレイネットワークの管理プログラムにおいて、
前記ノード状態監視ステップでは、前記通信装置により、前記複数のノードのそれぞれに対して、定期的にノード状態確認メッセージを送出させ、該ノード状態確認メッセージに対する各ノードからの応答時間に応じて、該複数のノードの状態を把握する、
ことを特徴とするオーバレイネットワークの管理プログラム。
【請求項3】
請求項2に記載のオーバレイネットワークの管理プログラムにおいて、
前記ノード状態監視ステップでは、前記ノード状態確認メッセージに対して、予め定めた第一の待ち時間以内に応答があった場合には、応答したノードは正常であると判断し、該第一の待ち時間を超え、且つ該第一の待ち時間より長い第二の待ち時間以内に応答があった場合には、応答したノードは障害危機であると判断し、該第二の待ち時間を超えても応答がない場合には、応答のないノードは障害であると判断し、
前記仮想ノード生成ステップでは、前記ノード状態確認メッセージに対しての応答が前記第一の待ち時間を超え、且つ前記第二の待ち時間以内であった場合には、応答したノードに関して前記仮想ノードを生成して、該仮想ノードを起動待ち状態にし、前記ノード状態確認メッセージに対しての応答が前記第二の待ち時間を越えてもない場合には、応答のないノードに関して仮想ノードが生成されていなければ該仮想ノードを生成し、該仮想ノード又は該ノードに関して既に起動待ち状態になっている仮想ノードを起動させる、
ことを特徴とするオーバレイネットワークの管理プログラム。
【請求項4】
請求項3に記載のオーバレイネットワークの管理プログラムにおいて、
前記ノード状態確認メッセージに対しての応答が前記第一の待ち時間以内にあった場合、応答したノードに関する仮想ノードが生成され、且つ該仮想ノードが起動しているか否かを判断する仮想ノード確認ステップと、
前記仮想ノード確認ステップで、前記仮想ノードが生成され、且つ該仮想ノードが起動していると判断された場合、前記切替通信ステップで切替指示された通信アドレスを元の通信アドレスに戻す旨の第二の通信アドレス切替指示を、前記通信装置により、前記他のノードに通知させる第二の切替通知ステップと、
前記仮想ノード確認ステップで、前記仮想ノードが生成されていると判断された場合、該仮想ノードを削除する仮想ノード削除ステップと、
を前記コンピュータに実行させることを特徴とするオーバレイネットワークの管理プログラム。
【請求項5】
請求項3及び4のいずれか一項に記載のオーバレイネットワークの管理プログラムにおいて、
前記ノード状態監視ステップでは、前記ノード状態確認メッセージに対して、前記第二の待ち時間を超え、且つ該第二の待ち時間よりも長い第三の待ち時間を越えても応答がない場合には、応答のないノードは重度障害であると判断し、
前記ノード状態確認メッセージに対しての応答が前記第三の待ち時間を越えてもない場合には、応答のないノードを前記オーバレイネットワークから離脱させる離脱処理ステップを前記コンピュータに実行させることを特徴とするオーバレイネットワークの管理プログラム。
【請求項6】
データを保持していると共に、データへのアクセスのためのノードを示すルート情報及び該ルート情報に示されているノードの通信アドレスを含む構成情報を保持している複数のノードを備えているオーバーレイネットワークの管理方法において、
コンピュータの通信装置により、前記複数のノードから、各ノードが保持している少なくとも前記構成情報を収集させ、該構成情報を該コンピュータの記憶装置に格納するノード情報管理ステップと、
前記通信装置により、前記複数のノードのそれぞれに対する通信を定期的に試みさせて、各ノードからの応答に応じて、該複数のノードの状態を把握するノード状態監視ステップと、
前記ノード状態監視ステップで把握された前記複数のノードの状態のうち、いずれかのノードの状態が予め定めた障害状態である場合には、前記記憶装置に格納されている該ノードの前記構成情報を用いて、該ノードに関して、他のノードからアクセス可能な仮想ノードを前記コンピュータ上に生成し、該仮想ノードを起動させる仮想ノード生成ステップと、
前記仮想ノード生成ステップで、仮想ノードが生成され、該仮想ノードが起動すると、前記予め定めた障害状態であるとされた前記ノードの通信アドレスとして、該ノードの仮想ノードが生成された自コンピュータの通信アドレスに変更する旨の指示を含む通信アドレス切替通知を、前記通信装置により、前記他のノードに通知させて、該他のノードが前記予め定めた障害状態であるとされた該ノードにアクセスしようとしている場合に、該ノードの仮想ノードにアクセスさせる切替通知ステップと、
を前記コンピュータが実行することを特徴とするオバーレイネットワークの管理方法。
【請求項7】
データを保持していると共に、データへのアクセスのためのノードを示すルート情報及び該ルート情報に示されているノードの通信アドレスを含む構成情報を保持している複数のノードを備えているオーバーレイネットワークの管理装置において、
データが格納される記憶装置と、
前記複数のノードから、各ノードが保持している少なくとも前記構成情報を収集し、該構成情報を前記記憶装置に格納するノード情報管理手段と、
前記複数のノードのそれぞれに対する通信を定期的に試みて、各ノードからの応答に応じて、該複数のノードの状態を把握するノード状態監視手段と、
前記ノード状態監視手段で把握された前記複数のノードの状態のうち、いずれかのノードの状態が予め定めた障害状態である場合には、前記記憶装置に格納されている該ノードの前記構成情報を用いて、該ノードに関して、他のノードからアクセス可能な仮想ノードを生成し、該仮想ノードを起動させ、該ノードの通信アドレスとして、該ノードに関する仮想ノードが生成された自装置の通信アドレスに変更する旨の通信アドレス切替指示を、前記他のノードに通知し、該他のノードが前記予め定めた障害状態であるとされた該ノードにアクセスしようとしている場合に、該ノードに関する該仮想ノードにアクセスさせる仮想ノード生成手段と、
を備えていることを特徴とするオバーレイネットワークの管理装置。
【請求項8】
請求項7に記載のオバーレイネットワークの管理装置において、
前記ノード状態監視手段は、前記複数のノードのそれぞれに対して、定期的にノード状態確認メッセージを送出し、該ノード状態確認メッセージに対して、予め定めた第一の待ち時間以内に応答があった場合には、応答したノードは正常であると判断し、該第一の待ち時間を超え、且つ該第一の待ち時間より長い第二の待ち時間以内に応答があった場合には、応答したノードは障害危機であると判断し、該第二の待ち時間を超えても応答がない場合には、応答のないノードは障害であると判断し、
前記仮想ノード生成手段は、前記ノード状態確認メッセージに対しての応答が前記第一の待ち時間を超え、且つ前記第二の待ち時間以内であった場合には、応答したノードに関して前記仮想ノードを生成して、該仮想ノードを起動待ち状態にし、前記ノード状態確認メッセージに対しての応答が前記第二の待ち時間を越えてもない場合には、応答のないノードに関して仮想ノードが生成されていなければ該仮想ノードを生成し、該仮想ノード又は該ノードに関して既に起動待ち状態になっている仮想ノードを起動させる、
ことを特徴とするオーバレイネットワークの管理装置。
【請求項9】
請求項8に記載のオーバレイネットワークの管理装置において、
前記ノード状態監視手段は、前記ノード状態確認メッセージに対しての応答が前記第一の待ち時間以内にあった場合、応答したノードに関する仮想ノードが生成され、且つ該仮想ノードが起動しているか否かを判断し、
前記仮想ノード生成手段は、前記ノード状態監視手段により、前記ノード状態確認メッセージに対して前記第一の待ち時間以内に応答したノードに関する仮想ノードが生成され、且つ該仮想ノードが起動していると判断された場合、前記通信アドレス切替指示で切替えた通信アドレスを元の通信アドレスに戻す旨の第二の通信アドレス切替指示を前記他のノードに通知し、該仮想ノードを削除する、
ことを特徴とするオーバレイネットワークの管理装置。
【請求項10】
請求項7から9のいずれか一項に記載のオーバレイネットワークの管理装置と、
前記複数のノードとを備え、
前記複数のノードは、それぞれ、前記管理装置からの保持情報の送信要求に対して、又は自ら定期的に、該ノードが保持している少なくとも前記構成情報を該管理装置へ送出し、該管理装置がノードの状態を把握するために、該管理装置からの前記定期的な通信に対して応答するオーバーレイネットワーク管理手段を有している、
ことを特徴とするオーバレイネットワークシステム。
【請求項1】
データを保持していると共に、データへのアクセスのためのノードを示すルート情報及び該ルート情報に示されているノードの通信アドレスを含む構成情報を保持している複数のノードを備えているオーバーレイネットワークの管理プログラムにおいて、
コンピュータの通信装置により、前記複数のノードから、各ノードが保持している少なくとも前記構成情報を収集させ、該構成情報を該コンピュータの記憶装置に格納するノード情報管理ステップと、
前記通信装置により、前記複数のノードのそれぞれに対する通信を定期的に試みさせて、各ノードからの応答に応じて、該複数のノードの状態を把握するノード状態監視ステップと、
前記ノード状態監視ステップで把握された前記複数のノードの状態のうち、いずれかのノードの状態が予め定めた障害状態である場合には、前記記憶装置に格納されている該ノードの前記構成情報を用いて、該ノードに関して、他のノードからアクセス可能な仮想ノードを前記コンピュータ上に生成し、該仮想ノードを起動させる仮想ノード生成ステップと、
前記仮想ノード生成ステップで、仮想ノードが生成され、該仮想ノードが起動すると、前記予め定めた障害状態であるとされた前記ノードの通信アドレスとして、該ノードの仮想ノードが生成された自コンピュータの通信アドレスへの切替える旨の通信アドレス切替指示を、前記通信装置により、前記他のノードに通知させて、該他のノードが前記予め定めた障害状態であるとされた該ノードにアクセスしようとしている場合に、該ノードの仮想ノードにアクセスさせる切替通知ステップと、
を前記コンピュータに実行させることを特徴とするオバーレイネットワークの管理プログラム。
【請求項2】
請求項1に記載のオバーレイネットワークの管理プログラムにおいて、
前記ノード状態監視ステップでは、前記通信装置により、前記複数のノードのそれぞれに対して、定期的にノード状態確認メッセージを送出させ、該ノード状態確認メッセージに対する各ノードからの応答時間に応じて、該複数のノードの状態を把握する、
ことを特徴とするオーバレイネットワークの管理プログラム。
【請求項3】
請求項2に記載のオーバレイネットワークの管理プログラムにおいて、
前記ノード状態監視ステップでは、前記ノード状態確認メッセージに対して、予め定めた第一の待ち時間以内に応答があった場合には、応答したノードは正常であると判断し、該第一の待ち時間を超え、且つ該第一の待ち時間より長い第二の待ち時間以内に応答があった場合には、応答したノードは障害危機であると判断し、該第二の待ち時間を超えても応答がない場合には、応答のないノードは障害であると判断し、
前記仮想ノード生成ステップでは、前記ノード状態確認メッセージに対しての応答が前記第一の待ち時間を超え、且つ前記第二の待ち時間以内であった場合には、応答したノードに関して前記仮想ノードを生成して、該仮想ノードを起動待ち状態にし、前記ノード状態確認メッセージに対しての応答が前記第二の待ち時間を越えてもない場合には、応答のないノードに関して仮想ノードが生成されていなければ該仮想ノードを生成し、該仮想ノード又は該ノードに関して既に起動待ち状態になっている仮想ノードを起動させる、
ことを特徴とするオーバレイネットワークの管理プログラム。
【請求項4】
請求項3に記載のオーバレイネットワークの管理プログラムにおいて、
前記ノード状態確認メッセージに対しての応答が前記第一の待ち時間以内にあった場合、応答したノードに関する仮想ノードが生成され、且つ該仮想ノードが起動しているか否かを判断する仮想ノード確認ステップと、
前記仮想ノード確認ステップで、前記仮想ノードが生成され、且つ該仮想ノードが起動していると判断された場合、前記切替通信ステップで切替指示された通信アドレスを元の通信アドレスに戻す旨の第二の通信アドレス切替指示を、前記通信装置により、前記他のノードに通知させる第二の切替通知ステップと、
前記仮想ノード確認ステップで、前記仮想ノードが生成されていると判断された場合、該仮想ノードを削除する仮想ノード削除ステップと、
を前記コンピュータに実行させることを特徴とするオーバレイネットワークの管理プログラム。
【請求項5】
請求項3及び4のいずれか一項に記載のオーバレイネットワークの管理プログラムにおいて、
前記ノード状態監視ステップでは、前記ノード状態確認メッセージに対して、前記第二の待ち時間を超え、且つ該第二の待ち時間よりも長い第三の待ち時間を越えても応答がない場合には、応答のないノードは重度障害であると判断し、
前記ノード状態確認メッセージに対しての応答が前記第三の待ち時間を越えてもない場合には、応答のないノードを前記オーバレイネットワークから離脱させる離脱処理ステップを前記コンピュータに実行させることを特徴とするオーバレイネットワークの管理プログラム。
【請求項6】
データを保持していると共に、データへのアクセスのためのノードを示すルート情報及び該ルート情報に示されているノードの通信アドレスを含む構成情報を保持している複数のノードを備えているオーバーレイネットワークの管理方法において、
コンピュータの通信装置により、前記複数のノードから、各ノードが保持している少なくとも前記構成情報を収集させ、該構成情報を該コンピュータの記憶装置に格納するノード情報管理ステップと、
前記通信装置により、前記複数のノードのそれぞれに対する通信を定期的に試みさせて、各ノードからの応答に応じて、該複数のノードの状態を把握するノード状態監視ステップと、
前記ノード状態監視ステップで把握された前記複数のノードの状態のうち、いずれかのノードの状態が予め定めた障害状態である場合には、前記記憶装置に格納されている該ノードの前記構成情報を用いて、該ノードに関して、他のノードからアクセス可能な仮想ノードを前記コンピュータ上に生成し、該仮想ノードを起動させる仮想ノード生成ステップと、
前記仮想ノード生成ステップで、仮想ノードが生成され、該仮想ノードが起動すると、前記予め定めた障害状態であるとされた前記ノードの通信アドレスとして、該ノードの仮想ノードが生成された自コンピュータの通信アドレスに変更する旨の指示を含む通信アドレス切替通知を、前記通信装置により、前記他のノードに通知させて、該他のノードが前記予め定めた障害状態であるとされた該ノードにアクセスしようとしている場合に、該ノードの仮想ノードにアクセスさせる切替通知ステップと、
を前記コンピュータが実行することを特徴とするオバーレイネットワークの管理方法。
【請求項7】
データを保持していると共に、データへのアクセスのためのノードを示すルート情報及び該ルート情報に示されているノードの通信アドレスを含む構成情報を保持している複数のノードを備えているオーバーレイネットワークの管理装置において、
データが格納される記憶装置と、
前記複数のノードから、各ノードが保持している少なくとも前記構成情報を収集し、該構成情報を前記記憶装置に格納するノード情報管理手段と、
前記複数のノードのそれぞれに対する通信を定期的に試みて、各ノードからの応答に応じて、該複数のノードの状態を把握するノード状態監視手段と、
前記ノード状態監視手段で把握された前記複数のノードの状態のうち、いずれかのノードの状態が予め定めた障害状態である場合には、前記記憶装置に格納されている該ノードの前記構成情報を用いて、該ノードに関して、他のノードからアクセス可能な仮想ノードを生成し、該仮想ノードを起動させ、該ノードの通信アドレスとして、該ノードに関する仮想ノードが生成された自装置の通信アドレスに変更する旨の通信アドレス切替指示を、前記他のノードに通知し、該他のノードが前記予め定めた障害状態であるとされた該ノードにアクセスしようとしている場合に、該ノードに関する該仮想ノードにアクセスさせる仮想ノード生成手段と、
を備えていることを特徴とするオバーレイネットワークの管理装置。
【請求項8】
請求項7に記載のオバーレイネットワークの管理装置において、
前記ノード状態監視手段は、前記複数のノードのそれぞれに対して、定期的にノード状態確認メッセージを送出し、該ノード状態確認メッセージに対して、予め定めた第一の待ち時間以内に応答があった場合には、応答したノードは正常であると判断し、該第一の待ち時間を超え、且つ該第一の待ち時間より長い第二の待ち時間以内に応答があった場合には、応答したノードは障害危機であると判断し、該第二の待ち時間を超えても応答がない場合には、応答のないノードは障害であると判断し、
前記仮想ノード生成手段は、前記ノード状態確認メッセージに対しての応答が前記第一の待ち時間を超え、且つ前記第二の待ち時間以内であった場合には、応答したノードに関して前記仮想ノードを生成して、該仮想ノードを起動待ち状態にし、前記ノード状態確認メッセージに対しての応答が前記第二の待ち時間を越えてもない場合には、応答のないノードに関して仮想ノードが生成されていなければ該仮想ノードを生成し、該仮想ノード又は該ノードに関して既に起動待ち状態になっている仮想ノードを起動させる、
ことを特徴とするオーバレイネットワークの管理装置。
【請求項9】
請求項8に記載のオーバレイネットワークの管理装置において、
前記ノード状態監視手段は、前記ノード状態確認メッセージに対しての応答が前記第一の待ち時間以内にあった場合、応答したノードに関する仮想ノードが生成され、且つ該仮想ノードが起動しているか否かを判断し、
前記仮想ノード生成手段は、前記ノード状態監視手段により、前記ノード状態確認メッセージに対して前記第一の待ち時間以内に応答したノードに関する仮想ノードが生成され、且つ該仮想ノードが起動していると判断された場合、前記通信アドレス切替指示で切替えた通信アドレスを元の通信アドレスに戻す旨の第二の通信アドレス切替指示を前記他のノードに通知し、該仮想ノードを削除する、
ことを特徴とするオーバレイネットワークの管理装置。
【請求項10】
請求項7から9のいずれか一項に記載のオーバレイネットワークの管理装置と、
前記複数のノードとを備え、
前記複数のノードは、それぞれ、前記管理装置からの保持情報の送信要求に対して、又は自ら定期的に、該ノードが保持している少なくとも前記構成情報を該管理装置へ送出し、該管理装置がノードの状態を把握するために、該管理装置からの前記定期的な通信に対して応答するオーバーレイネットワーク管理手段を有している、
ことを特徴とするオーバレイネットワークシステム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【公開番号】特開2010−28525(P2010−28525A)
【公開日】平成22年2月4日(2010.2.4)
【国際特許分類】
【出願番号】特願2008−188553(P2008−188553)
【出願日】平成20年7月22日(2008.7.22)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
【公開日】平成22年2月4日(2010.2.4)
【国際特許分類】
【出願日】平成20年7月22日(2008.7.22)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
[ Back to top ]