(57)【要約】【課題】階層型のネットワークシステムにおいて、下位層の負荷を考慮したネットワークシステム全体の負荷均等化を行う。【解決手段】任意の３階層（ｎ〜ｎ＋２階層）において、第ｎ＋１階層の一つのノードは、第ｎ＋２階層の一つ以上のノードからそれぞれの負荷情報を取得し、取得した負荷情報と自ノードの負荷情報とに基づき、自ノードの空きリソース量を算出し、算出した自ノードの空きリソース量を、第ｎ階層のノードへ送信し、第ｎ階層のノードは、第ｎ＋１階層の各ノードから取得した空きリソース量に基づき、重み値を算出し、算出した重み値に基づき、受信した処理要求を、第ｎ＋１階層のいずれかのノードへ分配する。【選択図】  図28
2014035717.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードが３階層以上に接続され、最上位の根ノードが受信した処理要求を、下位層ノードへ転送し処理させるネットワークシステムにおける負荷分散方法であって、
任意の３階層（ｎ〜ｎ＋２階層）において、
第ｎ＋１階層の一つのノードは、
第ｎ＋２階層の一つ以上のノードからそれぞれの負荷情報を取得し、
取得した前記負荷情報と自ノードの負荷情報とに基づき、自ノードの空きリソース量を算出し、
算出した自ノードの空きリソース量を、第ｎ階層のノードへ送信し、
第ｎ階層のノードは、
第ｎ＋１階層の各ノードから取得した空きリソース量に基づき、重み値を算出し、
算出した前記重み値に基づき、受信した前記処理要求を、第ｎ＋１階層のいずれかのノードへ分配する
ことを特徴とする負荷分散方法。
【請求項２】
請求項１記載の負荷分散方法において、
前記ネットワークシステムが前記根ノードを複数備える場合、
各々の前記根ノードが、自根ノードに接続される第２階層のノードから前記空きリソース量を取得し、
第２階層の各ノードから取得した空きリソース量に基づき、重み値を算出し、
他の根ノードへ、算出した前記重み値を送信し、前記他の根ノードから、前記他の根ノードの重み値を取得し、
自他の根ノードの前記重み値に基づき、受信した前記処理要求を、自ノードを含むいずれかの根ノードへ分配する
ことを特徴とする負荷分散方法。
【請求項３】
請求項１記載の負荷分散方法において、
前記ネットワークシステムが、複数の前記根ノードとＤＮＳサーバとを備える場合、
各々の前記根ノードが、自根ノードに接続される第２階層のノードから前記空きリソース量を取得し、
第２階層の各ノードから取得した空きリソース量に基づき、重み値を算出し、
算出した前記重み値と当該根ノードのアドレス情報とを、前記ＤＮＳサーバへ送信する
ことを特徴とする負荷分散方法。
【請求項４】
請求項１から３のいずれか一に記載の負荷分散方法において、
前記第ｎ階層ノードは、
第ｎ＋１階層の各ノードから取得した空きリソース量の標準偏差を算出し、
前記標準偏差と、あらかじめ定められた指定値とに基づき、前記重み値を算出する
ことを特徴とする負荷分散方法。
【請求項５】
請求項１から４のいずれか一に記載の負荷分散方法において、
前記空きリソース量は、ＣＰＵ利用率、または、コネクション数に基づいて算出する
ことを特徴とする負荷分散方法。
【請求項６】
複数のノードが３階層以上に接続され、最上位の根ノードが受信した処理要求を、下位層ノードへ転送し処理させるネットワークシステムであって、
任意の３階層（ｎ〜ｎ＋２階層）において、
第ｎ＋１階層の一つのノードは、
第ｎ＋２階層の一つ以上のノードからそれぞれの負荷情報を取得する機能と、
取得した前記負荷情報と自ノードの負荷情報とに基づき、自ノードの空きリソース量を算出する機能と、
算出した自ノードの空きリソース量を、第ｎ階層のノードへ送信する機能と、を備え、
第ｎ階層のノードは、
第ｎ＋１階層の各ノードから取得した空きリソース量に基づき、重み値を算出する機能と、
算出した前記重み値に基づき、受信した前記処理要求を、第ｎ＋１階層のいずれかのノードへ分配する機能と、を備える
ことを特徴とするネットワークシステム。
【請求項７】
請求項６記載のネットワークシステムにおいて、
前記ネットワークシステムが前記根ノードを複数備える場合、
各々の前記根ノードが、
自根ノードに接続される第２階層のノードから前記空きリソース量を取得する機能と、
第２階層の各ノードから取得した空きリソース量に基づき、重み値を算出する機能と、
他の根ノードへ、算出した前記重み値を送信する機能と、前記他の根ノードから、前記他の根ノードの重み値を取得する機能と、
自他の根ノードの前記重み値に基づき、受信した前記処理要求を、自ノードを含むいずれかの根ノードへ分配する機能と、を備える
ことを特徴とするネットワークシステム。
【請求項８】
請求項７記載のネットワークシステムにおいて、
前記ネットワークシステムが、複数の前記根ノードとＤＮＳサーバとを備える場合、
各々の前記根ノードが、
自根ノードに接続される第２階層のノードから前記空きリソース量を取得する機能と、
第２階層の各ノードから取得した空きリソース量に基づき、重み値を算出する機能と、
算出した前記重み値と当該根ノードのアドレス情報とを、前記ＤＮＳサーバへ送信する機能と、を備える
ことを特徴とするネットワークシステム。
【請求項９】
請求項６から８のいずれか一に記載のネットワークシステムにおいて、
前記第ｎ階層ノードは、
第ｎ＋１階層の各ノードから取得した空きリソース量の標準偏差を算出する機能と、
前記標準偏差と、あらかじめ定められた指定値とに基づき、前記重み値を算出する機能と、を備える
ことを特徴とするネットワークシステム。
【請求項１０】
請求項６から９のいずれか一に記載のネットワークシステムにおいて、
前記空きリソース量は、ＣＰＵ利用率、または、コネクション数に基づいて算出する機能と、を備える
ことを特徴とするネットワークシステム。
【請求項１１】
複数のノードが３階層以上に接続され、最上位の根ノードが受信した処理要求を、下位層ノードへ転送し処理させるネットワークシステムにおけるノードであって、
下位層の一つ以上のノードからそれぞれの負荷情報を取得する機能と、
取得した前記負荷情報と自ノードの負荷情報とに基づき、自ノードの空きリソース量を算出する機能と、
算出した自ノードの空きリソース量を、上位層のノードへ送信する機能と、を備える
ことを特徴とするノード。
【請求項１２】
複数のノードが３階層以上に接続され、最上位の根ノードが受信した処理要求を、下位層ノードへ転送し処理させるネットワークシステムにおいて、前記ネットワークシステムが前記根ノードを複数備える場合の根ノードであって、
自根ノードに接続される第２階層のノードから当該第２階層のノードの空きリソース量を取得する機能と、
第２階層の各ノードから取得した空きリソース量に基づき、重み値を算出する機能と、
他の根ノードへ、算出した前記重み値を送信する機能と、
前記他の根ノードから、当該他の根ノードの重み値を取得する機能と、
自他の根ノードの前記重み値に基づき、受信した前記処理要求を、自ノードを含むいずれかの根ノードへ分配する機能と、を備える
ことを特徴とする根ノード。
【請求項１３】
複数のノードが３階層以上に接続され、最上位の根ノードが受信した処理要求を、下位層ノードへ転送し処理させるネットワークシステムにおいて、前記ネットワークシステムが、複数の前記根ノードとＤＮＳサーバとを備える場合の根ノードであって、
自根ノードに接続される第２階層のノードから当該第２階層のノードの空きリソース量を取得する機能と、
第２階層の各ノードから取得した空きリソース量に基づき、重み値を算出する機能と、
算出した前記重み値と当該根ノードのアドレス情報とを、前記ＤＮＳサーバへ送信する機能と、を備える
ことを特徴とする根ノード。
【請求項１４】
請求項１２または１３に記載のネ根ノードにおいて、
第２階層の各ノードから取得した空きリソース量の標準偏差を算出する機能と、
前記標準偏差と、あらかじめ定められた指定値とに基づき、前記重み値を算出する機能と、を備える
ことを特徴とする根ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
開示される主題は、WWW（World Wide Web）やメールシステム、データセンタ等に代表されるネットワークシステムにおいて、サーバ装置又は端末とサーバ装置間の通信経路上に設置される複数の中継装置に関する。
【背景技術】
【０００２】
クライアント端末は、LAN（Local Area Network）やWAN（Wide Area Network）に接続されるサーバ装置（以下、サーバという）へスイッチやファイアウォール、ゲートウェイ等の中継装置を介してアクセスする。有線ネットワーク網や無線ネットワーク網に接続される端末の普及、携帯端末の高性能化や高機能化、無線通信網の高速化や高帯域化、動画や音楽といったコンテンツの大容量化によって、WWW等のサーバ装置とクライアント端末間でやり取りされる通信量が増大している。また、このような環境下で生成される通信ログや、各種センサ情報など、大容量の情報が蓄積され続けている。このような大容量の情報を効率良く管理する必要がある。
【０００３】
このような課題の基、キャリアやデータセンタシステム内のスイッチやファイアウォール、ゲートウェイ等の中継装置を通過する通信量は膨大なものとなり、増加の一途である。この通信量増加に伴い、中継装置やサーバ処理能力増強が急務である。能力増強対策として、ハードウエア性能向上を図る手法と、リクエストを分散処理する手法が挙げられる。一般に、前者はスケールアップと呼ばれ、後者はスケールアウトと呼ばれている。スケールアップによる対処では、単一障害点によるサービス停止、ハードウエア更新時のサービス停止などの問題点がある。大規模なシステムを有するキャリアやデータセンタ運用業者は、サービスを停止させず、通信量の増加に対応できるスケールアウト型の能力増強を図ることが多い。また、通信量の増加だけではなく、大量の情報の処理実行や管理を行うにあたってもスケールアウト型の能力増強を図ることが多い。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第2008/129597号パンフレット
【特許文献２】特開2010-279238号公報
【非特許文献】
【０００５】
【非特許文献１】Microsoft Corporation、"Layered Application Guidelines"、[2012年6月13日検索]、インターネット＜URL:http://msdn.microsoft.com/en-us/library/ ee658109.aspx＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
一般的にシステム内のサーバ等のノードは、可用性やスケーラビリティ等を効率的に満たすため、多階層的に接続される。この多階層的に構築されたシステムでは、上位層のノードから下位層のノードへ処理要求が転送される。この技術内容が非特許文献1に開示されている。このような多階層的に構築されたシステムでは、親子関係にある（互いの階層が隣接する）ノード間の監視による障害回避等は実現しているが、親と孫関係にある（互いの階層の間に一つ以上の階層がある）ノード間の監視が行われていないため、孫ノードの障害を親が認識せずに、処理要求を子ノードへ転送してしまい、サービス無応答の状態が発生してしまう。
【０００７】
この問題を解決するための技術が、特許文献1に開示されている（段落0051〜0055、0056〜0065、0073〜0105、及び0106〜0116）。特許文献1の技術では、多階層的に構築されたシステムにおいて、全階層の全ノードから生死情報を含む負荷情報をある一ヶ所の上位ノードへ集約管理する。本技術は、負荷情報を一ヶ所へ集約することにより、何れかの階層のノードで障害が発生したとしても、その障害経路を経由しないよう途中のノードへ指示することができ、下位ノードの障害によるサービス無応答を防ぐ内容である。また本技術では、負荷を集中的に管理することで、負荷がある閾値を超えた場合、そのノードへ処理要求を転送せず、安定的にシステムを運用できるとしている。
【０００８】
また、多階層的に構築されたシステムにおいて、分散電源が逐次追加される環境下で、全体の電力提供を安定的に管理して膨大な電力需要家の監視制御を実現する技術が、特許文献2に開示されている（段落0043〜0044）。特許文献2の技術は、電力の流れを制御する監視センタをトップとした上位層から下位層へ放射状に構築される木構造の配電・給電システムにおいて、1階層下の監視制御器から消費電力量又は発電量を収集、集約の後、1階層上の監視制御器へ報告し、監視センタの監視制御器を起点として1階層下の監視制御器へ消費電力量又は発電電力量を指示する内容である。特許文献2の技術では、木構造のシステムにおいて、下位層の情報を集約して上位層へ報告している。このような考え方をもって、下位層の状況を踏まえた分散制御が可能であることを示している。
【０００９】
しかし、特許文献1の技術では、システムの全ノードの負荷情報等を特定のノードに集約させるため、通信コストが大きくなってしまう。また、ある負荷の閾値を超えたノードに対して処理要求を転送しないように制御した場合、閾値を超えたノードは一定期間処理要求を受け付けず、他ノードにて処理要求を実行してしまうため、システム全体の負荷が均等化しない。
【００１０】
また、多階層的に構築されたシステムに特許文献2の技術を応用した場合、経路途中のノードの負荷を考慮していないため、負荷の均等化を図ることが難しい。そして、分散システムは、上位層から下位層へ放射状に構築される木構造以外に、ノード間がｎ：ｍに接続される形態も一般的である。また複数の根（root）を持つ構成で、DNS（Domain Name System）を利用した分散形態のシステムも有りうる。このような接続形態のシステムにおいて、特許文献2の技術を適用できない。
【課題を解決するための手段】
【００１１】
本明細書では、３階層以上に構成されたシステムにおいて、親子関係にあるノード間で、親ノードが、複数の下位層の、各階層一つ以上のノードに掛かる負荷に基づき実施する負荷分散技術が開示される。
【００１２】
開示される技術によれば、３階層以上に構成されたシステムの任意の３階層において、第２階層に属する一つ以上のノード（子ノードという）の空きリソース量に基づき、負荷が分散される。
【００１３】
例えば、子ノードは、第３階層に属するノード（孫ノードという）から取得した孫ノードの負荷情報と子ノード自身の負荷情報とに基づいて、子ノード以下の階層の空きリソース量を算出し、算出した空きリソース量を上位層のノード(親ノードという)へ送信し、親ノードは、一つ以上の子ノードから取得した空きリソース量に基づき、重み値を算出し、算出した重み値に基づき、受信した処理要求を、いずれかの子ノードへ分配することにより、負荷均等化を実現する。
【００１４】
複数の階層に跨り、各ノードの負荷が均等に近づくように処理要求を分配し、負荷を分散させることによって複数のノードの中で突出して負荷が高いノードが無くなるため、例えばバースト的な処理要求を処理するような場合に、負荷の高いノードにおいてリソース枯渇によるサービス停止やレスポンスの悪化を引き起こすことを防止できる。
【００１５】
上記態様によれば、親ノードや管理ノードが二つ以上下位の階層のノードの生死監視や負荷情報の取得をしなくても、各ノードの状況を把握しつつ、負荷分散を図ることが可能である。
【００１６】
また、多階層に構築されたシステムにおいて、複数の根(root)ノードを持つ構成や、下位層のノードが複数の上位層ノードに（ｎ：ｍに）接続される構成であっても、負荷分散を図ることが可能である。
【００１７】
また、空きリソース量を基にした負荷分散を実施するため、異なるハードウエア環境における負荷の均等化が可能となる。
【発明の効果】
【００１８】
開示によれば、多階層構造のシステムにおいて、より均等な負荷分散が可能になる。
【図面の簡単な説明】
【００１９】
【図１】コンピュータシステムの基本的な構成例を示す図である。
【図２】コンピュータシステムを構成するノードの構成例を示す図である。
【図３】ノードが保持する重みや空きリソース量と転送先を登録する重みテーブルの構成例を示す図である。
【図４】ノードが保持する負荷情報を登録する負荷情報管理テーブルの構成例を示す図である。
【図５】ノードが保持するハードウエアスペックの情報を登録する負荷基本情報管理テーブルの構成例を示す図である。
【図６】ノードが保持する分配先ノード情報を登録する分配先ノード管理テーブルの構成例を示す図である。
【図７】ノードが保持する負荷情報の履歴を登録する負荷履歴管理テーブルの構成例を示す図である。
【図８】分配元のノードにおいて実行されるハードウエアスペックの情報取得処理内容の構成例を示すフローチャートである。
【図９】分配元のノードにおいて実行される負荷情報取得処理内容の一例を示すフローチャートである。
【図１０】分配元又は分配先のノードにおいて実行される空きリソース量、及び重みを算出する処理内容の一例を示すフローチャートである。
【図１１】分配元のノードにおいて実行される分配処理内容の一例を示すフローチャートである。
【図１２】コンピュータシステムのノード接続構成の一例を示す図である。
【図１３】コンピュータシステムの構成例を示す図である。
【図１４】コンピュータシステムの構成例を示す図である。
【図１５】コンピュータシステムを構成するノードの構成例を示す図である。
【図１６】ノードが保持する親ノード単位の空きリソース量を登録するグループ空きリソース量管理テーブルの一例を示す図である。
【図１７】分配先ノードにおいて実行される親ノード単位の空きリソース量を登録処理内容の一例を示すフローチャートである。
【図１８】分配元又は分配先のノードにおいて実行される親ノード単位の空きリソース量を算出する処理内容の一例を示すフローチャートである。
【図１９】分配元のノードにおいて実行される親ノード間の分配処理内容の一例を示すフローチャートである。
【図２０】コンピュータシステムの構成例を示す図である。
【図２１】DNSサーバの構成例を示す図である。
【図２２】コンピュータシステムを構成するノードの構成例を示す図である。
【図２３】ノードが保持するDNS情報を登録するDNS情報管理テーブルの構成例を示す図である。
【図２４】DNSサーバが保持するDNSテーブルを登録するDNSテーブルの構成例を示す図である。
【図２５】DNSサーバにおいて実行される重みづけ分配処理内容の一例を示すフローチャートである。
【図２６】親ノードにおいて実行される親ノード間の重みづけ情報をDNSサーバへ送信する処理内容の一例を示すフローチャートである。
【図２７】DNSサーバにおいて実行される重みづけ情報受信処理内容の一例を示すフローチャートである。
【図２８】分配元のノードにおいて実行される空きリソース量、及び重みを算出する処理内容の概要の一例を示すフローチャートである。
【発明を実施するための形態】
【実施例１】
【００２０】
本実施形態のコンピュータシステムの構成は、複数のノードとクライアント端末がネットワークで接続される。
【００２１】
図1は、複数のノードが、ネットワークにより木構造（下位層の一つ以上のノードが一つの上位層のノードに接続する）に相互接続されるコンピュータシステムの構成例を示す。親ノード(a)100は、ネットワーク101を介してクライアント102と接続される。親ノード(a)100は、子ノード(b1)110ａ及び子ノード(b2)110ｂと相互接続される。子ノード(b1)110ａは孫ノード(c1)120ａと孫ノード(c2)120ｂと相互接続される。子ノード(b2)110ｂは孫ノード(c3)120ｃと孫ノード(c4)120ｄと相互接続される。本実施例では、各子ノード110ａ〜110ｂにそれぞれ複数の孫ノード120ａ〜120ｂ、120ｃ〜120ｄが接続される形態を示しているが、いずれかの孫ノード120ａ〜120ｄが存在しない構成や、子ノードと孫ノードが1対1で接続される構成、また孫ノードの下位層にさらにノードが接続される構成であってもよい。
【００２２】
図2は、ノードの構成例を示す図である。本実施例では、親ノード(a)100、子ノード110ａ〜110ｂ、孫ノード120ａ〜120ｄは同一の構成をとるノードの例を示している。ただし、親ノード(a)100、子ノード110ａ〜110ｂ、孫ノード120ａ〜120ｄがそれぞれ異なる処理を実施する構成でもよい。例えば、Web3階層のように、親ノード(a)100がウェブサーバ、子ノード110ａ〜110ｂがアプリケーションサーバ、孫ノード120ａ〜120ｄがデータベースサーバといった構成であってもかまわない。ここでは代表として親ノード(a)100の構成例について述べる。
【００２３】
親ノード(a)100は、1つ以上のCPU201と、1つ以上のネットワークインタフェース(NW I/F)202〜204と、入出力装置205と、メモリ207が内部バス等の通信路206を介して相互に接続されるコンピュータ上に実現される。NW I/F202はネットワーク101を介してクライアント102と接続される。NW I/F203及び204はネットワークを介して子ノード110ａ〜110ｂと接続される。クライアント102と子ノード110ａ〜110ｂが接続されるネットワークが同一であってもよい。メモリ207には、CPU201によって実行され、以下に説明するサーバ機能210、中継機能211、SNMP機能212、重み算出機能213、負荷情報収集機能214を、各コンピュータ上のプロセスとして実現する各プログラムと、重みテーブル221、負荷情報管理テーブル222、負荷基本情報管理テーブル223、負荷履歴管理テーブル224、分配先ノード管理テーブル225が格納される。
【００２４】
各プログラムは、予め各ノード100、110のメモリ207に格納されていても良いし、必要なときに、各ノードが利用可能な媒体を介して、他の装置からメモリ207に導入されてもよい。媒体とは、たとえば、図示しない外部デバイスインタフェースに着脱可能な記憶媒体、または通信媒体（すなわち、NW I/F202〜204に接続する有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号）を指す。  サーバ機能210は、クライアント102から受信した要求の処理を実行する。中継機能211は、クライアント102から受信した処理要求を下位層のノードへ転送する処理を実行する。SNMP機能212は、ノード間で負荷情報を送信する処理を実行する。重み算出機能213は、下位層のノードより取得した負荷情報を基に、下位層のノード間の分配重みを算出する。負荷情報収集機能214は、ノード間で負荷情報の収集処理を実行する。
【００２５】
図3は、各ノードに具備された重みテーブル221の一例を示したものである。各ノードの中継機能211は、重みテーブル221に登録された転送先に対して、重み割合に従った処理要求の分配を実行する。分配方法には一般に様々な方法があり、本実施例ではラウンドロビン方法による分配を想定しているが、その他の方法を用いても良い。
【００２６】
重みテーブル221の転送先欄301には、当該ノードが受信した処理要求を転送するノードの名称が格納される。重み欄302には、転送先ノードの負荷量に応じた重み値が格納される。空きリソース量欄303には、転送先ノードの空きリソース量が格納される。
【００２７】
空きリソース量とは、転送先ノードから収集した負荷情報を基に算出した値である。具体的には、例えば、ノードの空きCPU使用率（1-CPU使用率）とCPUコア数とCPUクロック数の積で示される。この例ではCPUのみを負荷監視対象としているが、CPUだけではなく、ネットワークやディスク、メモリ、データサイズといった監視対象リソースを含めてもかまわない。また、空きリソース量には、転送先ノードを含め、転送先ノードのさらに下位層のノード群の負荷量も含まれる。
【００２８】
例えば、親子孫といった図1のような3階層にわたるノードが構成されている場合、子ノード(b1)110ａは、孫ノード(c1)120ａと孫ノード(c2)120ｂから負荷情報（CPUコア数及びクロック数、CPU使用率）を収集し、収集した負荷情報を用いて、孫ノード(c1)120ａと孫ノード(c2)120ｂの空きリソース量を算出する。子ノード(b1)110ａは、孫ノードの空きリソース量の合計値と、自身の空きリソース量の合計値を子ノード(b1)110ａとして、親ノード(a)100へ送信する。このように空きリソース量を上位ノードへ伝えることにより、親ノード(a)100において、子ノード(b1)110ａと子ノード(b2)110ｂ以下のノードを含む負荷量を測ることが可能となり、子ノードから孫ノードまでを考慮した負荷分散を実施できる。
【００２９】
ここで述べた重みとは、分配先ノード数に応じて割り振った割合である。例えば、1つの親ノードが2つの子ノードへ分配を行う場合、一方の子ノードへ処理要求を転送させる割合が70%で、もう一方の子ノードへ処理要求を転送させる割合が30%であるならば、重みはそれぞれ70、30と表すことができる。
【００３０】
図4は、各ノードに具備された負荷情報管理テーブル222の一例を示したものである。各ノードの負荷情報収集機能214が、管理者の指定する一定時間毎に下位層のノードに対して負荷情報取得要求を実行し、下位ノードから負荷情報を取得し、負荷情報管理テーブル222へ登録する。登録の際、既に登録情報がある場合は新たに取得した負荷情報で上書きする。この負荷情報管理テーブル222に登録されるのは、下位ノードを持たないノード（図1の孫ノード(c1)120ａ〜孫ノード(c4)120ｄに相当）及び自ノードのみである。負荷情報管理テーブル222のノード名欄401には、ノードを識別するノード識別子が格納される。CPU使用率欄402には、当該ノードのCPU使用率が格納される。メモリ使用率欄403には、当該ノードのメモリ使用率が格納される。ディスク使用率欄404には、当該ノードのディスク使用率が格納される。コネクション数欄405には、当該ノードのコネクション数が格納される。
【００３１】
図5は、各ノードに具備される負荷基本情報管理テーブル223の一例を示したものである。各ノードの負荷情報収集機能214が、下位層のノードに対してハードウエアスペック情報取得要求を実行し、下位ノードからハードウエアスペックを取得し、負荷基本情報管理テーブル223へ登録する。負荷基本情報管理テーブル223のノード名欄501には、ノードを識別するノード識別子が格納される。CPUクロック数欄502には、当該ノードのCPUクロック数が格納される。CPUコア数欄503には、当該ノードのCPUコア数が格納される。本実施例では、ハードウエアスペックの一例としてCPUクロック数とCPUコア数を取り上げているが、ネットワーク帯域やCPU種別、ディスクアクセス速度、メモリ量といった値を含めてもよい。
【００３２】
図6は、各ノードに具備される分配先ノード管理テーブル225の一例を示したものである。分配先ノード管理テーブル225には、ノード識別子とアドレスが登録され、それらを結びつけている。分配先ノード管理テーブル225のノード名欄601には、ノードを識別するノード識別子が格納される。アドレス欄602には、当該ノードのアドレスが格納される。
【００３３】
図7は、各ノードに具備される負荷履歴管理テーブル224の一例を示したものである。負荷履歴管理テーブル224には、一定期間、分配先ノード及び自ノードの負荷情報が格納されている。負荷履歴管理テーブル224の取得時間欄701には、負荷情報取得時間が格納される。ノード名欄702には、ノードを識別するノード識別子が格納される。CPU使用率欄703には、当該ノードのCPU使用率が格納される。メモリ使用率欄704には、当該ノードのメモリ使用率が格納される。ディスク使用率欄705には、当該ノードのディスク使用率が格納される。コネクション数欄706には、当該ノードのコネクション数が格納される。
【００３４】
図28は、図１に示すシステム構成が３階層以上の場合の任意の３階層において、第２階層に属するノード（子ノードという）の負荷情報収集機能214、重み算出機能213、SNMP機能212、及び中継機能211が、第３階層に属するノード（孫ノードという）から負荷情報を収集し、孫ノードの負荷及び自ノード（子ノード）の負荷に基づく空きリソース量を算出して、第１階層に属するノード（親ノードという）へ送信し、さらに、当該子ノードが、孫ノードへ、親ノードから送信された処理要求を分配する際の処理フローの概要の一例を示したフローチャートである。
【００３５】
子ノードの負荷情報収集機能214は、孫ノードから負荷情報を収集する（ステップ2801）。
【００３６】
子ノードの重み算出機能213は、例えば上述の方法により、孫ノードの負荷情報も考慮した、自ノードの空きリソース量を算出する（ステップ2802）。
【００３７】
子ノードのSNMP機能212は、親ノードの負荷情報収集機能214から負荷情報取得要求を受けると、ステップ2802で算出した空きリソース量を親ノードへ送信する（ステップ2803）。
【００３８】
親ノードの重み算出機能213は、処理要求を子ノードへ分配するために、子ノードの空きリソース量に基づき、処理要求の分配割合となる重みを算出する（ステップ2804）。
【００３９】
親ノードは、ステップ2804で算出した重みに従い、受信した処理要求（ステップ2805）をいずれかの子ノードに分配する。子ノードの中継機能211は、親ノードが分配した処理要求を受信する（ステップ2806）。
【００４０】
ステップ2806の後は、ステップ2801へ戻り、処理を繰り返す。
【００４１】
なお、処理要求を受信した子ノードは、自身が上記３階層の親ノードとなる場合は、自ノード内の処理を実行した後、同様の処理により、処理要求の更なる分配を行う。
【００４２】
また、ステップ2801〜2804の処理と、ステップ2805の処理とは、独立しているため、並行して行うことが可能である。その場合、親ノードの中継機能211は、ステップ2805を行う時点で算出済みの重みを参照して、分配先の子ノードを決定する。
【００４３】
図28に示したフローチャートの各ステップの詳細については、以降の図8から図11で述べる。
【００４４】
図8は、各ノードの負荷情報収集機能214が下位ノード及び自ノードへハードウエアスペックの問合せ処理の流れの一例を示したフローチャートである。負荷情報収集機能214は、負荷基本情報管理テーブル223に登録されている各列の項目を取得する（ステップ801）。次に、負荷情報収集機能214は、分配先ノード管理テーブル225に登録されているノード宛にステップ801で取得した項目の問合せを行う（ステップ802）。本実施例では、問合せにあたり、分配先のノードへSNMP（Simple Network Management Protocol）を利用してハードウエアスペックを取得する。本実施例では取り上げていないが、例えばSNMPでは取得できないディスクアクセス速度といった値の場合は、管理者が直接負荷基本情報管理テーブル223へ登録することも可能である。
【００４５】
そして、負荷情報収集機能214は、ステップ802の問合せ結果を負荷基本情報管理テーブル223へ格納する（ステップ803）。負荷情報収集機能214は、負荷基本情報管理テーブル223全ての項目に情報が格納されたか確認し、終了する。全ての項目に情報がまだ格納されていない場合は、ステップ801に戻り残りの項目の情報を取得する（ステップ804）。  図9は、各ノードの負荷情報収集機能214が下位ノード及び自ノードへ負荷情報を定期的に問い合せる処理の流れの一例を示したフローチャートである。負荷情報収集機能214は、負荷情報管理テーブル222に登録されている各列の項目を取得する（ステップ901）。次に、負荷情報収集機能214は、分配先ノード管理テーブル225に登録されているノード宛にステップ901で取得した項目について、問合せを行う（ステップ902）。そして、負荷情報収集機能214は、ステップ902の問合せ結果を負荷情報管理テーブル222へ格納する（ステップ903）。負荷情報収集機能214は、負荷情報管理テーブル222全ての項目に情報が格納されたか確認し、ステップ905へ移る。全ての項目に情報がまだ格納されていない場合は、ステップ901に戻り残りの項目の情報を取得する（ステップ904）。負荷情報収集機能214は、管理者の指定する一定期間スリープする（ステップ905）。負荷情報収集機能214は、ステップ905にて一定期間スリープした後に、管理者よりアボート受付けの有無を確認し、受付けならば終了し、未受付けならばステップ901へ移る（ステップ906）。
【００４６】
また、CPU使用率などは、本実施例で想定している機能以外の処理（例えばOS内部処理など）によって瞬間的に使用率が急上昇することもあり得る。このような状況を考慮してCPU使用率を用いるため、負荷履歴管理テーブル224の負荷情報の履歴を参照し、コネクション数に大きな変化がなく、CPU使用率が大きく変化している場合に実施例で示す処理以外によるCPU使用率の上昇として、負荷履歴管理テーブル224の一世代前のCPU利用率を用いる方法も考えられる。
【００４７】
図10は、各ノードの重み算出機能213が空きリソース量を算出する処理の流れの一例を示したフローチャートである。
【００４８】
重み算出機能213は、分配先ノード管理テーブル225に登録されているレコードの有無を確認する。レコードが有る場合はステップ1002へ移り、レコードが無い場合は、処理を終了する（ステップ1001）。
【００４９】
次に、重み算出機能213は、分配先ノード管理テーブル225に登録されているレコードのノード名欄601に登録されている識別子を基に、負荷基本情報管理テーブル223のノード名欄501と負荷情報管理テーブル222のノード名欄401が同一のレコードを検索し、負荷基本情報管理テーブル223と負荷情報管理テーブル222の各項目の情報を取得する（ステップ1002）。
【００５０】
重み算出機能213は、ステップ1002で得た情報を基に空きリソース量を算出する。本実施例では、CPUクロック数、CPUコア数、CPU使用率を用い、上記記載のように空きリソース量を算出する（ステップ1003）。
【００５１】
重み算出機能213は、ステップ1003で算出した空きリソース量を重みテーブル221の当該転送先に一致するレコードの空きリソース量欄303へ登録する（ステップ1004）。
【００５２】
次に重み算出機能213は、分配先ノード管理テーブル225に登録されている全レコードの空きリソース量算出を行ったか確認する。算出完了している場合はステップ1006へ移り、算出が未完の場合はステップ1002へ移る（ステップ1005）。
【００５３】
重み算出機能213は、ステップ1003で算出した空きリソース量を統計的に処理する。具体的には、標準偏差を算出する（ステップ1006）。
【００５４】
そして、重み算出機能213は、管理者が指定する指定値とステップ1006で算出した標準偏差との積を算出する。その積の結果よりも空きリソース量が小さい場合のみ、外れ値として抽出する（ステップ1007）。
【００５５】
重み算出機能213は、ステップ1007で外れ値が抽出されたかどうかの有無を確認する。抽出された場合はステップ1009へ移り、抽出されなかった場合はステップ1013へ移る（ステップ1008）。
【００５６】
重み算出機能213は、ステップ1007で抽出されなかったノードの空きリソース量と、管理者が指定する指定値とステップ1006で算出した標準偏差との積との差分（以降、リソース余裕分と呼ぶ）を、ノード毎に算出する。一方、ステップ1007で外れ値として抽出したノードの空きリソース量と、管理者が指定する指定値とステップ1006で算出した標準偏差との積との差分（以降、リソース溢れ分と呼ぶ）を、ノード毎に算出する（ステップ1009）。
【００５７】
重み算出機能213は、ステップ1007で抽出されたノードのリソース溢れ分を、ステップ1007で抽出されなかったノード毎のリソース余裕分に応じた割合を算出する（ステップ1010）。
【００５８】
次に、重み算出機能213は、ステップ1009で算出した割合と、重みテーブル221の重み欄302に登録されている値との積を算出し、重み欄302に算出結果を上書きする（ステップ1011）。
【００５９】
重み算出機能213は、重みテーブル221の全レコードについて重みを算出して更新を行ったか確認する。全レコードの更新が完了した場合はステップ1013へ移り、全レコードの更新が未完ならばステップ1009へ移る（ステップ1012）。
【００６０】
次に、重み算出機能213は、管理者の指定する一定期間スリープする（ステップ1013）。
【００６１】
重み算出機能213は、ステップ1013にて一定期間スリープした後に、管理者よりアボート受付けの有無を確認し、受付けならば終了し、未受付けならばステップ1002へ移る（ステップ1014）。
【００６２】
図10に示したフローチャートにおいて、ステップ1003ではCPU利用率を用いた空きリソース量の算出例を示している。前述のように、CPU以外の負荷情報を用いて空きリソース量を算出した場合も同様のフローで制御が可能である。
【００６３】
また、図4の負荷情報管理テーブル222のコネクション数欄405に登録されるコネクション数（滞留数）を利用した制御も可能である。例えば、各ノードのコネクション数と、ハードウエアスペック、及び管理者指定による1コネクション当りのリソース使用量を利用して、どれだけリソースに対して余裕があるのかという空きリソース量を算出可能である。これは、例えばCPUクロック数とCPUコア数の積に対して、1コネクション当りのリソース使用量とコネクション数の積がどれだけの空き割合を占めているといった値が、空きリソース量として挙げられる。
【００６４】
図11は、各ノードに具備される中継機能211が重みテーブル221の登録内容に従って、クライアント102又は上位ノードからの処理要求の転送先を決定する処理の流れの一例を示したフローチャートである。中継機能211は、クライアント102又は上位ノードからの処理要求を受信する（ステップ1101）。そして、サーバ機能210は、自ノード内のサーバ処理を実施する（ステップ1102）。次に、中継機能211は、重みテーブル221の重み欄302に登録されている重みの割合に沿って、転送先を決定する。例えば、ラウンドロビン方法を利用して転送先を決める場合、重みテーブル221の重み欄302に登録されているレコードの順に、重みの割合で転送先を決定する（ステップ1103）。そして、中継機能211は、ステップ1103で決定した転送先へ処理要求を転送する（ステップ1104）。
【００６５】
本実施例では、以上の処理フローを、ノードに具備されるサーバ機能210、中継機能211、SNMP機能212、重み算出機能213、負荷情報収集機能214が実行することによって、図1に示されるコンピュータシステムの構成でノード(c1)120ａ〜(c4)120ｄの負荷状況まで考えた分配をノード(a)100で実現することが可能である。なお、空きリソース量という情報を基に分配するため、負荷の均等化を図ることが可能である。
【００６６】
本実施例ではノードの負荷余裕分として空きリソース量を利用する例を述べたが、実際にCPU等の使用量を用いる考え方であっても、同様に負荷の均等化を図ることが可能である。
【００６７】
また、図12は、図1に示したコンピュータシステムの構成を変更し、ノード(a1)100ａ〜ノード(a3)100ｃの階層とノード(b1)120ａ〜ノード(b4)120ｄの階層の間にノード(LB1)110ａを配し、ノード(b1)120ａ〜ノード(b4)120ｄの階層とノード(c1)140ａ〜ノード(c4)140ｄの階層間にノード(LB2)130ａ及びノード(LB3)130ｂを配した構成例である。このように階層が増えた場合でも実施例1に示した方法により下位ノードの負荷を上位ノードへ伝えていくことが可能であり、各階層のノード状況を把握した上で負荷分散させることが可能である。
【００６８】
ただし、図12の構成は、図1に示したシステム構成とは、上位層から下位層へ放射状に構築される木構造ではない点が異なる。実施例1に示した方法に加え、例えばノード(LB1)110ａにおいて、負荷情報管理テーブル222のコネクション数欄405に登録される情報の粒度を転送元単位に細かくし、その割合に従って空きリソース量を配分させることにより、各階層の各ノードの状況に基づく負荷分散が可能になる。
【００６９】
また、図13は、図1に示したコンピュータシステムの構成を、下位層のノード(c1)140ａ〜ノード(c4)140ｄの各々が上位層のノード(b1)120ａ〜ノード(b2)120ｂの複数に接続するよう変更した接続形態例である。図13に示す構成であっても、同様に負荷分散が可能である。
【００７０】
例えば、ノード(b1)120ａ〜ノード(b2)120ｂの負荷情報収集機能214が収集する負荷情報として、ノード(c1)140ａ〜ノード(c4)140ｄのSNMP機能212がCPU使用率等を応答するにあたり、ノード(b1)120ａ〜ノード(b2)120ｂから処理要求を受け付けた割合でCPU使用率を割った値を、CPU使用率として応答することにより、各階層の各ノードの状況に基づく負荷分散が可能になる。
【００７１】
なお、あるノードに障害が発生した場合は、障害発生ノードから負荷情報を収集することができなくなるが、負荷情報が収集できないノードの空きリソース量をゼロとすることにより、そのノードへ処理要求が転送されることなく、サービスの継続が可能である。ノードを減設させる場合も同様の方法で対応できる。一方、ノードを増設する場合については、増設ノードの親ノードに対して、分配先ノード管理テーブル225等へのレコード追加を実行することにより対応可能である。このようにスケールアウトやスケールダウン、ノード障害発生といった状況に対して容易に対応可能であり、かつサービス無停止で構成変更を実現することが可能である。
【００７２】
本実施例で示したコンピュータシステムの構成では触れていないが、一般に障害対策としてノードの冗長化が行われる。例えば親ノードの冗長化が行われている場合、子ノードは冗長状態にある2つ以上の親ノードへ同じ情報を送信することで、仮に系切り替え等が発生しても本実施例の負荷分散方法の適用が可能である。
【実施例２】
【００７３】
実施例1では、最上位ノード（根(root)ノード）が一つの構成を対象としていた。実施例2では、複数の根ノードを含む接続構成を対象とする負荷分散方法について説明する。以降の説明では、実施例1との相違点を中心に説明する。
【００７４】
図14は、コンピュータシステムの構成例を示した図である。根ノードとなるノード(a1)100ａとノード(a2)100ｂがネットワーク101を介してクライアント102と接続される。ノード(a1)100ａとノード(a2)100ｂよりも下位層のノードの接続形態は、実施例1の図1に示した構成と同様である。根ノードは３つ以上あってもよい。
【００７５】
図15は、図2に示したノードの構成例に、新たにグループ空きリソース量管理テーブル231を追加した根ノードの構成例を示す図である。グループ空きリソース量管理テーブル231は、根ノード単位の空きリソース量を管理するテーブルである。
【００７６】
図16は、各根ノードに具備されるグループ空きリソース量管理テーブル231の一例を示したものである。グループ空きリソース量管理テーブル231の空きリソース量欄1602には、根ノード以下全体の空きリソース量が格納される。根ノードアドレス欄1603には、自ノードと他の根ノードのアドレス情報が格納される。重み欄1604には、各根ノードの負荷量に応じた重み値が格納される。
【００７７】
実施例2では、実施例1の図28に示したフローチャートに加え、各根ノードが、図16に示したグループ空きリソース量管理テーブル231を参照し、複数の根ノード以下の負荷に応じて処理要求の転送先を決定する。根ノード以下の各ノードは図28ステップ2804までと同様の処理を実行する。そして根ノードは、図17、図18に示すフローチャートを実行し、グループ間の空きリソース量を取得する。根ノードは、クライアント102から処理要求を受信した後、図19のステップ1902から1911を実行し、複数の根ノード間で処理要求の転送先を決定する。
【００７８】
図17は、負荷情報収集機能214がグループ空きリソース量管理テーブル231へ情報を登録する処理の流れの一例を示したフローチャートである。この処理は、最も上位層に位置するノードであり、空きリソース量の問合せを受けることがない根ノードにおいて実施される。
【００７９】
負荷情報収集機能214は、自ノードに該当するレコードに対して、空きリソース量欄1602へ自ノード（根ノード）の空きリソース量を登録し、根ノードアドレス欄1603へ自ノードのアドレス情報を登録する（ステップ1701）。負荷情報収集機能214は、グループ空きリソース量管理テーブル231の他ノードに該当するレコードの根ノードアドレス欄1603に登録されているアドレス情報を基にして、他根ノードへ空きリソース量の問合せ及び自ノードの空きリソース量の送信を行う（ステップ1702）。
【００８０】
負荷情報収集機能214は、グループ空きリソース量管理テーブル231の全てのレコードが更新されたことを確認する。全レコードが更新された場合はステップ1704へ移り、そうでない場合はステップ1702へ移る（ステップ1703）。次に、負荷情報収集機能214は、管理者の指定する一定期間スリープする（ステップ1704）。そして、負荷情報収集機能214は、ステップ1704にて一定期間スリープした後に、管理者よりアボート受付けの有無を確認し、受付けならば終了し、未受付けならばステップ1701へ移る（ステップ1705）。
【００８１】
図18は、重み算出機能213がグループ空きリソース量管理テーブル231の空きリソース量を基に、根ノード間の重みを算出する処理の流れの一例を示したフローチャートである。まず重み算出機能213が、グループ空きリソース量管理テーブル231に登録されたレコードとして、自ノードと他根ノードを含む複数のレコードが存在するか確認する。存在する場合、ステップ1802へ移り、存在しない場合は終了する（ステップ1801）。次のステップ1802〜ステップ1806に関しては、図10のステップ1006〜1010と処理内容が同様であり、説明は割愛する。
【００８２】
ステップ1807以降について続いて説明する。重み算出機能213は、ステップ1806において算出した割合と、グループ空きリソース量管理テーブル231の重み欄1604に登録されている値との積を算出し、重み欄1604に算出結果を上書きする（ステップ1807）。次に、重み算出機能213は、グループ空きリソース量管理テーブル231の全レコードについて重みを算出して更新を行ったか確認する。全レコードの更新が完了した場合はステップ1809へ移り、全レコードの更新が未完ならばステップ1805へ移る（ステップ1808）。そして重み算出機能213は、管理者の指定する一定期間スリープする（ステップ1809）。重み算出機能213は、ステップ1809にて一定期間スリープした後に、管理者よりアボート受付けの有無を確認し、受付けならば終了し、未受付けならばステップ1802へ移る（ステップ1810）。
【００８３】
図19は、中継機能211がグループ空きリソース量管理テーブル231の重み欄1604の登録内容に従って、クライアント102からの処理要求の転送先を決定する処理の流れの一例を示したフローチャートである。
【００８４】
例えばクライアント102毎にデフォルトゲートウェイの指定として中継ノード（根ノード）が指定されている場合を考える。いずれかの根ノードの中継機能211は、クライアント102から処理要求を受信する（ステップ1901）。そして、サーバ機能210は、自ノード内のサーバ処理を実施する（ステップ1902）。次に、中継機能211は、グループ空きリソース量管理テーブル231の重み欄1604に登録されている重みの割合に沿って、転送先根ノードを決定する（ステップ1903）。ここのロジックは図11のステップ1103と同様である。
【００８５】
そして、ステップ1904において、転送先が自ノードであるか否かを確認する。転送先が自ノードである場合はステップ1910へ移り、自ノード以外の根ノードであればステップ1905へ移る（ステップ1904）。転送先が自ノード以外の根ノードである場合、中継機能211は、ステップ1903で決定した転送先根ノードへ、ネットワーク101を使って、処理要求を転送する（ステップ1905）。転送先が自ノードである場合、中継機能211は、重みテーブル221の重み欄302に登録されている重みの割合に沿って、転送先を決定する（ステップ1910）。このステップ1910の処理は図11のステップ1103と同じである。そして、中継機能211は、ステップ1910で決定した転送先となる下位層のノードへ処理要求を転送する（ステップ1911）。
【００８６】
本実施例では、以上の処理フローを、ノードに具備されるサーバ機能210、中継機能211、重み算出機能213、負荷情報収集機能214が実行することによって、図14に示されるコンピュータシステムの構成でノード(c1)120ａ〜(c8)120ｈの負荷状況まで考えた負荷分散を根ノード(a1)100ａ及びノード(a2)100ｂで実現することが可能である。本実施例では、最上位層の根ノード間において、根ノードの空きリソース量のみ同期するため、最小限の情報量の同期で負荷分散を実現可能である。
【００８７】
また、新たに根ノードが増設される場合は、グループ空きリソース量管理テーブル231のみを管理者が更新することによって、新たな分配先としてシステムが認識可能であるため、容易にスケールアウト又はスケールダウンが可能である。
【実施例３】
【００８８】
実施例3では、クライアント102からの処理要求を根ノードへ分配する場合に、DNSを利用した負荷分散方法を説明する。以降の説明では、実施例1及び実施例2との相違点を中心に説明する。
【００８９】
図20は、コンピュータシステムの構成例を示した図である。実施例1の図1に示した構成に加え、DNSサーバ103がネットワーク101に接続されている構成である。クライアント102は、名前解決処理のため、DNSサーバ103へ問合せを行う。DNSサーバ103は、問合せに対して適切なアクセス先を返答することによって、クライアント102は処理要求を適切なノードへ送信できる。
【００９０】
図21は、DNSサーバ103の構成例を示す図である。DNSサーバ103は、1つ以上のCPU2101と、1つ以上のネットワークインタフェース(NW I/F)2102と、入出力装置2103と、メモリ2105が内部バス等の通信路2104を介して相互に接続されるコンピュータ上に実現される。NW I/F2102はネットワーク101を介してクライアント102と根ノード(a1)100ａや根ノード(a2)100ｂと接続される。メモリ2105には、CPU2101によって実行されるDNS機能2110と、DNSテーブル2111が格納される。DNS機能2110は、クライアント102から名前解決処理要求を受信すると、DNSテーブル2111の内容に沿って適切なアクセス先をクライアント102へ返答する。
【００９１】
図22は、図15に示したノードの構成例に、新たにDNS情報管理テーブル241を追加した構成例を示す図である。DNS情報管理テーブル241は、DNSサーバ103のアドレス情報を管理するテーブルである。
【００９２】
図23は、各ノードに具備されるDNS情報管理テーブル241の一例を示したものである。DNS情報管理テーブル241は、根ノード（直接クライアントから処理要求を受けるノード）が備える。DNS情報管理テーブル241のノード名欄2301には、DNSサーバ103の識別子が登録される。アドレス欄2302には、DNSサーバ103のアドレス情報が登録される。
【００９３】
図24は、DNSサーバ103に具備されるDNSテーブル2111の一例を示したものである。DNSテーブル2111は、DNSサーバ103のDNS機能2110がクライアント102から名前解決処理要求を受信した時に適切なアクセス先を決定するために参照される。DNSテーブル2111のホスト名欄2401には、クライアントから問合せを受けるドメインのホスト名が登録される。種別欄2402には、当該レコードの種別が登録される。アドレス欄2403には、当該ドメインに対するアクセス先アドレス情報が登録される。重み欄2404には、当該ドメインに対するアクセス先の重み情報が登録される。
【００９４】
図26は、親ノードに具備される重み算出機能213がDNSサーバ103へ重み情報を送信する処理の流れの一例を示したフローチャートである。重み算出213は、DNS情報管理テーブル241に登録レコードが存在するか確認する。登録レコードが存在する場合はステップ2602へ移り、存在しない場合は終了する（ステップ2601）。ステップ2601において、DNS情報管理テーブル241に登録レコードが存在する場合、重み算出213は、グループ空きリソース量管理テーブル231の根ノードアドレス欄1603と重み欄1604に登録されている情報を、DNS情報管理テーブル241に登録されているレコードのアドレス欄登録アドレスへ送信する（ステップ2602）。そして、重み算出213は、管理者の指定する一定期間スリープする（ステップ2603）。重み算出213は、ステップ2603にて一定期間スリープした後に、管理者よりアボート受付けの有無を確認し、受付けならば終了し、未受付けならばステップ2602へ移る（ステップ2604）。
【００９５】
図27は、DNSサーバ103に具備されるDNS機能2110が根ノードから重み情報を受信する処理の流れの一例を示したフローチャートである。DNS機能2110は、根ノードからアドレス情報と重み情報を受信する（ステップ2701）。次に、DNS機能2110は、ステップ2701で受信したアドレス情報がDNSテーブル2111のアドレス欄2403と一致するレコードを検索し、そのレコードの重み欄2404にステップ2701で受信した重み情報を上書きする（ステップ2702）。
【００９６】
図25は、DNSサーバ103に具備されるDNS機能2110がDNSテーブル2111の登録内容に従って、クライアント102からの名前解決処理の応答する処理の流れの一例を示したフローチャートである。
【００９７】
DNS機能2110は、クライアント102から名前解決処理要求を受信する（ステップ2501）。DNS機能2110は、受信した名前解決処理要求のホスト名とDNSテーブル2111のホスト名欄2401が一致するレコードを抽出する。複数のレコードが抽出された場合、重み欄2404の情報に沿ってレコードを選択する。ここでの選択方法は、上述したノードでの分配先決定方法と同様である。ただし、同じ方法を用いる必要はなく、DNSサーバ103独自の重みに応じた選択方法を採用してもかまわない（ステップ2502）。次に、DNS機能2110は、クライアント102に対してステップ2502で決定したレコードのアドレス欄2403に登録されるアドレス情報を返信する（ステップ2503）。
【００９８】
本実施例では、クライアント102がDNSサーバ103へ名前解決処理要求への応答を行う際、根ノードから得た重みを基に応答するアドレスを決定することによって、実施例1で述べた下位層のノードまでを考慮して負荷分散を行うことが可能となる。また、優先DNSサーバと代替DNSサーバのように複数のDNSサーバが存在する場合、グループ空きリソース量管理テーブル231に登録されることになるため、それぞれのDNSサーバへ重み情報が伝わる。クライアントがどちらのDNSサーバに名前解決処理の問合せを行ったとしても、下位層まで考慮した負荷分散が可能である。
【符号の説明】
【００９９】
100：ノード、102：クライアント、103：DNSサーバ、221：重みテーブル、231：グループ空きリソース量管理テーブル、2111：DNSテーブル
【図１】
2014035717.tif 000003
【図２】
2014035717.tif 000004
【図３】
2014035717.tif 000005
【図４】
2014035717.tif 000006
【図５】
2014035717.tif 000007
【図６】
2014035717.tif 000008
【図７】
2014035717.tif 000009
【図８】
2014035717.tif 000010
【図９】
2014035717.tif 000011
【図１０】
2014035717.tif 000012
【図１１】
2014035717.tif 000013
【図１２】
2014035717.tif 000014
【図１３】
2014035717.tif 000015
【図１４】
2014035717.tif 000016
【図１５】
2014035717.tif 000017
【図１６】
2014035717.tif 000018
【図１７】
2014035717.tif 000019
【図１８】
2014035717.tif 000020
【図１９】
2014035717.tif 000021
【図２０】
2014035717.tif 000022
【図２１】
2014035717.tif 000023
【図２２】
2014035717.tif 000024
【図２３】
2014035717.tif 000025
【図２４】
2014035717.tif 000026
【図２５】
2014035717.tif 000027
【図２６】
2014035717.tif 000028
【図２７】
2014035717.tif 000029
【図２８】
2014035717.tif 000030