JP5327220B2 - 管理プログラム、管理装置および管理方法 - Google Patents

Description

本発明は、装置構成情報において、ユーザの追加又はユーザの運用方針の変更及び削除を容易にするとともに、装置構成情報管理のセキュリティ及びスケーラビリティの確保を実現する装置構成情報管理プログラム、装置構成情報管理装置及び装置構成情報管理方法に関する。

近年、ＳａａＳ（Software as a Service）と呼ばれる技術が普及しつつある。ＳａａＳとは、ユーザが、必要とする機能及びプログラムの提供を選択的に受けるサービスをいう。ＳａａＳでは、例えば、外部記憶領域提供やコンテンツ配信や音声通話等のサービスの様に、ユーザ（以下、テナントと呼ぶ）が利用したい機能及びプログラムを、必要時に、ネットワーク経由でサービスプロバイダから入手して利用するものである。

ＳａａＳは、インターネット・データ・センタ（以下、ＩＤＣと略記する）を基盤として提供されるサービスである。また、ＳａａＳは、ＩＤＣにおいて、サーバやデータベース等の物理構成を複数のテナントで共有し、物理構成をテナント毎に論理的に分割した論理構成を以って個別に使用できるマルチテナントが可能な技術である。なお、以下では、物理構成を規定する情報を物理装置構成情報と呼び、論理構成を規定する情報を論理装置構成情報と呼ぶこととする。

マルチテナントのシステム運用管理では、ＩＴＩＬ（登録商標、Information Technology Infrastructure Library）と呼ばれる、成功事例のノウハウを蓄積した文書に規定される、システムの装置構成情報（ＣＩ、Configuration Item）を管理するための標準規格であるＣＭＤＢ（Configuration Management Database）の技術を利用する。ＣＭＤＢとは、装置構成情報データベースのことである。

ＣＭＤＢは、コンピュータ・システムの装置構成情報（物理装置構成情報及び論理装置構成情報）を管理するために、コンピュータ・システムの装置構成情報及び装置構成情報間の関係を管理するデータベースとして、装置構成情報データベースが構築されることになる。

コンピュータ・システムの装置構成には、各種ハードウェアはいうまでもなく、ソフトウェア、各種データなど、多種多様な要素が含まれる。装置構成情報データベースの実装は、ＭＤＲ（Management Data Repository）と呼ばれる。以下、ＭＤＲの物理的実装を物理ＭＤＲと呼び、物理ＭＤＲを論理的に分割又は併合した論理的実装を論理ＭＤＲと呼ぶこととする。

そして、複数の物理ＭＤＲ及び論理ＭＤＲを仮想的に統合する上位階層に位置する装置構成情報データベースは、ＦＣＭＤＢ（Federated ＣＭＤＢ）と呼ばれる。ＦＣＭＤＢによって、配下の複数の物理ＭＤＲ及び論理ＭＤＲが、仮想的に統合管理されることとなる。

特開２００３−３１６５２２号公報

しかしながら、上記従来技術では、テナント数やサービス数の増大とともに、ＩＤＣの物理装置構成情報及び論理装置構成情報の関係が複雑化してきている現状では、テナント追加やテナント毎の運用条件の変更等によって既存の論理装置構成情報を変更する必要が発生した場合に、次の問題点があった。

すなわち、あるテナントに関して論理装置構成情報を変更すると、物理ＭＤＲを共有する他のテナントに影響を及ぼす可能性があることから、他のテナントに影響を与えない様に、慎重に論理装置構成情報を変更する必要がある。

しかし、物理装置構成情報及び論理装置構成情報の関係が複雑化してきている現状では、他のテナントに与える影響を見積もることが難しく、論理装置構成情報の変更を困難にしていた。

本発明は、上記問題点（課題）を解消するためになされたものであって、他のテナントに影響を与えることなく、サーバやデータベース等の論理装置構成情報を容易に変更することを可能とする装置構成情報管理プログラム、装置構成情報管理装置及び装置構成情報管理方法を提供することを目的とする。

上述した問題を解決し、目的を達成するため、装置構成情報管理プログラム、装置構成情報管理装置及び装置構成情報管理方法の一観点において、ユーザ毎の運用対象装置の運用方針を含む装置構成情報を管理する論理的装置構成情報データベースと、論理的装置構成情報データベースの物理的実装である物理的装置構成情報データベースとの対応関係を管理する論理物理構成データベースから、運用方針の変更を行うユーザの該当運用方針の入力を受け付け、受け付けられた該当ユーザの運用方針を変更する変更方針を生成し、生成された該当ユーザの変更方針が、他のユーザの運用方針へ与える影響を評価することによって、該当変更方針の実行の可否を判定するとともに、他のユーザの運用方針へ与える影響を出力することを要件とする。

開示の装置構成情報管理プログラム、装置構成情報管理装置及び装置構成情報管理方法によれば、装置構成情報において、ユーザの追加又はユーザの運用方針の変更及び削除を容易にするとともに、装置構成情報管理のセキュリティ及びスケーラビリティの確保を実現することが可能になるという効果を奏する。

図１は、実施形態の一例に係る装置構成情報分散管理システムの概要を説明するための図である。 図２は、第一実施形態の一例に係る装置構成情報管理装置を含む装置構成情報管理システムの構成を示すブロック図である。 図３は、運用ポリシーの一例を示す図である。 図４は、変更ポリシーの一例を示す図である。 図５は、第一実施形態の一例に係る装置構成情報管理装置の処理概要を説明するための図である。 図６は、変更ポリシーに応じて生成される実行フローの一例を示す図である。 図７は、第一実施形態の一例に係る装置構成情報管理処理手順を示すフローチャートである。 図８は、第二実施形態の一例に係る装置構成情報管理装置を含む装置構成情報管理システムの構成を示すブロック図である。 図９は、第二実施形態の一例に係る装置構成情報管理装置によって解決される問題点を説明するための図である。 図１０は、第二実施形態の一例に係る装置構成情報管理処理手順を示すフローチャートである。

以下に添付図面を参照し、本発明の装置構成情報管理プログラム、装置構成情報管理装置及び装置構成情報管理方法に係る実施形態の一例を詳細に説明する。なお、以下に開示する実施形態の一例では、図１に示す様に、マルチテナントで運用を行うＩＤＣにおいて、複数の物理ＭＤＲを物理的に統合管理する物理ＦＣＭＤＢと、テナント毎の論理ＭＤＲと、物理ＦＣＭＤＢ及び論理ＭＤＲを統合管理する上位階層の論理物理ＦＣＭＤＢとを有する、装置構成情報の階層的な分散管理システムを前提とする。

そして、論理物理ＦＣＭＤＢと、物理ＦＣＭＤＢ及び論理ＭＤＲの間に、テナントの追加、運用方針の変更等を動的に管理し実行する動的テナント管理装置が配置される。動的テナント管理装置は、物理ＭＤＲを共有する論理ＭＤＲにおけるテナントの追加、運用方針の変更等の論理装置構成情報の変更の実行に際して、論理装置構成情報の変更リスクを評価して変更の可否を判定する。

動的テナント管理装置は、例えば、あるテナントの論理装置構成情報を変更する際に、他のテナントの装置運用に影響を与えることを“変更リスク”と定義する場合に、“変更リスクなし”と判定した場合に、変更に該当するテナントの論理装置構成情報の変更フローを生成して出力する。

［第一実施形態の一例］
図２〜図７を参照して、第一実施形態の一例に係る装置構成情報管理装置を含む装置構成情報管理システムについて説明する。図２は、第一実施形態の一例に係る装置構成情報管理装置を含む装置構成情報管理システムの構成を示すブロック図である。

図２に示す様に、装置構成情報管理システムＳ１は、動的テナント管理装置１００ａと、論理物理ＦＣＭＤＢ２００と、変更フロー実行装置３００と、物理ＭＤＲ４００と、論理ＭＤＲ５００と、実行済み変更フロー管理装置６００を有する。

動的テナント管理装置１００ａは、運用ポリシー入力受付部１０１と、変更ポリシー生成部１０２と、変更ポリシー管理部１０３と、ＳＬＡ（Service Level Agreement）判定部１０４ａと、リスク評価結果出力部１０５と、変更フロー生成部１０６とを有する。

運用ポリシー入力受付部１０１は、論理ＭＤＲ５００によって管理される、変更対象であるテナントの運用ポリシー及び変更ポリシーの入力を受け付ける。入力された運用ポリシー及び変更ポリシーは、変更ポリシー生成部１０２へと受け渡される。

なお、運用ポリシーの一例は、図３に示す通りである。運用ポリシーは、少なくとも次の情報を含む。
（１）テナントを識別するためのテナントＩＤ
（２）該当テナントがＩＤＣにおいて割り当てられている割り当てリソース（コンピュータの各種ハードウェア、記憶装置、通信装置、各種ソフトウェア、各種データ等を含む）の利用開始日時
（３）割り当てリソースの運用条件（さらに運用条件は、サービスの提供時間帯、稼働率、・・・、割り当てリソースの共有条件等を含む）
（４）該当テナントが割り当てリソースを使用して提供するサービス（各サービスには、サービス名、サービスの種別情報及び運用条件が対応付けられている）

変更ポリシー生成部１０２は、運用ポリシー入力受付部１０１から受け渡された運用ポリシー及び変更ポリシーに基づき、変更対象の運用ポリシーの一部又は全部を変更する変更ポリシーを生成し、変更ポリシー管理部１０３及びリスク評価結果出力部１０５へと受け渡す。変更ポリシー管理部１０３は、変更ポリシー生成部１０２によって生成された変更ポリシーを一時管理する管理部である。なお、変更ポリシーの一例は、図４に示す通りである。

図４に示す変更ポリシーは、図３に示す運用ポリシーをベースに、リソースを追加したものとなっている。具体的には、リソース１〜リソースＮが追加されている。例えば、リソース１は、容量と装置ＩＤを指定されたハードディスク、型番と装置ＩＤを指定されたＣＰＵ（Central Processing Unit）、容量と装置ＩＤを指定されたメモリ、伝送速度と装置ＩＤを指定されたネットワーク装置である。これら追加されたリソースは、サービス１〜サービスＮそれぞれで使用するリソースとして規定されることとなる。

ＳＬＡ判定部１０４ａは、変更ポリシー管理部１０３で管理される変更ポリシーを取り出して、変更ポリシーによる論理装置構成情報の変更が、テナントと取り交わしたＳＬＡが充足されるか否かを判定する。なお、変更ポリシー管理部１０３で管理される変更ポリシーが複数ある場合は、全てについてＳＬＡが充足されるか否かを判定する。

ＳＬＡが、例えば、「運用ポリシーに規定するサービス提供時間を厳守すること」である場合には、論理装置構成情報の変更によって、該当するＳＬＡを取り交わした他のテナントのリソース運用に影響を与えて、該当サービス提供時間中にリソース運用を停止させてしまうと、ＳＬＡが充足されなくなる。

ＳＬＡ判定部１０４ａは、例えば、図５に示す様に、（１）各テナントの運用ポリシーと、運用ポリシー変更対象のテナントの変更ポリシーの中で、変更するリソース及び／又はサービスに関して、変更操作が競合する運用条件を抽出する。

（２）そして、ＳＬＡ判定部１０４ａは、運用条件の適合性をチェックする。ここでチェック対象となる運用条件の項目は、例えば、サービス提供時間帯及びリソース共有条件である。

図５の例では、運用条件１は、サービス提供時間帯が８：００〜２２：００であり、運用条件Ｘは、サービス提供時間帯が６：００〜２２：００である。従って、論理装置構成情報の変更作業が可能である時間は、２２：００〜翌６：００であると判定される。

しかし、図５において、運用条件１と運用条件Ｘとの間で、共有条件に差異がある。（３）この共有条件の差異が、論理装置構成情報の変更作業に差し支えないものとされる場合には、リソース１の論理装置構成情報変更の操作可能時間を２２：００〜翌６：００として、“論理装置構成情報の変更リスクなし”と判定することとなる。

なお、図５における、運用条件１と運用条件Ｘとの間の共有条件の差異が、論理装置構成情報の変更作業に差し支えがあり、他のテナントのリソース運用に影響を与えるとされる場合には、“論理装置構成情報の変更リスクあり”と判定することとなる。

なお、ＳＬＡは、上記したものに限定されるものではなく、例えば、「稼働率がある一定値以上であること」であるとしてもよい。この場合には、ＳＬＡ判定部１０４ａは、論理装置構成情報の変更によって、該当するＳＬＡを取り交わした他のテナントのリソース運用に影響を与えてリソース運用を停止させてしまい、稼働率が低下して、ＳＬＡが充足されなくなるおそれがあるか否かを判定することとなる。

ＳＬＡ判定部１０４ａは、論理装置構成情報の変更リスクの評価結果をリスク評価結果出力部１０５へと受け渡す。リスク評価結果出力部１０５は、変更ポリシー生成部１０２から受け渡された該当する変更ポリシーとともに、ＳＬＡ判定部１０４ａから受け渡された論理装置構成情報の変更リスクの評価結果を表示出力又は印刷出力する。

また、ＳＬＡ判定部１０４ａは、“論理装置構成情報の変更リスクなし”と判定した場合に、変更フロー生成部１０６に対して、変更対象のテナントの変更ポリシーに基づいて導出された論理装置構成情報変更の操作可能時間等の操作可能条件を受け渡す。変更フロー生成部１０６は、変更対象のテナントを特定して、操作可能条件を考慮した論理装置構成情報の変更フローを生成する。

なお、変更フローを生成する際に、論理装置構成情報変更の操作可能時間等の操作可能条件を考慮することによって、他のテナントのサービス運用に影響を与えることを回避することができることから、動的テナント管理装置１００ａは、動的に論理装置構成情報を変更することが可能であるものであるといい得る。

なお、変更フローの一例は、図６に示す通りである。変更フローは、例えば、実行日時、論理装置構成情報の変更対象テナント及び論理装置構成情報の変更対象サービスを特定して、装置構成情報の変更処理（リソース追加処理）を手順化したものである。

論理物理ＦＣＭＤＢ２００は、物理ＭＤＲ４００及び論理ＭＤＲ５００を仮想的に統合し、テナント、サービス、論理ＭＤＲ及び物理ＭＤＲ間の関係を管理する論理物理構成ＤＢ２００ａを有する。動的テナント管理装置１００ａは、論理物理ＦＣＭＤＢ２００を介して、物理ＭＤＲ４００及び論理ＭＤＲ５００から各種情報を取得する。

変更フロー生成部１０６によって生成された変更フローは、変更フロー実行装置３００へと出力される。変更フロー実行装置３００は、入力された変更フローに従って、物理ＭＤＲ４００及び論理ＭＤＲ５００に対して、該当するテナントの装置構成情報の変更処理（リソース追加処理）を実施する。そして、変更フロー実行装置３００によって実行された変更フローは、実行済み変更フロー管理装置６００に格納されることとなる。

物理ＭＤＲ４００は、物理ＦＣＭＤＢ４０１によって、複数の物理ＭＤＲａ４０２ａ、・・・、物理ＭＤＲｘ４０２ｘが物理的に統合管理される構成である。変更フロー実行装置３００による変更フローは、物理ＦＣＭＤＢ４０１を介して、物理ＭＤＲａ４００ａ、・・・、物理ＭＤＲｘ４０２ｘに対して実施される。

また、論理ＭＤＲ５００は、テナント毎に、物理ＭＤＲａ４００ａ、・・・、物理ＭＤＲｘ４０２ｘを論理的に分割又は併合したＭＤＲである。論理ＭＤＲ５００は、テナントａＭＤＲ５０１ａ、・・・、テナントｘＭＤＲ５０１ｘと、テナント毎に論理的に分割されている。このように、テナント毎に、物理ＭＤＲを論理的に分割することによって、リソース運用に関してセキュリティ及びスケーラビリティを確保することが可能になる。

なお、テナントａＭＤＲ５０１ａ、・・・、テナントｘＭＤＲ５０１ｘは、それぞれテナントａ運用ポリシー５０２ａ、・・・、テナントｘ運用ポリシー５０２ｘを含む。これらの運用ポリシーが、論理装置構成情報の変更時に、動的テナント管理装置１００ａの運用ポリシー入力受付部１０１へと入力されることとなる。

次に、第一実施形態の一例に係る装置構成情報管理処理について説明する。図７は、第一実施形態の一例に係る装置構成情報管理処理手順を示すフローチャートである。同図に示す様に、先ず、運用ポリシー入力受付部１０１は、変更ポリシーの入力を受け付ける（ステップＳ１０１）。

続いて、変更ポリシー生成部１０２は、サービスに必要となるリソースを割り当てた変更ポリシーを出力する（ステップＳ１０２）。続いて、ＳＬＡ判定部１０４ａは、リソースを共有するテナントの運用ポリシーを、論理物理ＦＣＭＤＢ２００を介して取得する（ステップＳ１０３）。

続いて、ＳＬＡ判定部１０４ａは、テナントの運用ポリシーと変更ポリシーとから、変更するリソース及びサービスそれぞれに対し、操作可能な時間帯を抽出する（ステップＳ１０４）。続いて、ＳＬＡ判定部１０４ａは、例えば、他のテナントの利用開始時刻と比較し、時間的に無理な変更の有無をリスクとして、リスク評価結果出力部１０５を介して出力する（ステップＳ１０５）。

続いて、ＳＬＡ判定部１０４ａは、リスクが存在するか否かを判定する。リスクが存在すると判定された場合に（ステップＳ１０６肯定）、装置構成情報管理処理は終了し、リスクが存在すると判定されなかった場合に（ステップＳ１０６否定）、変更フロー生成部１０６は、変更ポリシーを手順化した変更フローを生成する（ステップＳ１０７）。ステップＳ１０７が終了すると、第一実施形態の一例に係る装置構成情報管理処理は終了する。

以上の第一実施形態の一例に係る装置構成情報管理処理によれば、新たに変更対象となるテナントの変更ポリシーの変更リスクを評価するので、テナントの追加、リソースの追加又は変更を、変更リスクを回避しつつ、動的に行うことが可能になる。

［第二実施形態の一例］
次に、図８〜図１０を参照して、第一実施形態の一例に係る装置構成情報管理装置を含む装置構成情報管理システムについて説明する。なお、第二実施形態の一例では、第一実施形態の一例との差異についてのみ説明する。

図８は、第二実施形態の一例に係る装置構成情報管理装置を含む装置構成情報管理システムの構成を示すブロック図である。図８に示す様に、装置構成情報管理システムＳ２は、動的テナント管理装置１００ａに代えて動的テナント管理装置１００ｂを有する。動的テナント管理装置１００ｂは、動的テナント管理装置１００ａと比較して、ＳＬＡ判定部１０４ａに代えてＳＬＡ判定部１０４ｂを有し、さらに変更フロー管理部１０７を加えた構成となっている。

変更フロー管理部１０７は、変更フロー生成部１０６によって生成された変更フローを、実行前に一時的に管理する管理部である。ＳＬＡ判定部１０４ｂは、変更リスクを判定する際に、変更フロー管理部１０７に一時管理されている変更フローも考慮して、変更リスクを判定する。

例えば、図９に示す様に、テナントＴＴＴのための変更ポリシーのリソース１の操作可能時間である２２：００〜翌６：００は、変更フロー管理部１０７に管理されている変更フロー１０７ａ、・・・、変更フロー１０７ｘのうち、テナントＹＹＹのための変更フローである変更フロー１０７ａと、同一のリソース１の割り当てを異なる時間帯に行う処理のバイオレーション（背反）が存在することが分かる。

よって、変更フロー１０７ａの処理内容を考慮すると、テナントＴＴＴのための変更ポリシーから、リソース１の操作可能時間を２２：００〜翌６：００とすることができないことが分かる。

次に、第二実施形態の一例に係る装置構成情報管理処理について説明する。図１０は、第二実施形態の一例に係る装置構成情報管理処理手順を示すフローチャートである。同図に示す様に、先ず、先ず、運用ポリシー入力受付部１０１は、変更ポリシーの入力を受け付ける（ステップＳ２０１）。

続いて、変更ポリシー生成部１０２は、変更ポリシーの変更前／変更後のリソースより、変更となるリソースの確定を行う（ステップＳ２０２）。続いて、変更ポリシー生成部１０２は、運用ポリシーで定義された共有条件を検索し、変更に必要となるリソースの確定を行う（ステップＳ２０３）。

続いて、ＳＬＡ判定部１０４ｂは、リソースを共有するテナントの運用ポリシーを取得する（ステップＳ２０４）。続いて、ＳＬＡ判定部１０４ｂは、変更フロー管理部１０７から処理待ち変更フローを取得する（ステップＳ２０５）。続いて、ＳＬＡ判定部１０４ｂは、テナントの運用ポリシーと変更ポリシーと処理待ちフローとから、変更するリソース及び／又はサービスそれぞれに対し、変更操作可能な時間帯を抽出する（ステップＳ２０６）。

続いて、ＳＬＡ判定部１０４ｂは、例えば、他のテナントの利用開始時刻と比較し、時間的に無理な変更の有無をリスクとして、リスク評価結果出力部１０５を介して出力する（ステップＳ２０７）。

続いて、ＳＬＡ判定部１０４ｂは、リスクが存在するか否かを判定する。リスクが存在すると判定された場合に（ステップＳ２０８肯定）、ステップＳ２１０へ移り、リスクが存在すると判定されなかった場合に（ステップＳ２０８否定）、変更フロー生成部１０６は、変更ポリシーを手順化した変更フローを生成し、処理待ち変更フローとして変更フロー管理部１０７に格納する（ステップＳ２０９）。

続いて、変更フロー管理部１０７は、管理する処理待ち変更フローが実行時刻となったか否かを判定する（ステップＳ２１０）。管理する処理待ち変更フローが実行時刻となったと判定された場合に（ステップＳ２１０肯定）、変更フローを実行する様に、変更フロー実行装置３００へ、該当する変更フローを出力する（ステップＳ２１１）。ステップＳ２１１が終了すると、第二実施形態の一例に係る装置構成情報管理処理は終了する。

以上の第二実施形態の一例に係る装置構成情報管理処理によれば、処理待ち変更フローによる論理装置構成情報の変更も考慮して、新たに変更対象となるテナントの変更ポリシーの変更リスクを評価するので、テナントの追加、リソースの追加又は変更が頻繁である場合であっても、論理装置構成情報の変更の変更リスクを回避することが可能になる。

以上、本発明の実施形態の一例を説明したが、本発明は、これに限られるものではなく、請求の範囲に記載した技術的思想の範囲内で、更に種々の異なる実施形態で実施されてもよいものである。また、実施形態の一例に記載した効果は、これに限定されるものではない。

また、上記実施形態の一例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記実施形態の一例で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散又は統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散又は統合して構成することができる。

具体的には、上記第一実施形態の一例及び第二実施形態の一例では、動的テナント管理装置１００ａ及び動的テナント管理装置１００ｂは、論理物理ＦＣＭＤＢと別装置としたが、これに限定されず、同一装置に実装されてもよい。

さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ（Central Processing Unit）（またはＭＰＵ（Micro Processing Unit）、ＭＣＵ（Micro Controller Unit）などのマイクロ・コンピュータ）および当該ＣＰＵ（またはＭＰＵ、ＭＣＵなどのマイクロ・コンピュータ）にて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現されてもよい。

１００ａ、１００ｂ 動的テナント管理装置
１０１ 運用ポリシー入力受付部
１０２ 変更ポリシー生成部
１０３ 変更ポリシー管理部
１０４ａ、１０４ｂ ＳＬＡ判定部
１０５ リスク評価結果出力部
１０６ 変更フロー生成部
１０７ 変更フロー管理部
１０７ａ、・・・、１０７ｘ 変更フロー
２００ 論理物理ＦＣＭＤＢ
２００ａ 論理物理構成ＤＢ
３００ 変更フロー実行装置
４００ 物理ＭＤＲ
４０１ 物理ＦＣＭＤＢ
４０２ａ 物理ＭＤＲａ
４０２ｂ 物理ＭＤＲｂ
４０２ｘ 物理ＭＤＲｘ
５００ 論理ＭＤＲ
５０１ａ テナントａＭＤＲ
５０１ｘ テナントｘＭＤＲ
５０２ａ テナントａ運用ポリシー
５０２ｘ テナントｘ運用ポリシー
６００ 実行済み変更フロー管理装置

Claims (9)

1. 管理装置としてのコンピュータに実行させる管理プログラムであって、
   前記管理装置としてのコンピュータは、
   複数のテナントそれぞれの第１の構成情報をもとに物理リソースを論理的に分散もしくは統合した論理リソースである前記複数のテナントそれぞれのテナント運用ポリシー、ならびに、前記第１の構成情報を管理する第１データベースと、
   前記第１の構成情報に対応する第２の構成情報をもとに前記物理リソースを管理する第２データベースと、
   前記第１の構成情報および前記第２の構成情報をもとに、前記テナント、前記論理リソース、ならびに、前記物理リソースの対応関係を管理する第３データベースと、
   を備え、
   前記テナント運用ポリシーの変更を受け付け、
   受け付けられた前記テナント運用ポリシーを変更する変更方針を生成し、
   生成された前記変更方針が他のテナントのテナント運用ポリシーに与える影響を評価することによって、該変更方針の実行の可否を判定するとともに、前記他のテナントのテナント運用ポリシーに与える影響を出力し、
   前記変更方針の実行が可能と判定されたときに、前記第１データベースおよび前記第２データベースによって管理される前記テナントの前記テナント運用ポリシーを生成された前記変更方針に従って変更する変更フローを生成し、
   生成された前記変更フローを実行前に管理部に格納して管理し、
   前記テナント運用ポリシーと前記変更方針と前記管理部に格納された変更フローとに基づいて、前記第３データベースによって管理される前記対応関係に基づき、前記変更フローによって運用ポリシーが変更される前記テナントと前記論理リソースまたは前記物理リソースを共有する他のテナントの前記変更フローの実施可能時間帯を抽出し、前記変更フローを抽出した前記実施可能時間帯に基づいて出力する、
   処理を前記コンピュータに実行させることを特徴とする管理プログラム。
2. 前記変更フローは、前記変更フローが実行される日時を指定する日時情報を含む
   ことを特徴とする請求項１記載の管理プログラム。
3. 前記管理部に格納された実行前の前記変更フローを、前記日時情報に基づいて出力する 処理をさらに前記コンピュータに実行させることを特徴とする請求項２記載の管理プログラム。
4. 複数のテナントそれぞれの第１の構成情報をもとに物理リソースを論理的に分散もしくは統合した論理リソースである前記複数のテナントそれぞれのテナント運用ポリシー、ならびに、前記第１の構成情報を管理する第１データベースと、
   前記第１の構成情報に対応する第２の構成情報をもとに前記物理リソースを管理する第２データベースと、
   前記第１の構成情報および前記第２の構成情報をもとに、前記テナント、前記論理リソース、ならびに、前記物理リソースの対応関係を管理する第３データベースと、
   前記テナント運用ポリシーの変更を受け付ける受付部と、
   受け付けられた前記テナント運用ポリシーを変更する変更方針を生成する変更方針生成部と、
   生成された前記変更方針が他のテナントのテナント運用ポリシーに与える影響を評価することによって、該当変更方針の実行の可否を判定するとともに、前記他のテナントのテナント運用ポリシーに与える影響を出力する出力部と、
   前記変更方針の実行が可能と判定されたときに、前記第１データベースおよび前記第２データベースによって管理される前記テナントの前記テナント運用ポリシーを生成された前記変更方針に従って変更する変更フローを生成する変更フロー生成部と、
   生成された前記変更フローを実行前に格納して管理するとともに、前記テナント運用ポリシーと前記変更方針と格納した前記変更フローとに基づいて、前記第３データベースによって管理される前記対応関係に基づき、前記変更フローによって運用ポリシーが変更される前記テナントと前記論理リソースまたは前記物理リソースを共有する他のテナントの前記変更フローの実施可能時間帯を抽出し、前記変更フローを抽出した前記実施可能時間帯に基づいて出力する管理部と、
   を備えたことを特徴とする管理装置。
5. 前記変更フローは、前記変更フローが実行される日時を指定する日時情報を含む
   ことを特徴とする請求項４記載の管理装置。
6. 前記管理部は、管理している実行前の前記変更フローを、前記日時情報に基づいて出力する
   ことを特徴とする請求項５記載の管理装置。
7. 管理装置がおこなう管理方法であって、
   前記管理装置は、
   複数のテナントそれぞれの第１の構成情報をもとに物理リソースを論理的に分散もしくは統合した論理リソースである前記複数のテナントそれぞれのテナント運用ポリシー、ならびに、前記第１の構成情報を管理する第１データベースと、
   前記第１の構成情報に対応する第２の構成情報をもとに前記物理リソースを管理する第２データベースと、
   前記第１の構成情報および前記第２の構成情報をもとに、前記テナント、前記論理リソース、ならびに、前記物理リソースの対応関係を管理する第３データベースと、
   を備え、
   前記テナント運用ポリシーの変更を受け付け、
   受け付けられた前記テナント運用ポリシーを変更する変更方針を生成し、
   生成された前記変更方針が他のテナントのテナント運用ポリシーに与える影響を評価することによって、該当変更方針の実行の可否を判定するとともに、前記他のテナントのテナント運用ポリシーに与える影響を出力し、
   前記変更方針の実行が可能と判定されたときに、前記第１データベースおよび前記第２データベースによって管理される前記テナントの前記テナント運用ポリシーを生成された前記変更方針に従って変更する変更フローを生成し、
   生成された前記変更フローを実行前に管理部に格納して管理し、
   前記テナント運用ポリシーと前記変更方針と前記管理部に格納された変更フローとに基づいて、前記第３データベースによって管理される前記対応関係に基づき、前記変更フローによって運用ポリシーが変更される前記テナントと前記論理リソースまたは前記物理リソースを共有する他のテナントの前記変更フローの実施可能時間帯を抽出し、前記変更フローを抽出した前記実施可能時間帯に基づいて出力する、
   処理を含むことを特徴とする管理方法。
8. 前記変更フローは、前記変更フローが実行される日時を指定する日時情報を含む
   ことを特徴とする請求項７記載の管理方法。
9. 前記管理部に格納された実行前の前記変更フローを、前記日時情報に基づいて出力する
   処理をさらに含むことを特徴とする請求項８記載の管理方法。

Images