ライセンスチェックシステムおよびリソースプール管理システム
【課題】仮想マシンや仮想サーバ上で稼働するソフトウェアについて、ライセンスの消費数や必要数を効率的に算出することができるライセンスチェックシステムを提供する。
【解決手段】複数の物理サーバ上で稼働する仮想マシンおよび各仮想マシン上で稼働するソフトウェアからなるシステム環境であるリソースプール２においてソフトウェア毎に実際に消費されているライセンスの数を把握するライセンスチェックシステムであって、リソースプール２において稼働中のシステムの構成情報を記録して保持する構成管理部３０と、構成管理部３０から構成情報を取得し、リソースプール２において稼働中のシステム環境で消費されている各ソフトウェアのライセンス数を、各ソフトウェアのライセンス体系の特性毎にカテゴライズして予め定義されたライセンス計算ロジック４２に従って算出し、ライセンス状況ＤＢ４１に記録するライセンスチェック部４０とを有する。
【解決手段】複数の物理サーバ上で稼働する仮想マシンおよび各仮想マシン上で稼働するソフトウェアからなるシステム環境であるリソースプール２においてソフトウェア毎に実際に消費されているライセンスの数を把握するライセンスチェックシステムであって、リソースプール２において稼働中のシステムの構成情報を記録して保持する構成管理部３０と、構成管理部３０から構成情報を取得し、リソースプール２において稼働中のシステム環境で消費されている各ソフトウェアのライセンス数を、各ソフトウェアのライセンス体系の特性毎にカテゴライズして予め定義されたライセンス計算ロジック４２に従って算出し、ライセンス状況ＤＢ４１に記録するライセンスチェック部４０とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＴ関連資産のライセンス管理の技術に関し、特に、クラウドコンピューティングサービス等において利用される仮想マシンや仮想サーバ上で稼働するソフトウェアのライセンスの有無をチェックするライセンスチェックシステムおよびリソースプール管理システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
近年では、例えばデータセンターなどの設備に多数のサーバ機器やネットワーク機器などのコンピュータリソースからなるシステム環境を構築してリソースプールとして管理し、顧客が必要とする分のリソースを仮想マシンや仮想サーバの形で提供するクラウドコンピューティングサービスが普及してきている。
【０００３】
このようなサービスを提供する事業者等では、顧客からのリソース使用の要求に適時に対応することが可能となるよう、予め未使用・未割当てのハードウェア（ＨＷ）やソフトウェア（ＳＷ）を在庫として保持・管理しておき、顧客とのサービスに係る契約の成立やリソースの使用要求（システムの変更要求）などに応じて、在庫から必要なリソースを確保してリソースプールに展開したりシステムを構築したりすることが行われる。
【０００４】
このとき、ソフトウェアリソースについては、ソフトウェアの現物ではなくライセンスを在庫として管理する必要がある。このライセンスの管理は、リソースを提供する事業者等が一元的に行う必要がある。ソフトウェアのライセンス管理の手法としては、例えば、企業における各従業員等のクライアント端末に導入されたソフトウェアのライセンスを自動的にチェックして管理するというようなことは一般的に行われており、そのための製品等も提供されている。
【０００５】
例えば、特開２００４−１１８５８４号公報（特許文献１）には、会社等の組織が有するソフトウェアライセンスに関するライセンス情報をデータベースに記憶し、また、組織内の社内端末で使用されているソフトウェアに関するインベントリ情報を取得してデータベースに記憶し、データベースに記憶されるライセンス情報について、ソフトウェア毎のライセンス数を計数し、また、データベースに記憶されるインベントリ情報について、ソフトウェア毎の使用数を計数し、各ソフトウェアについてライセンス数と使用数を比較し、使用数がライセンス数より大きいソフトウェアを検出した場合、検出内容を示す警告メールを担当者宛で送信することで、組織で使用するソフトウェアのライセンス管理を効率良く行うことができるライセンス管理サーバが記載されている。
【０００６】
また、特開２００８−１４６３９０号公報（特許文献２）には、インベントリ収集機能及び使用許諾情報収集機能を備えた情報収集処理部、使用許諾情報から許諾条件を抽出する使用許諾条件抽出処理部、抽出した許諾条件を判別する使用許諾内容判別処理部、保有数チェック機能及び使用可能数チェック機能を備えた使用状況検証処理部、および各種のＤＢを具備し、システムのソフトウェアの使用状態の検証時に、使用ソフトウェアと使用ソフトウェアに係る使用許諾情報との相違を検出することで精度の高いライセンス管理を行うことができるソフトウェアライセンス管理システムが記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１１８５８４号公報
【特許文献２】特開２００８−１４６３９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
仮想マシンや仮想サーバの形で多数のコンピュータリソースをクラウドコンピューティングサービスとして提供する事業者等において、ソフトウェアのライセンスの管理を行うことは容易ではない。仮想マシンや仮想サーバ上で稼働するソフトウェアのライセンス形態は、物理ＣＰＵや仮想ＣＰＵの数、コア数といった（仮想）ハードウェア構成に依存する場合が多く、仮想マシンや仮想サーバのシステム構成如何によってライセンスの消費数も変動するためである。
【０００９】
このため、特許文献１に記載されているようにソフトウェアのインベントリ情報から単純にライセンス使用数を求めることができない。また、特許文献２に記載されているような技術を使用したとしても使用許諾の全文から使用許諾条件が判別可能な場合はあるものの、それに基づいてソフトウェアが実際に導入されている（仮想）ハードウェア構成を考慮した上でのライセンス消費数を求めることは困難である。
【００１０】
従って従来では、クラウドコンピューティングサービスを提供するリソースプールにおけるソフトウェアのライセンス数のチェックを自動で行うような仕組みは存在せず、システム管理者等により手動で行って管理するのが一般的であった。しかし、チェックするリソースの数が多く、ソフトウェア毎のライセンスの許諾条件のバリエーションも多く複雑であるため、大きな作業負荷とコストを要していた。
【００１１】
そこで本発明の目的は、仮想マシンや仮想サーバ上で稼働するソフトウェアについて、ライセンスの消費数や必要数を効率的に算出することができるライセンスチェックシステムおよび当該ライセンスチェックシステムを有するリソースプール管理システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１２】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１３】
本発明の代表的な実施の形態によるライセンスチェックシステムは、複数の物理サーバ上で稼働する仮想マシンおよび各仮想マシン上で稼働するソフトウェアからなるシステム環境であるリソースプールにおいてソフトウェア毎に実際に消費されているライセンスの数を把握するライセンスチェックシステムであって、以下の特徴を有するものである。
【００１４】
すなわち、ライセンスチェックシステムは、前記リソースプールにおいて稼働中のシステムの構成情報をディスカバリして、物理サーバの構成情報を含むハードウェア構成、物理サーバ上で稼働する仮想マシンの構成情報を含む仮想ハードウェア構成および仮想マシン上で稼働するソフトウェアの情報を含む仮想ソフトウェア構成の各情報を取得し、これらをそれぞれ、ＨＷ構成記録手段、仮想ＨＷ構成記録手段および仮想ＳＷ構成記録手段に記録して保持する構成管理部と、前記構成管理部から前記ハードウェア構成、前記仮想ハードウェア構成および前記仮想ソフトウェア構成の情報を取得し、これらの情報に基づいて、前記リソースプールにおいて稼働中のシステム環境で消費されている各ソフトウェアのライセンス数を、各ソフトウェアのライセンス体系の特性毎にカテゴライズして予め定義されたライセンス計算ロジックに従って算出し、ライセンス状況記録手段に記録するライセンスチェック部とを有することを特徴とするものである。
【００１５】
また、本発明は、上記のライセンスチェックシステムを有し、顧客からの要求に基づく構築仕様の内容に従って、前記リソースプールにおいてハードウェアおよびソフトウェアのリソースを展開してシステムを構築してサービスとして提供するリソースプール管理システムにも適用することができる。
【発明の効果】
【００１６】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１７】
本発明の代表的な実施の形態によれば、仮想マシンや仮想サーバ上で稼働するソフトウェアなど、物理的もしくは仮想的なハードウェア構成に依存してライセンスの消費数が変動するソフトウェアについて、ライセンスの消費数や必要数を効率的に算出することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施の形態であるリソースプール管理システムの構成例について概要を示した図である。
【図２】本発明の一実施の形態におけるＨＷマスタＤＢのデータ構成の例について示した図である。
【図３】本発明の一実施の形態におけるＳＷマスタＤＢのデータ構成の例について示した図である。
【図４】本発明の一実施の形態における資産台帳ＤＢのデータ構成の例について示した図である。
【図５】本発明の一実施の形態におけるＨＷ構成ＤＢのデータ構成の例について示した図である。
【図６】本発明の一実施の形態における仮想ＨＷ構成ＤＢのデータ構成の例について示した図である。
【図７】本発明の一実施の形態における仮想ＳＷ構成ＤＢのデータ構成の例について示した図である。
【図８】本発明の一実施の形態におけるライセンス状況ＤＢのデータ構成の例について示した図である。
【図９】本発明の一実施の形態におけるＨＷ在庫ＤＢのデータ構成の例について示した図である。
【図１０】本発明の一実施の形態におけるＳＷ在庫ＤＢのデータ構成の例について示した図である。
【図１１】本発明の一実施の形態におけるＨＷ在庫仮押えＤＢのデータ構成の例について示した図である。
【図１２】本発明の一実施の形態におけるＳＷ在庫仮押えＤＢのデータ構成の例について示した図である。
【図１３】本発明の一実施の形態における契約内容管理ＤＢのデータ構成の例について示した図である。
【図１４】本発明の一実施の形態におけるハードウェアについての在庫情報を最新の状態に更新する処理の流れの例について概要を示したフローチャートである。
【図１５】本発明の一実施の形態におけるソフトウェアについての在庫情報を最新の状態に更新する処理の流れの例について概要を示したフローチャートである。
【図１６】本発明の一実施の形態におけるライセンスチェック処理の流れの例について概要を示したフローチャートである。
【図１７】（ａ）〜（ｄ）は、本発明の一実施の形態におけるライセンス計算パターンの判断基準の１つとなるソフトウェアのグルーピングパターンの概念の例について示した図である。
【図１８】（１）〜（４）は、本発明の一実施の形態におけるライセンス計算パターンの別の判断基準となるライセンス計算グループの概念の例について示した図である。
【図１９】本発明の一実施の形態におけるグルーピングパターンとライセンス計算グループをマトリクス化し、ライセンス計算パターンを割当てた例を示した図である。
【図２０】本発明の一実施の形態におけるハードウェアリソースについて在庫を仮押えする処理の流れの例について概要を示したフローチャートである。
【図２１】本発明の一実施の形態におけるソフトウェアのライセンスについて在庫を仮押えする処理の流れの例について概要を示したフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００２０】
本発明の一実施の形態であるリソースプール管理システムは、複数の物理サーバ上で稼働する仮想マシンおよび各仮想マシン上で稼働するソフトウェアからなるシステム環境であるリソースプールを構築し、顧客が必要とする分のリソースを仮想マシンの形でリソースプール上で提供するクラウドコンピューティングサービスの実装において利用されるシステムである。このリソースプール管理システムは、リソースプールにおいてソフトウェア毎に実際に消費されているライセンスの数を把握するライセンスチェックシステムとしての機能を含む。
【００２１】
リソースプール管理システムでは、顧客からのリソース使用の要求に適時に対応することが可能となるよう、予め未使用・未割当てのハードウェアやソフトウェアの資産を在庫として保持・管理しておき、顧客とのサービスに係る契約の成立やリソースの使用要求などに応じて、在庫から必要なリソースを確保してリソースプールに展開してシステムを構築する。このとき、特にソフトウェアについては、在庫を現物ではなくライセンスの残数として把握する必要がある。したがって、稼働中のシステム構成において消費されている各ソフトウェアのライセンス数をライセンス体系の特性に応じて適切に算出して、保有するライセンス数との比較により在庫に反映させるとともに、稼働中のシステムがライセンス違反となっていないことを確認する。
【００２２】
また、顧客との契約等に基づいて新たにシステムを構築する際に、システム構成に応じた適切なライセンス数を在庫から引当てて確保した上で構築する。ライセンス数が不足しそうであることを検知した場合は、例えば購買担当者等に通知してライセンスの購入を促してもよい。以上のような仕組みにより、クラウドコンピューティング環境でのリソースプールのような大規模なシステム環境においてライセンスの管理を効率的に行うことを可能とする。
【００２３】
＜システム構成＞
図１は、本発明の一実施の形態であるリソースプール管理システムの構成例について概要を示した図である。リソースプール管理システム１は、図示しないＷｅｂサーバシステムやアプリケーション等によって提供されるサービスポータル３のサイトを介して、システム担当者４や営業担当者５、購買担当者６などのユーザからのアクセスを受け、クラウドコンピューティングサービスを提供するための多数のコンピュータリソースからなるリソースプール２について、システムの構築や構成の管理、顧客との契約の管理、ソフトウェアのライセンスや、リソースの在庫の管理などを行うシステムである。
【００２４】
リソースプール管理システム１は、例えば、１台以上のサーバ機器によって構成され、ソフトウェアプログラムによって実現される資産管理部２０、構成管理部３０、ライセンスチェック部４０、在庫管理部５０、契約管理部６０およびシステム構築部７０の各部を有する。これら各部は、それぞれを独立したシステムとして別個のサーバ機器上で実装してもよいし、複数を同一のサーバ機器上で共存させて実装してもよい。
【００２５】
資産管理部２０は、リソースプール管理システム１によって管理されるハードウェア／ソフトウェアリソース（資産）を資産台帳データベース（ＤＢ）２１に登録・保持することで管理する。資産台帳ＤＢ２１への資産の登録は、例えば、購買担当者６が購入した資産に関する情報をサービスポータル３によって提供されるエントリー画面等から入力することで行われる。図示しない他の購買システム等との連携により自動的に登録されるようにしてもよい。なお、ハードウェアおよびソフトウェアについてのマスタ情報は、ＨＷマスタＤＢ１１およびＳＷマスタＤＢ１２に登録される。また、資産管理部２０は、例えば、日次の処理により、資産台帳ＤＢ２１に登録されている各資産についてベンダー等との保守契約の期間をチェックし、保守契約が終了もしくは終了しそうなものについて購買担当者６等に電子メールなどによりアラートを通知する。
【００２６】
構成管理部３０は、リソースプール２において稼働中のシステムのコンピュータリソースの構成をＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２および仮想ＳＷ構成ＤＢ３３にそれぞれ保持して管理する。これらの構成情報については、例えば、構成管理部３０が日次でリソースプール２の構成を公知技術を利用してディスカバリし、取得した構成情報を、ＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２および仮想ＳＷ構成ＤＢ３３にそれぞれ格納する。また、取得した構成情報に基づいて、消費されているソフトウェアのライセンス数を算出する処理を後述するライセンスチェック部４０に要求する。
【００２７】
ライセンスチェック部４０は、構成管理部３０からの要求に対して、ＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２および仮想ＳＷ構成ＤＢ３３のデータに基づいて、リソースプール２において稼働中のシステムで消費されているソフトウェアのライセンス数を、ソフトウェア毎のライセンス体系の特性を考慮して定義されたライセンス計算ロジック４２に従って算出し、ライセンス状況ＤＢ４１に記録する。ここで、消費されているライセンス数が、資産管理部２０の資産台帳ＤＢ２１に保持された保有リソース量（ライセンス数）を超える、もしくは超えそうな場合は、購買担当者６等に電子メールなどによりアラートを通知する。
【００２８】
また、ライセンスチェック部４０は、後述する在庫管理部５０から要求されたソフトウェアに対して、当該ソフトウェアをリソースプール２の対象サーバ上に新たに導入・展開する際に消費する（必要となる）ライセンス数を算出する処理も行う。
【００２９】
在庫管理部５０は、リソースプール２において未使用（顧客に提供するサービスとして未割当て）のハードウェアおよびソフトウェアのリソースを在庫としてその量をＨＷ在庫ＤＢ５１およびＳＷ在庫ＤＢ５２に保持して管理する。例えば、日次の処理により、構成管理部３０のＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２からハードウェアリソースの使用量を算出し、資産管理部２０の資産台帳ＤＢ２１から取得した保有リソース量との差分からハードウェアの在庫数を算出する。また、ライセンスチェック部４０のライセンス状況ＤＢ４１から取得したソフトウェアのライセンスの消費数と、資産台帳ＤＢ２１から取得した保有ライセンス数との差分からソフトウェアのライセンスの在庫数を算出する。算出した在庫数の情報は、電子メールなどにより営業担当者５に通知するようにしてもよい。
【００３０】
また、在庫管理部５０は、後述するシステム構築部７０から、リソースプール２へのシステムの新たな展開・構築のために必要となるリソースの仮押えの要求を受けて、ＨＷ在庫ＤＢ５１およびＳＷ在庫ＤＢ５２に十分な在庫がある場合に、これをＨＷ在庫仮押えＤＢ５３およびＳＷ在庫仮押えＤＢ５４に登録して引当てる。このとき、ソフトウェアについては、ライセンス体系に応じた適切なライセンス数を引当てるため、ライセンスチェック部４０に対して対象のソフトウェアについて必要なライセンス数の算出を要求する。
【００３１】
契約管理部６０は、リソースプール２によるクラウドコンピューティングサービスの提供について顧客と締結された契約の内容を契約内容管理ＤＢ６１に登録・保持することで管理する。また、契約内容に基づいて、リソースプール２において後述するシステム構築部７０が構築するシステムの仕様を構築仕様１３として出力する。契約内容管理ＤＢ６１への契約内容の登録は、例えば、営業担当者５が顧客と締結した契約の内容に関する情報をサービスポータル３によって提供される契約情報入力画面等から入力することで行われる。図示しない他の契約管理システム等との連携により自動的に登録されるようにしてもよい。
【００３２】
システム構築部７０は、契約管理部６０から出力された構築仕様１３の内容に従って、リソースプール２においてハードウェア／ソフトウェアのリソースを展開・設定してシステムを構築する。この中には、システムの新規構築だけでなく、既存システムに対するリソースの追加や変更も含まれる。システムの構築の際には、リソースプール２に対する変更管理の要請から、システム担当者４等により変更に対する承認処理が行われる。
【００３３】
また、構築に際しては、システム構成に応じて必要となるリソースを予め確保した上で構築するために、在庫管理部５０に対してリソース毎に在庫の仮押え（引当て）を要求する。在庫の仮押えができなかった場合は、例えば、システムの構築をいったん留保した上で必要なリソースの購入等を行う。仮押えが認められた場合は、実際にシステムを構築し、正常終了後に仮押えした在庫を確定させる。
【００３４】
上記のようなリソースプール管理システム１の構成において、例えば、構成管理部３０およびライセンスチェック部４０をあわせて独立したシステムとして構成することで、リソースプール２において実際に消費されているソフトウェアライセンスの数を適切に把握するライセンスチェックシステムとすることも可能である。
【００３５】
＜データ構成＞
以下では、本発明の一実施の形態であるリソースプール管理システム１における各データベースもしくはテーブルの構成について説明する。図２は、ＨＷマスタＤＢ１１のデータ構成の例について示した図である。ＨＷマスタＤＢ１１は、リソースプール２で使用されているハードウェアについての属性情報を保持するマスタテーブルであり、例えば、ハードウェアＩＤ、ハードウェア種別、メーカー、型番、スペック、登録日などの項目を有する。キー項目はハードウェアＩＤである。
【００３６】
ハードウェアＩＤの項目は、対象のハードウェアを一意に識別するためのＩＤの情報を保持する。ハードウェア種別の項目は、ハードウェアの種別（例えば、ストレージやサーバ、ネットワーク機器など）を識別するための情報を保持する。メーカー、型番、スペックの項目は、それぞれ、対象のハードウェアのメーカーやベンダーの情報、型番や製品番号等の情報、各種スペックについての情報を保持する。登録日の項目は、対象のハードウェアの情報が当該ＤＢに登録された日時の情報を保持する。
【００３７】
図３は、ＳＷマスタＤＢ１２のデータ構成の例について示した図である。ＳＷマスタＤＢ１２は、リソースプール２で使用されているソフトウェアについての属性情報を保持するマスタテーブルであり、例えば、ソフトウェアＩＤ、ソフトウェア名、メーカー、型番、バージョン、エディション、オプション、ライセンス計算パターン、検索対象外フラグ、親ソフトウェアＩＤ、物理サーバ依存ライセンスフラグ、仮押えライセンス数、在庫仮押え特殊ロジックＮｏなどの項目を有する。キー項目はソフトウェアＩＤである。
【００３８】
ソフトウェアＩＤの項目は、対象のソフトウェアを一意に識別するためのＩＤの情報を保持する。ソフトウェア名、メーカー、型番の項目は、それぞれ、対象のソフトウェアの製品名、メーカーやベンダーの情報、型番や製品番号等の情報を保持する。バージョン、エディションの項目は、対象のソフトウェアのバージョン（例えば、バージョン番号、リリース番号、リビジョン番号、モディフィケーション番号などを含む）およびエディション（例えば、「エンタープライズエディション」や「プロフェッショナルエディション」など）の情報を保持する。オプションの項目は、対象のソフトウェアについて追加購入しているオプションを識別する情報を保持する。
【００３９】
ライセンス計算パターンは、対象のソフトウェアについてライセンスの消費数を計算する際の計算パターン（図１におけるライセンス計算ロジック４２）を識別する情報を保持する。仮想マシンに導入されて稼働するソフトウェアでは、システム構成によってライセンスの消費数の計算方法が異なるなど複雑なライセンス体系を有するが、本実施の形態では、後述するように、ソフトウェア毎にライセンス体系に応じてライセンスの消費数の計算方法（ロジック）をいくつかのパターンにカテゴライズして予め割り当てておく。特殊な計算方法をとるソフトウェアについては、対応する計算ロジックをライセンス計算ロジック４２を追加する形で設定し、パターンを割り当てることも可能である。
【００４０】
検索対象フラグの項目は、対象のソフトウェアについてはライセンス数計算パターンを検索する際の検索対象から除外し、個別にライセンス消費数の計算を行わないことを指定するためのフラグの情報を保持する。例えば、同じソフトウェアでバージョンやエディションが異なるものが複数ある場合に、これらのライセンス消費数の計算パターンが全て同じで個別にライセンス数を計算する必要がない場合には、代表となるいずれか１つのバージョンもしくはエディションで１回ライセンス消費数を計算すればよいため、他のバージョンやエディションで重ねてライセンス消費数の計算を行わないようにするために利用することができる。
【００４１】
また、親ソフトウェアＩＤの項目は、対象のソフトウェアのライセンス消費数の計算の際に、例えば後述するように、バージョンやエディションに関わりなくソフトウェアの単位でライセンスを消費する体系を有する場合に、ライセンスの消費数をまとめて計算する対象（親）となるバージョンやエディションを有するソフトウェアのＩＤの情報を保持する。この場合、対象のソフトウェアのライセンスの諸費数は、親となるソフトウェアのライセンスの消費数としてカウントされる。
【００４２】
物理サーバ依存ライセンスフラグの項目は、後述するように図１の在庫管理部５０において対象のソフトウェアについて在庫の仮押えを行う際に、対象のソフトウェアが、導入されている物理サーバの数に依存してライセンス消費数が計算されるタイプであることを識別可能とするためのフラグである。この値がｆａｌｓｅである場合は、導入されている仮想マシンの数に依存してライセンス消費数が計算されるタイプであることを示す。
【００４３】
仮押えライセンス数の項目は、対象のソフトウェアについて在庫の仮押えを行う際に、物理サーバもしくは仮想マシン（上述の物理サーバ依存ライセンスフラグによって決定される）毎に必要なライセンスの単位数の情報を保持する。この情報は、顧客に対してサービスメニューとして予め決められた種類のシステム構成やオプションから選択させる契約方法をとることによって、事前にマスタデータとして定義しておくことが可能である。在庫仮押え特殊ロジックＮｏは、対象のソフトウェアが、在庫の仮押えを行う際に特殊なロジックを必要とするものである場合に、その特殊ロジックを特定するための情報を保持する。これにより、予め定義しておいた対応する特殊ロジックを呼び出して仮押えの処理を行うことができる。
【００４４】
図４は、資産台帳ＤＢ２１のデータ構成の例について示した図である。資産台帳ＤＢ２１は、リソースプール管理システム１によって管理されるハードウェア／ソフトウェア資産についての情報を台帳として保持するテーブルであり、例えば、資産管理ＩＤ、種別、資産ＩＤ、見積番号、保守契約番号、保守契約期間、保有ライセンス数などの項目を有する。キー項目は、資産管理ＩＤ、種別および資産ＩＤである。
【００４５】
資産管理ＩＤの項目は、対象のリソースについて、全てのハードウェア／ソフトウェアリソースの中で一意に割り振られたＩＤの情報を保持する。種別の項目は、対象のリソースの種別（例えば、「ハードウェア」や「ソフトウェア」）の情報を保持する。資産ＩＤの項目は、対象のリソースに割り振られているＩＤの情報を保持する。対象のリソースがハードウェアの場合は図２のＨＷマスタＤＢ１１におけるハードウェアＩＤ、ソフトウェアの場合は図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤに設定された値となる。
【００４６】
見積番号の項目は、対象のリソースを購入した際にメーカー等から取得した見積を特定する情報を保持する。保守契約番号および保守契約期間の項目は、それぞれ、対象のリソースについてメーカー等と締結している保守契約を特定する情報およびその期間の情報を保持する。これらの情報により、図１の資産管理部２０において、対象のリソースについて保守契約期間が終了しているか否かを確認し、システム担当者４や購買担当者６等に保守契約の更新の要否を問い合わせたりすることができる。保有ライセンス数の項目は、対象のリソースがソフトウェアの場合に保有しているライセンス数の情報を保持する。
【００４７】
図５は、ＨＷ構成ＤＢ３１のデータ構成の例について示した図である。ＨＷ構成ＤＢ３１は、リソースプール２において稼働中のシステムの物理ハードウェア（サーバ）の構成情報を保持するテーブルであり、例えば、サーバＩＤ、サーバ名、ホスト名、ＩＰアドレス、ＣＰＵ数、ＣＰＵコア数、メモリサイズなどの情報を保持する。キー項目はサーバＩＤである。
【００４８】
サーバＩＤの項目は、対象の物理サーバを識別するＩＤの情報を保持する。サーバ名、ホスト名およびＩＰアドレスの項目は、それぞれ、対象の物理サーバに設定されたサーバ名、ホスト名の情報および割り当てられたＩＰアドレスの情報を保持する。ＣＰＵ数およびＣＰＵコア数の情報は、それぞれ、対象の物理サーバが有するＣＰＵおよび物理コアの数の情報を保持する。メモリサイズの項目は、対象の物理サーバが有する物理メモリのサイズの情報を保持する。
【００４９】
図６は、仮想ＨＷ構成ＤＢ３２のデータ構成の例について示した図である。仮想ＨＷ構成ＤＢ３２は、リソースプール２において物理サーバ上で稼働中の仮想ハードウェア（仮想マシン）の構成情報を保持するテーブルであり、例えば、仮想マシンＩＤ、サーバＩＤ、テナントＩＤ、アプライアンスＩＤ、ホスト名、ＩＰアドレス、ｖＣＰＵ数、仮想メモリサイズ、ローカルディスクサイズ、インシデントＩＤなどの項目を有する。キー項目は仮想マシンＩＤである。
【００５０】
仮想マシンＩＤの項目は、対象の仮想マシンを識別するＩＤの情報を保持する。サーバＩＤの項目は、対象の仮想マシンが稼働する物理サーバのＩＤの情報を保持する。このサーバＩＤの項目は、図５のＨＷ構成ＤＢ３１におけるサーバＩＤの項目と同様である。テナントＩＤおよびアプライアンスＩＤの項目は、それぞれ、対象の仮想マシンを利用している顧客（テナント）および当該顧客が契約により選択したシステム構成のパターン（アプライアンス）を特定するＩＤの情報を保持する。
【００５１】
ホスト名およびＩＰアドレスの項目は、それぞれ、対象の仮想マシンに設定されたホスト名および割り当てられたＩＰアドレスの情報を保持する。ｖＣＰＵ数、仮想メモリサイズおよびローカルディスクサイズの項目は、それぞれ、対象の仮想マシンに割り当てられたｖＣＰＵ（仮想ＣＰＵ）数、仮想メモリのサイズおよびローカルディスクのサイズの情報を保持する。インシデントＩＤの項目は、対象の仮想マシンを構築して稼働させたインシデントを識別するＩＤの情報を保持する。
【００５２】
図７は、仮想ＳＷ構成ＤＢ３３のデータ構成の例について示した図である。仮想ＳＷ構成ＤＢ３３は、リソースプール２において稼働中の仮想マシン上で稼働するソフトウェアの情報を保持するテーブルであり、例えば、仮想マシンＩＤ、ソフトウェアＩＤ、サーバＩＤ、インシデントＩＤなどの項目を有する。キー項目は仮想マシンＩＤおよびソフトウェアＩＤである。
【００５３】
仮想マシンＩＤの項目は、対象のソフトウェアが稼働する仮想マシンを識別するＩＤの情報を保持する。この仮想マシンＩＤの項目は、図６の仮想ＨＷ構成ＤＢ３２における仮想マシンＩＤの項目と同様である。ソフトウェアＩＤの項目は、対象のソフトウェアを識別するＩＤの情報を保持する。このソフトウェアＩＤの項目は、図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤの項目と同様である。サーバＩＤの項目は、対象のソフトウェアが稼働する物理サーバを識別するＩＤの情報を保持する。このサーバＩＤの項目は、図５のＨＷ構成ＤＢ３１におけるサーバＩＤの項目と同様である。インシデントＩＤの項目は、対象のソフトウェアを導入して稼働させたインシデントを識別するＩＤの情報を保持する。
【００５４】
図８は、ライセンス状況ＤＢ４１のデータ構成の例について示した図である。ライセンス状況ＤＢ４１は、リソースプール２において稼働中のシステムで消費されているソフトウェアのライセンス数の情報を保持するテーブルであり、例えば、ソフトウェアＩＤ、ライセンス消費数などの項目を有する。キー項目はソフトウェアＩＤである。ソフトウェアＩＤの項目は、対象のソフトウェアを識別するＩＤの情報を保持する。このソフトウェアＩＤの項目は、図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤの項目と同様である。ライセンス消費数の項目は、対象のソフトウェアについて図１におけるライセンスチェック部４０によって算出されたライセンスの消費数の情報を保持する。
【００５５】
図９は、ＨＷ在庫ＤＢ５１のデータ構成の例について示した図である。ＨＷ在庫ＤＢ５１は、リソースプール２において未使用（顧客に提供するサービスとして未割当て）のハードウェアリソースの量を在庫情報として保持するテーブルであり、例えば、サーバＩＤ、ｖＣＰＵ残数、仮想メモリ残数などの項目を有する。キー項目はサーバＩＤである。サーバＩＤの項目は、対象のハードウェアリソースを有する物理サーバを識別するＩＤの情報を保持する。このサーバＩＤの項目は、図５のＨＷ構成ＤＢ３１におけるサーバＩＤの項目と同様である。ｖＣＰＵ残数および仮想メモリ残数の項目は、それぞれ、対象のサーバにおいて割当て可能なｖＣＰＵの数および仮想メモリのサイズの情報を在庫情報として保持する。
【００５６】
図１０は、ＳＷ在庫ＤＢ５２のデータ構成の例について示した図である。ＳＷ在庫ＤＢ５２は、リソースプール２において未使用のソフトウェアのライセンスの数を在庫情報として保持するテーブルであり、例えば、ソフトウェアＩＤ、ライセンス在庫数などの項目を有する。キー項目はソフトウェアＩＤである。ソフトウェアＩＤの項目は、対象のソフトウェアを識別するＩＤの情報を保持する。このソフトウェアＩＤの項目は、図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤの項目と同様である。ライセンス在庫数の項目は、対象のソフトウェアにおいて利用可能なライセンス数を在庫情報として保持する。
【００５７】
図１１は、ＨＷ在庫仮押えＤＢ５３のデータ構成の例について示した図である。ＨＷ在庫仮押えＤＢ５３は、リソースプール２においてシステムを新たに展開・構築する際に、必要なハードウェアリソースを在庫から仮押えした内容についての情報を保持するテーブルであり、例えば、サーバＩＤ、仮想マシンＩＤ、消費ｖＣＰＵ数、消費仮想メモリ数、インシデントＩＤなどの項目を有する。キー項目はサーバＩＤおよび仮想マシンＩＤである。
【００５８】
サーバＩＤおよび仮想マシンＩＤの項目は、それぞれ、対象のハードウェアリソースを有する物理サーバおよび構築対象の仮想マシンを識別するＩＤの情報を保持する。このサーバＩＤおよび仮想マシンＩＤの項目は、それぞれ、図５のＨＷ構成ＤＢ３１におけるサーバＩＤの項目および図６の仮想ＨＷ構成ＤＢ３２における仮想マシンＩＤの項目と同様である。消費ｖＣＰＵ数および消費仮想メモリ数の項目は、それぞれ、構築対象の仮想マシン上で必要なハードウェアリソース量として仮押えしたｖＣＰＵの数および仮想メモリのサイズの情報を保持する。インシデントＩＤの項目は、対象のハードウェアリソースを仮押えさせたインシデントを識別するＩＤの情報を保持する。
【００５９】
図１２は、ＳＷ在庫仮押えＤＢ５４のデータ構成の例について示した図である。ＳＷ在庫仮押えＤＢ５４は、リソースプール２においてシステムを新たに展開・構築する際に、必要なソフトウェアのライセンスを在庫から仮押えした内容についての情報を保持するテーブルであり、例えば、ソフトウェアＩＤ、ライセンス消費数、インシデントＩＤなどの項目を有する。キー項目はソフトウェアＩＤである。
【００６０】
ソフトウェアＩＤの項目は、対象のソフトウェアを識別するＩＤの情報を保持する。このソフトウェアＩＤの項目は、図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤの項目と同様である。ライセンス消費数の項目は、対象のソフトウェアについて必要なリソースとして仮押さえしたライセンス数の情報を保持する。インシデントＩＤの項目は、対象のソフトウェアのライセンスを仮押えさせたインシデントを識別するＩＤの情報を保持する。
【００６１】
図１３は、契約内容管理ＤＢ６１のデータ構成の例について示した図である。契約内容管理ＤＢ６１は、リソースプール２によるクラウドコンピューティングサービスの提供について顧客と締結された契約の内容を保持するテーブルであり、例えば、契約ＩＤ、テナントＩＤ、適用開始日、適用終了日、アプライアンスＩＤ、初期費用、月額費用、インシデントＩＤなどの項目を有する。キー項目は契約ＩＤおよびテナントＩＤである。
【００６２】
契約ＩＤの項目は、顧客との契約を一意に識別するためのＩＤの情報を保持する。テナントＩＤの項目は、対象の契約を締結した顧客（テナント）を識別するためのＩＤの情報を保持する。このテナントＩＤの項目は、図６の仮想ＨＷ構成ＤＢ３２におけるテナントＩＤの項目と同様である。なお、各テナントの名称や連絡先等の属性の情報は別途テナントのマスタテーブルに保持しておいてもよい。適用開始日および適用終了日の項目は、それぞれ、対象の契約が適用される期間の開始日および終了日の情報を保持する。
【００６３】
アプライアンスＩＤの項目は、対象のテナントが対象の契約により選択したシステム構成のパターン（アプライアンス）を識別するＩＤの情報を保持する。このアプライアンスＩＤの項目は、図６の仮想ＨＷ構成ＤＢ３２におけるアプライアンスＩＤの項目と同様である。顧客はアプライアンスとしてシステムの構成のパターンを選択することで、簡便・効率的にサービスを利用することができる。初期費用および月額費用の項目は、それぞれ、対象の契約における料金体系の内容を保持する。インシデントＩＤの項目は、対象の契約およびアプライアンスに基づいてリソースプール２にシステムを展開・構築するためのインシデントを識別するＩＤの情報を保持する。
【００６４】
なお、上述の図２〜図１３で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。
【００６５】
＜リソースプール管理処理−在庫更新およびライセンスチェック＞
以下では、本発明の一実施の形態であるリソースプール管理システム１における管理処理の内容について説明する。まず、リソースプール２で稼働中のシステムの構成情報に基づいて、ハードウェア／ソフトウェアのリソースの在庫情報を最新の状態に更新するとともに、ソフトウェアのライセンスの消費状況をチェックし、必要なライセンスを保有していることを確認する処理について説明する。この処理は例えば日次処理として実行される。
【００６６】
前提として、図１の構成管理部３０での日次処理により、予めリソースプール２において稼働中のシステムのコンピュータリソースの構成をディスカバリし、取得した構成情報がＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２および仮想ＳＷ構成ＤＢ３３にそれぞれ保持されているものとする。
【００６７】
図１４は、ＨＷ在庫ＤＢ５１に保持するハードウェアについての在庫情報を最新の状態に更新する処理の流れの例について概要を示したフローチャートである。ハードウェアの在庫更新処理を開始すると、まず、図１における在庫管理部５０は、ＨＷ構成ＤＢ３１に保持されている各物理サーバについて処理を行うループ処理を開始する。当該ループ処理では、対象の物理サーバのＣＰＵコアの総数およびメモリサイズの情報（保有リソース量）を取得する（Ｓ０１）。次に、仮想ＨＷ構成ＤＢ３２から、対象の物理サーバ上で稼働する各仮想マシンのレコードを抽出し、これらのｖＣＰＵ数および仮想メモリサイズの合計（消費リソース量）を算出する（Ｓ０２）。
【００６８】
その後、ステップＳ０１で取得したＣＰＵコア数とメモリサイズ、およびステップＳ０２で取得したｖＣＰＵ数と仮想メモリサイズとの差分によりＣＰＵ残数と仮想メモリ残数を算出し、ＨＷ在庫ＤＢ５１に出力して内容を更新する（Ｓ０３）。その後、次の物理サーバの処理に移る。全ての物理サーバについてのループ処理が終了すると、ハードウェアの在庫更新処理を終了する。
【００６９】
図１５は、ＳＷ在庫ＤＢ５２に保持するソフトウェアについての在庫情報を最新の状態に更新する処理の流れの例について概要を示したフローチャートである。ソフトウェアの在庫更新処理を開始すると、まず、図１における在庫管理部５０は、ライセンスチェック部４０により、各ソフトウェアについてのライセンスの消費数を算出してライセンス不足の有無をチェックするライセンスチェック処理を実行する（Ｓ１１）。当該処理は、在庫更新処理とは非同期で予め実行しておいてもよい。なお、当該処理の内容については後述する。
【００７０】
次に、仮想ＳＷ構成ＤＢ３３に保持されている各ソフトウェアについて処理を行うループ処理を開始する。当該ループ処理では、対象のソフトウェアについて資産台帳ＤＢ２１から保有ライセンス数を取得する（Ｓ１２）。次に、対象のソフトウェアについてステップＳ１１によって算出されたライセンスの消費数をライセンス状況ＤＢ４１から取得する（Ｓ１３）。次に、その後、ステップＳ１２で取得した保有ライセンス数とステップＳ１３で取得した消費ライセンス数との差分によりライセンス在庫数を算出し、ＳＷ在庫ＤＢ５２に出力して内容を更新する（Ｓ１４）。その後、次のソフトウェアの処理に移る。全てのソフトウェアについてのループ処理が終了すると、ソフトウェアの在庫更新処理を終了する。
【００７１】
なお、在庫管理部５０は、更新されたハードウェア／ソフトウェアの在庫情報を営業担当者５等に電子メール等により通知するようにしてもよい。また、在庫数が所定の閾値よりも少ないことを検知した場合は購買担当者６等にその旨の警告を電子メール等により通知するようにしてもよい。
【００７２】
図１６は、図１５のステップＳ１１におけるライセンスチェック処理の流れの例について概要を示したフローチャートである。当該処理では、構成管理部３０が保有するリソースプール２におけるシステムの構成情報に基づいて、ソフトウェアのライセンス体系の特性に応じてライセンスの消費数を算出し、資産台帳ＤＢ２１の情報と照合することでライセンス不足の有無をチェックする処理を行う。ライセンスチェック処理を開始すると、まず、ライセンスチェック部４０は、仮想ＳＷ構成ＤＢ３３に保持されている各ソフトウェアについて処理を行うループ処理を開始する。
【００７３】
当該ループ処理では、対象のソフトウェアについてＳＷマスタＤＢ１２からライセンス計算パターンの情報を取得する（Ｓ２１）。次に、取得したライセンス計算パターンに対応するライセンス計算ロジック４２を取得し、これに基づいて対象のソフトウェアのライセンスの消費数を算出する（Ｓ２２）。当該処理の内容については後述する。次に、算出したライセンスの消費数を、資産台帳ＤＢ２１の保有ライセンス数と照合し、ライセンス不足の有無をチェックする（Ｓ２３）。ライセンス数の残数が所定の閾値よりも少ない場合は購買担当者６等にその旨の警告を電子メール等により通知するようにしてもよい。その後、次のソフトウェアの処理に移る。全てのソフトウェアについてのループ処理が終了すると、ライセンスチェック処理を終了する。
【００７４】
＜ライセンス計算パターンおよびライセンス計算ロジック＞
以下では、図１６のライセンスチェック処理におけるソフトウェア毎のライセンス計算パターンおよびライセンス計算ロジック４２の内容について説明する。図１７は、ライセンス計算パターンの判断基準の１つとなるソフトウェアのグルーピングパターンの概念の例について示した図である。一般的に、ソフトウェアのライセンスの消費単位としては、ソフトウェアやバージョン、エディション単位など種々のものが存在し、メーカーやベンダー、ソフトウェア等により異なる場合がある。これらをカテゴライズすると、図１７に示すように、概ね以下の（ａ）〜（ｄ）の４つのパターン（以下ではこれを「グルーピングパターン」と記載する場合がある）に分類することが可能である。
【００７５】
（ａ）ソフトウェア毎にバージョンおよびエディションの単位でライセンスが必要となるもの。すなわち、同一ソフトウェアの同一バージョンであっても、エディションが異なれば別個のライセンスを必要とするもの。（ｂ）ソフトウェア毎にエディションの単位でライセンスが必要となるもの。すなわち、同一ソフトウェアについて異なるバージョンであっても、エディションが同一であればライセンスは共通となるもの。（ｃ）ソフトウェア毎にバージョンの単位でライセンスが必要となるもの。すなわち、エディションの考え方がないもの。（ｄ）ソフトウェアの単位でライセンスが必要となるもの。すなわち、エディションの考え方がなく、同一のソフトウェアであれば異なるバージョンであってもライセンスは共通となるもの。
【００７６】
上記の４つのパターンにおいて、（ａ）および（ｃ）のパターン、すなわち、異なるバージョンでは別個のライセンスを必要とするパターンは、本実施の形態のリソースプール２で使用されるような、メーカーやベンダーとの保守契約が付随するサーバ用のソフトウェアでは一般的ではなく基本的には存在しないと考えられる（ライセンスの購入ではなく保守契約によってバージョンアップが行われる）。また、一般的に利用される多くのソフトウェアが（ｄ）のパターンにカテゴライズされるものと考えられる。
【００７７】
なお、上記の４つの典型的なグルーピングパターンに属さない特殊なライセンス体系を有するソフトウェアも存在する（例えば、上位エディションのライセンスに下位エディションの利用権が存在するものなど）。これらについては、特殊パターンとして追加でグルーピングパターンを割当てることができる。
【００７８】
図１８は、ライセンス計算パターンの別の判断基準となるライセンス計算グループの概念の例について示した図である。本実施の形態のリソースプール２で使用されるような、仮想マシン上で稼働するソフトウェアの場合、導入されるサーバの構成によってライセンスの消費数が異なる場合がある。これらをカテゴライズすると、図１８に示すように、概ね以下の（１）〜（４）の４つのグループ（以下ではこれを「ライセンス計算グループ」と記載する場合がある）に分類することが可能である。
【００７９】
（１）導入される仮想マシンのｖＣＰＵ毎にライセンスが必要となるもの。（２）導入される仮想マシン毎にライセンスが必要となるもの。すなわち、導入される仮想マシンのｖＣＰＵの数に依存せずにライセンスが必要となるもの。（３）導入される物理サーバのＣＰＵ毎にライセンスが必要となるもの。すなわち、導入される仮想マシンの数に依存せず、また、導入される仮想マシンが利用しない物理ＣＰＵが存在する場合でも、物理サーバのＣＰＵ数分のライセンスが必要となるもの。（４）導入される物理サーバのＣＰＵのコア毎にライセンスが必要となるもの。すなわち、導入される仮想マシンの数に依存せず、また、導入される仮想マシンが利用しない物理ＣＰＵが存在する場合でも、物理サーバのＣＰＵコア数分のライセンスが必要となるもの。
【００８０】
なお、上記の４つの典型的なライセンス計算グループに属さない特殊なライセンス体系を有するソフトウェアも存在する（例えば、ｖＣＰＵの数について階段状にライセンス数が消費されるものや、導入される仮想マシンがハイパーバイザの割当てにより実際に利用する物理ＣＰＵの数分のライセンスが消費されるものなど）。これらについては、特殊グループとして追加でライセンス計算グループを割当てることができる。
【００８１】
図１９は、図１７に示したグルーピングパターンと、図１８に示したライセンス計算グループをマトリクス化し、これらの組み合わせに対してライセンス計算パターンを割当てた例を示した図である。図中において、典型的なグルーピングパターン（ａ）〜（ｄ）および典型的なライセンス計算グループ（１）〜（４）からなる部分については、基本的に存在しないと考えられる（ａ）および（ｃ）のグルーピングパターンを除き、ライセンス計算パターン（“＃００１”〜“＃００４”）を割当てている。また、特殊なグルーピングパターン（ｅ）およびライセンス計算グループ（５）〜（８）についても、該当する箇所にライセンス計算パターン（“＃１０５”〜“＃１０８”）を割当てることができる。
【００８２】
ここで、ライセンス計算パターンとは、ライセンスの消費数を算出する際の計算方法（ロジック）のパターンであり、ソフトウェア毎にグルーピングパターンおよびライセンス計算グループに基づいて割当てられ、ＳＷマスタＤＢ１２のライセンス計算パターンの項目に予め設定される。各ライセンス計算パターンに対応するライセンス消費数の計算ロジックはライセンス計算ロジック４２に定義され、ライセンスチェック部４０によって管理される。
【００８３】
図中に示すとおり、上述したライセンス計算グループ（１）〜（４）において、（ｂ）と（ｄ）のグルーピングパターンでは同じライセンス計算パターン（“＃００１”〜“＃００４”）となることを示している。これらのライセンス計算パターンに対応する具体的な計算方法であるライセンス計算ロジック４２の概要は例えば以下の通りである。
【００８４】
ライセンス計算パターン“＃００１”では、まず、ライセンスの消費数の算出対象のソフトウェアについて、ＳＷマスタＤＢ１２から、親ソフトウェアＩＤの項目に算出対象のソフトウェアのソフトウェアＩＤが指定されているレコードを抽出する。次に、仮想ＳＷ構成ＤＢ３３により、算出対象のソフトウェアおよび先に抽出したレコードに対応するソフトウェアについて、これらが導入された仮想マシンを特定し、さらに仮想ＨＷ構成ＤＢ３２により、対象の各仮想マシンのｖＣＰＵ数を取得する。取得したｖＣＰＵ数を全て加算したものが対象のソフトウェアのライセンス消費数となるため、これをライセンス状況ＤＢ４１に登録する。
【００８５】
ライセンス計算パターン“＃００２”では、“＃００１”と同様に、まず、算出対象のソフトウェアについて、ＳＷマスタＤＢ１２から、親ソフトウェアＩＤの項目に算出対象のソフトウェアのソフトウェアＩＤが指定されているレコードを抽出する。次に、仮想ＳＷ構成ＤＢ３３により、算出対象のソフトウェアおよび先に抽出したレコードに対応するソフトウェアについて、これらが導入された仮想マシンを特定する。特定した仮想マシンの台数が対象のソフトウェアのライセンス消費数となるため、これをライセンス状況ＤＢ４１に登録する。
【００８６】
ライセンス計算パターン“＃００３”では、“＃００１”と同様に、まず、算出対象のソフトウェアについて、ＳＷマスタＤＢ１２から、親ソフトウェアＩＤの項目に算出対象のソフトウェアのソフトウェアＩＤが指定されているレコードを抽出する。次に、仮想ＳＷ構成ＤＢ３３により、算出対象のソフトウェアおよび先に抽出したレコードに対応するソフトウェアについて、これらが導入された物理サーバを特定し、さらにＨＷ構成ＤＢ３１により、対象の物理サーバのＣＰＵ数を取得する。取得したＣＰＵ数を全て加算したものが対象のソフトウェアのライセンス消費数となるため、これをライセンス状況ＤＢ４１に登録する。
【００８７】
ライセンス計算パターン“＃００４”では、“＃００１”と同様に、まず、算出対象のソフトウェアについて、ＳＷマスタＤＢ１２から、親ソフトウェアＩＤの項目に算出対象のソフトウェアのソフトウェアＩＤが指定されているレコードを抽出する。次に、仮想ＳＷ構成ＤＢ３３により、算出対象のソフトウェアおよび先に抽出したレコードに対応するソフトウェアについて、これらが導入された物理サーバを特定し、さらにＨＷ構成ＤＢ３１により、対象の物理サーバのＣＰＵコア数を取得する。取得したＣＰＵコア数を全て加算したものが対象のソフトウェアのライセンス消費数となるため、これをライセンス状況ＤＢ４１に登録する。
【００８８】
このように、グルーピングパターンおよびライセンス計算グループの組み合わせにより各ソフトウェアのライセンス体系をカテゴライズしてライセンス計算パターンを割当て、対応するライセンス計算ロジック４２を定義することにより、仮想マシン上で稼働するソフトウェアのライセンス体系と実際のシステム構成に応じたライセンス消費数の算出が可能となる。
【００８９】
＜リソースプール管理処理−構築時の在庫仮押え＞
以下では、本発明の一実施の形態であるリソースプール管理システム１における管理処理の他の内容として、リソースプール２へのシステムの新たな展開・構築の際に、システム構築部７０からの要求により、在庫管理部５０が必要となるリソースを仮押えする際の処理について説明する。
【００９０】
図２０は、ハードウェアリソースについて在庫を仮押えする処理の流れの例について概要を示したフローチャートである。ハードウェアの在庫仮押え処理を開始すると、在庫管理部５０は、まず、システム構築部７０が構築仕様１３に基づいて指定した構築対象の各ハードウェアについて処理を行うループ処理を開始する。当該ループ処理では、まず、対象のハードウェアについてＨＷ在庫ＤＢ５１を参照して在庫があるか否かを確認し（Ｓ３１）、在庫がない場合は当該ハードウェアの情報を記憶した上で次のハードウェアの処理に移る。
【００９１】
ステップＳ３１において在庫がある場合は、ＨＷ在庫仮押えＤＢ５３に必要なリソースの情報をシステム構築部７０から指定されたインシデントＩＤの情報とともに登録する（Ｓ３２）。このとき対象の物理サーバについて既に仮押え情報が登録されている場合はこれに加算して更新する。さらに、ＨＷ在庫ＤＢ５１の対応するリソースの在庫量を減算して更新し（Ｓ３３）、さらに、構成管理部３０に依頼する等によりＨＷ構成ＤＢ３１および仮想ＨＷ構成ＤＢ３２に対応する構成情報を登録する（Ｓ３４）。その後、次のハードウェアの処理に移る。構築対象の全てのハードウェアについてのループ処理が終了すると、在庫の仮押えの結果をシステム担当者４に通知する等の処理を行った上でハードウェアの在庫仮押え処理を終了する。
【００９２】
図２１は、ソフトウェアのライセンスについて在庫を仮押えする処理の流れの例について概要を示したフローチャートである。ソフトウェアの在庫仮押え処理を開始すると、在庫管理部５０は、まず、システム構築部７０が構築仕様１３に基づいて指定した構築（導入）対象の各ソフトウェアについて処理を行うループ処理を開始する。
【００９３】
当該ループ処理では、まず、対象のソフトウェアについてＳＷマスタＤＢ１２を参照し、ライセンス体系が物理サーバに依存する（仮想マシンに依存しない）ものであるか否かを確認する（Ｓ４１）。例えば、対象のソフトウェアが図１８に示したライセンス計算グループにおいて（３）もしくは（４）に該当するものである場合は物理サーバに依存するライセンス体系に該当する。本実施の形態では、このような判定を容易にするため、ＳＷマスタＤＢ１２に物理サーバ依存ライセンスフラグとしてライセンス条項や条件等に基づいて当該情報を予め設定しておくものとする。すなわち、ステップＳ４１では、ＳＷマスタＤＢ１２の物理サーバ依存ライセンスフラグの値を判定することになる。
【００９４】
ステップＳ４１で対象のソフトウェアが物理サーバに依存するライセンス体系でない場合は、後述するステップＳ４５に進む。物理サーバに依存するライセンス体系である場合は、次に、ライセンスの必要数を算出するための特殊なロジックが必要か否かを判定する（Ｓ４２）。ここでは、対象のソフトウェアを導入する仮想マシンが稼働する物理サーバのＣＰＵ数やコア数からの単純な計算により必要なライセンス数を算出することが困難なライセンス計算グループに属するような場合が該当する。
【００９５】
本実施の形態では、このような判断を容易にするため、ＳＷマスタＤＢ１２に在庫仮押え特殊ロジックＮｏとして、予め定義された特殊ロジックを特定する情報を設定可能であるものとする。在庫仮押え特殊ロジックＮｏの設定内容により特殊ロジックが必要であると判定される場合は、在庫仮押え特殊ロジックＮｏによって特定される特殊ロジックを利用してライセンスの消費数を算出し（Ｓ４３）、後述するステップＳ４６に進む。
【００９６】
ステップＳ４２で特殊ロジックが必要でない場合は、仮想ＳＷ構成ＤＢ３３を参照して、対象のソフトウェアが構築仕様１３にて指定された導入対象の物理サーバに既に導入されているか否かを判定する（Ｓ４４）。既に導入済みである場合は、対象のソフトウェアについてのライセンスは引当て済みであるとして、何もせずに次のソフトウェアの処理に移る。対象の物理サーバにまだ導入されていない場合は、対象のソフトウェアを対象の物理サーバに導入する際に消費するライセンス数を取得する（Ｓ４５）。具体的には、ＳＷマスタＤＢ１２の仮押えライセンス数の項目の値を取得する。
【００９７】
本来では、同一のソフトウェアであっても導入対象の物理サーバや仮想サーバのＣＰＵ数等の構成に応じてライセンスの消費数は異なる場合がある。しかしながら、クラウドコンピューティング環境では、大量のハードウェアリソースを維持・管理して提供する必要があることからその構成は物理サーバ間で統一される場合が多いと考えられる。従って、本実施の形態では、リソースプール２で管理される物理サーバのシステム構成は基本的に統一されているものとし、どの物理サーバに導入しても一律にＳＷマスタＤＢ１２における仮押えライセンス数に設定されたライセンス数が消費されるものとして計算の簡略化を図っている。なお、物理サーバの構成が統一されていない環境において、上述したソフトウェア在庫更新処理で示したように、導入対象の物理サーバの構成に基づいてライセンスの消費数を個別に算出する手順とすることも当然ながら可能である。
【００９８】
その後、対象のソフトウェアについて必要なライセンス数につき、ＳＷ在庫ＤＢ５２を参照してライセンスの在庫があるか否かを確認し（Ｓ４６）、在庫がない場合は当該ソフトウェアの情報を記憶した上で次のソフトウェアの処理に移る。
【００９９】
ステップＳ４６において在庫がある場合は、ＳＷ在庫仮押えＤＢ５４に必要なライセンス数の情報をシステム構築部７０から指定されたインシデントＩＤの情報とともに登録する（Ｓ４７）。このとき対象のソフトウェアについて既に仮押え情報が登録されている場合はこれに加算して更新する。さらに、ＳＷ在庫ＤＢ５２の対応するソフトウェアのライセンスの在庫数を減算して更新し（Ｓ４８）、さらに構成管理部３０に依頼する等により仮想ＳＷ構成ＤＢ３３に対応する構成情報を登録する（Ｓ４９）。その後、次のソフトウェアの処理に移る。導入対象の全てのソフトウェアについてのループ処理が終了すると、ライセンスの在庫の仮押えの結果をシステム担当者４に通知する等の処理を行った上でソフトウェアの在庫仮押え処理を終了する。
【０１００】
なお、上記のハードウェア／ソフトウェアの在庫仮押え処理による構築対象のハードウェア／ソフトウェアリソースの在庫の仮押えの成立をもって、システム担当者４がリソースプール２に対するシステム構築実行の承認（変更承認）を行うようすることが可能である。その後、リソースプール２におけるシステム構築が完了した際に、ＨＷ在庫仮押えＤＢ５３およびＳＷ在庫仮押えＤＢ５４のレコードを削除等することで、仮押えしていた在庫の引当てを確定することができる。
【０１０１】
以上に説明したように、本発明の一実施の形態であるリソースプール管理システム１もしくはライセンスチェックシステムによれば、リソースプール２において稼働中のシステムにおいて消費されているソフトウェア（特に仮想サーバ上で稼働し、ライセンス体系が複雑なソフトウェア）のライセンス数を適切に算出して、保有するライセンス数との比較により在庫に反映させるとともに、稼働中のシステムがライセンス違反となっていないことを確認することが可能となる。
【０１０２】
また、新たにシステムを構築する際に、システム構成に応じた適切なライセンス数を在庫から仮押えして確保した上で構築する。また、いずれの場合にも、保有ライセンス数が不足しそうであることを検知した場合は、購買担当者６等に通知してライセンスの購入を促すことができる。このような仕組みにより、クラウドコンピューティング環境でのリソースプールにおけるような大規模なシステム環境におけるソフトウェア（特に仮想サーバで稼働するソフトウェア）のライセンスの管理を効率的に行うことが可能となる。
【０１０３】
また、ソフトウェアのライセンス条項や条件が特殊なものである場合にも、対応するライセンス計算ロジック４２を定義してライセンス計算パターンを割当てることでライセンスの消費数を算出することが可能であり、高い拡張性も有する。
【０１０４】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【０１０５】
本発明は、クラウドコンピューティングサービス等において利用される仮想マシンや仮想サーバ上で稼働するソフトウェアのライセンスの有無をチェックするライセンスチェックシステムおよびリソースプール管理システムに利用可能である。
【符号の説明】
【０１０６】
１…リソースプール管理システム、２…リソースプール、３…サービスポータル、４…システム担当者、５…営業担当者、６…購買担当者、
１１…ＨＷマスタＤＢ、１２…ＳＷマスタＤＢ、１３…構築仕様、
２０…資産管理部、２１…資産台帳ＤＢ、
３０…構成管理部、３１…ＨＷ構成ＤＢ、３２…仮想ＨＷ構成ＤＢ、３３…仮想ＳＷ構成ＤＢ、
４０…ライセンスチェック部、４１…ライセンス状況ＤＢ、４２…ライセンス計算ロジック、
５０…在庫管理部、５１…ＨＷ在庫ＤＢ、５２…ＳＷ在庫ＤＢ、５３…ＨＷ在庫仮押えＤＢ、５４…ＳＷ在庫仮押えＤＢ、
６０…契約管理部、６１…契約内容管理ＤＢ、
７０…システム構築部。
【技術分野】
【０００１】
本発明は、ＩＴ関連資産のライセンス管理の技術に関し、特に、クラウドコンピューティングサービス等において利用される仮想マシンや仮想サーバ上で稼働するソフトウェアのライセンスの有無をチェックするライセンスチェックシステムおよびリソースプール管理システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
近年では、例えばデータセンターなどの設備に多数のサーバ機器やネットワーク機器などのコンピュータリソースからなるシステム環境を構築してリソースプールとして管理し、顧客が必要とする分のリソースを仮想マシンや仮想サーバの形で提供するクラウドコンピューティングサービスが普及してきている。
【０００３】
このようなサービスを提供する事業者等では、顧客からのリソース使用の要求に適時に対応することが可能となるよう、予め未使用・未割当てのハードウェア（ＨＷ）やソフトウェア（ＳＷ）を在庫として保持・管理しておき、顧客とのサービスに係る契約の成立やリソースの使用要求（システムの変更要求）などに応じて、在庫から必要なリソースを確保してリソースプールに展開したりシステムを構築したりすることが行われる。
【０００４】
このとき、ソフトウェアリソースについては、ソフトウェアの現物ではなくライセンスを在庫として管理する必要がある。このライセンスの管理は、リソースを提供する事業者等が一元的に行う必要がある。ソフトウェアのライセンス管理の手法としては、例えば、企業における各従業員等のクライアント端末に導入されたソフトウェアのライセンスを自動的にチェックして管理するというようなことは一般的に行われており、そのための製品等も提供されている。
【０００５】
例えば、特開２００４−１１８５８４号公報（特許文献１）には、会社等の組織が有するソフトウェアライセンスに関するライセンス情報をデータベースに記憶し、また、組織内の社内端末で使用されているソフトウェアに関するインベントリ情報を取得してデータベースに記憶し、データベースに記憶されるライセンス情報について、ソフトウェア毎のライセンス数を計数し、また、データベースに記憶されるインベントリ情報について、ソフトウェア毎の使用数を計数し、各ソフトウェアについてライセンス数と使用数を比較し、使用数がライセンス数より大きいソフトウェアを検出した場合、検出内容を示す警告メールを担当者宛で送信することで、組織で使用するソフトウェアのライセンス管理を効率良く行うことができるライセンス管理サーバが記載されている。
【０００６】
また、特開２００８−１４６３９０号公報（特許文献２）には、インベントリ収集機能及び使用許諾情報収集機能を備えた情報収集処理部、使用許諾情報から許諾条件を抽出する使用許諾条件抽出処理部、抽出した許諾条件を判別する使用許諾内容判別処理部、保有数チェック機能及び使用可能数チェック機能を備えた使用状況検証処理部、および各種のＤＢを具備し、システムのソフトウェアの使用状態の検証時に、使用ソフトウェアと使用ソフトウェアに係る使用許諾情報との相違を検出することで精度の高いライセンス管理を行うことができるソフトウェアライセンス管理システムが記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１１８５８４号公報
【特許文献２】特開２００８−１４６３９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
仮想マシンや仮想サーバの形で多数のコンピュータリソースをクラウドコンピューティングサービスとして提供する事業者等において、ソフトウェアのライセンスの管理を行うことは容易ではない。仮想マシンや仮想サーバ上で稼働するソフトウェアのライセンス形態は、物理ＣＰＵや仮想ＣＰＵの数、コア数といった（仮想）ハードウェア構成に依存する場合が多く、仮想マシンや仮想サーバのシステム構成如何によってライセンスの消費数も変動するためである。
【０００９】
このため、特許文献１に記載されているようにソフトウェアのインベントリ情報から単純にライセンス使用数を求めることができない。また、特許文献２に記載されているような技術を使用したとしても使用許諾の全文から使用許諾条件が判別可能な場合はあるものの、それに基づいてソフトウェアが実際に導入されている（仮想）ハードウェア構成を考慮した上でのライセンス消費数を求めることは困難である。
【００１０】
従って従来では、クラウドコンピューティングサービスを提供するリソースプールにおけるソフトウェアのライセンス数のチェックを自動で行うような仕組みは存在せず、システム管理者等により手動で行って管理するのが一般的であった。しかし、チェックするリソースの数が多く、ソフトウェア毎のライセンスの許諾条件のバリエーションも多く複雑であるため、大きな作業負荷とコストを要していた。
【００１１】
そこで本発明の目的は、仮想マシンや仮想サーバ上で稼働するソフトウェアについて、ライセンスの消費数や必要数を効率的に算出することができるライセンスチェックシステムおよび当該ライセンスチェックシステムを有するリソースプール管理システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１２】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１３】
本発明の代表的な実施の形態によるライセンスチェックシステムは、複数の物理サーバ上で稼働する仮想マシンおよび各仮想マシン上で稼働するソフトウェアからなるシステム環境であるリソースプールにおいてソフトウェア毎に実際に消費されているライセンスの数を把握するライセンスチェックシステムであって、以下の特徴を有するものである。
【００１４】
すなわち、ライセンスチェックシステムは、前記リソースプールにおいて稼働中のシステムの構成情報をディスカバリして、物理サーバの構成情報を含むハードウェア構成、物理サーバ上で稼働する仮想マシンの構成情報を含む仮想ハードウェア構成および仮想マシン上で稼働するソフトウェアの情報を含む仮想ソフトウェア構成の各情報を取得し、これらをそれぞれ、ＨＷ構成記録手段、仮想ＨＷ構成記録手段および仮想ＳＷ構成記録手段に記録して保持する構成管理部と、前記構成管理部から前記ハードウェア構成、前記仮想ハードウェア構成および前記仮想ソフトウェア構成の情報を取得し、これらの情報に基づいて、前記リソースプールにおいて稼働中のシステム環境で消費されている各ソフトウェアのライセンス数を、各ソフトウェアのライセンス体系の特性毎にカテゴライズして予め定義されたライセンス計算ロジックに従って算出し、ライセンス状況記録手段に記録するライセンスチェック部とを有することを特徴とするものである。
【００１５】
また、本発明は、上記のライセンスチェックシステムを有し、顧客からの要求に基づく構築仕様の内容に従って、前記リソースプールにおいてハードウェアおよびソフトウェアのリソースを展開してシステムを構築してサービスとして提供するリソースプール管理システムにも適用することができる。
【発明の効果】
【００１６】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１７】
本発明の代表的な実施の形態によれば、仮想マシンや仮想サーバ上で稼働するソフトウェアなど、物理的もしくは仮想的なハードウェア構成に依存してライセンスの消費数が変動するソフトウェアについて、ライセンスの消費数や必要数を効率的に算出することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施の形態であるリソースプール管理システムの構成例について概要を示した図である。
【図２】本発明の一実施の形態におけるＨＷマスタＤＢのデータ構成の例について示した図である。
【図３】本発明の一実施の形態におけるＳＷマスタＤＢのデータ構成の例について示した図である。
【図４】本発明の一実施の形態における資産台帳ＤＢのデータ構成の例について示した図である。
【図５】本発明の一実施の形態におけるＨＷ構成ＤＢのデータ構成の例について示した図である。
【図６】本発明の一実施の形態における仮想ＨＷ構成ＤＢのデータ構成の例について示した図である。
【図７】本発明の一実施の形態における仮想ＳＷ構成ＤＢのデータ構成の例について示した図である。
【図８】本発明の一実施の形態におけるライセンス状況ＤＢのデータ構成の例について示した図である。
【図９】本発明の一実施の形態におけるＨＷ在庫ＤＢのデータ構成の例について示した図である。
【図１０】本発明の一実施の形態におけるＳＷ在庫ＤＢのデータ構成の例について示した図である。
【図１１】本発明の一実施の形態におけるＨＷ在庫仮押えＤＢのデータ構成の例について示した図である。
【図１２】本発明の一実施の形態におけるＳＷ在庫仮押えＤＢのデータ構成の例について示した図である。
【図１３】本発明の一実施の形態における契約内容管理ＤＢのデータ構成の例について示した図である。
【図１４】本発明の一実施の形態におけるハードウェアについての在庫情報を最新の状態に更新する処理の流れの例について概要を示したフローチャートである。
【図１５】本発明の一実施の形態におけるソフトウェアについての在庫情報を最新の状態に更新する処理の流れの例について概要を示したフローチャートである。
【図１６】本発明の一実施の形態におけるライセンスチェック処理の流れの例について概要を示したフローチャートである。
【図１７】（ａ）〜（ｄ）は、本発明の一実施の形態におけるライセンス計算パターンの判断基準の１つとなるソフトウェアのグルーピングパターンの概念の例について示した図である。
【図１８】（１）〜（４）は、本発明の一実施の形態におけるライセンス計算パターンの別の判断基準となるライセンス計算グループの概念の例について示した図である。
【図１９】本発明の一実施の形態におけるグルーピングパターンとライセンス計算グループをマトリクス化し、ライセンス計算パターンを割当てた例を示した図である。
【図２０】本発明の一実施の形態におけるハードウェアリソースについて在庫を仮押えする処理の流れの例について概要を示したフローチャートである。
【図２１】本発明の一実施の形態におけるソフトウェアのライセンスについて在庫を仮押えする処理の流れの例について概要を示したフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００２０】
本発明の一実施の形態であるリソースプール管理システムは、複数の物理サーバ上で稼働する仮想マシンおよび各仮想マシン上で稼働するソフトウェアからなるシステム環境であるリソースプールを構築し、顧客が必要とする分のリソースを仮想マシンの形でリソースプール上で提供するクラウドコンピューティングサービスの実装において利用されるシステムである。このリソースプール管理システムは、リソースプールにおいてソフトウェア毎に実際に消費されているライセンスの数を把握するライセンスチェックシステムとしての機能を含む。
【００２１】
リソースプール管理システムでは、顧客からのリソース使用の要求に適時に対応することが可能となるよう、予め未使用・未割当てのハードウェアやソフトウェアの資産を在庫として保持・管理しておき、顧客とのサービスに係る契約の成立やリソースの使用要求などに応じて、在庫から必要なリソースを確保してリソースプールに展開してシステムを構築する。このとき、特にソフトウェアについては、在庫を現物ではなくライセンスの残数として把握する必要がある。したがって、稼働中のシステム構成において消費されている各ソフトウェアのライセンス数をライセンス体系の特性に応じて適切に算出して、保有するライセンス数との比較により在庫に反映させるとともに、稼働中のシステムがライセンス違反となっていないことを確認する。
【００２２】
また、顧客との契約等に基づいて新たにシステムを構築する際に、システム構成に応じた適切なライセンス数を在庫から引当てて確保した上で構築する。ライセンス数が不足しそうであることを検知した場合は、例えば購買担当者等に通知してライセンスの購入を促してもよい。以上のような仕組みにより、クラウドコンピューティング環境でのリソースプールのような大規模なシステム環境においてライセンスの管理を効率的に行うことを可能とする。
【００２３】
＜システム構成＞
図１は、本発明の一実施の形態であるリソースプール管理システムの構成例について概要を示した図である。リソースプール管理システム１は、図示しないＷｅｂサーバシステムやアプリケーション等によって提供されるサービスポータル３のサイトを介して、システム担当者４や営業担当者５、購買担当者６などのユーザからのアクセスを受け、クラウドコンピューティングサービスを提供するための多数のコンピュータリソースからなるリソースプール２について、システムの構築や構成の管理、顧客との契約の管理、ソフトウェアのライセンスや、リソースの在庫の管理などを行うシステムである。
【００２４】
リソースプール管理システム１は、例えば、１台以上のサーバ機器によって構成され、ソフトウェアプログラムによって実現される資産管理部２０、構成管理部３０、ライセンスチェック部４０、在庫管理部５０、契約管理部６０およびシステム構築部７０の各部を有する。これら各部は、それぞれを独立したシステムとして別個のサーバ機器上で実装してもよいし、複数を同一のサーバ機器上で共存させて実装してもよい。
【００２５】
資産管理部２０は、リソースプール管理システム１によって管理されるハードウェア／ソフトウェアリソース（資産）を資産台帳データベース（ＤＢ）２１に登録・保持することで管理する。資産台帳ＤＢ２１への資産の登録は、例えば、購買担当者６が購入した資産に関する情報をサービスポータル３によって提供されるエントリー画面等から入力することで行われる。図示しない他の購買システム等との連携により自動的に登録されるようにしてもよい。なお、ハードウェアおよびソフトウェアについてのマスタ情報は、ＨＷマスタＤＢ１１およびＳＷマスタＤＢ１２に登録される。また、資産管理部２０は、例えば、日次の処理により、資産台帳ＤＢ２１に登録されている各資産についてベンダー等との保守契約の期間をチェックし、保守契約が終了もしくは終了しそうなものについて購買担当者６等に電子メールなどによりアラートを通知する。
【００２６】
構成管理部３０は、リソースプール２において稼働中のシステムのコンピュータリソースの構成をＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２および仮想ＳＷ構成ＤＢ３３にそれぞれ保持して管理する。これらの構成情報については、例えば、構成管理部３０が日次でリソースプール２の構成を公知技術を利用してディスカバリし、取得した構成情報を、ＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２および仮想ＳＷ構成ＤＢ３３にそれぞれ格納する。また、取得した構成情報に基づいて、消費されているソフトウェアのライセンス数を算出する処理を後述するライセンスチェック部４０に要求する。
【００２７】
ライセンスチェック部４０は、構成管理部３０からの要求に対して、ＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２および仮想ＳＷ構成ＤＢ３３のデータに基づいて、リソースプール２において稼働中のシステムで消費されているソフトウェアのライセンス数を、ソフトウェア毎のライセンス体系の特性を考慮して定義されたライセンス計算ロジック４２に従って算出し、ライセンス状況ＤＢ４１に記録する。ここで、消費されているライセンス数が、資産管理部２０の資産台帳ＤＢ２１に保持された保有リソース量（ライセンス数）を超える、もしくは超えそうな場合は、購買担当者６等に電子メールなどによりアラートを通知する。
【００２８】
また、ライセンスチェック部４０は、後述する在庫管理部５０から要求されたソフトウェアに対して、当該ソフトウェアをリソースプール２の対象サーバ上に新たに導入・展開する際に消費する（必要となる）ライセンス数を算出する処理も行う。
【００２９】
在庫管理部５０は、リソースプール２において未使用（顧客に提供するサービスとして未割当て）のハードウェアおよびソフトウェアのリソースを在庫としてその量をＨＷ在庫ＤＢ５１およびＳＷ在庫ＤＢ５２に保持して管理する。例えば、日次の処理により、構成管理部３０のＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２からハードウェアリソースの使用量を算出し、資産管理部２０の資産台帳ＤＢ２１から取得した保有リソース量との差分からハードウェアの在庫数を算出する。また、ライセンスチェック部４０のライセンス状況ＤＢ４１から取得したソフトウェアのライセンスの消費数と、資産台帳ＤＢ２１から取得した保有ライセンス数との差分からソフトウェアのライセンスの在庫数を算出する。算出した在庫数の情報は、電子メールなどにより営業担当者５に通知するようにしてもよい。
【００３０】
また、在庫管理部５０は、後述するシステム構築部７０から、リソースプール２へのシステムの新たな展開・構築のために必要となるリソースの仮押えの要求を受けて、ＨＷ在庫ＤＢ５１およびＳＷ在庫ＤＢ５２に十分な在庫がある場合に、これをＨＷ在庫仮押えＤＢ５３およびＳＷ在庫仮押えＤＢ５４に登録して引当てる。このとき、ソフトウェアについては、ライセンス体系に応じた適切なライセンス数を引当てるため、ライセンスチェック部４０に対して対象のソフトウェアについて必要なライセンス数の算出を要求する。
【００３１】
契約管理部６０は、リソースプール２によるクラウドコンピューティングサービスの提供について顧客と締結された契約の内容を契約内容管理ＤＢ６１に登録・保持することで管理する。また、契約内容に基づいて、リソースプール２において後述するシステム構築部７０が構築するシステムの仕様を構築仕様１３として出力する。契約内容管理ＤＢ６１への契約内容の登録は、例えば、営業担当者５が顧客と締結した契約の内容に関する情報をサービスポータル３によって提供される契約情報入力画面等から入力することで行われる。図示しない他の契約管理システム等との連携により自動的に登録されるようにしてもよい。
【００３２】
システム構築部７０は、契約管理部６０から出力された構築仕様１３の内容に従って、リソースプール２においてハードウェア／ソフトウェアのリソースを展開・設定してシステムを構築する。この中には、システムの新規構築だけでなく、既存システムに対するリソースの追加や変更も含まれる。システムの構築の際には、リソースプール２に対する変更管理の要請から、システム担当者４等により変更に対する承認処理が行われる。
【００３３】
また、構築に際しては、システム構成に応じて必要となるリソースを予め確保した上で構築するために、在庫管理部５０に対してリソース毎に在庫の仮押え（引当て）を要求する。在庫の仮押えができなかった場合は、例えば、システムの構築をいったん留保した上で必要なリソースの購入等を行う。仮押えが認められた場合は、実際にシステムを構築し、正常終了後に仮押えした在庫を確定させる。
【００３４】
上記のようなリソースプール管理システム１の構成において、例えば、構成管理部３０およびライセンスチェック部４０をあわせて独立したシステムとして構成することで、リソースプール２において実際に消費されているソフトウェアライセンスの数を適切に把握するライセンスチェックシステムとすることも可能である。
【００３５】
＜データ構成＞
以下では、本発明の一実施の形態であるリソースプール管理システム１における各データベースもしくはテーブルの構成について説明する。図２は、ＨＷマスタＤＢ１１のデータ構成の例について示した図である。ＨＷマスタＤＢ１１は、リソースプール２で使用されているハードウェアについての属性情報を保持するマスタテーブルであり、例えば、ハードウェアＩＤ、ハードウェア種別、メーカー、型番、スペック、登録日などの項目を有する。キー項目はハードウェアＩＤである。
【００３６】
ハードウェアＩＤの項目は、対象のハードウェアを一意に識別するためのＩＤの情報を保持する。ハードウェア種別の項目は、ハードウェアの種別（例えば、ストレージやサーバ、ネットワーク機器など）を識別するための情報を保持する。メーカー、型番、スペックの項目は、それぞれ、対象のハードウェアのメーカーやベンダーの情報、型番や製品番号等の情報、各種スペックについての情報を保持する。登録日の項目は、対象のハードウェアの情報が当該ＤＢに登録された日時の情報を保持する。
【００３７】
図３は、ＳＷマスタＤＢ１２のデータ構成の例について示した図である。ＳＷマスタＤＢ１２は、リソースプール２で使用されているソフトウェアについての属性情報を保持するマスタテーブルであり、例えば、ソフトウェアＩＤ、ソフトウェア名、メーカー、型番、バージョン、エディション、オプション、ライセンス計算パターン、検索対象外フラグ、親ソフトウェアＩＤ、物理サーバ依存ライセンスフラグ、仮押えライセンス数、在庫仮押え特殊ロジックＮｏなどの項目を有する。キー項目はソフトウェアＩＤである。
【００３８】
ソフトウェアＩＤの項目は、対象のソフトウェアを一意に識別するためのＩＤの情報を保持する。ソフトウェア名、メーカー、型番の項目は、それぞれ、対象のソフトウェアの製品名、メーカーやベンダーの情報、型番や製品番号等の情報を保持する。バージョン、エディションの項目は、対象のソフトウェアのバージョン（例えば、バージョン番号、リリース番号、リビジョン番号、モディフィケーション番号などを含む）およびエディション（例えば、「エンタープライズエディション」や「プロフェッショナルエディション」など）の情報を保持する。オプションの項目は、対象のソフトウェアについて追加購入しているオプションを識別する情報を保持する。
【００３９】
ライセンス計算パターンは、対象のソフトウェアについてライセンスの消費数を計算する際の計算パターン（図１におけるライセンス計算ロジック４２）を識別する情報を保持する。仮想マシンに導入されて稼働するソフトウェアでは、システム構成によってライセンスの消費数の計算方法が異なるなど複雑なライセンス体系を有するが、本実施の形態では、後述するように、ソフトウェア毎にライセンス体系に応じてライセンスの消費数の計算方法（ロジック）をいくつかのパターンにカテゴライズして予め割り当てておく。特殊な計算方法をとるソフトウェアについては、対応する計算ロジックをライセンス計算ロジック４２を追加する形で設定し、パターンを割り当てることも可能である。
【００４０】
検索対象フラグの項目は、対象のソフトウェアについてはライセンス数計算パターンを検索する際の検索対象から除外し、個別にライセンス消費数の計算を行わないことを指定するためのフラグの情報を保持する。例えば、同じソフトウェアでバージョンやエディションが異なるものが複数ある場合に、これらのライセンス消費数の計算パターンが全て同じで個別にライセンス数を計算する必要がない場合には、代表となるいずれか１つのバージョンもしくはエディションで１回ライセンス消費数を計算すればよいため、他のバージョンやエディションで重ねてライセンス消費数の計算を行わないようにするために利用することができる。
【００４１】
また、親ソフトウェアＩＤの項目は、対象のソフトウェアのライセンス消費数の計算の際に、例えば後述するように、バージョンやエディションに関わりなくソフトウェアの単位でライセンスを消費する体系を有する場合に、ライセンスの消費数をまとめて計算する対象（親）となるバージョンやエディションを有するソフトウェアのＩＤの情報を保持する。この場合、対象のソフトウェアのライセンスの諸費数は、親となるソフトウェアのライセンスの消費数としてカウントされる。
【００４２】
物理サーバ依存ライセンスフラグの項目は、後述するように図１の在庫管理部５０において対象のソフトウェアについて在庫の仮押えを行う際に、対象のソフトウェアが、導入されている物理サーバの数に依存してライセンス消費数が計算されるタイプであることを識別可能とするためのフラグである。この値がｆａｌｓｅである場合は、導入されている仮想マシンの数に依存してライセンス消費数が計算されるタイプであることを示す。
【００４３】
仮押えライセンス数の項目は、対象のソフトウェアについて在庫の仮押えを行う際に、物理サーバもしくは仮想マシン（上述の物理サーバ依存ライセンスフラグによって決定される）毎に必要なライセンスの単位数の情報を保持する。この情報は、顧客に対してサービスメニューとして予め決められた種類のシステム構成やオプションから選択させる契約方法をとることによって、事前にマスタデータとして定義しておくことが可能である。在庫仮押え特殊ロジックＮｏは、対象のソフトウェアが、在庫の仮押えを行う際に特殊なロジックを必要とするものである場合に、その特殊ロジックを特定するための情報を保持する。これにより、予め定義しておいた対応する特殊ロジックを呼び出して仮押えの処理を行うことができる。
【００４４】
図４は、資産台帳ＤＢ２１のデータ構成の例について示した図である。資産台帳ＤＢ２１は、リソースプール管理システム１によって管理されるハードウェア／ソフトウェア資産についての情報を台帳として保持するテーブルであり、例えば、資産管理ＩＤ、種別、資産ＩＤ、見積番号、保守契約番号、保守契約期間、保有ライセンス数などの項目を有する。キー項目は、資産管理ＩＤ、種別および資産ＩＤである。
【００４５】
資産管理ＩＤの項目は、対象のリソースについて、全てのハードウェア／ソフトウェアリソースの中で一意に割り振られたＩＤの情報を保持する。種別の項目は、対象のリソースの種別（例えば、「ハードウェア」や「ソフトウェア」）の情報を保持する。資産ＩＤの項目は、対象のリソースに割り振られているＩＤの情報を保持する。対象のリソースがハードウェアの場合は図２のＨＷマスタＤＢ１１におけるハードウェアＩＤ、ソフトウェアの場合は図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤに設定された値となる。
【００４６】
見積番号の項目は、対象のリソースを購入した際にメーカー等から取得した見積を特定する情報を保持する。保守契約番号および保守契約期間の項目は、それぞれ、対象のリソースについてメーカー等と締結している保守契約を特定する情報およびその期間の情報を保持する。これらの情報により、図１の資産管理部２０において、対象のリソースについて保守契約期間が終了しているか否かを確認し、システム担当者４や購買担当者６等に保守契約の更新の要否を問い合わせたりすることができる。保有ライセンス数の項目は、対象のリソースがソフトウェアの場合に保有しているライセンス数の情報を保持する。
【００４７】
図５は、ＨＷ構成ＤＢ３１のデータ構成の例について示した図である。ＨＷ構成ＤＢ３１は、リソースプール２において稼働中のシステムの物理ハードウェア（サーバ）の構成情報を保持するテーブルであり、例えば、サーバＩＤ、サーバ名、ホスト名、ＩＰアドレス、ＣＰＵ数、ＣＰＵコア数、メモリサイズなどの情報を保持する。キー項目はサーバＩＤである。
【００４８】
サーバＩＤの項目は、対象の物理サーバを識別するＩＤの情報を保持する。サーバ名、ホスト名およびＩＰアドレスの項目は、それぞれ、対象の物理サーバに設定されたサーバ名、ホスト名の情報および割り当てられたＩＰアドレスの情報を保持する。ＣＰＵ数およびＣＰＵコア数の情報は、それぞれ、対象の物理サーバが有するＣＰＵおよび物理コアの数の情報を保持する。メモリサイズの項目は、対象の物理サーバが有する物理メモリのサイズの情報を保持する。
【００４９】
図６は、仮想ＨＷ構成ＤＢ３２のデータ構成の例について示した図である。仮想ＨＷ構成ＤＢ３２は、リソースプール２において物理サーバ上で稼働中の仮想ハードウェア（仮想マシン）の構成情報を保持するテーブルであり、例えば、仮想マシンＩＤ、サーバＩＤ、テナントＩＤ、アプライアンスＩＤ、ホスト名、ＩＰアドレス、ｖＣＰＵ数、仮想メモリサイズ、ローカルディスクサイズ、インシデントＩＤなどの項目を有する。キー項目は仮想マシンＩＤである。
【００５０】
仮想マシンＩＤの項目は、対象の仮想マシンを識別するＩＤの情報を保持する。サーバＩＤの項目は、対象の仮想マシンが稼働する物理サーバのＩＤの情報を保持する。このサーバＩＤの項目は、図５のＨＷ構成ＤＢ３１におけるサーバＩＤの項目と同様である。テナントＩＤおよびアプライアンスＩＤの項目は、それぞれ、対象の仮想マシンを利用している顧客（テナント）および当該顧客が契約により選択したシステム構成のパターン（アプライアンス）を特定するＩＤの情報を保持する。
【００５１】
ホスト名およびＩＰアドレスの項目は、それぞれ、対象の仮想マシンに設定されたホスト名および割り当てられたＩＰアドレスの情報を保持する。ｖＣＰＵ数、仮想メモリサイズおよびローカルディスクサイズの項目は、それぞれ、対象の仮想マシンに割り当てられたｖＣＰＵ（仮想ＣＰＵ）数、仮想メモリのサイズおよびローカルディスクのサイズの情報を保持する。インシデントＩＤの項目は、対象の仮想マシンを構築して稼働させたインシデントを識別するＩＤの情報を保持する。
【００５２】
図７は、仮想ＳＷ構成ＤＢ３３のデータ構成の例について示した図である。仮想ＳＷ構成ＤＢ３３は、リソースプール２において稼働中の仮想マシン上で稼働するソフトウェアの情報を保持するテーブルであり、例えば、仮想マシンＩＤ、ソフトウェアＩＤ、サーバＩＤ、インシデントＩＤなどの項目を有する。キー項目は仮想マシンＩＤおよびソフトウェアＩＤである。
【００５３】
仮想マシンＩＤの項目は、対象のソフトウェアが稼働する仮想マシンを識別するＩＤの情報を保持する。この仮想マシンＩＤの項目は、図６の仮想ＨＷ構成ＤＢ３２における仮想マシンＩＤの項目と同様である。ソフトウェアＩＤの項目は、対象のソフトウェアを識別するＩＤの情報を保持する。このソフトウェアＩＤの項目は、図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤの項目と同様である。サーバＩＤの項目は、対象のソフトウェアが稼働する物理サーバを識別するＩＤの情報を保持する。このサーバＩＤの項目は、図５のＨＷ構成ＤＢ３１におけるサーバＩＤの項目と同様である。インシデントＩＤの項目は、対象のソフトウェアを導入して稼働させたインシデントを識別するＩＤの情報を保持する。
【００５４】
図８は、ライセンス状況ＤＢ４１のデータ構成の例について示した図である。ライセンス状況ＤＢ４１は、リソースプール２において稼働中のシステムで消費されているソフトウェアのライセンス数の情報を保持するテーブルであり、例えば、ソフトウェアＩＤ、ライセンス消費数などの項目を有する。キー項目はソフトウェアＩＤである。ソフトウェアＩＤの項目は、対象のソフトウェアを識別するＩＤの情報を保持する。このソフトウェアＩＤの項目は、図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤの項目と同様である。ライセンス消費数の項目は、対象のソフトウェアについて図１におけるライセンスチェック部４０によって算出されたライセンスの消費数の情報を保持する。
【００５５】
図９は、ＨＷ在庫ＤＢ５１のデータ構成の例について示した図である。ＨＷ在庫ＤＢ５１は、リソースプール２において未使用（顧客に提供するサービスとして未割当て）のハードウェアリソースの量を在庫情報として保持するテーブルであり、例えば、サーバＩＤ、ｖＣＰＵ残数、仮想メモリ残数などの項目を有する。キー項目はサーバＩＤである。サーバＩＤの項目は、対象のハードウェアリソースを有する物理サーバを識別するＩＤの情報を保持する。このサーバＩＤの項目は、図５のＨＷ構成ＤＢ３１におけるサーバＩＤの項目と同様である。ｖＣＰＵ残数および仮想メモリ残数の項目は、それぞれ、対象のサーバにおいて割当て可能なｖＣＰＵの数および仮想メモリのサイズの情報を在庫情報として保持する。
【００５６】
図１０は、ＳＷ在庫ＤＢ５２のデータ構成の例について示した図である。ＳＷ在庫ＤＢ５２は、リソースプール２において未使用のソフトウェアのライセンスの数を在庫情報として保持するテーブルであり、例えば、ソフトウェアＩＤ、ライセンス在庫数などの項目を有する。キー項目はソフトウェアＩＤである。ソフトウェアＩＤの項目は、対象のソフトウェアを識別するＩＤの情報を保持する。このソフトウェアＩＤの項目は、図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤの項目と同様である。ライセンス在庫数の項目は、対象のソフトウェアにおいて利用可能なライセンス数を在庫情報として保持する。
【００５７】
図１１は、ＨＷ在庫仮押えＤＢ５３のデータ構成の例について示した図である。ＨＷ在庫仮押えＤＢ５３は、リソースプール２においてシステムを新たに展開・構築する際に、必要なハードウェアリソースを在庫から仮押えした内容についての情報を保持するテーブルであり、例えば、サーバＩＤ、仮想マシンＩＤ、消費ｖＣＰＵ数、消費仮想メモリ数、インシデントＩＤなどの項目を有する。キー項目はサーバＩＤおよび仮想マシンＩＤである。
【００５８】
サーバＩＤおよび仮想マシンＩＤの項目は、それぞれ、対象のハードウェアリソースを有する物理サーバおよび構築対象の仮想マシンを識別するＩＤの情報を保持する。このサーバＩＤおよび仮想マシンＩＤの項目は、それぞれ、図５のＨＷ構成ＤＢ３１におけるサーバＩＤの項目および図６の仮想ＨＷ構成ＤＢ３２における仮想マシンＩＤの項目と同様である。消費ｖＣＰＵ数および消費仮想メモリ数の項目は、それぞれ、構築対象の仮想マシン上で必要なハードウェアリソース量として仮押えしたｖＣＰＵの数および仮想メモリのサイズの情報を保持する。インシデントＩＤの項目は、対象のハードウェアリソースを仮押えさせたインシデントを識別するＩＤの情報を保持する。
【００５９】
図１２は、ＳＷ在庫仮押えＤＢ５４のデータ構成の例について示した図である。ＳＷ在庫仮押えＤＢ５４は、リソースプール２においてシステムを新たに展開・構築する際に、必要なソフトウェアのライセンスを在庫から仮押えした内容についての情報を保持するテーブルであり、例えば、ソフトウェアＩＤ、ライセンス消費数、インシデントＩＤなどの項目を有する。キー項目はソフトウェアＩＤである。
【００６０】
ソフトウェアＩＤの項目は、対象のソフトウェアを識別するＩＤの情報を保持する。このソフトウェアＩＤの項目は、図３のＳＷマスタＤＢ１２におけるソフトウェアＩＤの項目と同様である。ライセンス消費数の項目は、対象のソフトウェアについて必要なリソースとして仮押さえしたライセンス数の情報を保持する。インシデントＩＤの項目は、対象のソフトウェアのライセンスを仮押えさせたインシデントを識別するＩＤの情報を保持する。
【００６１】
図１３は、契約内容管理ＤＢ６１のデータ構成の例について示した図である。契約内容管理ＤＢ６１は、リソースプール２によるクラウドコンピューティングサービスの提供について顧客と締結された契約の内容を保持するテーブルであり、例えば、契約ＩＤ、テナントＩＤ、適用開始日、適用終了日、アプライアンスＩＤ、初期費用、月額費用、インシデントＩＤなどの項目を有する。キー項目は契約ＩＤおよびテナントＩＤである。
【００６２】
契約ＩＤの項目は、顧客との契約を一意に識別するためのＩＤの情報を保持する。テナントＩＤの項目は、対象の契約を締結した顧客（テナント）を識別するためのＩＤの情報を保持する。このテナントＩＤの項目は、図６の仮想ＨＷ構成ＤＢ３２におけるテナントＩＤの項目と同様である。なお、各テナントの名称や連絡先等の属性の情報は別途テナントのマスタテーブルに保持しておいてもよい。適用開始日および適用終了日の項目は、それぞれ、対象の契約が適用される期間の開始日および終了日の情報を保持する。
【００６３】
アプライアンスＩＤの項目は、対象のテナントが対象の契約により選択したシステム構成のパターン（アプライアンス）を識別するＩＤの情報を保持する。このアプライアンスＩＤの項目は、図６の仮想ＨＷ構成ＤＢ３２におけるアプライアンスＩＤの項目と同様である。顧客はアプライアンスとしてシステムの構成のパターンを選択することで、簡便・効率的にサービスを利用することができる。初期費用および月額費用の項目は、それぞれ、対象の契約における料金体系の内容を保持する。インシデントＩＤの項目は、対象の契約およびアプライアンスに基づいてリソースプール２にシステムを展開・構築するためのインシデントを識別するＩＤの情報を保持する。
【００６４】
なお、上述の図２〜図１３で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。
【００６５】
＜リソースプール管理処理−在庫更新およびライセンスチェック＞
以下では、本発明の一実施の形態であるリソースプール管理システム１における管理処理の内容について説明する。まず、リソースプール２で稼働中のシステムの構成情報に基づいて、ハードウェア／ソフトウェアのリソースの在庫情報を最新の状態に更新するとともに、ソフトウェアのライセンスの消費状況をチェックし、必要なライセンスを保有していることを確認する処理について説明する。この処理は例えば日次処理として実行される。
【００６６】
前提として、図１の構成管理部３０での日次処理により、予めリソースプール２において稼働中のシステムのコンピュータリソースの構成をディスカバリし、取得した構成情報がＨＷ構成ＤＢ３１、仮想ＨＷ構成ＤＢ３２および仮想ＳＷ構成ＤＢ３３にそれぞれ保持されているものとする。
【００６７】
図１４は、ＨＷ在庫ＤＢ５１に保持するハードウェアについての在庫情報を最新の状態に更新する処理の流れの例について概要を示したフローチャートである。ハードウェアの在庫更新処理を開始すると、まず、図１における在庫管理部５０は、ＨＷ構成ＤＢ３１に保持されている各物理サーバについて処理を行うループ処理を開始する。当該ループ処理では、対象の物理サーバのＣＰＵコアの総数およびメモリサイズの情報（保有リソース量）を取得する（Ｓ０１）。次に、仮想ＨＷ構成ＤＢ３２から、対象の物理サーバ上で稼働する各仮想マシンのレコードを抽出し、これらのｖＣＰＵ数および仮想メモリサイズの合計（消費リソース量）を算出する（Ｓ０２）。
【００６８】
その後、ステップＳ０１で取得したＣＰＵコア数とメモリサイズ、およびステップＳ０２で取得したｖＣＰＵ数と仮想メモリサイズとの差分によりＣＰＵ残数と仮想メモリ残数を算出し、ＨＷ在庫ＤＢ５１に出力して内容を更新する（Ｓ０３）。その後、次の物理サーバの処理に移る。全ての物理サーバについてのループ処理が終了すると、ハードウェアの在庫更新処理を終了する。
【００６９】
図１５は、ＳＷ在庫ＤＢ５２に保持するソフトウェアについての在庫情報を最新の状態に更新する処理の流れの例について概要を示したフローチャートである。ソフトウェアの在庫更新処理を開始すると、まず、図１における在庫管理部５０は、ライセンスチェック部４０により、各ソフトウェアについてのライセンスの消費数を算出してライセンス不足の有無をチェックするライセンスチェック処理を実行する（Ｓ１１）。当該処理は、在庫更新処理とは非同期で予め実行しておいてもよい。なお、当該処理の内容については後述する。
【００７０】
次に、仮想ＳＷ構成ＤＢ３３に保持されている各ソフトウェアについて処理を行うループ処理を開始する。当該ループ処理では、対象のソフトウェアについて資産台帳ＤＢ２１から保有ライセンス数を取得する（Ｓ１２）。次に、対象のソフトウェアについてステップＳ１１によって算出されたライセンスの消費数をライセンス状況ＤＢ４１から取得する（Ｓ１３）。次に、その後、ステップＳ１２で取得した保有ライセンス数とステップＳ１３で取得した消費ライセンス数との差分によりライセンス在庫数を算出し、ＳＷ在庫ＤＢ５２に出力して内容を更新する（Ｓ１４）。その後、次のソフトウェアの処理に移る。全てのソフトウェアについてのループ処理が終了すると、ソフトウェアの在庫更新処理を終了する。
【００７１】
なお、在庫管理部５０は、更新されたハードウェア／ソフトウェアの在庫情報を営業担当者５等に電子メール等により通知するようにしてもよい。また、在庫数が所定の閾値よりも少ないことを検知した場合は購買担当者６等にその旨の警告を電子メール等により通知するようにしてもよい。
【００７２】
図１６は、図１５のステップＳ１１におけるライセンスチェック処理の流れの例について概要を示したフローチャートである。当該処理では、構成管理部３０が保有するリソースプール２におけるシステムの構成情報に基づいて、ソフトウェアのライセンス体系の特性に応じてライセンスの消費数を算出し、資産台帳ＤＢ２１の情報と照合することでライセンス不足の有無をチェックする処理を行う。ライセンスチェック処理を開始すると、まず、ライセンスチェック部４０は、仮想ＳＷ構成ＤＢ３３に保持されている各ソフトウェアについて処理を行うループ処理を開始する。
【００７３】
当該ループ処理では、対象のソフトウェアについてＳＷマスタＤＢ１２からライセンス計算パターンの情報を取得する（Ｓ２１）。次に、取得したライセンス計算パターンに対応するライセンス計算ロジック４２を取得し、これに基づいて対象のソフトウェアのライセンスの消費数を算出する（Ｓ２２）。当該処理の内容については後述する。次に、算出したライセンスの消費数を、資産台帳ＤＢ２１の保有ライセンス数と照合し、ライセンス不足の有無をチェックする（Ｓ２３）。ライセンス数の残数が所定の閾値よりも少ない場合は購買担当者６等にその旨の警告を電子メール等により通知するようにしてもよい。その後、次のソフトウェアの処理に移る。全てのソフトウェアについてのループ処理が終了すると、ライセンスチェック処理を終了する。
【００７４】
＜ライセンス計算パターンおよびライセンス計算ロジック＞
以下では、図１６のライセンスチェック処理におけるソフトウェア毎のライセンス計算パターンおよびライセンス計算ロジック４２の内容について説明する。図１７は、ライセンス計算パターンの判断基準の１つとなるソフトウェアのグルーピングパターンの概念の例について示した図である。一般的に、ソフトウェアのライセンスの消費単位としては、ソフトウェアやバージョン、エディション単位など種々のものが存在し、メーカーやベンダー、ソフトウェア等により異なる場合がある。これらをカテゴライズすると、図１７に示すように、概ね以下の（ａ）〜（ｄ）の４つのパターン（以下ではこれを「グルーピングパターン」と記載する場合がある）に分類することが可能である。
【００７５】
（ａ）ソフトウェア毎にバージョンおよびエディションの単位でライセンスが必要となるもの。すなわち、同一ソフトウェアの同一バージョンであっても、エディションが異なれば別個のライセンスを必要とするもの。（ｂ）ソフトウェア毎にエディションの単位でライセンスが必要となるもの。すなわち、同一ソフトウェアについて異なるバージョンであっても、エディションが同一であればライセンスは共通となるもの。（ｃ）ソフトウェア毎にバージョンの単位でライセンスが必要となるもの。すなわち、エディションの考え方がないもの。（ｄ）ソフトウェアの単位でライセンスが必要となるもの。すなわち、エディションの考え方がなく、同一のソフトウェアであれば異なるバージョンであってもライセンスは共通となるもの。
【００７６】
上記の４つのパターンにおいて、（ａ）および（ｃ）のパターン、すなわち、異なるバージョンでは別個のライセンスを必要とするパターンは、本実施の形態のリソースプール２で使用されるような、メーカーやベンダーとの保守契約が付随するサーバ用のソフトウェアでは一般的ではなく基本的には存在しないと考えられる（ライセンスの購入ではなく保守契約によってバージョンアップが行われる）。また、一般的に利用される多くのソフトウェアが（ｄ）のパターンにカテゴライズされるものと考えられる。
【００７７】
なお、上記の４つの典型的なグルーピングパターンに属さない特殊なライセンス体系を有するソフトウェアも存在する（例えば、上位エディションのライセンスに下位エディションの利用権が存在するものなど）。これらについては、特殊パターンとして追加でグルーピングパターンを割当てることができる。
【００７８】
図１８は、ライセンス計算パターンの別の判断基準となるライセンス計算グループの概念の例について示した図である。本実施の形態のリソースプール２で使用されるような、仮想マシン上で稼働するソフトウェアの場合、導入されるサーバの構成によってライセンスの消費数が異なる場合がある。これらをカテゴライズすると、図１８に示すように、概ね以下の（１）〜（４）の４つのグループ（以下ではこれを「ライセンス計算グループ」と記載する場合がある）に分類することが可能である。
【００７９】
（１）導入される仮想マシンのｖＣＰＵ毎にライセンスが必要となるもの。（２）導入される仮想マシン毎にライセンスが必要となるもの。すなわち、導入される仮想マシンのｖＣＰＵの数に依存せずにライセンスが必要となるもの。（３）導入される物理サーバのＣＰＵ毎にライセンスが必要となるもの。すなわち、導入される仮想マシンの数に依存せず、また、導入される仮想マシンが利用しない物理ＣＰＵが存在する場合でも、物理サーバのＣＰＵ数分のライセンスが必要となるもの。（４）導入される物理サーバのＣＰＵのコア毎にライセンスが必要となるもの。すなわち、導入される仮想マシンの数に依存せず、また、導入される仮想マシンが利用しない物理ＣＰＵが存在する場合でも、物理サーバのＣＰＵコア数分のライセンスが必要となるもの。
【００８０】
なお、上記の４つの典型的なライセンス計算グループに属さない特殊なライセンス体系を有するソフトウェアも存在する（例えば、ｖＣＰＵの数について階段状にライセンス数が消費されるものや、導入される仮想マシンがハイパーバイザの割当てにより実際に利用する物理ＣＰＵの数分のライセンスが消費されるものなど）。これらについては、特殊グループとして追加でライセンス計算グループを割当てることができる。
【００８１】
図１９は、図１７に示したグルーピングパターンと、図１８に示したライセンス計算グループをマトリクス化し、これらの組み合わせに対してライセンス計算パターンを割当てた例を示した図である。図中において、典型的なグルーピングパターン（ａ）〜（ｄ）および典型的なライセンス計算グループ（１）〜（４）からなる部分については、基本的に存在しないと考えられる（ａ）および（ｃ）のグルーピングパターンを除き、ライセンス計算パターン（“＃００１”〜“＃００４”）を割当てている。また、特殊なグルーピングパターン（ｅ）およびライセンス計算グループ（５）〜（８）についても、該当する箇所にライセンス計算パターン（“＃１０５”〜“＃１０８”）を割当てることができる。
【００８２】
ここで、ライセンス計算パターンとは、ライセンスの消費数を算出する際の計算方法（ロジック）のパターンであり、ソフトウェア毎にグルーピングパターンおよびライセンス計算グループに基づいて割当てられ、ＳＷマスタＤＢ１２のライセンス計算パターンの項目に予め設定される。各ライセンス計算パターンに対応するライセンス消費数の計算ロジックはライセンス計算ロジック４２に定義され、ライセンスチェック部４０によって管理される。
【００８３】
図中に示すとおり、上述したライセンス計算グループ（１）〜（４）において、（ｂ）と（ｄ）のグルーピングパターンでは同じライセンス計算パターン（“＃００１”〜“＃００４”）となることを示している。これらのライセンス計算パターンに対応する具体的な計算方法であるライセンス計算ロジック４２の概要は例えば以下の通りである。
【００８４】
ライセンス計算パターン“＃００１”では、まず、ライセンスの消費数の算出対象のソフトウェアについて、ＳＷマスタＤＢ１２から、親ソフトウェアＩＤの項目に算出対象のソフトウェアのソフトウェアＩＤが指定されているレコードを抽出する。次に、仮想ＳＷ構成ＤＢ３３により、算出対象のソフトウェアおよび先に抽出したレコードに対応するソフトウェアについて、これらが導入された仮想マシンを特定し、さらに仮想ＨＷ構成ＤＢ３２により、対象の各仮想マシンのｖＣＰＵ数を取得する。取得したｖＣＰＵ数を全て加算したものが対象のソフトウェアのライセンス消費数となるため、これをライセンス状況ＤＢ４１に登録する。
【００８５】
ライセンス計算パターン“＃００２”では、“＃００１”と同様に、まず、算出対象のソフトウェアについて、ＳＷマスタＤＢ１２から、親ソフトウェアＩＤの項目に算出対象のソフトウェアのソフトウェアＩＤが指定されているレコードを抽出する。次に、仮想ＳＷ構成ＤＢ３３により、算出対象のソフトウェアおよび先に抽出したレコードに対応するソフトウェアについて、これらが導入された仮想マシンを特定する。特定した仮想マシンの台数が対象のソフトウェアのライセンス消費数となるため、これをライセンス状況ＤＢ４１に登録する。
【００８６】
ライセンス計算パターン“＃００３”では、“＃００１”と同様に、まず、算出対象のソフトウェアについて、ＳＷマスタＤＢ１２から、親ソフトウェアＩＤの項目に算出対象のソフトウェアのソフトウェアＩＤが指定されているレコードを抽出する。次に、仮想ＳＷ構成ＤＢ３３により、算出対象のソフトウェアおよび先に抽出したレコードに対応するソフトウェアについて、これらが導入された物理サーバを特定し、さらにＨＷ構成ＤＢ３１により、対象の物理サーバのＣＰＵ数を取得する。取得したＣＰＵ数を全て加算したものが対象のソフトウェアのライセンス消費数となるため、これをライセンス状況ＤＢ４１に登録する。
【００８７】
ライセンス計算パターン“＃００４”では、“＃００１”と同様に、まず、算出対象のソフトウェアについて、ＳＷマスタＤＢ１２から、親ソフトウェアＩＤの項目に算出対象のソフトウェアのソフトウェアＩＤが指定されているレコードを抽出する。次に、仮想ＳＷ構成ＤＢ３３により、算出対象のソフトウェアおよび先に抽出したレコードに対応するソフトウェアについて、これらが導入された物理サーバを特定し、さらにＨＷ構成ＤＢ３１により、対象の物理サーバのＣＰＵコア数を取得する。取得したＣＰＵコア数を全て加算したものが対象のソフトウェアのライセンス消費数となるため、これをライセンス状況ＤＢ４１に登録する。
【００８８】
このように、グルーピングパターンおよびライセンス計算グループの組み合わせにより各ソフトウェアのライセンス体系をカテゴライズしてライセンス計算パターンを割当て、対応するライセンス計算ロジック４２を定義することにより、仮想マシン上で稼働するソフトウェアのライセンス体系と実際のシステム構成に応じたライセンス消費数の算出が可能となる。
【００８９】
＜リソースプール管理処理−構築時の在庫仮押え＞
以下では、本発明の一実施の形態であるリソースプール管理システム１における管理処理の他の内容として、リソースプール２へのシステムの新たな展開・構築の際に、システム構築部７０からの要求により、在庫管理部５０が必要となるリソースを仮押えする際の処理について説明する。
【００９０】
図２０は、ハードウェアリソースについて在庫を仮押えする処理の流れの例について概要を示したフローチャートである。ハードウェアの在庫仮押え処理を開始すると、在庫管理部５０は、まず、システム構築部７０が構築仕様１３に基づいて指定した構築対象の各ハードウェアについて処理を行うループ処理を開始する。当該ループ処理では、まず、対象のハードウェアについてＨＷ在庫ＤＢ５１を参照して在庫があるか否かを確認し（Ｓ３１）、在庫がない場合は当該ハードウェアの情報を記憶した上で次のハードウェアの処理に移る。
【００９１】
ステップＳ３１において在庫がある場合は、ＨＷ在庫仮押えＤＢ５３に必要なリソースの情報をシステム構築部７０から指定されたインシデントＩＤの情報とともに登録する（Ｓ３２）。このとき対象の物理サーバについて既に仮押え情報が登録されている場合はこれに加算して更新する。さらに、ＨＷ在庫ＤＢ５１の対応するリソースの在庫量を減算して更新し（Ｓ３３）、さらに、構成管理部３０に依頼する等によりＨＷ構成ＤＢ３１および仮想ＨＷ構成ＤＢ３２に対応する構成情報を登録する（Ｓ３４）。その後、次のハードウェアの処理に移る。構築対象の全てのハードウェアについてのループ処理が終了すると、在庫の仮押えの結果をシステム担当者４に通知する等の処理を行った上でハードウェアの在庫仮押え処理を終了する。
【００９２】
図２１は、ソフトウェアのライセンスについて在庫を仮押えする処理の流れの例について概要を示したフローチャートである。ソフトウェアの在庫仮押え処理を開始すると、在庫管理部５０は、まず、システム構築部７０が構築仕様１３に基づいて指定した構築（導入）対象の各ソフトウェアについて処理を行うループ処理を開始する。
【００９３】
当該ループ処理では、まず、対象のソフトウェアについてＳＷマスタＤＢ１２を参照し、ライセンス体系が物理サーバに依存する（仮想マシンに依存しない）ものであるか否かを確認する（Ｓ４１）。例えば、対象のソフトウェアが図１８に示したライセンス計算グループにおいて（３）もしくは（４）に該当するものである場合は物理サーバに依存するライセンス体系に該当する。本実施の形態では、このような判定を容易にするため、ＳＷマスタＤＢ１２に物理サーバ依存ライセンスフラグとしてライセンス条項や条件等に基づいて当該情報を予め設定しておくものとする。すなわち、ステップＳ４１では、ＳＷマスタＤＢ１２の物理サーバ依存ライセンスフラグの値を判定することになる。
【００９４】
ステップＳ４１で対象のソフトウェアが物理サーバに依存するライセンス体系でない場合は、後述するステップＳ４５に進む。物理サーバに依存するライセンス体系である場合は、次に、ライセンスの必要数を算出するための特殊なロジックが必要か否かを判定する（Ｓ４２）。ここでは、対象のソフトウェアを導入する仮想マシンが稼働する物理サーバのＣＰＵ数やコア数からの単純な計算により必要なライセンス数を算出することが困難なライセンス計算グループに属するような場合が該当する。
【００９５】
本実施の形態では、このような判断を容易にするため、ＳＷマスタＤＢ１２に在庫仮押え特殊ロジックＮｏとして、予め定義された特殊ロジックを特定する情報を設定可能であるものとする。在庫仮押え特殊ロジックＮｏの設定内容により特殊ロジックが必要であると判定される場合は、在庫仮押え特殊ロジックＮｏによって特定される特殊ロジックを利用してライセンスの消費数を算出し（Ｓ４３）、後述するステップＳ４６に進む。
【００９６】
ステップＳ４２で特殊ロジックが必要でない場合は、仮想ＳＷ構成ＤＢ３３を参照して、対象のソフトウェアが構築仕様１３にて指定された導入対象の物理サーバに既に導入されているか否かを判定する（Ｓ４４）。既に導入済みである場合は、対象のソフトウェアについてのライセンスは引当て済みであるとして、何もせずに次のソフトウェアの処理に移る。対象の物理サーバにまだ導入されていない場合は、対象のソフトウェアを対象の物理サーバに導入する際に消費するライセンス数を取得する（Ｓ４５）。具体的には、ＳＷマスタＤＢ１２の仮押えライセンス数の項目の値を取得する。
【００９７】
本来では、同一のソフトウェアであっても導入対象の物理サーバや仮想サーバのＣＰＵ数等の構成に応じてライセンスの消費数は異なる場合がある。しかしながら、クラウドコンピューティング環境では、大量のハードウェアリソースを維持・管理して提供する必要があることからその構成は物理サーバ間で統一される場合が多いと考えられる。従って、本実施の形態では、リソースプール２で管理される物理サーバのシステム構成は基本的に統一されているものとし、どの物理サーバに導入しても一律にＳＷマスタＤＢ１２における仮押えライセンス数に設定されたライセンス数が消費されるものとして計算の簡略化を図っている。なお、物理サーバの構成が統一されていない環境において、上述したソフトウェア在庫更新処理で示したように、導入対象の物理サーバの構成に基づいてライセンスの消費数を個別に算出する手順とすることも当然ながら可能である。
【００９８】
その後、対象のソフトウェアについて必要なライセンス数につき、ＳＷ在庫ＤＢ５２を参照してライセンスの在庫があるか否かを確認し（Ｓ４６）、在庫がない場合は当該ソフトウェアの情報を記憶した上で次のソフトウェアの処理に移る。
【００９９】
ステップＳ４６において在庫がある場合は、ＳＷ在庫仮押えＤＢ５４に必要なライセンス数の情報をシステム構築部７０から指定されたインシデントＩＤの情報とともに登録する（Ｓ４７）。このとき対象のソフトウェアについて既に仮押え情報が登録されている場合はこれに加算して更新する。さらに、ＳＷ在庫ＤＢ５２の対応するソフトウェアのライセンスの在庫数を減算して更新し（Ｓ４８）、さらに構成管理部３０に依頼する等により仮想ＳＷ構成ＤＢ３３に対応する構成情報を登録する（Ｓ４９）。その後、次のソフトウェアの処理に移る。導入対象の全てのソフトウェアについてのループ処理が終了すると、ライセンスの在庫の仮押えの結果をシステム担当者４に通知する等の処理を行った上でソフトウェアの在庫仮押え処理を終了する。
【０１００】
なお、上記のハードウェア／ソフトウェアの在庫仮押え処理による構築対象のハードウェア／ソフトウェアリソースの在庫の仮押えの成立をもって、システム担当者４がリソースプール２に対するシステム構築実行の承認（変更承認）を行うようすることが可能である。その後、リソースプール２におけるシステム構築が完了した際に、ＨＷ在庫仮押えＤＢ５３およびＳＷ在庫仮押えＤＢ５４のレコードを削除等することで、仮押えしていた在庫の引当てを確定することができる。
【０１０１】
以上に説明したように、本発明の一実施の形態であるリソースプール管理システム１もしくはライセンスチェックシステムによれば、リソースプール２において稼働中のシステムにおいて消費されているソフトウェア（特に仮想サーバ上で稼働し、ライセンス体系が複雑なソフトウェア）のライセンス数を適切に算出して、保有するライセンス数との比較により在庫に反映させるとともに、稼働中のシステムがライセンス違反となっていないことを確認することが可能となる。
【０１０２】
また、新たにシステムを構築する際に、システム構成に応じた適切なライセンス数を在庫から仮押えして確保した上で構築する。また、いずれの場合にも、保有ライセンス数が不足しそうであることを検知した場合は、購買担当者６等に通知してライセンスの購入を促すことができる。このような仕組みにより、クラウドコンピューティング環境でのリソースプールにおけるような大規模なシステム環境におけるソフトウェア（特に仮想サーバで稼働するソフトウェア）のライセンスの管理を効率的に行うことが可能となる。
【０１０３】
また、ソフトウェアのライセンス条項や条件が特殊なものである場合にも、対応するライセンス計算ロジック４２を定義してライセンス計算パターンを割当てることでライセンスの消費数を算出することが可能であり、高い拡張性も有する。
【０１０４】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【０１０５】
本発明は、クラウドコンピューティングサービス等において利用される仮想マシンや仮想サーバ上で稼働するソフトウェアのライセンスの有無をチェックするライセンスチェックシステムおよびリソースプール管理システムに利用可能である。
【符号の説明】
【０１０６】
１…リソースプール管理システム、２…リソースプール、３…サービスポータル、４…システム担当者、５…営業担当者、６…購買担当者、
１１…ＨＷマスタＤＢ、１２…ＳＷマスタＤＢ、１３…構築仕様、
２０…資産管理部、２１…資産台帳ＤＢ、
３０…構成管理部、３１…ＨＷ構成ＤＢ、３２…仮想ＨＷ構成ＤＢ、３３…仮想ＳＷ構成ＤＢ、
４０…ライセンスチェック部、４１…ライセンス状況ＤＢ、４２…ライセンス計算ロジック、
５０…在庫管理部、５１…ＨＷ在庫ＤＢ、５２…ＳＷ在庫ＤＢ、５３…ＨＷ在庫仮押えＤＢ、５４…ＳＷ在庫仮押えＤＢ、
６０…契約管理部、６１…契約内容管理ＤＢ、
７０…システム構築部。
【特許請求の範囲】
【請求項１】
複数の物理サーバ上で稼働する仮想マシンおよび各仮想マシン上で稼働するソフトウェアからなるシステム環境であるリソースプールにおいてソフトウェア毎に実際に消費されているライセンスの数を把握するライセンスチェックシステムであって、
前記リソースプールにおいて稼働中のシステムの構成情報をディスカバリして、物理サーバの構成情報を含むハードウェア構成、物理サーバ上で稼働する仮想マシンの構成情報を含む仮想ハードウェア構成および仮想マシン上で稼働するソフトウェアの情報を含む仮想ソフトウェア構成の各情報を取得し、これらをそれぞれ、ＨＷ構成記録手段、仮想ＨＷ構成記録手段および仮想ＳＷ構成記録手段に記録して保持する構成管理部と、
前記構成管理部から前記ハードウェア構成、前記仮想ハードウェア構成および前記仮想ソフトウェア構成の情報を取得し、これらの情報に基づいて、前記リソースプールにおいて稼働中のシステム環境で消費されている各ソフトウェアのライセンス数を、各ソフトウェアのライセンス体系の特性毎にカテゴライズして予め定義されたライセンス計算ロジックに従って算出し、ライセンス状況記録手段に記録するライセンスチェック部とを有することを特徴とするライセンスチェックシステム。
【請求項２】
請求項１に記載のライセンスチェックシステムにおいて、
各ソフトウェアのライセンス体系について、ソフトウェア、バージョンおよびエディションのいずれの単位でライセンスが消費されるかをカテゴライズしたグルーピングパターンと、各ソフトウェアのライセンス体系について、導入される機器の構成によってライセンスの消費数が異なるパターンをカテゴライズしたライセンス計算グループとの組み合わせに対してライセンス計算パターンを割り当て、
前記ライセンスチェック部は、前記ライセンス計算パターンに対応して予め定義された前記ライセンス計算ロジックを保持することを特徴とするライセンスチェックシステム。
【請求項３】
請求項２に記載のライセンスチェックシステムにおいて、
前記グルーピングパターンは、（ａ）ソフトウェア毎にバージョンおよびエディションの単位でライセンスが必要となるもの、（ｂ）ソフトウェア毎にエディションの単位でライセンスが必要となるもの、（ｃ）ソフトウェア毎にバージョンの単位でライセンスが必要となるもの、（ｄ）ソフトウェアの単位でライセンスが必要となるもの、の各パターンを含み、
前記ライセンス計算グループは、（１）導入される仮想マシンの仮想ＣＰＵ毎にライセンスが必要となるもの、（２）導入される仮想マシン毎にライセンスが必要となるもの、（３）導入される物理サーバのＣＰＵ毎にライセンスが必要となるもの、（４）導入される物理サーバのＣＰＵの物理コア毎にライセンスが必要となるもの、の各パターンを含むことを特徴とするライセンスチェックシステム。
【請求項４】
請求項１〜３のいずれか１項に記載のライセンスチェックシステムを有し、
顧客からの要求に基づく構築仕様の内容に従って、前記リソースプールにおいてハードウェアおよびソフトウェアのリソースを展開してシステムを構築してサービスとして提供するリソースプール管理システムであって、
さらに、前記リソースプールにて保有するハードウェアのリソース量およびソフトウェアのライセンスの数を含む情報を資産台帳記録手段に記録して保持する資産管理部と、
前記リソースプールにて保有するハードウェアのリソースおよびソフトウェアのライセンスの数量の未使用もしくは未割当て分を在庫としてＨＷ在庫記録手段およびＳＷ在庫記録手段にそれぞれ記録して保持する在庫管理部とを有し、
前記在庫管理部は、前記資産管理部が有するハードウェアの保有リソース量と、前記構成管理部が有する前記ハードウェア構成および前記仮想ハードウェア構成から得られる前記リソースプールで稼働中のシステムにおける消費リソース量との差分から、ハードウェアのリソースの在庫情報を算出して前記ＨＷ在庫記録手段の内容を更新し、また、前記資産管理部が有するソフトウェアの保有ライセンス数と、前記ライセンスチェック部が有するソフトウェアの消費ライセンス数との差分から、ソフトウェアのライセンスの在庫情報を算出して前記ＳＷ在庫記録手段の内容を更新することを特徴とするリソースプール管理システム。
【請求項５】
請求項４に記載のリソースプール管理システムにおいて、
前記在庫管理部は、前記リソースプールにおいてハードウェアまたはソフトウェアのリソースを展開してシステムを構築する際に、前記構築仕様にて指定されたハードウェアまたはソフトウェアについて、必要なリソース量またはライセンス数を、前記ＨＷ在庫記録手段または前記ＳＷ在庫記録手段に保持する在庫から仮押えすることを特徴とするリソースプール管理システム。
【請求項６】
請求項５に記載のリソースプール管理システムにおいて、
前記リソースプールにおける各物理サーバのシステム構成は統一されており、
前記在庫管理部は、前記構築仕様にて指定されたソフトウェアについて在庫を仮押えする際に、各ソフトウェアについてライセンスの消費数が物理サーバに依存するか否か、および仮押えの際の消費ライセンスの単位数について予め定義された情報に基づいて、前記構築仕様にて指定された導入先の物理サーバもしくは仮想マシンの情報に応じて必要なライセンス数を算出して仮押えすることを特徴とするリソースプール管理システム。
【請求項７】
請求項４〜６のいずれか１項に記載のリソースプール管理システムにおいて、
前記在庫管理部は、前記ＨＷ在庫記録手段または前記ＳＷ在庫記録手段に保持する在庫の数量が所定の閾値より少ないことを検知した場合に、その旨をユーザに通知することを特徴とするリソースプール管理システム。
【請求項１】
複数の物理サーバ上で稼働する仮想マシンおよび各仮想マシン上で稼働するソフトウェアからなるシステム環境であるリソースプールにおいてソフトウェア毎に実際に消費されているライセンスの数を把握するライセンスチェックシステムであって、
前記リソースプールにおいて稼働中のシステムの構成情報をディスカバリして、物理サーバの構成情報を含むハードウェア構成、物理サーバ上で稼働する仮想マシンの構成情報を含む仮想ハードウェア構成および仮想マシン上で稼働するソフトウェアの情報を含む仮想ソフトウェア構成の各情報を取得し、これらをそれぞれ、ＨＷ構成記録手段、仮想ＨＷ構成記録手段および仮想ＳＷ構成記録手段に記録して保持する構成管理部と、
前記構成管理部から前記ハードウェア構成、前記仮想ハードウェア構成および前記仮想ソフトウェア構成の情報を取得し、これらの情報に基づいて、前記リソースプールにおいて稼働中のシステム環境で消費されている各ソフトウェアのライセンス数を、各ソフトウェアのライセンス体系の特性毎にカテゴライズして予め定義されたライセンス計算ロジックに従って算出し、ライセンス状況記録手段に記録するライセンスチェック部とを有することを特徴とするライセンスチェックシステム。
【請求項２】
請求項１に記載のライセンスチェックシステムにおいて、
各ソフトウェアのライセンス体系について、ソフトウェア、バージョンおよびエディションのいずれの単位でライセンスが消費されるかをカテゴライズしたグルーピングパターンと、各ソフトウェアのライセンス体系について、導入される機器の構成によってライセンスの消費数が異なるパターンをカテゴライズしたライセンス計算グループとの組み合わせに対してライセンス計算パターンを割り当て、
前記ライセンスチェック部は、前記ライセンス計算パターンに対応して予め定義された前記ライセンス計算ロジックを保持することを特徴とするライセンスチェックシステム。
【請求項３】
請求項２に記載のライセンスチェックシステムにおいて、
前記グルーピングパターンは、（ａ）ソフトウェア毎にバージョンおよびエディションの単位でライセンスが必要となるもの、（ｂ）ソフトウェア毎にエディションの単位でライセンスが必要となるもの、（ｃ）ソフトウェア毎にバージョンの単位でライセンスが必要となるもの、（ｄ）ソフトウェアの単位でライセンスが必要となるもの、の各パターンを含み、
前記ライセンス計算グループは、（１）導入される仮想マシンの仮想ＣＰＵ毎にライセンスが必要となるもの、（２）導入される仮想マシン毎にライセンスが必要となるもの、（３）導入される物理サーバのＣＰＵ毎にライセンスが必要となるもの、（４）導入される物理サーバのＣＰＵの物理コア毎にライセンスが必要となるもの、の各パターンを含むことを特徴とするライセンスチェックシステム。
【請求項４】
請求項１〜３のいずれか１項に記載のライセンスチェックシステムを有し、
顧客からの要求に基づく構築仕様の内容に従って、前記リソースプールにおいてハードウェアおよびソフトウェアのリソースを展開してシステムを構築してサービスとして提供するリソースプール管理システムであって、
さらに、前記リソースプールにて保有するハードウェアのリソース量およびソフトウェアのライセンスの数を含む情報を資産台帳記録手段に記録して保持する資産管理部と、
前記リソースプールにて保有するハードウェアのリソースおよびソフトウェアのライセンスの数量の未使用もしくは未割当て分を在庫としてＨＷ在庫記録手段およびＳＷ在庫記録手段にそれぞれ記録して保持する在庫管理部とを有し、
前記在庫管理部は、前記資産管理部が有するハードウェアの保有リソース量と、前記構成管理部が有する前記ハードウェア構成および前記仮想ハードウェア構成から得られる前記リソースプールで稼働中のシステムにおける消費リソース量との差分から、ハードウェアのリソースの在庫情報を算出して前記ＨＷ在庫記録手段の内容を更新し、また、前記資産管理部が有するソフトウェアの保有ライセンス数と、前記ライセンスチェック部が有するソフトウェアの消費ライセンス数との差分から、ソフトウェアのライセンスの在庫情報を算出して前記ＳＷ在庫記録手段の内容を更新することを特徴とするリソースプール管理システム。
【請求項５】
請求項４に記載のリソースプール管理システムにおいて、
前記在庫管理部は、前記リソースプールにおいてハードウェアまたはソフトウェアのリソースを展開してシステムを構築する際に、前記構築仕様にて指定されたハードウェアまたはソフトウェアについて、必要なリソース量またはライセンス数を、前記ＨＷ在庫記録手段または前記ＳＷ在庫記録手段に保持する在庫から仮押えすることを特徴とするリソースプール管理システム。
【請求項６】
請求項５に記載のリソースプール管理システムにおいて、
前記リソースプールにおける各物理サーバのシステム構成は統一されており、
前記在庫管理部は、前記構築仕様にて指定されたソフトウェアについて在庫を仮押えする際に、各ソフトウェアについてライセンスの消費数が物理サーバに依存するか否か、および仮押えの際の消費ライセンスの単位数について予め定義された情報に基づいて、前記構築仕様にて指定された導入先の物理サーバもしくは仮想マシンの情報に応じて必要なライセンス数を算出して仮押えすることを特徴とするリソースプール管理システム。
【請求項７】
請求項４〜６のいずれか１項に記載のリソースプール管理システムにおいて、
前記在庫管理部は、前記ＨＷ在庫記録手段または前記ＳＷ在庫記録手段に保持する在庫の数量が所定の閾値より少ないことを検知した場合に、その旨をユーザに通知することを特徴とするリソースプール管理システム。
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１９】
【図２０】
【図２１】
【図１】
【図１７】
【図１８】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１９】
【図２０】
【図２１】
【図１】
【図１７】
【図１８】
【公開番号】特開２０１２−３３０９６（Ｐ２０１２−３３０９６Ａ）
【公開日】平成２４年２月１６日（２０１２．２．１６）
【国際特許分類】
【出願番号】特願２０１０−１７３６７７（Ｐ２０１０−１７３６７７）
【出願日】平成２２年８月２日（２０１０．８．２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２４年２月１６日（２０１２．２．１６）
【国際特許分類】
【出願日】平成２２年８月２日（２０１０．８．２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]