(57)【要約】【課題】構成変更処理中のリソース不足による処理遅延を抑え、構成変更前に予測した負荷状況と実際の負荷状況の大幅なズレの発生を防止して、サービスの適切な配置を可能にする。【解決手段】負荷分散機構２０は、各サーバノードの負荷が分散するようにクライアント端末１０から受信したリクエストを複数のサーバノード間で振り分ける。構成変更機構４０は、サービスの起動又は停止に関する構成変更に際し、必要なリソース量を算定する。負荷分散機構２０は、負荷管理テーブル２００を参照して、算定されたリソース量を必要とするサーバノードについてそのリソース量を確保する。その後、構成変更機構４０は、構成変更を実行する。【選択図】図１
2007249445.tif 000002
【特許請求の範囲】
【請求項１】
サービスを提供する複数の業務プログラムが稼働するサーバノードを複数備え、各前記サーバノードの負荷が分散するようにクライアント端末から受信したリクエストを前記複数のサーバノード間で振り分けるように制御する負荷分散制御装置における負荷分散制御方法において、
前記負荷分散制御装置は、
前記サービスの起動又は停止に関する構成変更に際し、リソースの種別ごとに構成変更に必要なリソース量を設定したリソース量管理情報を参照して、必要なリソース量を算定し、
稼働中の前記サービスの識別子と前記サーバノードの識別子の各組合せに関してリソース種別ごとにリソース使用状況を記憶する負荷管理情報を参照して、算定されたリソース量を必要とする前記サーバノードについて前記構成変更の処理のために不足のリソースがあるか否か判定し、
前記不足のリソースがある場合には不足のリソース量を利用可能とした後に、前記構成変更を実行することを特徴とする負荷分散制御方法。
【請求項２】
前記構成変更は、前記不足のリソースがない場合は構成変更を実行することを特徴とする請求項１記載の負荷分散制御方法。
【請求項３】
前記構成変更は、前記サービスの起動又は停止を含む複数のパターンが設定され、各パターンに応じて必要なリソース量を算定することを特徴とする請求項１記載の負荷分散制御方法。
【請求項４】
さらに前記負荷管理情報の前記リソース使用状況を参照し、前記構成変更が必要か否かを判定し、
前記構成変更が必要な場合に対象とするサービスを決定することを特徴とする請求項１記載の負荷分散制御方法。
【請求項５】
さらに前記計算機に接続される入力装置を介して前記構成変更の指示と、対象とするサービスおよび前記パターンについての情報とを受け取るステップを有することを特徴とする請求項２記載の負荷分散制御方法。
【請求項６】
前記負荷管理情報は、前記リソース使用状況に対応してリソース種別ごとに負荷基準値を設定され、
前記不足のリソース量を確保するに際し、前記構成変更のためにリソースを必要とするサーバノードで稼働中のサービスについて前記不足のリソース量に応じて前記負荷基準値を低下させるように設定し、
前記構成変更を実行した後に、低下させた前記負荷基準値を元の値に戻すことを特徴とする請求項１記載の負荷分散制御方法。
【請求項７】
前記稼働中のサービスがそのリクエスト量のスループットとサービスの優先度に応じて前記負荷基準値の低下分を分担することを特徴とする請求項５記載の負荷分散制御方法。
【請求項８】
サービスを提供する複数の業務プログラムが稼働するサーバノードを複数備え、各前記サーバノードの負荷が分散するようにクライアント端末から受信したリクエストを前記複数のサーバノード間で振り分けるように制御する負荷分散制御装置において、
前記負荷分散制御装置は、
リソースの種別ごとに構成変更に必要なリソース量を設定するリソース量管理テーブルと、
稼働中の前記サービスの識別子と前記サーバノードの識別子の各組合せに関してリソース種別ごとにリソース使用状況を記憶する負荷管理テーブルと、
前記サービスの起動又は停止に関する構成変更に際し、前記リソース量管理テーブルを参照して必要なリソース量を算定する手段と、
前記負荷管理テーブルを参照して算定されたリソース量を必要とする前記サーバノードについて前記構成変更の処理のために不足のリソースがあるか否か判定する手段と、
前記不足のリソースがある場合には不足のリソース量を利用可能とする手段と、
前記不足のリソース量を利用可能とした後に、前記構成変更を実行する手段とを有することを特徴とする負荷分散制御装置。
【請求項９】
複数のサーバノードから構成され、前記サーバノードの各々は、サービスを提供する複数の業務プログラムが稼働するサーバノード群と、
独立した計算機として構成されるか前記サーバノードに搭載される負荷分散制御機構とを有するクラスタシステムにおいて、
前記負荷分散制御機構は、
各サーバノードの負荷が分散するようにクライアント端末から受信したリクエストを前記複数のサーバノード間で振り分ける手段と、
リソースの種別ごとに構成変更に必要なリソース量を設定するリソース量管理テーブルと、
稼働中の前記サービスの識別子と前記サーバノードの識別子の各組合せに関してリソース種別ごとにリソース使用状況を記憶する負荷管理テーブルと、
前記サービスの起動又は停止に関する構成変更に際し、前記リソース量管理テーブルを参照して必要なリソース量を算定する手段と、
前記負荷管理テーブルを参照して算定されたリソース量を必要とする前記サーバノードについて前記構成変更の処理のために不足のリソースがあるか否か判定する手段と、
前記不足のリソースがある場合には不足のリソース量を利用可能とする手段と、
前記不足のリソース量を利用可能とした後に、前記構成変更を実行する手段とを有することを特徴とするクラスタシステム。
【請求項１０】
サービスを提供する複数の業務プログラムが稼働するサーバノードを複数備え、計算機に、各サーバノードの負荷が分散するようにクライアント端末から受信したリクエストを前記複数のサーバノード間で振り分けるよう制御する機能を実現させるプログラムにおいて、
前記計算機に、
前記サービスの起動又は停止に関する構成変更に際し、リソースの種別ごとに構成変更に必要なリソース量を設定するリソース量管理情報を参照して、必要なリソース量を算定する機能、
稼働中の前記サービスの識別子と前記サーバノードの識別子の各組合せに関してリソース種別ごとにリソース使用状況を記憶する負荷管理情報を参照して、算定されたリソース量を必要とする前記サーバノードについて前記構成変更の処理のために不足のリソースがあるか否か判定する機能、および
前記不足のリソースがある場合には不足のリソース量を利用可能とした後に、前記構成変更を実行する機能を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の計算機で構成されるクラスタシステムに係わり、特に、クラスタシステムを構成するサーバノードと稼働するサービスの負荷状況に応じてサービスの配置が適切となるよう制御する負荷分散制御技術に関する。
【背景技術】
【０００２】
近年、新幹線座席予約システム、航空券予約システム、電子商取引システムなど、各種業務処理システムは、インターネットを介し、Ｗｅｂサービスとして提供されるようになってきた。そして、そのようなアプリケーション・システムが増えるにつれて利用者も増加し、これに伴ってサーバへのアクセス（即ちクライアントからの処理要求）が集中するという問題が生じている。ここで、このような問題が生じると、サーバの負荷が急激に高くなるので、処理速度の低下や最悪の場合はシステムの異常停止という不都合が生じてしまう。
【０００３】
この問題を回避するため、複数の計算機（例えばサーバ計算機）で構成される計算機システムを管理し、アプリケーションプログラムを実行することによりクライアント（ユーザ）に提供するサービスの処理性能及び信頼性を高めるクラスタシステムと呼ばれるソフトウェア技術がある。クラスタシステムは、計算機の起動時や障害発生，負荷状況の変動に対応して、計算機システム上で稼働するサービスを最適な計算機にスケジュールするなどの機能を有し、可用性の向上や負荷分散を実現する。
【０００４】
なおクラスタシステムに関連する技術として、特許文献１、特許文献２、特許文献３および特許文献４に開示される技術がある。
【０００５】
【特許文献１】特開２００２−１６３２４１号公報
【特許文献２】特開２００５−３１７３６  号公報
【特許文献３】特開２００５−１００３８７号公報
【特許文献４】特開２００５−１３５１２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１では、使用されるか否かが明らかでない予備のサーバを予め用意しておく必要があるので、システムの構築や維持、管理に必要以上の費用が発生してしまう問題がある。これを解決すべく特許文献２ではサービスへの負荷状況を判定し、特定のサービス以外のサービスが稼働しているサーバの稼働サービスを特定サービスに切り替えるなどの構成変更を行うことによって上記の問題を解決する。更に、特許文献３では、サービスのポリシー管理（優先度、サービスの関係（排他、依存）等）により、サービスの最適配置後の動的な負荷状況の変化等などのサービスにおける実行状況に応じたサービスの最適な構成変更を、確実に行うことが可能なクラスタシステムを実現している。
【０００７】
しかしながら、上記従来技術は、サービスの最適配置を行う際の構成変更処理自体がサーバノードにかける負荷を考慮していない。このため、サーバノードに構成変更処理の負荷が加わることにより、以下の課題が発生する可能性がある。
【０００８】
（１）構成変更処理の負荷により、構成変更処理が完了する時間が予定時間より間延びすることにより、構成変更が完了した時点での負荷状態は、構成変更要と判断した時に予測した負荷状態と大幅なズレが発生していることが予想される。つまり、構成変更後のサービス配置が既に最適な配置となっていないことがあり得る。
【０００９】
（２）構成変更処理の負荷により、それまで負荷分散制御により均衡を保っていた負荷バランスが崩れ、そのためにクライアントへのサービス処理の遅延が発生し、サービス品質に影響を与えることがあり得る。
【課題を解決するための手段】
【００１０】
本発明は、サービスを提供する複数の業務プログラムが複数のサーバノード上で稼働するクラスタシステムに関し、各サーバノードの負荷が分散するようにクライアント端末から受信したリクエストを前記複数のサーバノード間で振り分ける負荷分散制御技術に関するものである。
【００１１】
本発明の負荷分散制御を行う計算機は、サービスの起動又は停止に関する構成変更に際し、必要なリソース量を算定し、算定されたリソース量を必要とするサーバノードについて構成変更の処理のために不足のリソースがあるか否か判定し、不足のリソースがある場合には不足のリソース量を確保した後に、構成変更を実行する。
【００１２】
上記の負荷分散制御を行う計算機は、稼働中のサービスの識別子とサーバノードの識別子の各組合せに関してリソース種別ごとにリソース使用状況を記憶する負荷管理情報を保持する。この負荷管理情報は、リソース使用状況に対応してリソース種別ごとに負荷基準値を設定してもよい。負荷分散制御を行う計算機は、不足のリソース量を確保するに際し、構成変更のためにリソースを必要とするサーバノードで稼働中のサービスについて、不足のリソース量に応じて負荷基準値を低下させるように設定し、構成変更を実行した後に、低下させた負荷基準値を元の値に戻す。
【００１３】
本発明の実施形態によれば、稼働中のサービスがそのリクエスト量のスループットとサービスの優先度に応じて負荷基準値の低下分を分担する。
【００１４】
また本発明の実施形態によれば、負荷分散制御計算機は、負荷分散機構と構成変更機構とに分離される。負荷分散機構は、各サーバノードが実行する複数のサービスのうち、各サービスの負荷基準値と、各サービスの負荷状況とを比較し、クライアントからのリクエストの割当て先として、最適なサービスを決定するとともに、サーバノード上のサービスの配置が最適となるように、対象となるサーバノードに対して構成変更指示を発行する。構成変更機構は、負荷分散機構からの構成変更指示により、対象とするサービスの構成変更処理を実行する。構成変更機構は、構成変更に必要なリソース量（ＣＰＵ、メモリ、ディスクの使用量などが含まれる）を算定し、算定されたリソース量を負荷分散機構に通知する。負荷分散機構は、必要なリソース量情報を受け付け、サービスの優先度等に従って、一時的に、各サービスの負荷基準値の閾値を変更する。
【発明の効果】
【００１５】
本発明のクラスタシステムによれば、構成変更処理のリソース不足による処理遅延を削減することができ、構成変更処理の速やかな実行が可能となる。
【００１６】
また構成変更処理の遅延を抑えることによって、構成変更が必要と判断した時に予測した負荷状態と実際の負荷状態との大幅なズレの発生を防止でき、処理完了時に、予測したサービスの適切な配置の実現が可能となる。
【００１７】
また、本発明の実施形態によれば、構成変更処理に必要なリソース量を予め算定し、構成変更処理実行中に稼働中のサービスがそのリクエスト量のスループットとサービスの優先度に応じて必要なリソース量を分担して負担するように負荷基準値を低下させることによって、構成変更処理実行中においてもそれまでの負荷バランスを保つことができ、クライアントへの安定したサービスの提供が可能となる。
【発明を実施するための最良の形態】
【００１８】
本発明に係るクラスタシステムの一実施形態について図面を用いて説明する。
【００１９】
図１は、本実施形態に係るクラスタシステムの全体構成を示す図である。本クラスタシステムは、クライアント端末１０，負荷分散機構２０，サーバノード３０−１，３０−２，・・・、および構成変更機構４０を備えている。クライアント端末１０は、ネットワーク０を介して負荷分散機構２０と通信可能であり、それ以外の装置は、ネットワーク１によって相互通信が可能な構成となっている。
【００２０】
各サーバノードは、ＣＰＵ２、メモリ３およびディスク装置４から構成されるノイマン型の計算機システムである。図でサービスＡ，Ｂ，Ｐ，Ｑ，Ｒ，Ｓとあるのは、各々のサービスを提供する業務プログラムであり、これら業務プログラムは、各サーバノードに搭載されるサーバプログラム３の管理下で実行される。サーバプログラムとしては、ＯＬＴＰ（Online Transaction Processing）やＪ２ＥＥ（Java2 Platform, Enterprise Edition:サンマイクロシステムズ社の登録商標）サーバなどのアプリケーションサーバが用いられる。サーバプログラムや業務プログラムは、予めディスク装置４などの外部記憶装置に保存されており、適宜メモリ３にロードしてＣＰＵ２により実行される。なお本明細書では、いずれかの機構又は装置を指すときは、符号の添数字を省略する。
【００２１】
クライアント端末１０は、ウェブブラウザ又はウェブサーバを搭載しており、インターネット等のネットワーク０を介してサーバノード３０にアクセスし、サービスを要求する計算機である。クライアント１０が要求するサービスとしては、例えば、テキスト、画像、音楽等の各種コンテンツの閲覧、商品の注文やチケットの予約、銀行口座残高の移動等を挙げることができる。
【００２２】
負荷分散機構２０は、負荷管理テーブル２００、構成変更指示部２１、負荷基準値変更部２２およびリクエスト振り分け部２３を備える計算機である。負荷分散機構２０は、ＣＰＵ、メモリおよびその他の記憶装置を備える。負荷管理テーブル２００は、記憶装置に格納され、各サービスごとにサーバノードの現在のリソース使用状況を示す情報と、負荷基準値を格納する。構成変更指示部２１、負荷基準値変更部２２およびリクエスト振り分け部２３は、メモリに格納されるプログラムであり、ＣＰＵにより実行される。
【００２３】
リクエスト振り分け部２３は、各クライアント端末１０からのリクエストを受け付け、負荷管理テーブル２００を参照し、各サーバノード３０の負荷がほぼ均等にバランスするように、いずれかのサーバノード３０上で稼働中のサービスに振り分ける。またあるサービスのリソース使用状況がその負荷基準値を上回った場合、リクエスト振り分け部２３は、同一サービスが稼働する他のサーバノード３０にそのリクエストを振り分ける。決定されたサービスノード３０上のアクセス先アドレスは、例えば、ネーミングサービスであるＪＮＤＩ（Java Naming and Directory Interface:サンマイクロシステムズ社の登録商標）によるアクセス先検索を利用して指定される。図１で実線の矢印はリクエストの流れを示し、点線の矢印は制御の流れを示す。
【００２４】
構成変更指示部２１は、負荷管理テーブル２００を参照し、各サービスの負荷基準値とリソース使用状況からサービスに関する構成変更が必要か否かを判定する。構成変更が必要と判定したとき、構成変更指示部２１は、構成変更機構４０に対して構成変更の指示を行う。
【００２５】
負荷基準値変更部２２は、構成変更などに伴い、負荷管理テーブル２００中の負荷基準値を変更する。
【００２６】
負荷分散機構２０は、いずれかのサーバノード３０に搭載されてもよく、サーバノード３０から独立したサーバ計算機として存在してもよい。
【００２７】
構成変更機構４０は、リソース量管理テーブル１００、リソース量算定部４１、リソース量情報通知部４２および構成変更部４３を有する計算機である。構成変更機構４０は、ＣＰＵ、メモリ、その他の記憶装置、入力装置および表示装置を備える。リソース量管理テーブル１００は、記憶装置に格納され、構成変更などに必要なリソース量についての情報を格納する。リソース量算定部４１、リソース量情報通知部４２および構成変更部４３は、メモリに格納されるプログラムであり、ＣＰＵにより実行される。
【００２８】
構成変更部４３は、負荷分散機構２０によって構成変更に必要なリソースが確保された後に、対象とするサーバノード３０に対してサービスの起動、停止などサービスに関する構成変更を指示する。各サーバノード３０には、指定されたサービスの構成を変更するためのプログラムが組み込まれており、指示に従って構成変更を実行する。
【００２９】
リソース量算定部４１は、負荷分散機構２０又は入力装置からの運用コマンドにより構成変更要求を受け付け、リソース量管理テーブル１００を参照して指示された構成変更処理に必要なリソース量を算定する。リソース量情報通知部４２は、算出したリソース量を負荷分散機構２０に通知する。
【００３０】
構成変更機構４０は、各サーバノード３０に搭載されてもよく、サーバノード３０から独立したサーバ計算機として存在してもよい。構成変更機構４０がサーバノード３０に搭載される場合には、サーバノード３０のＣＰＵ、メモリ、その他の記憶装置、入力装置および表示装置を利用する。構成変更機構４０が独立したサーバ計算機の場合に、負荷分散機構２０と共存してあるいは一体となった負荷分散制御機構として１台のサーバ計算機に搭載されてもよい。
【００３１】
サーバノード３０へ送られる処理要求（リクエスト）は、負荷分散機構２０を経由するものと、しないものがある。負荷分散機構２０を経由する処理要求としては、クライアントから送られるリクエストがある。負荷分散機構２０を経由しない処理要求として、構成変更機構４０から送られる構成変更の指示がある。また、運用計算機（図示していない）からサーバノード３０へ送られる運用要求などもあり得る。従って、本実施例では、負荷分散機構２０を経由する処理要求と負荷分散機構２０を経由しない処理要求について、各サーバノード３０の負荷を制御し、負荷をバランスさせることが可能となる。
【００３２】
次に、負荷分散機構２０および構成変更機構４０の処理手順の概略について図２のフローチャートを参照して説明する。
【００３３】
先ず、構成変更指示部２１は、負荷管理テーブル２００を参照し、構成変更が必要なサービスがあるか否かを判定する。対象とするサービスが決定された場合に、構成変更のパターンを決定する（ＳＴ−１）。構成変更のパターンとして、例えば以下の様な変更が挙げられる。
（１）サーバノード３０−１上のサービスＡを、サービスＢに置き換える。
（２）サーバノード３０−１上にサービスＡを追加する。
（３）サーバノード３０−１上のサービスＡを停止する。
（４）サーバノード３０−１上のサービスＡを、サーバノード３０−２上にスイッチオーバする。
（５）サーバノード３０−１上のサービスＡの多重度を変更する。
例えば、サーバノード３０−１上のサービスＡに対するリクエスト量が減少し、他のサーバノード３０上のサービスＢのリクエスト量が増加する傾向がある場合に、パターン１の構成変更の必要が生じる。
【００３４】
次に、構成変更指示部２１は、構成変更機構４０に対して行う構成変更を指示する（ＳＴ−２）。本発明に係る構成変更指示は、パターン１〜５の様な構成変更のパターンを情報として含む。
【００３５】
図３は、構成変更指示情報７０のフォーマットの例を示す。本例の構成変更指示情報７０は、構成変更対象７１、構成変更パターン７２、構成変更パターンパラメタ１（７３）、構成変更パターンパラメタ２（７４）などの項目から構成される。
【００３６】
例えば、パターン１の場合は、構成変更対象７１がサーバノード３０−１上で稼働する“サービスＡ／サーバノード１”であり、構成変更パターン７２に“サービス入替え”、更に、入れ替える先のサービス名を、構成変更パターンパラメタ１（７３）として、“サービスＢ”と設定し、構成変更パターンパラメタ２（７４）として“サービスＢ”の多重度数を格納している。パターン２，３の場合は、構成変更パターン７２に“サービス追加”又は“サービス停止”が設定される。パターン４の場合は、構成変更パターン７２に、“系切り替え”、構成変更パターンパラメタ１（７３）として、移動先のサーバノード名を格納する。パターン５の場合は、構成変更パターン７２に“多重度変更（増／減）”、構成変更パターンパラメタ１（７３）に、増又は減分の多重度数を格納する。
【００３７】
リソース量算定部４１は、この構成変更指示を受け付け（ＳＴ−１１）、リソース量管理テーブル１００を参照し、指定された構成変更のパターンから、構成変更に必要なリソース量を算定する（ＳＴ−１２）。その詳細手順については後述する。次にリソース量情報通知部４２は、確保すべきリソース量についての算定結果情報を負荷分散機構２０に通知する（ＳＴ−１３）。
【００３８】
負荷基準値変更部２２は、このリソース算定結果情報を受け付け（ＳＴ−３）、構成変更を実行するサーバノード３０のリソースを確保するため、負荷基準値の変更を行う対象サービスを選定し、対象サービスについて新しい負荷基準値を算出する（ＳＴ−４）。負荷基準値変更部２２は、リソースを確保するサーバノードの各々についてＳＴ−４の処理を繰り返す。ＳＴ−４の詳細手順については後述する。
【００３９】
次に負荷基準値変更部２２は、ＳＴ−４で算出した対象サービスの新しい負荷基準値に従って負荷管理テーブル２００の該当する負荷基準値を変更する（ＳＴ−５）。次に負荷基準値変更部２２は、負荷基準値を変更することによって構成変更に必要なリソース量を確保した旨を構成変更機構４０に通知する（ＳＴ−６）。なお負荷基準値を変更してから構成変更のために対象とするサーバノードの空きリソースが確保されるまである程度の遅延が生じる可能性がある。このため、負荷基準値変更部２２は、一定時間待った後に、構成変更機構４０にリソース確保を通知してもよい。
【００４０】
構成変更部４３は、このリソース確保通知を受け付け（ＳＴ−１４）、ＳＴ−１１で受信した構成変更パターンに従ってサービスに関する構成変更を実行する（ＳＴ−１５）。構成変更機構４０は、構成変更を実行するためのコマンドのリストを保持し、該当するコマンドを対象とするサーバノード３０に送信する。例えば、パターン４の構成変更の場合に、一般のクラスタソフトが提供する計画切り替えコマンドを使用してもよい。構成変更の実行が完了すると、構成変更部４３は、その旨を負荷分散機構２０に通知する（ＳＴ−１６）。
【００４１】
負荷基準値変更部２２は、この通知を受け付け（ＳＴ−７）、負荷管理テーブル２００を参照し、ＳＴ−５で変更した負荷基準値を変更前の負荷基準値に戻す（ＳＴ−８）。なお負荷分散機構２０は、ＳＴ−２からＳＴ−８までの処理中は、次の構成変更の処理を開始しない。
【００４２】
図４は、リソース量管理テーブル１００のデータ構成例を示す図である。サービス識別子１０５は、サービス名とサービスノード名の組合せに対して付与された識別子である。多重度１０６は、稼働中のサービスの多重度である。多重度は、同一サービスについて実行中のプロセスの数であり、並行して処理されるリクエストの数に相当する。稼働中フラグ１０７は、そのサービスが稼働中（ＯＮ）か否（ＯＦＦ）かを示すフラグである。サービス名／ノード名１１０は、サービス名とそのサービスが稼働するサーバノードのサーバノード名の組合せを示す。サービス起動１２０は、そのサービスを起動するに必要なリソースの量をリソースの種別ごとに設定する。なおディスクの使用量は、記憶容量の代わりに利用率でもよい。他のディスク使用量についても同様である。サービス停止１３０は、そのサービスを停止するに必要なリソースの量を設定する。１多重度あたりの構成変更に必要なリソース量１４０は、サービスの起動／停止の際に１多重度について必要なリソース量である。
【００４３】
連携用リソース１５０は、構成変更の際に他のサーバノードと連携する処理が加わる場合に、連携先のサービス識別子１０５と、その処理に必要なリソース量を設定する。例えば、新たに起動するサービスが同一サービスを稼働する他のサーバノードのセッション情報などのメモリ上の情報を引き継ぐ場合や、セッション情報を二重化する場合に追加のリソース量が必要となる。ここでセッションとは、クライアント端末１０と稼働中のサービスとの間に確立されたセッションである。セッション情報の二重化は、フェイルオーバー時の対策として他サーバノードにもセッション情報をもたせることを意味する。このとき、あるサーバノード３０上でサービスを起動するとき、そのサービスの業務プログラムは、他のサーバノード３０上の同一サービスを行う業務プログラムとの間でセッションを確立する必要がある。連携用リソース１５０は、このサービス間のセッションを確立するために必要なリソースである。
【００４４】
図５は、リソース量算定結果情報８０のデータ構成例を示す図である。リソース量算定結果情報８０は、構成変更対象のサーバノード３０の構成変更に必要なリソース量（ＣＰＵ利用率、メモリ使用量、ディスク使用量）、構成変更機構４０がＳＴ−１１で受信した構成変更指示情報７０、および連携先のサーバノード３０に必要なリソース量（ＣＰＵ利用率、メモリ使用量、ディスク使用量）を含む。構成変更指示情報７０は、入力装置からのコマンド入力により、ＳＴ−１１から処理を開始する場合に必要になる情報である。
【００４５】
図６は、パターン１の構成変更に必要なリソース量の算定（ＳＴ−１２）の処理手順の詳細を示すフローチャートである。
【００４６】
リソース算定部４１は、まず構成変更指示情報７０の構成変更対象７１に関するリソース量を算定する（ＳＴ−３００）。すなわちリソース算定部４１は、構成変更対象７１に格納されているサービス名／サービスノード名をキーにリソース量管理テーブル１００を検索して該当するサービス／サーバノードのサービス停止の値を取得し、基礎リソース量（Resource_B_A）とする。ｍｅｍは、メモリの略である。またリソース量管理テーブル１００の多重度と“１多重度当りの構成変更に必要なリソース量”を掛け合わせることによって、停止するサービスに関する多重度依存のリソース量(Resource_M_A)を算出する。
【００４７】
次にリソース算定部４１は、構成変更指示情報７０の構成変更パラメタ１（７３）に関するリソース量を算定する（ＳＴ−３１０）。すなわちリソース算定部４１は、構成変更パラメタ１（７３）に格納されているサービス名と当該サーバノード名をキーにリソース量管理テーブル１００を検索して該当するサービス／サーバノードのサービス起動の値を取得し、基礎リソース量(Resource_B_B)とする。また構成変更指示情報７０の構成変更パラメタ２（７４）に格納されている多重度と、リソース量管理テーブル１００の当該サービス／サーバノードの“１多重度当りの構成変更に必要なリソース量”１４０を掛け合わせて起動するサービスに関する多重度依存のリソース量（Resource_M_B）を算出する。さらに起動するサービス／サーバノードが連携用リソースを必要とする場合に、リソース量管理テーブル１００から当該サービス／サーバノードの“連携用リソース量”を取得し、連携用リソース量（Resource_C_B）とする。
【００４８】
次にリソース算定部４１は、構成変更対象のサーバノード３０に関する要求リソース量を算出する（ＳＴ−３２０）。要求リソース量(Resource_D)は、構成変更対象７１に関するリソース量合計(Resource_B_A+Resource_M_A)と、構成変更パラメタ１（７３）に関するリソース量合計(Resource_B_B+Resource_M_B+Resource_C_B)のいずれか大きい方の値である。サービス停止とサービス起動はシリアルに実行されるため、要求リソース量は、いずれか大きい方の値をとればよい。
【００４９】
次にリソース算定部４１は、起動するサービス／連携先サーバノードが連携用リソースを必要とする場合に、そのサービス／サーバノードについてリソース量管理テーブル１００から“連携用リソース量”を取得し、連携先の連携用リソース量（Resource_C）とする（ＳＴ−３３０）。
【００５０】
次にリソース算定部４１は、ＳＴ−３２０とＳＴ−３３０の算出結果からリソース量算定結果情報８０を作成する（ＳＴ−３４０）。
【００５１】
図４に示すリソース量管理テーブル１００のデータ例を用いてＳＴ−３００とＳＴ−３１０の計算をすると、その結果は図７に示す値となる。
【００５２】
図７のデータにＳＴ−３２０を適用すると、その結果は、次の通りとなる。
・ＣＰＵ利用率：３０（％）
・メモリ使用量：５０ＭＢ
・ディスク使用量：１０ＭＢ
またＳＴ−３３０の処理結果は、次の通りとなる。
ＣＰＵ利用率：２（％）
メモリ使用量：１ＭＢ
ディスク使用量：１ＭＢ
なお構成変更のパターン２の場合には、サービスＡについて図７のＳＴ−３１０のみ計算すればよく、パターン３の場合には、サービスＡについてＳＴ−３００のみ計算したものが要求リソース量となる。
【００５３】
またパターン４の場合には、サーバノード３０−１についてＳＴ−３００のリソース量合計、サーバノード３０−２についてＳＴ−３１０のリソース量合計が各々、要求リソース量となる。さらにサーバノード３０−２には、ＳＴ−３３０の連携用リソース量が加わる。なおパターン４の場合には、サーバノード３０−１とサーバノード３０−２の両ノードで同時にサービスＡが稼働する２重オンラインが生じてはならない。一般のクラスタソフトが提供しているサービスの計画切替コマンドを使用することにより、２重オンラインを回避できる。
【００５４】
パターン５の場合には、多重度の増加分についてＳＴ−３１０の（ｂ）を適用し、減少分についてＳＴ−３００の（ｂ）を適用して要求リソース量を算出すればよい。
【００５５】
なお上述したように、構成変更機構４０又は構成変更機構４０が搭載されるサーバノード３０の入力装置から構成変更コマンドを入力することができる。このコマンドは、構成変更指示情報７０を含む。オペレータによりこのコマンドが入力されると、構成変更機構４０は、ＳＴ−１１から処理を開始する。その後の処理手順は、図２に示す通りである。
【００５６】
図８は、負荷管理テーブル２００のデータ構成例を示す図である。サービス名２１０はサービスの識別子、優先度２１１はそのサービスの優先度である。リクエスト量２１２は、リクエスト件数／秒であり、各サーバノード３０上で稼働中のサービスの現在のスループットを格納する。リソース使用状況２１３は、そのサービスの現在のリソース使用状況を示し、負荷基準値２１４は、そのサービスの負荷基準値である。リソース確保中フラグ２１５は、構成変更のリソースを確保するために、そのサービスについて負荷基準値を変更するＳＴ−４の処理を実行中である（１）か否か（０）を示すフラグである。
【００５７】
図８の負荷管理テーブル２００によれば、構成変更を実施するサーバノードでは、サービスＰ〜サービスＳが稼働している。優先度２１１は、１が一番優先度が高く、数値が増えるに従い優先度が低くなっていくものとする。このため、次の様にサービスＲの優先順位が一番低い。
優先順位：サービスＰ＞サービスＱ＞サービスＳ＞サービスＲ
優先順位のみに従えば、サービスＲの負荷基準値を変更すべきであるが、現在のリクエスト量（スループット  件／秒）が一番多く、この時間帯でサービスＲが繁忙期であることがわかる。このため、単純に優先度のみで対象サービスを決定し、その負荷基準値を下げ、従ってリクエスト量を低下させると、クライアント端末１０に対するサービスの提供品質の確保という観点では問題が生じる可能性がある（ただし、業務スケジュール、繁忙期となる時刻に合わせて、各サービスの優先度と負荷基準値を、時間帯によって変更する機能があるのであれば、優先度のみを因子にして、負荷基準値を変更する対象サービスを決定しても、クライアント１０への影響は少ない場合がある）。
【００５８】
このため、構成変更に必要なリソース確保の一つの例として、リクエスト量と優先度をもとに、要求リソース量のうち各サービスが確保する必要のある割合を算出して、各サービスの確保すべきリソース量を算出し、構成変更を実施するサーバノード上で稼働中のサービス全体からリソース確保を行う方法をとることができる。
【００５９】
図９は、図２の処理ステップＳＴ−４の処理手順の詳細を示すフローチャートである。
【００６０】
まず、負荷基準値変更部２２は、構成変更対象のサーバノードの構成変更に必要なリソース量のうち、実際に各サービスの負荷基準値の変更により確保する必要のあるリソース量を求める（ＳＴ−４０）。
・不足分要求リソース量（ＲＤ）＝必要なリソース量−（使用可能最大リソース量−構成変更対象外サービスの使用中リソース量）＋（予測リソース使用量）
上式の“使用可能最大リソース量”は、当該サーバノードで、稼働するサービスに割り当てることのできるリソース量である。例えばＣＰＵ利用率であれば、その内、ＯＳなどのシステムが使用する分を差し引いた値となる。
【００６１】
“使用可能最大リソース量”から、“構成変更対象外サービスの使用中リソース量”を差し引き、更に“予測リソース使用量”を加算し、空き状態にあるサーバノード上のリソースで賄えない分のリソース量を“不足分要求リソース量（ＲＤ）”として算出する。
【００６２】
“構成変更対象外サービスの使用中リソース量”は、構成変更の対象となる稼働中サービスＡが使用中のリソース量を省いた値となる。例えば、図８の負荷管理テーブル２００に示すように、サービスＰ〜サービスＳの各々の使用中リソース量の総計となる。
・ＣＰＵ：９０（％）
・メモリ：７１（ＭＢ）
・ディスク：４７（ＭＢ）
“予測リソース使用量”は、例えば、統計的に、構成変更処理中に使用が予測されるリソース量である。構成変更処理中にクライアントからのリクエストが突如増加し、確保したリソース量では賄えない状況を避けるための余裕値である。予測リソース使用量の代わりにＳＴ−１２で必要なリソース量に余裕分を加えておいてもよい。
【００６３】
“不足分要求リソース量（ＲＤ）”が、０以下であれば、負荷基準値変更部２２は、空き状態にあるリソース量で対応できるものと判断して、当該リソースの確保については、負荷基準値を変更する必要はない（ＳＴ−４１Ｎｏ）。
【００６４】
図８の負荷管理テーブル２００によれば、サーバノード３０−１上のサービスで使用可能なリソース量が以下の通りである場合、負荷基準値を変更してリソース確保を行う必要があるリソースは、ＣＰＵのみとなる。
・サーバノード３０−１で使用可能最大リソース量：
ＣＰＵ：９５（％）
メモリ：３００（ＭＢ）
ディスク：９８（ＭＢ）
・不足分要求リソース量ＲＤ（ＣＰＵ）＝３０−（９５−９０）＝２５
・不足分要求リソース量ＲＤ（メモリ）＝５０−（３００−７１）＋１００（予測分）＝−７９
・不足分要求リソース量ＲＤ（ディスク）＝１０−（９８−４７）＋４０（予測分）＝−１
ただしＣＰＵの予測リソース使用量を０とする。
【００６５】
負荷基準値変更部２２は、ＳＴ−４２からＳＴ−４４までの処理を負荷管理テーブル２００に登録された稼働中サービスの各々について繰り返す。負荷基準値変更部２２は、稼働中サービスが選択可能サービスか否か判定する（ＳＴ−４２）。ここで選択可能なサービスとは、サービスＡのように構成変更対照のサービスと、それ以外の負荷基準値変更の対象としない特殊サービスとを除いた負荷基準値変更の対象とするサービスである。稼働中サービスが選択可能サービスでなければ、ＳＴ−４３とＳＴ−４４の処理をスキップする。稼働中サービスが選択可能サービスであれば、負荷基準値変更部２２は、構成変更対象サーバノード上で稼働中のサービスに対するリクエスト量として、以下の式により優先度を反映したリクエスト量を求める（ＳＴ−４３）。
優先度を反映した当該サービスｍのリクエスト量（ＲＰｍ）＝（サービスｍのリクエスト量）／（サービスｍの優先度）。
【００６６】
次に負荷基準値変更部２２は、サービスｍのリクエスト量ＲＰｍを、当該サーバノードに対する総リクエスト量に加算し、優先度を反映したリクエスト総量ＡＲを求める（ＳＴ−４４）。
優先度を反映した当該サーバノードに対するリクエスト総量ＡＲ＝ＡＲ＋ＲＰｍ。
【００６７】
以上の計算の結果、図８の負荷管理テーブル２００によれば、サーバノード３０−１について以下の値が求められる。
サービスＰ：ＲＰ(P)＝３０／１＝３０
サービスＱ：ＲＰ(Q)＝１／２＝０．５
サービスＲ：ＲＰ(R)＝５０／４＝１２．５
サービスＳ：ＲＰ(S)＝２０／３＝６．６
ＡＲ＝４９．６。
【００６８】
次に負荷基準値変更部２２は、ＳＴ−４５からＳＴ−４７までの処理を負荷基準値の変更対象とする各サービスについて繰り返す。負荷基準値変更部２２は、サービスｍに関して、ＳＴ−４３で求めたリクエスト量（ＲＰｍ）を基に、リクエストの比率を求める（ＳＴ−４５）。
サービスｍのリクエスト比率（ＲＲｍ）＝（ＲＰｍ／ＡＲ）。
【００６９】
次に負荷基準値変更部２２は、この比率から、要求リソース量のうち、当該サービスｍについて削減する必要のあるリソース量分を以下の式によって算出する（ＳＴ−４７）。
サービスｍの削減すべきリソース量（ＲＤｍ）＝（（１−ＲＲｍ）＊ＲＤ）／（負荷基準値変更対象サービス数−１）
すなわち不足分要求リソース量ＲＤをそのリクエスト比率（ＲＲｍ）に応じて変更対象サービス全体で平均的に負担する。
【００７０】
以上の計算の結果、図８の負荷管理テーブル２００によれば、各サービスの削減すべきリソース量は以下の通りとなる。
サービスＰ：ＲＲ(P)＝ＲＰ(P)／ＡＲ＝０．６
サービスＱ：ＲＲ(Q)＝ＲＰ(Q)／ＡＲ＝０．０１
サービスＲ：ＲＲ(R)＝ＲＰ(R)／ＡＲ＝０．２５
サービスＳ：ＲＲ(S)＝ＲＰ(S)／ＡＲ＝０．１３
サービスＰ：ＲＤ(P)＝（（１−ＲＲ(P)）＊ＲＤ(CPU)）／（４−１）＝３.２９
サービスＱ：ＲＤ(Q)＝（（１−ＲＲ(Q)）＊ＲＤ(CPU)）／（４−１）＝８.２５
サービスＲ：ＲＤ(R)＝（（１−ＲＲ(R)）＊ＲＤ(CPU)）／（４−１）＝６.２３
サービスＳ：ＲＤ(S)＝（（１−ＲＲ(S)）＊ＲＤ(CPU)）／（４−１）＝７.２２。
【００７１】
次に、負荷基準値変更部２２は、各サービスの削減すべきリソース量から、サービスｍの変更後の負荷基準値（ＲＳｍ）を求める（ＳＴ−４７）。
当該サービスｍの変更後の負荷基準値（ＲＳｍ）＝サービスｍの現状リソース使用量−ＲＤｍ
以上の計算の結果、図８の負荷管理テーブル２００によれば、各サービスの変更後の負荷基準値は以下の通りとなる。
サービスＰ：ＲＳ(P)＝２０−ＲＤ(P)＝１６．７１（％）
サービスＱ：ＲＳ(Q)＝１０−ＲＤ(Q)＝１．７５（％）
サービスＲ：ＲＳ(R)＝３０−ＲＤ(R)＝２３．７７（％）
サービスＳ：ＲＳ(S)＝３０−ＲＤ(S)＝２２．７８（％）。
【００７２】
負荷基準値変更部２２は、図９の処理をループ（１）により必要なリソース分繰り返す。また連携先のサーバノード３０についても、同様に図９の処理を実行する。
【００７３】
なお、負荷管理テーブル２００を構成変更機構４０からも参照できるようにしておくことで、負荷基準値を算出するステップ（ＳＴ−４）は、構成変更機構４０で行うことも可能である。
【００７４】
図１３は、負荷基準値の算出ステップを、構成変更機構４０で行った場合の構成変更処理手順を示すフローチャートである。負荷基準値を算出するステップ（ＳＴ−４’）の後、構成変更に必要なリソースがあるか否か判定する（ＳＴ−３０）。構成変更に必要なリソースがない場合（ＳＴ−３０ＮＯ）は、負荷分散機構２０に負荷基準値の変更を指示する（ＳＴ−３１）。図１４にＳＴ−３１によって負荷基準値の変更を指示する際の、負荷基準値情報のデータ構成例を示す。図中のデータは上記の計算結果を例としている。一方、構成変更に必要なリソースがある場合（ＳＴ−３０ＹＥＳ）、ただちに構成変更処理を実施する（ＳＴ−１５）。構成変更処理が終了後、構成変更に必要なリソース確保のために負荷基準値を変更したか否か判定する（ＳＴ−３２）。この判定は、ＳＴ−３１およびＳＴ−１４のステップを実行したか否かで決まり、負荷基準値を変更していた場合は、負荷分散機構２０に構成変更処理完了の通知をする（ＳＴ−１６）。
【００７５】
なお、構成変更機構４０は、前述のように、単独の装置として構成することができる他に、図１０に示すようにクラスタシステムを構成する各サーバノード３０に搭載し、サーバノード３０上で動作させることも可能である。この場合、各構成変更機構４０間で、リソース量管理テーブル１００の情報を共有するなどして同期をとるものとする。図１０の例では、リソース量管理テーブル１００は、各サーバノード３０のディスク装置４０に格納されるとしている。
【００７６】
以上述べたように、本実施形態によれば、必要に応じて構成変更対象のサーバノード３０上で稼働するサービスの負荷基準値を下げることによって、サービスに関する構成変更が必要とするリソースを確保できるので、この種の構成変更の速やかな実行が実現できる。
【００７７】
また本実施形態によれば、必要に応じて構成変更対象のサーバノード３０上で稼働するサービスの負荷基準値をそのサービスグレードに応じて均等に下げることによって、構成変更中にリクエスト振り分け部２３のリクエスト振り分けによる負荷バランスが崩れるのを回避し、クライアントに対して安定したサービスを提供することができる。
【００７８】
更に、本発明の応用例として、クライアントからのリクエストより、優先的にリソース確保して実行したい特定バッチ業務を、本実施形態で示す構成変更機構４０を経由して実行することにより、一時的にバッチ処理に必要なリソースを確保することができる。これにより、実行時間の限られたバッチ業務を、速やかに実行することができ、リソース不足による処理遅延を防止することができる。
【００７９】
更に、本発明の応用例として、オンライン中のサービスを提供するサーバプログラムが内部的な処理を実施する際にもリクエストの流量制御をすることができる。ここで、内部的な処理とは、オンラインで使用しているジャーナルファイルの切り離しなど、リソースを大きく消費する処理が含まれる。ジャーナルファイルの切り離しの場合、サーバのデーモンなどが構成変更機構４０に対して構成変更指示を行う。図２のＳＴ−１１のステップでは、図１１に示すような構成変更指示情報７０−２が通知される。構成変更指示情報７０−２の構成変更対象７１に「サーバプログラム３−１／サーバノード１」、構成変更パターン７２に「ジャーナルファイル切り離し」を設定し、構成変更パターンパラメタ１（７３）に強制的に実行する等の実行タイミングを指示するフラグを指定することができる。また、構成変更に必要なリソース量を算定するステップ（ＳＴ−１２）では、図１２に示すような内部処理用のリソース量管理テーブル１００−２を用意しておくことによって、必要なリソース量を算出することが可能である。構成変更指示後の処理については、図２に示す処理と同様の処理（ＳＴ−３〜ＳＴ−１６）が行われる。
【図面の簡単な説明】
【００８０】
【図１】本発明に係るクラスタシステムの一実施形態を示すブロック図である。
【図２】本システムの負荷分散機構と構成変更機構の処理動作を説明するフローチャートである。
【図３】負荷分散機構から構成変更機構へ通知する構成変更指示情報のデータ構成例を示す図である。
【図４】リソース量管理テーブルのデータ構成例を示す図である。
【図５】リソース量算定結果情報のデータ構成例を示す図である。
【図６】構成変更処理に必要なリソース量の算定処理の手順を示すフローチャートである。
【図７】構成変更処理に必要なリソース量の計算結果例を示す図である。
【図８】負荷管理テーブルのデータ構成例を示す図である。
【図９】各サービスの負荷基準値変更に関する処理の手順を示すフローチャートである。
【図１０】他のクラスタシステム構成を示すブロック図である。
【図１１】他の構成変更指示情報のデータ構成例を示す図である。
【図１２】他のリソース量算定結果情報のデータ構成例を示す図である。
【図１３】負荷分散機構と構成変更機構の他の処理動作を説明するフローチャートである。
【図１４】変更する負荷基準値情報のデータ構成例を示す図である。
【符号の説明】
【００８１】
１０：クライアント端末、２０：負荷分散機構、２１：構成変更指示部、２２：負荷基準値変更部、２３：リクエスト振り分け部、３０：サーバノード、４０：構成変更機構、４１：リソース量算定部、４２：リソース量情報通知部、４３：構成変更部、７０：構成変更指示情報、８０：リソース量算定結果情報、９０：負荷基準値情報、１００：リソース量管理テーブル、２００：負荷管理テーブル。
【図１】
2007249445.tif 000003
【図２】
2007249445.tif 000004
【図３】
2007249445.tif 000005
【図４】
2007249445.tif 000006
【図５】
2007249445.tif 000007
【図６】
2007249445.tif 000008
【図７】
2007249445.tif 000009
【図８】
2007249445.tif 000010
【図９】
2007249445.tif 000011
【図１０】
2007249445.tif 000012
【図１１】
2007249445.tif 000013
【図１２】
2007249445.tif 000014
【図１３】
2007249445.tif 000015
【図１４】
2007249445.tif 000016