(57)【要約】【課題】グリッドシステム導入にあたって、現状の業務システムの改変を最小限にするとともに、容易なグリッドシステム構築を実現する。【解決手段】業務システム１０１には、負荷の低い業務プログラム２０３と、負荷の高い業務プログラム２０２とが混在している。プラグイン１０３は、負荷の高い業務プログラム２０２に対して組み込むことが可能になっており、負荷の高い業務プログラム２０２からの処理要求を、ネットワーク２０５を介してリソースプール１０４に対して送受信する手段を備えている。【選択図】図２
2008299527.tif 000002
【特許請求の範囲】
【請求項１】
複数の業務プログラムが稼働する業務システムと、該業務システムとネットワーク接続され、複数の処理ノードの負荷のバランスをとる負荷バランサを備えたリソースプールと、該リソースプールに対してコントロールを行う管理コンソールを有するグリッド管理システムと、を含んで構成されたグリッドシステムにおいて、
業務システムに前記業務プログラム単位で組み込まれ、前記グリッドシステムによる負荷分散を可能とするプラグインを備えることを特徴とするグリッドコンピューティングシステム。
【請求項２】
前記プラグインを、前記業務プログラム中で負荷の高い部分に装着するとともに、該プラグインと前記リソースプールとをネットワーク接続し、前記プラグインから前記処理ノードへの処理要求と、該処理要求に対する応答と、のやり取りを行うとともに、該やり取りに基づいて前記プラグインと前記リソースプールとのデータの送受信を行う第１の通信手段と、を有することを特徴とする請求項１に記載のグリッドコンピューティングシステム。
【請求項３】
前記グリッドシステムと、前記グリッド管理システムと、の間でデータの送受信を行う第２の通信手段を有し、前記管理コンソールは、前記第２の通信手段により、前記リソースプールの負荷報告を受信し、該負荷報告による負荷状況に基づいて、前記処理ノードへの負荷分散を決定することを特徴とする請求項１又は２に記載のグリッドコンピューティングシステム。
【請求項４】
前記プラグインは、前記業務プログラムの基盤となる基盤ソフトウェアにより、前記業務プログラムによる処理に代えて前記第１の通信手段を介して前記リソースプールへ処理を依頼するすり替え手段を有することを特徴とする請求項１から３までのいずれか１項に記載のグリッドコンピューティングシステム。
【請求項５】
前記プラグインは、
前記リソースプールにおいて分散処理できるか否かを判断する手段と、
分散処理できると判断された場合に、前記リソースプールに処理を要求する手段と、
分散処理できないと判断された場合に、前記すり替え手段によるすり替え前のソフトウェアを用いて処理する手段と
を有することを特徴とする請求項４に記載のグリッドコンピューティングシステム。
【請求項６】
前記リソースプールと前記管理コンソールとにおいて、前記リソースプール内の前記複数の処理ノードを仮想的に網状に配置してリソース管理する管理手段を有することを特徴とする請求項１から５までのいずれか１項に記載のグリッドコンピューティングシステム。
【請求項７】
さらに、前記網状に配置された処理ノードのそれぞれが、前記管理コンソールに対して自身の負荷の状況を送信する手段と、を有することを特徴とする請求項６に記載のグリッドコンピューティングシステム。
【請求項８】
さらに、前記管理手段は、負荷上昇時の処理ノードからの報告に従って自律的に処理ノードを追加し、負荷減少時の処理ノードからの報告に従って自律的に処理ノードを減らすことを特徴とする請求項６又は７に記載のグリッドコンピューティングシステム。
【請求項９】
複数の業務プログラムが稼働する業務システムと、該業務システムとネットワーク接続され、複数の処理ノードの負荷のバランスをとる負荷バランサを備えたリソースプールと、該リソースプールに対してコントロールを行う管理コンソールを有するグリッド管理システムと、を含んで構成されたグリッドシステムにおける業務システムであって、
前記業務プログラム単位で組み込まれ、前記グリッドシステムによる負荷分散を可能とするプラグインを備え、
前記プラグインを、前記業務プログラム中で負荷の高い部分に装着するとともに、該プラグインと前記リソースプールとをネットワーク接続し、前記プラグインから前記処理ノードへの処理要求と、該処理要求に対する応答と、のやり取りを行うとともに、該やり取りに基づいて前記プラグインと前記リソースプールとのデータの送受信を行う第１の通信手段と、
前記グリッドシステムと、前記グリッド管理システムと、の間でデータの送受信を行う第２の通信手段と、を有することを特徴とする業務システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、グリッドコンピューティングシステムに関し、特に、コンピュータネットワーク上で提供するアプリケーションサービスに関連する処理割り当て技術に関し、より詳細には、複数の情報処理装置等をネットワーク上で接続したグリッドコンピューティングシステムへの接続技術に関する。
【背景技術】
【０００２】
コンピュータが処理すべき情報量は増大する傾向にあり、一台のコンピュータでは処理しきれなくなる場合がある。このような問題を解決するものとして、近年、グリッドコンピューティングと呼ばれる技術が注目され始めている。グリッドとは、複数の計算機などから構成される異種混合システムを構成し、負荷の分散を図るものである。このようなシステムに関連する技術としては、下記の特許文献１がある。
【０００３】
【特許文献１】特開２００５−５６２０１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、グリッドによる負荷分散システムでは、複数の計算機にあらかじめ分散対象のシステム全体を複製し、同一のプログラム実行環境を準備して、負荷分散をする。しかしながら、負荷の高いシステムであっても、内部のプログラム全部の負荷が高いとは限らず、負荷が高いのはシステム全体の一部である場合が多い。つまり、現状のグリッドシステムは、分散の必要がないプログラム部分に関しても分散処理を行っていることになる。このため、実質的にグリッドを運用するユーザは、必要のない計算機への投資をしていることになるという不都合が生じる。
【０００５】
グリッドシステムを用いた業務システムの運用を考える場合に、グリッドシステムを用いていない形態で運用されている業務システムを、グリッドシステムを用いた負荷分散環境に移行する場合に、業務システムのプログラム、あるいは、動作環境の改変が伴う。このため、グリッドに移行するための現状業務システムの改変費用が必要になる上に、動作障害に対するリスクも発生することになる。
【０００６】
グリッドシステムにおける分散処理を考える場合に、グリッドシステム内においてどのように負荷を分散するのかに関しては、予め考慮して設計を行い、ルール付けする必要がある。あるいは、グリッドシステム内のコンピュータの定義づけを行う必要がある。
【０００７】
しかし、このような作業は非常に複雑である上に煩雑な作業でもあり、専門的な知識を持った技術者以外は困難な作業ともなっている。
【０００８】
本発明は、グリッドシステム導入にあたって、現状の業務システムの改変を最小限にするとともに、容易なグリッドシステム構築を実現することを目的とする。また、効率的な計算機システムの利用を可能とすることを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一観点によれば、複数の業務プログラムが稼働する業務システムと、該業務システムとネットワーク接続され、複数の処理ノードの負荷のバランスをとる負荷バランサを備えたリソースプールと、該リソースプールに対してコントロールを行う管理コンソールを有するグリッド管理システムと、を含んで構成されたグリッドシステムにおいて、業務システムに前記業務プログラム単位で組み込まれ、前記グリッドシステムによる負荷分散を可能とするプラグインを備えることを特徴とするプラグイングリッドコンピューティングシステムが提供される。前記プラグインを、前記業務プログラム中で負荷の高い部分に装着するとともに、該プラグインと前記リソースプールとをネットワーク接続し、前記プラグインから前記処理ノードへの処理要求と、該処理要求に対する応答と、のやり取りを行うとともに、該やり取りに基づいて前記プラグインと前記リソースプールとのデータの送受信を行う第１の通信手段と、を有することが好ましい。前記グリッドシステムと、前記グリッド管理システムと、の間でデータの送受信を行う第２の通信手段を有することが好ましい。
【００１０】
また、前記管理コンソールは、前記第２の通信手段により、前記リソースプールの負荷報告を受信し、該負荷報告による負荷状況に基づいて、前記処理ノードへの負荷分散を決定することが好ましい。
【００１１】
前記プラグインは、前記業務プログラムの基盤となる基盤ソフトウェアにより、前記業務プログラムによる処理に代えて前記第１の通信手段を介して前記リソースプールへ処理を依頼するすり替え手段を有していても良い。前記プラグインは、前記リソースプールにおいて分散処理できるか否かを判断する手段と、分散処理できると判断された場合に、前記リソースプールに処理を要求する手段と、分散処理できないと判断された場合に、前記すり替え手段によるすり替え前のソフトウェアを用いて処理する手段と、を有することが好ましい。
【００１２】
前記第１の通信手段により、前記プラグインと前記リソースプールとの間において、前記プラグインからデータを圧縮して送信する手段と、前記リソースプールからデータを圧縮して送信する手段と、前記プラグインから前記圧縮されたデータを受け取って解凍する手段と、前記リソースプールから圧縮されたデータを受け取って解凍する手段と、を有するようにしても良い。前記リソースプールと前記管理コンソールとにおいて、前記リソースプール内の前記複数の処理ノードを仮想的に網状に配置してリソース管理する管理手段を有することが好ましい。さらに、前記網状に配置された処理ノードのそれぞれが、前記管理コンソールに対して自身の負荷の状況を送信する手段と、を有していても良い。さらに、前記管理手段は、負荷上昇時の処理ノードからの報告に従って自律的に処理ノードを追加し、負荷減少時の処理ノードからの報告に従って自律的に処理ノードを減らすようにしても良い。上記システムによれば、業務プログラムの改変を行うことなく、容易にグリッドによる負荷分散システムを導入できる。
【００１３】
尚、上記解決手段に示された構成要素は、システム全体の形態又はそれぞれ個別の装置（システム）の形態のいずれをもとることができる。また、上記処理を行うためのプログラムや、それを記録したコンピュータで読みとり可能な記録媒体も本発明の範疇に入るものである。
【発明の効果】
【００１４】
本発明のプラグイングリッドシステムによれば、次のような効果がある。
（１）負荷の高いシステムにあっても、内部では負荷の高い部分と、負荷の低い部分があるが、負荷の高い部分だけを分散処理することができるため、効率が高まる。
（２）負荷の高い処理を行っている内部を、負荷分散をするグリッドシステムに対する要求、及び、処理結果の受信だけをするプラグインに置き換えるため、負荷の高いシステムのシステム改変をすることなくグリッドのメリットを享受できる。
（３）リソースプール内で使用する計算機リソースは自律的に判断して増減を行うようにすると、利用者は定義づけを行う必要はないため処理が簡単である。
【発明を実施するための最良の形態】
【００１５】
本明細書において、プラグインとは、業務ソフトウェアなどのアプリケーションソフトウェアに追加機能を提供するための小さなプログラムのことを指し、特に、業務プログラムとリソースプールとの双方向通信を可能にするプログラムを指す。
【００１６】
以下、本発明の一実施の形態によるグリッドコンピューティングについて図面を参照しながら説明を行う。本実施の形態によるグリッドコンピューティングは、プラグインを適用することを特徴とする。
【００１７】
図１は、本実施の形態によるグリッドコンピューティングシステムの一構成例を示す機能ブロック図である。図１に示すように、本実施の形態によるグリッドコンピューティングは、業務システム１０１と、リソースプール１０４と、管理コンソール１０７と、を有して構成されている。業務システム１０１には、既存の業務プログラム１０２が多数インストールされており、さらに、プラグイン１０３が新たに組み込まれ、リソースプール１０４との通信（Ｌ１）を行うことができるように構成されている。リソースプール１０４は、複数の処理ノード１０５と、これらの処理ノード１０５のぞれぞれと接続される負荷バランサ１０６と、を備えている。プラグイン１０３からの処理要求があると、処理ノード１０５で処理が行われる。負荷バランサ１０６は、処理ノード１０５への処理の割り振りと、管理コンソール１０７との通信とを行う（Ｌ２、Ｌ３）。管理コンソール１０７は、図示しないリソースプール１０４との通信手段を有しており、グリッドコンピューティングシステムを操作するためのＧＵＩ１０８、及び、稼動/障害レポート１０９を出力する図示しない出力部と、を備えている。
【００１８】
図２は、図１に示した業務システム１０１の詳細な構成例を示す図である。図２に示す業務システム１０１には、負荷の低い業務プログラム２０３と、負荷の高い業務プログラム２０２とが混在している。プラグイン１０３は、負荷の高い業務プログラム２０２に対して組み込むことが可能になっており、負荷の高い業務プログラム２０２からの処理要求を、ネットワーク２０５を介してリソースプール１０４に対して送受信する手段を備えている。
【００１９】
図３は、図１に示したリソースプール１０４の構成例を示す図である。リソースプール１０４は、処理ノード１０５と負荷バランサ１０６とを有している。プラグイン１０３からの処理要求Ｌ１は、負荷バランサ１０６が受信し、処理ノード１０５を含む各処理ノードに送信することで処理を行わせる。また、処理ノード１０５からの処理結果は、負荷バランサ１０６を介してプラグイン１０３に対して返送される。また、負荷バランサ１０６は、リソースプール１０４の全体を管理する図示しない管理手段を備えている。これにより、管理コンソール１０７（図１）から構成管理要求を受けて処理ノードへの負荷配分を変更することができる。さらに、リソースプール１０４内の稼動／障害情報を、管理コンソール１０７に対して送信する手段を備えている。符号Ｌ１（処理要求及び応答）、Ｌ２（イベント）、Ｌ３（管理）に関しては後述する。
【００２０】
図４は、図１で記述した管理コンソール１０７の構成例を示す図である。管理コンソール１０７は、グリッドコンピューティングシステム全体を管理するコントローラ４０６と、ユーザがシステムに対して操作をするインターフェイスを構成するＧＵＩ４０５と、を有して構成されている。ＧＵＩ４０５は、ユーザによるグリッドの構成管理操作の受付、および、稼動障害レポートの出力操作の受付を行う。コントローラ４０６は、ＧＵＩ４０５からの構成管理操作を構成管理要求Ｌ３としてリソースプールに要求する。また、ＧＵＩ４０５から、稼動／障害レポートの出力要求を受けた場合は、リソースプールからの稼動障害イベントＬ２を元にレポート４０４を作成し出力することができる。レポート４０４が、システムの性能、障害などの情報を含む。
【００２１】
図５は、実際の業務システム１０１の詳細な構成例を示す図である。図５に示すように、業務システム１０１は、プラグインの組み込みを、ＯＳの差分を吸収する基盤ソフトであるJavaを基盤としたシステムである。以下、ＸＭＬデータを処理する業務プログラムが稼動している場合を例にして説明する。まず、本実施の形態による業務システム１０１は、基盤ソフト５０２としてJavaを採用しているものとする。業務プログラム１０２は、基盤ソフト５０２の持っているＸＭＬ処理プログラムを用いてＸＭＬの読み込みから業務データ処理までのＸＭＬ操作を行っている。プラグイン１０３は、このＸＭＬ処理プログラムを上書きする形で業務システム１０１に組み込むように構成されている。従って、業務プログラム１０２を改変することなく、グリッド接続のためのプラグイン１０３を組み込むことができる。すなわち、プラグイン１０３は、内部で全てのプログラムを処理するのではなく、負荷の高いプログラムを選択的に外部のリソースプール１０４に通信により処理を依頼する。この際、業務プログラム１０２に関しては、何ら改変を行わなくても良い。
【００２２】
図６は、図５で示したプラグイン１０３の処理を、業務プログラム１０２において、ＸＭＬのパース処理にグリッドを適用する例に説明するための図である。図６に示すように、プラグイン１０３では、業務プログラム１０２から処理要求を受け取ると、リソースプール１０４による分散処理が可能な要求か否かを判断する。この際、分散処理可能な要求であれば、プラグインの通信機能６０３を呼び出して、リソースプール（グリッドシステム）１０４へ処理要求を転送し、リソースプール１０４から結果を受け取る。
【００２３】
一方、分散処理しない要求が業務プログラム１０２から来た場合は、プラグイン１０３が改変せずに残しておいた従来機能（元々、ＪＡＶＡが持っているＡＰＩ）を用いて処理を行う。このように構成することにより、業務プログラム１０２から見ると、プラグイン１０３を組み込む前でも、組み込んだ後でも、同じ処理結果を得ることができる。
【００２４】
尚、いずれのプログラムが高負荷であるかに関しては、業務プログラムにおいてユーザが予め推定し指定できるようにしても良いし（例えばＸＭＬ処理などの高負荷が予測される処理）、或いは、プログラムの負荷を随時監視しておき、その結果に基づいて、高負荷のプログラムをピックアップして、リソースプールに通信で送るようにしても良い。後者の方法によれば、リアルタイムに負荷分散を行うことができるという利点がある。
【００２５】
図７は、プラグイン１０３とリソースプール１０４との間の通信について説明する図である。業務システム１０１の中の業務プログラム１０２は、プラグイン１０３に対して処理の要求を行う。この際、プラグイン１０３は、リソースプール１０４に対してデータを送信する際に圧縮を行い、圧縮データ７０２がリソースプール１０４に向けて送信される。リソースプール１０４側では、圧縮データ７０２を解凍して元に戻してからＸＭＬなどの処理を行う。リソースプール１０４からプラグイン１０３への返信においても、同様の圧縮処理を行い、圧縮データ７０４がプラグイン１０３へ送信される。このように、データ圧縮を行うことにより、ネットワーク（通信回線）の負荷が下がり、より多くの処理要求をリソースプール１０４において分散処理できるようになるという利点がある。尚、ＸＭＬ処理などは、圧縮するとデータ量が小さくなる処理の場合には圧縮を行い、ｊｐｇなどの処理には圧縮を行ことなく処理を行うようにする。このように、データによって圧縮処理を行うか否かを切り分けて行うことが好ましい。
【００２６】
以下に、リソースプール内における処理例について説明する。図８は、リソースプール１０４内における処理ノードの初期量管理方式を示す図である。本実施の形態によるグリッドシステムでは、プラグインの種類ごとに、リソースプール１０４に初期量を割り当てることができる。また、リソースプール１０４内の処理ノード（図では、８０４ａ、８０４ｂで示されており、実際には、さらに多くの処理ノードを有している場合が多い）は、管理コンソール１０７によって図に示すように、仮想的に、網目状の線によって画定される１つ１つの升目として管理される。
【００２７】
管理コンソール１０７から、構成管理要求８０２としてリソースプール１０４に対して初期量の割り当て指示があった場合に、リソースプール１０４は指示された処理ノード、例えば８０４ａ・８０４ｂを初期量として割り当てる。初期量の割り当ては、図３を参照しながら説明した負荷バランサ１０６が処理ノード８０４ａ・８０４ｂに対して、全ての処理要求を渡すことにより実現される。
【００２８】
上記の方式により、リソースプール１０４内の各処理ノードは、リソースプール１０４の構成をそれぞれが意識して管理する必要がなく、管理コンソール１０７のみによる簡易な方式でグリッドシステム全体を一元管理することができる。
【００２９】
図９は、図８の状態のリソースプール内で負荷が上昇した場合の、管理コンソールまでの情報伝達の例について説明する図である。リソースプール１０４内の各処理ノードは、それぞれ自身の負荷については監視することができる。負荷が上昇した場合、あらかじめきめられた負荷に達していない処理ノード８０４ｂは、負荷の報告はしない。また、決められた負荷を超えた処理ノード８０４ａは、図３で説明した負荷バランサ１０６を通して、負荷報告９０２を管理コンソール１０７に送信する。負荷報告９０２を受け取った管理コンソール１０７は、処理ノード追加処理を実行する。この処理ノードの追加処理とノードの削減処理に関しては、後述する図１０から図１３までを参照して説明する。
【００３０】
図１０は、処理ノードの追加／削除の方式の一例を示す図である。リソースプール１０４内で高負荷となった処理ノード８０４ａに対して、図９において記述した方式に従って、負荷報告９０２を管理コンソール１０７に対して送信する。負荷報告９０２を受け取った管理コンソール１０７は、高負荷となった処理ノード８０４ａの隣のノード（図では、上下左右の４ノード）１００４を、追加の処理ノードとして割り当てる。その結果、管理コンソール１０７内で仮想的に管理されているリソースプール１０４の網目はリソースプール１０４ａに示すように、８０４ａとそれに隣接する４つのノードとの５つのノードを含む状態になる。管理コンソール１０７は、リソースプール１０４ａに対して、ノード追加要求１００７を送信し、ノード追加要求１００７を受け取ったリソースプール１０４ａは、新たに１００４の処理ノードを使うようになる。また、負荷が減少した場合はノードを減少させるようにする逆の処理を行う。ノードの増加・減少に関する管理には２通りあり、隣のノードから優先的に増加・減少される方法と、管理コンソール１０７からの指示による方法とがある。
【００３１】
以下に、上記の処理ノード追加／削除時におけるリソースプールの動作例の詳細について図１１及び図１２を参照しながら説明を行う。図１１は、図１０を参照しながら説明した処理ノードの追加処理の詳細な処理例を示す図である。図１１に示すように、第１の処理ノード１０４ａにおいて処理ノードの負荷が上昇すると、負荷の上昇報告１１０２が管理コンソール１０７に対して送信される。管理コンソール１０７では、負荷が上昇した第１の処理ノード１０４ａの隣のノードを新たに割り当てることを決定する（１１０５）。その結果、管理コンソール１０７で管理される、仮想的な網目構成は、符号１０４に示すように変化する。管理コンソール１０７は、この仮想的な構成を実現するために、負荷バランサ１０６に対して、処理ノードの変更（追加）要求１１０６を送信する。負荷バランサ１０６は、第２の処理ノード１０４ｂを追加するために、負荷バランスの調整を行い、第１の処理ノード１０４ａと第２の処理ノード（追加ノード）１０４ｂとのバランスを例えば５対５の均等バランスをとるように振り分ける。上記により、第１の処理ノード１０４ａと第２の処理ノード１０４ｂとで、負荷を均等に配分されることになる（１１０８）。
【００３２】
図１２は、図１０で説明した処理ノードの削減処理の詳細な例を示す図である。処理ノード１０４ａにおいて処理ノードの負荷が下降すると、負荷の下降報告１２０２が管理コンソール１０７に対して送信される。管理コンソール１０６では、負荷が下降した処理ノード１０４ａの隣のノードを解放することを決定する（１２０５）。その結果、管理コンソールで管理される、仮想的な網目構成は１２０４で示すようになる。管理コンソール１０７は、この仮想的な構成を実現するために、負荷バランサ１０６に対して処理ノードの削減要求１２０６を送信する。負荷バランサ１０６は、処理ノード１０４ｂを削除するために、負荷バランスの調整を行い、処理ノード１０４ａと１０４ｂとのバランスを１０対０に振り分ける。このようにして、処理ノード１０４ｂには全く処理要求がこなく
なり、処理は専ら処理ノード１０４ａで行われ負荷が処理ノード１０４ａに集中するようになるため、処理ノード１０４ｂを他の業務に振り分けることもできる。
【００３３】
以上に説明したように、本実施の形態によるプラグイングリッドシステムによれば、次のような効果がある。
（１）負荷の高いシステムにあっても、内部では負荷の高い部分と、負荷の低い部分がある場合に、負荷の高い部分だけを分散処理することができる。
（２）負荷の高い処理を行っている内部を、負荷分散をするグリッドシステムに対する要求、及び、処理結果の受信だけをするプラグインに置き換えるため、負荷の高いシステムのシステム改変をすることなくグリッドのメリットを享受できる。
（３）グリッドシステムの構成の管理が容易である。
（４）グリッドシステムの稼動状況を容易に知ることができる。
（５）グリッドシステムとの通信はネットワークを介して行うが、データ圧縮をすることができるため、ネットワークに対する負荷は最小限である。
（６）リソースプール内で使用する計算機リソースは自律的に判断して増減を行うようにすることもできる。このようにすると、利用者は定義づけを行う必要はない。
【産業上の利用可能性】
【００３４】
本発明は、グリッドコンピューティングシステムに利用可能である。
【図面の簡単な説明】
【００３５】
【図１】本発明の一実施の形態によるグリッドコンピューティングシステムの一構成例を示す図である。
【図２】本実施の形態によるグリッドコンピューティングシステムのプラグインの構成例を示す図である。
【図３】本実施の形態によるグリッドコンピューティングシステムのリソースプールの構成例を示す図である。
【図４】本実施の形態による管理コンソールの構成例を示す図である。
【図５】Javaをベースとした業務システムにおけるプラグインの組み込み例を示す図である。
【図６】プラグインの動作例を示す図である。
【図７】プラグインの通信方式を示す図である。
【図８】リソースプール内の処理ノードの管理方式の例を示す図である。
【図９】負荷の管理方式を示す図である。
【図１０】処理ノードの割り当て方式を示す図である。
【図１１】処理ノードの割り当て時の負荷分散方式であって追加の場合の例を示す図である。
【図１２】処理ノードの割り当て時の負荷分散方式であって削除の場合の例を示す図である。
【符号の説明】
【００３６】
１０１…業務システム、１０２…業務プログラム、１０３…プラグイン、１０４…リソースプール、１０５…処理ノード、１０６…負荷バランサ、１０７…管理コンソール、１０８…ＧＵＩ、１０９…稼動／障害レポート、２０２…業務プログラム(高負荷)、２０３…業務プログラム(低負荷)、２０５…ネットワーク、４０４…稼動／障害レポート、４０５…ＧＵＩ、４０６…コントローラ、５０２…基盤ソフト、６０３…プラグインの通信機能、６０４…プラグインが改変しない基盤ソフト、７０２…プラグインからリソースプールへの通信、７０４…リソースプールからプラグインへの通信、８０２…構成管理要求、８０４…割り当てられた処理ノード、９０２…稼動障害イベント、１００４…追加された処理ノード、１１０２…負荷上昇報告、１１０５…管理コンソールの意思決定、１１０６…構成変更要求、１１０８…処理ノード追加後の負荷の流れ、１２０２…負荷下降報告、１２０５…管理コンソールの意思決定、１２０６…構成変更要求、１２０８…処理ノード削減後の負荷の流れ。
【図１】
2008299527.tif 000003
【図２】
2008299527.tif 000004
【図３】
2008299527.tif 000005
【図４】
2008299527.tif 000006
【図５】
2008299527.tif 000007
【図６】
2008299527.tif 000008
【図７】
2008299527.tif 000009
【図８】
2008299527.tif 000010
【図９】
2008299527.tif 000011
【図１０】
2008299527.tif 000012
【図１１】
2008299527.tif 000013
【図１２】
2008299527.tif 000014