(57)【要約】【課題】システムの負荷が増大した場合にリアルタイム性を維持しながら負荷分散する。【解決手段】要求されたサービスを実行可能な複数のサーバを含む計算機システムで、サービスは、サービスの実行に必要なデータに基づいて定義されたサービスグループに属し、各サーバにサービスグループが割り当てられ、サーバの負荷が所定の上限値を超えた場合には、負荷が上限値を超えたサーバで実行されるサービスの一部を実行させる転送先サーバを選択し、負荷が上限値を超えたサーバに割り当てられたサービスグループから一以上のサービスグループを選択し、転送先サーバに選択されたサービスグループを割り当て、選択されたサービスグループに属するサービスの実行に必要なデータを負荷が上限値を超えたサーバから転送先サーバに転送する。【選択図】図１
2010134518.tif 000002
【特許請求の範囲】
【請求項１】
要求されたサービスを実行可能な複数のサーバを含む計算機システムの構成を管理する方法であって、
前記サーバは、各サーバ間を接続するインタフェースと、前記インタフェースに接続されたプロセッサと、前記サービスを提供するために必要なデータを格納する記憶部と、を備え、
前記各サーバには、同じデータを参照するサービスが割り当てられ、
前記サーバは、
前記サーバの負荷が所定の上限値を超えた場合には、前記負荷が上限値を超えたサーバで実行されるサービスの一部を実行させる転送先サーバを選択し、
前記負荷が上限値を超えたサーバに割り当てられたサービスから一以上のサービスを選択し、
前記転送先サーバに前記選択されたサービスを割り当て、
前記選択されたサービスの実行に必要なデータを前記負荷が上限値を超えたサーバから前記転送先サーバに転送することを特徴とする計算機システムの構成管理方法。
【請求項２】
前記サービスの実行要求は、前記複数のサーバにマルチキャストで送信され、
前記サービスの実行要求を受信した各サーバは、要求されたサービスを実行しない場合は、前記受信したサービスの実行要求を破棄することを特徴とする請求項１に記載の構成管理方法。
【請求項３】
前記サーバには、同じデータを参照するサービスごとにグループ化されたサービスの集合単位で前記サービスが割り当てられ、
前記サーバは、
前記サービスの集合を二つの集合に分割し、
前記分割された二つの集合のうち、一方の集合を選択し、
前記選択された集合に属するサービスを選択することを特徴とする請求項１に記載の構成管理方法。
【請求項４】
前記複数のサーバには、前記サービスを実行する第１のサーバ、及び前記第１のサーバに障害が発生した場合に前記サービスを実行する第２のサーバが含まれ、
前記第１のサーバは、前記第１のサーバに格納されたデータが更新された場合には、前記更新されたデータの差分情報を前記第２のサーバに転送し、
前記第１のサーバ又は前記第２のサーバは、前記第１のサーバの負荷が前記所定の上限値を超えたことによって、前記第１のサーバに格納されたデータを前記転送先サーバに転送する場合には、前記転送先サーバに前記差分情報をさらに転送することを特徴とする請求項１に記載の構成管理方法。
【請求項５】
前記第１のサーバは、
前記複数のサーバから、複数の転送先サーバを選択し、
前記選択された複数の転送先サーバから、前記サービスを実行する第３のサーバを選択し、
前記選択された複数の転送先サーバに含まれ、かつ、前記第３のサーバとして選択されたサーバ以外のサーバを前記第４のサーバとし、
前記第１のサーバ又は前記第２のサーバは、前記第３のサーバ及び第４のサーバに前記差分情報を転送することを特徴とする請求項４に記載の構成管理方法。
【請求項６】
前記サービスには、前記サービスの信頼性を示す信頼性レベルが設定され、
前記第１のサーバは、前記選択されたサービスに設定された信頼性レベルに基づいて、前記選択される複数の転送先サーバの数を決定することを特徴とする請求項５に記載の構成管理方法。
【請求項７】
前記差分情報は、前記複数のサーバにマルチキャストで送信され、
前記差分情報を受信した各サーバは、前記受信した差分情報を適用するデータを格納していない場合には、前記受信した差分情報を破棄することを特徴とする請求項４に記載の構成管理方法。
【請求項８】
前記サーバは、
前記サーバの負荷が所定の下限値以下になった場合には、少なくとも一つ以上のサービスが割り当てられ、かつ、前記負荷が下限値以下のサーバに割り当てられているサービスを処理していない集約先サーバを選択し、
前記負荷が下限値以下のサーバに割り当てられているサービス、及び前記集約先サーバに割り当てられているすべてのサービスを、前記負荷が下限値以下のサーバ又は前記集約先サーバのいずれか一方に割り当て、
前記サービスが割り当てられなかったサーバに対するサービスの割り当てを解除し、
前記サービスの割り当てが解除されたサーバに格納されたデータを、前記すべてのサービスが割り当てられたサーバに転送することを特徴とする請求項１に記載の構成管理方法。
【請求項９】
前記サービスには、前記サービスの信頼性を示す信頼性レベルが設定され、
前記サーバは、前記負荷が下限値以下のサーバ及び前記集約先サーバのうち、前記信頼性レベルの高いサービスが割り当てられていたサーバに、前記すべてのサービスを割り当てることを特徴とする請求項８に記載の構成管理方法。
【請求項１０】
前記サーバは、前記サービスが割り当てられていないサーバを前記転送先サーバとして選択することを特徴とする請求項１に記載の構成管理方法。
【請求項１１】
前記サーバは、前記所定の上限値の設定を受け付けることを特徴とする請求項１に記載の構成管理方法。
【請求項１２】
要求されたサービスを実行可能な複数のサーバを含む計算機システムであって、
前記サーバは、各サーバ間を接続するインタフェースと、前記インタフェースに接続されたプロセッサと、前記サービスを提供するために必要なデータを格納する記憶部と、を備え、
前記各サーバには、同じデータを参照するサービスが割り当てられ、
前記サーバは、
前記サーバの負荷が所定の上限値を超えた場合には、前記負荷が上限値を超えたサーバで実行されるサービスの一部を実行させる転送先サーバを選択し、
前記負荷が上限値を超えたサーバに割り当てられたサービスから一以上のサービスを選択し、
前記転送先サーバに前記選択されたサービスを割り当て、
前記選択されたサービスの実行に必要なデータを前記負荷が上限値を超えたサーバから前記転送先サーバに転送することを特徴とする計算機システム。
【請求項１３】
要求されたサービスを実行可能な複数のサーバを含む計算機システムに含まれるサーバで実行される構成管理プログラムであって、
前記各サーバには、同じデータを参照するサービスが割り当てられ、
前記プログラムは、
前記サーバの負荷が所定の上限値を超えた場合には、前記負荷が上限値を超えたサーバで実行されるサービスの一部を実行させる転送先サーバを選択する手順と、
前記負荷が上限値を超えたサーバに割り当てられたサービスから一以上のサービスを選択する手順と、
前記転送先サーバに前記選択されたサービスを割り当てる手順と、
前記選択されたサービスの実行に必要なデータを前記負荷が上限値を超えたサーバから前記転送先サーバに転送する手順と、を含むことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の計算機を含む計算機システムの構成を管理する技術に関する。
【背景技術】
【０００２】
クライアントからの要求に応じて、決済などの業務処理を実行するサーバシステムでは、リアルタイム性が重要である。リアルタイム性は、サーバシステムによって実行される業務処理を短時間で実行し、応答する性質である。
【０００３】
リアルタイム性を実現するためには、計算機の処理能力の向上に加え、負荷分散などによって処理効率を向上させる処理方式が必要となる。具体的には、複数のサーバでクラスタを構成し、クライアントからの要求を、複数のサーバが分担して並列処理することによって、各サーバの処理負荷を軽減するとともに、処理可能な要求量を増加させる。
【０００４】
さらに、クライアントからの要求が短時間に集中する場合にリアルタイム性を実現するためには、サーバの負荷の変動に応じて、要求を処理するサーバの割り当てを動的に変更するなどの処理が必要となる。
【０００５】
ただし、クライアントからの要求には、個別のサーバで保持されているデータにアクセスする要求が含まれる場合がある。要求を処理するサーバの割り当てを変更するためには、サーバで保持されるデータの管理、及びクライアントとサーバとの関係の管理が複雑となり、通常のクライアント及びサーバでは実現することが困難である。
【０００６】
そこで、クラスタを構成する各サーバが、クラスタ全体に割り当てられた論理ネットワークアドレスに送信されたパケットを受信し、受信したパケットのパラメータに基づいて、当該パケットの有効又は無効と選別する技術が開示されている（特許文献１参照）。特許文献１に開示された技術によれば、クライアントの改造又はネームサーバの設定を必要とせずに、論理ネットワーク宛のパケットを実際に受信するサーバを変更することができる。
【０００７】
また、クライアントがサーバに対してサービスの要求を送信する場合に、クラスタに割り当てられた仮想ネットワークアドレスに対して物理アドレス要求を送信する技術が開示されている（特許文献２参照）。特許文献２に開示された技術によれば、サーバは、各サーバの負荷情報からサーバの優先度を決定し、決定された優先度に基づいて物理アドレス要求に応答するか否かを判定する。クライアントは、物理アドレスを受信すると、受信した物理アドレスに対してサービス要求を送信する。こうすることによって、ネームサーバの設定を必要とせずに、サービスを提供するサーバを変更することが可能となる。
【特許文献１】特開２０００−１８７６３２号公報
【特許文献２】特開２００１−２１６２８２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
特許文献１に開示された技術では、パケットを受信するサーバにおいて、サーバの状態を表すパラメータ、論理ネットワークアドレス、及び送信元であるクライアントのアドレスに基づいて、パケットを破棄するか否かを選択する。しかし、個別のサーバで保持されているデータにアクセスする処理が要求された場合、パケットを受信するサーバを変更しても、変更先サーバが処理に必要なデータを保持していないため、要求を処理することができない。
【０００９】
また、特許文献２に開示された技術では、各サーバは処理負荷に基づいて決定されるサーバの優先度によってサービス要求の処理を実行するサーバを変更する。ここで、サーバが大量のデータを保有し、それらにアクセスする複数のサービスを実行する場合を考える。このとき、一部のサービスを他のサーバが処理するように変更することによって負荷分散するためには、サービスに必要なデータが変更先のサーバに格納されていなければならない。しかし、特許文献２に開示された技術では、要求を処理するために必要なデータを特定する情報を持たないため、変更先サーバにすべてのデータが格納されていなければならない。しかし、変更先サーバにすべてのデータをコピーすると、データコピーに必要な処理時間及び処理負荷が膨大になるため、この間に受信するクライアントからの要求を処理する性能が低下し、リアルタイム性を維持することが困難になる。
【課題を解決するための手段】
【００１０】
本発明の代表的な一形態によれば、要求されたサービスを実行可能な複数のサーバを含む計算機システムの構成を管理する方法であって、前記サーバは、各サーバ間を接続するインタフェースと、前記インタフェースに接続されたプロセッサと、前記サービスを提供するために必要なデータを格納する記憶部と、を備え、前記サービスは、前記サービスの実行に必要なデータに基づいて定義されたサービスグループに属し、前記各サーバには、前記サービスグループが割り当てられ、前記方法は、前記サーバの負荷が所定の上限値を超えた場合には、前記負荷が上限値を超えたサーバで実行されるサービスの一部を実行させる転送先サーバを選択し、前記負荷が上限値を超えたサーバに割り当てられたサービスグループから一以上のサービスグループを選択し、前記転送先サーバに前記選択されたサービスグループを割り当て、前記選択されたサービスグループに属するサービスの実行に必要なデータを前記負荷が上限値を超えたサーバから前記転送先サーバに転送する。
【発明の効果】
【００１１】
本発明の一形態によれば、リアルタイム性を維持しながら負荷を分散させることができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態について図面を参照しながら説明する。
【００１３】
＜第１の実施の形態＞
図１は、本発明の第１の実施の形態の計算機システムの構成の一例を示すブロック図である。
【００１４】
本発明の第１の実施の形態の計算機システムは、１台以上のクライアント１０１と、１台以上のサーバ１１０によって構成される。図１には、１以上の数字であるｍとｎを用いて、クライアント１０１をｍ台、サーバ１１０をｎ台使用して構成した例を示す。
【００１５】
クライアント１０１及びサーバ１１０は、互いに通信可能な計算機である。サーバ１１０は、クライアント１０１から要求された処理を実行する。
【００１６】
各クライアント１０１は、処理要求送信部１０２を備える。処理要求送信部１０２は、利用者によって入力された処理要求をサーバに送信する。処理要求送信部１０２は、クライアント１０１で実行されるプログラム、又は同じ機能を提供する専用ハードウェアとして実現される。
【００１７】
クライアント１０１及びサーバ１１０は、ネットワーク１０３によって接続される。ネットワーク１０３は、クライアント１０１が複数のサーバ１１０に対して送信するマルチキャスト通信を行い、さらに、複数のサーバ１１０間でデータを送受信する。
【００１８】
サーバ１１０には、状態が「実行系」であるサーバと状態が「待機系」であるサーバとが含まれる。また、状態が「実行系」であるサーバと状態が「待機系」であるサーバは同じ構成である。状態が「実行系」であるサーバは、クライアントから要求された処理を実行する。状態が「待機系」であるサーバは、状態が「実行系」であるサーバに障害が発生した場合に、状態が「実行系」であるサーバに替わって要求された処理を実行する。
【００１９】
各サーバ１１０は、処理データ管理部１１１、クラスタ情報管理部１１８及びサービス情報管理部１２１を格納する。処理データ管理部１１１、クラスタ情報管理部１１８及びサービス情報管理部１２１は、それぞれサーバ１１０上で実行されるプログラム、又は同じ機能を提供する専用ハードウェアとして実現される。
【００２０】
処理データ管理部１１１は、要求受信部１１２、処理実行部１１３、データ転送部１１４、処理データ１１５、処理要求キュー１１６、及び処理結果情報バッファ１１７を含む。
【００２１】
要求受信部１１２は、クライアント１０１から送信された処理要求電文を受信し、処理実行部１１３に処理要求電文を送信する。
【００２２】
処理実行部１１３は、要求受信部１１２から送信された処理要求電文に基づいて、要求された処理を実行する。
【００２３】
データ転送部１１４は、処理データ１１５及び処理結果情報バッファ１１７に格納された処理結果情報を他のサーバ１１０に転送する。
【００２４】
処理データ１１５は、処理実行部１１３によって実行される処理に必要なデータを格納する。また、処理データ１１５は、高速にアクセス可能な揮発性の記憶媒体（メモリ）に記憶されている。
【００２５】
処理要求キュー１１６は、クライアント１０１から送信された処理要求電文に含まれる情報を格納する。
【００２６】
処理結果情報バッファ１１７は、処理実行部１１３によって実行された処理結果を一時的に格納する。
【００２７】
クラスタ情報管理部１１８は、クラスタ情報処理部１１９及びクラスタ情報テーブル１２０を含む。
【００２８】
クラスタ情報処理部１１９は、クラスタ情報テーブル１２０を更新し、クラスタ情報テーブル１２０に格納された情報を送受信する。また、他のサーバに処理データ転送要求を送受信することによって、サーバ間のデータをコピーする。さらに、追加サーバ応答要求電文及び追加サーバ応答要求電文に対する応答を送受信する。
【００２９】
クラスタ情報テーブル１２０は、サーバ１１０が属するマルチキャストアドレス、各サーバ１１０のアドレス、及び各サーバ１１０の状態を保持する。
【００３０】
サービス情報管理部１２１は、サービス情報判断部１２２、サービス情報転送部１２３、サービス情報テーブル１２４、サービスグループ情報テーブル１２５、及び処理サービスグループＩＤ１２６及び負荷量閾値テーブル１２７を格納する。
【００３１】
サービス情報判断部１２２は、サーバの負荷の増減を検知する。
【００３２】
サービス情報転送部１２３は、サービス情報テーブル１２４、サービスグループ情報テーブル１２５及び処理サービスグループＩＤ１２６を更新し、他のサーバ１１０に情報を送受信する。
【００３３】
サービス情報テーブル１２４は、各サービスの識別子、各サービスで使用されるデータを格納するテーブルの識別子、及び各サービスの負荷量を含む。サービスグループ情報テーブル１２５は、各サービスグループの識別子、各サービスグループに属するサービスの識別子、及び各サービスグループに属するサービスの負荷量の合計を格納する。
【００３４】
処理サービスグループＩＤ１２６は、各サーバ１１０が処理するサービスグループを識別する識別子である。負荷量閾値テーブル１２７は、サービスグループの構成を変更する基準となる負荷量の閾値を格納する。
【００３５】
図２は、本発明の第１の実施の形態のサーバ１１０のハードウェア構成を示すブロック図である。
【００３６】
サーバ１１０は、前述したように、状態が「実行系」であっても「待機系」であっても同じ構成となっている。各サーバ１１０は、ＣＰＵ２１、ディスプレイ装置２２、キーボード２３、マウス２４、ネットワークインタフェースカード（ＮＩＣ）２５、ハードディスク装置２６及びメモリ２７を備える。ＣＰＵ２１、ディスプレイ装置２２、キーボード２３、マウス２４、ＮＩＣ２５、ハードディスク装置２６及びメモリ２７は、バス２８によって接続される。
【００３７】
状態が「実行系」及び「待機系」の各サーバ１１０は、ＮＩＣ２５を介してネットワークに接続し、他のサーバ１１０と相互に通信する。
【００３８】
ＣＰＵ２１は、メモリ２７に記憶されたプログラムを実行する。メモリ２７は、ＣＰＵ２１によって実行されるプログラム及び当該プログラムの実行に必要なデータを記憶する。本発明の第１の実施の形態では、メモリ２７は、揮発性記録媒体によって構成されている。
【００３９】
メモリ２７は、処理管理部１００、オペレーティングシステム３０、処理データ管理部１１１、クラスタ情報管理部１１８、サービス情報管理部１２１、処理データ１１５、処理要求キュー１１６、処理結果情報バッファ１１７、及びクラスタ情報テーブル１２０、サービス情報テーブル１２４、サービスグループ情報テーブル１２５、処理サービスグループＩＤ１２６を記憶する。
【００４０】
処理管理部１００は、オペレーティングシステム３０で実行されるプログラムである。処理データ管理部１１１、クラスタ情報管理部１１８及びサービス情報管理部１２１は、処理管理部１００によって実行されるプログラムである。処理データ管理部１１１、クラスタ情報管理部１１８及びサービス情報管理部１２１については、図１にて説明した処理を実行する。
【００４１】
処理データ１１５は、各種サービスで使用されるデータである。処理データ１１５は、データベース管理システムのような処理データ管理部１１１とは異なるアプリケーションによって管理されてもよい。この場合、データベース管理システムは、メモリ２７に記憶される。
【００４２】
処理要求キュー１１６は、図１にて説明したように、処理要求電文２００に含まれていた処理内容が格納される領域である。処理結果情報バッファ１１７は、図１にて説明したように、要求された処理の結果を一時的に格納する領域である。具体的には、待機系のサーバ１１０において、実行系のサーバ１１０から送信された処理結果を、処理データ１１５に反映させるまでの間、一時的に格納する。
【００４３】
クラスタ情報テーブル１２０は、図１にて説明したように、マルチキャストで通信する場合の送信先のサーバ１１０及び各サーバ１１０の稼働状態を格納する。サービス情報テーブル１２４は、図１にて説明したように、各サービスで使用されるテーブル及び負荷量を格納する。サービスグループ情報テーブル１２５は、図１にて説明したように、サービスグループに属するサービスを格納する。処理サービスグループＩＤ１２６は、図１にて説明したように、各サーバ１１０に割り当てられたサービスグループの識別子を保持する。
【００４４】
ディスプレイ装置２２は、サービスの処理結果などの各種情報を表示する。キーボード２３及びマウス２４は、利用者からの入力を受け付ける。ＮＩＣ２５は、ネットワークに接続するインタフェースである。ハードディスク装置２６は、メモリ２７に格納される処理データ１１５、及びメモリ２７にロードされる各種プログラムを格納する。
【００４５】
また、クライアント１０１のハードウェア構成は、図２に示したサーバ１１０のハードウェア構成と同様であって、ＣＰＵ、メモリ、ＮＩＣ及び入出力装置などを備える。なお、クライアント１０１は、仮想計算機上で実行されるプログラムによって実現されてもよい。
【００４６】
次に、本発明の第１の実施の形態における処理の概要について説明する。
【００４７】
図３は、本発明の第１の実施の形態の計算機システムの構成を変更する手順の概要を説明する図である。
【００４８】
本発明の第１の実施の形態では、サーバ１１０の負荷が増大した場合に、サービスグループ単位でサービスを分離し、他のサーバに振り分けることによって負荷を分散させる。このようにシステムを分離することによって負荷を分散させることをスケールアウトという。
【００４９】
まず、スケールアウトを実行する前の通常の処理について説明する。
【００５０】
サーバ１１０は、クライアント１０１からマルチキャストで送信されたサービス要求を受け付けると（Ｓ３４０１）、状態が「実行系」であるサーバ１１０が受け付けたサービス要求を処理する。要求されたサービスの処理が完了すると、処理されたサービスの負荷量をサービス情報テーブル１２４に記録する。要求されたサービスを処理するたびに、処理したサーバ１１０に割り当てられたサービスの負荷量の合計が負荷量閾値の上限を超えているか否かを判定する（Ｓ３４０２）。
【００５１】
サーバ１１０は、Ｓ３４０２の処理で負荷の合計が負荷量閾値の上限を超えたことを検知すると、スケールアウトを開始する。
【００５２】
サーバ１１０は、まず、使用するデータが互いに干渉しないサービスを分類し、当該サービスを分離する（Ｓ３４０３）。例えば、図３では、サービスＳ１及びＳ２と、サービスＳ３及びＳ４とでサービスを分類することができる。また、複数のサービスグループが定義されている場合には、サービスグループを選択するようにしてもよい。
【００５３】
サーバ１１０は、計算機システムに含まれているサーバからをＳ３４０３の処理で分離されたサービスを処理するための複数のサーバ１１０を選択する。このとき、選択されたサーバを状態が「追加系」であるサーバとする。さらに、分離されたサービス（Ｓ３及びＳ４）で使用されるデータを状態が「追加系」であるサーバにコピーする（Ｓ３４０４）。このとき、状態が「実行系」であるサーバ１１０でさらにサービスの処理要求を受け付ける可能性があるため、状態が「実行系」であるサーバ１１０の負荷を増大させないように、状態が「待機系」であるサーバ１１０からデータをコピーする。
【００５４】
なお、分離されたデータのコピーを実行している間に、当該分離されたデータを使用するサービスを処理した場合には、処理結果情報をマルチキャストで送信する。このとき、受信したサーバ１１０に割り当てられたサービスであれば処理結果を反映させ、そうでない場合には、受信した処理結果を破棄する。また、状態が「追加系」であるサーバ１１０でデータがコピー中の場合にはコピーが完了してから処理結果を反映させる。以上の処理によってデータの整合性を保つことができる。
【００５５】
Ｓ３４０４の処理におけるデータのコピーが完了すると（Ｓ３４０５）、状態が「追加系」である複数のサーバ１１０のうち１つを実行系に、残りを待機系とする。そして、状態が「実行系」である追加されたサーバ１１０（サーバ４）は、分離されたサービスの受け付けを開始する（Ｓ３４０６）。また、サービスが分離されたサーバ１１０（サーバ１）では、分離されたサービスＳ３及びＳ４の処理を停止する。以上の処理によって、スケールアウトが完了する。
【００５６】
次に、スケールアウト後の処理について説明する。
【００５７】
Ｓ３４０１からＳ３４０６の処理によってスケールアウトされ、システムが分離された後、クライアント１０１は、スケールアウト前と同様に、サービス要求をマルチキャストで送信する（Ｓ３４０７）。サービス要求がマルチキャストで送信されるため、クライアント１０１はサーバ１１０のスケールアウトによる影響を受けることはない。本発明の第１の実施の形態では、すべてのサーバ１１０がサービス要求を受信し、状態が「実行系」であるサーバ１１０が処理を担当するサービスの要求を受け付けた場合には当該サービスを処理し、その他の場合には受信したサービス要求を破棄する。
【００５８】
続いて、本発明の第１の実施の形態の詳細を説明する。まず、本発明の第１の実施の形態におけるテーブル及びキューの内容を、図４から図１３を参照しながら説明する。
【００５９】
図４は、本発明の第１の実施の形態の処理要求電文２００の一例を示す図である。
【００６０】
処理要求電文２００は、クライアント１０１からサーバ１１０にサービスの処理を要求する際に送信される情報である。処理要求電文２００は、サービスＩＤ２０１及び処理内容２０２を含む。
【００６１】
サービスＩＤ２０１は、クライアント１０１に処理を要求されるサービスを一意に識別する識別子である。処理内容２０２は、サービスＩＤ２０１によって識別されるサービスの処理内容を示す情報である。具体的には、サービスを処理するために必要なパラメータなどが格納される。
【００６２】
処理要求電文２００に含まれるサービスＩＤ２０１及び処理内容２０２は、受信したサーバ１１０の処理要求キュー１１６に登録される。
【００６３】
図５は、本発明の第１の実施の形態の処理要求キュー１１６の構成の一例を示す図である。
【００６４】
処理要求キュー１１６は、サーバ１１０に受信された処理要求電文２００に含まれる情報が格納される。処理要求キュー１１６は、サービスＩＤ３０１及び処理内容３０２を格納する。
【００６５】
サービスＩＤ３０１は、処理要求電文２００に含まれるサービスＩＤ２０１の値が格納される。処理内容３０２は、処理要求電文２００に含まれる処理内容２０２の値が格納される。
【００６６】
図６は、本発明の第１の実施の形態の処理結果情報４００の構成の一例を示す図である。
【００６７】
処理結果情報４００は、処理要求キュー１１６に格納された処理要求が、サーバ１１０によって処理された結果である。処理結果情報４００は、処理通番４０１、サービスＩＤ４０４、テーブルＩＤ４０２及び処理結果４０３を含む。
【００６８】
処理通番４０１は、処理要求キュー１１６に格納された処理要求が処理された場合に付与され、完了した処理を一意に識別するための識別子である。
【００６９】
サービスＩＤ４０４は、処理されたサービスの識別子である。サービスＩＤ４０４は、処理要求キュー１１６のサービスＩＤ３０１に対応する。テーブルＩＤ４０２は、サービスＩＤ４０４によって識別されるサービスを処理する際に使用されたテーブルの識別子である。
【００７０】
処理結果４０３は、サービスの処理結果が格納される。具体的には、サービスＩＤ４０４に対応するサービスで、テーブルＩＤ４０２に対応するテーブルに格納されたデータが処理された結果である。サービスによる処理では、例えば、「テーブルの更新」「テーブルの一部削除」「テーブルの一部追加」などが実行される。
【００７１】
図７は、本発明の第１の実施の形態の処理通番５００の一例を示す図である。
【００７２】
処理通番５００は、サーバ１１０でサービスが処理されるたびに加算され、実行された処理を一意に識別するために用いられる。処理通番５００は、図４に示した処理結果情報４００の処理通番４０１に格納される。
【００７３】
図８は、本発明の第１の実施の形態のクラスタ情報テーブル１２０の構成の一例を示す図である。
【００７４】
クラスタ情報テーブル１２０は、クラスタとサーバ１１０との関係を保持する。クラスタ情報テーブル１２０は、マルチキャストアドレス６０１、サーバアドレス６０２及び状態６０３を含む。
【００７５】
マルチキャストアドレス６０１は、サーバ１１０を含むクラスタで共有されるマルチキャストアドレスである。クラスタ内の複数のサーバ１１０は、マルチキャストアドレスのメンバーシップに参加していることを意味する。
【００７６】
サーバアドレス６０２は、サーバ１１０に情報を送信する際に使用されるアドレスである。サーバアドレス６０２には、各サーバ１１０で一意のアドレスが割り当てられており、例えば、ＩＰアドレスが割り当てられている。
【００７７】
状態６０３は、サーバ１１０の状態を表す。具体的には、「実行系」「待機系」「追加系」などの値が設定される。
【００７８】
図９は、本発明の第１の実施の形態のサービスグループ情報テーブル１２５の構成の一例を示す図である。
【００７９】
サービスグループ情報テーブル１２５は、サービスグループと、当該サービスグループを構成するサービスとの関連を保持する。サービスグループとは、共通のテーブルを利用して処理するサービスを負荷合計が均等になるようにグループ化したものである。なお、本発明の第１の実施の形態では、共通のテーブルを利用して処理するサービスをサービスグループと定義し、各サーバにサービスグループを割り当てるようにしているが、サービスグループとしてではなく、個々のサービスを直接各サーバに割り当てるようにしてもよい。
【００８０】
サービスグループ情報テーブル１２５は、サービスグループＩＤ７０１、サービスＩＤ７０２及び負荷合計７０３を含む。
【００８１】
サービスグループＩＤ７０１は、サービスグループを一意に識別する識別子である。サービスＩＤ７０２は、当該サービスグループを構成するサービスである。負荷合計７０３は、当該サービスグループを構成する各サービスの負荷量を合計した値である。
【００８２】
図１０は、本発明の第１の実施の形態のサービス情報テーブル１２４の構成の一例を示す図である。
【００８３】
サービス情報テーブル１２４は、サービスと当該サービスで使用されるテーブルとの関連を保持する。サービス情報テーブル１２４は、サービスＩＤ８０１、使用テーブルＩＤ８０２及び負荷量８０３を含む。
【００８４】
サービスＩＤ８０１は、サービスを一意に識別する識別子である。使用テーブルＩＤ８０２は、当該サービスによって使用されるデータを格納するテーブルの識別子である。
【００８５】
負荷量８０３は、当該サービスの処理による負荷を示す情報である。負荷量８０３は、例えば、サービス処理時のＣＰＵ利用率、メモリ使用量、入出力処理の頻度及びロック処理の頻度など、サーバ１１０から取得可能な情報に基づいて算出される。
【００８６】
図１１は、本発明の第１の実施の形態の処理サービスグループＩＤ１２６の一例を示す図である。
【００８７】
処理サービスグループＩＤ１２６は、サーバ１１０によって処理されるサービスグループの一覧である。
【００８８】
図１２は、本発明の第１の実施の形態の追加サーバ応答要求電文１０００の構成の一例を示す図である。
【００８９】
追加サーバ応答要求電文１０００は、電文種別１００１及び電文内容１００２を含む。電文種別１００１は、当該電文が「応答要求」又は「応答」のいずれかを示す情報である。電文内容１００２は、当該電文が「応答」である場合に、当該電文を送信するサーバのアドレスを格納する。
【００９０】
図１３は、本発明の第１の実施の形態の負荷量閾値テーブル１２７の構成の一例を示す図である。
【００９１】
負荷量閾値テーブル１２７は、閾値名２９０１及び負荷量２９０２を含む。
【００９２】
閾値名２９０１は、「上限値」及び「下限値」などの負荷量閾値の種類を表す。
【００９３】
負荷量２９０２は、閾値名２９０１に対応する負荷量を表す。図１３には、負荷量の「上限値」は８０、負荷量の「下限値」は１０であることを示している。
【００９４】
次に、本発明の第１の実施の形態の処理の手順について、図１４から図２０を参照しながら説明する。
【００９５】
図１４は、本発明の第１の実施の形態のクライアント１０１からの処理要求に応じてサーバ１１０で処理を実行する手順を説明する図である。
【００９６】
図１４には、クライアント１０１が、サーバ１１０Ａ及びサーバ１１０Ｂによって構成されるクラスタに処理を要求する手順が示されている。また、要求された処理では、サービスグループＩＤがＳＧ＿Ａであるサービスグループに属し、サービスＩＤがＳ１であるサービスが実行される。
【００９７】
クライアント１０１は、サービスＩＤがＳ１であるサービスが実行される処理要求電文２１１Ａをサーバ１１０に送信する（Ｓ１１０１）。処理要求電文２１１Ａは、サービスＩＤ３０１に「Ｓ１」の値を格納する。処理要求電文２１１Ａの送信先は、サーバ１１０Ａ及びサーバ１１０Ｂを含むクラスタに割り当てられたマルチキャストアドレスである。
【００９８】
サーバ１１０Ａの処理要求受信部１１２Ａは、処理要求電文２１１Ａを受信し、処理要求を処理実行部１１３Ａに送信する（Ｓ１１０２Ａ）。
【００９９】
処理実行部１１３Ａは、処理要求受信部１１２Ａから送信された処理要求に格納されたサービスＩＤ３０１及び処理内容３０２を参照する（Ｓ１１０３Ａ）。さらに、処理実行部１１３Ａは、図２０にて後述するように、受信した処理要求電文２００が処理対象である場合には要求された処理を実行し、処理対象でない場合には受信した処理要求電文２００を破棄する。
【０１００】
図１４に示す例では、サーバ１１０ＡにはサービスグループＩＤがＳＧ＿Ａのサービスグループが割り当てられ、さらに、サービスＩＤがＳ１のサービスはサービスグループＳＧ＿Ａに属しているため、受信した処理要求電文２００に基づいてサービスを処理する。処理実行部１１３Ａは、Ｓ１１０３Ａの処理において、処理要求電文２００に含まれる処理内容３０２に基づいてサービスＳ１を実行し、処理結果情報４００を作成する。
【０１０１】
処理実行部１１３Ａは、処理結果情報４００をデータ転送部１１４Ａに送信する。データ転送部１１４Ａは、クラスタ情報テーブル１２０のマルチキャストアドレス６０１を参照し、処理実行部１１３Ａによって送信された処理結果情報４００をマルチキャスト送信する。
【０１０２】
また、サーバ１１０Ｂの処理要求受信部１１２Ｂは、Ｓ１１０１の処理によって処理要求電文２００をクライアント１０１から受信すると、サーバ１１０Ａの処理要求受信部１１２ＡのＳ１１０２Ａの処理と同様に処理を実行する（Ｓ１１０２Ｂ）。なお、サーバ１１０Ｂの状態が「待機系」であるため、Ｓ１１０３Ｂの処理では、サーバ１１０Ｂによって受信された処理要求電文２００は破棄される。
【０１０３】
サーバ１１０Ｂのデータ転送部１１４Ｂは、Ｓ１１０５の処理によってサーバ１１０Ａのデータ転送部１１４Ａによって送信された処理結果情報４００を受信する（Ｓ１１０６）。そして、データ転送部１１４Ｂは、図１８にて後述するように、受信した処理結果情報４００に基づいて処理データ１１５を更新するか否かを判定する。処理データ１１５を更新する場合には、処理結果情報４００に含まれる処理結果４０３に基づいて処理データ１１５を更新し、サーバ１１０Ａの処理データ１１５と内容を同一にする。処理データ１１５を更新しない場合には、受信した処理結果情報４００を破棄する。
【０１０４】
図１４に示す例では、サーバ１１０Ｂはサーバ１１０Ａの待機系であり、同一のデータを格納するため、処理結果４０３に基づいて処理データ１１５を更新する。
【０１０５】
次に、サービスグループＩＤがＳＧ＿Ａのサービスグループに属さないサービスＩＤがＳ３のサービスの実行を含む処理要求電文２００を受信した場合について説明する。
【０１０６】
クライアント１０１は、Ｓ１１０１の処理と同様に、処理要求電文２００を送信する（Ｓ１１０７）。このとき送信された処理要求電文２００のサービスＩＤ３０１には、「Ｓ３」が設定されている。
【０１０７】
サーバ１１０Ａの処理要求受信部１１２Ａは、クライアント１０１によって送信された処理要求を受信する（Ｓ１１０８Ａ）。このとき、処理要求に含まれるサービスＩＤにＳ３が設定されており、サーバ１１０Ａに割り当てられているサービスグループＳＧ＿Ａには当該サービスが含まれていないため、受信した処理要求電文２００を破棄する。
【０１０８】
サーバ１１０Ｂの処理要求受信部１１２Ｂは、Ｓ１１０８Ａ及びＳ１１０９Ａと同様に、処理要求電文２００を受信し（Ｓ１１０８Ｂ）、Ｓ１１０３Ｂの処理と同様に、受信した処理要求電文２００を破棄する（Ｓ１１０９Ｂ）。
【０１０９】
次に、状態が「実行系」であるサーバ１１０の負荷が上限を超えたために、状態が「実行系」であるサーバ１１０を追加するスケールアウトを実行することによって、負荷分散を図る手順について説明する。
【０１１０】
図１５は、本発明の第１の実施の形態の実行系のサーバ１１０をクラスタに追加する（スケールアウト）手順を説明する図である。
【０１１１】
まず、図１５に示す処理手順を説明する前に、対象となるクラスタの構成について説明する。図１５に示すクラスタでは、状態が「実行系」であるサーバ１１０Ａ、状態が「待機系」であるサーバ１１０Ｃが同一クラスタ内に含まれ、いずれのサーバもサービスグループＳＧ＿Ａを処理する。なお、この時点ではサーバ１１０Ａで処理されるすべてのサービスがサービスグループＳＧ＿Ａに属している。
【０１１２】
続いて、状態が「実行系」であるサーバ１１０Ａにおける負荷が増加した場合に、サービスグループＳＧ＿Ａを分割してサービスグループＳＧ＿Ｂを生成し、サービスグループＳＧ＿Ｂに含まれるサービスをサーバ１１０Ｂで処理するように構成を変更する手順を説明する。
【０１１３】
状態が「実行系」であるサーバ１１０Ａのサービス情報判断部１２２Ａは、サーバ１１０Ａの負荷があらかじめ設定された閾値（上限値）を超えたことを検知すると、クラスタ情報処理部１１９Ａに通知する（Ｓ１２０１）。具体的には、サーバ１１０Ａのシステムログなどに含まれるＣＰＵ使用率、メモリ使用率及び入出力処理量などに基づいて負荷量を算出し、負荷量閾値テーブル１２７に設定されている閾値（この場合は上限値）と比較する。
【０１１４】
クラスタ情報処理部１１９Ａは、サービス情報判断部１２２Ａからの負荷が上限を超えた旨の通知を受け付けると、追加サーバ応答要求電文１０００をクラスタ内の全サーバにマルチキャストで送信する（Ｓ１２０２）。
【０１１５】
サーバ１１０Ｃは、この時点で、状態が「待機系」であって、かつ、分離前のサービスグループＳＧ＿Ａを処理する。したがって、サーバ１１０Ｃの処理サービスグループＩＤ１２６には、サービスグループＳＧ＿Ａが含まれている。
【０１１６】
サーバ１１０Ｃのクラスタ情報管理部１１８Ｃに含まれるクラスタ情報処理部１１９Ｃは、サーバ１１０Ａからマルチキャストにて送信された追加サーバ応答要求電文１０００を受信する（Ｓ１２０３）。クラスタ情報処理部１１９Ｃは、自サーバの状態が「追加系」であるサーバではないため、電文を破棄する。
【０１１７】
サーバ１１０Ｂは、マルチキャストによって送信された情報の受信が開始されている（Ｓ１２００）。また、この時点では、サービスグループＳＧ＿Ａ及びＳＧ＿Ｂを処理しない。すなわち、サーバ１１０Ｂの処理サービスグループＩＤ１２６にはサービスグループＳＧ＿Ａが含まれていない。なお、マルチキャスト通信の開始は、例えば、Ｓ１２０１の処理で負荷が閾値を超えた時点で、サーバ１１０Ｂをマルチキャストアドレスのメンバーシップに追加するようにしてもよい。このとき、計算機システムに追加用のサーバ１１０をあらかじめプールしておき、スケールアウト実行時にクラスタに追加するようにしてもよい。
【０１１８】
サーバ１１０Ｂは、サーバ１１０Ａからマルチキャストにて送信された追加サーバ応答要求電文１０００を受信する（Ｓ１２０４）。クラスタ情報処理部１１９Ｂは、Ｓ１２０４の処理において、追加サーバ応答要求電文１０００の送信元であるサーバ１１０Ａに応答を送信する。このとき、送信される応答には、自サーバ（サーバ１１０Ｂ）のアドレスが格納される。
【０１１９】
サーバ１１０Ａは、サーバ１１０Ｂから送信された応答を受信すると、受信した応答に基づいてクラスタ情報テーブル１２０を更新し、更新された情報をクラスタ内の全サーバに送信する（Ｓ１２０５）。具体的には、応答に含まれるサーバ１１０Ｂのアドレスをクラスタ情報テーブル１２０に追加し、追加されたサーバ１１０Ｂの状態を「追加系」とする。
【０１２０】
クラスタ情報を受信したサーバのクラスタ情報処理部１１９は、自サーバのクラスタ情報テーブル１２０の内容を送信されたクラスタ情報に基づいて、サーバ１１０Ａのクラスタ情報テーブル１２０と同一になるように更新する（Ｓ１２０６Ｂ及びＳ１２０６Ｃ）。クラスタ情報テーブル１２０の更新後、クラスタ情報処理部１１９は、サーバ１１０Ａにクラスタ情報更新完了を通知する。
【０１２１】
サーバ１１０Ａは、クラスタ情報を送信したすべてのサーバからクラスタ情報更新完了を通知された後、自サーバ１１０Ａのサービス情報転送部１２３Ａにサービス変更要求を送信する。
【０１２２】
このとき、図２０にて後述するように、サービス情報テーブル１２４に基づいて、サービスの実行に使用されるテーブルごとに、サービスをグループ分けする。このとき、負荷量の合計ができるだけ均等になるようにグループ分けする。そして、新たなサービスグループを定義し、サービスグループ情報テーブル１２５を更新する。本発明の第１の実施の形態では、サービスグループＳＧ＿ＡからサービスグループＳＧ＿Ｂを生成し、サービスグループ情報テーブル１２５にサービスグループＳＧ＿Ａ及びＳＧ＿Ｂに対応するレコードを登録する。
【０１２３】
なお、あらかじめサービスグループＳＧ＿Ａ及びＳＧ＿Ｂが分割された状態でサーバ１１０Ａに登録されており、サービスグループＳＧ＿Ａの負荷合計７０３とサービスグループＳＧ＿Ｂの負荷合計７０３の差が小さい場合には、新たにサービスグループを生成せずに以降の処理を実行することができる。
【０１２４】
サービス情報転送部１２３Ａは、クラスタ情報処理部１１９Ａからサービス変更要求を受信すると、サービス変更処理を実行し（Ｓ１２０７）、完了通知をクラスタ情報処理部１１９Ａに送信する。
【０１２５】
Ｓ１２０７のサービス変更処理については、図１６にて後述する。サービス変更処理が実行されると、サーバ１１０Ａ及びサーバ１１０Ｃの各処理サービスグループＩＤ１２６にはＳＧ＿Ａ及びＳＧ＿Ｂが格納され、サーバ１１０Ｂの処理サービスグループＩＤ１２６にはＳＧ＿Ｂが格納される。さらに、各サーバ１１０のサービス情報テーブル１２４には、処理サービスグループＩＤ１２６に属するサービスＩＤ８０１が格納されるように変更される。
【０１２６】
したがって、Ｓ１２０７の処理によって、サーバ１１０Ａ及びサーバ１１０Ｃのサービスグループ情報テーブル１２５、サービス情報テーブル１２４及び処理サービスグループＩＤ１２６はそれぞれ図９、図１０及び図１１に示す状態になる。また、サーバ１１０Ｂについては、それぞれ図２６、図２４及び図２８に示す状態になる。クラスタ情報処理部１１９Ａは、サービス情報転送部１２３Ａから完了通知を受信し、サーバ追加が完了する（Ｓ１２０８）。
【０１２７】
ここで、サーバ１１０Ａは、前述したサーバ追加処理（Ｓ１２０２からＳ１２０８）をあらかじめ設定された追加サーバの数だけ繰り返す。追加されるサーバの数は１つでもよいし、複数であってもよい。本発明の第１の実施の形態では、追加するサーバ数を３とし、以降の説明では３台のサーバが追加系として追加される。
【０１２８】
図１６は、本発明の第１の実施の形態のサービス変更処理（Ｓ１２０７）の手順を説明する図である。
【０１２９】
サービス変更処理は、前述のように、サービス情報管理部１２１Ａのサービス情報転送部１２３Ａによって実行される。
【０１３０】
サービス情報転送部１２３Ａは、受信したサービス変更要求に基づいて、サービス情報テーブル１２４、サービスグループ情報テーブル１２５、及び処理サービスグループＩＤ１２６を変更する（Ｓ１３０１）。
【０１３１】
次に、サービス情報転送部１２３Ａは、クラスタ内の全サーバにサービス情報テーブル１２４、サービスグループ情報テーブル１２５、処理サービスグループＩＤ１２６を送信する。このとき、同一の内容を送信してもよいし、各サーバで更新が必要な情報を選択して送信してもよい。
【０１３２】
サーバ１１０Ｂのサービス情報管理部１２１Ｂに含まれるサービス情報転送部１２３Ｂは、サービス情報転送部１２３Ａから送信されたサービス情報テーブル１２４、サービスグループ情報テーブル１２５及び処理サービスグループＩＤ１２６を受信する。そして、受信した情報に基づいて、自サーバの各テーブルを更新し、サービス情報転送部１２３Ａに完了を通知する（Ｓ１３０２Ｂ）。
【０１３３】
サーバ１１０Ｃのサービス情報管理部１２１Ｃに含まれるサービス情報転送部１２３Ｃは、Ｓ１３０２Ｂの処理と同様に自サーバの各テーブルを更新し、サービス情報転送部１２３Ａに完了を通知する（Ｓ１３０２Ｃ）。
【０１３４】
サービス情報転送部１２３Ａは、各サーバから完了通知を受信すると、サービス変更を終了する。
【０１３５】
次に、図１７を参照しながら、状態が「追加系」であるサーバに処理データを転送する手順と、処理データ転送中にサービスを処理した場合に処理結果を転送する手順について説明する。
【０１３６】
図１７は、本発明の第１の実施の形態の状態が「追加系」であるサーバに処理データを転送する手順を説明する図である。
【０１３７】
図１７に示す処理が実行される前に、前提として、図１５にて説明したサーバ追加処理が完了しており、同一クラスタ内には、状態が「実行系」であるサーバ１１０Ａ、状態が「追加系」であるサーバ１１０Ｂ及び状態が「待機系」であるサーバ１１０Ｃが含まれている。図１７では、サーバ１１０Ａ又はサーバ１１０Ｃから、サービスグループＳＧ＿Ｂに属するサービスで使用される処理データが転送される場合について説明する。
【０１３８】
サーバ１１０Ａのクラスタ情報管理部１１８Ａは、まず、状態が「待機系」であるサーバ１１０Ｃのうち１つに対し、サーバ１１０Ｂに処理データを転送させるための処理データ転送要求を送信する。なお、状態が「実行系」であるサーバ１１０Ａが処理データをサーバ１１０Ｂに転送するようにしてもよい。ただし、この場合には、サーバ１１０Ａは処理データ転送要求をサーバ１１０Ｃに送信せずに、Ｓ１４０１以降の処理はサーバ１１０Ａによって実行される。
【０１３９】
サーバ１１０Ｃのクラスタ情報管理部１１８Ｃは、クラスタ情報管理部１１８Ａによって送信された処理データ転送要求を受信し、サーバ１１０Ｃの処理データ管理部１１１Ｃに処理データ転送を指示する。
【０１４０】
サーバ１１０Ｃの処理データ管理部１１１Ｃは、処理データ転送指示を受け付けると、サーバ１１０Ｂに処理データ１１５の送信を開始する（Ｓ１４０１）。この後、サーバ１１０Ｃのステータスは、「処理データ転送中」に設定される。
【０１４１】
サーバ１１０Ｂの処理データ管理部１１１Ｂは、サーバ１１０Ｃから送信された処理データ１１５の受信を開始する（Ｓ１４０２）。この後、サーバ１１０Ｂのステータスは、「処理データ転送中」に設定される。
【０１４２】
サーバ１１０Ａの処理データ管理部１１１Ａは、クライアント１０１から送信された処理要求電文２００を受信すると、図１４のＳ１１０３Ａの処理と同様に、要求された処理を実行する。サーバ１１０Ａのクラスタ情報管理部１１８Ａは、処理結果情報４００をマルチキャストで同一クラスタ内のサーバに送信する。
【０１４３】
サーバ１１０Ｂ及びサーバ１１０Ｃは、「処理データ転送中」のステータスの場合に、処理結果情報４００をサーバ１１０Ａから受信すると、受信した処理結果情報４００を処理結果情報バッファ１１７に格納し、処理結果の反映を保留する（Ｓ１４０３）。
【０１４４】
サーバ１１０Ｂの処理データ管理部１１１Ｂは、サーバ１１０Ｃの処理データ管理部１１１Ｃから送信された処理データの受信を完了すると、サーバ１１０Ｃに処理データの受信完了を通知する（Ｓ１４０４）。
【０１４５】
サーバ１１０Ｃの処理データ管理部１１１Ｃは、処理データ管理部１１１Ｂから処理データ受信完了の通知を受信すると、処理データの送信を終了する（Ｓ１４０５）。ここで、送信した処理データをメモリ２７から削除することによって使用メモリリソースを削減するようにしてもよい。
【０１４６】
処理データ管理部１１１Ｂ及び処理データ管理部１１１Ｃは、処理データの転送が完了すると、「処理データ転送中」ステータスを解除する。「処理データ転送中」ステータスが解除されると、サーバ１１０Ｂの状態が「追加系」に、サーバ１１０Ｃの状態が「待機系」になる。さらに、図１４のＳ１１０６の処理と同様に、処理結果情報バッファ１１７に格納されている処理結果情報４００を処理データ１１５に反映させ、処理データ管理部１１１Ａに通知する（Ｓ１４０６Ｂ、Ｓ１４０６Ｃ）。
【０１４７】
サーバ１１０Ａの処理データ管理部１１１Ａは、状態が「追加系」であるサーバ１１０Ｂ、及び処理データ転送要求の送信先であるサーバ１１０Ｃから処理結果情報反映の完了通知を受信し、処理データの転送及び処理結果の反映が終了したことを確認する（Ｓ１４０８）。
【０１４８】
サーバ１１０Ａのクラスタ情報管理部１１８Ａは、クラスタ情報テーブル１２０を作成及び更新する（Ｓ１４０９）。具体的には、クラスタ情報テーブルの状態６０３を参照し、追加系とそれ以外の状態（既存の系）について、それぞれクラスタ情報テーブル１２０を作成する。作成されたクラスタ情報テーブル１２０は、既存の系については図２１、追加系については図２２に示すようになる。また、追加系のクラスタ情報テーブル１２０を作成する場合には、いずれか１つを実行系に、他を待機系に設定する。
【０１４９】
サーバ１１０Ａのクラスタ情報管理部１１８Ａは、図２１に示すようにクラスタ情報テーブル１２０を更新し、さらに作成されたクラスタ情報テーブル１２０をサーバ１１０Ｂ及びサーバ１１０Ｃに転送する。サーバ１１０Ｂは、図２２に示すようにクラスタ情報テーブル１２０を更新する（Ｓ１４１０Ｂ）。サーバ１１０Ｃは、図２１に示すようにクラスタ情報テーブル１２０に更新する（Ｓ１４１０Ｃ）。
【０１５０】
サーバ１１０Ａのクラスタ情報管理部１１８Ａは、サービス情報管理部１２１Ａのサービス情報転送部１２３Ａにサービス変更要求を送信する。
【０１５１】
サービス情報転送部１２３Ａは、図１６に示したサービス変更処理を実行し、クラスタ情報管理部１１８Ａに完了を通知する（Ｓ１４１１）。
【０１５２】
サービス変更処理では、サーバ１１０Ａ及びサーバ１１０ＣがサービスグループＳＧ＿Ａに属するサービスのみを処理するように処理サービスグループＩＤ１２６、サービス情報テーブル１２４及びサービスグループ情報テーブル１２５が変更される。
【０１５３】
具体的には、サーバ１１０Ａ及びサーバ１１０Ｃの処理サービスグループＩＤ１２６にはＳＧ＿Ａ（図２７）、サービス情報テーブル１２４にはサービスグループＳＧ＿Ａに属するサービス（図２３）、さらに、サービスグループ情報テーブル１２５にはＳＧ＿Ａ（図２５）が、それぞれ設定される。
【０１５４】
なお、サーバ１１０Ｂについては、処理サービスグループＩＤ１２６、サービス情報テーブル１２４及びサービスグループ情報テーブル１２５を変更する必要はない。このとき、サーバ１１０Ｂの処理サービスグループＩＤにはＳＧ＿Ｂ（図２８）、サービス情報テーブル１２４にはサービスグループＳＧ＿Ｂに属するサービス（図２４）、サービスグループ情報テーブル１２５にはＳＢ＿Ｂ（図２６）が設定されている。
【０１５５】
最後に、クラスタ情報管理部１１８Ａは、サービス変更の完了の通知を受信すると、サーバ１１０ＢへのサービスグループＳＧ＿Ｂの移行が完了する。
【０１５６】
ここで、以上の処理によってサービスグループＳＧ＿Ｂの移行が完了した後の処理について説明する。
【０１５７】
スケールアウト後は、クラスタ情報テーブル１２０に基づいて、各サーバ１１０は実行系及び待機系のサーバとして稼働する。実行系のサーバ１１０がクライアント１０１からの処理要求電文２００を受信すると、図１４のＳ１１０３Ａの処理で説明したように、処理対象のサービスであれば処理を実行し、処理結果情報４００をマルチキャストで他のサーバ１１０に転送する。待機系のサーバ１１０は、マルチキャスト送信された処理結果情報４００を受信すると、図１４のＳ１１０６の処理で説明したように、処理データ１１５に反映させる必要があれば、受信した処理結果情報４００に基づいて処理データ１１５を更新する。処理結果情報４００を処理データ１１５に反映させる必要がなければ、受信した処理結果情報４００を破棄する。また、実行系のサーバ１１０が受信した処理要求電文２００が処理対象のサービスでない場合には、図１４のＳ１１０８Ａの処理で説明したように、受信した処理要求電文２００を破棄する。
【０１５８】
図１８は、本発明の第１の実施の形態の処理結果情報を処理データに反映させる手順を示すフローチャートである。本処理は、図１４に示したＳ１１０６の処理に対応する。
【０１５９】
サーバ１１０のデータ転送部１１４は、処理結果情報４００を受信すると、サービス情報管理部１２１のサービス情報転送部１２３にサービスグループ情報テーブル１２５の取得を要求する（Ｓ１６０１）。Ｓ１６０１の処理で取得されたサービスグループ情報テーブル１２５を参照することによって、処理結果情報４００を受信したサーバ１１０が処理するサービスグループを特定することができる。
【０１６０】
次に、サーバ１１０の処理実行部１１３は、サービスグループ情報テーブル１２５を検索し、処理結果情報４００に含まれるサービスＩＤ４０４がサービスグループ情報テーブル１２５に含まれるサービスＩＤ７０２に一致するか否かを判定する（Ｓ１６０２）。処理結果情報４００に含まれるサービスＩＤ４０４がサービスグループ情報テーブル１２５に含まれるサービスＩＤ７０２に一致する場合には（Ｓ１６０２の結果が「Ｙｅｓ」）、処理結果情報４００に含まれる処理結果４０３を処理データ１１５に反映させる（Ｓ１６０３）。処理結果情報４００に含まれるサービスＩＤ４０４がサービスグループ情報テーブル１２５に含まれるサービスＩＤ７０２に一致しない場合には（Ｓ１６０２の結果が「Ｎｏ」）、受信した処理結果情報４００を破棄する（Ｓ１６０４）。
【０１６１】
図１９は、本発明の第１の実施の形態の処理要求電文を受信する手順を示すフローチャートである。本処理は、図１４に示したＳ１１０３Ａの処理に対応する。
【０１６２】
サーバ１１０のデータ転送部１１４は、処理要求電文２００を受信すると、サービス情報管理部１２１のサービス情報転送部１２３にサービスグループ情報テーブル１２５の取得を要求する（Ｓ１７０１）。Ｓ１７０１の処理で取得されたサービスグループ情報テーブル１２５を参照することによって、処理要求電文２００を受信したサーバ１１０が処理するサービスグループを特定することができる。
【０１６３】
次に、サーバ１１０の処理実行部１１３は、サービスグループ情報テーブル１２５を検索し、処理を要求されたサービスがサービスグループ情報テーブル１２５に含まれるか否かを判定する（Ｓ１７０２）。処理を要求されたサービスがサービスグループ情報テーブル１２５に含まれる場合には（Ｓ１７０２の結果が「Ｙｅｓ」）、受信した処理要求電文２００に基づいて要求された処理を実行する（Ｓ１７０３）。処理を要求されたサービスがサービスグループ情報テーブル１２５に含まれていない場合には（Ｓ１７０２の結果が「Ｎｏ」）、受信した処理要求電文２００を破棄する（Ｓ１７０４）。
【０１６４】
図２０は、本発明の第１の実施の形態のサービスグループ情報テーブル１２５を作成する手順を示すフローチャートである。本処理は、図１５に示したＳ１２０１の処理に対応する。
【０１６５】
サーバ１１０のサービス情報判断部１２２は、サーバ１１０の負荷が閾値を超えたことを検知すると、サービスグループ情報テーブル１２５の作成処理を実行する。まず、サービス情報テーブル１２４の使用テーブルＩＤ８０２の値が一致するサービスＩＤをまとめる（Ｓ１８０１）。Ｓ１８０１の処理によって、使用テーブルが干渉するサービス、すなわち、共通のテーブルを利用するサービスを複数のグループにまとめることができる。
【０１６６】
次に、サーバ１１０のサービス情報判断部１２２は、新たに作成するサービスグループの数だけサービスグループＩＤ７０１を作成する。作成するサービスグループＩＤの数はあらかじめ設定しておく。さらに、Ｓ１８０１の処理でまとめられたサービスを、サービスグループごとに負荷の合計が可能な限り均等になるように振り分ける（Ｓ１８０２）。例えば、まとめられたサービスの負荷量の合計が大きい順に、負荷合計７０３の小さいサービスグループに振り分ける。このようにして、サービスで使用されるテーブルが互いに干渉せず、かつ、各負荷合計７０３がより均等になるようにサービスグループ情報テーブル１２５を作成することができる。
【０１６７】
図２１は、本発明の第１の実施の形態のスケールアウト後の既存の系のクラスタ情報テーブル１２０の内容を示す図である。
【０１６８】
図２１に示すクラスタ情報テーブル１２０の構成は、図８に示したクラスタ情報テーブル１２０と同じである。また、図２１に示すクラスタ情報テーブル１２０に格納されたデータについては、図１７のＳ１４０９の処理で説明したとおりである。
【０１６９】
図２２は、本発明の第１の実施の形態のスケールアウト後の追加系のクラスタ情報テーブル１２０の内容を示す図である。
【０１７０】
図２２に示すクラスタ情報テーブル１２０の構成は、図８に示したクラスタ情報テーブル１２０と同じである。また、図２２に示すクラスタ情報テーブル１２０に格納されたデータについては、図１７のＳ１４０９の処理で説明したとおりである。
【０１７１】
図２３は、本発明の第１の実施の形態のスケールアウト後の既存の系のサービス情報テーブル１２４の内容を示す図である。
【０１７２】
図２３に示すサービス情報テーブル１２４の構成は、図１０に示したサービス情報テーブル１２４と同じである。また、図２３に示すサービス情報テーブル１２４に格納されたデータについては、図１７のＳ１４１１の処理で説明したとおりである。
【０１７３】
図２４は、本発明の第１の実施の形態のスケールアウト後の追加系のサービス情報テーブル１２４の内容を示す図である。
【０１７４】
図２４に示すサービス情報テーブル１２４の構成は、図１０に示したサービス情報テーブル１２４と同じである。また、図２４に示すサービス情報テーブル１２４に格納されたデータについては、図１７のＳ１４１１の処理で説明したとおりである。
【０１７５】
図２５は、本発明の第１の実施の形態のスケールアウト後の既存の系のサービスグループ情報テーブル１２５の内容を示す図である。
【０１７６】
図２５に示すサービスグループ情報テーブル１２５の構成は、図９に示したサービスグループ情報テーブル１２５と同じである。また、図２５に示すサービスグループ情報テーブル１２５に格納されたデータについては、図１７のＳ１４１１の処理で説明したとおりである。
【０１７７】
図２６は、本発明の第１の実施の形態のスケールアウト後の追加系のサービスグループ情報テーブル１２５の内容を示す図である。
【０１７８】
図２６に示すサービスグループ情報テーブル１２５の構成は、図９に示したサービスグループ情報テーブル１２５と同じである。また、図２６に示すサービスグループ情報テーブル１２５に格納されたデータについては、図１７のＳ１４１１の処理で説明したとおりである。
【０１７９】
図２７は、本発明の第１の実施の形態のスケールアウト後の既存の系の処理サービスグループＩＤ１２６の内容を示す図である。
【０１８０】
図２７に示す処理サービスグループＩＤ１２６の構成は、図１１に示した処理サービスグループＩＤ１２６と同じである。また、図２７に示す処理サービスグループＩＤ１２６に格納されたデータについては、図１７のＳ１４１１の処理で説明したとおりである。
【０１８１】
図２８は、本発明の第１の実施の形態のスケールアウト後の追加系の処理サービスグループＩＤ１２６の内容を示す図である。
【０１８２】
図２８に示す処理サービスグループＩＤ１２６の構成は、図１１に示した処理サービスグループＩＤ１２６と同じである。また、図２８に示す処理サービスグループＩＤ１２６に格納されたデータについては、図１７のＳ１４１１の処理で説明したとおりである。
【０１８３】
本発明の第１の実施の形態によれば、サーバ１１０が保持されるデータを引き継ぎながら、サービスを処理するサーバを分離することによって負荷分散を図ることができる。
【０１８４】
また、本発明の第１の実施の形態によれば、データを引き継ぐ際にコピーされるデータ量を最小限に抑えることでサーバの負荷の増大を抑制することによって、クライアントから要求されたサービスを、リアルタイム性を維持しながら処理することができる。
【０１８５】
さらに、本発明の第１の実施の形態によれば、クライアント１０１からサービスの処理要求がマルチキャストで送信されるため、サーバの構成が変更されてもクライアント側の設定を変更せずにサービスの処理要求を継続することができる。
【０１８６】
＜第２の実施の形態＞
本発明の第１の実施の形態では、負荷量が所定の上限値を超えたサーバ１１０で実行されるサービスを他のサーバ１１０に振り分けることによって負荷分散を図っていたが、第２の実施の形態では、負荷の少ないサーバを集約（マージ）することによって、計算機資源を有効に利用する。このようにサーバを集約することをスケールインという。
【０１８７】
なお、第２の実施の形態において、第１の実施の形態と共通する内容については適宜説明を省略する。
【０１８８】
第２の実施の形態のシステム構成は、図１及び図２に示した第１の実施の形態と同じである。また、テーブル及び電文の構成についても図４から図１２に示した第１の実施の形態と同じである。
【０１８９】
第２の実施の形態における処理の手順について説明する。なお、クライアント１０１から送信された処理要求に基づいて、サーバ１１０がサービスを実行する手順については、第１の実施の形態の図１４に示した手順と同じである。
【０１９０】
ここで、処理手順の説明する前に、第２の実施の形態の計算機システムの構成について説明すると、計算機システムには、実行系のサーバ１１０Ｄ及び待機系のサーバ１１０Ｆが同一クラスタ内に含まれ、いずれもサービスグループＳＧ＿Ａを処理する。また、同一マルチキャストアドレスを受信する実行系のサーバ１１０Ｅが当該計算機システムに含まれ、サービスグループＳＧ＿Ｂを処理する。以下、サーバ１１０Ｄの負荷が減少し、サービスグループＳＧ＿Ａの処理主体をサーバ１１０Ｅに移行する手順を、図２９を参照しながら説明する。
【０１９１】
図２９は、本発明の第２の実施の形態のスケールインを実行するための準備処理の手順を説明する図である。
【０１９２】
状態が「実行系」であるサーバ１１０Ｄのサービス情報判断部１２２Ｄは、サーバ１１０Ｄの負荷量があらかじめ設定された閾値（下限値）を下回ったことを検知すると、クラスタ情報処理部１１９Ｄに通知する（Ｓ３０１０１）。具体的には、サーバ１１０Ｄのシステムログなどに含まれるＣＰＵ使用率、メモリ使用率及び入出力処理量などに基づいて負荷量を算出し、負荷量閾値テーブル１２７に設定されている閾値（この場合は下限値）と比較する。
【０１９３】
クラスタ情報処理部１１９Ｄは、サービス情報判断部１２２Ｄから負荷量が下限値を下回った旨の通知を受信すると、マージ可否応答電文要求をマルチキャストによって送信する（Ｓ３０１０２）。マージ可否応答電文要求は、図１２の追加サーバ応答要求電文１０００と同様の構成であり、電文種別１００１を「マージ可否応答要求」とし、電文内容１００２には、自サーバ（サーバ１１０Ｄ）のアドレスが格納される。
【０１９４】
サーバ１１０Ｆは、状態が「待機系」であり、かつ、サービスグループＳＧ＿Ａを処理する。すなわち、サーバ１１０Ｆの処理サービスグループＩＤ１２６には、ＳＧ＿Ａが含まれている。
【０１９５】
サーバ１１０Ｆのクラスタ情報管理部１１８Ｆ内のクラスタ情報処理部１１９Ｆは、サーバ１１０Ｄからマルチキャストにて送信されたマージ可否応答要求電文を受信する（Ｓ３０１０３）。クラスタ情報処理部１１９Ｆは、自サーバの状態が「待機系」であるため、マージ可否応答要求電文を破棄する。
【０１９６】
また、サーバ１１０Ｅは、同一マルチキャストを受信し、かつ、サービスグループＳＧ＿Ｂを処理する。サーバ１１０Ｅの処理サービスグループＩＤ１２６には、サービスグループＳＧ＿Ｂが含まれているが、ＳＧ＿Ａは含まれていない。
【０１９７】
サーバ１１０Ｅのクラスタ情報処理部１１９Ｅは、サーバ１１０Ｄからマルチキャストにて送信されたマージ可否応答要求電文を受信すると、自サーバの状態が「実行系」であるため、マージ可否応答要求電文を送信したサーバ１１０Ｄに応答を送信する（Ｓ３０１０４）。この応答は、図１２の追加サーバ応答要求電文１０００と同様の構成であり、電文種別１００１を「マージ可能応答」とし、電文内容１００２には、自サーバの全サービスの負荷の合計量と、クラスタ情報テーブル１２０Ｅを格納する。格納されるクラスタ情報テーブル１２０Ｅは図３１に示すようになっている。
【０１９８】
図３１は、本発明の第２の実施の形態の集約先となるサーバ１１０Ｅのクラスタ情報テーブル１２０の内容を示す図である。図３１に示すクラスタ情報テーブル１２０の構成は、図８に示した第１の実施の形態のクラスタ情報テーブル１２０と同じである。
【０１９９】
サーバ１１０Ｄは、サーバ１１０Ｅから送信された応答を受信する。サーバ１１０Ｄは、複数のサーバから同様の応答を受信した場合には、応答に格納された負荷の合計が最も小さいサーバを選択する。ここでは、サーバ１１０Ｄはサーバ１１０Ｅの応答を選択した場合を想定し、以降の手順を以下に説明する。
【０２００】
サーバ１１０Ｄは、応答に含まれるクラスタ情報テーブル１２０Ｅに基づいて、サーバ１１０Ｄのクラスタ情報テーブル１２０Ｄを更新し、更新後のクラスタ情報テーブル１２０Ｄをマルチキャストアドレスに送信する（Ｓ３０１０５）。具体的には、クラスタ情報テーブル１２０Ｄに、クラスタ情報テーブル１２０Ｅに含まれるすべてのサーバアドレス６０２及び状態６０３を追加する。また、追加されたサーバ１１０Ｅの状態を「ＳＧ＿Ａ追加系かつＳＧ＿Ｂ実行系」に、それ以外の追加されたサーバの状態を「ＳＧ＿Ａ追加系かつＳＧ＿Ｂ待機系」に更新する。更新前のクラスタ情報テーブル１２０Ｄを図３０に、更新後のクラスタ情報テーブル１２０Ｅを図３２に示す。
【０２０１】
図３０は、本発明の第２の実施の形態の集約されるサーバ１１０Ｄの更新前のクラスタ情報テーブル１２０Ｄの内容を示す図である。図３０に示すクラスタ情報テーブル１２０の構成は、図８に示した第１の実施の形態のクラスタ情報テーブル１２０と同じである。
【０２０２】
図３２は、本発明の第２の実施の形態の集約されるサーバ１１０Ｅの更新前のクラスタ情報テーブル１２０Ｅの内容を示す図である。図３２に示すクラスタ情報テーブル１２０の構成は、図８に示した第１の実施の形態のクラスタ情報テーブル１２０と同じである。
【０２０３】
「ＳＧ＿Ａ追加系かつＳＧ＿Ｂ実行系」は、サービスグループＳＧ＿Ａの処理主体が当該サーバに移動中であり、かつ、当該サーバは状態が「実行系」であるサービスグループＳＧ＿Ｂの処理主体であることを意味する。また、「ＳＧ＿Ａ追加系かつＳＧ＿Ｂ待機系」は、サービスグループＳＧ＿Ａの処理主体が当該サーバに移動中であり、かつ、当該サーバは状態が「待機系」のサービスグループＳＧ＿Ｂの処理主体であることを意味する。
【０２０４】
更新後のクラスタ情報テーブル１２０Ｄを受信したサーバのクラスタ情報処理部１１９は、自サーバのクラスタ情報テーブル１２０の内容を受信したクラスタ情報テーブル１２０Ｄと同一になるように更新する（Ｓ３０１０６Ｅ、Ｓ３０１０６Ｆ）。更新後、クラスタ情報処理部１１９は、サーバ１１０Ｄにクラスタ情報更新完了を通知する。
【０２０５】
サーバ１１０Ｄは、クラスタ情報を送信したすべてのサーバからクラスタ情報更新完了を通知された後、サービス情報転送部１２３Ｄにサービス変更要求を通知する。
【０２０６】
サービス情報転送部１２３Ｄは、クラスタ情報処理部１１９Ｄからのサービス変更要求を受け付けて、サービス変更処理を実行する（Ｓ３０１０７）。サービス変更処理が完了すると、クラスタ情報処理部１１９Ｄにその旨を通知する。ここで、サービス変更処理Ｓ３０１０７では、図１６にて説明した処理に基づいて、サーバ１１０Ｄ、サーバ１１０Ｅ及びサーバ１１０Ｆの各処理サービスグループＩＤがＳＧ＿Ａ及びＳＧ＿Ｂに変更される。
【０２０７】
クラスタ情報処理部１１９Ｄは、サービス情報転送部１２３Ｄからサービス変更処理の完了を受け付けると、マージ準備処理を完了する（Ｓ３０１０８）。
【０２０８】
次に、マージ準備が終了した後に実際にサービスグループをマージする処理について説明する。マージ処理は、図１７と同様の手順であるが、クラスタを構成するサーバが相違する。この場合、同一クラスタ内に、実行系のサーバ１１０Ｄ、ＳＧ＿Ａ追加系かつＳＧ＿Ｂ実行系のサーバ１１０Ｅ、及び待機系のサーバ１１０Ｆが含まれ、サーバ１１０Ｄ又はサーバ１１０Ｆからサーバ１１０Ｅに、サービスグループＳＧ＿Ａに関連する処理データを転送する。具体的には、以下の処理が相違する。
【０２０９】
サーバ１１０Ｄのクラスタ情報管理部１１８Ｄは、Ｓ１４０９の処理で、クラスタ情報テーブル１２０Ｄを以下のように更新する。クラスタ情報テーブル１２０Ｄの状態６０３を参照し、「ＳＧ＿Ａ追加系かつＳＧ＿Ｂ実行系」又は「ＳＧ＿Ａ追加系かつＳＧ＿Ｂ待機系」のみを含むテーブルを作成する。そして、いずれか１つのサーバを実行系に、他のサーバを待機系に設定する。例えば、「ＳＧ＿Ａ追加系かつＳＧ＿Ｂ実行系」のサーバを実行系に、「ＳＧ＿Ａ追加系かつＳＧ＿Ｂ待機系」のサーバを待機系に設定すればよい。なお、クラスタ情報テーブル１２０Ｄの状態６０３が「ＳＧ＿Ａ追加系かつＳＧ＿Ｂ実行系」であって、クライアント１０１からサービスの処理要求を受け付けた場合には、サービスグループＳＧ＿Ｂに属するサービスのみを処理する。
【０２１０】
また、サービス情報転送部１２３Ｄは、図１６に示したサービス変更処理を実行し、完了を通知する。このとき、サービス変更処理では、サーバ１１０Ｄ及びサーバ１１０Ｆの各処理サービスグループＩＤ１２６を「なし」、サービス情報テーブル１２４を空行列に変更する。また、サーバ１１０Ｅの処理サービスグループＩＤにはＳＧ＿Ａ及びＳＧ＿Ｂ、サービス情報テーブル１２４にはサービスグループＳＧ＿Ａ及びＳＧ＿Ｂに属するサービスを格納するように変更する。以上の処理によって、サーバ１１０Ｄで処理されていたサービスグループＳＧ＿Ａに属するサービスのサーバ１１０Ｅへの移行が完了する。
【０２１１】
本発明の第２の実施の形態によれば、サーバ１１０の負荷が所定の下限値を下回った場合には、スケールインを実行して必要なサーバを削減することによって限られた計算機資源を有効に活用することができる。
【０２１２】
また、本発明の第２の実施の形態によれば、クライアント１０１からサービスの処理要求がマルチキャストで送信されるため、第１の実施の形態と同様に、サーバの構成が変更されてもクライアント側の設定を変更せずにサービスの処理要求を継続することができる。
【０２１３】
さらに、本発明の第２の実施の形態を第１の実施の形態とともに計算機システムに適用することによって、サーバの負荷の状態に応じて動的に構成を変更することができる。
【０２１４】
＜第３の実施の形態＞
本発明の第３の実施の形態では、サービスごとに信頼性レベルをあらかじめ設定し、設定された信頼性レベルに基づいて、スケールアウト又はスケールインの実行時のサーバの増減数を決定する。
【０２１５】
なお、第３の実施の形態において、第１の実施の形態又は第２の実施の形態と共通する内容については適宜説明を省略する。
【０２１６】
第３の実施の形態のシステム構成は、図１及び図２に示した第１の実施の形態と同じである。
【０２１７】
以下、第１の実施の形態との相違点を中心に第３の実施の形態について説明する。
【０２１８】
図３３は、本発明の第３の実施の形態のサービスグループ情報テーブル１２５の構成の一例を示す図である。
【０２１９】
サービスグループ情報テーブル１２５は、第１の実施の形態の構成に加え、最大信頼性レベル２７０４を含む。
【０２２０】
最大信頼性レベル２７０４は、サービスグループＩＤ７０１によって識別されるサービスグループに属するサービスに設定された信頼性レベルの最大値が格納される。すなわち、サービスグループごとに設定されているスケールアウト時に必要なサーバの数となる。
【０２２１】
図３４は、本発明の第３の実施の形態のサービス情報テーブル１２４の構成の一例を示す図である。
【０２２２】
サービス情報テーブル１２４は、第１の実施の形態の構成に加え、信頼性レベル２８０４を含む。信頼性レベルが１のサービスは１つの実行系のみを、信頼性レベルが２のサービスは１つの実行系と１つの待機系を、信頼性レベルが３のサービスは１つの実行系と２つの待機系をそれぞれ必要とする。
【０２２３】
次に、サーバ１１０の負荷が上限値を超えたためにシステムをスケールアウトする場合に、信頼性レベル２８０４に基づいて実行される処理について説明する。
【０２２４】
まず、図１５のＳ１２０１の処理で最大信頼性レベル２７０４ができるだけ小さくなるようにサービスをグループ分けする点である。最大信頼性レベル２７０４を小さくすることによって、追加するサーバの数を少なくすることができる。
【０２２５】
最大信頼性レベル２７０４を小さくする方法は、例えば、図２０のＳ１８０２の処理でまとめられたサービスを複数のサービスグループ情報テーブル１２５に振り分ける場合に、各サービスグループの負荷合計が同じ場合、まとめられたサービスの中で最大の信頼性レベル以上の最大信頼性レベル２７０４のサービスグループに振り分ける。
【０２２６】
さらに、図１２のＳ１２０８の処理で追加されるサーバの数は、第１の実施の形態ではあらかじめ設定されていたが、第３の実施の形態ではＳ１２０１の処理で作成したサービスグループ情報テーブル１２５の中で、一番小さい最大信頼性レベルの値分になる。第３の実施の形態では、図３３のサービスグループ情報テーブル１２５では、サービスグループＩＤ７０１、ＳＧ＿Ｂの最大信頼性レベルが一番小さく、値は２である。したがって、追加される系の数は２となる。
【０２２７】
以降、スケールアウト処理では、最大信頼性レベル２７０４が最も小さいサービスグループを、追加された系が処理するようにシステムをスケールアウトする。
【０２２８】
さらに、第２の実施の形態との相違点について説明する。
【０２２９】
データを転送する際に、マージ可否応答要求電文の応答に自サーバのサービスグループ情報テーブル１２５の最大信頼性レベル２７０４の最大値を付加する。マージ可否応答要求電文の送信元のサーバ１１０Ｄは、集約先を決定した後、さらに自サーバと決定した集約先サーバの最大信頼性レベルとを比較し、最大信頼性レベルがより小さい方をデータの転送元とする。このように処理することによって、最大信頼性レベルの大きい方にサービス及びデータが集約される。
【０２３０】
本発明の第３の実施の形態によれば、サービスごとに要求される信頼性に基づいて、追加又は削減するサーバの数を決定し、負荷状況に加えて処理されるサービスの信頼性に基づいて計算機システムの構成を変更することができる。
【図面の簡単な説明】
【０２３１】
【図１】本発明の第１の実施の形態の計算機システムの構成の一例を示すブロック図である。
【図２】本発明の第１の実施の形態のサーバのハードウェア構成を示すブロック図である。
【図３】本発明の第１の実施の形態の計算機システムの構成を管理する手順の概要を説明する図である。
【図４】本発明の第１の実施の形態の処理要求電文の一例を示す図である。
【図５】本発明の第１の実施の形態の処理要求キューの構成の一例を示す図である。
【図６】本発明の第１の実施の形態の処理結果情報の構成の一例を示す図である。
【図７】本発明の第１の実施の形態の処理通番の一例を示す図である。
【図８】本発明の第１の実施の形態のクラスタ情報テーブルの構成の一例を示す図である。
【図９】本発明の第１の実施の形態のサービスグループ情報テーブルの構成の一例を示す図である。
【図１０】本発明の第１の実施の形態のサービス情報テーブルの構成の一例を示す図である。
【図１１】本発明の第１の実施の形態の処理サービスグループＩＤの一例を示す図である。
【図１２】本発明の第１の実施の形態の追加サーバ応答要求電文の構成の一例を示す図である。
【図１３】本発明の第１の実施の形態の負荷量閾値テーブルの構成の一例を示す図である。
【図１４】本発明の第１の実施の形態のクライアントからの処理要求に応じてサーバで処理を実行する手順を説明する図である。
【図１５】本発明の第１の実施の形態の実行系のサーバをクラスタに追加する手順を説明する図である。
【図１６】本発明の第１の実施の形態のサービス変更処理の手順を説明する図である。
【図１７】本発明の第１の実施の形態の状態が「追加系」であるサーバに処理データを転送する手順を説明する図である。
【図１８】本発明の第１の実施の形態の処理結果情報を処理データに反映させる手順を示すフローチャートである。
【図１９】本発明の第１の実施の形態の処理要求電文を受信する手順を示すフローチャートである。
【図２０】本発明の第１の実施の形態のサービスグループ情報テーブルを作成する手順を示すフローチャートである。
【図２１】本発明の第１の実施の形態のスケールアウト後の既存の系のクラスタ情報テーブルの内容を示す図である。
【図２２】本発明の第１の実施の形態のスケールアウト後の追加系のクラスタ情報テーブルの内容を示す図である。
【図２３】本発明の第１の実施の形態のスケールアウト後の既存の系のサービス情報テーブルの内容を示す図である。
【図２４】本発明の第１の実施の形態のスケールアウト後の追加系のサービス情報テーブルの内容を示す図である。
【図２５】本発明の第１の実施の形態のスケールアウト後の既存の系のサービスグループ情報テーブルの内容を示す図である。
【図２６】本発明の第１の実施の形態のスケールアウト後の追加系のサービスグループ情報テーブルの内容を示す図である。
【図２７】本発明の第１の実施の形態のスケールアウト後の既存の系の処理サービスグループＩＤの内容を示す図である。
【図２８】本発明の第１の実施の形態のスケールアウト後の追加系の処理サービスグループＩＤの内容を示す図である。
【図２９】本発明の第２の実施の形態のスケールインを実行するための準備処理の手順を説明する図である。
【図３０】本発明の第２の実施の形態の集約されるサーバの更新前のクラスタ情報テーブルの内容を示す図である。
【図３１】本発明の第２の実施の形態の集約先となるサーバのクラスタ情報テーブルの内容を示す図である。
【図３２】本発明の第２の実施の形態の集約されるサーバの更新前のクラスタ情報テーブルの内容を示す図である。
【図３３】本発明の第３の実施の形態のサービスグループ情報テーブルの構成の一例を示す図である。
【図３４】本発明の第３の実施の形態のサービス情報テーブルの構成の一例を示す図である。
【符号の説明】
【０２３２】
２１  ＣＰＵ
２５  ネットワークインタフェースカード
２７  メモリ
１００  処理管理部
１０２  要求送信管理部
１１０  サーバ
１１１  処理データ管理部
１１２  処理要求受信部
１１３  処理実行部
１１４  データ転送部
１１５  処理データ
１１６  処理要求キュー
１１７  処理結果情報バッファ
１１８  クラスタ情報管理部
１１９  クラスタ情報処理部
１２０  クラスタ情報テーブル
１２１  サービス情報管理部
１２２  サービス情報判断部
１２３  サービス情報転送部
１２４  サービス情報テーブル
１２５  サービスグループ情報テーブル
１２６  処理サービスグループＩＤ
１２７  負荷量閾値テーブル
２００  処理要求電文
４００  処理結果情報
【図１】
2010134518.tif 000003
【図２】
2010134518.tif 000004
【図３】
2010134518.tif 000005
【図４】
2010134518.tif 000006
【図５】
2010134518.tif 000007
【図６】
2010134518.tif 000008
【図７】
2010134518.tif 000009
【図８】
2010134518.tif 000010
【図９】
2010134518.tif 000011
【図１０】
2010134518.tif 000012
【図１１】
2010134518.tif 000013
【図１２】
2010134518.tif 000014
【図１３】
2010134518.tif 000015
【図１４】
2010134518.tif 000016
【図１５】
2010134518.tif 000017
【図１６】
2010134518.tif 000018
【図１７】
2010134518.tif 000019
【図１８】
2010134518.tif 000020
【図１９】
2010134518.tif 000021
【図２０】
2010134518.tif 000022
【図２１】
2010134518.tif 000023
【図２２】
2010134518.tif 000024
【図２３】
2010134518.tif 000025
【図２４】
2010134518.tif 000026
【図２５】
2010134518.tif 000027
【図２６】
2010134518.tif 000028
【図２７】
2010134518.tif 000029
【図２８】
2010134518.tif 000030
【図２９】
2010134518.tif 000031
【図３０】
2010134518.tif 000032
【図３１】
2010134518.tif 000033
【図３２】
2010134518.tif 000034
【図３３】
2010134518.tif 000035
【図３４】
2010134518.tif 000036