JP2006058938A - ポリシルール管理支援方法およびポリシルール管理支援装置 - Google Patents

Abstract

【課題】システムの構成変更あった場合に、当該構成変更により修正が必要なポリシルールの修正漏れを防止する。
【解決手段】ポリシ管理装置１は、処理部と、前記コンピュータシステムの構成要素毎に少なくとも１つのポリシルールが記憶されたポリシルールテーブル１５１とを有する。そして、処理部は、コンピュータシステムの構成要素毎に、構成変更通知を受け付ける受付ステップと、前記受付ステップにおいて受け付けた構成要素の構成変更により、影響を受ける少なくとも１つの構成要素を検出する検出ステップと、前記検出ステップにおいて検出された構成要素各々に対応するポリシルールを、前記ポリシルールテーブル１５１から特定し、当該特定したポリシルールの一覧を作成する作成ステップと、を行う。
【選択図】 図１

Description

本発明は、ポリシルールを管理する技術に関する。

特許文献１には、ネットワークの構成変更を検出して、構成変更により追加または交換された機器に不正アクセス検知ポリシを配布する侵入検知管理システムが記載されている。また、特許文献２には、マルチキャストルーティング情報を一元管理し、ネットワークの構成変更を検出して、ルーティング情報の変更通知をすべきネットワーク機器に当該構成変更を通知するマルチキャスト方法が記載されている。

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

ところで、ポリシルールが適用されたシステムにおいて、当該システムの構成が変更した場合、ポリシルールも変更しないと矛盾が発生してシステム障害の原因となる場合がある。ポリシルールとは、所定の事象が発生した場合に、当該事象毎に実施すべき操作（対処作業）を定めた規則である。

例えば、アプリケーションサーバ機と、データベースサーバ機とを用いて所定の業務を実行するシステムにおいて、アプリケーションサーバ機の処理がボトルネックであるとする。そして、所定の業務の応答時間が閾値を超えた場合、アプリケーションサーバ機を追加する旨のポリシルールが存在するものとする。このようなシステムにおいて、現行使用しているアプリケーションサーバ機が高性能なサーバ機にアップグレードされた場合、データベースサーバ機が今度はボトルネックとなる。そのため、上記ポリシルールを、変更後のシステム構成と整合するポリシルールに修正（変更）する必要がある。なお、引用文献１および引用文献２では、ポリシルールの修正については考慮されていない。

本発明は上記事情に鑑みてなされたものであり、本発明の目的は、システムの構成変更があった場合に、当該構成変更により修正が必要なポリシルールの修正漏れを防止することにある。

上記課題を解決するために、本発明では、コンピュータシステムの構成変更通知を受け付けて、当該構成変更により影響を受ける可能性のあるポリシルールをリストアップする。

例えば、情報処理装置が行う、コンピュータシステムにおけるポリシルールの管理を支援するポリシルール管理支援方法において、ポリシルールは、コンピュータシステムの運用管理操作である。そして、情報処理装置は、処理部と、コンピュータシステムの構成要素毎に少なくとも１つのポリシルールが記憶されたポリシルール記憶部とを有する。処理部は、コンピュータシステムの構成要素毎に、構成変更通知を受け付ける受付ステップと、 受付ステップにおいて受け付けた構成要素の構成変更により、影響を受ける少なくとも１つの構成要素を検出する検出ステップと、検出ステップにおいて検出された構成要素各々に対応するポリシルールを、ポリシルール記憶部から特定し、当該特定したポリシルールの一覧を作成する作成ステップと、を行う。

本発明では、システムの構成変更があった場合に、当該構成変更により影響を受ける可能性のあるポリシルールの一覧を作成することで、構成変更後のシステムと整合性のとれたポリシルールの管理を支援することができる。

以下、本発明の実施の形態について説明する。

図１は、本発明の一実施形態が適用されたシステムの全体構成図である。図示するように、本実施形態のシステムは、ポリシルールを管理するポリシ管理装置１と、システム構成を管理する構成管理装置２と、負荷分散装置３と、アプリケーションサーバ機（以下、「ＡＰサーバ機」）４と、データベースサーバ機（以下、「ＤＢサーバ機」）５と、を有する。そして、これらの装置１〜５は、インターネットなどのネットワーク６により接続されている。

ポリシ管理装置１は、図示するように、イベント受付部１１と、影響範囲検索部１２と、ポリシルール検索部１３と、出力部１４と、記憶部１５と、を有する。イベント受付部１１は、構成管理装置２から後述するイベントメッセージを受け付ける。影響範囲検索部１２は、イベント受付部１１が受け付けたイベントメッセージによって影響する範囲を検索する。ポリシルール検索部１３は、後述するポリシルールテーブル１５１から変更対象のポリシルールを検索する。出力部１４は、ポリシルール検索部が検索したポリシルールを出力装置に出力する。

記憶部１５には、ポリシルールテーブル１５１が記憶されている。ポリシルールとは、管理対象のシステムにおいて、所定の事象が発生した場合に、当該事象毎に自律的に実行すべき操作（処理）を定めた規則である。ポリシルールの具体的な例としては、ある所定の業務の応答時間（レスポンス）が所定の時間を超えた場合、当該業務を実行しているサーバ装置を１台追加するなどである。

構成管理装置２は、図示するように、構成管理部２１と、検索応答部２２と、記憶部２３と、を有する。構成管理部２１は、入力装置から入力された管理対象システムの構成変更情報を受け付けて、記憶部２３に記憶された各種テーブルを更新する。検索応答部２２は、ポリシ管理装置１から送信された検索要求を受け付けて、要求された管理オブジェクトを特定し、ポリシ管理装置１に通知する。なお、管理オブジェクトについては、図４において後述する。記憶部２３には、後述する、管理オブジェクトテーブル２３１と、依存関係テーブル２３２と、操作管理テーブル２３３と、が記憶されている。

負荷分散装置３は、並列に接続された装置各々の負荷を均等にするように処理（トランザクション）を分散して割り当てる。図示するように、負荷分散装置３は、運用管理エージェント３１と、分散処理部３２とを有する。運用管理エージェント３１は、構成管理装置２の指示を受け付けて、各種の操作を行う。分散処理部３２は、負荷分散装置３に接続された各装置の負荷を均等にするように処理を分散して割り当てる。

ＡＰサーバ機４は、業務処理を行う装置である。図示するように、ＡＰサーバ機４は、運用管理エージェント４１と、業務アプリケーション４２と、ミドルウェア４３とを有する。運用管理エージェント４１は、構成管理装置２の指示を受け付けて、各種の操作を行う。業務アプリケーション４２は、業務処理を行うアプリケーションソフトウェア（プログラム）である。ミドルウェア４３は、ＯＳ（Operating System）上で動作し、業務アプリケーション４２に対してＯＳよりも高度で具体的な機能を提供するソフトウェアである。

ＤＢサーバ機５は、ＡＰサーバ機４に各種のデータを提供する装置である。図示するように、ＤＢサーバ機５は、運用管理エージェント５１と、データベース５２と、ＤＢＭＳ（DataBase Management System）５３と、を有する。運用管理エージェント５１は、構成管理装置２の指示を受け付けて、各種の操作を行う。ＤＢＭＳ５３は、データベースを管理し、ＡＰサーバ機４からのデータアクセス要求に応えるソフトウェアである。なお、ＤＢＭＳ５３は、ミドルウェアの一種である。

以上説明した、ポリシ管理装置１、構成管理装置２、負荷分散装置３、ＡＰサーバ機４、および、ＤＢサーバ機５は、いずれも例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワーク接続するための通信制御装置９０６と、これらの各装置を接続するバス９０７と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、ポリシ管理装置１、構成管理装置２、負荷分散装置３、ＡＰサーバ機４、および、ＤＢサーバ機５の各機能は、ポリシ管理装置１用のプログラムの場合はポリシ管理装置１のＣＰＵ９０１が、構成管理装置２用のプログラムの場合は構成管理装置２のＣＰＵ９０１が、負荷分散装置３用のプログラムの場合は負荷分散装置３のＣＰＵ９０１が、ＡＰサーバ機４用のプログラムの場合はＡＰサーバ機４のＣＰＵ９０１が、そして、ＤＢサーバ機５用のプログラムの場合はＤＢサーバ機５のＣＰＵ９０１が、それぞれ実行することにより、実現される。なお、ポリシ管理装置１の記憶部１５には、ポリシ管理装置１のメモリ９０２または外部記憶装置９０３が用いられる。また、構成管理装置２の記憶部２３には、構成管理装置２のメモリ９０２または外部記憶装置９０３が用いられる。

次に、ポリシ管理装置１および構成管理装置２が管理している管理対象システム、および、当該管理対象システムの管理オブジェクト構成について説明する。

図３は、図１に示すシステムの中の管理対象システムの一例を示したものである。図示する管理対象システムは、Ｗｅｂ３階層構造のアプリケーション層とデータベース層に相当するシステムである。すなわち、本システムは、負荷分散装置３と、少なくとも１つのＡＰサーバ４と、ＤＢサーバ５と、を有する。負荷分散装置３は、並列に接続された各ＡＰサーバ間での負荷を均等にするように処理を分散して割り当てる。少なくとも１つのＡＰサーバ４各々は、ＤＢサーバ５に格納されているデータベースにアクセスし、業務処理を行う。ＤＢサーバ５は、複数のＡＰサーバ４各々の要求に基づいて、データベースに格納されているデータを検索または更新する。

図４は、構成管理装置２により管理される、図３に示す管理対象システムの構成情報の構造を図示している。本実施形態では、システムの構成情報は、データベース５２や、ＡＰサーバ機４など、少なくとも１つの管理オブジェクトと、管理オブジェクト間の依存関係（図４では、管理オブジェクト間を結ぶ線として示している）を用いた階層構造として保持されている。なお、図４は、本実施形態の説明のために設けたものであり、ここで説明する管理オブジェクトと、管理オブジェクト間の依存関係からなる構成情報は、本実施形態では、実際には後述する管理オブジェクトテーブル２３１と、依存関係テーブル２３２と、操作管理テーブル２３３との３つのテーブルを用いて格納および管理されている。

管理オブジェクト（Managed Object）は、管理対象システムの構成情報を構成管理装置２が一元的に管理できるようにするために、管理対象システムの構成要素をオブジェクトとして仮想化したものである。１つの管理オブジェクトは、管理対象システムの構成要素の１つに対応しており、例えば、業務アプリケーションおよびミドルウェアなどの
ソフトウェア、サーバ機などのハードウェア、およびデータベースなどを含む。

また、管理オブジェクト間の依存関係は、関係付けられたそれぞれの管理オブジェクトに対応する管理対象システムの構成要素の間に、依存関係があるという情報を構成情報の一部として保持するためのものある。例えば、図４では、上位階層のＤＢＭＳ５３と、下位階層のＤＢサーバ機５の間には依存関係がある旨の情報（ＤＢＭＳ５３とＤＢサーバ機５とを結ぶ直線）が示されている。これは、図３に示す管理対象システムにおいて、ＤＢＭＳ５３（図３では不図示）は、ＤＢサーバ機５上で実行されており、したがって、ＤＢサーバ５に依存していることを示している。すなわち、ＤＢサーバ５に障害が発生すると、ＤＢＭＳ５３にも障害が発生することを示している。

図示する管理オブジェクト構成は、業務Ａ１００の管理オブジェクトが最上位階層に位置する。なお、業務Ａ１００の管理オブジェクトは、下位階層の管理オブジェクトのインデックス（ポインタ）としての役割を果たすものである。業務Ａ１００の管理オブジェクトは、図３で説明したように、アプリケーション層と、データベース層とを有する。アプリケーション層については、業務Ａ１００の下位階層には少なくとも１つの業務アプケーション４２、業務アプケーション４２各々の下位階層にはミドルウェア４３、そして、ミドルウェア４３各々の下位階層にはハードウェアであるＡＰサーバ機４と負荷分散装置３とを有する。

また、データベース層については、業務Ａ１００の下位階層にはデータベース５２、データベース５２の下位階層にはＤＢＭＳ５３、そして、ＤＢＭＳ５３の下位階層にはハードウェアであるＤＢサーバ機５を有する。このように、最下位階層にはソフトウェアまたはデータベースを実装する（組み込む）ハードウェア４、５の管理オブジェクトが位置する。そして、当該ハードウェア４、５の上位階層には、基盤となるソフトウェア（すなわち、依存されるソフトウェア）４３、５３の管理オブジェクトが位置する。そして、基盤となるソフトウェア４３、５３の上位階層には、当該ソフトウェア４３、５３上で動作するソフトウェア（すなわち、依存するソフトウェア）またはデータベース（依存するデータベース）の管理オブジェクト４２、５２が位置する。

次に、構成管理装置２の記憶部２３に記憶された管理オブジェクトテーブル２３１、依存関係テーブル２３２、および、操作管理テーブル２３３について説明する。

図５は、管理オブジェクトテーブル２３１の一例を示したものである。管理オブジェクトテーブル２３１は、図４で説明した管理対象システムの各管理オブジェクトを記憶したテーブルである。図示するように、管理オブジェクトテーブル２３１は、管理オブジェクト毎に、オブジェクト名５０１と、オブジェクト種別５０２と、詳細情報５０３と、を有する。オブジェクト名５０１は、当該管理オブジェクトの名称であって、ユニークな名称である。オブジェクト種別５０２は、ＡＰサーバ機、ミドルウェア、業務アプリケーションなど、管理オブジェクトの種類を示すものである。

詳細情報５０３には、オブジェクト種別５０２毎に、異なる情報が設定される。例えば、オブジェクト種別５０２がＡＰサーバ機の場合、詳細情報には、ＣＰＵの名称などが設定される。また、オブジェクト種別がミドルウェアの場合、詳細情報には、製品名とバージョンなどが設定される。

図６は依存関係テーブル２３２の一例を示したものである。依存関係テーブル２３２は、管理オブジェクト毎に、当該管理オブジェクト上で動作する管理オブジェクト（上位階層の管理オブジェクト）を対応付けたテーブルである。図示するように、依存関係テーブル２３２は、管理オブジェクト毎に、オブジェクト名６０１と、上位オブジェクト名６０２と、を有する。上位オブジェクト名６０２には、オブジェクト名６０１に設定された管理オブジェクト各々の上位階層に位置する管理オブジェクトのオブジェクト名が設定される。

なお、管理オブジェクト間の階層構造については、図４に示す管理オブジェクト構成において、説明したとおりである。例えば、オブジェクト名６０１が「ＡＰサーバ機４−１」の上位オブジェクト名６０２は、「ミドルウェア４３−１」である。また、「業務Ａ」は最上位階層の管理オブジェクトであるため、オブジェクト名６０１が「業務Ａ」の上位オブジェクト名６０２は、「スペース」である。このような依存関係テーブル２３２を保持することにより、構成管理部２１は、管理対象システムの各管理オブジェクトについて、当該管理オブジェクトに変更が発生した場合、その影響をうける管理オブジェクトを特定することができる。

図７は、操作管理テーブル２３３の一例を示したものである。操作管理テーブル２３３は、メソッドを有する管理オブジェクト毎に、当該管理オブジェクトのメソッドが記憶されているテーブルである。メソッドとは、各管理オブジェクト自身に対する運用管理の操作（手続き）である。図示するように、操作管理テーブル２３３は、管理オブジェクト毎に、オブジェクト名７０１と、操作名７０２と、エージェントアドレス７０３と、エージェントポート番号７０４と、を有する。オブジェクト名７０１には、メソッドを有する管理オブジェクトの名称が設定される。操作名７０２には、メソッド（操作）の名称が設定される。エージェントアドレス７０３には、オブジェクト名７０１に設定された管理オブジェクトのＩＰアドレスが設定される。また、エージェントポート番号７０４には、オブジェクト名７０１に設定された管理オブジェクトと通信を行うためのポート番号が設定される。ポート番号とは、インターネット上の通信において、複数の相手と同時に接続を行なうためにＩＰアドレスの下に設けられたサブ(補助)アドレスである。図示する例では、オブジェクト名７０１が「ミドルウェア４３−１」の場合、操作名７０２には業務を起動する操作である「業務起動」が設定されている。

なお、以上説明した管理オブジェクトテーブル２３１、依存関係テーブル２３２、および、操作管理テーブル２３３は、管理者が入力装置９０４を用いて、またはネットワーク６などを介して、あらかじめ記憶部２３に記憶されているものとする。

次に、ポリシ管理装置１の記憶部１５に記憶されたポリシルールテーブル１５１について説明する。ポリシルールテーブル１５１には、管理対象のシステムにおいて、所定の事象が発生した場合に、当該事象毎に行うべき操作（処理）を定めた規則（ポリシルール）が記憶されている。

図８は、ポリシルールテーブル１５１の一例を示したものである。図示するように、ポリシルールテーブル１５１は、オブジェクト名８０１と、イベント名８０２と、通番８０３と、操作対象オブジェクト名８０４と、操作名８０５と、引数８０６とを有する。イベント名８０２は、運用管理装置２が検知した各種イベント（事象）の名称が設定される。通番８０３は、ポリシルール毎（オブジェクト名８０１が同一で、かつ、イベント名８０２が同一のレコードのグループ毎）に１から順に設定される連番である。ポリシ管理装置１は、この連番８０３の順番で、操作名８０５に指定された各操作の指示を行う。操作対象オブジェクト名８０４には、操作対象の管理オブジェクトのオブジェクト名が設定される。操作名８０５には、操作の名称が設定される。引数８０６には、操作名８０５に設定された操作を操作対象の管理オブジェクトに指示する際に引き渡すデータ（パラメータ）が設定される。

次に、構成管理装置２が、ポリシ管理装置１に送信するイベントメッセージについて説明する。構成管理装置２の構成管理部２１は、管理対象システムで発生する各種の事象を監視（モニタリング）または検知する。例えば、構成管理部２１は、監視対象の業務の応答時間（レスポンス）があらかじめ定められた閾値を超えた場合、または、監視対象システムの各管理オブジェクトの障害や構成変更を検知した場合、イベントメッセージを作成し、ポリシ管理装置１に通知する。

図９は、イベントメッセージの一例を示したものである。図示するように、イベントメッセージは、オブジェクト名９０１と、イベント名９０２と、詳細情報９０３と、を有する。オブジェクト名９０１には、イベントが発生した管理オブジェクトの名称が設定される。イベント名９０２には、構成変更、応答時間超過など、発生したイベント（事象）の名称が設定される。なお、構成管理部２１は、所定の業務の応答時間を監視しており、当該監視時間があらかじめ定められた閾値を超えた場合、イベント名９０２に「応答時間超過」を設定したイベントメッセージを作成する。また、構成管理部２１は、記憶部２３に記憶されている各テーブル２３１、２３２、２３３のデータが更新された場合、イベント名９０２に「構成変更」を設定したイベントメッセージを作成する。また、構成管理部２１は、各管理オブジェクトの障害を検知した場合、イベント名９０２に「障害」を設定したイベントメッセージを作成する。

詳細情報９０３には、イベント名９０２に設定された各イベントの詳細情報が設定される。例えば、オブジェクト名９０１が「ＡＰサーバ機４−１」でイベント名９０２が「構成変更」の場合、詳細情報９０３には変更後のＣＰＵ名が設定される。また、オブジェクト名９０１が「業務Ａ」でイベント名９０２が「応答時間超過」の場合、詳細情報９０３には閾値を超えた応答時間が設定される。

次に、ポリシ管理装置１の処理の流れを説明する。

図１０は、ポリシ管理装置１のイベント受付部１１の処理フローである。イベント受付部１１は、構成管理サーバ２から送信（通知）されるイベントメッセージ（図９参照）を受信する（Ｓ１０１）。なお、イベント受付部１１は、イベントメッセージを受信するまで待ちの状態である。そして、イベント受付部１１は、受信したイベントメッセージのイベント名９０２が構成変更か否かを判別する（Ｓ１０２）。

そして、イベント名９０２が構成変更でない場合（Ｓ１０２：ＮＯ）、イベント受付部１１は、記憶部１５に記憶されたポリシルールテーブル１５１を読み出し、イベントメッセージに対応するポリシルールを特定する（Ｓ１０３）。すなわち、イベント受付部１１は、イベントメッセージのオブジェクト名９０１およびイベント名９０２と同じポリシルール（少なくとも１つのレコード）を、ポリシルールテーブル１５１から検索する。例えば、イベントメッセージのオブジェクト名９０１が「業務Ａ」でイベント名９０２が「応答時間超過」の場合、イベント受付部１１は、ポリシルールテーブル１５１（図８参照）から、オブジェクト名が「業務Ａ」でイベント名が「応答時間超過」のポリシルール（少なくとも１つのレコード）８１０を特定する。

そして、イベント受付部１１は、ポリシルールテーブル１５１から特定したポリシールール（少なくとも１つのレコード）の通番８０３の順番で、レコード毎に構成管理装置を呼び出す（Ｓ１０４）。すなわち、イベント受付部１１は、当該レコードの操作対象オブジェクト名８０４、操作名８０５、引数８０６を含むメッセージを、構成管理装置２に送信（いわゆる、メソッド呼び出しを）する。

そして、構成管理装置２の構成管理部２１は、イベント受付部１１が送信したメッセージを受け付けると、操作管理テーブル２３３（図７参照）を読み出す。そして、構成管理部２１は、操作管理テーブル２３３から、メッセージに含まれる操作対象オブジェクト名８０４および操作名８０５と同一のオブジェクト名７０１および操作名７０２のレコードを特定する。そして、構成管理部２１は、特定したレコードのエージェントアドレス７０３およびエージェントポート番号７０４を宛先として、オブジェクト名７０１に設定された管理オブジェクトに操作名７０２に指定された操作の指示を送信する。なお、構成管理部２１は、操作を指示する際に、イベント受付部１１から受信したメッセージに含まれる引数８０６をあわせて送信する。

管理対象システムの各装置（負荷分散装置３、ＡＰサーバ機４、ＤＢサーバ機５など）のいずれかの装置の運用管理エージェント３１、４１、５１は、構成管理装置２から、引数８０６を含む操作指示を受信し、指示されたオブジェクトに対し、指示された操作を行う。例えば、ＡＰサーバ機４の運用管理エージェント４１は、管理対象システムの中で、構成要素であるミドルウェア４３や、ＡＰサーバ機４を管理対象として、運用管理操作を実行する。運用管理エージェント４１が、操作名８０５が「業務起動」で、引数８０６が「プログラム名＝Ｗ」の操作指示を受信した場合、当該運用管理エージェント４１が実行されているＡＰサーバ機４のオペレーティングシステムを使用して、ミドルウェア４３にプログラム名が「Ｗ」である業務プログラムを起動するように指示する。

一方、イベント名が「構成変更」の場合（Ｓ１０２：ＹＥＳ）、イベント受付部１１は、受信したイベントメッセージを変数Ｅとしてレジスタまたは記憶部１５に格納する（Ｓ１０５）。そして、イベント受付部１１は、影響範囲検索部１２を呼び出す。そして、イベント受付部１１は、当該イベントメッセージにより影響を受ける可能性のあるオブジェクト名のリスト（影響範囲検索部１２の処理結果）を受け取る（Ｓ１０６）。なお、影響範囲検索部１２の処理については後述する。

そして、イベント受付部１１は、ポリシルール検索部１３を呼び出す（Ｓ１０７）。そして、影響範囲検索部１２は、影響範囲検索部１２が作成したオブジェクト名のリストに対応するポリシルールをリストアップする。なお、ポリシルール検索部１３の処理については後述する。そして、イベント受付部１１は、ポリシルール検索部１３の処理が終了すると、イベントメッセージの待ちの状態に戻る（Ｓ１０１）。

次に、影響範囲検索部１２の処理の流れを説明する。

図１１は、影響範囲検索部１２のメインルーチンの処理フローである。影響範囲検索部１２のメインルーチンは、イベント受付部１１から呼び出されると（図１０：Ｓ１０６）、以降の処理で用いる変数Ｔのエリアを初期化する（Ｓ１１１）。なお、変数Ｔのエリアは、レジスタまたは記憶部１５に設定されるものとする。影響範囲検索部１２のメインルーチンは、イベント受付部１１がレジスタまたは記憶部１５に記憶した変数Ｅ（イベントメッセージ）のオブジェクト名を読み出し、変数Ｉとしてレジスタまたは記憶部１５に格納する（Ｓ１１２）。そして、影響範囲検索部１２のメインルーチンは、影響範囲検索部１２のサブルーチンを呼び出す（Ｓ１１３）。

図１２は、影響範囲検索部１２のサブルーチンの処理フローである。影響範囲検索部１２のサブルーチンは、メインルーチンから呼び出されると（図１１：Ｓ１１３）、構成管理装置２に変数Ｉに設定されたオブジェクト名の上位階層のオブジェクト名を要求する（Ｓ１２１）。構成管理装置２の検索応答部２２は、依存関係テーブル２３２（図６参照）を読み出し、オブジェクト名６０１が変数Ｉと一致するレコードを特定する。そして、検索応答部２２は、特定したレコードの上位オブジェクト名６０２をポリシ管理装置１に送信する。

なお、例えば、１台のサーバ装置（下位の管理オブジェクト）が複数の種類のミドルウェア（上位の管理オブジェクト）を有する場合など、上位オブジェクト名６０２が複数有る場合がある。この場合は、検索応答部２２は、複数の上位オブジェクト名６０２を送信する。また、最上位階層の管理オブジェクトの場合（例えば、業務Ａの場合など）、上位オブジェクト名６０２がスペース（空白）の場合がある。この場合は、検索応答部２２は、スペースを送信する。

そして、影響範囲検索部１２のサブルーチンは、構成管理装置２から上位オブジェクト名６０２を受け付けて、当該受け付けた上位オジェクト名を、変数Ｌとしてレジスタまたは記憶部１５に格納する（Ｓ１２２）。そして、影響範囲検索部１２のサブルーチンは、変数Ｌがスペースか否かを判別する（Ｓ１２３）。変数Ｌがスペースの場合（Ｓ１２３：ＹＥＳ）、影響範囲検索部１２のサブルーチンは、処理を終了し、メインルーチンに戻る。

一方、変数Ｌがスペースでない場合（Ｓ１２３：ＮＯ）、影響範囲検索部１２のサブルーチンは、変数Ｔ（図１１：Ｓ１１１）のエリアに、変数Ｌの内容を追加する（Ｓ１２４）。そして、影響範囲検索部１２のサブルーチンは、変数Ｉのエリアに変数Ｌの先頭の要素（上位オブジェクト名６０２）を格納する（Ｓ１２５）。そして、影響範囲検索部１２のサブルーチンは、変数Ｌの内容をスタックに退避する（Ｓ１２６）。そして、影響範囲検索部１２のサブルーチンは、当該影響範囲検索部１２のサブルーチンを再帰的に呼び出す（Ｓ１２７）。

そして、再帰的に呼び出したサブルーチンの処理が終了した後、影響範囲検索部１２のサブルーチンは、スタックに退避した変数Ｌの内容を取り出して、変数Ｌのエリアに格納する（Ｓ１２８）。そして、影響範囲検索部１２のサブルーチンは、変数Ｌに次の要素（未処理の上位オブジェクト名６０２）が存在するか否かを判別する（Ｓ１２９）。次の要素が存在しない場合（Ｓ１２９：ＮＯ）、影響範囲検索部１２のサブルーチンは、処理を終了し、メインルーチンに戻る。一方、次の要素が存在する場合（Ｓ１２９：ＹＥＳ）、影響範囲検索部１２のサブルーチンは、変数Ｉのエリアに変数Ｌの次の要素を格納して、Ｓ１２６の処理に戻る（Ｓ１３０）。

以上のように、影響範囲検索部１２は、イベントメッセージのオブジェクト名９０１に設定された管理オブジェクトより上位の階層の全てのオブジェクト名を取得し、変数Ｔのエリアに格納する。すなわち、影響範囲検索部１２は、イベントメッセージのオブジェクト名に設定されたオブジェクトの構成変更により影響を受ける可能性のある全てのオブジェクト名をリストアップした変数Ｔを作成する。そして、影響範囲検索部１２は、処理を終了し、イベント受付部１１の処理（図１０：Ｓ１０６）に戻る。

次に、ポリシルール検索部１３の処理の流れを説明する。

図１３は、ポリシルール検索部１３の処理フロー図である。ポリシルール検索部１３は、イベント受付部１１から呼び出されると（図１０：Ｓ１０７）、変数Ｔの先頭の要素（オブジェクト名）を読み出し、変数Ｊとしてレジスタまたは記憶部１５に格納する（Ｓ１３１）。そして、ポリシルール検索部１３は、ポリシルールテーブル１５１を検索し、オブジェクト名８０１が変数Ｊと一致する全てのレコードを抽出する。そして、ポリシルール検索部１３は、抽出したレコードを変数Ｓとしてレジスタまたは記憶部１５に格納する（Ｓ１３２）。そして、ポリシルール検索部１３は、変数Ｓに格納した各レコードをソート（整列）する（Ｓ１３３）。すなわち、ポリシルール検索部１３は、変数Ｓの各レコードのイベント名８０２を第１のソートキーとし、通番８０３を第２のソートキーとして昇順に並べ替える。そして、ソートした変数Ｓの内容を、出力部１４を用いて出力装置９０５に出力する（Ｓ１３４）。なお、出力装置９０５に出力される出力画面については、後述する。

そして、ポリシルール検索部１３は、変数Ｔに次（未処理）の要素（オブジェクト名）があるか否かを判別する（Ｓ１３５）。そして、変数Ｔに次の要素がある場合（Ｓ１３５：ＹＥＳ）、ポリシルール検索部１３は、変数Ｊに次の要素の内容を設定し、Ｓ１３２の処理に戻る（Ｓ１３６）。一方、変数Ｔに次の要素がない場合（Ｓ１３５：ＮＯ）、ポリシルール検索部１３は、処理を終了し、イベント受付部１１の処理に戻る（図１０：Ｓ１０７）。

以上のように、ポリシルール検索部１３は、変数Ｔに設定された全てのオブジェクト名に対応するポリシルールをポリシルールテーブル１５１からリストアップし、出力装置９０５に出力する。そして、ポリシルール検索部１３は、処理を終了し、イベント受付部１１の処理（図１０：Ｓ１０７）に戻る。そして、イベント受付部１１は、再び構成管理装置２からのイベントメッセージの待ちの状態となる。

図１４に、ポリシルール検索部１３が、出力部１４を用いて出力装置９０５に出力する出力画面の一例を示す。

図示するように、本出力画面には、オブジェクト名１４１と、当該オブジェクト名に対応するイベント名１４２と、当該イベント名１４２の詳細な内容を表示するための詳細表示ボタン１４３と、承認指示を受け付けるための承認チェックボックス１４４と、を有する。オブジェクト名１４１には、変数Ｔにリストアップされた各オブジェクト名が表示される。イベント名には、管理オブジェクト毎にポリシルールテーブルから検索されたレコードの各イベント名８０２が表示される。なお、変数Ｔにリストアップされたオブジェクト名のポリシルールが存在しない場合、イベント名１４２は表示されない。

そして、ポリシルール検索部１３は、入力装置９０４などを用いてイベント名８０２各々に対応して表示された詳細表示ボタン１４３の押下を受け付けると、当該オブジェクト名１４１で、かつ、当該イベント名１４２のレコード（ポリシルール）を、変数Ｓまたはポリシルールテーブル１５１から抽出し、出力装置９０５に出力する。承認チェックボックス１４４については、管理者が、本出力画面に表示されたイベント毎のポリシルールの修正を行った場合、または、修正が不要であると判断した場合に、チェック（レ印）を入力する。これにより、ポリシルールの修正漏れ容易に防止することができる。

以上で本実施形態について説明した。

上記の実施形態では、構成変更のイベントメッセージを受け付けて、当該構成変更の影響を受ける可能性のあるポリシルールをリストアップし、出力装置９０５に出力する。これにより、管理者は、構成変更後のシステムと矛盾する（整合性のない）ポリシルールが存在するか否かを、効率よくチェックすることができる。また、構成変更により、システムと矛盾するポリシルールについては、ポリシルールの修正を迅速に実施することができる。

また、当該構成変更の影響を受ける可能性のあるポリシルールをリストアップすることによって、ポリシルールテーブル１５１に膨大なポリシルールが登録されていた場合であっても、修正が必要なポリシルールの修正漏れを防止することができる。

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記の実施形態では、ポリシ管理装置１は、構成管理装置２から、ネットワーク６を介してイベントメッセージ（図９参照）を受信する。しかしながら、ポリシ管理装置１は、構成管理装置２以外からイベントメッセージを受信して、影響するポリシルールをリストアップすることとしてもよい。具体的には、管理者が、所定の管理オブジェクトを変更した場合に影響するポリシルールをリストアップするため（シミュレーションするため）に、ポリシ管理装置１の入力装置９０４からイベントメッセージに相当するデータを入力することとしてもよい。イベント受付部１１は、入力装置９０４から入力されたデータを受け付けて、図１０に示す処理を行う。

また、ポリシルールテーブル１５１に、管理者の注意を促すための要注意フラグをさらに設定することとしても良い。要注意フラグは、ポリシルールに記載された操作を自律的に行う際に、管理者に当該操作を行うか否の指示を入力させるためのフラグである。例えば、ポリシ管理装置１が構成変更のイベントメッセージを受け付けた場合、図１０のＳ１０５以降の処理を行い、当該構成変更により影響を受ける可能性のあるポリシルールをリストアップし、出力装置９０５に出力する。しかしながら、管理者が構成変更後のシステムと矛盾しないようにポリシルールを修正するまでの間に、構成変更以外のイベントメッセージがポリシ管理装置１に送信される場合がある。

具体的には、業務Ａの応答時間が所定の制限時間を超えると、ＡＰサーバ機を一台追加する、というポリシルールがあるとする。そして、ＡＰサーバ機を高性能なサーバ機にアップグレードした構成変更のイベントメッセージがポリシ管理装置１に通知されるものとする。この場合、応答時間のボトルネックはＤＢサーバ機となるため、管理者は、前記ポリシルールを修正する必要がある。しかしながら、管理者がポリシルールを修正するまでの間に、業務Ａの応答時間制限超過のイベントメッセージが通知されると、現状（修正前）のポリシルールを実行してしまう（図１０：Ｓ１０４）。すなわち、ＡＰサーバ機はボトルネックではなくなったにもかかわらず、１台追加されてしまう。そこで、構成変更によりリストアップされたポリシルールについては要注意フラグを設定し、要注意フラグが設定されたポリシルールを実行する前に管理者に当該ポリシルールの操作を行うか否の指示を入力させることとする。

図１５は、要注意フラグを有するポリシルールテーブル１５１Ａの一例を示す図である。図示するポリシルールテーブル１５１Ａは、要注意フラグ８０７を有する点において、図８のポリシルールテーブル１５１と異なる。要注意フラグ８０７は、初期状態においては、「０」が設定され、構成変更によりリストアップされると要注意であることを示す「１」が設定される。なお、ポリシルール検索部１３は、図１３のＳ１３２の処理において、オブジェクト名が変数Ｊと一致するレコードを特定する際に、要注意フラグを「０」から「１」に更新する。また、ポリシルール検索部１３は、図１４に示す出力画面の承認チェックボックス１４４にチェック（レ印）の入力を受け付けたタイミングで、ポリシルールテーブル１５１Ａの要注意フラグ８０７を、「１」から「０」に更新する。

図１６は、要注意フラグを有する場合にイベント受付部１１が実行する図１０のＳ１０３の処理フローである。イベントメッセージのイベント名９０２が構成変更でない場合（Ｓ１０２：ＮＯ）、イベント受付部１１は、記憶部１５に記憶されたポリシルールテーブル１５１Ａを読み出し、イベントメッセージに対応するポリシルール（少なくとも１つのレコード）を特定する（Ｓ１０３１）。そして、イベント受付部１１は、特定したポリシルールのフラグに「１（要注意）」が設定されているか否かを判別する（Ｓ１０３２）。ポリシルールのフラグに「０（初期状態）」が設定されている場合（Ｓ１０３２：ＮＯ）、イベント管理部１１は、図１０に示すＳ１０４の処理に進む。

一方、ポリシルールのフラグに「１（要注意）」が設定されている場合（Ｓ１０３２：ＹＥＳ）、イベント管理部１１は、指示受付画面を出力装置９０５に出力する（Ｓ１０３３）。指示受付画面は、当該ポリシルールの操作を実行するか、または、中止するかの指示を受け付けるための画面である。このような指示受付画面を出力し、当該ポリシルールの実行可否を入力させることにより、構成変更後のシステムと矛盾するポリシルールの実行を回避することができる。

そして、イベント受付部１１は、管理者が入力装置９０４を介して入力した指示を受け付ける（Ｓ１０３４）。そして、イベント受付部１１は、当該指示がポリシルールの実行指示か否かを判別する（Ｓ１０３５）。実行指示を受け付けた場合（Ｓ１０３５：ＹＥＳ）、イベント受付部１１は、図１０に示すＳ１０４の処理に進む。一方、中止指示を受け付けた場合（Ｓ１０３５：ＮＯ）、イベント受付部１１は、ポリシルールの実行を中止し、図１０に示すＳ１０１の処理に戻り、イベントメッセージの待ちの状態となる。

また、図１５に示す要注意フラグを有するポリシルールテーブル１５１Ａにおいて、要注意フラグ８０７に「１（要注意）」が設定されたポリシルールを実行する場合（図１０：Ｓ１０４）、イベント受付部１１は、以下の処理を行うこととしてもよい。すなわち、イベント受付部１１は、ポリシルールに記述された運用管理操作の実行対象である、管理対象システムの構成要素のトレース出力レベルを上げることとしてもよい。具体的には、イベント受付部１１は、図１０のＳ１０３の後、Ｓ１０４を実行する中で、ポリシルールに記載された一連の運用管理操作を構成管理装置２に対するメソッド呼び出しにより順次実行する。その際に、イベント受付部１１は、実行する運用管理操作各々について、要注意フラグが「１」であれば、直前に操作名「トレースレベル上昇」の運用管理操作を行うようにする。「トレースレベル上昇」が操作名となっている運用管理操作要求を受け付けた構成管理装置２は、操作管理テーブル２３３を参照し、管理対象システムの各運用管理エージェント３１、４１、５１のいずれかに、操作要求を行う。

操作要求を受信した運用管理エージェンは、それぞれが管理対象とする管理対象システムの構成要素に対して、トレースレベルを上昇させる運用管理操作を実行する。一般に、ミドルウェア、ＯＳ、ＤＢＭＳなどの管理対象システムの構成要素は、障害発生時に管理者が障害の原因を特定できるようにするために、稼動情報をトレースとして記憶装置に随時出力している。一般に、これらの構成要素が出力するトレースは、その詳細度をトレースレベルとして設定できるようになっており、トレースレベルが高いほど詳細な稼動情報が出力される。操作名が「トレースレベル上昇」の操作要求を受け取った運用管理エージェントは、管理対象とする構成要素（ミドルウェアなど）に対して、トレースレベルの変更を行う。

例えば、図１０のＳ１０３で特定されたポリシルールが、図１５に示すオブジェクト名８０１が「業務Ａ」でイベント名８０２が「応答時間制限超過」８２０であるとする。このとき、イベント受付部１１は、Ｓ１０４において、構成管理装置２に対して次の順序で運用管理操作要求を行う。まず、イベント受付部１１は、オブジェクト名「ミドルウェア４３−２」の管理オブジェクトに対して、操作名が「トレースレベル上昇」（不図示）の運用管理操作を要求する。その結果として、管理対象システムのミドルウェア４３−２は、稼動情報をトレースとしてより詳細に出力するようになる。

次に、イベント受付部１１は、オブジェクト名「ミドルウェア４３−２」の管理オブジェクトに対して、操作名８０５が「業務起動」、引数８０６が「プログラム＝Ｗ」の運用管理操作を要求する。その結果として、管理対象システムのミドルウェア４３−２は、プログラム名が「Ｗ」のプログラムを起動するが、その前にトレースレベルが変更されているため、プログラム起動中の状況（途中経過など）をより詳細にトレースとして出力する。

次に、イベント受付部１１は、オブジェクト名「負荷分散装置３」の管理オブジェクトに対して、操作名が「トレースレベル上昇」（不図示）の運用管理操作を要求する。その結果として、負荷分散装置３は、稼動情報をトレースとしてより詳細に出力するようになる。そして、イベント受付部１１は、オブジェクト名「負荷分散装置３」の管理オブジェクトに対して、操作名８０５が「負荷分散先追加」、引数８０６が「ミドルウェア４３−２」の運用管理操作を要求する。その結果として、管理対象システムの負荷分散装置３は、負荷分散先に管理対象システムのミドルウェア４３−２を追加するが、その前にトレースレベルが変更されているため、追加処理の実行中の状況（ネットワーク設定の変更状況など）を、より詳細にトレースとして出力する。

なお、同様に、イベント受付部１１は、もし自分自身もトレース出力しており、その詳細度をトレースレベルとして設定できるのであれば、前記の「トレースレベル上昇」の運用管理操作を行う前に、自分自身のトレースレベルも上昇させるようにしてもよい。この場合、図１０のＳ１０３で特定されたポリシルールの要注意フラグ８０７が「１」の場合、イベント受付部１１がポリシルールを実行するために行った処理の実行情報（構成管理装置２への通信ログなど）についても、より詳細に出力されるようになる。

これにより、要注意フラブが「１（要注意）」のポリシルールを実行したことにより何か問題が発生した場合、管理者は詳細なトレース情報を参照することにより、当該問題を解決するために迅速な対応をとることができる。

本発明の一実施形態が適用されたシステムの全体構成図。 各装置のハードウェア構成例を示す図。 管理対象システムのシステム構成の一例を示す図。 管理対象システムの管理オブジェクト構成図の一例を示す図。 管理オブジェクトテーブルの一例を示す図。 依存関係テーブルの一例を示す図。 操作管理テーブルの一例を示す図。 ポリシルールテーブルの一例を示す図。 イベントメッセージの一例を示す図。 イベント受付部の処理フロー図。 影響範囲検索部のメインルーチンの処理フロー図。 影響範囲検索部のサブルーチンの処理フロー図。 ポリシルール検索部の処理フロー図。 ポリシルールリストアップの出力画面の一例を示す図。 要注意フラグを有するポリシルールテーブルの一例を示す図。 要注意フラグを有する場合のイベント受付部の処理フロー図。

符号の説明

１：ポリシ管理装置、１１：イベント受付部、１２：影響範囲検索部、１３：ポリシルール検索部、１４：出力部、１５：記憶部、２：構成管理装置、２１：構成管理部、２２：検索応答部、２３：記憶部、３：負荷分散装置、３１：運用管理エージェント、３２：分散処理部、４：ＡＰサーバ機、４１：運用管理エージェント、４２：業務アプリケーション、４３：ミドルウェア、５：ＤＢサーバ機、５１：運用管理エージェント、５２：データベース、５３：ＤＢＭＳ、６：ネットワーク

Claims (10)

1. 情報処理装置が行う、コンピュータシステムにおけるポリシルールの管理を支援するポリシルール管理支援方法において、
   前記ポリシルールは、前記コンピュータシステムの運用管理操作であって、
   前記情報処理装置は、処理部と、前記コンピュータシステムの構成要素毎に少なくとも１つのポリシルールが記憶されたポリシルール記憶部とを有し、
   前記処理部は、
   前記コンピュータシステムの構成要素毎に、構成変更通知を受け付ける受付ステップと、
   前記受付ステップにおいて受け付けた構成要素の構成変更通知により、影響を受ける少なくとも１つの構成要素を検出する検出ステップと、
   前記検出ステップにおいて検出された構成要素各々に対応付けられたポリシルールを、前記ポリシルール記憶部から特定し、当該特定したポリシルールの一覧を作成する作成ステップと、を行うこと
   を特徴とするポリシルール管理支援方法。
2. 請求項１記載のポリシルール管理支援方法であって、
   前記処理部は、前記作成ステップが作成した前記ポリシルールの一覧を、出力装置に出力する第１の出力ステップを、さらに行うこと
   を特徴とするポリシルール管理支援方法。
3. 請求項１記載のポリシルール管理支援方法であって、
   前記受付ステップは、前記構成変更通知を、ネットワークを介して接続された外部システムおよび／または前記情報処理が有する入力手段から受け付けること
   を特徴とするポリシルール管理支援方法。
4. 請求項１記載のポリシルール管理支援方法であって、
   前記処理部は、
   前記特定ステップにおいて特定したポリシルール各々に、当該ポリシルールの運用管理操作を行うか否かを判別するための要注意フラグを設定する設定ステップと、
   前記コンピュータシステムの構成要素毎に、前記構成変更通知以外のその他通知を受け付ける通知受付ステップと、
   前記通知受付ステップにおいて受け付けた構成要素の前記その他通知に対応するポリシルールを前記ポリシルール記憶部から特定し、当該特定したポリシルールに前記要注意フラグが設定されているか否かを判別する判別ステップと、
   前記判別ステップで要注意フラグが設定されていると判別した場合、前記特定したポリシルールを出力装置に出力する第２の出力ステップと、をさらに行うこと
   を特徴とするポリシルール管理支援方法。
5. 請求項１記載のポリシルール管理支援方法であって、
   前記処理部は、
   前記特定ステップにおいて特定したポリシルール各々に、当該ポリシルールの運用管理操作を行うか否かを判別するための要注意フラグを設定する設定ステップと、
   前記コンピュータシステムの構成要素毎に、前記構成変更通知以外のその他通知を受け付ける通知受付ステップと、
   前記通知受付ステップにおいて受け付けた構成要素の前記その他通知に対応するポリシルールを前記ポリシルール記憶部から特定し、当該特定したポリシルールに前記要注意フラグが設定されているか否かを判別する判別ステップと、
   前記判別ステップで要注意フラグが設定されていると判別した場合、前記コンピュータシステムのトレース出力レベルを上げる指示を、前記コンピュータシステムに通知する通知ステップと、をさらに行うこと
   を特徴とするポリシルール管理支援方法。
6. 請求項１記載のポリシルール管理支援方法であって、
   前記コンピュータシステムの構成要素には、所定の業務と、当該所定の業務を実行するためのアプリケーションプログラムとを含み、
   前記所定の業務は、前記アプリケーションプログラムの構成変更により、影響を受ける構成要素であること
   を特徴とするポリシルール管理支援方法。
7. 請求項１記載のポリシルール管理支援方法であって、
   前記コンピュータシステムの前記構成要素には、アプリケーションプログラムと、当該アプリケーションプログラムに各種の機能を提供するミドルウェアとを含み、
   前記アプリケーションプログラムは、前記ミドルウェアの構成変更により、影響を受ける構成要素であること
   を特徴とするポリシルール管理支援方法。
8. 請求項１記載のポリシルール管理支援方法であって、
   前記コンピュータシステムの前記構成要素には、アプリケーションプログラムに各種の機能を提供するミドルウェアと、当該ミドルウェアを実行するサーバ装置と含み、
   前記ミドルウェアは、前記サーバ装置の構成変更により、影響を受ける構成要素であること
   を特徴とするポリシルール管理支援方法。
9. コンピュータシステムにおけるポリシルールの管理を支援するポリシルール管理支援装置において、
   前記ポリシルールは、前記コンピュータシステムの運用管理操作であって、
   前記コンピュータシステムの構成要素毎に少なくとも１つのポリシルールが記憶されたポリシルール記憶手段と、
   前記コンピュータシステムの構成要素毎に、構成変更通知を受け付ける受付手段と、
   前記受付手段が受け付けた構成要素の構成変更により、影響を受ける少なくとも１つの構成要素を検出する検出手段と、
   前記検出手段が検出した構成要素各々に対応するポリシルールを、前記ポリシルール記憶部から特定し、当該特定したポリシルールの一覧を作成する作成手段と、を有すること
   を特徴とするポリシルール管理支援装置。
10. 情報処理装置がコンピュータシステムにおけるポリシルールの管理を支援するためのポリシルール管理支援プログラムにおいて、
    前記ポリシルールは、前記コンピュータシステムの運用管理操作であって、
    前記情報処理装置は、処理部と、前記コンピュータシステムの構成要素毎に少なくとも１つのポリシルールが記憶されたポリシルール記憶部とを有し、
    前記処理部に、
    前記コンピュータシステムの構成要素毎に、構成変更通知を受け付ける受付ステップと、
    前記受付ステップにおいて受け付けた構成要素の構成変更により、影響を受ける少なくとも１つの構成要素を検出する検出ステップと、
    前記検出ステップにおいて検出された構成要素各々に対応するポリシルールを、前記ポリシルール記憶部から特定し、当該特定したポリシルールの一覧を作成する作成ステップと、を実行させること
    を特徴とするポリシルール管理支援プログラム。
    

Images