JP6004075B2 - 計算システムおよび計算システム管理方法 - Google Patents

Description

本発明は、計算システムおよび計算システム管理方法に関する。

従来、Java（登録商標）アプリケーションが動作するするアプリケーションサーバにおいて、ＪａｖａＶＭはＪａｖａアプリケーションが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放するガーベジコレクション（garbage collection; GC）が用いられている。メモリ領域のうち、Ｊａｖａが使用できるメモリ領域（ヒープ領域）と非ヒープ領域の両方のメモリを開放するガーベジコレクションがＦｕｌｌＧＣである。

従来のガーベジコレクションにかかる技術では、ＦｕｌｌＧＣなどのオーバーヘッドを予兆して、オーバーヘッド回避手段を実行する技術がある。この場合、オーバーヘッド回避手段の実行中は、他のアプリケーションサーバに処理を振り分ける。また、待機仮想計算機を用意し、順次ＦｕｌｌＧＣを行う技術もある。

さらに、リセット処理時間設定テーブルに設定された値からの時刻に自システム内にあるリセット処理実行部が呼び出され、閉塞処理およびＦｕｌｌＧＣ処理を実施後、その後閉塞解除処理が呼び出される技術がある。他に、処理プログラムの処理によって参照されたメモリのガーベジコレクションを実行し、ガーベジコレクションが実行された時刻を計測し、計測の結果から、前回実行されたガーベジコレクション処理と今回実行されたガーベジコレクション処理との間隔を算出し、算出された間隔と所定のしきい値との比較の結果、異常の発生を通知するか否かを決定するものもある。この例は、システムでのしきい値とＦｕｌｌＧＣの間隔やＦｕｌｌＧＣにより増えた空きメモリ量をチェックしてアラートを通知するための仕組みである。

特開２００７−１９９８２９号公報 特公平８−２７７８４号公報 特開２００３−１７８０４１号公報 特開２００７−３２８４１３号公報 特開２００７−２２６３９９号公報 特開２０００−２２２３７６号公報 特開２００１−２０２２８４号公報

しかしながら、従来の技術では、複数のアプリケーションサーバが同じ負荷となるように負荷分散が行われるため、オーバーヘッド回避手段の実行中は、残りの複数の仮想計算機でも同時にメモリ使用量が増加しＦｕｌｌＧＣが発生し、システム全体の処理効率が低下する課題がある。

また、アプリケーションサーバのオーバーヘッドを外部装置である負荷分散装置が予兆する場合、ネットワークを介した入出力処理が必要となるが、入出力処理はアプリケーションサーバの性能を低下させ、高い精度での監視を実現するのが困難という課題がある。

加えて、アプリケーションサーバのオーバーヘッドを予兆するための機能が負荷分散装置に求められるため、アプリケーションサーバの仕様や実装を変更したりスケールアップを行ったりすると負荷分散管理装置の保守が必要となる課題がある。

また、複数のアプリケーションサーバが同じ負荷となるように負荷分散が行われると、複数の仮想計算機で同時にメモリ使用量が増加する。また最近は広大なメモリ空間を備える仮想計算機が台頭し、ＦｕｌｌＧＣ処理時間が増長する傾向があり、結果として順次ＦｕｌｌＧＣ処理の所要時間も増長する。そのため、ＦｕｌｌＧＣ処理を順次に行う方式だと、順次ＦｕｌｌＧＣの順が後ろの方の仮想計算機において、ＦｕｌｌＧＣ処理の順が来るまでの間にメモリ使用量が増加し、閉塞処理が実行されないままＦｕｌｌＧＣが発生し、正常なフェイルオーバーを実現できず、システム全体の処理効率が低下する課題がある。

また、従来のJavaアプリケーションやJavaのプロセスを起動するアプリケーションサーバシステム上でアプリケーションを運用している際に、空きヒープ量が不足した場合にJava標準機能としてガーベジコレクションが実行されると全体のヒープ量に比例した時間、アプリケーション処理能力が低下することとなりリクエストに対するスループットが低下してしまう。

時刻によって自動的にＦｕｌｌＧＣを行う技術では、指定時刻に必ずしもリクエストが存在しないとは限らず、過負荷時の状態が長く続く場合や過負荷時の状態が複数の時間に点在するような場合、１日のうちに複数回のＦｕｌｌＧＣ処理を必要とする可能性がある。この場合、リクエストが発生しているため、少なからずスループットは低下してしまう。

そして、業務運用中メモリ使用量が増えヒープ残量が設定したしきい値を切った場合に自動的にＦｕｌｌＧＣを行う技術では、ＦｕｌｌＧＣが動作したＪａｖａＶＭは処理性能が著しく低下するため、業務に影響がでてしまう。

そこで、一つの側面では、ガーベジコレクション実行時におけるアプリケーション処理の負荷を軽減することを目的とする。

本願の開示する計算システムおよび計算システム管理方法は、複数の計算機に計算処理を配分する計算システムであって、ガーベジコレクション、計算機の停止、または計算機の再起動の実行を指示する実行指示部を備える。また、開示の計算システムおよび計算システム管理方法では、計算処理を実行可能な運用状態の計算機は、ガーベジコレクション、計算機の停止、または計算機の再起動の実行を指示された場合に、待機中の他の計算機を運用状態に切り替え、切り替え完了後にガーベジコレクション、計算機の停止、または計算機の再起動を開始する。そして、開示の計算システムおよび計算システム管理方法は、ガーベジコレクションまたは計算機の再起動を実行する計算機の状態に基づいて、切り替えの完了後にガーベジコレクションまたは計算機の再起動を開始するか、切り替えの完了前にガーベジコレクションまたは計算機の再起動を開始するかを選択する。

本願の開示する計算システムおよび計算システム管理方法によれば、ガーベジコレクション、計算機の停止、または計算機の再起動の実行時におけるアプリケーション処理の負荷を軽減することができる。

図１は、実施例１にかかる計算システムの構成図である。 図２は、実施例１にかかる計算システムと従来技術とを対比する説明図である。 図３は、計算システム１における増設についての説明図である。 図４は、図１に示した定義情報の説明図である。 図５は、救済措置の優先度の具体例である。 図６は、図１に示した仮想計算機管理テーブルの説明図である。 図７は、仮想計算機の起動と相互認知の処理についての説明図である。 図８−１は、運用仮想計算機の処理を説明するフローチャートである。 図８−２は、運用仮想計算機の処理を説明するフローチャートである。 図８−３は、運用仮想計算機の処理を説明するフローチャートである。 図９は、待機仮想計算機の処理を説明するフローチャートである。 図１０は、装置間の連携についての説明図である。 図１１は、運用仮想計算機と待機仮想計算機の連携についての説明図である。 図１２は、実施例２にかかる計算システムの構成図である。 図１３は、図１２に示した計算機の構造についての説明図である。 図１４は、仮想計算機の起動処理について説明するフローチャートである。 図１５は、図１４に示した運用・待機問い合わせ（Ｓ９０６）について説明するフローチャートである。 図１６は、コマンド実行処理部による外部からのＦｕｌｌＧＣ処理について説明するフローチャートである。 図１７は、運用中のＪａｖａＶＭによるＦｕｌｌＧＣ処理について説明するフローチャートである。 図１８は、待機中のＪａｖａＶＭによるＦｕｌｌＧＣ処理について説明するフローチャートである。 図１９は、振り分け処理の動作を説明するフローチャートである。 図２０は、ＪａｖａＶＭの状態遷移図と振り分け状態の説明図である。 図２１は、仮想計算機情報記憶部が保持するデータの具体例である。 図２２は、アプリケーション終了の待ち合わせ処理について説明するフローチャートである。 図２３は、待機ＪａｖａＶＭの運用化依頼処理について説明するフローチャートである。 図２４は、ＦｕｌｌＧＣ実行時のＪａｖａＶＭと振り分け状態の遷移についての説明図である。 図２５は、待機ＪａｖａＶＭを運用化した際のＦｕｌｌＧＣ処理について説明するフローチャートである。

以下に、本発明にかかる計算システムおよび計算システム管理方法の実施例を図面に基づいて詳細に説明する。なお、本実施例は開示の技術を限定するものではない。

［計算システムの構成］
図１は、実施例１にかかる計算システムの構成図である。図１に示した計算システム１は、負荷分散装置１００に仮想計算機１１〜１３を接続した構成を有する。また、仮想計算装置１１〜１３は、相互に通信可能である。

仮想計算機１１〜１３は、オペレーティングシステムで動作する仮想計算機であり、オペレーティングシステム上に複数実行可能である。すなわち、仮想計算機は、コンピュータのエミュレータではなく、単一のオペレーティングシステム上でそれぞれが計算アプリケーションとして計算処理を担うことができる。

仮想計算機１１は、アプリケーション２１、監視エージェント３１、安定稼働エージェント４１、情報記憶部５１を有する。アプリケーション２１は、負荷分散装置１００から配分された計算処理を実行するアプリケーションである。監視エージェント３１は、仮想計算機１１の動作を監視し、監視結果に基づいて仮想計算機１１のガーベジコレクションの実行を指示する実行指示部として機能する。

具体的には、監視エージェント３１は、仮想計算機１１で発生するタイムアウト、仮想計算機１１のメモリ使用状況、負荷状況、外部からのＦｕｌｌＧＣ要求の発生を監視する。そして、監視エージェント３１は、監視結果を事象検知イベントとして安定稼働エージェント４１に通知する。

安定稼働エージェント４１は、監視エージェント３１からの事象検知イベントを受信する事象検知イベント受信部６１と、受信したイベントに基づいて救済措置を実行する救済措置実行部６２を有する。安定稼働エージェント４１は、ガーベジコレクション、計算機の停止、または計算機の再起動の実行を指示された場合に、待機中の他の仮想計算機を計算処理が実行可能な運用状態に切り替える。そして、切り替え完了後にガーベジコレクション、計算機の停止、または計算機の再起動を開始する安定稼働処理部として動作する。

情報記憶部５１は、定義情報や仮想計算機管理テーブルなど、仮想計算機１１が使用する各種情報を記憶する記憶部である。

仮想計算機１２は、仮想計算機１１と同様に、アプリケーション２２、監視エージェント３２、安定稼働エージェント４２、情報記憶部５２を有する。また、仮想計算機１３は、アプリケーション２３、監視エージェント３３、安定稼働エージェント４３、情報記憶部５３を有する。アプリケーション２２〜２３は、アプリケーション２１と同様に動作し、監視エージェント３２〜３３は監視エージェント３１と同様に動作する。そして、安定稼働エージェント４２〜４３は安定稼働エージェント４１と同様に動作し、情報記憶部５２〜５３は情報記憶部５１と同様に動作する。

図２は、実施例１にかかる計算システムと従来技術（特開２００７−１９９８２９号公報）とを対比する説明図である。図２に示したように計算システム１は、仮想計算機１１〜１３が計算機１ａ上で実行され、計算機１ａは負荷分散装置１００と接続している。そして、負荷分散装置１００は、ネットワーク１２０を介して端末群１１０と接続している。

一方、比較例である計算システム３では、仮想計算機７１〜７３が計算機３ａ上で実行され、計算機３ａは負荷分散装置１００と接続している。加えて、負荷分散装置１００と計算機３ａは、運用管理装置１３０と接続している。そして、負荷分散装置１００は、ネットワーク１２０を介して端末群１１０と接続している。

計算システム３では、仮想計算機を増設するときは、運用管理装置を含めたシステム全体で設定を行なうこととなる点が課題である。これに対して計算システム１では、運用管理装置を持たず、仮想計算機同士で通信する。このように運用管理装置を持たないため、保守作業を軽減することができる。

図３は、計算システム１における増設についての説明図である。図３に示した例では、計算機１ａに負荷分散装置１００が接続され、負荷分散装置１００はさらに負荷分散装置１０１に接続されている。負荷分散装置１０１は、ネットワーク１２０を介して端末群１１０と接続している。

この構成では、計算機１ｂを負荷分散装置１００に増設することもできる。この場合、負荷分散装置無しの増設となる。また、負荷分散装置１００に負荷分散装置１０２を含む計算システム１ｃを増設することもできる。このように負荷分散装置１００を含めて増設することが可能である。

比較例の計算システム３では、負荷分散装置が１つであることが前提となる。これは、運用管理装置が特定の負荷分散装置と通信を行なう構成となるためである。対して本実施例にかかる計算システム１では、各仮想計算機が直接、負荷分散装置と通信するため、負荷分散装置を含むシステムを追加することが可能となるのである。

［データの具体例］
図４は、図１に示した定義情報の説明図である。定義情報は、監視データのしきい値と、しきい値に達したときの救済措置を設定している。この定義情報は、定義ファイルやシステム全体から情報を取得し、メモリ上などに保持することで管理する。

図４に示した例では、定義情報は、大分類の情報名、中分類の情報名、小分類の情報名、値、その他の項目を有する。大分類の情報名「負荷分散」、中分類の情報名「ホスト」には、値「１９２．１６８．１００．１」が定義されている。また、大分類の情報名「負荷分散」、中分類の情報名「ポート」には、値「１２２２０」が定義されている。

同様に、大分類の情報名「事象検知時同報」、中分類の情報名「同報間隔」には、値「５秒」が定義されている。さらに、大分類の情報名「事象監視」、中分類の情報名「監視間隔」には、値「１秒」が定義されている。

同様に、大分類の情報名「事象監視」、中分類の情報名「応答タイムアウト」、小分類の情報名「しきい値１」には、値「４８０秒」が定義されている。大分類の情報名「事象監視」、中分類の情報名「応答タイムアウト」、小分類の情報名「救済措置１」には、値「強制再起動」が定義されている。

大分類の情報名「事象監視」、中分類の情報名「メモリ領域Ａ」、小分類の情報名「しきい値１」には、値「６０％」が定義されている。大分類の情報名「事象監視」、中分類の情報名「メモリ領域Ａ」、小分類の情報名「救済措置１」には、値「転生リセット」が定義されている。

大分類の情報名「事象監視」、中分類の情報名「メモリ領域Ａ」、小分類の情報名「しきい値２」には、値「８５％」が定義されている。大分類の情報名「事象監視」、中分類の情報名「メモリ領域Ａ」、小分類の情報名「救済措置２」には、値「強制リセット」が定義されている。

大分類の情報名「事象監視」、中分類の情報名「メモリ領域Ｂ」、小分類の情報名「しきい値１」には、値「８０％」が定義されている。大分類の情報名「事象監視」、中分類の情報名「メモリ領域Ｂ」、小分類の情報名「救済措置１」には、値「転生再起動」が定義されている。

大分類の情報名「事象監視」、中分類の情報名「メモリ領域Ｂ」、小分類の情報名「しきい値２」には、値「９０％」が定義されている。大分類の情報名「事象監視」、中分類の情報名「メモリ領域Ｂ」、小分類の情報名「救済措置２」には、値「強制再起動」が定義されている。

このように、しきい値と救済措置の組は１つ以上用意する。そして、しきい値に達した場合には、対応する救済措置を実行する。

救済措置には、仮想計算機の強制停止、転生停止、強制再起動、転生再起動、強制リセット、転生リセットの６種類がある。また、他の救済措置を設けることもできる。

強制は、待機仮想計算機が存在しなくても、救済措置を実行することを示し、転生は待機仮想計算機が出現する状態まで待ち、負荷分散の振り分けを切り替えてから救済措置を実行することを示す。また、リセットとは、ＦｕｌｌＧＣその他の処理を実行し、資源を解放する処理を指す。

救済措置には、優先度を付与する。他の救済措置を実行中に、後から優先度の高い救済措置が必要となった場合には、その救済措置を実行する。図５は、救済措置の優先度の具体例である。図５に示した例では、強制停止が優先度１、転生停止が優先度２、強制再起動が優先度３、転生再起動が優先度４、強制リセットが優先度５、転生リセットが優先度６である。

図６は、図１に示した仮想計算機管理テーブルの説明図である。仮想計算機管理テーブルの目的は、他の仮想計算機との通信方式を知ることと、他の仮想計算と通信を行なって待機仮想計算機が存在する場合にフェイルオーバーを行なうことである。

図６では、運用開始時のテーブルと、仮想計算機追加後のテーブルを示している。運用開始時のテーブルでは、マシン名「Ａ」、プロトコル「JMX-SNMP」、ホスト名／ＩＰアドレス「app1.fu.com」、ポート番号「162」の仮想計算機と、マシン名「Ｂ」、プロトコル「JMX-RMI」、ホスト名／ＩＰアドレス「app2.fu.com」、ポート番号「2001」の仮想計算機が登録されている。

さらに、仮想計算機追加後のテーブルでは、マシン名「Ｃ」、プロトコル「JMX-RMI」、ホスト名／ＩＰアドレス「app3.fu.com」、ポート番号「2001」の仮想計算機と、マシン名「Ｄ」、プロトコル「JMX-RMI」、ホスト名／ＩＰアドレス「app4.fu.com」、ポート番号「2003」の仮想計算機が追加して登録されている。

［処理動作］
図７は、仮想計算機の起動と相互認知の処理についての説明図である。仮想計算機は、情報処理システムへの参加時に、他の仮想計算機に同報して情報交換する。各仮想計算機は、運用か待機かを予め決められており、それを追加／削除することで、運用数や待機数を調整することができる。

具体的には、仮想計算機を起動すると、定義情報を取得し（Ｓ１０１）、情報処理システムへの参加を同報にて通知する（Ｓ１０２）。仮想計算機は、仮想計算機管理テーブルを更新し（Ｓ１０３）、自仮想計算機が運用であるか待機であるかを判定する（Ｓ１０４）。運用の場合には、負荷分散装置に自仮想計算機への振り分け開始を依頼し（Ｓ１０５）、運用仮想計算機として動作を開始する。また、待機の場合には、負荷分散装置に自仮想計算機への振り分け停止を依頼し（Ｓ１０６）、待機仮想計算機として動作を開始する。

例えば、アプリサーバＡが起動した場合、アプリサーバＡは他の仮想計算機に所定のプロトコルで同報し、情報処理ステムに参加する意志を示す。同報を受けたアプリサーバＢは応答を返す。また必要に応じてアプリサーバＡとアプリサーバＢは相互認証を実施し、セキュリティを高めることができる。

アプリサーバＡとアプリサーバＢは、仮想計算機管理テーブルを更新するために情報交換し、それぞれ仮想計算機管理テーブルを更新する。

図８は、運用仮想計算機の処理を説明するフローチャートである。運用仮想計算機の監視エージェントは、監視データを採取し（Ｓ２０１）、しきい値に達した場合（Ｓ２０２，Ｙｅｓ）に事象検知イベントを送信する処理（Ｓ２０３）を繰り返す。

事象検知イベント受信部は、事象検知イベントを受信し（Ｓ３０１）、救済措置が未実行であるかを判定する（Ｓ３０２）。救済措置が未実行である場合（Ｓ３０２，Ｙｅｓ）、事象検知イベント受信部は当該救済措置を実行する（Ｓ３０４）。

救済措置を実行中である場合（Ｓ３０２，Ｎｏ）、事象検知イベント受信部は、新規救済措置の優先度が実行済みの既存救済措置よりも優先度が高いかを判定する（Ｓ３０３）。新規救済措置の優先度が既存救済措置の優先度よりも低い場合（Ｓ３０３，Ｎｏ）、事象検知イベント受信部は、再びステップＳ３０１に戻る。また、新規救済措置の優先度が既存救済措置の優先度よりも高い場合（Ｓ３０３，Ｙｅｓ）、事象検知イベント受信部は、既存救済措置を中止し（Ｓ３０５）、新規救済措置を実行して（Ｓ３０６）、ステップＳ３０１に戻る。救済措置が実行中でない場合（Ｓ３０３，Ｎｏ）、事象検知イベントを受信する処理（Ｓ３０１）から繰り返す。

救済措置実行部は、救済措置の実行指示を受け付ける（Ｓ４０１）と、事象検知を同報する（Ｓ４０２）。その後、待機仮想計算機が存在するかを判定する（Ｓ４０３）。待機仮想計算機が存在する場合（Ｓ４０３，Ｙｅｓ）、待機仮想計算機に運用開始を依頼し（Ｓ４０４）、負荷分散装置に自仮想計算機への新規のみ振り分け停止を依頼する（Ｓ４０５）。

仮想計算機が存在しない場合（Ｓ４０３，Ｎｏ）、救済措置実行部は、転生が必須かを判定し（Ｓ４０６）、転生が必須でない場合には（Ｓ４０６，Ｎｏ）、負荷分散装置に自仮想計算機への新規のみ振り分け停止を依頼する（Ｓ４０７）。

転生が必須である場合（Ｓ４０６，Ｙｅｓ）、救済措置実行部は、定義された時間だけ待機し（Ｓ４０８）と、救済措置の中止依頼があるかを判定する（Ｓ４０９）。そして、救済措置の中止依頼があれば（Ｓ４０９，Ｙｅｓ）、救済措置を中止し、ステップＳ４０１に戻る。救済措置の停止依頼がなければ（Ｓ４０９，Ｎｏ）、ステップＳ４０２に戻る。

ステップＳ４０５、ステップＳ４０７の後には、救済措置実行部は、残存処理の終了を待ち（Ｓ４１０）、負荷分散装置に自仮想計算機への振り分け停止を依頼し（Ｓ４１１）、救済措置の種類を判定する（Ｓ４１２）。救済措置の種類が再起動である場合には、自仮想計算機を再起動し（Ｓ４１３）、救済措置の種類がリセットである場合には自仮想計算機をリセットして（Ｓ４１４）、処理を終了する。

図９は、待機仮想計算機の処理を説明するフローチャートである。待機仮想計算機は、事象検知の同報を受け付ける（Ｓ５０１）と、送信元に応答し（Ｓ５０２）、運用開始の依頼を受け付けると（Ｓ５０３）、負荷分散装置に自仮想計算機への振り分け開始を依頼（Ｓ５０４）する。そして、ＦｕｌｌＧＣを実行し（Ｓ５０５）、送信元に応答して（Ｓ５０６）、運用仮想計算機となる。

図１０は、装置間の連携についての説明図である。まず、運用仮想計算機と待機仮想計算機が相互認知する。すなわち、運用仮想計算機が仮想計算機を認識し（Ｓ７０１）、仮想計算機が運用仮想計算機を認識する（Ｓ８０１）。

運用仮想計算機は負荷分散装置に振り分け開始を依頼し（Ｓ７０２）、待機仮想計算機は負荷分散装置に振り分け停止を依頼する（Ｓ８０２）。負荷分散装置は、待機仮想計算機（Ｂ）からの振り分け停止依頼を受け付け（Ｓ６０１）、待機仮想計算機（Ｂ）への振り分けを停止する（Ｓ６０２）。また、負荷分散装置は、運用仮想計算機（Ａ）からの振り分け開始依頼を受け付け（Ｓ６０３）、運用仮想計算機（Ａ）への振り分けを開始する（Ｓ６０４）。

運用仮想計算機は、端末からの要求処理を開始する（Ｓ７０３）。その後、運用仮想計算が監視エージェントで問題を検知すると（Ｓ７０４）、待機仮想計算機に運用を依頼する（Ｓ７０５）。待機仮想計算機は、運用仮想計算機に応答し、待機仮想計算機への振り分け開始を負荷分散装置に依頼して（Ｓ８０３）、ＦｕｌｌＧＣを実行し（Ｓ８０４）、運用状態となる。

負荷分散装置は、待機仮想計算機からの振り分け開始依頼を受け付け（Ｓ６０５）、待機仮想計算機であった計算機に対して振り分けを開始する（Ｓ６０６）。

運用仮想計算機は、負荷分散装置に新規のみ振り分け停止を依頼し（Ｓ７０６）、残存処理の終了を待機する（Ｓ７０７）。残存処理が終了すると、運用仮想計算機は、負荷分散装置に振り分け停止を依頼し（Ｓ７０８）、救済措置を行なって（Ｓ７０９）、待機状態となる。

負荷分散装置は、運用仮想計算機であった仮想計算機からの新規のみ振り分け停止依頼を受け付けると（Ｓ６０７）、運用仮想計算機であった仮想計算機への新規のみ振り分けを停止する（Ｓ６０８）。その後、運用仮想計算機（Ａ）への振り分け停止依頼を受け付け（Ｓ６０９）、運用仮想計算機（Ａ）への振り分けを停止する（Ｓ６１０）。

図１１は、運用仮想計算機と待機仮想計算機の連携についての説明図である。図１１に示した例では、５つの仮想計算機Ａ〜Ｅのうち、仮想計算機Ａ〜Ｃが初期状態で運用中、仮想計算機Ｄ〜Ｅが初期状態で待機中の場合を示している。また、図中の太線は、運用中であることを、細線は待機中であることを示し、破線は救済措置中であることを示す。

図１１に示した例では、まず運用中である仮想計算機Ａが第１しきい値による事象検知を仮想計算機Ｂ〜Ｅに同報している。そして、待機中の仮想計算機Ｄが最初に同報元に応答している。同報元の仮想計算機Ａは、最初に応答した仮想計算機Ｄに対して運用開始を依頼し、救済措置を実行する。依頼を受けた仮想計算機Ｄは、依頼に対して応答し、運用状態となる。

その後、運用中の仮想計算機Ｂが第１しきい値による事象検知を仮想計算機Ａ，Ｃ〜Ｅに同報している。そして、待機中の仮想計算Ｅが同報元に応答している。同報元の仮想計算機Ｂは、最初に応答した仮想計算機Ｅに対して運用開始を依頼し、救済措置を実行する。依頼を受けた仮想計算機Ｅは、依頼に対して応答し、運用状態となる。

さらにその後、運用中の仮想計算機Ｃが第１しきい値による事象検知を仮想計算機Ａ〜Ｂ，Ｄ〜Ｅに同報している。この同報には応答可能な待機仮想計算機が無い。このため、転生処理は保留し、仮想計算機Ｃは、周期的に第１しきい値による事象検知の同報を繰り返す。その後、第２しきい値を超過しても待機仮想計算機が存在しない場合、同報を中止し、救済措置を開始する。

仮想計算機Ｃが第２しきい値を超過して救済措置に移行するまでは、待機仮想計算機を運用状態に移行させることで、仮想計算機の運用数３を維持することができている。仮想計算機Ｃが第２しきい値を超過して救済措置に移行した後は、運用数が２に減少するが、仮想計算機Ｃの救済措置が完了すると運用状態に復帰するため、運用数は３に戻る。なお、仮想計算機Ａ，Ｂは、救済措置の完了後に待機仮想計算機となる。

上述してきたように、本実施例１にかかる計算システム１は、運用管理装置なしに、仮想計算機同士で自律的にフェイルオーバー制御（待機仮想計算機に運用を委譲)を行う。また、高負荷状態に達するリスクを減すために、メモリ消費量に２段階のしきい値を設けて性能監視を行っている。そして、システム起動後に、リクエスト数やアプリケーションの実装に応じて、運用または待機仮想計算機を追加または削減することができる。すなわち、プロビジョニングが可能である。

具体的には、計算システム１は、複数の仮想計算機(ＪａｖａＶＭ)から構成する情報処理システムであり、運用仮想計算機と待機仮想計算機を用意し、運用中に運用または待機仮想計算機を動的に追加または削減可能である。なお、運用と待機の比率は固定でなくてもよい。

そして、２段階しきい値によるメモリ使用量監視および異常監視を行い、メモリ使用量の増加および異常発生を検知し、負荷分散装置に対して、待機仮想計算機への振り分け開始を依頼する。また、負荷分散装置に対して、運用仮想計算機への新規のみ振り分け停止を依頼し、運用仮想計算機での残存処理が完了するまで待機し、負荷分散装置に対して、運用仮想計算機への振り分けを完全に停止する。そして、運用仮想計算機の資源解放（ＦｕｌｌＧＣ)もしくは再起動を行い、運用仮想計算機を待機仮想計算機にする。このとき、運用数によっては、運用仮想計算機に復帰する。

以上の構成と動作によって、計算システム１は、運用管理装置なしに、仮想計算機が自律的に性能監視を行い、仮想計算機同士で直接通信しあってフェイルオーバーを実現する。そのため運用管理装置を用意する場合に比べ、高い精度での監視が可能かつ、運用管理装置との通信コストが削減される効果がある。また、運用管理装置に対する保守作業も削減される効果がある。

さらに、仮想計算機のスペックに応じて、メモリ使用量に２段階のしきい値を設けることができる。第１しきい値を超過したときにフェイルオーバーができた場合には直ちにＦｕｌｌＧＣを実行し、フェイルオーバーができないまま第２しきい値を超過した場合はフェイルオーバーを行わずにＦｕｌｌＧＣを実行する。これによりフェイルオーバーの確率が向上し、処理効率が低下しにくいシステム運用を実現できる効果がある。ひいては障害発生率も低下させ安定稼働率を高めることにつながる。

そして、仮想計算機同士で通信し、仮想計算機の情報、運用数と待機数を増加もしくは削減するため、アプリケーション特性やリクエスト数の変化に応じて、システムを停止することなくプロビジョニングを行うことができる。

このように、計算システム１は、ガーベジコレクション実行時におけるアプリケーション処理に負荷を軽減し、仮想計算機を安定して稼働させることができる。

［計算システムの構成］
図１２は、実施例２にかかる計算システムの構成図である。また、図１３は、図１２に示した計算機の構造についての説明図である。図１２に示した計算システム２は、負荷分散装置１００に計算機２ａが接続した構成を有する。また、負荷分散装置１００は、ネットワーク１２０を介して端末群１１０と接続している。

計算機２ａは、コマンド実行処理部９０、ＪＭＸ管理サーバ９１、仮想計算機１４〜１６の機能をソフトウェアによって実現する。コマンド実行処理部９０は、ＪＭＸ管理サーバ９１や仮想計算機１４〜１６に対して各種コマンドに対応する処理を実行させる。このコマンドには、任意の契機にガーベジコレクションの実行を指示する事を可能とするコマンドが含まれる。

ＪＭＸ管理サーバ９１は、アプリ安定稼働サービス部９２を備える。アプリ安定稼働サービス部９２は、図１３に示したように、仮想計算機情報記憶部９２ａによって仮想計算機の情報を管理するとともに、振り分け制御部９３によって仮想計算機１４〜１６に対する処理の振り分けを管理することで、仮想計算機１４〜１６を安定して稼働させる。振り分け制御部９３には、ＷｅｂＳｅｒｖｉｃｅＣｏｎｎｅｃｔｏｒ、ＳｅｓｓｉｏｎＢｅａｎ、ＭｅｓｓａｇｅＤｒｉｖｅｎＢｅａｎが含まれる。

仮想計算機１４〜１６は、それぞれアプリケーション９５、アプリ安定稼働機能部９６、ＪａｖａＶＭ監視部９７を有する。アプリケーション９５は、自仮想計算機に振り分けられた計算処理を実行する。アプリ安定稼働機能部９６は、計算処理を実行可能な運用状態においてガーベジコレクションの実行を指示された場合に、待機中の他の計算機を運用状態に切り替えて、切り替え完了後にガーベジコレクションを開始する安定稼働処理部として機能する。

アプリ安定稼働機能部９６は、ＭＢｅａｎ処理部９６ａ、イベント処理部９６ｂ、救済機能実行部９６ｃを有する。ＭＢｅａｎ処理部９６ａは、リソースの管理（ＪａｖａＶＭ管理ＭＢｅａｎ，ユーザクラス実行ＭＢｅａｎ）を行なって、事象検知時に相当する状態をアプリ安定稼働サービス部９２から経由して仮想計算機情報記憶部９２ａに登録する。また、待機中の際、アプリ安定稼働サービス部９２からから運用化するための依頼を受け付け、イベント処理部９６ｂに渡す。

イベント処理部９６ｂは、ＭＢｅａｎ処理部９６ａや、ＪａｖａＶＭ監視部９７からイベントの通知を受け、救済機能実行部９６ｃに救済措置を実行させる。ＪａｖａＶＭ監視部９７は、ＪａｖａＶＭの予兆監視、アプリケーションのタイムアウト監視、メモリの予兆監視を行なって、イベントが発生した場合にイベント処理部９６ｂに通知する。

［処理動作の説明］
図１４は、仮想計算機の起動処理について説明するフローチャートである。仮想計算機はアプリ安定稼働機能の起動時の処理を開始すると、まずＪＭＸポートを開け（Ｓ９０１）、ＭＢｅａｎの登録処理を行なう（Ｓ９０２）。そして、仮想計算機識別子、全プロセス数、設定待機数、プロセス通番、ＪＭＸポート番号、Ｗｅｂポート番号、プロセスＩＤなどをアプリ安定稼働サービスに登録する（Ｓ９０３）。

アプリ安定稼働サービス部は、登録を受けて、仮想計算機識別子とプロセス通番に対応する状態として、ＳＴＯＰを設定する（Ｓ９０４）。

その後、アプリ安定稼働機能は、救済機能実行部、イベント受信部、監視処理用リストの生成および登録を行なう（Ｓ９０５）。そして、図１５に示す運用・待機問い合わせ（Ｓ９０６）を行ない、アプリ安定稼働サービス部からの返却値（ＡＣＴＩＶＥまたはＳＴＡＮＤＢＹ）を内部の状態として設定する（Ｓ９０７）。以上の手順によって、仮想計算機が起動する（Ｓ９０８）。

図１５は、図１４に示した運用・待機問い合わせ（Ｓ９０６）について説明するフローチャートである。運用・待機状態の問い合わせ依頼が開始すると、アプリ安定稼働サービス部は、待機状態から運用状態への呼び出しかを判定する（Ｓ１００１）。

待機状態から運用状態への呼び出しでない場合（Ｓ１００１，Ｎｏ）、アプリ安定稼働サービス部は、全プロセス数から待機数を引いた数と現在の運用数を比較する（Ｓ１００２）。

全プロセス数から待機数を引いた数が現在の運用数と同じである場合（Ｓ１００２，同じ）には、アプリ安定稼働サービス部は、現在のＡＣＴＩＶＥ状態である全プロセスリストに対象プロセス通番があるかを判定する（Ｓ１００３）。

待機状態から運用状態にするための呼び出しである場合（Ｓ１００１，Ｙｅｓ）、全プロセス数から待機数を引いた数が現在の運用数より多い場合（Ｓ１００２，多い）、また、現在のＡＣＴＩＶＥ状態である全プロセスリストに対象プロセス通番がある場合、アプリ安定稼働サービス部は、図１９に示す振り分け処理を開始する（Ｓ１００４）。

振り分けの開始に成功すると（Ｓ１００５，Ｙｅｓ）、アプリ安定稼働サービス部は、仮想計算機情報記憶部へＡＣＴＩＶＥを設定し（Ｓ１００６）、決定状態（ＡＣＴＩＶＥ）を返却する。

全プロセス数から待機数を引いた数が現在の運用数よりも少ない場合（Ｓ１００２，少ない）や、運用リストに対象プロセス通番が無かった場合（Ｓ１００３，Ｎｏ）、アプリ安定稼働サービス部は、図１９に示す振り分け処理を停止する（Ｓ１００７）。

振り分けの停止に成功すると（Ｓ１００８，Ｙｅｓ）、アプリ安定稼働サービス部は、仮想計算機情報記憶部へＳＴＡＮＤＢＹを設定し（Ｓ１００９）、決定状態（ＳＴＡＮＤＢＹ）を返却する。

振り分けの開始や停止に失敗すると（Ｓ１００５，Ｎｏ、Ｓ１００８，Ｎｏ）、アプリ安定稼働サービス部は、状態ＡＢＮＯＲＭＡＬを設定し例外をスローする（Ｓ１０１０）。その後、救済措置によって当該ＪａｖａＶＭの再起動が行なわれる（Ｓ１０１１）。

図１６は、コマンド実行処理部による外部からのＦｕｌｌＧＣ処理について説明するフローチャートである。外部からのＦｕｌｌＧＣ処理では、コマンド実行処理部は、まず指定オプションが正しいかを判定する（Ｓ１１０１）。指定オプションが正しくなければ（Ｓ１１０１，Ｎｏ）、コマンド実行処理部は、Ｓｙｎｔａｘを出力して（Ｓ１１１１）、異常終了する。

指定オプションが正しい場合（Ｓ１１０１，Ｙｅｓ）、コマンド実行処理部は、仮想計算機識別子を指定してアプリ安定稼働サービスから仮想計算機内の全プロセスの状態情報を取得する（Ｓ１１０２）。このとき、仮想計算機情報記憶部の全ＪａｖａＶＭのＦｕｌｌＧＣフラグをＦａｌｓｅに設定する。

その後、コマンド実行処理部は、ステップＳ１１０３からＳ１１１０までの処理を全プロセス分についてループ処理する。

ループ内において具体的には、コマンド実行処理部は、対象プロセスの最新情報を取得し（Ｓ１１０３）、ＦｕｌｌＧＣフラグがＴｒｕｅかを判定する（Ｓ１１０４）。ＦｕｌｌＧＣフラグがＴｒｕｅであれば（Ｓ１１０４，Ｙｅｓ）、コマンド実行処理部は、次のプロセスの処理に移る。

ＦｕｌｌＧＣフラグがＦａｌｓｅであれば（Ｓ１１０４，Ｎｏ）、コマンド実行処理部は、状態がＡＣＴＩＶＥまたはＳＴＡＮＤＢＹかを判定する（Ｓ１１０５）。状態がＡＣＴＩＶＥまたはＳＴＡＮＤＢＹでなければ（Ｓ１１０５，Ｎｏ）、コマンド実行処理部は、次のプロセスの処理に移る。

状態がＡＣＴＩＶＥまたはＳＴＡＮＤＢＹであれば（Ｓ１１０５，Ｙｅｓ）、コマンド実行処理部は、ＪａｖａＶＭ管理ＭＢｅａｎにＦｕｌｌＧＣを依頼する（Ｓ１１０６）。このステップＳ１１０６は、具体的には、ステップＳ１１１２〜Ｓ１１１４の処理を有する。すなわち、ＪＭＸポート番号でＪＭＸ通信による接続を行ない（Ｓ１１１２）、ＪａｖａＶＭに登録されたＪａｖａＶＭ管理ＭＢｅａｎのオペレーションを呼び出し（Ｓ１１１３）、通信の切断とＪＭＸリソース解放を行なう（Ｓ１１１４）。

ステップＳ１１０６の終了後、コマンド実行処理部は、Ｌｉｓｔｅｎｅｒが呼ばれるまで待機後（Ｓ１１０７，Ｙｅｓ）、ＦｕｌｌＧＣフラグをＴｒｕｅに設定し（Ｓ１１０８）、コマンド標準出力に結果を出力する（Ｓ１１０９）。コマンド実行処理部は、エラーが発生した場合（Ｓ１１１０，Ｙｅｓ）にはループを抜けて終了し、エラーが発生していなければ（Ｓ１１１０，Ｎｏ）、次のプロセスの処理に移る。そして、コマンド実行処理部は、全てのプロセスについて処理が終了した場合にフローを終える。

図１７は、運用中のＪａｖａＶＭによるＦｕｌｌＧＣ処理について説明するフローチャートである。ＪａｖａＶＭ管理ＭＢｅａｎが送信したＦｕｌｌＧＣイベントは、イベントキューに格納される（Ｓ１２０１）。

イベント処理部は、ＪａｖａＶＭの生存中にループする処理において、イベントキューからＦｕｌｌＧＣイベントを受信する（Ｓ１２０２）と、救済措置可能状態であり（Ｓ１２０３，Ｙｅｓ）、優先度の高い救済措置が実行中でなければ（Ｓ１２０４，Ｎｏ）、状態をＤＥＴＥＣＴＥＤ＿ＦＵＬＬＧＣに設定し（Ｓ１２０５）、ＦｕｌｌＧＣの依頼を設定する（Ｓ１２０６）。

救済機能実行部は、ＪａｖａＶＭの生存中にループする処理において、イベント処理部からＦｕｌｌＧＣの依頼をうけると、コマンドによるＦｕｌｌＧＣ依頼（以降、強制ＦｕｌｌＧＣと表す）であるかを判定する（Ｓ１２０７）。強制ＦｕｌｌＧＣであれば（Ｓ１２０７，Ｙｅｓ）、救済機能実行部は、待機中のＪａｖａＶＭを運用化するようアプリ安定サービス部に依頼する（Ｓ１２０８）。

待機中のＪａｖａＶＭの運用化は、アプリ安定稼働サービスによって対象として判断された（Ｓ１２１６）、待機中のＪａｖａＶＭに依頼される（Ｓ１２２１）。運用化の要求を受け付けた待機中のＪａｖａＶＭは、図２５に示すＦｕｌｌＧＣの実行を行なった後（Ｓ１２２２）、アプリ安定稼働サービスに運用・待機を問い合わせる（Ｓ１２２３）。

アプリ安定稼働サービスは、待機中のＪａｖａＶＭからの運用・待機の問い合わせを受けて、図１５に示した運用・待機決定処理を行なう（Ｓ１２１７）。待機中のＪａｖａＶＭは、ステップＳ１２１７の運用・待機決定処理の結果を受けてＡＣＴＩＶＥ状態を設定される（Ｓ１２２４）。

運用中のＪａｖａＶＭの救済機能実行部は、待機中の他のＪａｖａＶＭが運用化出来ると、自ＪａｖａＶＭへの新規振り分け停止をアプリ安定稼動サービス部に依頼し（Ｓ１２０９）、アプリ安定稼動サービスは、運用中のＪａｖａＶＭへの新規のみ振り分け停止処理（Ｓ１２１８）を行なう。

新規のみ振り分けの停止後、運用中のＪａｖａＶＭの救済機能実行部は、アプリケーション終了を待ち合わせ（Ｓ１２１０）、自ＪａｖａＶＭへの振り分け停止をアプリ安定稼動サービス部に依頼する（Ｓ１２１１）。アプリ安定稼動サービスは、依頼を受けて運用中のＪａｖａＶＭへの振り分け停止処理（Ｓ１２１９）を行なう。

運用中のＪａｖａＶＭの救済機能実行部は自らの状態をＦｕｌｌＧＣに設定し（Ｓ１２１２）、ＦｕｌｌＧＣを実行する（Ｓ１２１３）。ＦｕｌｌＧＣの実行後、運用中のＪａｖａＶＭの救済機能実行部は、アプリ安定稼働サービスに運用・待機を問い合わせる（Ｓ１２１４）。

アプリ安定稼働サービスは、運用中のＪａｖａＶＭからの運用・待機の問い合わせを受けて、図１５に示した運用・待機決定処理を行なう（Ｓ１２２０）。運用中のＪａｖａＶＭは、ステップＳ１２２０の運用・待機決定処理の結果を受けて状態をＡＣＴＩＶＥまたはＳＴＡＮＤＢＹに設定され（Ｓ１２１５）、処理を終了する。

図１８は、待機中のＪａｖａＶＭによるＦｕｌｌＧＣ処理について説明するフローチャートである。ＪａｖａＶＭ管理ＭＢｅａｎが送信したＦｕｌｌＧＣイベントは、イベントキューに格納される（Ｓ１３０１）。

イベント処理部は、ＪａｖａＶＭの生存中にループする処理において、イベントキューからＦｕｌｌＧＣイベントを受信する（Ｓ１３０２）と、救済措置可能状態であり（Ｓ１３０３，Ｙｅｓ）、優先度の高い救済措置が実行中でなければ（Ｓ１３０４，Ｎｏ）、状態をＤＥＴＥＣＴＥＤ＿ＦＵＬＬＧＣに設定し（Ｓ１３０５）、ＦｕｌｌＧＣの依頼を設定する（Ｓ１３０６）。

救済機能実行部は、ＪａｖａＶＭの生存中にループする処理において、イベント処理部からＦｕｌｌＧＣの依頼をうけると、強制ＦｕｌｌＧＣであるかを判定する（Ｓ１３０７）。強制ＦｕｌｌＧＣであれば（Ｓ１３０７，Ｙｅｓ）、待機中のＪａｖａＶＭの救済機能実行部は自らの状態をＦｕｌｌＧＣに設定し（Ｓ１３０８）、ＦｕｌｌＧＣを実行する（Ｓ１３０９）。ＦｕｌｌＧＣの実行後、待機中のＪａｖａＶＭの救済機能実行部は、アプリ安定稼働サービスに運用・待機を問い合わせる（Ｓ１３１０）。

アプリ安定稼働サービスは、運用中のＪａｖａＶＭからの運用・待機の問い合わせを受けて、図１５に示した運用・待機決定処理を行なう（Ｓ１３１２）。待機中のＪａｖａＶＭは、ステップＳ１３１２の運用・待機決定処理の結果を受けて状態をＡＣＴＩＶＥまたはＳＴＡＮＤＢＹに設定され、（Ｓ１３１１）、処理を終了する。

図１９は、振り分け処理の動作を説明するフローチャートである。振り分け制御部は、振り分け操作対象のＪａｖａＶＭはＷＥＢ専用かを判定する（Ｓ１４０１）。振り分け操作対象のＪａｖａＶＭがＷＥＢ専用であれば（Ｓ１４０１，Ｙｅｓ）、振り分け制御部は、仮想計算機に登録されたＷＥＢサーバを取得（Ｓ１４０２）し、自ＪａｖａＶＭが使用しているＷＥＢサーバか（Ｓ１４０３）の判定を、登録Ｗｅｂサーバインスタンス分、および登録Ｗｅｂサーバ分、ループする。

振り分け制御部は、自ＪａｖaＶＭが使用しているＷＥＢサーバであればループを抜けた後、振り分けモードを判定し（Ｓ１４０４）、振り分けモードがＯＮであれば振り分けを開始し（Ｓ１４０５）、振り分けモードがＯＦＦであれば振り分けを停止する（Ｓ１４０６）。そして、振り分けモードがＯＦＦ＿ＮＥＷであれば、新規のみ振り分けを停止して（Ｓ１４０７）、処理を終了する。

一方、振り分け操作対象のＪａｖａＶＭがＷＥＢ専用でない場合（Ｓ１４０１，Ｎｏ）、振り分け制御部は、振り分けモードを判定し（Ｓ１４０８）、振り分けモードがＯＮであれば振り分けを開始し（Ｓ１４０９）、振り分けモードがＯＦＦであれば振り分けを停止する（Ｓ１４１０）。そして、振り分けモードがＯＦＦ＿ＮＥＷであれば、新規のみ振り分けを停止して（Ｓ１４１１）、処理を終了する。

図２０は、ＪａｖａＶＭの状態遷移図と振り分け状態の説明図である。ＪａｖａＶＭは、起動されるとアプリ安定サービスによってＳＴＯＰ状態に設定され、運用中を示すＡＣＴＩＶＥと待機中を示すＳＴＡＮＤＢＹのいずれかの状態をとる。ＳＴＡＮＤＢＹの状態から運用化されると、ＡＣＴＩＶＥとなる。

ＡＣＴＩＶＥ状態でＦｕｌｌＧＣ依頼を受けると、ＡＣＴＩＶＥ状態から事象を検知したことを示すＤＥＴＥＣＴＥＤ＿ＦＵＬＬＧＣ状態となる。その後、ＤＥＴＥＣＴＥＤ＿ＦＵＬＬＧＣからＦｕｌｌＧＣ実行中であることを示すＦＵＬＬＧＣ状態に移行し、ＦｕｌｌＧＣの完了後に運用中を示すＡＣＴＩＶＥと待機中を示すＳＴＡＮＤＢＹのいずれかの状態をとる。

また、ＡＣＴＩＶＥ状態でプロセス停止依頼を受けると、ＡＣＴＩＶＥ状態から事象を検知したことを示すＤＥＴＥＣＴＥＤ＿ＳＴＯＰ状態となる。その後、プロセスを停止してＳＴＯＰ状態となる。

また、各状態で異常が発生するとＪａｖａＶＭは、異常検知を示すＡＢＮＯＲＭＡＬ状態となる。

振り分け状態は、ＯＮ、ＯＦＦ＿ＮＥＷ、ＯＦＦのいずれかの状態をとる。振り分け状態ＯＮではＪａｖａＶＭはリクエストを受け付ける。振り分け状態ＯＦＦ＿ＮＥＷではＪａｖａＶＭは新規のみリクエストを受け付けない。そして、振り分け状態ＯＦＦではＪａｖａＶＭはリクエストを受け付けない。

図２１は、仮想計算機情報記憶部が保持するデータの具体例である。仮想計算機情報記憶部が保持するＨａｓｈＭａｐは、仮想計算機識別子と対象オブジェクトの項目を関連付けて有する。図２１の例では、仮想計算機識別子１〜３を登録している。そして、仮想計算機識別子１に対応する保持オブジェクトはＪａｖａＢｅａｎｓ１＿１、仮想計算機識別子２に対応する保持オブジェクトはＪａｖａＢｅａｎｓ１＿２、仮想計算機識別子３に対応する保持オブジェクトはＪａｖａＢｅａｎｓ１＿３である。

ＪａｖａＢｅａｎｓ１＿１は、仮想計算機識別子、起動プロセス数、タイプ、待機プロセス数、Ｍａｐオブジェクトの項目を有する。仮想計算機識別子、起動プロセス数、タイプ、待機プロセス数、Ｍａｐオブジェクトの項目を有する。図２１の例では、仮想計算機識別子には「仮想計算機１」、起動プロセス数には「３」、タイプには「ＷＥＢ／ＥＪＢ」、待機プロセス数には「１」、Ｍａｐオブジェクトには「ＪａｖａＢｅａｎｓ２＿１」が登録されている。

また、ＪａｖａＢｅａｎｓ１＿１のＭａｐオブジェクトとして保持しているＪａｖａＢｅａｎｓ２＿１は、プロセス通番、ＪＭＸポート番号、プロセスＩＤ、Ｗｅｂポート番号、状態、ＦｕｌｌＧＣフラグの項目を有する。図２１に示した例では、プロセス通番「１」には、ＪＭＸポート番号「２０００１」、プロセスＩＤ「２９３５８」、Ｗｅｂポート番号「８４２１」、状態「ＡＣＴＩＶＥ」、ＦｕｌｌＧＣフラグ「Ｆａｌｓｅ」が登録されている。また、プロセス通番「２」には、ＪＭＸポート番号「２０００２」、プロセスＩＤ「２９３５９」、Ｗｅｂポート番号「８４２２」、状態「ＡＣＴＩＶＥ」、ＦｕｌｌＧＣフラグ「Ｆａｌｓｅ」が登録されている。そして、プロセス通番「３」には、ＪＭＸポート番号「２０００３」、プロセスＩＤ「２９３６１」、Ｗｅｂポート番号「８４２３」、状態「ＳＴＡＮＤＢＹ」、ＦｕｌｌＧＣフラグ「Ｆａｌｓｅ」が登録されている。

図２２は、アプリケーション終了の待ち合わせ処理について説明するフローチャートである。アプリケーション終了の待ち合わせ処理では、運用中のＪａｖａＶＭは、状態がＳＴＡＮＤＢＹまたはＡＢＮＯＲＭＡＬかを判定する（Ｓ１５０１）。状態がＳＴＡＮＤＢＹまたはＡＢＮＯＲＭＡＬである場合（Ｓ１５０１，Ｙｅｓ）、運用中のＪａｖａＶＭは、アプリケーション終了の待ち合わせ処理を終了する。

状態がＳＴＡＮＤＢＹやＡＢＮＯＲＭＡＬではない場合（Ｓ１５０１，Ｎｏ）、運用中のＪａｖａＶＭは、実行中のアプリケーション中で最後に開始したアプリケーションの開始時刻をｌａｓｔＳｔａｒｔＡｐｐＴｉｍｅとして取得する（Ｓ１５０２）。ここで最後に開始したアプリケーションが終了していた場合―１が返却され、ｌａｓｔＳｔａｒｔＡｐｐＴｉｍｅに設定される。

運用中のＪａｖａＶＭは、フラグが最初に設定されたＯＦＦのままかｌａｓｔＳｔａｒｔＡｐｐＴｉｍｅが０以上である間（Ｓ１５０３）、ループ処理を繰り返す。具体的には、１秒スリープし（Ｓ１５０４）、実行中のアプリケーション中で最後に開始したアプリケーションの開始時刻をｌａｓｔＳｔａｒｔＡｐｐＴｉｍｅとして取得する（Ｓ１５０５）。

そして、ｌａｓｔＳｔａｒｔＡｐｐＴｉｍｅが−１かつフラグがＯＦＦであるかを判定する（Ｓ１５０６）。ｌａｓｔＳｔａｒｔＡｐｐＴｉｍｅが−１かつフラグがＯＦＦである場合（Ｓ１５０６，Ｙｅｓ）、運用中のＪａｖａＶＭは、振り分けをＯＦＦに設定し、フラグをＯＮにする（Ｓ１５０７）。そして、３秒スリープし（Ｓ１５０８）、ループを抜けて処理を終了する。

一方、ｌａｓｔＳｔａｒｔＡｐｐＴｉｍｅが−１かつフラグがＯＦＦでない場合（Ｓ１５０６，Ｎｏ）、運用中のＪａｖａＶＭは、タイムアウトを超過していれば（Ｓ１５０９，Ｙｅｓ）、ループを抜けて処理を終了し、タイムアウトを超過していなければ（Ｓ１５０９，Ｎｏ）、ループを継続する。

図２３は、待機ＪａｖａＶＭの運用化依頼処理について説明するフローチャートである。運用中のＪａｖａＶＭは、待機ＪａｖａＶＭの運用化依頼を行なう場合、ｉｎｓｔａｎｃｅＮｏに−１を設定する（Ｓ１６０１）。そして、多重度が２未満であるか（Ｓ１６０２）、自ＪａｖaＶＭの状態がＳＴＡＮＤＢＹかＡＢＮＯＲＭＡＬであるかを判定する（Ｓ１６０３）。多重度が２未満である場合（Ｓ１６０２，Ｙｅｓ）や、ＳＴＡＮＤＢＹかＡＢＮＯＲＭＡＬである場合（Ｓ１６０３，Ｙｅｓ）、運用中のＪａｖａＶＭは、処理を終了する。

多重度が２未満でなく（Ｓ１６０２，Ｎｏ）、自ＪａｖａＶＭの状態がＳＴＡＮＤＢＹかＡＢＮＯＲＭＡＬでない場合（Ｓ１６０３，Ｎｏ）、運用中のＪａｖａＶＭは、ｉｎｓｔａｎｃｅＮｏが−１の間、アプリ安定稼動サービス部による処理を繰り返し呼び出す。この結果、運用化できた、または不要になった場合（Ｓ１６０４，Ｙｅｓ）に処理を終了する。運用化できておらず、不要にもなっていない場合（Ｓ１６０４，Ｎｏ）、１秒スリープして（Ｓ１６０５）、ループ処理をつづける。ループから抜けた場合には、運用ＪａｖａＶＭは他の待機ＪａｖａＶＭの運用化依頼処理を終了する。

アプリ安定稼動サービス部は、ｒｅｓｕｌｔに−１を設定し（Ｓ１６０６）、状態がＡＣＴＩＶＥとＦＵＬＬＧＣの数が多重度に等しいかを判定する（Ｓ１６０７）。状態がＡＣＴＩＶＥとＦＵＬＬＧＣの数が多重度に等しい場合（Ｓ１６０７，Ｙｅｓ）、アプリ安定稼動サービス部は、運用中のＪａｖａＶＭに運用化が不要であることを示す−２を返して（Ｓ１６１５）、処理を終了する。

状態がＡＣＴＩＶＥとＦＵＬＬＧＣの数が多重度に等しくない場合（Ｓ１６０７，Ｎｏ）、アプリ安定稼動サービス部は、多重度から設定待機数を引いた値がＡＣＴＩＶＥ数よりも大きいかを判定する（Ｓ１６０８）。多重度から設定待機数を引いた値が現在のＡＣＴＩＶＥ数以下である場合（Ｓ１６０８，Ｎｏ）、アプリ安定稼動サービス部は、運用中のＪａｖａＶＭに運用化が不要であることを示す−２を返して（Ｓ１６１５）、処理を終了する。

多重度から設定待機数を引いた値がＡＣＴＩＶＥ数よりも大きいか場合（Ｓ１６０８，Ｙｅｓ）、アプリ安定稼動サービス部は、ステップＳ１６０９〜Ｓ１６１３の処理を全ＪａｖａＶＭ分ループする。

すなわち、アプリ安定稼動サービス部は、呼び出したＪａｖａＶＭ自身ではなく（Ｓ１６０９，Ｎｏ）、状態がＳＴＡＮＤＢＹである（Ｓ１６１０，Ｙｅｓ）ＪａｖａＶＭについて、待機ＪａｖａＶＭへのＡＣＴＩＶＥ化の指示を行なう（Ｓ１６１１）。そして、図１５に示した運用・待機決定処理（Ｓ１６１２）を行なって、運用化された場合（Ｓ１６１３，Ｙｅｓ）には運用化されたＪａｖａＶＭのプロセス通番を返却して（Ｓ１６１４）、処理を終了する。

図２４は、ＦｕｌｌＧＣ実行時のＪａｖａＶＭと振り分け状態の遷移についての説明図である。図２４において、初期状態では、プロセス通番「１」についてＪａｖａＶＭ状態が「ＡＣＴＩＶＥ」、振り分け状態が「ＯＮ」となっている。また、プロセス通番「２」についてＪａｖａＶＭ状態が「ＳＴＡＮＤＢＹ」、振り分け状態が「ＯＦＦ」となっている。同様に、プロセス通番「３」についてＪａｖａＶＭ状態が「ＳＴＡＮＤＢＹ」、振り分け状態が「ＯＦＦ」となっている。そして、プロセス通番「４」についてＪａｖａＶＭ状態が「ＡＣＴＩＶＥ」、振り分け状態が「ＯＮ」となっている。

この状態からＦｕｌｌＧＣを受け付けると、まずプロセス通番「１」のＪａｖａＶＭ状態が「ＤＥＴＥＣＴＥＤ＿ＦＵＬＬＧ」となる。そして、待機状態であったプロセス通番「２」が運用化され、プロセス通番「２」のＪａｖａＶＭ状態が「ＡＣＴＩＶＥ」、振り分け状態が「ＯＮ」となる。

その後、プロセス通番「１」について新規のみ振り分けが停止し、プロセス通番「１」の振り分け状態が「ＯＦＦ＿ＮＥＷ」となる。さらに、アプリケーション終了を待って振り分けを停止することで、プロセス通番「１」の振り分け状態が「ＯＦＦ」となる。

そして、プロセス通番「１」はＦｕｌｌＧＣを開始してＪａｖａＶＭ状態が「ＦＵＬＬＧＣ」となる。ＦｕｌｌＧＣ終了後、プロセス通番「１」は運用・待機決定処理によって待機化され、ＪａｖａＶＭ状態が「ＳＴＡＮＤＢＹ」となる。そして、２つ目、すなわちプロセス通番「２」のＪａｖａＶＭのＦｕｌｌＧＣ処理に移行する。

図２５は、待機ＪａｖａＶＭを運用化した際のＦｕｌｌＧＣ処理について説明するフローチャートである。具体的には、ＦｕｌｌＧＣを実行すると（Ｓ１７０１）、ＦｕｌｌＧＣフラグをＴｒｕｅに設定する（Ｓ１７０２）。通常ＪａｖａＶＭは１時間に１回など、定期的にＦｕｌｌＧＣが走るようになっている。これに対し、実施例２のシステムでは、Ｊａｖａ自身が自動で勝手に行わないようにＦｕｌｌＧＣの実行を制限している。また、ＳＴＡＮＤＢＹの状態で全く振り分けられない状態であっても一定時間以上経過すると、ＲＭＩ等のリソースを使用し続けるため、ＡＣＴＩＶＥ化の際には、必ずＦｕｌｌＧＣを行なうように実装している。

上述したように実施例２にかかる計算システム２は、ＦｕｌｌＧＣを受け付けたＪａｖａＶＭが、新規のみ振り分け停止、アプリケーション終了待ち、振り分け停止を行なう。その後、ＦｕｌｌＧＣが実行される事でＦｕｌｌＧＣを受け付けた前後にリクエストされたアプリケーションの実行を保証する。

また、ＦｕｌｌＧＣを受け付けたＪａｖａＶＭの代わりに、待機用に設定された他のＪａｖａＶＭを運用化させる仕組みを有する。そして、待機ＪａｖａＶＭが複数存在している時には、どれを運用化させるか判断する仕組みと、同じＪａｖａＶＭに対して何度もＦｕｌｌＧＣを行わない仕組みを有する。すなわち、待機中にＦｕｌｌＧＣを行なえば、ＦｕｌｌＧＣフラグがＴｒｕｅとなり、待機状態から運用状態に変更する際のＦｕｌｌＧＣをスキップすることができる。

このため、実施例２にかかる計算システム２では、仮想計算機上で設定数分のＪａｖａＶＭが起動され、１つ以上の待機ＪａｖａＶＭを設定しておくことにより、ＦｕｌｌＧＣを実行した場合でも運用ＪａｖａＶＭ数は常に保たれる。かつ、ＦｕｌｌＧＣを行う際に、処理中のアプリケーションが存在する場合は完了するまで待機を行い、一つずつ順番に処理を行っていくため、リクエストに対するスループットは低下することなく、全てのＪａｖａＶＭに対して資源解放処理が実施されることになる。

したがって、実施例２に開示した構成および動作によって、ガーベジコレクション実行時におけるアプリケーション処理の負荷を軽減することができる。

１〜３ 計算システム
１ａ，１ｂ，１ｃ，３ａ 計算機
１１〜１６，７１〜７３ 仮想計算機
２１〜２３，９５ アプリケーション
３１〜３３ 監視エージェント
４１〜４３ 安定稼働エージェント
５１〜５３ 情報記憶部
６１ 事象検知イベント受信部
６２ 救済措置実行部
８１ オペレーティングシステム
８２ 実行環境プログラム
９０ コマンド実行処理部
９１ 管理サーバ
９２ アプリ安定稼働サービス部
９２ａ 仮想計算機情報記憶部
９３ 振り分け制御部
９６ アプリ安定稼働機能部
９６ａ ＭＢｅａｎ処理部
９６ｂ イベント処理部
９６ｃ 救済機能実行部
９７ ＪａｖａＶＭ監視部
１００〜１０３ 負荷分散装置
１１０ 端末群
１２０ ネットワーク
１３０ 運用管理装置

Claims (5)

1. 複数の計算機に計算処理を配分する計算システムであって、
   ガーベジコレクションまたは計算機の再起動の実行を指示する実行指示部を備え、
   計算処理を実行可能な運用状態の計算機は、
   ガーベジコレクションまたは計算機の再起動の実行を指示された場合に、待機中の他の計算機が存在すれば、前記待機中の他の計算機に運用開始を依頼し、前記複数の計算機に計算処理を配分する負荷分散装置に対して、ガーベジコレクションまたは計算機の再起動の実行を指示された計算機に対する新規リクエストの計算処理の振り分け停止を依頼する第１の依頼部と、
   処理中のリクエストに対する残存処理が終了した場合、前記負荷分散装置に対して、前記ガーベジコレクションまたは計算機の再起動の実行を指示された計算機に対する全リクエストの計算処理の振り分け停止を依頼する第２の依頼部と
   を有することを特徴とする計算システム。
2. 前記実行指示部は、前記計算処理が配分される前記複数の計算機とは異なる計算機に設けられることを特徴とする請求項１に記載の計算システム。
3. 前記複数の計算機は、オペレーティングシステムで動作する仮想計算機であり、前記オペレーティングシステム上に複数実行可能であることを特徴とする請求項１または２に記載の計算システム。
4. 前記負荷分散装置は、前記ガーベジコレクションまたは計算機の再起動の実行を指示された計算機からの新規リクエストの計算処理の振り分け停止の依頼に応じて、当該計算機に対する新規リクエストの計算処理の振り分けを停止し、前記新規リクエストの計算処理を他の計算機に振り分け、前記ガーベジコレクションまたは計算機の再起動の実行を指示された計算機から、前記ガーベジコレクションまたは計算機の再起動の実行を指示された計算機から全リクエストの計算処理の振り分け停止を依頼された場合に、当該計算機に対して全リクエストの計算処理の振り分けを停止することを特徴とする請求項１〜３のいずれか１つに記載の計算システム。
5. 複数の計算機に計算処理を配分する計算システム管理方法であって、
   実行指示部が、ガーベジコレクションまたは計算機の再起動の実行を指示し、
   計算処理を実行可能な運用状態の計算機が、
   ガーベジコレクションまたは計算機の再起動の実行を指示された場合に、待機中の他の計算機が存在すれば、前記待機中の他の計算機に運用開始を依頼し、前記複数の計算機に計算処理を配分する負荷分散装置に対して、ガーベジコレクションまたは計算機の再起動の実行を指示された計算機に対する新規リクエストの計算処理の振り分け停止を依頼し、
   処理中のリクエストに対する残存処理が終了した場合、前記負荷分散装置に対して、前記ガーベジコレクションまたは計算機の再起動の実行を指示された計算機に対する全リクエストの計算処理の振り分け停止を依頼する
   処理を実行することを特徴とする計算システム管理方法。

Images