(57)【要約】【課題】サービスの重要度だけでなく、システムの状態を考慮して、利用中のリソースが、サービスに及ぼす影響を定量的に出力する手段を提供すること。【解決手段】各リソースの機能、その稼動状態、各サービスが利用するリソースおよびサービスにおけるリソース間の関係を定義したシステム構成情報（１０３５）と、サービスごとに設定された所定の重要度とを少なくとも保持する記憶部（１０３０）と、システム構成情報（１０３５）より、リソースを利用するサービスを特定し、特定したサービスにおいて、リソースと同一の機能を有する同等リソースを特定し、この同等リソースの状態およびその数に基づいて、リソースがサービスに及ぼす影響度を算出し、サービスの重要度および算出した影響度に基づいて、リソースの優先度を算出する優先度計算部（１０２４）とを有する運用管理装置（１０００）。【選択図】図２
2008217285.tif 000002
【特許請求の範囲】
【請求項１】
１以上のサービスを提供する１以上の計算機からなる情報処理システムにおいて、前記計算機のハードウェアまたはソフトウェアからなるリソースの前記サービスにおける重要性を示す、リソースの優先度を算出する運用管理装置であって、
各リソースの機能、その稼動状態、各サービスが利用するリソースおよび前記サービスにおけるリソース間の関係を定義したシステム構成情報と、前記サービスごとに設定された所定の重要度とを少なくとも保持する記憶部と、
前記システム構成情報より、前記重要度の算出対象となるリソースを利用するサービスを特定し、
前記システム構成情報より、前記特定したサービスにおいて、前記リソースと同じ機能を有する同等リソースを特定し、
前記同等リソースの稼動状態およびその数に基づいて、前記リソースが前記サービスに及ぼす影響度を算出し、
前記サービスの重要度および前記算出した影響度に基づいて、前記リソースの優先度を算出する優先度計算部とを有すること、
を特徴とする情報処理システムの運用管理装置。
【請求項２】
前記計算機から、リソースの稼動状態、各サービスが利用するリソースおよび前記サービスにおけるリソース間の関係の変更の通知を受信すると、前記システム構成情報を更新する構成管理部をさらに有すること、
を特徴とする請求項１に記載の情報処理システムの運用管理装置。
【請求項３】
前記リソースの優先度は、
前記記憶部に保持された前記サービスの前記重要度と、前記算出した影響度とを用いて次の数式１により算出されること、
を特徴とする請求項１または請求項２に記載の情報処理システムの運用管理装置。
Ｒｓ＝Ｇｓ×Ｒｒ  ・・・（１）
ただし、Ｒｓはリソースの優先度、Ｇｓはサービスの重要度、Ｒｒは算出された影響度をそれぞれ表す。
【請求項４】
前記リソースの優先度は、
前記記憶部に保持された前記サービスの前記重要度と、前記算出した影響度と、前記影響度が前記リソースの優先度に影響する度合いを表す所定の係数とを用いて次の数式２により算出されること、
を特徴とする請求項１または請求項２に記載の情報処理システムの運用管理装置。
Ｒｓ＝Ｇｓ×（１＋αＲｒ）  ・・・（２）
ただし、Ｒｓはリソースの優先度、Ｇｓはサービスの重要度、Ｒｒは算出された影響度、αは所定の係数（α＞０）をそれぞれ表す。
【請求項５】
前記影響度は、
システム構成情報から、前記同等リソースのうち、前記リソース以外で正常に稼動しているリソースの数を算出し、このリソースの数と、前記同等リソースの総数とを用いて次の数式３により算出されること、
を特徴とする請求項１ないし請求項４のいずれか１項に記載の情報処理システムの運用管理装置。
Ｒｒ＝１−ｍ／ｎ  ・・・（３）
ただし、Ｒｒは影響度、ｍは正常に稼動しているリソースの数、ｎは同等リソースの総数をそれぞれ表す。
【請求項６】
前記影響度は、
前記同等リソースのうち、前記リソース以外で正常に稼動しているリソースの数と、システム構成情報に含まれる前記サービスを提供するために最低限必要なリソースの数と、前記同等リソースの総数とを用いて次の数式４又は数式５により算出されること、
を特徴とする請求項１ないし請求項４のいずれか１項に記載の情報処理システムの運用管理装置。
Ｒｎｓ≧Ｒｍｉｎにおいて
Ｒｒ＝（Ｒｎｓ−Ｒｍｉｎ＋１）／（Ｒｎａ−Ｒｍｉｎ＋１）  ・・・（４）
Ｒｎｓ＜Ｒｍｉｎにおいて
Ｒｒ＝０  ・・・（５）
ただし、Ｒｒは影響度、Ｒｎｓは正常に稼動しているリソースの数、Ｒｍｉｎは最低限必要なリソースの数、Ｒｎａは同等リソースの総数をそれぞれ表す。
【請求項７】
前記影響度は、
前記同等リソースのうち、前記リソース以外で正常に稼動しているリソースの数と、前記同等リソースの総数と、前記同等リソースの可用性とに基づいて算出されること、
を特徴とする請求項１ないし請求項４のいずれか１項に記載の情報処理システムの運用管理方法。
【請求項８】
前記同等リソースの可用性は、前記同等リソースの各リソースの故障率から算出した前記正常に稼動するリソースのうちの１台に障害が発生する確率を用いて表され、前記影響度は、次の数式６により算出されること、
を特徴とする請求項６に記載の運用管理方法。
Ｒｒ＝（１−ｐ）×Ｒｎｓ／Ｒｎａ＋ｐ×（Ｒｎｓ−１）／Ｒｎａ  ・・・（６）
ただし、Ｒｒは影響度、ｐは障害が発生する確率、Ｒｎｓは正常に稼動しているリソースの数、Ｒｎａは同等リソースの総数をそれぞれ表す。
【請求項９】
前記記憶部には、
リソースに発生する障害の内容に応じた復旧処理を定義したポリシをさらに保持し、
前記計算機から、リソースに発生した障害内容およびそのリソースを特定する情報を含んだ障害情報を受信する障害監視部と、
前記受信した障害情報に応じた前記ポリシを選択するポリシ管理部と、
前記選択されたポリシから、障害が発生したリソースを特定し、前記優先度計算部から取得した当該リソースの優先度に基づいて、前記選択されたポリシから、実行するポリシを指定するポリシ制御部と、
前記ポリシ制御部が指定したポリシに定義された復旧処理を実行するポリシ適用部とをさらに有すること、
を特徴とする請求項１ないし請求項８のいずれか１項に記載の情報処理システムの運用管理装置。
【請求項１０】
前記ポリシ制御部は、
前記優先度計算部の前記リソースの優先度の算出前後で、前記システム構成情報が変化しているか否かを判定し、
前記システム構成情報が変化している場合は、前記優先度計算部に、当該リソースの優先度を再度算出させること、
を特徴とする請求項９に記載の情報処理システムの運用管理装置。
【請求項１１】
前記優先度計算部が算出したリソースの優先度を用いて、前記障害が発生したリソースの優先度より、優先度の低いリソースを特定し、前記システム構成情報から、前記優先度の低いリソースを利用するサービスを特定し、前記優先度の低いリソースの前記サービスへの割り当てを解除し、前記優先度の低いリソースを、代替リソースとして前記ポリシ適用部に通知するリソース管理部をさらに有し、
前記ポリシ適用部は、
前記ポリシ制御部が指定したポリシに定義された復旧処理を実行する際に、前記リソース管理部から通知された前記優先度の低いリソースを前記復旧処理に割り当てることを、
特徴とする請求項９または請求項１０に記載の情報処理システムの運用管理装置。
【請求項１２】
前記優先度計算部が算出した前記リソースの優先度および前記システム構成情報を閲覧可能な表示画面を作成して出力する表示処理部をさらに有すること、
を特徴とする請求項１ないし請求項１１のいずれか１項に記載の情報処理システムの運用管理装置。
【請求項１３】
１以上のサービスを提供する１以上の計算機からなる情報処理システムにおいて、前記計算機のハードウェアおよびソフトウェアのリソースの前記サービスにおける重要性を示す、前記リソースの優先度を算出する運用管理装置における運用管理方法であって、
前記運用管理装置の優先度計算部が、
前記運用管理装置の記憶部に保持され、各リソースの機能、その稼動状態、各サービスが利用するリソースおよび前記サービスにおけるリソース間の関係を定義したシステム構成情報より、前記リソースを利用するサービスを特定し、
前記システム構成情報より、前記特定したサービスにおいて、前記リソースと同じ機能を有する同等リソースを特定し、
前記同等リソースの稼動状態およびその数に基づいて、前記リソースが前記サービスに及ぼす影響度を算出し、
前記サービスごとに設定され前記記憶部に保持された所定の重要度および前記算出した影響度に基づいて、前記リソースの優先度を算出すること、
を特徴とする情報処理システムの運用管理方法。
【請求項１４】
前記運用管理装置の障害監視部が、
前記計算機から、リソースに発生した障害内容およびそのリソースを特定する情報を含んだ障害情報を受信すると、
前記運用管理装置のポリシ管理部が、
前記受信した障害情報に応じて、前記記憶部に保持され、リソースに発生する障害の内容に応じた復旧処理を定義されたポリシを選択し、
前記運用管理装置のポリシ制御部が、
前記選択されたポリシから、障害が発生したリソースを特定し、前記優先度計算部から取得した当該リソースの優先度に基づいて、前記選択されたポリシから、実行するポリシを指定し、
前記運用管理装置のポリシ適用部が、
前記ポリシ制御部が指定したポリシに定義された復旧処理を実行すること、
を特徴とする請求項１３に記載の情報処理システムの運用管理方法。
【請求項１５】
前記ポリシ適用部が、
前記ポリシ制御部が指定したポリシに定義された復旧処理を実行する際に、前記リソース管理部に代替リソースを要求し、
前記運用管理装置のリソース管理部が、
前記優先度計算部が算出したリソースの優先度を用いて、前記障害が発生したリソースの優先度より、優先度の低いリソースを特定し、
前記システム構成情報から、前記優先度の低いリソースを利用するサービスを特定し、
前記優先度の低いリソースの前記サービスへの割り当てを解除し、
前記優先度の低いリソースを、代替リソースとして前記ポリシ適用部に通知し、
前記ポリシ適用部が、
前記通知された前記優先度の低いリソースを前記復旧処理に割り当てることを、
を特徴とする請求項１４に記載の情報処理システムの運用管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１以上の計算機から構成される情報処理システムを自律制御する方法に関し、特に、サービスに及ぼす影響が大きい障害を遅延なく復旧するために、情報処理システムで発生した障害の重大性、およびサービスで利用中のリソースの重要性を、サービスに及ぼす影響を考慮して適切に評価することができる情報処理システムの運用管理装置および運用管理方法に関する。
【背景技術】
【０００２】
情報処理システムを構成するリソース、すなわち計算機などのハードウェアまたはサーバやアプリケーションなどのソフトウェアに障害が発生した場合、運用管理者が、発生した障害の内容に応じた対処を実行することが一般的である。
また、近年では、発生した障害の対処として実行する処理を、予め運用管理装置に設定しておき、障害が発生した場合に、運用管理装置に設定された処理を自動的に実行することで、障害を復旧することも可能になっている。
【０００３】
ところで、情報処理システムでは、短い間隔で複数の障害が発生することもある。
特に、一台の物理ホスト上で複数のサーバを稼動する構成において、物理ホストに障害が発生した場合、その物理ホスト上で稼動する複数のサーバから障害イベントが発生する可能性が高くなる。このような、一台の物理ホスト上で複数のサーバを稼動する構成は、現在でも実現可能な技術であるが、将来、仮想化技術の進歩によって、より一般的になると考えられる。その場合、運用管理者または運用管理装置が、それぞれの障害に応じて対処する必要がある。
【０００４】
しかし、発生した全ての障害を復旧させるために十分な余剰リソースが存在しない場合や、復旧処理を並行して実行することができない場合、すべての障害を遅延なく復旧させることができない可能性がある。したがって、重大な障害が発生した場合、その障害を優先して復旧することが必要である。そのためには、発生した障害の重大性を評価し、復旧処理の優先順位を決定することを支援する機能が望まれる。
【０００５】
また、複数の障害が発生した場合に限らず、単一の障害が発生した場合であっても、余剰リソースが存在しない場合などは、重大な障害の復旧が遅延してしまう可能性がある。このような場合には、サービスに及ぼす影響の小さなリソースを、障害が発生したリソースの代替として利用することにより、遅延なく重大な障害の復旧を行なうことが可能となる。そのためには、発生した障害の重大性を評価するとともに、サービスで利用中のリソースの重要性を評価し、発生した障害の重大性よりも重要でないリソースが存在すれば、そのリソースを融通するなどして、障害を遅延なく復旧することを支援する機能が望まれる。
【０００６】
前記課題に対し、特許文献１に記載の従来技術では、情報処理システムにおいて発生する障害イベントごとに設けた重要度によって、障害の重要性を表現している。
特許文献１に記載の技術によれば、運用管理者または運用管理装置が発生した障害イベントに設定された重要度を参照することによって、より重大な障害の復旧を優先することが可能である。
【０００７】
しかし、障害イベントごとに重要度を設けている場合、その障害がどのサービスに影響を及ぼすかを把握することができない。そのため、サービスに重大な影響を及ぼす障害の復旧が遅延してしまう場合があり、業務上大きな損失を招く可能性があるという問題がある。
したがって、単に障害イベントの重要度に基づいて、障害の復旧を優先するのではなく、サービスにより重大な影響を及ぼす障害の復旧を優先することが必要である。
【０００８】
前記課題に対し、特許文献２では、業務ごとにあらかじめ定義された重要度計算規則に基づいて、障害が発生したリソースを利用する業務の重要度を算出し、算出した重要度を障害の重要度として位置づけている。業務の重要度は、売り上げなどの業務データから算出される。運用管理者は、該業務の重要度をコンソールなどで参照することにより、業務により重大な影響を及ぼす障害を検知することを可能にしている。
【特許文献１】特開２００５−３３１９９８号公報
【特許文献２】特開２００５−３１８９３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、特許文献２では、予め定義された業務の重要度計算規則に従って算出した重要度を障害の重要度として位置づけているため、障害が業務に与える影響を情報処理システムの状態に応じて区別することができないという問題がある。
【００１０】
例えば、業務の停止を招くような障害が発生した場合であっても、重要度計算規則によって、その業務よりわずかに重要度が高く計算された別の業務に障害が発生すると、その障害によって業務が停止する可能性が低くても、その障害の復旧を優先することになる。なぜなら、運用管理者はコンソールなどに表示された業務の重要度に基づいて、復旧処理の優先順位を決定するからである。重要度の大きな業務に発生した障害であっても、障害の程度によって復旧処理の優先順位を決定しなければ、結果的に業務上大きな損失を招く可能性がある。
【００１１】
したがって、発生した障害の重大性を、サービスの重要度だけではなく、その時々のシステムの状態を考慮して評価し、サービスに及ぼす影響が大きい障害を優先して復旧することが望まれる。
【００１２】
また、利用中のリソースを、障害が発生したリソースの代替として利用する場合、利用中のリソースの中から、最もサービスに及ぼす影響が小さなリソースを、障害が発生したリソースの代替として利用することが望ましい。利用中のリソースの重要性は、その時々のシステムの状態に応じて変化するため、利用中のリソースの重要性の評価においても、該リソースを利用するサービスの重要度だけではなく、その時々のシステムの状態を考慮することが望ましい。
【００１３】
本発明は前記の課題を鑑みてなされたものであり、サービスの重要度だけでなく、システムの状態を考慮して、利用中のリソースが、サービスに及ぼす影響を定量的に出力する手段を提供することを目的とする。
【課題を解決するための手段】
【００１４】
前記課題を解決するために、本発明に係る情報処理システムの運用管理装置は、１以上のサービスを提供する１以上の計算機からなる情報処理システムにおいて、この計算機のハードウェアまたはソフトウェアからなるリソースの前記サービスにおける重要性を示す、リソースの優先度を算出する運用管理装置であって、各リソースの機能、その稼動状態、各サービスが利用するリソースおよび前記サービスにおけるリソース間の関係を定義したシステム構成情報と、前記サービスごとに設定された所定の重要度とを少なくとも保持する記憶部と、前記システム構成情報より、前記重要度の算出対象となるリソースを利用するサービスを特定し、前記システム構成情報より、前記特定したサービスにおいて、前記リソースと同一の機能を有する同等リソースを特定し、前記同等リソースの状態およびその数に基づいて、前記リソースが前記サービスに及ぼす影響度を算出し、前記サービスの重要度および前記算出した影響度に基づいて、前記リソースの優先度を算出する優先度計算部とを有することを特徴とする。
【発明の効果】
【００１５】
本発明によると、サービスの重要度だけでなく、システムの状態を考慮して、利用中のリソースが、サービスに及ぼす影響を定量的に計算することができる。
【発明を実施するための最良の形態】
【００１６】
以下、添付した図面を参照しつつ、本発明の好適な実施の形態について説明する。
【００１７】
(第１実施形態)
図１は、本発明の第１実施形態に係る運用管理装置（情報処理システムの運用管理装置）が適用された情報処理システムの全体構成を示す図面である。
図１に示した情報処理システムは、運用管理装置１０００と、第１のネットワーク１１００と、クライアント１２００と、第２のネットワーク１３００と、ロードバランサＡ１４００と、ロードバランサＢ１４０１と、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）と、ＤＢサーバＡ〜Ｅ（１６００〜１６０４）とを構成要素として含んで構成される。
【００１８】
運用管理装置１０００と、ロードバランサＡ１４００と、ロードバランサＢ１４０１と、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）と、ＤＢサーバＡ〜Ｅ（１６００〜１６０４）とは、第１のネットワーク１１００を介して通信可能に接続される。
また、情報処理システムは、第２のネットワーク１３００を介してクライアント１２００と通信可能に接続され、クライアント１２００に対して業務サービス（以下、業務とよぶ）を提供する。なお、本実施形態では説明のために、請求項のサービスに対応する言葉として「業務」を用いるが、請求項のサービスとは情報処理システムの内部的なバッチ処理などを広く含む概念である。
【００１９】
以下、図１に示した情報処理システムの各構成要素について説明する。
運用管理装置１０００は、情報処理システムを管理するためのコンピュータである。運用管理装置１０００は、情報処理システムで発生する障害と、この障害が発生した場合に対処として行なう処理の組み合わせとを、ポリシとして管理し、情報処理システムで障害が発生すると、管理されたポリシに基づいて障害の復旧処理を行なう。詳しくは後述する。
【００２０】
第１のネットワーク１１００は、運用管理装置１０００と、ロードバランサＡ１４００と、ロードバランサＢ１４０１と、ＷｅｂＡＰサーバＡ〜Ｅ（１５００〜１５０４）と、ＤＢサーバＡ〜Ｅ（１６００〜１６０４）とを相互に通信可能に接続する通信網である。この第１のネットワーク１１００は、例えば企業内におけるＬＡＮ（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」で特定されるプログラムは、リソース種別が「ＷｅｂＡＰサーバ」であるリソースの業務への割り当てを解除するための処理が記述されたコマンドやスクリプトなどである。このプログラムには、例えば、ロードバランサＡ１４００の設定情報において、クライアント１２００からの処理要求の振り分け先として指定されているＷｅｂＡＰサーバＡ１５００を削除し、ＷｅｂＡＰサーバＡ１５００のＷｅｂＡＰサーバ制御機能１５１０を利用して、業務プログラム１５１１を停止するための処理が記述される。
【０１８１】
図２５は、本実施形態に係るポリシ制御部１０２３の処理を説明するフローチャートの例である。図２５を参照して、ポリシ制御部１０２３の処理を説明する。
【０１８２】
まず、ポリシ制御部１０２３は、システム構成テーブル１０３５におけるすべての行のリソースグループ１０００５、業務番号１０００６および状態１０００７、つまりリソースの情報を記憶する（ステップ２５０００）。
そして、システム構成テーブル１０３５の各行に対して、ステップ２５０２０からステップ２５０３０を繰り返す（ステップ２５０１０）。
【０１８３】
まず、ポリシ制御部１０２３は、現在処理対象の行に対して、この行のＩＰアドレス１０００２を取得し、優先度計算部１０２４でリソースの優先度を算出する（ステップ２５０２０）。優先度計算部１０２４では、ステップ２５０２０で取得したＩＰアドレスに基づいて、リソースの優先度を算出する。なお、このリソースの優先度の計算手順については、図１４を用いて説明した第１実施形態の手順と同様である。
そして、システム構成テーブル１０３５（図２２参照）の現在処理対象の行に対して、この行の優先度１０００８に、ステップ１３０４０で算出したリソースの優先度を設定する（ステップ２５０３０）。システム構成テーブル１０３５のすべての行において、優先度１０００８を設定するまでステップ２５０２０からステップ２５０３０を繰り返す（ステップ２５０４０）。
【０１８４】
次に、ポリシ制御部１０２３は、ポリシ適用テーブル１０３３のすべての行において、優先度７００３を設定する（ステップ２５０５０）。なお、ポリシ適用テーブル１０３３に優先度を設定する手順については、図２６を参照して後記する。
そして、システム構成テーブル１０３５におけるすべての行のリソースグループ１０００５、業務番号１０００６および状態１０００７が、ステップ２５０００で記憶したリソースグループ、業務番号および状態と一致しているか否かを判定し（ステップ２５０６０）、一致していない場合（ステップ２５０６０でＮｏ）、ステップ２５０００へ戻りシステム構成テーブル１０３５の優先度１０００８を再度計算する。一致している場合（ステップ２５０６０でＹｅｓ）、ポリシ適用部１０２５で優先度の高いポリシのインスタンスを適用する（ステップ２５０７０）。
この、優先度の高いポリシのインスタンスを適用する手順については、図１７を用いて説明した第１実施形態の手順と同様である。
【０１８５】
ポリシ制御部１０２３の処理は、プログラムが起動するとループ状態になり、プログラム起動中は継続的にリソースおよびポリシのインスタンスの優先度の計算と、ポリシのインスタンスの適用を繰り返す。プログラムが終了すると、ポリシ制御部１０２３の処理は終了するか否かを判定し（ステップ２５０８０）、終了しない場合は（ステップ２５０８０で‘Ｎｏ’）、ステップ２５０００からの処理を繰り返す。
【０１８６】
図２６は、図２５で示したフローチャートのステップ２５０５０で呼び出される処理を説明するフローチャートの例である。図２６に示すフローチャートでは、ポリシ適用テーブル１０３３（図７参照）のすべての行の優先度７００３を設定する。
【０１８７】
そのために、ポリシ適用テーブル１０３３（図７参照）の各行に対して、ステップ２６０１０からステップ２６０３０を繰り返す（ステップ２６０００）。
まず、障害情報テーブル１０３１におけるイベント通し番号５０００が、現在処理対象の行のイベント通し番号７００１に一致する行を選択し、この行のＩＰアドレス５００４を取得する。これにより、障害が発生したリソースを特定する（ステップ２６０１０）。
【０１８８】
次に、システム構成テーブル１０３５におけるＩＰアドレス１０００２が、ステップ２６０１０で取得したＩＰアドレスと一致する行（リソース）を選択し、この行（リソース）の優先度１０００８を取得する（ステップ２６０２０）。
そして、ポリシ適用テーブル１０３３の現在処理対象の行に対して、この行の優先度７００３に、ステップ２６０２０で取得したリソースの優先度を設定する（ステップ２６０３０）。ポリシ適用テーブル１０３３のすべての行において、優先度７００３を設定するまでステップ２６０１０からステップ２６０３０を繰り返す（ステップ２６０４０）。
【０１８９】
次に、図２７は、リソース管理部１０２８の処理を説明するフローチャートの例である。図２７を参照して、リソース管理部１０２８の処理を説明する。前記のように、リソース管理部１０２８は、指定されたリソースの代替リソースを確保する処理部であり、障害が発生したリソースの代替リソースをリソース管理部１０２８に対して要求する処理が、ポリシのアクションに定義された場合において、このポリシをポリシ適用部１０２５が適用することにより呼び出される。
【０１９０】
まず、リソース管理部１０２８は、ポリシ適用部１０２５から障害が発生したリソースのＩＰアドレスを取得する（ステップ２７０００）。
そして、リソース管理テーブル１０３７（図２３参照）におけるＩＰアドレス２３００１が、ステップ２７０００で取得したＩＰアドレスと一致する行を選択し、この行の種別２３００２を取得する。これにより、障害が発生したリソースの種別を特定する（ステップ２７０１０）。
【０１９１】
次に、リソース管理部１０２８は、リソース管理テーブル１０３７における種別２３００２が、ステップ２７００１で取得した種別と一致する行をすべて選択することで、同一の種類のリソースを特定する（ステップ２７０２０）。
そして、ステップ２７０２０で選択した行のうち、割当状態２３００３が「未割当」である行が存在するか否かを確認し（ステップ２７０３０）、「未割当」の行が存在する場合（ステップ２７０３０でＹｅｓ）、ステップ２７１２０へ移る。一方、「未割当」の行が存在しない場合（ステップ２７０３０でＮｏ）、ステップ２７０４０へ移る。
【０１９２】
次に、リソース管理部１０２８は、システム構成テーブル１０３５（図２２参照）におけるＩＰアドレス１０００２が、ステップ２７０００で取得したＩＰアドレスと一致する行を選択し、この行の優先度１０００８を取得する。これにより、障害が発生したリソースの優先度を取得する（ステップ２７０４０）。
そして、システム構成テーブル１０３５におけるＩＰアドレス１０００２が、主記憶装置１０２０に記憶されておらず、かつＩＰアドレス１０００２がステップ２７０２０で選択した行のいずれかの行のＩＰアドレス２３００１と一致し、かつ状態１０００７が「障害」ではなく、優先度１０００８がステップ２７０４０で取得した優先度よりも低い行のうち、優先度１０００８が最も低い行を選択し、この行のＩＰアドレス１０００２とリソース種別１０００３と業務番号１０００６を取得する（ステップ２７０５０）。
ステップ２７０５０において、リソース管理部１０２８は、ＩＰアドレス１０００２を取得した後、取得したＩＰアドレスを主記憶装置１０２０に記憶する。主記憶装置１０２０に記憶されたＩＰアドレスは、本処理の終了時にすべて削除する。さらに、ステップ２７０５０において取得した業務番号１０００６は、主記憶装置１０２０に記憶する。
【０１９３】
次に、リソース管理部１０２８は、主記憶装置１０２０に記憶されたすべての業務番号について、ステップ２７０６０ないしステップ２７１００の処理を繰り返す（ステップ２７０６０）。そのため、記憶された業務番号のいずれかを取得し、取得した後、この業務番号を主記憶装置１０２０から削除する。
そして、再割当定義テーブル１０３８（図２４参照）における業務番号２４０００が、ステップ２７０６０から取得した業務番号と一致し、かつリソース種別２４００１が、ステップ２７０５０で取得したリソース種別と一致する行を選択する。これにより、ステップ２７０５０で特定したリソースの再割当定義を特定する（ステップ２７０７０）。
【０１９４】
次に、リソース管理部１０２８は、ステップ２７０７０で選択した行の再割当可否２４００３が「可」であるか確認する（ステップ２７０８０）。「可」でない場合（ステップ２７０８０でＮｏ）、ステップ２７０５０へ戻る。「可」である場合（ステップ２７０８０でＹｅｓ）、システム構成テーブル１０３５におけるリソースグループ１０００５が、ステップ２７０５０で選択した行のリソースグループ１０００５と一致し、かつ業務番号１０００６が、ステップ２７０６０で選択した業務番号を含み、かつ状態１０００７が「障害」ではない行の総数を算出し、算出した値が、再割当定義テーブル１０３８における最小構成２４００２の値より大きいか否かを確認する。これにより、リソースの組み合わせが最小構成を満たすか否かを判定する（ステップ２７０９０）。
【０１９５】
ステップ２７０９０において、最小構成２４００２の値以下である場合（ステップ２７０９０でＮｏ）、ステップ２７０５０へ戻る。最小構成２４００２の値より大きい場合（ステップ２７０９０でＹｅｓ）、ステップ２７０７０で選択した行の再割当処理２４００４を主記憶装置１０２０に記憶し、ステップ２７１１０へ移る。そして、主記憶装置１０２０に記憶されたすべての業務番号について、ステップ２７０６０からステップ２７０９０の処理を繰り返す（ステップ２７１００）。
【０１９６】
次に、リソース管理部１０２８は、主記憶装置１０２０に記憶された再割当処理２４００４により特定されるコマンドやスクリプト、または再割当スクリプト１０３９を実行することにより（ステップ２７１１０）、ステップ２７０５０で取得したＩＰアドレスで特定されるリソースの業務への割り当てを解除する。そして、主記憶装置１０２０に格納された再割当処理２４００４を削除する。ステップ２７０５０で取得した業務番号が複数である場合、主記憶装置１０２０に記憶された再割当処理２４００４より特定されるコマンドやスクリプト、または再割当スクリプト１０３９をすべて実行する。
【０１９７】
ステップ２７１１０において、再割当処理２４００４により特定されるコマンドやスクリプト、または再割当スクリプト１０３９が実行されると、リソース管理部１０２８は、このリソースの割り当て解除を通知される。リソース管理部１０２８は、リソース管理テーブル１０３７（図２３参照）におけるＩＰアドレス２３００１が、再割当処理２４００４により特定されるコマンドやスクリプト、または再割当スクリプト１０３９から通知されたＩＰアドレスと一致する行を選択し、この行のリソース名２３０００を未設定にし、割当状態２３００３を「未割当」に設定する。さらに、リソース管理部１０２８は、このリソースの割り当て解除を構成管理部１０２６へ通知する。構成管理部１０２６は、システム構成テーブル１０３５におけるＩＰアドレス１０００２が、通知されたＩＰアドレスと一致する行を削除し、この行のリソース番号を、システム構成テーブル１０３５におけるすべての接続リソース１０００４から削除する。
【０１９８】
次に、リソース管理部１０２８は、リソース管理テーブル１０３７（図２３参照）における種別２３００２が、ステップ２７０１０で取得したリソース種別と一致し、かつ割当状態２３００３が「未割当」である行の割当状態２３００３を「割当済」に設定し、この行のＩＰアドレス２３００１を、ポリシ適用部１０２５に返す（ステップ２７１２０）。そして、ポリシ適用部１０２５は、ステップ２７１２０で取得したＩＰアドレスにより特定されるリソースを利用して、ポリシに定義されたアクションの実行を継続する。
【０１９９】
本実施の形態は、単一の障害が発生した場合に、優先度の低いリソースの業務への割り当てを解除し、この障害の復旧処理に利用するものであるが、単一の障害が発生した場合の本発明の適用例として、ポリシのインスタンスの優先度にしきい値を設けることによって、このしきい値を超過した場合のみポリシのインスタンスを適用することにより、優先度が低い、すなわち障害が業務に及ぼす影響が小さい場合は、通常業務を優先させることも可能である。
【０２００】
以上、説明した本実施形態の運用管理装置によると、優先度の高いリソースに障害が発生した場合に、優先度の低いリソースを代替として利用することができるので、余剰リソースが存在しない場合であっても、サービスに及ぼす影響の大きい障害を遅延なく復旧でき、リソースを有効活用できる。
【図面の簡単な説明】
【０２０１】
【図１】第１実施形態に係る運用管理装置が適用された情報処理システムの全体構成を示す図面である。
【図２】運用管理装置の構成を示す図面である。
【図３】運用管理装置の動作の概要を説明する説明図である。
【図４】障害監視部が情報処理システムから受信するイベントに含まれる情報を表すテーブルである。
【図５】障害情報テーブルに含まれる情報を表すテーブルである。
【図６】ポリシ定義テーブルに含まれる情報を表すテーブルである。
【図７】ポリシ適用テーブルに含まれる情報を表すテーブルである。
【図８】情報処理システムの業務実行時における論理的な接続関係の例を説明する図面である。
【図９】業務定義テーブルに含まれる情報を表すテーブルである。
【図１０】システム構成テーブルに含まれる情報を表すテーブルである。
【図１１】障害監視部の処理を説明するフローチャートである。
【図１２】ポリシ管理部の処理を説明するフローチャートである。
【図１３】ポリシ制御部の処理を説明するフローチャートである。
【図１４】優先度計算部の処理を説明するフローチャートである。
【図１５】優先度計算部における処理を説明するフローチャートである。
【図１６】優先度計算部における処理を説明するフローチャートである。
【図１７】ポリシ適用部における処理を説明するフローチャートである。
【図１８】ポリシインスタンス一覧画面を示す図面である
【図１９】業務システム画面を示す図面である。
【図２０】第２実施形態に係る運用管理装置の構成を示す図である。
【図２１】運用管理装置の動作の概要を説明する説明図である。
【図２２】システム構成テーブルに含まれる情報を表すテーブルである。
【図２３】リソース管理テーブルに含まれる情報を表すテーブルである。
【図２４】再割当定義テーブルに含まれる情報を表すテーブルである。
【図２５】ポリシ制御部の処理を説明するフローチャートである。
【図２６】ステップ２５０５０で呼び出される処理を説明するフローチャートである。
【図２７】リソース管理部の処理を説明するフローチャートである。
【符号の説明】
【０２０２】
１０００  運用管理装置
１０２１  障害監視部
１０２２  ポリシ管理部
１０２３  ポリシ制御部
１０２４  優先度計算部
１０２５  ポリシ適用部
１０２６  構成管理部
１０２７  表示処理部
１０２８  リソース管理部
【図１】
2008217285.tif 000003
【図２】
2008217285.tif 000004
【図３】
2008217285.tif 000005
【図４】
2008217285.tif 000006
【図５】
2008217285.tif 000007
【図６】
2008217285.tif 000008
【図７】
2008217285.tif 000009
【図８】
2008217285.tif 000010
【図９】
2008217285.tif 000011
【図１０】
2008217285.tif 000012
【図１１】
2008217285.tif 000013
【図１２】
2008217285.tif 000014
【図１３】
2008217285.tif 000015
【図１４】
2008217285.tif 000016
【図１５】
2008217285.tif 000017
【図１６】
2008217285.tif 000018
【図１７】
2008217285.tif 000019
【図１８】
2008217285.tif 000020
【図１９】
2008217285.tif 000021
【図２０】
2008217285.tif 000022
【図２１】
2008217285.tif 000023
【図２２】
2008217285.tif 000024
【図２３】
2008217285.tif 000025
【図２４】
2008217285.tif 000026
【図２５】
2008217285.tif 000027
【図２６】
2008217285.tif 000028
【図２７】
2008217285.tif 000029