(57)【要約】【課題】本発明は、複数のサーバとルータを組み合わせることにより、全体としての処理やトラヒックの負荷を効率的に分散することができる負荷分散システムの提供を目的とする。【解決手段】  通信可能な状態で互いに接続された複数のサーバと、該サーバに通信可能な状態に接続されたルータとを備えるサーバ群が複数存在し、各サーバ群の間において、各サーバが互いに通信可能な状態に接続されるとともに、各ルータが互いに通信可能な状態で接続される。某サーバ群において多量の処理を行う場合、他のサーバ群において当該処理を分散して行い、某サーバ群において多量のトラヒックがある場合、他のサーバ群のルータにおいて当該トラヒックを分散して行うことを特徴とする。【選択図】図１
2012032990.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバやルータの資源を管理するであって、
通信可能な状態で互いに接続された複数のサーバと、該サーバに通信可能な状態に接続されたルータとを備えるサーバ群が複数存在し、
各サーバ群の間において、各サーバが互いに通信可能な状態に接続されるとともに、各ルータが互いに通信可能な状態で接続され、
某サーバ群において多量の処理を行う場合、他のサーバ群において当該処理を分散して行い、
某サーバ群において多量のトラヒックがある場合、他のサーバ群のルータにおいて当該トラヒックを分散して行うことを特徴とする複合型資源管理システム。
【請求項２】
前記各サーバ群における前記サーバと前記ルータと通信可能な状態に設けられたコントロールサーバを備え、
該コントロールサーバは、某サーバ群において多量の処理を行う場合、某サーバ群のサーバからリソースオーバー通知を受けたあと、他のサーバ群のサーバのリソース状況を確認して、リソースに余裕のあるサーバ群のサーバにおいて処理を分散して行わせ、
某サーバ群において多量のトラヒックがある場合、某サーバ群のルータからトラヒックオーバー通知を受けたあと、他のサーバ群のルータのトラヒック状況を確認して、トラヒックに余裕のあるサーバ群においてトラヒックを分散して行わせる請求項１に記載の複合型資源管理システム。
【請求項３】
前記ルータは、前記サーバと同様にＣＰＵ、メモリ、通信制御部、ＷＡＮ制御部およびＬＡＮ制御部から構成される請求項１または請求項２に記載の複合型資源管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続された複数のクライアントに対しサービスを提供する複数のサーバとルータの負荷を分散する俯瞰分散システムに関する。
【背景技術】
【０００２】
従来、ネットワーク上のコンピュータリソースを融通し合って、仮想的に高性能のコンピュータを構成したり、柔軟に資源配分を行ったりできるようにする負荷分散システムが知られている。
【０００３】
この負荷分散システムは、一般には図５に示すように、一つのルータに対して複数のサーバが接続されており、当該複数のサーバの間で負荷分散されていた。そして、大規模なシステムの場合には、このような負荷分散システムが複数群設けられるものであった。
【０００４】
例えば、特許文献１には、グリッドコンピューティングシステムのミドルウェアに、データベースを特定するｊｏｂＩＤと、データベースを共有可能なユーザのｕｓｅｒＩＤとを対応付けて記憶するデータベース共有情報記憶手段４３と、一のユーザが、他のユーザが使用するデータベースのｊｏｂＩＤを指定してジョブを投入した際に、データベース共有情報記憶手段４３を検索し、他のユーザが使用するデータベースのｊｏｂＩＤに対応するｕｓｅｒＩＤに一のユーザのｕｓｅｒＩＤが含まれる場合に、一のユーザが投入したジョブの実行時に、他のユーザが使用するデータベースへの接続を設定するデータ処理装置５と、を備えたものが開示されている。
【０００５】
また、特許文献２には、クライアントの端末アプリケーションが起動されてサーバ決定が依頼されると、サーバ情報ファイルから、レスポンス時間が最短で、かつＣＰＵ使用率が最も低いサーバを検索して、クライアントに通知する通信経路変換装置５を設けて、クライアントが検索されたサーバに対して発行した接続要求にもとづいて、該サーバがクライアントを接続して通信を開始可能にするものが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９−１８７４１５号公報
【特許文献２】特開２０００−２５０８７８号公報
【特許文献３】特開２００６−２６１８０５号公報
【特許文献４】特開２００４−３３６２０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来の負荷分散システムによると、一つのサーバ群（例えばサーバ群Ａ）において処理量が限界に達するとそれ以上は処理を制限せざるを得ない一方、他のサーバ群（例えばサーバ群Ｂ）ではリソースに余裕があるなどして、サーバの負荷分散を効率的に行えていなかった。
【０００８】
また、一つのサーバ群（例えばサーバ群Ａ）においてルータのトラヒック量が限界に達すると通信を制限せざるを得ない一方、他のサーバ群（例えばサーバ群Ｂ）では処理に余裕があるなどして、ルータの負荷分散を効率的に行えていなかった。
【０００９】
すなわち、従来の負荷分散システムは、単に一つのサーバ群においてのみサーバの処理やルータのトラヒックの負荷を分散しているにすぎなかった。
【００１０】
なお、特許文献３，４には、サーバに複数のルータを設けるシステムが開示されているが、あくまでも単一のサーバに対するトラヒック量の負荷を分散するものである。このためサーバごとに常に複数のルータを設けなければならず、使用していないルータが常時存在することから無駄が多く、装置構成のコスト高を招くものであった。
【００１１】
本発明は、上述の問題に鑑みてなされたものであって、複数のサーバとルータを組み合わせることにより、サーバやルータの資源を効率的に管理する複合型資源管理システムの提供を目的とする。
【課題を解決するための手段】
【００１２】
本発明は、上記目的を達成するために、サーバやルータの負荷を分散するための複合型資源管理システムであって、通信可能な状態で互いに接続された複数のサーバと、該サーバに通信可能な状態に接続されたルータとを備えるサーバ群が複数存在し、各サーバ群の間において、各サーバが互いに通信可能な状態に接続されるとともに、各ルータが互いに通信可能な状態で接続され、某サーバ群において多量の処理を行う場合、他のサーバ群において当該処理を分散して行い、某サーバ群において多量のトラヒックがある場合、他のサーバ群のルータにおいて当該トラヒックを分散して行うことを特徴とする。
【００１３】
また、前記各サーバ群における前記サーバと前記ルータと通信可能な状態に設けられたコントロールサーバを備え、該コントロールサーバは、某サーバ群において多量の処理を行う場合、某サーバ群のサーバからリソースオーバー通知を受けたあと、他のサーバ群のサーバのリソース状況を確認して、リソースに余裕のあるサーバ群のサーバにおいて処理を分散して行わせ、某サーバ群において多量のトラヒックがある場合、某サーバ群のルータからトラヒックオーバー通知を受けたあと、他のサーバ群のルータのトラヒック状況を確認して、トラヒックに余裕のあるサーバ群においてトラヒックを分散して行わせるのが好ましい。
【００１４】
また、前記ルータは、前記サーバと同様にＣＰＵ、メモリ、通信制御部、ＷＡＮ制御部およびＬＡＮ制御部から構成されるのが好ましい。
【発明の効果】
【００１５】
本発明によれば、個々のサーバー・ルータの使用率（ＣＰＵ・ＭＭ・ＧＰＵ）を総合管理し運用することにより、個々のサーバーが一つの高性能サーバーとして運用できる。また、ルータの回線制御を総合管理することにより、個々の回線が一つの高速回線と同じ処理が出来る。そして、大型サーバーを設置することなく、小型サーバーを統合することにより大型サーバーを設置したのと同様の性能を利用できる。このようにサーバーとルータを効率よく運用することにより、個々のサーバー・ルータが機能増設することなく、他サーバー・ルータの空いているリソースを利用し仮想的に性能を上げることができ、全体としての処理やトラヒックの負荷を効率的に分散することができる。この結果、一台のサーバーでは処理時間がかかっていたジョブを他のサーバーを仮想的に利用することで大幅に処理時間を短縮することができる。
【図面の簡単な説明】
【００１６】
【図１】本システムの全体構成を示す概略図である。
【図２】サーバのハードウェア構成を示す概略図である。
【図３】ルータのハードウェア構成を示す概略図である。
【図４】コントロールサーバのハードウェア構成を示す概略図である。
【図５】従来の複合型資源管理システムの全体構成を示す概略図である。
【発明を実施するための形態】
【００１７】
次に本発明の一実施形態に係る複合型資源管理システム（以下、本システムという）について、図面を参照しつつ説明する。
【００１８】
本システムは、図１に示すように、複数のサーバ群Ａ、Ｂから構成される。なお、図１では紙面の関係上、サーバ群Ａ，Ｂのみ図示しているが、実際にはそれ以上のサーバ群から構成される場合が多い。
【００１９】
このサーバ群Ａは、通信可能な状態で互いに接続された複数のサーバと、該サーバに通信可能な状態に接続されたルータとを備える。また、各サーバ群Ａ、Ｂの間において、各サーバが互いに通信可能な状態に接続されるとともに、各ルータが互いに通信可能な状態で接続されている。
【００２０】
そして、某サーバ群において多量の処理を行う場合、他のサーバ群において当該処理を分散して行う。また、某サーバ群において多量のトラヒックがある場合、他のサーバ群のルータにおいて当該トラヒックを分散して行う。この動作について後に詳述することとする。
【００２１】
前記サーバは、図２に示すように、ＬＡＮ制御、ＣＰＵ、ＭＭ，ＤＩＳＫおよびＧＰＵ
などから構成される。このＬＡＮ（Local Area Network）制御は、他のサーバやルータのＬＡＮ制御とのローカルアドレスを使用して通信を行う。ＣＰＵ（Central Processing Unit：中央演算装置）はＤＩＳＫからＭＭに読み込んだプログラムを実行し、各ＬＡＮ制御・ＧＰＰＵ・ＤＩＳＫを制御する。ＭＭ（Main Memory：主記憶装置）は実行プログラムの格納や処理データーの格納処理を行う。ＤＩＳＫ（Disk Drive）は、プログラムやデーターを格納保存を行う。このＤＩＳＫは、装置全体を制御するオペレーティングシステムであるＬｉｎｕｘ、ホームページ・アプリケーションであってデーターベースの制御プログラムであるＷＥＢ・ＡＰ・ＤＢ制御、装置内のリソース管理や、他のサーバやルータのＧＣＣＳ−Ｓの管理、ＧＣＣＳーＭとのの制御情報管理を行うＧＣＣＳ−Ｓからなる。ＧＰＵ（Graphics Processing Unit）は、画面制御や画像処理制御を行う。
【００２２】
前記ルータは、図３に示すように、モデム、ＷＡＮ、ＣＰＵ、ＭＭ、ＳＳＤ、ＧＰＵ、ＬＡＮなどから構成される。このモデム（Modem）は、ＷＡＮ制御から送られてくるデジタルデーターを音声信号に変換して通信回線に送ったり、通信回線から送られてくる音声信号をデジタルデーターに変換しＷＡＮ制御に送る機器である。ＷＡＮ（Wide Area Network）制御はモデムから送られてくるデジタルデーターを自己のデーターか判断（ＩＰアドレス）し、自己のデーターであればＣＰＵに従い、ＢＵＳ経由でＭＭにデーターを送ったり。ＣＰＵに従いＭＭやＳＳＤからのデーターをＢＵＳ経由で受けてデジタルデーターとしてモデムに送る。ＣＰＵ（Central Processing Unit：中央演算装置）は、ＳＤからＭＭに読み込んだプログラムを実行し、各ＷＡＮ制御・ＧＰＵ・ＬＡＮ制御・ＳＳＤを制御する。ＭＭ（Main Memory：主記憶装置）は、実行プログラムの格納や処理データーの格納処理を行う。ＳＳＤ（Solid State Drive）は、プログラムやデーターを格納保存を行う。このＳＳＤは、装置全体を制御するオペレーティングシステムＬｉｎｕｘ、WAN・LANの通信制御とLANに接続されるサーバー機器などの制御制御（ローカルアドレス管理）を行う通信制御、装置内のリソース管理や、他装置のＧＣＣＳ−Ｒの管理、ＧＣＣＳ−Ｍとの制御情報管理を行うＧＣＣＳ−Ｒからなる。ＧＰＵ（Graphics Processing Unit）は、画面制御や画像処理制御を行う。ＬＡＮ（Local Area Network）制御は、他のサーバやルータのＬＡＮ制御とのローカルアドレスを使用して通信を行う。このようにルータをサーバによって構成することができる。
【００２３】
また、本実施形態では、前記各サーバ群における前記サーバと前記ルータと通信可能な状態に設けられたコントロールサーバが設けられている。
【００２４】
前記コントロールサーバは、某サーバ群において多量の処理を行う場合、某サーバ群のサーバからリソースオーバー通知を受けたあと、他のサーバ群のサーバのリソース状況を確認して、リソースに余裕のあるサーバ群のサーバにおいて処理を分散して行わせる機能を有する。また、某サーバ群において多量のトラヒックがある場合、某サーバ群のルータからトラヒックオーバー通知を受けたあと、他のサーバ群のルータのトラヒック状況を確認して、トラヒックに余裕のあるサーバ群においてトラヒックを分散して行わせる機能を有する。この動作については後に詳述することとする。
【００２５】
前記コントロールサーバは、図４に示すように、ＣＰＵ、ＭＭ、ＳＳＤ、ＧＰＵ、ＬＡＮなどから構成される。このＬＡＮ（Local Area Network）制御は、他のサーバやＬＡＮ制御とのローカルアドレスを使用して通信を行う。また、ＣＰＵ（Central Processing Unit：中央演算装置）はＤＩＳＫからＭＭに読み込んだプログラムを実行し、各ＬＡＮ制御・ＧＰＵ・ＤＩＳＫを制御する。ＭＭ（Main Memory：主記憶装置）は実行プログラムの格納や処理データーの格納処理を行う。ＤＩＳＫ（Disk Drive）はプログラムやデーターを格納保存を行う。このＤＩＳＫは、装置全体を制御するオペレーティングシステムであるＬｉｎｕｘ、ホームページ・アプリケーションであってデーターベースの制御プログラムであるＷＥｂ・ＡＰ・ＤＢ制御、装置内のリソース管理や、他装置のＧＣＣＳ−Ｓの管理、ＧＣＣＳ−Ｍとの制御情報管理を行うＧＣＣＳ−Ｓからなる。ＧＰＵ（Graphics Processing Unit）は画面制御や画像処理制御を行う。
【００２６】
次に本システムの動作について説明する。
【００２７】
図１に示すように、サーバーＡ群に於いてサーバーＡ−１はＧＣＣＳ−Ｓオペレーティングシステムにより、サーバーＡ−１内のリソース（ＣＰＵ・ＭＭ・ＧＰＵの使用率）を監視し、リソースの空き状況をコントロールサーバーのＧＣＣＳ−Ｍに通知すると共に、サーバーＡ群内のサーバーＡ−２・Ａ−３のＧＣＣＳ−Ｓにも通知する。
【００２８】
同様に、サーバーＡ−２のＧＣＣＳ−Ｓオペレーティングシステムにより、リソースの空き状況をコントロールサーバーのＧＣＣＳ−Ｍに通知すると共に、サーバーＡ群内のサーバーＡ−１・Ａ−３のＧＣＣＳ−Ｓにも通知する。
【００２９】
サーバーＡ−３もＧＣＣＳ−Ｓオペレーティングシステムにより、リソースの空き状況をコントロールサーバーのＧＣＣＳ−Ｍに通知すると共に、サーバーＡ群内のサーバーＡ−１・Ａ−２のＧＣＣＳ−Ｓにも通知する。
【００３０】
これにより、サーバーＡ群内でのリソースの空き状況をサーバーＡ−１・Ａ−２・Ａ−３間で監視し、必要時にいつでも他リソースを利用できリソースの有効活用が出来る。
【００３１】
また、ルータＡはＧＣＣＳ−Ｒオペレーティングシステムにより、ルータ内のリソースを監視しコントロールサーバーのＧＣＣＳ−Ｍにリソースの空き状況を通知するとともに、通信制御の通信回線トラヒック状況をコントロールサーバーのＧＣＣＳ−Ｍに通知する。  
【００３２】
これにより、サーバーＡ−１・Ａ−２・Ａ−３は自己の回線使用率に合わせた通信回線の確保を、コントロールサーバーのＧＣＣＳ−Ｍが制御することにより行われる。これらの機能は、サーバーＢ群・ルータＢに於いても同様に、リソースの監視と通信回線の監視を行う。
【００３３】
また、ジョブの実行に関して、サーバーＡ群内のサーバーＡ−１に於いて画像処理等で多量のデーターや処理を行う場合、サーバーＡ−１はＧＣＣＳ−Ｓの機能により、大きなデーターを他サーバーに分散して処理を行う機能と、大きな処理（ジョブ）を小さな単位（タスク）に分割して、他サーバーに分散し並列処理する機能がある。
【００３４】
これらの機能により、サーバーＡ−１に於いて大きな処理を行う場合、サーバーＡ−１は、コントロールサーバーのＧＣＣＳ−Ｍに対しリソースオーバー通知を行う。コントロールサーバーＧＣＣＳ−Ｍは、サーバーＡ−２・Ａ−３のリソース状況を確認し、リソースの空いているサーバーＧＣＣＳ−Ｓに利用通知を出すと共に、サーバーＡ−１のＧＣＣＳ−Ｓに使用許可を出す。
【００３５】
コントロールサーバーＧＣＣＳ−Ｍから使用通知をもらったサーバーＡ−１のＧＣＣＳ−Ｓは、使用許可の出たサーバーＡ−２・Ａ−３のＧＣＣＳ−Ｓに使用通知を出し、ジョブを分割化したタスク処理の一つをサーバーＡ−１・Ａ−２のＧＣＣＳ−Ｓに渡しタスクの実行指示を行う。タスク処理を受けたサーバーＡ−１・Ａ−２のＧＣＣＳ−Ｓはタスクの実行を行い、進捗状況をサーバーＡ−１のＧＣＣＳ−Ｓに通知すると共にコントロールサーバーのＧＣＣＳ−Ｍにも通知する。
【００３６】
サーバーＡ−１は、ＧＣＣＳ−Ｓによりジョブの進行状況の管理とサーバーＡ−２・Ａ−３に渡したタスク処理の進捗状況の管理を行う。サーバーＡ−１のＧＣＣＳ−Ｓは、自己のタスクの進捗状況とサーバーＡ−２・Ａ−３のＧＣＣＳ−Ｓからタスクの進捗状況の通知を受け、すべてのタスク完了通知を受けてジョブの処理完了となり、サーバーＡ−２・Ａ−３のＧＣＣＳ−ＳとコントロールサーバーのＧＣＣＳ−Ｍに完了通知を行う。完了通知を受けたサーバーＡ−２・Ａ−３はリソースの解放となり、コントロールサーバーのＧＣＣＳ−Ｍに新たに空きリソース状況を通知する。
【００３７】
ところで、サーバーＡ−１の処理が、サーバーＡ群内の空きリソースだけでは処理能力が不足する場合には、サーバーＡ群の処理と同時に、サーバーＢ群の空きリソースも利用可能になっている。ただし、本実施形態では、利用に際してはコントロールサーバー経由での利用に限られ、直接サーバーＢ群のサーバーＢ−１・Ｂ−２・Ｂ−３に指示を出せないようになっている。
【００３８】
サーバーＢ群を利用する際には、サーバーＡ−１のＧＣＣＳ−Ｓは、コントロールサーバーのＧＣＣＳ−Ｍに使用通知を出し、コントロールサーバーのＧＣＣＳ−Ｍから使用許可を受けて、サーバーＡ−１のＧＣＣＳ−Ｓは、コントロールサーバーのＧＣＣＳ−Ｍにタスク処理を依頼する。
【００３９】
コントロールサーバーＧＣＣＳ−Ｍは、空きリソースの通知のあったサーバーＢ−１・Ｂ−２・Ｂ−３のＧＣＣＳ−Ｓに使用通知を出し、サーバーＡ−１のジョブの分割化されたタスク処理の一つをサーバーＢ−１・Ｂ−２・Ｂ−３に渡しタスクの実行指示を行う。
【００４０】
サーバーＢ−１・Ｂ−２・Ｂ−３のＧＣＣＳ−Ｓはタスクの実行と進捗状況を、コントロールサーバーのＧＣＣＳ−Ｍに通知する。コントロールサーバーのＧＣＣＳ−Ｍは、サーバーＢ−１・Ｂ−２・Ｂ−３のＧＣＣＳ−Ｓからタスクの進捗状況を受けると、サーバーＡ−１のＧＣＣＳ−Ｓにタスクの進捗状況の通知を行う。
【００４１】
サーバーＡ−１のＧＣＣＳ−Ｓは、自己のタスクの実行完了とサーバーＡ−２・Ａ−３のＧＣＣＳ−ＳとコントロールサーバーのＧＣＣＳ−Ｍからタスクの実行完了（サーバーＢ−１・Ｂ−２・Ｂ−３のタスクの実行完了）の通知を受けて、すべてのタスク実行完了としてジョブの処理完了となり、サーバーＡ−２・Ａ−３のＧＣＣＳ−ＳとコントロールサーバーのＧＣＣＳ−Ｍにジョブの完了通知を行う。
【００４２】
コントロールサーバーのＧＣＣＳ−Ｍは、サーバーＡ−１のＧＣＣＳ−Ｓから完了通知を受け、各サーバーＢ−１・Ｂ−２・Ｂ−３のＧＣＣＳ−Ｓに完了通知を行う。完了通知を受けたサーバーＡ−２・Ａ−３・Ｂ−１・Ｂ−２・Ｂ−３はリソースの解放となり、コントロールサーバーのＧＣＣＳ−Ｍに新たに空きリソース状況を通知する。
【００４３】
コントロールサーバーＧＣＣＳ−Ｍは、サーバー群単位での空きリソースやタスク処理の管理制御を行い、サーバー群が増えた場合でもコントロールサーバーのＧＣＣＳ−Ｍにてサーバー群単位での空きリソースやタスク処理の管理制御を行う。
【００４４】
この機能は、ルータＡとルータＢ間でも同じことが出来、ルータＡのＧＣＣＳ−Ｒは、通信制御の通信回線使用状況（トラヒック）をコントロールサーバーのＧＣＣＳ−Ｍに通知する。同様にルータＢのＧＣＣＳ−Ｒは、通信制御のトラヒックをコントロールサーバーのＧＣＣＳ−Ｍに通知する。
【００４５】
ルータＡのトラヒックがオーバーする場合、ルータＡのＧＣＣＳ−ＲはコントロールサーバーのＧＣＣＳ−Ｍにトラヒックオーバー通知を行う。コントロールサーバーのＧＣＣＳ−Ｍは、ルータＢのＧＣＣＳ−Ｒに通信回線の空きが有るか確認通知を出す。ルータＢに空きがある場合、ルータＢのＧＣＣＳ−Ｒより、コントロールサーバーのＧＣＣＳ−Ｍに対しトラヒックに空きがあることを通知する。コントロールサーバーのＧＣＣＳ−Ｍは、ルータＢのＧＣＣＳ−Ｒに通信回線の使用通知を出す。
【００４６】
このようにルーターＡは、ルータＢの通信回線の空きを利用し通信回線のトラヒックオーバーを回避する。
【符号の説明】
【００４７】
Ａ−１、２、３…サーバＡ群のサーバ
Ｂ−１、２、３…サーバＢ群のサーバ
Ｍ…コントロールサーバ
【図１】
2012032990.tif 000003
【図２】
2012032990.tif 000004
【図３】
2012032990.tif 000005
【図４】
2012032990.tif 000006
【図５】
2012032990.tif 000007