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

Abstract

【課題】情報処理システムに障害が発生しにくい，特に業務運用に与える影響が大きい障害が発生しにくいシステム運用管理が必要とされる。
【解決手段】運用管理装置は，構成を管理する対象である情報処理システムと接続する。運用管理装置は，稼動中の情報処理システムから，情報処理システムの構成情報を取得し，取得した構成情報から，情報処理システムを構成するリソースに障害が発生した場合に，情報処理システムの業務遂行に与える影響を示す影響度を各リソースについて算出し，算出した影響度が予め定めた影響度の上限値を超えているリソースがある場合に，リソースの影響度が上限値を下回る情報処理システムの構成案を作成する。作成する情報処理システムの構成案は，リソースの影響度が上限値を下回る情報処理システムの分散化構成と多重化構成の構成変更案である。
【選択図】図２

Description

本発明は，情報処理システムの障害予防に関し，とくに情報処理システムの構成情報を基に，発生する可能性のある障害を事前に予防するための技術に関する。

情報処理システムの大規模化に伴って，情報処理システムにおける業務プログラム(アプリケーションプログラム)の実行による業務やサービスの運用と，情報処理システムのリソースの効率的な運用とが分けられている。前者のための業務運用管理は，情報処理システムのユーザからの処理要求やサービス要求に，所定のパフォーマンス（たとえば，応答時間）をもって応えられるように，運用スケジュールや負荷に応じて，業務プログラムを実行するための計算機，ストレージ装置，ネットワークインタフェイスなどのリソースの選択，業務プログラムの起動・停止などを制御する。後者のためのシステム運用管理は，情報処理システムのリソースの構成を管理し，稼動状況の監視，過負荷や故障などに伴う障害発生の監視，障害が発生した場合にその影響の範囲や度合いの抑制などを制御する。システム運用管理は，情報処理システムのコストパフォーマンスや運用計画などに伴うリソースの性能や数の制約の下に実現されなければならない。

情報処理システムに障害が発生した場合の制御に関連する技術が特許文献１に記載されている。特許文献１には，システムの状態を考慮して，リソースがサービスに及ぼす影響度を算出し，サービスの重要度および算出した影響度に基づいて，リソースの優先度を算出することがが示されている。これにより，重要度の高いサービスが利用しているリソースに障害が発生した場合，重要度の低いサービスが利用しているリソースを重要度の高いサービスに割り当てることが可能になる。

特開２００８−２１７２８５号公報

昨今では計算機やストレージ装置などの仮想化技術の進展に伴い，業務運用管理もシステム運用管理も，制御の幅（管理の対象，対象を制御するための構成や手順の選択肢，など）が拡大している。また，業務運用管理とシステム運用管理とが分けられて運用される情報処理システムにおいては，そのための管理者も分けられる。ここでは，業務運用管理の管理者を業務管理者，システム運用管理の管理者をシステム管理者と呼ぶ。

このような状況の下では，業務管理者による情報処理システムの業務運用管理の結果が，情報処理システムに障害を発生させ易い，障害が発生した場合にその影響が大きいシステム状態を招く場合が生じる。特許文献１は，障害が発生した場合に対処する技術を開示しているが，障害が発生しにくい，特に業務運用に与える影響が大きい障害が発生しにくいシステム運用管理が望まれる。

開示される運用管理装置は，構成を管理する対象である情報処理システムと接続する。また，管理クライアントと接続する。運用管理装置は，稼動中の情報処理システムから，情報処理システムの構成情報を取得する構成情報取得部，取得した構成情報から，情報処理システムを構成するリソースに障害が発生した場合に，情報処理システムの業務遂行に与える影響を示す影響度を各リソースについて算出する影響度計算部，及び，算出した影響度が予め定めた影響度の上限値を超えているリソースがある場合に，リソースの影響度が上限値を下回る情報処理システムの構成案を作成する構成生成部を有する。

開示される運用管理装置の望ましい他の態様は，情報処理システムの構成案は，リソースの影響度が上限値を下回る情報処理システムの分散化構成と多重化構成の構成変更案である。

開示される運用管理装置の望ましいさらに他の態様は，影響度計算部は，情報処理システムを構成するリソースに障害が発生した場合に，そのリソースが影響を与える他のリソース影響度とそのリソースの重要度の和をそのリソースの影響度として算出する。

開示される運用管理装置の望ましいさらに他の態様は，影響度計算部が影響度を算出した各リソースの中で，多重化構成されているリソースに関して，算出した影響度を修正する多重度計算部をさらに有する。

開示される運用管理装置の望ましいさらに他の態様は，管理クライアントから入力される予め定めた影響度の上限値を設定するアラートポリシー設定部，各リソースについて算出した影響度が予め定めた影響度の上限値を超えているか否かを判定するアラート検出部，および，算出した影響度が予め定めた影響度の上限値を超えている場合にアラートを管理クライアントに出力するアラート出力部をさらに有する。
その他本願が開示する課題やその解決方法については，発明の実施形態の欄及び図面により明らかにされる。

本発明によれば，情報処理システムに障害が発生しにくい，特に業務運用に与える影響が大きい障害が発生しにくいシステム運用管理が可能になる。

実施形態のシステム構成例である。 実施形態のシステムの各部，各テーブル構成を示す図である。 構成制御部の処理フローである。 構成情報テーブルの一例である。 構成情報テーブルの一例である。 構成情報テーブルの一例である。 リソース関連情報テーブルの一例である。 構成確認画面の一例である。 重要度定義テーブルの一例である。 影響度情報テーブルの一例である。 依存関係定義テーブルの一例である。 影響度計算部の処理フローである。 影響度計算部の処理フローである。 影響度確認画面の一例である。 多重度定義テーブルの一例である。 アラートポリシーテーブルの一例である。 アラートの判定および発行の処理フローである。 推奨構成生成部の処理フローである。 分散化構成生成処理のフローチャートである。 割り当て可能なリソース検索処理のフローチャートである。 多重度構成生成処理のフローチャートである。 分散化構成テーブルの一例である。 多重化構成テーブルの一例である。 推奨構成表示画面の一例である。

図１に，実施形態のシステム構成例を示す。本実施形態のシステムは，通信ネットワークを介して接続する，一つ以上のサーバ装置２及び一つ以上のスイッチ(ネットワークスイッチ)４を含む管理対象装置１と，構成管理サーバ５及び管理クライアント６を含む構成管理システムを備え，構成管理システムが，業務管理者により業務運用管理されている情報処理システムとしての管理対象装置１の構成を管理・制御する。

構成管理サーバ５(運用管理装置)は，構成を管理する対象である管理対象装置１と接続する。構成管理サーバ５は，稼動中の管理対象装置１から，管理対象装置１の構成情報を取得し，取得した構成情報から，管理対象装置１を構成するリソースに障害が発生した場合に，管理対象装置１の業務遂行に与える影響を示す影響度を各リソースについて算出し，算出した影響度が予め定めた影響度の上限値を超えているリソースがある場合に，リソースの影響度が上限値を下回る管理対象装置１の構成案を作成する。

作成する管理対象装置１の構成案は，リソースの影響度が上限値を下回る管理対象装置１の分散化構成と多重化構成の構成変更案である。構成管理サーバ５は，管理対象装置１を構成するリソースに障害が発生した場合に，そのリソースが影響を与える他のリソース影響度とそのリソースの重要度の和をそのリソースの影響度として算出する。構成管理サーバ５は，影響度を算出した各リソースの中で，多重化構成されているリソースに関して，算出した影響度を修正する。また構成管理サーバ５は，管理クライアント６から入力される予め定めた影響度の上限値を設定し，各リソースについて算出した影響度が予め定めた影響度の上限値を超えているか否かを判定し，算出した影響度が予め定めた影響度の上限値を超えている場合にアラートを管理クライアントに出力する。

図２に，管理対象装置１と，構成管理サーバ５及び管理クライアント６を含む構成管理システムの，本実施形態の説明に必要な各部及び各テーブルを示す。管理対象装置１のメモリに格納される構成情報提供部１６は，そのCPUによって実行される。また，構成管理サーバ５のメモリに格納される各部は，そのCPUによって実行される。

管理対象装置１の構成情報提供部１６は，構成管理サーバ５からの要求に応じて，管理対象装置１の構成情報を送信する。構成管理サーバ５は，構成情報制御部３５によって各部の実行を制御することによって機能する。補助記憶装置に格納される各情報テーブルは，各部の実行に用いられる。構成情報制御部３５を初めとする各部および各情報テーブルに関して，以下に説明する。

図３に，構成制御部３５の処理フローを示す。この処理フローを用いて，構成管理システムの動作概要を説明し，各部の動作の詳細は後述する。構成制御部３５が各処理部を実行させ，管理対象装置１の構成を管理・制御する。構成情報取得部１７が管理対象装置１の構成情報を収集する（ステップ7）。収集した構成情報を基に，重要度計算部１８がリソースの重要度を算出し（ステップ８），影響度計算部１９がリソースの影響度を算出する。（ステップ９）。次に多重度計算部２０がリソースの多重度を算出して，算出した多重度に基づいて影響度を修正する（ステップ１０）。その後，アラートポリシー検出部２１が，求めた影響度がアラートポリシーに合致するか判定し（ステップ１１，ステップ１２），アラートポリシーに合致しない場合は，処理を終了する。なお，アラートポリシーは，予めアラートポリシー設定部２４の実行に伴う，管理クライアント６を介したシステム管理者からの入力により，アラートポリシーテーブル３４に設定されている。

アラートポリシーと合致している場合，アラート出力部２３がアラートを発行する（ステップ１３）。次に，推奨構成生成部２２が推奨する構成変更案を作成し（ステップ１４），推奨構成表示部２５が管理クライアント５に作成した構成変更案を表示する（ステップ１５）。以下，構成制御部３５のステップ７〜ステップ１４の各処理について説明する。

＜管理対象装置１の構成情報収集（ステップ７）＞
構成管理サーバ５の構成情報取得部１７が，管理対象装置１の構成情報提供部１６に構成情報の送信を要求し，管理対象装置１の構成情報提供部１６が管理対象装置１の構成情報を返信する。管理対象装置１の構成情報は，仮想化されたものも含めて管理対象装置１のリソースの名称や識別子に対応付けられて，その属性や他のリソースとの関係などのシステム運用管理に基づく構成情報と，業務プログラム（アプリケーション）がどのリソースを使用しているかなどの業務運用管理に基づく構成情報とを含む。システム運用管理の観点からは，アプリケーションなどもソフトウエアリソースとして扱えるので，以下では，ハードウェア，ソフトウェアにとらわれずにリソースと呼ぶ。

管理対象装置１の構成情報は，業務管理者による稼動中の情報処理システム（管理対象装置１）の業務運用管理の結果によって変化する。

構成情報収集部１７は，受信した構成情報を，構成情報テーブル２６に格納する。また，構成情報収集部１７は，構成情報に含まれるリソース間の関連情報をリソース関連情報テーブル２７に格納し，管理対象装置１のリソース一覧（各リソースについてリソース識別子およびリソース種別）を影響度情報テーブル２８に格納する。影響度情報テーブル２８については後述する。

構成情報テーブル２６は，図４〜図６に示すように，リソース種別毎のテーブルで構成される。図４は，リソース種別１０１が“アプリケーション”の構成情報テーブル２６の例のアプリケーション構成情報テーブル１００であり，収集した構成情報に含まれるリソースを識別する識別子１０２，アプリケーション名１０３やインストールパス１０４などの属性値を格納する。図５はホスト構成情報テーブル１０５の例であり，属性値としてホスト名，IPアドレスなどを格納する。図６はプロセッサ構成情報テーブル１０６の例であり，属性値としてプロセッサの動作周波数やコア数などを格納する。例示を省略するが，リソース種別には，さらに，プロセッサやメモリなどのホストを構成するリソース，スイッチなどがある。

図７は，リソース関連情報テーブル２７の例であり，リソース間の関連情報と関連の種別を格納する。リソース間の関連には関連元（リソース識別子およびリソース種別）１０８と関連先（リソース識別子およびリソース種別）１０９がある。関連種別１１０が“所有”であるたとえば“ホスト-A”と“アプリケーション-A”の関連は，関連元の“ホスト-A”が“アプリケーション-A”を所有していることを表す。関連種別１１０が“使用”は，関連元１０８が関連先１０９を使用してることを表す。換言すると，“所有”は包含関係を表し，“使用”は接続関係を表す。

構成情報収集部１７は，リソース関連情報テーブル２７に格納した関連情報を基にして，図８に示す構成確認画面１１１を，管理クライアント６のディスプレイに表示する。図８に示す構成確認画面１１１の例は，図７に示すリソース関連情報テーブル２７に対応して，たとえば“ホスト-A”が“アプリケーション-A” 所有していることを示している。

＜リソースの重要度算出（ステップ８）＞
収集した構成情報に含まれるリソースにはリソース種別ごとの属性がある。図４のアプリケーション構成情報テーブル１００では，アプリケーション名１０３やインストールパス１０４などが属性である。重要度計算部１８は，図９に示す重要度定義テーブル３１に定義されたリソースの種別２０１とその属性に関する条件２０２にマッチした重要度２０３を参照し，リソースごとの重要度を算出する。リソースの種別２０１と条件にマッチしないリソースの重要度は最小値の1とする。求めた重要度を影響度情報テーブル２８の重要度カラムに格納する。

重要度定義テーブル３１のリソース種別２０１，条件２０２，重要度２０３の定義内容は，管理対象装置１の構成変更に応じて，管理クライアント６を通じて，システム管理者が入力，更新する。なお，リソースの種別２０１とその属性に関する条件２０２にマッチした重要度２０３の値は，業務運用管理の観点からのリソースの重要性に応じて定義され，アプリケーションなどの業務運用管理に係るリソースの重要度などは，予め業務管理者から得ておく。

図１０は影響度情報テーブル２８の例である。影響度情報テーブル２８には，構成情報収集部１７によってリソース識別子３０１，リソース種別３０２が既に格納されている。リソース識別子“アプリケーション-A”は重要度定義テーブル３１にヒットし，その重要度２０３は５であるので，影響度情報テーブル２８のリソース識別子３０１“アプリケーション-A”の重要度３０３に５を格納する。同様に，影響度情報テーブル２８の全レコード（管理対象装置１の全リソース）に対して重要度を求め格納する。

＜リソースの影響度算出（ステップ９）＞
リソース毎の影響度を次式により求める。
リソースの影響度 = (影響を与える全リソースの影響度の和) + (リソースの重要度)
影響度は，あるリソースに障害が発生した場合の管理対象装置１(情報処理システム)の業務遂行に与える影響の度合いを示し，上式に示すように，あるリソースに障害が発生した場合に，そのリソースの障害が影響するリソースの影響度と，そのリソースの重要度の和で定義する。

影響度計算部１９は，上式の影響度を求める対象のリソースが(影響を与える全リソースの影響度の和)を求めるために，図１１に示す依存関係定義テーブル３０を用いる。依存関係定義テーブル３０は，影響を与える元である影響元リソース種別４０１，影響を受ける影響先リソース種別４０２，及び影響元の関連種別４０３を格納する。影響元の関連種別４０３は，リソース関連情報テーブル２７に関連元のリソースと関連先のリソースのいずれとして格納されるかを示す。

影響度計算部１９は，上式により各リソースの影響度を求め，影響度情報テーブル２８の影響度３０４に格納する。影響度計算部１９の処理フローを図１２,図１３に示す。

影響度情報テーブル２８のリソース識別子３０１に対応するリソース種別３０２が，依存関係定義テーブル３０の影響元リソース種別４０１にあるかを検索する(ステップ５０１)。処理フローは，影響度情報テーブル２８のリソース識別子３０１の一つに関する処理を示すが，影響度情報テーブル２８のリソース識別子３０１のすべてに関して，影響度３０４を格納し終えるまで繰り返す。

検索の結果，リソース種別がある場合はステップ５０３を依存関係毎に繰返し，ない場合はステップ５０５に分岐する(ステップ５０２)。リソース種別がない場合，影響度情報テーブル２８の該当リソースの重要度３０３を影響度３０４とする(ステップ５０５)。たとえば，影響度情報テーブル２８のリソース識別子３０１が“ホスト-A”のリソース種別３０２である“ホスト”を依存関係定義テーブル３０で検索すると，リソース種別“ホスト”は依存関係定義テーブル３０の影響元リソース種別４０１にあるので，ステップ５０３を実行して依存関係毎の影響度を算出する。

依存関係毎の影響度の算出処理を図１３を用いて説明する。依存関係定義テーブル３０の影響元リソース種別４０１の関連種別４０３が関連元であるかを判定し（ステップ６０１），関連元である場合は，該当するリソースが関連元であり，依存関係定義テーブル３０の影響先リソース種別４０２に等しい関連先リソース種別の関連をリソース関連情報テーブル２７から検索する（ステップ６０２）。関連元でない場合は，該当するリソースが関連先であり，依存関係定義テーブル３０の影響元リソース種別４０１に等しい関連元リソース種別をリソース関連情報テーブル２７から検索する（ステップ６０５）。たとえば，影響元リソース種別４０１が“ホスト”の場合には，依存関係定義テーブル３０の関連種別に“関連元”と定義してあるので，“ホスト-A”が関連元であり，関連先が依存関係定義テーブル３０の影響先リソース種別４０２のアプリケーションである関連をリソース関連情報テーブル２７から検索すると，関連先リソースとして，“アプリケーション-A”と“アプリケーション-B”と“アプリケーション-C”が見つかる。これが，“ホスト-A”が影響を与えるリソースになる。これを影響先リソース３０５として影響度情報テーブル２８に格納する。

次に，関連先リソースとして見つけたリソース毎に，それぞれの影響度を求める（ステップ６０３）。たとえば，“アプリケーション-A”のリソース種別である“アプリケーション”は依存関係定義テーブル３０の影響元リソース種別４０１にないので，“アプリケーション-A”が影響を与えるリソースは存在しない。これにより，“アプリケーション-A”の(影響を与える全リソースの影響度の和)は0と求まる。また，“アプリケーション-A”の重要度は影響度テーブル２８から5と求まる。これにより，“アプリケーション-A”の影響度は0 + 5 = 5と求まり，これを影響度情報テーブル２８の“アプリケーション-A”の行の影響度３０４に格納する。同様に，“アプリケーション-B”と“アプリケーション-C”の影響度はどちらも1と求まる。

次に，該当リソースの全ての依存関係の影響度と該当リソースの重要度との和を該当リソースの影響度とする（ステップ５０４）。該当リソースが“ホスト-A”の場合，“ホスト-A”の(影響を与える全リソースの影響度の和)は(“アプリケーション-A”の影響度) + (“アプリケーション-B”の影響度) + (”アプリケーション-C ”の影響度) = 5 + 1 + 1 = 7 と求まる。また，“ホスト-A”の重要度は影響度情報テーブル２８において1であるので，“ホスト-A”の影響度は7 + 1 = 8と求まる。これを影響度情報テーブル２８の“ホスト-A”の影響度３０４に格納する。

また，影響度計算部１９は，算出した影響度を表す，図１４に示す影響度確認画面１１２を，管理クライアント６のディスプレイに表示する。影響度確認画面１１２は，図８に示す構成情報確認画面１１１に，各リソースの影響度を重畳させた画面である。

＜リソースの多重度算出（ステップ１０）＞
管理対象装置１のリソースがクラスタ構成やハードウェアの冗長化構成などのように多重化されている場合，そのリソースに障害が発生した場合の管理対象装置１に与える影響は，多重化していないリソースよりも小さい。そこで，リソースの多重度計算部２０では，多重化されているリソースを検索し，影響度を修正する。

図１５は，多重度定義テーブル２９の例であり，多重化の対象のリソース種別７０１と多重化となる条件７０２が定義されている。リソースの多重度計算部２０では，収集したリソース毎に多重度定義テーブル２９を検索し，多重化しているリソースの組を発見する。発見したリソースの組を一つのリソースとして影響度情報テーブル２８で扱い，その影響度は多重度にあわせて修正する。２重化されているリソースの影響度は1/2のように，影響度を1/(多重度)に修正し，影響度情報テーブル２８の影響度３０４を更新する。

＜アラートポリシー判定および発行（ステップ１１〜１３）＞
アラート検出部２１がアラートポリシー３４を参照し，アラートを発行するか判定する。アラートを発行する場合は，アラート出力部２３がアラートを発行する。アラート出力部２３では，管理クライアント６のディスプレイにGUI表示，メール送信，SNMP（Simple Network Management Protocol）などの少なくとも一つにより，ユーザにアラートを通知する。

図１６は，アラートポリシーテーブル３４の例であり，影響度の上限値(閾値)８０１と上限値を超えたリソース数の閾値８０２と除外条件８０３として除外リソース種別が定義されている。除外条件８０３に該当せずに，影響度が上限値８０１を超え，その数（リソースの数）がリソース数の閾値８０２以上であるリソースを，アラート発行の対象とする。

図１７に，アラートの判定および発行の処理フローを示す。影響度がユーザが規定した閾値を超えた場合，そのリソースに関してアラートを発行しシステム管理者に通知する。アラート検出部２１では，各リソースに関して影響度計算部１９（多重度計算部２０による修正を含む）により影響度３０４が求められた影響度情報テーブル２８から，アラートポリシーテーブル３４の影響度の上限値８０１を超えたリソース数を検索し，検索したリソース数が，アラートポリシーテーブル３４の上限を超えたリソース数の閾値８０２を超えていた場合（ステップ９００），アラート出力部２３を通して，アラートをユーザに通知する（ステップ９０１）。なお，リソース数の閾値８０２を用いずに，影響度の上限値８０１を超えたリソースをアラート発行の対象のリソースとする簡易な判定でもよい。図１６に示す例では，リソース数の閾値８０２が１であるので，実質的に簡易な判定と同じになる。

図１０の影響度情報テーブル２８と図１６のアラートポリシーテーブル３４に示す例では，影響度上限値８０１の７を超えているリソース数が，除外条件８０３を満たすネットワークスイッチを除いて４つあり，リソース数閾値８０２の１も超えているので，アラートを発行する。

＜推奨する構成変更案作成（ステップ１４）＞
影響度が規定した閾値を超えた場合，アラートを発行すると共に，ユーザに対して推奨する構成変更案を提供する。推奨構成生成部２２が，推奨する構成変更案を作成し，推奨構成表示部２５が，作成した構成変更案を表示する。

図１８に，推奨構成生成部２２の処理フローを示す。推奨構成生成部２２は，分散化構成作成処理（ステップ１００２）と多重化構成作成処理（ステップ１００４）を実行し，管理対象装置１の新たな構成案として分散化構成と多重化構成の構成変更案を作成する。

以下，分散化構成作成処理（ステップ１００２）と多重化構成作成処理（ステップ１００４）について説明する。

＜分散化構成変更案作成（ステップ１００２）＞
分散化構成作成の処理フローを図19に示す。本処理では，分散化した推奨構成を分散化構成情報テーブル３２に格納する。

まず該当リソースの影響先リソース３０５の一覧を影響度情報テーブル２８から取得する（ステップ１１０５）。“ホスト-A”を例にすると，影響度情報テーブル２８より，“アプリケーション-A”と“アプリケーション-B”と“アプリケーション-C”を取得する。ここで，該当リソースとは，影響度が規定した閾値を超えているリソースであり，複数ある場合は，それら複数のリソースに関して図１９に示す処理を繰り返す。

次に，該当リソースに与える影響度が大きいリソースの順に，割り当て可能なリソースを検索する（ステップ１１０６）。“ホストA”に影響を与えるリソースを影響度順に並べると，“アプリケーション-A”，“アプリケーション-B” ，“アプリケーション-C”の順になる(影響度が同値の場合は順不同)。この場合，まず“アプリケーションA”を割り当てるリソースを検索する。

図２０に，ステップ１１０６の割り当て可能なリソース検索の処理フローを示す。リソースの一覧を取得する（ステップ１１０９）。リソースの一覧は，管理対象装置１のリソースの一覧であり，構成管理サーバ５に格納され管理されている。なお，リソースの一覧には，管理対象装置１を構成するリソースではあるが使用されていないリソースも含んでいる。リソースの一覧の中に追加リソースとしてのホストがない状態では，割り当て可能なリソースは“ホスト-A”しかなく，また，“ホスト-A”には関連が割り当っていない（再割り当てのため，構成変更収集部で収集した関連は考慮せずに，“ホスト-A”には関連を割り当てていない初期状態を想定する）ので，“アプリケーション-A”を“ホスト-A”に割り当てる。これにより，ホストAの影響度は“アプリケーションA”の影響度 + “ホストA”の重要度 = 5 + 1 = 6 となり，アラートの閾値を超えてしまうが，“ホストA”は未割り当てリソースのため，“アプリケーションA”を割り当てることとし，分散化構成テーブル１１００に格納する。図22は分散化構成情報テーブル３２の例であり，リソース識別子１１０１が“ホストA”のリソースにリソース識別子１１０３が“アプリケーション-A”を割り当てることを示している（ステップ１１０８）。

次に，“アプリケーション-B”を割り当てるリソースを検索する。割り当て対象のリソースは“ホスト-A”があるが，“ホスト-A”に割り当てた場合，“ホスト-A”の影響度は“アプリケーション-A”の影響度 + “アプリケーション-B”の影響度 + “ホスト-A”の重要度 = 5 + 1 + 1 = 7となり，アラートポリシーの影響度上限値を超えてしまう。

“ホスト-A”は未割り当てリソースでもない（すでに“アプリケーション-A”を割り当てている）ため，割り当てるリソースが見つからない（ステップ１１１０）。割り当てるリソースが見つからない場合，新規のリソースを追加する（ステップ１１０７）。図２２の例では，新しいリソース“追加ホスト”を追加し，“アプリケーション-B”を“追加ホスト”に割り当てる。同様に，“アプリケーション-C”は“追加ホスト”に割り当てることになる。以上のように “ホスト-A”に関して作成した分散化テーブル（分散化変更案情報の実現形式の一つ）を図２２に示す。また，分散化テーブル１１００には，作成した推奨構成の影響度１１０４を格納する。

以上の例は，新しいリソースとして“追加ホスト”がリソースの一覧にある場合，すなわち管理対象装置１を構成するリソース(ホスト)ではあるが使用されていないリソース(ホスト)がある場合であるが，新しいリソースがない場合がある。この場合は，分散化構成をとる必要があるが追加リソースがなく，分散化構成をとることができないことを，管理クライアント６を介してシステム管理者に通知するか，追加リソースがあるとして分散化構成案を作成し，リソースの追加を促すメッセージをシステム管理者に通知する。

＜多重化構成変更案作成（ステップ１００４）＞
多重化構成作成の処理フローを図２１に示す。本処理では，多重化の推奨構成を多重化構成情報テーブル３３に格納する。

まず現在の影響度と閾値から多重度を以下の計算式より算出する（ステップ１２０４）。
多重度 = リソースの影響度 / リソースの閾値 (但し，小数点以下切り上げ)
以下，リソースとして“ホスト-A”を取り上げて説明するが，影響度が規定した閾値を超えているリソースが複数ある場合は，それら複数のリソースに関して，以下に説明する処理を繰り返す。

図１０の影響度テーブル２８より “ホスト-A”の影響度は8であり，図１６のアラートポリシーテーブル３４より影響度上限値は７なので，多重度は[8 / 7 ]= 2と求まる（ステップ１２０４）。なお，[ ]は，小数点以下を切り上げた整数値を表す。これより，現在の“ホスト-A”に１つ“追加ホスト”を追加し（ステップ１２０５），ホスト数を2とする。次に，“追加ホスト”と“ホスト-A”に影響を与えているリソース(“アプリケーション-A”と“アプリケーション-B”と“アプリケーションC”)との間の関連を作成する（ステップ１２０６）。さらに，“ホスト-A”と“追加ホスト”の影響度は多重度2で多重化しているため，影響度を1/(多重度)とし，それぞれ8 / 2 = 4となる。また，作成した多重化構成のリソース識別子１２０１とリソース種別１２０２と算出した推奨構成での影響度１２０３は多重化テーブル１２００（多重化変更案情報の実現形式の一つ）に格納する。図23に多重化構成テーブルの例を示す。

なお，“追加ホスト”に関しては，分散化構成変更案作成の場合と同様に，追加ホストとしてのリソースがない場合，多重化構成をとる必要があるが追加リソースがなく，多重化構成をとることができないことを，管理クライアント６を介してシステム管理者に通知するか，追加リソースがあるとして多重化構成案を作成し，リソースの追加を促すメッセージをシステム管理者に通知する。。

＜推奨する構成変更案を表示（ステップ１５）＞
推奨構成表示部２５は，推奨する構成変更案を管理クライアント６に表示する。図24は推奨構成表示画面１３００の例である。また，推奨構成表示画面に必要な情報は分散化構成情報テーブル３２と多重化構成情報テーブル３３に保存されているため，推奨構成表示画面１３００は構成変更後でも表示可能である。

そこで，システムの運用管理者は，推奨構成に従い構成変更を実施したあと，影響度確認画面で，構成変更後の影響度を表示し，推奨構成画面１３００と比較することで同じ構成に変更ができたことを確認することができる。

本実施形態によれば，情報処理システムに障害が発生しにくい，特に業務運用に与える影響が大きい障害が発生しにくいシステム運用管理が可能になる。具体的には，障害が発生した場合に情報システムに重大な影響を及ぼす恐れがあるリソースを事前に検知し，検知内容に対応した構成変更案をシステム管理者に対して提案することが可能になる。また実際の構成変更後に構成変更案どおりに構成変更できたか検証することが可能になる。

１：管理対象装置，２：サーバ装置，４：スイッチ，５：構成管理サーバ，６：管理クライアント，１６：構成情報提供部，１７：構成情報取得部，１８：重要度計算部，１９：影響度計算部，２０：多重度計算部，２１：アラート検出部，２２：推奨構成生成部，２３：アラート出力部，２４：アラートポリシー設定部，２５：推奨構成表示部，２６：構成情報テーブル，２７：リソース関連情報テーブル，２８：影響度情報テーブル，２９：多重度定義テーブル，３０：依存関係定義テーブル，３１：重要度定義テーブル，３２：分散化構成情報テーブル，３３：多重化構成情報テーブル，３４：アラート ポリシー，３５：構成情報制御部。

Claims (10)

1. 構成を管理する対象である情報処理システムと接続する運用管理装置であって，管理クライアントと接続し，
   稼動中の前記情報処理システムから，前記情報処理システムの構成情報を取得する構成情報取得部，
   取得した前記構成情報から，前記情報処理システムを構成するリソースに障害が発生した場合に，前記情報処理システムの業務遂行に与える影響を示す影響度を各リソースについて算出する影響度計算部，及び，
   算出した前記影響度が予め定めた影響度の上限値を超えているリソースがある場合に，前記リソースの影響度が前記上限値を下回る前記情報処理システムの構成案を作成する構成生成部を有することを特徴とする運用管理装置。
2. 前記情報処理システムの構成案は，前記リソースの影響度が前記上限値を下回る前記情報処理システムの分散化構成と多重化構成の構成変更案であることを特徴とする請求項１記載の運用管理装置。
3. 前記影響度計算部は，前記情報処理システムを構成する前記リソースに障害が発生した場合に，前記リソースが影響を与える他のリソース影響度と前記リソースの重要度の和を前記リソースの影響度として算出することを特徴とする請求項２記載の運用管理装置。
4. 前記影響度計算部が前記影響度を算出した前記各リソースの中で，多重化構成されているリソースに関して，算出した前記影響度を修正する多重度計算部をさらに有することを特徴とする請求項２記載の運用管理装置。
5. 前記管理クライアントから入力される前記予め定めた影響度の上限値を設定するアラートポリシー設定部，前記各リソースについて算出した前記影響度が予め前記定めた影響度の上限値を超えているか否かを判定するアラート検出部，および，算出した前記影響度が予め前記定めた影響度の上限値を超えている場合にアラートを前記管理クライアントに出力するアラート出力部をさらに有することを特徴とする請求項２記載の運用管理装置。
6. 構成を管理する対象である情報処理システムと接続する運用管理装置による運用管理方法であって，前記運用管理装置は管理クライアントと接続し，前記運用管理装置は，
   稼動中の前記情報処理システムから，前記情報処理システムの構成情報を取得し，
   取得した前記構成情報から，前記情報処理システムを構成するリソースに障害が発生した場合に，前記情報処理システムの業務遂行に与える影響を示す影響度を各リソースについて算出し，
   算出した前記影響度が予め定めた影響度の上限値を超えているリソースがある場合に，前記リソースの影響度が前記上限値を下回る前記情報処理システムの構成案を作成することを特徴とする運用管理方法。
7. 前記情報処理システムの構成案は，前記リソースの影響度が前記上限値を下回る前記情報処理システムの分散化構成と多重化構成の構成変更案であることを特徴とする請求項６記載の運用管理方法。
8. 前記運用管理装置は，前記情報処理システムを構成する前記リソースに障害が発生した場合に，前記リソースが影響を与える他のリソース影響度と前記リソースの重要度の和を前記リソースの影響度として算出することを特徴とする請求項７記載の運用管理方法。
9. 前記運用管理装置は，前記影響度を算出した前記各リソースの中で，多重化構成されているリソースに関して，算出した前記影響度を修正することを特徴とする請求項７記載の運用管理方法。
10. 前記運用管理装置は，前記管理クライアントから入力される前記予め定めた影響度の上限値を設定し，前記各リソースについて算出した前記影響度が予め前記定めた影響度の上限値を超えているか否かを判定し，算出した前記影響度が予め前記定めた影響度の上限値を超えている場合にアラートを前記管理クライアントに出力するすることを特徴とする請求項７記載の運用管理方法。

Images