JP5914245B2 - 多階層の各ノードを考慮した負荷分散方法 - Google Patents

多階層の各ノードを考慮した負荷分散方法 Download PDF

Info

Publication number
JP5914245B2
JP5914245B2 JP2012177712A JP2012177712A JP5914245B2 JP 5914245 B2 JP5914245 B2 JP 5914245B2 JP 2012177712 A JP2012177712 A JP 2012177712A JP 2012177712 A JP2012177712 A JP 2012177712A JP 5914245 B2 JP5914245 B2 JP 5914245B2
Authority
JP
Japan
Prior art keywords
node
nodes
function
resource amount
root
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
JP2012177712A
Other languages
English (en)
Other versions
JP2014035717A (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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2012177712A priority Critical patent/JP5914245B2/ja
Priority to PCT/JP2013/071210 priority patent/WO2014024863A1/ja
Priority to US14/419,769 priority patent/US20150215394A1/en
Publication of JP2014035717A publication Critical patent/JP2014035717A/ja
Application granted granted Critical
Publication of JP5914245B2 publication Critical patent/JP5914245B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/044—Network management architectures or arrangements comprising hierarchical management structures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer And Data Communications (AREA)

Description

開示される主題は、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テーブル

Claims (14)

  1. 互いに独立する複数のノードが、各階層に一つ以上、かつ、ｍ階層（ｍは３以上、ｍ＝１が最上位）に接続され、最上位の根ノードが受信した処理要求を、いずれかの下位層ノードが処理するネットワークシステムにおける負荷分散方法であって、
    任意の３階層（ｎ〜ｎ＋２階層、１＜＝ｎ、ｎ＋２＜＝ｍ）において、
    第ｎ＋１階層の一つのノードは、
    第ｎ＋２階層の一つ以上のノードからそれぞれの負荷情報を取得し、
    取得した前記負荷情報と自ノードの負荷情報とに基づき、自ノードと、下位層の一つ以上の前記ノードと、の合計空きリソース量を算出し、
    算出した前記合計空きリソース量を、第ｎ階層のノードへ送信し、
    第ｎ階層のノードは、
    第ｎ＋１階層の一つ以上の前記ノードの各々から取得した前記合計空きリソース量に基づき、第ｎ＋１階層の前記ノード各々の重み値を算出し、
    算出した前記重み値に基づき、受信した前記処理要求を、第ｎ＋１階層のいずれかの前記ノードへ分配する
    ことを特徴とする負荷分散方法。
  2. 請求項１記載の負荷分散方法において、
    前記ネットワークシステムが前記根ノードを複数備える場合、
    各々の前記根ノードが、
    自根ノードに接続される第２階層の前記ノードから前記合計空きリソース量を取得し、
    第２階層の前記ノードの各々から取得した前記合計空きリソース量に基づき、前記重み値を算出し、
    他の根ノードへ、算出した前記重み値を送信し、前記他の根ノードから、前記他の根ノードが算出した前記重み値を取得し、
    自他の根ノードが算出した前記重み値に基づき、受信した前記処理要求を、自ノードを含むいずれかの根ノードへ分配する
    ことを特徴とする負荷分散方法。
  3. 請求項１記載の負荷分散方法において、
    前記ネットワークシステムが、複数の前記根ノードとＤＮＳサーバとを備える場合、
    各々の前記根ノードが、
    自根ノードに接続される第２階層の前記ノードから前記合計空きリソース量を取得し、
    第２階層の前記ノードの各々から取得した前記合計空きリソース量に基づき、前記重み値を算出し、
    算出した前記重み値と当該根ノードのアドレス情報とを、前記ＤＮＳサーバへ送信する
    ことを特徴とする負荷分散方法。
  4. 請求項１から３のいずれか一に記載の負荷分散方法において、
    前記第ｎ階層の前記ノードは、
    第ｎ＋１階層の前記ノードの各々から取得した前記合計空きリソース量の標準偏差を算出し、
    前記標準偏差と、あらかじめ定められた指定値とに基づき、前記重み値を算出する
    ことを特徴とする負荷分散方法。
  5. 請求項１から４のいずれか一に記載の負荷分散方法において、
    前記合計空きリソース量は、ＣＰＵ利用率、または、コネクション数に基づいて算出する
    ことを特徴とする負荷分散方法。
  6. 互いに独立する複数のノードが、各階層に一つ以上、かつ、ｍ階層（ｍは３以上、ｍ＝１が最上位）に接続され、最上位の根ノードが受信した処理要求を、いずれかの下位層ノードが処理するネットワークシステムであって、
    任意の３階層（ｎ〜ｎ＋２階層、１＜＝ｎ、ｎ＋２＜＝ｍ）において、
    第ｎ＋１階層の一つのノードは、
    第ｎ＋２階層の一つ以上のノードからそれぞれの負荷情報を取得する機能と、
    取得した前記負荷情報と自ノードの負荷情報とに基づき、自ノードと、下位層の一つ以上の前記ノードと、の合計空きリソース量を算出する機能と、
    算出した前記合計空きリソース量を、第ｎ階層のノードへ送信する機能と、を備え、
    第ｎ階層のノードは、
    第ｎ＋１階層の一つ以上の前記ノードの各々から取得した前記合計空きリソース量に基づき、第ｎ＋１階層の前記ノード各々の重み値を算出する機能と、
    算出した前記重み値に基づき、受信した前記処理要求を、第ｎ＋１階層のいずれかの前記ノードへ分配する機能と、を備える
    ことを特徴とするネットワークシステム。
  7. 請求項６記載のネットワークシステムにおいて、
    前記ネットワークシステムが前記根ノードを複数備える場合、
    各々の前記根ノードが、
    自根ノードに接続される第２階層の前記ノードから前記合計空きリソース量を取得する機能と、
    第２階層の前記ノードの各々から取得した前記合計空きリソース量に基づき、前記重み値を算出する機能と、
    他の根ノードへ、算出した前記重み値を送信する機能と、前記他の根ノードから、前記他の根ノードが算出した前記重み値を取得する機能と、
    自他の根ノードが算出した前記重み値に基づき、受信した前記処理要求を、自ノードを含むいずれかの根ノードへ分配する機能と、を備える
    ことを特徴とするネットワークシステム。
  8. 請求項７記載のネットワークシステムにおいて、
    前記ネットワークシステムが、複数の前記根ノードとＤＮＳサーバとを備える場合、
    各々の前記根ノードが、
    自根ノードに接続される第２階層の前記ノードから前記合計空きリソース量を取得する機能と、
    第２階層の前記ノードの各々から取得した前記合計空きリソース量に基づき、前記重み値を算出する機能と、
    算出した前記重み値と当該根ノードのアドレス情報とを、前記ＤＮＳサーバへ送信する機能と、を備える
    ことを特徴とするネットワークシステム。
  9. 請求項６から８のいずれか一に記載のネットワークシステムにおいて、
    前記第ｎ階層の前記ノードは、
    第ｎ＋１階層の前記ノードの各々から取得した前記合計空きリソース量の標準偏差を算出する機能と、
    前記標準偏差と、あらかじめ定められた指定値とに基づき、前記重み値を算出する機能と、を備える
    ことを特徴とするネットワークシステム。
  10. 請求項６から９のいずれか一に記載のネットワークシステムにおいて、
    前記合計空きリソース量は、ＣＰＵ利用率、または、コネクション数に基づいて算出する機能と、を備える
    ことを特徴とするネットワークシステム。
  11. 互いに独立する複数のノードが、各階層に一つ以上、かつ、ｍ階層（ｍは３以上、ｍ＝１が最上位）に接続され、最上位の根ノードが受信した処理要求を、いずれかの下位層ノードが処理するネットワークシステムにおけるノードであって、
    下位層の一つ以上のノードからそれぞれの負荷情報を取得する機能と、
    取得した前記負荷情報と自ノードの負荷情報とに基づき、自ノードと、下位層の一つ以上の前記ノードと、の合計空きリソース量を算出する機能と、
    算出した前記合計空きリソース量を、上位層のノードへ送信する機能と、を備える
    ことを特徴とするノード。
  12. 互いに独立する複数のノードが、各階層に一つ以上、かつ、ｍ階層（ｍは３以上、ｍ＝１が最上位）に接続され、最上位の根ノードが受信した処理要求を、いずれかの下位層ノードが処理するネットワークシステムにおいて、前記ネットワークシステムが前記根ノードを複数備える場合の根ノードであって、
    自根ノードに接続される第２階層のノードから、当該第２階層の前記ノードと、下位層の一つ以上の前記ノードと、の合計空きリソース量を取得する機能と、
    第２階層の前記ノードの各々から取得した前記合計空きリソース量に基づき、前記重み値を算出する機能と、
    他の根ノードへ、算出した前記重み値を送信する機能と、
    前記他の根ノードから、当該他の根ノードが算出した前記重み値を取得する機能と、
    自他の根ノードが算出した前記重み値に基づき、受信した前記処理要求を、自ノードを含むいずれかの根ノードへ分配する機能と、を備える
    ことを特徴とする根ノード。
  13. 互いに独立する複数のノードが、各階層に一つ以上、かつ、ｍ階層（ｍは３以上、ｍ＝１が最上位）に接続され、最上位の根ノードが受信した処理要求を、いずれかの下位層ノードが処理するネットワークシステムにおいて、前記ネットワークシステムが、複数の前記根ノードとＤＮＳサーバとを備える場合の根ノードであって、
    自根ノードに接続される第２階層のノードから、当該第２階層の前記ノードと、下位層の一つ以上の前記ノードと、の合計空きリソース量を取得する機能と、
    第２階層の前記ノードの各々から取得した前記合計空きリソース量に基づき、前記重み値を算出する機能と、
    算出した前記重み値と当該根ノードのアドレス情報とを、前記ＤＮＳサーバへ送信する機能と、を備える
    ことを特徴とする根ノード。
  14. 請求項１２または１３に記載の根ノードにおいて、
    第２階層の前記ノードの各々から取得した前記合計空きリソース量の標準偏差を算出する機能と、
    前記標準偏差と、あらかじめ定められた指定値とに基づき、前記重み値を算出する機能と、を備える
    ことを特徴とする根ノード。
JP2012177712A 2012-08-10 2012-08-10 多階層の各ノードを考慮した負荷分散方法 Active JP5914245B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2012177712A JP5914245B2 (ja) 2012-08-10 2012-08-10 多階層の各ノードを考慮した負荷分散方法
PCT/JP2013/071210 WO2014024863A1 (ja) 2012-08-10 2013-08-06 多階層の各ノードを考慮した負荷分散方法
US14/419,769 US20150215394A1 (en) 2012-08-10 2013-08-06 Load distribution method taking into account each node in multi-level hierarchy

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012177712A JP5914245B2 (ja) 2012-08-10 2012-08-10 多階層の各ノードを考慮した負荷分散方法

Publications (2)

Publication Number Publication Date
JP2014035717A JP2014035717A (ja) 2014-02-24
JP5914245B2 true JP5914245B2 (ja) 2016-05-11

Family

ID=50068087

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012177712A Active JP5914245B2 (ja) 2012-08-10 2012-08-10 多階層の各ノードを考慮した負荷分散方法

Country Status (3)

Country Link
US (1) US20150215394A1 (ja)
JP (1) JP5914245B2 (ja)
WO (1) WO2014024863A1 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5747389B2 (ja) * 2012-08-31 2015-07-15 日本電信電話株式会社 計算機資源割当装置及び方法及びプログラム
JP6256594B2 (ja) * 2014-03-28 2018-01-10 富士通株式会社 プログラム、管理方法およびコンピュータ
JP6693764B2 (ja) * 2016-02-15 2020-05-13 エヌ・ティ・ティ・コミュニケーションズ株式会社 処理装置、分散処理システム及び分散処理方法
JP6709689B2 (ja) 2016-06-16 2020-06-17 株式会社日立製作所 計算機システム及び計算機システムの制御方法
US10193823B2 (en) * 2016-09-12 2019-01-29 Microsoft Technology Licensing, Llc Rich resource management incorporating usage statistics for fairness
JP6769218B2 (ja) 2016-09-30 2020-10-14 横河電機株式会社 アプリケーション開発環境提供システム、アプリケーション開発環境提供方法、アプリケーション開発環境提供プログラム、および情報処理装置
US11133987B2 (en) * 2018-10-24 2021-09-28 Cox Communications, Inc. Systems and methods for network configuration management
CN113195331B (zh) * 2018-12-19 2024-02-06 祖克斯有限公司 使用延迟确定和cpu使用率确定的安全系统操作
CN110688204B (zh) * 2019-08-08 2022-08-26 平安科技（深圳）有限公司 分布式计算系统任务分配方法及相关设备
US11979458B2 (en) * 2020-03-20 2024-05-07 Verizon Patent And Licensing Inc. Systems and methods for providing discovery and hierarchical management of distributed multi-access edge computing
CN111522998B (zh) * 2020-04-15 2023-09-26 支付宝(杭州)信息技术有限公司 一种图模型的生成方法、装置及设备
CN115328666B (zh) * 2022-10-14 2023-07-14 浪潮电子信息产业股份有限公司 设备调度方法、系统、电子设备及计算机可读存储介质
CN116095083B (zh) * 2023-01-16 2023-12-26 之江实验室 一种计算方法、系统、装置、存储介质及电子设备
CN117434990B (zh) * 2023-12-20 2024-03-19 成都易联易通科技有限责任公司 粮仓的环境控制方法和系统

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10283330A (ja) * 1997-04-04 1998-10-23 Hitachi Ltd 並列計算機の負荷分散制御方法
US6067545A (en) * 1997-08-01 2000-05-23 Hewlett-Packard Company Resource rebalancing in networked computer systems
JP3645135B2 (ja) * 1999-09-30 2005-05-11 三菱電機株式会社 並列多目標追尾装置
EP1107108A1 (en) * 1999-12-09 2001-06-13 Hewlett-Packard Company, A Delaware Corporation System and method for managing the configuration of hierarchically networked data processing devices
US6728266B1 (en) * 1999-12-23 2004-04-27 Nortel Networks Limited Pricing mechanism for resource control in a communications network
JP2001306511A (ja) * 2000-04-25 2001-11-02 Pfu Ltd マシン情報の収集方法およびマシン情報の収集装置ならびにその記録媒体
JP2002014941A (ja) * 2000-06-28 2002-01-18 Hitachi Ltd 多階層分散処理装置
US6973479B2 (en) * 2002-05-01 2005-12-06 Thales Avionics, Inc. Method and system for configuration and download in a restricted architecture network
US6940832B2 (en) * 2003-01-17 2005-09-06 The Research Foundation Of The City University Of New York Routing method for mobile infrastructureless network
US7853948B2 (en) * 2005-10-24 2010-12-14 International Business Machines Corporation Method and apparatus for scheduling grid jobs
WO2007119329A1 (ja) * 2006-03-14 2007-10-25 Nec Corporation 階層化システム及びその管理方法と、プログラム
US7680907B2 (en) * 2006-07-21 2010-03-16 Barclays Capital Inc. Method and system for identifying and conducting inventory of computer assets on a network
US8214488B2 (en) * 2006-11-06 2012-07-03 Nec Corporation Resource information providing system, method, resource information providing apparatus, and program
US7590149B1 (en) * 2006-11-10 2009-09-15 Juniper Networks, Inc. Load balancing with unequal routing metrics in a meshed overlay network
US7693876B2 (en) * 2007-01-24 2010-04-06 Netapp, Inc. Monitoring usage rate patterns in storage resources
US20080225714A1 (en) * 2007-03-12 2008-09-18 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic load balancing
JP5246157B2 (ja) * 2007-04-04 2013-07-24 富士通株式会社 負荷分散システム
JP5178218B2 (ja) * 2008-01-31 2013-04-10 三菱電機株式会社 機能提供装置
US8271652B2 (en) * 2008-07-24 2012-09-18 Netapp, Inc. Load-derived probability-based domain name service in a network storage cluster
JP2011035753A (ja) * 2009-08-04 2011-02-17 Yokogawa Electric Corp ネットワーク管理システム
JP5471166B2 (ja) * 2009-08-26 2014-04-16 日本電気株式会社 管理システム、管理装置、ネットワーク装置、管理方法およびプログラム
JP2011134152A (ja) * 2009-12-25 2011-07-07 Hitachi Ltd 情報処理装置及びその制御方法
JP5531819B2 (ja) * 2010-06-28 2014-06-25 株式会社リコー 管理装置，ライセンス管理サーバ，電子機器，電子機器管理システム，管理方法，プログラム，および記録媒体

Also Published As

Publication number Publication date
JP2014035717A (ja) 2014-02-24
US20150215394A1 (en) 2015-07-30
WO2014024863A1 (ja) 2014-02-13

Similar Documents

Publication Publication Date Title
JP5914245B2 (ja) 多階層の各ノードを考慮した負荷分散方法
Sajjad et al. Spanedge: Towards unifying stream processing over central and near-the-edge data centers
Verma et al. A survey on network methodologies for real-time analytics of massive IoT data and open research issues
Krishnamurthy et al. Pratyaastha: an efficient elastic distributed sdn control plane
Rostanski et al. Evaluation of highly available and fault-tolerant middleware clustered architectures using RabbitMQ
CN108701076B (zh) 分布式数据集存储和检索
Mai et al. Netagg: Using middleboxes for application-specific on-path aggregation in data centres
EP2901308B1 (en) Load distribution in data networks
US9674042B2 (en) Centralized resource usage visualization service for large-scale network topologies
JP5557590B2 (ja) 負荷分散装置及びシステム
US9350682B1 (en) Compute instance migrations across availability zones of a provider network
JP5664098B2 (ja) 複合イベント分散装置、複合イベント分散方法および複合イベント分散プログラム
CN105979273A (zh) 基于大数据及云计算的智能商用电视的云监控与云运维
US20200042608A1 (en) Distributed file system load balancing based on available node capacity
JP2023514487A (ja) 分散ストレージシステムにおけるマスターデータ配置
KR20200080458A (ko) 클라우드 멀티-클러스터 장치
US11336504B2 (en) Intent-based distributed alarm service
Alkaff et al. Cross-layer scheduling in cloud systems
KR100718907B1 (ko) 퍼지 그룹핑 기반의 로드 밸런싱 시스템 및 그 로드 밸런싱방법
Ranchal et al. RADical Strategies for engineering web-scale cloud solutions
Yang et al. High-performance docker integration scheme based on OpenStack
CN112655185B (zh) 软件定义网络中的服务分配的设备、方法和存储介质
Medhi et al. Openflow-based multi-controller model for fault-tolerant and reliable control plane
JP7260801B2 (ja) バックアップシステム及びその方法並びにプログラム
JP2024514467A (ja) 地理的に分散されたハイブリッドクラウドクラスタ

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150216

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151117

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160114

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160404

R151 Written notification of patent or utility model registration

Ref document number: 5914245

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151