(57)【要約】【課題】  障害前後の性能の不変性と障害後の可用性向上を同時に実現する際に、障害前のサーバと障害後のサーバが、ＣＰＵ性能、ＣＰＵ数、Ｉ／Ｏ性能などの点で、同じでないことがあること、アプリケーションの移行先のサーバでも、他のアプリケーションが既に稼動していることがあるため、アプリケーション移行後の性能が予測できない。【解決手段】  サーバの正常稼動時に各アプリケーションの要求性能を取得し、サーバ稼動時におけるサーバの提供性能を取得し、サーバの障害発生時に、アプリケーションを移行できる構成を有するサーバを特定し、要求性能情報と提供性能情報とを比較することにより、アプリケーション実行性能が最も近いサーバを特定し、一定の可用性を満たすサーバを特定する。【選択図】  図２
2005234917.tif 000002
【特許請求の範囲】
【請求項１】
サーバの障害時にアプリケーションの移行先のサーバを決定する方法において、
サーバの正常稼動時に各アプリケーションの要求性能を取得し、
サーバ稼動時におけるサーバの提供性能を取得し、
アプリケーションを移行できる構成を有するサーバの候補を抽出し、
前記要求性能情報と前記提供性能情報とを比較することによりアプリケーション実行性能が近いサーバを特定し、
前記特定したサーバの中から、サーバ移行後の負荷の変化が少ないサーバをアプリケーションの移行先のサーバとして決定することを特徴とする障害時のサーバ決定方法。
【請求項２】
サーバの障害時に、前記サーバで稼動していたアプリケーションを他のサーバへ移行するシステムにおいて、障害前後のアプリケーション性能の変化を最小化し、かつ、障害後の可用性を高めることを特徴とする障害時のサーバ方法。
【請求項３】
サーバの障害時にアプリケーションの移行先のサーバを決定する方法において、
プログラムの実行多重度を変えながら種々の特性を持ったテストプログラムを実行することにより、サーバの正常稼動時に各アプリケーションの要求性能を取得し、
サーバ稼動時におけるサーバの提供性能を取得し、アプリケーションを移行できる構成を有するサーバの候補を抽出し、
前記要求性能情報と前記提供性能情報とを比較することによりアプリケーション実行性能が近いサーバを特定し、
前記特定したサーバの中から、サーバ移行後の負荷の変化が少ないサーバをアプリケーションの移行先のサーバとして決定することを特徴とする障害時のサーバ決定方法。
【請求項４】
前記テストプログラムは、プログラムの実行多重度を変えながら、実行形態の異なるプログラムを少なくとも１つのサーバのそれぞれで実行したときの経過時間を測定することを特徴とする請求項３記載の障害時のサーバ決定方法。
【請求項５】
前記要求性能の取得の際に、少なくとも１つのサーバのそれぞれにおいて、前記アプリケーションで実行を中断して、前記アプリケーションのそれぞれに対応する実行多重度で前記テストプログラムを実行することを特徴とする請求項３記載の障害時のサーバ決定方法。
【請求項６】
前記提供性能の取得の際に、少なくとも１つのサーバのそれぞれについて、取りうる実行多重度のそれぞれに対して前記テストプログラムを実行することを特徴とする請求項３記載の障害時のサーバ決定方法。
【請求項７】
前記サーバ候補の抽出の際に、前記アプリケーションの要求性能に近いサーバ候補を抽出し、前記サーバ候補の中から、性能差と障害発生確率とに基づいた性能差評価によりサーバを決定することを特徴とする請求項３記載の障害時のサーバ決定方法。
【請求項８】
前記テストプログラムの実行形態は、並列化可能でＣＰＵのみを使用するプログラム、並列化不可能でＣＰＵのみを使用するプログラム、同時アクセス可能なディスクへの入出力を実行するプログラム、及び同時アクセス不可能なディスクへの入出力を実行するプログラムの少なくとも１つであることを特徴とする請求項３記載の障害時のサーバ決定方法。
【請求項９】
サーバの正常稼動時に各アプリケーションの要求性能情報を取得し、サーバ稼動時におけるサーバの提供性能情報を取得し、サーバの障害発生時に、アプリケーションを移行できる構成を有するサーバを特定し、前記要求性能情報と前記提供性能情報とを比較することにより、アプリケーション実行性能が最も近いサーバを特定し、一定の可用性を満たすサーバを特定することを特徴とする障害時のサーバ決定方法。
【請求項１０】
通信手段を介して互いに接続された複数のサーバが接続された計算機システムにおいて、前記複数のサーバの１つは、
前記複数のサーバのそれぞれの正常稼動時に各アプリケーションの要求性能情報を取得する手段と、
前記複数のサーバのそれぞれの稼動時におけるサーバの提供性能情報を取得する手段と、
前記複数のサーバのいずれかの障害発生時に、アプリケーションを移行できる構成を有するサーバを特定する手段と、
前記要求性能情報と前記提供性能情報とを比較することにより、前記特定したサーバの中から、アプリケーション実行性能が最も近いサーバを特定する手段とを有することを特徴とする計算機システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバの障害時にアプリケーションの最適な移行先のサーバを決定する方法に関する。
【背景技術】
【０００２】
近年、アプリケーションのクラスタリングにより性能向上と高可用性を実現することが増えている。特に、ＳＡＮ(Storage Area Network)を利用したクラスタシステムでは、フェイルオーバやカスケードフェイルオーバによる障害時の継続運用を実現している。
【０００３】
ＳＡＮではクラスタを構成する複数のサーバが同じストレージにアクセスすることが容易になる。これにより、障害が起きたサーバの切り換え先が柔軟に変更できるようになってきている。
【０００４】
具体的には、複数のサーバに対して数台のスペアサーバを用意し、特定のサーバに障害が発生した場合に、アプリケーションをスペアサーバへ移行させる技術がある（例えば、特許文献１参照）。また、スペアサーバを用意していない場合でも、障害が発生していたサーバ上でのアプリケーションを稼動中の他のサーバ上で動作させることも可能になっている。また、稼動中のサーバへアプリケーションを移行する際に、稼動中の複数のサーバからワークロードの低いものを選ぶ機能を取り入れた製品として、例えば、Ｖｅｒｉｔａｓ社のＣｕｌｕｓｔｅｒ  Ｓｅｒｖｅｒ（文献：VERITAS White Paper、Managing Application Availability with Application Clustering and the VERITAS Cluster Server2.0））がある（非特許文献１参照）。
【０００５】
【特許文献１】米国特許第５８５２７２４号
【非特許文献１】VERITAS White Paper、Managing Application Availability with Application Clustering and the VERITAS Cluster Server2.0
【発明の開示】
【発明が解決しようとする課題】
【０００６】
稼動中のサーバへアプリケーションを移行する場合、負荷増加による稼動中のアプリケーションに与える性能面での影響がある。さらに、これを問題にしない場合でも、移行先のサーバが移行するアプリケーションが必要とする計算機資源を保有しているかどうかという問題がある。
【０００７】
負荷分散としては、負荷が最も少ないサーバへアプリケーションを移行するという方法も実装例は少ないがすでにある。また、例えばＨＴＴＰの通信の応答時間などからサーバの負荷を推測しているような従来技術もあるが、応答時間が短いサーバへアプリケーションを移行したとしても、実際にアプリケーションを実行した時に、応答時間が本当に期待したものになるかわからない。
【０００８】
アプリケーションには、ＣＰＵバウンドやＩ／Ｏバウンドなどの特性があるため、単純にＣＰＵビジー率やＨＴＴＰなどによる通信の応答時間だけから負荷を推測しても、目的のアプリケーションを動作させたときに、常に期待した応答時間が得られる保証はない。
【０００９】
さらに、フェイルオーバ時の切り換え先は、負荷が最も少ないサーバより、その業務を障害前の性能と同等の状態で継続した方が望ましいことがある。例えば、ロードバランサによる負荷分散が行われているような場合、切り換え先の性能がより高ければ、ロードバランサによってはリソースに余裕があると検知し、要求の割当量を増大させる可能性がある。しかし、このような事態は、今までのユーザに対する応答が遅くなるので、多くのユーザにとって望まない結果である。そもそも、障害を契機にあるアプリケーションの性能が向上するというのは明らかに不自然である。障害時のフェイルオーバと負荷分散とでは異なる対応が必要である。
【００１０】
一般に、障害による、アプリケーションの他のサーバへの移行においては、性能も含め、（可用性を除き）すべてにおいて障害発生前後で変化が少ないほど安全面で優位である、と考えられる（障害発生前後の不変性を最大限保つ）。これは、少しでも早くアプリケーション実行を終了させようとする負荷分散の考え方とは対照的である。また、アプリケーションを他のサーバへ移行する際には、可能な限り信頼性の高い（障害発生確率が低い）サーバを選ぶべきである。
【００１１】
従来技術には、このような障害発生前後の性能の不変性と障害後の可用性向上を同時に実現するものはない。特に、障害発生前後の性能の不変性を保つための方法は、技術的に困難があった。これは、障害前のサーバと障害後のサーバが、ＣＰＵ性能、ＣＰＵ数、Ｉ／Ｏ性能などの点で、同じでないことがあること、アプリケーションの移行先のサーバでも、他のアプリケーションが既に稼動していることがあるため、アプリケーション移行後の性能が予測できないためである。
【００１２】
本発明の目的は、サーバの障害時に、障害発生前後の性能の不変性と障害後の可用性向上を同時に実現しながら、アプリケーションの最適な移行先のサーバを決定する方法を提供することにある。
【課題を解決するための手段】
【００１３】
本発明の目的を達成するため、サーバの障害時にアプリケーションの移行先のサーバを決定する方法において、プログラムの実行多重度を変えながら種々の特性を持ったテストプログラムを実行することにより、サーバの正常稼動時に各アプリケーションの要求性能を取得し、サーバ稼動時におけるサーバの提供性能を取得し、アプリケーションを移行できる構成を有するサーバの候補を抽出し、要求性能情報と提供性能情報とを比較することによりアプリケーション実行性能が近いサーバを特定し、特定したサーバの中から、サーバ移行後の負荷の変化が少ないサーバをアプリケーションの移行先のサーバとして決定する。
【発明の効果】
【００１４】
サーバ障害によりこのサーバで動作していたアプリケーションを他のサーバへ移行する（フェイルオーバする）際、移行前後でアプリケーションの性能の変化を少なくする。つまり、障害の前後で、可用性は別にしても、可能な限り性能が不変であるようにすることができる。特に、アプリケーションごとに最も適した性能を維持することができる。
【００１５】
障害の起きていなかった他のサーバへの影響も抑えながら、障害の発生したサーバ上で動作していたアプリケーションの他のサーバへの移行が可能となる。
【００１６】
また、障害情報に基づいて、障害発生頻度が高いサーバやサーバのハードウェアの寿命について管理している。これにより、切り換え先を決定の際に、障害がおきにくいサーバから優先して選ぶことができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明における実施例を、図面を用いて詳しく説明する。
【００１８】
図１は本発明を実施するサーバの構成を示した図である。図１によれば、サーバ１０１は１つ以上のＣＰＵ（例えば、１０５ａ、１０５ｂ）、メモリ１０１、ハードディスク１０６、及び、１つ以上のネットワークインタフェース（例えば、１１１ａ、１１１ｂ）を含む。ハードディスクには、オペレーティングシステム１０７、アプリケーションプログラム（例えば１０８、１０９）、及び、プログラム用データ１１０が含まれている。サーバ稼動時は、オペレーティングシステム１０２、アプリケーションプログラム１０３、プログラム用データ１０４などがメモリ１０１に読み込まれている。サーバは、ネットワークインタフェース（例えば、１１１ａ、１１１ｂ）を介してＬＡＮ１１２と接続されている。本発明は、以降で詳しく説明するプログラムにより、サーバを動作させることにより実施される。
【００１９】
図２は、本発明を実施する、サーバ群、ディスク群の全体の構成図である。図２によれば、複数のサーバ（２０３ａ〜２０３ｇ）がＬＡＮ２０２に接続され、外部ネットワーク２０１と接続されている。障害管理対象サーバ群（２０３ａ〜２０３ｇ）上では、複数のアプリケーションが実行されている。アプリケーションの中には２つ以上のサーバによるクラスタで動作するものや単体サーバ上で動作するものなどが混在している。また、１つのサーバ上で２つ以上の異なるアプリケーションが動作していることもある。サーバは、シングルプロセッサやマルチプロセッサ（共有メモリ及び非共有メモリ）等、さまざまな種類のハードウェアが混在できる。ＯＳも複数の異なるＯＳが混在できる。
【００２０】
本発明は、アプリケーション及びサーバの障害を管理するものであるが、障害管理対象のアプリケーションは単体のサーバ（例えば図1の２０３ｆ）で実行されることもあれば、複数のサーバからなるクラスタ（例えば、２０４、２０５）で動作することもある。サーバ２０３ａ〜２０３ｇはすべて、ＳＡＮ（例えば２０７ａ、２０７ｂ）を通じて、ディスク２０６ａ〜２０６ｇに接続されている。
【００２１】
説明を明確にするため、ここでは、サーバ２０３ｇを障害管理サーバ、サーバ２０３ａからサーバ２０３ｆまでを障害管理対象のサーバとする。管理対象のサーバ（サーバ２０３ａからサーバ２０３ｆ）上では、性能情報を取得するためのプログラムを起動する（性能情報取得プログラム）。このプログラムは、決められたテストプログラムを動作させ、その経過時間を測定することで、そのサーバの性能情報を取得する。性能情報の測定は一定の時間間隔で実行される。
【００２２】
取得する性能には、次の２タイプの性能がある。
１）要求性能：現在稼動中のアプリケーションが利用している実効的な性能である。この性能を測定するために、このアプリケーションを一時停止あるいはサスペンドして、上記の性能情報取得プログラムを実行する。このプログラムの結果として得られた経過時間をサーバにおけるアプリケーションの要求性能情報と呼ぶことにする。
２）提供性能：サーバ上で新たにアプリケーションを起動した場合に、アプリケーションに提供できる実効的な性能である。この性能情報は、単に、性能測定対象のサーバ上で上記性能情報取得プログラムを実行することで得られる。結果として得られた経過時間をサーバにおける提供性能情報と呼ぶことにする。
【００２３】
取得された性能情報は、障害管理サーバ２０３ｇが参照できるディスク２０６ａに記録される。また、一方で、ハートビートなどの既にある技術により、ＬＡＮを介した通信による管理対象サーバ（サーバ２０３ａからサーバ２０３ｆ）の障害チェック（ヘルスチェック）を行っているものとする。
【００２４】
ディスク２０６ａは、障害管理用テーブル格納域２０８を含む。障害管理用テーブルは、障害管理対象サーバ群（２０３ａ〜２０３ｆ）および障害管理サーバ２０３ｇがアクセス可能である必要がある。
【００２５】
障害発生時など、既にアプリケーションが稼動中の他のサーバ上での実行に切り換える際には、障害管理サーバ２０３ｇが、ディスク２０６ａのテーブル格納域２０８のテーブルを利用して、最適な切り換え先のサーバを決定する。
【００２６】
障害管理用テーブル格納域２０８には、提供性能テーブル２０９、要求性能テーブル２１０、サーバ構成情報テーブル２１１、アプリケーション資源情報テーブル２１２、アプリケーション特性情報テーブル２１３、障害情報テーブル２１４が含まれる。
【００２７】
提供性能テーブル２０９の詳細は、図１０に示す。要求性能テーブル２１０の詳細は、図９に示す。サーバ構成情報テーブル２１１の詳細は、図１２に示す。アプリケーション資源情報テーブル２１２の詳細は、図１３に示す。アプリケーション特性情報テーブル２１３の詳細は、図１１に示す。障害情報テーブル２１４の詳細は、図１４に示す。
【００２８】
図９はアプリケーションの要求性能テーブル９０１である。このテーブルの属性には、サーバ識別子９０２、アプリケーション識別子９０３、多重度９０４、性能情報１（９０５）〜性能情報４（９０８）がある。このテーブルから、あるサーバで動作しているあるアプリケーションについて、そのアプリケーションが利用できている計算機資源がどれだけあるかを知ることができる情報である。例えば、図９の行９０９について、サーバ識別子Ｓ１のサーバのアプリケーションＡ１は、テストジョブ１〜４を多重度２で実行した場合に、測定結果（性能情報１〜４）がＴ２１、Ｔ２２、Ｔ２３、Ｔ２４であるような計算機資源を利用していると見ることができる。
【００２９】
図１０は、提供性能テーブル１００１である。これは、あるサーバについて、現在利用できる計算機資源を示す。つまり、このサーバで新たにアプリケーションを起動する場合、そのアプリケーションが現在のそのサーバ上で利用できる実効的な計算機能力を示すものである。例えば、図１０の行１００８では、サーバ識別子Ｓ２のサーバは、実行多重度１で前記の性能情報取得プログラムを実行した場合に、テストプログラム１〜４の実行結果（経過時間）がＵ３１、Ｕ３２、Ｕ３３、Ｕ３４になるような計算機能力が、そのサーバで利用できる（提供される）ことを示している。
【００３０】
図１１はアプリケーションの性能面における特徴及び可用性面での要求を示した、アプリケーション特性テーブル１１０１である。まず性能面での特徴を図１１の重み値１１０３〜１１０６で示している。この値は、テストプログラムの特性に対応して、Ｉ／Ｏバウンド、ＣＰＵバウンド、並列実行可能、並列実行不可能といったアプリケーションの特徴を定量的に表すことを可能にするテーブルである。例えば、Ｉ／Ｏバウンドであれば、重み３及び重み４の属性値を大きくする。ＣＰＵバウンドであれば、重み１及び重み２の属性値を大きくする。並列実行可能なプログラムであれば、重み１及び重み３の属性値を大きくするなどである。これにより、管理対象のアプリケーションが複数あり、それぞれの特徴が異なっていても、障害が発生した複数のアプリケーションに対して、それぞれの特性に応じた適切な移行先を決定することが可能となる。図１１の連続実行時間１１０７及び障害発生率上限値１１０８は、アプリケーションを連続実行する時間とそれに対して設定する障害発生確率の上限値である。
【００３１】
図１２のサーバ構成情報テーブルには、各サーバの構成に関する情報（静的な情報）が、サーバを構成する資源の種類ごとに記憶されている。この情報には、アクセス可能なディスクの識別子情報、利用できるアプリケーションの一覧情報、及び、利用できるＮＩＣ（ネットワークインタフェースカード）の一覧情報が含まれている。図１２中の各テーブルの詳細については後述する。
【００３２】
図１３はアプリケーション資源情報テーブル１３０１であり、各行１３０７にはサーバ識別子１３０２のサーバ上で動作しているアプリケーション１３０３が必要とするディスクリソースの一覧１３０４、ＩＰアドレスの一覧１３０５、及び、メモリ使用量１３０６が含まれている。
【００３３】
図１４は、障害情報管理テーブル１４０１である。各サーバの障害関連情報が保存されている。このテーブルの属性には、偶発的な障害の確率を記述するための偶発故障率λ（１４０３）、計算機の寿命を確率的に説明する、ワイブル分布のパラメータである係数ａ（１４０４）係数ｂ（１４０５）がある。
【００３４】
また、その製品（サーバ）が製造されてからの経過時間１４０６とアプリケーション起動後（障害回復による再起動後も含める）の経過時間１４０７を記憶している。
【００３５】
図３及び図４は、管理サーバ（図２のサーバ２０３ｇ）及び管理対象サーバ（図２のサーバ２０３ａからサーバ２０３ｆ）で共通して動作する、性能取得プログラムのフローチャートである。このプログラムには、テストプログラムを実行する実行多重度ｎが入力として与えられる。
【００３６】
ステップ３０１では、並列化可能でＣＰＵのみ使用するプログラム（テストプログラム１）を多重度ｎで一斉に実行する。ステップ３０２では、経過時間の測定を開始する。ステップ３０３で、多重度ｎのすべてのテストプログラム１が終了したらステップ３０４へ移行し、終了していなければ、再びステップ３０３へ戻り、終了を待つ。ステップ３０４では、経過時間を変数Ｔ１に設定する。ここで、テストプログラム１は、演算、比較等のＣＰＵのみを使用する処理だけを含むように人為的に作ったプログラムである。並列化可能とは、共有資源を利用せず、サーバがマルチプロセッサタイプである場合に、複数のＣＰＵで処理を並列実行可能であるということである。
【００３７】
ステップ３０５では、並列化不可能でＣＰＵのみ使用するプログラム（テストプログラム２）を多重度ｎで一斉に実行する。ステップ３０６では、経過時間の測定を開始する。並列化不可能なプログラムとは、２以上の多重度で一斉に処理を実行しても、共有資源を利用する等の理由で並列実行できないプログラムである。ステップ３０７で、多重度ｎのすべてのテストプログラム２が終了したらステップ３０８に移行し、終了していなければ、再びステップ３０７へ戻り、終了を待つ。ステップ３０８では、経過時間を変数Ｔ２に設定する。
【００３８】
ステップ３０９で、同時アクセス可能なディスクへの入出力を実行するプログラム（テストプログラム３）を多重度ｎで一斉に実行する。ここで、テストプログラム３は、２以上の多重度で処理を実行した場合に、排他待ちが起きないように、異なるデータにアクセスするプログラムである。ステップ３１０では、経過時間の測定を開始する。ステップ３１１では、すべてのテストプログラム３が終了したら、ステップ３１２に移行し、終了していなければ、再びステップ３１１へ戻り、終了を待つ。ステップ３１２において、経過時間を変数Ｔ３に設定する。
【００３９】
ディスクへのアクセスは、一回あたりのデータアクセス量などに依存する。また、通常、書き込みと読み込みとでは、そのアクセス速度が異なっている。したがって、一回あたりのデータ量を変えたテストプログラムや、書き込みのみまたは読み込みのみのテストプログラムを作成し、テストプログラム３の代わりにこのテストプログラムを利用することでさらに詳細な性能データを得るように拡張することも容易に実現可能である。
【００４０】
ステップ３１３では、同時アクセス不可能なディスクへの入出力を実行するプログラム（テストプログラム４）を多重度ｎで一斉に実行する。ここで、テストプログラム４は２以上の多重度で実行した場合に、同じデータにアクセスさせることで、並列で入出力ができないようなプログラムである。ステップ３１４では、経過時間の測定を開始する。ステップ３１５では、すべてのテストプログラム４が終了したらステップ３１６に移行し、終了していなければ、再びステップ３１５へ戻り、終了を待つ。ステップ３１６において経過時間を変数Ｔ４に設定する。
【００４１】
上記に説明した性能情報取得プログラムの実行結果として、実行形態の異なる４つのテストプログラム１〜４による４つの経過時間、Ｔ１、Ｔ２、Ｔ３、Ｔ４が得られる。これらの値は、性能取得プログラムを呼び出した、プログラムへ与えられる。
【００４２】
図５は、管理対象サーバ（図２のサーバ２０３ａからサーバ２０３ｆ）のすべての管理対象サーバ上で動作する要求性能測定プログラムを説明するフローチャートである。
【００４３】
ステップ５０１において、要求性能情報テーブル（図９の９０１）から、要求性能測定プログラムを実行しているサーバ上で動作しているアプリケーションの一覧を取得する。ステップ５０２で、これらアプリケーション一覧から１つのアプリケーションを選択する。ステップ５０３で、要求性能情報テーブル（図９の９０１）の多重度９０４からアプリケーションに対応する実行多重度の一覧を作成する。
【００４４】
ステップ５０４で、多重度一覧から１つの多重度ｎを選択する。ステップ５０５では、ステップ５０２で選択したアプリケーションのプロセスを一時停止（サスペンド）する。ステップ５０６で、多重度ｎを指定して、性能情報取得プログラム（図３及び図４のフローチャート）を実行する。ステップ５０７で、結果として得られた経過時間Ｔ１〜Ｔ４を要求性能情報テーブル（図９の９０１）の性能情報１〜４にそれぞれ記憶する。ステップ５０８では、一時停止（サスペンド）させたアプリケーションのサスペンドを解除する。
【００４５】
ステップ５０９では、実行多重度一覧のすべての多重度について要求性能情報を取得し終えたら処理をステップ５１０に移行し、そうでなければ、ステップ５０４に戻り、実行多重度一覧にあって、実行していない多重度を選択する。ステップ５１０では、すべての管理対象アプリケーションについて要求性能情報を取得した場合、要求性能の測定プログラムを終了し、そうでなければステップ５０２に戻り、管理対象アプリケーション一覧からまだ測定していない１つのアプリケーションを選択する。
【００４６】
図６は、管理対象サーバ（図２のサーバ２０３ａからサーバ２０３ｆ）のすべてのサーバ上で動作する提供性能測定プログラムを説明するフローチャートである。
【００４７】
ステップ６０１では、要求性能情報テーブル（図９のテーブル９０１）における実行多重度９０４のすべての値から重複を除いた実行多重度の一覧を得る。例えば、図９の場合、実行多重度一覧は、｛１、２、４、８｝である。
【００４８】
ステップ６０２では、多重度一覧の中から１つの値ｎを選択する。ステップ６０３で、多重度ｎを指定して、性能情報取得プログラム（図３及び図４）を実行する。ステップ６０４で、結果として得られた性能情報を要求性能情報テーブル１００１（図１０）に記憶する（例えば、図１０の行１００８を更新する）。ステップ６０５では、多重度一覧のすべての値でテストが終了していれば提供性能測定プログラムを終了し、そうでなければステップ６０２に戻る。
【００４９】
要求性能情報と提供性能情報を取得するタイミングはさまざまである。特に要求性能を取得するためには、わずかな時間でもアプリケーションを一時停止（サスペンド）する必要があるため、測定間隔を長くする方がよい。上記２つの測定間隔は実際には、ユーザ等によって適宜決定される。また、性能情報の時間的な変化が大きい場合は、一定時間内に測定された複数回の測定データの平均をとるなど回避策がある。
【００５０】
図７は、アプリケーションの移行先を決定するアプリケーション移行先決定プログラムを説明するフローチャートである。本プログラムは、図８で説明する障害管理プログラムが、アプリケーション障害を検知した場合や、アプリケーション障害でない場合でも、可用性の低下を検知した場合に呼び出される。本プログラムはサーバ識別子及びアプリケーション識別子を入力情報とする。
【００５１】
図７によれば、ステップ７０１で、サーバ構成情報テーブル（図１２）の「利用できるアプリケーション一覧」（例えば、図１２のテーブル１２０９）から、障害発生したアプリケーションを起動可能なサーバの一覧表（一覧表Ａ１２０１）を作成する。ステップ７０２で、サーバ構成情報テーブル（図１２）のアクセス可能なディスク識別子（例えば、図１２の１２０３、１２０５）とアプリケーション資源情報テーブル（図１３）から、障害発生したアプリケーションがアクセスを必要としたディスクにアクセス可能なサーバをすべて探し、一覧表Ｂ１２０７に出力する。ステップ７０３では、図９の要求性能情報テーブル、図１０の提供情報テーブル、図１１のアプリケーション特性情報テーブルを利用して、一覧表Ｂ１２０７のサーバ群をアプリケーションの要求性能に近い順に並び替えた一覧表Ｃ１２１３を作成する。この並び替えでは、以下の性能差の評価式を定義する。
【００５２】
【数１】
2005234917.tif 000003
ただし、Ｔ(ｓ、ａ、ｎ、ｋ)はサーバ識別子ｓのサーバにおいて、アプリケーション識別子ａのアプリケーションを一時停止（サスペンド）した状態で、多重度ｎで実行したテストプログラムｋの実行結果の経過時間（要求性能情報）である。この値は、図９の要求性能情報テーブルの性能情報から得ることができる値である。例えば、ｓ＝Ｓ１、ａ＝Ａ１、ｎ＝２、ｋ＝４とすると、値Ｔ(ｓ、ａ、ｎ、ｋ)は、要求性能情報テーブル図９の行９０９の値Ｔ１２に対応する。Ｔ(ｓ、ｎ、ｋ)はサーバ識別子ｓのサーバにおいて、多重度ｎで実行したテストプログラムｋの実行結果の経過時間（提供性能情報）である。この値は、図１０の提供性能情報テーブルの性能情報から得られる。例えば、ｓ＝Ｓ２、ｎ＝１、ｋ＝４とすると、値Ｔ(ｓ、ｎ、ｋ)は、図１０の行１００８の値Ｕ３４に対応する。ρ(ａ、ｋ)は、アプリケーション特性情報テーブル（図１１のテーブル１１０１）において、アプリケーション識別子がａのアプリケーションであって、テストプログラムｋに対する重みの値である。例えば、ａ＝Ａ２、ｋ＝１とすると、図１１の行１１０７を参照することにより、値１であることが分かる。
【００５３】
数１の利点を示すため、性能差を単純に、テストジョブ実行結果の経過時間の差を２乗するような以下の式で算出した場合と比較する。
【００５４】
【数２】
2005234917.tif 000004
数２では、例えば、そもそもマルチプロセッサに対応していないようなアプリケーションの切り換え先を決定する場合でも、マルチプロセッサ特有の性能を他の性能と同様に比較してしまう。このようなアプリケーションの切り換え先を、マルチプロセッサ性能で比較する意味は通常ない。また、ＣＰＵバウンドやＩ／Ｏバウンドなアプリケーションでは、それぞれ、ＣＰＵ性能、Ｉ／Ｏ性能が近いか否かを判定基準として優先すべきである。数２では、ｄ＝０であれば、完全に一致して問題とはならないが、性能情報は動的に変動するものであり、ｄ＝０となることは現実的にはありえない。従って、ｄ≠０と考えてよいが、それぞれに特徴のあるテストプログラムの実行経過時間を同等に扱っているため、性能が近いサーバを見つける場合、ｄの値が同じ程度の大きさのサーバが２つ以上ある場合、その差がサーバのどのような特性に起因するものかわからない。これでは、ｄの値が同程度に小さいサーバが２つ以上ある場合、実際にアプリケーションを動作させたときのアプリケーション実行性能は、各サーバで異なってくる。
【００５５】
これらの問題をすべて解決するため、性能が近いか否かという尺度自体を、アプリケーションの特性で決めるように、アプリケーションの性能面での特徴を、アプリケーション特性情報テーブルの重み（図１１の項目１１０３〜１１０６）で表現し、重み情報を利用して定義した数１の性能差で要求性能と提供性能との差を比較しているため、テストジョブの経過時間による性能比較であっても、実際に移行するアプリケーション実行性能が移行前のサーバのアプリケーション実行性能に近いものとなる。
【００５６】
ステップ７０４では、上記の性能差評価方法によって並べられた、提供性能が要求性能に近いサーバの順に、障害発生確率を計算して評価している。ステップ７０５では、可用性要求を満たしたサーバが見つかった場合はプログラムを終了し、見つからなければ、ステップ７０６へ移行する。ステップ７０６では、可用性の要求を緩和（最大障害確率を増大）し、再びステップ７０４へ戻る。
【００５７】
ステップ７０４の可用性の評価において、以下の障害発生確率を用いて評価している。まず、アプリケーション起動後の経過時間をｔ、製造後の経過時間Ｘをとしてその時の障害発生確率は、以下のようにして算出する。
【００５８】
【数３】
2005234917.tif 000005
第１項は、指数分布であり、偶発事故によるものである。第２項はサーバのハードウェア的な寿命を考慮した障害の発生確率（ワイブル分布）である。
【００５９】
この障害発生確率を計算するために必要なλ、ａ、ｂは、障害情報テーブル図１４の平均偶発故障率λ（図１４の項目１４０３）、増加故障率係数ａ（図１４の項目１４０４）、増加故障率係数ｂ（図１４の項目１４０５）に記録されている。ａ、ｂはハードウェアの寿命を考慮してあらかじめ設定された値である。λは、システム導入時にはある初期値が設定されているが、障害が発生するたびに、ＭＴＢＦ（Ｍｅａｎ  Ｔｉｍｅ  Ｂｅｔｗｅｅｎ  Ｆａｉｌｕｒｅ）を計算し、λ＝１／ＭＴＢＦを計算することにより偶発故障の発生確率を最新の値に更新する。また、サーバ製造後の経過時間Xは障害情報テーブル（図１４の項目１４０６）、アプリケーション起動後の経過時間をｔは、障害情報テーブル（図１４の項目１４０７）に記憶されている。
【００６０】
ステップ７０４の評価は、アプリケーション特性情報テーブル図１１にある、アプリケーションの連続実行時間１１０６（この値をＸとする）とそれに対応する障害発生率の上限値１１０７の値（この値をＹとする）を利用し、今後Ｘ年以内に障害が発生する確率をＹ以下にするというような条件で行う。これは、以下のような数３の積分値についての評価となる。
【００６１】
【数４】
2005234917.tif 000006
図８のフローチャートを利用して、障害管理サーバのみで動作する障害管理プログラムを説明する。ステップ８０１では、ヘルスチェックを行い、サーバの障害をチェックする。ヘルスチェックの方式については、ハートビートなど従来からある方法で実現する。ステップ８０２では、サーバの障害が検知されなければ、ステップ８０１へ戻り、障害が検知されれば、ステップ８０３に移行する。ステップ８０３では、アプリケーション利用資源情報テーブル（図１３）を利用してそのサーバで稼動していたアプリケーションの一覧を得る。
【００６２】
ステップ８０４では、ステップ８０３で得られたアプリケーション一覧から１つのアプリケーションを選択し、ステップ８０５では、このアプリケーション識別子と障害を起こしたサーバ識別子を入力情報として、フェイルオーバ先を決定するために、図７のアプリケーション移行先決定プログラムを実行する。ステップ８０６では、この結果として得られたサーバへアプリケーションを移行する。移行するための方式については、従来のフェイルオーバ方式を利用する。例えば、サーバの障害が発生した時に、プログラム、データ及びプログラムの実行に必要な各種制御情報を移行先のサーバに移してから、障害が発生したサーバの動作を停止し、その後、移行先のサーバを起動してプログラムの実行を継続する。
【００６３】
ステップ８０７では、提供性能情報テーブルの移行先サーバの提供性能情報すべてに対して値０又は十分に大きい値を設定し、アプリケーションが移行されたサーバへ、提供性能測定を要求する。ここで０又は十分に大きい値を設定しているのは、提供性能が再測定されるまで、そのサーバが再び他のアプリケーションの移行先として選ばれないようにするためである。ステップ８０８では、障害は発生したサーバのすべての管理対象アプリケーションが移行されたか否かを判定し、すべてが移行されていなければ、ステップ８０４へ戻り、すべてのアプリケーションが移行されていれば、終了する。
【図面の簡単な説明】
【００６４】
【図１】発明を実施するサーバの構成図である。
【図２】発明を実施する障害管理サーバ、障害管理対象サーバ群、ディスク群の関係を示した構成図である。
【図３】障害管理対象サーバ上で実行される性能取得プログラムを説明するフローチャートである。
【図４】障害管理対象サーバ上で実行される性能取得プログラムを説明するフローチャートである。
【図５】障害管理対象サーバ上で実行される要求性能測定プログラムを説明するフローチャートである。
【図６】障害管理対象サーバ上で実行される提供性能測定プログラムを説明するフローチャートである。
【図７】障害管理サーバ上で実行されるアプリケーション移行先決定プログラムを説明するフローチャートである。
【図８】障害管理サーバ上で実行される障害管理プログラムを説明するフローチャートである。
【図９】障害管理対象サーバ群及び障害管理サーバから参照可能なディスクに格納されている、要求性能情報テーブルの図である。
【図１０】障害管理対象サーバ群及び障害管理サーバから参照可能なディスクに格納されている、提供性能情報テーブルの図である。
【図１１】障害管理対象サーバ群及び障害管理サーバから参照可能なディスクに格納されている、アプリケーション特性情報テーブルの図である。
【図１２】障害管理対象サーバ群及び障害管理サーバから参照可能なディスクに格納されている、サーバ構成情報テーブルの図である。
【図１３】障害管理対象サーバ群及び障害管理サーバから参照可能なディスクに格納されている、アプリケーション資源情報テーブルの図である。
【図１４】障害管理対象サーバ群及び障害管理サーバから参照可能なディスクに格納されている、障害情報テーブルの図である。
【符号の説明】
【００６５】
２０１：グローバル・エリア・ネットワーク
２０２：ローカル・エリア・ネットワーク
２０３ａ、２０３ｂ、２０３ｃ、２０３ｄ、２０３ｅ、２０３ｆ、２０３ｇ：サーバ
２０４、２０５：クラスタシステム
２０６ａ、２０６ｂ、２０６ｃ、２０６ｄ、２０６ｅ、２０６ｆ、２０６ｇ：ディスク
２０７ａ、２０７ｂ：ＳＡＮ（ストレージ・エリア・ネットワーク）
２０８：テーブル格納域
２０９：提供性能情報テーブル
２１０：要求性能情報テーブル
２１１：サーバ構成情報テーブル
２１２：アプリケーション資源情報テーブル
２１３：アプリケーション特性情報テーブル
２１４：障害情報テーブル
【図１】
2005234917.tif 000007
【図２】
2005234917.tif 000008
【図３】
2005234917.tif 000009
【図４】
2005234917.tif 000010
【図５】
2005234917.tif 000011
【図６】
2005234917.tif 000012
【図７】
2005234917.tif 000013
【図８】
2005234917.tif 000014
【図９】
2005234917.tif 000015
【図１０】
2005234917.tif 000016
【図１１】
2005234917.tif 000017
【図１２】
2005234917.tif 000018
【図１３】
2005234917.tif 000019
【図１４】
2005234917.tif 000020