(57)【要約】      （修正有）【課題】システムの信頼性を向上させる管理装置、管理方法および管理プログラムを提供する。【解決手段】コントロールサーバ１０は、各データセンタで動作するシステムの構成情報を記憶する記憶部１２を有する。そして、コントロールサーバ１０は、障害が発生する条件を満たすシステムの構成情報を有するデータセンタを、記憶部１２に記憶される情報から特定する。その後、コントロールサーバ１０は、障害が発生する条件を満たすと特定されたデータセンタの通知先に、障害に関する障害情報を送信する。【選択図】図２
2017058789.tif 000002
【特許請求の範囲】
【請求項１】
各データセンタで動作するシステムの構成情報を記憶する記憶部と、
障害が発生する条件を満たす前記システムの構成情報を有するデータセンタを前記記憶部から特定する特定部と、
前記特定部によって特定された前記データセンタの通知先に、前記障害に関する障害情報を送信する送信部と
を有することを特徴とする管理装置。
【請求項２】
前記記憶部は、前記データセンタが設置される地域を特定する地域情報をさらに記憶し、
前記送信部は、特定された前記データセンタに対応付けられる前記地域情報にしたがって、前記障害情報の送信を制御することを特徴とする請求項１に記載の管理装置。
【請求項３】
前記送信部は、前記地域情報にしたがって特定される地域が輸出規制に該当する場合、前記障害情報の送信を抑制することを特徴とする請求項２に記載の管理装置。
【請求項４】
前記送信部は、前記地域情報にしたがって特定される地域が輸出規制に該当する場合、前記障害情報の一部を送信することを特徴とする請求項２に記載の管理装置。
【請求項５】
前記送信部は、前記地域情報にしたがって特定される地域が輸出規制に該当する場合、特定される前記データセンタの管理者のうち、前記輸出規制に該当しない地域にいる管理者に対応づけられた通知先に対して、前記障害情報を送信することを特徴とする請求項２に記載の管理装置。
【請求項６】
コンピュータが、
各データセンタで動作するシステムの構成情報を記憶する記憶部を参照し、障害が発生する条件を満たす前記システムの構成情報を有するデータセンタを前記記憶部から特定する処理と、
特定された前記データセンタの通知先に、前記障害に関する障害情報を送信する処理と
を実行することを特徴とする管理方法。
【請求項７】
コンピュータに、
各データセンタで動作するシステムの構成情報を記憶する記憶部を参照し、障害が発生する条件を満たす前記システムの構成情報を有するデータセンタを前記記憶部から特定する処理と、
特定された前記データセンタの通知先に、前記障害に関する障害情報を送信する処理と
を実行させることを特徴とする管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理装置、管理方法および管理プログラムに関する。
【背景技術】
【０００２】
近年、仮想マシンなどの普及により、地域や国に限定されず、複数のデータセンタを用いてサービスを提供するアウトソーシングサービスが普及している。例えば、アウトソーシングサービスは、サービスマネージメント、運用、サービスプラットフォーム、ファシリティ、ネットワークを、統一されたコンセプトと標準化されたサービスマネージメントのもとに、地理的な制約や物理的な制約を受けることなく、均質に提供する。
【０００３】
また、アウトソーシングサービスは、複数のデータセンタから構成されることから、稼働する情報機器の台数やシステム数は膨大な数となる。このため、システム毎に担当エンジニアが存在し、それぞれのシステムを個別に管理することが一般的である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００６−５２０９７５号公報
【特許文献２】特開２００６−２４４３７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記技術では、担当エンジニアの負荷が高く、障害検出や障害対応に漏れや遅延が発生することがあり、システムの信頼性が低下する。例えば、ハードウェアやソフトウェアを開発するベンダー各社は、障害情報を随時公開しているが、障害情報を確認する頻度や網羅性は、担当エンジニアによってバラツキがある。また、担当エンジニアが、公開される障害情報とシステムの構成情報とを突き合わせて障害の検出を行っているが、システム内のハードウェアやソフトウェアの増加に伴い、担当エンジニアの作業負担も大きくなる。
【０００６】
１つの側面では、システムの信頼性を向上させることができる管理装置、管理方法および管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
第１の案では、管理装置は、各データセンタで動作するシステムの構成情報を記憶する記憶部を有する。管理装置は、障害が発生する条件を満たす前記システムの構成情報を有するデータセンタを前記記憶部から特定する特定部を有する。管理装置は、前記特定部によって特定された前記データセンタの通知先に、前記障害に関する障害情報を送信する送信部を有する。
【発明の効果】
【０００８】
一実施形態によれば、システムの信頼性を向上させることができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施例１にかかるシステムの全体構成例を示す図である。
【図２】図２は、実施例１にかかるシステムの機能構成を示す機能ブロック図である。
【図３】図３は、障害マスタＤＢに記憶される情報の例を示す図である。
【図４】図４は、顧客マスタＤＢに記憶される情報の例を示す図である。
【図５】図５は、センタマスタＤＢに記憶される情報の例を示す図である。
【図６】図６は、条件マスタＤＢに記憶される情報の例を示す図である。
【図７】図７は、構成ＤＢに記憶される情報の例を示す図である。
【図８】図８は、ユーザ通知例を説明する図である。
【図９】図９は、障害更新時の処理の流れを示すフローチャートである。
【図１０】図１０は、構成更新時の処理の流れを示すフローチャートである。
【図１１】図１１は、障害情報の通知判定処理の流れを示すフローチャートである。
【図１２】図１２は、ハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１０】
以下に、本願の開示する管理装置、管理方法および管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は矛盾のない範囲内で適宜組み合わせることができる。
【実施例１】
【００１１】
［全体構成］
図１は、実施例１にかかるシステムの全体構成例を示す図である。図１に示すように、このシステムは、コントロールセンタ１、データセンタＡ、データセンタＢ、データセンタＣを有する。
【００１２】
各データセンタは、物理サーバが設定されるデータセンタ（以下、ＤＣと記載する場合がある）であり、物理サーバまたは仮想マシンによって、Ｗｅｂサーバ、ＤＢ（DataBase）サーバ、ＡＰサーバなどの各種サーバ機能を提供し、運用系システムを提供する。コントロールセンタ１は、コントロールサーバ１０が設置され、各データセンタに関する情報や各データセンタを利用する顧客に関する情報を管理するデータセンタである。
【００１３】
また、データセンタＡは、Ａ国内に設置され、データセンタＢは、Ｂ国内に設置され、データセンタＣは、Ｃ国内に設置され、コントロールセンタ１は、Ａ国内に設置される。つまり、図１の例では、データセンタＡとコントロールセンタ１は同国内に設置され、他のデータセンタは、別の国に設置されている。
【００１４】
このような状態において、コントロールセンタ１のコントロールサーバ１０は、各データセンタで動作するシステムの構成情報を記憶する。そして、コントロールサーバ１０は、障害が発生する条件を満たすシステムの構成情報を有するデータセンタを特定する。その後、コントロールサーバ１０は、特定されたデータセンタに、障害に関する障害情報を送信する。
【００１５】
つまり、コントロールサーバ１０は、管理対象のＤＣのうち、障害条件と一致するシステム構成を有するＤＣを特定し、該ＤＣに障害情報を配布する。このようにすることで、各ＤＣの担当エンジニアによる障害検出に関する負荷を軽減でき、障害見落としなどの人為的なミスを削減し、システムの信頼性を向上させることができる。
【００１６】
［機能構成］
次に、図１に示したコントロールセンタ１のコントロールサーバ１０および各データセンタに設置される管理サーバについて説明する。なお、各データセンタに設置される管理サーバは同様の構成を有するので、ここでは、管理サーバ５０として説明する。図２は、実施例１にかかるシステムの機能構成を示す機能ブロック図である。
【００１７】
（コントロールサーバ１０の構成）
図２に示すように、コントロールサーバ１０は、通信部１１、記憶部１２、制御部２０を有する。
【００１８】
通信部１１は、有線や無線を問わず、他の装置との通信を制御する通信インタフェースである。例えば、通信部１１は、管理者端末やベンダー各社から、障害が発生する可能性があるシステム構成の情報や障害の優先度などを含む障害情報を受信する。また、通信部１１は、各ＤＣの管理サーバ５０に、障害情報を送信する。
【００１９】
記憶部１２は、制御部２０が実行するプログラムやデータを記憶するデータベースであり、例えばハードディスクやメモリなどである。この記憶部１２は、障害マスタＤＢ１３、顧客マスタＤＢ１４、センタマスタＤＢ１５、条件マスタＤＢ１６、構成ＤＢ１７を記憶する。
【００２０】
障害マスタＤＢ１３は、障害の発生条件や障害の優先度などを含む障害情報を記憶するデータベースである。図３は、障害マスタＤＢ１３に記憶される情報の例を示す図である。図３に示すように、障害マスタＤＢ１３は、「障害ＩＤ、該当条件、優先度、対策情報」などを対応付けて記憶する。
【００２１】
ここで記憶される「障害ＩＤ」は、障害を一意に識別する識別子である。「該当条件」は、障害を発生させるシステムの構成情報であり、例えばＯＳ（Operating  System）の種別、ＯＳのバージョン、ＨＷ（HardWare）の種別、ＨＷのバージョン、ＳＷ（SoftWare）の種別、ＳＷのバージョン、ＭＷ（MiddleWare）の種別、ＭＷのバージョンなどである。「優先度」は、障害の影響度を示す情報であり、影響大きい、注意喚起、通知レベルなどが設定される。「対策情報」は、ベンダー等が通知する障害対策の情報であり、例えばパッチ適用、ＸＸＸファイル削除、再インストールなどが設定される。
【００２２】
図３の例では、優先度として「影響度の大きい」が設定される「Ｓ００１」の障害が、「Ｗ２０１２」のＯＳで発生することを示している。また、優先度として「注意喚起」が設定される「Ｓ００２」の障害が、ＭＷ「ＩＡＳ」のバージョン「Ｖ９．２．０」で発生することを示している。
【００２３】
顧客マスタＤＢ１４は、ＤＣを利用する顧客に関する情報を記憶するデータベースである。図４は、顧客マスタＤＢ１４に記憶される情報の例を示す図である。図４に示すように、顧客マスタＤＢ１４は、「顧客ＩＤ、顧客名、ＤＣＩＤ、契約条件、障害情報等の通知先」を対応付けて記憶する。
【００２４】
ここで記憶される「顧客ＩＤ」は、顧客を識別する識別子である。「顧客名」は、顧客の名称である。「ＤＣＩＤ」は、顧客が利用するＤＣを識別する識別子である。「契約条件」は、ＤＣを運営する会社と顧客との間で締結された契約条件である。「障害情報等の通知先」は、管理者のアドレス情報などである。
【００２５】
図４の例では、「Ａ社」には「Ｕ００１」が割当てられており、このＡ社が「サポートデスクあり」の条件で、「Ｄ００１」のＤＣを使用していることを示す。また、「Ｂ社」には「Ｕ００２」が割当てられており、このＢ社が「サポートデスクなし」の条件で、「Ｄ００２」のＤＣを使用していることを示す。また、Ａ社の管理者の通知先がアドレス（ＸＸＸ）であることが示される。
【００２６】
センタマスタＤＢ１５は、各ＤＣの設置場所などに関する情報を記憶するデータベースである。図５は、センタマスタＤＢ１５に記憶される情報の例を示す図である。図５に示すように、センタマスタＤＢ１５は、「ＤＣＩＤ、設置センタ、設置場所」を対応付けて記憶する。
【００２７】
ここで記憶される「ＤＣＩＤ」は、ＤＣを識別する識別子である。「設置センタ」は、ＤＣが設置される地域を示し、「設置場所」は、ＤＣが設置される国を示す。図５の例では、「Ｄ００１」のＤＣは、「日本」の「館林」に設置されることを示し、「Ｄ００２」のＤＣは、「アメリカ」の「カルフォルニア」に設置されることを示す。
【００２８】
条件マスタＤＢ１６は、システム構成が障害情報を満たすか否かを判定するときに使用する情報を記憶するデータベースである。図６は、条件マスタＤＢ１６に記憶される情報の例を示す図である。図６に示すように、条件マスタＤＢ１６は、「構成ＩＤ、ハード名、ＯＳ、ＭＷ、アプリ、障害ＩＤ、一致フラグ」を対応付けて記憶する。
【００２９】
ここで記憶される「構成ＩＤ」は、システム構成を識別する識別子であり、「ハード名」は、システムを構成するハードウェアの名称である。「ＯＳ」は、システムで利用されるＯＳの名称であり、「ＭＷ」は、システムで利用されるミドルウェアの情報であり、「アプリ」は、システムで動作するアプリケーションの情報である。「障害ＩＤ」は、当該システム構成と一致する障害情報の識別子である。「一致フラグ」は、いずれかの障害情報と一致したか否かを示す情報である。
【００３０】
図６の例では、システム構成「Ｋ００１」は、「ＸＸＸ」のハードウェア、「Ｗ２０１２」のＯＳ、「ＩＡＳ  Ｖ９．２．０」のミドルウェアで構成される。また、このシステム構成「Ｋ００１」では、アプリケーションとして「ＡＰＬ（Ａ）」が動作する。そして、このシステム構成「Ｋ００１」は、「Ｓ００１」の障害情報と一致したことを示す。
【００３１】
また、システム構成「Ｋ００２」は、「ＲＲＲ」のハードウェア、「Ｗ００８」のＯＳ、「ＳＣＭＥＥ  Ｖ１５．１．０」のミドルウェアで構成される。また、このシステム構成「Ｋ００２」では、アプリケーションとして「ＡＰＬ（Ｂ）」が動作する。そして、このシステム構成「Ｋ００１」は、いずれの障害情報とも一致しないことを示す。
【００３２】
構成ＤＢ１７は、顧客ごとに、顧客が使用するシステムの構成情報を記憶するデータベースである。図７は、構成ＤＢ１７に記憶される情報の例を示す図である。図７に示すように、構成ＤＢ１７は、「顧客ＩＤ、構成ＩＤ、ハード名、ＯＳ、ＭＷ、アプリ、障害ＩＤ」を対応付けて記憶する。ここで記憶される各情報は上述したので、詳細な説明は省略する。
【００３３】
図７の例では、顧客「Ｕ００１」は、「Ｋ００１」、「Ｋ００２」、「Ｋ００３」の３つのシステム構成を有する。このシステム構成のうち、システム構成「Ｋ００１」は、「ＸＸＸ」のハードウェア、「Ｗ２０１２」のＯＳ、「ＩＡＳ  Ｖ９．２．０」のミドルウェアで構成される。また、このシステム構成「Ｋ００１」では、アプリケーションとして「ＡＰＬ（Ａ）」が動作する。そして、このシステム構成「Ｋ００１」は、「Ｓ００１」の障害情報と一致したことを示す。
【００３４】
制御部２０は、コントロールサーバ１０全体を司る処理部であり、例えばプロセッサなどである。制御部２０は、更新部２１、条件判定部２２、通知部２３を有する。なお、更新部２１、条件判定部２２、通知部２３は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例などである。
【００３５】
更新部２１は、障害情報にしたがって障害マスタＤＢ１３を更新する処理部である。具体的には、更新部２１は、管理者端末やベンダー各社から、障害が発生する可能性があるシステム構成の情報や障害の優先度などを含む障害情報を取得し、障害マスタＤＢ１３に格納する。そして、更新部２１は、障害マスタＤＢ１３を更新したことを、条件判定部２２に通知する。
【００３６】
例えば、更新部２１は、取得した障害情報から、障害の危険があるシステム構成と、障害の危険度等を示す優先度、対策障害など抽出する。そして、更新部２１は、新たな障害ＩＤを付与した新たなレコードを障害マスタＤＢ１３に生成し、当該レコードの「該当条件に」に当該抽出したシステム構成を格納し、「優先度」に当該抽出した優先度を格納し、「対策情報」に当該抽出した対策情報を格納する。
【００３７】
また、更新部２１は、各ＤＣからの通知によって構成ＤＢ１７を更新する処理部である。具体的には、更新部２１は、データセンタＡから顧客ＩＤ「Ｕ００１」の構成ＩＤ「Ｋ００１」の新たな構成情報を受信した場合、当該受信した情報で構成ＤＢ１７および条件マスタＤＢ１６を更新する。そして、更新部２１は、構成ＤＢ１７および条件マスタＤＢ１６が更新されたことを条件判定部２２に通知する。
【００３８】
条件判定部２２は、障害が発生する条件を満たすシステムの構成情報を有するデータセンタを特定する処理部である。具体的には、条件判定部２２は、更新部２１によって障害マスタＤＢ１３が更新されると、更新された該当条件を障害マスタＤＢ１３から読み出す。そして、条件判定部２２は、読み出した該当条件と、条件マスタＤＢ１６に記憶される各レコードとを比較し、条件マスタＤＢ１６の一致フラグを設定する。
【００３９】
例えば、条件判定部２２は、障害の該当条件を満たす構成ＩＤを検出し、当該構成ＩＤの「一致フラグ」が既に「ＴＲＵＥ」であった場合、当該該当条件の障害ＩＤを新たに追加する。また、条件判定部２２は、障害の該当条件を満たす構成ＩＤを検出し、当該構成ＩＤの「一致フラグ」が「ＦＡＬＳＥ」であった場合、「一致フラグ」を「ＴＲＵＥ」に書き換えるとともに、当該該当条件の障害ＩＤを新たに追加する。
【００４０】
ここで、条件判定部２２は、予め設定した条件にしたがって、該当条件を満たすか否かを判定する。例を挙げると、条件判定部２２は、該当条件に含まれるハード名、ＯＳ、ＭＷ、アプリのすべてが一致する構成ＩＤを、該当条件を満たすシステム構成と判定することができる。また、条件判定部２２は、該当条件に含まれるハード名、ＯＳ、ＭＷ、アプリのうち、予め指定した組が一致する構成ＩＤを、該当条件を満たすシステム構成と判定することができる。
【００４１】
また、条件判定部２２は、該当条件の優先度に応じて、判定する項目の数等を動的に変更することもできる。例えば、条件判定部２２は、優先度が最も緊急を要する「影響が大きい」である場合、ハード名、ＯＳ、ＭＷ、アプリのいずれかが一致する場合に、該当条件を満たすと判定する。これは、障害による影響を最小限に抑えるためである。また、条件判定部２２は、最も低い優先度である場合、ハード名、ＯＳ、ＭＷ、アプリのすべてが一致する場合に、該当条件を満たすと判定する。これは、影響度の小さい障害情報を通知することで、システム構成の変更や障害対策などの不用意な作業を抑制するためである。
【００４２】
また、条件判定部２２は、更新部２１によって構成ＤＢ１７および条件マスタＤＢ１６が更新されると、障害マスタＤＢ１３に記憶される各該当条件と、条件マスタＤＢ１６に記憶される各レコードとを比較し、条件マスタＤＢ１６の一致フラグを設定することもできる。このとき、条件判定部２２は、変更された構成ＩＤについてだけ判定することもできる。
【００４３】
通知部２３は、条件判定部２２によって障害が発生する条件を満たすと特定されたデータセンタに、障害に関する障害情報を送信する処理部である。具体的には、通知部２３は、条件マスタＤＢ１６を監視し、一致フラグが「ＴＲＵＥ」に更新された構成ＩＤや障害ＩＤが追加された構成ＩＤを検出する。そして、通知部２３は、検出した構成ＩＤをキーにして構成ＤＢ１７を検索し、該当する構成ＩＤの障害ＩＤに、新たな障害情報の障害ＩＤを通知する。
【００４４】
さらに、通知部２３は、構成ＤＢ１７から特定した構成ＩＤに対応付けられる顧客ＩＤを特定し、当該顧客ＩＤをキーにして顧客マスタＤＢ１４を検索し、該当するＤＣＩＤを特定する。そして、通知部２３は、特定したＤＣＩＤの管理サーバ５０に、該当障害ＩＤに対応する障害情報を障害マスタＤＢ１３から抽出して送信する。このとき、通知部２３は、契約条件が「サポートデスクあり」の顧客については顧客の通知先に障害情報を送信し、契約条件が「サポートデスクなし」の顧客については顧客の通知先への障害情報の送信を抑制することもできる。
【００４５】
なお、各管理サーバの通知先として予め設定されたメールアドレスや機器アドレス（ＩＰ（Internet  Protocol）アドレスやＭａｃ（Media  Access  Control）アドレスなど）などは、予め記憶されているものとする。また、顧客の通知先として、予め設定されたメールアドレスや機器アドレスなども、予め記憶されているものとする。そして、各管理サーバの機器アドレスの場合は、管理サーバ経由で管理者の通知先（予め設定されたメールアドレスや機器アドレスなど）に通知してもよい。また、機器アドレスの場合は、機器の表示装置に障害内容を表示させるようなコマンドを含めた障害情報を送信してもよい。
【００４６】
一例として、障害ＩＤ「Ｓ００２」によって、構成ＩＤ「Ｋ００２」の「一致フラグ」が「ＦＬＡＳＥ」から「ＴＲＵＥ」に変更された例で説明する。つまり、「Ｋ００２」のシステム構成が障害ＩＤ「Ｓ００２」の該当条件を満たすと判定されたものとする。
【００４７】
この場合、通知部２３は、構成ＤＢ１７における構成ＩＤ「Ｋ００２」の障害ＩＤに「Ｓ００２」を追加する。続いて、通知部２３は、構成ＤＢ１７を参照して、構成ＩＤ「Ｋ００２」に対応する顧客ＩＤ「Ｕ００１」を特定する。その後、通知部２３は、顧客マスタＤＢ１４を参照し、顧客ＩＤ「Ｕ００１」の契約条件が「サポートデスクあり」であることから、障害情報の通知を行うと決定する。
【００４８】
そして、通知部２３は、顧客マスタＤＢ１４を参照し、顧客ＩＤ「Ｕ００１」のＤＣＩＤ「Ｄ００１」を特定する。さらに、通知部２３は、障害ＩＤ「Ｓ００２」に対応する「該当条件、優先度、対策情報」を障害マスタＤＢ１３から抽出する。その後、通知部２３は、ＤＣＩＤ「Ｄ００１」の管理サーバ５０に、抽出した「該当条件、優先度、対策情報」を障害情報として送信する。
【００４９】
（管理サーバ５０の構成）
図２に示すように、管理サーバ５０は、通信部５１、記憶部５２、制御部６０を有する。通信部５１は、有線や無線を問わず、他の装置との通信を制御する通信インタフェースである。例えば、通信部５１は、コントロールサーバ１０から障害情報を受信し、コントロールサーバ１０に構成情報を送信する。
【００５０】
記憶部５２は、制御部６０が実行するプログラムやデータを記憶するデータベースであり、例えばハードディスクやメモリなどである。この記憶部５２は、障害マスタＤＢ５３、構成ＤＢ５４を記憶する。
【００５１】
障害マスタＤＢ５３は、障害の発生条件や障害の優先度などを含む障害情報を記憶するデータベースである。なお、障害マスタＤＢ５３が記憶する情報は、障害マスタＤＢ１３が記憶する情報と同じなので、詳細な説明は省略する。
【００５２】
構成ＤＢ５４は、管理サーバ５０が設置されるＤＣを利用する顧客ごとに、顧客が使用するシステムの構成情報を記憶するデータベースである。なお、構成ＤＢ５４が記憶する情報は、構成ＤＢ１７が記憶する情報と同じなので、詳細な説明は省略する。
【００５３】
制御部６０は、管理サーバ５０全体を司る処理部であり、例えばプロセッサなどである。制御部６０は、構成更新部６１、通知部６２、障害更新部６３を有する。なお、構成更新部６１、通知部６２、障害更新部６３は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例などである。
【００５４】
構成更新部６１は、構成ＤＢ５４を更新する処理部である。具体的には、構成更新部６１は、ＳＷやＭＷなどが新たにインストールされた場合、ＳＷやＭＷなどが削除された場合、ＳＷやＭＷなどに更新パッチが適用された場合、該当する構成情報を更新する。そして、構成更新部６１は、構成情報を更新したことを通知部６２に通知する。
【００５５】
通知部６２は、更新された構成情報をコントロールサーバ１０に送信する処理部である。具体的には、通知部６２は、構成更新部６１から構成ＩＤ「Ｋ００１」が更新されたことが通知されると、構成ＤＢ５４から構成ＩＤ「Ｋ００１」の構成情報を読み出して、コントロールサーバ１０に送信する。また、通知部６２は、構成更新部６１から構成ＩＤ「Ｋ０１１」の構成情報が新たに追加されたことが通知されると、構成ＤＢ５４から構成ＩＤ「Ｋ０１１」の構成情報を読み出して、コントロールサーバ１０に送信する。
【００５６】
障害更新部６３は、コントロールサーバ１０から受信した障害情報にしたがって、障害マスタＤＢ５３を更新する処理部である。例えば、障害更新部６３は、コントロールサーバ１０から、障害ＩＤ「Ｓ００５」の障害情報（該当条件、優先度、対策情報）を受信すると、受信した障害情報を障害マスタＤＢ５３に追加する。
【００５７】
また、障害更新部６３は、管理者等から、障害ＩＤ「Ｓ００６」の障害情報（該当条件、優先度、対策情報）の入力を受け付けると、受け付けた障害情報を障害マスタＤＢ５３に追加する。そして、障害更新部６３は、追加した障害情報をコントロールサーバ１０に送信し、障害情報の一致判定の実行を要求する。
【００５８】
また、障害更新部６３は、新たな障害情報を障害マスタＤＢ５３に追加した場合、管理者や顧客等の通知先に障害通知を送信することもできる。図８は、通知例を説明する図である。障害更新部６３は、例えば図８に示す障害通知を送信したり、ディスプレイ等に表示させたりする。障害通知は、図８に示すように、障害情報が追加された日を示す「発行日」、障害情報の該当条件に該当する「対象機種、対象製品、対象ＭＷ」、対策情報などが記載される「連絡内容」などを含む。なお、障害通知に含まれる内容は、適宜変更することができる。
【００５９】
［障害更新時の処理の流れ］
図９は、障害更新時の処理の流れを示すフローチャートである。図９に示すように、コントロールセンタ１のコントロールサーバ１０の更新部２１は、障害情報を受信すると（Ｓ１０１：Ｙｅｓ）、障害マスタＤＢ１３を更新する（Ｓ１０２）。
【００６０】
続いて、条件判定部２２は、障害マスタＤＢ１３から該当条件を読出し（Ｓ１０３）、該当条件に基づいて、条件マスタＤＢ１６の一致フラグを判定する（Ｓ１０４）。そして、該当条件に一致するシステム構成が検出された場合（Ｓ１０５：Ｙｅｓ）、通知部２３は、各ＤＢを参照して、一致するシステム構成を有するＤＣを特定し（Ｓ１０６）、特定したＤＣに、該当する障害情報を通知する（Ｓ１０７）。なお、Ｓ１０３からＳ１０７までの処理は、障害マスタＤＢ１３に記憶される各該当条件、条件マスタＤＢ１６に記憶される各構成について実行される。
【００６１】
そして、各ＤＣの管理サーバ５０の障害更新部６３は、コントロールサーバ１０から障害情報を受信すると（Ｓ１０８）、障害マスタＤＢ５３を更新する（Ｓ１０９）。その後、障害更新部６３は、障害情報を顧客などの通知先へ通知する（Ｓ１１０）。
【００６２】
［構成更新時の処理の流れ］
図１０は、構成更新時の処理の流れを示すフローチャートである。図１０に示すように、各ＤＢの管理サーバ５０の構成更新部６１は、構成ＤＢ５４に記憶される構成情報を更新すると（Ｓ２０１：Ｙｅｓ）、更新した構成情報である構成情報をコントロールサーバ１０に送信する（Ｓ２０２）。
【００６３】
更新情報を受信したコントロールサーバ１０の更新部２１は、受信した更新情報を用いて構成ＤＢ１７を更新する（Ｓ２０３）。また、更新部２１は、構成ＤＢ１７の更新に伴って、条件マスタＤＢ１６を更新する（Ｓ２０４）。その後、条件判定部２２は、更新されたシステム構成と、障害マスタＤＢ１３とを比較して、障害情報の該当条件に一致するかを判定する（Ｓ２０５）。そして、通知部２３は、該当する障害情報が検出された場合（Ｓ２０６：Ｙｅｓ）、送信元のＤＣに対して、該当する障害情報を送信する（Ｓ２０７）。このとき、条件マスタＤＢ１６や構成ＤＢ１７も更新される。
【００６４】
そして、各ＤＣの管理サーバ５０の障害更新部６３は、コントロールサーバ１０から障害情報を受信すると（Ｓ２０８）、障害マスタＤＢ５３を更新する（Ｓ２０９）。その後、障害更新部６３は、障害情報を顧客などの通知先へ通知する（Ｓ２１０）。
【００６５】
［効果］
上述したように、コントロールサーバ１０は、障害や障害の予兆が検出されたシステムの条件を一括で管理し、該当するシステムを有するＤＣに通知する。このようにすることで、各ＤＣの担当エンジニアによる障害検出に関する負荷を軽減できる。したがって、障害情報の集中管理を実現し、ＤＣ間における障害情報の確認頻度や網羅性を均一化できるので、障害見落としなどの人為的なミスを削減し、システムの信頼性を向上させることができる。
【実施例２】
【００６６】
ところで、実施例１では、ＤＣの設置地域等に関係なく、障害情報を通知する例を説明したが、これに限定されるものではない。例えば、管理サーバ２０は、条約等による輸出規制などを考慮することもできる。そこで、実施例２では、障害情報の通知制御について説明する。
【００６７】
図１１は、障害情報の通知判定処理の流れを示すフローチャートである。なお、障害判定については実施例１と同様なので、説明を省略する。図１１に示すように、コントロールサーバ１０の通知部２３は、障害情報の通知が発生すると（Ｓ３０１：Ｙｅｓ）、通知先のＤＢについてサポートデスク契約が締結されているかを判定する。つまり、通知部２３は、顧客マスタＤＢ１４を参照して、該当顧客の契約条件に「サポートデスクあり」が設定されているかを判定する。
【００６８】
そして、通知部２３は、サポートデスク契約がある場合（Ｓ３０２：Ｙｅｓ）、センタマスタＤＢ１５等を参照して、通知先ＤＣが属する国を特定する（Ｓ３０３）。続いて、通知部２３は、予め記憶部１２等に記憶させた条約情報や輸出規制を参照して、コントロールセンタ１から当該特定した国への輸出規制に該当するかを判定する（Ｓ３０４）。
【００６９】
ここで、通知部２３は、輸出規制に該当しない場合（Ｓ３０４：Ｎｏ）、障害情報をそのまま、該当するＤＣの管理サーバ５０に送信する（Ｓ３０５）。一方、通知部２３は、輸出規制に該当する場合（Ｓ３０４：Ｙｅｓ）、輸出規制等の内容を特定し（Ｓ３０６）、特定した規制内容に応じた通知を実行する（Ｓ３０７）。
【００７０】
例えば、通知部２３は、一切の輸出が規制されている場合は、障害が確認されたことだけを通知し、詳細な情報は通知しない。また、通知部２３は、危険物などの一部の輸出が規制されている場合は、ウイルス作成などに利用できるような具体的なシステム構成やセキュリティホールなどの情報を除いて、通知する。
【００７１】
また、通知部２３は、該当ＤＣに複数の通知先が設定されている場合は、輸出規制に該当しない国にいる管理者に対応付けられた通知先にだけに送信する。また、通知部２３は、該当ＤＣに複数の通知先が設定されている場合は、輸出規制に該当するＤＣの管理サーバ５０には障害の有無だけを通知する一方で、当該ＤＣを利用する顧客（利用者）のうち輸出規制に該当しない国にいる顧客（利用者）に対応付けられた通知先にだけ障害情報を通知することもできる。
【００７２】
なお、ここではＤＣが設置される国を例にして説明したが、これに限定されるものではなく、例えば地域、経済特区、各種特区についても、これらに設定される規制や条件等に応じて、通知情報の制御を実行することができる。
【００７３】
このように、コントロールサーバ１０は、世界に設置されるＤＣを一括で管理する場合であっても、条約などの法規制に沿った運用を実現できるとともに、システムの信頼性を向上させることができる。
【実施例３】
【００７４】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
【００７５】
［更新契機］
実施例１では、コントロールサーバ１０が障害情報を更新した場合と管理サーバ５０が構成情報を更新した場合の例を説明したが、これに限定されるものではない。例えば、コントロールサーバ１０が構成情報を更新した場合も、実施例１と同様に処理することができる。また、管理サーバ５０が障害情報を更新した場合も、管理サーバ５０が更新した障害情報をコントロールサーバ１０に通知することで、実施例１と同様に処理することができる。
【００７６】
［システム］
また、図示した装置の各構成は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、任意の単位で分散または統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ等のプロセッサおよび当該プロセッサにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【００７７】
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【００７８】
［ハードウェア］
図１２は、ハードウェア構成例を示す図である。ここではコントロールサーバ１０を例にして説明するが、管理サーバ５０についても同様である。図１２に示すように、コントロールサーバ１０は、通信インタフェース１０ａ、ＨＤＤ（Hard  Disk  Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。また、図１２に示した各部は、バス等で相互に接続される。
【００７９】
通信インタフェース１０ａは、他の装置との通信を制御するインタフェースであり、例えばネットワークインタフェースカードである。ＨＤＤ１０ｂは、図１等に示した機能を動作させるプログラムやＤＢなどを記憶する。
【００８０】
プロセッサ１０ｄは、図２等に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１０ｂ等から読み出してメモリ１０ｃに展開することで、図２等で説明した各機能を実行するプロセスを動作させる。
【００８１】
すなわち、このプロセスは、コントロールサーバ１０が有する各処理部と同様の機能を実行する。具体的には、プロセッサ１０ｄは、更新部２１、条件判定部２２、通知部２３と同様の機能を有するプログラムをＨＤＤ１０ｂ等から読み出す。そして、プロセッサ１０ｄは、更新部２１、条件判定部２２、通知部２３と同様の処理を実行するプロセスを実行する。
【００８２】
このようにコントロールサーバ１０は、プログラムを読み出して実行することで管理方法を実行する情報処理装置として動作する。また、コントロールサーバ１０は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コントロールサーバ１０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【符号の説明】
【００８３】
１０  コントロールサーバ
１１  通信部
１２  記憶部
１３  障害マスタＤＢ
１４  顧客マスタＤＢ
１５  センタマスタＤＢ
１６  条件マスタＤＢ
１７  構成ＤＢ
２０  制御部
２１  更新部
２２  条件判定部
２３  通知部
５０  管理サーバ
５１  通信部
５２  記憶部
５３  障害マスタＤＢ
５４  構成ＤＢ
６０  制御部
６１  構成更新部
６２  通知部
６３  障害更新部
【図１】
2017058789.tif 000003
【図２】
2017058789.tif 000004
【図３】
2017058789.tif 000005
【図４】
2017058789.tif 000006
【図５】
2017058789.tif 000007
【図６】
2017058789.tif 000008
【図７】
2017058789.tif 000009
【図８】
2017058789.tif 000010
【図９】
2017058789.tif 000011
【図１０】
2017058789.tif 000012
【図１１】
2017058789.tif 000013
【図１２】
2017058789.tif 000014