JP2008217285A - 情報処理システムの運用管理装置および運用管理方法 - Google Patents

Abstract

【課題】サービスの重要度だけでなく、システムの状態を考慮して、利用中のリソースが、サービスに及ぼす影響を定量的に出力する手段を提供すること。
【解決手段】各リソースの機能、その稼動状態、各サービスが利用するリソースおよびサービスにおけるリソース間の関係を定義したシステム構成情報（１０３５）と、サービスごとに設定された所定の重要度とを少なくとも保持する記憶部（１０３０）と、システム構成情報（１０３５）より、リソースを利用するサービスを特定し、特定したサービスにおいて、リソースと同一の機能を有する同等リソースを特定し、この同等リソースの状態およびその数に基づいて、リソースがサービスに及ぼす影響度を算出し、サービスの重要度および算出した影響度に基づいて、リソースの優先度を算出する優先度計算部（１０２４）とを有する運用管理装置（１０００）。
【選択図】図２

Description

本発明は、１以上の計算機から構成される情報処理システムを自律制御する方法に関し、特に、サービスに及ぼす影響が大きい障害を遅延なく復旧するために、情報処理システムで発生した障害の重大性、およびサービスで利用中のリソースの重要性を、サービスに及ぼす影響を考慮して適切に評価することができる情報処理システムの運用管理装置および運用管理方法に関する。

情報処理システムを構成するリソース、すなわち計算機などのハードウェアまたはサーバやアプリケーションなどのソフトウェアに障害が発生した場合、運用管理者が、発生した障害の内容に応じた対処を実行することが一般的である。
また、近年では、発生した障害の対処として実行する処理を、予め運用管理装置に設定しておき、障害が発生した場合に、運用管理装置に設定された処理を自動的に実行することで、障害を復旧することも可能になっている。

ところで、情報処理システムでは、短い間隔で複数の障害が発生することもある。
特に、一台の物理ホスト上で複数のサーバを稼動する構成において、物理ホストに障害が発生した場合、その物理ホスト上で稼動する複数のサーバから障害イベントが発生する可能性が高くなる。このような、一台の物理ホスト上で複数のサーバを稼動する構成は、現在でも実現可能な技術であるが、将来、仮想化技術の進歩によって、より一般的になると考えられる。その場合、運用管理者または運用管理装置が、それぞれの障害に応じて対処する必要がある。

しかし、発生した全ての障害を復旧させるために十分な余剰リソースが存在しない場合や、復旧処理を並行して実行することができない場合、すべての障害を遅延なく復旧させることができない可能性がある。したがって、重大な障害が発生した場合、その障害を優先して復旧することが必要である。そのためには、発生した障害の重大性を評価し、復旧処理の優先順位を決定することを支援する機能が望まれる。

また、複数の障害が発生した場合に限らず、単一の障害が発生した場合であっても、余剰リソースが存在しない場合などは、重大な障害の復旧が遅延してしまう可能性がある。このような場合には、サービスに及ぼす影響の小さなリソースを、障害が発生したリソースの代替として利用することにより、遅延なく重大な障害の復旧を行なうことが可能となる。そのためには、発生した障害の重大性を評価するとともに、サービスで利用中のリソースの重要性を評価し、発生した障害の重大性よりも重要でないリソースが存在すれば、そのリソースを融通するなどして、障害を遅延なく復旧することを支援する機能が望まれる。

前記課題に対し、特許文献１に記載の従来技術では、情報処理システムにおいて発生する障害イベントごとに設けた重要度によって、障害の重要性を表現している。
特許文献１に記載の技術によれば、運用管理者または運用管理装置が発生した障害イベントに設定された重要度を参照することによって、より重大な障害の復旧を優先することが可能である。

しかし、障害イベントごとに重要度を設けている場合、その障害がどのサービスに影響を及ぼすかを把握することができない。そのため、サービスに重大な影響を及ぼす障害の復旧が遅延してしまう場合があり、業務上大きな損失を招く可能性があるという問題がある。
したがって、単に障害イベントの重要度に基づいて、障害の復旧を優先するのではなく、サービスにより重大な影響を及ぼす障害の復旧を優先することが必要である。

前記課題に対し、特許文献２では、業務ごとにあらかじめ定義された重要度計算規則に基づいて、障害が発生したリソースを利用する業務の重要度を算出し、算出した重要度を障害の重要度として位置づけている。業務の重要度は、売り上げなどの業務データから算出される。運用管理者は、該業務の重要度をコンソールなどで参照することにより、業務により重大な影響を及ぼす障害を検知することを可能にしている。
特開２００５−３３１９９８号公報 特開２００５−３１８９３号公報

しかし、特許文献２では、予め定義された業務の重要度計算規則に従って算出した重要度を障害の重要度として位置づけているため、障害が業務に与える影響を情報処理システムの状態に応じて区別することができないという問題がある。

例えば、業務の停止を招くような障害が発生した場合であっても、重要度計算規則によって、その業務よりわずかに重要度が高く計算された別の業務に障害が発生すると、その障害によって業務が停止する可能性が低くても、その障害の復旧を優先することになる。なぜなら、運用管理者はコンソールなどに表示された業務の重要度に基づいて、復旧処理の優先順位を決定するからである。重要度の大きな業務に発生した障害であっても、障害の程度によって復旧処理の優先順位を決定しなければ、結果的に業務上大きな損失を招く可能性がある。

したがって、発生した障害の重大性を、サービスの重要度だけではなく、その時々のシステムの状態を考慮して評価し、サービスに及ぼす影響が大きい障害を優先して復旧することが望まれる。

また、利用中のリソースを、障害が発生したリソースの代替として利用する場合、利用中のリソースの中から、最もサービスに及ぼす影響が小さなリソースを、障害が発生したリソースの代替として利用することが望ましい。利用中のリソースの重要性は、その時々のシステムの状態に応じて変化するため、利用中のリソースの重要性の評価においても、該リソースを利用するサービスの重要度だけではなく、その時々のシステムの状態を考慮することが望ましい。

本発明は前記の課題を鑑みてなされたものであり、サービスの重要度だけでなく、システムの状態を考慮して、利用中のリソースが、サービスに及ぼす影響を定量的に出力する手段を提供することを目的とする。

前記課題を解決するために、本発明に係る情報処理システムの運用管理装置は、１以上のサービスを提供する１以上の計算機からなる情報処理システムにおいて、この計算機のハードウェアまたはソフトウェアからなるリソースの前記サービスにおける重要性を示す、リソースの優先度を算出する運用管理装置であって、各リソースの機能、その稼動状態、各サービスが利用するリソースおよび前記サービスにおけるリソース間の関係を定義したシステム構成情報と、前記サービスごとに設定された所定の重要度とを少なくとも保持する記憶部と、前記システム構成情報より、前記重要度の算出対象となるリソースを利用するサービスを特定し、前記システム構成情報より、前記特定したサービスにおいて、前記リソースと同一の機能を有する同等リソースを特定し、前記同等リソースの状態およびその数に基づいて、前記リソースが前記サービスに及ぼす影響度を算出し、前記サービスの重要度および前記算出した影響度に基づいて、前記リソースの優先度を算出する優先度計算部とを有することを特徴とする。

本発明によると、サービスの重要度だけでなく、システムの状態を考慮して、利用中のリソースが、サービスに及ぼす影響を定量的に計算することができる。

以下、添付した図面を参照しつつ、本発明の好適な実施の形態について説明する。

(第１実施形態)
図１は、本発明の第１実施形態に係る運用管理装置（情報処理システムの運用管理装置）が適用された情報処理システムの全体構成を示す図面である。
図１に示した情報処理システムは、運用管理装置１０００と、第１のネットワーク１１００と、クライアント１２００と、第２のネットワーク１３００と、ロードバランサＡ１４００と、ロードバランサＢ１４０１と、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）と、ＤＢサーバＡ〜Ｅ（１６００〜１６０４）とを構成要素として含んで構成される。

運用管理装置１０００と、ロードバランサＡ１４００と、ロードバランサＢ１４０１と、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）と、ＤＢサーバＡ〜Ｅ（１６００〜１６０４）とは、第１のネットワーク１１００を介して通信可能に接続される。
また、情報処理システムは、第２のネットワーク１３００を介してクライアント１２００と通信可能に接続され、クライアント１２００に対して業務サービス（以下、業務とよぶ）を提供する。なお、本実施形態では説明のために、請求項のサービスに対応する言葉として「業務」を用いるが、請求項のサービスとは情報処理システムの内部的なバッチ処理などを広く含む概念である。

以下、図１に示した情報処理システムの各構成要素について説明する。
運用管理装置１０００は、情報処理システムを管理するためのコンピュータである。運用管理装置１０００は、情報処理システムで発生する障害と、この障害が発生した場合に対処として行なう処理の組み合わせとを、ポリシとして管理し、情報処理システムで障害が発生すると、管理されたポリシに基づいて障害の復旧処理を行なう。詳しくは後述する。

第１のネットワーク１１００は、運用管理装置１０００と、ロードバランサＡ１４００と、ロードバランサＢ１４０１と、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）と、ＤＢサーバＡ〜Ｅ（１６００〜１６０４）とを相互に通信可能に接続する通信網である。この第１のネットワーク１１００は、例えば企業内におけるＬＡＮ（Local Area Network）により具現される。また、例えばＷＡＮ（Wide Area Network）を適用することもできる。
クライアント１２００は、情報処理システムから情報処理サービスの提供を受けるための処理要求を、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）に送信するためのコンピュータである。図1には、クライアント１２００が１台のみ接続された例を示したが、クライアント１２００は複数台であってもよい。また、情報処理システムが、定期的なバッチ処理などを実行するシステムである場合には、クライアント１２００が設置されない構成とすることもできる。

第２のネットワーク１３００は、クライアント１２００と、情報処理システムとを相互に通信可能に接続する通信網である。第２のネットワーク１３００は、例えば企業内におけるＬＡＮにより具現される。また、例えばＷＡＮを適用することもできる。
第１のネットワーク１１００と第２のネットワーク１３００とは、別のネットワークでもよいし、同一のネットワークにより具現することもできる。

ロードバランサＡ１４００およびロードバランサＢ１４０１は、クライアント１２００からＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）へ送信された処理要求を、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）に振り分けて送信するコンピュータであり、ロードバランサ制御機能１４１０と、エージェント機能１４１１を含んで構成される。

ロードバランサ制御機能１４１０は、クライアント１２００からＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）へ送信された処理要求を、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）に振り分けて送信する機能である。

エージェント機能１４１１は、運用管理装置１０００への障害情報（イベント）の送信や、各種設定情報の変更などを行なう機能である。設定情報の変更は、運用管理装置１０００が、ポリシに定義された対処に基づき、エージェント機能１４１１を用いて実行する。設定情報の変更は、エージェント機能１４１１の機能として含んでもよいし、オペレーティングシステムが提供する基本的な機能を利用してもよいし、他のプログラムを利用してもよい。
図１に示した情報処理システムでは、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）の５台を含む構成が例示されているが、ＷｅｂＡＰサーバが１台の場合には、ロードバランサを設けない構成とすることもできる。

ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）は、クライアント１２００から送信された各処理要求に応じた処理を実行し、処理結果をクライアント１２００に送信するコンピュータであり、それぞれ、ＷｅｂＡＰサーバ制御機能１５１０と、業務プログラム１５１１と、エージェント機能１４１１とを含んで構成される。

ＷｅｂＡＰサーバ制御機能１５１０は、クライアント１２００から送信された各処理要求に応じて業務プログラム１５１１を実行し、処理結果をクライアント１２００に送信する機能である。ＷｅｂＡＰサーバ制御機能１５１０は、各処理要求に応じた処理を実行する際に、ＤＢサーバＡ〜Ｅ（１６００〜１６０４）に対して、業務で利用するデータの読み書きの要求を送信する。

業務プログラム１５１１は、各種情報処理サービスをクライアント１２００に提供するために実行されるプログラムである。情報処理システムが、バッチ処理など、クライアント１２００に対して各種情報処理サービスを提供するシステムではない場合、業務プログラム１５１１は、バッチ処理を実行するためのプログラムでもよい。図１では、業務プログラム１５１１を１つ備える例を示しているが、業務プログラム１５１１を２つ以上設ける構成とすることもできる。
また、図１に示した情報処理システムでは、５台のＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）が例示されているが、情報処理システムには、ＷｅｂＡＰサーバが１台以上含まれればよい。

ＤＢサーバＡ〜Ｅ（１６００〜１６０４）は、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）からの要求を受けて、業務プログラム１５１１が利用するデータを読み書きするためのコンピュータであり、ＤＢサーバ制御機能１６１０と、エージェント機能１４１１とを含んで構成される。業務プログラム１５１１が利用するデータは、ＤＢサーバＡ〜Ｅ（１６００〜１６０４）のローカルディスクに記憶されてもよいし、ＳＡＮ（Storage Area Network）を介して外部のディスク装置などに記憶されてもよい。
ＤＢサーバ制御機能１６１０は、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）から、業務プログラム１５１１が利用するデータの読み書きの要求を受信すると、このデータの読み書きをする機能である。

図１に示した情報処理システムでは、５台のＤＢサーバＡ〜Ｅ（１６００〜１６０４）が例示されているが、ＤＢサーバを設けない構成とすることもできるし、さらに多く設けることもできる。

（運用管理装置の構成）
次に、図２は、本実施形態に係る運用管理装置１０００の構成を示す図面である。
運用管理装置１０００は、ＣＰＵ１０１０と、主記憶装置１０２０とを有するコンピュータであり、ディスクインタフェース１０４０を介してディスク装置１０３０と接続され、通信インタフェース１０５０を介して第１のネットワーク１１００と接続され、ディスプレイインタフェース１０６０を介して表示装置１０７０と接続される。

ディスク装置１０３０は、運用管理装置１０００が利用するデータを格納するハードディスクドライブなどの記憶装置であり、障害情報テーブル１０３１と、ポリシ定義テーブル１０３２と、ポリシ適用テーブル１０３３と、業務定義テーブル１０３４と、システム構成テーブル１０３５と、対処スクリプト１０３６とを有する。

障害情報テーブル１０３１は、情報処理システムで発生した障害の情報を格納するためのテーブルである。以降、情報処理システムで発生した障害の情報を、「イベント」と呼ぶ。

ポリシ定義テーブル１０３２は、情報処理システムで発生する可能性のある障害と、その障害が発生した場合に対処として実行する処理の組み合わせを定義した「ポリシ」を格納するためのテーブルである。

ポリシ適用テーブル１０３３は、情報処理システムで発生した障害に対し、ポリシに定義された対処を実行中か、または実行待ちのポリシの優先度や状態を格納するためのテーブルである。
以降、対処が実行中か、または実行待ちであるポリシを、このポリシの「インスタンス」と呼ぶ。

業務定義テーブル１０３４は、情報処理システムで実行される業務の情報を格納するためのテーブルである。
システム構成テーブル１０３５は、情報処理システムの構成情報を格納するためのテーブルである。
対処スクリプト１０３６は、障害が発生した際に、対処として実行する各処理を記述したプログラムである。対処スクリプト１０３６は、バッチファイルなど、障害に対する対処として行なう処理が実行できるものであればよい。図２に示した構成では、対処スクリプト１０３６が１つ例示されているが、対処スクリプトを２つ以上設ける構成とすることもできる。

運用管理装置１０００は、主記憶装置１０２０に格納された、障害監視部１０２１、ポリシ管理部１０２２、ポリシ制御部１０２３、構成管理部１０２６、および表示処理部１０２７を具現する各種プログラムをＣＰＵ１０１０が実行することにより、情報処理システムの運用管理を行なう。

障害監視部１０２１は、情報処理システムよりイベントを受信し、この受信したイベントを管理するとともに、関連する処理部へ通知する処理部である。障害監視部１０２１は、障害の発生をポリシ管理部１０２２へ通知し、障害の発生に伴うリソースの状態の変化を構成管理部１０２６へ通知する。

ポリシ管理部１０２２は、障害監視部１０２１から障害の発生を通知されると、この障害に適用するポリシをポリシ定義テーブル１０３２より特定し、このポリシのインスタンスの情報をポリシ適用テーブル１０３３に格納する処理部である。

ポリシ制御部１０２３は、優先度計算部１０２４とポリシ適用部１０２５からなる。
優先度計算部１０２４は、情報処理システムを構成するリソースの優先度を計算する処理部である。
ポリシ適用部１０２５は、ポリシ適用テーブル１０３３に格納されたポリシのインスタンスのうち、最も優先度の高いポリシのインスタンスを適用する処理部である。

ポリシ制御部１０２３は、優先度計算部１０２４で、障害が発生したリソースの優先度を計算し、計算したリソースの優先度に基づき、この障害に適用するポリシのインスタンスの優先度を設定し、ポリシ適用部１０２５で優先度の最も高いポリシのインスタンスを適用する。

構成管理部１０２６は、情報処理システムの構成情報を管理し、情報処理システムのリソースの状態の変化、構成の変更の通知を受け、システム構成テーブル１０３５を更新する処理部である。
表示処理部１０２７は、情報処理システムから受信したイベントや、ポリシの情報など各種情報を表示装置１０７０に表示するための画面を生成する処理部である。
表示装置１０７０は、ディスプレイなどであり、表示処理部１０２７で生成された画面を表示するための装置である。

（運用管理装置の動作概要）
次に、図３は、本実施形態に係る運用管理装置１０００の動作の概要を説明する説明図である。運用管理装置１０００が、情報処理システムで発生した障害を検知し、業務に重大な影響を及ぼす障害を優先して復旧するまでの流れを、図３を用いて説明する。

障害監視部１０２１は、第１のネットワーク１１００を介して、情報処理システムからイベントを受信し（ステップｓ１）、障害監視部１０２１を介してこのイベントを障害情報テーブル１０３１へ格納する（ステップｓ２）。
そして、障害監視部１０２１は、障害が発生したリソースの状態の変化を構成管理部１０２６に通知し（ステップｓ３）、構成管理部１０２６がシステム構成テーブル１０３５を更新する（ステップｓ４）。

次に、障害監視部１０２１は、障害の発生をポリシ管理部１０２２に通知する（ステップｓ５）。ポリシ管理部１０２２は、障害の発生を通知されると、障害情報テーブル１０３１に新たに格納されたイベントを取得し（ステップｓ６）、システム構成テーブル１０３５から障害が発生したリソースの情報を取得する（ステップｓ７）。
そして、ポリシ管理部１０２２は、取得したイベントおよびリソースの情報が、ポリシを適用する際の条件として定義されているポリシをポリシ定義テーブル１０３２を参照して特定し（ステップｓ８）、このポリシのインスタンスをポリシ適用テーブル１０３３へ格納する（ステップｓ９）。

ポリシ制御部１０２３は、ポリシ適用テーブル１０３３を常時監視しており、ステップｓ９でのポリシ適用テーブル１０３３へのポリシのインスタンスの格納を契機に、障害情報テーブル１０３１およびポリシ適用テーブル１０３３を参照し、ポリシのインスタンスを適用するリソースを特定し（ステップｓ１０）、優先度計算部１０２４で、業務定義テーブル１０３４およびシステム構成テーブル１０３５を参照し（ステップｓ１１）、障害が業務に及ぼす影響の大きさに基づいて、このリソースの優先度を算出する（ステップｓ１２）。
そして、ポリシ制御部１０２３は、算出したリソースの優先度に基づき、ポリシのインスタンスの優先度を設定し（ステップｓ１３）、ポリシ適用部１０２５で、最も優先度の高いポリシのインスタンスを適用する（ステップｓ１４）。ポリシ適用部１０２５は、ポリシに定義された対処に基づき、第１のネットワーク１１００を介して、目的の計算機のエージェント機能１４１１を用いて設定情報の変更などを行なう。

構成管理部１０２６は、情報処理システムを構成するリソースの状態や、構成の変更を通知されると（ステップｓｎ）、システム構成テーブル１０３５を更新する。したがって、優先度計算部１０２４で算出される優先度には、その時々の情報処理システムの構成情報が反映される。
そして、ポリシのインスタンスの適用後、ポリシ適用部１０２５は、障害への対処の完了を障害監視部１０２１へ通知し、障害監視部１０２１が、構成管理部１０２６で障害が発生したリソースの状態を元に戻す（ステップｓ１５）。

ここで、図４は、障害監視部１０２１が情報処理システムから受信するイベント４０００に含まれる情報を表すテーブルである。
イベント４０００は、イベントＩＤ４００１、詳細情報４００２、リソース名４００３、ＩＰアドレス４００４、および状態４００５の各情報を含み、情報処理システムから受信するイベントごとにイベントＩＤ４００１、詳細情報４００２、リソース名４００３、ＩＰアドレス４００４、状態４００５が設定される。

図４に示したテーブルにおいて、イベントＩＤ４００１は、情報処理システムで発生した障害を現象ごとに分類するためのＩＤである。また、詳細情報４００２は、情報処理システムで発生した障害の内容を示す文字列や数値が格納される。障害とは、リソースで稼動するサービスやアプリケーション、業務の停止を招く事象であり、本実施形態では、例えば「サーバダウン」などが設定される。

また、リソース名４００３は、障害が発生したリソースの名称を示す文字列などが設定される。本実施の形態では、例えば「ＷｅｂＡＰサーバＡ」などが設定される。
ＩＰアドレス４００４は、障害が発生したリソースを一意に識別し、該リソースと通信する際に相手先を特定するための値が設定される。本実施の形態では、リソースのＩＰアドレスが設定される。

状態４００５は、障害が発生したリソースの状態を示す文字列や数値が設定される。本実施の形態では、「障害」が設定される。
なお、イベント４０００には、イベントＩＤ４００１、詳細情報４００２、リソース名４００３、ＩＰアドレス４００４、状態４００５以外の項目を設けることもできる。

（ディスク装置に格納された情報）
以下、運用管理装置１０００のディスク装置１０３０に格納された各テーブルに含まれる情報について説明する。

図５は、ディスク装置１０３０に格納された障害情報テーブル１０３１に含まれる情報を表すテーブルである。
障害情報テーブル１０３１は、情報処理システムで障害が発生した際に、情報処理システムから受信したイベントを格納するためのテーブルである。

障害情報テーブル１０３１は、イベント通し番号５０００、イベントＩＤ５００１、詳細情報５００２、リソース名５００３、ＩＰアドレス５００４、および状態５００５からなり、イベントごとに、イベント通し番号５０００、イベントＩＤ５００１、詳細情報５００２、リソース名５００３、ＩＰアドレス５００４、および状態５００５が格納される。

イベント通し番号５０００は、情報処理システムで発生した障害を一意に識別するための番号であり、情報処理システムから受信したイベント４０００を障害情報テーブル１０３１に格納する際に割り当てられる。

イベントＩＤ５００１は、情報処理システムで発生する障害を現象ごとに分類するためのＩＤであり、情報処理システムから受信したイベント４０００のイベントＩＤ４００１が格納される。
詳細情報５００２は、情報処理システムで発生した障害の内容を示す文字列や数値が設定される。情報処理システムから受信したイベント４０００の詳細情報４００２が設定される。

リソース名５００３は、障害が発生したリソースの名称を示す文字列が設定される。情報処理システムから受信したイベント４０００のリソース名４００３が設定される。
ＩＰアドレス５００４は、障害が発生したリソースを一意に識別し、該リソースと通信する際に相手先を特定するための値が設定される。情報処理システムから受信したイベント４０００のＩＰアドレス４００４が設定される。

状態５００５は、障害が発生したリソースの状態を示す文字列や数値が設定される。情報処理システムから受信したイベント４０００の状態４００５が設定される。

次に、図６は、ディスク装置１０３０に格納されたポリシ定義テーブル１０３２に含まれる情報を表すテーブルである。
ポリシ定義テーブル１０３２は、情報処理システムで発生する可能性のある障害と、その障害が発生した場合に対処として実行する処理の組み合わせとを定義したポリシを格納するためのテーブルである。

ポリシ定義テーブル１０３２は、ポリシ定義ＩＤ６０００、イベントＩＤ６００１、リソース種別６００２、およびアクション６００３からなり、運用管理装置１０００に定義されるポリシごとに、ポリシ定義ＩＤ６０００、イベントＩＤ６００１、リソース種別６００２、およびアクション６００３が格納される。

ポリシ定義ＩＤ６０００は、ポリシ定義テーブル１０３２に格納されているポリシを一意に識別するためのＩＤである。
イベントＩＤ６００１は、情報処理システムで発生する障害を、現象ごとに分類するためのＩＤである。

リソース種別６００２は、障害が発生したリソースの種類を示す文字列や数値が設定される。本実施形態では、例えば、「ＷｅｂＡＰサーバ」などが設定される。
イベントＩＤ６００１およびリソース種別６００２は、ポリシを適用する際の条件となる情報であり、情報処理システムから受信したイベントのイベントＩＤおよびリソース種別が、イベントＩＤ６００１およびリソース種別６００２と一致する場合に、このポリシを適用する。
なお、本実施形態では、イベントＩＤ６００１およびリソース種別６００２を、ポリシを適用する際の条件としているが、障害の発生時刻など、イベントＩＤ６００１およびリソース種別６００２以外の項目を、ポリシを適用する際の条件にしてもよい。

アクション６００３は、情報処理システムから受信したイベント４０００のイベントＩＤ４００１および、障害が発生したリソースのリソース種別（図１０参照）が、それぞれポリシ定義テーブル１０３２のイベントＩＤ６００１およびリソース種別６００２と一致する場合に、障害の対処として実行する処理であり、例えば、障害が発生したサーバを代替することなどである。

アクション６００３には、対処として実行するコマンドやスクリプトなどを特定するための情報が設定される。例えば、オペレーティングシステムが基本的な機能として提供するコマンドやスクリプト、運用管理装置１０００のディスク装置１０３０に格納された対処スクリプト１０３６を特定するためのパスが格納される。
また、アクション６００３により特定されるコマンドやスクリプトを実行する際、システム構成テーブル１０３５からリソースのＩＰアドレスなどの情報を取得することにより、対処の適用先を特定することができる。システム構成テーブル１０３５については後述する。

図６に示したポリシ定義テーブル１０３２では、ポリシ定義ＩＤ「００２」の行は、イベントＩＤ「１００」すなわち「サーバダウン」の障害が発生した場合に（図５の障害情報テーブル１０３１参照）、対処として「D:\script\scriptB」で特定されるスクリプトを実行することを表している。このスクリプトは、例えば、障害が発生したサーバと同等の性能を有する代替サーバを起動するための処理を記述したものである。

次に、図７は、ディスク装置１０３０に格納されたポリシ適用テーブル１０３３に含まれる情報を表すテーブルである。ポリシ適用テーブル１０３３は、ポリシのインスタンスの優先度や状態を格納するためのテーブルである。

ポリシ適用テーブル１０３３は、ポリシ適用ＩＤ７０００、イベント通し番号７００１、ポリシ定義ＩＤ７００２、優先度７００３、および適用状態７００４からなり、ポリシのインスタンスごとに、ポリシ適用ＩＤ７０００、イベント通し番号７００１、ポリシ定義ＩＤ７００２、優先度７００３、および適用状態７００４が格納される。

ポリシ適用ＩＤ７０００は、ポリシのインスタンスを一意に識別するためのＩＤである。ポリシ適用ＩＤ７０００は、情報処理システムで発生した障害に適用するポリシのインスタンスの情報を、ポリシ適用テーブル１０３３に格納する際に、ポリシ管理部１０２２によって割り当てられる。

イベント通し番号７００１は、情報処理システムで発生した障害の情報を一意に識別するための番号である。イベント通し番号７００１には、ポリシの適用の契機となったイベントのイベント通し番号、すなわち障害情報テーブル１０３１（図５参照）のイベント通し番号５０００が設定される。

ポリシ定義ＩＤ７００２は、ポリシ定義テーブル１０３２（図６参照）に格納されたポリシを一意に識別するためのＩＤである。ポリシ定義ＩＤ７００２には、障害に適用するポリシのポリシ定義ＩＤ、すなわちポリシ定義テーブル１０３２のポリシ定義ＩＤ６０００が格納される。
優先度７００３は、ポリシを適用する際の優先順位を表した値である。障害が業務に及ぼす影響が大きいほど、優先度７００３は高く設定される。ポリシの優先度７００３が高く設定されている場合、このポリシを優先して適用する。優先度７００３は、優先順位を表せるものであれば、数値であっても文字列であってよい。
なお、優先度７００３の算出手順については後記する。

適用状態７００４は、ポリシのインスタンスの状態を示す文字列や数値が設定される。本実施形態では、「未適用」または「適用中」が設定される。「未適用」は、ポリシに定義されたアクションの実行待ちであることを表す。「適用中」は、ポリシに定義されたアクションが実行中であることを表す。以降、ポリシに定義されたアクションが実行中であることを、「ポリシのインスタンスが適用中である」という。

図７に示したポリシ適用テーブル１０３３において、ポリシ適用ＩＤ「００１」の行は、イベント通し番号「００１」の障害、つまり「ＷｅｂＡＰサーバＡ」に発生した障害に対し、ポリシ定義ＩＤ「００２」のポリシを適用することを表している。ポリシのインスタンスの優先度は、「３０」である。

次に、業務定義テーブル１０３４およびシステム構成テーブル１０３５に格納される情報を説明するために、前提となる情報処理システムの稼動状態について説明する。

図８は、図１に示した情報処理システムの業務実行時における論理的な接続関係の例を説明する図面である。図８に示した接続関係では、情報処理システムが業務Ａおよび業務Ｂの２つの業務に利用されることを表している。

図８を参照して、業務Ａは、ロードバランサＡ１４００と、ＷｅｂＡＰサーバＡ１５００と、ＷｅｂＡＰサーバＢ１５０１と、ＷｅｂＡＰサーバＣ１５０２と、ＤＢサーバＡ１６００と、ＤＢサーバＢ１６０１と、ＤＢサーバＣ１６０２とを用いて処理を実行する。
また、業務Ｂは、ロードバランサＢ１４０１と、ＷｅｂＡＰサーバＤ１５０３と、ＷｅｂＡＰサーバＥ１５０４と、ＤＢサーバＣ１６０２と、ＤＢサーバＤ１６０３と、ＤＢサーバＥ１６０４とを用いて処理を実行する。

第２のネットワーク１３００と、ロードバランサＡ１４００およびロードバランサＢ１４０１とを結ぶ線分は、第２のネットワーク１３００を介して、ロードバランサＡ１４００およびロードバランサＢ１４０１が、クライアント１２００からの処理要求を受け付けることを示している。
ロードバランサＡ１４００とＷｅｂＡＰサーバＡ〜Ｃ（１５００〜１５０２）とを結ぶ線分は、ロードバランサＡ１４００が、クライアント１２００からの処理要求を、業務Ａの業務プログラム１５１１（図１参照）が格納されたＷｅｂＡＰサーバＡ〜Ｃ（１５００〜１５０２）へ振り分けることを示している。

ロードバランサＢ１４０１とＷｅｂＡＰサーバＤ〜Ｅ（１５０３〜１５０４）とを結ぶ線分は、ロードバランサＢ１４０１が、クライアント１２００からの処理要求を、業務Ｂの業務プログラム１５１１（図１参照）が格納されたＷｅｂＡＰサーバＤ〜Ｅ（１５０３〜１５０４）へ振り分けることを示している。
ＷｅｂＡＰサーバＡ〜Ｃ（１５００〜１５０２）とＤＢサーバＡ〜Ｃ（１６００〜１６０２）とを結ぶ線分は、ＷｅｂＡＰサーバＡ〜Ｃ（１５００〜１５０２）が、業務Ａで利用するデータの読み書きの要求を、ＤＢサーバＡ〜Ｃ（１６００〜１６０２）へ送信することを示している。ＤＢサーバＡ〜Ｃ（１６００〜１６０２）は、業務Ａで利用するデータの読み書きの要求を受信すると、業務Ａで利用するデータを読み書きする。

ＷｅｂＡＰサーバＤ〜Ｅ（１５０３〜１５０４）とＤＢサーバＣ〜Ｅ（１６０２〜１６０４）とを結ぶ線分は、ＷｅｂＡＰサーバＤ〜Ｅ（１５０３〜１５０４）が、業務Ｂで利用するデータの読み書きの要求を、ＤＢサーバＣ〜Ｅ（１６０２〜１６０４）へ送信することを示している。ＤＢサーバＣ〜Ｅ（１６０２〜１６０４）は、業務Ｂで利用するデータの読み書きの要求を受信すると、業務Ｂで利用するデータを読み書きする。
なお、ＤＢサーバＣ１６０２は業務Ａおよび業務Ｂに利用されることを示している。

ＤＢサーバＡ１６００とＤＢサーバＢ１６０１とを結ぶ線分、およびＤＢサーバＤ１６０３とＤＢサーバＥ１６０４とを結ぶ線分は、それぞれ線分で結ばれたＤＢサーバ同士がフェールオーバクラスタ構成を組んでいることを示している。フェールオーバクラスタ構成を組んだＤＢサーバは、ハートビートの送受信や、業務で利用するデータの同期を取るためのミラーリングなどを行っていることを示している。

以降、情報処理システムが、図８で示した業務実行時における論理的な接続関係を有する場合における、運用管理装置１０００のディスク装置１０３０に格納された業務定義テーブル１０３４およびシステム構成テーブル１０３５に格納される情報について説明する。

図９は、ディスク装置１０３０に格納された業務定義テーブル１０３４に含まれる情報を表すテーブルである。業務定義テーブル１０３４は、情報処理システムで実行される業務の情報を格納するためのテーブルである。

業務定義テーブル１０３４は、業務番号９０００、業務名９００１、および重要度９００２からなり、情報処理システムで実行される業務ごとに、業務番号９０００、業務名９００１、および重要度９００２が格納される。

業務番号９０００は、情報処理システムで実行される業務を一意に識別するための番号である。
業務名９００１は、情報処理システムで実行される業務の名称を示す文字列が設定される。
重要度９００２は、情報処理システムで実行される業務がどの程度重要であるかを示す文字列や数値が設定される。重要度９００２は、固定値であってもよく、特許文献２に記載された方法のように、何らかの計算規則やプログラムによって算出した値でもよい。

図１０は、ディスク装置１０３０に格納されたシステム構成テーブル１０３５に含まれる情報を表すテーブルである。図１０のシステム構成テーブル１０３５には、図８で示した接続関係に基づいた情報処理システムの構成情報が格納される。

システム構成テーブル１０３５は、リソース番号１００００、リソース名１０００１、ＩＰアドレス１０００２、リソース種別１０００３、接続リソース１０００４、リソースグループ１０００５、業務番号１０００６、および状態１０００７からなり、情報処理システムを構成するリソースごとに、リソース番号１００００、リソース名１０００１、ＩＰアドレス１０００２、リソース種別１０００３、接続リソース１０００４、リソースグループ１０００５、業務番号１０００６、および状態１０００７が格納される。

リソース番号１００００は、情報処理システムを構成するリソースを一意に識別するための番号である。
リソース名１０００１は、情報処理システムを構成するリソースの名称を示す文字列が設定される。本実施形態では、例えば「ＷｅｂＡＰサーバＡ」などが設定される。

ＩＰアドレス１０００２は、情報処理システムを構成するリソースを一意に識別し、このリソースと通信する際に相手先を特定するための値が設定される。本実施の形態では、リソースのＩＰアドレスが設定される。ポリシに定義されたアクション６００３（図６参照）に設定されたコマンドやスクリプトは、ＩＰアドレス１０００２より対処の適用先を特定することができる。
リソース種別１０００３は、リソースの分類を示す文字列や数値が設定される。本実施形態では、例えば「ＷｅｂＡＰサーバ」、「ＤＢサーバ」などが設定される。システム構成や業務上の役割に応じて、リソース種別１０００３を変えてもよい。

接続リソース１０００４は、リソースの接続関係を表しており、接続するリソースのリソース番号１００００が設定される。接続するリソースが複数の場合、複数のリソース番号が設定される。図８で示した接続関係において、ロードバランサＡ１４００は、ＷｅｂＡＰサーバＡ１５００と、ＷｅｂＡＰサーバＢ１５０１と、ＷｅｂＡＰサーバＣ１５０２とに接続しているため、ＷｅｂＡＰサーバＡ１５００と、ＷｅｂＡＰサーバＢ１５０１と、ＷｅｂＡＰサーバＣ１５０２とのリソース番号「２，３，４」が格納される。なお、本実施形態では、複数のリソースＩＤ１３０００を連結して設定するものとしたが、接続リソース１０００４を別のテーブルで管理し、正規化することもできる。

リソースグループ１０００５は、同一機能を有するリソースのまとまりを示す文字列や数値が設定される。同一機能を有するリソースとは、例えば、ロードバランサで負荷分散されたサーバや、フェールオーバークラスタ構成を組んだサーバなどである。リソースグループ１０００５は、ユーザが設定してもよく、各サーバのエージェント機能１４１１を利用して取得したロードバランサやＷｅｂＡＰサーバなどの設定情報から自動的に設定してもよい。

業務番号１０００６は、リソースを利用する業務を表し、業務定義テーブル１０３４（図９参照）の該当する業務番号９０００が設定される。リソースを利用する業務が複数ある場合、複数の番号が格納される。図８で示した接続関係において、ＤＢサーバＣ１６０２は、業務Ａおよび業務Ｂが利用するため、業務番号１０００６には、業務Ａおよび業務Ｂのそれぞれの業務番号９００である「１，２」が格納される。なお、本実施形態では、複数の業務番号９０００を連結して設定するものとしたが、業務番号１０００６を別のテーブルで管理し、正規化することもできる。
状態１０００７は、リソースの障害状態を表し、障害監視部１０２１から通知された状態が格納される。リソースに障害が発生している場合、「障害」が格納される。リソースが正常稼動している場合は、何も設定されない。

（運用管理装置の詳細な動作）
次に、前記の各情報が格納された運用管理装置１０００の各機能部の処理動作について説明する（適宜、図１ないし図１０参照）。

図１１は、障害監視部１０２１の処理を説明するフローチャートの例である。図１１を参照して、障害監視部１０２１の処理を説明する。前記のように、障害監視部１０２１は、発生した障害の情報を障害情報テーブル１０３１へ格納し、障害の発生を関連する処理部へ通知する処理部である。

まず、情報処理システムで障害が発生すると障害監視部１０２１は、この障害が発生したリソースを監視するエージェント機能１４１１から、イベント４０００（図４参照）を受信する（ステップ１１０００）。

次に、受信したイベントのイベントＩＤ４００１、詳細情報４００２、リソース名４００３、ＩＰアドレス４００４、および状態４００５をそれぞれ障害情報テーブル１０３１（図５参照）のイベントＩＤ５００１、詳細情報５００２、リソース名５００３、ＩＰアドレス５００４、および状態５００５に格納する（ステップ１１０１０）。このとき、障害情報テーブル１０３１のイベント通し番号５０００には、障害情報テーブル１０３１内で一意のイベント通し番号を設定する。

次に、ステップ１１０００で受信したイベント４０００のＩＰアドレス４００４と状態４００５を、構成管理部１０２６へ送信し、リソースの状態変化を通知する（ステップ１１０２０）。構成管理部１０２６は、システム構成テーブル１０３５（図１０参照）におけるＩＰアドレス１０００２が、ステップ１１０２０で送信されたＩＰアドレスと一致する行を選択し、この行の状態１０００７に、ステップ１１０２０で送信された状態４００５を設定する。
そして、ステップ１１０１０で新しく設定したイベント通し番号を、ポリシ管理部１０２２へ送信し、障害の発生を通知する（ステップ１１０３０）。
障害監視部１０２１の処理は、プログラムが起動するとループ状態になり、プログラム起動中は継続的に情報処理システムから障害の情報を受信する。プログラムが終了すると、障害監視部１０２１の処理は終了し（ステップ１１０４０で‘Ｙｅｓ’）、終了しない場合は（ステップ１１０４０‘Ｎｏ’）、ステップ１１０００に戻って、ループを繰り返す。

具体的には、「ＷｅｂＡＰサーバＡ」に障害が発生した場合、障害監視部１０２１はエージェント機能１４１１から、図４に示した、イベントＩＤ「１００」、詳細情報「サーバダウン」、リソース名「ＷｅｂＡＰサーバＡ」、ＩＰアドレス「192.168.1.3」、および状態「障害」が設定されたイベント４０００を受信し、障害情報テーブル１０３１へ格納する（図５の１行目のデータ）。このとき、障害情報テーブル１０３１内で一意のイベント通し番号「００１」を設定する。
そして、構成管理部１０２６へ、障害が発生したリソースのＩＰアドレス「192.168.1.3」と状態「障害」を送信し、構成管理部１０２６がシステム構成テーブル１０３５（図１０参照）を更新する。さらに、ポリシ管理部１０２２へ、イベント通し番号「００１」を送信し、障害の発生を通知する。

次に、図１２は、ポリシ管理部１０２２の処理を説明するフローチャートの例である。図１２を参照して、ポリシ管理部１０２２の処理を説明する。前記のように、ポリシ管理部１０２２は、障害監視部１０２１から障害発生の通知を受け、その障害に適用するポリシを決定する処理部である。

まず、ポリシ管理部１０２２は、障害監視部１０２１から、新たに発生した障害のイベント通し番号を受信する（ステップ１２０００）。
そして、障害情報テーブル１０３１（図５参照）におけるイベント通し番号５０００が、ステップ１２０００で受信したイベント通し番号と一致する行を選択し、この行のイベントＩＤ５００１とＩＰアドレス５００４を取得する（ステップ１２０１０）。

次に、ポリシ管理部１０２２は、システム構成テーブル１０３５（図１０参照）におけるＩＰアドレス１０００２が、ステップ１２０１０で取得したＩＰアドレスと一致する行を選択し、この行のリソース種別１０００３を取得する（ステップ１２０２０）。
そして、ポリシ定義テーブル１０３２（図６参照）におけるイベントＩＤ６００１およびリソース種別６００２が、それぞれステップ１２０１０で取得したイベントＩＤおよびステップ１２０２０で取得したリソース種別と一致する行を選択し、この行のポリシ定義ＩＤ６０００を取得する（ステップ１２０３０）。

そして、ステップ１２０００で受信したイベント通し番号と、ステップ１２０３０で取得したポリシ定義ＩＤ６０００とを、ポリシ適用テーブル１０３３（図７参照）のイベント通し番号７００１とポリシ定義ＩＤ７００２とに設定して格納する（ステップ１２０４０）処理を終了する。このとき、ポリシ適用テーブル１０３３のポリシ適用ＩＤ７０００には、ポリシ適用テーブル１０３３内で一意のポリシ適用ＩＤを設定する。

具体的には、図８に示す情報システムの接続関係において、「ＷｅｂＡＰサーバＡ１５００」（ＩＰアドレス「192.168.11.3」）に障害が発生した場合、障害監視部１０２１から、イベント通し番号「００１」を受信し、障害情報テーブル１０３１からイベントＩＤ「１００」を取得する。そして、システム構成テーブル１０３５からリソース種別「ＷｅｂＡＰサーバ」を取得する。
次に、ポリシ定義テーブル１０３２から、イベントＩＤが「１００」、リソース種別が「ＷｅｂＡＰサーバ」であるポリシのポリシ定義ＩＤ「００２」を特定し、イベント通し番号「００１」およびポリシ定義ＩＤ「００２」をポリシ適用テーブル１０３３に格納する。このとき、ポリシ適用テーブル１０３３内で一意のポリシ適用ＩＤ「００１」を設定する。
なお、ステップ１２０３０において、イベントＩＤやリソース種別以外の項目を、ポリシを適用する際の条件とすることも可能である。

次に、図１３は、ポリシ制御部１０２３の処理を説明するフローチャートの例である。図１３を参照して、ポリシ制御部１０２３の処理を説明する。前記のように、ポリシ制御部１０２３は、優先度計算部１０２４で算出したリソースの優先度に基づいてポリシのインスタンスの優先度を設定し、情報処理システムで発生した障害にポリシを適用する処理部である。

まず、ポリシ制御部１０２３は、システム構成テーブル１０３５（図１０参照）におけるすべての行のリソースグループ１０００５、業務番号１０００６および状態１０００７を記憶する（ステップ１３０００）。そして、ポリシ適用テーブル１０３３の各行に対して、ステップ１３０２０からステップ１３０５０の処理を繰り返す（ステップ１３０１０）。

まず、処理対象の行に対して、この行のイベント通し番号７００１を取得することで、ポリシ適用テーブル１０３３より、ポリシを適用する障害のイベント通し番号を特定する（ステップ１３０２０）。そして、障害情報テーブル１０３１におけるイベント通し番号５０００が、ステップ１３０２０で取得したイベント通し番号と一致する行を選択し、この行のＩＰアドレス５００４を取得する。これにより、障害情報テーブル１０３１から、障害が発生したリソースのＩＰアドレスを特定する（ステップ１３０３０）。
次に、優先度計算部１０２４で、ステップ１３０３０で取得したＩＰアドレスに基づき、リソースの優先度を算出する（ステップ１３０４０）。なお、このリソースの優先度の算出手順については、図１４を参照して後記する。

次に、ポリシ適用テーブル１０３３の現在処理対象の行に対して、この行の優先度７００３に、ステップ１３０４０で算出したリソースの優先度を設定する（ステップ１３０５０）。ポリシ適用テーブル１０３３のすべての行において、優先度７００３を設定するまでステップ１３０２０からステップ１３０５０を繰り返す（ステップ１３０６０）。

次に、システム構成テーブル１０３５におけるすべての行のリソースグループ１０００５、業務番号１０００６および状態１０００７が、ステップ１３０００で記憶したリソースグループ、業務番号および状態と一致しているか確認し（ステップ１３０７０）、一致していない場合（ステップ１３０７０でＮｏ）、ステップ１３０００へ戻りポリシのインスタンスの優先度を再度計算する。
ここで、ステップ１３０７０において、システム構成テーブル１０３５におけるリソースグループ１０００５、業務番号１０００６または状態１０００７が変化した場合に、再度、ポリシのインスタンスの優先度をすべて計算することとしたが、変化によって影響のあるポリシのインスタンスの優先度のみを計算することもできる。つまり、システム構成テーブル１０３５におけるリソースグループ１０００５、業務番号１０００６または状態１０００７が変化した行を選択し、システム構成テーブル１０３５におけるリソースグループ１０００５が、選択した行のリソースグループ１０００５または変化する前のリソースグループ１０００５と一致する行を選択し、該行のＩＰアドレス１０００２で特定されるリソースに発生した障害に適用するポリシのインスタンスの優先度のみを計算することもできる。

一方、システム構成テーブル１０３５とステップ１３０００で記憶した情報とが一致している場合（ステップ１３０７０でＹｅｓ）、ポリシ適用部１０２５で優先度の高いポリシのインスタンスを適用する（ステップ１３０８０）。
この、優先度の高いポリシのインスタンスを適用する手順については、図１７を参照して後述する。

図１３に示したポリシ制御部１０２３の処理は、プログラムが起動するとループ状態になり、プログラム起動中は継続的にポリシのインスタンスの優先度の計算と適用を繰り返す。プログラムが終了すると、ポリシ制御部１０２３の処理は終了する（ステップ１３０９０）。
なお、本実施形態におけるポリシ制御部１０２３は、ステップ１３０８０においてポリシ適用部１０２５を呼び出した直後、ステップ１３０９０へ移り、プログラムを終了するか否かを判定し、終了しない場合は（ステップ１３０９０で‘Ｎｏ’）、以降の処理を継続する。複数の障害が発生している場合は、ポリシ適用部１０２５の処理が複数並行して実行される。同時に実行できるポリシ適用部１０２５の処理の数は、制限を設けないこともできるし、１以上の制限を設けることもできる。

次に、図１４は、優先度計算部１０２４の処理を説明するフローチャートの例である。図１４を参照して、優先度計算部１０２４の処理を説明する。前記のように、優先度計算部１０２４は、ステップ１３０４０（図１３参照）で指定されたＩＰアドレスで特定されるリソースの優先度を計算する処理部である。

まず、優先度計算部１０２４は、リソースの優先度を表す変数αを０に初期化する（ステップ１４０００）。そして、システム構成テーブル１０３５（図１０参照）におけるＩＰアドレス１０００２が、ステップ１３０４０（図１３参照）で指定されたＩＰアドレスと一致する行を選択し、この行の業務番号１０００６を取得することで、システム構成テーブル１０３５から、リソースを利用する業務を特定する（ステップ１４０１０）。

次に、ステップ１４０１０で取得した業務番号のいずれかを選択し、ステップ１４０１０で取得したすべての業務番号について、ステップ１４０２０ないしステップ１４０５０の処理を繰り返す（ステップ１４０２０）。
まず、ステップ１３０４０で指定されたＩＰアドレス、およびステップ１４０２０で選択した業務番号に基づいて、業務におけるリソースの優先度βを算出し（ステップ１４０３０）、業務におけるリソースの優先度を表す変数βに算出した値を設定する。
なお、業務におけるリソースの優先度の算出手順については、図１５を参照して後述する。また、ステップ１４０２０において、業務番号を選択する際、主記憶装置１０２０に記憶されていない業務番号を選択し、選択した後、選択した業務番号を主記憶装置１０２０に記憶する。主記憶装置１０２０に記憶した業務番号は、本処理の終了時にすべて削除する。

次に、優先度計算部１０２４は、変数βの値を、変数αに加算する（ステップ１４０４０）。ステップ１４０１０で取得したすべての業務番号について、業務におけるリソースの優先度を算出した場合、優先度計算部１０２４の処理を終了する（ステップ１４０５０）。ステップ１４０２０からステップ１４０５０において、リソースを利用する業務ごとに、この業務におけるリソースの優先度を、リソースの優先度に加算することによって、多くの業務が利用するリソースの優先度は高く計算される。

次に、図１５は、図１４で示したフローのステップ１４０３０（図１４参照）で呼び出される優先度計算部１０２４における処理を説明するフローチャートの例である。図１５を参照して、業務におけるリソースの優先度の計算手順について説明する。
図１５で示す処理において、優先度計算部１０２４は、ステップ１４０３０で指定されたＩＰアドレスと業務番号に基づき、業務におけるリソースの優先度を計算する。

まず、優先度計算部１０２４は、業務におけるリソースの優先度を表す変数βを０に初期化する（ステップ１５０００）。そして、業務定義テーブル１０３４（図９参照）における業務番号９０００が、ステップ１４０３０で指定された業務番号と一致する行を選択し、この行の重要度９００２を取得して、業務の重要度を表す変数γに設定する（ステップ１５０１０）。

次に、ステップ１４０３０で指定されたＩＰアドレスと業務番号に基づいて、リソースの冗長度を算出し、リソースの冗長度を表す変数σに算出した値を設定する（ステップ１５０２０）。なお、リソースの冗長度を計算する手順については、図１６を参照して後述する。

次に、変数γの値と、変数σの値を１から減算した値とを積算した値を、変数βに設定する（ステップ１５０３０）。これにより、ステップ１５０１０からステップ１５０３０において、業務の重要度が高い場合、およびリソースの冗長度が低い場合に、業務におけるリソースの優先度が高く設定される。

次に、図１６は、図１５で示したフローのステップ１５０２０（図１５参照）で呼び出される優先度計算部１０２４における処理を説明するフローチャートの例である。図１５を参照して、業務におけるリソースの優先度の計算手順について説明する。
図１６で示す処理において、優先度計算部１０２４は、ステップ１５０２０で対象としたＩＰアドレスと業務番号に基づき、リソースを利用する業務ごとに、リソースの冗長度を算出する。本実施形態において、リソースの冗長度には、同一機能を有するリソースのうち、ステップ１５０２０で指定されたＩＰアドレスで特定されるリソース以外で正常な状態にあるリソースが占める割合が設定される。したがって、冗長度を１から減算した値は、同一機能を有するリソースのうち、ステップ１５０２０で指定されたＩＰアドレスで特定されるリソースおよび障害状態にあるリソースが占める割合となる。冗長度が低い場合、前記リソースの障害によってシステムが停止する可能性が高くなるとともに、システムの処理能力低下の可能性があるため、本実施形態では、業務に及ぼす影響の大きさを判断する値（影響度）として、冗長度を１から減算した値を利用する。

まず、優先度計算部１０２４は、リソースの冗長度を表す変数σを０に初期化する（ステップ１６０００）。そして、システム構成テーブル１０３５（図１０参照）におけるＩＰアドレス１０００２が、ステップ１５０２０で指定されたＩＰアドレスと一致する行、すなわち、障害が発生したリソースの行を選択し、この行のリソースグループ１０００５を取得する。これにより、障害が発生したリソースのリソースグループを特定する（ステップ１６０１０）。

次に、優先度計算部１０２４は、システム構成テーブル１０３５におけるリソースグループ１０００５が、ステップ１６０１０で取得したリソースグループと一致するすべての行を選択する。これにより、同一のリソースグループに属するリソースを特定する（ステップ１６０２０）。
次に、ステップ１６０２０で選択した各行における業務番号１０００６が、ステップ１５０２０で指定された業務番号を含むすべての行を選択する。これにより、同一の業務が利用するリソースを特定する（ステップ１６０３０）。ステップ１６０１０〜１６０３０により、ステップ１５０２０で指定されたＩＰアドレスにより特定されるリソースと同一機能を有し、同一の業務が利用するリソースが特定される。

次に、ステップ１６０３０で選択した行の総数を取得し、取得した行の総数すなわち、全リソースの数を変数nに代入する。（ステップ１６０４０）。
そして、障害状態にないリソースの数を表す変数mを０で初期化し（ステップ１６０５０）、ステップ１６０３０で選択した各行に対して、ステップ１６０７０からステップ１６０９０を繰り返す（ステップ１６０６０）。

まず、優先度計算部１０２４は、現在処理対象の行に対して、この行のＩＰアドレス１０００２がステップ１５０２０で指定されたＩＰアドレスと一致するか否かを確認し、指定されたリソースであるか否かを判定する（ステップ１６０７０）。指定されたリソースである場合（ステップ１６０７０でＹｅｓ）、ステップ１６１００へ移る。一方、指定されたリソースではない場合（ステップ１６０７０でＮｏ）、この行の状態１０００７が「障害」と一致するか確認して、対象リソースが障害状態であるか否かを判定する（ステップ１６０８０）。障害状態である場合（ステップ１６０８０でＹｅｓ）、ステップ１６１００へ移る。一方、障害状態ではない場合（ステップ１６０８０でＮｏ）、変数ｍに１を加算する（ステップ１６０９０）。ステップ１６０３０で選択したすべての行に対してステップ１６０７０からステップ１６０９０を繰り返した場合、ステップ１６１１０へ移る（ステップ１６１００）。

そして、変数ｍを、変数ｎで除算した値を、変数σに代入する（ステップ１６１１０）。これにより、ステップ１６０００からステップ１６１１０において、障害状態にあるリソースが多い場合、および同一機能を有するリソースが少ない場合に、リソースの冗長度は低く計算される。

以下、情報処理システムが、図８に示す接続関係を有する場合において、「ＷｅｂＡＰサーバＡ」（ＩＰアドレス「192.168.1.3」）に障害が発生したときを例に、ポリシのインスタンスの優先度の算出方法について説明する。

「ＷｅｂＡＰサーバＡ」に障害が発生した場合、システム構成テーブル１０３５（図１０参照）より、リソース名１０００１「ＷｅｂＡＰサーバＡ」を利用する業務の業務番号１０００６「１」を特定する。業務定義テーブル１０３４（図９参照）から、業務番号９０００「１」の業務「業務Ａ」の重要度９００２は、「９０」である。
システム構成テーブル１０３５から、「ＷｅｂＡＰサーバＡ」のリソースグループ１０００５は「２」であるので、同一機能を有し、同一業務が利用するリソースは、「ＷｅｂＡＰサーバＡ」、「ＷｅｂＡＰサーバＢ」および「ＷｅｂＡＰサーバＣ」である。したがって、同一機能を有するリソースの総数は「３」となる。「ＷｅｂＡＰサーバＡ」の状態１０００７は「障害」であるから、障害状態にないリソースは、「ＷｅｂＡＰサーバＢ」および「ＷｅｂＡＰサーバＣ」であり、その数は「２」である。

したがって、図１６で示した処理によって算出される、「ＷｅｂＡＰサーバＡ」の冗長度は「２／３」であり、図１５で示した処理によって算出される、「業務Ａ」における「ＷｅｂＡＰサーバＡ」の優先度は「９０×（１−２／３）」から、「３０」となる。「ＷｅｂＡＰサーバＡ」を利用する業務は、業務番号「１」の業務「業務Ａ」のみであるから、ポリシ適用テーブル１０３３（図７参照）のポリシのインスタンスの優先度７００３は「３０」となる。

なお、「ＷｅｂＡＰサーバＤ」（ＩＰアドレス「192.168.1.10」）に適用するポリシのインスタンス優先度は、次の通り算出される。「ＷｅｂＡＰサーバＤ」を利用する業務は業務番号「２」の「業務Ｂ」のみであり、その重要度は「８０」である。「ＷｅｂＡＰサーバＤ」と同一機能を有するリソースで、業務番号「２」の業務が利用するリソースは、「ＷｅｂＡＰサーバＤ」、「ＷｅｂＡＰサーバＥ」であり、そのうち障害状態にないリソースは、「ＷｅｂＡＰサーバＥ」であるから、冗長度は「１／２」となる。したがって、業務の優先度は、「８０×（１−１／２）」から「４０」であり、ポリシ適用テーブル１０３３のポリシのインスタンスの優先度７００３は「４０」となる。

業務定義テーブル１０３４に格納された業務番号「２」の業務の方が、業務番号「１」の業務よりも重要度は低いが、システム構成および状態から算出されるリソースの冗長度が「ＷｅｂＡＰサーバＤ」の方が小さく、業務に及ぼす影響が大きいため、ポリシ適用テーブル１０３３に格納されるポリシのインスタンスの優先度は高く計算される。

（リソースの優先度の計算方法の変更例）
リソースの優先度の計算方法は、前記の図１４から図１６に示した手順に限定することなく、様々に変更可能である。以下、リソースの優先度の計算方法の変更例について説明する。

まず、リソースの優先度をＲｓ、業務の重要度をＧｓ、リソースの冗長度をＲｒとする。図１６のフローチャートで示した通り、（１−Ｒｒ）は同一機能を有するリソースのうち、優先度の算出対象のリソースまたは障害状態にあるリソースが占める割合である。そこで、本実施形態では、業務に及ぼす影響の大きさを判断する値（影響度）として、（１−Ｒｒ）を利用する。図１５に示したフローチャートのステップ１５０３０におけるリソースの優先度Ｒｓは、次の数式１で表現できる。

Ｒｓ＝Ｇｓ×（１−Ｒｒ） ・・・（１）

ただし、このリソースを利用する業務が複数ある場合は、すべての業務における上記の値を積算したものとなる。

ここで、数式１によってリソースの優先度Ｒｓが算出される場合、業務の重要度Ｇｓの差が小さい業務がそれぞれ利用するリソースの優先度Ｒｓは、リソースの冗長度Ｒｒに大きく依存することとなる。従って、業務の重要度Ｇｓをより重視する場合、リソースの冗長度Ｒｒがリソースの優先度Ｒｓに影響する度合いを小さくできることが望ましい。その場合、リソースの優先度Ｒｓを算出する式としては、例えば、次の数式２を用いることができる。

Ｒｓ＝Ｇｓ×（１＋α（１−Ｒｒ）） ・・・（２）
ただし、α＞０

パラメータαを操作することにより、重要度Ｇｓまたは冗長度Ｒｒがそれぞれリソースの優先度Ｒｓに影響する度合いを調整することができる。

また、業務の重要度Ｇｓが低い場合においても、決してシステムを停止することができない場合、冗長度Ｒｒの低い箇所においてリソースの優先度Ｒｓがより大きくなるようにできることが望ましい。その場合、リソースの優先度Ｒｓを算出する式としては、例えば、次の数式３を用いることができる。

Ｒｓ＝Ｇｓ×（１−Ｒｒ）＾ｎ ・・・（３）
ただし、１≦ｎ

また、リソースの冗長度Ｒｒについても、前記の方法によってのみ算出されるものではない。例えば、ＲＡＩＤ５やＲＡＩＤ６などは、ディスクが冗長化されているため、それぞれ１台または２台の障害までは許容できるが、それ以上の数のディスクに障害が発生した場合、機能が停止してしまう。従って、同一機能を有するリソースの数がある値を下回ると機能が停止しまうような場合、ここリソースの数がその値に近いならば、リソースの冗長度を低く設定することが望ましい。

ここで、業務に対して同一機能を有するリソースの総数をＲｎａ、そのうち優先度の算出対象のリソース以外で正常な状態にあるリソースの数をＲｎｓ、機能を停止させないために最低限必要なリソースの数をＲｍｉｎとすると、機能を停止させずに変動可能なリソースの数は、Ｒｎａ−Ｒｍｉｎである。同一機能を有するリソースの数が、機能を停止させないために最低限必要なリソースの数に近い場合に、リソースの冗長度を低く設定する計算式としては、例えば、次の数式４を用いることができる。

Ｒｒ＝（Ｒｎｓ−Ｒｍｉｎ＋１）／（Ｒｎａ−Ｒｍｉｎ＋１） ・・・（４）
ただし、Ｒｎｓ≧Ｒｍｉｎ
Ｒｒ＝０
ただし、Ｒｎｓ＜Ｒｍｉｎ

数式４において、リソースの数Ｒｎｓが最低限必要なリソースの数Ｒｍｉｎを下回った場合は、リソースの冗長度Ｒｒが０となり、リソースの優先度Ｒｓは高く設定される。

また、前記の方法では、リソースの数および状態のみを利用してリソースの冗長度を算出したが、各々のリソースの違いを考慮する場合、各々のリソースの情報を利用してリソースの冗長度を算出できることが望ましい。ここで、正常に稼動するリソースのうちの１台に障害が発生する確率をｐとする。ｐは、各リソースの故障率などから算出することが可能である。リソースの故障率を利用し、さらに１台に障害が発生した場合における業務の影響を考慮してリソースの冗長度Ｒｒを設定する計算式としては、例えば、次の数式５を用いることができる。

Ｒｒ＝（１−ｐ）×Ｒｎｓ／Ｒｎａ＋ｐ×（Ｒｎｓ−１）／Ｒｎａ ・・・（５）

数式５において、リソースごとに故障率は異なるため、ｐの値はそれぞれのリソースの特性を反映した値が算出される。

以上のように、時々刻々変化するシステム構成情報から、業務が利用するリソースの構成情報を取得してリソースの優先度を動的に算出する方法であれば、他の方法により算出してもよい。

次に、図１７は、ポリシ適用部１０２５における処理を説明するフローチャートの例である。図１７を参照して、ポリシ適用部１０２５の処理を説明する。前記のように、ポリシ適用部１０２５は、優先度の高いポリシのインスタンスを選択し、情報処理システムに適用する処理部である。

まず、ポリシ適用部１０２５は、ポリシ適用テーブル１０３３の適用状態７００４が「未適用」である行のうち、優先度７００３の値が最も高い行（ポリシ）を特定し（ステップ１７０００）、この行（ポリシ）の適用状態７００４を「適用中」に更新する（ステップ１７０１０）。

次に、ポリシ定義テーブル１０３２（図６参照）におけるポリシ定義ＩＤ６０００が、ステップ１７０００で選択した行のポリシ定義ＩＤ７００２と一致する行を選択し、この行のアクション６００３より特定されるコマンドやスクリプトを実行することで、ポリシに定義されたアクションを実行する（ステップ１７０２０）。
そして、コマンドやスクリプトの実行後、ポリシ適用テーブル１０３３において、ステップ１７０００で選択した行（ポリシ）を削除する（ステップ１７０３０）。

そして、ポリシ適用部１０２５は、ステップ１７０００で選択した行のイベント通し番号７００１を、障害監視部１０２１へ送信し、障害の対処の完了を通知する（ステップ１７０４０）。すると、障害監視部１０２１は、障害情報テーブル１０３１におけるイベント通し番号５０００が、受信したイベント通し番号と一致する行を削除する。さらに、障害情報テーブル１０３１のＩＰアドレス５００４が、該行のＩＰアドレス５００４と一致し、かつ状態５００５が「障害」と一致する行が存在しない場合、構成管理部１０２６に該ＩＰアドレスを通知する。構成管理部１０２６は、システム構成テーブル１０３５におけるＩＰアドレス１０００２が、通知されたＩＰアドレスと一致する行を選択し、この行の状態１０００７を未設定に戻す。

具体的には、図７に示したポリシ適用テーブル１０３３おいて、適用状態７００４が「未適用」であり、最も優先度７００３の高いポリシは、ポリシ適用ＩＤ７０００「００２」のポリシであり、ポリシ定義ＩＤ７００２は「００１」である。したがって、ポリシ適用部１０２５は、ポリシ定義テーブル１０３２（図６参照）を参照して、ポリシ定義ＩＤ６０００「００１」のポリシに定義されたアクション６００３「D:\script\scriptA」で特定されるコマンドやスクリプトを実行する。そして、コマンドやスクリプトの実行後、ポリシ適用テーブル１０３３におけるポリシ適用ＩＤ７０００が「００２」と一致する行を削除する。

次に、ポリシ適用部１０２５は、イベント通し番号「００２」を障害監視部１０２１へ送信し、障害監視部１０２１は、障害情報テーブル１０３１におけるイベント通し番号５０００が「００２」と一致する行を削除する。障害情報テーブル１０３１のＩＰアドレス５００４が「192.168.1.10」と一致し、かつ状態５００５が「障害」と一致する行が存在しない場合、障害監視部１０２１は、構成管理部１０２６にＩＰアドレス「192.168.1.10」を送信し、構成管理部１０２６が、システム構成テーブル１０３５におけるＩＰアドレス１０００２が「192.168.1.10」と一致する行の状態１０００７を未設定にする。

次に、図１８は、運用管理装置１０００の表示装置１０７０（図２参照）に表示されるポリシインスタンス一覧画面を示す図面である。図１８に示したポリシインスタンス一覧画面１０７１は、ポリシ適用ＩＤ、適用状態、優先度など、情報処理システムで発生した障害に対して適用するポリシのインスタンスの各種情報を含む。ポリシインスタンス一覧画面１０７１には、それぞれポリシのインスタンスの優先度が表示されているため、運用管理者が、どの障害を優先して復旧しているかを確認することができる。さらに、優先度に応じて画面に表示する色を変更することにより、重大な障害が発生したことを、運用管理者が一目で把握できるように支援することが可能である。画面に表示する色以外でも、優先度に応じて画面への表示方法を変更してもよい。

また、図１９は、表示装置１０７０に表示される業務システム画面を示す図面である。図１９に示した業務システム画面１０７２は、図８で示した情報処理システムの論理的な接続関係を業務ごとに表示すると共に、情報処理システムを構成するリソースの一覧を表示する画面である。

業務システム画面１０７２において、システム構成表示エリア１０７３は、各業務のシステム構成を表示する領域である。システム構成表示エリア１０７３では、障害が発生しているリソースを明示すると共に、リソースの優先度に応じて表示する色などを変更することにより、重大な障害が発生したことを、運用管理者が一目で把握できるように支援することが可能である。

また、リソース一覧エリア１０７４は、すべてのリソースの情報を表示するための領域である。リソース一覧エリア１０７４においても、システム構成表示エリア１０７３と同様に、優先度に応じて画面への表示方法を変更することにより、運用管理者が、全ての業務において最も及ぼす影響の大きいリソースを特定できるように支援することが可能である。

図１８および図１９に例示した表示画面は、運用管理装置１０００のディスク装置１０３０に格納された各情報に基づいて、表示処理部１０２７が作成する。作成された表示画面は、表示処理部１０２７が、ディスプレイインタフェース１０６０を介して、表示装置１０７０に出力する。

以上、説明した本実施形態の運用管理装置によると、情報処理システムに発生した障害の復旧処理の優先順位を、障害が発生したリソースの優先度に基づいて決定することができるので、サービスに及ぼす影響の大きい障害を優先して復旧することができる。

(第２実施形態)
前記の第１実施形態は、複数の障害が発生した場合に、障害が発生したリソースの優先度に基づいて算出した復旧処理の優先度を比較することにより、優先度の高い復旧処理を先に実行する例である。
一方、第２実施形態では、本発明を単一の障害に適用した例であり、情報処理システムを構成するすべてのリソースの優先度を算出し、優先度の高いリソースに障害が発生した場合に、このリソースの優先度よりも、優先度の低いリソースの業務への割り当てを解除し、優先度の高いリソースの代替リソースとして利用する。
したがって、余剰リソースが存在しない場合であっても、業務に重大な影響を及ぼす障害を遅延なく復旧することが可能となる。
なお、以下の説明において、第１実施形態と同様の構成については、同じ参照符号を付してその詳細な説明は省略する。

（運用管理装置の構成）
図２０は、本実施形態に係る運用管理装置１０００の構成を示す図である。
ディスク装置１０３０は、図２に示した第１実施形態の運用管理装置１０００と同様に、障害情報テーブル１０３１と、ポリシ定義テーブル１０３２と、ポリシ適用テーブル１０３３と、業務定義テーブル１０３４と、システム構成テーブル１０３５と、対処スクリプト１０３６とを有する。本実施形態の運用管理装置１０００は、さらに、リソース管理テーブル１０３７と、再割当定義テーブル１０３８と、再割当スクリプト１０３９とを有する。

リソース管理テーブル１０３７は、情報処理システムを構成するリソースの名称や種別、業務への割り当て状態を格納するためのテーブルである。
再割当定義テーブル１０３８は、リソースの業務への割り当てを解除する際の制約や、割り当てを解除する際の処理に関する情報を格納するためのテーブルである。

再割当スクリプト１０３９は、リソースを再割り当てする際に、業務に割り当てられたリソースの割り当てを解除するために実行する処理を記述したプログラムである。再割当スクリプト１０３９は、バッチファイルなど、リソースの業務への割り当てを解除する処理が実行できるものであればよい。図２０に示した運用管理装置１０００では、再割当スクリプト１０３９を１つ備える構成を例示したが、再割当スクリプトを２つ以上備える構成とすることもできる。

主記憶装置１０２０には、図２に示した第１実施形態の運用管理装置１０００と同様に障害監視部１０２１、ポリシ管理部１０２２、ポリシ制御部１０２３、構成管理部１０２６、および表示処理部１０２７を有する。本実施形態の運用管理装置１０００は、さらにリソース管理部１０２８を有している。
また、ポリシ制御部１０２３は、第１実施形態の運用管理装置１０００と同様に優先度計算部１０２４とポリシ適用部１０２５からなる。

本実施形態のポリシ制御部１０２３は、システム構成テーブル１０３５に格納されるすべてのリソースの優先度を、優先度計算部１０２４で算出し、算出したリソースの優先度に基づき、ポリシ適用テーブル１０３３に格納されるポリシのインスタンスの優先度を算出し、ポリシ適用部１０２５で優先度の最も高いポリシのインスタンスを適用する。障害が発生したリソースの優先度から、ポリシのインスタンスの優先度のみを算出する第１実施形態とは異なり、本実施形態にかかるポリシ制御部１０２３は、すべてのリソースの優先度を算出する。

リソース管理部１０２８は、情報処理システムを構成するリソースを管理する処理部であり、リソースの業務への割り当てなどを行なう。リソース管理部１０２８は、十分な余剰リソースが存在しない場合、優先度の低いリソースの業務への割り当てを解除し、優先度の高いポリシのインスタンスが使用するリソースを確保する。

（運用管理装置の動作概要）
次に、図２１は、本実施形態に係る運用管理装置１０００の動作の概要を説明する説明図である。運用管理装置１０００が、優先度の低いリソースの業務への割り当てを解除し、優先度の高いポリシが使用するリソースを確保するまでの流れを、図２１を用いて説明する。
ここで、情報処理システムからイベント４０００を受信してから、ポリシ管理部１０２２が適用するポリシのインスタンスをポリシ適用テーブル１０３３に格納するまでの流れ（ステップｓ１〜ステップｓ９）は、図３に示した第１実施形態における処理と同様であるため、その説明を省略する。

次に、ポリシ制御部１０２３は、ポリシ適用テーブル１０３３へのポリシのインスタンスの格納を契機に、優先度計算部１０２４で、業務定義テーブル１０３４およびシステム構成テーブル１０３５を参照し（ステップｓ１０）、システム構成テーブル１０３５に格納されるすべてのリソースの優先度を算出する（ステップｓ１１、ステップｓ１２）。
そして、ポリシ制御部１０２３は、障害情報テーブル１０３１およびポリシ適用テーブル１０３３より、ポリシのインスタンスを適用するリソースを特定し（ステップｓ１３）、システム構成テーブル１０３５から取得したリソースの優先度を、このポリシのインスタンスの優先度として設定する（ステップｓ１４）。

次に、ポリシ適用部１０２５は、代替リソースをリソース管理部１０２８に対して要求する処理が、ポリシのアクションに定義された場合において、このポリシのインスタンスを適用することにより、リソース管理部１０２８から代替リソースを確保する（ステップｓ１５）。このとき、十分な余剰リソースが存在しない場合、リソース管理部１０２８は、システム構成テーブル１０３５より優先度の低いリソースを特定し（ステップｓ１６）、リソース管理テーブル１０３７および再割当定義テーブル１０３８を参照して、このリソースの業務への割り当てを解除することが可能であるか確認する（ステップｓ１７）。

次に、リソース管理部１０２８は、このリソースの業務への割り当てを解除し（ステップｓ１８）、リソース管理テーブル１０３７を更新する（ステップｓ１９）。そして、ポリシ適用部１０２５は、確保したリソースを利用してポリシのインスタンスを適用する（ステップｓ２０）。
そして、ポリシのインスタンスの適用後、ポリシ適用部１０２５は、障害への対処の完了を障害監視部１０２１へ通知し、障害監視部１０２１が、構成管理部１０２６で障害が発生したリソースの状態を元に戻す(ステップｓ２１)。

（ディスク装置に格納された情報）
以下、運用管理装置１０００のディスク装置１０３０に格納された各テーブルに含まれる情報について、第１実施形態と異なる部分について説明する。

図２２は、ディスク装置１０３０に格納されたシステム構成テーブル１０３５に含まれる情報を表すテーブルである。
図２２に示すように、システム構成テーブル１０３５は、図１０に示した第１実施形態のシステム構成テーブル１０３５と同様に、リソース番号１００００、リソース名１０００１、ＩＰアドレス１０００２、リソース種別１０００３、接続リソース１０００４、リソースグループ１０００５、業務番号１０００６および状態１０００７を含む。さらに、本実施形態のシステム構成テーブル１０３５は優先度１０００８を含んでいる。

優先度１０００８は、情報処理システムを構成するリソースの重要性を示す情報であり、優先度計算部１０２４で算出されたリソースの優先度が設定される。

図２３は、ディスク装置１０３０に格納されたリソース管理テーブル１０３７に含まれる情報を表すテーブルである。
リソース管理テーブル１０３７は、情報処理システムを構成するリソースの名称や種別、業務への割り当て状態を格納するためのテーブルである。リソース管理テーブル１０３７には、業務に割り当てられていないリソースの情報も格納される。

図２３に示すように、リソース管理テーブル１０３７は、リソース名２３０００、ＩＰアドレス２３００１、種別２３００２、および割当状態２３００３からなり、情報処理システムを構成するリソースごとにリソース名２３０００、ＩＰアドレス２３００１、種別２３００２、および割当状態２３００３が格納される。

リソース名２３０００は、情報処理システムを構成するリソースの名称を示す文字列が設定される。本実施形態では、例えば「ＷｅｂＡＰサーバＡ」が設定される。業務に割り当てられていないリソースは、リソース名２３０００が設定されていなくてもよい。業務に割り当てられていないリソースのリソース名２３０００は、ポリシに定義されたアクションによって、このリソースが業務に割り当てられる際に設定される。

ＩＰアドレス２３００１は、情報処理システムにおいてリソースを一意に識別し、このリソースと通信する際に相手先を特定するための値が設定される。本実施形態では、リソースのＩＰアドレスが設定される。
種別２３００２は、ロードバランサやサーバなどリソースの分類を示す文字列や数値が設定される。システム構成テーブル１０３５のリソース種別１０００３に設定された「ＷｅｂＡＰサーバ」や「ＤＢサーバ」などのように、業務におけるリソースの役割に応じて分類することもできるし、本実施形態における「サーバ」のように、より抽象的な分類とすることもできるし、ハードウェアレベルの分類とすることもできる。

割当状態２３００３は、リソースが業務に割り当てられているか否かを示す文字列や数値が設定される。本実施形態では、「割当済」または「未割当」が設定される。「割当済」であるリソースは、既に業務に割り当てられていることを表す。「未割当」であるリソースは、業務に割り当てられておらず、代替リソースとして利用することが可能であることを表す。

図２４は、ディスク装置１０３０に格納された再割当定義テーブル１０３８に含まれる情報を表すテーブルである。
再割当定義テーブル１０３８は、リソースの業務への割り当てを解除する際の制約や、割り当てを解除する際の処理に関する情報を格納するためのテーブルである。

図２４に示すように、再割当定義テーブル１０３８は、業務番号２４０００、リソース種別２４００１、最小構成２４００２、再割当可否２４００３および再割当処理２４００４からなり、業務におけるリソースの分類ごとに、業務番号２４０００、リソース種別２４００１、最小構成２４００２、再割当可否２４００３および再割当処理２４００４が格納される。

業務番号２４０００は、情報処理システムで実行される業務を一意に識別するための番号であり、業務定義テーブル１０３４の業務番号９０００のうち、該当する業務番号が設定される。
リソース種別２４００１は、リソースの分類を表し、システム構成テーブル１０３５のリソース種別１０００３のうち、該当するリソース種別が設定される。

最小構成２４００２は、同一機能を有するリソースの最小構成を表し、同一機能を有するリソースの数の最小値が設定される。業務に割り当てられているリソースのうち、同一機能を有するリソースで障害状態にないリソースの数が、最小構成２４００２に設定される値に達していない場合は、業務への割り当てを解除することはできない。最小構成２４００２は、ユーザが業務要件などから設定するものとする。最小構成２４００２は、同一機能を有するリソースの数以外にも、同一機能を有するリソースの処理能力などにすることもできる。

再割当可否２４００３は、リソースを再割当することが可能であるか否かを示す文字列や数値が設定される。本実施形態では、「可」または「不可」が設定される。「可」の場合、リソースを再割当することが可能である。「不可」の場合、リソースを再割当することができない。
再割当処理２４００４は、リソースを再割当する際に、このリソースの業務への割り当てを解除するために実行するコマンドやスクリプトなどを特定するための情報が設定される。本実施形態では、オペレーティングシステムが基本的な機能として提供するコマンドやスクリプト、運用管理装置１０００のディスク装置１０３０に格納された再割当スクリプト１０３９を特定するためのパスが格納される。

図２４に示した再割当定義テーブル１０３８において、再割当処理２４００４の「D:\script\WebAP\scriptA」で特定されるプログラムは、リソース種別が「ＷｅｂＡＰサーバ」であるリソースの業務への割り当てを解除するための処理が記述されたコマンドやスクリプトなどである。このプログラムには、例えば、ロードバランサＡ１４００の設定情報において、クライアント１２００からの処理要求の振り分け先として指定されているＷｅｂＡＰサーバＡ１５００を削除し、ＷｅｂＡＰサーバＡ１５００のＷｅｂＡＰサーバ制御機能１５１０を利用して、業務プログラム１５１１を停止するための処理が記述される。

図２５は、本実施形態に係るポリシ制御部１０２３の処理を説明するフローチャートの例である。図２５を参照して、ポリシ制御部１０２３の処理を説明する。

まず、ポリシ制御部１０２３は、システム構成テーブル１０３５におけるすべての行のリソースグループ１０００５、業務番号１０００６および状態１０００７、つまりリソースの情報を記憶する（ステップ２５０００）。
そして、システム構成テーブル１０３５の各行に対して、ステップ２５０２０からステップ２５０３０を繰り返す（ステップ２５０１０）。

まず、ポリシ制御部１０２３は、現在処理対象の行に対して、この行のＩＰアドレス１０００２を取得し、優先度計算部１０２４でリソースの優先度を算出する（ステップ２５０２０）。優先度計算部１０２４では、ステップ２５０２０で取得したＩＰアドレスに基づいて、リソースの優先度を算出する。なお、このリソースの優先度の計算手順については、図１４を用いて説明した第１実施形態の手順と同様である。
そして、システム構成テーブル１０３５（図２２参照）の現在処理対象の行に対して、この行の優先度１０００８に、ステップ１３０４０で算出したリソースの優先度を設定する（ステップ２５０３０）。システム構成テーブル１０３５のすべての行において、優先度１０００８を設定するまでステップ２５０２０からステップ２５０３０を繰り返す（ステップ２５０４０）。

次に、ポリシ制御部１０２３は、ポリシ適用テーブル１０３３のすべての行において、優先度７００３を設定する（ステップ２５０５０）。なお、ポリシ適用テーブル１０３３に優先度を設定する手順については、図２６を参照して後記する。
そして、システム構成テーブル１０３５におけるすべての行のリソースグループ１０００５、業務番号１０００６および状態１０００７が、ステップ２５０００で記憶したリソースグループ、業務番号および状態と一致しているか否かを判定し（ステップ２５０６０）、一致していない場合（ステップ２５０６０でＮｏ）、ステップ２５０００へ戻りシステム構成テーブル１０３５の優先度１０００８を再度計算する。一致している場合（ステップ２５０６０でＹｅｓ）、ポリシ適用部１０２５で優先度の高いポリシのインスタンスを適用する（ステップ２５０７０）。
この、優先度の高いポリシのインスタンスを適用する手順については、図１７を用いて説明した第１実施形態の手順と同様である。

ポリシ制御部１０２３の処理は、プログラムが起動するとループ状態になり、プログラム起動中は継続的にリソースおよびポリシのインスタンスの優先度の計算と、ポリシのインスタンスの適用を繰り返す。プログラムが終了すると、ポリシ制御部１０２３の処理は終了するか否かを判定し（ステップ２５０８０）、終了しない場合は（ステップ２５０８０で‘Ｎｏ’）、ステップ２５０００からの処理を繰り返す。

図２６は、図２５で示したフローチャートのステップ２５０５０で呼び出される処理を説明するフローチャートの例である。図２６に示すフローチャートでは、ポリシ適用テーブル１０３３（図７参照）のすべての行の優先度７００３を設定する。

そのために、ポリシ適用テーブル１０３３（図７参照）の各行に対して、ステップ２６０１０からステップ２６０３０を繰り返す（ステップ２６０００）。
まず、障害情報テーブル１０３１におけるイベント通し番号５０００が、現在処理対象の行のイベント通し番号７００１に一致する行を選択し、この行のＩＰアドレス５００４を取得する。これにより、障害が発生したリソースを特定する（ステップ２６０１０）。

次に、システム構成テーブル１０３５におけるＩＰアドレス１０００２が、ステップ２６０１０で取得したＩＰアドレスと一致する行（リソース）を選択し、この行（リソース）の優先度１０００８を取得する（ステップ２６０２０）。
そして、ポリシ適用テーブル１０３３の現在処理対象の行に対して、この行の優先度７００３に、ステップ２６０２０で取得したリソースの優先度を設定する（ステップ２６０３０）。ポリシ適用テーブル１０３３のすべての行において、優先度７００３を設定するまでステップ２６０１０からステップ２６０３０を繰り返す（ステップ２６０４０）。

次に、図２７は、リソース管理部１０２８の処理を説明するフローチャートの例である。図２７を参照して、リソース管理部１０２８の処理を説明する。前記のように、リソース管理部１０２８は、指定されたリソースの代替リソースを確保する処理部であり、障害が発生したリソースの代替リソースをリソース管理部１０２８に対して要求する処理が、ポリシのアクションに定義された場合において、このポリシをポリシ適用部１０２５が適用することにより呼び出される。

まず、リソース管理部１０２８は、ポリシ適用部１０２５から障害が発生したリソースのＩＰアドレスを取得する（ステップ２７０００）。
そして、リソース管理テーブル１０３７（図２３参照）におけるＩＰアドレス２３００１が、ステップ２７０００で取得したＩＰアドレスと一致する行を選択し、この行の種別２３００２を取得する。これにより、障害が発生したリソースの種別を特定する（ステップ２７０１０）。

次に、リソース管理部１０２８は、リソース管理テーブル１０３７における種別２３００２が、ステップ２７００１で取得した種別と一致する行をすべて選択することで、同一の種類のリソースを特定する（ステップ２７０２０）。
そして、ステップ２７０２０で選択した行のうち、割当状態２３００３が「未割当」である行が存在するか否かを確認し（ステップ２７０３０）、「未割当」の行が存在する場合（ステップ２７０３０でＹｅｓ）、ステップ２７１２０へ移る。一方、「未割当」の行が存在しない場合（ステップ２７０３０でＮｏ）、ステップ２７０４０へ移る。

次に、リソース管理部１０２８は、システム構成テーブル１０３５（図２２参照）におけるＩＰアドレス１０００２が、ステップ２７０００で取得したＩＰアドレスと一致する行を選択し、この行の優先度１０００８を取得する。これにより、障害が発生したリソースの優先度を取得する（ステップ２７０４０）。
そして、システム構成テーブル１０３５におけるＩＰアドレス１０００２が、主記憶装置１０２０に記憶されておらず、かつＩＰアドレス１０００２がステップ２７０２０で選択した行のいずれかの行のＩＰアドレス２３００１と一致し、かつ状態１０００７が「障害」ではなく、優先度１０００８がステップ２７０４０で取得した優先度よりも低い行のうち、優先度１０００８が最も低い行を選択し、この行のＩＰアドレス１０００２とリソース種別１０００３と業務番号１０００６を取得する（ステップ２７０５０）。
ステップ２７０５０において、リソース管理部１０２８は、ＩＰアドレス１０００２を取得した後、取得したＩＰアドレスを主記憶装置１０２０に記憶する。主記憶装置１０２０に記憶されたＩＰアドレスは、本処理の終了時にすべて削除する。さらに、ステップ２７０５０において取得した業務番号１０００６は、主記憶装置１０２０に記憶する。

次に、リソース管理部１０２８は、主記憶装置１０２０に記憶されたすべての業務番号について、ステップ２７０６０ないしステップ２７１００の処理を繰り返す（ステップ２７０６０）。そのため、記憶された業務番号のいずれかを取得し、取得した後、この業務番号を主記憶装置１０２０から削除する。
そして、再割当定義テーブル１０３８（図２４参照）における業務番号２４０００が、ステップ２７０６０から取得した業務番号と一致し、かつリソース種別２４００１が、ステップ２７０５０で取得したリソース種別と一致する行を選択する。これにより、ステップ２７０５０で特定したリソースの再割当定義を特定する（ステップ２７０７０）。

次に、リソース管理部１０２８は、ステップ２７０７０で選択した行の再割当可否２４００３が「可」であるか確認する（ステップ２７０８０）。「可」でない場合（ステップ２７０８０でＮｏ）、ステップ２７０５０へ戻る。「可」である場合（ステップ２７０８０でＹｅｓ）、システム構成テーブル１０３５におけるリソースグループ１０００５が、ステップ２７０５０で選択した行のリソースグループ１０００５と一致し、かつ業務番号１０００６が、ステップ２７０６０で選択した業務番号を含み、かつ状態１０００７が「障害」ではない行の総数を算出し、算出した値が、再割当定義テーブル１０３８における最小構成２４００２の値より大きいか否かを確認する。これにより、リソースの組み合わせが最小構成を満たすか否かを判定する（ステップ２７０９０）。

ステップ２７０９０において、最小構成２４００２の値以下である場合（ステップ２７０９０でＮｏ）、ステップ２７０５０へ戻る。最小構成２４００２の値より大きい場合（ステップ２７０９０でＹｅｓ）、ステップ２７０７０で選択した行の再割当処理２４００４を主記憶装置１０２０に記憶し、ステップ２７１１０へ移る。そして、主記憶装置１０２０に記憶されたすべての業務番号について、ステップ２７０６０からステップ２７０９０の処理を繰り返す（ステップ２７１００）。

次に、リソース管理部１０２８は、主記憶装置１０２０に記憶された再割当処理２４００４により特定されるコマンドやスクリプト、または再割当スクリプト１０３９を実行することにより（ステップ２７１１０）、ステップ２７０５０で取得したＩＰアドレスで特定されるリソースの業務への割り当てを解除する。そして、主記憶装置１０２０に格納された再割当処理２４００４を削除する。ステップ２７０５０で取得した業務番号が複数である場合、主記憶装置１０２０に記憶された再割当処理２４００４より特定されるコマンドやスクリプト、または再割当スクリプト１０３９をすべて実行する。

ステップ２７１１０において、再割当処理２４００４により特定されるコマンドやスクリプト、または再割当スクリプト１０３９が実行されると、リソース管理部１０２８は、このリソースの割り当て解除を通知される。リソース管理部１０２８は、リソース管理テーブル１０３７（図２３参照）におけるＩＰアドレス２３００１が、再割当処理２４００４により特定されるコマンドやスクリプト、または再割当スクリプト１０３９から通知されたＩＰアドレスと一致する行を選択し、この行のリソース名２３０００を未設定にし、割当状態２３００３を「未割当」に設定する。さらに、リソース管理部１０２８は、このリソースの割り当て解除を構成管理部１０２６へ通知する。構成管理部１０２６は、システム構成テーブル１０３５におけるＩＰアドレス１０００２が、通知されたＩＰアドレスと一致する行を削除し、この行のリソース番号を、システム構成テーブル１０３５におけるすべての接続リソース１０００４から削除する。

次に、リソース管理部１０２８は、リソース管理テーブル１０３７（図２３参照）における種別２３００２が、ステップ２７０１０で取得したリソース種別と一致し、かつ割当状態２３００３が「未割当」である行の割当状態２３００３を「割当済」に設定し、この行のＩＰアドレス２３００１を、ポリシ適用部１０２５に返す（ステップ２７１２０）。そして、ポリシ適用部１０２５は、ステップ２７１２０で取得したＩＰアドレスにより特定されるリソースを利用して、ポリシに定義されたアクションの実行を継続する。

本実施の形態は、単一の障害が発生した場合に、優先度の低いリソースの業務への割り当てを解除し、この障害の復旧処理に利用するものであるが、単一の障害が発生した場合の本発明の適用例として、ポリシのインスタンスの優先度にしきい値を設けることによって、このしきい値を超過した場合のみポリシのインスタンスを適用することにより、優先度が低い、すなわち障害が業務に及ぼす影響が小さい場合は、通常業務を優先させることも可能である。

以上、説明した本実施形態の運用管理装置によると、優先度の高いリソースに障害が発生した場合に、優先度の低いリソースを代替として利用することができるので、余剰リソースが存在しない場合であっても、サービスに及ぼす影響の大きい障害を遅延なく復旧でき、リソースを有効活用できる。

第１実施形態に係る運用管理装置が適用された情報処理システムの全体構成を示す図面である。 運用管理装置の構成を示す図面である。 運用管理装置の動作の概要を説明する説明図である。 障害監視部が情報処理システムから受信するイベントに含まれる情報を表すテーブルである。 障害情報テーブルに含まれる情報を表すテーブルである。 ポリシ定義テーブルに含まれる情報を表すテーブルである。 ポリシ適用テーブルに含まれる情報を表すテーブルである。 情報処理システムの業務実行時における論理的な接続関係の例を説明する図面である。 業務定義テーブルに含まれる情報を表すテーブルである。 システム構成テーブルに含まれる情報を表すテーブルである。 障害監視部の処理を説明するフローチャートである。 ポリシ管理部の処理を説明するフローチャートである。 ポリシ制御部の処理を説明するフローチャートである。 優先度計算部の処理を説明するフローチャートである。 優先度計算部における処理を説明するフローチャートである。 優先度計算部における処理を説明するフローチャートである。 ポリシ適用部における処理を説明するフローチャートである。 ポリシインスタンス一覧画面を示す図面である 業務システム画面を示す図面である。 第２実施形態に係る運用管理装置の構成を示す図である。 運用管理装置の動作の概要を説明する説明図である。 システム構成テーブルに含まれる情報を表すテーブルである。 リソース管理テーブルに含まれる情報を表すテーブルである。 再割当定義テーブルに含まれる情報を表すテーブルである。 ポリシ制御部の処理を説明するフローチャートである。 ステップ２５０５０で呼び出される処理を説明するフローチャートである。 リソース管理部の処理を説明するフローチャートである。

符号の説明

１０００ 運用管理装置
１０２１ 障害監視部
１０２２ ポリシ管理部
１０２３ ポリシ制御部
１０２４ 優先度計算部
１０２５ ポリシ適用部
１０２６ 構成管理部
１０２７ 表示処理部
１０２８ リソース管理部

Claims (15)

1. １以上のサービスを提供する１以上の計算機からなる情報処理システムにおいて、前記計算機のハードウェアまたはソフトウェアからなるリソースの前記サービスにおける重要性を示す、リソースの優先度を算出する運用管理装置であって、
   各リソースの機能、その稼動状態、各サービスが利用するリソースおよび前記サービスにおけるリソース間の関係を定義したシステム構成情報と、前記サービスごとに設定された所定の重要度とを少なくとも保持する記憶部と、
   前記システム構成情報より、前記重要度の算出対象となるリソースを利用するサービスを特定し、
   前記システム構成情報より、前記特定したサービスにおいて、前記リソースと同じ機能を有する同等リソースを特定し、
   前記同等リソースの稼動状態およびその数に基づいて、前記リソースが前記サービスに及ぼす影響度を算出し、
   前記サービスの重要度および前記算出した影響度に基づいて、前記リソースの優先度を算出する優先度計算部とを有すること、
   を特徴とする情報処理システムの運用管理装置。
2. 前記計算機から、リソースの稼動状態、各サービスが利用するリソースおよび前記サービスにおけるリソース間の関係の変更の通知を受信すると、前記システム構成情報を更新する構成管理部をさらに有すること、
   を特徴とする請求項１に記載の情報処理システムの運用管理装置。
3. 前記リソースの優先度は、
   前記記憶部に保持された前記サービスの前記重要度と、前記算出した影響度とを用いて次の数式１により算出されること、
   を特徴とする請求項１または請求項２に記載の情報処理システムの運用管理装置。
   Ｒｓ＝Ｇｓ×Ｒｒ ・・・（１）
   ただし、Ｒｓはリソースの優先度、Ｇｓはサービスの重要度、Ｒｒは算出された影響度をそれぞれ表す。
4. 前記リソースの優先度は、
   前記記憶部に保持された前記サービスの前記重要度と、前記算出した影響度と、前記影響度が前記リソースの優先度に影響する度合いを表す所定の係数とを用いて次の数式２により算出されること、
   を特徴とする請求項１または請求項２に記載の情報処理システムの運用管理装置。
   Ｒｓ＝Ｇｓ×（１＋αＲｒ） ・・・（２）
   ただし、Ｒｓはリソースの優先度、Ｇｓはサービスの重要度、Ｒｒは算出された影響度、αは所定の係数（α＞０）をそれぞれ表す。
5. 前記影響度は、
   システム構成情報から、前記同等リソースのうち、前記リソース以外で正常に稼動しているリソースの数を算出し、このリソースの数と、前記同等リソースの総数とを用いて次の数式３により算出されること、
   を特徴とする請求項１ないし請求項４のいずれか１項に記載の情報処理システムの運用管理装置。
   Ｒｒ＝１−ｍ／ｎ ・・・（３）
   ただし、Ｒｒは影響度、ｍは正常に稼動しているリソースの数、ｎは同等リソースの総数をそれぞれ表す。
6. 前記影響度は、
   前記同等リソースのうち、前記リソース以外で正常に稼動しているリソースの数と、システム構成情報に含まれる前記サービスを提供するために最低限必要なリソースの数と、前記同等リソースの総数とを用いて次の数式４又は数式５により算出されること、
   を特徴とする請求項１ないし請求項４のいずれか１項に記載の情報処理システムの運用管理装置。
   Ｒｎｓ≧Ｒｍｉｎにおいて
   Ｒｒ＝（Ｒｎｓ−Ｒｍｉｎ＋１）／（Ｒｎａ−Ｒｍｉｎ＋１） ・・・（４）
   Ｒｎｓ＜Ｒｍｉｎにおいて
   Ｒｒ＝０ ・・・（５）
   ただし、Ｒｒは影響度、Ｒｎｓは正常に稼動しているリソースの数、Ｒｍｉｎは最低限必要なリソースの数、Ｒｎａは同等リソースの総数をそれぞれ表す。
7. 前記影響度は、
   前記同等リソースのうち、前記リソース以外で正常に稼動しているリソースの数と、前記同等リソースの総数と、前記同等リソースの可用性とに基づいて算出されること、
   を特徴とする請求項１ないし請求項４のいずれか１項に記載の情報処理システムの運用管理方法。
8. 前記同等リソースの可用性は、前記同等リソースの各リソースの故障率から算出した前記正常に稼動するリソースのうちの１台に障害が発生する確率を用いて表され、前記影響度は、次の数式６により算出されること、
   を特徴とする請求項６に記載の運用管理方法。
   Ｒｒ＝（１−ｐ）×Ｒｎｓ／Ｒｎａ＋ｐ×（Ｒｎｓ−１）／Ｒｎａ ・・・（６）
   ただし、Ｒｒは影響度、ｐは障害が発生する確率、Ｒｎｓは正常に稼動しているリソースの数、Ｒｎａは同等リソースの総数をそれぞれ表す。
9. 前記記憶部には、
   リソースに発生する障害の内容に応じた復旧処理を定義したポリシをさらに保持し、
   前記計算機から、リソースに発生した障害内容およびそのリソースを特定する情報を含んだ障害情報を受信する障害監視部と、
   前記受信した障害情報に応じた前記ポリシを選択するポリシ管理部と、
   前記選択されたポリシから、障害が発生したリソースを特定し、前記優先度計算部から取得した当該リソースの優先度に基づいて、前記選択されたポリシから、実行するポリシを指定するポリシ制御部と、
   前記ポリシ制御部が指定したポリシに定義された復旧処理を実行するポリシ適用部とをさらに有すること、
   を特徴とする請求項１ないし請求項８のいずれか１項に記載の情報処理システムの運用管理装置。
10. 前記ポリシ制御部は、
    前記優先度計算部の前記リソースの優先度の算出前後で、前記システム構成情報が変化しているか否かを判定し、
    前記システム構成情報が変化している場合は、前記優先度計算部に、当該リソースの優先度を再度算出させること、
    を特徴とする請求項９に記載の情報処理システムの運用管理装置。
11. 前記優先度計算部が算出したリソースの優先度を用いて、前記障害が発生したリソースの優先度より、優先度の低いリソースを特定し、前記システム構成情報から、前記優先度の低いリソースを利用するサービスを特定し、前記優先度の低いリソースの前記サービスへの割り当てを解除し、前記優先度の低いリソースを、代替リソースとして前記ポリシ適用部に通知するリソース管理部をさらに有し、
    前記ポリシ適用部は、
    前記ポリシ制御部が指定したポリシに定義された復旧処理を実行する際に、前記リソース管理部から通知された前記優先度の低いリソースを前記復旧処理に割り当てることを、
    特徴とする請求項９または請求項１０に記載の情報処理システムの運用管理装置。
12. 前記優先度計算部が算出した前記リソースの優先度および前記システム構成情報を閲覧可能な表示画面を作成して出力する表示処理部をさらに有すること、
    を特徴とする請求項１ないし請求項１１のいずれか１項に記載の情報処理システムの運用管理装置。
13. １以上のサービスを提供する１以上の計算機からなる情報処理システムにおいて、前記計算機のハードウェアおよびソフトウェアのリソースの前記サービスにおける重要性を示す、前記リソースの優先度を算出する運用管理装置における運用管理方法であって、
    前記運用管理装置の優先度計算部が、
    前記運用管理装置の記憶部に保持され、各リソースの機能、その稼動状態、各サービスが利用するリソースおよび前記サービスにおけるリソース間の関係を定義したシステム構成情報より、前記リソースを利用するサービスを特定し、
    前記システム構成情報より、前記特定したサービスにおいて、前記リソースと同じ機能を有する同等リソースを特定し、
    前記同等リソースの稼動状態およびその数に基づいて、前記リソースが前記サービスに及ぼす影響度を算出し、
    前記サービスごとに設定され前記記憶部に保持された所定の重要度および前記算出した影響度に基づいて、前記リソースの優先度を算出すること、
    を特徴とする情報処理システムの運用管理方法。
14. 前記運用管理装置の障害監視部が、
    前記計算機から、リソースに発生した障害内容およびそのリソースを特定する情報を含んだ障害情報を受信すると、
    前記運用管理装置のポリシ管理部が、
    前記受信した障害情報に応じて、前記記憶部に保持され、リソースに発生する障害の内容に応じた復旧処理を定義されたポリシを選択し、
    前記運用管理装置のポリシ制御部が、
    前記選択されたポリシから、障害が発生したリソースを特定し、前記優先度計算部から取得した当該リソースの優先度に基づいて、前記選択されたポリシから、実行するポリシを指定し、
    前記運用管理装置のポリシ適用部が、
    前記ポリシ制御部が指定したポリシに定義された復旧処理を実行すること、
    を特徴とする請求項１３に記載の情報処理システムの運用管理方法。
15. 前記ポリシ適用部が、
    前記ポリシ制御部が指定したポリシに定義された復旧処理を実行する際に、前記リソース管理部に代替リソースを要求し、
    前記運用管理装置のリソース管理部が、
    前記優先度計算部が算出したリソースの優先度を用いて、前記障害が発生したリソースの優先度より、優先度の低いリソースを特定し、
    前記システム構成情報から、前記優先度の低いリソースを利用するサービスを特定し、
    前記優先度の低いリソースの前記サービスへの割り当てを解除し、
    前記優先度の低いリソースを、代替リソースとして前記ポリシ適用部に通知し、
    前記ポリシ適用部が、
    前記通知された前記優先度の低いリソースを前記復旧処理に割り当てることを、
    を特徴とする請求項１４に記載の情報処理システムの運用管理方法。

Images